Supply encryption key to write_flash --encrypt (ESPTOOL-133)

[jeremyherbert]

In the latest commits, it seems that writing encrypted files is now supported. Is this feature intended to only be used when flash encryption debugging is enabled? It seems like the commands in the test do not allow a key to be specified.

self.run_esptool("write_flash --encrypt --ignore-flash-encryption-efuse-setting 0x10000 images/helloworld-esp32_edit.bin")

I currently have a bunch of custom scripts which encrypt the app locally and flash it; this is because each device has a unique encryption key. It would be neat to get rid of them all and use something like write_flash --encrypt-with-key=aes_key.bin 0x10000 data.bin 0x20000 data2.bin

Is this possible with the new changes?

[jeremyherbert]

Even more useful would be something like this (which is what my own scripts do currently):

write_flash --encrypt-from-keydir=key_directory 0x10000 data.bin 0x20000 data2.bin

Inside the folder key_directory is simply a collection of the aes_key.bin files, named with the MAC address of the device. So if the MAC was 11:22:33:44:55:AA, it would be called 1122334455AA.bin. Then, using esptool to read out the MAC, the correct key can be selected.

[projectgus]

Hi @jeremyherbert,

We haven't pushed support for this feature to IDF yet (it's coming soon), but this new command is a way to flash encrypted devices (in development) without needing to store a key. This lets developers use flash encryption throughout the development process, even with randomly generated keys.

Essentially, by not burning the UART_BOOTLOADER_ALLOW_ENCRYPT efuse, you can put the device in a "development" mode where this command will work to write the data encrypted, without needing any key. The device is not secure, but development/testing can proceed with flash encryption in effect.

When going into production, this efuse must be burned to prevent attackers getting access to flash contents.

[jeremyherbert]

Yep, I understand that the efuse must be burned for production. What I am suggesting is that it would be useful to have alternate method which allows the user to supply the key on the programming system, so that this can still be used regardless of the efuse state.

For example, I have a product which occasionally needs to be reflashed when they come back to us from the field. Although it does have OTA, our assemblies are expensive, and as such we still want to keep open the option to reflash manually in case a bad firmware is accidentally flashed. We program each device with a unique flash encryption key at manufacture time, and keep it in a database associated with the mac address of the ESP32. If there was a way to supply this key to esptool, it would save the custom scripts invoking espsecure and then esptool. I'm sure I'm not the only one doing this?

[projectgus]

Got it. I think this is a reasonable request. At the moment we're trying to simplify the flash encryption documentation and getting started process so it's less daunting for new users (less choices, etc.)

When we're done with this we can possibly revisit the idea of having one-step support for preflashed keys, and some scheme for storage of per-device keys. I like the idea of having a supported scheme as another way to discourage users from sharing one key between all production devices.

[jeremyherbert]

Yes, it was rather daunting the first time I enabled flash encryption and secure boot myself. I think it would also be neat if there was a way to burn the encryption key and write it straight into the keydir in one step (as mentioned above). Again, this is what my custom scripts do now; detect if flash encryption is enabled, and if not, read the MAC, generate a random key into the keydir against that MAC and then burn efuses with that key. Also, all keys will have write permissions removed after writing them to the keydir ;)

I was sort of posting this to see if the idea is acceptable; happy to give this one a go myself and file a PR if I can find the time.