Como configurar o WiFi Enterprise em dispositivos Android com o EAP-TLS

O Android se conecta a WiFi corporativo com EAP-TLS quando três requisitos são atendidos. O dispositivo possui seu próprio certificado de cliente. Ele confia na AC raiz que assinou o seu certificado de servidor RADIUS. Seu perfil de WPA2 ou WPA3-Enterprise usa o método EAP TLS, com um Domínio correspondente a esse certificado de servidor. Distribua os três requisitos a partir do seu MDM para configurar frotas inteiras sem precisar tocar em um dispositivo.

O que o EAP-TLS realmente faz em um dispositivo Android?

O IEEE 802.1X é o padrão para controle de acesso à rede baseado em porta. No WiFi, o ponto de acesso não trafega nenhum dado de um dispositivo até que um servidor de autenticação o aprove. Esse servidor é um servidor RADIUS, o serviço que aceita ou rejeita cada solicitação de conexão. O dispositivo Android é o suplicante, o ponto de acesso é o autenticador e o RADIUS é o servidor de autenticação.

O EAP-TLS (Extensible Authentication Protocol with Transport Layer Security, definido no RFC 5216) é como ambos os lados provam quem são. Ele usa certificados X.509, não senhas. A verificação ocorre em ambas as direções:

1. O servidor RADIUS apresenta seu certificado. O Android verifica se ele se encadeia a uma autoridade certificadora (AC) raiz confiável. Ele também verifica se o nome do certificado corresponde ao Domínio no perfil de WiFi.
2. O dispositivo Android apresenta seu próprio certificado de cliente. O RADIUS verifica se a sua AC o emitiu, se está dentro do prazo de validade e se não foi revogado.

Como não existe senha, não há nada para ser alvo de phishing, reutilizado ou redefinido. O PEAP (Protected EAP) com MSCHAPv2 funciona de forma diferente: ele envia um nome de usuário e uma senha dentro de um túnel TLS. Uma senha PEAP roubada funciona em qualquer dispositivo. A chave privada de um certificado de cliente permanece no dispositivo para o qual foi emitida.

Comportamentos do Android que pegam as equipes de surpresa

Quatro comportamentos do Android moldam cada implantação:

• A validação de servidor é obrigatória. A partir do Android 11, o Google removeu a opção de ignorar a validação do certificado de servidor em redes corporativas. Todo perfil precisa de um certificado de AC e de um Domínio, caso contrário o dispositivo não se conectará.
• ** O uso estendido de chave (EKU) importa.** O certificado do servidor RADIUS precisa do uso estendido de chave de Autenticação do Servidor (EKU), OID 1.3.6.1.5.5.7.3.1. Emita certificados de cliente com Autenticação de Cliente, OID 1.3.6.1.5.5.7.3.2.
• Instalações manuais precisam de PKCS#12. O Android espera que o certificado do cliente e a chave privada estejam agrupados em um único arquivo .p12 ou .pfx.
• Os endereços MAC são aleatórios. Desde o Android 10, os dispositivos usam um endereço MAC aleatório por rede por padrão. Nunca baseie a identidade ou a política de acesso em endereços MAC.

Como o EAP-TLS se compara com as alternativas

O que você precisa antes de configurar o Android para EAP-TLS?

Coloque estes seis itens em prática antes de mexer em um dispositivo. A maioria das implementações malsucedidas se deve a um deles.

