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?
Several mysterious EFUSE
Re: Several mysterious EFUSE
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?
Should it be read / write protected?
ABS_DONE_1 secure boot abstract 1 locked
Maybe it doesn't matter?
Re: Several mysterious EFUSE
I'm not sure why you think you won't get an answer here, that's a bit troubling to me.
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.)
This isn't used, it should be safe to ignore it. The similarly named ABS_DONE_0 efuse is used (by Secure Boot).1. There is no information anywhere:
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
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.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).
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.)
Re: Several mysterious EFUSE
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
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.
Last edited by brp80000 on Tue Jan 29, 2019 12:29 am, edited 6 times in total.
Re: Several mysterious EFUSE
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?
Re: Several mysterious EFUSE
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.
(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.)
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.
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.8. Burning WR/RD disable FLASH_CRYPT_CONFIG
9. Burning WR disable ABS_DONE_0
(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.)
Not sure I understand this question, can you explain further?
Re: Several mysterious EFUSE
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
Who is online
Users browsing this forum: No registered users and 175 guests