Program PPK0_INVLD eFUSE

Due to security concerns such as losing or compromising the Primary Secret Key (PSK), there might be a situation where usage of a PPK eFUSE must be revoked. This is a one-time operation (i.e., after a PPK – 0 or 1 is revoked it cannot be undone). Therefore, exercise caution while using this feature. Revoking both the PPKs or having an un-revoked/programmed PPK and not having the corresponding key/pem file leads to bricking of the board (provided the RSA always enable eFUSE is already programmed).

Important: DO NOT revoke a PPK unless the other one is programmed or there will be no way to boot the device.

Because both PPK0 and PPK1 have been programmed, this section demonstrates how to invalidate the use of PPK0 as a PPK revocation example. After successful revocation, booting fails if the BI attempts to use PPK0. Changing the BIF file to use PPK1 successfully boots the device.

This task demonstrates how to invalidate the use of PPK0 as a PPK revocation example.

Select i = PPK Revocation from the main menu.
The status of eFUSEs is displayed for reference. Verify in the printed status that both PPK0 and PPK1 are valid.
Enter y to proceed with PPK revocation.
The status of PPK0 and PPK1 is printed for reference.
Enter 0 for revoking PPK0.
Enter y to confirm.
Confirmation of successful eFUSE programming is printed in the UI, as shown in the following figure.
Figure 1. PPK0 Revocation
Power cycle the board.
Note: Both the FSBL and lab application do not load because the BI is still using a revoked PPK (i.e., PPK0). Booting failure can also be confirmed by observing the LED color of PS_ERR_OUT, which is red. It takes up to 30 seconds for the LED to light up.

Note: After PPK0 has been revoked it can no longer be used in the BI, therefore, a new BI needs to be generated using PPK1.

Select secured_eKeyR_mod.bif.

Set the pskfile field to use psk1.pem.
Use the correct location of the file. In this case:
C:\Xilinx\enhanced_key_revocation_lab_files\psk1.pem
Set ppk_select to 1 to use PPK1 eFUSE (see the following code).

Save the file as secured_eKeyR_PPKr.bif.

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
[pskfile]C:\Xilinx\enhanced_key_revocation_lab_files\psk1.pem
[auth_params]ppk_select = 1
[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
}

Note: The corresponding pem file for PPK0 is psk0.pem and for PPK1 it is psk1.pem.

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

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

Copy the new BI to the SD card.
Power on the board.
Both the FSBL and the lab application load successfully. The current BI is using a valid PPK1.

After successful execution of all the steps in this tutorial, the device state is as follows:

PPK1 is the only valid PPK eFUSE and the corresponding pem file is psk1.pem.
- PSK1 is programmed with hash for psk1.pem.
RSA always authentication is enabled.
SPK ID, with regards to Standard Zynq UltraScale+ key revocation is 0x00000001.
SPK ID 1 is invalid, with regards to Zynq UltraScale+ enhanced key revocation.

After PPK0 has been revoked it can no longer be used in the BI, therefore, a new BI needs to be generated using PPK1.