It is often useful to be able to derive many different keys from a single master key. An important example is when using the TSM to implement a wallet for cryptocurrencies, such as Bitcoin. For privacy reasons, a Bitcoin wallet usually prefers to generate a new key for each transaction to be signed. But if the new key is generated randomly, the user will have to create a backup of the new key for each transaction.

Instead, using deterministic key derivation, the wallet can initially create a single master key, which is then backed up. Later, for each new transaction to sign, the wallet can then derive a fresh, seemingly independent, key from the master key, without having to deal with additional backup.

The TSM supports key derivation for hierarchical, deterministic wallets as specified by BIP32 and SLIP10. BIP32 specifies a deterministic key derivation scheme for Bitcoin wallets. SLIP10 generalizes BIP32 in order to allow derivation for other types of keys. In both schemes, you initially derive a master key from an initial seed. Then from the master key, you can derive a sequence of new keys, where each new key is defined by an integer. These keys can again be used to derive keys, and so on. This forms a tree of derived keys, where each leaf is identified by a derivation path (sometimes called chain path), which is the sequence of integers used to derive that key.

In BIP32 and SLIP10 each key is actually an extended key consisting of the key itself and a chain code. The chain code for a given key is required in order to derive its child keys.

Hardened Key Derivation

The original BIP32 derivation scheme has a potential security issue: If an attacker obtains a derived private key (and the chain code), he can use this to compute any key in the derivation tree. Hardened derivation was later added to the specification to avoid this.

BIP32-compliant hard derivation requires computing HMAC-SHA512 on the private key. In a threshold setting, this turns out to be much less efficient than standard, non-hardened derivation, because it requires so-called general purpose MPC.

But note that it is only a security issue if the derived keys are somehow less protected than the master key. In the TSM, the derived keys are protected by secret sharing, just as the master key, so using non-hardened derivation is not a security concern when keys are kept in the TSM.

Nevertheless, in some cases, hardened derivation does make sense, also for keys in the TSM:

String BIP32 Compliance We may want to import a BIP32 seed from another wallet into the TSM and be able to derive the same keys as derived by the other wallet. Or, similarly, we may want to be able to export a BIP32 seed to another wallet and be able to derive the same keys as in the TSM. Most current wallets follow BIP44, which dictates the initial levels of derived keys to use hardened derivation.
Export of derived keys In some cases, you may want to export derived private keys to environments with less protection than the TSM. In such cases, it makes sense to only export hardened keys, in order to protect the other keys in the derivation tree.

If you need deterministic, hierarchical derivation, but do not need to import BIP32 seeds from - or export seeds to - other BIP32 wallets, then we recommend using only non-hardened hierarchical derivation. This is described further here.

If you need to import BIP32 seeds from - or export BIP32 seeds to - other BIP32 wallets, or if you need to export derived keys from the TSM to some less secure environment, then we recommend using hardened derivation, e.g., as specified in BIP44. You can read more about how hardened key derivation works in the TSM here.

Derivation of EdDSA Keys

See this for more information about our derivation scheme for Ed25519 and Ed448 keys.