Secure boot ensures the system only runs intended firmware and is accomplished by using the hardware root of trust boot mechanism. This provides the required confidentiality, integrity, and authentication to host the most secure applications. The Zynq UltraScale+ MPSoC hardware root of trust is based on the Rivest-Shamir-Adleman (RSA)-4096 asymmetric authentication algorithm with the Secure Hash Algorithm (SHA)-3/384. The use and revocation of primary public keys and secondary public keys is demonstrated.
The secure boot process starts by determining which Primary Public Key (PPK) to use and then validating its integrity. The public key is stored in the boot image (BI) in external memory, therefore, it is assumed that an adversary could tamper with it. Consequently, the configuration security unit (CSU) reads the public key from external memory, calculates its cryptographic checksum using the SHA-3/384 engine, and compares it to the value stored in eFUSEs. If they match, the integrity of the public key has been validated and the boot can continue. The Secondary Public Key (SPK) and its associated ID are then read, stored in on-chip memory (OCM), and authenticated using the PPK. After the SPK and SPK ID have been authenticated, the CSU compares the ID that was bound to the SPK in the BI to the ID that is stored in the eFUSEs. If the IDs match, the SPK is valid and the boot continues. Lastly, the SPK verifies the authenticity of the entire BI. The CSU authenticates the first stage boot loader (FSBL), and optionally the PMU firmware (PMUFW) if enabled in the BI. If encrypted, the CSU also performs the decryption after authentication.
Refer to Zynq UltraScale+ Device Technical Reference Manual (UG1085) to better understand different boot modes and features available for secure, encrypted, and normal boot.
The Zynq UltraScale+ MPSoC can store the hash digest of both PPKs. Each PPK can only be revoked once (i.e., revoke the first PPK and use the second PPK). Since only two revocations is not sufficient in typical systems, the Zynq UltraScale+ MPSoC provides a secondary key mechanism that:
- Provides a second level of defense if the first authentication mechanism gets compromised.
- Allows the user to revoke SPK more than twice.
- Uses different keys to authenticate each application or group of partitions, enhancing the security posture of the end system.
Each SPK is associated with an ID called SPK_ID. The Zynq UltraScale+ MPSoC provides a 32-bit eFUSE register called SPK_ID to hold the SPK_ID associated with SPK, so the user can revoke the SPK a maximum of 32 times. In this document, this revocation method is referred to as Zynq UltraScale+ standard key revocation.
In addition, the Zynq UltraScale+ MPSoC also provides 256 user eFUSEs. These eFUSEs can be used optionally to indicate the revocation status of the SPK associated with SPK_IDs 0-256. With this, the user can revoke up to 256 SPKs. In this document, this revocation method is referred to as Zynq UltraScale+ enhanced key revocation.
The following table lists the key differences between standard and enhanced revocation modes.
| Zynq UltraScale+ Standard Key Revocation | Zynq UltraScale+ Enhanced Key Revocation |
|---|---|
| Uses SPK ID eFUSEs | Uses user eFUSEs |
| 32 Reserved eFUSEs | 256 user-assigned eFUSEs Note: Not all user eFUSEs are required to be
used.
|
| FSBL key must be revoked using the standard revocation format. | FSBL cannot be revoked using enhanced revocation format. |
| Non-FSBL partitions can be revoked using standard revocation format. | Non-FSBL partitions can be revoked using enhanced revocation format. |
| Only one standard SPK ID number is valid at a time. | Many enhanced SPK ID numbers can be valid at a time (up to 256). |
| Changing the SPKID eFUSEs impacts all partitions regardless of SPK ID number. | Changing the USER eFUSEs only impacts partitions using that specific SPK ID number. |