Passpoint (Hotspot 2.0)

O Passpoint é um protocolo Wi-Fi Alliance (WFA) que permite que dispositivos móveis descubram e autentiquem pontos de acesso Wi-Fi que fornecem acesso à Internet.

Suporte a dispositivos

Para oferecer suporte ao Passpoint, os fabricantes de dispositivos precisam implementar hardware/interfaces/wifi/supplicant/1.0 ou superior. A linguagem de design de interface Wi-Fi HAL (HIDL) fornecida no Android Open Source Project (AOSP) define um HAL para o suplicante. O requerente fornece suporte para o padrão 802.11u, especificamente para recursos de descoberta e seleção de rede, como Serviço de anúncio genérico (GAS) e protocolo de consulta de rede de acesso (ANQP).

Implementação

Android 11 ou superior

Para oferecer suporte ao Passpoint em dispositivos com Android 11 ou superior, os fabricantes de dispositivos precisam fornecer suporte de firmware para 802.11u. Todos os outros requisitos para suporte ao Passpoint estão incluídos no AOSP.

Android 10 ou inferior

Para dispositivos com Android 10 ou inferior, os fabricantes de dispositivos precisam fornecer suporte à estrutura e HAL/firmware:

  • Framework: Enable Passpoint (requer um sinalizador de recurso)
  • Firmware: Suporte para 802.11u

Para oferecer suporte ao Passpoint, implemente o Wi-Fi HAL e ative o sinalizador de recurso para o Passpoint. Em device.mk localizado em device/<oem>/<device> , modifique a variável de ambiente PRODUCT_COPY_FILES para incluir suporte para o recurso Passpoint:

PRODUCT_COPY_FILES +=
frameworks/native/data/etc/android.hardware.wifi.passpoint.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.passpoint.xml

Todos os outros requisitos para suporte ao Passpoint estão incluídos no AOSP.

Validação

Para validar sua implementação do recurso Passpoint, use o conjunto de testes de unidade e testes de integração fornecidos no Android Comms Test Suite (ACTS).

Testes de unidade

Execute os seguintes testes de unidade do pacote Passpoint.

Testes de serviço:

atest com.android.server.wifi.hotspot2

Testes do gerente:

atest android.net.wifi.hotspot2

Testes de integração (ACTS)

O conjunto de testes do ACTS Passpoint, localizado em tools/test/connectivity/acts_tests/tests/google/wifi/WifiPasspointTest.py , implementa um conjunto de testes funcionais.

Provisionamento de passpoint R1

O Android oferece suporte ao Passpoint R1 desde o Android 6.0, permitindo o provisionamento de credenciais do Passpoint R1 (versão 1) por meio do download baseado na Web de um arquivo especial que contém informações de perfil e credenciais. O cliente inicia automaticamente um instalador especial para as informações de Wi-Fi e permite que o usuário visualize partes das informações antes de aceitar ou recusar o conteúdo.

As informações de perfil contidas no arquivo são usadas para corresponder aos dados recuperados de pontos de acesso habilitados para Passpoint e as credenciais são aplicadas automaticamente para qualquer rede correspondente.

A implementação de referência do Android é compatível com EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA e EAP-AKA'.

Mecanismo de download

O arquivo de configuração do Passpoint deve ser hospedado em um servidor web e deve ser protegido com TLS (HTTPS), pois pode conter senha de texto simples ou dados de chave privada. O conteúdo é composto de texto MIME de várias partes encapsulado representado em UTF-8 e codificado na codificação base64 por RFC-2045 seção 6.8.

Os seguintes campos de cabeçalho HTTP são usados ​​pelo cliente para iniciar automaticamente um instalador de Wi-Fi no dispositivo:

  • Content-Type deve ser definido como application/x-wifi-config .
  • Content-Transfer-Encoding deve ser definido como base64 .
  • Content-Disposition não deve ser definido.

O método HTTP usado para recuperar o arquivo deve ser GET. Sempre que um HTTP GET do navegador recebe uma resposta com esses cabeçalhos MIME, o aplicativo de instalação é iniciado. O download deve ser acionado tocando em um elemento HTML, como um botão (os redirecionamentos automáticos para um URL de download não são suportados). Esse comportamento é específico do Google Chrome; outros navegadores da web podem ou não fornecer funcionalidade semelhante.

