Carteiras de hardware de código aberto: por que importam

Carteiras de hardware de código aberto: por que importam para a segurança do Bitcoin

O Bitcoin nasceu do código aberto. Qualquer pessoa pode auditar publicamente o protocolo, a implementação de referência e as bibliotecas criptográficas das quais ele depende. Nos dispositivos que guardam as chaves privadas, as carteiras de hardware, o princípio do código aberto não é universal. Alguns fabricantes publicam tudo, enquanto outros mantêm componentes críticos proprietários. A diferença importa mais do que a maioria dos usuários percebe.

O que “código aberto” significa em uma carteira de hardware

Uma carteira de hardware tem várias camadas, e cada uma pode ser aberta ou fechada de forma independente:

Firmware: é o software que roda no microcontrolador, no elemento seguro da carteira ou em ambos. É a camada mais crítica, porque gera chaves, guarda a semente, assina transações e controla o que aparece na tela. Com firmware de código aberto, qualquer pessoa pode ler o código, auditá-lo em busca de vulnerabilidades e verificar se o binário que roda no dispositivo confere com o código-fonte publicado.

Projeto de hardware: inclui os esquemas, o layout da placa de circuito impresso e as especificações dos componentes físicos. Com hardware aberto, você pode verificar quais chips estão na placa, como se conectam e se o projeto confere com o que o fabricante afirma. Com hardware totalmente aberto, outra pessoa ou empresa poderia, em tese, fabricar o mesmo dispositivo por conta própria.

Aplicativos complementares: são o software para computador ou celular que se comunica com a carteira de hardware. Exemplos são a Ledger Wallet, antes Ledger Live, o Trezor Suite e a integração com a Sparrow Wallet. Esses aplicativos geram os endereços que aparecem na tela, montam as transações e se comunicam com a rede do Bitcoin. Se forem de código aberto, você pode verificar se o software vaza dados ou troca endereços.

Uma carteira pode ter uma camada aberta e outra fechada. Saber onde essa abertura começa e termina é essencial para avaliar o modelo de confiança real. A aula Como funcionam as carteiras de hardware oferece uma visão mais ampla de como essas camadas interagem.

Níveis de abertura

Totalmente aberto (firmware e hardware): tanto o código-fonte do firmware quanto os esquemas do hardware são públicos. Qualquer pessoa pode auditar o código do próprio dispositivo e o projeto dos circuitos. Os fabricantes dos chips da placa, como o elemento seguro, mantêm fechado o projeto interno desses chips. Alguns exemplos são a Blockstream Jade, o SeedSigner e o Passport Core da Foundation, que já não é vendido. É o nível máximo de transparência. Em tese, é possível fabricar o dispositivo a partir dos projetos publicados, o que elimina a dependência de um único fornecedor.

Publicado com restrições: o código é publicado e pode ser auditado, mas a licença limita o que você pode fazer com ele. O principal exemplo é a Coldcard. A Coinkite publica todo o código-fonte do firmware, além dos esquemas e das listas de peças da Mk4, da Mk5 e da Q. A licença MIT com uma “Commons Clause” que proíbe a venda torna o código-fonte disponível, embora ele não seja aberto no sentido estrito. Qualquer pessoa ainda pode ler e compilar o código.

Código fechado: o fabricante não publica o firmware dos componentes críticos para a segurança. O principal exemplo é a Ledger, cujo elemento seguro roda firmware proprietário. Os usuários confiam no fabricante e nas certificações externas, como as classificações Common Criteria EAL5+ ou EAL6+ dos chips da Ledger, já que não podem verificar o código por conta própria.

Por que o código aberto importa para a segurança

Auditorias da comunidade

Pessoas que não trabalham para o fabricante revisam o firmware de código aberto. Pesquisadores independentes de segurança, desenvolvedores de carteiras concorrentes e usuários de Bitcoin muito desconfiados examinam o código. Com revisores tão diferentes, aparecem problemas que as equipes internas deixam passar. Isso acontece porque as equipes partem das mesmas premissas e compartilham pontos cegos, mesmo quando são competentes. Quem revisa de fora traz outras perspectivas, outros modelos de ameaça e outras motivações.

