The PUF takes advantage of silicon variations unique to Zynq UltraScale+ devices to generate a device-unique encryption key that cannot be read by anyone, including the user. Along with generating a unique encryption key, the PUF also generates the required helper data so that the PUF can exactly regenerate the encryption key later. The details of the PUF are described in the Zynq UltraScale+ MPSoC: Technical Reference Manual (UG1085) [Ref 2] . Normally, the PUF’s encryption key, referred to as the Key Encryption Key (KEK), is used for encrypting a user’s plain-text red key so that a user’s red key can be stored encrypted in black key form in either eFUSES or the boot header. The black encryption key is then decrypted using the PUF’s KEK to generate the red key, which in turn is used for decrypting the boot information during secure boot. This use of the PUF is shown in the following figure.
IMPORTANT: The PUF characterization results confirm that over the life of the device, the PUF is expected to reliably regenerate the KEK across all voltages and temperatures assuming registration at a nominal voltage and temperature .
IMPORTANT: The RSA_EN eFUSE must be programmed in order to use the PUF’s device-unique encryption key to encrypt and decrypt user data. Once this is programmed, Boot Header based authentication (bh_auth_enable) can no longer be used.
When the PUF is registered in eFUSEs and RSA authentication is enabled in eFUSEs, documented in Programming BBRAM and eFUSEs (XAPP1319) [Ref 3] , the PUF’s device-unique encryption key can be used to encrypt and decrypt any user data. This encrypted data can then be stored externally to the Zynq UltraScale+ device, which is the focus of this application note. The RSA authentication settings cannot be stored in the boot header when using the PUF to encrypt and decrypt user data.
IMPORTANT: When the RSA_ENABLE eFUSEs are programmed, boot header authentication is no longer permitted.
The process of using the PUF to encrypt user data is shown in This Figure and works as follows: a user generates data that must be encrypted and appends an optional ID. This optional ID can be used to validate that the correct version of data that is being used, such as when the data consists of encryption key information or configuration and is useful in preventing replay attacks. Even though the ID is optional, Xilinx highly recommends using it to ensure a more secure system. The optional ID enables key/data revocation as the user data packet can be revoked by burning one of the 256-bit user eFUSEs. Each of the 256-bit user eFUSEs can be mapped to 256 different 8-bit user IDs. Keep in mind that user eFUSEs are a shared resource as the fuses could be used for Enhanced Key Revocation software, a tamper log (see Developing Tamper-Resistant Designs with Zynq UltraScale+ Devices (XAPP1323) [Ref 4] , or any other user function.
Next, the PUF is enabled to regenerate the PUF’s device-unique encryption key, which is loaded into the AES cryptographic core to encrypt the data. Xilinx recommends minimizing the use of the PUF’s key by keeping the user data small or implementing an advanced key-rolling architecture where the PUF’s device-unique key is only used to encrypt the first portion of a larger sized data, thereby minimizing its exposure. This helps to avoid differential power analysis (DPA) attacks. After the encrypted data is written to external memory, the data is read back and decrypted to verify the process using the GCM authentication tag. If the data is authenticated, the user selected ID is safe to use. Conversely, if the data verification fails, a revocation penalty can take place, such as burning an associated user eFUSE.
Decrypting external data using the PUF is shown in This Figure and works as follows: the encrypted data packet is read from the external memory location followed by regeneration of the PUF decryption key. The data is then decrypted and authenticated via the GCM tag. If authentication passes and if the ID from the decrypted data has not been revoked in user eFUSEs, then the data is valid and can be used. Conversely, if the GCM tag authentication fails, then a penalty can be invoked and the decryption process could be stopped to avoid side channel attacks such as DPA. Furthermore, if the decryption process authenticates but the data’s ID has been revoked in user eFUSEs, the data is invalid and should not be used.
IMPORTANT: The PUF KEK isn’t a FIPS legal key for storing data outside a cryptographic boundary. However, you can create a FIPS-legal KEK, encrypt the FIPS-legal KEK with the PUF KEK, store the encrypted FIPS-legal KEK in eFUSEs, and subsequently use the FIPS-legal KEK to store data outside the cryptographic boundary.
