ESP32 Forum

Posted: **Mon Sep 10, 2018 9:54 am**

Hi,
I did some tests about secure boot and flash encryption. The result is not 100% perfect, but I actually bricked 2 dev boards.
I'm wondering if there is a way to reset the eFuse to factory setting?
which I think may not harm the data in flash, cause the secure boot and flash encryption will not pass without the right key.
Hope there is a way, or I have to dump these dev boards.

I succeeded in Flash Encryption.
Then I disabled flash encryption by burning the FLASH_CRYPT_CNT efuse again and Flash with the plainText bins. I put my dev boards into normal status.
Then I tested with Both Secure Boot and Flash Encryption enabled. And I failed.

secure boot check fail
ets_main.c 371

I burn the FLASH_CRYPT_CNT again, and it shows

flash read err, 1000
ets_main.c 371

So the flash encryption worked before, the bootloader is encrypted. But the secure boot doesn't work well.
I'm wondering what does

secure boot check fail

means. Did the bootloader fail to pass the verification or the Partitions Table and App's signing failed to pass the verification?

Posted: **Mon Sep 10, 2018 12:26 pm**

Fundamentally, an eFuse is a single bit of non-volatile memory with the restriction that once an eFuse bit is programmed to 1, it can never be reverted to 0.

So sadly no you can't revert eFuse to factory (but that would be a nice to have for next chip).

Be careful when building the bootloader that the resulting image (.bin) does not exceed 24k, or it will overlap with the partition table. The compiler / linker does not warn about this (at least in IDF 3.0.x). Try setting a lower log level for the bootloader.

Posted: **Mon Sep 10, 2018 2:32 pm**

Hi, @Mr_red
I checked the bootloader's size before flash it, cause the instruction mentioned about that. It's smaller than that (<16k), cause I changed the settings for bootloader logging.

And I just tested the Verify function of espsecure.py which is in the bundle of esptool.
I've found that espsecure.py can only verify the Data bin file with the signing private key. It worked with the private key.

espsecure.py v2.5.0
Verifying 216016 bytes of data
Signature is valid

I extract_public_key from the private key with espsecure.py extract_public_key command.

espsecure.py v2.5.0
secure_boot_signing_key.pem public key extracted to public_key.pem

And then I verify_signature the Data bin file with the generated public_key, error occurs.
I pasted the log here:

python espsecure.py verify_signature --keyfile public_key.pem VS_app_signed.bin
espsecure.py v2.5.0
Traceback (most recent call last):
File "espsecure.py", line 156, in verify_signature
sk = _load_key(args) # try to load as private key first
File "espsecure.py", line 123, in _load_key
sk = ecdsa.SigningKey.from_pem(args.keyfile.read())
File "C:\Python37\lib\site-packages\ecdsa-0.13-py3.7.egg\ecdsa\keys.py", line 159, in from_pem
privkey_pem = string[string.index(b("-----BEGIN EC PRIVATE KEY-----")):]
ValueError: subsection not found

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "espsecure.py", line 401, in <module>
_main()
File "espsecure.py", line 394, in _main
main()
File "espsecure.py", line 389, in main
operation_func(args)
File "espsecure.py", line 160, in verify_signature
vk = ecdsa.VerifyingKey.from_pem(args.keyfile.read())
File "C:\Python37\lib\site-packages\ecdsa-0.13-py3.7.egg\ecdsa\keys.py", line 52, in from_pem
return klass.from_der(der.unpem(string))
File "C:\Python37\lib\site-packages\ecdsa-0.13-py3.7.egg\ecdsa\der.py", line 191, in unpem
return base64.b64decode(d)
File "C:\Python37\lib\base64.py", line 87, in b64decode
return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

I doubt if the bootloader will use the same method and went wrong.

Secure boot won’t be enabled until after a valid partitions table and app image have been flashed. This is to prevent accidents before the system is fully configured.

I can tell that the eFuse of ABS_DONE_0 is checked with 1. So my partitions table and app is checked.
And the flash encryption also worked. I noticed the change of FLASH_CRYPT_CNT.
But the secure boot check fail. I'm doubtful about the verification.
So I use espsecure.py to verify my files on PC.

I think I will post this to Bug Report, at least there is a bug for espsecure.py.

Posted: **Wed Sep 12, 2018 8:07 am**

"secure boot check fail" is a message from the ROM means that the digest calculated when secure boot was enabled (and ABS_DONE_0 was written to 1) no longer matches the bootloader found in flash.

It's unrelated to signing keys, although the digest is generated from the secure boot key in efuse.

It is not possible to set an efuse bit to 0 after it has been set to 1.

Reasons the digest could fail to match include:

The bootloader.bin in flash has changed since the digest was calculated.
The flash encryption setting has changed since the digest was calculated. (meaning either the bootloader in the flash is still ciphertext but ESP32 has flash encryption disabled, or the bootloader in the flash is now plaintext but ESP32 has flash encryption enabled).

Did you pre-generate the secure boot key and write it with "espsecure.py burn_key"? If so, you can follow the steps in the docs here to generate a new bootloader and matching digest: https://docs.espressif.com/projects/esp ... eflashable

If you don't have the key, your only chance is to restore the same state of the flash that was there when the digest was calculated. This may be possible if you still have the bootloader.bin which was flashed.

