The Versal adaptive SoC contains a physically unclonable function (PUF). The PUF creates a signature (or fingerprint) of each device that is unique to that device. The KEK can only be directly fed into the AES-GCM engine and cannot be read out of the device.
The KEK is 256 bits in length with 256 bits of entropy and is used to encrypt the users red key allowing its storage in black (encrypted) form. The black key can be stored in either eFUSEs, BBRAM, or external storage.
Enhanced from the previous generation, the Versal device's PUF also outputs a user accessible unique ID that is cryptographically isolated from the PUF KEK despite using the same entropy source. While unique to each device, it is not considered a “secret” and does not have the same access protections as the KEK.
The silicon manufacturing process includes inherent, random, and uncontrollable variations that cause unique and different characteristics from device to device. The AMD devices operate within these variations and device functionality is not affected. PUF includes tiny circuits that exploit these chip-unique process variations to generate unique keys. The type of PUF used to generate the KEK is also an important consideration. The Versal device's PUF uses an asymmetric technology that is different from the device key storage technology (for example, SRAM or eFUSE). This asymmetric technology increases the security level above what can be achieved with a single technology.
The PUF uses approximately 4 Kb of helper data to help the PUF recreate the original KEK value over the guaranteed operating temperature and voltage range over the life of the part. The helper data consists of a syndrome, aux, and chash value. The helper data can either be stored in eFUSEs or in the boot image. The following table lists the PUF helper data.
| Field | Size (Bits) | Description |
|---|---|---|
| Syndrome | 4060 | These bits aid the PUF in recovering the proper PUF signature given slight variations in the ring oscillators over temperature, voltage, and time |
| Aux | 24 | This is a Hamming code that allows the PUF to perform some level of error correction on the PUF signature |
| Chash | 32 | This is a hash of the PUF signature that allows the PUF to recognize if the regenerated signature is correct |
Access to the PUF is restricted by the RCU. The PUF can be controlled through the RCU registers.
The PUF undergoes a registration process when a new KEK needs to be created. The registration process initializes the PUF so that a KEK is created, and the following options are available.
- The registration software can then use the KEK to encrypt the user key and program the eFUSEs.
- The encrypted user key can be output for inclusion into a boot image. The registration software also programs the helper data into the eFUSEs.
- The helper data can be output for inclusion into a boot image.
For secure boot, the helper data and the encrypted user key must be stored in the same location (that is, both in eFUSE or both in the boot image). When the device powers on, the RCU examines the boot image header (the boot image header is authenticated when authentication is enabled). The boot image header contains information on whether the PUF is used, where the encrypted key is stored (eFUSE or boot image), and where the helper data is stored (eFUSE or boot image). The RCU then initializes the PUF, loads the helper data, and regenerates the KEK. This process is called regeneration. After the KEK is regenerated, the RCU can use it to decrypt the user key, which is then used to decrypt the rest of the boot image.
The PUF is only supported when using a nominal VCC_PMC of 0.70V. See the Versal Adaptive SoC Security Manual (UG1508) in the Security Lounge for detailed information on PUF usage.