Random number generation in hardware wallets: how your seed is really made

Every hardware wallet asks you to trust one thing above all others: that the 24 words it gave you are unpredictable. Your entire wallet, every account, every address, every coin, is derived from that one seed. And the seed is derived from a single number that the device pulls out of the air the moment you set it up.

If that number is truly random, your keys are safe against the whole planet guessing for the age of the universe. If it is not, no amount of tamper-proofing, no secure element, and no air-gap can save you. An attacker who can guess your seed never has to touch your device.

So the most important question you can ask a hardware wallet is rarely printed on the box: where does the randomness come from, and how do you know it is real? This article explains how hardware wallets generate randomness, the ways randomness can quietly fail, and how Keycard Shell makes your seed.

#Why randomness is the foundation of your wallet

How Seed Generation Works: Hardware wallets create recovery phrases by gathering physical entropy through a True Random Number Generator (TRNG) and smoothing it through a Deterministic Random Bit Generator (DRBG). This raw randomness is then mapped directly to BIP-39 recovery words.

A crypto wallet is not really a store of coins. It is a store of keys, and every key traces back to one root secret: your seed. When you create a wallet, the device does roughly this:

1. 1
   It gathers entropy, a batch of genuinely unpredictable bits.
2. 2
   It turns that entropy into your recovery phrase. The BIP-39 standard maps the bits to words: 128 bits for 12 words, 256 bits for 24.
3. 3
   From that phrase it derives an unlimited tree of private keys, using the BIP-32 standard.

Notice where the security actually lives. Steps 2 and 3 are public, deterministic maths. Anyone can run them. The only secret in the whole chain is the entropy in step 1. That first batch of randomness is the wallet. Everything else is bookkeeping on top of it.

This is why randomness is not a detail. A wallet can have a bank-grade chip, a beautiful screen, and a flawless air-gap, and still hand you a seed that a laptop can guess in a weekend, if the randomness feeding step 1 is weak. Storage protects a secret that already exists. Randomness decides whether the secret was ever secret at all.

#Good randomness comes in two stages (TRNG vs DRBG)

You cannot simply ask a computer for a random number. Computers are deterministic by design; left alone, they are the opposite of random. So a well-built device uses two components, and it helps to know both.

Stage one: the TRNG (True Random Number Generator). This is a physical source of randomness. It measures something genuinely unpredictable in the real world: electrical noise in the silicon, thermal jitter, the avalanche effect in a diode. The output is real entropy, but it is slow, and it can be slightly biased.

Stage two: the DRBG (Deterministic Random Bit Generator). This is a cryptographic engine that takes a small amount of true entropy from the TRNG and stretches it into a fast, clean, unlimited stream of random bits. It is "deterministic" because the same input seed always produces the same output. But since nobody can know the input, nobody can predict the output.

A simple way to picture it: the TRNG is rolling dice a few times, and the DRBG is a machine that turns those few rolls into millions of unpredictable numbers. You need both. The dice give you true unpredictability. The engine gives you speed and smooths out any bias in the dice.

Europe's certification bodies test these two stages separately, and you will see the names on serious datasheets. AIS-31 is the German standard for the physical source, the dice. AIS-20 is the standard for the deterministic engine, the machine. Both are published by Germany's BSI and applied through Common Criteria, the international security-evaluation framework. When both stages are certified, the randomness has been graded end to end.

#Where hardware wallets get their entropy

Different wallets draw their entropy from different places. The common sources are:

• A Secure Element TRNG: a hardened chip, similar to the one in your bank card or passport, with a certified physical noise source inside it.
• A Microcontroller (MCU) TRNG: the general-purpose processor's own hardware random generator.
• A dedicated noise source: for example an avalanche-noise circuit added specifically for entropy.
• Your dice: some wallets let you roll a physical die and type in the results.

Underneath these choices sit two schools of thought, and it is worth understanding both, because reasonable engineers disagree.

