O Ataque Que Nunca Tocou um Dispositivo

Em 30 de julho de 2026, cerca de 594 BTC saíram de aproximadamente 500 endereços Bitcoin single-sig em menos de meia hora. Até 2 de agosto, após uma terceira onda de ataque, os pesquisadores on-chain da Galaxy rastreavam 1.367 BTC, aproximadamente 88,6 milhões de dólares, drenados de 4.585 endereços. Todos os endereços afetados foram criados depois que o firmware vulnerável foi lançado em março de 2021, e todas as moedas roubadas seguem paradas, sem gasto, sob controle do atacante. No mesmo dia, a Coinkite publicou um aviso de segurança alertando que seeds geradas em dispositivos Coldcard Mk3 com firmware 4.0.1 a 5.0.3 podem estar em risco, e a equipe de engenharia da Block publicou uma análise independente de causa raiz.

A falha técnica já está bem documentada: uma verificação de macro em uma dependência do firmware desviou silenciosamente a geração de seeds para um fallback determinístico de software, em vez do gerador de números aleatórios de hardware. Seeds que deveriam carregar 128 bits de entropia tornaram-se computacionalmente enumeráveis. O atacante reconstruiu chaves privadas offline. Nenhum dispositivo foi tocado. Nenhum usuário caiu em phishing. Nenhum cofre foi violado.

A Coinkite respondeu com aviso, firmware de emergência e orientação de migração em questão de horas; em 31 de julho a empresa assumiu responsabilidade integral pela falha, e seu aviso atualizado estende o risco a seeds geradas em dispositivos Mk4, Mk5 e Q antes do firmware corrigido. Este texto não é sobre o fornecedor. É sobre o que a estrutura do incidente revela, porque a estrutura vai se repetir.

A falha morava no nascimento da chave, não no armazenamento

Todo framework de custódia que revisamos trata o armazenamento de chaves como o centro de gravidade: qual dispositivo, qual cofre, qual geografia. Este incidente não comprometeu nenhuma dessas camadas. As carteiras estavam frias. Os dispositivos estavam offline. As seeds nunca foram expostas.

A vulnerabilidade morava na proveniência da chave: a versão de firmware em execução no momento em que a seed foi gerada, anos antes do roubo. A exposição foi determinada por um evento no passado que a maioria dos detentores nunca registrou e não consegue reconstruir. Atualizar o firmware depois não repara nem enfraquece uma seed existente.

Esta é a primeira lição de governança. Proveniência de chave é metadado auditável: qual família de dispositivo, qual versão de firmware, qual método de geração, em qual data. Uma política de custódia que não registra proveniência não consegue responder à única pergunta que importava em 30 de julho: “esta seed foi gerada dentro da janela vulnerável?”

O que sobreviveu foi política, não hardware

Observe quem não teve moedas drenadas naquela madrugada. Segundo os avisos, detentores que aplicaram passphrase BIP-39 têm exposição limitada. Detentores que geraram entropia com dados físicos contornaram inteiramente o caminho de código vulnerável. E detentores cujos fundos estavam atrás de um quórum multisig que incluía ao menos um dispositivo de outro fornecedor estavam protegidos por construção: como observa a análise da Block, um quórum composto exclusivamente de dispositivos vulneráveis herda a vulnerabilidade, enquanto um quórum de dispositivos heterogêneos não herda.

Nenhuma dessas três coisas é propriedade de hardware. As três são decisões de política: um fator extra de entropia, uma fonte independente de entropia, e diversidade de fornecedor dentro do quórum. Os detentores que sobreviveram não escolheram um dispositivo melhor. Escolheram uma política que não dependia de nenhum dispositivo isolado estar correto.

Esta é a doutrina sobre a qual construímos: hardware falha em silêncio, política falha fazendo barulho. Uma política bem composta converte uma falha catastrófica de fornecedor único em um não-evento.

A lacuna de mensurabilidade

A frase mais desconfortável de todo o ciclo de divulgação é esta: não existe teste que o próprio detentor possa rodar contra a sua carteira para determinar se a sua seed está dentro do intervalo reproduzível. Os detentores afetados precisam assumir o pior em vez de verificar.

Essa é a crise real, e ela é maior do que qualquer bug de firmware isolado. A autocustódia, como praticada hoje, é imensurável. O detentor não consegue pontuar sua exposição à concentração de fornecedor, não consegue provar que sua política de herança sobrevive à perda de uma chave, e não consegue demonstrar ao cônjuge, ao herdeiro ou ao auditor que o arranjo funciona. Segurança que não pode ser medida só pode ser acreditada, e 30 de julho é a cara que a crença tem quando a premissa embaixo dela falha.

O que uma camada de governança faz com isso

Uma camada de governança acima do vault, que não guarda chaves e não favorece fornecedor, trata este incidente como uma classe de cenário, não como notícia:

Pontuação de composição de quórum. Quantos fornecedores distintos, linhagens de firmware e fontes de entropia participam da política de gastos? Um 2-de-3 sobre um único fornecedor está a uma falha de distância de um 0-de-3.

Proveniência de chave como metadado de primeira classe. Data de geração, família de dispositivo, versão de firmware e método de entropia registrados por chave, para que, quando o próximo aviso chegar, a exposição seja uma consulta, não um pânico.

Validação de política sob cenários de comprometimento. A pergunta “esta política continua satisfazível se toda chave do fornecedor X for presumida comprometida?” é uma pergunta determinística e respondível. Ela deveria ser respondida antes do aviso, não depois.

Nada disso exige confiar chaves a uma plataforma. Exige tratar custódia como um sistema governado com propriedades mensuráveis, em vez de uma coleção de dispositivos com reputações.

O padrão vai se repetir

Esta não é a primeira falha silenciosa de integridade de dispositivo na custódia de Bitcoin, e o histórico de divulgações da indústria de hardware wallets como um todo diz que não será a última. Os fornecedores não são o problema. Concentração é. Qualquer modelo de segurança cujo modo de falha é “o firmware de um fornecedor esteve errado por cinco anos” carrega um risco que nunca precificou.

Os detentores que estavam bem em 30 de julho estavam bem por uma razão que poderiam ter escrito de antemão. Esse é o padrão: governança de custódia significa conseguir escrever a razão antes do incidente, e prová-la depois.