Vulnerabilidade de aleatoriedade na Coldcard Wallet expõe ponto cego de segurança de carteiras de hardware

Artigo de: Liam 'Akiba' Wright

Tradução: Saoirse, Foresight News

Antes mesmo que um hardware wallet seja conectado à rede, sua defesa de segurança já pode ser comprometida. Um hardware wallet isolado pode manter a chave privada desconectada da internet por anos, mas o risco já está presente desde o momento em que a frase de recuperação é gerada.

A vulnerabilidade de números aleatórios recentemente divulgada pelo Coldcard confirma perfeitamente essa armadilha de segurança. Carteiras afetadas podem gerar uma frase de recuperação de 12 ou 24 palavras que parece totalmente normal, permitindo que o usuário armazene com segurança a frase e assine transações offline. No entanto, o intervalo do gerador de números aleatórios subjacente foi significativamente reduzido. Atacantes podem, em outros dispositivos, testar exaustivamente todas as combinações possíveis de sementes para recriar as sementes candidatas e, em seguida, comparar com o livro-razão público do Bitcoin para identificar as sementes válidas que correspondem aos endereços reais.

Na minha opinião, o destino de segurança da carteira é determinado no momento da criação da semente. Antes que medidas de proteção como PIN, placa de backup em aço, sacos de selo anti-tamper e isolamento a ar entrem em ação, a semente deve ser gerada a partir de uma fonte aleatória verdadeiramente confiável.

Um bom gerador moderno de números aleatórios pode produzir entropia suficiente. No entanto, se um atacante conhecer a lógica de funcionamento do gerador de números aleatórios, poderá reverter todo o processo de geração.

Lançar dados manualmente fornece aos usuários uma fonte de aleatoriedade, cuja aleatoriedade é intuitiva e controlável, e independente do código escrito pelo fabricante.

A geração de sementes do Coldcard apresenta vulnerabilidades de segurança. Atacantes podem gerar sementes candidatas externamente ao dispositivo, convertê-las em endereços de chave pública e compará-las com registros de transações no livro-razão público do Bitcoin para realizar ataques.

A origem técnica da vulnerabilidade é tão minúscula que é aterrorizante. Uma alteração de código em 1º de março de 2021 transferiu a funcionalidade de geração de semente do Coldcard para um novo repositório de código. Na versão de produção do firmware, a opção de configuração MICROPY_HW_ENABLE_RNG foi definida como 0, indicando que o gerador aleatório de hardware estava desativado; no entanto, a lógica de integração do código apenas verificava se essa opção de configuração existia, sem ler seu valor numérico. Sempre que essa opção de configuração estivesse presente, o sistema abandonava o gerador aleatório de hardware e passava a usar o algoritmo determinístico Yasmarang do MicroPython como solução alternativa. Segundo o relatório conjunto da Block, essa lógica defeituosa foi lançada oficialmente ao público em 17 de março, junto com a versão 4.0.0 do firmware.

A mnemonic phrase gerada parece perfeitamente normal, mas o espaço de busca exaustivo por trás dela foi drasticamente reduzido. Segundo cálculos preliminares da Coinkite, o espaço de busca efetivo para as versões Mk2 e Mk3 afetadas é de aproximadamente 40 bits; para as versões Mk4, Mk5 e da série Q afetadas, o espaço de busca efetivo é de aproximadamente 72 bits.

A equipe do Block estabeleceu restrições específicas para modelos futuros: quando o estado do algoritmo de reserva e o histórico de chamadas forem fixos, existem no máximo 2^32 fluxos aleatórios distinguíveis. Os dados fornecidos pela Coinkite estimam o intervalo de busca eficaz que um atacante poderia percorrer.

Ambos os relatórios de análise confirmam que todos os modelos posteriores antes da correção do firmware estavam dentro do intervalo de risco. O aviso de segurança da Coinkite afirma que os firmwares Mk4 e Mk5 anteriores às versões padrão 5.6.0 e Edge 6.6.0X, bem como os firmwares da série Q anteriores às versões padrão 1.5.0Q e Edge 6.6.0QX, estão afetados. Para os Mk2 e Mk3, a Coinkite lista as versões de risco como 4.0.1 a 4.1.9, enquanto a equipe Block considera que a vulnerabilidade já existia desde a versão 4.0.0. Em relação a essa fronteira de versão controversa, recomenda-se que os usuários adotem uma abordagem conservadora.

