This section addresses random bit generators (RBGs) and SSP management that encompasses the entire lifecycle of SSPs (e.g., SSP generation, SSP establishment, SSP entry/output, SSP storage, and SSP zeroization). SSPs consist of CSPs (e.g., secret and private keys, passwords, RBG state information, etc.) and public security parameters (PSPs) that are explicitly defined for the first time in FIPS 140-3 to also address public keys, public-key certificates, etc. Unlike CSPs whose confidentiality and integrity should be ensured, for PSPs, there are only integrity-related requirements in this clause. SSPs can be entered into or output from the cryptographic module either electronically/automatically (e.g., via a smart card/tokens, PC card, etc.) or directly/manually (e.g., entered via a keyboard or output via a visual display). Manual entry/output of SSPs should be through interfaces specified in the standard and SSPs that are entered unencrypted into the module can be temporarily displayed to allow for visual verification. At SLs 1 and 2, the input or output of CSPs, key components, and authentication data can be in either encrypted or plaintext form, provided they are maintained within the operational environment and meet the operational environment requirements. At SL3, CSPs that enter or leave the cryptographic module should either be encrypted or use trusted channels (see Cryptographic Module Interfaces). SL4 requires that the module should also use multi-factor separate identity-based operator authentication for entering or outputting key components. At all security levels, unprotected SSPs stored in plaintext form should be zeroizable. SL4 also extends this requirement to encrypted SSPs. At SL1, the zeroization of plaintext SSPs can be performed procedurally by the operator of the module. At SLs 2 and 3, the module by itself should zeroize plaintext SSPs when they are no longer needed. Furthermore, at SL4, the zeroization of SSPs should be non-interruptible and occur in a sufficiently small time period to prevent their recovery.
The (CSP) AES decryption key (see Software/Firmware Security) is stored in plaintext (red) form on the device in either the BBRAM or non-volatile eFUSEs during the provisioning of the device (i.e., prior to field deployment). The red key is transferred via a write-only path to the BBRAM/eFUSEs upon which a key integrity check is performed. Both BBRAM and eFUSEs do not provide a physical readback path for the red key, whereas the key is only usable by the AES-GCM engine during secure boot. To further guard the red key, the operator can use the PUF, available in the Zynq UltraScale+ MPSoC, to generate a die-unique KEK and use it to AES-encrypt the red key. The PUF-encrypted red key (or now, black key) can be stored in the on-chip eFUSEs. The red keys stored in BBRAM can be zeroized. The eFUSE-stored keys cannot be zeroized because they are one-time programmable (OTP). Registers holding the red key are immediately zeroized after they are used to decrypt the first block of an image. The AES keys that are required to decrypt the remaining blocks of the image are provided with the image (see the key rolling technique discussed in Non-invasive Security). For the PSPs, the RSA public/private key pair that is used during secure boot for the asymmetric authentication of an image is created off the device by the operator. Secure boot requires only the public key (which has no value to an adversary) to be on the device. Due to limited space, the public key is hashed using SHA-3 and stored in on-chip eFUSEs while the full public key is provided with the image. During secure boot, the device rehashes the provided public key and compares the resulting hash with the hash value stored in eFUSEs to verify its integrity. The Zynq UltraScale+ MPSoC can accommodate two 384-bit hashes of primary public keys (PPKs), which are write-protected and can be individually revoked in case of a tamper event. To limit the use of the two PPKs, the PPKs are only used to authenticate secondary public keys (SPKs) and the SPKs, in turn, to authenticate the image. SPKs are also provided with the image and the operator is responsible for creating them along with their private counterparts. Zynq UltraScale+ MPSoCs support up to 32 SPKs and they can also be revoked upon a tamper event.
The Zynq UltraScale+ MPSoC does not have a built-in RBG in silicon to create application layer session keys. However, an RBG can be implemented in the PL to create keys within the device. For loading external application layer session keys, the interface port is user-defined and can be a plaintext (red) or ciphertext (black) key load depending on the implementation. Also, a hardware security module (HSM) IP that provides secure key management and additional cryptographic processing to the Zynq UltraScale+ MPSoC is available from Secure-IC [REF 15] (an AMD partner).