Program SPK ID eFUSE

Generating a Secure Boot Image and Booting the Secured ZCU102 Device demonstrates how to generate a secure BI. The generated BI uses SPK ID as 0x00000000 (default) for the FBSL and the lab application. To make the device and booting process more secure this value must be changed. Perform the following steps to change the SPK ID to 0x00000001.

Note: An SPK ID of 0x00000001 is used to minimize irreversible programming of the SPK eFUSE because it is the least significant bit. For more practical purposes, the SPK eFUSE can have any value between 0x00000001 and 0xFFFFFFFF. To maximize SPK ID range the values it should be programmed as current value + next power of 2 (consuming only one bit per programming).

Power cycle the board to load the current BIF.
Select r = SPK Revocation from the main menu.
Select s = Revoking keys by programming SPK eFUSE from the sub-menu.
The current SPK ID value is displayed.
Enter 00000001 for the new SPK ID.
Enter y to confirm SPK eFUSE programming, however any pattern of eFUSEs can be written to fulfill key revocation needs.
Figure 1. Standard SPK Revocation
Select s = Print eFUSE Status from the main menu.
View the new SPK ID.
Verify the correct SPK ID was programmed. The new SPK ID value should be 00000001.
Power cycle the board. The FSBL and lab application fail to load and the PS_ERR_OUT LED glows red, as shown in Figure 19.
Note: In this application note, failure to load the BI is purposefully done to show that our security mechanism is working.

Note: A failure of the current BI to load on the device indicates that SPK ID revocation worked. Because the current BI uses the SPK ID of the eFUSE as 0x00000000 (default) and the new value of SPK ID in the device is 0x00000001, the boot is expected to fail. A new BI with the SPK ID set to 0x00000001 must be generated for a successful boot.

Modify the secured.bif file generated in Generating a Secure Boot Image and Booting the Secured ZCU102 Device.

Change the spk_id value in the BIF file to 0x00000001 (hex value for 32-bit eFUSE).

Save the modified file and name it secured_mod.bif.

Note: In the demonstrations, the revocation steps are shown and the same keys are simply reloaded. In a normal scenario, new keys would be generated and incorporated.

//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
}

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

bootgen -image secured_mod.bif -r -o BOOT.bin -archzynqmp - w on

Copy the new BOOT.BIN to the SD card.
Power on the board.
Both the FSBL and the lab application should load successfully. The lab UI main menu displays on the serial terminal.

Note: SPK ID0x00000001 should be used for BI generation targeted on the programmed ZCU102 device (unless changed to something else).