Andrey Lazutkin, da Tangem, defende carteiras de hardware mais simples

O marketing das carteiras de hardware atualmente costuma ir em uma direção: mais recursos, mais telas, mais conectividade, mais atualizações de firmware. A Tangem construiu todo o seu produto apostando no caminho oposto.
 

Não há tela, nem bateria, nem conexão USB ou Bluetooth, nem firmware atualizável e nem seed phrase para anotar. Para muitos especialistas em segurança, isso pode parecer uma lista de recursos esperados de uma carteira cripto; mas, na verdade, é uma lista de funcionalidades propositalmente deixadas de fora.
 

A Yellow Media conversou com o CTO da Tangem, Andrey Lazutkin, e foi direto ao ponto. 

• O que acontece se o celular for comprometido? 
• Por que lançar um firmware que nunca pode ser atualizado? 
• O que protege o Tangem Ring de um ataque NFC em um trem lotado? 
• E o que muda quando a computação quântica chegar?

O problema de não ter tela: e se o celular estiver enganando?

Um princípio central das carteiras de hardware tradicionais é “O que você vê é o que você assina” — uma tela no próprio dispositivo para o usuário conferir os detalhes da transação. A Tangem não tem tela e transfere toda a interface para o smartphone. 

Se um celular for infectado por malware que altera o que aparece na tela, o usuário pode autorizar uma transferência NFC maliciosa sem perceber. Como a arquitetura da Tangem previne adulteração da interface em um aparelho comprometido?

Ter tela não é um modelo de segurança por si só. É apenas um componente. E cada componente traz riscos. Quanto mais complexa a carteira de hardware, mais superfícies de ataque ela tem: lógica de exibição, botões, firmware, mecanismos de atualização, USB, Bluetooth, baterias, drivers, analisadores e interfaces físicas. 

A internet está cheia de exemplos de carteiras de hardware atacadas não por falhas na criptografia, mas por brechas criadas pela complexidade da implementação.

A Tangem segue a filosofia oposta: tornar o dispositivo de assinatura o mais simples possível. Sem tela, sem bateria, sem USB, sem Bluetooth, sem firmware atualizável, sem sistema operacional complexo. A chave privada é gerada e armazenada dentro do chip seguro e nunca sai do cartão. Essa simplicidade é uma grande vantagem de segurança.

O celular é usado apenas como interface, mas as chaves não ficam nele. O app da Tangem também é fortemente protegido: 

• verificações de integridade em tempo real, 
• anti-debugging,
• anti-emulação, 
• detecção de root e jailbreak, 
• armazenamento criptografado,
• comunicação segura, 
• validação de certificado, 
• proteção WebView, 
• proteção contra tapjacking, 
• tratamento seguro de entrada, 

Além disso, há permissões minimizadas, revisão de código, auditorias e verificações automáticas de segurança.
 

Por isso, não vemos segurança como “com ou sem tela”. Olhamos para toda a arquitetura. A Tangem reduz a superfície de ataque no hardware e reforça a camada mobile que prepara as transações. Essa abordagem oferece ao usuário uma combinação poderosa: um dispositivo de assinatura simples e isolado, e uma experiência mobile segura e moderna.

Em segurança, a complexidade costuma ser inimiga. A vantagem da Tangem é que o cartão faz muito pouco, mas faz uma coisa crítica extremamente bem: proteger a chave e assinar com segurança.

Por que o cartão nunca pode ser atualizado

O firmware da Tangem é gravado na fábrica e imutável — não pode ser atualizado remotamente, eliminando o risco de updates maliciosos. Mas se um zero-day ou uma falha crítica de criptografia for descoberta nesse lote de chips, o usuário não pode corrigir. Por que um chip totalmente não atualizável é mais seguro para autocustódia de longo prazo do que um chip que aceita atualização?

Atualizabilidade não é de graça. Em uma carteira de hardware, o mecanismo de atualização é também um mecanismo permanente de injeção de código.

Se uma carteira pode receber firmware novo depois de sair da fábrica, o usuário precisa confiar no fornecedor para sempre: nas chaves de assinatura, sistema de builds, pipeline de lançamento, servidores de atualização, funcionários, processos de segurança e decisões futuras do negócio. Mesmo que tudo seja projetado corretamente, essa infraestrutura passa a fazer parte da base de confiança.
 

Isso cria riscos reais: servidores de atualização comprometidos, chaves de assinatura vazadas, insiders maliciosos, pressão regulatória, atualizações ruins acidentais ou uma futura alteração de firmware que enfraqueça o modelo de segurança original.

