Open-Source Hardware Wallets: Verifiable, Auditable, Reproducible

An open-source hardware wallet is one whose firmware, bootloader, and ideally hardware schematics are published so that anyone can inspect, audit, and independently rebuild the code that protects private keys. This matters because closed-source signing devices ask you to trust a vendor's claims without the ability to verify them. Open source shifts that trust from a company's reputation to publicly reviewable, reproducible engineering.

#Why Source Visibility Matters for Hardware Signing Devices

Every hardware wallet sits at the most sensitive point in your security model: it holds the private keys and produces the cryptographic signatures that authorize on-chain transactions. When the firmware running on that device is closed, you depend entirely on the vendor's word that no exfiltration routine, backdoor, or key-leaking side channel exists. You cannot verify. You can only trust.

Open-source firmware eliminates that dependency. Any security researcher, cryptographer, or motivated user can read the signing logic, the key-derivation paths, the random-number generation calls, and the communication protocol between the device and the host wallet. Bugs get found by the community, not just by a single internal team.

The trade-off is real, though. Publishing source code also lets attackers study it. The counter-argument, well established in cryptographic engineering, is Kerckhoffs's principle: a system should remain secure even when everything except the secret keys is public knowledge. A hardware wallet whose security depends on obscurity has a fragile foundation.

#The boundary: silicon stays proprietary

Even the most open hardware wallets rely on commercial secure-element silicon whose internal design is not published. The chip vendor submits the silicon to Common Criteria evaluation (EAL5+, EAL6+, or similar), and independent labs test it against defined attack classes. That evaluation certificate is the trust anchor for the chip layer. Open source covers the firmware and applet running on that chip, not the transistor layout underneath.

#Auditability, Reproducibility, and What Each Actually Proves

These three terms are often conflated. They represent distinct, escalating levels of assurance.

• Open source (auditable): The code is published. Anyone can read it and look for flaws. This is necessary but not sufficient, because the binary flashed onto the device might not match the published source.
• Reproducible builds: A deterministic build system lets a third party compile the same source and produce a bit-identical binary. Comparing that binary against the one on the device proves the running firmware matches the public code. Without reproducible builds, open source is a promise, not proof.
• Open hardware (verifiable BOM): Schematics, bill of materials, and 3D mechanical files are published. A sufficiently motivated party can inspect or even fabricate the hardware independently, ruling out hidden components or undocumented radios.

The limitation is effort. Most users will never compile firmware or inspect a PCB. Reproducibility matters because it lets a smaller group of auditors verify on behalf of the wider community, and anyone who wants to can repeat the process.

#Keycard as a Concrete Example of Full-Stack Openness

Keycard demonstrates what a fully open approach looks like in practice. The Keycard smartcard applet (running on an NXP JCOP4 P71 secure element, EAL6+ certified at the chip level) is published on GitHub under keycard-tech. The Keycard Shell, an air-gapped signing device with a camera, display, and QR-based transaction flow (ERC-4527 / BC-UR), goes further: its firmware, bootloader, hardware schematics, BOM, and 3D enclosure files are all MIT-licensed and publicly available.

Shell firmware supports reproducible builds using CMake and Python tooling. Anyone can clone the repository, compile the firmware, and compare the resulting binary hash against the official release. A pair of scripts (firmware-hash.py and database-hash.py) automate this comparison. The bootloader is write-protected, JTAG-burnt, and open source, which means both the code that runs and the code that verifies new firmware are inspectable.

The Keycard smartcard applet itself is also open source, though its build reproducibility is not yet formally established to the same degree as the Shell firmware. This is an honest distinction: the Shell firmware build is reproducible today, the applet build is a work in progress.

For users who want maximum independence, the system is DIY-buildable. You can purchase a blank JavaCard, compile the Keycard applet from source, install it, and lock the card yourself by randomizing the GlobalPlatform keys, resulting in immutable firmware that you personally verified.

#How Open-Source Wallets Compare

No single column makes a wallet "better." The right question is which trade-offs align with your threat model. Ledger's closed firmware means you cannot independently audit the secure-element code, but Ledger has invested heavily in internal security testing. Trezor's classic models lacked a secure element entirely, making them more susceptible to physical extraction attacks, though the open firmware meant the community caught and disclosed issues quickly. Coldcard offers air-gapped signing and a strong Bitcoin focus but does not publish full hardware design files.