• Uma infraestrutura de chaves públicas (PKI). Você precisa de uma CA para emitir certificados de cliente. Se você já opera uma CA interna, como o Microsoft Active Directory Certificate Services, ela pode emitir certificados de servidor e de cliente.
• Um certificado de servidor RADIUS criado para Android. Ele precisa de um Subject Alternative Name (SAN) contendo um nome DNS. Ele também precisa do EKU de Autenticação de Servidor e de uma cadeia de volta até a raiz que você distribuirá. Configure o RADIUS para enviar a cadeia completa, incluindo os intermediários.
• RADIUS configurado para EAP-TLS. Ele deve confiar na CA que emite os certificados de cliente. Também deve verificar a revogação por meio de uma lista de revogação de certificados (CRL) ou OCSP (Online Certificate Status Protocol).
• Um SSID Enterprise nos seus pontos de acesso. Defina WPA2-Enterprise ou WPA3-Enterprise e aponte-o para o RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet oferecem suporte a 802.1X.
• Um MDM registrado via Android Enterprise. O gerenciamento de dispositivos móveis (MDM) é a única maneira prática de emitir e renovar certificados além de um projeto piloto. Conecte-o à sua CA com o SCEP, o protocolo de solicitação de certificado definido na RFC 8894.
• Um plano de nomenclatura e VLAN. Decida qual identidade vai em cada certificado de cliente, como o ID do dispositivo ou o nome de login do funcionário. Em seguida, decida a qual VLAN (virtual LAN, um segmento de rede logicamente separado) cada grupo de dispositivos pertence.

Como configurar o EAP-TLS no Android?

Você tem dois caminhos. A configuração manual valida seu projeto em alguns dispositivos. Os perfis implantados via MDM o levam para toda a infraestrutura.

Opção 1: configuração manual para pilotos e pequenos grupos

Os caminhos do menu diferem entre as versões do Android e os fabricantes, portanto, siga os rótulos dos campos em vez de um caminho fixo.

1. Entregue os arquivos com segurança. O dispositivo precisa do certificado da CA raiz e de um arquivo .p12 contendo seu certificado de cliente e a chave privada. Envie a senha do .p12 por um canal separado.
2. Instale os certificados. Abra o instalador de certificados nas configurações de segurança do dispositivo. Instale a CA raiz como um certificado WiFi, em seguida, instale o arquivo .p12 e insira sua senha.
3. Adicione a rede. Nas configurações de WiFi, adicione uma rede manualmente e insira o SSID exatamente como ele é.
4. Escolha a segurança Enterprise. Selecione a opção WPA2-Enterprise ou WPA3-Enterprise. Os rótulos variam de acordo com a versão.
5. Defina o método EAP para TLS.
6. Defina o certificado CA. Selecione a raiz que você instalou. Se uma CA pública emitiu seu certificado RADIUS, escolha a opção de certificados do sistema.
7. Defina o status do certificado online. "Solicitar status do certificado" pede ao RADIUS o status OCSP de seu próprio certificado.
8. Defina o Domínio. Insira o nome DNS contido na SAN do certificado RADIUS. Este é o campo que a maioria das equipes erra.
9. Selecione o certificado do cliente. Escolha aquele instalado a partir do arquivo .p12.
10. Defina a Identidade. Use o nome no certificado do cliente, como o ID do dispositivo, nunca um endereço MAC.

A configuração manual tem um custo oculto. Todo certificado expira e cada dispositivo precisa passar pelo mesmo trabalho manual novamente.

Opção 2: Perfis enviados por MDM via Android Enterprise

O Android Enterprise é o framework do Google para gerenciar dispositivos Android. Três de seus modos são relevantes aqui:

• Totalmente gerenciado é adequado para telefones e tablets da empresa.
• Perfil de trabalho isola aplicativos e certificados corporativos em dispositivos pessoais.
• Dedicado é adequado para portáteis de uso único, quiosques e terminais POS.

A ordem de criação é a mesma no Microsoft Intune, Workspace ONE e na maioria das outras plataformas MDM:

1. Conecte o MDM à sua CA. Instale o conector SCEP para que o MDM possa intermediar as solicitações de certificado.
2. Envie um perfil de certificado confiável. Ele entrega sua CA raiz, e quaisquer intermediárias, a cada dispositivo.
3. Envie um perfil de certificado SCEP. O dispositivo gera sua própria chave privada e solicita um certificado de cliente. Defina o assunto ou SAN a partir de uma variável do dispositivo. Defina também o EKU de Autenticação do Cliente, o período de validade e o limite de renovação.
4. Envie o perfil de WiFi. Defina o SSID, a segurança Enterprise e o tipo EAP TLS. Selecione o perfil SCEP como o certificado do cliente. Para confiança no servidor, selecione o perfil da CA raiz e insira o nome do servidor RADIUS a partir de sua SAN.
5. Atribua a um grupo piloto primeiro. Leia os logs do RADIUS por vários dias antes de expandir a atribuição.

