Possible attack vector of BIP32 HD wallet

Question

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 ?

Answer 1

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 xpubs. 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 cs 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 xpubs. From there, with all of those xpubs, 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 xpubs 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.