Unauthorized Programming of PPK Digests:
AMD Xilinx recommends programming all public key digests prior to fielding a device, even when RSA/ECDSA authentication is not being used.
This is because an unprogrammed public key digest can create multiple security concerns, including the following:
Alternately, the PPK#_WR_LK eFUSEs can be programmed to prevent an adversary from programming their own PPK digest into the device.
Note: for Versal devices, programming the PPK will enable AHWRoT. When AHWRoT is used, XPPU can be used to protect unauthorized access to the eFUSE controller which will prevent unauthorized programming of unprogrammed PPK digests.
Unauthorized Programming of AES Keys:
A similar “ransom-ware” concern exists with the AES key and ENC_ONLY (Zynq UltraScale+) or SHWROT_EN (Versal) eFUSEs. In those cases, there is no write lock bit for the enable eFUSEs, but there is a WR_LK for the AES key. Xilinx recommends using AES_WR_LK to fix the key to a known value or using AHWRoT boot mode to prevent unauthorized access to the eFUSE controller.
Additional Resources:
XAPP1319: Programming BBRAM and eFUSEs contains details on how to program eFUSEs for Zynq UltraScale+ MPSoC devices.
XAPP1267: Using Encryption and Authentication to Secure an UltraScale/UltraScale+ FPGA Bitstream contains details on how to program eFUSEs for UltraScale and UltraScale + FPGAs.
XAPP1357: Asymmetric Hardware Root of Trust Secure Boot contains information on how to program eFUSEs and use Asymmetric Hardware Root of Trust Secure Boot for Versal ACAP devices.
AMD Xilinx recommends programming all public key digests prior to fielding a device, even when RSA/ECDSA authentication is not being used.
This is because an unprogrammed public key digest can create multiple security concerns, including the following:
- UltraScale/UltraScale+ FPGAs and Zynq UltraScale+ SoCs do not define an unprogrammed all-0 value as an illegal PPK digest. As a result, all users who use an all-0 value are sharing an unknown set of RSA or ECDSA keys. This is bad key management practice (albeit the key is unknown).
- An unprogrammed PPK allows adversaries to program the public key digest, allowing only the adversaries’ bitstreams and boot images to load, thus denying legitimate future use of the device or holding the device for ransom.
Alternately, the PPK#_WR_LK eFUSEs can be programmed to prevent an adversary from programming their own PPK digest into the device.
Note: for Versal devices, programming the PPK will enable AHWRoT. When AHWRoT is used, XPPU can be used to protect unauthorized access to the eFUSE controller which will prevent unauthorized programming of unprogrammed PPK digests.
Unauthorized Programming of AES Keys:
A similar “ransom-ware” concern exists with the AES key and ENC_ONLY (Zynq UltraScale+) or SHWROT_EN (Versal) eFUSEs. In those cases, there is no write lock bit for the enable eFUSEs, but there is a WR_LK for the AES key. Xilinx recommends using AES_WR_LK to fix the key to a known value or using AHWRoT boot mode to prevent unauthorized access to the eFUSE controller.
Additional Resources:
XAPP1319: Programming BBRAM and eFUSEs contains details on how to program eFUSEs for Zynq UltraScale+ MPSoC devices.
XAPP1267: Using Encryption and Authentication to Secure an UltraScale/UltraScale+ FPGA Bitstream contains details on how to program eFUSEs for UltraScale and UltraScale + FPGAs.
XAPP1357: Asymmetric Hardware Root of Trust Secure Boot contains information on how to program eFUSEs and use Asymmetric Hardware Root of Trust Secure Boot for Versal ACAP devices.