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.

Passpoint 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 do dispositivo

Para oferecer suporte ao Passpoint, os fabricantes de dispositivos precisam implementar a interface suplicante. No Android 13 e versões mais recentes, a interface usa a AIDL para a definição da HAL. Para versões anteriores ao Android 13, as interfaces e partições de fornecedor usam o HIDL. Os arquivos HIDL estão em hardware/interfaces/supplicant/1.x, e os arquivos AIDL estão em hardware/interfaces/supplicant/aidl. O suplicante é compatível com o padrão 802.11u, especificamente os recursos de descoberta e seleção de rede, como o Generic Publicidade Service (GAS) e o protocolo de consulta de rede de acesso (ANQP, na sigla em inglês).

Implementação

Android 11 ou versão mais recente

Para oferecer suporte ao Passpoint em dispositivos com o Android 11 ou versões mais recentes, os fabricantes precisam oferecer suporte a firmware para 802.11u. Todos os outros requisitos para oferecer suporte ao Passpoint estão incluídos no AOSP.

Android 10 ou versão anterior

Para dispositivos com o Android 10 ou versões anteriores, os fabricantes precisam oferecer suporte a framework e HAL/firmware:

Framework: ativar o Passpoint (requer uma flag de recurso)
Firmware: suporte para 802.11u

Para oferecer suporte ao Passpoint, implemente a HAL de Wi-Fi e ative a flag de recurso para o Passpoint. No device.mk, localizado em device/<oem>/<device>, modifique a variável de ambiente PRODUCT_COPY_FILES para incluir suporte ao 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 oferecer 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 de integração fornecidos no Android Comms Test Suite (ACTS).

Testes de unidades

Execute os seguintes testes de unidade de pacote do Passpoint.

Testes de serviço:

atest com.android.server.wifi.hotspot2

Testes do gerenciador:

atest android.net.wifi.hotspot2

Testes de integração (ACTS, na sigla em inglês)

O pacote de testes 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 a versão 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 confira partes dessas informações antes de aceitar ou recusar o conteúdo.

As informações de perfil contidas no arquivo são usadas para correspondência com os dados recuperados de pontos de acesso com o Passpoint, e as credenciais são aplicadas automaticamente a qualquer rede correspondente.

A implementação de referência do Android oferece suporte a EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA e EAP-AKA.

Mecanismo de download

O arquivo de configuração do Passpoint precisa ser hospedado em um servidor da Web e ser protegido com TLS (HTTPS) porque pode conter senhas de texto não criptografado ou dados de chave privada. O conteúdo é composto por texto MIME de várias partes encapsulado representado em UTF-8 e codificado em base64, de acordo com a seção 6.8 do RFC-2045.

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

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

O método HTTP usado para recuperar o arquivo precisa ser GET. Sempre que um HTTP GET do navegador receber uma resposta com esses cabeçalhos MIME, o app de instalação será iniciado. O download precisa ser acionado ao tocar em um elemento HTML, como um botão. Não é possível usar redirecionamentos automáticos para um URL de download. Esse comportamento é específico para o Google Chrome. Outros navegadores da Web podem ou não oferecer funcionalidades semelhantes.

Composição do arquivo

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

Parte	Content-Type (menos aspas)	Obrigatório	Descrição
Perfil	`application/x-passpoint-profile`	Sempre	Payload formatado do OMA-DM SyncML contendo o MO do Passpoint R1 `PerProviderSubscription` formatado para `HomeSP` e `Credential`.
Certificado de confiança	`application/x-x509-ca-cert`	Obrigatório para EAP-TLS e EAP-TTLS	Um único payload 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 do cliente com pelo menos o certificado do cliente e a chave privada associada. O contêiner PKCS 12, bem como a chave privada e os certificados, precisam estar em texto não criptografado e sem senha.

A seção "Perfil" precisa 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 do Passpoint R2 versão 1.0.0, seção 9.1.

O nó de nível superior precisa ser MgmtTree, e o subnó imediato precisa ser PerProviderSubscription. Um exemplo de arquivo XML é mostrado em Exemplo de perfil OMA-DM XML.

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