A polêmica do Ledger Recover deixou isso muito claro. O próprio suporte da Ledger teria escrito, em um post já apagado: “Tecnicamente, sempre foi possível escrever um firmware que facilite a extração de chaves. Você sempre confiou que a Ledger não enviaria esse tipo de firmware, sabendo disso ou não.” É exatamente esse elo de confiança que a Tangem elimina.
 

A Tangem escolhe a imutabilidade. Nosso firmware é gravado durante a fabricação e não pode ser modificado depois. Não há atualização OTA, nem atualização via USB, nem caminho de atualização sem fio, nem como a Tangem enviar novo código ao cartão após ele estar nas mãos do usuário.

Sim, isso significa que não podemos corrigir um chip remotamente se uma vulnerabilidade de hardware for descoberta no futuro. Mas um dispositivo atualizável não elimina riscos; ele cria outro risco permanente: a possibilidade de alterar código crítico de segurança depois.

Para autocustódia de longo prazo, acreditamos que a raiz de confiança mais segura é a imutável. O dispositivo não deve depender de o fabricante permanecer confiável para sempre. A filosofia da Tangem é simples: o cartão deve proteger a chave, assinar com segurança e nunca mais aceitar novo código.
 

A dependência da loja de aplicativos

A Tangem depende do app companheiro; há uma dependência estrutural de canais de distribuição centralizados, como a App Store da Apple e o Google Play.

 Se um agente estatal ou atacante sofisticado comprometer suas credenciais de desenvolvedor e publicar uma atualização maliciosa antes de a equipe perceber, que barreiras nativas dentro do elemento seguro protegem os fundos do usuário?

Para esse cenário acontecer, um invasor teria que comprometer nossas credenciais de desenvolvedor, burlar MFA e controles internos de acesso, passar pelo processo de aprovação de lançamento, injetar código malicioso no build oficial, passar pela revisão da Apple ou Google, manter a identidade oficial do app, evitar a detecção de malware da plataforma e ainda não ser percebido pela nossa equipe, sistemas de monitoramento e pela comunidade open-source.

Não é uma única vulnerabilidade. É uma cascata de falhas em múltiplas camadas de segurança independentes. E é exatamente isso que quero dizer quando afirmo que segurança deve ser avaliada como um sistema completo, não olhando para um único recurso isolado. 

No nosso ponto de vista, a probabilidade de uma cadeia dessas dar certo é muito menor do que os riscos criados por uma arquitetura de carteira de hardware mais complexa, especialmente uma que dependa de atualizações de firmware para se manter segura ao longo do tempo.
 

Dispositivos mais complexos precisam de mais interfaces, mais firmware, mais mecanismos de atualização, mais componentes e mais processos confiáveis. Cada uma dessas camadas cria superfícies de ataque adicionais: ataques na cadeia de suprimentos, interfaces de depuração, bugs de firmware, atualizações comprometidas, vazamento de chaves de assinatura, comprometimento do sistema de builds ou pressão do fornecedor para mudar o comportamento do dispositivo após o envio.
 

Se você olhar o histórico de ataques a carteiras de hardware, o padrão é claro. A maioria dos problemas reais não vem de quebrar a criptografia. Eles vêm da complexidade: erros de implementação, mecanismos de atualização, interfaces físicas, comportamento do firmware, suposições na cadeia de suprimentos ou interações inesperadas entre componentes.

Uma atualização maliciosa na loja de apps é um risco teórico. Mas exige uma cadeia de falhas independentes antes de o invasor sequer chegar ao usuário. Já um código-fonte permanentemente atualizável mantém um caminho aberto para atualização de código durante toda a vida útil do produto.

Esse é o núcleo do modelo de segurança da Tangem: minimizar o número de componentes confiáveis, reduzir a superfície de ataque e tornar o dispositivo de assinatura imutável.

Backup sem seed phrase vs. papel

A arquitetura sem seed phrase da Tangem garante segurança clonando a chave privada nos cartões de backup durante a configuração. Isso elimina o ponto único de falha de uma seed phrase anotada, mas cria uma dependência física: se você perder os cartões de backup, não há recuperação. Como um backup só de hardware escala para herança multigeracional ou planejamento sucessório em comparação com o padrão BIP-39 em papel?

Quando alguém compra uma carteira de hardware, espera que o dispositivo proteja suas chaves privadas. Mas, em muitas carteiras tradicionais, o dispositivo exibe a seed phrase ao usuário e devolve a responsabilidade para ele.
 

