From the documentation I understand that FLASH_CRYPT_CNT is a 7-bit eFuse field, and each time plaintext firmware is flashed and encrypted in-place on boot, the next bit is set, giving a maximum of 4 plaintext flash cycles in development mode.
What I am unclear about is the following scenarios:
Code: Select all
Method | PC needs key? | Consumes FLASH_CRYPT_CNT?
----------------------------------------------|---------------|-------------------------
UART flash plaintext, in-place encrypt on boot| No | Yes
OTA via esp_partition_write() | No | No
PC pre-encrypts, flashes ciphertext via UART | Yes | ?
idf.py encrypted-app-flash (dev mode) | No | ?
idf.py encrypted-flash (dev mode) | No | ?
Release mode: UART flash pre-encrypted data | Yes | ?
1. For idf.py encrypted-app-flash and idf.py encrypted-flash, does the UART download mode use the hardware encryption engine to write ciphertext directly, bypassing the in-place encryption on boot, and therefore not consuming a FLASH_CRYPT_CNT bit?
2. If flashing pre-encrypted ciphertext via UART, does the bootloader still flip FLASH_CRYPT_CNT on the next boot, or does it detect via FLASH_CRYPT_CNT odd/even state that no in-place encryption is needed?
3. Since FLASH_CRYPT_CNT odd/even is the only mechanism the bootloader uses to decide whether to encrypt, and the bootloader cannot inspect flash content directly to determine if it is encrypted, how exactly does the bootloader decide whether to consume a bit after flashing via encrypted-app-flash?
Thank you.