Coldcard RNG flaw

[chants]

A Coldcard RNG flaw may have exposed predictable wallet seeds linked to $88.6 million in suspected Bitcoin thefts across 4,585 addresses.

https://www.esecurityplanet.com/threats/news-coldcard-rng-flaw-bitcoin-theft/

It wasnt so long ago IDA Pro key system had the same 32 bit seed RNG flaw. But that mistake didnt cause a massive heist and was far less costly. In this case it looks like they of course knew to use a hardware RNG but due to a prepeocessor variable being defined but not 0 in a patch they pushed, it led to a fallback that was catastrophic.

[th3tuga]

Some more details:

Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware

How a deterministic fallback and limited secure-element reseed constrain entropy across COLDCARD generations


Following reports from COLDCARD users, and working alongside other security researchers, Block’s Bitcoin Engineering and Security teams root-caused vulnerabilities that allow for theft of Bitcoin from COLDCARD users. This analysis is based on our current understanding of the situation. We have not done full empirical testing to confirm exploitability. We are publishing this advisory early, because active exploitation is under way. This analysis is the opinion of Block, and based on our internal research; we recommend looking at Coinkite's definitive report once available.

This report does not pertain to Block products; no Block products or customers are affected by this vulnerability.

COLDCARD firmware contains an RNG integration error that causes ngu.random to use MicroPython's deterministic Yasmarang fallback instead of the STM32 hardware RNG.

The production board configuration defines MICROPY_HW_ENABLE_RNG as zero because COLDCARD provides a separate hardware-RNG wrapper. Libngu incorrectly checks whether that macro is defined rather than whether it is enabled. The build therefore succeeds, and libngu binds to MicroPython's rng_get(). With the macro set to zero, that function is a Yasmarang software generator initialized from the MCU UID and timer registers.

The consequences differ by device:

Mk2/Mk3 v4: No cryptographic entropy is added to ngu.random. For a known UID, timer state and call history, wallet generation is deterministic.
Mk4/Q/Mk5: Boot adds secure-element entropy, but hashes it and retains only four bytes. reseed() then replaces only one 32-bit Yasmarang state word. For a fixed fallback state and call history, there are at most 2^32 securely distinguished output streams.

Wallet generation hashes the resulting 32 bytes, but deterministic hashing cannot increase the number of possible seeds.

Exposure depends on the firmware used when a secret was generated, not the device's manufacturing date. Upgrading does not retroactively weaken or repair an existing seed.
Impact

An attacker who can determine or sufficiently constrain the device UID, timer state and RNG-call history can reproduce the fallback stream offline.

A wallet xpub, address or generated public key provides a candidate-validation oracle. Successful recovery of a wallet seed or private key permits theft of all associated funds.

For Mk2/Mk3 v4, there is no cryptographically generated secret input to enumerate. For current devices, once the fallback state and call history are fixed, the remaining secure-element-derived search space is at most 2^32, averaging approximately 2^31 candidate trials.

This does not mean every remote attacker can immediately recover every seed. Practical cost depends on available UID information, boot timing, prior RNG calls and derivation cost. No end-to-end brute-force benchmark is claimed here.
Impact due to seed export

If you exported a seed generated in a vulnerable coldcard, moving it to another wallet, then that same insecure seed is still affected.

Full details: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware