A autenticação sem senha deveria marcar o fim das tomadas de conta. Projetada para substituir senhas tradicionais por chaves criptográficas vinculadas a dispositivos físicos, prometia um futuro onde credenciais roubadas não poderiam mais desbloquear contas de usuários.
Mas um exame detalhado de como o Google construiu seu ecossistema de passkeys revela algo muito mais complexo do que a imagem limpa e segura que o "passwordless" tipicamente projeta. Sob cada login de passkey impulsionado pelo Google Password Manager, um componente oculto na nuvem está realizando silenciosamente operações criptográficas sensíveis.
Arquitetura e descoberta
Um sistema de passkey do Google não funciona como um autenticador de hardware convencional travado em um único dispositivo. Sempre que um usuário do Chrome faz login em um serviço usando um passkey apoiado pelo Google Password Manager (GPM), o navegador abre silenciosamente uma conexão com um serviço remoto hospedado em enclave.ua5v[.]com.
Este domínio funciona como um autenticador baseado na nuvem responsável por gerar chaves de passkey, lidar com solicitações de autenticação e manter as credenciais sincronizadas em todos os dispositivos inscritos do usuário. Como de janeiro de 2026, quase nenhuma informação pública descrevia o papel deste domínio na autenticação de passkey.
Pesquisadores da Unit42 identificaram essa estrutura baseada na nuvem enquanto conduziam uma revisão de segurança profunda da implementação de passkey do Google, abordando o trabalho do ponto de vista de um atacante.
Fluxo de autenticação na nuvem
A arquitetura depende de um processo de onboarding de dispositivo que é executado em segundo plano antes que os passkeys possam ser usados. O Chrome gera dois pares de chaves apoiados por hardware usando o Trusted Platform Module (TPM) do dispositivo — uma chave de identidade e uma chave de verificação de usuário — e os registra com o autenticador na nuvem.
O autenticador na nuvem armazena essas chaves públicas, atribui uma chave de wrapping específica do dispositivo e emite um par de chaves de membro para estabelecer o dispositivo como um participante confiável no domínio de segurança do usuário.
O que essa arquitetura cria é um modelo híbrido onde as chaves privadas de passkey nunca são armazenadas diretamente em um dispositivo em forma utilizável. Em vez disso, elas são criptografadas com um Security Domain Secret (SDS) gerenciado pelo autenticador na nuvem.
Riscos e implicações de segurança
Cada login requer que o Chrome envie o SDS embrulhado de volta para a nuvem, onde é descriptografado e usado para assinar a resposta de autenticação em nome do dispositivo. Isso coloca uma confiança substancial no componente na nuvem e levanta questões pontuais sobre o que acontece quando essa lógica do lado da nuvem se torna um alvo.
A comunicação entre o Chrome e o autenticador na nuvem é protegida pelo Noise Protocol Framework, usando a variante de handshake Noise_NK_P256_AESGCM_SHA256. O Chrome abre uma conexão WebSocket para wss://enclave.ua5v[.]com/enclave, realiza uma troca de chaves Diffie-Hellman para estabelecer uma chave de sessão compartilhada e assina cada solicitação subsequente com uma chave de dispositivo apoiada pelo TPM.
Se comprometido ou impersonado, o enclave remoto poderia permitir que um atacante gerasse respostas de autenticação válidas em nome de qualquer usuário inscrito.
Recomendações para executivos e CISOs
Organizações e indivíduos que dependem de passkeys sincronizados através do GPM devem monitorar de perto suas contas do Google para inscrições de dispositivos inesperadas, auditar regularmente os logs de autenticação para padrões de acesso incomuns e considerar o uso de chaves de segurança de hardware compatíveis com FIDO2 para contas privilegiadas ou de alta sensibilidade em vez de passkeys sincronizados na nuvem.
Perguntas frequentes
- O que é o enclave.ua5v[.]com? É um serviço de autenticador baseado na nuvem que gerencia operações criptográficas para passkeys do Google.
- Qual o risco principal? Concentração de autoridade criptográfica em um componente remoto que, se comprometido, pode gerar autenticações válidas.
- Como mitigar? Usar chaves de segurança de hardware FIDO2 para contas críticas.