O kernel do Linux, o OpenSSL e o próprio Bitcoin Core se beneficiaram muito dessas revisões. Alguns erros que persistiram por anos em software de código fechado apareceram rapidamente quando o código foi aberto à revisão pública. O firmware de uma carteira de hardware é muito menos complexo que um sistema operacional, o que torna viável uma revisão minuciosa pela comunidade.

Sem portas dos fundos ocultas

Com firmware de código aberto, qualquer porta dos fundos que o fabricante inserir fica visível no código. O Ledger Recover (2023) mostrou por que isso importa. É um serviço pago opcional. Se você aderir e aprovar no dispositivo, o serviço criptografa a semente e a divide entre três empresas. Críticos disseram que isso mostrava que o firmware da Ledger podia ser atualizado para exportar uma semente. A Ledger respondeu que é preciso aderir e que o serviço exige o PIN e a aprovação no dispositivo. Em princípio, o firmware de qualquer carteira de hardware poderia mudar para exportar uma semente. O que muda é o que você pode verificar. O sistema operacional da Ledger é fechado, então pessoas de fora não podiam ler como a função opera. Com firmware aberto, uma mudança assim apareceria no código de cada atualização.

As carteiras de código aberto continuam expostas a ataques à cadeia de suprimentos e a compilações adulteradas. A abertura oferece uma forma de detectar esses problemas que o modelo de código fechado não oferece.

Compilações verificáveis

O código aberto permite compilações reproduzíveis. Você pode compilar o código publicado e verificar se o binário resultante é idêntico ao que o fabricante distribui no dispositivo. Sem compilações reproduzíveis, o fabricante poderia publicar um código-fonte limpo e distribuir binários modificados. Essas compilações fecham essa brecha e são um complemento essencial à publicação do código aberto. Mais adiante, o tema é tratado com mais detalhes.

O princípio “confie, mas verifique” no Bitcoin

A cultura do Bitcoin se apoia na verificação. Ao operar um nó completo, você verifica a blockchain por conta própria, sem depender de terceiros. Ao conferir as assinaturas de uma transação, você verifica a propriedade sem depender do que o remetente diz. O mesmo princípio vale para carteiras de hardware. Se você puder verificar o código que protege as chaves, faça isso. Se não puder, você depende de confiança, independentemente das certificações ou da reputação do fabricante.

As carteiras de código fechado podem ser seguras. O modelo de confiança delas depende da integridade do fabricante e de auditores externos, em vez de verificação direta. Se você tiver um volume alto de bitcoins, é essencial entender qual modelo de confiança se aplica ao dispositivo. O artigo sobre autocustódia de Bitcoin (em inglês) trata de como essas decisões afetam a segurança geral.

Panorama atual das carteiras de hardware de código aberto

Trezor (Safe 3, Safe 5)

A Trezor abriu o mercado de carteiras de hardware em 2014 e usa código aberto desde o início. O firmware de todos os dispositivos da Trezor está publicado no GitHub e passou por revisões extensas. Os projetos e esquemas do hardware também são públicos. O Safe 3 e o Safe 5 acrescentaram um elemento seguro Infineon Optiga Trust M. O chip é fechado, mas todo o código da Trezor que se comunica com ele é aberto, o que prova que é possível integrar um elemento seguro sem fechar o código da carteira. O Safe 7 acrescenta um segundo chip, o TROPIC01, que a Trezor apresenta como um elemento seguro que pode ser auditado de forma independente. O Trezor Suite, aplicativo complementar, também publica o código-fonte sob a licença de referência da própria Trezor, que permite ler o código, mas proíbe redistribuí-lo.

Coldcard Mk5 e Q

