Falha no Coldcard permitiu grande roubo de Bitcoin apesar do uso de "secure elements"

Os dois chips de "secure element" do Coldcard não foram violados. O roubo que atingiu carteiras Coldcard a partir de 30 de julho de 2026 explorou um problema um nível abaixo: o software responsável por gerar a "seed" antes mesmo de ela ser entregue ao chip para armazenamento, segundo a análise técnica da BIT publicada em 7 de agosto de 2026. A conclusão do episódio é direta: um "secure element" pode ser excelente para impedir extração física e, ainda assim, proteger uma chave que já nasceu fraca. Como o ataque ocorreu sem "tocar" no secure element O Coldcard é fabricado pela canadense Coinkite. De acordo com a BIT, o produto usa dois chips resistentes a violação, um Microchip ATECC608 e um Maxim DS28C36B, projetados para suportar tentativas de extração em nível de laboratório. O ponto vulnerável estava antes disso: a origem da seed que esses chips passam a guardar. Segundo reportagem do Block citada pelo The Hacker News em 1º de agosto de 2026, a configuração de produção do Coldcard definia a macro MICROPY_HW_ENABLE_RNG como zero, pois a Coinkite fornecia um "wrapper" próprio para RNG de hardware. O problema é que uma biblioteca de suporte, a libngu, verificava apenas se a macro existia, e não se ela estava ativada. Com isso, o firmware ficava preso ao gerador de números aleatórios de fallback do MicroPython, o Yasmarang. O CoinDesk, em reportagem publicada em 31 de julho de 2026, descreveu o mesmo defeito: uma opção de build fazia o dispositivo ignorar o gerador de aleatoriedade de hardware, e uma checagem em uma biblioteca auxiliar testava somente a existência da configuração, não se ela estava em uso. De acordo com o CoinDesk, o Block rastreou a mudança a um commit datado de 1º de março de 2021. As publicações divergem em detalhes sobre o que alimentava esse gerador de fallback. O The Hacker News, citando o Block, diz que ele era inicializado a partir do ID único do dispositivo e de registradores de timer, sem coletar nova entropia depois. O CoinDesk descreve entradas equivalentes como o número de série do chip e registradores de clock, classificando-as como não secretas. A BIT, em 7 de agosto de 2026, relata duas instâncias de Yasmarang combinadas via XOR, com uma delas semeada por constantes públicas codificadas. A diferença está no traçado fino do mecanismo; o resultado prático é o mesmo. Entropia efetiva e impacto na segurança Segundo estimativas da própria Coinkite citadas por The Hacker News, BIT e crypto.news, as seeds geradas sob o bug teriam cerca de 40 bits de entropia efetiva nos modelos Mk2 e Mk3, e aproximadamente 72 bits nos Mk4, Mk5 e Q, frente ao alvo de projeto de 128 bits para uma seed BIP39 padrão. O Block, conforme o The Hacker News, evitou apresentar um número único de força bruta, definiu tetos condicionais e alertou que o valor mais alto não equivale a "segurança criptográfica real" de 73 bits. Não há, nos relatos públicos citados, benchmark de brute force divulgado, nem reconstrução de seed de uma vítima específica vinculada a um endereço drenado, segundo o The Hacker News. O que o secure element garante (e o que não garante) A BIT delimita a fronteira: o secure element "não verifica se a seed foi gerada com aleatoriedade suficiente". Ele protege a seed após a criação; não tem como julgar se a seed era boa quando chegou. Na comparação de arquiteturas, a BIT diz que o desenho de dois chips do Coldcard eleva a barreira para extração física, pois um atacante precisaria vencer dois chips de fornecedores diferentes mais o processador principal, patamar superior ao de um design com um único secure element. Ainda segundo a BIT, Ledger e Trezor usam um secure element cada. Um comparativo publicado pela Spark Money (sem data de publicação na versão revisada para esta matéria) descreve que os chips da Ledger são peças da STMicroelectronics certificadas em Common Criteria EAL5+ ou EAL6+ conforme o modelo, e que os Trezor Safe 3 e Safe 5 usam o OPTIGA Trust M da Infineon. O mesmo texto afirma que a documentação do secure element da Trezor é pública, permitindo auditoria independente, enquanto o firmware do secure element da Ledger permanece fechado sob NDA com a STMicroelectronics, apesar de o software em nível de aplicação ser majoritariamente aberto. O Coldcard, em contraste, publica o código-fonte completo do firmware, segundo Spark Money e BIT. A abertura, por si só, não impediu que o erro de março de 2021 passasse despercebido por mais de cinco anos. Ter firmware auditável não significa que ele tenha sido auditado com profundidade suficiente para capturar um bug desse tipo: um "guard" que checa se uma opção está definida, e não qual é o valor dela. Por que os números de perdas não batem Cinco veículos citados trazem cinco leituras numéricas para o mesmo evento em evolução. A discrepância reflete recorte e data de corte, não necessariamente conflito factual. O CoinDesk (publicado e atualizado em 31 de julho de 2026) relatou cerca de 594 BTC, aproximadamente US$ 38 milhões, retirados de cerca de 500 carteiras de assinatura única, em uma janela de 01:31 a 01:56 UTC. O crypto.news (1º de agosto de 2026) reportou os mesmos 594 BTC e cerca de US$ 38 milhões, mas situou a varredura entre 2:14 e 2:39 UTC, divergência de horário que não é possível resolver com as evidências aqui citadas. O The Hacker News (1º de agosto de 2026) citou mapeamento da Galaxy Research de um conjunto mais amplo: 1.196 endereços drenados em 41 minutos no dia 30 de julho, totalizando 1.082,65 BTC (cerca de US$ 70,2 milhões). Mais tarde, o mesmo artigo foi atualizado com duas ondas adicionais identificadas pela Galaxy Research, elevando o total observado para 1.367,05 BTC (cerca de US$ 88,6 milhões) em 4.585 endereços. A BIT, em 7 de agosto de 2026, apontou um acumulado até 3 de agosto de 2026 de aproximadamente 1.816 BTC, acima de US$ 116 milhões, em mais de 5.200 endereços, classificando o caso como o maior exploit de hardware wallet já registrado. Segundo o The Hacker News, a Galaxy Research ressalvou que suas conclusões se baseiam em análise de padrões on-chain e que não confirmou computacionalmente que todos os endereços marcados foram gerados com entropia fraca do Coldcard. A Galaxy também afirmou que a atividade seguia em andamento na data da atualização e que reportou cerca de 600 endereços sob suspeita de controle do atacante a investigadores, o que deixa o total sujeito a novas revisões. O que não dá para concluir a partir dos relatos Não existe um número final consolidado de perdas nas fontes citadas. Os totais de 594 BTC, 1.082,65 BTC, 1.367,05 BTC e 1.816 BTC devem ser lidos como medições em momentos e escopos diferentes. O crypto.news reportou que a Coinkite teria afirmado que um atacante possivelmente usou IA para encontrar a falha, e que uma revisão com IA feita pela própria empresa semanas antes não encontrou nada grave; a publicação descreveu a alegacão como "plausível, mas não verificada". Não há confirmação independente dessa atribuição nas evidências aqui revisadas. Também não há relato público que tenha reconstruído uma seed roubada específica e a tenha conectado a um endereço drenado, conforme o The Hacker News. O padrão usado pela Galaxy Research para atribuir ondas a um operador comum identifica comportamento transacional, não uma causa confirmada; a Galaxy afirmou explicitamente que não trataria a Onda 3 como ligada às Ondas 1 e 2. Quanto ao escopo de firmwares vulneráveis, o comunicado da Coinkite lista Mk3 firmware 4.0.1 a 4.1.9 e não cita o Mk2. Uma análise separada do Block, segundo o The Hacker News, coloca Mk2 e Mk3 nas versões 4.0.0 a 4.1.9 no caminho vulnerável, um alcance mais amplo do que o do aviso da empresa; não há como cravar qual escopo é definitivo com as informações apresentadas. Por fim, este material não permite dizer se o código de geração de seed de Ledger ou Trezor recebeu um escrutínio externo do mesmo tipo que o Block aplicou ao Coldcard, pois não há relatório equivalente nas fontes reunidas. O crypto.news afirmou em 1º de agosto de 2026 que Block, Trezor e Ledger confirmaram que seus produtos não foram afetados por esta falha específica, o que se refere a este bug, não a uma auditoria ampla do código de aleatoriedade. Fontes Todos os fatos acima são atribuídos a reportagens da BIT, Block (via The Hacker News), CoinDesk, crypto.news, The Hacker News, Galaxy Research e Spark Money. Onde houve divergência entre veículos, ela foi indicada no texto.