Quando a aleatoriedade falha: o bug de entropia da Coldcard e o que dois aparelhos mudam
No fim de julho de 2026, atacantes começaram a drenar bitcoin de milhares de carteiras de hardware que não tinham feito nada errado. Os donos haviam seguido os conselhos. Compraram um aparelho dedicado a assinar, mantiveram a semente offline, nunca a digitaram num site. Nada disso importou, porque a semente que aqueles aparelhos geravam nunca fora tão aleatória quanto parecia.
Cerca de 1.816 BTC saíram de mais de 5.200 endereços em quatro ondas. Tornou-se o maior exploit de carteira de hardware do ano.
Este artigo não é uma volta olímpica. O bug envolvido é do tipo que poderia ter acontecido a quase qualquer carteira, inclusive a nossa, e a pergunta interessante não é quem o publicou, mas o que a arquitetura de uma carteira faz quando ele acontece.
O que de fato deu errado
Um único commit, em março de 2021.
O projeto da Coldcard previa que as sementes fossem geradas por um gerador de números aleatórios em hardware — um chip dedicado que extrai entropia de processos físicos. Essa é a maneira certa. Mas uma mudança no firmware 4.0.1 fez a geração de sementes passar por um gerador pseudoaleatório em software semeado a partir de constantes públicas fixadas no código.
Um PRNG é determinístico por definição. Dado o mesmo valor inicial, produz sempre a mesma sequência. Então uma semente gerada assim não é um número que ninguém consegue adivinhar: é um número tirado de um conjunto pequeno o bastante para ser percorrido, usando constantes que estiveram o tempo todo no firmware publicado.
Os aparelhos continuaram se comportando normalmente. Mostravam vinte e quatro palavras, anotava-se, derivavam endereços corretos, assinavam transações válidas. Não existe em carteira alguma uma tela que mostre quanta entropia entrou na sua semente. Todo usuário afetado tinha um aparelho que parecia e se comportava exatamente como um que funciona, por até cinco anos.
A janela vai do firmware 4.0.1, de março de 2021, ao 4.1.9, de julho de 2026. Atualizar o firmware corrigia a geração dali em diante e não fazia absolutamente nada pelas sementes já criadas: aquelas chaves já eram fracas, e nenhuma atualização acrescenta retroativamente aleatoriedade a um número já escrito num cartão dentro do cofre de alguém. Os afetados tiveram de gerar uma semente nova e mover suas moedas.
Por que aleatoriedade fraca é perda total e silenciosa
Vale ser preciso sobre por que essa classe de bug é tão grave, porque não é intuitivo.
Uma semente BIP-39 de 24 palavras representa 256 bits de entropia. Adivinhar uma não é apenas difícil, é inimaginável: não existe computador, presente ou futuro, que percorra esse espaço por força bruta. É o alicerce sobre o qual repousa todo o modelo de autocustódia: sua chave está segura porque é uma entre um número incompreensivelmente grande de possibilidades.
Essa garantia não é uma propriedade das palavras. É uma propriedade do processo que as escolheu. Vinte e quatro palavras tiradas de um gerador fraco são idênticas a vinte e quatro tiradas de um forte. Passam em toda soma de verificação, produzem endereços válidos e restauram perfeitamente em qualquer carteira. A única diferença é que outra pessoa também consegue chegar a elas.
A falha, portanto, é invisível por dentro, e é completa. Não é "um atacante poderia roubar você se cometer um erro" — não há erro a evitar, nem link de phishing a recusar, nem caixa de confirmação a ler com atenção. O dinheiro está disponível quando convier ao atacante, e o primeiro sinal de que algo estava errado é que ele sumiu.
O que dois aparelhos mudam
Aqui está a parte que importa arquiteturalmente, e quero enunciá-la com precisão em vez de em termos de marketing.
O SSP é um multisig 2-de-2. Os fundos vivem num endereço controlado por duas chaves independentes, geradas em dois aparelhos independentes — uma na extensão do navegador, outra no aplicativo SSP Key — e uma transação exige as duas assinaturas. O arranjo dois-de-dois é a base inteira da carteira.
Agora rode o cenário da Coldcard contra essa estrutura. Suponha que a geração de sementes da extensão tivesse a mesma falha e que um atacante consiga derivar por completo sua chave do navegador.
Ainda assim ele não pode gastar nada. Ele tem uma das duas assinaturas exigidas. O endereço não libera fundos por uma chave só, seja de quem for e como quer que a tenha obtido. Para mover suas moedas ele precisaria quebrar também, de forma independente e simultânea, a chave do seu telefone — outro aplicativo, outro sistema operacional, outra fonte de entropia, gerada em outro momento.
Essa é a diferença estrutural. Numa carteira de chave única, uma semente fraca é perda total. Num 2-de-2, uma semente fraca é um problema sério que não é, por si só, uma perda.
A ressalva, dita com todas as letras
Seria fácil parar aqui e deixar você concluir que o SSP é imune a isso. Não é, e fingir o contrário durante o incidente de outra pessoa seria exatamente a hora errada.
Os dois aplicativos do SSP usam a mesma implementação de BIP-39 — @scure/bip39, fixada na mesma versão em ambos. Uma falha nessa biblioteca atingiria as duas chaves. A independência que o SSP lhe dá é real, mas específica: duas sementes separadas, geradas em momentos diferentes em aparelhos diferentes, extraindo entropia de fontes diferentes do sistema operacional — a Web Crypto do navegador de um lado, o CSPRNG da plataforma móvel do outro. Não é a independência de duas bases de código totalmente alheias.
O que isso compra é proteção contra o modo de falha que de fato ocorreu na Coldcard: um erro de implementação específico de um aparelho no jeito como um produto gerava suas sementes. Não protegeria contra um defeito na primitiva criptográfica compartilhada por baixo das duas.
Essa é uma afirmação bem mais fraca do que "isso não pode acontecer conosco", e é a verdadeira. Quem lhe disser que a carteira dele é categoricamente imune a falha de entropia está lhe falando do marketing dele, não da arquitetura.
O que tirar disso
Se você tem uma Coldcard daquela janela de firmware, a única suposição segura é que a semente está comprometida, tenham fundos se movido ou não. Gere uma nova em firmware corrigido e migre. Um aparelho que ainda não foi drenado não é um aparelho seguro.
Se você usa qualquer carteira de chave única, esse é o risco que você carrega, e vale ser consciente dele em vez de ansioso. Carteiras de hardware continuam muito melhores do que as alternativas para a maioria das pessoas. A lição não é que sejam ruins; é que uma chave só é um ponto único de falha, e cada parte da história dessa chave — inclusive o instante em que nasceu, anos atrás, num firmware que você não leu — faz parte do seu modelo de ameaça.
E, no geral, prefira arquiteturas em que uma coisa dar errado não seja suficiente. Esse princípio é o motivo de o SSP exigir dois aparelhos, de algumas operações exigirem nova assinatura mesmo você já estando autenticado, e de o que realmente barra uma transação ser uma pergunta que vale fazer a qualquer carteira em que você confia. A resposta nunca deveria ser "um segredo, e a esperança de que foi gerado direito".
Para uma comparação mais ampla das opções e do que cada uma protege de fato, comparando opções de autocustódia trata dos trade-offs.
