Por que o firmware imutável é um recurso de segurança

O firmware é o software fundamental embutido no chip de uma carteira de hardware. Ele governa todas as operações críticas: como as  chaves privadas são geradas, armazenadas e usadas para assinar transações. Como o firmware opera na camada mais profunda do dispositivo, com acesso direto ao elemento seguro onde as chaves privadas residem, sua integridade é essencial. Se o firmware for comprometido, as consequências são graves e muitas vezes irreversíveis.

Este artigo apresenta um exame abrangente das duas abordagens concorrentes de firmware em carteiras de hardware: atualizável e não atualizável (imutável). Ele explora vulnerabilidades documentadas, analisa métodos de ataque emergentes e responde diretamente a afirmações recentes do setor sobre as limitações do firmware imutável.

O que é firmware em carteiras de hardware?

O firmware é o software especializado de baixo nível embutido diretamente no chip de uma carteira de hardware. Ele funciona como o sistema operacional do dispositivo, embora seja muito mais restrito em escopo do que o software executado em um computador ou smartphone. O firmware controla todas as funções críticas de segurança: geração de chaves privadas, armazenamento de chaves, assinatura de transações e comunicação com aplicativos complementares.

Ao contrário de aplicativos comuns, o firmware é executado diretamente no hardware, dando-lhe acesso imediato ao elemento seguro — o chip resistente a adulterações onde as chaves privadas são mantidas. Essa posição especial reforça a importância da integridade do firmware. Se ele for comprometido, um invasor poderá obter acesso às informações mais sensíveis da carteira.

Os fabricantes de carteiras de hardware adotaram duas abordagens distintas para o gerenciamento de firmware:

• Firmware atualizável: O fabricante pode lançar novas versões de firmware que os usuários baixam e instalam em seus dispositivos. Este modelo é utilizado por carteiras como Ledger, Trezor e a maioria dos outros fabricantes importantes.

• Firmware imutável (não atualizável): O firmware é gravado no chip uma única vez durante a fabricação e não pode ser alterado posteriormente pelo fabricante, por agentes externos ou por qualquer outro meio. Este é o modelo utilizado pela Tangem.

À primeira vista, o firmware atualizável oferece vantagens claras: a capacidade de corrigir vulnerabilidades, introduzir novos recursos e se adaptar a ameaças. No entanto, o próprio mecanismo de atualização introduz riscos de segurança substanciais que superam suas vantagens.

Contra o que o firmware imutável foi projetado para proteger

Toda arquitetura de segurança começa com um modelo de ameaças: uma avaliação formal de quais ataques o sistema foi projetado para prevenir, quais riscos ele aceita e onde a responsabilidade é distribuída entre as diferentes camadas.
 

O firmware atualizável cria um canal persistente para a entrega de código a um dispositivo após sua venda. Embora esse canal seja destinado a melhorias legítimas, ele também representa uma superfície de ataque que permanece acessível a agentes maliciosos durante toda a vida útil do dispositivo.

O firmware não atualizável é a única abordagem amplamente aceita para dispositivos seguros operados por usuários finais. NÃO existem cartões bancários ou e-passaportes que permitam atualizações de firmware over-the-air em campo. O YubiKey, uma chave de segurança de hardware que fornece autenticação de dois fatores e multifator, também possui firmware imutável. Isso ocorre porque os riscos de segurança são sempre muito elevados.

Vamos discutir essas ameaças:

1. Ameaças internas

Qualquer organização capaz de enviar atualizações de firmware necessariamente emprega indivíduos que podem modificar o código que controla as chaves privadas dos usuários. Um agente interno malicioso — motivado por ganho financeiro, razões ideológicas ou coerção externa — poderia embutir uma backdoor ou vulnerabilidade em uma atualização.

O setor de cibersegurança em geral documentou um aumento consistente de incidentes originados internamente ao longo da última década. Em carteiras de hardware, onde um único caminho de código comprometido pode afetar milhões de dólares em fundos de usuários, esse risco é particularmente grave.

2. Engenharia social

A existência de um pipeline de atualização de firmware cria um alvo de alto valor para ataques de engenharia social. Adversários podem tentar manipular funcionários para modificar código, compartilhar credenciais de acesso ou aprovar mudanças maliciosas por meio de phishing, personificação ou cenários de emergência fabricados.

A ameaça escalou substancialmente: os ataques de phishing por voz com deepfake aumentaram mais de 1.600% no primeiro trimestre de 2025. Qualquer empresa que mantém um mecanismo de atualização precisa se defender continuamente contra essas táticas em evolução.

3. Coerção governamental e pressão regulatória

