Falha de entropia da Coldcard e quase US$ 90 milhões em perdas: um alerta profundo sobre um hardware considerado “absolutamente seguro”

Em 30 de julho, surgiu na blockchain do Bitcoin uma série de transferências bastante incomuns.

A primeira rodada de varredura que chamou atenção durou apenas 41 minutos. Nesse intervalo, 1.082,65 BTC foram transferidos de 1.196 endereços. Mais tarde, a Galaxy Research identificou outras duas rodadas de atividade aparentemente relacionada. Até 2 de agosto, as três rodadas somavam aproximadamente 1.367,05 BTC, avaliados em quase US$ 88,6 milhões pelo preço da época, envolvendo 4.585 endereços.

Esses números podem ser confrontados com as atualizações públicas da Galaxy Research, o rastreamento on-chain do CoinDesk e a análise técnica publicada pelo The Hacker News.

As carteiras tinham um ponto em comum: acredita-se que suas seeds tenham sido geradas por carteiras de hardware Coldcard, da Coinkite.

Muitos dos dispositivos afetados ficaram offline por anos, e suas frases de recuperação nunca foram enviadas para a nuvem. O problema surgiu muito antes. Quando essas carteiras foram criadas, os dispositivos não utilizaram, como deveriam, o gerador de números verdadeiramente aleatórios por hardware. O atacante não precisava roubar a frase-semente. Bastava calcular as frases que poderiam ter sido geradas e depois procurar na blockchain os endereços correspondentes.

Esse é um dos tipos de falha mais difíceis de prevenir em uma carteira de hardware. O dispositivo pode permanecer trancado em uma gaveta e a chave privada pode realmente nunca sair dele. Mas, se a chave privada já nasceu com aleatoriedade insuficiente, medidas posteriores como air gap, elemento seguro e proteção contra violação não conseguem compensar o problema.

Limites das fontes e das conclusões

Fontes primárias para verificação: COLDCARD Mk3 Seed Generation Warning; Version History; BIP-0039: Mnemonic code for generating deterministic keys.

Os fatos verificáveis deste artigo sobre a falha de baixa entropia da COLDCARD, os firmwares afetados e a migração segura baseiam-se nas fontes oficiais ou regulatórias citadas. O status real do serviço, tarifas, critérios de elegibilidade e disponibilidade regional devem ser confirmados nas páginas atuais do emissor ou da plataforma no momento da solicitação.

A migração de ativos deve ser realizada em um dispositivo confiável, com verificação direta do endereço de destino. Qualquer valor de perda deve distinguir confirmação oficial de análise de terceiros. Experiências de usuário, taxas de sucesso, comparações de custos ou avaliações de tendências que não tenham sido divulgadas diretamente nas fontes primárias acima são análises ou inferências e não foram oficialmente confirmadas para casos individuais pelas entidades envolvidas.

O que já foi confirmado

A Coinkite, desenvolvedora da Coldcard, reconheceu que parte do firmware publicado entre 2021 e julho de 2026 apresentava um problema de baixa entropia. A empresa orientou os usuários afetados a gerar novas seeds e transferir seus fundos para novos endereços. As versões corrigidas indicadas no aviso de segurança da Coinkite incluem Mk2/Mk3 4.2.0, Mk4/Mk5 padrão 5.6.0, Q padrão 1.5.0Q e as versões da linha Edge 6.6.0X e 6.6.0QX.

A equipe de engenharia e segurança de Bitcoin da Block também realizou uma análise independente. O relatório técnico localizou o problema na cadeia de chamadas do gerador aleatório. Ao criar uma seed, o firmware deveria chamar o gerador de números aleatórios por hardware do chip STM32, mas acabava utilizando o Yasmarang, um gerador pseudoaleatório por software incorporado ao MicroPython.

Tanto a falha de firmware quanto as varreduras on-chain são reais, mas a atribuição entre os dois fatos ainda não está totalmente fechada. A Galaxy identificou as transações relacionadas a partir de padrões de taxas, comportamento do troco, estrutura de transferências em lote e caminhos de derivação. Até agora, nenhum relatório público apresentou de ponta a ponta a reconstrução da seed fraca de uma vítima específica e a correspondência exata com um endereço esvaziado.

