secure element: Access to private key for backup

[MaJerle]

Device uses top notch secure element to protect the key. Few questions, before I decide to buy:

• Will device display private key at configuration to back it up in case something goes badly wrong?
  • If yes, does it mean it is possible to read the private key from secure element?
  • If no, how can we ensure private key backup in case of device failure or firmware update failure?
• If I have a private key from another wallet, can I reuse this key and load it to this wallet?

In case of Ledger, there is ST33 MCU which stores private key and runs most of the software, so it is easy to print words on the display. But here it is different.

[benma]

The secure element does not store the seed, it is used instead to stretch the encryption key that is used to encrypt the seed. See https://bitbox.swiss/blog/best-of-both-worlds-using-a-secure-chip-with-open-source-firmware/ for more details.

As for backups, please see this: https://shiftcrypto.support/help/en-us/5-backup - you can make backups and restore backups of other wallets. When restoring from other wallets, there may be complications depending on the coin and wallet, as the derivation paths are not always compatible. See this as an example: https://bitbox.swiss/blog/moving-from-your-ledger-nano-s-or-nano-x-to-the-bitbox02-is-easy/

[MaJerle]

How do you protect communication between main MCU and secure chip? If someone would read what's happening on the communication lines, and at the same time open the main MCU (in your article, you pointed that this is possible and that some countries make it legal), would this allow them to crack the info?

If not, how do you make sure it is the case?

[benma]

If you tap the I2C bus, the seed would not be leaked. The transport is encrypted for many chip commands, but the primary reason it won't leak the seed is that the seed is never even transmitted there.

The answer lies in the picture you added actually. The secure chip receives the hash of your device password (so not your password), and applies KDF to it with internal keys. The output is then again hmac'd with your password, which results in the final encryption key. This means that the secure chip (and the communication line to the MCU) never have the seed nor the encryption key of the encrypted seed.

[MaJerle]

If you tap the I2C bus, the seed would not be leaked. The transport is encrypted for many chip commands, but the primary reason it won't leak the seed is that the seed is never even transmitted there.

What is the encryption mechanism between MCU and secure chip so that if someone listens on I2C port all traffic, it cannot get the data?

The answer lies in the picture you added actually. The secure chip receives the hash of your device password (so not your password), and applies KDF to it with internal keys. The output is then again hmac'd with your password, which results in the final encryption key. This means that the secure chip (and the communication line to the MCU) never have the seed nor the encryption key of the encrypted seed.

From what I understand, personal password (the one that user enters to the device) is the key info to prevent data to be stolen, correct?

If for instance person desolders MCU from device and reads non-volatile memory, it can get access to the salt of the device which is mixed with the user input. Devices have counter which prevents against brute force but only up to some extent (10 attempts if I well understood).

If a person steals the salt from one device and takes your firmware, builds it in a way the counter part is removed from the code, it can technically try many times to guess the user password, whose sha256(password|salt) is sent to secure element (that is device specific), until response from the secure element matches the data from scanned I2C line.

So the only way to really be secure, is for attacker to not get lucky and guessing user password against ~750000 trials which is the max counter inside the secure element? If user password (pin code?) is 8 characters, thats 64-bit key (in case of ASCII, or maybe 7-bits per character, which is indeed way smaller than 750000 max possible trials. In case of 64-bits, this is 4E-12% of chances, which is indeed very small.

Then they have a key to decrypt the key stored in the main MCU.

Please confirm or deny this theory.

Wouldn't such problems (salt problem in this case) be solved by using (for instance) STM32H5 MCU, which has HUK - Hardware Unique Key, that stores 256-bit key not available to the user nor the core and only accessible by Secure AES, which is DPA protected?

[benma]

To invoke the KDF command on the chip, its CheckMac command needs to be called with an auth key, which is stored in MCU flash split into two different locations. The output of secure chip's KDF command is then encrypted using an encryption key which is stored also in MCU flash split into two different locations.

I didn't go over your calculations in detail, but in general yes, the secure chip limits the number of total tries as you state, and the goal of that is to thwart brute force attempts for any reasonable password.

I can't answer your last question, as I am not familiar with this - we'd need to research it. Thanks for the input!

[MaJerle]

Thanks, I will close the question.