The Boot ROM allows to ensure the integrity of the device at boot.
An immutable boot sequence (Secure Boot Code) is implemented into a ROM called the Secure Boot ROM. The Secure Boot ROM manages Test mode entry, firmware and data authentication, firmware loading, and necessary system configurations.
For secure boot support on the PIC32CX-BZ3, a 64K ROM is dedicated to the secure boot firmware. Keys and credentials required for code authentication are stored as a part of eFuses. On every reset, secure boot firmware authenticates the rest of the program image in the Flash.
- Immutable boot support with ROM
- Firmware code authentication (Only at Boot time)
- Support for immutable keys
- Microchip or customer programmable secure boot key
- Support for secure execution environment
- Supports Anti-roll back
- Support for firmware readable life cycle counter
- Defined system boot state
Boot ROM Flow
Once the device comes out of reset, Boot ROM firmware checks if Test mode is triggered, if not it continues with chip initialization. After the completion of chip initialization, the bootstrap code checks for a valid firmware image and executes. If the device does not find any valid image, it jumps to Secure Safe mode. For validating the firmware image, the bootstrap code uses the security library depending on the firmware images authentication scheme specified for that firmware.
Firmware programming is handled by Device Firmware Update (DFU) using Device Service Unit (DSU). DSU supports the Debug mode, also it implements a CoreSight Debug ROM that provides device identification as well as identification of other debug components within the system. See Device Service Unit (DSU) from Related Links.
- An image with valid structure (defined in Table 1) and without using any authentication scheme.
- An image with a valid structure (defined inTable 1 ) with an authentication scheme supported by the device. For supporting the authentication scheme using public key cryptography, EFUSE must have a valid SECURE_BOOT_KEY.
- If the device is secured (with SECURE_BOOT_KEY! = 0), the valid image must always use the ECDSA p384 + SHA 384 or ECDSA p256 + SHA 256 for authentication.
Firmware Image Format
Firmware image comes with a metadata header, metadata payload, and metadata footer that gives the ROM firmware information about location of the firmware image, security decryption/ authentication information, sequence number and more. Application (Firmware Image) can only be executed from Embedded Flash or Boot Flash.
The following table provides details about the contents of each firmware image.
| Offset | Name | Description |
|---|---|---|
| Metadata Header | ||
| 0x00:0x03 | SEQ_NUM |
Metadata sequence number of the image in Little Endian (LE). Monotonically decreasing image index. Values of 0 or 0xFFFFFFFF indicate that the image is invalid. Boot ROM Image selection algorithm will prefer a valid image with lowest sequence number. |
| 0x04 | MD_REV |
Support Metadata Header Version Note: This field must be set to 0x01 for this version of metadata header. |
| 0x05 | CONT_IDX | 0x01 – Plain firmware image |
| 0x06:0x09 | IDENTIFIER | MCHP ASCII String Identifier. |
| 0x0A | MD_AUTH_MTHD |
Metadata authentication method. 0x00 – None 0x02 – ECDSA p256 + SHA256 0x03 – ECDSA p256 + SHA2-384 |
| 0x0B | MD_AUTH_KEY |
Key index for authenticating metadata. 0x00 – Secure boot Key |
| 0x0C | PL_DEC_MTHD |
Payload decryption method. 0x00 – Plain |
| 0x0D | PL_DEC_KEY | Not applicable. |
| 0x0E:0x0F | PL_LEN | Metadata payload length. The payload length for this version must be 0x74. |
| Metadata Payload = Firmware Image Header | ||
| 0x10:0x13 | FW_IMG_REV | Firmware image revision (little endian). |
| 0x14:0x17 | FW_IMG_SRC_ADDR |
Firmware Image source address. The source address of the firmware image in persistent storage. This field is not authenticated and the OTA or Bootloader can rewrite it based on the image storage location selected. |
| 0x18:0x1B | FW_IMG_DST_ADDR |
Firmware image destination address. The destination address will be used as the jump address during the application transition. As the ROM firmware must copy this header structure into executable memory, the destination address must not be less than 0x200. |
| 0x1C:0x1F | FW_IMG_LEN |
Firmware image length. The firmware image length must be a multiple of 4096 (Count) bytes. |
| 0x20 | FW_IMG_AUTH_MTHD |
Firmware image authentication method. 0x00 – None 0x02 – ECDSA p256 + SHA-256 0x03 – ECDSA p384 + SHA2-384 |
| 0x21 | FW_IMG_AUTH_KEY |
Firmware image authentication key index. 0x00 – Secure boot key |
| 0x22 | FW_IMG_DEC_MTHD |
Firmware image decryption method. 0x00 – Plain |
| 0x23 | FW_IMG_DEC_KEY | Not applicable. |
| 0x24:0x83 | FW_IMG_SIG |
The following are the options of firmware image signature: The concatenated R and S term of the ECDSA signature (P-256) of the SHA-256 hash of the firmware image specified by FW_IMG_SRC_ADDR and FW_IMG_LEN. (or) The concatenated R and S term of the ECDSA signature (P-384) of the SHA-384 hash of the firmware image specified by FW_IMG_SRC_ADDR and FW_IMG_LEN. |
| Metadata Footer | ||
| 0x84:0xE3 | MD_SIG |
The following are the options of metadata payload signature: The concatenated R and S term of the ECDSA signature (P-256) of the SHA-256 hash of the firmware image specified by FW_IMG_SRC_ADDR and FW_IMG_LEN. (or) The concatenated R and S term of the ECDSA signature (P-384) of the SHA-384 hash of the firmware image specified by FW_IMG_SRC_ADDR and FW_IMG_LEN. |
| Address | Size (bytes) | |
|---|---|---|
| Image 0 metadata | 0x0080_0000 | 512 |
| Image 0 | 0x0080_0200 | 15872 |
| Image 2 metadata | 0x0100_0000 | 512 |
| Image 2 | 0x0100_0200 | Max: 523776 |
| Image 3 metadata | 0x0104_0000 | 512 |
| Image 3 | 0x0104_0200 | Max: 261632 |
- Boot Flash image 0
- Embedded Flash image 0
- Embedded Flash image 1 in the second panel (only possible if the image is less than 256 KB; including headers)
For an embedded Flash only device, the ROM firmware checks for a valid image in three memory locations, see Table 2.
DSU Mode Entry
Immediately after resetting, the ROM firmware reads the condition of Code Protect, and Device Secured State bits to determine the Device Security state. Security state the ROM firmware needs to perform specific actions.
Serial Debugging and Programming
- The device is not code-protected and unsecured, supports debugging and programming features.
- The device is code-protected and unsecured, supports debugging, erase and programming features.
- The device is not code-protected and secured, does not support the debugging feature, and supports the programming feature.
- The device is not code-protected and secured, does not support the debugging feature, erase and supports the programming feature.
Chip Initialization
All the necessary hardware modules that the BOOT ROM program uses will be initialized – System clock, Interrupts, and more.
Firmware Authentication and Loading
The firmware image validation block is the primary block that ensures the integrity/authenticity of the images that are run on a secured device.
Firmware Image Validation – Secured Mode
The following are the main blocks in the process of image validation:
- 1.READ_CFG - Read device configuration (device id, secure elements). Secure elements and device id information can be accessed from EFUSE memory.
- 2.LOOKUP_METADATA - Search for valid firmware image metadata with the lowest sequence number.
- 3.AUTHENTICATE_IMAGE - Authenticate the image based on the security configuration of the device (EFUSE) and as indicated by its metadata. The firmware image header dictates the authentication scheme. Secure Boot is done on successful authentication of the firmware.
- 4.RUN_APPLICATION - If the valid image is in embedded flash and is available in its destination address space, jump to the DST_ADDR as indicated by its metadata.
- 5.SECURE_SAFE_MODE - Secure Safe mode is a
while 1() loopin the firmware, where the device is waiting for a valid application image to execute.
Firmware Image Validation – Unsecured Mode
In the Unsecured mode, the device is not checked for authentication scheme that needs SECURE_BOOT_KEY.
If the device is unsecured (and SECURE_BOOT_KEY is invalid and the Device Secured state is not set), the bootstrap code looks for valid images (valid sequence number, header and more.). Root of trust cannot be possible in this scenario.