From 6f2a00c425291de3babd5cb229fa92a2ebceae89 Mon Sep 17 00:00:00 2001 From: Angus Gratton Date: Tue, 31 Dec 2019 17:19:16 +1100 Subject: [PATCH] doc: secure boot: Fix relative reference to key generation step --- docs/en/security/secure-boot.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/security/secure-boot.rst b/docs/en/security/secure-boot.rst index 3cd24d803..6ff969d90 100644 --- a/docs/en/security/secure-boot.rst +++ b/docs/en/security/secure-boot.rst @@ -117,7 +117,7 @@ Configuration "Secure Boot: One-Time Flash" is the recommended configuration for However, an alternative mode :ref:`Secure Boot: Reflashable ` is also available. This mode allows you to supply a binary key file that is used for the secure bootloader key. As you have the key file, you can generate new bootloader images and secure boot digests for them. -In the esp-idf build process, this 256-bit key file is derived from the app signing key generated during the generate_signing_key step above. The private key's SHA-256 digest is used as the secure bootloader key (as-is for Coding Scheme None, or truncate to 192 bytes for 3/4 Encoding). This is a convenience so you only need to generate/protect a single private key. +In the esp-idf build process, this 256-bit key file is derived from the ECDSA app signing key generated by the user (see the :ref:`secure-boot-generate-key` step below). This private key's SHA-256 digest is used as the secure bootloader key in efuse (as-is for Coding Scheme None, or truncate to 192 bytes for 3/4 Encoding). This is a convenience so you only need to generate/protect a single private key. .. note:: Although it's possible, we strongly recommend not generating one secure boot key and flashing it to every device in a production environment. The "One-Time Flash" option is recommended for production environments.