The single certified source school says: use one high-quality, independently certified TRNG inside a Secure Element, and keep the whole process on that chip. The strength is assurance. The source has been laboratory-tested and graded. Ledger and Keycard sit here.

The multi-source mixing school says: never trust one source. Combine several, device plus host, or several chips, and optionally let the user add their own entropy, so no single component failing can sink the seed. The strength is redundancy. Trezor, Foundation's Passport, and Keystone sit here.

Here is how the current market lines up:

#How randomness fails, and why you usually cannot see it

The uncomfortable truth about random number generators is that you cannot judge one by looking at its output. A weak generator and a strong one produce numbers that look equally random to any test you can run at home. This makes RNG failures uniquely dangerous: they leave no trace on the device and no visible difference in the seed. Three failure modes matter.

A biased or too-simple source. The physical noise is real but poor: not enough true entropy, so the set of possible seeds is far smaller than it should be. This is also the risk with careless user entropy, such as rolling a die too few times, or typing a pattern instead of rolling at all.

The right generator that never actually runs. This is the subtle one, and it is worth explaining because it caught the whole industry off guard. A device can contain a perfectly good hardware TRNG, ship it in the firmware, and still generate seeds from a weak software generator instead, because of a build error that silently swaps which function gets called. The published design is correct. The chip is correct. The wrong code runs anyway.

This is exactly what happened to Coldcard, a Bitcoin-focused wallet, in 2026. For five years its devices fell back to a software pseudo-random generator instead of the hardware TRNG, because a single build-time check asked the wrong question. Seeds that should have carried 128 bits of strength had as few as 32. The design documents were accurate the whole time. Attackers reconstructed the weak seeds and swept 1,082 BTC, around $70 million, in about 40 minutes (some later estimates run higher; that figure is the amount verifiable on-chain). The bug is now fixed, and Coldcard added a build-time check that fails the build unless the hardware generator is the one wired in. Users who had added their own dice rolls were the only ones untouched.

