Infraestrutura de carteira e modelo de segurança
Contexto do setor
Sistemas de carteira costumam depender de um ou mais métodos criptográficos fundamentais para proteger chaves privadas. Entender essas abordagens oferece contexto para o modelo de segurança descrito neste documento.
Shamir's Secret Sharing (SSS)
SSS divide uma chave privada em várias partes, exigindo um limiar mínimo para reconstruir o original. Oferece sigilo perfeito — qualquer número de partes abaixo do limiar não revela nada sobre a chave. SSS é maduro, bem suportado por ferramentas e rápido (assinatura em 20–40 ms). A contrapartida é que a chave privada precisa ser totalmente remontada para assinar, criando um ponto único de falha no momento da reconstituição.
Threshold Signature Schemes (TSS)
TSS (comumente conhecido como MPC) permite que várias partes produzam conjuntamente uma assinatura sem jamais remontar a chave privada. Isso elimina o risco de reconstituição do SSS. A contrapartida é a imaturidade — o primeiro protocolo ECDSA eficiente entre duas partes surgiu só em 2017 — e o desempenho: cada assinatura envolve idas e voltas na rede, introduzindo latência que pode chegar a vários segundos.
Trusted Execution Environments (TEE)
TEEs executam operações criptográficas dentro de enclaves de hardware, garantindo que o material de chave nunca seja exposto e que apenas código autorizado rode. Clientes podem verificar operações por meio de atestações. TEEs escalam bem e evitam a latência de ida e volta do TSS, mas sua segurança depende da integridade do enclave, que historicamente foi vulnerável a exploits de canal lateral.
WebAuthn PRF Extension
A extensão WebAuthn PRF (Pseudo-Random Function) deriva um segredo determinístico do hardware de passkey do usuário — Secure Enclave em dispositivos Apple, TPM no Windows, Titan chip no Android. Esse segredo está vinculado ao dispositivo e à biometria ou ao PIN do usuário, calculado no dispositivo durante a autenticação e nunca transmitido. Ela viabiliza uma classe de desenhos de carteira em que o material de chave pode ser criptografado com um segredo que nenhum servidor jamais viu.
Proteção de chave em três partes
Visão geral
As chaves privadas neste sistema nunca são armazenadas inteiras — nem nos dispositivos do usuário, nem em nossos servidores, em lugar algum. Em vez disso, o material de chave é dividido criptograficamente entre três partes independentes usando um esquema de compartilhamento de segredo 3-de-3. As três partes precisam cooperar para reconstruir uma chave. Menos de três revela matematicamente zero informação sobre a chave privada.
Este é um modelo híbrido: combina criptografia no cliente baseada em passkey (PRF-as-KEK), compartilhamento de segredo e um enclave isolado no servidor em uma única arquitetura. A construção resultante alcança a mesma garantia de segurança informacional que o compartilhamento de segredo de Shamir — nenhum subconjunto de partes abaixo do limiar obtém informação sobre a chave — ao mesmo tempo em que vincula uma parte ao hardware de autenticação físico do usuário, de modo que nenhum comprometimento só no servidor pode reconstruir a chave.
Este é o modelo de segurança padrão para todos os dispositivos modernos (todos os navegadores principais em iOS, macOS, Android e Windows).
As três partes
Parte 1 — O autenticador do usuário
O hardware de passkey do usuário calcula um segredo determinístico vinculado àquele dispositivo e à biometria ou ao PIN do usuário. Essa saída — chamada de saída PRF — é produzida no dispositivo durante a autenticação e nunca é transmitida a lugar algum. Não é armazenada. Não é registrada em log. Existe apenas na memória durante a operação de assinatura.
Esse segredo é a contribuição do usuário para a reconstrução da chave. Sem ele, as outras duas partes não detêm nada que possa produzir uma chave privada utilizável.
Parte 2 — A API
A API armazena uma cópia criptografada do material de chave do usuário. Ela é criptografada com o segredo derivado por PRF do usuário, que a API nunca viu. A API controla o acesso — só libera esse payload criptografado para uma requisição que apresente uma asserção WebAuthn válida assinada pela passkey registrada do usuário. Ela não pode, porém, descriptografar o próprio payload.
A API atua como mecanismo de entrega autenticado, não como custodiante de chaves.
Parte 3 — O enclave crypto
Um sistema separado e isolado — operando independentemente da API com suas próprias chaves de criptografia e infraestrutura — detém a parte da chave no servidor. Essa parte é criptografada em repouso com um segredo conhecido apenas pelo enclave. O enclave libera a parte descriptografada somente depois que a requisição passou na validação da asserção, e apenas para ser combinada com a parte do usuário na etapa final de assinatura.
O enclave nunca vê a saída PRF do usuário, a parte de chave do usuário nem a chave privada montada.
Propriedades de segurança
Sem ponto único de falha
| Cenário | Consequência |
|---|---|
| Dispositivo do usuário roubado | O atacante não pode reproduzir a biometria/o PIN; a saída PRF não é obtível |
| API totalmente comprometida | O atacante obtém apenas texto cifrado com um segredo que nunca viu |
| Enclave totalmente comprometido | O atacante obtém uma parte da chave; a outra parte não está em nenhum dos sistemas comprometidos |
| API e enclave ambos comprometidos | O atacante obtém o payload do usuário criptografado e a parte do servidor — mas ainda não consegue descriptografar o payload do usuário sem a saída PRF do autenticador físico |
O último cenário é o crítico. Mesmo um comprometimento completo de toda a infraestrutura do lado do servidor é insuficiente para reconstruir uma chave privada. O autenticador do usuário é o portão criptográfico que nenhuma brecha do lado do servidor contorna.
Segurança informacional
O modelo híbrido herda a mesma classe de garantia de segurança que o compartilhamento de segredo de Shamir: a divisão da chave não é apenas computacionalmente segura — é segura em termos informacionais. Um atacante com poder computacional ilimitado, que detenha o material de duas das três partes, não obtém informação sobre a chave privada. Não existe algoritmo, dado qualquer tempo ou hardware, que derive a chave apenas com os dados de duas partes. É a mesma garantia fornecida por um one-time pad.
Não custodial por desenho
Operamos tanto a API quanto o enclave. Apesar disso, não podemos acessar unilateralmente os fundos dos usuários. A saída PRF do usuário é a peça que falta — é produzida dentro do hardware do usuário e nunca é transmitida. Nossa incapacidade de acessar fundos não é política nem compromisso contratual. É uma restrição matemática que vale independentemente de controles de acesso internos, pressão regulatória ou comprometimento da infraestrutura.
Como uma transação é assinada
Toda a assinatura ocorre no dispositivo do usuário. A chave privada nunca é montada em nenhum servidor.
- O usuário aprova uma transação no aplicativo. O dispositivo autentica o usuário por biometria ou PIN.
- O dispositivo calcula localmente seu segredo PRF vinculado ao hardware. Esse segredo nunca sai do dispositivo.
- O aplicativo obtém o payload do usuário criptografado da API e a parte do servidor do enclave. Nenhuma dessas peças é utilizável sozinha.
- No dispositivo do usuário, na memória: o segredo do hardware descriptografa o payload do usuário, produzindo a parte de chave do usuário. As duas partes são combinadas na chave privada completa.
- A chave privada assina a transação — inteiramente no dispositivo.
- A chave privada é imediatamente apagada da memória. Não é colocada em cache, não é persistida, não é registrada em log.
A chave privada completa existe por alguns milissegundos, apenas no dispositivo do usuário e apenas durante a operação de assinatura. Nenhum servidor a vê.
Exportação da chave privada
Se um usuário optar por exportar sua chave privada — por exemplo, para migrar para outra carteira — o mesmo princípio se aplica. A chave é reconstruída e entregue inteiramente no dispositivo do usuário. O servidor fornece as partes criptografadas, mas a descriptografia e a montagem ocorrem localmente. Em nenhum momento da exportação a chave privada passa por ou fica visível a qualquer servidor.
Sincronização de passkey e acesso entre dispositivos
Plataformas modernas — iCloud Keychain na Apple, Google Password Manager no Android — sincronizam passkeys entre os dispositivos de um usuário. O segredo vinculado ao hardware usado para reconstrução da chave faz parte do material de passkey sincronizado, ou seja, a mesma saída PRF é reproduzível em qualquer dispositivo do grupo de sincronização do usuário. Isso preserva o modelo de segurança em três partes entre dispositivos: qualquer dispositivo sincronizado pode participar da assinatura sem alteração da arquitetura do lado do servidor.
Os usuários são informados se a passkey foi sincronizada com a conta na nuvem, para sempre terem visibilidade sobre a recuperabilidade da carteira.
O suporte a PRF está disponível em iOS 18+, macOS Sequoia 15.4+, Android 14+ e na série YubiKey 5. Em plataformas sem suporte a PRF, usa-se um fallback de assinatura do lado do servidor.
Comparação com a segurança de carteiras convencionais
| Modelo | Localização da chave privada | Quem pode acessar os fundos |
|---|---|---|
| Autocustódia padrão (frase semente) | Armazenada pelo usuário | Qualquer pessoa com a frase semente |
| Custódia de exchange / carteira quente | Armazenada pelo operador | Operador (e qualquer pessoa que comprometa o operador) |
| Carteira de hardware | Armazenada no dispositivo | Qualquer pessoa com o dispositivo físico + PIN |
| Este sistema | Nunca armazenada inteira | Exige simultaneamente o autenticador ativo do usuário e a infraestrutura do servidor |
Resumo
Este modelo híbrido — combinando criptografia no cliente baseada em PRF, partilha de segredo e um enclave isolado — distribui confiança entre três partes genuinamente independentes, de modo que nenhum subconjunto de duas pode reconstruir uma chave privada, com a mesma garantia de segurança informacional que o compartilhamento de segredo de Shamir. O segredo de hardware vinculado à biometria do usuário é a âncora criptográfica de todo o sistema. A infraestrutura do lado do servidor, independentemente de quão amplamente esteja comprometida, não pode produzir uma assinatura válida sem a participação física do usuário.