ESP32 Forum

Posted: **Mon Jan 28, 2019 12:52 am**

There is very little chance of getting an answer here, but I will still ask)))
I use Flash Encryption with Secure Boot. The question is what additional EFUSE should be installed and write protected in this mode.

1. There is no information anywhere:
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)

2. The documentation says "By default, on first boot the flash encryption process will burn efuses"
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
But If i use Reflashing with pregenerated key, they are not set (remained at 0).
How should I set these values?

Posted: **Mon Jan 28, 2019 10:22 pm**

Tell me how should be installed?
Should it be read / write protected?

ABS_DONE_1 secure boot abstract 1 locked

Maybe it doesn't matter?

Posted: **Mon Jan 28, 2019 11:06 pm**

I'm not sure why you think you won't get an answer here, that's a bit troubling to me.

1. There is no information anywhere:
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)

This isn't used, it should be safe to ignore it. The similarly named ABS_DONE_0 efuse is used (by Secure Boot).

2. The documentation says "By default, on first boot the flash encryption process will burn efuses"
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
But If i use Reflashing with pregenerated key, they are not set (remained at 0).

The very first time you flashed the device, did you flash a plaintext firmware and allow the device to encrypt itself (using the key you had already burned to the device) and then enable flash encryption by itself? If so, this process should automatically burn these efuses.

This won't happen if you manually burned the FLASH_CRYPT_CNT efuse to value 1 with espefuse.py and then flashed a ciphertext firmware for the first boot.

There are also some sdkconfig options (marked "Potentially Insecure") which can cause these efuses to not be burned on first boot:
https://docs.espressif.com/projects/esp ... re-options

If you still think that these efuses should have been burned but were not, please let us know your ESP-IDF version and the exact sequence of steps you followed to enable flash encryption.

(Note: If you set FLASH_CRYPT_CNT manually to enable encryption, rather than letting the device encrypt itself on first boot, then you'll also need to manually burn these 3 efuses and also the JTAG_DISABLE efuse in order to have a secure device. This may not matter if you're only using the pregenerated key for development, though.)

Posted: **Mon Jan 28, 2019 11:55 pm**

I use ESP-IDF V3.1.2
The use of the pre-generated Secure key and the AES key is my deliberate choice, please do not discuss it. If necessary, I can disclose why this is done and what additional protection is used.

------------------- This actions is performed once -----------------------------------------------
1. I use pregenerated secure boot key
espsecure.py generate_signing_key key.pem
2. make menuconfig -> Security features ->
[*] Enable hardware secure boot in bootloader
Secure bootloader mode (One-time flash)
[*] Sign binaries during build
(key.pem) Secure boot private signing key
!!! i dont use any Potentially insecure options !!!
make
make bootloader
3. I use pregenerated AES key
espsecure.py generate_flash_encryption_key my_flash_encryption_key.bin
4. Encrypt all partitions
espsecure.py encrypt_flash_data --keyfile my_flash_encryption_key.bin --flash_crypt_conf 0xf --address 0x1000 -o build/bootloader/bootloader-encrypted.bin build/bootloader/bootloader.bin
espsecure.py encrypt_flash_data --keyfile my_flash_encryption_key.bin --flash_crypt_conf 0xf --address 0x10000 -o build/app-encrypted.bin build/app.bin
espsecure.py encrypt_flash_data --keyfile my_flash_encryption_key.bin --flash_crypt_conf 0xf --address 0x8000 -o build/partitions-encrypted.bin build/partitions.bin
-------------------- This action is performed for every devices -------------------------------
1. Flash all partitions
esptool.py --port COM72 --baud 921600 write_flash 0x1000 build/bootloader/bootloader-encrypted.bin
esptool.py --port COM72 --baud 921600 write_flash 0x10000 build/app-encrypted.bin
esptool.py --port COM72 --baud 921600 write_flash 0x8000 build/partitions-encrypted.bin
2. Burn the key and protect it
espefuse.py --port COM72 burn_key flash_encryption my_flash_encryption_key.bin
3. Burn FLASH_CRYPT_CONFIG
espefuse.py --port COM72 burn_efuse FLASH_CRYPT_CONFIG 0xf
4. Enable Encrypt
espefuse.py --port COM72 burn_efuse FLASH_CRYPT_CNT
5. RESET DEVICE

Next, after the reset my application checks itself and burns some EFUSE

