How trusted randomness and verifiability prevent failures like Coldcard

Key generation bugs, like the one that affected Coldcard, are less common than other wallet vulnerabilities. 

Milk Sad, an earlier bug of this sort, surfaced in the summer of 2023 and caused losses across thousands of wallets, blockchains, and asset types. Ill Bloom made headlines in July 2026 after attackers exploited weak recovery phrases to steal more than $5 million. Weeks later, the Coldcard exploit exposed the same underlying problem: insufficient randomness during wallet creation.

Randomness is what makes private keys cryptographically secure. It ensures that each key is selected from a range of possibilities too large for an attacker to search.

When these key generation bugs occur, they typically reduce the randomness used to generate wallet keys. A programming or architecture error creates weak, non-random keys and shrinks the pool of possible values enough that savvy attackers can reproduce them and drain funds.

This article explains why key generation bugs happen and gives tips on what you can do to avoid them and keep your users' assets safe.

What are private keys and how are they generated?

A private key gives a wallet the ability to create signatures authorizing transactions. It’s a large, secret number selected from the valid range of a cryptographic system. 

These keys are generated in two common ways. A system can create an individual private key directly from secure randomness, or a hierarchical deterministic wallet can generate a recovery phrase and derive many private keys from it. The second model is common in consumer wallets. 

A weak key and a strong key behave identically onchain. Both produce valid addresses and signatures. The blockchain cannot determine whether a wallet was generated securely. It can only verify that a transaction carries a mathematically valid signature.

What is secure entropy?

Entropy is the unpredictability used to create a wallet seed or private key. A wallet is secure because its key is selected from such a large set of possible values that finding it through trial and error is computationally infeasible.

That protection depends on how the randomness is produced. Software randomness is not inherently insecure. Operating systems provide cryptographically secure generators that can be safe when properly designed and seeded. The danger comes from using a generator that was not built for cryptography or initializing it with values an attacker can reproduce.

A flawed entropy source can generate thousands of keys that look completely normal while quietly limiting them to a searchable set of possibilities.

How did the current problem with Coldcard happen?

“The Coldcard issue was a key-generation flaw. Coldcard has a good hardware RNG, but a coding bug silently switched key generation to a generic, weaker software source, so an attacker who understood the pattern could reconstruct affected keys.”
                                                           
                              –Michael Lewellen, Head of Solutions Engineering at Turnkey

A firmware flaw in Coldcard’s wallet-generation process caused affected devices to bypass their intended hardware random number generator and generate recovery phrases through a weaker software path. That path relied on predictable, nonsecret device information, making some wallet seeds easier to reproduce.

The recovery phrases still looked normal and created valid Bitcoin wallets. Users had no visible indication that anything had gone wrong. 

The lesson is simple: if the secure source of randomness is unavailable, the device should stop and refuse to create the wallet. It should never quietly switch to a less secure method.

The real question: Trust the provider, or verify the hardware?

Every wallet built on outside infrastructure comes down to one question: what are you actually trusting? With most providers, the answer is the provider itself. You trust its code, its deployment process, and its claim that the secure hardware behaves as documented.

Coldcard shows why that is a weak foundation and a real problem. The device contained dedicated hardware for producing randomness, and the documentation said that hardware was used. A software bug bypassed it anyway, and no one could see the failure until the funds were gone.

An application protecting user funds is better served by trust it can verify rather than by trust it takes on faith. That reframes the problem into two questions: what is generating the randomness, and is the approved system the one actually running?

Trusted randomness starts with the source, and verifiability confirms that source is running

“Turnkey is designed to expose this class of failure, instead of allowing it to remain hidden. Our deployment pipeline uses attestation to verify both the exact software running and the secure hardware environment running it.”

                               – Michael Lewellen, Head of Solutions Engineering at Turnkey

Good randomness matters, but so does what physically generates it and whether that source is guaranteed to be used every time. 

Verifiability closes that gap. It allows the hardware to attest to the software running during wallet generation, so anyone can verify which entropy source it used and whether the intended controls were active.

The honest limits of verifiability

