O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Passpoint (Hotspot 2.0)

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

Suporte de dispositivo

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 HAL Wi-Fi (HIDL) fornecida no Android Open Source Project (AOSP) define uma HAL para o suplicante. O suplicante fornece suporte para o padrão 802.11u, especificamente recursos de detecção 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 suportar o 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 de estrutura e HAL / firmware:

  • Estrutura: Habilitar Passpoint (requer um sinalizador de recurso)
  • Firmware: suporte para 802.11u

Para oferecer suporte ao Passpoint, implemente o HAL Wi-Fi e habilite o sinalizador de recurso para 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 suportar o 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 de gerente:

atest android.net.wifi.hotspot2

Testes de integração (ACTS)

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

Provisionamento 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 credencial. 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 compatível.

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 não criptografado ou dados de chave privada. O conteúdo é composto de texto MIME multiparte embalado representado em UTF-8 e codificado em codificação base64 de acordo com a seção 6.8 da RFC-2045.

Os seguintes campos de cabeçalho HTTP são usados ​​pelo cliente para iniciar automaticamente um instalador 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 (redirecionamentos automáticos para um URL de download não são suportados). Este comportamento é específico do Google Chrome; outros navegadores da web podem ou não fornecer funcionalidade semelhante.

Composição de arquivo

O conteúdo codificado em Base64 deve consistir em conteúdo MIME multiparte com um Content-Type de multipart/mixed . As seguintes partes constituem as partes individuais do conteúdo multipartes.

Papel Tipo de conteúdo (menos citações) Requerido Descrição
Perfil application/x-passpoint-profile Sempre PerProviderSubscription útil formatada OMA-DM SyncML contendo o MO formatado Passpoint R1 PerProviderSubscription para HomeSP e Credential .
Certificado de confiança application/x-x509-ca-cert Obrigatório para EAP-TLS e EAP-TTLS Uma única carga útil de certificado codificado em base64 X.509v3.
Chave EAP-TLS application/x-pkcs12 Requerido 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 UTF-8 que especifica partes das subárvores HomeSP e Credential na Especificação Técnica 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 exemplo de arquivo XML aparece em Exemplo de perfil 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 : Obrigatório para EAP-TTLS com os seguintes nós definidos:

    • 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 um de PAP , CHAP , MS-CHAP ou MS-CHAP-V2
  • DigitalCertificate : Requerido 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 EAP apropriado e o IMSI deve corresponder a um IMSI de um dos cartões SIM instalados no dispositivo no momento do provisionamento. A sequência IMSI pode consistir inteiramente em dígitos decimais para forçar a correspondência de igualdade total ou em zero ou mais dígitos decimais seguidos por um asterisco (*) para relaxar a correspondência IMSI apenas com o prefixo. Por exemplo, a sequência 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.

Autenticação separada, autorização e nome de domínio de contabilidade (AAA)

Os administradores de rede de pontos 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 protocolo de consulta de rede de acesso (ANQP) podem especificar uma lista delimitada por ponto e vírgula de FQDNs em um novo nó na subárvore de 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 Android

    • AAAServerTrustedNames : Obrigatório para nomes confiáveis ​​de servidor AAA com o seguinte conjunto de nós:

      • 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 privados autoassinados
Os administradores de rede 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 Passpoint que desejam confiar em CAs de raiz pública confiáveis ​​para 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 CA raiz públicos instalados no armazenamento confiável.

Provisionamento Passpoint R2

O Android 10 introduziu suporte para recursos do Passpoint R2. Passpoint R2 implementa inscrição online (OSU), um método padrão para provisionar novos perfis 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 do Passpoint R2 com suporte 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 IU 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ço 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ço para configurar um perfil 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.

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
Aplicar datas de expiração em perfis permite que a estrutura evite a autoconexão com pontos de acesso com credenciais expiradas, que estão fadadas a falhar. Isso evita o uso de tempo de antena e economiza bateria e largura de banda de back-end. A estrutura exibe uma notificação para o usuário quando uma rede correspondente ao seu perfil está dentro do alcance e o perfil expirou.
Vários perfis com FQDN idêntico
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 combinado com o cartão SIM instalado e usado para conectar a rede.

Exemplos de perfis OMA-DM PerProviderSubscription-MO XML

Perfil com 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 usuário user , senha password codificada com Base64, e conjunto reino para 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 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 do consórcio de roaming (para roaming)
  • Reino definido como users.globalroaming.net
  • Credencial com um certificado digital que contém 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 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 executando o Android 8.x ou Android 9 com um perfil Passpoint R1 EAP-SIM, EAP-AKA ou EAP-AKA 'não se conectam automaticamente à rede Passpoint. Esse problema afeta usuários, operadoras e serviços, reduzindo o descarregamento de Wi-Fi.

Segmento Impacto Tamanho do impacto
Operadoras e provedores de serviço 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 que funciona em uma rede de operadora com suporte para Passpoint R1.

Causa da falha

Passpoint especifica um mecanismo para combinar 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 esta modificação, o sistema não encontrou nenhuma correspondência para os provedores de serviço que funcionavam anteriormente, então os dispositivos Passpoint não se conectaram automaticamente.

Soluções Alternativas

Para contornar o problema dos critérios de correspondência modificados, as operadoras e provedores de serviço 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ço de rede implementem uma solução alternativa do lado da rede para obter o tempo de implantação mais rápido. Uma solução alternativa do lado do dispositivo depende dos OEMs pegarem uma changelist (CL) do AOSP e, em seguida, atualizarem os dispositivos em campo.

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

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

  1. Inclua o elemento ANQP do domínio NAI.
  2. Defina o reino subcampo NAI para coincidir com o Realm do perfil instalado no dispositivo.
  3. Defina as seguintes informações com base em cada tipo de EAP:

    • EAP-TTLS: defina o EAPMethod(21) e os tipos de autenticação interna compatíveis ( 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)

Dispositivo / correção AOSP para OEMs

Para implementar uma solução alternativa do 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.