Symmetric Hardware Root of Trust Secure Boot

Versal ACAP Technical Reference Manual (AM011)
Document ID
AM011
Release Date
2022-12-16
Revision
1.5 English

The Versal device S-HWRoT secure boot mode is enabled through the programming of eFUSEs. Similar to the A-HWRoT mode, this mode provides confidentiality, integrity, and authentication of the device configuration files. However, unlike the A-HWRoT mode, the S-HWRoT mode provides integrity and authentication using the counter mode of symmetric AES (AES-GCM).

In this boot mode, all configuration images are encrypted (excluding the boot header). Given this exclusion, the boot header is subject to modification. Consequently, all security critical information contained in the boot header is ignored but replicated in eFUSEs. Modification of the boot header itself, while possible, achieves nothing as the eFUSEs are used for security critical decisions, not the boot header itself.
Recommended: Xilinx strongly recommends the purchase of devices with built-in side channel leakage reduction functionality enabled. Protocol DPA countermeasures (authentication prior to decryption) cannot be used in the S-HWRoT boot mode due to the lack of asymmetric authentication. However, the built-in side channel leakage reduction capabilities can provide DPA resistance.

The following figure shows a high-level view of the S-HWRoT boot flow.

Figure 1. Symmetric Hardware Root of Trust Boot Flow

The RCU detects that the S-HWRoT secure boot mode is enabled and then automatically decrypts the PLM and CDO. To maximize security, the key used by the RCU at this point is limited to the black key. This key is stored encrypted by the PUF key encryption key (KEK). No other key source is allowed for the PLM and CDO. The IVs used at this point are programmed by the user into internal eFUSEs. As this is located inside the device, they are protected from modification.

Once the PLM and CDO have been decrypted and authenticated (via the AES GCM tag) and stored in internal memory, the RCU releases the reset to the specified processing unit. At this stage, control is handed over to the user application and it is responsible for maintaining the established security. All remaining partitions can use the following key sources on a partition-by-partition basis:

  • Black eFUSE key
  • User AES keys (volatile or non-volatile)

The IVs used for the remaining partitions are securely delivered within the configuration image. The process to load these partitions is user-configurable.