How trusted randomness and verifiability prevent failures like Coldcard

The Coldcard incident raises two important questions for anyone responsible for user funds:

1. Can you trust the randomness used to generate keys?

Coldcard had a secure hardware random-number generator, but a firmware bug bypassed it. Recovery phrases were generated through a weaker software path that relied on predictable, nonsecret device information.

Software randomness is not inherently unsafe. The risk comes from using a generator that was not designed for cryptography or seeding it with information an attacker can reproduce.

The intended entropy source must be mandatory. If it is unavailable, key generation should stop.

2. Can you verify what actually ran?

Reviewing source code is not enough. You need a verifiable connection between the reviewed source, the resulting build, and the software that actually generated the keys.

Turnkey addresses both problems through:

• Trusted randomness: Keys are generated inside AWS Nitro Enclaves using entropy from the Nitro Security Module. AWS is one of the leading and most trusted providers of confidential computing infrastructure. There is no weaker fallback. If the approved source is unavailable, key generation stops.
• Verifiable infrastructure: Open-source software and remote attestation let customers verify that the expected build and controls are running inside an authentic Nitro Enclave.
• Focused security review: The entropy path is specifically examined through internal reviews and recurring third-party audits by firms such as Trail of Bits.
• A narrower trust boundary: Attestation still depends on AWS hardware and keys, but it replaces broad trust in the infrastructure provider with a smaller, clearly defined trust boundary.

More details here:

https://www.turnkey.com/blog/coldcard-verifiability-key-generation