FriendlyName: precisa ser definido e usado como texto de exibição.
FQDN: obrigatório
RoamingConsortiumOI

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

Realm: precisa ser uma string que não esteja 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 "password", no exemplo abaixo)
- EAPMethod/EAPType: precisa ser definido como 21.
- EAPMethod/InnerMethod: precisa ser definido como PAP, CHAP, MS-CHAP ou MS-CHAP-V2.
DigitalCertificate: obrigatório para EAP-TLS. Os seguintes nós precisam ser definidos:
- CertificateType definida para x509v3
- CertSHA256Fingerprint definido como o resumo SHA-256 correto do certificado do cliente na seção MIME da chave EAP-TLS.
SIM: obrigatório para EAP-SIM, EAP-AKA e EAP-AKA'. O campo EAPType precisa ser definido como o tipo de EAP apropriado e IMSI precisa corresponder a um IMSI de um dos chips 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 cinco ou seis dígitos decimais seguidos por um asterisco (*) para transformar o IMSI correspondente somente à MCC/MNC. Por exemplo, a string IMSI 123456* corresponde a qualquer chip com MCC como 123 e MNC como 456.

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

Nome de domínio separado para autenticação, autorização e contabilidade (AAA): Os administradores de rede de Passpoint que exigem um nome de domínio AAA especificado independentemente do nome de domínio totalmente qualificado (FQDN, na sigla em inglês) divulgado pela rede pelo 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 com o Android 10 ou versões anteriores ignoram esse nó.

Android: subárvore de extensões do Android
- AAAServerTrustedNames: obrigatório para nomes confiáveis de servidores 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 particulares autoassinados: Os administradores de rede de Passpoint que gerenciam os certificados internamente podem provisionar perfis com uma AC autoassinado particular para a 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 do Passpoint que querem contar com ACs raiz públicas confiáveis para a autenticação do servidor AAA podem provisionar perfis sem um certificado de CA raiz. Nesse caso, o sistema compara os certificados do servidor AAA com os certificados de CA raiz públicos instalados no repositório de confiança.

Provisionamento de Passpoint R2

O Android 10 introduziu suporte aos recursos do Passpoint R2. O Passpoint R2 implementa a inscrição on-line (OSU, na sigla em inglês), um método padrão para provisionar novos perfis do Passpoint. O Android 10 e versões mais recentes oferecem suporte ao provisionamento de perfis EAP-TTLS usando o protocolo SOAP-XML em OSU ESS aberto.

Os recursos compatíveis do Passpoint R2 exigem apenas o código de referência do AOSP (nenhum suporte extra de driver ou firmware é necessário). O código de referência do AOSP também inclui uma implementação padrão da interface do Passpoint R2 no app Configurações.

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

Exibe uma lista dos provedores de serviços divulgados pelo AP no seletor de Wi-Fi, além de mostrar os SSIDs.
Solicita que o usuário toque em um dos provedores de serviços para configurar um perfil do Passpoint.
Orienta o usuário no fluxo de configuração do perfil do Passpoint.
Instala o perfil do Passpoint resultante após a conclusão.
Associa-se à rede do Passpoint usando o perfil do Passpoint recém-provisionado.

Recursos do Passpoint R3

O Android 12 apresenta os recursos do Passpoint R3 abaixo, que melhoram a experiência do usuário e permitem que as redes obedeçam às leis locais:

Termos e Condições

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

O URL dos Termos e Condições precisa direcionar para um site seguro que usa HTTPS. Se o URL apontar para um site não seguro, o framework vai desconectar e bloquear a rede imediatamente.

URL de informações do local

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

O URL de informações do local precisa direcionar para um site seguro usando HTTPS. Se o URL apontar para um site não seguro, o framework vai ignorar o URL e não exibirá uma notificação.

Outros recursos do Passpoint

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

Notificação e aplicação da data de validade: A aplicação de datas de validade em perfis permite que o framework evite a conexão automática com pontos de acesso com credenciais expiradas, que provavelmente falham. Isso evita o uso do tempo de transmissão e economiza bateria e largura de banda do back-end. O framework exibe uma notificação para o usuário quando uma rede correspondente ao perfil dele está dentro do intervalo e o perfil expirou.
Vários perfis com FQDN idêntico: As operadoras que implantam redes do Passpoint e usam vários IDs públicos de redes móveis terrestres (PLMN, na sigla em inglês) podem provisionar vários perfis do Passpoint com o mesmo FQDN, um para cada ID de PLMN, que é automaticamente combinado com o chip instalado e usado para conectar a rede.

