Chapter 4. API Guides
1. On startup, the ROM code checks the Secure Boot V2 bit in the eFuse. If Secure Boot is disabled, a normal
boot will be executed. If Secure Boot is enabled, the boot will proceed according to the following steps.
2. The ROM code verifies the bootloader’s signature block (Verifying a Signature Block). If this fails, the boot
process will be aborted.
3. The ROM code verifies the bootloader image using the raw image data, its corresponding signature block(s),
and the eFuse (Verifying an Image). If this fails, the boot process will be aborted.
4. The ROM code executes the bootloader.
5. The bootloader verifies the application image’s signature block (Verifying a Signature Block). If this fails, the
boot process will be aborted.
6. The bootloader verifies the application image using the raw image data, its corresponding signature blocks and
the eFuse (Verifying an Image). If this fails, the boot process will be aborted. If the verification fails but
another application image is found, the bootloader will then try to verify that other image using steps 5 to 7.
This repeats until a valid image is found or no other images are found.
7. The bootloader executes the verified application image.
4.25.4 Signature Block Format
The bootloader and application images are padded to the next 4096 byte boundary, thus the signature has a flash
sector of its own. The signature is calculated over all bytes in the image including the padding bytes.
The content of each signature block is shown in the following table:
Table 8: Content of a Signature Block
Offset Size (bytes) Description
0 1 Magic byte
1 1 Version number byte (currently 0x02), 0x01 is for Secure Boot V1.
2 2 Padding bytes, Reserved. Should be zero.
4 32 SHA-256 hash of only the image content, not including the signature block.
36 384 RSA Public Modulus used for signature verification. (value ‘n’in
RFC8017).
420 4 RSA Public Exponent used for signature verification (value ‘e’in
RFC8017).
424 384 Pre-calculated R, derived from ‘n’.
808 4 Pre-calculated M’, derived from ‘n’
812 384 RSA-PSS Signature result (section 8.1.1 of RFC8017) of image content,
computed using following PSS parameters: SHA256 hash, MFG1 func-
tion, 0 length salt, default trailer field (0xBC).
1196 4 CRC32 of the preceding 1095 bytes.
1200 16 Zero padding to length 1216 bytes.
Note: R and M’are used for hardware-assisted Montgomery Multiplication.
The remainder of the signature sector is erased flash (0xFF) which allows writing other signature blocks after previous
signature block.
4.25.5 Verifying a Signature Block
A signature block is “valid”if the first byte is 0xe7 and a valid CRC32 is stored at offset 1196. Otherwise it’s
invalid.
Espressif Systems 1457
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General