Composição do arquivo

O conteúdo codificado em Base64 deve consistir em conteúdo MIME multipart com um Content-Type de multipart/mixed . As partes a seguir compõem as partes individuais do conteúdo de várias partes.

Papel Tipo de conteúdo (menos aspas) Requerido Descrição
Perfil application/x-passpoint-profile Sempre Carga formatada OMA-DM SyncML contendo o MO formatado Passpoint R1 PerProviderSubscription para HomeSP e Credential .
Certificado de confiança application/x-x509-ca-cert Necessário para EAP-TLS e EAP-TTLS Uma única carga útil de certificado codificado em base64 X.509v3.
Chave EAP-TLS application/x-pkcs12 Obrigatório para EAP-TLS Uma estrutura PKCS #12 ASN.1 codificada em base64 contendo uma cadeia de certificados de cliente com pelo menos o certificado de cliente e a chave privada associada. O contêiner PKCS 12, bem como a chave privada e os certificados, devem estar em texto não criptografado sem senha.

A seção Perfil deve ser transferida como texto XML codificado em base64 e codificado em UTF-8 que especifica partes das subárvores HomeSP e Credential na Especificação Técnica do Passpoint R2 Versão 1.0.0, seção 9.1.

O nó de nível superior deve ser MgmtTree e o subnó imediato deve ser PerProviderSubscription . Um arquivo XML de exemplo aparece no perfil de exemplo OMA-DM XML .

Os seguintes nós de subárvore são usados ​​em HomeSP :

  • FriendlyName : Deve ser definido; usado como texto de exibição
  • FQDN : obrigatório
  • RoamingConsortiumOI

Os seguintes nós de subárvore são usados ​​em Credential :

  • Realm : deve ser uma string não vazia
  • UsernamePassword : Necessário para EAP-TTLS com os seguintes nós definidos:

    • Nome de Username : String que contém o nome de usuário
    • Password : string codificada em Base64 (definida como cGFzc3dvcmQ= , a string codificada em base64 para "senha", no exemplo abaixo)
    • EAPMethod/EAPType : deve ser definido como 21
    • EAPMethod/InnerMethod : Deve ser definido como PAP , CHAP , MS-CHAP ou MS-CHAP-V2
  • DigitalCertificate : Necessário para EAP-TLS. Os seguintes nós devem ser definidos:

    • CertificateType definido como x509v3
    • CertSHA256Fingerprint definido para o resumo SHA-256 correto do certificado do cliente na seção MIME da chave EAP-TLS
  • SIM : Necessário para EAP-SIM, EAP-AKA e EAP-AKA'. O campo EAPType deve ser definido para o tipo de EAP apropriado e o IMSI deve corresponder a um IMSI de um dos cartões SIM instalados no dispositivo no momento do provisionamento. A string IMSI pode consistir inteiramente de dígitos decimais para forçar a correspondência de igualdade total ou de zero ou mais dígitos decimais seguidos por um asterisco (*) para relaxar a correspondência de IMSI apenas para prefixo. Por exemplo, a string IMSI 123* corresponde a qualquer cartão SIM com um IMSI começando com 123.

O Android 11 apresenta recursos que tornam o provisionamento do Passpoint R1 mais flexível.

Nome de domínio separado de autenticação, autorização e contabilidade (AAA)

Os administradores de rede de ponto de acesso que exigem um nome de domínio AAA especificado independentemente do nome de domínio totalmente qualificado (FQDN) anunciado pela rede por meio do Access Network Query Protocol (ANQP) podem especificar uma lista de FQDNs delimitada por ponto e vírgula em um novo nó na subárvore Extension . Este é um nó opcional e os dispositivos que executam o Android versão 10 ou inferior ignoram esse nó.

  • Android : subárvore de extensão do Android

    • AAAServerTrustedNames : Necessário para nomes confiáveis ​​de servidor AAA com os seguintes nós definidos:

      • FQDN : String que contém os nomes confiáveis ​​do servidor AAA. Use ponto e vírgula para separar os nomes confiáveis. Por exemplo, example.org;example.com .
