Hack da Coldcard: O que os utilizadores de Bitcoin devem saber

O hack ao Coldcard diz respeito à geração vulnerável de sementes em determinado firmware de carteiras de hardware, e não a uma comprometimento do Bitcoin. A falha ocorreu enquanto alguns dispositivos Coldcard estavam a criar o segredo a partir do qual as chaves da carteira são derivadas. O protocolo, a blockchain e o sistema de assinaturas do Bitcoin continuaram a funcionar normalmente.

Perdas estimadas do Coldcard ao longo de 4 ondas de ataque. Da Galaxy Research e CoinDesk. 

Análises de blockchain disponíveis até 4 de agosto associaram 4 ondas suspeitas de varrimento a aproximadamente 1.815,75 BTC provenientes de 5.294 endereços potenciais. Com o preço do Bitcoin próximo de 63.789 dólares durante a verificação final, esse montante valia cerca de 115,8 milhões de dólares. A estimativa é provisória: não representa um total oficial de perdas, e os 5.294 endereços não correspondem a 5.294 vítimas confirmadas.

O incidente é invulgar porque a principal explicação técnica não exige que o atacante roube um dispositivo, obtenha uma frase de recuperação, infete o computador do utilizador ou viole os servidores da Coinkite. A aleatoriedade fraca terá reduzido o número de sementes plausíveis o suficiente para que os atacantes pudessem calcular candidatos offline, derivar os seus endereços e procurar correspondências no registo público do Bitcoin.

Esse mecanismo levanta uma questão difícil sobre a autogestão de Bitcoin. As carteiras de hardware continuam valiosas para isolar chaves e aprovar transações, mas essas proteções dependem de o segredo ser imprevisível quando inicialmente criado. O incidente testa, portanto, até que ponto os utilizadores ainda confiam no firmware, nos sistemas de compilação, na revisão de código e num único fabricante de carteiras.

Resumo do incidente

• Primeiro ataque observado: 30 de julho de 2026, aproximadamente entre 01:10:20 e 01:51:26 UTC.

• Última perda estimada: Cerca de 1.815,75 BTC provenientes de 5.294 endereços potenciais, com base na estimativa mais recente de 4 ondas disponível em 4 de agosto.

• Produtos afetados: Sementes geradas em firmwares específicos Mk2, Mk3, Mk4, Mk5 e Q, sujeitas às condições de dados e frase secreta indicadas no aviso da Coinkite.

• Falha técnica principal: A geração da semente recorreu a um substituto determinístico de números aleatórios por software em vez do caminho pretendido do RNG (gerador de números aleatórios) por hardware.

• Ação imediata do utilizador: Instale o firmware corrigido antes de criar uma nova semente completamente nova, verifique a carteira substituta e transfira os fundos com cuidado.

• Principal incerteza: Padrões na blockchain não conseguem confirmar que todos os endereços assinalados vieram do Coldcard nem indicar quantas pessoas únicas foram afetadas.

O que aconteceu no hack ao Coldcard?

A primeira grande varredura ocorreu em aproximadamente 41 minutos a 30 de julho. A Galaxy Research mapeou 1.196 endereços de origem que moveram um total combinado de 1.082,65 BTC durante essa janela. Um valor anterior de cerca de 594,5 BTC proveniente de aproximadamente 500 endereços representava apenas uma visão parcial do mesmo evento inicial, e não um montante separado a somar a ele.

Perdas cumulativas de Bitcoin associadas ao incidente Coldcard por nível de evidência até 3 de agosto de 2026. De Galaxy Research.

 As transações chamaram a atenção porque muitos endereços de origem partilhavam características consistentes com o padrão da carteira vulnerável. Os fundos foram transferidos de forma rápida e sistemática, sugerindo que chaves candidatas e endereços financiados tinham sido identificados antes do início da varredura. A blockchain mostra as transferências e a sua estrutura, mas não pode revelar por si só como cada chave privada foi obtida.

Novos agrupamentos surgiram após a primeira divulgação. A estimativa cumulativa aumentou para cerca de 1.158,7 BTC em 2.673 endereços potenciais de origem após uma segunda vaga suspeita, depois para 1.367,05 BTC em 4.585 endereços após uma terceira. Uma quarta vaga suspeita a 3 de agosto adicionou cerca de 448,7 BTC provenientes de 709 endereços potenciais de origem, resultando na atual estimativa aritmética de 1.815,75 BTC e 5.294 endereços, caso os grupos não se sobreponham.

A sequência principal foi:

• Março de 2021: Uma alteração na integração do firmware introduziu o caminho vulnerável de geração de semente.

• 30 de julho de 2026: Ocorreu a primeira grande varredura, e a Coinkite publicou um aviso e uma explicação técnica.

