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 do solicitante. 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 do fornecedor usam HIDL. Os arquivos HIDL estão em hardware/interfaces/supplicant/1.x, e os arquivos AIDL estão em hardware/interfaces/supplicant/aidl. O solicitante oferece suporte ao padrão 802.11u, especificamente recursos de descoberta e seleção de rede, como o serviço de publicidade genérica (GAS, na sigla em inglês) e o protocolo de consulta de acesso à rede (ANQP, na sigla em inglês).

Implementação

Android 11 ou mais recente

Para oferecer suporte ao Passpoint em dispositivos com o Android 11 ou versões mais recentes, os fabricantes precisam oferecer suporte de firmware ao 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 a 802.11u

Para oferecer suporte ao Passpoint, implemente o HAL do Wi-Fi e ative a flag 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 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, execute os seguintes testes de unidade do pacote do Passpoint:

Testes de serviço:

atest com.android.server.wifi.hotspot2

Testes do administrador:

atest android.net.wifi.hotspot2

Provisionamento do 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 inicializa automaticamente um instalador especial para as informações do Wi-Fi e permite que o usuário visualize partes das informações antes de aceitar ou recusar o conteúdo.

As informações do perfil contidas no arquivo são usadas para correspondência com os dados recuperados dos pontos de acesso ativados pelo 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 protegido com TLS (HTTPS), porque pode conter uma senha de texto simples ou dados de chave privada. O conteúdo é composto por texto MIME de várias partes representado em UTF-8 e codificado em 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 de Wi-Fi no dispositivo:

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

O método HTTP usado para recuperar o arquivo precisa ser GET. Sempre que um GET HTTP 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 do Google Chrome. Outros navegadores da Web podem ou não oferecer uma funcionalidade semelhante.

Composição de arquivos

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 (sem aspas)	Obrigatório	Descrição
Perfil	`application/x-passpoint-profile`	Sempre	Payload formatado em SyncML OMA-DM contendo a MO formatada `PerProviderSubscription` do Passpoint R1 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 X.509v3 codificado em base64.
Chave EAP-TLS	`application/x-pkcs12`	Obrigatório para EAP-TLS	Uma estrutura ASN.1 PKCS #12 codificada em base64 que contém uma cadeia de certificados do cliente com pelo menos o certificado do cliente e a chave privada associada. O contêiner PKCS 12, a chave privada e os certificados precisam estar em texto não criptografado 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 aparece 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 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 "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 igualdade total ou de 5 ou 6 dígitos decimais seguidos por um asterisco (*) para relaxar a correspondência de IMSI apenas para MCC/MNC. Por exemplo, a string IMSI 123456* corresponde a qualquer chip com MCC 123 e MNC 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 do Passpoint que exigem um nome de domínio AAA especificado independente do nome de domínio totalmente qualificado (FQDN) anunciado pela rede pelo protocolo de consulta de rede de acesso (ANQP) podem especificar uma lista delimitada por ponto e vírgula de FQDNs em um novo nó no subárvore Extension. Esse é um nó opcional, e os dispositivos com o Android versão 10 ou anterior ignoram esse nó.

Android: subárvore de extensão do Android
- AAAServerTrustedNames: obrigató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 pontos e vírgulas para separar os nomes confiáveis. Por exemplo: example.org;example.com.

ACs raiz particulares autoassinados: Os administradores de rede do Passpoint que gerenciam os certificados internamente podem provisionar perfis com uma AC autoassinada particular para autenticação AAA.
Permitir a instalação de perfis sem um certificado de CA raiz: O certificado de AC raiz anexado ao perfil é usado para autenticação do 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 do Passpoint R2

O Android 10 oferece 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 Passpoint R2, o framework do Android:

Mostra uma lista dos provedores de serviços anunciados pelo AP no seletor de Wi-Fi, além dos SSIDs.
Solicita que o usuário toque em um dos provedores de serviços para configurar um perfil do Passpoint.
Orienta o usuário pelo fluxo de configuração do perfil do Passpoint.
Instala o perfil do Passpoint resultante após a conclusão.
É associado à rede do Passpoint usando o perfil do 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 obedeçam às 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 não seguros, que usam redes abertas, por uma rede Passpoint segura. Uma notificação é exibida ao usuário quando ele precisa aceitar os Termos e Condições.

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

URL das informações do local

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

O URL das informações do local precisa apontar para um site seguro que use HTTPS. Se o URL apontar para um site não seguro, o framework vai ignorá-lo e não vai mostrar 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.

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 inválidas, que vão falhar. Isso evita o uso do tempo de transmissão e economiza bateria e largura de banda de back-end. O framework mostra uma notificação ao usuário quando uma rede que corresponde ao perfil está no intervalo 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, na sigla em inglês) podem provisionar vários perfis do Passpoint com o mesmo FQDN, um para cada ID PLMN, que é automaticamente associado 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, na sigla em inglês) para executar o roteamento explícito usando vários proxies dentro de uma rede AAA. Consulte RFC 7542 (link em inglês). O Android 12 implementa esse recurso de acordo com a especificação da WBA para extensões PPS-MO (link em inglês).
Processamento 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 autenticação na rede por um determinado período (especificado por um atraso de 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, os dispositivos que não têm suporte a esse recurso podem tentar se reconectar repetidamente à rede enquanto o serviço está 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 de uma rede com:

O nome amigável da rede foi definido como Example Network
FQDN definido como hotspot.example.net
OIs do consórcio de roaming (para roaming)
Credencial com 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 de uma rede com:

O nome amigável da rede foi definido como GlobalRoaming
FQDN definido como globalroaming.net
OIs do Consórcio de roaming (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 do chip (EAP-AKA)

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

O nome amigável da rede foi definido como Purple Passpoint
FQDN definido como wlan.mnc888.mcc999.3gppnetwork.org
Credencial do chip com ID PLMN de 999888
O método EAP foi 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 o offload do Wi-Fi.

Segmento	Impacto	Tamanho do impacto
Operadoras e provedores de serviços do Passpoint	Aumento da carga na rede celular.	Qualquer operadora que use o Passpoint R1.
Usuários	Perda da oportunidade de conexão automática com os pontos de acesso (APs) de Wi-Fi da operadora, resultando em custos de dados mais altos.	Qualquer usuário com um dispositivo que seja executado em uma rede de operadora que ofereça suporte ao 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 encontrou correspondências para provedores de serviços que funcionavam anteriormente. Por isso, os dispositivos Passpoint não se conectaram automaticamente.

Alternativas

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

A solução recomendada é que os provedores de serviços de rede implementem uma solução alternativa para a rede para o tempo mais rápido de implantação. Uma solução alternativa no dispositivo depende de OEMs que selecionam uma lista de mudanças (CL) do AOSP e, em seguida, atualizam os dispositivos no campo.

Correção de rede para operadoras e provedores de serviços do 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 NAI, mas a adição dessa propriedade está em conformidade com as especificações do Passpoint. Portanto, as implementações de cliente que obedecem às especificações não devem ser interrompidas.

Adicione o elemento ANQP do domínio NAI.
Defina o subcampo de domínio NAI 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:definir EAPMethod(23)
- EAP-AKA': defina EAPMethod(50).

Correção de dispositivo/AOSP para OEMs

Para implementar uma solução alternativa no dispositivo, os OEMs precisam escolher o patch CL aosp/718508. 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.