diff --git a/components/bootloader/Kconfig.projbuild b/components/bootloader/Kconfig.projbuild index 1df75b63384..db5fa4c246d 100644 --- a/components/bootloader/Kconfig.projbuild +++ b/components/bootloader/Kconfig.projbuild @@ -1010,13 +1010,8 @@ menu "Security features" Revoking unused digest slots makes ensures that no trusted keys can be added later by an attacker. If set, it means that you have a plan to use unused digests slots later. - Note that if you plan to enable secure boot during the first boot up, the bootloader will intentionally - revoke the unused digest slots while enabling secure boot, even if the above config is enabled because - keeping the unused key slots un-revoked would a security hazard. - In case for any development workflow if you need to avoid this revocation, you should enable - secure boot externally (host based mechanism) rather than enabling it during the boot up, - so that the bootloader would not need to enable secure boot and thus you could avoid its revocation - strategy. + This config is honored both at runtime in the app and while enabling secure boot during the first + boot up in the bootloader. When set, the unused digest slots are left un-revoked in both cases. config SECURE_BOOT_SKIP_WRITE_PROTECTION_SCA bool "Skip write-protection of SECURE_FLASH_PSEUDO_ROUND_FUNC_STRENGTH" diff --git a/components/bootloader_support/src/secure_boot_v2/secure_boot.c b/components/bootloader_support/src/secure_boot_v2/secure_boot.c index 73b6a8c4fbb..3d57cbf62c9 100644 --- a/components/bootloader_support/src/secure_boot_v2/secure_boot.c +++ b/components/bootloader_support/src/secure_boot_v2/secure_boot.c @@ -347,8 +347,12 @@ static esp_err_t check_and_generate_secure_boot_keys(const esp_image_metadata_t if (boot_key_digests.num_digests < SECURE_BOOT_NUM_BLOCKS) { /* The revocation index can be 0, 1, 2. Bootloader count can be 1,2,3. */ for (unsigned i = boot_key_digests.num_digests; i < SECURE_BOOT_NUM_BLOCKS; i++) { +#ifndef CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS ESP_LOGI(TAG, "Revoking empty key digest slot (%d)...", i); esp_efuse_set_digest_revoke(i); +#else + ESP_LOGW(TAG, "Unused key digest slot (%d) left un-revoked due to the config SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS", i); +#endif } } #endif // SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS diff --git a/docs/en/security/flash-encryption.rst b/docs/en/security/flash-encryption.rst index df0504092be..1ec0bf351ee 100644 --- a/docs/en/security/flash-encryption.rst +++ b/docs/en/security/flash-encryption.rst @@ -621,7 +621,7 @@ To use a host generated key and program it into the eFuses of the device, take t .. only:: SOC_KEY_MANAGER_SUPPORTED - To use a host generated key and deploy it into the device's Key Manager of the device, take the following steps: + To use a host generated key and deploy it into the device's Key Manager, take the following steps: 1. Ensure that you have an {IDF_TARGET_NAME} device with default flash encryption eFuse settings as shown in :ref:`flash-encryption-efuse`. @@ -1224,11 +1224,11 @@ Manually Encrypting Files .. only:: SOC_KEY_MANAGER_SUPPORTED - Manually encrypting or decrypting files require the flash encryption key to be deployed in the Key Manager or pre-burned in eFuses (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used. + Manually encrypting or decrypting files requires the flash encryption key to be deployed in the Key Manager or pre-burned in eFuses (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used. .. only:: not SOC_KEY_MANAGER_SUPPORTED - Manually encrypting or decrypting files require the flash encryption key to be pre-burned in eFuse (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used. + Manually encrypting or decrypting files requires the flash encryption key to be pre-burned in eFuse (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used. The key file should be a single raw binary file (example: ``key.bin``). diff --git a/docs/en/security/secure-boot-v2.rst b/docs/en/security/secure-boot-v2.rst index bcbe0e92669..74af72ca9ac 100644 --- a/docs/en/security/secure-boot-v2.rst +++ b/docs/en/security/secure-boot-v2.rst @@ -741,9 +741,7 @@ Secure Boot Best Practices .. note:: - Note that enabling the config :ref:`CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS` only makes sure that the **app** does not revoke the unused digest slots. - But if you plan to enable secure boot during the fist boot up, the bootloader will intentionally revoke the unused digest slots while enabling secure boot, even if the above config is enabled. Because keeping the unused key slots unrevoked would be a security hazard. - In case for any development workflow if you need to avoid this revocation, you should :ref:`enable-secure-boot-v2-externally`, rather than enabling it during the boot up, so that the bootloader would not need to enable secure boot, and thus you could avoid its revocation strategy. + Enabling the config :ref:`CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS` keeps the unused digest slots un-revoked in both cases: at runtime in the **app**, and in the **bootloader** when secure boot is enabled during the first boot up. Note that leaving unused key slots un-revoked could pose a security risk, unless the debug and download interfaces are completely disabled and remote interfaces are fully audited for security risks. Conservative Approach ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/en/security/security.rst b/docs/en/security/security.rst index 2f47efa117b..c6fb1ca255c 100644 --- a/docs/en/security/security.rst +++ b/docs/en/security/security.rst @@ -311,7 +311,7 @@ Please see more information to enable this feature in the :ref:`anti-rollback` g Encrypted Firmware Distribution ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Encrypted firmware distribution during over-the-air updates ensures that the application stays encrypted **in transit** from the server to the the device. This can act as an additional layer of protection on top of the TLS communication during OTA updates and protect the identity of the application. +Encrypted firmware distribution during over-the-air updates ensures that the application stays encrypted **in transit** from the server to the device. This can act as an additional layer of protection on top of the TLS communication during OTA updates and protect the identity of the application. Please see working example for this documented in :ref:`ota_updates_pre-encrypted-firmware` section. diff --git a/docs/en/security/tee/tee.rst b/docs/en/security/tee/tee.rst index 7886577d9ee..6a8e2b5b3ba 100644 --- a/docs/en/security/tee/tee.rst +++ b/docs/en/security/tee/tee.rst @@ -76,7 +76,7 @@ ESP-TEE divides the memory into separate regions for the TEE and REE, allocating Internal Memory (SRAM) ^^^^^^^^^^^^^^^^^^^^^^ -Internal memory is allocated to the the TEE based on the Kconfig options that are available under the :ref:`Memory Configuration ` section in the :ref:`esp-tee-trusted-execution-environment-` menu. All remaining memory is allocated to the REE. +Internal memory is allocated to the TEE based on the Kconfig options that are available under the :ref:`Memory Configuration ` section in the :ref:`esp-tee-trusted-execution-environment-` menu. All remaining memory is allocated to the REE. .. warning:: diff --git a/docs/zh_CN/security/secure-boot-v2.rst b/docs/zh_CN/security/secure-boot-v2.rst index a251016955a..b2d06eb5c04 100644 --- a/docs/zh_CN/security/secure-boot-v2.rst +++ b/docs/zh_CN/security/secure-boot-v2.rst @@ -741,9 +741,7 @@ Secure Boot v2 签名验证也可以在 OTA 更新期间验证数据分区镜像 .. note:: - 请注意，启用配置 :ref:`CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS` 只能确保 **应用程序** 不会撤销未使用的摘要槽。 - 若想在设备首次启动时启用安全启动，那么即使启用了上述配置，引导加载程序也会在启用安全启动时撤销未使用的摘要槽，因为保留未使用的密钥槽会构成安全隐患。 - 如果在开发流程中需要保留未使用摘要槽，则应从外部启用安全启动 (:ref:`enable-secure-boot-v2-externally`)，而不是在启动设备时启用安全启动，这样引导加载程序就无需启用安全启动，从而避免安全隐患。 + 启用配置 :ref:`CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS` 后，未使用的摘要槽在两种情况下都将保持未撤销状态：在 **应用程序** 运行时，以及在设备首次启动时由 **引导加载程序** 启用安全启动时。请注意，除非调试接口和下载接口已完全禁用，且远程接口已针对安全风险进行全面审计，否则保留未使用的密钥槽可能构成安全风险。 保守方法 ~~~~~~~~