• 31 de julho – 2 de agosto: O firmware corrigido tornou-se disponível, o âmbito afetado alargou-se e foram identificadas novas vagas suspeitas de varredura.

• 3 de agosto: Uma quarta vaga compatível com o padrão elevou a estimativa observada acima dos 1.800 BTC.

• 4 de agosto: Não tinha sido confirmada nenhuma quinta vaga verificada, nem um número final de vítimas, programa de compensação ou anúncio de fundos recuperados.

O evento transformou-se numa questão de segurança de carteiras de hardware porque os roubos suspeitos tiveram origem em carteiras cujas chaves deveriam permanecer offline. O limite de segurança não foi ultrapassado através de extração remota convencional. Em vez disso, as evidências apontam para uma fraqueza numa fase anterior: a criação do segredo que o hardware foi então concebido para proteger.

Como funcionava a vulnerabilidade do Coldcard

Uma seed de carteira Bitcoin deve começar com entropia suficiente, ou seja, informação imprevisível usada para criar as palavras de recuperação e as chaves derivadas delas. Uma seed BIP-39 corretamente gerada com 12 palavras normalmente visa 128 bits de entropia. Esse espaço de busca é tão vasto que adivinhar a seed por força bruta não constitui um ataque prático.

O design pretendido do Coldcard obtinha aleatoriedade de fontes de hardware. Durante uma integração em 2021 envolvendo libNgU, contudo, a geração da carteira passou de ckcc.rng_bytes() para ngu.random.bytes(). Esse caminho levou a uma alternativa determinística dentro do MicroPython, em vez da implementação específica do hardware para números aleatórios esperada pelo código da carteira.

O erro persistiu porque ambas as implementações RNG expunham uma assinatura de função compatível. A implementação de hardware pretendida também estava presente no binário do firmware, o que tornava uma revisão limitada aparentemente tranquilizadora. O que não foi verificado foi a rota completa desde a função de geração da carteira até à implementação RNG que efetivamente forneceu a sua saída.

Uma verificação relacionada na compilação falhou por uma razão subtil. A macro relevante foi definida com valor zero, enquanto a proteção testava se a macro existia, e não se estava ativada. Assim, a compilação concluiu-se em vez de parar quando o objeto errado foi incluído.

A análise preliminar da Coinkite estima um espaço de busca efetivo de cerca de 40 bits para Mk2 e Mk3. Os modelos Mk4, Mk5 e Q incorporaram valores adicionais dos seus elementos seguros, aumentando a estimativa da empresa para cerca de 72 bits, ainda abaixo do alvo pretendido de 128 bits. Análises independentes examinaram limites estruturais mais restritos na construção dos modelos mais recentes, mas essas conclusões não devem ser simplificadas numa afirmação universal de que todas as seeds desses modelos tinham exatamente 32 bits de segurança total.

Da entropia fraca a uma transação não autorizada

A cadeia técnica pode ser explicada sem reproduzir um método de ataque:

1. O firmware selecionou um gerador determinístico de software em vez do caminho pretendido do RNG de hardware.

2. A seed resultante provinha de um conjunto efetivo muito menor de possibilidades.

3. Um atacante que compreendesse e restringisse suficientemente o processo defeituoso poderia calcular offline seeds e chaves candidatas.

4. Os endereços públicos derivados dessas candidatas poderiam ser comparados com endereços financiados visíveis na blockchain do Bitcoin.

5. Uma candidata correspondente forneceria a chave necessária para assinar uma transação a partir desse endereço.

Nesse modelo, não é necessário acesso físico porque o atacante não está a extrair uma chave da carteira. O atacante está a chegar independentemente à mesma chave. A rede Bitcoin não consegue distinguir a assinatura do proprietário legítimo de outra assinatura válida criada com uma chave privada derivada de forma idêntica.

Esta explicação é fortemente apoiada pelo histórico do firmware, pelo relato técnico da Coinkite, por análises independentes e pelos padrões observados nas transações. Continua sujeita a revisão caso uma análise post-mortem posterior altere a causa raiz, testes independentes rejeitem as estimativas de entropia ou trabalhos forenses demonstrem que uma parte significativa dos endereços suspeitos teve origem não relacionada.

Quais dispositivos Coldcard e seeds são afetados?

A exposição é determinada principalmente por onde e como a seed atual foi gerada, e não simplesmente pelo modelo que um utilizador possui atualmente. Um dispositivo com firmware corrigido pode ainda conter uma seed antiga vulnerável. Um dispositivo que já executou firmware afetado pode conter uma seed segura importada de outra fonte segura.

Standard e Edge são ramos distintos de firmware. Uma versão mais antiga do Edge não é segura apenas porque o seu número de versão parece superior ao de uma versão Standard. Os utilizadores precisam da versão corrigida correspondente ao modelo e ramo que realmente utilizam.

