Ataque Pass-ta-key expõe mitos sobre passkeys e TPM no Windows

O pesquisador Arie Olshtein, da firma de segurança Palo Alto Networks, detalhou recentemente uma técnica de exploração batizada de Pass-ta-key, direcionada ao aplicativo do Google Password Manager (GPM) no sistema operacional Windows. A divulgação provocou forte apreensão entre profissionais de tecnologia ao demonstrar a extração do conjunto completo de chaves de acesso (passkeys) em uma máquina infectada por pragas virtuais. No entanto, conforme revelado pelo editor sênior de segurança do portal Ars Technica, Dan Goodin, o alarde gerado ao redor dessa pesquisa mascara uma realidade fundamental: o ataque não introduz um vetor inédito de vulnerabilidade, mas apenas expõe as consequências históricas do comprometimento direto de um dispositivo rodando o sistema da Microsoft.

O termo Pass-ta-key foi formulado como um trocadilho intencional combinando a palavra passkey, a expressão técnica pass the key (passar a chave) e uma referência bem-humorada ao prato italiano pasta. O estudo publicado por Arie Olshtein focou na capacidade de malwares lerem e interceptarem credenciais mantidas pelo Google Password Manager quando o aplicativo é executado em um ambiente Windows previamente tomado por código malicioso. A reação inicial da comunidade de cibersegurança envolveu surpresa expressiva, motivada sobretudo por uma crença bastante difundida de que todas as passkeys ficariam obrigatoriamente retidas dentro do hardware blindado do computador.

A principal fonte de confusão no debate público envolve o papel desempenhado pelo TPM (Trusted Platform Module), o módulo de plataforma confiável integrado aos processadores e placas-mãe de computadores modernos. Muitos administradores de sistemas supunham que o TPM funcionava como um cofre inviolável do qual nenhuma chave privada poderia ser extraída por software, independentemente do nível de privilégio do malware no Windows. Quando o experimento da Palo Alto Networks comprovou que o Pass-ta-key conseguia colher as credenciais do GPM, questionamentos surgiram sobre a real robustez da autenticação sem senha. O diagnóstico técnico de Dan Goodin no Ars Technica demonstra que essa expectativa equivocada decorre de uma interpretação incorreta das diretrizes da FIDO Alliance.

Armazenamento e especificações FIDO2

Contrariando a percepção popular de muitos usuários, as especificações oficiais do padrão FIDO2, gerenciadas pelo consórcio industrial FIDO Alliance, não exigem que as passkeys sejam mantidas obrigatoriamente dentro de chips TPM ou em qualquer outro hardware dedicado de isolamento criptográfico. Embora o mercado utilize terminologias variadas dependendo da fabricante — como Secure Enclave nos ecossistemas da Apple, Trusted Execution Environment (TEE) em arquiteturas ARM e StrongBox em dispositivos com Android —, a arquitetura da FIDO Alliance concede liberdade para que desenvolvedores definam onde e como as chaves serão armazenadas. O propósito central da norma é eliminar segredos compartilhados expostos a ataques de phishing na web, e não criar imunidade contra malwares que controlam o próprio sistema operacional.

Dentro do ecossistema computacional atual, a Microsoft figura praticamente como uma exceção isolada ao permitir que usuários corporativos salvem suas passkeys diretamente no TPM nativo do Windows. Essa abordagem baseada em hardware rígido, no entanto, é recomendada pela própria Microsoft essencialmente para redes empresariais com gestão centralizada, não sendo a configuração padrão destinada ao consumidor comum. Essa distinção estratégica ocorre porque o armazenamento exclusivo via hardware impõe barreiras severas de usabilidade para o público geral, impedindo o fluxo contínuo de dados entre múltiplos aparelhos.

A mudança de paradigma em direção ao armazenamento local e à sincronização em nuvem ocorreu há alguns anos, quando os arquitetos de sistemas operacionais e desenvolvedores de aplicativos independentes identificaram um gargalo decisivo: as passkeys não teriam qualquer chance de alcançar adoção em massa se não pudessem ser sincronizadas facilmente entre todos os dispositivos do usuário. Caso a gravação no TPM fosse obrigatória, a única maneira de utilizar uma credencial em um novo computador ou celular seria recriar manualmente o par de chaves assimétricas em cada serviço web individualmente. Diante dessa limitação estrutural, os projetistas da FIDO Alliance validaram o modelo de armazenamento flexível nos dispositivos e na nuvem.

