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 Wi-Fi Alliance (WFA) protocolo que permite aos dispositivos móveis descobrir e autenticar no Wi-Fi pontos de acesso que fornecem acesso à Internet.

Suporte do dispositivo

Para oferecer suporte ao Passpoint, os fabricantes de dispositivos precisam implementar a interface Suplicant. 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, e partições de fornecedores 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 oferece suporte padrão 802.11u, especificamente recursos de seleção e descoberta de rede, como o Generic acima Service, (GAS) e o Access Network Query Protocol (ANQP).

Implementação

Android 11 ou versão mais recente

Para oferecer suporte ao Passpoint em dispositivos com o Android 11 ou mais recente, faça o seguinte: os fabricantes de dispositivos precisam fornecer suporte de 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 fornecer 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 sinalização de recurso para Passpoint. No device.mk localizado em device/<oem>/<device>, modifique o PRODUCT_COPY_FILES para incluir suporte ao Recurso do 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 o seguinte Testes de unidade do pacote Passpoint:

Testes de serviço:

atest com.android.server.wifi.hotspot2

Testes do gerenciador:

atest android.net.wifi.hotspot2

Provisionamento de Passpoint R1

O Android oferece suporte ao Passpoint R1 desde a versão 6.0, permitindo o provisionamento das 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 veja partes das informações antes de aceitar ou recusar 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 estar hospedado em um servidor da Web e ser protegido com TLS (HTTPS) porque pode conter uma senha de texto não criptografado ou dados de chave privada. O conteúdo é composto por texto MIME de várias partes unido. representado em UTF-8 e codificado em base64, conforme a seção 6.8 do RFC-2045.

Os campos de cabeçalho HTTP a seguir 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 de o navegador receber uma resposta com esses cabeçalhos MIME, o aplicativo de instalação será começar. O download deve ser acionado tocando em um elemento HTML, como um (redirecionamentos automáticos para um URL de download não são suportados). Esse comportamento é específico para o Google Chrome. outros navegadores podem ou não oferecer recursos funcionalidade de armazenamento.

Composição do arquivo

O conteúdo codificado em Base64 precisa consistir em conteúdo MIME multipartes com um Content-Type de multipart/mixed. As partes a seguir compõem o partes 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 Passpoint R1 Objetivo de marketing formatado para `PerProviderSubscription` 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 ASN.1 PKCS #12 codificada em base64 contendo um certificado 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, devem estejam em texto não criptografado e sem senha.

A seção Perfil deve ser transferida como XML codificado em base64 e UTF-8 texto 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 Exemplo de perfil OMA-DM XML.

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

FriendlyName: precisa 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: 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=, o 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 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 cliente certificado 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 com o tipo de EAP apropriado e IMSI deve corresponder a um IMSI de os chips instalados no dispositivo no momento do provisionamento. O IMSI string 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 flexibilizar a correspondência IMSI somente para MCC/MNC. Por exemplo, a sequência IMSI 123456* corresponde a qualquer chip com MCC como 123 e MNC como 456.

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

Nome de domínio separado para autenticação, autorização e contabilidade (AAA): 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) anunciado pelo de rede pelo Access Network Query Protocol (ANQP) pode especificar lista delimitada por ponto e vírgula de FQDNs em um novo nó em na subárvore Extension. Este é um nó opcional e dispositivos que executam Android a versão 10 ou anterior ignora 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. Usar ponto e vírgula para separar os nomes confiáveis. Por exemplo: example.org;example.com.

CAs raiz particulares autoassinados: Administradores de rede de Passpoint que gerenciam os certificados internamente podem provisionar perfis com uma CA particular autoassinado 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 AAA do servidor de anúncios. Administradores de rede do Passpoint que querem contar com CAs raiz públicas confiáveis para a autenticação do servidor AAA podem provisionar sem um certificado de CA raiz. Nesse caso, o sistema verifica certificados de servidor AAA com relação aos certificados de CA raiz públicos instalados no repositório de confiança.

Provisionamento de Passpoint R2

O Android 10 introduz o suporte ao Passpoint R2 atributos de machine learning. O Passpoint R2 implementa a inscrição on-line (OSU), um método padrão para provisionar novos perfis do Passpoint. Android 10 e versões mais recentes oferece suporte ao provisionamento de perfis EAP-TTLS usando o protocolo SOAP-XML por abra o OSU ESS.

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

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 Wi-Fi selecionado (além de exibir os SSIDs).
Solicita que o usuário toque em um dos provedores de serviços para configurar um Passpoint perfil.
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 Passpoint recém-provisionado perfil.

Recursos do Passpoint R3

O Android 12 introduz o Passpoint R3 abaixo recursos que melhoram a experiência do usuário e permitem que as redes estejam em conformidade com leis locais:

Termos e Condições

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

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, a estrutura imediatamente desconecta e bloqueia a rede.

URL de informações do local

Permite que as operadoras de redes e locais forneçam informações adicionais para o usuário, como mapas do local, diretórios, promoções e cupons. Uma notificação é exibida ao usuário quando 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, a estrutura ignorará o URL e não exibe uma notificação.

Outros recursos do Passpoint

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

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

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

Prefixo de identidade decorado: Ao autenticar em redes com decoração de prefixo, o elemento de identidade do usuário permite que os operadores de rede atualizem as configurações identificador (NAI) para realizar roteamento explícito por meio de várias proxies dentro de uma rede AAA (consulte RFC 7542). O Android 12 implementa esse recurso de acordo com 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 (especificada por meio de 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, os dispositivos Este recurso pode tentar se reconectar à rede repetidamente 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 o 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 Passpoint R1 EAP-SIM, EAP-AKA ou EAP-AKA". não vai se conectar automaticamente à rede do Passpoint. Isso afeta os usuários, as operadoras e os 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 Wi-Fi da operadora (APs), o que resulta em custos de dados mais altos.	Qualquer usuário com um dispositivo executado em uma rede de operadora compatível O Passpoint R1

Causa da falha

O Passpoint especifica um mecanismo para corresponder a um provedor de serviços anunciado (ANQP, na sigla em inglês) em 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 que focam EAP-SIM/AKA/AKA falhas:

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ência para as provedores de serviços ativos. Por isso, os dispositivos 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) ao as 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 agilizar a implantação. Do lado do dispositivo uma alternativa depende de os OEMs selecionarem uma lista de mudanças (CL, na sigla em inglês) no AOSP e depois e atualizar dispositivos em campo.

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

A solução alternativa do lado da rede exige a reconfiguração da rede para adicionar a NAI elemento ANQP do domínio, 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á de acordo com as especificações do Passpoint, as implementações não devem falhar.

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 patch CL aosp/718508 (link em inglês). Esse patch pode ser aplicado às seguintes versões (não se aplica a Android 10 ou mais recente):

Android 9
Android 8.x

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