A linha Coldcard da Coinkite roda firmware cujo código-fonte completo está publicado no GitHub. Ele usa o MicroPython e roda em um microcontrolador STM32. A licença MIT com uma “Commons Clause” proíbe a venda do código, por isso ele é código-fonte disponível e não código aberto no sentido estrito. O firmware cuida de todas as operações do usuário, enquanto dois elementos seguros de fornecedores diferentes, Microchip ATECC608 e Maxim DS28C36B, protegem a semente e aplicam o PIN. No mesmo repositório, a Coinkite publica os esquemas e as listas de peças da Mk4, da Mk5 e da Q. A Mk5 substituiu a Mk4 em março de 2026, e a Coldcard Q, com teclado QWERTY e tela maior, compartilha a mesma base de firmware. O código público não impediu a falha de geração de sementes de julho de 2026, mas permitiu que pesquisadores de fora a analisassem. Veja o aviso sobre a Coldcard (em inglês). A configuração é tratada no guia de configuração da Coldcard (em inglês).

Blockstream Jade e Jade Plus

Tanto o firmware quanto o hardware da Jade são abertos. A Blockstream publica o firmware com licenças de código aberto e os arquivos de projeto de hardware dos dois modelos no GitHub. A Jade usa um “elemento seguro virtual”. Em vez de um chip dedicado, ela usa um protocolo de oráculo cego. Ao desbloquear com o PIN, o dispositivo se conecta a um servidor da Blockstream ou a um que você hospedar, por meio do aplicativo complementar. Nem o dispositivo nem o servidor conseguem desbloquear as chaves sozinhos. É uma solução criativa que evita os problemas dos acordos de confidencialidade dos chips tradicionais, mas normalmente precisa desse servidor para desbloquear o dispositivo. Os dois modelos têm câmera para operar isolados da rede (air-gapped), por QR. A Jade Plus (janeiro de 2025) acrescenta uma tela maior e uma câmera melhor.

Foundation Passport Core (já não é vendido)

A Foundation Devices construiu o Passport com um compromisso explícito com a transparência. O firmware é publicado sob a GPLv3, embora algumas partes usem a MIT ou outras licenças compatíveis. Os projetos de circuito são publicados sob a CERN-OHL-S v2, uma licença de hardware aberto com copyleft que exige compartilhar mudanças sob as mesmas condições. O Passport usa um elemento seguro Microchip ATECC608, e o firmware que se comunica com ele é aberto. O dispositivo roda em um processador STM32H7 e tem uma câmera para operar isolado da rede, por QR. A Foundation também publica a documentação do modelo de segurança e a análise de ameaças. Em março de 2026, a Foundation anunciou que descontinuou o Passport Core e diz que ele continua recebendo atualizações de segurança. Hoje ela vende o Passport Prime, que não avaliamos.

BitBox02

A BitBox02, da Shift Crypto, que opera como BitBox, tem firmware e hardware de código aberto. O firmware é escrito em C e Rust, está publicado no GitHub sob a licença Apache 2.0 e passou por uma auditoria independente. A BitBox identifica a Census Labs como auditora. Os esquemas do hardware são públicos. A BitBox02 usa um elemento seguro Microchip ATECC608B para atestação e derivação de chaves adicionais. O aplicativo complementar, o BitBoxApp, também é de código aberto. A edição exclusiva para Bitcoin elimina todo o suporte a altcoins, o que reduz a superfície de ataque.

SeedSigner

O SeedSigner é um projeto que você monta inteiramente por conta própria. É um dispositivo de assinatura de Bitcoin sem estado, feito de componentes comuns: Raspberry Pi Zero, módulo de câmera e tela LCD. Todo o software é de código aberto. Os usuários montam o dispositivo a partir das instruções e do código publicados. Não existe “fabricante”. O SeedSigner não guarda chaves. Ele as gera ou importa em cada sessão e assina PSBTs por códigos QR. É o extremo da abertura: você monta o hardware, compila o software e verifica tudo. Em troca, a usabilidade é menor e não há elemento seguro.

Tabela comparativa

