Table 5 - Summary of FIPS 140-3 Security Requirements

Improvement of TE Filtering Coverage

TE filters serve as a pivotal mechanism to streamline the classification and evaluation of TE, ensuring that only relevant and applicable tests are conducted based on specific module characteristics. A proper set of applicable TEs tailored by a given module specification refines the required assessments and optimizes the validation process.

With the growing complexity of cryptographic modules and the need for efficient validation, TE filters are designed to:

• Target specific needs through focusing on applicable tests by narrowing down evidence requirements based on module attributes such as type, security level, and operational environment

• Reduce redundancy through minimizing repetitive validation steps by filtering out TEs that are not relevant to a given module’s configuration or features

• Enhance automation through supporting automated workflows by integrating filters into structured JSON schemas, aligning with automation tools like WebCryptik

This document delves into the methodologies and criteria for applying TE filters, the implementation of filtering mechanisms, and their role in achieving a more efficient and scalable CMVP. By leveraging these filters, vendors and validators can focus on precise compliance requirements, reducing manual overhead while maintaining robust security standards.

Table 5 is excerpted from ISO/IEC 19790:2012, which is the base of FIPS 140-3. It provides a structured summary of the FIPS 140-3 security requirements across various requirement areas. It outlines the security levels applicable to each category, specifying the testing expectations and security assurances needed to meet compliance. The table serves as a reference for understanding how different cryptographic module components must align with FIPS 140-3 standards, ensuring consistent evaluation and validation. Each requirement area focuses on distinct security aspects, such as module specifications, authentication mechanisms, physical security, and lifecycle assurance, enabling a comprehensive approach to cryptographic module validation.

Table 5 - Summary of FIPS 140-3 Security Requirements

Requirement Area		FIPS 140-3 Security Level
		1	2	3	4
1	General	No security testing requirements (i.e., no TEs)
2	Cryptographic Module Specification	Specification of cryptographic module, cryptographic boundary, approved security functions, and normal and degraded modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. All services provide status information to indicate when the service utilizes an approved cryptographic algorithm, security function, or process in an approved manner.
3	Cryptographic Module Interfaces	Required and optional interfaces. Specification of all interfaces and of all input and output data paths		Trusted channel
4	Roles, Services, and Authentication	Logical separation of required and optional roles and services	Role-based or identity-based operator authentication	Identity-based operator authentication	Multi-factor authentication
5	Software / Firmware Security	Approved integrity technique. Defined SFMI, HFMI, and HSMI. Executable code	Approved digital signature or keyed message authentication code-based integrity test	Approved digital signature-based integrity test
6	Operational Environment	Non-modifiable. Limited or Modifiable Control of SSPs	Modifiable. Role-based or discretionary access control. Audit mechanism
7	Physical Security	Production-grade components	Tamper evidence. Opaque covering or enclosure	Tamper detection and response for covers and doors. Strong enclosure or coating. Protection from direct probing EFP or EFT	Tamper detection and response envelope. EFP. Fault injection mitigation
8	Non-Invasive Security	Module is designed to mitigate against non-invasive attacks specified in Annex “F”
		Documentation and effectiveness of mitigation techniques specified in Annex “F”		Mitigation testing	Mitigation testing
9	Security Parameter Management	Random bit generators, SSP generation, establishment, entry & output, storage & zeroization
		Automated SSP transport or SSP agreement using approved methods
		Manually established SSPs may be entered or output in plaintext form		Manually established SSPs may be entered or output in either encrypted form, via a trusted channel, or using split knowledge procedures
10	Self-Tests	Pre-operational: software/firmware integrity, bypass, and critical functions test
		Conditional: cryptographic algorithm, pair-wise consistency, SW/FW loading, manual entry, conditional bypass & critical functions test
11	Life-Cycle Assurance
	Configuration Management	Configuration management system for cryptographic module, components, and documentation. Each is uniquely identified and tracked throughout its lifecycle		Automated configuration management system
	Design	Module designed to allow testing of all provided security-related services
	FSM	Finite State Model
	Development	Annotated source code, schematics, or HDL	Software high-level language and hardware high-level descriptive language		Documentation annotated with pre-conditions upon entry into module components and postconditions expected to be true when components is completed
	Testing	Functional testing		Low-level testing
	Delivery & Operation	Initialization procedures	Delivery procedures		Operator authentication using vendor-provided authentication information
	Guidance	Administrator and non-administrator guidance
12	Mitigation of Other Attacks	Specification of mitigation of attacks for which no testable requirements are currently available			Specification of mitigation of attacks with testable requirements

Building on the summary of FIPS 140-3 security requirements in Table 5, Table 6 provides a more granular analysis of the number of security requirements per ISO/IEC 24759:2014(2015), which is a companion document to ISO/IEC 19790 specifying the derived test requirements, across different implementation areas. This table categorizes security requirements based on the module’s type being Software (SW), Firmware (FW), Hardware (HW), SW-HW hybrid (SW-H), or FW-HW hybrid (FW-H), and further differentiates them by security levels. The breakdown facilitates a clearer understanding of the distribution of TE requirements, highlighting how various module implementations align with compliance expectations at each level.

The number of total TEs and the percentage of applicable TEs will indicate how many TEs are not applicable. By filtering out these non-applicable TEs with public consensus, the CSTL can more directly perform the required testing.