Uma seed vulnerável permanece vulnerável se for restaurada num Coldcard corrigido, importada para outra carteira de hardware ou introduzida em software de carteira compatível. Nenhuma dessas ações adiciona aleatoriedade às palavras originais. Em contraste, uma seed gerada de forma segura noutro local não é enfraquecida apenas por ter sido posteriormente importada para um Coldcard afetado; essa conclusão decorre do facto de a falha ter ocorrido durante o processo de geração da seed pelo Coldcard.

A Coinkite afirma que TAPSIGNER, OPENDIME e SATSCARD não foram afetados porque utilizam bases de código diferentes. Trata-se de uma declaração específica de produto, e não de evidência de que todas as funções ou propriedades de segurança desses produtos tenham sido submetidas a uma auditoria independente.

Quanto Bitcoin foi roubado?

 

Eventos conhecidos e suspeitos de roubo de Bitcoin associados ao Coldcard, por montante, data e nível de evidência, até 3 de agosto de 2026. Da Galaxy Research. 

A resposta mais defensável atualmente é uma estimativa, não um total definitivo. Em 4 de agosto, o cálculo mais recente com base em quatro ondas era aproximadamente 1.815,75 BTC, no valor de cerca de 115,8 milhões de dólares a um preço contemporâneo do Bitcoin próximo de 63.789 dólares. O valor combina as três primeiras ondas suspeitas com a estimativa da quarta onda e parte do princípio de que o conjunto mais recente de endereços não se sobrepõe aos agrupamentos anteriores.

Os números mudaram porque a investigação continuou a descobrir atividade adicional. Os relatórios iniciais capturaram apenas parte da primeira varredura, enquanto atualizações subsequentes adicionaram novas ondas e refinaram os filtros de endereços. Os valores em dólares também variaram porque o Bitcoin negociou entre aproximadamente 62.000 e 65.000 dólares durante o período de reporte.

Um endereço não é o mesmo que uma carteira ou uma pessoa. Um único utilizador pode controlar muitos endereços, uma seed pode derivar muitos endereços e um agrupamento forense pode incluir falsos positivos. Padrões na blockchain podem revelar sincronização coordenada, estrutura das transações, histórico da origem e comportamento do destino, mas não conseguem provar independentemente que todas as chaves de origem vieram de um Coldcard vulnerável.

O número de endereços deve, portanto, ser descrito como endereços fonte potenciais, e não como vítimas confirmadas. Nenhum total oficial de vítimas únicas, dispositivos, seeds ou utilizadores foi publicado até à data limite. Relatos individuais de vítimas podem corroborar a realidade do incidente, mas não estabelecem a sua escala total.

O total poderá aumentar sem uma nova vaga de ataques caso os investigadores identifiquem transações mais antigas ou recebam confirmações adicionais de vítimas. Também poderá diminuir se um conjunto de endereços se sobrepor a outro cluster ou se análises posteriores eliminarem falsos positivos. Uma estimativa com maior divulgação não deverá substituir a atual, a menos que a sua metodologia, o corte da blockchain e a ligação ao Coldcard possam ser verificados.

Porque atualizar o firmware não é suficiente

O firmware controla o que um dispositivo faz agora. Uma seed regista o resultado do que o dispositivo fez quando essa carteira foi criada. Assim que uma entropia insuficiente tiver gerado uma seed, uma atualização posterior do software não pode retroativamente expandir o conjunto do qual essa seed foi obtida.

O firmware corrigido resolve a geração futura ao excluir a alternativa indesejada por software e ao adicionar verificações em tempo de compilação em torno do símbolo RNG. Não altera as palavras de recuperação já anotadas, nem as chaves já derivadas delas, nem faz com que um atacante esqueça uma candidata capaz de as reproduzir.

Mover as mesmas palavras para um dispositivo diferente altera apenas a localização do armazenamento, não o segredo. Comprar outra carteira e restaurar a seed afetada produz a mesma carteira e as mesmas chaves. O princípio oficial de migração é, portanto: a correção repara o gerador, enquanto a seed afetada deve ser substituída.

Uma nova seed criada com o firmware corrigido gera uma carteira diferente. Os fundos só ficam protegidos pelo novo segredo após o endereço de recebimento ter sido verificado e os bitcoins terem sido transferidos para lá. Transações não autorizadas confirmadas não podem ser revertidas alterando o firmware ou restaurando um backup.

O que os utilizadores afetados do Coldcard devem fazer agora

A resposta adequada depende da origem da seed, do firmware utilizado na sua criação e de qualquer entropia independente ou proteção por frase-passe. Os utilizadores devem basear-se no aviso de segurança atual do Coldcard para procedimentos específicos do dispositivo e evitar improvisar sob pressão.