Isolamento e sandbox no Windows

A decisão de permitir o armazenamento de passkeys nos próprios dispositivos foi fundamentada na premissa de que os sistemas operacionais modernos oferecem controle granular de permissões e isolamento de processos. Em plataformas como macOS, iOS e Android, o modelo de sandboxing é estruturado de tal forma que um programa malicioso instalado na máquina não possui capacidade técnica para acessar a memória, os arquivos ou as chaves privadas mantidas por outro aplicativo. Nesses ecossistemas, o isolamento nativo impede a coleta indevida das credenciais, a menos que o sistema operacional seja violado por meio de uma exploração complexa de vulnerabilidade do tipo zero-day, premissa que tem se provado válida na prática real de segurança.

O ambiente Windows, contudo, constitui a grande exceção a essa regra de isolamento rígido devido a restrições históricas de compatibilidade regressiva mantidas pela Microsoft. Diferente do iOS ou do Android, nos quais cada aplicativo roda por padrão em uma caixa de areia com privilégios severamente restritos, no Windows a grande maioria dos programas e processos é executada com todas as permissões concedidas à conta do usuário logado. Embora o Windows disponha de tecnologias de sandboxing projetadas para isolar certas aplicações, essa proteção funciona apenas de forma unidirecional: um app confinado fica limitado, mas um malware executado fora do sandbox tem acesso livre aos dados e processos de aplicativos circunscritos.

Especialistas em arquitetura de segurança sempre estiveram cientes de que o escopo de proteção no Windows é consideravelmente mais frágil contra códigos maliciosos operando no nível do usuário. Sem a garantia de que as passkeys armazenadas localmente em um computador Windows ficariam a salvo no caso de uma infecção, os desenvolvedores de softwares de terceiros criaram uma abordagem alternativa de design. Em vez de salvarem as chaves puras no disco rígido local sem isolamento adequado, aplicações como o Google Password Manager para Windows, o 1Password e o Dashlane passaram a armazenar as credenciais na forma de blocos criptografados de ponta a ponta (end-to-end encrypted blobs) hospedados na nuvem.

Fluxo do Google Password Manager

Para compreender como o ataque **Pass-ta-key** explora essa estrutura, é necessário analisar a mecânica do fluxo de autenticação operado pelo **Google Password Manager** no **Windows**. Quando um usuário decide realizar login em um site utilizando uma *passkey* gerenciada pelo **GPM**, o computador local resgata uma chave de usuário ou de dispositivo armazenada no **TPM** e a apresenta ao autenticador localizado na infraestrutura de *backend* do **Google**. A apresentação dessa chave, somada ao fato de a máquina já estar previamente logada na **Conta do Google** da vítima, autoriza os servidores do **Google** a emitirem uma asserção de autenticação criptográfica direcionada ao site que o usuário deseja acessar.

Essa asserção transmitida ao serviço final é assinada digitalmente com a chave privada correspondente, que permanece guardada de forma criptografada nos servidores em nuvem do **Google**. Uma vez confirmada a assinatura, a sessão do usuário é liberada no site de destino. Esse fluxo distribuído difere radicalmente do funcionamento dos mesmos aplicativos no **iOS**, **macOS** e **Android**, nos quais o dispositivo físico local — e não a nuvem — guarda a chave privada criptografada no armazenamento interno e assina a asserção de autenticação diretamente na máquina cliente sem a intermediação de servidores remotos.

A finalidade das passkeys é eliminar um segredo compartilhado que possa sofrer phishing ou ser obtido por meio de violações de servidores. As passkeys não foram projetadas para resistir a ataques físicos contra os dispositivos que as armazenam.

