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.
How does Flash Encryption (aka Secure Boot) work?
-
- Posts: 1
- Joined: Mon Sep 05, 2016 6:44 am
Re: How does Flash Encryption (aka Secure Boot) work?
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.
-
- Posts: 9833
- Joined: Thu Nov 26, 2015 4:08 am
Re: How does Flash Encryption (aka Secure Boot) work?
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.
Re: How does Flash Encryption (aka Secure Boot) work?
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.
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.
Re: How does Flash Encryption (aka Secure Boot) work?
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.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.
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
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.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Re: How does Flash Encryption (aka Secure Boot) work?
No I don't think so it is used for Mac address and general purpose. Maybe also have to disable JTAG to be secure.rudi ;-) wrote:Theoretically the efuse otp memory is secure - or do you think not? ( its a question )
Re: How does Flash Encryption (aka Secure Boot) work?
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.
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.
Re: How does Flash Encryption (aka Secure Boot) work?
Sounds good. So if enabled all flash r/w are encrypted including data? Is there a performance penalty?
Re: How does Flash Encryption (aka Secure Boot) work?
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.
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: Google [Bot] and 153 guests