A partir desse momento, o elo mais fraco não é mais a carteira de hardware. É a seed phrase: um pedaço de papel, uma placa de metal, uma gaveta, um cofre, uma foto que nunca deveria ser tirada ou uma frase que pode ser perdida, danificada, copiada, exposta ou roubada.
 

Perder acesso a chaves privadas e frases de recuperação é uma das maiores causas reais de perda definitiva de cripto. A Chainalysis estima que milhões de bitcoins já foram perdidos para sempre. Ataques de phishing continuam mirando diretamente nas seed phrases, porque, uma vez exposta, não importa o preço ou nível de segurança da carteira de hardware.
 

No modelo tradicional, você tem uma carteira de hardware e uma seed phrase. Pode fazer mais cópias da seed, mas cada uma aumenta o risco, pois não são protegidas por hardware. O usuário precisa inventar seu próprio sistema de segurança.
 

A Tangem enxerga diferente: acredita que o backup também deve ser protegido por hardware. Por isso, no kit padrão da Tangem, o usuário recebe três cartões. Cada cartão é uma carteira de hardware completa, com elemento seguro, e não apenas um segredo em papel desprotegido.
 

Para herança ou armazenamento de longo prazo, o usuário pode ficar com um cartão para uso diário, guardar outro em local seguro e entregar o terceiro para um familiar, advogado ou como parte de um arranjo sucessório. Se todos os cartões forem perdidos, não há recuperação — mas isso é autocustódia real. O que a Tangem elimina é a parte mais frágil do modelo tradicional: a seed phrase exposta.
 

Se a chave privada é importante o suficiente para ser protegida por uma carteira de hardware, o backup também deve ser. É exatamente isso que a Tangem faz.

Simulação de transação pode ser 100% confiável?

Phishing em DeFi e assinaturas às cegas continuam sendo formas comuns de carteiras de usuários serem drenadas. Seu app integra simulação de transações e detecção de golpes em dApps para mostrar ao usuário o que um contrato vai executar. 

Mas, considerando a natureza Turing-completa de contratos inteligentes complexos e rotas multi-hop, a simulação do lado do cliente pode ser 100% confiável? Ou existe o risco de dar ao usuário uma falsa sensação de segurança absoluta?

Ótima pergunta, porque você usou a expressão-chave “segurança absoluta”.

A resposta honesta é não. Nenhuma carteira, motor de simulação, dispositivo de hardware ou empresa de segurança pode prometer segurança absoluta. O universo cripto é adversarial. Segurança não é um recurso mágico; é um conjunto de camadas que tornam ataques mais difíceis, caros e menos escaláveis.
 

E, às vezes, o ponto mais fraco não é onde as pessoas esperam. Existem casos confirmados no setor em que dados de clientes de carteiras de hardware foram expostos. Nessas situações, o problema nem sempre foi a criptografia ou o dispositivo em si, mas o perímetro de segurança mais amplo ao redor do usuário: phishing, engenharia social, contatos de suporte falsos, dispositivos de substituição falsificados ou pressão direcionada.
 

No DeFi, a Tangem utiliza algumas das camadas de proteção mais avançadas disponíveis: simulação de transação, análise de risco de contratos inteligentes, detecção de dApps maliciosos, checagem de domínios, alertas para comportamentos suspeitos e proteção contra assinatura às cegas sempre que a transação pode ser decodificada e analisada.
 

Mas a simulação pode ser 100% confiável para todo contrato inteligente possível? Não. Contratos inteligentes complexos, rotas multi-hop, mudanças de estado on-chain, front ends maliciosos, domínios de phishing e engenharia social significam que o usuário ainda precisa conferir onde está conectando, o que está aprovando e se confia no dApp.
 

Portanto, nunca posicionamos a simulação como proteção absoluta. Ela é mais uma camada de segurança que melhora muito a visibilidade antes da assinatura. Ajuda o usuário a entender o que a transação provavelmente fará, identificar golpes mais cedo e evitar aprovações às cegas.

A mentalidade certa é: a Tangem protege a chave com hardware, reduz a superfície de ataque com um cartão simples e imutável e adiciona proteção DeFi moderna no app. Mas o usuário ainda deve usar dApps confiáveis, checar domínios, evitar transações apressadas ou sob pressão, ter cuidado com aprovações e nunca tratar qualquer sistema de alerta como substituto do bom senso.

