Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
and all ECDSA to be disabled if secure boot is not enabled
Previously if ECDSA disabled in config then secure_boot_signatures.c would
fail to build (whether or not secure boot was enabled).
To avoid breaking apps that might be using the signature scheme with custom OTA
without enabling secure boot signatures in config, this change just disables
this functionality if unavailable in mbedTLS config.
Possible fix for root cause of https://github.com/espressif/esp-idf/pull/3703
Closes https://github.com/espressif/esp-idf/issues/4758
In testing environment, to avoid accidentally enabling flash
encryption on a device, CONFIG_SECURE_FLASH_REQUIRE_ALREADY_ENABLED
can be set. If set, the bootloader will refuse to boot if flash
encryption is not enabled, instead of enabling it.
This MR improves existing flash encryption document to provide simplified steps
Adds two new modes for user: Development & Release
Adds a simple example
Supports encrypted write through make command
Added:
* set a secure version in app/bootloader.
* description anti-rollback to ota part
* emulate the secure_version write and read operations
* efuse_em partition.
* a description about a rollback for native_ota_example.
Closes: TW26335
Allows OTA updates to be secured via signature checks, without requiring the overhead or complexity
of a full secure boot implementation.
Uses same signing mechanisms (build system and/or espsecure.py as Secure Boot).
Requires:
* [ ] More testing
* [ ] Documentation
Because address space is mapped in 64KB pages, it was possible for unauthenticated data after the
app .bin to become mapped into the flash cache address space.
This problem is solved by 2 changes:
* "esptool elf2image --secure-pad" will pad the image so that the signature block ends close to the
64KB boundary. Due to alignment constraints it will be 12 bytes too short after signing (but
with flash encryption, these 12 bytes are still encrypted as part of the last block and can't be
arbitrarily changed).
* By default, secure boot now requires all app partitions to be a multiple of 64KB in size.
Added feature:
- reset firmware to Factory app.(by long pressing of the button)
- boot Test app. (by long pressing of the button)
- Added feature erase data partitions from factory reset.
TW10281
TW10280
Also add steps to disable flash encryption, as some people seem to
accidentally enable it.
Explicitly mark the flash encryption and secure boot as "READ DOCS
FIRST" in menuconfig.
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
This also removes logging implementation from bootloader and replaces it
with the one provided by the log component. Some occurrences of printf
and ets_printf have been changed to ESP_LOGx APIs.