Carteira	Firmware de código aberto	Hardware aberto	Compilações reproduzíveis	Auditorias independentes de segurança
Trezor Safe 3 / Safe 5	Sim	Sim	Sim	Várias, incluindo a primeira, da Kudelski
Coldcard Mk5 / Q	Código-fonte disponível (MIT + Commons Clause)	Esquemas e listas de peças	Sim	Revisão da comunidade e divulgações da NVD
Blockstream Jade / Jade Plus	Sim	Sim	Sim	Revisão da comunidade e relatório de falha da DARKNAVY (corrigida em 2025)
Foundation Passport Core (já não é vendido)	Sim (GPLv3)	Sim (CERN-OHL-S v2)	Sim	Revisão da comunidade
BitBox02	Sim	Esquemas e lista de peças	Sim	Census Labs
SeedSigner	Sim	Não se aplica (componentes comuns)	Sim	Revisão da comunidade
Ledger (Nano, Stax, Flex)	Não (firmware do elemento seguro)	Não	Não	Certificação CC EAL5+ / EAL6+ do chip e equipe interna Donjon da Ledger

Exemplos de código fechado e em quem você precisa confiar

A Ledger é o principal exemplo da abordagem de código fechado. O argumento a favor de fechar o firmware do elemento seguro é que a segurança do chip depende, em parte, de ocultar o funcionamento interno. Segundo esse argumento, publicar o firmware daria a atacantes um mapa detalhado para criar ataques de canal lateral ou estratégias de injeção de falhas.

O argumento tem algum mérito técnico. Os elementos seguros são projetados para resistir a tipos de ataque conhecidos, e ocultar como as contramedidas foram implementadas acrescenta dificuldade. Mesmo assim, segurança por obscuridade é uma defesa complementar. As operações criptográficas em si não se beneficiam do segredo, e a lógica de gerenciamento de chaves, que define como as sementes são geradas, guardadas e exportadas, deve poder ser auditada de qualquer forma. O debate sobre o Ledger Recover mostrou por quê. Quando a Ledger anunciou um serviço opcional capaz de exportar uma cópia criptografada da semente, os usuários tiveram de confiar na explicação da empresa sobre como ele funciona, porque não podiam ler o código que roda no elemento seguro. Esses ataques são tratados com mais detalhes no artigo sobre riscos de ataques de canal lateral em hardware de criptomoedas (em inglês).

Como funcionam as compilações reproduzíveis

Só o código aberto não permite verificar tudo. O último elo são as compilações reproduzíveis. Qualquer pessoa pode compilar o código-fonte e gerar um binário idêntico byte por byte ao que o fabricante distribui.

Sem compilações reproduzíveis, o fabricante poderia publicar código-fonte impecável no GitHub e entregar os dispositivos com binários diferentes, talvez adulterados. As compilações reproduzíveis fecham essa brecha para os arquivos que o fabricante distribui. Se um usuário ou pesquisador compilar o código e obtiver um binário cujo hash coincide com o do arquivo oficial de firmware, terá uma evidência sólida de que a versão oficial foi compilada a partir do código publicado. Para saber se o aparelho que você tem está rodando essa versão, é preciso uma verificação à parte. O dispositivo verifica a assinatura e, em alguns modelos, também é possível conferir o hash do firmware (o processo está nas perguntas frequentes mais abaixo).

Obter compilações reproduzíveis é difícil. É preciso controlar com precisão os compiladores, as configurações do vinculador, as versões das bibliotecas e os ambientes de compilação. Vários projetos já conseguem:

• A Trezor oferece compilações reproduzíveis com contêineres Docker e versões fixas das ferramentas de compilação.
• A BitBox02 publica instruções de compilação reproduzível e ambientes Docker.
• A Coldcard automatiza a compilação reproduzível com o Docker e informa se o resultado confere byte por byte com a versão oficial.
• A Blockstream Jade aceita compilações reproduzíveis com ambientes de compilação documentados.
• O SeedSigner publica imagens de versões reproduzíveis desde a versão 0.7.0.
• O Foundation Passport oferece uma compilação com o Docker e um comando para comparar o hash do firmware com o publicado.

Se um projeto de carteira de hardware se apresentar como de código aberto, mas não oferecer compilações reproduzíveis, há uma brecha na verificação. Poder auditar o código-fonte tem valor, mas a ligação entre esse código e o firmware do dispositivo depende de confiança. A relação entre compilações reproduzíveis e atualizações é tratada no artigo sobre atualizações de firmware e segurança (em inglês).

Impacto real: vulnerabilidades encontradas graças ao código aberto

