Recovery sem perder soberania: por que 3 envelopes independentes mudam tudo

Cofre zero-knowledge tem um problema clássico: se o servidor matematicamente não consegue ver suas senhas, então também não consegue te devolver elas quando você esquecer a senha mestra. A garantia de privacidade vira armadilha de recuperação.

Quase todo cofre de senhas resolve isso quebrando a privacidade no momento do recovery. Você responde perguntas de segurança, fornece um documento, fala com atendimento, e a empresa libera acesso. Naquele momento, ela teve que conseguir te identificar e dar de volta seu material. Significa que ela podia, e poderia ter feito o mesmo para outro pedido, em outras circunstâncias.

Existe um jeito diferente. Mais novo, mais elegante, e que sustenta a promessa zero-knowledge mesmo durante o recovery. Chama-se múltiplos envelopes OPAQUE com domain separation. Esse texto explica como funciona, sem matemática pesada.

O que é um envelope OPAQUE

OPAQUE-3DH (RFC 9497) é o protocolo que permite que cliente e servidor concordem numa chave compartilhada a partir de uma senha, sem o servidor ver a senha. Cada vez que você cria conta, o cliente e o servidor executam o register, que produz dois artefatos:

1. Um envelope opaco que fica no servidor (cifrado com sua senha, mas o servidor não tem a chave de decifrar).
2. Uma export_key de 32 bytes que fica no cliente (derivada determinística da sua senha, sal do servidor e parâmetros internos).

Você esquece a export_key (não precisa lembrar) porque ela é derivada da senha toda vez que você loga. Mas ela é o material que cifra suas chaves do cofre. Logo, se você sabe a senha mestra, derivam export_key, decifra envelope, libera vault. Se não sabe, nada.

O envelope é o ponto-chave. Ele é específico daquela senha. Mudou a senha, muda o envelope. Não tem como descobrir a senha a partir do envelope sozinho (mesmo com poder computacional ilimitado, ele é teoricamente opaco).

A ideia: 3 envelopes, 3 senhas diferentes

E se você criasse não um, mas três envelopes ao mesmo tempo? Cada um cifrado com uma senha diferente? Cada um capaz de decifrar a mesma chave do cofre?

Isso é o que o TAIVA Vault faz no cadastro. Você não vê três envelopes na interface. Você vê:

1. Senha mestra que você decora e usa todo dia.
2. Senha de backup que você anota em outro lugar (gerenciador físico, papel num cofre, segunda família).
3. Chave de recovery de 24 palavras que você imprime ou copia para um lugar offline.

Internamente, cada uma dessas três entradas vira a senha de um envelope OPAQUE independente. Os três envelopes cifram a mesma DEK (Data Encryption Key) do cofre. Qualquer um dos três decifra o cofre inteiro.

A propriedade matemática crucial: os três envelopes não podem ser correlacionados. Mesmo o servidor olhando os três blobs cifrados que ele tem armazenados, não consegue dizer se vieram da mesma conta nem se cifram o mesmo conteúdo. Isso é chamado de domain separation: cada envelope é tratado como uma identidade criptográfica separada, com sal próprio, derivação própria, parâmetros próprios.

O fluxo de recovery na prática

Cenário típico. Você esquece a senha mestra. Tenta entrar, tenta de novo, percebe que não vai voltar. Vai para opção "esqueci senha".

A interface te pede: "use sua chave de recovery (24 palavras) ou sua senha de backup".

Você escolhe a chave de recovery, abre o envelope físico onde ela está, digita as 24 palavras.

O cliente:

1. Deriva uma export_key a partir das 24 palavras (mesma função, sal diferente).
2. Tenta decifrar o envelope OPAQUE de recovery (não o primário).
3. Se as palavras estavam certas, abre. Se erradas, falha sem revelar nada.
4. Decifrado o envelope, extrai a DEK.
5. Cofre desbloqueado.

Em nenhum momento o servidor viu suas palavras de recovery. Não viu sua senha mestra. Não viu sua senha de backup. O servidor só fez sua parte protocolar (responder ao handshake OPAQUE) e entregou o envelope opaco.

Após desbloquear via recovery, a interface te força a definir nova senha mestra. Isso gera novo envelope primário (substitui o antigo). Suas palavras de recovery continuam válidas (não mudam). Sua senha de backup continua válida. Você acabou de trocar um dos três anéis sem que o servidor visse nenhum deles.

Por que 3 e não 1 ou 5

A escolha não é arbitrária. Está calibrada para três cenários típicos de perda de acesso:

Cenário 1: você esqueceu a senha mestra.

Frequente, baixo impacto. Resolve com chave de recovery. Senha de backup nem entra em ação.

Cenário 2: você esqueceu a senha mestra E perdeu a chave de recovery.

