benma

Randomness is the foundation everything else in a hardware wallet stands on. Get it wrong and nothing else matters. Not the secure element, not the air-gap, not the metal backup. Weak entropy during initialization = funds drained "remotely." No device access needed, attacker just recomputes your keys. It's the single most critical path in a hardware wallet, and we treated it that way from the very first Trezor Model One (just turned 12 years old!) by mixing device entropy with entropy from the host (computer or phone). Never trust one source. We deliberately designed it this way from the very beginning. The nightmare scenario is that test mode with weak randomness is shipped by accident. People think their wallet generated something truly random but it didn't. Anyone who knows the pattern can work backward and recreate their private keys and AI is definitely speeding this up. We run dedicated safeguards to make sure that can never happen in our builds. Trezor Model One and Model T mixed two entropy sources together (from MCU and from the host). With Trezor Safe 3 we took this further and added Optiga as an independent entropy source. Safe 7 mixes four: MCU, host, Optiga, TROPIC01. On all models this results to 128-bit entropy in default settings. On top of that, we also introduced Entropy Check back in February 2025. From a different angle: Let's finally retire the myth about air-gap. Air-gap doesn’t necessarily imply stronger security. With air-gapped wallets you miss this entropy from the host. If the randomness is not sufficient and keys are predictable, the attacker never needs to touch your hardware.

Multisig accounts where affected coldcards make up the signing threshold (e.g. 2-of-3 are affected coldcards) are also potentially vulnerable for addresses that were reused (or where the descriptor is known). I recommend moving these funds too in abundance of caution.

Multisig accounts where affected coldcards make up the signing threshold (e.g. 2-of-3 are affected coldcards) are also potentially vulnerable for addresses that were reused (or where the descriptor is known). I recommend moving these funds too in abundance of caution.

My current hypothesis for the Coldcard theft. 1- The issue: - Low entropy RNG, either in a library or secure element/chip itself. Could be a limited batch or a specific firmware. - Probably affecting the mnemonic, even if the theft is weird/confusing. - Thief knows about the RNG bug, but not about Bitcoin. 2- The attack - Attacker asked an AI to craft a script to bruteforce and prepare a sweep. - AI ONLY TRIED bip84 derivation paths - AI ONLY TRIED A LIMITED NUMBER OF DEPTH This is why we only see Segwit being stolen, and sometimes partial wallets instead of full wallets. If i am correct: - The funds of partially affected wallets ARE AT RISK or further drain - The funds of other type of addresses ARE AT RISK when the scan looks for them too. If I am wrong: - WHY only bip 84? - WHY partial sweeps? Could be some very rare bug happening in very specific cases, but looking at the chain it's hard to guess what it could be. Some weird derivation bug happening only in CC, at bip 84 paths?