Este evento demonstra claramente: instalar apenas a nova versão do firmware não corrige as vulnerabilidades de segurança das carteiras existentes. Atualizar para a versão corrigida garante apenas a segurança das novas sementes geradas posteriormente; todas as sementes antigas já geradas conservarão apenas a entropia obtida no momento de sua criação, e todos os endereços derivados dessa semente compartilham a mesma chave subjacente.

Todos os usuários que estiverem utilizando uma versão de firmware com riscos devem consultar o comunicado oficial de segurança. A menos que você possa confirmar que a seed foi gerada por meio de um número suficiente de lançamentos de dados feitos manualmente, é obrigatório usar o firmware corrigido, confiar em uma fonte de aleatoriedade confiável para gerar uma nova seed e transferir os fundos para uma nova carteira. Se você apenas usar a antiga frase mnemônica para gerar novos endereços, o defeito de segurança original será mantido exatamente como antes.

O Bitcoin Optech publicou dados estimados em 31 de julho, indicando que o valor de ativos ameaçados excedia 1.000 bitcoins. Até 2 de agosto, a Galaxy Research estimou que aproximadamente 1.367 bitcoins em risco estavam contidos em 4.585 endereços. Um usuário da plataforma X com o nome de usuário Graham_Quantum afirmou que, em 29 de julho, 18,25245043 bitcoins já haviam sido transferidos de carteiras relacionadas.

Após a divulgação da mensagem, muitos usuários transferiram seus ativos por motivos de proteção, gerando um fluxo de capital ainda maior. Após a revelação da vulnerabilidade, 77.402 BTC foram movidos do pool de saídas não gastas (UTXO) antigas.

Dois tipos de dados precisam ser distinguidos:

Este acidente de segurança provocou dois impactos simultâneos: primeiro, o roubo de ativos por hackers; segundo, uma onda muito maior de migração voluntária dos usuários para se proteger.

A vulnerabilidade na Coldcard, que envolve aproximadamente US$ 89 milhões, provocou a maior transferência de fundos em Bitcoin na blockchain desde o colapso da FTX e comprometeu seriamente a interpretação dos sinais de mercado. Milhares de usuários transferiram emergencialmente seus Bitcoins de carteiras antigas, tornando difícil discernir a autenticidade dos sinais bearish emitidos pelos principais indicadores da blockchain.

Cálculos baseados na documentação oficial do Coldcard para dados: um dado justo de seis faces gera aproximadamente 2,585 bits de entropia por lançamento independente. Lançar 50 vezes produz aproximadamente 129,25 bits de entropia bruta, atendendo ao padrão de segurança comum de 128 bits; lançar 99 vezes produz aproximadamente 255,91 bits de entropia bruta, aproximando-se do padrão de segurança de 256 bits (esse valor ainda não passou pelo algoritmo de conversão integrado da carteira).

Este conjunto de valores corresponde ao padrão amplamente utilizado BIP-39: uma frase mnemônica de 12 palavras codifica 128 bits de entropia mais 4 bits de checksum; uma frase mnemônica de 24 palavras codifica 256 bits de entropia mais 8 bits de checksum.

O mecanismo de isolamento offline dos hardware wallets só protege a mnemonic gerada, mas não corrige vulnerabilidades de aleatoriedade fraca durante o processo de geração; apenas ao utilizar dados de entropia independentes obtidos por meio de lançamento de dados privado é possível gerar uma mnemonic BIP-39 segura.

A soma de verificação serve apenas para identificar erros de cópia da frase mnemônica. O que realmente determina a segurança são os dados aleatórios subjacentes. Operações de hash e formatação padronizada podem melhorar entradas de baixa entropia, mas o espaço total de todas as possibilidades da chave não aumenta. Aquelas 12 palavras que parecem tranquilizadoras podem vir de um pool aleatório extremamente pequeno.

Para que o lançamento manual de dados forneça proteção, o fluxo interno da carteira deve aceitar corretamente os dados aleatórios gerados pelos dados. Os dados em si devem ser válidos, cada lançamento deve ser autêntico e independente dos demais, e toda a sequência de lançamentos deve ser mantida em sigilo. Reutilizar padrões de lançamento, gravar imagens, armazenar sequências na nuvem ou inserir resultados em um computador conectado à internet comprometerão a independência e a confidencialidade da aleatoriedade.

Em relação ao evento de segurança desta Coldcard, a Coinkite declarou: apenas os usuários que puderem confirmar que foram realizadas pelo menos 50 lançamentos de dados justos, independentes e confidenciais na geração final da semente poderão evitar a migração de ativos; em qualquer situação de incerteza, a equipe recomenda a migração dos fundos.