Verifiability does not remove every trust assumption. It narrows and relocates them. Instead of trusting a provider's entire organization, software stack, and deployment process, a customer can inspect the software and verify its execution while placing a smaller amount of trust in the underlying hardware.

Some assumptions remain. Attestation evidence ultimately depends on signatures issued by the hardware provider. Attestation can identify the running software, but it cannot fully prove the quality of every value a hardware generator produces.

Some trust in the hardware provider is therefore unavoidable. Customers must trust that the provider designs and operates the hardware correctly, protects its attestation keys, and discloses security flaws. That is why the provider’s credibility, security track record, and transparency matter. 

By knowing who provides the hardware and being able to verify what runs on it, customers gain a smaller, clearly defined trust boundary that they and their auditors can evaluate instead of relying on a blanket promise they can only accept.

How Turnkey protects key generation with trusted randomness and verifiability

“Our engineers know this class of bug well from prior incidents in other software. The entropy path is a deliberate focus of our internal reviews and third-party audits with top-tier firms like Trail of Bits that we conduct on a recurring basis.”

                               –Michael Lewellen, Head of Solutions Engineering at Turnkey

‍
Turnkey combines open-source software with remote attestation to make its protected execution path verifiable. The underlying hardware signs proof of which software is running inside the enclave, allowing customers to verify that it matches an expected, published build.

Trusted randomness instead of trusting software

Turnkey’s key generation draws its randomness, or entropy, from the Nitro Security Module (NSM), a dedicated secure co-processor provided by AWS. AWS is one of the leading providers of confidential computing technology that keeps data protected even while it is in use.

This shifts the root of trust from Turnkey’s application software to AWS, a widely trusted provider of confidential computing infrastructure. Customers rely on AWS’s Nitro hardware to produce secure entropy rather than relying solely on Turnkey’s claims about its own systems. 

At boot, the enclave confirms that the NSM is available. Key generation is hardcoded to this source and does not include a weaker fallback path. If the approved entropy source cannot be used, the enclave aborts instead of continuing with software randomness.

This fail-closed design directly addresses the architectural pattern exposed by Coldcard. The intended source cannot be silently bypassed while wallet generation continues. 

Verifiable key generation from code to hardware

Turnkey's remote attestation provides signed evidence that a specific build is running inside an authentic AWS Nitro Enclave.

This means attestation ties the running build, including its entropy checks and lack of a weaker fallback, to a published reference customers can inspect.

Protecting key material after generation

Once generated, key material is protected inside a trusted execution environment, an isolated, hardware-protected compute environment that shields the code and data inside it from the host system and even the operators running it. It never exists in plaintext outside that environment.

Each control protects a different stage:

• Hardware-backed entropy protects the key during generation.
• Attestation makes the environment verifiable.
• Enclave isolation protects it from later extraction.

The application server, user device, Turnkey employees and external infrastructure never receive the raw private key. The enclave returns only the requested cryptographic result, such as a completed signature.

Restricting how keys can be used

Key generation is only one layer of Turnkey’s security architecture. Turnkey also evaluates application-defined policy before every signature.

Policies can restrict:

• Who can initiate or approve a transaction
• Which addresses and contracts can receive funds
• Which transaction types and contract functions are permitted
• How much can be transferred
• When additional approvals are required

These controls separate possession of an application credential from unrestricted use of the wallet. A request that falls outside the approved policy is denied before a signature is created.

Learn more in Turnkey’s architecture whitepaper.

Turnkey: Securing keys at generation

Wallet security begins before storage, authentication or transaction signing. It begins with the randomness used to create the wallet.

Coldcard demonstrates why simply including a hardware random number generator is not enough. The system must guarantee that the approved source is used and stop when it is unavailable.

Trusted hardware entropy makes wallet seeds and private keys unpredictable. Remote attestation allows customers to verify the generation path rather than trusting a provider’s claims. Secure isolation and signing policies then protect the key after it has been generated.

When an application is responsible for users’ funds, “it looks random” is not enough. The randomness must be trustworthy, and the process that generated it must be independently verifiable. Turnkey makes that possible.

Get started with Turnkey today.

‍