THE COLDCARD BITCOIN HARDWARE WALLET SECURITY DEBACLE, WHAT REALLY HAPPENED? The best AI report -Claude Opus 5 Max- on what actually happened with @COLDCARDwallet. To verify, but seems quite likely, and that means Trezor and Ledger should be fine: "The Coldcard failure was **not** a broken TRNG chip. It was a build-configuration bug that silently bypassed the hardware TRNG entirely. Coldcard's board config sets `MICROPY_HW_ENABLE_RNG` to zero because Coinkite ships its own hardware-RNG wrapper. But the libngu library checked only whether that macro was *defined*, not whether it was *enabled*, so the build succeeded and quietly bound to MicroPython's software fallback — a non-cryptographic "Yasmarang" generator seeded from the chip's UID, SysTick and RTC registers.¹ None of those are secrets: the UID is factory metadata partly exposed as the USB serial number, and the timer values are constrainable.¹ Consequences by generation:¹ - **Mk2/Mk3 on firmware v4.0.0–v4.1.9** — no cryptographic entropy at all. With known UID, timer state and call history, seed generation is *deterministic*. Realistic ceiling on a cold boot: roughly 2^16 to 2^40 candidates instead of 2^256. - **Mk4/Q/Mk5** — boot adds secure-element entropy, but hashes it and keeps only four bytes, and `reseed()` overwrites just one 32-bit state word. Ceiling: 2^32, averaging ~2^31 trials. Two details make this instructive. Libngu XORs the fallback against a *second* Yasmarang stream initialized from published constants — XOR of two reproducible inputs is still reproducible.¹ And the health check only rejected identical adjacent outputs, which a deterministic PRNG passes trivially.¹ SHA256d over the result doesn't help: hashing can't enlarge the candidate set.¹ Roughly 594 BTC (~$38M) was swept from ~500 single-sig wallets in a 25-minute window, 1,324 UTXOs across a three-block span.³ Coinkite's own advisory covers Mk3 firmware 4.0.1 through 5.0.3 and states Mk4/Q/Mk5 are unaffected on early analysis;² Block's independent report disagrees on that last point and puts current models at the 2^32 bound.¹ Treat both as preliminary. Two things that surprise people: exposure depends on the firmware running **when the seed was created**, not the purchase date or current firmware — upgrading does not repair an existing seed.¹ And exporting a weak seed into a different wallet doesn't fix it either.¹ ## How the major wallets generate entropy **Ledger** — single source, but a heavily certified one. The TRNG sits inside the Secure Element; entropy is generated there and mapped to BIP39 words.⁵ Ledger's own security lab describes SE TRNGs as free-oscillator designs validated by third-party labs to EAL5+ and AIS-31, tested across temperature, voltage and frequency with defect-detection built in.⁴ Nano X is EAL5+; Nano S Plus and Stax use EAL6+ parts.⁶ The trade-off is honest: you get certification but not verifiability — the OS is closed-source and there's no host-entropy mixing you can independently check. **Trezor** — multi-source by design, and this is the architectural answer to the Coldcard failure mode. Model One and Model T XOR host-OS entropy with the STM32 hardware TRNG. Safe 3 and Safe 5 add a third source, the Optiga secure element. Safe 7 adds a fourth, the TROPIC01 chip.⁷ The reasoning is that an attacker would need every source to fail simultaneously.⁷ Crucially, you can verify it: `trezorctl` lets you see the entropy the host sent and ask the device to display its internal entropy, then reconstruct the seed yourself and check it matches.⁸ Trezor Suite 25.2.2 (Feb 2025) automated a version of this as the "entropy check," and it's a workflow in the firmware's `ResetDevice`.⁹ ¹⁰ **BitBox02** — five sources: manufacturing randomness, your device password, the host computer, the microcontroller, and the secure chip, combined so each can only add entropy, never subtract.¹¹ Firmware is open-source with reproducible builds independently checked by WalletScrutiny.¹² ## How secure are these against hacking? The honest answer is that the TRNG silicon is essentially never the thing that gets attacked. Every large real-world entropy failure has been an *integration* failure in software: - Android's `SecureRandom` bug drained wallets in 2013⁴ - Milksad (2023) — Libbitcoin Explorer used Mersenne Twister seeded from a 32-bit clock value; ~2,600 wallets compromised, ~$900k confirmed⁷ - Coldcard (2026) — a `#ifndef` that should have been `#if`¹ Attacking a certified SE TRNG requires physical possession, lab equipment and specialist skill. Exploiting an entropy bug requires an xpub or an address — which is public and acts as a free validation oracle, letting an attacker test candidate seeds offline at scale.¹ That asymmetry is why architecture beats certification here. So the practical ranking: 1. **Multi-source mixing** where independent components each contribute. One flawed source can't sink the seed. 2. **Verifiability** — open-source, reproducibly built firmware, plus a way for *you* to confirm the entropy you supplied was actually used. Trezor's entropy check and BitBox's reproducible builds are the concrete examples. 3. **Certification** — real value against physical attacks (EAL5+/6+, AIS-31), but it certifies the component, not the firmware that calls it. Coldcard's Mk4 *had* a secure element; the firmware threw away 28 of its 32 bytes.¹ ## If you want to remove trust in the RNG entirely Dice. Each D6 roll contributes 2.585 bits, so 50 rolls gives 128-bit security and 99 rolls gives 256-bit.¹³ Coldcard's dedicated dice path hashes the roll sequence directly with SHA256 and bypasses the device generator completely² ¹³ — note that this only works via `Import Existing > Dice Rolls`, not the normal New Wallet flow.² BitBox02 publishes an equivalent procedure.¹¹ Never photograph the rolls or type them into a networked computer.² A strong BIP39 passphrase is the other lever: it adds entropy outside the device RNG, which is why Coinkite says passphrase-protected Mk3 wallets face minimal risk.² It's a genuine mitigation, not a substitute for migrating. If you generated a seed on an affected Coldcard, both Coinkite and Block recommend moving funds — and note that a multisig quorum composed entirely of vulnerable devices provides no protection.¹ ² --- **SOURCES** 1. Block Engineering — *Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware* — https://t.co/YrOOIe9vZq 2. Coinkite Blog — *Mk3 Security Advisory* — https://t.co/ZSVtMGe7wr 3. CoinDesk — *Major bitcoin wallet flaw drains 594 BTC in 25-minute sweep* — https://t.co/IoK6xqEUOi 4. Ledger Donjon — *Threat Model: Random Number Generation* — https://t.co/L3pZxe9McO 5. Ledger Academy — *What Is The Entropy in Crypto?* — https://t.co/WckSL8rTFM 6. Ledger Academy — *The Secure Element Chip* — https://t.co/0e1bv1VnBr 7. Trezor Knowledge Base — *What is entropy and how does Trezor generate your wallet?* — https://t.co/BNQ0E9trcK 8. Trezor Forum — *Entropy Check on Trezor Model One* — https://t.co/y1sTJpp10u 9. Trezor — *Trezor Suite update February 2025* — https://t.co/HV77m2i5uk 10. Trezor Firmware — *core/CHANGELOG.md* — https://t.co/Zllvf7bw5F 11. BitBox Support Hub — *Can I create a wallet with my own entropy?* — https://t.co/TnGyVIDb2J 12. BitBox — *Security on every level* — https://t.co/Gon18TlnkH 13. COLDCARD Documentation — *Verifying Dice Roll Math* — https://t.co/hATD4o7yI4"