Com o SCEP, a chave privada nunca sai do dispositivo. O MDM renova os certificados antes que eles expirem, garantindo que os dispositivos permaneçam conectados sem a necessidade de chamados. Para etapas detalhadas tela a tela, siga a documentação do seu fornecedor de MDM.

Qual método se adapta ao seu ambiente?

Como é uma implementação de EAP-TLS no Android na prática?

Cenário prático: um hotel de 200 quartos substituindo uma senha de equipe compartilhada

Situação. As equipes de governança, manutenção e recepção compartilhavam 60 dispositivos Android. Todos se conectavam a uma única rede WPA2-Personal cuja senha não era alterada desde a inauguração. Ex-funcionários ainda a conheciam. Alterá-la significava reconfigurar 60 dispositivos manualmente.

O que foi feito. O TI registrou os dispositivos como dispositivos Android Enterprise totalmente gerenciados. O MDM enviou a CA raiz, um certificado de cliente SCEP válido por 12 meses e um perfil WiFi EAP-TLS. O RADIUS colocou todos os dispositivos aceitos na VLAN de operações. Os hóspedes permaneceram em uma rede de Guest WiFi separada com seu próprio Captive Portal, a página de login exibida antes do acesso à internet.

Resultado. A senha compartilhada foi descontinuada em todos os 60 dispositivos. A perda de um dispositivo agora custa apenas uma revogação de certificado; os outros 59 dispositivos permanecem intactos. A equipe não tem senha de WiFi para esquecer, portanto, as redefinições de senha de WiFi param completamente. Mais sobre o setor em Hotéis.

Cenário prático: uma rede de varejo de 150 lojas no escopo do PCI DSS

Situação. Cada loja operava quatro coletores de estoque e dois tablets de POS em Android: 900 dispositivos no total. O WiFi da loja trafegava dados de pagamento, colocando-o no escopo do PCI DSS. O Requisito 4.2.1.2 do PCI DSS v4.0 exige criptografia forte para autenticação e transmissão sem fio. Uma chave compartilhada alternada loja por loja era difícil de comprovar.

O que foi feito. O TI registrou cada dispositivo como um dispositivo Android Enterprise dedicado. O perfil SCEP gravou a função de cada dispositivo em seu certificado. O RADIUS associou esse campo e retornou uma VLAN usando os atributos de túnel do RFC 3580. Os tablets de POS ingressaram na VLAN de pagamento; os coletores ingressaram na VLAN de estoque. Os clientes usavam um SSID de Guest WiFi separado, com o WiFi Analytics gerando relatórios apenas sobre essa rede.

Resultado. Todos os 900 dispositivos foram registrados sem que nenhum funcionário da loja digitasse uma credencial. A rotação de chaves em 150 lojas foi encerrada. Cada conexão agora aparece nos logs do RADIUS vinculada ao certificado de um dispositivo identificado, fornecendo ao auditor evidências individuais por dispositivo. Mais sobre o setor em Varejo.

Como verificar se o Android está se autenticando com EAP-TLS?

Um ícone de conectado apenas prova que o dispositivo se associou a algo. Verifique três camadas e, em seguida, comprove que os controles falham em modo seguro (fail closed).

• No dispositivo. Os detalhes da rede mostram o SSID conectado e um endereço IP da VLAN esperada.
• No servidor RADIUS. O log mostra um Access-Accept, o tipo EAP TLS e o assunto do certificado do cliente apresentado.
• No controlador WiFi ou painel. O registro do cliente mostra 802.1X com WPA2 ou WPA3-Enterprise, além da VLAN atribuída pelo RADIUS.

Em seguida, execute quatro testes negativos em um dispositivo piloto:

1. Revogue seu certificado, publique a CRL e reconecte. Espere um Access-Reject.
2. Altere o domínio do perfil para um nome incorreto. O Android deve recusar o servidor.
3. Instale um certificado de cliente de uma CA diferente. Espere um Access-Reject.
4. Emita um certificado de curta duração. Confirme se o MDM o renova sem que o dispositivo desconecte.