Em certas jurisdições, a legislação permite que agências governamentais obriguem empresas de tecnologia a implementar capacidades de acesso remoto ou vigilância.

Se uma carteira de hardware suportar atualizações de firmware, um governo poderia exigir que o fabricante distribua uma atualização que conceda acesso backdoor aos fundos dos usuários.

Os funcionários também podem enfrentar pressão direta de agentes estatais, organizações criminosas ou órgãos reguladores. O mecanismo de atualização é o vetor habilitador para tal coerção. Sem ele, a exigência não pode ser cumprida.

4. Garantia de qualidade insuficiente

Nem todas as vulnerabilidades de firmware são introduzidas maliciosamente. Ciclos de desenvolvimento apressados, revisões de código incompletas e testes inadequados podem resultar em atualizações que inadvertidamente introduzem novas falhas de segurança.

Quando um fabricante lança atualizações com frequência — seja para correções menores, adições de recursos ou alterações de interface — a probabilidade de introduzir uma vulnerabilidade não intencional aumenta a cada lançamento.

5. Lacunas de auditoria

Uma auditoria de firmware é uma revisão abrangente do código-fonte, da arquitetura e das práticas de desenvolvimento conduzida por uma empresa de segurança independente de terceiros. Seu objetivo é verificar a ausência de backdoors, avaliar a qualidade das implementações criptográficas e verificar a conformidade com os padrões de segurança do setor.

Auditorias completas são caras e demoradas, muitas vezes custando centenas de milhares de dólares e exigindo vários meses para serem concluídas. Realizar uma auditoria independente para cada versão de firmware é economicamente e logisticamente impraticável para a maioria dos fabricantes.

6. Exposição da cadeia de suprimentos

O processo de atualização de firmware constitui uma cadeia de suprimentos complexa: o código é escrito, revisado, compilado, assinado criptograficamente, distribuído por servidores e instalado no dispositivo do usuário.

Cada etapa representa um ponto potencial de comprometimento. Os invasores podem atacar o ambiente de compilação, interceptar o canal de distribuição ou comprometer as chaves de assinatura usadas para validar a autenticidade das atualizações. Com envolvimento interno, um invasor poderia modificar a atualização durante o trânsito, entregando firmware comprometido que passa em todas as verificações de validação padrão.

7. Pressão sobre os usuários

Os fabricantes de carteiras atualizáveis frequentemente exigem atualizações para manter a compatibilidade com o software complementar. Os usuários que recusam podem ter funcionalidade reduzida ou perda de acesso a determinados recursos.

Essa dinâmica obriga os usuários a aceitar atualizações com base na confiança, independentemente de terem sido verificadas de forma independente. O firmware imutável elimina essa dependência. O dispositivo opera como entregue durante toda a sua vida útil, sem depender de futuras alterações de código.

Como os mecanismos de atualização criam uma superfície de ataque

O mecanismo que permite corrigir problemas de firmware é em si uma superfície de ataque que persiste durante toda a vida útil do dispositivo.

Para aceitar uma atualização de firmware, um dispositivo deve: 

• Receber código externo por um canal de comunicação (USB, Bluetooth),
   
• Validar a autenticidade do código usando assinaturas criptográficas;
   
• Gravar o novo código na memória do elemento seguro e sobrescrever ou substituir o firmware existente. 

Se o protocolo de atualização for frágil, o canal de comunicação entre o aplicativo complementar e o bootloader do dispositivo poderá ser interceptado ou falsificado por meio de ataques man-in-the-middle na camada de transporte USB ou Bluetooth.

A verificação de assinatura pode ser contornada se as chaves de assinatura forem exfiltradas ou se a rotina de verificação for burlada por injeção de falhas — como glitching de tensão — durante a verificação. 

A própria operação de gravação é vulnerável a ataques de time-of-check-to-time-of-use (TOCTOU), nos quais o firmware validado é substituído por código malicioso entre a etapa de verificação e a gravação efetiva no flash.

Um dispositivo que não possui essas capacidades não apresenta tais superfícies de ataque.  

Riscos documentados do firmware atualizável

Vários incidentes bem documentados demonstraram como vulnerabilidades de firmware podem comprometer carteiras de hardware.

1. Vulnerabilidade de substituição de firmware MCU do Ledger Nano S (2018). 
   O pesquisador de segurança Saleem Rashid demonstrou que um invasor poderia  substituir o firmware do Ledger Nano S por uma versão maliciosa que exfiltraria chaves privadas. Ele conseguiu fazer o upload de firmware modificado para a carteira, que revelaria as chaves privadas do usuário na próxima vez que o dispositivo fosse utilizado. 
   Ele também afirmou ser possível fazer o upload do firmware remotamente, instalando malware no computador da vítima que a induziria a atualizar o firmware "defeituoso" da carteira. A Ledger lançou a atualização de firmware 1.4.1 para mitigar o problema.
    