O valor do firmware de código aberto não é teórico. Pesquisadores da comunidade descobriram várias vulnerabilidades importantes porque o código estava disponível para revisão:

Vulnerabilidade do microcontrolador da Trezor (divulgada em janeiro de 2020): pesquisadores da Kraken Security Labs demonstraram um ataque por falha de tensão no microcontrolador STM32 do Trezor One e do Model T que permitia extrair a semente criptografada com cerca de 15 minutos de acesso físico. Primeiro, informaram a Trezor de forma responsável. Nos dispositivos existentes, o software não podia corrigir o problema, porque a vulnerabilidade do chip era uma limitação do hardware. Por isso, a Trezor indicou uma passphrase BIP39 como medida de proteção. Os modelos Safe mais recentes mantêm o PIN e os segredos atrás de um chip seguro, então induzir uma falha no chip principal de um dispositivo bloqueado já não revela a semente. O chip principal continua suscetível a esse tipo de falha. Em março de 2025, a Donjon, equipe de segurança da Ledger, usou a técnica para contornar a verificação de firmware do Safe 3. Isso importa se alguém adulterar o dispositivo antes de ele chegar a você. Compre na loja do fabricante.

Verificação de troco multisig da Coldcard (corrigida em dezembro de 2019): Dmitry Petukhov, um desenvolvedor que integrava a Coldcard ao próprio software, descobriu que o firmware não interpretava os scripts multisig com rigor suficiente. Um atacante intermediário, como um malware no computador que prepara a transação, podia disfarçar uma saída sob controle dele como seu troco e ficar com ela quando você usasse multisig. A Coinkite corrigiu a falha no firmware 3.0.6, acrescentou os endereços de troco à tela de confirmação como verificação adicional e informou que não havia indícios de exploração. Quando os detalhes vieram a público em março de 2020, o relatório de Petukhov citou as linhas exatas do código multisig público que pulavam a verificação.

Implementação do anti-klepto na BitBox02: a BitBox02 e, separadamente, a Blockstream Jade implementaram o protocolo anti-klepto, ou “anti-exfil”, para impedir que o dispositivo vaze material de chaves ao enviesar a geração de nonces (o tipo de ataque conhecido como Dark Skippy (em inglês)). Como a implementação era de código aberto, pesquisadores puderam verificar se o protocolo estava implementado corretamente e se o dispositivo resistia a esse tipo de vazamento por nonces.

Esses exemplos mostram um padrão. O código aberto oferece um meio de encontrar e corrigir vulnerabilidades antes de alguém explorá-las, embora não impeça que apareçam. O firmware de código fechado pode ter vulnerabilidades equivalentes ou piores que continuam sem ser descobertas porque ninguém de fora da empresa pode ler o código.

O futuro das carteiras de hardware de código aberto

A tendência é de mais abertura. Vários avanços mostram para onde o setor está indo:

Elementos seguros compatíveis com código aberto: o argumento de que elementos seguros exigem firmware fechado perde força. A integração do Optiga Trust M pela Trezor, o elemento seguro virtual da Jade e o uso de código aberto pela Foundation para se comunicar com o chip mostram caminhos viáveis para proteger o hardware sem esconder o código. À medida que surgirem mais chips projetados para integração com código aberto, o argumento dos acordos de confidencialidade perderá a força que ainda tem.

Compilações reproduzíveis como padrão esperado: há alguns anos, compilações reproduzíveis eram uma aspiração. Hoje vários projetos conseguem produzi-las, e cada vez mais usuários esperam por elas. As ferramentas de compilação reproduzível, como o Docker, o Nix e o Guix, estão amadurecendo, o que facilita a adoção por projetos novos.

Dispositivos montados em casa ou pela comunidade: projetos como o SeedSigner comprovaram que é possível montar um dispositivo funcional de assinatura de Bitcoin com hardware comum e software totalmente aberto. Esses dispositivos não têm o acabamento nem a proteção de um elemento seguro dos produtos comerciais, mas demonstram que é possível assinar no Bitcoin sem depender da confiança em um fornecedor. Isso serve de contrapeso aos fabricantes comerciais. Se ficarem opacos demais, os usuários têm alternativas.

