<blockquote>
  <p>First question: If <code>p</code> was a hardened node, could the attacker still calculate its private key from it's <code>xpub</code> and a child's private key ?</p>
</blockquote>

<p>Yes. It doesn't matter how <code>p</code> was generated. What matters is how <code>c</code> is generated.</p>

<blockquote>
  <p>Second question: Could the attacker "climb up" the depth (calculate parent's <code>xpriv</code>) from <code>p</code> all the way over to <code>m</code> after calculating <code>p</code>'s <code>xpriv</code> from the leaked <code>c</code> key and <code>p</code>'s <code>xpub</code> ?</p>
</blockquote>

<p>Only if the attacker also has <code>b</code> and <code>m</code>'s <code>xpub</code>s. An important part of the derivation is the parent's chaincode. The chaincode is part of the <code>xpub</code> and if the attacker does not have the chaincode, then he cannot derive the parent's private key.</p>

<blockquote>
  <p>Would a hardened <code>b</code> or <code>p</code> make a difference here ?</p>
</blockquote>

<p>If the attacker had <code>b</code> and <code>m</code>'s chaincodes, yes, hardening would make a difference. Hardening entirely prevents this attack. However hardening does not allow someone to have an <code>xpub</code> and be able to generate keys without the private key.</p>

<blockquote>
  <p>Third question: If a private key from <code>c</code>'s depth was leaked and the attacker knew <code>m</code>'s xpub, could the attacker calculate m's private key or does the exploit only permits calculating the direct parent of a leaked child ?</p>
</blockquote>

<p>The attack only operates on a child key and its direct parent extended public key.</p>

<p>However, given <code>m</code>'s xpub and <code>c</code>s private key, it may still be possible to recover <code>m</code>'s private key even though it is not <code>c</code>'s direct parent. If <code>b</code> and <code>p</code> are derived using unhardened derivation, then <code>m</code> can be used to derive <code>b</code> and <code>p</code>'s <code>xpub</code>s. From there, with all of those <code>xpub</code>s, the attacker can work backwards from <code>c</code> in order to get <code>m</code>.</p>

<p>If <code>b</code> and <code>p</code> are hardened, then it is not possible.</p>

<blockquote>
  <p>Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?</p>
</blockquote>

<p>Take BIP 44 for example. It define a standard derivation path of <code>m/44'/0'/0'/i/k</code>. The xpub at <code>m/44'/0'/0'</code> is given out. But since it itself is derived with hardened derivation, if any of <code>m</code>, <code>m/44'</code> or <code>m/44'/0'</code>'s <code>xpub</code>s are leaked, the user's master key is still safe since hardened derivation is used.</p>

<p>Additionally, Bitcoin Core derives all keys using hardened derivation. This is because it uses BIP 32 for the easier backup function (you can use an older backup and still get all of the same keys) rather than for the auditability.</p>

CC BY-SA 4.0
2018-09-04T19:12:13.260Z
Chaincodes are intended to be shared with others-- not published on the blockchain, but not secret data.  Describing BIP32 public derivation being secure against private key relations so long as the attacker doesn't know the chain code is technically correct, but might be a little dangerously misleading.
G. Maxwell
CC BY-SA 4.0
2018-09-04T20:15:00.797Z
So in the above path, if any `c`'s `xpriv` and `p`'s `xpub` were known, only `c`'s nodes would be exposed and the attacker couldn't do anything else to the rest of the `c`'s parent nodes. In essence, hardening nodes is only useful in a scenario where `m` or `b`'s `xpub`s are also known, rendering the whole tree exposed with any `c` private key, is that correct ?
Luis Pais
CC BY-SA 4.0
2018-09-04T22:21:40.943Z
Yes, that is correct. But as G. Maxwell points out, the chaincode is meant to be shared and sharing the chaincode will result in the entire tree be exposed.
Ava Chow
CC BY-SA 4.0
2018-09-05T01:02:57.017Z
Alright that's all I needed to know, thank you !
Luis Pais
CC BY-SA 4.0
2018-09-04T15:34:01.217Z
2018-09-04T15:34:01.217Z
Ava Chow
<p>I've been reading about BIP32 HD wallet and it's implementation and came across a few questions regarding the possible known "attack" vector of leaked private child keys and known <code>xpub</code> parent key leading to the discovery of the parent private key.
Given the following path of an HD wallet:</p>

<p><code>m/b/p/c</code></p>

<p>Where <code>m</code> is the master node derived from a seed, <code>b, p, c</code> being indexed nodes in different depths.</p>

<p>Imagine that a server is watching and creating receiving <code>c</code> addresses from <code>p</code>'s <code>xpub</code>. If one of <code>c</code>'s node's private key gets leaked and the server gets hacked, thus revealing <code>xpub</code> to the attacker, the attack could now generate <code>p</code>'s <code>xpriv</code> and with that, all of <code>c</code>'s node's private and public address could be derived by the attacker (hardened <code>c</code> nodes included).</p>

<p>First question: If <code>p</code> was a hardened node, could the attacker still calculate its private key from it's <code>xpub</code> and a child's private key ?</p>

<p>Second question: Could the attacker "climb up" the depth (calculate parent's <code>xpriv</code>) from <code>p</code> all the way over to <code>m</code> after calculating <code>p</code>'s <code>xpriv</code> from the leaked <code>c</code> key and <code>p</code>'s <code>xpub</code> ? Would a hardened <code>b</code> or <code>p</code> make a difference here ?</p>

<p>Third question: If a private key from <code>c</code>'s depth was leaked and the attacker knew <code>m</code>'s <code>xpub</code>, could the attacker calculate <code>m</code>'s private key or does the exploit only permits calculating the direct parent of a leaked child ?</p>

<p>Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?</p>

<wallet><private-key><address-generation><bip32-hd-wallets>
Possible attack vector of BIP32 HD wallet
Luis Pais
# Possible attack vector of BIP32 HD wallet

(Asked by: username_0 on 2018-09-04)

I've been reading about BIP32 HD wallet and it's implementation and came across a few questions regarding the possible known "attack" vector of leaked private child keys and known `xpub` parent key leading to the discovery of the parent private key.
Given the following path of an HD wallet:

`m/b/p/c`

Where `m` is the master node derived from a seed, `b, p, c` being indexed nodes in different depths.

Imagine that a server is watching and creating receiving `c` addresses from `p`'s `xpub`. If one of `c`'s node's private key gets leaked and the server gets hacked, thus revealing `xpub` to the attacker, the attack could now generate `p`'s `xpriv` and with that, all of `c`'s node's private and public address could be derived by the attacker (hardened `c` nodes included).

First question: If `p` was a hardened node, could the attacker still calculate its private key from it's `xpub` and a child's private key ?

Second question: Could the attacker "climb up" the depth (calculate parent's `xpriv`) from `p` all the way over to `m` after calculating `p`'s `xpriv` from the leaked `c` key and `p`'s `xpub` ? Would a hardened `b` or `p` make a difference here ?

Third question: If a private key from `c`'s depth was leaked and the attacker knew `m`'s `xpub`, could the attacker calculate `m`'s private key or does the exploit only permits calculating the direct parent of a leaked child ?

Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?

**Tags:** wallet, private-key, address-generation, bip32-hd-wallets


---

## 1 answers

### Answer by username_1 on 2018-09-04. Score: 2 | Accepted answer

> First question: If `p` was a hardened node, could the attacker still calculate its private key from it's `xpub` and a child's private key ?

Yes. It doesn't matter how `p` was generated. What matters is how `c` is generated.

> Second question: Could the attacker "climb up" the depth (calculate parent's `xpriv`) from `p` all the way over to `m` after calculating `p`'s `xpriv` from the leaked `c` key and `p`'s `xpub` ?

Only if the attacker also has `b` and `m`'s `xpub`s. An important part of the derivation is the parent's chaincode. The chaincode is part of the `xpub` and if the attacker does not have the chaincode, then he cannot derive the parent's private key.

> Would a hardened `b` or `p` make a difference here ?

If the attacker had `b` and `m`'s chaincodes, yes, hardening would make a difference. Hardening entirely prevents this attack. However hardening does not allow someone to have an `xpub` and be able to generate keys without the private key.

> Third question: If a private key from `c`'s depth was leaked and the attacker knew `m`'s xpub, could the attacker calculate m's private key or does the exploit only permits calculating the direct parent of a leaked child ?

The attack only operates on a child key and its direct parent extended public key.

However, given `m`'s xpub and `c`s private key, it may still be possible to recover `m`'s private key even though it is not `c`'s direct parent. If `b` and `p` are derived using unhardened derivation, then `m` can be used to derive `b` and `p`'s `xpub`s. From there, with all of those `xpub`s, the attacker can work backwards from `c` in order to get `m`.

If `b` and `p` are hardened, then it is not possible.

> Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?

Take BIP 44 for example. It define a standard derivation path of `m/44'/0'/0'/i/k`. The xpub at `m/44'/0'/0'` is given out. But since it itself is derived with hardened derivation, if any of `m`, `m/44'` or `m/44'/0'`'s `xpub`s are leaked, the user's master key is still safe since hardened derivation is used.

Additionally, Bitcoin Core derives all keys using hardened derivation. This is because it uses BIP 32 for the easier backup function (you can use an older backup and still get all of the same keys) rather than for the auditability.

> **Comments:**
> **username_2**: Chaincodes are intended to be shared with others-- not published on the blockchain, but not secret data.  Describing BIP32 public derivation being secure against private key relations so long as the attacker doesn't know the chain code is technically correct, but might be a little dangerously misleading.  
> **username_0**: So in the above path, if any `c`'s `xpriv` and `p`'s `xpub` were known, only `c`'s nodes would be exposed and the attacker couldn't do anything else to the rest of the `c`'s parent nodes. In essence, hardening nodes is only useful in a scenario where `m` or `b`'s `xpub`s are also known, rendering the whole tree exposed with any `c` private key, is that correct ?  
> **username_1**: Yes, that is correct. But as username_2 points out, the chaincode is meant to be shared and sharing the chaincode will result in the entire tree be exposed.  
> **username_0**: Alright that's all I needed to know, thank you !  

---