2. Controvérsia do Ledger Recover (2023). 
   A versão de firmware 2.2.1 da Ledger introduziu um novo recurso de recuperação que permitia extrair dados da frase seed do Elemento Seguro e transmiti-los a terceiros. O lançamento do serviço revelou que o firmware da Ledger possui a capacidade técnica de extrair e transmitir material da frase seed. 
   
   Essa capacidade existe em todos os dispositivos que executam o firmware atualizado, independentemente de o usuário assinar o serviço. Os usuários apontaram que isso contradizia diretamente a declaração anterior da Ledger de que atualizações de firmware não podem extrair chaves privadas do Elemento Seguro.
    
3. Campanha de phishing de firmware do Blockstream Jade (2025). 
   A Blockstream emitiu um alerta de segurança urgente sobre uma campanha de phishing direcionada a proprietários da carteira de hardware Jade por meio de e-mails falsos de atualização de firmware. Os e-mails fraudulentos se disfarçavam como comunicações legítimas da Blockstream, instruindo os usuários a baixar atualizações de firmware clicando em links maliciosos. O firmware falso provavelmente redirecionava os fundos para endereços controlados pelo invasor após a instalação.
    
4. Ataques à cadeia de suprimentos contra carteiras Ledger Nano X. 
   O Kraken Security Labs identificou ataques que poderiam permitir que agentes maliciosos assumissem o controle de computadores conectados às carteiras Ledger Nano X e instalassem malware, potencialmente resultando na perda ou roubo dos fundos armazenados. Nesse cenário, o firmware do processador não seguro é modificado usando um protocolo de depuração para funcionar como um dispositivo de entrada — como um teclado — que pode então enviar pressionamentos de tecla maliciosos ao computador host do usuário. 
   
   O Ledger Nano X é fornecido com a funcionalidade de depuração ativada em seu processador não seguro, um recurso que é desativado assim que o primeiro "app" — como o app de Bitcoin — é instalado no dispositivo. No entanto, antes que qualquer app seja instalado, o dispositivo pode ser regravado com firmware malicioso 
   que pode comprometer o computador host, de forma semelhante aos ataques "BadUSB" e "Rubber Ducky".

Dark Skippy: um estudo de caso em ataques baseados em firmware

Divulgado em agosto de 2024, o ataque Dark Skippy representa uma das ameaças baseadas em firmware tecnicamente mais sofisticadas identificadas até o momento. Ele demonstra a gravidade do risco que o firmware comprometido representa para os usuários de carteiras de hardware.

Visão geral técnica

O Dark Skippy tem como alvo o processo de geração de nonce usado durante a assinatura criptográfica de transações. Em operação normal, uma carteira de hardware gera um número aleatório (nonce) cada vez que assina uma transação. Essa aleatoriedade é essencial para a segurança do esquema de assinatura. O ataque ocorre em quatro etapas:

1. Comprometimento do firmware: O firmware malicioso é instalado na carteira de hardware por meio de uma atualização adulterada, um ataque à cadeia de suprimentos ou acesso físico.

2. Manipulação de nonce: Em vez de gerar nonces aleatórios, o firmware comprometido produz nonces fracos e determinísticos derivados de partes da frase seed do usuário.

3. Exfiltração de dados: Quando o usuário assina uma transação, fragmentos da frase seed são embutidos na assinatura da transação e transmitidos para a blockchain.

4. Reconstrução da seed: O invasor monitora a blockchain em busca de assinaturas afetadas e aplica o algoritmo Canguru de Pollard para computar a frase seed original a partir dos dados de nonce públicos.

Implicações

Variantes anteriores de ataques de exfiltração baseados em nonce exigiam dezenas de transações assinadas para extrair dados suficientes. O Dark Skippy pode extrair a frase seed completa de apenas 2 transações. Um único uso de um dispositivo comprometido é suficiente para esvaziar a carteira por completo.
 

O ataque também é excepcionalmente difícil de detectar. As assinaturas comprometidas são indistinguíveis das legítimas para o usuário. Nenhuma mensagem de erro, nenhuma anomalia visual e nenhum indicador comportamental alerta o usuário sobre a violação. A extração ocorre silenciosamente, e as vítimas podem não descobrir o comprometimento até que seus fundos tenham sido transferidos.
 

