Encrypt Only Secure Boot Details

Zynq UltraScale+ Device Technical Reference Manual (UG1085)

Document ID
Release Date
2.3 English

The Zynq UltraScale+ MPSoC hardware encrypt only secure boot is based solely on the confidentiality and symmetric authentication provided by AES-GCM. The encrypt only secure boot mode is enabled by programming the ENC_ONLY eFUSE. This eFUSE forces the device to decrypt every partition using the AES-GCM key stored in the eFUSEs.

The CSU, FSBL, XilSecure, and XilFPGA libraries loaded by the CSU decrypts every partition (e.g., FSBL, PMUFW, ATF, bitstream, U-Boot, etc.) loaded. The CSU ROM reads the ENC_ONLY eFUSE, sees that it is programmed and then automatically decrypts the FSBL. Since the CSU processes the FSBL and PMUFW as two separation partitions, the AES key and IV are reused if the PMUFW is part of the bootloader. The reuse of the AES key and IV is a violation of the AES standard. Consequently, the PMUFW must be loaded by the FSBL, and not the CSU, in the encrypt only secure boot mode. Once the FSBL has been decrypted and authenticated (using symmetric authentication provided by AES-GCM) in internal memory, the CSU releases the reset to the specified processing unit (APU or RPU). At this stage, control is handed over to the user and the user is responsible for maintaining the established security. The remaining secure boot process is configurable by the user. An example of an encrypt only secure boot process is shown in This Figure.

Figure 12-15:      Encrypt Only Secure Boot Example

X-Ref Target - Figure 12-15


In this example, the FSBL decrypts the Arm trusted firmware (ATF), U-Boot, and the PL bitstream, which are all individual partitions. The FSBL executing at EL3 and using the AES-GCM accelerator decrypts each partition using the device key stored in either eFUSE or BBRAM. However, the eFUSE key must be used when you use ENC_ONLY.


IMPORTANT:   If the bitstream is encrypted with the device key, the key stored in eFUSE or BBRAM, the bitstream must be decrypted and loaded by the FSBL. If the bitstream is encrypted with a user-provided key, U-Boot and Linux can command the bitstream load and decryption via the XILFPGA library. For more details, see the Loading Bitstreams section.


IMPORTANT:   The PUF is disabled and not supported for use in the encrypt only secure boot mode.

If any of these partitions fail the decryption GCM-tag check, the FSBL sets the multi-boot register and initiates a soft reset. The boot process starts over with the CSU looking for a valid boot image in memory. If a valid boot image is not found, the device goes into secure lockdown and requires a POR to exit.

To complete the secure boot process, Linux and the RPU SW must be decrypted and loaded by U-Boot. Linux and the RPU SW can be part of the boot.bin or they can be a single partition image that is resident in a different physical memory. In either case, U-Boot does not perform the decryption but rather calls the XilSecure library, which was securely loaded as part of the PMUFW. XilSecure executes out of internal PMU RAM and uses the AES-GCM accelerator to perform the decryption.

Note:   Partitions that are decrypted by U-Boot must be encrypted with a user-provided key and not the device key.The user-provided key is identified via the XilSecure API.

If there is a decryption failure, while using the GCM-tag check, XilSecure passes the failure status to U-Boot.

There are two important considerations of the encrypt only secure boot mode that may require you to provide system-level protections. First, the partitions are not authenticated before decryption. The symmetric authentication occurs at the end of the decryption cycle. This means that the device is subject to a DPA random-data attack. Hence, you should provide system-level protections if the DPA attack vector is a concern. For more information, see DPA Resistance. Second, the boot and partition headers are not authenticated. Without authentication of these headers, anyone with access to the boot image, can modify the control fields resulting in incorrect secure boot behavior. One such example, is modification of the destination execution address. This address represents the start instruction address for a loaded partition. Anyone with access to the boot image could modify the address, causing the device to jump to an arbitrary memory location to modify or bypass the secure boot process. Hence, you should provide system-level protections if the lack of authentication of the boot and partition headers is a concern.