Uma sequência geral cuidadosa é:

1. Confirmar o modelo e o histórico do firmware. A versão atual não é suficiente; é necessário determinar qual firmware gerou a seed financiada.

2. Estabelecer a origem da seed. Identifique se foi gerado no Coldcard, restaurado a partir de outro Coldcard afetado ou importado de uma fonte independente.

3. Instale um firmware corrigido verificado. Utilize o canal oficial e a versão Standard ou Edge correta para o dispositivo antes de gerar uma substituição.

4. Gere uma seed completamente nova. Não reutilize, modifique ligeiramente nem reimporte as palavras de recuperação antigas como substituição.

5. Registe e verifique a nova cópia de segurança. Verifique cuidadosamente as palavras e as informações de recuperação antes de enviar fundos.

6. Verifique a impressão digital da carteira e o endereço de recebimento. Confirme ambos através do ecrã do dispositivo confiável, não apenas num computador ou telemóvel ligado.

7. Envie uma transação de teste pequena. Utilize um valor suficiente para confirmar o processo sem mover imediatamente todo o saldo.

8. Confirme o recebimento e o controlo. Verifique se a nova carteira mostra o pagamento de teste e pode ser restaurada ou acedida conforme pretendido.

9. Transfira o saldo restante. Transfira apenas após ter verificado o destino e o resultado do teste.

10. Mantenha a cópia de segurança antiga até à conclusão. Aposente-a apenas depois de todo o saldo ter chegado e a migração ter sido confirmada.

Os utilizadores que já instalaram o firmware corrigido mas mantiveram a seed antiga concluíram apenas a primeira parte. Os utilizadores que compraram uma nova carteira e restauraram as mesmas palavras não eliminaram a vulnerabilidade. O fator decisivo é se os fundos estão agora sob controlo de uma seed nova gerada através de um processo corrigido ou de outra forma independente.

O período de migração também cria um risco separado de engenharia social. Os atacantes podem explorar a urgência mesmo quando não conseguem calcular a seed de um utilizador.

• Não utilize ligações de firmware não solicitadas, ferramentas de migração ou serviços de recuperação.

• Nunca introduza palavras da seed, chaves privadas, frases-passe, sequências de dados ou PINs num site.

• Rejeite contas de suporte que peçam segredos ou solicitem aos utilizadores que assinem uma transação não verificada.

• Verifique a substituição da área de transferência, envenenamento de endereços e pequenas alterações num endereço de destino.

• Verifique o endereço no ecrã da carteira física e evite mover todo o saldo antes de um teste bem-sucedido.

A Coinkite também alerta contra pressa. Um utilizador que perca a nova cópia de segurança, selecione a ferramenta de rede errada, envie para um endereço não verificado ou manipule incorretamente uma frase-passe pode causar uma perda mais imediata do que a própria vulnerabilidade que está a tentar resolver.

Falharam o isolamento aéreo e os elementos seguros?

O isolamento físico (air-gapping) e os elementos seguros não impediram este incidente porque abordam partes diferentes do modelo de segurança. Um isolamento físico destina-se a reduzir a comunicação entre um dispositivo de assinatura e sistemas ligados à rede. Pode limitar a extração remota e ajudar a manter a assinatura de transações isolada, mas não avalia a qualidade da aleatoriedade utilizada na criação da carteira.

Um elemento seguro protege o material secreto armazenado contra certas técnicas físicas e eletrónicas de extração. Pode guardar fielmente uma chave que ainda seja demasiado previsível. Se outra parte derivar independentemente a mesma chave privada, não há necessidade de contornar o chip nem de recuperar dados do dispositivo.

Modelos posteriores do Coldcard misturaram valores adicionais provenientes de 2 elementos seguros no estado do software. A Coinkite afirma que isto aumentou o espaço efetivo estimado de pesquisa de cerca de 40 bits nos modelos Mk2/Mk3 para aproximadamente 72 bits nos modelos Mk4, Mk5 e Q. Esta entrada adicional reduziu a gravidade, mas não restabeleceu o objetivo pretendido de 128 bits.

A falha ocorreu antes do armazenamento e da assinatura. A função de geração da seed acedeu à fonte errada de aleatoriedade, após o que o dispositivo protegeu e utilizou a chave resultante conforme projetado. O armazenamento offline não pode corrigir um segredo fraco, tal como o isolamento físico não pode alterar a forma como esse segredo foi originalmente calculado.

Esta distinção preserva o valor da segurança em camadas, ao mesmo tempo que identifica os seus limites. Isolamento físico, elementos seguros, verificação de firmware, cópias de segurança e revisão de transações resolvem problemas diferentes. Nenhuma camada isolada pode compensar automaticamente quando a etapa fundamental de geração da chave é defeituosa.

O que o incidente revela sobre a geração da seed

