How Private Keys Are Securely Generated Understanding Randomness in Hardware Wallets

When users create a wallet, they ultimately see a 12- or 24-word recovery phrase. Before those words can be generated, however, the device must first produce data that is sufficiently random and difficult to predict. This data is commonly called initial entropy, and it is the starting point of wallet security.

If the initial entropy is strong enough, an attacker has virtually no chance of guessing it. If the entropy is flawed, a recovery phrase may look completely random even though the underlying set of possible outcomes is far smaller than expected. An attacker would not need physical access to the device or possession of the recovery phrase. If they can reproduce the weak random number generation process, they may be able to enumerate private keys on their own computer and search for corresponding on-chain assets.

The recently disclosed COLDCARD randomness incident brought this issue, which is easy for ordinary users to overlook, back into public view. It is also a reminder that assessing a hardware wallet requires more than checking whether it is offline or contains a Secure Element. We must also examine which source of randomness is actually used to create the wallet and whether the production firmware follows the intended call path.

One point should be clarified at the outset: COLDCARD's official advisory applies to specific COLDCARD products and firmware versions. imKey is not within the affected scope, and imKey users do not need to move their assets solely because of this incident.

How a recovery phrase Is Generated

Using a typical BIP-39 wallet as an example, wallet creation can be simplified as follows:

Initial entropy  →  recovery phrase  →  Seed  →  Private keys, public keys, and addresses

The device first generates initial entropy, adds checksum information, and encodes the result as a recovery phrase using a fixed wordlist. A 12-word phrase typically corresponds to 128 bits of initial entropy, while a 24-word phrase typically corresponds to 256 bits.

The recovery phrase and an optional BIP-39 passphrase are used to compute the Seed. The Seed is then used to deterministically derive the private keys, public keys, and addresses for different accounts.

This means that the same recovery phrase and passphrase will always restore the same wallet. This determinism makes wallet backup and recovery possible, but it also means that subsequent computations cannot compensate for weak randomness at the starting point.

If only a small number of random states were available at the outset, no amount of hashing or key derivation can prevent an attacker from recomputing every possible wallet from that limited set of candidates.

Why Going Offline Cannot Compensate for Weak Randomness

A hardware wallet keeps private keys on an offline device, which can substantially reduce the risk of malware on a phone or computer stealing them directly. But being offline is not the same as having secure randomness. Offline isolation mainly protects private keys during storage and use after they are generated; the security of a recovery phrase still depends on whether the randomness used to create it was sufficiently unpredictable. Think of generating a recovery phrase as drawing a number from a container. Under normal conditions, the device draws at random from a set so vast that an attacker has virtually no chance of guessing the result. If random number generation is flawed, however, the container may in reality hold only a small subset of possible numbers. Even if the resulting recovery phrase looks irregular, an attacker who understands the flaw may be able to try every result in that limited set and locate the corresponding wallet.

The risk is established when the recovery phrase is generated. Keeping the hardware wallet offline afterward, or setting a PIN, cannot change the fact that the phrase originally came from a smaller, potentially searchable set.

This does not mean an offline device cannot generate secure randomness. A well-designed hardware wallet can use a qualified true random number generator (TRNG) to produce high-quality random numbers inside the device. The wallet creation process must also be designed to call that source correctly. When choosing a hardware wallet, users should therefore look for a verified TRNG and a clear, verifiable security design for recovery phrase generation.

A sufficiently strong, independent, and uncompromised BIP-39 passphrase may significantly increase the effort required to brute-force the resulting wallet. However, it does not increase the initial entropy of the original recovery phrase or replace any migration instructions issued by the manufacturer for affected phrases. For users unfamiliar with backup management, adding a passphrase without careful preparation may also lead to permanent loss if it is forgotten or recorded incorrectly.

What the COLDCARD Incident Teaches Us

According to Coinkite's technical explanation, COLDCARD was designed to rely solely on a hardware TRNG when creating wallets. It was not intended to fall back to weaker software-generated randomness if the hardware source failed. The issue was introduced during a later code migration.

Because of a build and linking integration error, the rng_get() function called during wallet creation ultimately resolved to MicroPython's built-in general-purpose software PRNG instead of the intended hardware TRNG implementation. In other words, the expected TRNG implementation was present in the firmware, but the Seed generation process did not call it as designed.

The problem was therefore not a runtime failure of the hardware TRNG or a remote compromise of the device. It was a discrepancy between the security design and the firmware that ultimately ran. In this situation, an attacker would not need access to a user's device. Because the software PRNG could produce only a limited range of possible outcomes, an attacker could reconstruct candidate private keys on other computing devices and compare them against public blockchain addresses to identify potentially affected wallets.

This incident shows that verifying the presence of a hardware TRNG is not enough. It is also necessary to confirm which random number implementation the wallet creation process actually calls. A complete security assessment must therefore examine the source of randomness, the actual call path, firmware builds, and exception handling together.

A firmware update can fix random number generation for wallets created afterward, but it cannot change recovery phrases generated before the update. If a manufacturer confirms that phrases created by certain models or firmware versions are affected, users should follow the official instructions, create a new recovery phrase in a trusted environment after the issue has been fixed, and move their assets to the new wallet.

How imKey Protects Randomness and Private Keys

imKey Pro uses an Infineon SLE78-series Secure Element. According to the Common Criteria security documentation for this chip platform, it contains a hardware TRNG whose random number mechanism has been evaluated at the AIS 31 PTG.2 level.

AIS 31 is a methodology developed within Germany's BSI framework for evaluating random number generators. PTG.2 considers not only whether the output is sufficiently random, but also the physical entropy source, the stochastic model, online health tests, and failure detection. Put simply, it evaluates how randomness is produced from physical noise and whether that process can operate continuously and reliably.