Por isso, a formulação mais precisa é: pesquisadores encontraram uma falha no firmware da Coldcard capaz de reduzir a geração de chaves privadas a um espaço pequeno o suficiente para enumeração offline e, ao mesmo tempo, observaram várias rodadas altamente suspeitas de varredura de fundos, fortemente alinhadas em tempo e comportamento. Afirmar que todos os 1.367,05 BTC foram “comprovadamente roubados por meio dessa falha” ainda vai além do que as evidências permitem.

O bug estava escondido na cadeia de chamadas do gerador aleatório

A Coldcard originalmente tinha um código que lia diretamente o RNG por hardware do STM32. A interface Python correspondente era ckcc.rng_bytes().

Em 2021, ao migrar código relacionado a curvas elípticas e introduzir a libNgU, a Coldcard trocou a interface de aleatoriedade usada na criação de novas carteiras por ngu.random.bytes(). Foi nesse ponto que o problema entrou no firmware.

Na configuração de produção, MICROPY_HW_ENABLE_RNG era definido como 0. Os desenvolvedores fizeram isso porque a Coldcard já possuía seu próprio wrapper para o RNG por hardware e não precisava que o MicroPython fornecesse outro. No entanto, a verificação da libNgU usava #ifndef, que apenas verificava se a macro estava definida, não se seu valor era diferente de zero.

O código compilava e o dispositivo inicializava normalmente. Porém, durante o link final, rng_get() não era resolvido para a implementação de hardware esperada pela Coldcard, mas para a rotina de fallback Yasmarang do MicroPython. O código e os commits relevantes podem ser consultados no repositório do firmware da Coldcard, enquanto o relatório da Block reconstrói detalhadamente toda a cadeia de chamadas.

O Yasmarang produz números que podem parecer aleatórios, mas não é um gerador de números aleatórios criptograficamente seguro criado para chaves mestras de carteiras. Seu estado inicial deriva principalmente dos 32 bits inferiores do UID do chip, do temporizador SysTick e dos registradores de tempo do RTC.

O UID do chip é apenas um identificador do dispositivo, não um segredo. O estado do temporizador também não equivale a ruído físico, e essas entradas podem estar correlacionadas. Depois da inicialização, o gerador não continua absorvendo nova aleatoriedade. Se o estado do dispositivo, o horário de inicialização e o número de chamadas anteriores puderem ser reduzidos a uma faixa administrável, as saídas seguintes podem ser reproduzidas em outro computador.

O firmware ainda aplica hash ao resultado posteriormente, mas isso não resolve o problema. Dez mil entradas possíveis continuam produzindo apenas dez mil saídas possíveis após SHA-256. O resultado pode parecer mais uniforme, mas o espaço de busca não aumentou. O checksum do BIP-39 serve apenas para verificar o formato; ele não adiciona entropia real à frase de recuperação.

40 bits contra 72 bits: qual é a diferença?

A especificação BIP-39 exige entropia inicial entre 128 e 256 bits. Uma frase comum de 12 palavras corresponde a 128 bits, enquanto uma de 24 palavras corresponde a 256 bits.

A estimativa inicial da Coinkite para o firmware antigo indica que o espaço efetivo de busca das seeds geradas por Mk2/Mk3 era de cerca de 40 bits, enquanto Mk4/Mk5/Q ficavam em torno de 72 bits.

Um espaço de 40 bits contém aproximadamente 1,1 trilhão de candidatos. Parece muito, mas está longe da escala de 128 bits. A diferença entre os espaços é de aproximadamente 2^88. Se um atacante puder reduzir ainda mais o intervalo utilizando o modelo do dispositivo, o UID do chip, o tempo de boot ou caminhos de derivação comuns, a enumeração offline deixa de ser apenas uma hipótese teórica.