Se todos os quatro se comportarem como o esperado, seu projeto é sólido.

O que dá errado com o EAP-TLS no Android e como você corrige?

A maioria das falhas está na cadeia de certificados ou no perfil, não no rádio.

Onde a Purple se encaixa ao lado do EAP-TLS?

O EAP-TLS é o controle correto para dispositivos que você possui e gerencia. O seu local também recebe pessoas cujos dispositivos você nunca gerenciará.

• Guest WiFi em seu próprio SSID. O Guest WiFi oferece a visitantes, clientes e passageiros um Captive Portal personalizado com opt-ins de escolha consciente. Isso gera dados primários em conformidade com o GDPR. O WiFi Analytics gera relatórios sobre essa rede, mantidos separados do tráfego EAP-TLS.
• WiFi de funcionários para dispositivos sem MDM. As Redes Baseadas em Identidade da Purple, incluindo SecurePass e iPSK, dão a cada pessoa sua própria credencial. O acesso se conecta ao Microsoft Entra ID, Okta ou Google Workspace, para que novas contratações, mudanças e desligamentos sejam gerenciados a partir do seu diretório.
• O hardware que você já possui. A Purple é uma sobreposição em nuvem agnóstica de hardware para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Nenhuma substituição total de infraestrutura é necessária.

A divisão funciona em todos os setores. Na Saúde, dispositivos Android clínicos usam EAP-TLS enquanto pacientes e visitantes usam Guest WiFi. Em Trens, os tablets da tripulação usam EAP-TLS e os passageiros usam Guest WiFi. A Purple opera em mais de 80.000 locais ativos em mais de 90 países (dados da Purple) e possui certificação ISO 27001 e Cyber Essentials.

Quanto custa o EAP-TLS no Android e qual é o retorno?

Pelo que você paga

• PKI. Uma AC interna existente adiciona pouco custo. Sem ela, você precisa construir uma AC ou assinar uma PKI na nuvem.
• Licenças de MDM. Se a sua frota do Android já estiver inscrita, esse custo já foi pago.
• RADIUS. Você precisa de suporte a EAP-TLS, verificação de revogação e um certificado de servidor compilado corretamente.
• Tempo de engenharia. Reserve orçamento para o piloto, a criação do perfil e uma implantação em etapas.

O que você recebe em troca

• Uma revogação em vez de uma rotação em toda a frota. No cenário do hotel, um aparelho perdido afeta um dispositivo, não 60.
• Sem redefinições de senha de WiFi. Os certificados substituem as senhas, portanto essa categoria de chamado desaparece.
• Resistência à coleta de credenciais. Um ponto de acesso falso não obtém nada. O Android rejeita seu certificado e não há senha para capturar.
• Comprovação de conformidade. Os logs de RADIUS por dispositivo dão suporte ao requisito 4.2.1.2 do PCI DSS, ao Artigo 32 do GDPR e ao controle de acesso do ISO 27001.
• Um caminho para o WPA3. O modo de 192 bits do WPA3-Enterprise, suportado a partir do Android 10, é construído em torno do EAP-TLS. O seu trabalho com certificados é reaproveitado.

A regra de decisão é curta. Se você gerencia mais do que um punhado de dispositivos Android por meio de um MDM, torne o EAP-TLS o seu padrão. Coloque os dispositivos de colaboradores não gerenciados em Redes Baseadas em Identidade e os visitantes no WiFi para Visitantes.

Perguntas frequentes

O EAP-TLS funciona em todos os dispositivos Android que provavelmente possuímos?

Sim. Qualquer dispositivo Android que você provavelmente gerencie hoje suporta EAP-TLS no WPA2-Enterprise, e o Android 10 e posteriores adicionam o WPA3-Enterprise. O que mudou foi a validação do servidor. A partir do Android 11, cada perfil corporativo precisa de um certificado de AC e um Domínio, portanto guias mais antigos que ignoram a validação não funcionam mais. Rótulos e caminhos de menu também diferem entre fabricantes, o que é mais um motivo para enviar perfis a partir de um MDM.

