The operational environment of a cryptographic module is defined as the management of the software, firmware, and hardware required for the module to operate. Most of the FIPS 140-2 requirements for operating systems are also in FIPS 140-3. At all security levels, the OS should provide complete process separation to the module to prevent any unauthorized access to the module's SSPs. At SL2, to protect the module's SSPs, the OS should also implement either role-based access controls or, at a minimum, a robust mechanism for defining new groups and assigning restrictive permissions. The authentication mechanisms of the OS should meet the requirements outlined in Roles, Services, and Authentication. In addition, the module, with the help of the OS, should provide an auditing mechanism for capturing and recording events that can potentially expose data the module manages. Other than how requirements are organized in this clause, the most noteworthy change in FIPS 140-3 is that the requirement for validation of the OS to CC EAL2 or higher has been removed.
The Zynq UltraScale+ MPSoC has built-in hardware mechanisms that limit unauthorized access to the device’s eFUSE- and BBRAM-stored cryptographic keys. Furthermore, it supports the secure installation of software by implementing in hardware FIPS-approved algorithms for image confidentiality, integrity, and authentication (see requirements in Software/Firmware Security). However, the Arm-based PS system of the Zynq UltraScale+ MPSoC protects the OS during execution by enforcing hardware-based isolation with security mechanisms that are built into the CPU (e.g., XPPU, XMPU, SMMU combined with the Arm TrustZone security, memory protection unit (MPU), secure virtualization, etc.) At the OS/application layer, mechanisms must be implemented to use the device's security facilities to restrict access to the module's SSPs and to provide support for auditing system events.