Os modelos posteriores acrescentavam uma etapa. Durante a inicialização, o Mk4 mistura um valor aleatório fornecido pelo elemento seguro, mas, depois de aplicar hash ao resultado, o código conserva apenas 4 bytes e usa esses 32 bits para substituir uma palavra de estado do Yasmarang. Com base nisso, a Block concluiu que, se os demais estados e o histórico de chamadas forem conhecidos, o elemento seguro distingue no máximo 2^32 fluxos de saída. Mesmo atribuindo ao estado desconhecido do temporizador um limite superior generoso, o espaço de candidatos permanece abaixo de 2^73.3.

Não é correto resumir isso como “o Mk4 tem 72 bits de segurança”. A própria Block ressalta que 2^73.3 é apenas um limite superior relativamente amplo para o espaço de candidatos, não 73 bits de segurança criptográfica no sentido convencional. O custo real de quebra depende das informações disponíveis sobre UID, tempo de boot, número de chamadas anteriores, derivação de endereços e velocidade de verificação. Ainda não existe um benchmark público completo de cracking.

O que pode ser afirmado com segurança é que os modelos posteriores estão em situação melhor que Mk2/Mk3, mas ainda não atingem o objetivo original de 128 bits da Coldcard. Por isso, a Coinkite também exige que esses usuários substituam suas seeds.

O problema está na seed, não apenas no dispositivo

O erro mais comum ao avaliar o risco é olhar apenas para o firmware atualmente instalado no dispositivo.

O que realmente determina o risco é qual versão do firmware gerou originalmente a frase de recuperação. Atualizar um Mk3 para a versão 4.2.0 hoje não adiciona retroativamente aleatoriedade a uma frase criada cinco anos atrás. Importar essa mesma frase em Ledger, Trezor ou uma carteira de software também não ajuda. A fraqueza já está incorporada na própria seed.

Há ainda um detalhe importante de versionamento. As versões padrão e Edge pertencem a linhas de lançamento diferentes. Um firmware Edge antigo não pode ser considerado corrigido apenas porque seu número é maior que 5.6.0. O escopo exato deve ser conferido no comunicado mais recente da Coinkite e no histórico oficial de versões.

A Coinkite afirma que TAPSIGNER, OPENDIME e SATSCARD utilizam bases de código diferentes e não são afetados por essa falha.

Se a carteira nunca esteve conectada, como o atacante conseguiu mover os bitcoins?

Uma carteira de hardware armazena as chaves privadas e assina transações. Quando a aleatoriedade é correta, obter a chave privada remotamente é de fato muito difícil.

Esse ataque contornou o dispositivo. O atacante podia enumerar possíveis estados aleatórios em seu próprio computador, gerar frases-semente candidatas, derivar as chaves públicas estendidas e os endereços comuns e então consultar a blockchain pública do Bitcoin para verificar se havia saldo.

Quando uma correspondência era encontrada, a chave privada calculada pelo atacante era idêntica à da carteira. O atacante podia assinar e transmitir a transação por conta própria, sem conectar o dispositivo original e sem conhecer o PIN. Portanto, o fato de o “dispositivo nunca ter ficado online” não elimina esse tipo de ataque, porque a busca pelas chaves candidatas pode ser feita inteiramente offline.

Moedas que ficaram anos sem se movimentar também não estão automaticamente seguras. O risco de uma seed fraca não expira. À medida que a pesquisa se torna pública e o custo computacional diminui, buscas antes pouco rentáveis podem se tornar economicamente viáveis. Endereços dormentes com saldos elevados podem, inclusive, tornar-se alvos mais atraentes.

Como interpretar os 4.585 endereços observados on-chain

Os principais dados compilados pela Galaxy Research até 2 de agosto foram:

As duas primeiras rodadas utilizaram padrões semelhantes de taxas fixas e processamento em lote. Podem ter vindo do mesmo operador ou apenas ter utilizado o mesmo conjunto de ferramentas. A terceira rodada mudou os endereços de consolidação e a estrutura das saídas. A Galaxy não atribuiu as três rodadas ao mesmo atacante porque os dados on-chain não são suficientes para sustentar essa conclusão.

