Por que o secure element não é um ponto único de confiança

O primeiro artigo da série sobre secure element explicou o que é um secure element. O segundo mostrou quais tipos de ataques ele consegue bloquear e quais não. Este artigo propõe outra questão: mesmo que o chip seja perfeitamente seguro, isso é suficiente?
 

  The short answer is no. And the reason has nothing to do with the chip's engineering. Most successful attacks against hardware wallet users do not break the secure element. They don't need to. They exploit the layers around it, the seed phrase written on a piece of paper, the firmware that tells the chip what to do, and the PIN that controls access to the device. The secure element can be technically impenetrable while the wallet it lives inside is thoroughly compromised.
 

Isso mostra que a segurança de uma carteira é um sistema, não apenas um chip. O secure element é o componente mais forte desse sistema, sua defesa mais interna. Mas é apenas uma parte. Considerar que ele resolve tudo é um equívoco que os atacantes sabem explorar.

Um castelo medieval não era só o torreão. Era um sistema de defesas em camadas: fosso, muralhas externas, muralhas internas, portão e, no centro, o torreão. Cada camada tinha uma função e barrava tipos diferentes de invasores. Vencer uma camada não encerrava a batalha; só aproximava o atacante da próxima. O torreão era o ponto mais protegido, mas um castelo com muralhas externas abandonadas não era bem defendido, por mais forte que fosse o torreão.

Primeira camada: integridade do firmware e secure boot

O secure element armazena e protege a chave privada. Mas ele não decide sozinho o que fazer com essa chave. Ele recebe instruções. E essas instruções vêm do firmware do dispositivo, o código que roda no processador principal da hardware wallet e define seu funcionamento.

Isso levanta uma questão importante: como saber se o firmware que envia comandos ao secure element é realmente o do fabricante e não algo adulterado?
 

O que significa integridade do firmware

Integridade do firmware é a garantia de que o código rodando no seu dispositivo é exatamente o que o fabricante forneceu, sem modificações, sem comprometimento, autêntico. Na hardware wallet, o firmware controla tudo que você vê: como o dispositivo responde, como as transações são montadas e apresentadas para assinatura.

Se um atacante consegue substituir ou modificar o firmware, ele ganha muito poder. Um firmware malicioso pode exibir um endereço diferente na tela do que o que está sendo realmente assinado. Pode alterar valores de transações sem ser percebido. Pode manipular a interface para capturar o PIN. Em algumas arquiteturas, pode criar condições que facilitam burlar as proteções do secure element. Nenhum desses ataques exige quebrar o secure element. Eles funcionam controlando o que é enviado para ele e o que aparece na tela.

Secure boot

A principal defesa técnica contra adulteração do firmware é o secure boot, um processo que verifica a assinatura criptográfica do firmware antes de permitir que ele rode. O fabricante detém a chave privada de assinatura. Todo firmware legítimo é assinado com essa chave. Ao ligar, o dispositivo confere o firmware com a chave pública do fabricante. Se a assinatura não bater — porque o firmware foi modificado, substituído ou corrompido — o dispositivo se recusa a iniciar.

É uma defesa relevante, mas com limites. O secure boot garante que só firmware assinado pelo fabricante rode. Não garante que a infraestrutura de assinatura do fabricante nunca foi comprometida, que o firmware não tenha bugs exploráveis ou que uma atualização futura não traga vulnerabilidades. Esses são riscos residuais, reais, mas geralmente pequenos para fabricantes de reputação e boas práticas de segurança.

O que essa camada não cobre

O secure boot não protege contra falhas em firmwares legítimos e devidamente assinados. Um bug no firmware genuíno, mesmo que acidental, pode criar uma vulnerabilidade explorável. Por isso é importante manter o firmware atualizado: atualizações corrigem falhas conhecidas, mas também exigem confiar em cada nova versão que chega.

Fabricantes de hardware wallets de confiança publicam changelogs do firmware, tornam o firmware imutável, exigem revisão independente e, em alguns casos, permitem que o usuário confira o hash do firmware antes da instalação.
 

Segunda camada: PIN e controle de acesso

Se o firmware é legítimo e o secure element está íntegro, a próxima camada de proteção é o controle de acesso: quem pode usar este dispositivo?