CAs raiz privadas autoassinadas
Os administradores de rede de passpoint que gerenciam seus certificados internamente podem provisionar perfis com uma CA autoassinada privada para autenticação AAA.
Permitir a instalação de perfis sem um certificado de CA raiz
O certificado de CA raiz anexado ao perfil é usado para autenticação de servidor AAA. Os administradores de rede de ponto de acesso que desejam confiar em CAs raiz confiáveis ​​públicas para sua autenticação de servidor AAA podem provisionar perfis sem um certificado de CA raiz. Nesse caso, o sistema verifica os certificados do servidor AAA em relação aos certificados públicos da CA raiz instalados no armazenamento confiável.

Provisionamento do Passpoint R2

O Android 10 introduziu suporte para recursos do Passpoint R2. O Passpoint R2 implementa a inscrição online (OSU), um método padrão para provisionar novos perfis do Passpoint. O Android 10 e superior oferece suporte ao provisionamento de perfis EAP-TTLS usando o protocolo SOAP-XML em OSU ESS aberto.

Os recursos suportados do Passpoint R2 requerem apenas o código de referência AOSP, nenhum driver adicional ou suporte de firmware é necessário). O código de referência AOSP também inclui uma implementação padrão da interface do usuário do Passpoint R2 no aplicativo Configurações.

Quando o Android detecta um ponto de acesso Passpoint R2, a estrutura do Android:

  1. Exibe uma lista dos provedores de serviços anunciados pelo AP no seletor de Wi-Fi (além de exibir os SSIDs).
  2. Solicita que o usuário toque em um dos provedores de serviços para configurar um perfil do Passpoint.
  3. Orienta o usuário pelo fluxo de configuração do perfil do Passpoint.
  4. Instala o perfil Passpoint resultante na conclusão bem-sucedida.
  5. Associa-se à rede Passpoint usando o perfil Passpoint recém-provisionado.

Recursos do Passpoint R3

O Android 12 apresenta os seguintes recursos do Passpoint R3 que melhoram a experiência do usuário e permitem que as redes cumpram as leis locais:

Termos e Condições

A aceitação dos termos e condições é legalmente exigida em alguns locais e locais para fornecer acesso à rede. Esse recurso permite que as implantações de rede substituam portais cativos inseguros, que usam redes abertas, por uma rede Passpoint segura. Uma notificação é exibida ao usuário quando os termos e condições precisam ser aceitos.

O URL dos termos e condições deve apontar para um site seguro usando HTTPS. Se a URL apontar para um site inseguro, a estrutura desconecta imediatamente e bloqueia a rede.

URL de informações do local

Permite que operadores de rede e locais forneçam informações adicionais ao usuário, como mapas de locais, diretórios, promoções e cupons. Uma notificação é exibida ao usuário quando a rede está conectada.

A URL de informações do local deve apontar para um site seguro usando HTTPS. Se a URL apontar para um site inseguro, a estrutura ignorará a URL e não exibirá uma notificação.

Outros recursos do Passpoint

O Android 11 apresenta os seguintes recursos do Passpoint que melhoram a experiência do usuário, o uso de energia e a flexibilidade de implantação.

Aplicação e notificação da data de expiração
A imposição de datas de expiração nos perfis permite que a estrutura evite a conexão automática a pontos de acesso com credenciais expiradas, que estão fadadas a falhar. Isso evita o uso do tempo de antena e economiza bateria e largura de banda de back-end. A estrutura exibe uma notificação ao usuário quando uma rede correspondente ao seu perfil está no alcance e o perfil expirou.
Vários perfis com FQDN idêntico
As operadoras que implantam redes Passpoint e usam vários IDs de rede móvel terrestre pública (PLMN) podem provisionar vários perfis Passpoint com o mesmo FQDN, um para cada ID PLMN, que é automaticamente correspondido ao cartão SIM instalado e usado para conectar a rede.

O Android 12 apresenta os seguintes recursos do Passpoint que melhoram a experiência do usuário, o uso de energia e a flexibilidade de implantação:

