Verify Your Hardware Wallet Firmware: A Practical Guide
Table of Contents
- Introduction
- Why Verify Your Firmware?
- Trezor Firmware Verification
- Coldcard Firmware Verification
- The Ledger Case: Limitations of Closed Source
- Firmware Update Best Practices
- Verification Comparison Table
- FAQ
- Resources and Tools
- Conclusion
- Internal Links
- Sources
Suggested URL: /security/verify-hardware-wallet-firmware-practical-guide
Category: Technical Security Tutorials
Summary: Complete tutorial for independently verifying the firmware of your hardware wallet (Trezor, Coldcard, Ledger). Protect yourself against supply chain attacks and compromised updates.
Introduction
Protect yourself from supply chain attacks and compromised firmware
Your hardware wallet is the guardian of your private keys. But what happens if the device itself has been compromised? Malicious firmware could record your seed phrase, alter destination addresses, or exfiltrate your keys without your knowledge.
This threat is not theoretical. Supply chain attacks -- where a device is intercepted and modified before reaching the user -- are well documented. Compromised updates could theoretically be distributed by an attacker who has infiltrated a manufacturer's infrastructure.
The solution? Independently verify that the firmware running on your device matches the public source code exactly. This tutorial guides you step by step through this verification process for the major hardware wallets on the market.
1. Why Verify Your Firmware?
Understand the real threats that target your device
1.1 The risk of supply chain attacks
A supply chain attack targets the distribution chain rather than the end user:
| Vector | Description | Example |
|---|---|---|
| Postal interception | The device is modified during transit | Firmware replaced before delivery |
| Malicious reseller | Purchase through an unofficial channel | Device pre-configured with a seed known to the attacker |
| Manufacturer compromise | Attack on the manufacturer's infrastructure | Official firmware itself compromised |
Documented real-world cases:
- In 2020, counterfeit Ledger devices were sent to customers after their database was leaked
- Modified Trezor units with additional chips were identified on the secondary market
1.2 The risk of compromised updates
Every firmware update is an opportunity for an attacker:
- Infrastructure attack: Compromise of distribution servers
- MITM attack: Interception of the connection during download
- Social engineering: Fake urgent update distributed via phishing
1.3 Open source vs closed source
The ability to verify firmware depends on its open source status:
| Device | Firmware | Verification possible |
|---|---|---|
| Trezor | 100% open source | ✅ Complete |
| Coldcard | Open source (application) | ✅ Complete |
| SeedSigner | 100% open source | ✅ Complete |
| BitBox02 | Open source | ✅ Complete |
| Ledger | Closed source (Secure Element) | ⚠️ Partial |
Key point: With open source firmware, you can compile the code yourself and compare the result with what is installed on the device. With closed source, you must trust the manufacturer.
2. Trezor Firmware Verification
Compile the source code yourself to guarantee its authenticity
The Trezor is entirely open source, which allows for complete verification.
2.1 Prerequisites
- A computer running Linux, macOS, or Windows with WSL
- Git installed
- Docker (for reproducible compilation)
- Your Trezor connected
2.2 Step 1: Download the source code
# Clone the official repository
git clone https://github.com/trezor/trezor-firmware.git
cd trezor-firmware
# Check out the version matching your firmware
# Check the version on your Trezor: Settings > Device > Firmware Version
git checkout core/v2.6.4 # Replace with your version
2.3 Step 2: Verify GPG signatures
Official releases are signed by Trezor developers.
# Import the developers' public keys
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys \
86E6792FC27BFD478860C11091F3B339B9A02A3D \
F2BBD5F2B8C6B8B8C6B8B8C6B8B8C6B8B8C6B8B8 # Example - verify on trezor.io
# Verify the tag signature
git verify-tag core/v2.6.4
The result must display "Good signature from" followed by the name of a known Trezor developer.
2.4 Step 3: Compile the firmware (Docker)
Trezor uses reproducible builds via Docker:
# Build the Docker environment
docker build -t trezor-build .
# Run the compilation
docker run -it --rm -v $(pwd):/src trezor-build \
bash -c "cd /src && poetry install && poetry run make -C core build_firmware"
The compilation produces a binary file in core/build/firmware/firmware.bin.
2.5 Step 4: Compare with the installed firmware
Get the hash of the installed firmware:
Use the trezorctl tool:
# Install trezorctl
pip install trezor
# Get firmware information
trezorctl get-features
Calculate the hash of the compiled firmware:
sha256sum core/build/firmware/firmware.bin
Compare the two hashes:
If the hashes match, your firmware is identical to the verified source code. If they differ, something is wrong -- do not continue using the device.
2.6 Command recap
# 1. Clone
git clone https://github.com/trezor/trezor-firmware.git && cd trezor-firmware
# 2. Checkout version
git checkout core/v2.X.X
# 3. Verify signature
git verify-tag core/v2.X.X
# 4. Compile
docker build -t trezor-build . && \
docker run -it --rm -v $(pwd):/src trezor-build \
bash -c "cd /src && poetry install && poetry run make -C core build_firmware"
# 5. Hash
sha256sum core/build/firmware/firmware.bin
3. Coldcard Firmware Verification
Verify GPG signatures and hashes to validate your firmware
The Coldcard uses a different approach: verification is performed via SD card and command-line tools.
3.1 Prerequisites
- Python 3 installed
- The
ckcc-protocoltool from Coinkite - Firmware downloaded from coldcard.com
3.2 Step 1: Download the official firmware
Go to coldcard.com/docs/upgrade and download:
- The firmware file (
.dfu) - The signature file (
.txtor.asc)
3.3 Step 2: Verify the signature
Coinkite signs each firmware with their GPG key.
# Import the Coinkite public key
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys \
A3A31BAD5A2A5B10D6B8E8F5E6C2E6D9F8A8B0C0 # Verify the exact ID on coldcard.com
# Verify the signature
gpg --verify firmware-signature.txt firmware-X.X.X.dfu
3.4 Step 3: Use verify.py
Coinkite provides a Python tool to verify the firmware:
# Install the tool
pip install ckcc-protocol
# Verify the firmware
ckcc verify firmware-X.X.X.dfu
3.5 Step 4: Verification via SD card
The simplest method for non-technical users:
- Copy the
.dfufile to a microSD card - Insert the card into the Coldcard
- Navigate to: Advanced > Upgrade > From SD Card
- The Coldcard displays the file hash
- Compare with the hash published on coldcard.com
3.6 Verifying the currently installed firmware
On the Coldcard, navigate to:
Advanced > View Identity > My Fingerprint
This fingerprint must match the one documented for your firmware version.
3.7 Compile from source (advanced)
For technical users:
# Clone the repository
git clone https://github.com/Coldcard/firmware.git
cd firmware
# Verify the tag
git checkout v5.X.X
git verify-tag v5.X.X
# Compile (requires the ARM environment)
make setup
make all
4. The Ledger Case: Limitations of Closed Source
Discover what you CANNOT verify with a proprietary Secure Element
4.1 Ledger architecture
The Ledger uses a two-part architecture:
| Component | Description | Open Source |
|---|---|---|
| BOLOS | Secure Element operating system | ❌ No |
| Applications | Bitcoin, Ethereum apps, etc. | ✅ Yes |
| Ledger Live | Desktop/mobile software | ✅ Yes |
The core of the problem: the Secure Element runs proprietary code that no one can audit.
4.2 What can be verified
Applications (partially):
- The application code (Bitcoin app, etc.) is on GitHub
- You can compile and compare the hashes
- But loading onto the device goes through BOLOS (closed source)
Ledger Live:
- The code is open source on GitHub
- You can compile your own version
- Verifies application signatures
4.3 What cannot be verified
- The BOLOS operating system
- The actual behavior of the Secure Element
- The absence of hardware backdoors
4.4 Why this is problematic
Without access to the Secure Element code, you must trust Ledger regarding:
- The absence of voluntary or coerced backdoors (government pressure)
- Code quality and the absence of vulnerabilities
- The fact that generated keys are truly random
4.5 Verifications still possible
Device attestation:
Ledger Live verifies that the device is authentic via a certificate signed by Ledger:
- Connect your Ledger to Ledger Live
- Access the device settings
- Click "Check authenticity"
This verification confirms that the device comes from the Ledger factory, but not that the firmware is sound.
Verify applications:
# Clone the application repository
git clone https://github.com/LedgerHQ/app-bitcoin.git
cd app-bitcoin
# Compile (requires the Ledger SDK)
make
# Compare the hash of the compiled application
# with the one installed on the device
4.6 Recommendation
For users who prioritize verifiability, prefer:
- Coldcard or Trezor as primary signers
- The Ledger can serve as a backup key in a multisig setup
- Avoid relying solely on a Ledger for significant amounts
5. Firmware Update Best Practices
Adopt a cautious approach to new firmware versions
5.1 Never update automatically
| Practice | Recommendation |
|---|---|
| Automatic updates | ❌ Disable |
| Update notifications | ✅ Enable |
| Delay before updating | ✅ Wait 1-2 weeks |
Why wait?
- The community can detect issues
- Vulnerabilities in new versions can be discovered
- In case of manufacturer compromise, time allows for detection
5.2 Pre-update checklist
Before applying any firmware update:
- Verify the official announcement (website, Twitter, GitHub)
- Search for discussions on Reddit, Twitter, forums
- Wait 1-2 weeks after release
- Verify the GPG signature of the firmware
- Make sure you have access to your seed phrase (in case of problems)
- Test on a secondary device if possible
5.3 When in doubt
If something seems suspicious:
- Do not update -- Wait for more information
- Reach out to the community -- Reddit, Twitter, dedicated forums
- Check official sources -- Website, GitHub, verified social accounts
- Consider a new device -- If compromise is suspected
5.4 Secure update procedure
For Trezor:
- Download the firmware from GitHub (not directly from Trezor Suite)
- Verify the GPG signatures
- Use
trezorctlto flash:trezorctl firmware-update -f firmware.bin
For Coldcard:
- Download from coldcard.com
- Verify the signatures
- Transfer via SD card
- Apply from the menu: Advanced > Upgrade
For Ledger:
- Verify official announcements
- Wait a few days
- Update via Ledger Live
- Verify attestation after updating
6. Verification Comparison Table
Evaluate at a glance the verification capabilities per device
| Aspect | Trezor | Coldcard | Ledger |
|---|---|---|---|
| Source code | 100% open | Mostly open | Apps open, OS closed |
| Reproducible build | ✅ Yes (Docker) | ✅ Yes | ⚠️ Partial (apps) |
| GPG signature | ✅ Yes | ✅ Yes | ✅ Yes |
| Hash verification | ✅ Complete | ✅ Complete | ⚠️ Partial |
| Device attestation | ❌ No | ⚠️ Basic | ✅ Yes |
| Auditable Secure Element | N/A | ⚠️ Partial | ❌ No |
FAQ
Q1: Is firmware verification really necessary for an individual?
For the majority of users purchasing directly from the manufacturer, the risk is low. However, verification becomes crucial if you:
- Bought second-hand or through a third-party reseller
- Hold significant amounts (>10,000 EUR)
- Are a potential target (public figure, crypto personality)
- Have professional security requirements
Q2: What should I do if verification fails?
- Do not transfer funds to this device
- Do not reveal any seed phrase to the device
- Contact the manufacturer with the details
- Consider the device as potentially compromised
- Purchase a new device through the official channel
Q3: Do reproducible builds guarantee 100% security?
No. They guarantee that the compiled code matches the published source code. But:
- The source code itself could contain vulnerabilities
- The compiler could be compromised (a "Ken Thompson" attack)
- The hardware could have backdoors
Reproducible builds are an essential verification layer, not an absolute guarantee.
Q4: Can I verify firmware on Windows?
Yes, but it is more complex. Recommendations:
- Use WSL2 (Windows Subsystem for Linux) for Linux commands
- Install Docker Desktop for compilation
- Or use a Linux virtual machine
Q5: Should I verify with every update?
Ideally yes. In practice, do it at minimum:
- On first use of a new device
- After any major update
- If you have doubts about the integrity
- Periodically (every 6-12 months)
Related Articles -- Technical Security
- Multisig 2-of-3 Bitcoin Tutorial
- SeedSigner DIY Complete Tutorial
- Passphrase 25th Word Bitcoin
- Coldcard Air-Gapped Bitcoin Guide
Resources and Tools
Official GitHub repositories
| Manufacturer | Firmware | Applications |
|---|---|---|
| Trezor | github.com/trezor/trezor-firmware | Included |
| Coldcard | github.com/Coldcard/firmware | github.com/Coldcard/ckcc-protocol |
| Ledger | - | github.com/LedgerHQ/app-bitcoin |
| SeedSigner | github.com/SeedSigner/seedsigner | Included |
| BitBox02 | github.com/digitalbitbox/bitbox02-firmware | Included |
Official GPG keys
- Trezor: trezor.io/security
- Coldcard: coldcard.com/docs/verify
- Ledger: ledger.com/pgp
Verification tools
- GPG: gnupg.org
- SHA256: Built into Unix systems (
sha256sum) - Docker: docker.com
- trezorctl:
pip install trezor - ckcc-protocol:
pip install ckcc-protocol
Conclusion
Verifiability is the price of true digital sovereignty
Firmware verification is an advanced but accessible security practice. For users who are serious about minimizing their dependence on manufacturers, it is an essential step.
Key points to remember:
- Prefer open source devices (Trezor, Coldcard, SeedSigner)
- Always verify GPG signatures before updating
- Wait a few days before applying a new version
- If you cannot fully verify (Ledger), use it in a multisig setup with verifiable devices
- Verification takes time, but your bitcoins are worth it
Internal Links
Complete your security arsenal with these essential resources
- Coldcard Air-Gapped Guide -- Complete Coldcard configuration
- Build Your Own SeedSigner -- A 100% verifiable hardware wallet
- Multisig 2-of-3 -- Diversify your signers
- The Passphrase (25th Word) -- An additional layer of security
- Travel Rule and Transfers -- Regulatory context
Sources
Official documentation
- Trezor Security: trezor.io/security
- Coldcard Docs: coldcard.com/docs
- Ledger Security: ledger.com/academy/security
Research and analyses
- Wallet.fail: Security presentations on hardware wallets
- Kraken Security Labs: Vulnerability analyses
- Ledger Donjon: Internal Ledger research (partially open source)
Community
- Bitcoin Stack Exchange: bitcoin.stackexchange.com
- Reddit r/Bitcoin: Discussions and user feedback
- Twitter/X: Security researcher accounts
Article written in December 2025. Commands and procedures may evolve with new firmware versions. Always consult the official documentation for up-to-date instructions.