Questions regarding flash encryption and Secure Boot

[ESPtronic]

Hello, I've ben reading the ESP-IDF docs and I have a few questions regarding flash encryption and Secure Boot.
Why did you design the ESP32 so that you have to burn an efuse (FLASH_CRYPT_CNT) for updating via serial, limiting the number of reflashes? Couldn't it just encrypt the firmware by default?
Also, why not send the key to the computer after enabling flash encryption or Secure Boot, before read and write protecting it?
And why aren't physical reflashes possible after enabling flash encrytion and Secure Boot at the same time?
Can I store an OTA binary pre-encrypted in the server, and then flash it without it being encrypted again?

[gawied]

Hi Esptronic

I have more or less the same questions and would like to know if you did get any further with your questions?

Cheers,
Gawie

[ESP_Sprite]

You are talking reflashes *of the bootloader* here. The bootloader is meant to use whatever method it wants (in the stock esp-idf bootloader: public/private keypairs) to validate the actual firmware. This way, the actual firmware itself can neatly be signed with a private key and be reflashed however many times you want/need. For the bootloader reflash: Sending the key to the computer would weaken it, because it would mean it's available in an extra location which can be breached; keeping it in the ESP32 and letting the ESP32 do all the work is more secure. With this in mind: physical reflashes aren't possible after enabling flash encryption and secure boot because you will only be able to write the flash unencrypted, and the flash needs to be both signed with the public key for the bootloader (not a problem; you should have that) as well as encrypted with the flash encryption key (which you do not have).

[ESPtronic]

Sending the key to the computer would weaken it

Yes, but why not offer it as an option? After all there's an option for pregenerating your own key, that may be even less safe, depending on the randomness of the source (I'm going to use it anyway).

as well as encrypted with the flash encryption key (which you do not have)

So if I use the pregenerated key, I can do unlimited reflashes?

And a final question, how difficult would it be to customize the bootloader?

[ESP_Angus]

Sending the key to the computer would weaken it

Yes, but why not offer it as an option? After all there's an option for pregenerating your own key, that may be even less safe, depending on the randomness of the source (I'm going to use it anyway).

It's an interesting suggestion. The main problem I can see is designing a protocol and the related tooling to make sure you successfully receive each key on the computer before it's read & write protected on the ESP32, after which it would be lost forever. While making sure that it's not possible to accidentally ship devices where the key has been generated but is not yet read & write protected, or the flash is not yet encrypted (encrypting of the flash happens on first boot).

This is certainly all possible, but it's complex - and the encryption & secure boot features are quite complex already. Having a few supported options that work well is better than having a lot of options which may work less well.

as well as encrypted with the flash encryption key (which you do not have)

So if I use the pregenerated key, I can do unlimited reflashes?

Yes, if you generate the key locally and pre-burn it to the ESP32 then you can reflash each device as many times as you want by encrypting the binary on the computer before flashing. See here:

http://esp-idf.readthedocs.io/en/latest ... yption-key

At the moment this process isn't fully integrated into the IDF build system, so there are some manual steps (documented at the link). Let us know if you encounter any problems or have any questions.

And a final question, how difficult would it be to customize the bootloader?

Quite easy. If you copy the $IDF_PATH/components/bootloader directory to (your project)/components/bootloader then you can go ahead and make any modifications to the bootloader source that you need to. The component in your project will override the component in IDF.

A lot of the code for secure boot & flash encryption is in the bootloader_support component as well. You can copy this to override it as well, in the same way.

Please keep in mind that if you copy & modify IDF components:

• We can't necessarily support you if things go wrong.
• Updating IDF becomes a little more complex as you'll need to pay attention to changes in these components.

[ESPtronic]

Thanks everyone for your help. I suppose I'll just use a high entropy source (a TRNG), (e.g. using avalanche noise). The reason I want to use a pregenerated key is the following: imagine you have 1 million devices in production, and then you make a mistake that makes OTA updates impossible. You forget to test it, and suddenly you get complaints, when all the devices have already been updated! Oops! Then you would have to replace the ESP32 in every single device you have, since you can't reprogram it. That would be around 3 million euros/dollars/pounds + shipping + desoldering and resoldering the ESP32. A very expensive mistake! In change, with the key, you would only have to reprogram it via serial. Advanced users could even do this at home, saving you lots of money and time.

I had another question, about storing the binary pre-encrypted in the server. AFAIK, the esp_spi_flash_write function will write unencrypted data when the write_encrypted parameter is set to false. So if I use this function when updating via OTA, will I be able to do this?

[ESP_Angus]

Thanks everyone for your help. I suppose I'll just use a high entropy source (a TRNG), (e.g. using avalanche noise). The reason I want to use a pregenerated key is the following: imagine you have 1 million devices in production, and then you make a mistake that makes OTA updates impossible. You forget to test it, and suddenly you get complaints, when all the devices have already been updated! Oops! Then you would have to replace the ESP32 in every single device you have, since you can't reprogram it. That would be around 3 million euros/dollars/pounds + shipping + desoldering and resoldering the ESP32. A very expensive mistake! In change, with the key, you would only have to reprogram it via serial. Advanced users could even do this at home, saving you lots of money and time.

Right. This is a potential risk, and the only way to mitigate it at the moment is careful testing. But storing the pregenerated keys is a good strategy if you are concerned about this.

I had another question, about storing the binary pre-encrypted in the server. AFAIK, the esp_spi_flash_write function will write unencrypted data when the write_encrypted parameter is set to false. So if I use this function when updating via OTA, will I be able to do this?

What you describe is tecnically possible. At the moment the built-in OTA operations use esp_partition_write() internally, which will automatically encrypt when writing an encrypted partition. So it's not possible with the built-in OTA update mechanism.

We'd normally recommend using HTTPS to secure the update in transit instead (you can have the firmware authenticate itself to the server in some way if necessary), and then send the binary itself unencrypted. This is also much simpler (only one binary on the server side).

[WiFive]

Smart to have a reset button to boot factory image (or previous good image) and a flash chip big enough to hold it. Also if you have a small factory image that can do encrypted OTA over serial with a "recovery key" you don't need to know the flash encryption key.

[ESP_Angus]

Smart to have a reset button to boot factory image (or previous good image)

This feature is on our list to add to the bootloader in IDF V3.1.

It's currently quite straightforward to create a custom bootloader (as described above) and implement your own "reset to factory" hooks, though.

[ESPtronic]

We'd normally recommend using HTTPS to secure the update in transit instead (you can have the firmware authenticate itself to the server in some way if necessary), and then send the binary itself unencrypted.

That's another option that could be feasible. I was thinking in the following method:

1. The server sends a single-use token encrypted with a key stored in the ESP32 (which would have its flash contents encrypted).
2. The ESP32 makes a request with the decrypted token, authenticating itself. The token expires immediately.
3. The server sends the binary, checking that it's sending it through HTTPS, and not HTTP.

Yet another option would be to encrypt it with another key and decrypting it on the ESP32, but that would be more difficult than simply writing it decrypted.

This is also much simpler (only one binary on the server side).

Why would I have to store more than one binary if I write it decrypted? I would only have to store the encrypted binary.

Smart to have a reset button to boot factory image (or previous good image) and a flash chip big enough to hold it.

That would be pretty easy, since there's already a "factory" image when you activate OTA.