docs(secure_boot_v2): Specify the workflow to disable revocation of unused key digests slots

This commit is contained in:
harshal.patil 2024-02-12 17:49:57 +05:30
parent f460cc731f
commit f4581d7103
No known key found for this signature in database
GPG Key ID: 5B5EC97C35B9A2E5
2 changed files with 14 additions and 0 deletions

View File

@ -990,6 +990,14 @@ 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.
config SECURE_FLASH_UART_BOOTLOADER_ALLOW_ENC
bool "Leave UART bootloader encryption enabled"
depends on SECURE_FLASH_ENCRYPTION_MODE_DEVELOPMENT

View File

@ -549,6 +549,12 @@ Secure Boot Best Practices
* Applications should be signed with only one key at a time, to minimize the exposure of unused private keys.
* The bootloader can be signed with multiple keys from the factory.
.. 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 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 (: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.
Conservative Approach:
~~~~~~~~~~~~~~~~~~~~~~