Search hardware wallet comparisons and you'll hit the same line about Jade: no secure element. It's usually stated as a verdict rather than a question, which is a shame, because the question underneath it is a good one. How does any device stop someone from guessing a six-digit PIN?
Jade answers it with a “virtual” Secure Element, a design that splits the ability to decrypt your wallet across two separate places. Neither one can do it alone. Here's how that works, and what an attacker actually walks away with at every point they might try.
What a Secure Element Chip Does for Your PIN
A dedicated secure element chip does three jobs:
- It stores key material in silicon built to resist physical probing.
- It limits how many PIN attempts you get before the device wipes.
- It checks the PIN internally, so the PIN itself is never exposed to the rest of the device.
Those are the goals. A secure element chip is one way to reach them. Jade reaches all three by splitting the work between the device in your hand and a server that knows nothing about you.
Two Keys, One Box
Picture an old safe-deposit box, the kind that needs two keys turned together: yours and the bank's. Neither key opens it alone.
Your recovery phrase sits encrypted on Jade. The key that decrypts it isn't stored anywhere, on the device or off it. It's derived fresh every time you unlock, from two ingredients that live in different places. One is the PIN you type on Jade's own buttons. The other is a secret held by a blind oracle, a server that holds half the arrangement and can't see the other half. Blockstream runs one. You can run your own on a laptop or a Raspberry Pi, over Tor if you want, because the oracle is open source too.
What the oracle never receives is your PIN. Jade sends a scrambled derivative of it, mixed with a key unique to that device and generated on it. No firmware path exports that device key, and without it the derivative is meaningless. Blockstream runs the oracle and still can't work backward to your PIN.
What Happens When You Unlock Jade
- You type your PIN on Jade itself, never into your computer and never into an app.
- Jade sends its scrambled derivative to the oracle, relayed by your companion app, which acts as a messenger and can't read what it's carrying.
- The oracle checks the derivative against the record it holds for that device. If it matches, the oracle returns its half of the arrangement, and Jade combines that with your PIN to build the decryption key.
- If it doesn't match, both sides count a strike. On the third wrong PIN, both destroy their copies. Jade wipes its encrypted wallet, and the oracle overwrites its share and deletes the record.
Jade also supports a duress PIN. Enter it and the device erases its keychain and shuts down. Nothing on the device suggests a second PIN ever existed.
What an Attacker Actually Gets
A security design is worth what an attacker fails to walk away with. Here are the five ways in.
A thief steals your Jade and extracts the flash. Assume they succeed completely. They get an encrypted blob and the device's unit key. What isn't on the chip is the oracle's share, and there's no way to test a candidate PIN without it. There's nothing to sit in a lab and brute-force, because the math doesn't resolve without the oracle.
So the thief goes to the oracle. It answers three times. The attempt counter lives on the server, so holding the device gives an attacker no way to reset it, glitch it, or wait it out. On the third miss the oracle deletes its share and the encrypted blob becomes permanently undecryptable, which leaves an attacker three guesses at a six-digit PIN before the wallet is gone for good.
The companion app, or the computer running it, is malicious. It relays encrypted traffic it can't read and can't forge, and it never touches your PIN, because you typed that on Jade. It can refuse to pass messages along, which stops you from unlocking but gets it no closer to your keys.
The oracle is breached, or Blockstream turns hostile. The attacker gets a pile of key shares and a table of scrambled PIN derivatives. Neither is usable. The derivatives reveal nothing without each device's unit key and each owner's PIN, and a key share on its own opens no wallet. The oracle can deny you access. It can never spend your bitcoin, and your recovery phrase restores the wallet without it.
Someone taps the network. Every attempt runs over a fresh encrypted session with a monotonic anti-replay counter, so captured traffic can't be replayed and old responses can't be recycled.
Every one of those paths stalls in the same place, because each needs two secrets that are never held by the same party.
Why Blockstream Built It This Way
Secure element vendors ship under non-disclosure agreements. Build a wallet around one and the component doing the most security-critical work becomes the one part nobody outside the vendor can read. That trade was never acceptable for Jade, which keeps the wallet-level protocol, firmware, schematics, and oracle implementation publicly inspectable and usable on commodity hardware.
The Virtual Secure Element is a protocol rather than a part, so it works on DIY hardware assembled from off-the-shelf boards. A secure element chip, its NDA, and its cost would have closed that door.
The Trade-Offs
Splitting a key across two parties buys real properties and costs real things.
Unlocking with a PIN requires the oracle to be reachable. When it isn't, Jade still works: the device runs statelessly, taking your recovery phrase directly by SeedQR scan or manual entry, with no oracle in the loop at all. Your recovery phrase is the wallet, not the Jade, and it restores the wallet anywhere, as it does with every wallet, secure element or not.
The microcontroller isn't hardened silicon, and Jade doesn't claim otherwise. A secure element also resists laboratory attacks like fault injection and power analysis against a powered-on device. The Virtual Secure Element protects your encrypted wallet at rest and your PIN in transit. It doesn't turn a general-purpose chip into a tamper-resistant one.
Two-party protocols carry more failure modes than one-chip designs. Telling "the network dropped" apart from "wrong PIN" has to be exact, because confusing them burns an attempt against a counter that only goes one way. That's a discipline the firmware carries, in the open, where anyone can check the work.
Check the Work Yourself
The argument only counts if it's verifiable, so all of it is published. Both the Jade firmware and the blind oracle server are open source. The PIN handling lives in main/process/pinclient.c on the device and in pindb.py on the server.
For the technically inclined: Jade derives pin_secret as a nested HMAC of the PIN and the device unit key. The server stores only SHA-256(pin_secret) alongside an encrypted per-account key share and an attempt counter. On a match it returns its key share part, and the device derives the final AES key as HMAC(key_share, pin_secret). Requests run over ephemeral elliptic-curve Diffie-Hellman (ECDH) sessions with the server key tweaked by a monotonic anti-replay counter. The on-device wallet blob is AES-256-CBC encrypted with a fresh random IV and authenticated by an appended HMAC-SHA256 over the IV and ciphertext, which Jade verifies before decryption.
- Get Jade Plus
- Read the Jade security model FAQs for shorter answers to the common questions
- Run your own blind oracle rather than Blockstream's.