A entropia da seed não é uma funcionalidade secundária. É o controlo que torna significativas todas as proteções subsequentes da carteira de hardware. Uma chave privada bem protegida continua vulnerável se o segredo original provier de um conjunto suficientemente pequeno para ser pesquisado por outra parte.

O erro na geração da seed do Coldcard mostra também por que motivo a revisão de software criptográfico envolve mais do que ler a função RNG pretendida. Os revisores precisam confirmar a configuração compilada, submódulos importados, resolução de símbolos, acessibilidade das chamadas, mistura de entropia, comportamento em caso de falha e binário final. Neste caso, a implementação de hardware esperada existia, mas o caminho de geração da carteira terá acedido a uma implementação diferente com a mesma interface.

A transparência do código-fonte ainda tem valor porque permite que investigadores independentes inspecionem alterações e contestem as conclusões de um fornecedor. Contudo, não prova que o código importante tenha sido revisto, que o código-fonte revisto corresponda a todas as compilações ou que os revisores tenham testado exatamente o caminho executado num dispositivo em produção. A visibilidade cria a possibilidade de verificação; por si só, não fornece essa verificação.

Os fabricantes continuam, portanto, a fazer parte do modelo de confiança. Os utilizadores dependem deles para projetar o caminho da entropia, configurar a compilação, testar lançamentos, divulgar falhas, assinar o firmware e manter instruções precisas de correção. Mesmo utilizadores tecnicamente avançados raramente recompilam todas as versões ou auditam uma pilha criptográfica incorporada antes de gerar uma carteira.

A lição prática é reduzir as consequências de uma falha oculta. Entropia independente, políticas de assinatura multi-fornecedor, monitorização em modo apenas leitura, recuperação testada e proveniência clara do firmware podem distribuir o risco. Cada medida também adiciona trabalho e possíveis erros, pelo que a arquitetura de segurança deve corresponder à capacidade do utilizador de a manter de forma fiável.

Significa a violação do Coldcard que a autoguarda é insegura?

O incidente não demonstra que a autoguarda de Bitcoin seja criptograficamente inviável. A rede Bitcoin não foi comprometida, as chaves corretamente geradas permanecem seguras segundo as premissas atuais e a vulnerabilidade estava ligada a uma implementação específica e ao histórico do firmware. A autoguarda continua a permitir que os utilizadores detenham e transfiram Bitcoin sem ceder o controlo unilateral a um intermediário financeiro.

Mostra, contudo, que a autoguarda não está isenta de confiança. Um utilizador de carteira de hardware pode controlar as chaves finais, mas ainda depende de componentes do dispositivo, firmware, bibliotecas, definições de compilação, revisões de segurança, documentação e canais de atualização. A frase “verifique, não confie” descreve um objetivo, mas a maioria dos utilizadores não consegue verificar pessoalmente todas as camadas necessárias para o alcançar.

A crítica mais forte é, portanto, prática e não filosófica. Uma pessoa pode seguir o processo normal de configuração, manter a carteira offline, proteger a cópia de segurança e ainda assim sofrer um defeito de geração ao nível do fabricante. Considerar esse resultado como erro do utilizador ignoraria o facto de que a geração segura de sementes por defeito é uma responsabilidade fundamental do produto.

A defesa mais forte da autoguarda é que o modelo pode ser tornado resiliente a falhas de componentes individuais. Uma chave criada através de entropia independente sólida não foi enfraquecida por este bug específico do Coldcard. Uma carteira multisignatura que exija uma segunda chave independente poderia permanecer segura mesmo que um dos signatários fosse previsível.

Diferentes modelos de custódia distribuem o risco de forma distinta:

• Autoguarda com assinatura única concentra os riscos de geração, cópia de segurança e autorização numa única chave.

• Multisignatura com múltiplos fornecedores reduz o risco associado a um único dispositivo, mas acrescenta complexidade na configuração, nos descritores, na sucessão e na recuperação.

• Custódia colaborativa pode adicionar controlos de recuperação e políticas, introduzindo simultaneamente dependência de provedores e considerações de privacidade.

• Custódia institucional ou em bolsa elimina a gestão pessoal da seed, mas acrescenta riscos relacionados com contraparte, acesso, questões legais e levantamento.

• Fundos cotados em Bitcoin oferecem exposição regulamentada ao preço, mas não proporcionam posse direta na cadeia nem controlo sobre transferências.

A vulnerabilidade do Coldcard não prova que uma bolsa ou fundo seja mais seguro para todos os utilizadores. Demonstra, contudo, que as decisões de autoguarda devem ter em conta riscos de implementação e operacionais, e não apenas riscos de hacking remoto e roubo físico.

Multisignatura, frases-passe e entropia gerada com dados

