|
|
@@ -3,13 +3,25 @@
|
|
|
Secure Boot V2
|
|
|
==============
|
|
|
|
|
|
-{IDF_TARGET_SBV2_SCHEME:default="RSA-PSS", esp32c2="ECDSA"}
|
|
|
+{IDF_TARGET_SBV2_SCHEME:default="RSA-PSS", esp32c2="ECDSA", esp32c6="RSA-PSS or ECDSA"}
|
|
|
|
|
|
-{IDF_TARGET_SBV2_KEY:default="RSA-3072", esp32c2="ECDSA-256 or ECDSA-192"}
|
|
|
+{IDF_TARGET_SBV2_KEY:default="RSA-3072", esp32c2="ECDSA-256 or ECDSA-192", esp32c6="RSA-3072, ECDSA-256, or ECDSA-192"}
|
|
|
+
|
|
|
+{IDF_TARGET_SECURE_BOOT_OPTION_TEXT:default="", esp32c6="RSA is recommended because of faster verification time. You can choose between RSA and ECDSA scheme from the menu."}
|
|
|
+
|
|
|
+{IDF_TARGET_ECO_VERSION:default="", esp32="(ECO 3 onwards)", esp32c3="(ECO 3 onwards)"}
|
|
|
+
|
|
|
+{IDF_TARGET_RSA_TIME:default="", esp32c6="~2.7 ms"}
|
|
|
+
|
|
|
+{IDF_TARGET_ECDSA_TIME:default="", esp32c6="~21.5 ms"}
|
|
|
+
|
|
|
+{IDF_TARGET_CPU_FREQ:default="", esp32c6="160 MHz"}
|
|
|
+
|
|
|
+{IDF_TARGET_SBV2_DEFAULT_SCHEME:default="RSA", esp32c2="ECDSA (V2)"}
|
|
|
|
|
|
.. important::
|
|
|
|
|
|
- This document is about Secure Boot V2, supported on the following chips: ESP32 (ECO3 onwards), ESP32-S2, ESP32-S3, ESP32-C3 (ECO3 onwards), and ESP32-C2. Except for ESP32, it is the only supported Secure Boot scheme.
|
|
|
+ This document is about Secure Boot V2, supported on {IDF_TARGET_NAME} {IDF_TARGET_ECO_VERSION}
|
|
|
|
|
|
.. only:: esp32
|
|
|
|
|
|
@@ -17,7 +29,6 @@ Secure Boot V2
|
|
|
|
|
|
Secure Boot V2 uses {IDF_TARGET_SBV2_SCHEME} based app and bootloader verification. This document can also be used as a reference for signing apps using the {IDF_TARGET_SBV2_SCHEME} scheme without signing the bootloader.
|
|
|
|
|
|
-
|
|
|
.. only:: esp32
|
|
|
|
|
|
``Secure Boot V2`` and RSA scheme (``App Signing Scheme``) options are available for ESP32 from ECO3 onwards. To use these options in menuconfig, set :ref:`CONFIG_ESP32_REV_MIN` greater than or equal to `Rev 3`.
|
|
|
@@ -31,13 +42,17 @@ Background
|
|
|
|
|
|
Secure Boot protects a device from running any unauthorized (i.e., unsigned) code by checking that each piece of software that is being booted is signed. On an {IDF_TARGET_NAME}, these pieces of software include the second stage bootloader and each application binary. Note that the first stage bootloader does not require signing as it is ROM code thus cannot be changed.
|
|
|
|
|
|
-.. only:: SOC_SECURE_BOOT_V2_RSA
|
|
|
+.. only:: esp32 or (SOC_SECURE_BOOT_V2_RSA and not SOC_SECURE_BOOT_V2_ECC)
|
|
|
|
|
|
- A new RSA based Secure Boot verification scheme (Secure Boot V2) has been introduced on the ESP32 (ECO3 onwards), ESP32-S2, ESP32-S3 and ESP32-C3 (ECO3 onwards).
|
|
|
+ A RSA based Secure Boot verification scheme (Secure Boot V2) is implemented on {IDF_TARGET_NAME} {IDF_TARGET_ECO_VERSION}.
|
|
|
|
|
|
-.. only:: SOC_SECURE_BOOT_V2_ECC
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_ECC and not SOC_SECURE_BOOT_V2_RSA
|
|
|
+
|
|
|
+ A ECC based Secure Boot verification scheme (Secure Boot V2) has been introduce on {IDF_TARGET_NAME}
|
|
|
|
|
|
- A new ECC based Secure Boot verification scheme (Secure Boot V2) has been introduced on the ESP32-C2.
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_RSA and SOC_SECURE_BOOT_V2_ECC
|
|
|
+
|
|
|
+ {IDF_TARGET_NAME} has provision to choose between a {IDF_TARGET_SBV2_SCHEME} based secure boot verification scheme.
|
|
|
|
|
|
The Secure Boot process on the {IDF_TARGET_NAME} involves the following steps:
|
|
|
|
|
|
@@ -54,7 +69,7 @@ Advantages
|
|
|
|
|
|
- Only one public key can be generated and stored in the chip during manufacturing.
|
|
|
|
|
|
-.. only:: esp32s2 or esp32c3 or esp32s3
|
|
|
+.. only:: SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS
|
|
|
|
|
|
- Up to three public keys can be generated and stored in the chip during manufacturing.
|
|
|
|
|
|
@@ -82,7 +97,7 @@ Secure Boot V2 verifies the bootloader image and application binary images using
|
|
|
|
|
|
Only one signature block can be appended to the bootloader or application image in {IDF_TARGET_NAME}
|
|
|
|
|
|
-.. only:: esp32s2 or esp32c3 or esp32s3
|
|
|
+.. only:: SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS
|
|
|
|
|
|
Up to 3 signature blocks can be appended to the bootloader or application image in {IDF_TARGET_NAME}.
|
|
|
|
|
|
@@ -113,11 +128,37 @@ Signature Block Format
|
|
|
|
|
|
The signature block starts on a 4KB aligned boundary and has a flash sector of its own. The signature is calculated over all bytes in the image including the padding bytes (:ref:`secure_padding`).
|
|
|
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_RSA and SOC_SECURE_BOOT_V2_ECC
|
|
|
+
|
|
|
+ .. note::
|
|
|
+
|
|
|
+ {IDF_TARGET_NAME} has a provision to choose between RSA scheme and ECDSA scheme. Only one scheme can be used per device.
|
|
|
+
|
|
|
+ ECDSA provides similar security strength, compared to RSA, with shorter key lengths. Current estimates are that ECDSA with curve P-256 has an approximate equivalent strength to RSA with 3072-bit keys. However, ECDSA signature verification takes considerably more amount of time as compared to RSA signature verification.
|
|
|
+
|
|
|
+ RSA is recommended for use cases where fast bootup time is required whereas ECDSA is recommended for use cases where shorter key length is required.
|
|
|
+
|
|
|
+ .. list-table:: Comparison between signature verification time
|
|
|
+ :widths: 10 10 20
|
|
|
+ :header-rows: 1
|
|
|
+
|
|
|
+ * - **Verification scheme**
|
|
|
+ - **Time**
|
|
|
+ - **CPU Frequency**
|
|
|
+ * - RSA-3072
|
|
|
+ - {IDF_TARGET_RSA_TIME}
|
|
|
+ - {IDF_TARGET_CPU_FREQ}
|
|
|
+ * - ECDSA-P256
|
|
|
+ - {IDF_TARGET_ECDSA_TIME}
|
|
|
+ - {IDF_TARGET_CPU_FREQ}
|
|
|
+
|
|
|
+ The above table compares the time taken to verify a signature in a particular scheme. It does not indicate the bootup time.
|
|
|
+
|
|
|
The content of each signature block is shown in the following table:
|
|
|
|
|
|
-.. only:: not esp32c2
|
|
|
+.. only:: esp32 or SOC_SECURE_BOOT_V2_RSA
|
|
|
|
|
|
- .. list-table:: Content of a Signature Block
|
|
|
+ .. list-table:: Content of a RSA Signature Block
|
|
|
:widths: 10 10 40
|
|
|
:header-rows: 1
|
|
|
|
|
|
@@ -164,7 +205,7 @@ The content of each signature block is shown in the following table:
|
|
|
|
|
|
.. only:: SOC_SECURE_BOOT_V2_ECC
|
|
|
|
|
|
- .. list-table:: Content of a Signature Block
|
|
|
+ .. list-table:: Content of a ECDSA Signature Block
|
|
|
:widths: 10 10 40
|
|
|
:header-rows: 1
|
|
|
|
|
|
@@ -257,14 +298,17 @@ An image is “verified” if the public key stored in any signature block is va
|
|
|
|
|
|
2. Generate the application image digest and match it with the image digest in the signature block. If the digests don't match, the verification fails.
|
|
|
|
|
|
-.. only:: not esp32c2
|
|
|
+.. only:: esp32 or (SOC_SECURE_BOOT_V2_RSA and not SOC_SECURE_BOOT_V2_ECC)
|
|
|
|
|
|
3. Use the public key to verify the signature of the bootloader image, using RSA-PSS (section 8.1.2 of RFC8017) with the image digest calculated in step (2) for comparison.
|
|
|
|
|
|
-.. only:: esp32c2
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_ECC and not SOC_SECURE_BOOT_V2_RSA
|
|
|
|
|
|
3. Use the public key to verify the signature of the bootloader image, using ECDSA signature verification (section 5.3.3 of RFC6090) with the image digest calculated in step (2) for comparison.
|
|
|
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_ECC and SOC_SECURE_BOOT_V2_RSA
|
|
|
+
|
|
|
+ 3. Use the public key to verify the signature of the bootloader image, using either RSA-PSS (section 8.1.2 of RFC8017) or ECDSA signature verification (section 5.3.3 of RFC6090) with the image digest calculated in step (2) for comparison.
|
|
|
|
|
|
|
|
|
Bootloader Size
|
|
|
@@ -287,10 +331,12 @@ eFuse usage
|
|
|
|
|
|
- BLK2 - Stores the SHA-256 digest of the public key. SHA-256 hash of public key modulus, exponent, pre-calculated R & M’ values (represented as 776 bytes – offsets 36 to 812 - as per the :ref:`signature-block-format`) is written to an eFuse key block. The write-protection bit must be set, but the read-protection bit must not.
|
|
|
|
|
|
-.. only:: esp32s2 or esp32c3 or esp32s3
|
|
|
+.. only:: not esp32
|
|
|
|
|
|
- SECURE_BOOT_EN - Enables Secure Boot protection on boot.
|
|
|
|
|
|
+.. only:: SOC_EFUSE_KEY_PURPOSE_FIELD
|
|
|
+
|
|
|
- KEY_PURPOSE_X - Set the purpose of the key block on {IDF_TARGET_NAME} by programming SECURE_BOOT_DIGESTX (X = 0, 1, 2) into KEY_PURPOSE_X (X = 0, 1, 2, 3, 4, 5). Example: If KEY_PURPOSE_2 is set to SECURE_BOOT_DIGEST1, then BLOCK_KEY2 will have the Secure Boot V2 public key digest. The write-protection bit must be set (this field does not have a read-protection bit).
|
|
|
|
|
|
- BLOCK_KEYX - The block contains the data corresponding to its purpose programmed in KEY_PURPOSE_X. Stores the SHA-256 digest of the public key. SHA-256 hash of public key modulus, exponent, pre-calculated R & M’ values (represented as 776 bytes – offsets 36 to 812 - as per the :ref:`signature-block-format`) is written to an eFuse key block. The write-protection bit must be set, but the read-protection bit must not.
|
|
|
@@ -318,9 +364,9 @@ How To Enable Secure Boot V2
|
|
|
|
|
|
4. Select the desired UART ROM download mode in "UART ROM download mode". By default the UART ROM download mode has been kept enabled in order to prevent permanently disabling it in the development phase, this option is a potentially insecure option. It is recommended to disable the UART download mode for better security.
|
|
|
|
|
|
-.. only:: esp32s2 or esp32c3 or esp32s3
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_RSA or SOC_SECURE_BOOT_V2_ECC
|
|
|
|
|
|
- 2. The "Secure Boot V2" option will be selected and the "App Signing Scheme" would be set to RSA by default.
|
|
|
+ 2. The "Secure Boot V2" option will be selected and the "App Signing Scheme" would be set to {IDF_TARGET_SBV2_DEFAULT_SCHEME} by default. {IDF_TARGET_SECURE_BOOT_OPTION_TEXT}
|
|
|
|
|
|
3. Specify the path to Secure Boot signing key, relative to the project directory.
|
|
|
|
|
|
@@ -368,11 +414,11 @@ Generating Secure Boot Signing Key
|
|
|
|
|
|
The build system will prompt you with a command to generate a new signing key via ``espsecure.py generate_signing_key``.
|
|
|
|
|
|
-.. only:: not esp32c2
|
|
|
+.. only:: esp32 or SOC_SECURE_BOOT_V2_RSA
|
|
|
|
|
|
- The ``--version 2`` parameter will generate the RSA 3072 private key for Secure Boot V2.
|
|
|
+ The ``--version 2`` parameter will generate the RSA 3072 private key for Secure Boot V2. Additionally ``--scheme rsa3072`` can be passed as well to generate RSA 3072 private key
|
|
|
|
|
|
-.. only:: esp32c2
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_ECC
|
|
|
|
|
|
Select the ECDSA scheme by passing ``--version 2 --scheme ecdsa256`` or ``--version 2 --scheme ecdsa192`` to generate corresponding ECDSA private key
|
|
|
|
|
|
@@ -380,21 +426,23 @@ The strength of the signing key is proportional to (a) the random number source
|
|
|
|
|
|
For example, to generate a signing key using the openssl command line:
|
|
|
|
|
|
-.. only:: not esp32c2
|
|
|
+.. only:: esp32 or SOC_SECURE_BOOT_V2_RSA
|
|
|
+
|
|
|
+ For RSA 3072
|
|
|
|
|
|
```
|
|
|
openssl genrsa -out my_secure_boot_signing_key.pem 3072
|
|
|
```
|
|
|
|
|
|
-.. only:: esp32c2
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_ECC
|
|
|
|
|
|
- For NIST192p curve
|
|
|
+ For ECC NIST192p curve
|
|
|
|
|
|
```
|
|
|
openssl ecparam -name prime192v1 -genkey -noout -out my_secure_boot_signing_key.pem
|
|
|
```
|
|
|
|
|
|
- For NIST256p curve
|
|
|
+ For ECC NIST256p curve
|
|
|
|
|
|
```
|
|
|
openssl ecparam -name prime256v1 -genkey -noout -out my_secure_boot_signing_key.pem
|
|
|
@@ -460,12 +508,12 @@ Secure Boot Best Practices
|
|
|
* Enable all Secure Boot options in the Secure Boot Configuration. These include flash encryption, disabling of JTAG, disabling BASIC ROM interpreter, and disabling the UART bootloader encrypted flash access.
|
|
|
* Use Secure Boot in combination with :doc:`flash encryption<flash-encryption>` to prevent local readout of the flash contents.
|
|
|
|
|
|
-.. only:: esp32s2 or esp32c3 or esp32s3
|
|
|
+.. only:: SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS
|
|
|
|
|
|
Key Management
|
|
|
--------------
|
|
|
|
|
|
- * Between 1 and 3 RSA-3072 public key pairs (Keys #0, #1, #2) should be computed independently and stored separately.
|
|
|
+ * Between 1 and 3 {IDF_TARGET_SBV2_KEY} public key pairs (Keys #0, #1, #2) should be computed independently and stored separately.
|
|
|
* The KEY_DIGEST eFuses should be write protected after being programmed.
|
|
|
* The unused KEY_DIGEST slots must have their corresponding KEY_REVOKE eFuse burned to permanently disable them. This must happen before the device leaves the factory.
|
|
|
* The eFuses can either be written by the software bootloader during during first boot after enabling "Secure Boot V2" from menuconfig or can be done using `espefuse.py` which communicates with the serial bootloader program in ROM.
|
|
|
@@ -581,14 +629,18 @@ How To Enable Signed App Verification
|
|
|
|
|
|
2. Ensure `App Signing Scheme` is `RSA`. For ESP32 ECO3 chip, select :ref:`CONFIG_ESP32_REV_MIN` to `Rev 3` to get `RSA` option available
|
|
|
|
|
|
-.. only:: not esp32 and not esp32c2
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_RSA and not SOC_SECURE_BOOT_V2_ECC
|
|
|
|
|
|
2. Ensure `App Signing Scheme` is `RSA`
|
|
|
|
|
|
-.. only:: esp32c2
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_ECC and not SOC_SECURE_BOOT_V2_RSA
|
|
|
|
|
|
2. Ensure `App Signing Scheme` is `ECDSA (V2)`
|
|
|
|
|
|
+.. only:: SOC_SECURE_BOOT_V2_RSA and SOC_SECURE_BOOT_V2_ECC
|
|
|
+
|
|
|
+ 2. Choose `App Signing Scheme`. Either `RSA` or `ECDSA (V2)`
|
|
|
+
|
|
|
|
|
|
3. Enable :ref:`CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT`
|
|
|
|