O Android 12 introduz os recursos do Passpoint abaixo que melhoram a experiência do usuário, o uso avançado e a flexibilidade de implantação:

Prefixo de identidade decorado: Ao autenticar em redes com decoração de prefixo, o prefixo de identidade decorado permite que os operadores de rede atualizem o identificador de acesso à rede (NAI, na sigla em inglês) para executar roteamento explícito por vários proxies dentro de uma rede AAA (consulte RFC 7542). O Android 12 implementa esse recurso de acordo com a especificação da WBA para extensões PPS-MO.
Processamento iminente de desautenticação: Permite que os operadores de rede sinalizem para um dispositivo que o serviço não está disponível para a credencial usada para autenticação na rede por um determinado período (especificado por um tempo limite). Depois de receber esse sinal, os dispositivos não vão tentar se reconectar à rede com a mesma credencial até que o tempo limite expire. Por outro lado, dispositivos que não oferecem suporte a esse recurso podem tentar se reconectar repetidamente à rede enquanto o serviço estiver indisponí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 adequado para a rede definido como Example Network
FQDN definido como hotspot.example.net
OIs de consórcio de roaming (para roaming)
Credencial com o nome de usuário 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 adequado para a rede definido como GlobalRoaming
FQDN definido como globalroaming.net
OIs do Roaming Consortium (para roaming)
Realm 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 de chip (EAP-AKA)

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

Nome adequado para a rede definido como Purple Passpoint
FQDN definido como wlan.mnc888.mcc999.3gppnetwork.org
Credencial do chip com o ID de 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 com o Android 8.x ou o Android 9 com um perfil Passpoint R1 EAP-SIM, EAP-AKA ou EAP-AKA não se conectarão automaticamente à rede do Passpoint. Esse problema afeta usuários, operadoras e serviços, reduzindo a descarga de Wi-Fi.

Segmento	Impacto	Tamanho do impacto
Operadoras e provedores de serviços de Passpoint	Aumento da carga na rede celular.	Qualquer operadora que use o Passpoint R1.
Usuários	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 compatível com o Passpoint R1.

Causa da falha

O Passpoint especifica um mecanismo para corresponder um provedor de serviços divulgado (ANQP, na sigla em inglês) 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 de 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 correspondências para provedores de serviços que já funcionavam. Por isso, os dispositivos do Passpoint não foram conectados automaticamente.

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, na sigla em inglês) às informações publicadas pelo AP de Passpoint.

A solução recomendada é que os provedores de serviços de rede implementem uma solução alternativa do lado da rede para agilizar a implantação. Uma solução alternativa do lado do dispositivo depende de os OEMs selecionarem uma lista de mudanças (CL, na sigla em inglês) do AOSP e atualizarem os dispositivos em 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 realm NAI, conforme especificado abaixo. As especificações do Passpoint não exigem o elemento ANQP do domínio da 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 podem ser interrompidas.

Adicione o elemento ANQP do realm NAI.
Defina o subcampo NAI realm para corresponder ao Realm do perfil instalado no dispositivo.
Defina as seguintes informações com base em cada tipo de EAP:
- EAP-TTLS:define EAPMethod(21) e tipos de autenticação interna compatíveis (PAP, CHAP, MS-CHAP ou MS-CHAP-V2).
- EAP-TLS:defina EAPMethod(13).
- EAP-SIM:defina EAPMethod(18)
- EAP-AKA:defina EAPMethod(23).
- EAP-AKA': defina EAPMethod(50)

Correção de dispositivo/AOSP para OEMs

Para implementar uma solução alternativa no lado do dispositivo, os OEMs precisam escolher o CL de patch aosp/718508 (link em inglês). Esse patch pode ser aplicado sobre as seguintes versões (não se aplica ao Android 10 ou versões mais recentes):

Android 9
Android 8.x

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