Controlos adicionais poderiam ter alterado o resultado para algumas carteiras, mas nenhum é isento de custos. A questão relevante é se um controlo adiciona uma barreira independente ou meramente repete a mesma dependência vulnerável.

Multisignatura com múltiplos fornecedores pode reduzir o risco de dispositivos correlacionados. Numa configuração 2-de-3, reconstruir uma chave gerada pelo Coldcard não é suficiente se uma segunda chave exigida tiver sido gerada de forma independente e permanecer segura. Uma configuração em que um número suficiente de chaves do quórum provenha do mesmo caminho vulnerável de geração poderá ainda estar exposta.

Uma frase-passe BIP-39 deriva uma carteira separada a partir da combinação da seed e da frase-passe. Assim, uma frase-passe forte, única e secreta pode constituir uma barreira independente: recuperar apenas a seed base fraca não revela a carteira protegida por frase-passe. A Coinkite continua a aconselhar os utilizadores afetados que utilizaram frases-passe a migrarem, pois a seed base permanece fraca, e uma frase-passe curta, padronizada, reutilizada, citada, exposta ou incerta poderá ser adivinhada.

O PIN do Coldcard não é uma frase-passe BIP-39. Um PIN controla o acesso local ao dispositivo físico e pode ativar comportamentos de segurança específicos do dispositivo. Contudo, não altera a carteira criptográfica derivada da seed, pelo que não impede um atacante que calcule a chave noutro local.

As orientações atuais da Coinkite sobre dados aplicam-se especificamente a esta questão de RNG:

• 50 a 98 lançamentos justos, independentes e privados adicionados durante a criação inicial da seed contribuíram com pelo menos 128 bits através da entrada de dados, segundo o cálculo do aviso.

• 99 ou mais desses lançamentos contribuíram aproximadamente com 256 bits.

• Menos de 50 lançamentos, contagens esquecidas, sequências expostas ou procedimentos incertos não se qualificam para a exceção.

Os lançamentos devem ter sido incorporados através do fluxo de trabalho original relevante, e a seed final financiada deve ser aquela produzida após a adição dos dados. Os utilizadores não devem assumir proteção se não puderem verificar essas condições. A sequência de dados constitui igualmente material secreto e não deve ser fotografada, digitalizada nem introduzida num serviço ligado à rede.

A partir do firmware Mk2/Mk3 4.2.0, a Coinkite documenta um caminho opcional de substituição exclusivamente com dados que exige pelo menos 99 lançamentos. Isto é diferente da exceção de 50 lançamentos para uma seed antiga criada com a função “Adicionar Lançamentos de Dados”. A geração normal de seeds em firmware corrigido é descrita como suficiente; os dados manuais são opcionais e acrescentam os seus próprios riscos de contagem, transcrição, cópia de segurança e privacidade.

Multisig, frases-passe e entropia independente podem reduzir um modo de falha ao mesmo tempo que aumentam a carga operacional. Uma frase-passe perdida, um descritor multisig incompleto, um signatário inacessível ou uma seed manual registada incorretamente podem bloquear permanentemente a recuperação. Mais controlos só são úteis quando o utilizador consegue documentá-los, testá-los e mantê-los.

Como o incidente afetou os mercados de Bitcoin e criptomoedas

A reação do mercado foi visível, mas difícil de isolar. O Bitcoin caiu para cerca de 62.800 dólares em 3 de agosto, à medida que as perdas relatadas com Coldcards aumentavam, e depois negociou próximo de 63.789 dólares durante a verificação em 4 de agosto. Uma movimentação desse tamanho pode refletir preocupações de segurança, mas não constitui evidência de que o incidente, por si só, tenha determinado o preço.

As comunicações da Reserva Federal, as alterações nas taxas do Tesouro, os desenvolvimentos geopolíticos, a participação mais ampla em criptoativos e notícias específicas de empresas sobre Bitcoin estiveram ativas no mesmo período. Esses fatores podem alterar o valor do dólar, as expectativas de liquidez e o apetite ao risco independentemente das manchetes sobre carteiras de hardware.

Os fluxos dos ETF norte-americanos de Bitcoin à vista também foram mistos, e não uniformemente defensivos. Os produtos registaram aproximadamente 233,1 milhões de dólares de entradas líquidas em 30 de julho, 265,4 milhões de dólares de saídas líquidas em 31 de julho e 170,1 milhões de dólares de entradas líquidas em 3 de agosto. Essa sequência não sustenta a afirmação simples de que os utilizadores do Coldcard abandonaram coletivamente a autoguarda em favor dos ETF.

As migrações urgentes provavelmente aumentaram alguma atividade na cadeia, mas uma transação que sai de uma carteira antiga não é automaticamente uma venda. Pode estar a ser transferida para um novo endereço de autoguarda, um guardião colaborativo ou uma exchange. Sem etiquetas fiáveis de destino e dados subsequentes de negociação, o volume de migração não pode ser convertido diretamente em pressão vendedora.