Os pesquisadores responsáveis pela divulgação (Lloyd Fournier e Nick Farrow da Frostsnap, e Robin Linus da ZeroSync) notificaram privadamente mais de 15 fornecedores de carteiras de hardware em março de 2024 antes de publicar suas descobertas. Até o momento desta publicação, o Dark Skippy não foi observado em uso real, mas a prova de conceito é totalmente funcional, e o código de demonstração foi disponibilizado publicamente.

O argumento contra o firmware de código aberto

A divulgação de código aberto torna o código-fonte disponível publicamente, permitindo que mais pessoas encontrem bugs. Isso trouxe benefícios de segurança em sistemas operacionais, bibliotecas criptográficas e protocolos de rede.

No entanto, a revisão de código aberto é voluntária, não estruturada e não oferece cobertura garantida. Não há exigência de que nenhum revisor específico examine nenhum caminho de código específico. 
 

Projetos de código aberto de alto perfil abrigaram vulnerabilidades críticas por anos (o Heartbleed no OpenSSL persistiu por mais de dois anos em código amplamente revisado). A mera disponibilidade do código-fonte não garante que ele tenha sido revisado de forma competente, nem que os revisores possuam a expertise especializada necessária para firmware de elemento seguro.

Além disso, publicar o código-fonte do firmware de carteiras de hardware introduz seus próprios riscos. Ele fornece aos adversários um mapa detalhado dos componentes internos do sistema, potencialmente habilitando ataques direcionados contra comportamentos específicos da implementação. 

É por isso que a Tangem emprega uma abordagem de segurança em profundidade: o firmware é de código fechado, mas formalmente avaliado por especialistas credenciados, enquanto o aplicativo complementar e o SDK são totalmente de código aberto no GitHub.

A arquitetura de firmware imutável da Tangem

Na Tangem, o firmware é carregado no elemento seguro durante a fabricação e não pode ser modificado ou substituído posteriormente. Não há mecanismo de atualização, nenhuma interface USB para gravação de firmware e nenhum canal sem fio para atualizações over-the-air. O elemento seguro é arquitetonicamente projetado para rejeitar qualquer tentativa de gravar novo código após a instalação inicial.

Respondendo às afirmações da Ledger

A Ledger comentou publicamente sobre a Tangem várias vezes, e sua própria equipe de pesquisa de segurança conduziu pesquisas extensas sobre nós. Esse contexto vale a pena ter em mente ao respondermos às afirmações que circulam sobre a Tangem.
 

Afirmação: "Congelar o sistema não protege os usuários, protege o invasor."

Esta declaração sugere que a imutabilidade é meramente inação, fazendo parecer que um sistema estático pode ser menos seguro; na verdade, é a abordagem comum. Como mencionamos anteriormente, seus cartões de crédito, passaportes e YubiKeys carregam todos firmware imutável. Um sistema imutável corta a ferramenta remota mais poderosa do invasor: injetar código malicioso por meio de atualizações. 

A abordagem da Ledger é bastante incomum e arriscada; cada atualização de firmware emitida oferece ao invasor uma nova oportunidade.
 

Afirmação: "As lacunas de auditoria da Tangem deixam períodos de vários anos sem escrutínio externo."

A Ledger argumentou que as duas auditorias da Tangem (2018 pela Kudelski e 2023 pela Riscure) deixam lacunas onde o escrutínio externo está ausente. Este argumento de lacuna de auditoria tem menos força contra firmware imutável do que contra firmware atualizável. Quando o firmware muda entre auditorias, o período não auditado envolve a execução de código novo e não revisado. Quando o firmware é imutável, o período não auditado envolve a execução do mesmo código que foi revisado anteriormente.
 

Afirmação: "A Tangem não consegue se adaptar a novas curvas criptográficas ou protocolos de blockchain."

Anteriormente, a Ledger argumentou que o firmware imutável não consegue suportar novas curvas criptográficas, potencialmente levando à obsolescência. No entanto, isso confunde duas camadas arquiteturais.

O firmware da Tangem implementa primitivas criptográficas fundamentais (ECDSA e EdDSA) usadas pela esmagadora maioria das redes blockchain. 

O suporte a novas blockchains, padrões de tokens e protocolos é implementado no aplicativo complementar na camada de aplicação, não no firmware. A Tangem atualmente suporta mais de 85 blockchains e mais de 16.000 tokens, e continua adicionando novas redes por meio de atualizações do aplicativo sem modificar o firmware do cartão. 

Afirmação: "Qualquer problema encontrado no Firmware da Tangem não pode ser corrigido."

