Segurança de carteira de hardware de bitcoin: lições da falha na geração da semente do Coldcard
2026/08/09 08:05:06
Bug na geração de seed do Coldcard expõe vulnerabilidade de segurança da carteira de bitcoin
Uma alteração de firmware em março de 2021 nos wallets de hardware Bitcoin Coldcard da Coinkite redirecionou a geração da seed longe do gerador de números aleatórios de hardware STM32 pretendido para um gerador pseudorrandômico de software determinístico. O erro permaneceu não detectado até o final de julho de 2026, quando atacantes esvaziaram mais de 1.000 endereços de bitcoin em ondas coordenadas, removendo aproximadamente 1.082 a 1.367 BTC, avaliados entre US$ 70 milhões e US$ 88 milhões na época. A Galaxy Research mapeou a primeira onda de 41 minutos que esvaziou 1.196 endereços em 30 de julho e posteriormente identificou ondas adicionais que ampliaram o total observado. A equipe de engenharia da Block e pesquisadores independentes rastrearam a causa raiz para uma verificação de macro do pré-processador que vinculou libngu ao fallback Yasmarang do MicroPython, que foi inicializado a partir do ID único do chip e dos registradores do temporizador, em vez de entropia fresca.
A Coinkite confirmou o problema nos modelos Mk2, Mk3, Mk4, Mk5 e Q, lançou um firmware de emergência no dia seguinte e instruiu os usuários a gerar novas sementes completamente novas, pois a atualização do firmware existente não consegue reparar uma frase de recuperação comprometida. O episódio renovou a análise sobre como as carteiras de hardware obtêm e verificam a entropia, os limites práticos da revisão de código aberto e os riscos residuais que persistem mesmo em dispositivos desconectados. A falha na geração de sementes da Coldcard demonstra que as carteiras de hardware permanecem dependentes da integração correta do firmware com as fontes de entropia; um único erro de configuração durando cinco anos pode reduzir a aleatoriedade efetiva muito abaixo do alvo de 128 bits de uma semente padrão BIP-39, permitindo a reconstrução offline das chaves privadas e roubos em larga escala que nenhuma quantidade de isolamento físico pode prevenir uma vez que a própria semente esteja fraca.
Como uma migração de firmware de 2021 desativou o RNG de hardware do Coldcard
Em março de 2021, a Coinkite migraram as operações de curva elíptica do Coldcard para a libsecp256k1 do Bitcoin Core e introduziram a biblioteca libngu MicroPython. O código de geração de seed passou da chamada específica da placa ckcc.rng_bytes, que corretamente invocava o gerador de números aleatórios verdadeiros por hardware do STM32, para ngu.random.bytes. A configuração da placa de produção definia MICROPY_HW_ENABLE_RNG como zero porque a Coinkite fornecia seu próprio wrapper de RNG por hardware. A verificação do pré-processador da libngu testava apenas se a macro estava definida, não se seu valor era diferente de zero. Como resultado, a compilação foi bem-sucedida e vinculou-se à fallback software Yasmarang do MicroPython. Essa fallback inicializou uma única vez, usando os 32 bits menos significativos do ID único do chip XORados com os registradores de tempo SysTick e RTC, e depois produziu um fluxo determinístico sem coleta adicional de entropia.
Em dispositivos Mk2 e Mk3 executando versões de 4.0.1 a 4.1.9, o caminho fornecido não oferecia praticamente nenhuma entropia criptográfica. Posteriormente, os firmwares Mk4, Mk5 e Q misturavam valores do elemento seguro, mas mantinham apenas quatro bytes após o hash e os utilizavam para reiniciar uma única palavra de estado de 32 bits, deixando aproximadamente 72 bits de entropia efetiva em vez dos 128 bits pretendidos. O código pretendido do RNG de hardware permaneceu presente no binário, mas nunca foi alcançado pelo caminho de geração da carteira. A revisão de código existente confirmou a presença da implementação TRNG, mas não verificou a resolução simbólica de ponta a ponta a partir do local da chamada de geração da semente. Portanto, o regresso permaneceu indetectado por mais de cinco anos até que a exploração ativa forçou a divulgação pública.
Efeito e Resultado
A consequência prática é que um atacante que consiga restringir ou obter o UID do dispositivo, o horário aproximado de inicialização e o histórico de chamadas anteriores ao RNG pode regenerar fluxos de saída candidatos offline. Cada candidato pode ser expandido em uma seed BIP-39, derivada em endereços e verificada contra a blockchain pública. Para os dispositivos Mk3 mais severamente afetados, a Coinkite estimou o espaço de busca efetivo em aproximadamente 40 bits; a análise da Block colocou limites condicionais bem abaixo dos níveis de segurança criptográfica para modelos posteriores.
Hashar a saída fraca ou aplicar o checksum do BIP-39 não pode aumentar o número de sementes possíveis. Uma vez que um endereço correspondente é encontrado, a chave privada correspondente controla cada derivação subsequente, permitindo o esvaziamento completo sem acesso físico ao dispositivo. A superfície de ataque segue, portanto, a frase de recuperação em si, e não o hardware que atualmente a contém. Restaurar uma semente afetada em firmware corrigido ou em qualquer outra carteira simplesmente transfere o mesmo segredo fraco.
Galaxy Research mapeia a varredura de 30 de julho e as ondas subsequentes
Em 30 de julho de 2026, um operador não identificado esvaziou 1.196 endereços de bitcoin em um período de 41 minutos, removendo 1.082,65 BTC avaliados em aproximadamente US$ 70,2 milhões. A Galaxy Research identificou o cluster por meio de uma taxa de taxa distinta de 30 sat/vB e a ausência de saídas de variação, padrões que se destacaram em relação à atividade on-chain normal. A empresa posteriormente documentou duas ondas adicionais que aumentaram o total acumulado observado para 1.367,05 BTC em 4.585 endereços, equivalente a aproximadamente US$ 88,6 milhões aos preços vigentes. A Galaxy alertou que heurísticas on-chain sozinhas não provam computacionalmente que todos os endereços originaram-se de entropia fraca do Coldcard, mas o agrupamento temporal e a ligação técnica fornecida pela análise de causa-raiz da Block tornaram a conexão altamente provável.
A empresa relatou aproximadamente 600 endereços suspeitos controlados por atacantes às autoridades e serviços de conformidade. Nenhuma reconstrução pública de uma seed específica de vítima foi publicada, mas a escala das transferências demonstrou que a entropia reduzida foi suficiente para enumeração offline prática uma vez que as restrições de estado do dispositivo necessárias foram conhecidas ou aproximadas. A velocidade da primeira onda sublinha que a vulnerabilidade não exigia interação em tempo real com as carteiras físicas. Uma vez que seeds candidatas pudessem ser geradas e validadas contra endereços conhecidos com fundos, o operador simplesmente assinou e transmitiu as transações.
Ondas subsequentes continuaram após o aviso da Coinkite, indicando que nem todos os detentores haviam concluído a migração. A Galaxy observou que o padrão de transação identifica mais o operador do que o roubo em si, pois um proprietário legítimo consolidando moedas pode produzir assinaturas on-chain idênticas. A ausência de atividade anterior compartilhando as mesmas características de taxa e variação nos trinta dias anteriores reforçou a atribuição a uma única campanha, e não ao comportamento orgânico dos usuários. O incidente, portanto, ilustra tanto o poder da análise de blockchain para detecção rápida quanto os limites dessas ferramentas quando a fraqueza criptográfica subjacente se origina off-line.
Resposta de Emergência e Correções de Firmware da Coinkite
A Coinkite emitiu seu primeiro aviso público em 31 de julho de 2026 e ampliou o escopo no dia seguinte após análise adicional. Versões corrigidas do firmware foram lançadas para cada modelo afetado: 4.2.0 para Mk2 e Mk3, 5.6.0 para Mk4 e Mk5 padrão, 1.5.0Q para Q padrão, e as respectivas versões Edge 6.6.0X e 6.6.0QX. A empresa interrompeu o envio de estoques vulneráveis e destruiu o estoque restante. As orientações oficiais enfatizaram que instalar o novo firmware não recupera uma seed existente; uma seed completamente nova deve ser gerada no dispositivo corrigido, e os fundos devem ser migrados após a verificação do novo backup e do endereço de recebimento.
A Coinkite estimou a entropia efetiva em aproximadamente 40 bits para as sementes Mk3 afetadas e cerca de 72 bits para as sementes Mk4, Mk5 e Q anteriores à correção. O aviso excluiu explicitamente as sementes criadas com pelo menos 50 rolagens justas, independentes e privadas de dados, pois a contribuição dos dados sozinha fornecia os 128 bits necessários e foi hashada junto com a saída do dispositivo. Senhas BIP-39 fortes e únicas foram reconhecidas como uma barreira adicional que impede um atacante que recupere apenas as palavras da semente de acessar os fundos, mas a empresa ainda recomendou a migração completa, pois a semente subjacente permanece fraca.
As instruções de migração enfatizaram a verificação sequencial e calma: confirme a versão fixa do firmware, gere a nova seed, registre e verifique o backup e a impressão digital, envie uma pequena transação de teste e, em seguida, transfira o restante, mantendo o backup antigo até a confirmação. Usuários cujo único dispositivo era um Mk2 ou Mk3 receberam um procedimento cuidadoso para um único dispositivo que alterna entre as seeds antigas e novas. A Coinkite também observou que os produtos TAPSIGNER, OPENDIME e SATSCARD utilizam bases de código separadas e permanecem inafetados. A resposta demonstrou tanto as vantagens de um modelo de firmware de código aberto que permitiu correções rápidas quanto a dificuldade prática de comunicar urgência a uma base de usuários dispersa que pode ter gerado seeds anos atrás e depois deixado os dispositivos off-line.
Estimativas de Entropia e Por Que 40 ou 72 Bits Não Atendem aos Objetivos do BIP-39
Uma seed BIP-39 padrão de 12 palavras é projetada para fornecer 128 bits de segurança. Quando a fonte de entropia subjacente cai para aproximadamente 40 bits em dispositivos Mk3 ou 72 bits em modelos posteriores, o espaço combinatório torna-se pesquisável com recursos computacionais modernos. A análise da Block mostrou que o fallback MicroPython Yasmarang, uma vez inicializado a partir de valores fixos ou restritos, produz um fluxo totalmente determinístico. Em dispositivos Mk4 e posteriores, a contribuição do elemento seguro é reduzida a um reseeding de 32 bits de uma única palavra de estado; as saídas subsequentes permanecem dentro de uma família de no máximo 2^32 fluxos para qualquer estado anterior e histórico de chamadas fixos.
A hash determinístico dessa saída não pode ampliar a família. Consequentemente, um atacante que obtenha ou aproxime os parâmetros de inicialização necessários pode enumerar candidatos offline, derivar os endereços correspondentes e compará-los com o conjunto público de UTXO. O custo é dominado pela derivação de endereços em vez de tentativas aleatórias puras, mas permanece viável na escala observada de roubos. Os números preliminares da Coinkite estão alinhados com avaliações independentes de que a entropia residual é insuficiente para auto-custódia de longo prazo de saldos significativos.
A lacuna não é teórica; as varreduras de 30 de julho e as ondas subsequentes forneceram confirmação empírica de que o espaço reduzido já estava sendo explorado. Mesmo a estimativa mais alta de 72 bits para modelos posteriores deixa uma margem muito abaixo do nível de segurança esperado por usuários que escolheram carteiras de hardware precisamente para evitar falhas de entropia de carteiras de software. Portanto, o episódio fornece um ponto de calibração concreto para o design futuro de carteiras de hardware: qualquer caminho que possa retornar silenciosamente a um PRNG de software semeado a partir de um estado de dispositivo não criptográfico deve ser rejeitado no momento da compilação, e não apenas revisado posteriormente.
Rolagens de dados e frases de passe como mitigações parciais
O parecer da Coinkite fez uma distinção clara para sementes que incorporaram pelo menos 50 rolagens de dados justas, independentes e privadas inseridas por meio da interface dedicada do dispositivo. Nesses casos, a entropia dos dados sozinha atingiu ou excedeu o alvo de 128 bits e foi combinada com a saída fraca do dispositivo antes de exibir as palavras finais da semente. Desde que as rolagens nunca tenham sido gravadas ou observadas, a semente resultante é considerada fora do escopo da falha no RNG. Menos de 50 rolagens ou qualquer incerteza sobre o número ou privacidade das rolagens retorna a semente à categoria de risco.
Uma frase-secreta BIP-39 forte e única cria uma carteira independente que não pode ser acessada apenas com as palavras-semente; um atacante também precisa recuperar a frase-secreta. Frases-secreta curtas, comuns ou reutilizadas não qualificam. Mesmo quando uma frase-secreta forte está presente, a Coinkite recomenda a migração eventual, pois a semente subjacente permanece criptograficamente fraca e a frase-secreta em si se torna um ponto único de falha caso seja exposta. Essas mitigações ilustram o valor das defesas em camadas, mas também sua incompletude. Lançamentos de dados exigem procedimentos físicos disciplinados que muitos usuários nunca realizaram.
Frases de acesso exigem backup cuidadoso e separado e recuperação exata; um único erro tipográfico gera uma carteira diferente e vazia. Nenhuma dessas medidas restaura a entropia que o firmware não forneceu, e nenhuma protege os recursos avançados do dispositivo que continuam dependendo do mesmo caminho enfraquecido de geração de números aleatórios. Usuários que confiaram exclusivamente na geração padrão de seed do dispositivo enfrentaram o impacto total do espaço de busca reduzido, enquanto aqueles que já haviam adotado entropia suplementar ou frases de acesso ganharam tempo, mas não segurança permanente.
Configurações de Multissignatura e os Limites do Risco Compartilhado
Quando todas as chaves de um quórum de assinatura múltipla forem geradas em um Coldcard afetado, toda a política torna-se passível de gasto por um atacante que recupere as sementes fracas. Um arranjo 2-de-3 no qual duas das três sementes originam-se de firmware vulnerável ainda permite que o atacante atinja o limiar uma vez que essas duas sementes sejam conhecidas. Apenas configurações que mantêm pelo menos uma chave externa forte fora do conjunto afetado preservam a segurança. Liana e outras carteiras baseadas em miniscript introduzem considerações adicionais de caminho: um caminho primário que pode ser satisfeito exclusivamente por chaves fracas do Coldcard é imediatamente passível de gasto, enquanto um caminho de recuperação bloqueado por um timelock permanece protegido apenas enquanto o bloqueio estiver ativo. Gastar uma carteira SegWit revela o descriptor completo na primeira transação, potencialmente permitindo a reconstrução de todos os endereços se todas as chaves forem fracas.
O Taproot limita a revelação ao caminho utilizado, reduzindo o raio de impacto, mas ainda expõe as chaves fracas que participam desse caminho. A lição prática é que a diversidade de hardware e fontes independentes de entropia permanecem essenciais mesmo dentro de esquemas de assinatura múltipla. Dependência de múltiplos dispositivos do mesmo modelo e geração de firmware concentra o risco em vez de distribuí-lo. Usuários que combinaram chaves do Coldcard com chaves de outros fornecedores ou com sementes geradas por dados mantiveram proteção parcial; aqueles que padronizaram uma única linha de produtos vulneráveis descobriram que o limiar de quórum não oferecia defesa alguma uma vez que a falha de entropia foi explorada. O incidente, portanto, reforça recomendações de longa data sobre fontes heterogêneas de chaves, demonstrando que essa recomendação não é meramente teórica.
Falhas na Revisão de Código Aberto e o Papel da IA na Descoberta
O firmware do Coldcard foi publicado por muito tempo sob uma licença de código aberto, permitindo inspeção independente. O erro de integração do RNG, no entanto, sobreviveu a múltiplos ciclos de lançamento e escrutínio externo. Análises existentes confirmaram que a implementação de RNG de hardware pretendida estava presente no binário, mas não verificaram se o ponto de chamada da geração da carteira realmente alcançava essa implementação em vez do fallback do MicroPython. A proteção do pré-processador usava #ifndef em vez de uma verificação de valor, permitindo que uma definição zero passasse silenciosamente. A Coinkite observou que até mesmo a revisão de código recente assistida por IA realizada pela própria empresa não detectou o problema, enquanto os atacantes ou os pesquisadores que primeiro identificaram a fraqueza podem ter se beneficiado de ferramentas semelhantes. O episódio, portanto, destaca uma lacuna persistente entre a presença do código-fonte e a verificação do comportamento em tempo de execução através de fronteiras de submódulos.
A latência de cinco anos também ilustra a dificuldade de detectar falhas silenciosas de entropia. Ao contrário de transbordamentos de buffer ou bugs de assinatura que produzem travamentos imediatos ou assinaturas inválidas, um PRNG fraco continua a gerar sementes que parecem plausíveis e passam nos testes internos de consistência. Apenas posteriormente, por enumeração offline contra a blockchain, a deficiência é revelada. Processos de revisão futuros precisarão de auditorias explícitas de entropia de ponta a ponta que forcem o sistema de compilação a rejeitar qualquer caminho de fallback e que midam a qualidade estatística da saída sob condições controladas. O código aberto permanece uma condição necessária para confiança, mas o caso Coldcard mostra que não é uma condição suficiente sem verificação direcionada dos caminhos de código mais críticos para segurança.
Praticidades da Migração e o Risco de Transferências Apressadas
A Coinkite enfatizou repetidamente que uma migração apressada pode criar novos vetores de perda que superam o risco original. Os usuários foram instruídos a verificar a versão fixa do firmware no dispositivo, gerar a nova seed somente após a atualização, registrar o backup e a impressão digital offline, confirmar um endereço de recebimento na tela do dispositivo e mover uma pequena quantia de teste antes da transferência do volume principal dos fundos. Proprietários de dispositivos únicos enfrentaram etapas adicionais de alternar entre as seeds antigas e novas, mantendo ambos os backups intactos até a confirmação final. Qualquer erro na ordem das operações, qualquer endereço digitado incorretamente ou qualquer destruição prematura do backup antigo poderia deixar permanentemente os coins bloqueados.
A empresa também alertou contra a restauração de uma semente afetada em um novo dispositivo ou carteira de software, pois a vulnerabilidade acompanha a própria frase. O volume de carteiras afetadas e as varreduras contínuas criaram pressão de tempo que entrou em conflito com a necessidade de procedimentos deliberados. Muitos detentores de longo prazo geraram sementes anos atrás, armazenaram os dispositivos off-line e mantiveram apenas cópias de papel. Reconstruir a versão exata do firmware em uso no momento da geração nem sempre foi straightforward. O aviso, portanto, equilibrou urgência e cautela, incentivando ação imediata para sementes não protegidas, enquanto insistia em etapas de verificação que evitam perdas autoinfligidas. A tensão entre velocidade e segurança permanece uma característica inerente a qualquer migração em larga escala de sementes e reaparecerá em futuros incidentes envolvendo carteiras de hardware.
Contexto da Indústria: Carteiras de Hardware Após o Incidente do Coldcard
A falha no Coldcard surge após episódios anteriores de baixa entropia em ambientes de software e hardware, incluindo a pesquisa Ill Bloom que vinculou um problema separado de PRNG em carteira de software a mais de US$ 5 milhões em perdas multi-cadeia. Carteiras de hardware foram amplamente comercializadas como a solução definitiva para falhas de entropia de software e malware. Os eventos de 2026 demonstram que o limite protetor é tão forte quanto o firmware que implementa o caminho de entropia. Concorrentes que dependem de elementos seguros diferentes, arquiteturas diferentes de números aleatórios ou processos de revisão diferentes não foram implicados, mas o mercado mais amplo agora deve enfrentar a possibilidade de que erros de integração semelhantes possam existir em outros lugares. A demanda por ferramentas independentes de medição de entropia, verificação formal de gráficos de chamadas RNG e interfaces padronizadas de rolagens de dados ou entropia externa provavelmente aumentará.
Defensores da autogestão enfrentam um desafio paralelo. O incidente já provocou discussão pública sobre se detentores de longo prazo devem considerar armazenamento diversificado, incluindo produtos regulamentados, para uma parte de seus ativos. Ao mesmo tempo, o lançamento rápido do firmware fixo e a transparência das divulgações técnicas reafirmam as vantagens dos ecossistemas de hardware aberto que conseguem responder em horas, e não em meses. O efeito líquido é uma calibração mais realista do risco, e não uma rejeição total das carteiras de hardware. Usuários que tratam o dispositivo como um componente dentro de um modelo de segurança em camadas, que inclui entropia externa, frases-passe e diversidade multisignature, mantêm uma proteção mais forte do que aqueles que consideram qualquer produto único como uma salvaguarda absoluta.
Lições para o design futuro de carteiras de hardware
Os sistemas de compilação devem exigir a presença de um RNG de hardware verificado nos locais exatos de chamada utilizados para geração de sementes; uma queda silenciosa para um PRNG de software semeado com metadados do dispositivo é inaceitável. Verificações do pré-processador devem testar o estado ativado dos recursos de entropia, e não meramente sua definição. As contribuições do elemento seguro devem preservar toda a entropia, em vez de serem truncadas para 32 bits antes de resemear uma máquina de estados fraca. Testes de ponta a ponta que medem a qualidade estatística das sementes geradas sob condições de inicialização realistas devem se tornar critérios padrão de lançamento.
A documentação deve deixar claro que a versão do firmware no momento da geração da seed, e não a versão atualmente instalada, determina a exposição. Por fim, as interfaces de usuário devem exibir o status da fonte de entropia e incentivar ou exigir dados adicionais de dados ou entropia externa para carteiras de alto valor. Essas alterações de design são incrementais, mas teriam evitado a regressão do Coldcard e reduziriam a probabilidade de falhas semelhantes em outros produtos.
Passos Práticos para Proprietários Atuais do Coldcard
Proprietários que geraram seeds no firmware Mk2 ou Mk3 versões 4.0.1–4.1.9, ou no Mk4, Mk5 ou Q firmware antes das versões corrigidas de 31 de julho, devem tratar os seeds como comprometidos, a menos que possam confirmar pelo menos 50 rolagens de dados privadas ou uma frase-passe única e forte. Instale o firmware corrigido apropriado nas páginas de download oficiais da Coinkite, gere um novo seed no dispositivo atualizado, verifique o backup e a impressão digital offline, confirme um endereço de recebimento na tela do dispositivo, envie uma pequena transação de teste e apenas então migre o saldo restante.
Mantenha o backup antigo até que a nova carteira mostre a quantia completa confirmada. Usuários que nunca geraram uma seed em um dispositivo afetado, mas que importaram uma seed afetada para outra carteira, ainda devem migrar, pois a fraqueza reside na frase. Participantes de multisignature devem avaliar cada chave independentemente, de acordo com seu dispositivo e firmware de geração. O aviso oficial e o fundamento técnico permanecem como referências autoritativas para instruções específicas do modelo.
Implicações mais amplas para as práticas de auto-custódia de bitcoin
O episódio do Coldcard reforça que a autogestão é um processo contínuo, e não uma única compra de hardware. A qualidade da entropia, a origem do firmware, a verificação do backup e a diversidade de chaves devem ser revisadas periodicamente. A análise on-chain pode detectar explorações em larga escala rapidamente, mas os detentores individuais ainda são responsáveis por monitorar canais oficiais e agir conforme os avisos. O mercado para auditorias de segurança independentes do firmware de carteiras de hardware provavelmente se expandirá, assim como a demanda por ferramentas que permitam aos usuários medir a entropia efetiva de suas próprias sementes sem expô-las.
Ao mesmo tempo, o incidente não invalida o valor central do armazenamento de chaves off-line; ele simplesmente demonstra que o limite off-line deve ser complementado por força criptográfica verificada no momento da geração da chave. Titulares que combinam hardware atualizado, entropia adicional, frases-passe e arranjos de assinatura múltipla continuam a controlar suas próprias chaves com um grau maior de segurança do que aqueles que dependem de uma única camada.
|
A KuCoin está celebrando seu 9º aniversário com uma campanha especial da plataforma cheia de recompensas exclusivas, atividades de negociação e ofertas por tempo limitado. Não perca a chance de participar e aproveitar os benefícios enquanto a exchange comemora nove anos de crescimento e inovação. Visite a página oficial da campanha agora:
|
Perguntas frequentes
Quais versões de firmware do Coldcard são afetadas pela falha na geração da seed?
Dispositivos Mk2 e Mk3 executando as versões 4.0.1 a 4.1.9, inclusive, geraram seeds com aproximadamente 40 bits de entropia efetiva. Dispositivos Mk4 e Mk5 antes da versão padrão 5.6.0 ou versão Edge 6.6.0X, e dispositivos Q antes da versão padrão 1.5.0Q ou versão Edge 6.6.0QX, produziram seeds com aproximadamente 72 bits de entropia. A exposição é determinada pela versão do firmware presente no momento em que a seed foi criada, não pela versão atualmente instalada. As versões corrigidas ajustam a geração de novas seeds, mas não conseguem reparar seeds fracas já existentes. As páginas oficiais de download listam as versões corrigidas para cada modelo e trilha de lançamento. Usuários que geraram seeds fora desses intervalos, ou aqueles que utilizaram pelo menos 50 rolagens de dados privadas, estão fora da categoria de risco principal.
Atualizar o firmware em um Coldcard existente protege uma seed já gerada?
Não. A vulnerabilidade reside na entropia usada para criar as palavras de seed. Instalar um firmware corrigido altera apenas o caminho de geração para futuras seeds. Restaurar uma frase de recuperação afetada em um firmware corrigido ou em qualquer outra carteira simplesmente transfere o mesmo segredo fraco adiante. A única remediação confiável é gerar uma nova seed completamente em um firmware corrigido e migrar os fundos após a verificação completa do novo backup e do endereço de recebimento. O aviso da Coinkite é explícito sobre esse ponto e fornece procedimentos passo a passo para migração em cenários de múltiplos dispositivos e de único dispositivo.
As sementes criadas com rolagens de dados ainda são seguras?
Sementes que incorporam pelo menos 50 rolagens justas, independentes e privadas de dados inseridas pela interface oficial do dispositivo recebem entropia suficiente apenas da contribuição dos dados. O dispositivo gera um hash dessas rolagens juntamente com sua própria saída (fraca), de modo que a semente final atinge ou excede o alvo de 128 bits, desde que as rolagens nunca tenham sido observadas ou registradas. Menos de 50 rolagens ou qualquer incerteza sobre o número ou privacidade das rolagens retorna a semente à categoria de risco. As rolagens de dados não protegem recursos avançados do dispositivo que continuam dependendo do mesmo caminho de números aleatórios, mas protegem as palavras da semente contra esta falha específica.
Como uma frase de passe BIP-39 altera o perfil de risco?
Uma frase de passe BIP-39 forte e única cria uma carteira separada que não pode ser derivada apenas das palavras da semente. Um atacante que recupera apenas a semente fraca ainda não pode acessar os fundos protegidos pela frase de passe sem também descobrir a frase de passe. Frases de passe curtas, comuns, padronizadas ou reutilizadas não oferecem proteção significativa. Mesmo com uma frase de passe forte, a Coinkite recomenda a migração eventual, pois a semente subjacente permanece criptograficamente deficiente e a própria frase de passe se torna um segredo crítico que deve ser backupado separadamente e nunca digitada em dispositivos não confiáveis. A frase de passe é independente do PIN do dispositivo.
O que os usuários de multisignatura devem fazer se algumas chaves vieram de Coldcards afetados?
Avalie cada chave de acordo com o dispositivo e a firmware que a geraram. Se o número de chaves afetadas atingir ou exceder o limiar de gasto de qualquer caminho, esse caminho está em risco imediato. Uma configuração 2-de-3 que inclua duas chaves Coldcard fracas pode ser gasta por um atacante que recupere essas duas sementes. Caminhos de recuperação protegidos por timelocks ativos permanecem mais seguros até que o bloqueio expire. Os usuários devem gerar chaves de substituição em firmware fixo ou em dispositivos não afetados, construir uma nova política de multisignature e migrar os fundos após verificar o novo descriptor e os endereços. Fontes de chaves heterogêneas reduzem a chance de uma única falha na firmware comprometer todo o quórum.
O ataque ainda está em andamento, e como os detentores podem monitorar novos saques?
A Galaxy Research observou múltiplas ondas após a varredura inicial de 30 de julho e relatou que a atividade continuou enquanto os usuários migravam. Padrões on-chain caracterizados por taxas de taxa específicas e comportamento de variação podem ser monitorados por exploradores públicos e serviços de análise, mas os detentores individuais não podem confiar exclusivamente na detecção após o fato. A proteção mais eficaz é a migração imediata de qualquer seed não protegida. Os canais oficiais da Coinkite e contas de pesquisa confiáveis permanecem como as principais fontes de atualizações sobre ondas adicionais ou agrupamentos de endereços recém-identificados.
Isenção de responsabilidade: Este conteúdo é apenas para fins informativos e não constitui aconselhamento financeiro. Investimentos em criptomoedas envolvem riscos. Faça sua própria pesquisa (DYOR).
Aviso legal: Esta página foi traduzida usando tecnologia de IA para sua conveniência. Para informações mais precisas, consulte a versão original em inglês.