Menos frequente, médio impacto. Geralmente acontece quando você perdeu acesso a um lugar onde guardava material físico (incêndio, mudança, troca de cofre familiar). Resolve com senha de backup, que mora numa cabeça diferente (cônjuge, filho adulto, amigo de confiança).

Cenário 3: você perdeu tudo.

Raro, alto impacto. Você esqueceu a senha mestra, perdeu a chave de recovery e perdeu acesso à senha de backup. Aí o cofre é irrecuperável. E isso é uma característica, não defeito. Significa que nem o serviço, nem governo, nem invasor consegue forçar acesso. O preço é que você também não consegue, se chegou nesse ponto.

Por isso 3. Um só (senha mestra) é frágil demais (qualquer esquecimento perde tudo). Dois ainda é pouco (cenário 2 é razoavelmente comum). Três cobre quase tudo sem inflar complexidade. Cinco ou mais aumentaria área de superfície sem cobrir muito mais cenário de uso real.

A pesquisa em UX de cofres digitais (Apple, Google, 1Password publicaram estudos) converge no número três como ponto ótimo entre robustez e usabilidade.

O detalhe que ninguém vê: domain separation

Voltando à propriedade técnica importante. Os três envelopes não devem revelar pertencerem à mesma conta.

Isso parece detalhe, mas tem consequência real. Imagine que o servidor é hackeado e vazam todos os envelopes OPAQUE armazenados. Sem domain separation, alguém olhando o vazamento poderia agrupar "primário, backup e recovery" do mesmo usuário, e atacar os três simultaneamente. Quebrar o mais fraco entrega acesso ao cofre.

Com domain separation, cada envelope parece um cadastro independente. Atacar um deles é estatisticamente igual a atacar qualquer outra conta sem ligação. Para atacar a "sua conta" especificamente, o atacante precisa saber QUAIS três envelopes pertencem a você, e isso o servidor não armazena nem em metadado.

Internamente, o TAIVA Vault implementa domain separation com credentialId distinto para cada envelope. O credentialId é derivado de userId + path onde path é "primary", "backup" ou "recovery". Como userId é interno (não publicado em vazamentos), os três envelopes ficam descorrelacionados a olho nu (e a olho de criptoanálise normal).

O que pode dar errado

A honestidade técnica importa também na descrição dos limites. Coisas que podem dar errado, e como mitigamos:

Você anota a chave de recovery na nuvem. Aí ela vira custodiada pela mesma classe de risco que o cofre. Recomendação: imprimir e guardar fisicamente. Algumas pessoas tatuam (não exagero, é prática real em famílias técnicas).

Você define a senha de backup igual à senha mestra. Tecnicamente possível, anula o benefício. Interface alerta, mas se você insistir, o sistema deixa. Recomendação óbvia: faça diferente.

Você dá a chave de recovery a alguém que depois vira hostil. Esse alguém pode entrar no seu cofre. A criptografia não resolve relação humana. Recovery key é poder de acesso. Trate como tal.

Você esquece os três. O cofre é irrecuperável. Não há porta dos fundos. Esse é o preço da soberania. Se houvesse porta dos fundos, ela existiria para atacante também.

Onde isso encaixa no design maior

O recovery via 3 envelopes é parte da promessa zero-knowledge real. Voltando ao princípio: o servidor não pode entregar acesso porque não tem o acesso. Você é o único locus possível de recuperação.

Mas a vida real é caótica. Senhas são esquecidas. Papéis se perdem. Pessoas mudam. Família migra. 3 envelopes calibram esse caos sem dar margem para que o servidor seja chamado de "guardião gentil" e termine entregando o cofre para quem não devia.

A próxima geração de cofres vai trazer também opções como compartilhamento social de recovery (Shamir entre confidentes), recovery por dispositivo de hardware (YubiKey), recovery por biometria local (sem servidor ver). Cada uma reduz mais o atrito sem trocar a soberania.

A direção é clara. O modelo "pede pro suporte e ele resolve" está sendo substituído por "você sempre teve poder de resolver, distribuído nas formas que faz sentido para você".

Leia também:

• Como o cofre que nunca sabe sua senha funciona: a arquitetura geral da qual o recovery é parte.
• Custódia vs posse: a distinção que ninguém ensina: por que o recovery clássico (via suporte da empresa) é custódia disfarçada.
• O que mudou no NIST FIPS 203 e por que importa para você: o algoritmo pós-quântico que cifra os envelopes contra ameaças futuras.

TAIVA Vault: cofre digital com 3 envelopes OPAQUE independentes. Esqueceu a senha mestra? Recovery via chave física ou senha de backup, sem que o servidor veja nenhuma das três. Começar trial grátis (14 dias) →