Understanding Hardware Wallets

Introduction

In the world of cryptocurrency, managing multiple accounts securely and conveniently is paramount. Hardware wallets, such as the Ledger, SafePal and others, achieve this by utilizing a single seed phrase to manage multiple accounts. This is made possible through a concept called hierarchical deterministic (HD) wallets. In this article, we will explore the mechanics of path derivation and touch on the extent of security if the connected computer or browser wallet is compromised.

Path Derivation: The Core of HD Wallets

Path derivation is a method used in HD wallets to generate multiple key pairs from a single seed phrase. Each account in an HD wallet is derived from a master private key using a specific derivation path. This allows for the creation of a structured tree of key pairs, enabling a single seed phrase to manage numerous accounts.

How Does It Work?

When you initialize your hardware wallet, a seed phrase (12, 18, or 24 words) is generated. This seed phrase is used to create a master private key. From this master key, a series of child keys are derived using the derivation path.

For Ethereum, the standard derivation path is m/44'/60'/0'/0/x, where:

  • 44' is the purpose (BIP-44 standard),
  • 60' is the coin type (Ethereum),
  • 0' is the account,
  • 0 is the change (0 for external, 1 for internal addresses),
  • x is the address index.

By changing the address index x, new addresses (accounts) are generated.

Let's simplify the math to understand the concept better. Assume the master private key is MPK. To derive the first Ethereum account, we follow the path m/44'/60'/0'/0/0.

  • Start with the master private key (MPK).
  • Apply the derivation function with the path components to get the first account's private key (PK0): PK0=Derive(MPK,path="m/44′/60′/0′/0/0")
  • To derive the second account, change the last component to 1: PK1=Derive(MPK,path="m/44′/60′/0′/0/1")
  • This process is repeated to generate as many accounts as needed, all derived from the single seed phrase.

Same same but with math

The derivation method used in hierarchical deterministic (HD) wallets involves a series of cryptographic operations. At the heart of this process is the use of Elliptic Curve Cryptography (ECC), specifically the secp256k1 curve, which is the standard for Bitcoin and Ethereum.

The derivation path, such as m/44'/60'/0'/0/x, guides the process of generating new key pairs. The "Derive" method applies cryptographic functions to the private keys and can also work directly with public keys, allowing for both private and public derivation.

1. Master Private Key and Chain Code

When the seed phrase is generated, it is used to derive a master private key (m) and a master chain code (c). This is done using the HMAC-SHA512 hash function: (Master Private Key,Master Chain Code)=HMAC-SHA512("Bitcoin seed",Seed)

In the context of hierarchical deterministic (HD) wallets, a chain code is an additional piece of data used alongside private keys to derive child keys. It ensures that derived keys can be generated in a deterministic yet secure manner, maintaining the integrity and security of the wallet's key structure.

The chain code, paired with a private key, ensures that derived keys remain secure and cannot be deduced merely by knowing a parent key. This separation of key material is crucial for maintaining the security hierarchy in an HD wallet.

By using the chain code, HD wallets can deterministically generate a tree of key pairs. This means that the same seed phrase will always produce the same set of keys and addresses, facilitating wallet backup and recovery.

Chain codes ensure that keys derived on different platforms or devices from the same seed phrase will always be identical, ensuring consistency and compatibility across various software and hardware wallets.

2. Child Key Derivation

To derive child keys, we use the following components:

  • Parent private key (k_{par}): The private key from the parent node.
  • Parent chain code (c_{par}): The chain code from the parent node.
  • Index (i): The index of the child node.

The child private key (k_{child}) and chain code (c_{child}) are derived as follows: 

(IL,IR)=HMAC-SHA512(cpar,SerP(kpar)∣∣Ser32(i)), where kchild=(IL+kpar) mod n, where c_child = IR

Here:

  • HMAC-SHA512 is the hashing function.
  • SerP(k_{par}) is the serialization of the parent's public key.
  • Ser32(i) is the serialization of the index.
  • IL and IR are the left and right halves of the HMAC-SHA512 output.
  • n is the order of the secp256k1 curve.

Example with Actual ECC

Let's consider an example with specific values to illustrate the process. We start with a master private key and chain code derived from a seed phrase.

Master Key and Chain Code

Assume:

Master Private Key=0x1E99423A4ED27608A15A2616F4DAE7B3EE08CF9A7E5D02BB10C55DF93FA4AEB2
Master Chain Code=0x5A1A2D3B4C5D6E7F8E9D1F2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D7E8F9A0B1C2D

Deriving the First Child Key

To derive the first child key at index 0: Compute the HMAC-SHA512 of the chain code and serialized parent public key with the index:

(IL,IR)=HMAC-SHA512(Master Chain Code,SerP(Master Private Key)∣∣Ser32(0))

With the HMAC-SHA512 output is:

IL=0xABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890
IR=0xFEDCBA9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210

Compute the child private key: 

k_child=(IL+Master Private Key)modn

Using the order n of the secp256k1 curve:

k_child=(0xABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890+0x1E99423A4ED27608A15A2616F4DAE7B3EE08CF9A7E5D02BB10C55DF93FA4AEB2) mod n
k_child=0xC9862E3D93B8F69B8E6A34D7A92A8A2D9D1A0B7F13A2D7B90A4F87E32985F37E

The child chain code is simply: 

c_child= IR = 0xFEDCBA9876543210FEDCBA9876543210FEDCBA9876543210FEDCBA9876543210

Public Key Derivation

HD wallets also support public key derivation using the same paths without requiring the private key. The public key derivation process is similar but uses the parent's public key and the chain code.

Security and Convenience

If the computer or browser wallet connected to the HD wallet is compromised, private keys remain secure within the hardware wallet, as they never leave the device - minimizing exposure to potential malware on the host device. Moreover, manual verification of transactions on the hardware wallet ensures that even if a connected computer is compromised, unauthorized transactions cannot be approved. Even in case of a compromised computer, the attacker cannot access the seed phrase or private keys stored in the hardware wallet.

Hardware wallets like the Ledger Nano series interact with the host operating system (Windows, macOS, Linux) through a secure application (e.g., Ledger Live). The operating system has limited access to the wallet:

  • Read/Write: The OS can send commands and receive responses but cannot directly access the private keys.
  • Security Protocols: Communication between the hardware wallet and the host OS is encrypted, preventing data interception.

Recovering Access to Derived Wallets Using a Single Master Key

If your hardware wallet is lost or destroyed, you can still regain access to all your derived wallets using your seed phrase. This process works both with a new hardware wallet and with compatible software wallets. Here’s a step-by-step guide on how to do this.

Using a New Hardware Wallet

Get a replacement hardware wallet from a reputable brand like Ledger, Trezor, or another supported device. When setting up the new device, select the option to restore an existing wallet from a recovery phrase. Carefully enter your original 12, 18, or 24-word seed phrase. The device will use this phrase to regenerate your master private key and chain code. The new hardware wallet will automatically derive all your previous accounts based on the seed phrase and the standard derivation paths. You’ll regain access to all your cryptocurrency addresses and balances.

Conclusion

Path derivation in HD wallets empowers users to manage multiple cryptocurrency accounts securely and conveniently with a single seed phrase. Hardware wallets, with their robust security features and user-friendly interfaces, provide a secure environment for storing and transacting digital assets. By understanding the mechanics of path derivation and the benefits of hardware wallets, users can enhance their cryptocurrency management experience while maintaining the highest level of security.

Comments

Post a Comment

Popular posts from this blog

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av...
Read more

Length extension attack

Image
What is length extension? When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Quick sidebar, before you freak out: Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks. So, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack. Truncated versions of SHA-2, including SHA-384 and SHA-512/256 are not susceptible, nor is the SHA-3 algorithm. A bit more details ...
Read more

Contract upgrade anti-patterns

Image
A popular trend in smart contract design is to promote the development of upgradable contracts . To be fair, existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs - even in the Zeppelin contract upgrade strategy. In this article, we are going to detail our analysis of existing smart contract upgrade strategies, describe the weaknesses we have observed in practice, and provide recommendations for contracts that require upgrades. In a follow-up blog post, we will detail a method, contract migration, that achieves the same benefits with few of the downsides. An overview of upgradable contracts Two ‘families’ of patterns have emerged for upgradable smart contracts: Data separation, where logic and data are kept in separate contracts. The logic contract owns and calls the data contract. Delegatecall-based proxies, where logic and data are kept in separate contracts, also, but the data contr...
Read more