Precisamos de um MDM para implantar o EAP-TLS no Android?

Não, mas você precisará de um além da fase piloto. A configuração manual funciona para um punhado de dispositivos. Cada dispositivo, no entanto, precisa de 10 etapas de configuração, uma chave privada copiada e renovação presencial a cada expiração. Um MDM inscrito por meio do Android Enterprise gera chaves no dispositivo e renova certificados automaticamente. Se você já possui licença do Microsoft Intune ou Workspace ONE para o Android, o custo extra é principalmente tempo de configuração.

Os colaboradores podem usar o EAP-TLS em telefones Android pessoais?

Sim, por meio de um perfil de trabalho do Android Enterprise, que mantém os certificados e aplicativos corporativos separados dos dados pessoais. O MDM instala o certificado e o perfil de WiFi apenas dentro do perfil de trabalho. Alguns colaboradores recusarão a inscrição em telefones pessoais. Para esses dispositivos, o Purple Staff WiFi fornece a cada pessoa sua própria credencial iPSK ou SecurePass, vinculada ao seu provedor de identidade, sem necessidade de gerenciamento de dispositivos.

O EAP-TLS funcionará em nossos pontos de acesso existentes?

Sim. O EAP-TLS é um método 802.1X, e Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam 802.1X. O ponto de acesso apenas retransmite a troca. As verificações de certificado ocorrem entre o Android e seu servidor RADIUS. Você configura um SSID Enterprise apontando para o RADIUS e, se segmentar o tráfego, habilita VLANs atribuídas por RADIUS.

Como o EAP-TLS se compara com o PEAP-MSCHAPv2 para o Android?

O EAP-TLS é mais forte, pois não há senha para ser roubada. O PEAP-MSCHAPv2 envia um nome de usuário e senha dentro de um túnel TLS, portanto, uma senha obtida por phishing funciona em qualquer dispositivo. O EAP-TLS precisa de um certificado cuja chave privada permaneça no dispositivo emitido. O PEAP é mais rápido de iniciar porque não precisa de PKI. Muitas empresas usam o PEAP enquanto constroem a infraestrutura de certificados necessária para o EAP-TLS.

O EAP-TLS ajuda na conformidade com o PCI DSS e o GDPR?

Sim, ele fornece controles e evidências para ambos. O requisito 4.2.1.2 do PCI DSS v4.0 exige criptografia forte para autenticação sem fio por onde trafegam dados do portador do cartão. Os certificados por dispositivo registrados pelo RADIUS mostram qual dispositivo se conectou e quando. O Artigo 32 do GDPR exige segurança adequada para dados pessoais, o que é suportado pela autenticação mútua. O EAP-TLS não garante conformidade por si só; segmentação, registros e políticas ainda se aplicam.

Como migramos os dispositivos do Android de uma senha de WiFi compartilhada para o EAP-TLS?

Execute ambas as redes em paralelo e, em seguida, desative a antiga. Crie o SSID do EAP-TLS e envie a AC raiz, o certificado SCEP e os perfis de WiFi para um grupo piloto. Confirme se os testes negativos foram aprovados e, em seguida, amplie a atribuição em etapas enquanto a rede de chave compartilhada permanece ativa. Assim que os registros do RADIUS mostrarem que a infraestrutura está se autenticando com certificados, remova o perfil antigo e desligue o SSID de chave compartilhada.

Onde o Purple se encaixa se nossos dispositivos de colaboradores usarem o EAP-TLS?

O Purple atende a todas as conexões que o EAP-TLS não atende. O WiFi para visitantes atende aos visitantes em um SSID separado com um portal cativo, consentimentos de escolha consciente e WiFi Analytics. O WiFi para colaboradores usa Redes Baseadas em Identidade para fornecer aos dispositivos não gerenciados dos colaboradores suas próprias credenciais. O Purple é executado como uma sobreposição em nuvem nos pontos de acesso que você já possui, em mais de 80.000 locais ativos em mais de 90 países (dados do Purple).