Segurança absoluta não existe. Segurança forte vem de defesas em camadas — e é assim que a Tangem é construída.
 

Pagar gas em stablecoins sem sair da cold storage

Recentemente, vocês lançaram um recurso que permite pagar taxas de rede em stablecoins como USDT ou USDC, em vez do token de gas da rede. Por trás dos panos, contornar o mecanismo nativo de gas normalmente exige relayers de abstração de conta ou liquidez de terceiros. 

Esses recursos de conveniência trazem riscos sutis de contraparte ou dependências centralizadas para um ambiente pensado como cold storage?
 

A Tangem usa EIP-7702 para Smart Gas em redes EVM compatíveis. Isso permite que o usuário pague taxas de rede em alguns tokens ERC-20, em vez de manter o token de gas nativo. Não muda o modelo de custódia: a chave privada segue dentro do cartão Tangem, o usuário ainda assina com a carteira de hardware e nenhum terceiro tem acesso às chaves.
 

App open-source, chip fechado

O app companheiro da Tangem é totalmente open source no GitHub, alinhado ao espírito “Don’t Trust, Verify” da comunidade. Mas o elemento seguro EAL6+ dos cartões roda em uma arquitetura proprietária, fechada, desenvolvida por fabricantes de silício. 

Como conciliar a filosofia open-source do DeFi com uma base de hardware que exige confiar em um projeto fechado de uma fundição corporativa?
 

Open source é importante, mas afirmar que toda camada de um produto de hardware seguro deve ser open-source é um sinal claro de que a pessoa não entende segurança de hardware.
 

No caso do elemento seguro, firmware fechado de baixo nível e internals fechados do chip não são falhas. Fazem parte do modelo de proteção. Esses chips são projetados para resistir a ataques físicos e invasivos: injeção de falhas, análise de canal lateral, sondagem, glitching, ataques a laser e outras técnicas de laboratório. Publicar detalhes do comportamento do firmware, layout de memória, sensores, contramedidas ou lógica de detecção de falhas não tornaria o usuário mais seguro. Só facilitaria o trabalho dos atacantes.
 

Isso não é ingenuidade de “segurança por obscuridade”. Segurança séria de hardware se baseia em proteção em camadas: elementos seguros certificados, conjuntos de comandos limitados, auditorias independentes, firmware imutável e superfície de ataque mínima. 

Mas também significa não expor detalhes desnecessários de implementação de baixo nível que facilitariam ataques físicos.

E sejamos honestos: mesmo quando alguém diz ter “firmware open-source”, o chip seguro em si nunca é totalmente aberto. Ele contém lógica de hardware, ROM, microcódigo, contramedidas proprietárias, processos de fabricação e mecanismos de segurança física que não são realistas de inspecionar ou reproduzir. 

Portanto, fingir que o consumidor pode verificar toda a raiz de confiança do hardware só porque parte do firmware é publicada é enganoso.

Nosso modelo de segurança é: “fechar onde a divulgação ajudaria atacantes, avaliar independentemente onde é preciso confiar e manter tudo o mais minimalista possível”.

Levar o hardware para o público: o Tangem Ring

À medida que a Tangem expande dos cartões para wearables como o Tangem Ring, o hardware vai direto para o espaço público. Que medidas técnicas protegem o usuário de um adversário usando um leitor NFC amplificado em um ambiente lotado para tentar handshakes não autorizados ou ataques de força bruta ao código de acesso?

Primeiro, NFC significa Near Field Communication. Foi feito para funcionar a curtíssima distância, então a ideia de um “leitor amplificado” interagindo silenciosamente com um anel no dedo de alguém em um local cheio não é um ataque realista no dia a dia.

Tem também o lado prático: o Tangem Ring foi projetado para parecer um wearable comum, como anéis de pagamento ou outros acessórios. O atacante precisaria primeiro identificar que a pessoa está usando uma carteira de hardware cripto, não apenas um anel comum.

Mesmo que alguém tente interagir com o anel via NFC, isso não daria acesso à carteira. O Tangem Ring, assim como os cartões Tangem, é protegido por um código de acesso definido pelo usuário. Sem esse código, o atacante não consegue autorizar operações da carteira.

Força bruta também não é viável. O dispositivo se protege contra tentativas repetidas de senha: após erros, o tempo de espera entre tentativas aumenta, tornando impossível adivinhar automaticamente.