Prefixo de identidade decorado
Ao autenticar em redes com uma decoração de prefixo, o prefixo de identidade decorado permite que os operadores de rede atualizem o Identificador de Acesso à Rede (NAI) para executar roteamento explícito por meio de vários proxies dentro de uma rede AAA (consulte RFC 7542 ). O Android 12 implementa esse recurso de acordo com a especificação WBA para extensões PPS-MO .
Tratamento iminente de desautenticação
Permite que os operadores de rede sinalizem a um dispositivo que o serviço não está disponível para a credencial usada para autenticar a rede por um determinado período (especificado por meio de um atraso de tempo limite). Depois de receber este sinal, os dispositivos não tentarão se reconectar à rede com a mesma credencial até que o tempo limite expire. Por outro lado, os dispositivos que não oferecem suporte a esse recurso podem tentar se reconectar repetidamente à rede enquanto o serviço não estiver disponível.

Exemplos de perfis XML OMA-DM PerProviderSubscription-MO

Perfil com uma credencial de nome de usuário/senha (EAP-TTLS)

O exemplo a seguir demonstra um perfil para uma rede com:

  • Nome amigável de rede definido como Example Network
  • FQDN definido como hotspot.example.net
  • OIs de consórcio de roaming (para roaming)
  • Credencial com nome de user , senha password codificada com Base64 e realm definido como example.net
  • Método EAP definido como 21 (EAP-TTLS)
  • Método interno da fase 2 definido como MS-CHAP-V2
  • Nomes de domínio AAA alternativos definidos como trusted.com e trusted.net
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>Example Network</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>hotspot.example.net</Value>
        </Node>
        <Node>
          <NodeName>RoamingConsortiumOI</NodeName>
          <Value>112233,445566</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>example.net</Value>
        </Node>
        <Node>
          <NodeName>UsernamePassword</NodeName>
          <Node>
            <NodeName>Username</NodeName>
            <Value>user</Value>
          </Node>
          <Node>
            <NodeName>Password</NodeName>
            <Value>cGFzc3dvcmQ=</Value>
          </Node>
          <Node>
            <NodeName>EAPMethod</NodeName>
            <Node>
              <NodeName>EAPType</NodeName>
              <Value>21</Value>
            </Node>
            <Node>
              <NodeName>InnerMethod</NodeName>
              <Value>MS-CHAP-V2</Value>
            </Node>
          </Node>
        </Node>
      </Node>
      <Node>
        <NodeName>Extension</NodeName>
        <Node>
            <NodeName>Android</NodeName>
            <Node>
                <NodeName>AAAServerTrustedNames</NodeName>
                <Node>
                    <NodeName>FQDN</NodeName>
                    <Value>trusted.com;trusted.net</Value>
                </Node>
            </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Perfil com uma credencial de certificado digital (EAP-TLS)

O exemplo a seguir demonstra um perfil para uma rede com:

  • Nome amigável de rede definido como GlobalRoaming
  • FQDN definido como globalroaming.net
  • OIs de consórcio de roaming (para roaming)
  • Domínio definido como users.globalroaming.net
  • Credencial com um certificado digital que tenha a impressão digital especificada
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>GlobalRoaming</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>globalroaming.net</Value>
        </Node>
        <Node>
          <NodeName>RoamingConsortiumOI</NodeName>
          <Value>FFEEDDCC0,FFEEDDCC1,009999,008888</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>users.globalroaming.net</Value>
        </Node>
        <Node>
          <NodeName>DigitalCertificate</NodeName>
          <Node>
            <NodeName>CertificateType</NodeName>
            <Value>x509v3</Value>
          </Node>
          <Node>
            <NodeName>CertSHA256Fingerprint</NodeName>
            <Value>0ef08a3d2118700474ca51fa25dc5e6d3d63d779aaad8238b608a853761da533</Value>
          </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Perfil com uma credencial SIM (EAP-AKA)