Não foi verificada nenhuma evidência clara e específica relativamente a entradas agregadas nas exchanges, liquidações de derivados ou uma alteração sustentada no financiamento e no interesse aberto. O impacto mais direto no mercado foi na confiança na implementação das carteiras físicas e no debate sobre custódia. A economia da rede e as regras monetárias do Bitcoin permaneceram inalteradas.

Uma reação de curto prazo poderá inverter-se se não surgirem novas ondas, os utilizadores concluírem as migrações e a estimativa de perdas se estabilizar. Poderá intensificar-se se for confirmado um novo cluster ou se o âmbito técnico final se alargar. Em qualquer dos casos, a liquidez macroeconómica e a posição geral do mercado poderão continuar a ser fatores determinantes do preço mais relevantes do que o incidente com as carteiras.

Será possível recuperar o Bitcoin roubado?

O registo público do Bitcoin permite aos investigadores acompanhar as transações após um roubo. Os analistas podem monitorizar endereços de destino conhecidos, identificar padrões de consolidação e sinalizar depósitos que cheguem a um serviço com registos de clientes ou capacidade de controlo de ativos. Essa transparência pode gerar pistas investigativas que não existiriam num sistema de pagamentos totalmente opaco.

Rastrear não é o mesmo que recuperar. Uma transação confirmada de Bitcoin é irreversível ao nível do protocolo, e um analista não pode mover moedas apenas por rotular um endereço. A recuperação normalmente exige que os fundos cheguem a um intermediário cooperante, uma ordem judicial contra uma parte identificável, o controlo das chaves relevantes ou a devolução voluntária.

A velocidade e a jurisdição complicam esse processo. Os fundos podem ser divididos entre vários endereços, transferidos através de múltiplos serviços ou movidos para entidades em países onde a coordenação jurídica é lenta. Mesmo um serviço conhecido poderá não conseguir congelar ativos que já tenham saído do seu controlo.

A Coinkite pediu aos utilizadores afetados que preservassem os seus dispositivos e afirmou que a sua equipa jurídica iria coordenar-se com as autoridades policiais em várias jurisdições, conforme necessário. Essa declaração indica preparação para uma possível investigação; não confirma um caso público identificado nem garante a recuperação dos ativos.

Em 4 de agosto, nenhum anúncio verificado estabeleceu que o Bitcoin associado ao Coldcard tivesse sido apreendido, bloqueado, devolvido ou recuperado. Os utilizadores também devem ter cuidado com burlões que prometem acesso a fundos roubados em troca de um pagamento antecipado ou de informações confidenciais da carteira.

Resposta da Coinkite e potenciais consequências legais

A Coinkite publicou o seu primeiro aviso de segurança e explicação técnica sobre o Coldcard em 30 de julho. Na revisão de 1 de agosto, já estava disponível firmware corrigido para todos os modelos afetados, tanto nas versões Standard como Edge. A empresa também esclareceu as condições relativas à geração com dados (dice-roll) e à frase-passe, alertou que as sementes antigas continuam expostas e forneceu orientações para migração.

A empresa interrompeu as remessas assim que confirmou a vulnerabilidade e afirmou ter destruído o inventário restante com firmware vulnerável. Trabalhou diretamente com os utilizadores, desculpou-se publicamente e prometeu uma análise técnica pós-incidente formal. A informação atual na loja indica que os modelos afetados adquiridos recentemente serão enviados com firmware corrigido, embora os dispositivos mais antigos ainda requeiram verificação e atualização pelo utilizador.

Várias questões importantes permanecem em aberto:

• A Coinkite não publicou um total oficial de perdas ou de vítimas únicas.

• Nenhum programa de reembolso, compensação, seguro ou reclamações formais tinha sido anunciado até à data limite.

• A análise técnica pós-incidente completa prometida ainda não tinha sido publicada.

• Nenhuma investigação policial identificada ou número de processo público tinha sido confirmado.

• Não tinha sido anunciada nenhuma atribuição verificada do atacante nem qualquer recuperação concluída.

As potenciais ações judiciais poderiam envolver negligência, defeitos do produto, garantias, falsas declarações, omissão de avisos ou violação de normas de proteção ao consumidor. Uma vulnerabilidade no firmware, por si só, não prova que tenha causado a perda de um utilizador específico. A relação de causalidade pode depender do modelo, do firmware usado na geração da semente, do uso de dados (dice), da robustez da frase-passe, da estrutura multisig, do histórico de cópias de segurança e se a semente foi exposta por outra via.