Posted: **Thu Sep 13, 2018 2:31 am**

Hi, @ESP_Angus
I built the bootloader.bin with One-time Flash option which is suggested in the Secure Boot guide.
My dev boards didn't enable Secure Boot before that, I checked them with

espefuse.py ** summary

before testing secure boot, cause I test flash encryption before this test. The ABS_DONE_0 is 0.

I disable the encryption by burning the FLASH_CRYPT_CNT again and flash an unencrypted Blink example to test, the blink worked. I flashed another normal project to double check. The dev board was in a normal state.
(Though the CNT is 3 0b00000011, and the diable XXX settings are already set to 1, I don't know if these will break the secure boot

)

I enabled both secure boot (one-time flash) and flash encryption (default setting) which means the key was generated by the bootloader and stored in the eFuse. And the first boot I got the

secure boot check fail

.

I repeated the same procedure again with my another dev board which was also tested flash encryption before with exact same procedure and failed again.

Though I got the bootloader.bin file, the flash encryption is enabled. I don't get the encryption key. I don't think there is any chance to reflash the bootloader.bin again. Cause the digest part is encrypted(Flash encryption guide mentioned this). Even I burn the FLASH_CRYPT_CNT again to disable the encryption, I don't have an unencrypted digest for the unencrypted bootloader. So it won't pass the secure boot check. And I don't have the flash encryption key, so I can't pre-encrypt the bootloader and flash it.
The bootloader with the safest secure settings(flash encryption on) is really a One-time flash

I don't know if secure boot needs a brand new dev board with unburnt eFuse

More help is needed to figure out what's wrong.

Posted: **Thu Sep 13, 2018 5:39 am**

From your description I don't understand when ABS_DONE_0 got set to 1.

This part, in particular:

I enabled both secure boot (one-time flash) and flash encryption (default setting) which means the key was generated by the bootloader and stored in the eFuse. And the first boot I got the
Code: Select all
secure boot check fail

Before this step, your ESP32 had FLASH_CRYPT_CNT set to 2 bits (0b00000011), and ABS_DONE_0 was set to zero. And no secure boot bootloader had ever been run on the board. Do I understand correctly?

Then you used menuconfig to set Secure Boot and Flash Encryption enabled, built a new app and bootloader, and flashed both the bootloader and the app.

How did you do this? Did you use Flash Download Tool or esptool.py?

Did you flash everything in one pass or in multiple passes?

If you used the Flash Download Tool, did you set any of the Secure Boot options in security.conf?

What is supposed to happen after the first flash:

After first reset (no security features enabled in efuse), bootloader runs.
Bootloader generates a digest from bootloader.bin and writes it at offset 0x0 in the flash, then burns ABS_DONE_0 to enable secure boot.
Bootloader encrypts the flash contents in place (including bootloader.bin and the digest) and then sets one more bit in FLASH_CRYPT_CNT to enable flash encryption.
Bootloader resets itself into newly enabled secure boot mode.

If everything is done according to plan, the only time this can go badly wrong is if the ESP32 is reset while it is encrypting the bootloader.bin and digest. If this happens, the ESP32 is left with flash encryption still disabled but an invalid bootloader or an invalid digest. This will cause "secure boot fail". This should happen within the first 20 seconds of the first boot though, unless there is some accidental reset (or power failure) it should be OK.

Posted: **Thu Sep 13, 2018 1:16 pm**

Hi, @ESP_Angus

Before this step, your ESP32 had FLASH_CRYPT_CNT set to 2 bits (0b00000011), and ABS_DONE_0 was set to zero. And no secure boot bootloader had ever been run on the board. Do I understand correctly?

Yes, the secure boot is never been tested before the final test which failed.

How did you do this? Did you use Flash Download Tool or esptool.py?

I generated the bin files with ESP-IDF, and flashed the bootloader bin, partitions table bin, app bin with Download Tool.

Did you flash everything in one pass or in multiple passes?

In one pass.

If you used the Flash Download Tool, did you set any of the Secure Boot options in security.conf?

I set all secure boot settings and flash encryption settings to False. And set the disable *** settings to False. Almost the same as the default states. So there is no warning window when starting the Download Tool.

The Download Tool needs manual reset after the flashing, I make sure it displays Finish完成 and press the reset button on my dev board.
Then I waited for more than One minute cause the guide says it could take 1 minute to encrypt the partition.
I didn't reset the board or unplug the USB cable.

I found the board is not booting, I used

Code: Select all

make Monitor

to check the debug message.
I got the fail message, then I used espefuse.py to summary the eFuse, I found the ABS_DONE_0 is set to 1.

Then I repeated this with the second dev board... And no luck.

Posted: **Fri Sep 14, 2018 1:10 am**

Thanks for the detailed explanation. The steps you followed sound like they should work.

What ESP-IDF version do you have? (you can run 'git describe --tags' to find out)

Posted: **Mon Sep 17, 2018 1:14 am**

Hi, @ESP_Angus

C:\msys32\home\human\esp\esp-idf>git describe --tags
v3.1

ESP32 Forum

How to reset all the eFuse? What does "secure boot check fail" means?

How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?

Re: How to reset all the eFuse? What does "secure boot check fail" means?