O modelo de segurança é simples: só a proximidade NFC não basta, só a presença física não basta e tentar adivinhar o código de acesso não é um ataque realista. O usuário pode usar o Tangem Ring em público com tranquilidade.

Regulação e o núcleo da autocustódia

Reguladores globais estão intensificando regras sobre “carteiras não hospedadas” e triagem obrigatória de destino de transações. Como CTO, você projeta sua infraestrutura para resistir a possíveis exigências futuras de compliance embutido ou ganchos de KYC em apps de autocustódia — ou seu software é projetado para ser totalmente não modificável, independentemente de mudanças legais?
 

Primeiro, é importante separar a arquitetura do dispositivo da camada regulatória.

Na Tangem, a chave privada é gerada e armazenada dentro do cartão. O cartão não sabe o que é KYC, não depende de servidor de compliance e não pede permissão à Tangem para assinar uma transação. Ele simplesmente protege a chave e assina quando o usuário autoriza.
 

O usuário pode interagir com o cartão pelo app oficial da Tangem ou, tecnicamente, por ferramentas e SDKs open-source. Isso significa que a Tangem não pode congelar o cartão remotamente, extrair a chave ou impedir o acesso do usuário aos fundos no nível do hardware.
 

Sobre regulação, é importante ser realista. Obrigar carteiras de autocustódia a embutir mecanismos de controle direto na camada de assinatura seria a ferramenta errada. Existem muitas carteiras gratuitas, open-source, forks e soluções alternativas. Se reguladores afastarem usuários de produtos auditados e seguros, muitos vão migrar para alternativas menos transparentes e menos seguras. Isso aumentaria perdas, golpes e atividades paralelas, não reduziria.
 

O que já vemos globalmente é outra tendência: reguladores focam nos pontos onde o cripto se conecta a serviços regulados; exchanges, on-ramps, off-ramps, produtos de pagamento e intermediários financeiros. É aí que KYC, AML, checagens de sanções e obrigações de reporte normalmente se aplicam.
 

Se certas jurisdições exigirem fluxos de compliance para serviços específicos, a Tangem pode ajudar o usuário a permanecer em conformidade ao usar esses serviços. Mas isso é bem diferente de dizer que a carteira de hardware em si deveria virar um dispositivo permissionado.
 

Nossa posição é simples: a Tangem pode apoiar acesso a serviços regulados de forma compatível, mas o núcleo da autocustódia precisa permanecer autocustódia. O cartão protege a chave. O usuário controla os fundos. A Tangem não detém os ativos, não controla a chave privada e não tem um botão remoto para decidir se o usuário pode assinar ou não.
 

A questão quântica

A grande maioria das carteiras de hardware, incluindo a Tangem, utiliza criptografia de curva elíptica padrão ECDSA ou Ed25519. Com o avanço da computação quântica, quão vulnerável está o silício de firmware fixo à eventual quebra quântica, e qual é o plano para migrar os cartões físicos existentes para criptografia pós-quântica?
 

A transição para criptografia pós-quântica precisa começar no protocolo da blockchain.

As carteiras de hardware não definem quais algoritmos de assinatura Bitcoin, Ethereum, Solana ou outras redes aceitam. Primeiro, as blockchains precisam adotar padrões criptográficos resistentes a quântica. Só depois esses algoritmos podem ser implementados em carteiras, elementos seguros e dispositivos de assinatura.
 

Hoje, não existe um caminho de migração universalmente aceito nem um algoritmo pós-quântico único adotado pelas grandes blockchains para assinaturas do dia a dia. O setor ainda está pesquisando, testando e debatendo a melhor abordagem.
 

A Tangem está ativamente trabalhando nessa direção, mas esse desafio é muito maior do que apenas carteiras de hardware. A mesma transição vai impactar cartões bancários, SIM cards, elementos seguros, documentos de identidade, dispositivos IoT e muitos outros sistemas críticos de segurança.

Nos próximos anos, esperamos uma forte aceleração em criptografia pós-quântica, suporte a chips seguros e padrões em nível de blockchain. Quando as redes estiverem prontas para esses algoritmos, a Tangem vai evoluir junto.

O ponto-chave é simples: a migração pós-quântica é uma transição de todo o ecossistema — primeiro as blockchains, depois as carteiras de hardware.

O fio condutor em todas as respostas é o mesmo argumento que a Tangem defende desde o início: segurança é uma propriedade do sistema como um todo, não de um recurso isolado. Menos partes móveis, menos pontos de confiança, menos chances de falha e um trabalho crítico feito com excelência.