Hardware wallets normalmente exigem um PIN, um código numérico digitado no próprio dispositivo, antes de responder a qualquer comando. O PIN impede que alguém que tenha acesso físico ao seu dispositivo simplesmente o utilize. Sem o PIN correto, o dispositivo não assina transações, não exibe endereços e não libera nenhuma função.

Como o PIN funciona junto ao secure element

O PIN é verificado pelo próprio secure element, não pelo processador geral do dispositivo. Esse é um detalhe arquitetural importante. Se a verificação do PIN fosse feita em software no processador principal, um atacante que conseguisse rodar código arbitrário ali poderia burlar a checagem. Quando a verificação ocorre dentro do secure element, ela está sujeita às mesmas proteções de resistência a violação do armazenamento da chave.

A maioria das hardware wallets certificadas implementa um contador de tentativas de PIN também dentro do secure element. Após um número definido de tentativas erradas — normalmente de três a dez — o dispositivo se apaga, trava permanentemente ou, no caso da Tangem, aumenta o tempo de bloqueio. Isso impede ataques de força bruta: mesmo um PIN de quatro dígitos, com 10 tentativas possíveis, exigiria um golpe de sorte estatisticamente impossível para ser descoberto ao acaso.

Quando o PIN é uma proteção forte

Contra furtos oportunistas, alguém que encontra ou rouba seu dispositivo e não sabe o PIN, a combinação de verificação de PIN no próprio aparelho e limite de tentativas é extremamente eficaz. O atacante enfrenta um dispositivo bloqueado, que se autodestrói antes que ele possa adivinhar o código. É o portão cumprindo seu papel.

Quando o PIN é uma proteção fraca

O PIN protege o dispositivo contra uso não autorizado. Não protege a seed phrase. São camadas separadas do castelo, que defendem coisas diferentes.

Se alguém rouba seu dispositivo e a seed phrase anotada no mesmo roubo, o PIN é irrelevante. Não precisam do dispositivo; podem restaurar sua carteira em qualquer wallet compatível usando a seed phrase. O portão foi completamente contornado.

A segurança do PIN também depende de ele não ser observado. Um PIN digitado em local público, filmado ou visto por alguém próximo já está comprometido, não importa a força do secure element.

Além disso, o PIN protege contra uso não autorizado. Não protege contra uso autorizado sob coação. Se alguém for ameaçado fisicamente a revelar o PIN, o chip não pode defendê-lo. Não é uma falha de projeto; apenas está fora do alcance da segurança técnica.
 

Terceira camada: armazenamento da seed phrase

A seed phrase, as 12 ou 24 palavras geradas ao configurar uma hardware wallet, é a representação legível da sua chave privada. Ela serve como mecanismo de recuperação: se você perder ou danificar o dispositivo, pode restaurar a carteira em outro aparelho usando essas palavras. Cada palavra é um ponto de checagem; juntas, elas reconstroem a chave que o secure element protegia.

Esse design é ao mesmo tempo essencial e a maior vulnerabilidade estrutural da maioria das configurações de hardware wallet.

Por que a seed phrase quebra a metáfora do castelo

Tudo que discutimos até aqui — secure boot, proteção por PIN, resistência a violação do secure element — parte do princípio de que a chave privada vive dentro do chip e só ele permite acesso.
 

A seed phrase invalida esse princípio. Ela é uma cópia da chave, em texto claro, codificada em palavras, que existe fora do chip: no papel, no metal, na sua casa, talvez em vários lugares. Qualquer pessoa que a obtenha pode reconstruir sua chave privada sem sequer tocar na hardware wallet. Toda defesa do chip se torna inútil no momento em que a seed phrase cai em mãos erradas.
 

Isso não é uma falha do projeto da hardware wallet. É uma escolha proposital: perder o dispositivo não deve significar perder os fundos para sempre. O mecanismo de recuperação necessariamente traz consigo uma vulnerabilidade. A questão é como ela será gerenciada.

O cenário de ameaças para seed phrases

Seed phrases enfrentam ameaças que chips de hardware não foram feitos para resolver:

• Physical theft: Uma seed phrase anotada em papel, guardada em casa e furtada está acessível a qualquer um que a encontre. Não exige conhecimento técnico, basta um aplicativo de wallet compatível.
   

