Best Protection for Blockchain BIP32 Keys
Cite this article
Crypto Wallets Under Attack
In February 2025, the cryptocurrency world was rocked by yet another major security breach—this time, targeting Bybit, a leading Dubai-based exchange [source]. Hackers, allegedly linked to North Korea, managed to steal approximately $1.5 billion worth of Ethereum, exposing critical weaknesses in private key management.
This attack follows a long history of high-profile breaches, reminding us that the security of cryptographic keys remains the weakest link in blockchain security.
Though being the largest theft in the young cryptocurrency history, it is just another one in the long list of breaches. One item on this list is the infamous is the Mt. Gox collapse in 2014, where approximately 850,000 bitcoins (worth around $450 million at the time) were stolen due to compromised private keys [source].
Investigations later revealed that hackers had been draining funds for years without detection—ultimately leading to the exchange’s downfall.
Both incidents underscore a fundamental truth: if cryptographic keys are not properly secured, the entire system is at risk. In blockchain networks, BIP32 (Bitcoin Improvement Proposal 32) and its extension BIP44 introduce hierarchical deterministic (HD) wallets, allowing multiple private keys to be derived from a single master seed.
While this improves key management, it also means that if the master key is compromised, all associated keys are at risk.
To prevent such catastrophic breaches, secure storage and handling of BIP32 keys is essential, ensuring that these keys remain out of reach from cybercriminals, especially as BIP32 is the most widely adopted standard for HD wallets [source].
As attacks on cryptocurrency platforms become more sophisticated, protecting BIP32 keys must be the top priority for exchanges, wallet providers, and individual users alike.
How to Best Protect BIP32 Keys
Unfortunately, it is still often seen in the market that BIP32 keys used for blockchains are not protected appropriately [source], even though these are protecting assets of enormous value.
So, what are the most important measures for protecting BIP32 keys? These are described in the following chapters. The main focus of this blog is the protection of private keys - a.k.a. extended private keys (xprv) in the HD Wallet world - as these are the critical elements used for creating transactions.
Public keys – a.k.a. extended public keys (xpub) in HD Wallet world - typically require less protection, especially when it comes to the last child keys in the key derivation path, and these public keys can be shared freely.
There is a caveat about sharing public keys in a non-hardened key scenario, in which you should protect the master public key very well, as described in the chapter Secure Derivation of Child Key.
High Entropy of Key Seed
The predominant key type for HD wallets is ECDSA with curve secp256k1, which is derived from an HMAC-512 key. The quality of such a key requires a random number generator (RNG) with a high-entropy seed.
Software based RNGs do not provide sufficient entropy and may result in predictable and therefore insecure keys [source]. Only specific hardware based RNGs ensure that the key quality is good. Therefore, this should be your choice, when generating your keys.
Typical hardware devices supporting adequate RNGs are FIPS 140-2 Level 3 compliant Hardware Security Modules (HSMs).
Secure Key Storage in Hardware
Securing storage of your private blockchain keys is paramount. Compromise of your private child keys - or even worse, your private master key - must be avoided at all costs, as this will result in misuse of your private key and illicit transactions that will empty your crypto wallet.
Moreover, it is also highly important to not lose your private key, as this will invalidate your crypto wallet. Within the blockchain world, blockchain participants often generate the keys in a software solution like the Mnemonic-Code-Converter and then import them into a blockchain node.
The backup of the key is achieved by a mnemonic (see BIP39), which is also called a seed phrase. This procedure has several shortcomings:
1. Software key generators do not provide good entropy and therefore keys are of low quality.
2. Private key values are exposed and may be stolen.
3. Mnemonics are cumbersome in usage and may lead to key loss.
4. Mnemonics require being stored in a physical safe.
The following sections describe different scenarios to improve the situation. All diagrams below show two blocks; one being an HSM protecting your keys and the other one a blockchain node, which executes your transactions.
In general, you should aim for executing as many crypto operations within the secure boundary of an HSM as possible and ideally not export any key value to the blockchain node at all.
Secure Generation and Storage of Master Key
Ensuring high quality of your master key is the most important step for setting up an HD wallet.
To do so, the key must be generated within an HSM, which provides an inbuilt secure storage and sufficient entropy. Therefore, the key manager needs to generate the master key within an HSM, as depicted in Figure 1.
Figure 1: BIP32 Key Generation Within HSM
Hereby the BIP32 key generation actually consists of an HMAC-512 key generation and an additional key derivation.
By generating the master key within an HSM, you will gain the complete functionality of key lifecycle management. This includes the mechanism to back up a key, which eliminates the need to use a cumbersome and insecure mnemonic for backing up the key seed.
In the scenario described above, the key manager transfers the key to a blockchain node, following the BYOK mechanism and then derives the child keys from the master key. The transaction signer creates transactions and signs them with the child key in the blockchain node.
Though this procedure addresses a couple of issues that were mentioned before, this procedure still incurs a master key export and therefore the exfiltration of the key value is a major threat.
Secure Derivation of Child Key
Ideally, you never expose the value of the master key, which is your most important asset. You should always protect it within the secure boundary of an HSM. The scenario depicted in Figure 2 addresses the protection of the key values during the key derivation process.
Figure 2: Secure Derivation of Child Key
Here, the key manager derives the child key within the HSM and then transfers it to the blockchain node, where it can be used for creating transaction signatures. This ensures that the private part of the master key is never exposed outside the HSM, which ticks all boxes for the security of the master key. However, the child keys are still stored in an unsafe environment.
This alone is harmful. But what is even worse, in case of non-hardened keys, if the attacker - in possession of a stolen private child key - also gets access to the public master key, the whole key chain up to the private master key is compromised and the attacker would be able to execute transactions with all keys in the chain up to the master key [source]. In case you go for non-hardened keys, you should set the private keys to be non-exportable and never share the public master key.
Secure Storage and Usage of Child Key
Ideally, you store all private keys within an HSM at all times; this includes the generation/derivation of an xprv and its usage for the creation of signatures as shown in Figure 3.
Figure 3: Secure Storage and Usage of Child Key
Here, the transaction signer still triggers a transaction on the blockchain node. But in comparison to the previous scenario, the private key creating the signature is located inside the HSM.
To achieve this, the key manager is not transferring the child keys from the HSM to the blockchain node, as done previously and therefore the key value is never in danger of being exposed. Of course, the private keys should be set to non-exportable to avoid any misuse.
This scenario is the ultimate and best storage and usage protection for private keys. And this is a general best practice; not just limited to a blockchain scenario.
Secure Key Usage Authorization
There are a couple of things you need to have in place to protect your blockchain signing keys. You must have a strong authentication in place. Only a username/password authentication is not sufficient. A second factor (like a hardware authentication token) to authorize the transaction must be in place.
Role Based Access Control (RBAC) will ensure that the users in your company are only allowed to perform those actions on the key or in the whole system that they are allowed to do. For example, an auditor should be able to view the transaction log of your keys, but he must not be able to perform a signature with the blockchain signing key. You definitely want to setup a zero-trust architecture and you want to follow the principle of least privileges.
Another thing you want to have in place is dual-control or multi-control of the usage of your blockchain keys. It is not sufficient to trust only a single person to sign transactions. One of your employees in charge of signing transactions may be compromised, may be distracted or may even be disgruntled and consequently malicious transactions may occur. This can be mitigated by implementing dual-control on the standard crypto interfaces.
Multisig wallets address this already by requiring several signatures from different people to authorize a transaction. However, creating multiple signatures on the blockchain is slower and raises the costs for each transaction. Further, you will need to manage more keys. It is easier and more cost effective to manage only a single key and perform a single signature, which must be authorized by several people.
Real-time Key Usage Auditing
The best and probably only feasible way to detect illicit transaction signings is to have real-time auditing in place. You should log all key usages and analyze those in real-time with appropriate tools like SIEM, SOAR or XDR. Such tools allow the detection of anomalies and to respond properly and in real time by at least raising an alarm or even better by blocking the signing key automatically to prevent further misuse.
How Fortanix DSM Helps Protecting BIP32 Keys
Fortanix offers a Key Management System (KMS) with an integrated HSM called Data Security Manager (DSM), which can be deployed on-prem, in the cloud, or as-a-service. This provides solutions to all the BIP32 key protection requirements detailed above. This includes:
- Hardware protection of your BIP32 keys in a FIPS 140-2 Level 3 compliant Hardware Security Module (HSM)
- Full key management capabilities, including BYOK to distribute your keys
- Inbuilt and secure backup of keys
- Full support for BIP32 key derivation path, configurable within the HSM
- Role Based Access Control (RBAC) to follow the principle of need to know
- Custom roles to comply with the principle of least privilege
- Strong authentication to prevent account compromise
- Full implementation of a quorum approval policy
- Zero Trust Architecture
- Event-level audit log, as required by compliance regulations
- Custom cryptographic policy to ensure no weak keys are ever generated or used
- Full automation capabilities through standard crypto interfaces and a powerful REST API
- Cold and warm HD wallet capabilities
- Future-proof Post Quantum Cryptography (PQC) readiness with full implementation of CNSA 2.0 suite
If you have any further questions, please contact Fortanix.
