Using read protected AES keys from application code

[schickb]

ESP32-C3 and similar parts let you set an XTS_AES_128_KEY efuse block that is write and read protected so that only internal ROM code can access it for flash encryption and decryption.

Is there a way do something similar for general purpose AES crypto through mbedtls or even direct ROM calls? For example, I'd like to set BLOCK_KEY5 to a USER key, and read and write protect it, then be able to tell the AES ROM to load that key.

I've looked around /components/hal and /components/mbedtls/port/aes/ but don't see anything that indicates you can pass a efuse identifier in for an AES key. Have I missed something? If not, this would be a nice feature and most of it appears to be there already.

[MicroController]

It seems that, at least on the C3, there is not a direct way to do that. There is however an indirect one, see https://docs.espressif.com/projects/esp ... parameters
The gist of it is to use the HMAC peripheral for key derivation from a read-protected eFuse block.
Haven't quite thought it through, but I believe you can build a secure protocol for certain use cases from that; specifically it seems to me that you can only tie encryption/decryption to a certain device this way and it will keep a secret part of the key secret; but it cannot protect the key from being used, for both encryption and decryption, by any (malicious) software running on the device.

[ESP_Mahavir]

Hello,

Is there a way do something similar for general purpose AES crypto through mbedtls or even direct ROM calls? For example, I'd like to set BLOCK_KEY5 to a USER key, and read and write protect it, then be able to tell the AES ROM to load that key.

Read (and write) protection is available only for the AES-XTS key used in flash encryption scheme on ESP32-C3, not for a general purpose AES key. One approach here could be to enable secure (trusted boot) and then use application specific EFuse block to store the symmetric encryption key. In this case, key can be used for generic encryption/decryption purpose but it is accessible (readable) to trusted software only.

The gist of it is to use the HMAC peripheral for key derivation from a read-protected eFuse block.

Good point! This could be another option. HMAC peripheral supports keys in EFuse with read protection enabled. HMAC peripheral can be used to further derive the symmetric encryption key using HMAC-SHA256 scheme. This combined with the secure (trusted) boot can also offer a good option where the derived key is only accessible to the trusted software running on the device.

Hope this helps!

[schickb]

Read (and write) protection is available only for the AES-XTS key used in flash encryption scheme on ESP32-C3, not for a general purpose AES key. One approach here could be to enable secure (trusted boot) and then use application specific EFuse block to store the symmetric encryption key. In this case, key can be used for generic encryption/decryption purpose but it is accessible (readable) to trusted software only.

I am using secure boot v2 and I understand that means the device will only run signed code, but if someone has the physical device in their hands and can get to all the pins, isn't it possible to use various tools to dump readable efuses and get the key?

The key could alternatively be stored in encrypted NVS which should only be readable by signed code.

The gist of it is to use the HMAC peripheral for key derivation from a read-protected eFuse block.

Thanks, I can think of a few ways to generate a key... signing a known message is one of them. What would be simpler to implement, and I assume more secure, is a feature that worked like the DS module or flash encryption that did not let application code or efuse readers access the key. Seems like the C3 chip has most of what's needed for this already.

[MicroController]

Btw, the read-protected efuses are not always 100% secure: https://limitedresults.com/2019/11/pwn- ... xtraction/
Don't know if that still applies to current ESP32's or any -C or -S SoCs.

[ESP_Sprite]

Btw, the read-protected efuses are not always 100% secure: https://limitedresults.com/2019/11/pwn- ... xtraction/
Don't know if that still applies to current ESP32's or any -C or -S SoCs.

Newer chips (ECO3 and -C and -S SOCs) have counter-measures against shenanigans like the ones you mentioned.

[schickb]

If someone has the physical device in their hands and can get to all the pins, isn't it possible to use various tools to dump readable efuses and get the key?

Is the statement above true? Asked another way... Is there a way to prevent someone with access to a chip from reading out efuses that are "readable"?

The technical manual says: "If read-protection for some data is not enabled, that data is readable from outside the chip". That makes me think there isn't a way to prevent reading efuses that cannot be read-protected. If so, I don't see how the suggestion of using secure boot alone would help. Encrypted NVS or a dynamically generated key would still be needed to prevent someone from obtaining the key.

All leading back to the suggestion that this would be nice feature in the future.

[ESP_Sprite]

If someone has the physical device in their hands and can get to all the pins, isn't it possible to use various tools to dump readable efuses and get the key?

Is the statement above true? Asked another way... Is there a way to prevent someone with access to a chip from reading out efuses that are "readable"?

The technical manual says: "If read-protection for some data is not enabled, that data is readable from outside the chip". That makes me think there isn't a way to prevent reading efuses that cannot be read-protected. If so, I don't see how the suggestion of using secure boot alone would help. Encrypted NVS or a dynamically generated key would still be needed to prevent someone from obtaining the key.

All leading back to the suggestion that this would be nice feature in the future.

It's about layers of protection. Not read-protecting the eFuses doesn't mean that anyone with a JTAG probe can simply walk along and steal your keys, but it does mean that the CPU now has access to those keys. You can then fence off the CPU by enabling secureboot and flash encryption, disabling JTAG and download mode and so forth and you can still make it theoretically impossible to get the eFuses. However, your attack surface is now larger: an attacker 'only' needs to find something exploitable so they're able to run code on the CPU and they will be able to exfiltrate the keys.

Btw, the proper way here is (as suggested) to use HMAC to derive a key from the read-protected eFuse key, then use AES with this derived key to do en/decryption. In downstream mode (configurable by eFuse), the HMAC->AES key path also is protected, as in the CPU can access neither the eFuses with the original key material nor the derived AES key.

[NStorm]

In downstream mode (configurable by eFuse), the HMAC->AES key path also is protected, as in the CPU can access neither the eFuses with the original key material nor the derived AES key.

It's an old post, but this sentance got my attention. Could you please confirm this and specify ESP32 part which supports such feature?
Because I don't see anything like that on both ESP-IDF & Technical RM for ESP32-C3. According to docs it can only downstream to DS or JTAG RE-ENABLE:

Furthermore, ESP32-C3 has three different application scenarios for its HMAC module:

HMAC is generated for software use
HMAC is used as a key for the Digital Signature (DS) module
HMAC is used for enabling the soft-disabled JTAG interface

The first mode is called Upstream mode, while the last two modes are called Downstream modes.

[ESP_Sprite]

Sorry, you are correct. DS internally uses the AES peripheral, which probably confused me.