A generator that is weak on purpose. The rarest and most serious case: a generator built so that one particular party can predict its output while everyone else sees perfect randomness. The known example is Dual_EC_DRBG, a generator the US standards body NIST published and then removed from its recommendations in 2014, after researchers showed its constants could hide a backdoor. It was not theoretical. In 2015 Juniper disclosed that its firewall software had shipped with Dual_EC and those suspect constants, creating a real, exploitable backdoor (Bruce Schneier's analysis). This is the mirror image of the accident above, the same outcome reached on purpose, and it is why cryptographers insist that every constant a generator depends on has a public, verifiable origin.

The thread running through all three: randomness cannot be validated by examining its output. Real assurance comes from three things only: a certified physical source, a verifiable path from that source to your seed, and entropy you supply yourself. A wallet that offers none of these is asking for trust it has not earned.

#How Keycard Shell makes your seed

Keycard Shell takes the single-certified-source approach, and pushes it as far as the architecture allows.

When you create a wallet, the seed is generated inside the Keycard chip, the NXP Secure Element, by its own hardware TRNG. During setup, your recovery phrase is then shown on the Shell screen so you can write it down, which means the phrase passes to the Shell for that one moment of display. From then on the signing keys stay on the card: every signature is computed on the chip, and the keys used to sign never leave it.

The randomness itself is certified end to end, both stages:

• The physical source (TRNG) is certified to AIS-31, the German BSI standard for true random generators.
• The engine (DRBG) is certified to AIS-20, the BSI standard for the deterministic side.

Both are attested in a single public document, the BSI certification report for the chip's secure core (BSI-DSZ-CC-1136), which states the TRNG on page 22 and the DRBG on page 24. The chip runs on a Secure Element certified to Common Criteria EAL6+, meaning an accredited laboratory spent months physically attacking it, with laser fault injection and side-channel analysis, and it held.

Recall that Coldcard's problem was firmware that was supposed to call the hardware generator and quietly did not. On Keycard, the code that generates your seed is open source, so anyone can read it and confirm it draws from the secure element's certified random source and nothing else. And the Shell's firmware builds are reproducible, so you can confirm your device runs exactly the published code, not a private variant. There is a deeper structural reason this works where it did not for Coldcard: the Shell software does not implement its own random generator at all. It requests the certified generator on the chip. There is no software fallback sitting next to it for a build setting to select by mistake. The single point where Coldcard failed does not exist here.

A note on the names, in case you check the certificate yourself. The randomness certificate is titled for the silicon core inside the chip, not the commercial product name on the fact sheet. That is a naming layer, not a discrepancy. The physical generator lives in the silicon, which is why the randomness proof carries the silicon's name.

And if you have never heard of the BSI: it is Germany's federal cybersecurity agency, roughly the German equivalent of the United States' NIST. It is a government body, not an industry group. It writes the AIS-20 and AIS-31 standards and certifies chips against them. That last point is what gives the certification its weight.

#Why Shell does not use dice rolls

If some wallets let you add your own entropy, why does Shell not? The honest answer is a trade-off, so it is worth being precise about it.

Adding your own randomness is not useless. If a device hashes true dice rolls together with its chip entropy, the result is at least as strong as the better of the two sources: good entropy mixed with bad entropy is still good entropy. That is the real reason the Coldcard owners who had rolled dice were untouched. Their own randomness survived a chip path that had failed. So a well-built dice option, or a dice-only mode that replaces the chip entropy entirely, can genuinely protect against a faulty or distrusted generator.

The cost sits on the other side. Hand-made entropy is a footgun, and its failure modes are common and invisible: too few rolls, a repeated pattern, dice rolled in view of a camera, or a device that accepts degenerate input as if it were random. People have lost funds each of these ways. A dice-only flow removes any need to trust the chip, but it puts the full weight of your seed on getting the manual process right, which is exactly where the documented losses come from.

Shell's choice is to make the certified path the only path, so there is no manual step for a user to get wrong. We answer the "can I trust the chip?" question a different way, without a footgun: the generator is certified to AIS-31 and AIS-20, the seed-generation code is open source and can be audited, and the Shell firmware is reproducible, so you can confirm your device runs that code.

#Frequently asked questions

Is the seed generated on my Keycard Shell secure?
Yes. It is produced by a certified hardware true random number generator inside the Keycard Secure Element, the same class of chip used in bank cards and passports. The generator is certified by the German BSI: AIS-31 for the physical randomness, AIS-20 for the engine that expands it, inside a Common Criteria EAL6+ secure element.

What are AIS-31 and AIS-20?
Two German BSI standards that define how random generators are graded. AIS-31 covers the physical noise source; AIS-20 covers the deterministic engine that stretches it. Both are applied through Common Criteria, the international security-evaluation standard. You can read them on BSI's own page.

Can I add my own entropy, dice rolls for example?
No, and by design. A certified on-chip TRNG is more reliable than hand-made entropy, which is easy to get wrong in ways you cannot see. If you want to supply your own randomness, that is a different trust model, served by devices built around it.

How do I know the certified TRNG was actually used, and not silently bypassed?
This is the right question to ask any wallet, and it is why the architecture matters more than the datasheet. The code that makes your seed is open source, so it can be audited to confirm it requests the certified generator on the chip. The Shell firmware is reproducible, so you can confirm your device runs that published code. And the seed generator is the chip's own certified one, so there is no second, weaker generator for a build mistake to select.

#The bottom line

Your wallet is only as strong as the randomness it was born from. That randomness is invisible, unverifiable by eye, and the one thing no downstream security can repair. So it is worth knowing how your device makes it. A good answer names a certified physical source, keeps the process on a tamper-resistant chip, and does not depend on firmware to call the right function at the right moment.

That is how Keycard Shell makes your seed: inside a Common Criteria EAL6+ secure element, from a BSI-certified true random number generator, where the keys are born and stay.

Ready to hold your own keys, on hardware you can verify? Get a Keycard Shell.