A arquitetura adotada pelo **Google Password Manager** no **Windows** garante a conveniência da sincronização, mas transfere o elo de validação para a sessão ativa da **Conta do Google** mantida no navegador ou no sistema operacional. Caso essa sessão seja comprometida por uma praga virtual que ganhe controle sobre a máquina local, o atacante adquire a capacidade de invocar os mesmos privilégios do usuário legítimo para interagir com o *backend* do **Google**, criando o cenário explorado pela pesquisa da **Palo Alto Networks**.

Variantes e mecânica do ataque

A demonstração técnica desenvolvida por Arie Olshtein revelou três variações distintas de execução do Pass-ta-key, explorando a relação de confiança entre o computador infectado e os serviços em nuvem. A variante mais impactante descrita no estudo faz com que o sistema Windows comprometido forje sua identidade na rede, simulando ser um dispositivo iPhone legítimo. Ao mascarar a comunicação com os atributos de um aparelho iOS, o código malicioso consegue acionar o recurso nativo de sincronização do Google Password Manager, projetado originalmente para permitir que usuários transfiram suas credenciais para novos telefones, resultando na entrega de todas as passkeys secretas diretamente ao atacante.

Apesar do impacto visual da demonstração da **Palo Alto Networks**, a análise de **Dan Goodin** no **Ars Technica** destaca que o cenário de risco sob um sistema Windows infectado permanece inalterado em relação às credenciais tradicionais. Se um cibercriminoso obtém acesso de execução de código com privilégios de usuário em uma máquina, ele possui meios técnicos para manipular o gerenciador de senhas, capturar dados digitados na memória RAM ou acionar as rotinas de exportação de cofres de credenciais. A mecânica descrita no Pass-ta-key representa uma consequência inevitável do comprometimento do host, e não um defeito estrutural na criptografia assimétrica das passkeys.

O relatório de Arie Olshtein sugere, contudo, que o aplicativo do Google Password Manager para Windows pode apresentar lacunas em certas camadas defensivas de software quando comparado a soluções concorrentes dedicadas. Gerenciadores como o 1Password implementam chamadas diretas às APIs do sistema operacional Windows para bloquear e impedir que processos terceiros leiam o conteúdo de seu espaço de memória. Todavia, a comunidade global de segurança cibernética aceita como consenso o fato de que, uma vez que o dispositivo cliente é tomado por um malware, o controle do invasor sobre as aplicações ativas é praticamente absoluto.

O papel real das passkeys

A criação e padronização das passkeys pela FIDO Alliance visaram resolver uma das maiores fragilidades da história da computação: a dependência de senhas estáticas e segredos compartilhados que podem ser interceptados por sites falsos, ataques de força bruta ou vazamentos maciços em bancos de dados corporativos. O protocolo foi desenhado para assegurar que, mesmo que um servidor web seja invadido ou que um usuário digite seus dados em uma página clonada, a chave privada nunca seja exposta. O ecossistema FIDO2 não foi concebido, contudo, para neutralizar invasões locais executadas diretamente dentro do sistema operacional cliente do usuário.

Para profissionais de cibersegurança e equipes de tecnologia que atuam no Brasil e no cenário internacional, as descobertas sobre o **Pass-ta-key** oferecem lições claras sobre gestão de riscos e arquitetura de redes. A transição de senhas convencionais para *passkeys* reduz radicalmente a superfície de ataques remotos e tentativas de *phishing* — ameaças que representam a esmagadora maioria dos incidentes de segurança corporativa —, mas não elimina a necessidade imperativa de manter controles rigorosos de proteção de endpoint, como sistemas de detecção e resposta (EDR) e políticas de privilégio mínimo no **Windows**.

Como conclui a avaliação do **Ars Technica**, o estudo conduzido pela **Palo Alto Networks** cumpre um papel pedagógico relevante ao desmistificar o funcionamento interno do Google Password Manager no **Windows**, reforçando que o comprometimento de um dispositivo logado expõe inevitavelmente todos os dados nele acessíveis. O ataque **Pass-ta-key** reafirma uma regra secular da segurança da informação: no momento em que um software malicioso ganha controle sobre o sistema operacional de um usuário, a integridade de qualquer mecanismo de credencial executado no mesmo ambiente estará comprometida.