FIPS 140-3 introduces this new section of requirements by grouping all the software/firmware requirements for integrity and loading of tests that are in FIPS 140-2. The section also introduces a few new requirements and allowances. At all security levels, integrity tests should be applied to a software/firmware module either by the module itself or by another validated and approved module. The tests should be able to be triggered using only interfaces specified in the standard, and all temporary values generated during a test should be zeroized upon completion of the test. Error correction codes (at minimum 16-bit in length) are still acceptable but only at SL1 and only for software/firmware components within a hardware module or within a disjoint hardware component of a hybrid module. For software/firmware modules at SL1, the only acceptable integrity methods are based on either message authentication codes (MACs) or digital signatures. At SL2, using hash-based MACs (HMACs) or digital signatures is mandatory for integrity. However, at SL3 and 4, only digital signatures are allowed. The clause also requires that the modules should contain only binaries and should be able to disable any debug interfaces allowing the inspection of the code.
The Zynq UltraScale+ MPSoC supports the secure boot of the SoC by providing confidentiality, integrity, and authentication of the PS/PL images using FIPS-approved cryptographic algorithms. The hardware rooted chain of trust starts with the device power-up when the metal-masked PMU/CSU boot ROM code is about to be executed. Since the boot ROM code is immutable with an adequate lifetime per FIPS 140-3 implementation guidelines, it does not need an integrity check. Nevertheless, the boot ROM code is hashed using the CSU's hardened SHA-3 engine, and the resulting checksum is checked against the golden copy that is also stored on the device. If the cryptographic checksums match, the CSU starts executing the part of its boot ROM code that authenticates the FSBL bootloader using RSA asymmetric digital signatures with SHA-3 hashing, which also verifies the integrity of the bootloader. The CSU also includes an RSA multiplier to accelerate public/private key operations. To provide confidentiality, the operator can encrypt the FSBL using the AES algorithm. In this case, the CSU uses the AES engine to decrypt it. Next, the FSBL takes over to boot other parts of the SoC, either in the PS or PL, and it is up to the operator to properly utilize the device's security facilities to maintain the chain of trust up to the application layer. The SoC also provides support for symmetric authentication that is based on the AES-GCM algorithm. The JTAG interface is the centerpiece of the debug features the Zynq UltraScale+ MPSoC provides for PS/PL development. By default, the JTAG port initially starts out disabled and is only enabled if a non-secure boot mode is detected or post secure boot by authenticated software. The device also provides an eFUSE that the operator can program to permanently disable the JTAG interface.