O exemplo a seguir demonstra um perfil para uma rede com:

  • Nome amigável de rede definido como Purple Passpoint
  • FQDN definido como wlan.mnc888.mcc999.3gppnetwork.org
  • Credencial SIM com ID PLMN de 999888
  • Método EAP definido como 23 (EAP-AKA)
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>Purple Passpoint</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>purplewifi.com</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>wlan.mnc888.mcc999.3gppnetwork.org</Value>
        </Node>
        <Node>
          <NodeName>SIM</NodeName>
          <Node>
            <NodeName>IMSI</NodeName>
            <Value>999888*</Value>
          </Node>
          <Node>
            <NodeName>EAPType</NodeName>
            <Value>23</Value>
          </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Aviso de autenticação

Dispositivos que executam o Android 8.x ou Android 9 com um perfil Passpoint R1 EAP-SIM, EAP-AKA ou EAP-AKA' não se conectarão automaticamente à rede Passpoint. Esse problema afeta usuários, operadoras e serviços ao reduzir o descarregamento de Wi-Fi.

Segmento Impacto Tamanho do impacto
Operadoras e provedores de serviços Passpoint Aumento da carga na rede celular. Qualquer operadora usando Passpoint R1.
Comercial Oportunidade perdida de se conectar automaticamente aos pontos de acesso (APs) Wi-Fi da operadora, resultando em custos de dados mais altos. Qualquer usuário com um dispositivo executado em uma rede de operadora com suporte para Passpoint R1.

Causa da falha

O Passpoint especifica um mecanismo para corresponder um provedor de serviços anunciado (ANQP) a um perfil instalado no dispositivo. As seguintes regras de correspondência para EAP-SIM, EAP-AKA e EAP-AKA' são um conjunto parcial de regras com foco nas falhas EAP-SIM/AKA/AKA':

If the FQDN (Fully Qualified Domain Name) matches
    then the service is a Home Service Provider.
Else: If the PLMN ID (3GPP Network) matches
    then the service is a Roaming Service Provider.

O segundo critério foi modificado no Android 8.0:

Else: If the PLMN ID (3GPP Network) matches AND the NAI Realm matches
    then the service is a Roaming Service Provider.

Com essa modificação, o sistema não observou nenhuma correspondência para provedores de serviços que funcionavam anteriormente, portanto, os dispositivos Passpoint não se conectavam automaticamente.

Soluções alternativas

Para contornar o problema dos critérios de correspondência modificados, as operadoras e os provedores de serviços precisam adicionar o domínio do identificador de acesso à rede (NAI) às informações publicadas pelo Passpoint AP.

A solução recomendada é que os provedores de serviços de rede implementem uma solução alternativa no lado da rede para um tempo de implantação mais rápido. Uma solução alternativa do lado do dispositivo depende dos OEMs pegarem uma lista de alterações (CL) do AOSP e, em seguida, atualizarem os dispositivos no campo.

Correção de rede para operadoras e provedores de serviços Passpoint

A solução alternativa do lado da rede requer a reconfiguração da rede para adicionar o elemento ANQP do território NAI conforme especificado abaixo. As especificações do Passpoint não exigem o elemento ANQP do território NAI, mas a adição dessa propriedade está em conformidade com as especificações do Passpoint, portanto, as implementações de cliente compatíveis com especificações não devem ser interrompidas.

  1. Adicione o elemento ANQP do território NAI.
  2. Defina o subcampo do domínio Realm para corresponder ao domínio do perfil instalado no dispositivo.
  3. Defina as seguintes informações com base em cada tipo de EAP:

    • EAP-TTLS: Defina EAPMethod(21) e tipos de autenticação interna suportados ( PAP , CHAP , MS-CHAP ou MS-CHAP-V2 )
    • EAP-TLS: Definir EAPMethod(13)
    • EAP-SIM: Definir EAPMethod(18)
    • EAP-AKA: Definir EAPMethod(23)
    • EAP-AKA': Definir EAPMethod(50)

Correção de dispositivo/AOSP para OEMs

Para implementar uma solução alternativa no lado do dispositivo, os OEMs precisam escolher o patch CL aosp/718508 . Este patch pode ser aplicado sobre as seguintes versões (não se aplica ao Android 10 ou superior):

  • Android 9
  • Android 8.x

Quando o patch é escolhido, os OEMs precisam atualizar os dispositivos em campo.