#Threat Models and Where Openness Helps (and Where It Does Not)

Supply-chain tampering. Open hardware files let you compare a received device against published schematics. Keycard Shell's mutual authenticity verification (device key in the STM32H573 MCU, checked at shell.keycard.tech/verify) adds a cryptographic layer. The Keycard itself carries a factory-signed ECDSA certificate in its Ident applet.

Malicious firmware. Reproducible builds prove the binary matches the audited source. Keycard's card-level firmware is immutable once locked (GlobalPlatform keys randomized, applet in SECURED state), which eliminates firmware-update attacks on the card entirely. The Shell bootloader verifies firmware signatures before flashing and prevents downgrades.

Physical key extraction. The NXP JCOP4 P71 secure element resists invasive and semi-invasive attacks within the scope of its EAL6+ evaluation. Keys are non-extractable; the card signs internally (unsigned hash in, DER signature out over ISO 7816 APDU). Open source does not help or hurt here because the silicon is proprietary regardless.

Blind signing. The Shell's display decodes transaction data before signing (ERC-20 transfers, EIP-712 typed data, Bitcoin PSBT outputs). But the user must actually read the screen. No amount of open source compensates for confirming a transaction without reviewing it.

User-dependent risks. PIN secrecy, seed backup integrity, and address verification on the device screen remain the user's responsibility. Open source secures the tool, not the person holding it.

#Frequently Asked Questions

What does "open source" mean for a hardware wallet?

It means the firmware source code is publicly available for inspection, audit, and independent compilation. In the strongest implementations, hardware design files (schematics, BOM) are also published. This lets anyone verify that the device does what it claims and nothing more.

Does open-source firmware make a hardware wallet less secure?

No. Well-designed cryptographic systems follow Kerckhoffs's principle: security depends on the secret key, not on secrecy of the system's design. Publishing the code invites broader scrutiny, which tends to surface bugs faster than internal-only review.

What are reproducible builds and why do they matter?

Reproducible builds let anyone compile the published source code and get a bit-identical binary. This proves the firmware actually running on the device matches the audited code. Without this step, you are trusting the vendor's build pipeline, which could inject code not present in the public repository.

Is the secure element inside an open-source wallet also open source?

Generally no. The NXP JCOP4 P71 used in Keycard, for example, is proprietary silicon. Its trustworthiness comes from Common Criteria EAL6+ evaluation by independent labs, not from published transistor-level designs. The firmware and applet running on the chip are open source, but the chip itself is a trust assumption.

Can I build my own Keycard from the published source?

Yes. You can purchase a compatible blank JavaCard, compile the Keycard applet from the public GitHub repository, install it via a standard smartcard reader, and lock the card by randomizing the GlobalPlatform keys. The Shell is also DIY-buildable from published hardware files, firmware, and bootloader.

Does Keycard's immutable firmware create a risk if a bug is found?

The card-level applet cannot be updated once locked, which is a deliberate supply-chain defense. A firmware bug on the card would require issuing a new card and migrating the seed. The trade-off is real, but it closes an entire class of attack where a compromised update mechanism installs malicious firmware. The Shell firmware, by contrast, is updatable with signature verification and rollback protection.

How does Keycard Shell achieve an air gap?

The Shell contains no Wi-Fi, Bluetooth, or cellular radio hardware. Transactions move between the Shell and a host wallet entirely through QR codes (ERC-4527 / BC-UR standard, supporting animated multi-part QR up to 64 segments). A software toggle can also block USB data transfer, allowing charging without any data channel. The camera uses a global-shutter CMOS sensor for reliable animated QR capture.

What is EAL6+ and does it certify the entire device?

EAL6+ is a Common Criteria assurance level applied to the secure-element chip (the NXP JCOP4 P71 in Keycard's case), not to the firmware, the wallet software, or the complete product. It means the chip was designed and tested using semi-formal methods and resisted attacks by trained evaluators with professional equipment within the defined evaluation scope. It is the highest widely used CC assurance class, the same tier used in passports and bank cards.

Are there any parts of Keycard's system that are not open source?

The NXP JCOP4 P71 secure-element silicon is proprietary, as is the case with every hardware wallet that uses a commercial secure element. Everything above the silicon layer, including the Keycard applet, Shell firmware, Shell bootloader, hardware schematics, and build tooling, is published under an MIT license.