Program User eFUSE

The SPK eFUSE is 32-bits, therefore there are only 32 possible revocations when using the Zynq UltraScale+ MPSoC standard key revocations. Another limitation is that all user partitions must share the same SPK ID with the FSBL. In the current example, the lab application and FSBL both have the SPK ID at 00000001. To overcome this, there is Zynq UltraScale+ MPSoC Enhanced Key Revocation, which allows different SPK IDs across multiple user partitions using User eFUSES.

Note: The FSBL must always use SPK eFUSE for SPK ID. Zynq UltraScale+ MPSoC enhanced key revocation can only be used for user applications/partitions.

In this section, a new BI is first generated, which uses User eFUSE SPK ID 1 for the lab application. With the new BI successfully loaded, SPK ID 1 is revoked using lab UI, which leads to failure in loading of the lab application when the board is re-booted. A new SPK ID is then assigned to the lab application (in the BIF file) and a new BI is generated and loaded into the device to verify successful loading of the user application (lab application) with the new SPK ID.

Note: Zynq UltraScale+ MPSoC standard key revocation uses hexadecimal value of 32-bit SPK eFUSE. However, Zynq UltraScale+ MPSoC enhanced key revocation needs key decimal numbers between 1–255.

Create a new BIF file.

Enter file name secured_eKeyR.bif with the following contents:

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
[pskfile]C:\Xilinx\enhanced_key_revocation_lab_files\psk0.pem
[auth_params]ppk_select = 0
[bootloader, destination_cpu=a53-0, authentication = rsa, spk_select = spk-efuse, sskfile = C:\Xilinx\enhanced_key_revocation_lab_files\ssk0.pem, spk_id = 0x00000001]C:\Xilinx\Key_Revocation_Lab\Key_Revocation_Platform\export\Key_Revocation_Platform\sw\Key_Revocation_Platform\boot\fsbl.elf 
[authentication = rsa, destination_cpu = a53-0, spk_select = user-efuse, sskfile = C:\Xilinx\enhanced_key_revocation_lab_files\ssk1.pem, spk_id = 1]C:\Xilinx\Key_Revocation_Lab\key_revocation_lab\Debug\key_revocation_lab.elf
}

Note: The SPK-select field of the BIF file determines which revocation method will be used. The values for this field can be spk-efuse (Zynq UltraScale+ MPSoC standard key revocation) or user-efuse (Zynq UltraScale+ MPSoC enhanced key revocation). In the secured_eKeyR.bif file, the SPK-eFUSE value is used for the FSBL SPK-select field and the user-eFUSE value is used for the corresponding lab application field.

Note: In the secured_eKeyR.bif file, ssk0.pem file is used for the FSBL and ssk1.pem file is used for the lab application.

Generate a new secured BI BOOT.bin using the bootgen command:

bootgen –image secured_eKeyR.bif -r -o BOOT.bin -arch zynqmp -w on

Select a new BI and copy it to the SD card.
Power on the board.
The lab application loads successfully and the main menu displays.

Note: SPK ID 1 for the lab application was successful because it has not been revoked yet.
Select r = SPK Revocation from the main menu.
Select u = Revoking keys by programming User eFUSEs from the sub-menu.
Set 001 as the SPK ID to be revoked.
Set y to confirm.
Note: The tool expects an integer value between 1 – 256. The SPK ID must be entered as three digits (i.e., for 1 enter 001, for 32 enter 032, and for 150 enter 150.

Figure 1. Enhanced SPK Revocation

The UI prints out the current SPK ID and the one it will be changed to.
Enter y to reconfirm the eFUSE programming.
Verify that the user eFUSE was successfully programmed.
Select s = Print eFUSE Status from the main menu.
Note: In the status for User0 eFUSE, the new value should be printed (i.e., 00000001) and in the list of revoked keys, 1 will be listed among the revoked keys.
Power cycle the board.
The serial terminal shows that the FBSL loads, but the lab application fails to load. In addition, the PS_ERR_OUT LED glows red. This verifies that revocation of SPK ID 1 worked because in the current BI, the lab application uses SPK ID 1 (User eFUSE) which has been successfully revoked restricting its further usage.

Note: It takes up to 30 seconds for the LED light to light up.

Note: In the programmed ZCU102 board, no user application can use the revoked user-eFUSE SPK ID 1.
With SPK ID 1 revoked, the lab application now must use a different SPK ID between 2-256 for a successful boot. In the following steps, the BIF file is modified with a new value for the lab application SPK ID, which will be 2.

Select secured_eKeyR.bif.

Set spk_id field value from 1 to 2.

Save the file as secured_eKeyR_mod.bif.

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
[pskfile]C:\Xilinx\enhanced_key_revocation_lab_files\psk0.pem
[auth_params]ppk_select = 0
[bootloader, destination_cpu=a53-0, authentication = rsa, spk_select = spk-efuse, sskfile = C:\Xilinx\enhanced_key_revocation_lab_files\ssk0.pem, spk_id = 0x00000001]C:\Xilinx\Key_Revocation_Lab\Key_Revocation_Platform\export\Key_Revocation_Platform\sw\Key_Revocation_Platform\boot\fsbl.elf 
[authentication = rsa, destination_cpu = a53-0, spk_select = user-efuse, sskfile = C:\Xilinx\enhanced_key_revocation_lab_files\ssk1.pem, spk_id = 2]C:\Xilinx\Key_Revocation_Lab\key_revocation_lab\Debug\key_revocation_lab.elf
}

Generate a new secured BOOT.bin BI using the bootgen command:

bootgen –image secured_eKeyR_mod.bif -r -o BOOT.bin -arch zynqmp -w on

Copy the new BOOT.BIN BI to the SD card.
Power on the board.
Both the FSBL and lab application load successfully. User eFUSE SPK ID 2 for the lab application works because that key has not been revoked.