The cryptographic module should be able to support distinct roles for its operators and the corresponding services the latter can access. In particular, the module should support at a minimum a crypto officer role and, optionally, a user role and a maintenance role. In FIPS 140-2, only the maintenance role is optional. There are no authentication requirements for SL1 modules. At SLs 2 and 3, the module should employ role-based authentication and identity-based authentication, respectively. At SL4, the clause adds an additional layer of security by requesting the modules to employ multi-factor identity-based authentication. Also, the module should expose the following services to operators:
- Module version and status
- Security functions
- Zeroization
- Self-test
FIPS 140-3 also introduces requirements for module self-initiated security functions that require no operator intervention at runtime. The requirements of this clause also cover the secure loading of software/firmware from an external source to the module.
Bootgen (see Bootgen User Guide (UG1283)), the AMD image generation tool, supports a variation on the split knowledge referenced in FIPS 140-3. For example, the encryption and authentication can be done on different servers by different operators by using Bootgen in the hardware security monitor (HSM) mode. The Zynq UltraScale+ MPSoC provides RSA asymmetric authentication, starting with the FSBL and including all partitions loaded into the embedded system. Bootgen supports a user-defined field (UDF) in the authentication certificate for identity authentication on the partitions loaded. If the UDF is used, the user must modify the FSBL to implement the identity check. Also, authenticated application code residing on the PS can implement role-based/user-based authentication schemes. Runtime device health checks, tamper response involving auto-triggered SSPs zeroization, and SoC lockdown are also part of the self-initiated security functions the Zynq UltraScale+ MPSoC provides to the operator.