MobileCoin Key Derivation Upgrade: Migration to Mnemonics

MobileCoin wallets all start with a random seed. This seed is then expanded (through a process called Key Derivation) into two cryptographic keys, which you use to receive and spend MOB (MobileCoin’s currency). The process of expansion is important to get right, because without enough randomness in the seed or without a robust expansion algorithm, you could end up with insecure keys, making your wallet vulnerable.

In addition, several hardware wallets exist which would be great to integrate with MOB. These typically rely on standardized approaches to key derivation. However, the key derivation scheme supported when MOB launched was not compatible with existing cross-wallet schemes.

We recently upgraded our key derivation procedure to better fit with the current crypto ecosystem and support mnemonics, which are widely used. New MobileCoin wallets can be unlocked with a set of 24 words. For more details, please read the technical explanation below.

In April 2021, the MobileCoin core implementation started using a new method for creating accounts. Accounts created before that date will no longer be actively supported (aside from limited support for fund-recovery). Users with old accounts may want to create new accounts (using ‘mnemonics’ instead of a ‘root entropy’) and transfer their funds.

Deprecating Root Entropies

At MobileCoin’s launch, a person who made a new account acquired a so-called ‘root entropy’, which was a random 32-byte number. This root entropy was used to derive the view and spend cryptographic keys required for receiving and spending MobileCoins.

There were two limitations with MobileCoin’s use of root entropies for key derivation.

Limitation 1

Private view and spend keys (they are Ristretto255 private keys) were computed by running the root entropy through HKDF-Blake2b. HKDF is the key-derivation function defined in RFC5869. It is built on top of HMAC, defined in RFC2104. HMAC is designed to interact with a user-defined cryptographic hash function (e.g. Blake2b in our case).

RFC2104 (HMAC) states in S2, P1:

“The definition of HMAC requires a cryptographic hash function, which we denote by H, and a secret key K. We assume H to be a cryptographic hash function where data is hashed by iterating a basic compression function on blocks of data.”

Since HKDF is built on HMAC, it depends on HMAC’s security assumptions and proofs. However, it turns out Blake2b is a ‘sponge construction’ built on ‘extensible-output functions’, which are unfortunately not the same as ‘compression functions’.

As a result, HKDF-Blake2b is not provably secure (or at least, it has not been proven secure at this point in time), because Blake2b is based on an extensible-output function while the HMAC security proof requires a hash function based on a compression function.

Limitation 2

Using a root entropy to derive keys is not well-standardized.

New: Mnemonics-Based Key Derivation

With the new account-generation method, users will obtain a BIP-39 ‘mnemonic’, which is a set of 24 words selected from a pre-defined list. Word selection is based off of a 32-byte randomly generated number concatenated with a 1-byte checksum. Private view and spend keys are derived from the mnemonic using the following set of steps (actually, multiple accounts can be derived from the same mnemonic).

• Convert the mnemonic word-list to a mnemonic-seed (following the BIP-39 specification; note that current MobileCoin wallet implementations explicitly do not support non-null BIP-39 passwords for the conversion from mnemonic word-lists to seeds, to simplify the user experience as much as possible).
• Create a BIP-32 ‘path’ that looks like this:

mnemonic-seed/44/866/account_index
mnemonic-seed: the mnemonic seed
44: indicates this BIP-32 'path' is BIP-44-compliant (it is only partially compliant, see the discussion below)
866: MobileCoin's 'coin_type' registered with SLIP-0044
account_index: the index of this account (there can be multiple account indices corresponding to different accounts derived from the same mnemonic)

• Pass the BIP-32 ‘path’ to a SLIP-0010-compliant key derivation function. This function performs a series of HMAC-SHA512 hashes on the ‘path’ and produces a SLIP-0010 key.
• Use HKDF-SHA512 to hash the SLIP-0010 key from the previous step, with two different domain-separation strings (“mobilecoin-ristretto255-view” and “mobilecoin-ristretto255-spend”). This produces the account’s private view and spend keys, which can be used to receive and spend MobileCoins.

MobileCoin’s mnemonic key-derivation scheme relies on a number of standards (BIP-32, BIP-39, BIP-44, SLIP-0010, SLIP-0044, and the interface expectations of HKDF which requires a hash function that uses a compression function [i.e. SHA512]). Readers should note that the last step is specific to MobileCoin, and not part of any existing standards (which were primarily designed with Bitcoin in mind, where only one private key is required to receive/spend funds, not two).

BIP-44 Deviation

BIP-44 defines BIP-32 paths with the following semantics:

m / purpose’ / coin_type’ / account’ / change / address_index

However, MobileCoin key-derivation paths exclude the ‘change’ and ‘address_index’ components. In MobileCoin, users do not create an address directly from their private view and spend keys. Instead, they generate so-called ‘subaddresses’ from those keys. Each subaddress has its own ‘subaddress index’.

MobileCoin users can efficiently recover funds sent to many different subaddresses derived from the same view/spend private key pair. In particular, money sent to a normal subaddress can be recovered alongside money sent to a designated ‘change’ subaddress.

In other words, subaddresses provide the same functions as the ‘change’ and ‘address_index’ components of BIP-44 paths, so those components do not need to be supported.

By koe, James Cape and Sara Drakeley