FIPS 140-3 IG.pdf

Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Canadian Centre for Cyber Security Initial Release: September 21, 2020 Last Update: August 30, 2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Table of Contents OVERVIEW....................................................................................................................................................... 5 SECTION 1 – GENERAL................................................................................................................................. 6 1.A BINDING AND EMBEDDING CRYPTOGRAPHIC MODULES............................................................................. 6 SECTION 2 – CRYPTOGRAPHIC MODULE SPECIFICATION............................................................ 11 2.3.A BINDING OF CRYPTOGRAPHIC ALGORITHM VALIDATION CERTIFICATES............................................... 11 2.3.B SUB-CHIP CRYPTOGRAPHIC SUBSYSTEMS............................................................................................. 13 2.3.C PROCESSOR ALGORITHM ACCELERATORS (PAA) AND PROCESSOR ALGORITHM IMPLEMENTATION (PAI)........................................................................................................................................................................ 16 2.3.D EXCLUDED COMPONENTS...................................................................................................................... 20 2.4.A DEFINITION AND USE OF A NON-APPROVED SECURITY FUNCTION........................................................ 22 2.4.B TRACKING THE COMPONENT VALIDATION LIST.................................................................................... 27 2.4.C APPROVED SECURITY SERVICE INDICATOR........................................................................................... 33 SECTION 3 – CRYPTOGRAPHIC MODULE INTERFACES.................................................................. 38 3.4.A TRUSTED CHANNEL............................................................................................................................... 38 SECTION 4 – ROLES, SERVICES, AND AUTHENTICATION............................................................... 41 4.1.A AUTHORISED ROLES.............................................................................................................................. 41 4.4.A MULTI-OPERATOR AUTHENTICATION................................................................................................... 44 SECTION 5 – SOFTWARE/FIRMWARE SECURITY............................................................................... 46 5.A NON-RECONFIGURABLE MEMORY INTEGRITY TEST................................................................................. 46 SECTION 6 – OPERATIONAL ENVIRONMENT...................................................................................... 47 SECTION 7 – PHYSICAL SECURITY......................................................................................................... 48 7.3.A TESTING TAMPER EVIDENT SEALS........................................................................................................ 48 7.3.B HARD COATING TEST METHODS (LEVEL 3 AND 4)................................................................................ 49 SECTION 8 – NON-INVASIVE SECURITY................................................................................................ 51 SECTION 9 – SENSITIVE SECURITY PARAMETER MANAGEMENT............................................... 52 9.3.A ENTROPY CAVEATS............................................................................................................................... 52 9.5.A SSP ESTABLISHMENT AND SSP ENTRY AND OUTPUT............................................................................ 58 9.6.A ACCEPTABLE ALGORITHMS FOR PROTECTING STORED SSPS................................................................ 66 9.7.A ZEROISATION OF ONE TIME PROGRAMMABLE (OTP) MEMORY............................................................ 68 9.7.B INDICATOR OF ZEROISATION.................................................................................................................. 70 SECTION 10 – SELF-TESTS......................................................................................................................... 73 10.2.A PRE-OPERATIONAL INTEGRITY TECHNIQUE SELF-TEST....................................................................... 73 10.3.A CRYPTOGRAPHIC ALGORITHM SELF-TEST REQUIREMENTS................................................................. 75 10.3.B SELF-TEST FOR EMBEDDED CRYPTOGRAPHIC ALGORITHMS................................................................ 89 10.3.C CONDITIONAL MANUAL ENTRY SELF-TEST REQUIREMENTS............................................................... 90 10.3.D ERROR LOGGING................................................................................................................................. 91 CMVP 2 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 10.3.E PERIODIC SELF-TESTING...................................................................................................................... 93 10.3.F COMPLETE IMAGE REPLACEMENT VERSUS SOFTWARE/FIRMWARE LOADING..................................... 96 SECTION 11 – LIFE-CYCLE ASSURANCE............................................................................................. 100 11.A CVE MANAGEMENT............................................................................................................................. 100 SECTION 12 – MITIGATION OF OTHER ATTACKS........................................................................... 103 12.A MITIGATION OF OTHER ATTACKS......................................................................................................... 103 ANNEX A – DOCUMENTATION REQUIREMENTS.............................................................................. 104 ANNEX B – CRYPTOGRAPHIC MODULE SECURITY POLICY........................................................ 105 ANNEX C – APPROVED SECURITY FUNCTIONS................................................................................ 106 C.A USE OF NON-APPROVED ELLIPTIC CURVES............................................................................................ 106 C.B VALIDATION TESTING OF HASH ALGORITHMS AND HIGHER CRYPTOGRAPHIC ALGORITHM USING HASH ALGORITHMS................................................................................................................................................ 108 C.C THE USE AND THE TESTING REQUIREMENTS FOR THE FAMILY OF FUNCTIONS DEFINED IN FIPS 202..... 109 C.D USE OF A TRUNCATED HMAC............................................................................................................... 111 C.E KEY GENERATION FOR RSA SIGNATURE ALGORITHM........................................................................... 112 C.F RSA APPROVED PARAMETER SIZES IN FIPS 186-5................................................................................ 113 C.G SP 800-67REV2 LIMIT ON THE NUMBER OF ENCRYPTIONS WITH THE SAME TRIPLE-DES KEY.............. 116 C.H KEY/IV PAIR UNIQUENESS REQUIREMENTS FROM SP 800-38D............................................................. 118 C.I XTS-AES (SP 800-38E) REQUIREMENTS ON THE KEY........................................................................... 126 C.J REQUIREMENTS FOR TESTING TO SP 800-38G........................................................................................ 127 C.K TRANSITION FROM FIPS 186-4 TO FIPS 186-5 AND SP 800-186............................................................ 128 C.L SP 800-107 REQUIREMENTS................................................................................................................... 131 C.M LEGACY ALGORITHMS.......................................................................................................................... 133 C.N REQUIREMENTS FOR SP 800-208 SCHEMES............................................................................................ 136 ANNEX D – APPROVED SENSITIVE SECURITY PARAMETER GENERATION AND ESTABLISHMENT METHODS.................................................................................................................. 141 D.A ACCEPTABLE SSP ESTABLISHMENT PROTOCOLS................................................................................... 141 D.B STRENGTH OF SSP ESTABLISHMENT METHODS..................................................................................... 143 D.C REFERENCES TO THE SUPPORT OF INDUSTRY PROTOCOLS..................................................................... 147 D.D ELLIPTIC CURVES AND THE FFC SAFE-PRIME GROUPS IN SUPPORT OF INDUSTRY PROTOCOLS............ 149 D.E MOVED TO W.1...................................................................................................................................... 151 D.F KEY AGREEMENT METHODS.................................................................................................................. 152 D.G KEY TRANSPORT METHODS................................................................................................................... 156 D.H REQUIREMENTS FOR VENDOR AFFIRMATION TO SP 800-133................................................................ 160 D.I THE USE OF POST-PROCESSING IN KEY GENERATION METHODS............................................................ 162 D.J ENTROPY ESTIMATION AND COMPLIANCE WITH SP 800-90B................................................................. 165 D.K INTERPRETATION OF SP 800-90B REQUIREMENTS................................................................................ 168 CMVP 3 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology D.L CRITICAL SECURITY PARAMETERS FOR THE SP 800-90A DRBGS......................................................... 175 D.M USING THE SP 800-108 KDFS IN AN APPROVED MODE........................................................................ 177 D.N SP 800-132 PASSWORD-BASED KEY DERIVATION FOR STORAGE APPLICATIONS.................................. 178 D.O COMBINING ENTROPY FROM MULTIPLE SOURCES................................................................................. 180 D.P SP 800-56CREV2 ONE-STEP KEY DERIVATION FUNCTION WITHOUT A COUNTER................................. 182 D.Q TRANSITION OF THE TLS 1.2 KDF TO SUPPORT THE EXTENDED MASTER SECRET................................ 184 D.R MOVED TO W.2...................................................................................................................................... 186 ANNEX E – APPROVED AUTHENTICATION MECHANISMS........................................................... 187 E.A APPLICABILITY OF REQUIREMENTS FROM SP 800-63B.......................................................................... 187 ANNEX F – APPROVED NON-INVASIVE ATTACK MITIGATION TEST METRICS..................... 189 WITHDRAWN GUIDANCE......................................................................................................................... 190 W.1 ASSURANCE OF THE VALIDITY OF A PUBLIC KEY FOR SSP ESTABLISHMENT......................................... 190 W.2 HASH FUNCTIONS ACCEPTABLE FOR USE IN THE SP 800-90A DRBGS................................................. 192 CHANGE SUMMARY.................................................................................................................................. 193 NEW GUIDANCE........................................................................................................................................... 193 MODIFIED GUIDANCE.................................................................................................................................. 193 MAPPING FIPS 140-2 IGS TO FIPS 140-3.................................................................................................. 198 END OF DOCUMENT.................................................................................................................................. 202 CMVP 4 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Overview This Implementation Guidance document is issued and maintained by the U.S. Government's National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS), which serve as the validation authorities of the Cryptographic Module Validation Program (CMVP) for their respective governments. The CMVP validates the test results of National Voluntary Laboratory Accreditation Program (NVLAP) accredited Cryptographic and Security Testing (CST) Laboratories which test cryptographic modules for conformance to Federal Information Processing Standard Publication (FIPS) 140-3, Security Requirements for Cryptographic Modules. The Cryptographic Algorithm Validation Program (CAVP) addresses the testing of Approved Security Functions and Approved Sensitive Security Parameter Generation and Establishment Methods which are referenced in the SP 800-140 series of FIPS 140-3. This document is intended to provide programmatic guidance of the CMVP, and in particular, clarifications and guidance pertaining to ISO/IEC 24759:2017(E), Test requirements for cryptographic modules, which are further clarified in FIPS PUB 140-3 Derived Test Requirements (DTR), which are used by CST Laboratories to test for a cryptographic module's conformance to FIPS 140-3. Guidance presented in this document is based on responses issued by NIST and CCCS to questions posed by the CST Labs, vendors, and other interested parties. Information in this document is subject to change by NIST and CCCS. Each section of this document corresponds with a requirements section of ISO/IEC 19790:2012 (corrections made in 2015). Within each section, the guidance is listed according to a subject phrase. For those subjects that may be applicable to multiple requirements areas, they are listed in the area that seems most appropriate. Under each subject there is a list, including the date of issue for that guidance, along relevant assertions, test requirements, and vendor requirements from the DTR. (Note: For each subject, there may be additional test and vendor requirements which apply.) Next, there is section containing a question or statement of a problem, along with a resolution and any additional comments with related information. This is the implementation guidance for the listed subject. Cryptographic modules validation listings can be found at: Cryptographic Module Validation Lists Cryptographic algorithm validation listings can be found at: Cryptographic Algorithm Validation Lists CMVP 5 08/30/2024 Section 1 – General 1.A Binding and Embedding Cryptographic Modules Applicable Levels: All Original Publishing Date: July 26, 2024 Effective Date: July 26, 2024 Last Modified Date: July 26, 2024 Relevant Assertions: Relevant Test Requirements: Relevant Vendor Requirements: Background ISO/IEC 19790:2012 and ISO/IEC 24759:2017 incorporate implicit or explicit references to bound or embedded scenarios, as shown with added underlines for readability in the following excerpts. [05.05] discussion of software/firmware integrity test: For software and firmware modules and the software or firmware component of a hybrid module (except for the software and firmware components within a disjoint hardware component of a hybrid module): - A cryptographic mechanism using an approved integrity technique shall [05.05] be applied to all software and firmware components within the module’s defined cryptographic boundary in one of the following ways: o by the cryptographic module itself; or o by another validated cryptographic module operating in an approved mode of operation. The above citation of [05.05] implicitly refers to a scenario where the module under test is bound to “another validated cryptographic module”. [05.13] discussion of software / firmware load test: If the software or firmware that is loaded is associated, bound, modifies, or is an executable requisite of the validated module, then the software/firmware load test is applicable and shall [05.13] be performed by the validated module with the following exceptions. - The cryptographic module is a software module and the loaded software image is a complete image replacement or overlay of the validated module. - The cryptographic module is a firmware module of physical Security Level 1 and the loaded firmware image is a complete image replacement or overlay of the validated module. - The cryptographic module is a hybrid software module and the loaded software image is a complete image replacement or overlay of the disjoint software components. - The cryptographic module is a hybrid firmware module of physical Security Level 1 and the loaded firmware image is a complete image replacement or overlay of the disjoint firmware components. Note underneath ISO/IEC 19790:2012 [02.18]: In addition to the disjoint software or firmware component(s), the hardware component can also include embedded software or firmware. ISO/IEC 19790:2012 Section 7.9.7 states: Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Except at security level 4, zeroisation of protected PSPs, encrypted CSPs, or CSPs otherwise physically or logically protected within an additional embedded validated module (meeting the requirements of this International Standard) is not required. The following items within the CMVP Caveats webpage relate to bound or embedded modules: When operated in approved mode with module [module name] validated to FIPS 140-3 under Cert. #xxxx operating in approved mode The module’s validation is bound to another validated cryptographic module. Example: A software cryptographic module which requires services from another validated software cryptographic module operating in the same operational environment. Application services are available from either module. This module contains the embedded module [module name] validated to FIPS 140-3 under Cert. #xxxx operating in approved mode If the module incorporates an embedded validated cryptographic module. Example 1: A software cryptographic module which is compiled with a privately linked validated software cryptographic module operating in the same operational environment. Application services are only available from the module indicated on the certificate. Example 2: A hardware cryptographic module which has embedded within its physical boundary a validated cryptographic module. Bound and embedded modules are also mentioned in the FIPS 140-3 IG articles specified below. In Table 1 of IG 9.5.A: o CM Hardware to/from EXT CM Hardware via directly connected EXT Path (e.g. CM bound to another CM): MD / EE o CM Software to/from CM Software via TOEPP Path (e.g. CM bound to another CM): MD / EE o CM Software to/from CM Software via INT Path (CM embedded within CM): N/A o CM Hardware to/from INT CM Hardware via INT Path (CM embedded within CM): N/A In IG D.J: Any new validation submission of a cryptographic module that obtains its entropy from a previously- validated embedded module shall comply with SP 800-90B. Question/Problem What is an embedded module? What is a bound module? What is required when the IUT relies on another validated cryptographic module? Can a module be bound to or embed a validated FIPS 140-2 module? Resolution 1. The binding/bound and embedding/embedded cases are to be defined in relation to the cryptographic module under validation, identified as the Implementation Under Test (IUT). The following diagrams illustrate the binding/bound and embedding/embedded scenarios, respectively. CMVP 7 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Throughout this IG, the term IUT refers to the module undergoing validation. The term EVM refers to the existing validated module. The primary benefit of this guidance is to be able to reuse an existing validated module to avoid repetitive testing and evaluation. Embedding: 2. An embedded cryptographic module (as shown in Figure 1) is a module that is wholly contained within the module boundary of an IUT and whose services are provided solely to the IUT. Example: A hardware cryptographic module, the IUT, with EVM (hardware, firmware, software, or hybrid) embedded within its physical boundary. Binding: 3. A binding cryptographic module (as shown in Figure 2) is a module with a separate, disjoint cryptographic boundary (IUT) that depends on an EVM. Application services are available from either cryptographic module. Example: A software cryptographic module (IUT) that requires services from a software EVM operating in the same operational environment (see Figure 2). The following shall apply to binding cases: a. In the case of software, firmware, and hybrid modules, the IUT and the EVM shall each operate on their tested operational environment(s) and those tested environments shall be the same (or one be within the other’s). b. If the IUT relies on the EVM to meet one or more FIPS 140-3 requirement (i.e., does not meet all FIPS 140-3 requirements on its own), then the IUT submission shall demonstrate in the Test Report how the relied upon FIPS requirement(s) is met without being non-compliant to any other FIPS 140-3 requirement, considering IUT and EVM boundaries are independent / disjoint. E.g., AS10.02 requires no external controls and no externally provided input test vectors ("external" to the module boundary), so the IUT may not be compliant to this requirement if it relied on the EVM for self-testing purposes. c. Per IG 9.5.A, SSPs moved or established between the binding IUT and bound EVM are subject to the ISO/IEC 19790:2012 section 7.9.5 Sensitive security parameter entry and output and section 7.9.4 Sensitive security parameter establishment respectively because they are moved or established across the modules' respective cryptographic boundaries. Embedding and Binding: 4. The following shall apply to both the embedding and binding cases: a. The EVM does not need to be (re)tested during the IUT validation. But the IUT, which utilizes the EVM, shall be fully tested. CMVP 8 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology b. For bound modules, the EVM shall be the same or higher security level as the IUT for all sections of the FIPS 140-3 standard, except for Mitigation of other attacks which can differ in security levels. This is to ensure the IUT provides the claimed security assurances despite utilizing the EVM to potentially meet certain FIPS 140-3 requirements and/or protect the IUT’s sensitive data. E.g., if the IUT is security level 2 in Roles, services, and authentication, but the EVM is only security level 1, the EVM would not require authentication for the service(s) relied on by the IUT, which means the associated SSPs could potentially be modified/disclosed by an unauthenticated operator prior to the IUT request. For embedded modules, the EVM can be a lower security level as the IUT for all sections of the FIPS 140-3 standard, but if this is the case, the lab/vendor shall either: 1) demonstrate the EVM already meets the higher security level requirement(s); or 2) demonstrate that the IUT is able to meet the higher-level requirement(s) on behalf of the EVM. c. The IUT shall inherit the Historical validation status if the EVM moves to the historical list for any reason (e.g., is sunset or an algorithm transition). The IUT could still become historical even if the EVM remains active if the IUT itself is subject to the historical list (e.g., an algorithm transition associated with an IUT algorithm). The vendors can revalidate their modules per FIPS 140-3 Management Manual Section 7.1. d. The EVM status shall be Active (i.e., is not on the Historical or Revoked list) at the time of the IUT submission to the CMVP. If the EVM becomes historical during IUT validation, the IUT will become historical once validation is completed. e. To claim an EVM’s implementation as an approved service / algorithm within the IUT documentation, the IUT shall only use EVM services / algorithms that are approved at the time of the IUT submission to the CMVP, even if the EVM implements algorithms in the approved mode that are no longer approved. E.g., the EVM may implement the transitioned FIPS 186-4 DSA SigGen algorithm but still be on the Active list since the FIPS 186-4 transition did not move the EVM to the historical list. The IUT could not claim the EVM’s implemented DSA SigGen is approved if the IUT was submitted after the FIPS 186-4 transition. f. A FIPS 140-3 IUT cannot embed or bind to a FIPS 140-2 EVM. Documentation Requirements: 5. The FIPS 140-3 IUT submission (e.g., Security Policy and validation test report) shall precisely identify the EVM by name, CMVP certificate number and version(s). The FIPS 140-3 Security Policy and validation test report for the IUT shall represent the functionality within its boundary with clear distinctions between IUT information and information associated with the EVM (e.g., clear separation of services, algorithms, SSPs, self-tests, zeroisation mechanisms, etc.). In some cases, the IUT might use only a subset of functionality provided by the EVM. The Security Policy and validation test report shall only cite the EVM functionality that is used by the IUT. This shall be done per below by marking “[EVM]” to the start of each applicable reference within the following WebCyptik tables (e.g., “[EVM] Perform Self-Tests” if the IUT calls the EVM’s “Perform Self-Test” service): CAVP Certs Table Column to mark EVM Marking Algorithms Category [EVM] CMVP 9 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology MIS Table Column to mark EVM Marking Table 6. Vendor Affirmed Algorithms Algorithm Properties [EVM] Table 7. Non-Approved, Allowed Algorithms Algorithm Capabilities [EVM] Table 8. Non-Approved Allowed Algorithms Use/Function [EVM] with No Security Claimed Table 9. Non-Approved, Not Allowed Use/Function [EVM] Algorithms Table 10. Security Function Implementations Description [EVM] Table 11. Entropy Certificates Cannot mark the table; must note in Security Policy after the table. Table 15. Roles Name [EVM] Table 16. Approved Services Table 17. Non-Approved Services Table 24. SSPs Name [EVM] Table 25. Pre-Operational Self-Tests Details [EVM] Table 26. Conditional Self-Tests Details [EVM] Table 27. Error States Description [EVM] All other areas of the Security Policy where EVM information is needed that are not shown in the above tables, shall also be marked with [EVM]. [AS02.24] Each IUT service shall indicate use of approved algorithms even when it requests the EVM to use any approved algorithms on its behalf (see IG 2.4.C). Additional Comments 1. In the case of software, firmware, and hybrid modules, since the IUT’s tested OE must match (or be a subset of) the tested OEs of the EVM, a post-validation addition to the IUT’s tested OEs would require an addition to the tested OEs of the EVM if the newly added OEs are not a subset of the OEs of the EVM (see the FIPS 140-3 Management Manual 7.1.7 OEUP). 2. If the EVM supplies the IUT with entropy and has an “ENT” validation (as opposed to an ESV), the IUT will show the “ENT” on its certificate. CMVP 10 08/30/2024 Section 2 – Cryptographic module specification 2.3.A Binding of Cryptographic Algorithm Validation Certificates Applicable Levels: All Original Publishing Date: September 21, 2020 Effective Date: September 21, 2020 Last Modified Date: September 21, 2020 Relevant Assertions: AS02.20 Relevant Test Requirements: TE02.20.01 Relevant Vendor Requirements: VE02.20.01 Background Cryptographic algorithm implementations are tested and validated under the Cryptographic Algorithm Validation Program (CAVP). The cryptographic algorithm validation certificate states the name and version number of the validated algorithm implementation, and the tested operational environment. Cryptographic modules are tested and validated under the Cryptographic Module Validation Program (CMVP). The cryptographic module validation certificate states the name and version number of the validated cryptographic module, and the tested operational environment. The validation certificate serves as a benchmark for the configuration and operational environment used during the validation testing. Question/Problem What are the configuration control and operational environment requirements for the cryptographic algorithm implementation(s) embedded within a cryptographic module when the latter is undergoing testing for compliance to FIPS 140-3? Resolution For a validated cryptographic algorithm implementation to be embedded within a software, firmware or hardware cryptographic module that undergoes testing for compliance to FIPS 140-3, the following requirements must be met: 1. The implementation of the validated cryptographic algorithm has not been modified upon integration into the cryptographic module undergoing testing; and 2. The operational environment under which the validated cryptographic algorithm implementation was tested by the CAVP must be identical to the operational environment that the cryptographic module is being tested under by the CST laboratory, subject to the following rules: For software modules, each Operational Environment listed must consist of the Operating System, the platform, and the processor on which the module was tested. If a hypervisor was used, that must also be listed (see the WebCryptik User’s Guide). If an implementation has been tested on an X-bit processor (e.g. 32-bit, 64-bit), a claim cannot be made that the implementation also runs on different bit size processors. For example: An algorithm implementation was tested and validated on a 32-bit platform. This was used in a previous 32-bit version of a software module that was validated for conformance to FIPS 140-3. Now the software module is undergoing testing on a 64-bit platform. This software module cannot operate on a 32-bit platform without change. In this case the operational Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology environments are not the same; therefore, the algorithm implementations must be re-tested on the 64-bit platform. Memory size, processor frequency, etc. are not relevant. If an algorithm implementation has been tested on one operating system, a claim cannot be made that the implementation also runs on another operating system when it is considered for module testing. The algorithm implementation must have been tested on every operating environment claimed by the software module. The algorithm certificate may include other operating environments as well, but they are not relevant to the module under test. If algorithm testing is not performed directly by the CST Lab, the CST Lab is responsible for asking the vendor to supply the operating environment (processor and/or operating system and platform) on which they ran the algorithm implementation and with which they generated the vector set test results. It is the CST Labs’ responsibility to verify that the results in the vector set test results were generated using the specified operating environment. If an algorithm is implemented in HDL on a Field Programmable Gate Array (FPGA) device and there is no underlying "OS" implemented in the FPGA, the algorithm implementation cannot be validated as firmware and ported as is to other FPGAs, since the CMVP does not validate HDL (which is equivalent to source code). The algorithm implementation would be validated in the FPGA as hardware. Once the FPGA device is validated, one could take the HDL on this FPGA and reuse it in creating a new FPGA. If this were done, the algorithm implementations would need to be validated on the new hardware because they would be considered as new hardware implementations. Additional Comments Additional information regarding operational environment can be found in the CAVP FAQ GEN.12. CMVP 12 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 2.3.B Sub-Chip Cryptographic Subsystems Applicable Levels: All Original Publishing Date: September 21, 2020 Effective Date: September 21, 2020 Last Modified Date: March 26, 2024 Relevant Assertions: Relevant Test Requirements: Relevant Vendor Requirements: Background Increased levels of integration in IC design, such as ASIC, FPGA or System-on-Chip (SoC), have been developed with heterogeneous computing characteristics. Heterogeneous computing may include multiple processors or functional engines, with isolated security subsystem designs that may be re-used in multiple configurations or generations of products. Question/Problem What is a sub-chip cryptographic subsystem, and what are the requirements for initial validation? Once validated, how can the sub-chip cryptographic subsystem be re-validated if modified? How can a non-modified sub-chip cryptographic subsystem be ported and reused on other single-chip implementations? Resolution The following terminology is used in the context of this IG: HDL – Hardware Design Language; examples are Verilog and VHDL. Security relevant – relevant to the requirements of FIPS 140-3. Soft circuitry core – an uncompiled hardware subsystem of an ASIC, FPGA or SoC. Hard circuitry core – a fixed or precompiled hardware subsystem of an ASIC, FPGA or SoC. For a hardware module, the minimum defined physical boundary in ISO/IEC 19790:2012 is a single-chip. For single-chip hardware modules a sub-chip cryptographic subsystem may be defined as the set of hard and/or soft circuitry cores and associated firmware which represents a sub-chip cryptographic subsystem boundary of a single-chip hardware module. The sub-chip cryptographic subsystem is integrated on the single-chip which may contain other functional subsystems (e.g. processor(s), memory, I/O and internal bus controls, sensors, etc.) and associated firmware. Upon fabrication of the complete physical single-chip, the HDL will be transformed to a gate or physical circuitry representation which may or may not retain a definable internal sub- chip cryptographic subsystem boundary. 1. Initial validation or security relevant re-validations The physical boundary shall be defined as the single-chip physical boundary; o ISO/IEC 19790:2012 Section 7.7 requirements shall apply at the physical boundary ISO/IEC 19790:2012 defines the Cryptographic boundary as an explicitly defined perimeter that establishes the boundary of all components (i.e. set of hardware, software or firmware components) of the cryptographic module. For a sub-chip cryptographic subsystem, the physical boundary is the single-chip physical boundary while its Hardware Module Interface (HMI) (i.e. the sub-chip cryptographic subsystem boundary) is defined as the set of hard and/or soft circuitry cores and associated firmware that comprises the sub-chip cryptographic subsystem. If there is any associated firmware externally loaded into the sub-chip cryptographic subsystem, the associated firmware shall meet requirements of Software/Firmware Load Test (ISO/IEC 19790:2012 Section 7.10.3.4). CMVP 13 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Except for externally loaded firmware, the associated firmware shall be stored and loaded inside the sub-chip cryptographic subsystem and shall meet the pre-operational software/firmware integrity test (ISO/IEC 19790:2012 Section 7.10.2.2). The ports and interfaces (ISO/IEC 19790:2012 Section 7.3) shall be defined at the HMI. o For operational testing purposes, access to the HMI ports shall be available and a mapping shall be provided. These may be mapped to physical I/O pins, internal test interfaces (e.g. Level Sensitive Scan Design (LSSD)) or the HMI data and control ports. The tester shall demonstrate that the ports at the HMI are accessible via the single-chip's other functional subsystems in a manner such that following five kinds of information are provably unmodifiable and under control of the test program: ▪ Data input, ▪ Data output, ▪ Control input, ▪ Control output, and ▪ Status output even in the presence of intervening other functional subsystems. Note 1: Typically, the test program acting on behalf of the tester with direct access to the ports and interfaces defined at the HMI provides the required demonstration of port access. Note 2: In single-chip embodiments, there may be intervening functional subsystems (or intervening circuitry) other than the sub-chip cryptographic subsystem subject to testing. There is a security concern that such intervening subsystems might act maliciously (e.g., intercept, modify, and store CSPs, or attempt a replay attack and/or man-in-the-middle attack). The tester shall verify and provide the vendor’s rationale in the validation report (TE02.13.01) explaining existing risks and mitigations. It is not required for the tester to manipulate these components as required by TE02.13.03 unless the vendor has identified an operational security concern. Additionally, the lab shall elaborate on the reasonability of the vendor’s rationale in TE02.13.03. The CMVP may provide additional guidance in the future on how to analyze and document such potential security risks. Note 3: If applicable, VE04.51.01 and TE04.51.01 shall be considered at the level of the tested sub-chip cryptographic subsystem and potential differences between the internal and external with respect to the subsystem boundary single chip clocks shall be accounted for properly. Depending on the Security Level of Section 7.9 (Sensitive security parameter management), the requirements for sensitive security parameter establishment (ISO/IEC 19790:2012 Section 7.9.4-5) shall be applicable at the HMI. o Transferring SSPs including the entropy input between a sub-chip cryptographic subsystem HMI and an intervening functional subsystem for Security Levels 1 and 2 on the same single chip does not require meeting the sensitive security parameter establishment requirements, per IG 9.5.A. Nevertheless, the above Note 2 for the ports and interfaces is applicable for the transferring of SSPs as well. That is, the tester shall provide a rationale in the physical security test report explaining risks and mitigations to the malicious act by such intervening subsystems. o For modules that are Security Levels 3 or 4, SSP establishment is AD / EE as stated in IG 9.5.A. Versioning information (AS04.13) shall be provided for CMVP 14 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology o the physical single-chip including any excluded functional subsystem firmware (shall be specified in the OE field of the validation), o the sub-chip cryptographic subsystem soft and hard circuitry cores, and o the associated firmware. Processor sub-functions outside the HMI but within the physical boundary such as a processor, memory macros, I/O controllers, etc. may be excluded under AS02.13 and AS02.14. However, the data paths used to meet either AS03.18 and AS03.20-22 or AS03.19 and AS03.20-22 (depending on the level) shall not be excluded. 2. Non-security relevant re-validations associated with changes within physical boundary Existing re-validation guidance is applicable. 3. Multiple disjoint sub-chip cryptographic subsystems: Disjoint sub-chip cryptographic subsystems may exist on a single-chip. Each shall be separately validated. Transferring Keys/SSPs including the entropy input between two disjoint sub-chip cryptographic subsystems on the same single chip for Security Level 1 or Security Level 2 modules for Section 7.9 (Sensitive security parameter management) is considered not having SSP establishment across their sub- chip cryptographic subsystem boundary per IG 9.5.A. For Security Level 3 and Security Level 4 modules for (Section 7.9 Sensitive security parameter management), CSP establishment is AD / EE as stated in IG 9.5.A. Alternatively, plaintext CSPs may be shared directly between two disjoint sub-chip cryptographic subsystems via a Trusted Channel (ISO/IEC 19790:2012 Section 7.3.4). In this scenario, the following porting rules shall apply: a. If the two sub-chip modules that are connected by a Trusted Channel are ported together, it is considered security relevant, and the testing lab shall submit a UPDT or a FS. b. If only one of the sub-chip modules that are connected by a Trusted Channel is ported, then the testing lab shall verify that the Trusted Channel is no longer functional and may submit a PTSC. c. If only one of the sub-chip modules that are connected by a Trusted Channel are ported and it is connected to a new sub-chip module, then it is considered security relevant, and the testing lab shall submit a UPDT or a FS. Additional Comments 1. This IG does not apply to single-chip implementations that do not contain sub-chip cryptographic subsystems, i.e., there is only one boundary which is the physical boundary. 2. If the sub-chip cryptographic subsystem enters an error state, the FIPS 140-3 requirements are applicable at the HMI of the sub-chip cryptographic subsystem; not at the boundary of the single- chip. 3. After validation, if there are any changes to versioning within the single chip (security relevant or not) even if solely to the components outside of the sub-chip cryptographic subsystem boundary, the module shall be validated or re-validated to maintain validated status (e.g., see the FIPS 140-3 MM Section 7.1.9). CMVP 15 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 2.3.C Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementation (PAI) Applicable Levels: All Original Publishing Date: September 21, 2020 Effective Date: September 21, 2020 Last Modified Date: July 26, 2024 Relevant Assertions: Relevant Test Requirements: Relevant Vendor Requirements: Background Single-chip processor manufacturers are adding acceleration functions to support complex cryptographic algorithms. When these functions are added, the CMVP, the CAVP and the Cryptographic Technology group at NIST will determine if the acceleration function is simply a mathematical construct or a complete cryptographic algorithm as defined in the NIST standards. If the function is deemed the complete cryptographic algorithm, then FIPS 140-3 defines the component to be security-specific hardware. Complete documentation of the entire component, including HDL, shall be submitted to the testing laboratory when under test. This type of implementation is considered a Processor Algorithm Implementation (PAI) function. If the module has been designed to run with and without the security-specific hardware, the resolution below under Software/Firmware Module may apply. If the function is deemed a mathematical construct and not the complete cryptographic algorithm as defined in the NIST standards, then FIPS 140-3 does not define the component to be security-specific hardware and complete documentation of the entire component, including HDL, is not required. This type of implementation is considered a Processor Algorithm Acceleration (PAA) function. Question/Problem What are the currently known processor chips that include Processor Algorithm Acceleration (PAA) and Processor Algorithm Implementation (PAI) functions to support complex cryptographic algorithms and how is it indicated on the validation certificate? What are the testing requirements when a module supports PAA and/or PAI? Resolution If a cryptographic module is designed to utilize a processor chip that includes PAA and/or PAI, the part number or version of the processor chip shall be included in TE02.15.01. A module that utilizes such processor hardware may or may not be defined as a hybrid module. Hybrid Software/Firmware Module: If the software or firmware component of the hybrid can only support a cryptographic algorithm by utilizing the PAA or PAI capability, then the module shall be defined as either a Hybrid Software Module embodiment, or a Hybrid-Firmware module embodiment. PAA Module versioning information shall include the part number or version of the processor chip. Operational Environment: running on with with PAA PAI Module versioning information shall include the part number or version of the processor chip. Operational Environment: running on with with PAI Software/Firmware Module: If the software or firmware component of the module can support a cryptographic algorithm natively (within the software/firmware) or by utilizing an available PAA or PAI, the module shall be defined as either a Software module embodiment or a Firmware module embodiment, unless other requirements designate the module as hybrid. CMVP 16 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology PAA Algorithm certificates; the accelerated algorithms shall be tested in both software/firmware only execution and PAA execution. Operational Environment: o running on with with PAA; o running on with without PAA PAI Algorithm certificates; the algorithms shall be tested in both software/firmware only execution and PAI execution. Operational Environment: o running on with with PAI; o running on with without PAI Testing requirements A module is considered a hybrid if all the Operational Environments (OEs) only support with PAA/PAI and were tested as such. A module can support PAA/PAI and be considered a software/firmware module instead of a hybrid if one of the following two options are chosen: 1. Perform module testing with and without PAA/PAI for all OEs on the certificate. a. OEs would either be listed with and without on the certificate (which is typical), or with or without (rare) if the algorithm and operational testing is performed on both options and shown in the Test Report. Sometimes a vendor may choose this second option as to encourage a user in using a PAA/PAI or non-PAA/PAI solution (even though both are technically validated). 2. Perform module testing without PAA/PAI for at least one OE on the certificate, and with PAA/PAI for at least one OE on the certificate. Testing with and without may be on the same OE or may be on another, “similar”, OE following the rules below. a. The module shall be tested with PAA/PAI on every OE on the certificate that supports a PAA/PAI. This is to confirm every PAA/PAI implementation/combination is tested, since there may be subtle differences in both the code and the PAA/PAI in the processor. b. For every OE that is tested with PAA/PAI, there shall be another “similar” or identical OE tested without PAA. Examples of OEs that may or may not be “similar” are provided in IG 2.3.A Resolution #2 (e.g., a 64-bit OE is not “similar” to a 32 bit-OE, even if everything else is identical). The testing lab shall justify the “similar” claim in the Test Report. It is recommended that “similar” requests be submitted to the CMVP via the existing Request for Guidance process detailed in the Management Manual Section 2.5 Request for Guidance from CMVP. It is at the discretion of the CMVP to accept this claim. c. There shall be no differences in module binaries executed on any of the OEs that are considered “similar”, whether testing with or without the PAA/PAI (note: the PAA/PAI code is considered outside of the logical boundary of the module). E.g., the module has identical binaries running on all “similar” OEs, and this code was tested in at least one instance of both with and without PAA/PAI. d. It is acceptable if some of the OEs only support without PAA/PAI and not with PAA/PAI – as this is still considered a software/firmware module. E.g., OE1 uses an Intel Xeon E5-2600 and was tested with and without PAA, while OE2 uses an ARMv5 that does not implement a PAA/PAI and was only tested without PAA/PAI. CMVP 17 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology e. It is acceptable if some of the OEs were only tested with PAA/PAI and not without PAA/PAI – as this is still considered a software module since that code branch (without PAA/PAI) has already been tested on a “similar” OE. E.g., OE1 uses OS1 on an Intel Xeon E5-2600 and was only tested with PAA, while OE2 uses OS1 on an Intel Xeon E5-2650 that was tested with and without PAA. f. The module certificate shall never include an OE that was not individually tested by the lab. g. The Test Report shall include evidence demonstrating all module/PAA/PAI code branches used by OEs on the certificate are tested within the combination of the tested OEs. h. The above rules apply only for MODULE LEVEL testing, and does not address CAVP testing (e.g., see CAVP FAQ AES.2). Below is a diagram to help explain option 2. The diagram shows a module running on two slightly different environments. The module was tested without PAA only once, since the module binary that includes the AES implementation without PAA(Yellow box) is exactly the same in both environments. Thus, there is assurance that the AES without PAA will function on any “similar” environment. However, the module was tested with PAA twice, since the processor is different in both environments, and testing on both guarantees that all code is exercised, including with the PAA code on the processor itself (peach and green boxes). The module certificate can only claim what is tested (i.e., with PAA on both environments, and without PAA on one). Known PAAs: Intel Processors – Xeon, Core i5, Core i7, Core M and Atom with Westmere, Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake, Goldmont Plus, Whiskey Lake, CMVP 18 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Amber Lake, Cascade Lake, Comet Lake, Sunny Cove, or Golden Cove micro-architectures: PAA = AES-NI o Accelerator sub-functions for AES implementations Intel Processors – Atom, Celeron, Xeon, and Pentium with Goldmont, Goldmont Plus, Sunny Cove, Golden Cove micro-architectures: PAA = Intel SHA Extensions o Accelerator sub-functions for SHA implementations AMD Processors - Opteron, Athlon, Sempron, FX, and A series with Bulldozer, Piledriver, Steamroller, Jaguar, Puma micro-architectures: PAA = AES-NI o Accelerator sub-functions for AES implementations AMD Processors – Ryzen series with Zen micro-architectures: PAA = SHA Extensions o Accelerator sub-functions for SHA implementations ARM Cortex A series, R series, Qualcomm Snapdragon, Apple A series processors, Samsung Exynos with ARMv7-A and ARMv8-A micro-architectures: PAA = NEON or Cryptography Extensions o Accelerator sub-functions for AES and SHA implementations IBM Power Processors 8, 9: PAA = Power ISA o Accelerator sub-functions for AES and SHA implementations Oracle: Oracle SPARC T series, M series: PAA = SPARC o Accelerator sub-functions for AES, DES, and SHA implementations Known PAIs: IBM CP Assist for Cryptographic Functions (CPACF) o Full implementations of AES (ECB, CBC), TDES, SHA-1, SHA2 Additional Comments 1. AES.2 in the CAVP FAQ gives requirements for both types of implementations. 2. The processor manufacturer may provide a device driver to support use of the processor algorithm accelerator. The device driver shall not provide any additional functionality to the PAA. 3. The implementation of complete algorithms, partial cryptographic modules, or full cryptographic modules as a component of a single-chip, or multiple of any of the above as components of a single-chip, is addressed in IG 2.3.B. 4. Please contact the CMVP to address new PAA or PAI implementations to make a determination whether they are full cryptographic functions or not. 5. If the PAI security function appears on the list of known PAIs, its HDL is not required for validation of software modules using it. 6. For CAVP and ESV certificates, testing with and without PAA/PAI is not required if the algorithm or entropy source does not utilize the corresponding PAA/PAI. CMVP 19 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 2.3.D Excluded Components Applicable Levels: All Original Publishing Date: March 17, 2023 Effective Date: March 17, 2023 Last Modified Date: March 17, 2023 Relevant Assertions: AS02.13 Relevant Test Requirements: TE(s) associated with AS(s) above Relevant Vendor Requirements: VE(s) associated with AS(s) above Background ISO/IEC 19790:2012 Section 7.2.3.1: Hardware, software and/or firmware components within the cryptographic boundary may be excluded from the requirements of this International Standard. The excluded hardware, software or firmware components shall [02.13] be implemented in a manner to not interfere or compromise the approved secure operation of the cryptographic module. ISO/IEC 24759:2017: AS02.13: (Specification — Levels 1, 2, 3, and 4) The excluded hardware, software or firmware components shall be implemented in a manner to not interfere or compromise the approved secure operation of the cryptographic module. VE02.13.01: The vendor shall describe the excluded components of the module and justify that these components will not interfere with the approved secure operation of the module. VE02.13.02: The vendor documentation shall provide the rationale for excluding each of the components. The rationale shall describe how each excluded component, when working properly or when it malfunctions, cannot interfere with the approved secure operation of the module. Rationale that may be acceptable, if adequately supported by documentation, includes the following. a) The component is not connected with security relevant components of the module that would allow inappropriate transfer of SSPs, plaintext data, or other information that could interfere with the approved secure operation of the module. b) All information processed by the component is strictly for internal use of the module, and does not in any way impact the correctness of control, status or data outputs. TE02.13.01: The tester shall verify from the vendor provided documentation that the excluded components of the cryptographic boundary will not interfere with the approved secure operation of the module. TE02.13.02: The tester shall verify the correctness of any rationale for exclusion provided by the vendor. The burden of proof is on the vendor; if there is any uncertainty or ambiguity, the tester shall require the vendor to produce additional information as needed. TE02.13.03: The tester shall manipulate (e.g. to cause the component to operate not as designed) the excluded components in a manner to cause incorrect operation of the excluded component. The tester shall verify that the incorrect operation of the excluded component shall not interfere with the approved secure operation of the module. Question/Problem What are the testing requirements to meet TE02.13.03? Resolution It is up to the testing lab and the vendor to come up with the appropriate testing approach to meet TE02.13.03. The testing approach and rationale shall be documented in this TE. Testing may rely on code review and/or documentation alone if and only if behavioral (e.g., using a debugger, code manipulator/injector, simulator, or CMVP 20 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology other tool to manipulate data and/or characteristics of the component that may impact the behavior of an excluded component) and/or physical (e.g., shorting/removing pins, voltage manipulation) methods to cause the incorrect operation of the excluded component are infeasible or impractical for a given module. Otherwise, behavioral and/or physical methods are required. Testing is considered infeasible or impractical when such manipulations are understood to permanently damage the module, or the system in which it is contained, without exposing any security relevant data or achieving any desired security goals beyond simply rendering the entire module inoperable. Tester shall verify rationale provided by the vendor in such a scenario. Testing excluded components may be at a high-level (e.g., the entire memory component of a module, the power supply, line cards, fans, etc.) and/or at a low-level (e.g., the underlying individual hardware components such as switches, resistors, capacitors, or inductors), depending on which test is most appropriate based on the analysis performed by the lab and vendor. The tests shall focus on the secure operation of the module, but not necessarily on other aspects such as reliability and/or quality, unless they may help prove lack of interference with the approved secure operation of the module. Acceptance of such testing is at the discretion of the CMVP. Labs can submit their proposed test approach to the CMVP for pre-approval via an RFG (see Management Manual Section 2.5 Request for Guidance from CMVP). Additional Comments 1. After validation, if an excluded component is modified, the module shall be validated or re-validated to maintain validated status, as excluded components are still considered within the boundary of the module. In such case, during validation or revalidation, compliance to AS02.13 is required. 2. The details of the excluded components (including their versioning) shall be captured in TE02.14.01. 3. The overall module version shall change if excluded components are changed. CMVP 21 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 2.4.A Definition and Use of a non-Approved Security Function Applicable Levels: All Original Publishing Date: September 21, 2020 Effective Date: September 21, 2020 Last Modified Date: March 14, 2022 Relevant Assertions: AS02.21 Relevant Test Requirements: TE02.21.01 and TE02.21.02 Relevant Vendor Requirements: VE02.21.01 and VE02.21.02 Background ISO/IEC 19790:2012 Terms and Definitions: Approved mode of operation: set of services which includes at least one service that utilises an approved security function or process and can include non-security relevant services. NOTE 1: Not to be confused with a specific mode of an approved security function, e.g. Cipher Block Chaining (CBC) mode. NOTE 2: Non- approved security functions or processes are excluded. Approved security function: security function (e.g. cryptographic algorithm) that is referenced in Annex C [which is superseded by SP 800-140C. Also see SP 800-140D which includes approved security functions in relation to SSP generation and establishment methods]. Cryptographic algorithm: well-defined computational procedure that takes variable inputs, which may include cryptographic keys, and produces an output. Plaintext key: unencrypted cryptographic key or a cryptographic key obfuscated by non-approved methods which is considered unprotected. Security function: cryptographic algorithms together with modes of operation, such as block ciphers, stream ciphers, symmetric or asymmetric key algorithms, message authentication codes, hash functions, or other security functions, random bit generators, entity authentication and SSP generation and establishment all approved either by ISO/IEC or an approval authority. NOTE: See Annex C [which is superseded by SP 800- 140C. Also see SP 800-140D]. ISO/IEC 19790:2012 Section 6 Functional Security Objectives: The security requirements specified in this International Standard relate to the secure design and implementation of a cryptographic module. The security requirements start with a baseline level of security objectives with increasing levels of security objectives. The requirements are derived from the following high- level functional security objectives for a cryptographic module to: employ and correctly implement the approved security functions for the protection of sensitive information; protect a cryptographic module from unauthorised operation or use; prevent the unauthorised disclosure of the contents of the cryptographic module, including CSPs; prevent the unauthorised and undetected modification of the cryptographic module and cryptographic algorithms, including the unauthorised modification, substitution, insertion, and deletion of SSPs; provide indications of the operational state of the cryptographic module; ensure that the cryptographic module performs properly when operating in an approved mode of operation; detect errors in the operation of the module and to prevent the compromise of SSPs resulting from these errors; ensure the proper design, distribution and implementation of the cryptographic module. CMVP 22 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology ISO/IEC 19790:2012 Section 7.9.1 Sensitive security parameter management general requirements: Encrypted CSPs refer to CSPs that are encrypted using an approved security function. CSPs encrypted or obfuscated using non-approved security functions are considered unprotected plaintext within the scope of this International Standard. ISO/IEC 24759:2017 AS02.21: (Specification — Levels 1, 2, 3, and 4) Non-approved cryptographic algorithms, security functions, and processes or other services not specified in {ISO/IEC 19790:2012} 7.4.3 shall not be utilized by the operator in an approved mode of operation unless the non-approved cryptographic algorithm or security function is part of an approved process and is not security relevant to the approved processes operation (e.g. a non-approved cryptographic algorithm or non-approved generated key may be used to obfuscate data or CSPs but the result is considered unprotected plaintext and provides no security relevant functionality until protected with an approved cryptographic algorithm). Question/Problem The term non-approved security function is not defined in the ISO/IEC 19790:2012 Terms and Definitions, but is cited in multiple places in the standard, DTR and IG. How is non-approved security function defined, and how is it interpreted in relation to the ISO/IEC 19790:2012 Section 7.2.4 Modes of operations? Resolution Definition of non-approved security function FIPS 140-3 is concerned specifically with approved and non-approved security functions: the term non- approved security function must be defined relative to functions that claim security, rather than all functionality outside the set of approved security functions. The term security is not defined in the Terms and Definitions, but, within the scope of FIPS 140-3, is determined based on the Section 6 Functional Security Objectives, and the specific Section 7 Security Requirements derived from those objectives. A non-approved security function is any function within the scope of the module that relies on a non-approved cryptographic algorithm to support a claim of security. Notes Per the definition of a cryptographic algorithm (see Background), primitive computational and logical operations (e.g. addition, subtraction, multiplication, division, AND, NOT, OR, and XOR) are used in cryptographic algorithms but are not themselves cryptographic algorithms. A non-approved cryptographic algorithm or proprietary cryptographic algorithm is not a security function if processed data can be treated as plaintext without violating the Objectives stated in ISO/IEC 19790:2012 Section 6, the applicable requirements in ISO/IEC 19790:2012 Section 7, or the security rules specified in the module’s Security Policy. Relationship of non-approved cryptographic algorithms and the modes of operation Non-approved security functions shall not be used in the approved mode of operation; however, non-approved cryptographic algorithms may be used in the approved mode of operation if the non-approved algorithms are not a security function. If a non-approved cryptographic algorithm is used by the module in the approved mode but is not a security function, the algorithm shall be included in the Security Policy’s list of non-approved algorithms allowed in the approved mode of operation with no security claimed (see SP 800-140B). However, the module’s certificate shall not include these algorithms as they do not claim any security and are not used to meet any requirement of FIPS 140-3. A non-approved cryptographic algorithm shall not share the same keys or CSPs that are used by an approved or allowed algorithm for any cryptographic operation in either the approved, or non-approved mode, as this counters Section 6 Security Objectives by potentially releasing sensitive data and/or CSP(s). A non-approved cryptographic algorithm may still access or modify a CSP in the approved mode (under strict conditions laid out in this IG), as long as the CSP is not used as part of the non-approved cryptographic operation, such encryption/decryption, SSP establishment (inclusive of key generation), message authentication, message digest generation or digital signature generation/verification. The only exception to the rule explained in the CMVP 23 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology first sentence of this paragraph, is the use of a non-approved cryptographic algorithm that utilizes an approved DRBG for any purpose such as SSP establishment, stand-alone random number generation, hashing, data obfuscation, etc. Despite access and modification of the state of the DRBG CSP(s) by a non-approved algorithm, this is allowed in both the approved and non-approved modes of operation. See the examples below for more information. Possible example scenarios of non-approved cryptographic algorithms in various modes of operation Example scenarios of non-approved cryptographic algorithms allowed in the approved mode with no security claimed 1. Use of a non-approved cryptographic algorithm to “obfuscate” a CSP For purposes of storage or certificate formatting (e.g. PFX), a module might: XOR a CSP with a secret value (note, the XOR itself is not a cryptographic algorithm but rather a part of a cryptographic algorithm that may include the establishment of the secret value for example) Encrypt or decrypt a CSP using a proprietary or non-approved cryptographic algorithm. Store authentication data using MD5 or using HMAC-SHA-1 with a weak HMAC key Format certificate data using a non-approved PKCS #12 As noted above, “CSPs encrypted or obfuscated using a non-approved [algorithms] or proprietary algorithm or method are considered unprotected plaintext.” All Section 7 requirements must be satisfied when considering the CSP in plaintext form: The report description of CSPs must correctly describe the form of the CSP. The module must support zeroisation of any CSPs stored internally in the forms described above. If the obfuscated CSP is imported or exported, the module must meet the requirements for plaintext CSP import or export. This conclusion is consistent with IG 9.6.A Acceptable Algorithms for Protecting Stored Keys and CSPs. 2. Use of an approved, non-approved or proprietary algorithm for a purpose that is not security relevant or is redundant to an approved cryptographic algorithm a. Use of MD5 1 in the TLS 1.0 / 1.1 KDF SP 800-135rev1 Section 4.2.1 describes the use of MD5 in conjunction with SHA-1 in the key derivation function, concluding that the TLS 1.0/1.1 KDF may be used within the context of the TLS protocol (with provisions for validation of the companion approved functions, SHA-1 and HMAC). This use of MD5 does not conflict with the security of the approved security functions. b. Storage device use of a PRF (e.g. XTS AES) for memory wear leveling (a technique for prolonging the service life of some kinds of erasable computer storage media). For best results, a method with good statistical properties (i.e. a PRF) may be used for wear leveling, redundant to any other encryption or decryption performed by the module. This use of an algorithm is not for a security purpose; it is to prolong memory life. 1 May be allowed in an approved mode of operation when used as part of an approved key transport scheme (e.g., SSL v3.1) where no security is provided by the algorithm. CMVP 24 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology c. A secure channel operated over an insecure communications channel Consider a module whose purpose is to provide end-to-end secure communications over an insecure communications channel. That channel may be plaintext or some method which provides insufficient security, assumed to provide no greater security than plaintext. Specifically, assume the module communicates over a normal, unprotected Ethernet, provides approved end to end encryption, decryption and message authentication, as well as initial authentication of the peer node, and meets all FIPS 140-3 Section 7 requirements. This module can be validated. Consider the same scenario but with wireless communications over WEP, WPA, WPA2 or similar, where the purpose of the module is a remedy for insecure communications media. The module must communicate with a WAP using the communications protocols the WAP provides. If the channel is treated as plaintext, and the module provides secure channel services that meet all FIPS 140-3 Section 7 requirements, to deny validation to such a module because the communications media uses non-approved functions defeats the purpose of the module, and is contrary to the intent of the CMVP as a program. d. Non-approved cryptographic algorithm that uses an approved DRBG for cryptographic purposes The module uses a non-approved cryptographic algorithm to “obfuscate” a CSP for RAM storage. The key used for “obfuscation” is derived via an approved DRBG. By doing this, the DRBG changes its state, and therefore the DRBG CSPs are modified. Despite the modification and use of the DRBG CSPs within a cryptographic operation, this is allowed because the DRBG is the exception to the rule laid out in this IG. 3. Use of a non-approved cryptographic algorithm as part of an approved algorithm that claims security a. Use of GHASH within AES GCM Although GHASH, alone, is a non-approved hashing function, it is used within an approved AES GCM algorithm, and is therefore permitted, even if the vendor claims security on this algorithm. However, if the vendor claims security on this function, then it shall not be used in the approved mode for any independent operation outside of the approved algorithm. Example scenarios of non-approved cryptographic algorithms not allowed in any mode 1. Non-approved cryptographic algorithm that share the same key or CSP as an approved algorithm a. A DES algorithm is encrypting data using a DES key K1. This key is a part of a Triple-DES key K = (K1, K2, K3) which is a CSP, as it may be used by an approved Triple-DES algorithm. The value E = DESK1 (data) is sent outside the module’s boundary. An attacker can easily break the single-DES encryption and recover K1, which will lead to the disclosure of the Triple-DES key K. b. Suppose a module generates, in full compliance with FIPS 186-5, a key pair for an approved RSA signature algorithm. However, the module also has a non-approved RSA signature algorithm not claiming any security. This non-approved RSA signature algorithm could use the same RSA key to generate its “signatures”. These non-approved signatures may be broken by an attacker and the signing key may be recovered, allowing the attacker to use this key to sign what they want. The reason the above two examples are prohibited is because they do not follow the above rule which states: “A non-approved cryptographic algorithm shall not share the same key or CSP that is used by an approved or allowed algorithm for any cryptographic operation in either the approved, or non-approved mode”. Even if the vendor claims no security on these non-approved algorithms, they are still not allowed. CMVP 25 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Additional Comments 1. The vendor must provide clear documentation and reasoning as to why the non-approved cryptographic algorithms can be used in an approved mode, i.e., not being used to meet the requirements of FIPS 140-3 sections 6 and 7. It is at the discretion of the CMVP to determine if such usage of an algorithm fits within the guidance laid out in this IG. 2. In addition, attempts to make use of this IG to include algorithms in the approved mode will not be accepted unless all of the following are met: 1) the algorithm is not used whatsoever to meet any FIPS 140-3 requirements; 2) the algorithm does not access or share CSPs in a way that counters the requirements of this IG; 3) the algorithm is either: i) not intended to be used as a security function (e.g. interoperability or for memory wear leveling); ii) redundant to an approved algorithm (e.g. double encryption); iii) a cryptographic or mathematical operation applied for “good measure” but not for providing sound security (e.g. XORing a CSP with a secret value, using a proprietary algorithm, or using non-approved algorithms to obfuscate stored CSPs which are considered plaintext); 4) the algorithm’s non-approved use and purpose (from 3) above) is unambiguous to the operator and can’t be easily confused for a security function. 3. A key point to consider for 4) above is the purpose or use of the service that utilizes the non-approved algorithms. For example, if the purpose is solely to provide cryptographic functionality to a calling application, then the service is easily confused for a security function (e.g., a software library that provides non-approved key agreement, key transport, or general encryption/decryption services) and the algorithm(s) within this service cannot claim no security per this IG. But if it is clear that the purpose of a service does not include providing any security functionality recognized in FIPS 140-3 then the service can use non-approved algorithms in the approved mode if provisions of this IG are met. Examples of such services are status output (possibly, using the non-security provisions of the SNMP protocol) and obfuscating CSPs for internal storage that is considered plaintext. CMVP 26 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 2.4.B Tracking the Component Validation List Applicable Levels: All Original Publishing Date: September 21, 2020 Effective Date: September 21, 2020 Last Modified Date: July 26, 2024 Relevant Assertions: AS02.20 Relevant Test Requirements: TE02.20.01 Relevant Vendor Requirements: VE02.20.01 Background In response to vendor and user requirements, the CAVP and CMVP have identified several components of the approved algorithms that can be used in an approved mode of operation. These components are included in this IG and labeled “CVL” (Component Validation List) in the CMVP documentation. The reasons for introducing and testing these algorithm components differ. It can be that the module performs key agreement compliant to SP 800-56Arev3, but the shared secret computation, key derivation and optional key confirmation procedures of the key agreement scheme are tested individually rather than as one complete test, as approved by IG D.F. In another example, the module may perform a cryptographic signature generation computation without computing the hash of the message as this hash has already been precomputed by another entity. Component testing allows one to verify the correctness of the remaining portion of the signature-generating routine. Question/Problem What are the available testable components of the approved algorithms? Which documents specify the functions that each of these components performs? What are their usage restrictions, if any? How do they map to the CAVP ACVTS certificate? Can an algorithm component be vendor affirmed? Resolution The following components can be tested and will be documented as “(CVL)” in the CAVP Certs Table of the module validation. TE02.20.01 shall explain how each CVL meets this IG and is used in an approved manner by the module. 1. An ECC CDH primitive from section 5.7.1.2 of SP 800-56Arev3. The test performs the multiplication of a point on a NIST-recommended elliptic curve by an integer and verifies that the x-coordinate of the resulting point has been computed correctly. The integer in question is defined in SP 800-56Arev3 as the product of the tested party’s private key dA and the curve’s co-factor h. Usage Restriction: Shall only be used within the context of a SP 800-56Arev3 KAS (enforced by the module in that this CVL is not used internally for other purposes; but if external / operator-accessible enforced by operator guidance within the Security Policy, e.g., “the KAS-ECC CDH-Component (CVL) shall only be used within the context of an SP 800-56Arev3 KAS”). CAVP certificate and denotation: Within the context of the CAVP ACVTS, this component test is identified by the following algorithm/mode/revision capability combination: “algorithm”: “KAS-ECC”, “mode”: “CDH-Component”, “revision”: ”Sp800-56Ar3”. This testing is denoted by “KAS-ECC CDH-Component SP800-56Ar3” on the CAVP webpage: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search. CMVP 27 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology 2. An RSA signature generation per FIPS 186-5 without the computation of a hash which is presumed to have already been computed. This RSA test verifies the ability of a module to perform the RSASP1 signature primitive described in PKCS#1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002, Section 5.2.1. RSASP1 takes as input an RSA private key and a message digest and outputs a signature representative or an error message. The test 1) verifies the ability of the module to detect an invalid message representative and 2), given a valid message representative, the ability of the module to compute the correct signature representative. The private key can be in the form of 1) a pair (n, d) or 2) a quintuple (p, q, dP, dQ, qInv). If the private key takes the form of a pair (n, d), then the signature representative is computed as described in Section 5.2.1 Step 2) a. of the standard. If the private key takes the form of a quintuple (p, q, dP, dQ, qInv), then the signature representative is computed as described in Section 5.2.1 Step 2) b. of the standard. As with the full RSA signature generation, defined in FIPS 186-5 and further explained in IG C.F, a component of an RSA signature generation, often referred to as RSASP1, can be used with any RSA modulus n (or a secret RSA key d) no smaller than 2048-bit long. The RSASP1 component implementations shall be tested by an accredited testing lab for all implemented RSA modulus lengths where the CAVP testing is available. If there is no CAVP testing for an RSASP1 component with a particular RSA modulus length then such modulus size does not need to be tested; however, at least one modulus length for which a test exists shall be implemented and tested by the CAVP. This test supports the 2048, 3072 and 4096-bit moduli. Usage Restriction: Shall only be used within the context of a FIPS 186-5 signature generation (enforced by the module in that this CVL is not used internally for other purposes; but if external / operator-accessible enforced by operator guidance within the Security Policy, e.g., “the RSA SigGen (CVL) shall only be used within the context of a FIPS 186-5 signature generation”). CAVP certificate and denotation: Within the context of the CAVP ACVTS, the RSA signature generation component test is identified by the following algorithm/mode/revision capability combination: “algorithm”: “RSA”, “mode”: “signaturePrimitive”, “revision”: ”1.0”. This testing is denoted by “RSA Signature Primitive” on the CAVP webpage: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search. 3. An ECDSA signature generation per FIPS 186-5 without the computation of a hash which is presumed to have already been computed. This ECDSA signature generation component test is the same as when the full ECDSA signature generation algorithm is tested except that the supplied messages are viewed as being already hashed, therefore no further hashing is performed. A binary string representing the hash digest is supplied to the test. See Section 7.3 of ANS X9.62-2005 or Section 6.4.1 of FIPS 186-5 for more information. Usage Restriction: Shall only be used within the context of a FIPS 186-5 signature generation (enforced by the module in that this CVL is not used internally for other purposes; but if external / operator-accessible enforced by operator guidance within the Security Policy, e.g., “the ECDSA SigGen (CVL) shall only be used within the context of a FIPS 186-5 signature generation”). CAVP certificate and denotation: Within the context of the CAVP ACVTS, this component test is identified by any of the following algorithm/mode/revision/componentTest capability combinations: CMVP 28 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology “algorithm”: “ECDSA”, “mode”: “sigGen”, “revision”: ”1.0”, “componentTest”: true; or “algorithm”: “ECDSA”, “mode”: “sigGen”, “revision”: ”FIPS186-5”, “componentTest”: true; or “algorithm”: “detECDSA”, “mode”: “sigGen”, “revision”: ” FIPS186-5”, “componentTest”: true. This testing is denoted by “ECDSA SigGen (FIPS186-4) 2”, “ECDSA SigGen (FIPS186-5)” or “Deterministic ECDSA SigGen (FIPS186-5)” accompanied by “Component” listed in the details field on the CAVP webpage: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation- search 4. An RSA decryption operation using an exponentiation for key encapsulation, as specified in section 7.1.2.1 of SP 800-56Brev2 published in March 2019. RSADP is used as shorthand to refer to the RSA decryption primitive in SP 800-56Brev2. This test only supports the 2048-bit modulo. Usage Restriction: Shall only be used within the context of a SP 800-56Brev2 KTS (enforced by the module in that this CVL is not used internally for other purposes; but if external / operator-accessible enforced by operator guidance within the Security Policy, e.g., “the RSA Decryption Primitive (CVL) shall only be used within the context of a SP 800-56Brev2 KTS”). CAVP certificate and denotation: Within the context of the CAVP ACVTS, this component test is identified by the following algorithm/mode/revision capability combination: “algorithm”: “RSA”, “mode”: “decryptionPrimitive”, “revision”: ”1.0”. This testing is denoted by “RSA Decryption Primitive” on the CAVP webpage: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search 5. An RSA decryption operation using an exponentiation for key encapsulation, as specified in sections 7.1.2.1 and 7.1.2.2 of SP 800-56Brev2 published in March 2019, or using the process specified in section 7.1.2.3 of the same publication where the private key is in the Chinese Remainder Theorem (CRT) format. RSADP is used as shorthand to refer to the RSA decryption primitive in SP 800-56Brev2. This test supports the 2048, 3072 and 4096-bit moduli. Usage Restriction: 2This test is mathematically equivalent to the comparable FIPS 186-5 test, and therefore, a vendor can claim compliance to FIPS 186-5 using this FIPS 186-4 test. However, all new testing is expected to use the FIPS 186-5 test. CMVP 29 08/30/2024 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program National Institute of Standards and Technology Shall only be used within the context of a SP 800-56Brev2 KTS (enforced by the module in that this CVL is not used internally for other purposes; but if external / operator-accessible enforced by operator guidance within the Security Policy, e.g., “the RSA Decryption Primitive SP800-56Brev2 (CVL) shall only be used within the context of a SP 800-56Brev2 KTS”). CAVP certificate and denotation: Within the context of the CAVP ACVTS, this component test is identified by the following algorithm/mode/revision capability combination: “algorithm”: “RSA”, “mode”: “decryptionPrimitive”, “revision”: ”Sp800-56Br2”. This testing is denoted by “RSA Decryption Primitive SP800-56Br2” on the CAVP webpage: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search 6. The key derivation functions from the following protocols and standards documented in SP 800-135rev1: IKEv1, IKEv2, TLS 1.0, 1.1 and 1.2, SSHv2, SRTP (using the 32-bit or 48-bit index value in SRTCP), SNMPv3, TPMv1.2, ANSI X9.63-2001 KDF and ANSI X9.42-2001 KDF. Usage Restriction: Shall only be used in the context of their respective protocols (enforced by the module in that this CVL is not used internally for other purposes; but if external / operator-accessible enforced by operator guidance within the Security Policy, e.g., “the KDF SSH (CVL) shall only be used within the context of the SSHv2 protocol”). CAVP certificate and denotation: Within the context of the CAVP ACVTS, these component tests are identified by the following algorithm/mode/revision capability combinations: “algorithm”: “kdf-components”, “revision”: ”1.0”, “mode”: “ikev1” | “ikev2” | “tls” | “ssh” | “srtp” | “snmp” | “tpm” | “ansix9.63” | “ansix9.42”; or “algorithm”: “TLS-v1.2”, “mode”: “KDF”, “revision”: ”RFC7627”. These tests are denoted by “KDF IKEv1”, “KDF IKEv2”, “KDF TLS”, “TLS v1.2 KDF RFC7627”, “KDF SSH”, “KDF SRTP”, “KDF SNMP”, “KDF TPM”, “KDF ANS 9.63” and “KDF ANS 9.42“ on the CAVP webpage: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation- search. 7. The TLS 1.3 key derivation function documented in Section 7.1 of RFC 8446. This is considered an approved CVL because the underlying functions performed within the TLS 1.3 KDF map to NIST approved standards, namely: SP 800-133rev2 (Section 6.3 Option #3), SP 800-56Crev2, and SP 800-108. U

Document Details

Tags

Related

Full Transcript

Upgrade to continue