TL;DR: “Keys never leave the silicon”, “you must hold the physical device” is a trust claim, not a cryptographic proof. A provable hardware wallet uses cryptography to make it verifiable. No consumer product does this today, but the primitives exist.
In Web3, a hardware wallet is a dedicated device that stores private keys in isolation from the host machine. Manufacturers describe this isolation with the claim that keys “never leave the device.” This post examines whether that claim can be made verifiable through cryptographic proof, what the required construction looks like, and how close current systems come to realizing it.
Use Case
The core benefit of a provable hardware wallet is the following guarantee: signing requires physical possession of the device, provably, in the past and in the future.
A private key stored on paper or in software can be copied silently. Any number of parties may hold a copy without the original owner knowing. A signature produced by that key proves nothing about who signed or when the key was compromised: it only proves that someone, at some point, held the key material.
A hardware-bound key changes this. If the key was generated inside hardware and cryptographically cannot leave it, then every past and future signature implies that the signer had physical control of the device at signing time. The device becomes the unforgeable proof of authorization.
This matters for anyone who needs to reason about signing accountability: who can authorize a transaction, who did authorize a past transaction, and whether that authorization was exclusive. It matters for individuals who want certainty that no silent copy of their key exists, for counterparties who need to know that a signature required physical presence, and for systems that need to enforce policies based on physical custody rather than key possession alone.
A further consequence is verifiable transfer of sole custody. If I hand a provable hardware wallet to someone else, I can cryptographically demonstrate that I no longer hold the key: because the key never existed outside the device, giving away the device is giving away the only copy. With a paper wallet or a seed phrase, handing over a copy proves nothing—the original owner could have retained another copy, and there is no way to disprove it. With a hardware-bound key, the transfer is provable: once the device leaves my hands, I verifiably have no signing capability left. This makes the concept relevant for asset sales, inheritance, escrow arrangements, and any situation where the transfer of exclusive control must be demonstrated to a third party.
Required Properties
A provable hardware wallet must satisfy three properties simultaneously.
Property 1: Hardware-bound key generation. The private key must be generated inside the secure hardware. A key generated outside and then imported into hardware with a seed phrase, carries no guarantee about how many copies are made before or after import. Generation must originate inside the trusted boundary.
Property 2: Verifiable non-exportability. A third party must be able to verify, through a cryptographic proof, that the private key cannot exit the hardware. This proof must be inspectable by anyone who holds the corresponding public key, without requiring access to the device itself.
Property 3: Auditable execution. The code that generates and manages the key must be inspectable. Without code auditability, the proof of hardware execution says nothing about whether the code itself exports the key through a covert channel. An attestation over secret or proprietary code is not sufficient.
These three properties together constitute provability. Current hardware wallets satisfy the first property in practice but not the second or the third.
Possible Implementation Paths
Three constructions can realize the three required properties, with different trust tradeoffs.
Path 1: TEE remote attestation. An open-source program runs inside a Trusted Execution Environment (Intel SGX, AMD SEV-SNP, or AWS Nitro Enclaves) and generates the key pair inside the enclave boundary, memory that is encrypted and inaccessible to the host OS, hypervisor, or any outside code. At generation time, the enclave produces a remote attestation report binding the measurement hash of the running code to the freshly generated public key, signed with the hardware’s attestation key. Any verifier can check this report against the manufacturer’s root certificate and, if the code is open source, audit that it never exports the private key. This is the most mature path, but it roots trust in the CPU manufacturer’s attestation key.
Path 2: Threshold key generation across attested enclaves. Instead of one device holding the full key, the key is generated as shares distributed across multiple independent attested TEEs or HSMs, following the NXK (Non-eXportable Key) construction of Sehrawat [2]. No single enclave, manufacturer, or compromised device can reconstruct the key, and each share’s non-exportability is individually attested. This reduces single-manufacturer trust at the cost of requiring multiple devices and an interactive signing protocol.
Path 3: Secure element with a zero-knowledge proof of correct generation. A certified secure element, of the kind used in Ledger or YubiKey-class devices, generates the key internally and produces a zero-knowledge proof that the key was generated by a published algorithm and never exposed on any output channel, without relying on a CPU vendor’s remote-attestation root. This avoids the silicon-manufacturer dependency of Path 1, but requires a ZK circuit for the key-generation procedure, which remains an open implementation challenge.
Each path turns the claim “this key is only on hardware” from an assertion into a verifiable statement, with the choice of path determined by which trust dependency (CPU manufacturer, multi-device protocol, or ZK tooling maturity) is acceptable.
Discussion
Trust in the silicon manufacturer. Remote attestation is rooted in a hardware key provisioned by the CPU manufacturer (Intel, AMD, Amazon) at fabrication. The security guarantee is contingent on trusting this manufacturer. A compromised root key, a backdoored attestation service, or a fabrication-time implant would break the guarantee. This is a fundamental limit shared with all HSM-based security.
Side-channel vulnerabilities. SGX enclaves have been broken by multiple microarchitectural attacks (Foreshadow in 2018, SGAxe in 2020, Plundervolt in 2019) that extract secrets without detection by the enclave code. AMD SEV-SNP and Intel TDX address some of these vectors through stronger isolation, but their research record is shorter. A provable hardware wallet must be paired with hardware that has a credible and continuously maintained side-channel resistance profile.
Open-source code is necessary. The attestation proves that code with hash H ran inside the enclave. The verifier can confirm behavior only if H is published and the code is auditable. Proprietary enclave code provides authenticity (this code ran here) but not correctness (this code does not export the key). Open source is a prerequisite for the security argument to hold.
Comparison with HSMs. Hardware Security Modules
certified under FIPS 140-2/3 Level 3 or 4 provide non-exportability
guarantees enforced through physical tamper resistance evaluated by an
accredited laboratory. They do not in general produce a remote
attestation statement that a given public key was generated inside a
specific codebase and is non-exportable. Certified HSMs rely on the
evaluation process for trust; provable hardware wallets rely on
cryptographic proof exportable to arbitrary verifiers. In practice, HSM
non-exportability is implemented via the PKCS#11
CKA_EXTRACTABLE=false attribute. Certification relies on
either a remote attestation certificate from the HSM vendor (e.g.,
Google Cloud HSM) or, when that is unavailable (e.g., AWS CloudHSM), a
manual “Key Generation Ceremony” witnessed by an independent auditor (SSL.com, “Bring Your Own
Auditor”). This manual procedure is exactly the kind of trust-based
verification a provable hardware wallet replaces with a cryptographic
proof inspectable by any third party. The NXK (Non-eXportable Key)
setting formalized by Sehrawat [2] captures this distinction
precisely.
Does It Exist Today?
Consumer hardware wallets do not implement remote attestation. Ledger devices use secure elements (ST33, SE050) and Trezor uses a microcontroller with firmware verification. These enforce physical resistance to extraction but do not produce attestation statements a remote party can verify independently.
Ledger. Ledger devices store private keys in a certified secure element (ST33 or SE050), satisfying Property 1. The firmware is partially proprietary: the BOLOS operating system and secure element code are not fully auditable, so Property 3 does not hold. Ledger does not implement remote attestation, so Property 2 does not hold either. The Ledger Recover feature (firmware 2.2.1, May 2023), which splits and transmits the seed off the device, demonstrates that non-exportability depends on Ledger’s firmware policy rather than on a verifiable cryptographic guarantee.
Trezor. Trezor devices (Model One and Model T) use a general-purpose microcontroller (STM32) and publish their full firmware as open source, satisfying Property 3. They do not use a hardware-isolated secure element, so the private key resides in standard flash memory. Physical access is sufficient to extract keys through fault injection or direct memory access, as demonstrated by Kraken Security Labs in 2020. Property 1 holds in practice, but Property 2 does not: there is no remote attestation and no silicon-level isolation. Trezor trades hardware isolation for software transparency, the inverse of Ledger’s tradeoff. Neither device satisfies all three properties.
YubiHSM. The YubiHSM 2 generates and stores keys
with the PKCS#11 CKA_EXTRACTABLE=false attribute, and the
FIPS 140-2 Level 3 validated variant gives this non-exportability a
laboratory-evaluated certification, satisfying Property 1 and the
certification-based reading of Property 2. However, like other certified
HSMs, YubiHSM does not produce a remote attestation report binding a
specific open-source codebase to a specific generated key:
non-exportability is a property the device asserts and a lab has
evaluated, not one a remote third party can cryptographically verify.
Property 2 in the cryptographic-proof sense and Property 3 do not
hold.
TEE-based key management services are the closest existing realization of the concept. Turnkey uses AWS Nitro Enclaves with remote attestation: users can verify through a published attestation chain that their keys are managed by a specific, versioned codebase running inside a genuine Nitro Enclave. Lit Protocol uses TEE-based nodes and publishes attestation data allowing independent verification. These systems target programmable, server-side key management rather than the user-held model of a hardware wallet, but the underlying cryptographic construction implements the proposed scheme.
No consumer-grade, self-custodal product currently combines all three required properties: key generation inside a TEE, remote attestation exported to the user, and open-source auditable enclave code. The technical components exist; the integrated product does not.
Related Work
Hardjono [1] develops the same core argument: a standard challenge-response protocol proves only that someone possesses a private key, not where that key resides or whether it has been copied. Hardjono formalizes three required properties—key generation inside trusted hardware, invisibility of the private key to the owner, and non-exportability—and argues that attestation services based on TPM hardware are a necessary component of regulated private wallet infrastructure. The focus is on institutional and compliance use cases rather than consumer self-custody, and the construction relies on the TPM key hierarchy rather than TEE remote attestation, but the underlying security goals are identical to those described here.
Sehrawat [2] formalizes the Non-eXportable Key (NXK)
setting, where private key shares are held inside hardware-backed
isolation modules (TEEs or HSM-like APIs) and cannot leave that
boundary. It introduces an ideal KeyBox functionality that
abstracts over the hardware enforcement and permits only attested
device-to-device sealing. The construction is applied to threshold
wallets for multi-device signing schemes. The paper is primarily a
cryptographic protocol contribution rather than a systems paper, but it
provides a formal framework for reasoning about hardware-bound key
non-exportability that is directly relevant to the properties described
here.
Conclusion
A provable hardware wallet is a system that generates a private key inside a Trusted Execution Environment and produces a remote attestation report allowing any third party to verify that the key was generated by auditable code inside genuine hardware. The claim “this key is only on hardware” becomes a verifiable cryptographic statement rather than a trust assumption about the manufacturer.
The required primitives are available today: remote attestation in Intel SGX, AMD SEV-SNP, and AWS Nitro Enclaves; open-source enclave frameworks; and the IETF RATS attestation verification standard. TEE-based key services such as Turnkey and Lit Protocol implement this model for server-side custody. The gap is in consumer self-custody products, where the hardware wallet market has not adopted remote attestation. Closing this gap would replace trust-in-manufacturer with trust-in-hardware-and-verifiable-code, a meaningful and achievable improvement for users who require strong, auditable guarantees about key custody.
Martin Monperrus March 2026
References
[1] T. Hardjono, “Attestation Infrastructures for Private Wallets,” arXiv:2102.12473, 2021.
[2] V. Sehrawat, “UC-Secure Star DKG for Non-Exportable Key Shares with VSS-Free Enforcement,” arXiv:2602.22187, 2026.