National Institute of Standards and Technology
Implementation Guidance for
FIPS PUB 140-1 and the Cryptographic Module Validation Program
National Institute of Standards and Technology
Communications Security Establishment
Last Update: 4/14/98
NOTE: Internal links will be added to this document in the near future...
Table of Contents
This Implementation Guidance document is issued and maintained by the U.S. Government's National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE) of the Government of Canada, which serve as the validation authorities of the Cryptographic Module Validation Program (CMVP) for their respective governments. The CMVP is a program under which NVLAP accredited Cryptographic Module Testing (CMT) laboratories test cryptographic modules for conformance to Federal Information Processing Standard Publication (FIPS PUB) 140-1, Security Requirements for Cryptographic Modules. In addition, this program covers the testing of FIPS-approved cryptographic algorithms, including the Data Encryption Algorithm, Digital Signature Algorithm, Secure Hash Algorithm, and Skipjack Algorithm.
This document is intended to provide clarifications of the CMVP, and in particular, clarifications and guidance pertaining to the Derived Test Requirements (DTR), which is used by CMT laboratories to test for a cryptomodule's conformance to FIPS PUB 140-1. Guidance presented in this document is based on responses issued by NIST and CSE to questions posed by the CMT labs, vendors, and other interested parties. However, information in this document is subject to change by NIST and CSE.
Each section of this document corresponds with a requirements section of FIPS PUB 140-1, with an additional first section containing general guidance that is not applicable to any particular requirements section. 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.
Below is a list of where the reader can find related documentation:
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
11/24/97 |
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
To whom should implementation guidance requests be directed? Is there a defined format for those requests?
Resolution
- Programmatic Questions: Questions concerning the general operation of the CMV Program can be directed to either NIST or CSE. Here are the appropriate points of contact:
- Test-specific Questions: If a vendor is under contract with a CMT lab for 140-1 or algorithm testing, then the vendor should contact the lab with any questions concerning the test requirements. This allows the lab representatives to use their expertise in 140-1 testing to answer those questions, and it acts as a filter for NIST and CSE.
Agencies, departments, vendors not under contract with a CMT lab, and CMT labs themselves who have specific questions about a 140-1 test requirement should contact the appropriate NIST and CSE points of contact:
All test-specific questions asking for implementation guidance shall have the following form, in order for NIST and CSE to understand the question as clearly as possible, and to provide an appropriate response:
- Applicable statement(s) from FIPS 140-1,
- Applicable assertion(s) from the DTR,
- Applicable required test procedure(s) from the DTR,
- A concise statement of the problem, followed by a clear and unambiguous question regarding the problem, and
- A statement of the resolution that is being sought.
(4/25/97)
All questions should be presented in a detailed, implementation-specific format, rather than an academic or hypothetical format. This information should also include a brief description of the implementation and the FIPS 140-1 target level. All of this will enable a more efficient and timely resolution of 140-1 related questions by NIST and CSE. When appropriate, NIST and CSE will derive general guidance from the problem and response, and add that guidance to this document. Note that general questions may still be submitted, but these questions should be identified as not being associated with a particular validation effort.
***Note that NIST and CSE will only issue official, written responses when the original request is submitted in writing (e-mail and fax are also acceptable).
Additional Comments
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
What information should be provided to NIST and CSE upon completion of validation testing, in order for a vendor to receive a validation certificate?
Resolution
The following information shall be provided to both NIST and CSE by the testing laboratory:
- A non-proprietary version of the VALIDATION REPORT, which shall include (at a minimum):
- Summary Report - a single page which lists the various requirements sections, their target level, the status of each area for that level (passed/failed/not applicable), and the overall level for which the module passed validation testing.
- Detailed Report with assessments (and notes, if applicable) - the information in the assessments and notes fields shall include remarks about the module, and briefly explain how the requirement is passed, failed, or not applicable. If specific guidance was issued by NIST and CSE for this cryptomodule during validation testing, then this guidance shall be addressed in the appropriate area(s) of the report.
- A non-proprietary version of the cryptographic module's SECURITY POLICY. For an explanation of this, see the guidance "Cryptomodule security policy" in Section 1 of this document.
- (IF APPLICABLE) A non-proprietary version of the laboratory's physical testing report, for cryptomodules with physical security at level 2 and above.
- In addition to items 1-3 above, the lab has the option to provide proprietary versions of those items, but this is not required by NIST and CSE.
***NOTE: NIST and CSE must have items 1-3 above before a validation certificate will be issued.***
Additional Comments
A copy of each of the above items shall be mailed directly to both NIST and CSE, in order to expedite the review and certificate issuance processes.
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
What is the position of NIST and CSE regarding partial validations?
Resolution
NIST and CSE will not issue a validation certificate unless a cryptomodule meets at least Level 1 security requirements for each area in section 4 of FIPS PUB 140-1. Note that in some cases, a requirements area might not be applicable to the cryptomodule being tested (e.g., "Operating System"). In those cases, the validation certificate will indicate "N/A" for that requirement.
Additional Comments
| Applicable Levels: |
ALL |
| Effective Dates: |
11/12/97- |
| Last Modified: |
|
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
What activities may CMT laboratories perform, regarding the design and testing of cryptomodules?
Resolution
The following information is supplemental to the guidance provided by NVLAP, and further defines the separation of the design, consulting, and testing roles of the laboratories. CMV Program policy in this area is as follows:
- A CMT Laboratory may not perform validation testing on a module for which the laboratory has:
- designed any part of the module,
- developed original documentation for any part of the module,
- built, coded or implemented any part of the module, or
- any ownership or vested interest in the module.
- Provided that a CMT Laboratory has met the above requirements, the laboratory may perform validation testing on modules produced by a company when:
- the laboratory has no ownership in the company,
- the laboratory has a completely separate management from the company, and
- business between the CMT Laboratory and the company is performed under contractual agreements, as done with other clients.
- A CMT Laboratory may perform consulting services to provide clarification of FIPS 140-1, the Derived Test Requirements, and other associated documents at any time during the life cycle of the module.
Additional Comments
Also see Guidance 4.1, regarding FSM and Security Policy consolidation and formatting.
| Applicable Levels: |
ALL |
| Effective Dates: |
11/24/97- |
| Last Modified: |
|
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
For a validated software cryptographic module, how may such a module be implemented so that compliance with the validation is maintained?
Resolution
- The tested/validated configuration is stated on the validation certificate. The certificate serves as the benchmark for the module-compliant configuration.
- For level 1 Operating System Security, the software cryptomodule will remain compliant with the FIPS 140-1 validation when operating on any general purpose computer (GPC) provided that:
- the GPC uses the specified single user operating system/mode specified on the valiation certificate, or another compatible single user operating system, and
- the software of the cryptomodule does not require modification when ported (platform specific configuration modifications are excluded).
- For level 2 Operating System Security the software cryptographic module will remain compliant with the FIPS 140-1 validation when operating on any GPC provided that:
- the GPC incorporates the specified evaluated C2 (or equivalent) operating system/mode/operational settings or another compatible evaluated C2 (or equivalent) operating system with like mode and operational settings, and
- the software of the cryptographic module does not require modification when ported (platform-specific configuration settings are excluded).
This policy only addresses a module's operating system configuration and does not affect requirements of the other sections of FIPS 140-1. A module must meet all requirements of the level stated. The GPC used with the cryptographic software must meet all physical requirements met by the test platform listed on the validation certificate.
Additional Comments
Note that this guidance is particularly relevant to USERS who are implementing a software module.
(i.e., modules containing both FIPS-approved and non-FIPS approved security methods)
| Applicable Levels: |
ALL |
| Effective Dates: |
3/11/98- |
| Last Modified: |
4/2/98 |
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
How can a module be defined, when it includes both FIPS-approved and non-FIPS approved security methods?
Resolution
(4/2/98) A module that contains both FIPS-approved and non-FIPS approved security methods shall have at least one "FIPS mode of operation" - which only allows for the operation of FIPS-approved security methods. This means that when a module is in the "FIPS mode", a non-FIPS approved method SHALL NOT be used in lieu of a FIPS-approved method (For example, if a module contains both MD5 and SHA-1, then when hashing is required in the FIPS mode, SHA-1 must be used.). The operator must be made aware of which services are FIPS 140-1 compliant.
The FIPS 140-1 validation certificate will identify the cryptomodule's "FIPS mode" of operation.
The selection of "FIPS mode" does not have to be restricted to any particular operator of the module. However, each operator of the module must be able to determine whether or not the "FIPS mode" is selected.
There is no requirement that the selection of a "FIPS mode" be permanent.
Additional Comments
FIPS 140-1 gives several examples of "FIPS approved security methods" in Section 2.1, including "e.g., cryptographic algorithm, cryptographic key generation algorithm or key distribution technique, authentication technique, or evaluation criteria".
| Applicable Levels: |
ALL |
| Effective Dates: |
4/14/98- |
| Last Modified: |
|
| Relevant Assertions: |
General |
| Relevant Test Requirements: |
|
| Relevant Vendor Requirements: |
|
Question/Problem
What is the Cryptographic Module Validation Program policy regarding the relationships among vendors, testing laboratories, and NIST/CSE?
Policy
The CMT laboratories are accredited by NVLAP to perform cryptographic module validation testing to determine compliance with FIPS 140-1. NIST/CSE rely on the CMT laboratories to use their extensive validation testing experience and expertise to make sound, correct, and independent decisions based on FIPS 140-1, the Derived Test Requirements, and Implementation Guidance. Once a vendor is under contract with a laboratory, NIST/CSE will only provide official guidance and clarification for the vendor's module through the point of contact at the laboratory.
In a situation where the vendor and laboratory are at an unresolvable impasse over a testing issue, the vendor may ask for clarification/resolution directly from NIST/CSE. The vendor should use the format required by Implementation Guidance G.1 and the point of contact at the laboratory must be carbon copied. All correspondence from NIST/CSE to the vendor on the issue will be issued through the laboratory point of contact.
Additional Comments
More FIPS 140-1 Guidance: