ESP32 Forum • Generic questions about secure boot & flash enc - Page 2

Page 2 of 3

Re: Generic questions about secure boot & flash enc

Posted: Sun Mar 24, 2019 7:59 pm

by urbanze

I've been thinking more about this part of server-side authentication and I ended up having another small idea, please see if it's reasonably valid (this does not have to be extreme secure), since the server does not seem to do any certification for me.

Since I will enable Flash Crypto, no one can get good code in there, so I plan on leaving an AES key.

The upload of the binary to the server will no longer be the RAW .bin file, but rather the encrypted file with the same key, so at least the file stays safe on the server until someone obtains the key (hacking my PC or ..?). During download, esp will decrypt and flashing new soft.

1. Is it a viable solution?

2. I think it's viable only if no one can get the key stored in Flash, so will a const string inside the code always be encrypted for anyone to read? Or I'll need to add some partition (like nvs) with Flag Encryp. and there to store the key? Or what simple method to keep const char secure?

Re: Generic questions about secure boot & flash enc

Posted: Mon Mar 25, 2019 5:31 am

by Angus

1. Is it a viable solution?

Yes. In fact, we plan to implement a similar feature in ESP-IDF but we have no ETA for this feature yet.

The only important consideration is to use sufficiently strong encryption method on the statically encrypted firmware. (ie not AES ECB, probably a mode with a random IV which is distributed alongside the file, etc.)

2. I think it's viable only if no one can get the key stored in Flash, so will a const string inside the code always be encrypted for anyone to read? Or I'll need to add some partition (like nvs) with Flag Encryp. and there to store the key? Or what simple method to keep const char secure?

Storing as const data in the code should be fine. Access to this data is equivalent to accessing the firmware in general, so it will be encrypted in the flash if flash encryption is enabled.

Re: Generic questions about secure boot & flash enc

Posted: Wed Mar 27, 2019 6:17 pm

by urbanze

After begin of my Flash Crypto tests with pregenerate key, I got the maxium value of FLASH_CRYPT_CNT.

Now, after many commands of flash, reflash and etc

, ESP32 logging (this when use make flash in terminal)

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