The relevant combination of Secure Element platform and model has also achieved Common Criteria EAL6+ certification, indicating that it underwent a high level of security evaluation within the certification scope.

Under imKey's product security architecture, the Secure Element supplies the randomness required to create a wallet. Critical operations—including generating and storing the Seed and private keys, as well as signing transactions—take place within the Secure Element's security boundary. The phone or general-purpose host system neither generates the wallet's initial entropy nor gains access to its private keys. For further details, see the imKey Secure Element TRNG FAQ and True Chip, True Randomness.

In terms of both the randomness source and the key-handling boundary, this architecture differs from the mechanism disclosed in the COLDCARD incident, where a software PRNG entered the Seed generation path.

Taken together, an evaluated hardware TRNG, on-chip key handling, and the supporting software and engineering safeguards form the foundation of imKey's approach to random number security.

How to Evaluate Hardware Wallet Security as a Whole

Not all imKey firmware is open source. Users and independent researchers therefore cannot inspect the full codebase or independently reproduce production firmware in the same way they could with a fully open-source project. Product security must instead be evaluated across several dimensions, including chip certification, product architecture, security testing, and ongoing maintenance.

Whether a product is open source is not the only measure of its security. Publishing code lowers the barrier for external researchers to review it, but code visibility does not mean every implementation detail has been thoroughly verified. The COLDCARD incident also demonstrates that some issues can arise in cross-module calls, builds, or linking, and may not be revealed by inspecting isolated code snippets.

In imKey's published materials, the Secure Element's TRNG and related security capabilities are supported by third-party certifications. The product architecture also describes the source of randomness and the processing boundaries for the Seed, private keys, and signing operations. This information helps users understand the basis of imKey's random number and key security mechanisms.

It is important to note that creating several recovery phrases in succession and judging whether the word order “looks random enough” cannot reliably establish the security of a device's randomness. recovery phraseOutput from a weak random number generator may still appear random and may even pass some common statistical tests.

A meaningful security assessment must therefore consider not only the Secure Element, but also the product architecture, critical implementations, build process, and exception-handling mechanisms.

What Users Should Do When Similar Security Incidents Occur

As of this article's publication, imKey is not included in the scope of COLDCARD's official advisory, and there is no evidence that imKey is affected by the incident. imKey users therefore do not need to replace their recovery phrases or move their assets solely because of this event.

If similar reports about random number security emerge in the future, do not act immediately on the basis of a social media screenshot. First confirm which manufacturer issued the report, which models and firmware versions are involved, which device generated your recovery phrase, and whether the manufacturer explicitly requires migration.

If a manufacturer confirms that recovery phrases generated by a particular model or firmware version have weak entropy, users can generally choose one of the following approaches based on their circumstances:

Option 1  Update the Original Device and Create a New Wallet

Install the fixed firmware through the manufacturer's official channel, then use the updated device to create an entirely new recovery phrase. Back it up carefully and verify the wallet address. Make a small test transfer first, and move the remaining assets only after confirming that everything works as expected.

Note that updating the firmware alone cannot repair a recovery phrase generated earlier. The assets must still be moved to the newly created wallet.

Option 2  Replace the Hardware Wallet and Move the Assets

Users who prefer to replace the device can choose a hardware wallet that provides relatively clear information about its randomness source, key-handling boundary, and security certifications, then create a new wallet on that device.

imKey Pro uses an Infineon SLE78-series Secure Element with a hardware TRNG. The Secure Element supplies the randomness required by the wallet, while critical operations—including generating and storing the Seed and private keys, as well as signing transactions—take place within the chip's security boundary.

When moving assets with imKey Pro, purchase the device through an official channel, install the latest firmware, and select Create Wallet to generate an entirely new recovery phrase. Do not import a potentially affected old recovery phrase into the new device. After verifying the backup and completing a small test transfer, move the remaining assets.

Replacing the device is not the essential step. The key to completing the migration is generating a new recovery phrase using a secure source of randomness.

Shop for an imKey hardware wallet

Security Depends on the Entire System

A single incident does not diminish the value of hardware wallets. Isolating private keys from internet-connected devices and signing transactions in dedicated hardware still substantially reduces the risk that malware or remote attackers will obtain private keys directly.

Hardware wallet security depends on several layers working together: a reliable source of randomness, a secure key-handling boundary, correct firmware implementation, and continuous software maintenance and security response.

Users should not judge a product solely by a single label such as “offline,” “Secure Element,” or “open source.” A more complete assessment requires understanding how private keys are generated, where they are stored, where transactions are signed, and how the manufacturer maintains the product over time.

imKey will continue to improve its product security mechanisms and supporting documentation so that users can better understand how each security design protects their digital assets.

References

Coinkite: Technical Deep Dive into the Entropy Issue

imKey: Secure Element True Random Number Generator (TRNG) FAQ

imKey: True Chip, True Randomness

BIP-39: Mnemonic Code for Generating Deterministic Keys

Common Criteria: Infineon M7892/M7893 B11 Security Target

Infineon: SLE78 Series Product Information

Oracle: Security Target Lite – Java Card Platform on SLE78

BSI: AIS 31 – Functionality Classes and Evaluation Methodology for Random Number Generators

Important notice: imKey provides physical security hardware products only. It does not provide virtual asset trading, custody, managed operations, or investment advice. Third-party products and incidents mentioned in this article are included solely to explain security mechanisms. For the scope of any impact and the required response, refer to the latest official announcements from the relevant manufacturer.