O risco representado por uma vulnerabilidade não corrigida em firmware imutável deve ser ponderado contra os riscos introduzidos pelo próprio mecanismo de atualização. Como demonstrado ao longo deste artigo, o pipeline de atualização introduz ameaças persistentes.
A questão relevante não é se o firmware imutável está livre de compromissos, mas se a postura de segurança líquida é superior. As evidências apoiam fortemente essa conclusão.

Linha do tempo de auditorias independentes

A transparência sobre a avaliação de segurança é essencial para a confiança dos usuários. O histórico completo de auditorias independentes da Tangem comprova nosso compromisso com avaliações futuras.
 

Perguntas frequentes

O que acontece se uma vulnerabilidade for descoberta no firmware imutável da Tangem?

É um cenário muito improvável. O firmware da Tangem foi auditado de forma independente por duas empresas de segurança líderes (Kudelski Security e Riscure), reduzindo significativamente a probabilidade de uma falha crítica não detectada.

Um invasor pode instalar firmware malicioso em um cartão Tangem?

Não. O chip do elemento seguro é arquitetonicamente projetado para rejeitar qualquer operação de gravação de firmware após a instalação inicial na fábrica. Não há interface ou mecanismo para entrega de novo código. Mesmo com posse física do cartão, um invasor não pode modificar o firmware.

O que é o Dark Skippy e ele afeta a Tangem?

O Dark Skippy é um método de ataque baseado em firmware divulgado em 2024 que pode extrair a frase seed completa de uma carteira a partir de apenas duas transações assinadas. Ele funciona substituindo nonces aleatórios no processo de assinatura por valores determinísticos derivados da seed.
O Dark Skippy requer que firmware malicioso esteja presente no dispositivo. O firmware da Tangem é imutável e não pode ser alterado após a fabricação, portanto esse vetor de ataque não se aplica.

O firmware imutável é simplesmente uma forma de evitar a complexidade das atualizações?

Não. É uma decisão deliberada de arquitetura de segurança que elimina categorias inteiras de risco: ameaças internas, engenharia social, coerção regulatória, ataques à cadeia de suprimentos e a lacuna de auditoria inerente a lançamentos frequentes de firmware.

Existem limitações no firmware imutável?

O principal compromisso é que novas funcionalidades não podem ser adicionadas ao firmware após a produção. No entanto, a maioria das melhorias de recursos, suporte a novas blockchains e aprimoramentos de experiência do usuário são entregues por meio do aplicativo móvel complementar da Tangem, que é atualizado regularmente e totalmente de código aberto.

O que significa a certificação EAL6+?

EAL6+ (Nível de Garantia de Avaliação 6, aumentado) é uma das mais altas certificações de segurança disponíveis sob o padrão internacional Common Criteria (ISO/IEC 15408). 
Significa que o chip foi semi-formalmente verificado e rigorosamente testado contra ataques físicos e de canal lateral sofisticados. O mesmo nível de certificação é exigido para passaportes internacionais, documentos de identidade nacionais e sistemas de pagamento governamentais de alta segurança. Uma visão geral detalhada da arquitetura de segurança da Tangem está disponível na  documentação de recursos de segurança.

Por que o firmware da Tangem é de código fechado se o aplicativo é de código aberto?

O firmware é executado dentro de um elemento seguro certificado e realiza um conjunto restrito de operações criptográficas. O aplicativo complementar, que lida com a funcionalidade voltada ao usuário e interage com blockchains, se beneficia de um amplo escrutínio da comunidade e é totalmente de código aberto no GitHub. Essa abordagem em camadas adapta o método de verificação ao perfil de risco de cada componente.

Referências

• Divulgação Oficial do Dark Skippy — O artigo de pesquisa original e FAQ técnico dos pesquisadores de segurança que identificaram o ataque. darkskippy.com
   
• Merkle Science: Análise de Ameaça do Dark Skippy — Análise técnica detalhada do vetor de ataque Dark Skippy e suas implicações para a segurança de carteiras de hardware. www.merklescience.com
   
• Portal Common Criteria (ISO/IEC 15408) — O padrão internacional que governa a certificação de segurança EAL para componentes de hardware, incluindo elementos seguros. www.commoncriteriaportal.org
   
• Cointelegraph: O Risco Oculto do Firmware Atualizável — Cobertura do setor sobre as implicações de segurança dos mecanismos de atualização de firmware em carteiras de hardware. cointelegraph.com
   
• CryptoSlate: Cobertura Técnica do Dark Skippy — Cobertura técnica sobre a prova de conceito do Dark Skippy e sua linha do tempo de divulgação. cryptoslate.com
   
• Saleem Rashid: Quebrando o Modelo de Segurança da Ledger — Pesquisa original de 2018 demonstrando a substituição de firmware MCU no Ledger Nano S. saleemrashid.com