In terminal, upload still working, but I tried to reflash new (bootloader.bin & partitions.bin & app.bin) in decrypted or crypted (with

Code: Select all

espsecure.py encrypt_flash_data --keyfile my_flash_encryption_key.bin --address 0xXXXX -o build/my-app-encrypted.bin build/my-app.bin

form, but still getting error log (log change with crypted form). Whats happen? Upload really turned off even terminal not tell me about any error? Or I do something wrong?

When flash bootloader,partitions,ota_data_initial and app in crypted forms, log is:

Code: Select all

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:880
ho 0 tail 12 room 4
load:0x40078000,len:9884
load:0x40080400,len:6160
entry 0x40080678
ets Jun  8 2016 00:22:57

Can I revive this esp? What need to do?

Re: Generic questions about secure boot & flash enc

Posted: Wed Mar 27, 2019 10:18 pm

by Angus

The first message "flash read err, 1000" indicates that the ESP32 can't read the bootloader from flash at offset 0x1000. This can happen if (for example) this area of the flash is not written correctly, or is written with plaintext bootloader when it should be ciphertext, or ciphertext when it should be plaintext. In any case, the root cause is a bad flash.

The second message "load:0x3fff0018,len:4 ...entry 0x40080678 ..." looks like it's loading the bootloader from flash OK, but then resetting afterwards.

(Some general information about boot messages can be found here: https://github.com/espressif/esptool/wi ... de-message )

It should be possible to fix whatever is causing the second message, so that this ESP32 can work correctly again.

Some questions

Is the "rst:" reason "SW_RESET" each time? Is it possible your code is actually resetting the ESP32 without doing anything else?
Have you disabled logging for the bootloader in menuconfig? If yes, can you please set it to Warning or Error level and rebuild the bootloader.
What IDF version are you using?
What is the output of "espefuse.py summary"?
Can you please post the exact commands you are using to encrypt and then flash the bootloader (and the output of each command, if you can get this).

Re: Generic questions about secure boot & flash enc

Posted: Thu Mar 28, 2019 11:58 am

by urbanze

The first message "flash read err, 1000" indicates that the ESP32 can't read the bootloader from flash at offset 0x1000. This can happen if (for example) this area of the flash is not written correctly, or is written with plaintext bootloader when it should be ciphertext, or ciphertext when it should be plaintext. In any case, the root cause is a bad flash.

The second message "load:0x3fff0018,len:4 ...entry 0x40080678 ..." looks like it's loading the bootloader from flash OK, but then resetting afterwards.

(Some general information about boot messages can be found here: https://github.com/espressif/esptool/wi ... de-message )

It should be possible to fix whatever is causing the second message, so that this ESP32 can work correctly again.

Some questions

Is the "rst:" reason "SW_RESET" each time? Is it possible your code is actually resetting the ESP32 without doing anything else?

Have you disabled logging for the bootloader in menuconfig? If yes, can you please set it to Warning or Error level and rebuild the bootloader.

What IDF version are you using?

What is the output of "espefuse.py summary"?

Can you please post the exact commands you are using to encrypt and then flash the bootloader (and the output of each command, if you can get this).

Answering your questions:
1. Yes, no.
2. See end of this post.
3. v4.0-dev-76-g96aa08a0f-dirty
4.eFuse summary

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/espefuse.py --port /dev/ttyUSB1 summary
espefuse.py v2.6
Connecting........__
EFUSE_NAME             Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 255 R/W (0xff)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/W (0x1)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 1 R/W (0x1)
BLK1                   Flash encryption key                              
  = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/- 
BLK2                   Secure boot key                                   
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLK3                   Variable Block 3                                  
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    Factory MAC Address                               
  = 30:ae:a4:xx:xx:xx (CRC 1d OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 1 R/W (0x1)
CHIP_VERSION           Reserved for future chip versions                 = 0 R/W (0x0)
CHIP_PACKAGE           Chip package identifier                           = 0 R/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 R/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 R/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

5. See below.

Steps to upload crypted binaries

0. Make erase_flash

Code: Select all

make erase_flash monitor -j20
Toolchain path: /home/ze/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a
Compiler version: 5.2.0
Python requirements from /home/ze/esp/esp-idf/requirements.txt are satisfied.
Erasing entire flash...
esptool.py v2.6
Serial port /dev/ttyUSB1
Connecting........_
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None
MAC: 30:ae:a4:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 1.0s
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB1 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

Code in test (this worked at first time)

Code: Select all

extern "C" void app_main()
{
	vTaskDelay(pdMS_TO_TICKS(50));
	rtc_wdt_disable();

	ESP_LOGW("ESP32", "Flash crypto: %d", esp_flash_encryption_enabled());
}

Partition table in test (this worked at first time)

Code: Select all

# Name,     Type,   SubType,    Offset,     Size,   Flags
factory,    app,    factory,    0x10000,    1M,
ota_0,      app,    ota_0,      ,           1M,
ota_1,      app,    ota_1,      ,           1M,
otadata,    data,   ota,        ,           8K,
nvs,        data,   nvs,        ,           8K,
cfg,        data,   nvs,        ,           48K,
log,	    data,   nvs,	    ,           72K,
gnr,        data,   nvs,        ,           100K,
coredump,   data,   coredump,   ,           200K,
phy_init,   data,   phy,        ,           4K,

1. Delete build folder and "Make all".

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB1 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x310000 /home/ze/esp/Flashtest/build/ota_data_initial.bin 0x1000 /home/ze/esp/Flashtest/build/bootloader/bootloader.bin 0x10000 /home/ze/esp/Flashtest/build/esp32.bin 0x8000 /home/ze/esp/Flashtest/build/partitions.bin

2. Crypting this 4 .bin

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/espsecure.py encrypt_flash_data --keyfile flash_key.bin --address 0x8000 -o enc/partitions.bin build/partitions.bin
espsecure.py v2.6
Using 256-bit key
Note: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/espsecure.py encrypt_flash_data --keyfile flash_key.bin --address 0x10000 -o enc/esp32.bin build/esp32.bin
espsecure.py v2.6
Using 256-bit key
Note: Padding with 12 bytes of random data (encrypted data must be multiple of 16 bytes long)

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/espsecure.py encrypt_flash_data --keyfile flash_key.bin --address 0x1000 -o enc/bootloader.bin build/bootloader/bootloader.bin
espsecure.py v2.6
Using 256-bit key

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/espsecure.py encrypt_flash_data --keyfile flash_key.bin --address 0x310000 -o enc/ota_data_initial.bin build/ota_data_initial.bin
espsecure.py v2.6
Using 256-bit key

3. Upload 4 .bin (same command that make all give me)

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB1 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x310000 /home/ze/esp/Flashtest/enc/ota_data_initial.bin 0x1000 /home/ze/esp/Flashtest/enc/bootloader.bin 0x10000 /home/ze/esp/Flashtest/enc/esp32.bin 0x8000 /home/ze/esp/Flashtest/enc/partitions.bin

4. Make monitor, this log is "very high output rate", flooding monitor

Code: Select all

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6176
ho 0 tail 12 room 4
load:0x40078000,len:11752
ho 0 tail 12 room 4
load:0x40080400,len:6712
entry 0x400806f4
E (112) flash_encrypt: Cannot re-encrypt data (FLASH_CRYPT_CNT 0xff write disabled 0
E (112) boot: Flash encryption check failed (-1).
E (114) boot: Factory app partition is not bootable
E (120) esp_image: image at 0x110000 has invalid magic byte
W (126) esp_image: image at 0x110000 has invalid SPI mode 231
E (132) boot: OTA app partition slot 0 is not bootable
E (138) esp_image: image at 0x210000 has invalid magic byte
W (144) esp_image: image at 0x210000 has invalid SPI mode 67
W (151) esp_image: image at 0x210000 has invalid SPI size 14
E (157) boot: OTA app partition slot 1 is not bootable
E (163) boot: No bootable app partitions in the partition table
ets Jun  8 2016 00:22:57

After upload all .bin crypted, I uploaded only app.bin in plaintext

Code: Select all

python /home/ze/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB1 --baud 921600 write_flash --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 /home/ze/esp/Flashtest/build/esp32.bin
esptool.py v2.6
Serial port /dev/ttyUSB1
Connecting........_
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None
MAC: 30:ae:a4:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 140356 bytes to 71782...
Wrote 140356 bytes (71782 compressed) at 0x00010000 in 1.3 seconds (effective 876.7 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6176
ho 0 tail 12 room 4
load:0x40078000,len:11752
ho 0 tail 12 room 4
load:0x40080400,len:6712
entry 0x400806f4
E (32) esp_image: image at 0x10000 has invalid magic byte
W (32) esp_image: image at 0x10000 has invalid SPI mode 11
W (34) esp_image: image at 0x10000 has invalid SPI size 6
E (40) boot: Factory app partition is not bootable
E (46) esp_image: image at 0x110000 has invalid magic byte
W (52) esp_image: image at 0x110000 has invalid SPI mode 231
E (58) boot: OTA app partition slot 0 is not bootable
E (64) esp_image: image at 0x210000 has invalid magic byte
W (70) esp_image: image at 0x210000 has invalid SPI mode 67
W (76) esp_image: image at 0x210000 has invalid SPI size 14
E (83) boot: OTA app partition slot 1 is not bootable
E (88) boot: No bootable app partitions in the partition table
ets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6176
ho 0 tail 12 room 4
load:0x40078000,len:11752
ho 0 tail 12 room 4
load:0x40080400,len:6712
entry 0x400806f4
E (64) esp_image: image at 0x10000 has invalid magic byte
W (64) esp_image: image at 0x10000 has invalid SPI mode 11
W (66) esp_image: image at 0x10000 has invalid SPI size 6
E (72) boot: Factory app partition is not bootable
E (78) esp_image: image at 0x110000 has invalid magic byte
W (84) esp_image: image at 0x110000 has invalid SPI mode 231
E (90) boot: OTA app partition slot 0 is not bootable
E (96) esp_image: image at 0x210000 has invalid magic byte
W (102) esp_image: image at 0x210000 has invalid SPI mode 67
W (109) esp_image: image at 0x210000 has invalid SPI size 14
E (115) boot: OTA app partition slot 1 is not bootable
E (121) boot: No bootable app partitions in the partition table
ets Jun  8 2016 00:22:57

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6176
ho 0 tail 12 room 4
load:0x40078000,len:11752
ho 0 tail 12 room 4
load:0x40080400,len:6712
entry 0x400806f4
E (64) esp_image: image at 0x10000 has invalid magic byte
W (64) esp_image: image at 0x10000 has invalid SPI mode 11
W (66) esp_image: image at 0x10000 has invalid SPI size 6
E (72) boot: Factory app partition is not bootable
E (78) esp_image: image at 0x110000 has invalid magic byte
W (84) esp_image: image at 0x110000 has invalid SPI mode 231
E (90) boot: OTA app partition slot 0 is not bootable
E (96) esp_image: image at 0x210000 has invalid magic byte
W (102) esp_image: image at 0x210000 has invalid SPI mode 67
W (109) esp_image: image at 0x210000 has invalid SPI size 14
E (115) boot: OTA app partition slot 1 is not bootable
E (121) boot: No bootable app partitions in the partition table
ets Jun  8 2016 00:22:57

Re: Generic questions about secure boot & flash enc

Posted: Thu Mar 28, 2019 12:34 pm

by WiFive

I got the maxium value of FLASH_CRYPT_CNT.

Yes, that means encryption is permanently disabled so a regular make flash without encryption should work. Time to get a new chip.

Re: Generic questions about secure boot & flash enc

Posted: Thu Mar 28, 2019 12:39 pm

by urbanze

I got the maxium value of FLASH_CRYPT_CNT.
Yes, that means encryption is permanently disabled so a regular make flash without encryption should work. Time to get a new chip.

1. If regular flash (without crypted bins) can't work, why uploading crypted bins not working? This is the ideia of pregenerate key and I using this...

I tested another nodemcu with pregenerate key and still working after various upload, but a question (I do not have another to try and lose it

). To upload app.bin, I just crypt by commands above and upload crypted, works nice.

2. To upload new bootloader, I need to upload it crypted or decrypted?
3. To upload new ota_data_initial, I need to upload it crypted or decrypted?
4. To upload new partitions, I need to upload it crypted or decrypted?

Re: Generic questions about secure boot & flash enc

Posted: Thu Mar 28, 2019 7:19 pm

by newsettler_AI

Hi, I've reading this topic, but still I' stuck with basics...

After I enabled Security features - Enable flash encryption on boot, I have flashed my app with command "make flash".
On first start it takes a while to run, but on next boots it starts as usual.

I made minor change in app. Flashed again. And now I got next:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

Time to get new chip? Or I still can somehow reverse this changes?

My espefuse.py summary:

Code: Select all

EFUSE_NAME             Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 1 R/W (0x1)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/W (0x1)
ABS_DONE_0             secure boot enabled for bootloader                = 0 R/W (0x0)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 1 R/W (0x1)
BLK1                   Flash encryption key
  = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLK2                   Secure boot key
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK3                   Variable Block 3
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    Factory MAC Address
  = 30:ae:a4:06:95:90 (CRC 27 OK) R/W
CHIP_VER_REV1          Silicon Revision 1                                = 0 R/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 0 R/W (0x0)
CHIP_PACKAGE           Chip package identifier                           = 0 R/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 R/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1100 R/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

Re: Generic questions about secure boot & flash enc

Posted: Thu Mar 28, 2019 11:05 pm

by Angus

Hi urbanze,

You don't need a new chip.

Code: Select all

E (112) flash_encrypt: Cannot re-encrypt data (FLASH_CRYPT_CNT 0xff write disabled 0

This is a bug in the IDF bootloader (it thinks FLASH_CRYPT_CNT 0xFF means encryption is disabled not enabled, so it's trying to encrypt again). Will fix ASAP.

Re: Generic questions about secure boot & flash enc

Posted: Thu Mar 28, 2019 11:20 pm

by Angus

Hi Al,

Hi, I've reading this topic, but still I' stuck with basics...
...
I made minor change in app. Flashed again. And now I got next:
Code: Select all
...
flash read err, 1000

It looks like the flash encryption is still turned on (because FLASH_CRYPT_CNT is set to 0x1), but you've flashed plaintext firmware onto the chip.

You can recover. The best way to recover depends on whether you have a copy of your flash encryption key.

- If you don't have the key, you can follow the steps for "Serial Flashing" in the docs to disable the flash encryption, then you can boot the plaintext image (and the bootloader will re-enable flash encryption on the first boot, same as the first time). Note that you can only do this 3 times total, and then flash encryption is permanently enabled. Because the plaintext bootloader in the flash right now is configured to enable flash encryption on first boot, if you want to stop this cycle then erase the flash first (or flash a different bootloader) and then disable flash encryption afterwards, otherwise it will re-enable flash encryption immediately..

- If you do have the key, you can follow the steps for reflashing with a pre-generated flash key. You can do this an unlimited number of times.

We know that right now the steps for enabling flash encryption during development are pretty fiddly and error-prone. We are working on some improvements in this department to make the process simpler, will hopefully be able to release them soon.