Mais conhecimento de segurança na comunidade do Bitcoin: os usuários entendem cada vez mais os riscos da cadeia de suprimentos, os modelos de confiança do firmware e os limites do código fechado. Essa pressão do mercado empurra os fabricantes para a transparência. O anúncio de um plano de abertura pela Ledger, por mais lenta que seja a execução, foi uma resposta direta à demanda da comunidade após a polêmica do Ledger Recover.

Ao avaliar como você faz a custódia, considere quais partes da carteira de hardware que você escolher têm código aberto, junto com a segurança física, a facilidade de uso, o suporte a multisig e o histórico do fabricante. O código aberto deve pesar na decisão, porque determina se a segurança se baseia em verificação ou em confiança. Usar hardware de vários fornecedores (em inglês) em uma configuração multisig pode reduzir a dependência do modelo de confiança de um único fabricante, aberto ou fechado.

Perguntas frequentes

O código aberto permite que qualquer pessoa hackeie a carteira?

Não. Publicar o código-fonte não reduz a segurança do dispositivo. A segurança criptográfica de uma carteira de hardware depende da solidez dos algoritmos e do gerenciamento das chaves, independentemente do segredo do código. O AES, o SHA-256 e a criptografia de curva elíptica são públicos, e a segurança vem das propriedades matemáticas. Com código aberto, qualquer pessoa pode procurar vulnerabilidades, então elas são encontradas e corrigidas mais rápido. O código fechado tem tantos erros quanto o aberto, mas é mais demorado encontrá-los, e atacantes podem descobri-los antes de quem defende o sistema.

Um SeedSigner que eu montar é tão seguro quanto uma carteira comercial?

Depende do modelo de ameaça. O SeedSigner não tem elemento seguro, então é mais vulnerável a ataques de extração física se alguém acessar o dispositivo enquanto as chaves estiverem carregadas. Ainda assim, ele foi projetado para operar sem estado. O dispositivo não guarda as chaves entre sessões. Para extraí-las, um atacante precisaria de acesso físico durante o curto período em que o dispositivo estiver ligado e as chaves estiverem na RAM. Se você priorizar a possibilidade de verificar e enfrentar pouco risco de roubo físico, o SeedSigner pode fazer parte de uma configuração sólida, especialmente como uma das chaves de uma configuração multisig.

Por que alguns fabricantes mantêm o projeto de hardware fechado mesmo com firmware aberto?

Abrir o hardware tem implicações econômicas diferentes de abrir o software. Publicar os esquemas completos e o layout da placa de circuito impresso facilita que concorrentes, especialmente fabricantes de baixo custo, façam clones. Algumas empresas mantêm o projeto parcialmente fechado para proteger o negócio e abrem o firmware para permitir auditorias de segurança. É um compromisso pragmático. O firmware contém a lógica mais crítica para a segurança, então abri-lo oferece a maior parte do benefício para auditoria. Projetos de hardware totalmente aberto, como a Blockstream Jade e o Passport Core da Foundation, aceitam o risco de clonagem em troca de transparência total.

Como verifico se a carteira de hardware roda o firmware que diz rodar?

Se a carteira oferecer compilações reproduzíveis, baixe o código-fonte, prepare o ambiente de compilação, que normalmente é um contêiner Docker do projeto, compile o código e compare o hash do binário resultante com o do arquivo oficial de firmware. Desconte a assinatura do fabricante conforme as instruções do projeto. Se os hashes conferirem, o firmware oficial corresponde exatamente ao código-fonte. O dispositivo verifica a assinatura do fabricante a cada atualização. Alguns aparelhos também permitem conferir o firmware que estão rodando. O Trezor Suite checa o hash do firmware toda vez que você conecta um Trezor com o firmware mais recente, e a BitBox02 pode mostrar o hash de firmware ao iniciar. Se a carteira não oferecer compilações reproduzíveis, você depende da confiança na assinatura do fabricante para a atualização. O processo para vários aparelhos populares é tratado no guia de atualizações de firmware e boas práticas de segurança (em inglês).