Cartões "frios" (cold cards): após a vulnerabilidade relacionada às "seeds", é obrigatório inserir a chave 65 vezes... É essencial migrar as carteiras existentes

A CoinKite, fabricante de carteiras de hardware para Bitcoin, divulgou em 20 de agosto um novo firmware padrão para o Coldcard. Esta atualização tem como principal objetivo forçar o usuário a inserir manualmente uma fonte de aleatoriedade física durante o processo de geração da chave privada (seed). O usuário deve realizar uma das seguintes ações: inserir 65 ou mais caracteres aleatórios em intervalos imprevisíveis, lançar um dado de 6 faces 50 vezes, ou lançar uma moeda 128 vezes. Essa exigência visa reduzir o risco de depender exclusivamente do gerador de números aleatórios (RNG) da carteira. As versões afetadas são amplas. Para os modelos Mk2 e Mk3, o firmware deve ser a versão 4.0.1 a 4.1.9. Para os modelos Mk4 e Mk5, o firmware padrão deve ser inferior à versão 5.6.0, e para o modelo Edge, o firmware deve ser inferior à versão 6.6.0X. Para o modelo Q, o firmware padrão deve ser inferior à versão 1.5.0Q e o firmware Edge deve ser inferior à versão 6.6.0QX. Uma análise técnica independente da Block revelou que, para os modelos Mk2 e Mk3, a versão 4.0.0 também está vulnerável, alertando que os padrões de segurança estabelecidos pelo fabricante não são suficientes para garantir a segurança. A causa raiz desta vulnerabilidade reside no código de fallback do MicroPython. De acordo com a análise da Block, uma flag de função definida como "0" era interpretada como "existente", o que permitia que as solicitações de geração de números aleatórios fossem direcionadas para um processo determinístico de fallback. Isso resultava em uma grande vulnerabilidade de segurança, pois a chave privada poderia ser gerada sem a devida entropia externa. A imposição da entrada física visa limitar os danos caso a geração de números aleatórios do dispositivo falhe novamente, mas não pode ser aplicada retroativamente às chaves privadas já geradas. Esta atualização inclui também diversas outras melhorias de segurança, além da geração da chave privada. Ela integra revisões USB a verificações de checksum PSBT passo a passo, reexamina os bytes da transação antes da assinatura e bloqueia o modo SIGHASH_SINGLE por padrão. Também restringe o download USB aos resultados da sessão criptografada atual, adiciona a verificação do comprimento do arquivo de firmware, interrompe falhas persistentes do RNG e inclui uma função para verificar a conexão do RNG de hardware durante a inicialização. Existe uma exceção à obrigação de migração. Usuários que estavam utilizando o firmware vulnerável e lançaram um dado 50 ou mais vezes em condições justas, independentes e confidenciais podem ser isentos de realizar a migração. No entanto, se o número de lançamentos for insuficiente ou se o usuário não tiver certeza de que as condições foram atendidas, ele deve gerar uma nova chave privada e transferir seus fundos. O guia oficial da CoinKite recomenda seguir a seguinte ordem: gerar uma nova chave privada, fazer backup, verificar a impressão digital da carteira, verificar o endereço de recebimento no dispositivo, enviar uma pequena quantia de teste e, em seguida, transferir o saldo total. A duplicação ou restauração da carteira não são consideradas como a geração de uma nova chave privada. A CoinKite afirmou que alguns clientes sofreram perdas significativas e que as autoridades estão investigando o caso. No entanto, o número de vítimas confirmadas e o valor total das perdas não foram divulgados. Além disso, a empresa esclareceu que os itens de verificação atualmente disponíveis (revisão de código, testes de caminho RNG em dispositivos reais, builds reproduzíveis e rastreamento do caminho do dado) não constituem uma auditoria completa do binário modificado.