O número de endereços também não pode ser convertido diretamente em número de vítimas. Uma pessoa pode controlar vários endereços, e uma única frase-semente pode derivar muitos endereços de recebimento. Por outro lado, se os pesquisadores analisaram apenas caminhos de derivação padrão, podem ter deixado de fora outros fundos da mesma carteira.

A atribuição on-chain também tem uma limitação natural: quando o próprio dono da carteira move os fundos, o padrão da transação pode ser semelhante ao de uma varredura feita por um atacante. O modelo da Galaxy utiliza impressões digitais de transações, caminhos de derivação e relatos de vítimas. Não existe um rótulo de “roubo” diretamente legível na blockchain. Por isso, os 1.367,05 BTC são melhor descritos como “volume observado aparentemente relacionado”.

O código estava aberto havia cinco anos. Por que ninguém percebeu?

O firmware da Coldcard sempre foi público, e a implementação do gerador aleatório por hardware realmente existia. Revisões anteriores conseguiam ver o código TRNG, mas não verificaram se a criação de novas carteiras acabava de fato utilizando essa implementação.

O bug atravessava várias camadas. A função de criação da carteira trocou de interface, a verificação de macros de compilação da libNgU era incompleta e o MicroPython oferecia um fallback por software com função semelhante. Nenhuma dessas partes parecia especialmente alarmante isoladamente. O software compilava, o dispositivo funcionava e a saída não se repetia de forma óbvia. O problema só aparece quando se acompanha a resolução dos símbolos e o caminho final de chamada no build real.

Testes convencionais de aleatoriedade também poderiam não detectar o problema. Um PRNG não criptográfico ainda consegue gerar valores com distribuição uniforme e sem repetições evidentes entre amostras consecutivas. O problema não é que os números “pareçam pouco aleatórios”, mas que o estado interno pode ser inferido.

O hotfix da Coinkite adicionou uma verificação dos símbolos RNG durante o build. Se a implementação errada voltar a entrar no firmware, a compilação falhará. A revisão técnica oficial também reconheceu que as verificações anteriores confirmavam a presença do TRNG esperado, mas não verificavam para qual implementação o caminho de geração da carteira realmente resolvia.

O código aberto continua sendo útil. O problema pôde ser localizado rapidamente e os commits históricos revisados justamente porque o código estava disponível. Mas “qualquer pessoa pode auditar” não significa que “alguém já auditou todos os caminhos críticos de segurança”. Em carteiras de hardware, builds reproduzíveis são apenas o ponto de partida. As cadeias de chamadas relacionadas a seeds, assinaturas e backups também precisam de validação ponta a ponta.

Multisig pode reduzir o risco, mas depende de como as chaves foram geradas

Em uma configuração multisig 2-de-3, recuperar uma única chave privada fraca não é suficiente para movimentar os fundos. O atacante ainda precisa de uma segunda chave de assinatura. Se as demais chaves tiverem sido geradas por fabricantes diferentes, bases de código distintas e fontes independentes de aleatoriedade, multisig pode proteger contra uma falha sistêmica de um único fornecedor.

Mas combinar três Coldcards afetadas em multisig não resolve automaticamente o problema. Se o atacante conseguir recuperar chaves fracas suficientes para atingir o limiar de assinatura, os fundos continuam vulneráveis. O relatório da Block afirma isso diretamente: o conjunto que forma o limiar da multisig deve conter um número suficiente de dispositivos seguros.

Para o usuário comum, uma configuração multisig mais complexa também não é necessariamente melhor. Falta de descriptors, caminhos de derivação, fingerprints de dispositivos ou backups pode fazer uma recuperação falhar. Se nunca foi feito um teste completo de restauração e a pessoa simplesmente seguiu um tutorial para juntar vários dispositivos, o risco operacional pode não ser menor que o de uma carteira de assinatura única.

Como migrar agora