• Fire and water damage: Diferente da hardware wallet, que pode ser substituída se a seed phrase estiver segura, uma seed phrase destruída ou danificada significa perda permanente, sem opção de recuperação.
   

• Inadvertent exposure: Fotografar a seed phrase, armazená-la em aplicativos de notas na nuvem ou digitá-la em interfaces digitais expõe ao risco de roubo remoto.
   

• Inheritance and estate: Uma seed phrase sem um plano de acesso para pessoas de confiança significa fundos inacessíveis permanentemente em caso de morte ou incapacidade do proprietário.

Como reforçar o armazenamento da seed phrase

O padrão básico é um backup físico em material durável — papel, no mínimo, ou placas de metal próprias para grandes valores — guardado em local seguro (cofre, caixa-forte) e sem ligação fácil com a identidade do dono.

Além desse básico, existem abordagens arquiteturais para reduzir o risco da seed phrase:

• Passphrase protection (25th word): A maioria dos padrões de seed phrase permite uma passphrase opcional, combinada à seed phrase para derivar a chave. Um atacante com a seed phrase, mas sem a passphrase, não consegue acessar os fundos. A passphrase deve ser memorizada ou guardada separadamente; ela se torna um segredo adicional que também precisa ser protegido.
   

• Shamir's Secret Sharing: A seed phrase pode ser dividida em múltiplas partes, cada uma inútil isoladamente, usando técnicas criptográficas. Um número mínimo de partes (por exemplo, três de cinco) deve ser reunido para recuperar a chave. Isso distribui o risco geograficamente e entre diferentes custodians.
   

• Multi-signature wallets: Em vez de uma única seed phrase, uma configuração multisig exige múltiplas chaves independentes para autorizar transações. Comprometer uma única chave ou seed phrase não basta. É uma arquitetura diferente de simplesmente proteger melhor uma seed phrase única; muda o modelo de ameaças por completo.

O que nenhuma solução técnica resolve totalmente

A segurança da seed phrase depende, no fim das contas, do comportamento humano: onde guardar, quem sabe, como manter ao longo do tempo e atualizar quando necessário. Nenhum chip pode decidir o melhor lugar para um pedaço de papel. Essa é a camada do castelo mais dependente da pessoa, não do hardware.

O sistema como um todo

Aplicar a metáfora do castelo nessas três camadas mostra como a segurança da hardware wallet funciona de fato — e onde ela pode falhar.

The secure element is the keep: o ponto mais protegido, onde a chave realmente vive, protegido por engenharia que resiste à maioria dos ataques diretos. Geralmente é a camada mais difícil de violar.

Firmware integrity and secure boot are the outer walls: controlam que código pode sequer se aproximar do torreão, garantindo que as instruções recebidas pelo chip sejam legítimas. Um castelo sem muralhas externas não é bem defendido, não importa o quão forte seja o torreão.

The PIN and access controls are the gatehouse: o ponto de checagem operado por humanos que impede usuários não autorizados de sequer interagir com o castelo. Eficaz contra invasores oportunistas; menos contra ameaças direcionadas.

The seed phrase is the secret passage: a rota de recuperação, legítima, mas que contorna todas as outras defesas se cair em mãos erradas. A segurança desse acesso depende quase totalmente de onde ele leva e quem sabe de sua existência.
 

A consequência prática dessa arquitetura é que a segurança efetiva do sistema não depende da camada mais forte, mas sim da mais fraca diante da ameaça real ao usuário. Alguém com secure element certificado EAL6+, mas seed phrase salva em um app de notas no celular, tem a proteção de um app de notas — não importa o chip.

A segurança da carteira é um sistema. O secure element é o componente mais importante desse sistema. Mas "o secure element é forte" não significa "a carteira é segura". São afirmações diferentes.

O secure element merece seu papel central. Ele resolve a parte mais difícil: proteger a chave privada contra ataques técnicos, remotos e físicos. Mas faz isso dentro de uma arquitetura maior — firmware, controles de acesso e backup da chave — que também precisa ser levada a sério.

Entender o sistema não é um argumento contra hardware wallets ou contra o secure element. É o argumento para levar o sistema completo a sério, começando por entender o que cada camada faz — e o que não faz.