The following table summarizes eleven sections of FIPS 140-3 requirements and provides a high-level explanation of using the Zynq UltraScale+ MPSoC with iDirect Government SEE and IP can satisfy each requirement. The iDirect Government’s FIPS 140-3 cryptographic module provides a FIPS 140-3 Level 3 solution by leveraging a proven cryptographic application and using the physical isolation and physical security features of the Zynq UltraScale+ MPSoC.
Refer to the Zynq UltraScale+ MPSoC: A FIPS 140-3 Primer (WP543) for more detailed explanation of each requirement and how a Zynq UltraScale+ MPSoC system can be leveraged to resolve each requirement.
| FIPS 140-3 Requirement | Description | iDirect Government Solution |
|---|---|---|
| Cryptographic module specification | A clear border is defined between software, hardware, firmware, hybrid software, and hybrid firmware. | The SEE defined by iDirect Government has a well-defined border between the secure RPU/PL environment and the unsecure APU/PL environment. Leveraging the Zynq UltraScale+ MPSoC XMPU/XPPU and proprietary iDirect Government cryptographic software. |
| Cryptographic module interfaces | Five logical interfaces exist between the cryptographic module and the unsecure world: data input, data output, control input, control output, and status output. | Leveraging iDirect Government’s SEE, previously certified cryptographic software and Zynq UltraScale+ MPSoC isolation features, these five interfaces can be logically separated and maintained during all levels of operation as defined in the FIPS 140-3 standard. |
| Roles, services, and authentication | The cryptographic module should be able to support distinct roles for its operators and corresponding cryptographic services. | iDirect Government’s cryptographic software supports three roles and services: secure, limited, and factory mode. Each operating role provides a range of none, limited, or full access to cryptographic services. |
| Software/firmware security | A cryptographic module shall implement an authenticated chain of trust and ensure authenticity of its cryptographic services via runtime tests. | Leveraging the authenticated boot feature of the Zynq UltraScale+ MPSoC, the iDirect Government’s cryptographic software can be authenticated from boot ROM to execution. The SEE messaging interface is authenticated and cryptographic services are continuously monitored to ensure authenticity. |
| Operational environment | The operational environment of a cryptographic module must be authenticated and access to its sensitive security parameters (SSPs) must be ensured. | The Zynq UltraScale+ MPSoC authenticated boot ensures authenticity through execution of the cryptographic software. iDirect Government’s secure messaging interface ensures that only authorized users can access cryptographic services after they have been validated. |
| Physical security | The cryptographic module must employ mechanisms to ensure authenticated access to SSPs within the cryptographic boundary. | iDirect Government’s secure messaging interface is authenticated by a username and password with each message being authenticated during transit. Each device image is signed and authenticated before being configured. After configuration the cryptographic algorithms in firmware and software are validated using FIPS accepted KAT tests. |
| Non-invasive security | FIPS 140-3 introduces a new section to mitigate against attacks that do not require physical access such as single/differential power analysis (SPA/DPA). | AMD publishes guidelines on AES key rolling to mitigate simple/differential power analysis (SPA/DPA) vulnerabilities. iDirect Government’s cryptographic software and firmware implements similar mitigations to limit the effectiveness of SPA/DPA attacks. |
| Sensitive security parameter management | 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). | iDirect Government’s previously certified cryptographic software already implements an approved key management schema, over-the-air key distribution protocol and AES-256 engine. iDirect Government’s cryptographic software also implements an approved DBRNG and TRNG source to ensure that the SEE has access to sufficient entropy for key generation. |
| Self-tests | The cryptographic module runs pre-operational and conditional tests by itself, requiring no external intervention to assure the operator that it is performing as expected. |
iDirect Government’s cryptographic software executes pre-operational KATs on boot before becoming fully operational. The tests can also be executed on request via the secure messaging interface. It is with the already defined authentication and integrity checks performed on the software executables and programmable logic images. |
| Life-cycle assurance | Life-cycle assurance ensures that the cryptographic module is properly designed, developed, tested, configured, delivered, installed, disposed, and documented by the vendor. | Using the best-in-class processes and procedures implemented by AMD during Zynq UltraScale+ MPSoC manufacturing, test, and distribution, iDirect Government provides extensive documentation to both the certifying body as well as end customers to support and maintain the product line. |
| Mitigation of other attacks | This section captures attacks and types of mitigation that are not defined elsewhere in the standard. It does not provide testable requirements and or metrics for evaluation. Security levels 1, 2, and 3 require that the list of attack(s) the cryptographic module is designed to mitigate should be included in the module's supporting documents to be evaluated when requirements and associated tests are developed. | Additional security functions can be implemented in the processing system or PL to mitigate attacks that are not currently covered by the standard. iDirect Government’s cryptographic software employs a variety of additional protections to ensure the integrity of customer data. Additional PL features can also be implemented to ensure authenticity of the bitstream as well as runtime PL configuration memory fault detection. |