Part 3: Vaults across devices
Part 3 of 5 in a deep dive on hardware wallets, randomness and the vaults behind every device. Start with Part 1 if you are new to the series.
The hardware vault family: from shared silicon to dedicated chips
"Hardware security" covers at least five architectures with very different isolation guarantees. What matters is how much each vault shares with the code an attacker is most likely to control.
| Vault | Isolation model | Typical certification | Where it lives | What it is good at |
|---|---|---|---|---|
| Trusted Execution Environment (Arm TrustZone, e.g. Android's Trusty/QSEE) | Same CPU cores and memory, separated by a hardware "secure world" mode | Rarely certified as a whole | Most Android phones, IoT | Cheap, fast key operations; vulnerable to CPU side channels and TEE OS bugs |
| Integrated secure subsystem (Apple Secure Enclave, Google Titan M2, Samsung Knox Vault) | Dedicated security core with its own boot ROM, RNG, and crypto engines; encrypted memory region | Vendor-specific, some FIPS 140 validation | iPhone, Mac, Pixel, Galaxy | Biometrics, disk encryption keys, passkeys, app keys |
| TPM 2.0 (discrete, firmware, or Microsoft Pluton) | Standardized module for measured boot and key storage; discrete chip or firmware in the CPU | TCG, FIPS 140-2/3, CC EAL4+ | Windows PCs, servers | Device identity, BitLocker, attestation; slow and limited curve support |
| Secure element (smart-card class silicon) | Separate tamper-resistant chip with glitch, laser, and probing countermeasures | Common Criteria EAL5+ to EAL6+ | SIM, EMV cards, passports, Apple Pay eSE, YubiKeys, hardware wallets | Small, slow, but designed to survive physical attackers with lab equipment |
| Hardware Security Module (HSM) | Standalone appliance or cloud service with tamper-responsive enclosure | FIPS 140-3 Level 3, PCI PTS HSM | Banks, card networks, custodians, cloud KMS | High-throughput signing, key ceremonies, quorum-based administration |
I separate them on two axes.
The first is physical attacker resistance. A TEE assumes the attacker is software. A secure element assumes the attacker has the device on a lab bench with a voltage glitcher, a laser, and an oscilloscope. Common Criteria evaluation at AVA_VAN.5 (the "high attack potential" level behind EAL5+ and EAL6+ claims) is the formal expression of that assumption, and it is why banks and passport agencies have used secure elements for decades.
The second is policy ownership. Every vault enforces a policy around its keys: who can use them, under what conditions, with what user presence. In a TEE or Secure Enclave, the platform owner (Apple, Google, Microsoft) writes that policy and the OS mediates every request. In a hardware wallet, the device itself owns the policy and shows the user exactly what it is about to sign. I believe this is the core reason hardware wallets exist as a separate category.
Apple's Secure Enclave shows how far integrated vaults have come. Apple documents a dedicated processor running an L4-based sepOS, an inline memory encryption engine with anti-replay protection, and a TRNG built from multiple ring oscillators post-processed with CTR_DRBG that is used whenever the Enclave creates a key or seed. Since the A9, the device's root UID key is generated by that TRNG during manufacturing and fused into the chip, so neither Apple nor its suppliers ever see it.
How the vaults are used across devices
The same building blocks are deployed very differently depending on what the device is optimizing for. Phones and laptops optimize for usability and platform-controlled policy. Hardware wallets and HSMs optimize for isolation and explicit approval.
| Device | Vault | Entropy source | Keys it protects | Who sets signing policy | secp256k1 in hardware? |
|---|---|---|---|---|---|
| iPhone / iPad | Secure Enclave (+ discrete eSE for Apple Pay) | Ring-oscillator TRNG + CTR_DRBG | Data protection keys, Face ID/Touch ID templates, device-bound P-256 keys, payment tokens | Apple (iOS + sepOS) | No |
| MacBook (Apple silicon or T2) | Secure Enclave in the SoC or T2 | Same as iPhone | FileVault volume keys, Touch ID, keychain, passkeys | Apple (macOS) | No |
| Android flagship (Pixel, Galaxy) | TEE (TrustZone) + StrongBox secure chip (Titan M2, Knox Vault) | Chip TRNG feeding Keystore | Disk encryption, Keystore keys, biometrics, Android Pay tokens | Google / OEM | No |
| Windows PC | TPM 2.0 (discrete, firmware, or Pluton) | TPM RNG | BitLocker, Windows Hello, device certificates | Microsoft / OEM | No |
| FIDO security key (YubiKey, Titan Key) | Secure element | SE TRNG | FIDO2/WebAuthn credentials, PIV, OpenPGP | Key vendor firmware + user PIN/touch | Typically no (P-256, Ed25519) |
| Hardware wallet (Ledger, Trezor Safe, Coldcard, Keystone) | Secure element, often paired with a general MCU | SE TRNG, sometimes mixed with MCU or user dice entropy | BIP-39 seed and all derived chain keys | Device firmware + on-screen user approval | Yes |
| HSM / cloud KMS | FIPS 140-3 Level 3 module | Certified internal RNG | Issuer keys, PIN keys, custody signing keys | Institution, via quorum and policy engine | Varies; many now support it |
Phone vaults cannot hold Bitcoin or Ethereum keys. Apple's Secure Enclave can only hold NIST P-256 keys for classical elliptic-curve signing, and CryptoKit does not support secp256k1 at all. Android StrongBox has the same practical limit. That means a mobile crypto wallet cannot generate or sign with a Bitcoin or Ethereum key inside the phone's vault. The workaround is to keep a P-256 key in hardware, use it to encrypt the secp256k1 key at rest, and decrypt that key into app memory at signing time. The vault protects the key while the phone is locked, but not while the wallet is signing on a potentially compromised OS. A hardware wallet closes that window.
Passkeys show the other side of the trade-off. Because P-256 is native to Secure Enclave and StrongBox, passkeys and smart-contract wallets that verify P-256 signatures can use phone hardware directly. But synced passkeys in iCloud Keychain or Google Password Manager are, by design, not bound to a single chip. Platform vendors chose recoverability over strict non-exportability. That is the right choice for consumer login and a different choice from what a cold-storage seed needs.
Secure elements fail too, but breaking one takes a lab. In 2024 NinjaLab's EUCLEAK research showed that Infineon's ECDSA library leaked through an electromagnetic side channel, allowing extraction of the private key from a YubiKey 5 with firmware below 5.7. The same library was used in Infineon TPMs and the Optiga Trust M family. The attack required physical access, disassembly, and lab equipment, and NinjaLab itself concluded a YubiKey remained safer than no hardware token. I read this as the secure element model working as intended, because the attack cost rose from "remote malware" to "steal the device, open it, and return it unnoticed."
The list of trusted keys is policy too. When eMudhra's intermediate keys were exposed, every platform had to block them separately. Apple began blocking the compromised certificates on 19 October and delivered the block automatically. JetBrains warned that its IDEs check certificates against the trust store of their own bundled runtime, so updating the operating system did not protect developers. The question is the same one this piece asks about signing keys: who sets the policy for which keys a device trusts, and how fast that policy can change.
Continue to Part 4: Inside a hardware wallet