Os termos da Coinkite incluem isenções de garantia, limitações de danos, cláusulas de arbitragem em Ontário, um prazo de 1 ano para iniciar processos, uma renúncia a ações coletivas e disposições indicando que a lei aplicável é a de Ontário. Essas cláusulas podem criar obstáculos significativos, mas a sua aplicabilidade pode variar consoante a jurisdição, o canal de compra, a legislação de defesa do consumidor e o tipo de reclamação apresentada.

Advogados estavam a avaliar possíveis ações e a recolher informações junto dos utilizadores afetados, mas nenhum processo judicial foi confirmado até 4 de agosto. A formulação correta é que a Coinkite enfrenta potenciais reclamações legais, e não que a responsabilidade tenha sido estabelecida ou que exista uma ação coletiva em curso.

Lições para utilizadores de carteiras físicas

O incidente apoia uma lista de verificação de segurança mais precisa, em vez de uma única recomendação universal de custódia:

• Verifique a proveniência e a versão do firmware antes de gerar uma nova carteira, e não apenas após os fundos chegarem.

• Compreenda a origem da seed e registe qual dispositivo e versão a criaram.

• Teste a recuperação antes de colocar um saldo significativo atrás de uma nova configuração.

• Considere entropia independente apenas se o método puder ser executado e documentado com segurança.

• Avalie multisig com múltiplos fornecedores para saldos elevados quando a complexidade operacional for gerível.

• Utilize monitorização em modo "watch-only" para detetar transações inesperadas sem expor as chaves de assinatura.

• Faça cópias de segurança das seeds e das frases-passe separadamente e inclua necessidades de herança e recuperação no planeamento.

• Trate mensagens urgentes de migração como possíveis tentativas de phishing, mesmo quando o incidente subjacente for real.

Estas práticas abordam riscos distintos. Não tornam uma carteira imune a todas as falhas de implementação, cadeia de abastecimento, cópia de segurança, físicas ou humanas. O objetivo é reduzir pontos únicos de falha sem criar uma configuração demasiado complexa para que o proprietário consiga recuperá-la de forma fiável.

O que vigiar a seguir

Os próximos desenvolvimentos confirmados determinarão se o incidente permanece essencialmente uma história de migração de emergência ou se evolui para questões de responsabilização e recuperação.

• Uma quinta vaga de ataques ou um agrupamento revisto de 4 vagas com sobreposição removida.

• Novos movimentos a partir dos endereços de destino identificados ou entrada num serviço identificado.

• Um bloqueio, apreensão, devolução voluntária ou outra recuperação verificada.

• A revisão técnica formal da Coinkite e qualquer alteração ao âmbito afetado.

• Anúncios de compensação, seguro, reclamações, reembolso ou substituição de dispositivos.

• Uma ação nomeada por parte das autoridades policiais ou atribuição do ataque a um agente específico.

• Um processo judicial, arbitragem, procedimento regulatório ou ordem judicial apresentados.

• Correcções adicionais de firmware ou divulgações envolvendo outros segredos gerados ou produtos.

Cada valor de perda deve manter uma marca temporal. Um número maior de endereços não representa necessariamente uma nova vaga de roubo, e um novo valor em dólares pode refletir apenas uma alteração no preço do Bitcoin.

Leitura final

A violação do Coldcard foi uma falha na geração de semente no firmware afetado. O caminho incorreto de aleatoriedade terá reduzido o espaço efetivo da semente, permitindo que atacantes reconstruíssem chaves candidatas sem possuir os dispositivos dos utilizadores nem as frases de recuperação. O próprio Bitcoin não foi hackeado, e não há evidências de que os servidores da Coinkite ou os elementos seguros do Coldcard tenham sido diretamente comprometidos.

A ação mais urgente para um utilizador afetado ou incerto é consultar o aviso oficial em tempo real, instalar o firmware corrigido adequado, gerar uma semente completamente nova, verificar a carteira substituta e migrar com cuidado. Apenas atualizar não corrige uma semente fraca já existente, e restaurar as mesmas palavras noutro local mantém a exposição.

A autogestão continua tecnicamente viável, mas este incidente demonstra que depende de uma geração correta de chaves, implementações fiáveis, qualidade das revisões e um design operacional gerível. As questões por resolver mais importantes são quantos dos 5.294 endereços potenciais estavam realmente associados ao Coldcard, quantas pessoas únicas foram afetadas, se surgirão mais vagas e se algum Bitcoin roubado poderá ser recuperado.

Este artigo destina-se exclusivamente a fins informativos e educacionais. Não constitui aconselhamento financeiro, de investimento, jurídico, de cibersegurança ou comercial. O armazenamento de criptomoedas envolve riscos de custódia, software, operacionais e de segurança. Verifique sempre as instruções específicas do dispositivo através dos canais oficiais do fabricante e procure assistência qualificada sempre que necessário.