Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Secure Boot V2: explain the removal of unused keys (IDFGH-13685) #14561

Closed
wants to merge 3 commits into from
Closed

docs: Secure Boot V2: explain the removal of unused keys (IDFGH-13685) #14561

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fa5cb9b
Doc: Update secure-boot-v2.rst
Lupindakaas Sep 12, 2024
f301bef
docs: Update secure-boot-v2.rst
Lupindakaas Sep 12, 2024
28c1522
Merge branch 'master' of https://github.com/Lupindakaas/esp-idf
Lupindakaas Sep 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion docs/en/security/secure-boot-v2.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -606,10 +606,11 @@ Secure Boot Best Practices

.. _secure-boot-v2-key-revocation:

Key Revocation
Key Revocation
--------------

* Keys are processed in a linear order, i.e., key #0, key #1, key #2.
* After revoking a key, all remaining unrevoked keys can be used to sign applications. I.e, if key #1 gets revoked, both keys #0 and key #2 can still be used to sign firmwares.
* 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.

Expand All @@ -634,6 +635,10 @@ Secure Boot Best Practices

* A similar approach can also be used to physically re-flash with a new key. For physical re-flashing, the bootloader content can also be changed at the same time.

.. note::

It can be necessary to revoke a key that isn't currently being used. For example: if the running application is still signed with key #0, but key #1 becomes compromised, you should revoke this key using this approach.
The new OTA update should still be signed with key #0, but the API `esp_ota_revoke_secure_boot_public_key(SECURE_BOOT_PUBLIC_KEY_INDEX_[N])` can be used to revoke the key #N. Afterwards all remaining unrevoked keys can be used to sign future applications.

.. _secure-boot-v2-aggressive-key-revocation:

Expand Down