How does Flash Encryption (aka Secure Boot) work?

jplarocque
Posts: 1
Joined: Mon Sep 05, 2016 6:44 am

How does Flash Encryption (aka Secure Boot) work?

Postby jplarocque » Mon Sep 05, 2016 6:51 am

I scanned through the datasheet and the ESP32 Technical Reference Manual and couldn't find any description of how Flash Encryption or Secure Boot work.

I've assumed that Flash Encryption and Secure Boot refer to the same feature. Is that true, or if not, what is the difference?

How does a developer take advantage of this feature? How are keys managed and how is protection assured?

Thanks,
-J.P.

jmattsson
Posts: 38
Joined: Fri Jun 03, 2016 5:37 am
Contact:

Re: How does Flash Encryption (aka Secure Boot) work?

Postby jmattsson » Mon Sep 05, 2016 7:07 am

I haven't had time to dive into this yet myself, but the source in https://github.com/espressif/esp-idf/tr ... r/src/main would hopefully explain a few things.

ESP_Sprite
Posts: 9746
Joined: Thu Nov 26, 2015 4:08 am

Re: How does Flash Encryption (aka Secure Boot) work?

Postby ESP_Sprite » Mon Sep 05, 2016 7:53 am

They're both aspects of the same thing, although you can use them separately. (Not sure how much sense that would make, though.) We're preparing documentation on that, at least an abstract of the hardware will be probably in the next techdoc.

WiFive
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

Re: How does Flash Encryption (aka Secure Boot) work?

Postby WiFive » Mon Sep 05, 2016 8:39 am

Most likely... when enabled, the ROM loader will only boot a signed firmware image. The key and enable bit are stored in the efuse otp memory. Because the key is stored in the efuse and you can't boot an unsigned firmware and you can't turn off secure boot and you can't ask the ROM loader to dump it then it is secure. Then you can add encryption so that even directly reading the flash chip protects the data, which is only decrypted on load to ram/cache. Now whether you can have a mixture of encrypted and unencrypted sectors/partitions on the flash and where that is defined I'm not sure.

I assume you could use secure boot without encryption if you are only worried about preventing unsigned code from running. But using encryption without secure boot wouldn't be very secure since someone could replace the flash chip and run unsigned code to dump the encryption key.

User avatar
rudi ;-)
Posts: 1729
Joined: Fri Nov 13, 2015 3:25 pm

Re: How does Flash Encryption (aka Secure Boot) work?

Postby rudi ;-) » Mon Sep 05, 2016 9:24 am

WiFive wrote:
..
The key and enable bit are stored in the efuse otp memory.
Because the key is stored in the efuse and you can't boot an unsigned firmware and you can't turn off secure boot and you can't ask the ROM loader to dump it then it is secure.
..

..But using encryption without secure boot wouldn't be very secure since someone could replace the flash chip and run unsigned code to dump the encryption key.
Am not sure that you can dump the encryption key from stored in the efuse otp memory without secure boot if you try boot unsigned code.

I wait for the modul to do exact this example to try this.
Theoretically the efuse otp memory is secure - or do you think not? ( its a question :) )

the bootloader code is a fine start in esp-idf -
will try to "get/put more" from/to this :mrgreen:

best wishes
rudi ;-)

edit:
the question is too,
how we handle plaintext code to crypt it with the key -
there must be stored the key in flash prozess - esptool does not support this just in time - or i am wrong -
sry - have not deeper read in this theme just in time - but think, there comes an "extended" for this in compile / link / flash prozess
- to encrypt firmware
- to signing firmware
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪

WiFive
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

Re: How does Flash Encryption (aka Secure Boot) work?

Postby WiFive » Mon Sep 05, 2016 10:04 am

rudi ;-) wrote:Theoretically the efuse otp memory is secure - or do you think not? ( its a question :) )
No I don't think so it is used for Mac address and general purpose. Maybe also have to disable JTAG to be secure.

ESP_igrr
Posts: 2071
Joined: Tue Dec 01, 2015 8:37 am

Re: How does Flash Encryption (aka Secure Boot) work?

Postby ESP_igrr » Tue Sep 13, 2016 12:19 am

Some parts of OTP, such as flash encryption key, are not readable from application. It is generated by hardware and stored in OTP. Flash decryption engine can load encryption key directly from OTP.

While you can't dump encryption key directly, you can use bootloader mode to dump contents of flash memory by uploading a small piece of code directly into IRAM. There are no provisions for code signing of code uploaded into IRAM.

So to make use of flash encryption one must also disable uart bootloader using one of the OTP bits.

If encryption flag in OTP is set, all code in flash will be encrypted. It is not possible to have one application binary in unencrypted form and another in encrypted form.

Encryption of uploaded code works on the chip itself. Second stage bootloader will check whether an application has already been encrypted. If it's not encrypted yet, bootloader will encrypt it in-place. It will also encrypt itself if necessary.
The reason this is implemented in the 2nd stage bootloader is to support mass-programming of flash chips (they can be programmed with the plaintext firmware and then will automatically be encrypted on first start).

All this will be described in more detail in the documentation.

WiFive
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

Re: How does Flash Encryption (aka Secure Boot) work?

Postby WiFive » Tue Sep 13, 2016 9:13 am

Sounds good. So if enabled all flash r/w are encrypted including data? Is there a performance penalty?

ESP_igrr
Posts: 2071
Joined: Tue Dec 01, 2015 8:37 am

Re: How does Flash Encryption (aka Secure Boot) work?

Postby ESP_igrr » Tue Sep 13, 2016 12:07 pm

There are normal spi_flash_read/write APIs which allow data to be read and written without encryption, and there are also spi_flash_read_decrypt/write_encrypt APIs (not merged into master yet), which decrypt/encrypt data. So you (or the one who implements a filesystem, for example) can decide. Encryption has some performance penalty, but i don't have any quantitative data on this. Decryption is handled by reading via cache, so there is not penalty in this case.

One thing to note: if you do use encryption, everything read via cache (ICACHE or DCACHE) will be decrypted. So it is not possible to read unencrypted data using cache if encryption is used.

Who is online

Users browsing this forum: Baidu [Spider], Google [Bot] and 84 guests