[ZYNQ] Provisioning Guideline

In a nutshell, the cortex-A53 bare-mental provisioning application is used to program the eFUSE, register the PUF, generate an AES black key, and write the Linux Kernel KUP key to the SD card. The provisioning application is always loaded by the Xilinx ZYNQ FSBL.

The provisioning includes the following steps:

1. Provisioning Steps

1.1 PUF Register

Zynq UltraScale+ devices use a hardened AES cryptographic block for AES encryption and decryption. The AES cryptographic block accepts keys from several sources to include storing a 256-bit AES key in eFUSEs. The AES key can also be stored in an obfuscated or black format either externally in flash or internally in eFUSEs. The AES key cannot be read out of eFUSEs once it has been programmed. The integrity of the key loading operation is verified using a 32-bit CRC. The Zynq UltraScale+ device also supports AES encryption and decryption using a PUF generated key, as discussed in Physically Uncloneable Function (PUF) Support. In the PUF eFUSEs mode, the CHASH, AUX data, and SYNDROME or PUF helper data are programmed into the eFUSEs.

The principle use of the PUF in Zynq UltraScale+ devices is black key storage. Black key storage stores the user’s AES key in the eFUSEs or in the Bootheader in an encrypted format. At the time of use, the encrypted key in the eFUSEs or Bootheader is decrypted, and the resulting plaintext key is used for the encryption and decryption operation. As a secondary usage of the PUF, the PUF along with the AES engine, can be used to encrypt and decrypt user data. Refer to External Secure Storage Using the PUF https://www.xilinx.com/support/documentation/application_notes/xapp1333-external-storage-puf.pdf

The PUF register process of the provisioning is to:

• Generate the PUF key and PUF helper data.

• Encrypt the Red Key to the black key, and write the black key to the eFUSE.

• Write the PUF helper data to eFUSE.

The PUF register process of the provisioning is shown as follows:

1.2 Write RSA key to eFUSE

Zynq UltraScale+ devices use silicon-based RSA and SHA3 cryptographic blocks for RSA authentication. RSA uses a 4096-bit private/public key pair. Only the 384-bit hash of the primary public key (PKK) is stored in the eFUSEs to save the area on the device. 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. For further details, you can refer to Zynq UltraScale+ MPSoC: Technical Reference Manual (UG1085). You can also program eFUSEs for revoking the public keys of applications and partitions. For further details, you can refer to Key Revocation Lab (XAPP1344).

1.3 Write the KUP key of the Linux Kernel to the SD card

The Xilinx Linux Kernel decrypting design has a flaw in that the AES key exists in the partition’s secure header in plaintext form when the image is generated by multi-stages. To enhance the partition secure feature, we designed the decrypt_agent (DA) app based on the cortex-r5 CPU. The cortex-r5 decrypt_agent locks steps with a cortex-a53 CPU that normally boots the images of BOOT.bin. The cortex-r5 decrypt_agent decrypts the encrypted Linux kernel synchronously when the cortex-a53 nearly boots to the TF-A bl31.bin. The cortex-r5 writes the decrypted Linux kernel to the DRAM for the cortex-a53 to boot it with U-Boot.

The Linux kernel KUP key blob shall be provisioned to the SD card. Then the decrypt_agent will use the KUP key blob to decrypt the Linux kernel. For more information, please refer to the https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/23/ecus/zynq_documents/zynq-decrypting-partition-by-the-decrypt-agent-using-puf-key

The encrypted image key is encrypted by the PUF key that is unique on each device. The provisioning process will write the encrypted image key to the SD card. Even if this key can be read from the SD card, it has no meaning for the reader. For he decryption of the decrypt_agent, you can refer the https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/23/ecus/zynq_documents/zynq-decrypting-partition-by-the-decrypt-agent-using-puf-key

The writing to the SD card process of the provisioning is shown in the following diagram:

2. Importing the VITIS Project

This section will describe how to import the VITIS project for the provisioning app.

Launch Vitis and create a platform project:

2.1 New hardware platform file

Click File > New > Platform Project to create a platform project using ZCU102 Vivado Xilinx Shell Archive (XSA).

Enter the project name as hw_platform, when the New Platform Project dialog box opens as shown in Figure 2. Click Next

Browse and select zcu102.xsa from the Vitis installation folder. To create the platform based on your selection, the tool automatically selects the appropriate operating system and processor.

Choose Create from hardware specification (XSA) in the Platform Project dialog box, and click Next.

Click Finish to create your platform project. The platform project editor opens as shown in Figure 5.

Right-click hw_platform and select Platform Build >Project to build the hardware platform. When the platform is generated, the dialog box shows the status of platform generation and the Board Support Package Settings dialog box opens.

Select Board Support Package under psu_cortexr53_0. The Board Support Package opens as shown in Figure 6

2.2 New provisioning software project

2.3 Cloning the source code to VITIS IDE

Get the location on the method of the figure.

Then get the all the source code on https://github.com/carloscn/zynq_device/tree/master

Go to the command line terminal:

Copy the Provisioning program in the warehouse:

The file can be found under the Debug of the previous directory in the current directory:

The file can be found under the Debug of the previous directory in the current directory. Copy the provision.elf to the path in the following figure. Let's rename it provision.elf

The boot_provision_image.sh will populate the dec_agent.elf to the boot image.