The increasing ubiquity of Xilinx® devices makes protecting the intellectual property (IP) within them as important as protecting the data processed by the device. Secure booting through the latest authentication methods is supported to prevent unauthorized or modified code from being run on Xilinx devices, and to make sure that only authorized programs access the images for loading various encryption techniques.
In a Zynq® UltraScale+™ MPSoC device, the secure boot is accomplished by using the hardware root of trust boot mechanism, which also provides a way to encrypt all of the boot or configuration files. This architecture provides the required confidentiality, integrity, and authentication to host the most secure of applications.
Zynq UltraScale+ MPSoCs has an AES-GCM hardware engine that supports confidentiality of your boot images and can also be used in post-boot to encrypt and decrypt user data.
The Zynq UltraScale+ MPSoC hardware root of trust is based on the RSA-4096 asymmetric authentication algorithm in conjunction with SHA-3/384. There are two key pairs used in the Zynq UltraScale+ MPSoC, and consequently two public key types: the primary public key (PPK) and the secondary public key (SPK).
AES Encryption:
AES is a symmetric key encryption technique; it uses the same key for encryption and decryption. The key used to encrypt a boot image should be available on the device for the decryption process while the device is booting with that boot image. Generally, the key is stored either in eFUSE or BBRAM, and the source of the key can be selected during boot image creation through BIF attributes. ZynqMP allows you to store the key in three forms – plain text key (Red key), obfuscated key (Gray key) and encrypted key (Black key).
Encryption process:
The boot image partitions are encrypted based on the user-provided encryption commands and attributes in the BIF file. The Bootgen tool is used to encrypt the partitions and the .bif file is input to it.
Figure: Encryption Process
Decryption Process:
For Xilinx SoC devices, the BootROM and the FSBL decrypt partitions during the booting cycle. The BootROM reads the FSBL from flash, decrypts, loads, and hands off the control. After the FSBL starts executing, it reads the remaining partitions, decrypts, and loads them. The AES key needed to decrypt the partitions can be retrieved from either eFUSE or BBRAM.
Figure: Decryption process
Key Management:
The AES crypto engine has access to a diverse set of key sources. Non-volatile key sources include eFUSEs, BBRAM, a PUF key encryption key (KEK), and a family key. These keys maintain their values even when the device is powered down. Volatile key sources include an operational key and a key update register key.
Red Key:
The red key is an unencrypted key (plain-text key) and can be stored in eFUSE/BBRAM. The red key is used by bootgen to encrypt the image and the ZynqMP uses the red key to decrypt the image during boot process.
Black Key:
The black key is an AES key encrypted with the Key Encryption Key (KEK) generated by the Physical Unclonable Function (PUF) module of the ZynqMP SoC. It can be stored in the eFUSE/boot header of the created image.
Gray/Obfuscated Keys:
The obfuscated key is an AES key encrypted (obfuscated) with the family key of the ZynqMP SoC. The family key is the dedicated embedded key in the device and the same key is used on all devices within a device family. The Obfuscated key can be stored in eFUSE/boot header of the image.
Operational Key:
The OP key is a register that holds the key decrypted from the secure header of the boot image. A good key management practice includes minimizing the use of secret or private keys. This can be accomplished using the operational key option enabled in Bootgen.
When enabled, the encrypted secure header in the FSBL will contain nothing more than the OP key, which is user specified, and the initialization vector (IV) needed for the first block of the configuration file. The result is that the AES key stored on the device, in either the BBRAM or eFUSEs, is only used for 384 bits, which significantly limits its exposure to side channel attacks.
Figure: Operational key
Rolling Keys:
The AES_GCM rolling keys feature represent the entire encrypted image in terms of smaller AES encrypted blocks/modules. Each module is encrypted using its own unique key. The initial key is stored at the key source on the device, while keys for each successive module are encrypted (wrapped) in the previous module.
RSA Authentication:
RSA is an asymmetric algorithm, meaning that the key to verify is not the same key used to sign. A pair of keys are needed for authentication. Signing is done using Secret Key/ Private Key and Verification is done using a Public Key.
In Xilinx SoCs, two pairs of public and secret keys are used – primary and secondary. The function of the primary public/secret key pair is to authenticate the secondary public/secret key pair. The function of the secondary key is to sign/verify partitions.
Singing:
The Bootgen signs partitions using the Secret key. The signing process is described in the following steps:
- PPK and SPK are stored in the Authentication Certificate (AC).
- SPK is signed using PSK to get the SPK signature which is also stored as part of the AC.
- Partition is signed using SSK to get Partition signature which is populated in the AC.
- The AC is appended or prepended to each partition that is opted in for authentication depending on the device.
- PPK is hashed and stored in eFUSE.
Verification:
In the device, the BootROM verifies the FSBL, and either the FSBL or U-Boot verifies the subsequent partitions using the Public key.
- Verify PPK: This step establishes the authenticity of the primary key, which is used to authenticate the secondary key
- PPK is read from the AC in the boot image
- Generate the PPK hash
- The hashed PPK is compared with the PPK hash retrieved from the eFUSE
- If they are the same, then the primary key is trusted. Otherwise secure boot will fail
- Verify secondary keys: This step establishes the authenticity of the secondary key, which is used to authenticate the partitions
- The SPK is read from the AC in the boot image
- Generate the hashed SPK
- Get the SPK hash, by verifying the SPK signature stored in the AC using PPK
- Compare the hashes from step (b) and step (c)
- If they are the same, then the secondary key is trusted. Otherwise secure boot will fail
- Verify partitions: This step establishes the authenticity of the partition which is being booted
- The partition is read from the boot image
- Generate the hash of the partition
- Get the partition hash by verifying the Partition signature stored in the AC using SPK
- Compare the hashes from step (b) and step (c)
- If they are the same, then the partition is trusted. Otherwise secure boot will fail
References:
1. https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
2. https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf
3. https://www.xilinx.com/support/documentation/sw_manuals/xilinx2021_1/ug1283-bootgen-user-guide.pdf
PlatoAi. Web3 Reimagined. Data Intelligence Amplified.
Click here to access.
