Verifying KeepKey Firmware
"Don't trust — verify."
The reason a hardware wallet is trustworthy is not that the company says so. It's that the firmware running on the device is open source, reproducibly built, and cryptographically signed — and that anyone in the world can confirm the signed binary on the device matches the public source code. This guide walks you through that verification, end to end.
What you're proving
When you connect a KeepKey, three things have to be true for the device to be trustworthy:
- The screen shows the real address you're sending to (no swap-the-address-at-signing-time attack).
- Your private keys stay on the device and never leak to the host or to the developers.
- The firmware enforces only the behaviors described in the public source code.
You cannot verify any of those by inspecting the device. You can only verify them by reading the source, building it yourself, and confirming the binary you built matches the binary running on the device.
The KeepKey firmware repository is open: github.com/keepkey/keepkey-firmware. It has been peer-reviewed by independent researchers for years. What this guide adds is the missing link — the proof that what's on your device is what's in that repository.
The verification process — overview
- Compile the firmware locally from the tagged release commit
- Hash the compiled binary with SHA-256
- Hash the official released binary the same way
- Compare — they should match exactly
If the hashes match, the published binary is exactly what the public source produces. If they don't, something has been altered between source and release, and you should not flash that binary.
Prerequisites
- Docker — the build runs inside a container so the toolchain version is pinned
- Git — to clone the repository and check out the release commit
- A few GB of disk space and ~10 minutes of compile time
You do not need to install an embedded toolchain locally. The Docker build script handles all of that.
Step 1 — Clone and check out the release
git clone https://github.com/keepkey/keepkey-firmware cd keepkey-firmware
Find the release you want to verify on the releases page. Each release has a tag and a commit hash:
Check out that exact commit:
git checkout 39db6942e62c5f63c3e6cf3a0cd35155bae62914
(Replace the hash with the one from the release you're verifying.)
Pull in the submodules — the firmware depends on several pinned dependencies that live in their own repos:
git submodule update --init --recursive
Step 2 — Build the firmware
Run the Docker build script:
./scripts/build/docker/device/release.sh
This produces
./bin/firmware.keepkey.binStep 3 — Hash both binaries
Hash your locally compiled binary:
tail -c +257 ./bin/firmware.keepkey.bin | shasum -a 256
Example output:
f83934f0bb88515712d98448c3ff91989d9ff28c1658245ca01ae45c2bd0a599 -
Now download the matching binary from the GitHub release (the
firmware.keepkey.bintail -c +257 firmware.keepkey.bin | shasum -a 256
f83934f0bb88515712d98448c3ff91989d9ff28c1658245ca01ae45c2bd0a599 -
Step 4 — Compare
The two hashes must match exactly. If they do, you have just proven that the published binary is bit-for-bit identical to what the public source code produces — meaning the device flashing this firmware can only do what the open-source code says it does.
If they don't match, something is off. Most often it's a build environment mismatch (wrong commit, missing submodule, wrong Docker tag). Re-run the steps above carefully. If they still don't match, post the discrepancy on the firmware repo's issues page and do not flash that binary.
What this proves and what it doesn't
It proves:
- The released firmware was built from the public source.
- No backdoor was inserted between source and binary.
- Your device, when flashed with this firmware, runs exactly the code in the repo.
It doesn't prove:
- That the source code itself is bug-free. (Read the code; it has been peer-reviewed for years, but you should still satisfy yourself.)
- That your current device firmware is the verified version. (You also need to confirm the version installed matches — see Updating your KeepKey.)
- That your computer isn't compromised in a way that fakes everything you're seeing. (No verification scheme defends against a fully owned host.)
In other words, reproducible builds give you the strongest available trust chain from "publicly auditable source" to "binary on the device" — but that chain still rests on the integrity of the host you ran the verification on.
Why this matters
A KeepKey is a hardware wallet because the device, not the computer, performs the security-critical operations: deriving keys, displaying addresses, signing transactions. If the firmware running on the device cannot be independently verified, that property is a marketing claim rather than a technical guarantee.
Reproducible builds collapse that gap. They turn "trust the company" into "trust the math." That's the whole point.
After verifying — flashing with Vault Desktop
Once you've verified a release is legitimate, the practical way to install it is via KeepKey Vault Desktop, which checks signatures on the device automatically and walks you through the bootloader flow if needed.
- Download Vault Desktop from keepkey.com/desktop
- Plug in the KeepKey
- Vault Desktop detects the running firmware version and offers the update
- Confirm the install on the device's screen
Detailed walkthrough: Updating your KeepKey.
Related
- Updating your KeepKey — the practical install flow in Vault Desktop
- 5 Myths About Hardware Wallets — why open-source firmware matters
- keepkey-firmware on GitHub — the source you're verifying
Get a KeepKey at keepkey.com