Se sua seed foi gerada em uma das versões de firmware listadas acima e você não adicionou entropia suficiente por meio de dados independentes nem utilizou uma passphrase BIP-39 forte e exclusiva, trate-a como uma seed antiga em risco.

Primeiro, obtenha na página oficial da Coldcard o firmware corrigido correspondente ao seu modelo e à sua linha de lançamento e confirme a versão na tela do dispositivo. Em seguida, gere uma frase-semente completamente nova e registre e verifique com cuidado o backup, o fingerprint da carteira e o endereço de recebimento.

Não mova todo o saldo de uma vez. Primeiro envie um pequeno valor, confirme a chegada na nova carteira, verifique novamente o fingerprint e o endereço e só então transfira o restante. Mantenha o backup antigo até confirmar que todo o saldo chegou. Depois de concluir a migração, não volte a usar os endereços antigos para receber fundos.

A Coinkite estabelece uma exceção para entropia gerada com dados. Se, ao criar a seed, você usou a função “Add Dice Rolls” da Coldcard e inseriu pelo menos 50 lançamentos de um dado de seis faces que fossem justos, independentes e mantidos totalmente em segredo, os dados já contribuíram com pelo menos 128 bits de entropia; 99 lançamentos ou mais equivalem a aproximadamente 256 bits. Se você não lembra quantos lançamentos foram feitos, ou se os resultados foram fotografados ou anotados em um dispositivo conectado à Internet, não dependa dessa exceção.

Uma passphrase BIP-39 também pode adicionar um segredo independente, mas palavras curtas, citações, variações comuns e senhas reutilizadas ainda podem ser adivinhadas. O PIN do dispositivo não é uma passphrase BIP-39. Mesmo que a passphrase seja forte, a Coinkite continua recomendando substituir a seed, porque a frase de recuperação antiga continua vulnerável.

Durante a migração, tenha cuidado especial com falsos comunicados, falsos agentes de suporte e páginas que prometam “verificação de segurança da seed”. Qualquer pessoa que peça sua frase de recuperação em um site, janela de chat ou software de suporte remoto deve ser considerada não confiável.

O que esse incidente ensina

O air gap da Coldcard, os builds reproduzíveis e as proteções físicas ainda têm valor. Eles apenas não conseguem proteger uma chave privada que já nasceu fraca no momento da geração. Uma carteira de hardware não é um cofre isolado; é um processo completo: geração de números aleatórios, build do firmware, armazenamento da chave privada, assinatura, backup e recuperação. Uma falha em qualquer dessas etapas pode comprometer o sistema inteiro.

Usuários não conseguem auditar pessoalmente cada linha de código de uma carteira de hardware, mas podem reduzir pontos únicos de falha. Grandes saldos não devem ficar indefinidamente presos a um único fabricante e a um único método de geração de seed. Registre qual dispositivo gerou cada frase, junto com a versão do firmware e a data. Consulte periodicamente os avisos de segurança do fabricante. E, quando a vulnerabilidade afeta a própria seed, não presuma que atualizar o firmware basta.

O que realmente precisa ser substituído desta vez são as chaves. Enquanto a seed antiga continuar controlando os fundos, o risco permanece.

Referências

Fontes oficiais da empresa e do firmware

• Site oficial da Coldcard

• Site oficial da Coinkite

• Aviso oficial de segurança da Coldcard / Coinkite

• Revisão técnica oficial da Coinkite

• Código-fonte e alertas de segurança oficiais do firmware da Coldcard

• Histórico oficial de versões do firmware da Coldcard

• Página oficial de download de firmware da Coldcard

Fontes técnicas independentes e padrões

• Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware

• Bitcoin BIPs: especificação BIP-39

• Commit da Coldcard de 2021 que introduziu a libNgU

Rastreamento on-chain e verificação jornalística

• Galaxy Research: rastreamento da terceira rodada e totais das três rodadas

• CoinDesk: as três rodadas se expandiram para 4.585 endereços e cerca de 1.367 BTC

• The Hacker News: caminho da vulnerabilidade, versões afetadas e atualização dos dados da Galaxy