1. 3.3v ... Burning EFUSE_BLK0_WDATA4_RE fuse EFUSE_RD_SDIO_FORCE to 1
2. 3.3v ... Burning EFUSE_BLK0_WDATA4_RE fuse EFUSE_RD_XPD_SDIO_REG to 1
3. 3.3v ... Burning EFUSE_BLK0_WDATA4_RE fuse EFUSE_RD_XPD_SDIO_REG to 1
4. Burning DISABLE_DL_ENCRYPT to 1
5. Burning DISABLE_DL_DECRYPT to 1
6. Burning DISABLE_DL_CACHE
7. Burning WR disable FLASH_CRYPT_CNT
8. Burning WR/RD disable FLASH_CRYPT_CONFIG
9. Burning WR disable ABS_DONE_0
10. Burning ABS_DONE_1
11. Burning JTAG_DISABLE
12. Burning WR disable EFUSE_WR_DIS_CONSOLE_DL_DISABLE

Here is the result

# $IDF_PATH/components/esptool_py/esptool/espefuse.py --port com72 summary espefuse.py v2.6-beta1
Connecting........_
EFUSE_NAME Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 1 R/- (0x1)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = ? -/- (0x0)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/- (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 1 R/- (0x1)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/- (0x0)
JTAG_DISABLE Disable JTAG = 1 R/- (0x1)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 1 R/- (0x1)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 1 R/- (0x1)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 1 R/- (0x1)
BLK1 Flash encryption key
= ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLK2 Secure boot key
= ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLK3 Variable Block 3
= (app`s 8 byte) 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 = 62852 R/W (0xf584)
RD_DIS Efuse read disablemask = 11 R/W (0xb)
CODING_SCHEME Efuse variable block length scheme = ? -/- (0x0)
KEY_STATUS Usage of efuse block 3 (reserved) = ? -/- (0x0)

Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 1 R/W (0x1)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1)
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 MAC Address
= 30:ae:a4:73:1f:a0 (CRC 8b 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 = ? -/- (0x0)
ADC_VREF Voltage reference calibration = 1100 R/W (0x0)

Flash voltage (VDD_SDIO) set to 3.3V by efuse.

Posted: **Tue Jan 29, 2019 12:01 am**

Also, I take software measures to flash from one of my devices did not come to my other device. If we do not consider the possibility of theft of the keys, is my device protected enough from hacking?

Posted: **Tue Jan 29, 2019 12:37 am**

I don't see any problem with the workflow you're following, although it's not our supported workflow (the docs encourage burning the efuse key block but then flashing plaintext firmware, bootloader, etc to the device and letting the device encrypt itself on first boot).

You will need to make sure to burn the additional efuses you mention, because normally these are burned by the bootloader during the first boot process. The code which would normally do this is here:
https://github.com/espressif/esp-idf/bl ... ypt.c#L117

If the device is already encrypted before first boot, the whole first boot process is skipped. But you can burn these efuses from inside your app if you prefer. Seems like that is working fine for you.

8. Burning WR/RD disable FLASH_CRYPT_CONFIG
9. Burning WR disable ABS_DONE_0

Small thing to note, write protection only prevents burning an efuse bit 0->1. In these cases if all the efuse bits are already set to 1, write disabling doesn't add any additional protections.

(In the case of FLASH_CRYPT_CNT, write disabling is a valid way to prevent flash encryption being disabled again. Although once secure boot is enabled via ABS_DONE_0, there is still no way to access or change the firmware even if this efuse is writeable.)

brp80000 wrote: ↑
Tue Jan 29, 2019 12:01 am
Also, I take software measures to flash from one of my devices did not come to my other device. If we do not consider the possibility of theft of the keys, is my device protected enough from hacking?

Not sure I understand this question, can you explain further?

Posted: **Tue Jan 29, 2019 12:44 am**

All described by me is performed in the firmware factory. This is followed by different firmware via OTA for different devices. Therefore, I take steps to prevent copying an already encrypted flash from one of my devices to another (because i use the same pregenerated keys). There is no question, I understand everything. Thank you so much for your reply

ESP32 Forum

Several mysterious EFUSE

Several mysterious EFUSE

Re: Several mysterious EFUSE

Re: Several mysterious EFUSE

Re: Several mysterious EFUSE

Re: Several mysterious EFUSE

Re: Several mysterious EFUSE

Re: Several mysterious EFUSE