Para mim, o valor central do dado manual reside no fato de que, ao depender do gerador de números aleatórios integrado ao dispositivo, você precisa confiar incondicionalmente em toda a cadeia: hardware, firmware, processo de compilação e código integrado.

O processo padronizado de entrada de dados dos dados permite introduzir entropia independente dessa cadeia de confiança, controlada diretamente pelo usuário. Aproximadamente 50 lançamentos justos de dados correspondem a um nível de segurança de 128 bits, e 99 lançamentos correspondem a um nível de segurança de 256 bits. No entanto, o usuário deve seguir rigorosamente o fluxo de operação oficial do dispositivo e não deve criar seus próprios esquemas de conversão de números aleatórios.

Defina uma senha BIP-39 de alta intensidade e única, que eleva o nível de ataque para outro patamar. A senha funciona como uma chave independente; mesmo que um atacante obtenha a frase de recuperação, ainda precisará decifrar a senha para acessar os ativos. Observe: a entropia da frase de recuperação não aumenta com a adição da senha. Qualquer senha (mesmo se um único caractere estiver incorreto) gerará um conjunto válido de endereços de carteira. Caso a senha seja perdida, os ativos serão permanentemente bloqueados. O PIN da carteira de hardware tem função totalmente diferente da senha.

Habilitar a senha de acesso envolve um compromisso: se você conseguir armazená-la adequadamente e reproduzi-la com precisão, ela criará uma forte segunda linha de defesa; mas se o plano de backup for inadequado, esse recurso pode impedir completamente o acesso aos seus ativos.

A vulnerabilidade do Coldcard mais uma vez alerta todos: a base da segurança da carteira de Bitcoin é a forte aleatoriedade no momento da geração da semente. Defeitos subjacentes semelhantes já ocorreram em sequência em diversos produtos de carteiras diferentes.

Em 2023, o Ledger Donjon divulgou que versões específicas da extensão de navegador Trust Wallet utilizavam, no caminho de execução WebAssembly, um algoritmo de rotação de Mason de 32 bits para gerar sementes aleatórias. Esses mnemônicos, aparentemente normais, derivavam todos de aproximadamente 4 bilhões de valores iniciais. O escopo do risco é claro: extensões de navegador das versões 0.0.172 a 0.0.182 que incorporavam o Trust Wallet Core anterior à versão 3.1.1. A Base de Dados Nacional de Vulnerabilidades dos EUA registrou que essa vulnerabilidade foi explorada em dezembro de 2022 e março de 2023.

O evento "Vulnerabilidade do Milk Sad" demonstra de forma clara os riscos similares. O comando bx seed do Libbitcoin Explorer 3.x utiliza um algoritmo Mersenne Twister de 32 bits semeado com base no tempo do sistema; sob condições de relógio idênticas, o software pode gerar exatamente a mesma frase mnemônica. Um atacante que tenha uma estimativa aproximada do momento de criação da semente terá um intervalo de busca muito menor do que o espaço aparentemente sugerido pela frase mnemônica.

Pesquisadores identificaram mais de 2.600 carteiras de Bitcoin ainda ativas dentro da faixa de risco; estimativas baseadas nos preços de agosto de 2023 indicam que os ativos roubados relacionados em várias cadeias públicas superam US$ 900.000. Mais de 2.550 dessas carteiras apresentam características de operações automatizadas, sugerindo fortemente que pertencem ao mesmo detentor. Os pesquisadores também apontaram que alguns incidentes de roubo de ativos podem ter envolvido outras vulnerabilidades de segurança.

Essas vulnerabilidades aparecem sempre com disfarces diferentes: o Coldcard acionou acidentalmente o algoritmo alternativo de aleatoriedade do firmware; a extensão de navegador Trust Wallet e a ferramenta de linha de comando Libbitcoin geraram números aleatórios fracos devido à dependência do relógio do sistema. As chaves da carteira geradas finalmente parecem impecáveis, mas o tamanho do conjunto de chaves acessíveis é tão pequeno que apresenta risco fatal.

A maioria das recomendações de armazenamento de Bitcoin disponíveis no mercado se concentra após a geração da seed: armazenar offline a frase de recuperação, usar suportes de backup duráveis, isolar permissões e testar o processo de recuperação. Essas medidas ainda possuem valor. Mas o acidente com o Coldcard nos lembra que as linhas de defesa de segurança precisam avançar um passo adiante.

O isolamento de ar só protege as chaves que você já inseriu no dispositivo. Por isso, a segurança da carteira de Bitcoin deve começar com uma fonte aleatória confiável.