Em 31 de julho de 2026, um invasor esvaziou cerca de 500 carteiras de Bitcoin em apenas 25 minutos. O ataque movimentou aproximadamente 594 BTC, cerca de US$ 38 milhões, e todas as carteiras afetadas pertenciam a pessoas que compraram uma carteira de hardware justamente para evitar esse tipo de situação.
Coinkite disclosed that COLDCARD firmware had been generating keys using a software pseudorandom number generator rather than the hardware generator built into the device. Two functions in the codebase shared the same name and signature, so the linker selected the wrong one, and the build produced no warning.
Esse é apenas o caso mais recente de uma longa lista. Na última década, as maiores perdas em criptomoedas aconteceram menos por ataques sofisticados e mais por algo básico: randomness that was not random enough.
O que está por trás da chave privada?
Carteiras de criptomoedas — seja em aplicativos, extensões de navegador ou dispositivos físicos — dependem de uma tarefa feita corretamente: gerar números que ninguém mais consiga adivinhar ou reproduzir. É disso que se trata a entropia nesse contexto: o quanto um número gerado é imprevisível.
Entropy is the raw randomness a wallet uses to create a private key, measured in bits. More bits mean a larger space of keys that an attacker must search. It enters a wallet at setup. Every key, address, and signature after that follows fixed mathematical rules, so no new randomness arrives later.
Fonte de entropia
Em teoria, uma carteira pode obter aleatoriedade de um pseudorandom number generator (PRNG): um algoritmo que expande uma pequena quantidade de entropia “real” para o quanto for necessário, mas apenas se a semente inicial for realmente imprevisível.
Softwares rodando em abas de navegador ou em celulares recém-ligados costumam começar em uma espécie de “câmara de privação sensorial”. Para gerar um número realmente aleatório, o programa precisa de “ruído”: entradas imprevisíveis do mundo externo, como variações de tempo no processador, movimentos do mouse ou componentes de hardware especializados.
Nos primeiros milissegundos após ligar um dispositivo, esses reservatórios de ruído podem estar vazios ou só parcialmente inicializados. Se uma biblioteca criptográfica chamar o gerador de números aleatórios cedo demais, pode acabar usando uma fonte rasa, gerando números que, embora tecnicamente aleatórios, vêm de um universo pequeno o suficiente para ser totalmente explorado.
Browsers add their own constraints. JavaScript’s Math.random() was never designed for security, and even the safer crypto.getRandomValues() depends on the operating system’s underlying entropy pool. If that pool is weak, as it can be in mobile sandboxes, virtual machines, or stripped-down IoT devices, the randomness is compromised before it ever reaches the code that generates your private key.
Randomness na assinatura de transações
Ao assinar uma transação de Bitcoin ou Ethereum, você não usa sua chave privada diretamente. Em vez disso, gera um nonce: um número aleatório de uso único, que é combinado à chave privada no algoritmo ECDSA (Elliptic Curve Digital Signature Algorithm) para gerar a assinatura.
Mas aqui está o perigo: se o mesmo nonce for usado duas vezes com a mesma chave privada, a matemática permite que um invasor descubra essa chave. Assinaturas ECDSA são um par de números, (r, s), que satisfazem uma equação específica envolvendo:
a chave privada (d),
o nonce (k), e
a mensagem da transação já transformada em hash (z).
Se k for o mesmo em duas mensagens diferentes, as equações se alinham, permitindo que qualquer pessoa que veja as duas assinaturas calcule k. Uma vez conhecido k, d — a chave privada — pode ser obtida com algumas multiplicações e um inverso modular.
Em 2013, a falha na função SecureRandom do Android fez com que carteiras de Bitcoin gerassem nonces previsíveis. Fundos sumiram de carteiras antes que a maioria dos usuários sequer soubesse do problema.
Diferente de um erro comum de programação, não é possível detectar aleatoriedade de baixa qualidade apenas lendo o código-fonte. As chamadas de função podem parecer corretas, mas, a menos que você meça os bits realmente gerados e faça testes estatísticos para verificar sua imprevisibilidade, uma falha fatal pode ficar escondida por meses ou anos, esperando alguém paciente o suficiente para explorá-la.
O motivo pelo qual a entropia continua sendo uma vulnerabilidade persistente pode ser resumido em:
Startup entropy drought: Dispositivos recém-ligados podem não ter acumulado ruído ambiental suficiente para alimentar PRNGs.
Browser limitations: JavaScript’s Math.random() não é seguro; mesmo crypto.getRandomValues() depende do pool de entropia do ambiente do dispositivo.
Unsafe tooling: Geradores de endereços personalizados, scripts offline ou bibliotecas desatualizadas muitas vezes sacrificam aleatoriedade por velocidade ou reprodutibilidade.
Human input: “Brainwallets” e frases escolhidas por usuários já foram quebradas apenas com ataques de dicionário.
Criptógrafos há muito preferem os hardware random number generators (HRNGs), também chamados de true RNGs. Eles convertem fenômenos físicos como jitter eletrônico, ruído térmico e decaimento radioativo em bits aleatórios, podendo se auto-testar continuamente contra falhas ou vieses.
Como o hardware resolve isso
Em sistemas de alta segurança, a solução é simples: gerar as chaves dentro de um chip que contém um HRNG certificado e nunca permitir que essas chaves sejam copiadas.
A secure element is a purpose-built, tamper-resistant microcontroller. It is a fortified chip designed to store secrets and perform cryptographic operations without revealing the underlying keys. They are the same class of component used in passports to prevent cloning, SIM cards to authenticate devices to mobile networks, and contactless payment cards to authorize transactions.
A secure element pode conter um hardware random number generator que tira sua imprevisibilidade do ruído físico, como flutuações térmicas ou jitter de oscilador, em vez de depender apenas de algoritmos matemáticos.
Esses HRNGs não são dispositivos “de uso único”. Sob padrões como o NIST SP 800-90B, eles devem realizar testes contínuos de integridade, monitorando cada fluxo de saída em busca de viés estatístico, bits travados ou outras falhas que possam comprometer a aleatoriedade ao longo do tempo. Se algo parecer suspeito, o chip pode interromper a geração de chaves imediatamente. Em uma boa carteira de hardware, o HRNG do secure element alimenta diretamente o processo de geração de chaves dentro do próprio chip.
Nem todo “hardware” é igual
O termo carteira de hardware abrange uma ampla variedade de projetos, e nem todos oferecem o mesmo nível de proteção para a aleatoriedade e o isolamento das chaves.
Na base do mercado estão dispositivos construídos sobre microcontroladores de uso geral, chips projetados para flexibilidade e não para resistir a ataques físicos ou de canal lateral. Muitos deles incluem um gerador de números aleatórios básico.
Ainda assim, pode ser apenas um gerador pseudorrandômico alimentado pelo estado interno do dispositivo, e não um HRNG totalmente certificado e testado conforme os padrões exigidos. Nesses casos, a geração da chave pode acontecer no firmware, e a chave privada resultante fica temporariamente armazenada em RAM ou memória flash. Isso significa que uma falha no firmware, um ataque de canal lateral bem-sucedido ou uma violação física podem expor a chave.
Já nas carteiras baseadas em secure element, tanto a fonte de entropia quanto a lógica de geração de chaves ficam dentro de um ambiente resistente a violações. Esse modelo também impõe controles de acesso rígidos: operações criptográficas (assinatura, derivação) são realizadas dentro do chip, e apenas a assinatura final ou a chave pública saem dele — nunca o segredo em si.
O SP 800-90B descreve como avaliar uma fonte de entropia: o processo físico ou de software que gera bits imprevisíveis. Ele exige análise estatística rigorosa para estimar a entropia real de cada fluxo de bits, além de testes internos contínuos para monitorar a fonte em busca de viés ou falhas.
Um dispositivo em conformidade não gera números aleatórios apenas uma vez e torce para dar certo. Ele monitora seu próprio funcionamento o tempo todo: se o padrão de ruído do HRNG mudar, se um bit travar ou se a saída não passar nos testes estatísticos, o sistema interrompe a geração de chaves para evitar criar chaves fracas.
Como saber se você está em risco
A maioria dos usuários não consegue medir a entropia diretamente, mas é possível questionar onde e como suas chaves foram geradas. Se elas foram criadas “em uma página web” ou “em um app Android antigo”, especialmente antes de meados da década de 2010, essas chaves provavelmente são fracas. A abordagem mais segura é criar uma nova carteira em um dispositivo de hardware que use aleatoriedade certificada e documentada, e então transferir seus fundos para ela.
Linha do tempo dos ataques de entropia
A baixa entropia elimina a necessidade de engenharia reversa. O invasor simplesmente testa o pequeno conjunto de chaves que o gerador comprometido poderia produzir, deriva os endereços de cada candidato e verifica esses endereços na blockchain em busca de saldo. Veja alguns casos históricos:
2018—The IOTA seed generator scam: Usuários foram orientados a criar suas seeds de carteira em um site. O operador desse site mantinha uma cópia das seeds e drenou os fundos depois, roubando cerca de US$ 4 milhões. Aqui, a aleatoriedade era zero: o invasor já conhecia os números.
2019—The Blockchain Bandit: Pesquisadores de segurança identificaram 732 chaves privadas fracas de Ethereum em circulação. Um invasor desconhecido monitorava esses endereços há anos, drenando cerca de 45.000 ETH assim que fundos apareciam.
2022—Profanity’s vanity address catastrophe: A ferramenta open-source Profanity gerava endereços personalizados de Ethereum a partir de seeds com apenas 32 bits de entropia — cerca de quatro bilhões de possibilidades. Uma GPU moderna pode explorar esse espaço em poucas horas. A Wintermute, uma market maker de Londres, perdeu cerca de US$ 160 milhões desse jeito.
2023—Trust Wallet browser extension flaw: Em uma divulgação da equipe de segurança da Ledger, foi descoberto que a extensão de navegador do Trust Wallet gerava seeds com cerca de 32 bits de entropia. O problema foi corrigido rapidamente e alguns usuários foram reembolsados, mas por meses qualquer um que criasse uma carteira ali estava em risco.
2025—The LuBian allegation:A denúncia da Arkham ainda não foi verificada, mas se a perda de 127.426 BTC realmente for resultado de geração de chaves previsíveis, será o maior exemplo de como um erro na criação pode condenar bilhões em ativos.
2026: COLDCARD: Coinkite disclosed that a software pseudorandom generator had replaced the intended hardware generator in shipped firmware. The fallback entered the upstream dependency in May 2018 and reached key generation in March 2021.
A Coinkite estima cerca de 40 bits de espaço efetivo de busca no hardware Mk3, e cerca de 72 bits em modelos mais recentes que misturavam dados do secure element. Ambos os números estão abaixo do alvo de 128 bits.
Havia um mecanismo de proteção para evitar exatamente isso. Ele testava se uma macro de configuração estava definida, e não se seu valor era diferente de zero; a macro foi definida como zero, então o teste passou e o erro nunca foi disparado.
Pensando em trocar o COLDCARD?
A Tangem gera sua chave dentro de um chip secure element certificado, usando um hardware random number generator.
Se você está cansado de se preocupar com seed phrases, nosso setup sem seed elimina as frases de 12 ou 24 palavras para anotar, fotografar ou perder — justamente o ponto em que a maioria dos hacks de carteiras acontece.
Auditada de forma independente pela Cure53, Kudelski e Riscure. Feita exatamente para esse cenário.
Mova suas moedas para onde a aleatoriedade é realmente aleatória. Conheça a Tangem Wallet.
Pergunte à IA se a Tangem é uma boa opção para as suas necessidades.
Pesquise a carteira Tangem com IA para descobrir se nossa segurança e usabilidade se adequam aos seus casos de uso específicos.
