|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/ap.belleisle/INFOSEC/stds/ |
Upload File : |
<HTML> <HEAD> <TITLE>FIPS 140-1 Implementation Guidance</TITLE> </HEAD> <body BACKGROUND="../yellow_p.gif"> <h2><center>National Institute of Standards and Technology</center></h2> <HR SIZE=4 WIDTH=75%> <h1><center>Implementation Guidance for<BR> FIPS PUB 140-1 and the Cryptographic Module Validation Program</center></h1> </h3><center><A HREF="http://www.nist.gov">National Institute of Standards and Technology</A><P> <A HREF="http://www.cse.dnd.ca">Communications Security Establishment</A></center></h3> <CENTER><STRONG>Last Update: 4/14/98</STRONG></CENTER><P> <HR SIZE=4 WIDTH=75%> <CENTER><STRONG>NOTE: Internal links will be added to this document in the near future...</STRONG></CENTER><P> <H2>Table of Contents</H2> <MENU> <LI>New Guidance and Modified Guidance (Issued within the last 30 days) <P> <UL><STRONG>New Guidance</STRONG><P> <LI><A HREF="1401ig.htm#relation"><B>G.7</B> Relationships Among Vendors, Laboratories, and NIST/CSE</A> <P> <LI><A HREF="1401ig-4.htm#9tripleDES"><B>9.4</B> Triple DES implementation within a 140-1 cryptomodule</A> <P> </UL> <UL><STRONG>Modified Guidance</STRONG><P> <LI><A HREF="1401ig.htm#FIPSmode"><B>G.6</B> Modules with both a FIPS mode and a non-FIPS mode</A> (i.e., modules containing both FIPS-approved and non-FIPS approved security methods) - modified for clarification on 4/2/98 <P> </UL><P> <HR SIZE=1 WIDTH=50%> <LI><A HREF="#overview">Overview</A> <P> <LI><A HREF="#general">General Issues</A> <UL> <LI><A HREF="#requests"><B>G.1</B> Implementation guidance requests to NIST and CSE</A> <LI><A HREF="#completion"><B>G.2</B> Completion of a validation - information that must be provided to NIST and CSE</A> <LI><A HREF="#partial"><B>G.3</B> Partial validations</A> <LI><A HREF="#designpolicy"><B>G.4</B> Design and testing of cryptographic modules</A> <LI><A HREF="#softval"><B>G.5</B> Maintaining validation compliance of software cryptographic modules</A> <LI><A HREF="#FIPSmode"><B>G.6</B> Modules with both a FIPS mode and a non-FIPS mode</A> <LI><A HREF="#relation"><B>G.7</B> Relationships Among Vendors, Laboratories, and NIST/CSE</A> </UL><P> <LI><A HREF="1401ig-2.htm#sec1">Section 1 - Cryptographic Module Design and Documentation</A> <UL> <LI><A HREF="1401ig-2.htm#1nonvalsub"><B>1.1</B> Non-validated security sub-elements</A> <LI><A HREF="1401ig-2.htm#1reval"><B>1.2</B> Re-validation of sub-elements</A> <LI><A HREF="1401ig-2.htm#1bound"><B>1.3</B> Cryptographic boundary must be fixed</A> <LI><A HREF="1401ig-2.htm#1submodule"><B>1.4</B> Limiting requirements on a sub-module within a cryptomodule</A> <LI><A HREF="1401ig-2.htm#1secpolicy"><B>1.5</B> Cryptomodule security policy</A> </UL><P> <LI><A HREF="1401ig-2.htm#sec2">Section 2 - Module Interfaces</A> <UL> <LI><A HREF="1401ig-2.htm#2maintint"><B>2.1</B> Maintenance access interface on a general purpose PC at Level 1</A> <LI><A HREF="1401ig-2.htm#2zeroize"><B>2.2</B> Zeroization requirements</A> <LI><A HREF="1401ig-2.htm#2pubkeyio"><B>2.3</B> Input/output of public keys versus secret and private keys</A> <LI><A HREF="1401ig-2.htm#2physport"><B>2.4</B> Using the same physical port for input and output of plaintext crypto keys</A> <LI><A HREF="1401ig-2.htm#2hwlogint"><B>2.5</B> Logical interfaces for hardware modules</A> </UL><P> <LI><A HREF="1401ig-2.htm#sec3">Section 3 - Roles and Services</A> <UL> <LI><A HREF="1401ig-2.htm#3maint"><B>3.1</B> Maintenance role requirement for power-on self-tests</A> <LI><A HREF="1401ig-2.htm#3delinserv"><B>3.2</B> Delineation of services between roles</A> <LI><A HREF="1401ig-2.htm#3showstat"><B>3.3</B> Implementation of the "Show Status" service</A> <LI><A HREF="1401ig-2.htm#3authmech"><B>3.4</B> Authentication mechanisms</A> <LI><A HREF="1401ig-2.htm#3idreqs"><B>3.5</B> Identity-based authentication requirements</A> <LI><A HREF="1401ig-2.htm#3maintzero"><B>3.6</B> Maintenance role and zeroization of unprotected critical security parameters (CSPs)</A> </UL><P> <LI><A HREF="1401ig-2.htm#sec4">Section 4 - Finite State Machine Model</A> <P> <UL> <LI><A HREF="1401ig-2.htm#4format"><B>4.1</B> FSM and Security Policy consolidation and formatting</A> </UL><P> <LI><A HREF="1401ig-3.htm#sec5">Section 5 - Physical Security</A> <UL> <LI><A HREF="1401ig-3.htm#5coating"><B>5.1</B> Conformal coating features</A> <LI><A HREF="1401ig-3.htm#5tamplogint"><B>5.2</B> Tamper evidence requirements and logical module interfaces for PC-like modules</A> <LI><A HREF="1401ig-3.htm#5embtamp"><B>5.3</B> Additional tamper evidence for embedded modules</A> <LI><A HREF="1401ig-3.htm#5tampev34"><B>5.4</B> Tamper evidence for cryptomodules with physical security at levels 3 and 4</A> <LI><A HREF="1401ig-3.htm#5lev2mcs"><B>5.5</B> Physical security requirements (Level 2) for multi-chip standalone cryptographic modules</A> <LI><A HREF="1401ig-3.htm#5keyloader"><B>5.6</B> Key loader physical security requirements at Level 3</A> <LI><A HREF="1401ig-3.htm#5tamprespzero"><B>5.7</B> Tamper response/zeroization circuitry on removable covers and doors for embedded and standalone modules</A> </UL><P> <LI><A HREF="1401ig-3.htm#sec6">Section 6 - Software Security</A> <P> <LI><A HREF="1401ig-3.htm#sec7">Section 7 - Operating System Security</A> <UL> <LI><A HREF="1401ig-3.htm#7swauthent"><B>7.1</B> Authentication of cryptographic software within a cryptomodule</A> <LI><A HREF="1401ig-3.htm#7lev2eval"><B>7.2</B> Level 2 O/S Requirements - Use of TCSEC, ITSEC, and CTCPEC Evaluations</A> </UL><P> <LI><A HREF="1401ig-4.htm#sec8">Section 8 - Cryptographic Key Management</A> <UL> <LI><A HREF="1401ig-4.htm#8fipskeymeth"><B>8.1</B> List of FIPS-approved key management methods</A> <LI><A HREF="1401ig-4.htm#8pubkeymeth"><B>8.2</B> Using various public-key methods for key management/distribution</A> <LI><A HREF="1401ig-4.htm#8keyload"><B>8.3</B> Use of key loaders and its implications</A> <LI><A HREF="1401ig-4.htm#8fips171"><B>8.4</B> Use and testing of FIPS 171 key distribution techniques</A> <LI><A HREF="1401ig-4.htm#8ivreqs"><B>8.5</B> Initialization Vector (IV) requirements</A> </UL><P> <LI><A HREF="1401ig-4.htm#sec9">Section 9 - Cryptographic Algorithms</A> <UL> <LI><A HREF="1401ig-4.htm#9fipsalgs"><B>9.1</B> FIPS-approved algorithms</A> <LI><A HREF="1401ig-4.htm#9noalgs"><B>9.2</B> Cryptomodule with no FIPS-approved algorithms cannot be validated</A> <LI><A HREF="1401ig-4.htm#9shagran"><B>9.3</B> SHA-1 granularity</A> <LI><A HREF="1401ig-4.htm#9tripleDES"><B>9.4</B> Triple DES implementation within a 140-1 cryptomodule</A> </UL><P> <LI><A HREF="1401ig-4.htm#sec10">Section 10 - EMI/EMC</A> <UL> <LI><A HREF="1401ig-4.htm#10fccreqs"><B>10.1</B> FCC Testing and Certification Requirements</A> </UL> <P> <LI><A HREF="1401ig-4.htm#sec11">Section 11 - Self Tests</A> <UL> <LI><A HREF="1401ig-4.htm#11perfst"><B>11.1</B> Performing power-up and conditional self-tests</A> <LI><A HREF="1401ig-4.htm#11dsakat"><B>11.2</B> Known answer test for DSA</A> <LI><A HREF="1401ig-4.htm#11loadcontrol"><B>11.3</B> Control of firmware or software loads</A> <LI><A HREF="1401ig-4.htm#11edcreqs"><B>11.4</B> Error Detection Code (EDC) requirements</A> </UL><P> <LI><A HREF="1401ig-5.htm">Expired implementation guidance</A> <P> </MENU> <HR SIZE=4 WIDTH=75%> <H2><A NAME="overview">Overview</A></H2> 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, <EM>Security Requirements for Cryptographic Modules</EM>. 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.<P> This document is intended to provide clarifications of the CMVP, and in particular, clarifications and guidance pertaining to the <EM>Derived Test Requirements (DTR)</EM>, 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. <EM>However, information in this document is subject to change by NIST and CSE.</EM><P> 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. <EM>(Note: For each subject, there may be additional test and vendor requirements which apply.)</EM> 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.<P> Below is a list of where the reader can find related documentation: <UL> <LI><A HREF="fip140-1.htm">FIPS PUB 140-1</A> <LI><A HREF="1401annc.htm">Announcement of the CMVP</A> <LI><A HREF="140test1.htm">Derived Test Requirements for FIPS PUB 140-1</A> <LI><A HREF="1401val.htm">Cryptographic Module Validation List</A> </UL> <HR SIZE=4 WIDTH=75%> <H2><A NAME="general"><CENTER>General Issues</CENTER></A></H2> <H3><EM><A NAME="requests">G.1 Implementation guidance requests to NIST and CSE</A></EM></H3> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>2/25/97-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM>11/24/97</EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> To whom should implementation guidance requests be directed? Is there a defined format for those requests?<P> <H4>Resolution</H4> <UL> <LI><EM>Programmatic Questions:</EM> Questions concerning the general operation of the CMV Program can be directed to either NIST or CSE. Here are the appropriate points of contact:<P> <UL> <LI><STRONG>NIST</STRONG><BR> <A HREF="mailto:[email protected]">Jim Foti</A><BR> (301) 975-5237<P> <LI><STRONG>CSE</STRONG><BR> <EM>(11/24/97)</EM><BR> <A HREF="mailto:[email protected]">Tom Casar</A><BR> (613) 991-7202<P> </UL><P> <LI><EM>Test-specific Questions:</EM> 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.<P> 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:<P> <UL> <LI><STRONG>NIST</STRONG><BR> <A HREF="mailto:[email protected]">Ray Snouffer</A><BR> (301) 975-4436<P> <LI><STRONG>CSE</STRONG><BR> <EM>(11/24/97)</EM><BR> <A HREF="mailto:[email protected]">Tom Casar</A><BR> (613) 991-7202<P> </UL><P> 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:<P> <OL> <LI>Applicable statement(s) from FIPS 140-1, <LI>Applicable assertion(s) from the DTR, <LI>Applicable required test procedure(s) from the DTR, <LI>A concise statement of the problem, followed by a clear and unambiguous question regarding the problem, and <LI>A statement of the resolution that is being sought. </OL><P> <EM>(4/25/97)</EM><BR> 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. </UL> <EM>***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).</EM><P> <H4>Additional Comments</H4> <P> <HR SIZE=4 WIDTH=50%> <H3><EM><A NAME="completion">G.2 Completion of a validation - information that must be provided to NIST and CSE</A></EM></H3> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>2/25/97-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM></EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> What information should be provided to NIST and CSE upon completion of validation testing, in order for a vendor to receive a validation certificate? <P> <H4>Resolution</H4> The following information shall be provided to both NIST and CSE by the testing laboratory:<P> <OL> <LI>A <EM>non-proprietary</EM> version of the VALIDATION REPORT, which shall include (at a minimum):<P> <OL TYPE=a> <LI>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.<P> <LI>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.<P> </OL> <LI>A <EM>non-proprietary</EM> 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.<P> <LI>(IF APPLICABLE) A <EM>non-proprietary</EM> version of the laboratory's physical testing report, for cryptomodules with physical security at <EM>level 2 and above</EM>.<P> <LI>In addition to items 1-3 above, the lab has the option to provide <EM>proprietary</EM> versions of those items, but this is not required by NIST and CSE. </OL> <EM>***NOTE: NIST and CSE must have items 1-3 above before a validation certificate will be issued.***</EM> <P> <H4>Additional Comments</H4> 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. <P> <HR SIZE=4 WIDTH=50%> <H3><EM><A NAME="partial">G.3 Partial validations</A></EM></H3> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>2/25/97-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM></EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> What is the position of NIST and CSE regarding partial validations? <P> <H4>Resolution</H4> 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. <P> <H4>Additional Comments</H4> <P> <HR SIZE=4 WIDTH=50%> <H3><EM><A NAME="designpolicy">G.4 Design and testing of cryptographic modules</A></EM></H3> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>11/12/97-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM></EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> What activities may CMT laboratories perform, regarding the design and testing of cryptomodules? <P> <H4>Resolution</H4> 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:<P> <OL> <LI>A CMT Laboratory <I>may not</I> perform validation testing on a module for which the laboratory has:<P> <OL TYPE=a> <LI>designed any part of the module, <LI>developed original documentation for any part of the module, <LI>built, coded or implemented any part of the module, or <LI>any ownership or vested interest in the module. </OL><P> <LI>Provided that a CMT Laboratory has met the above requirements, the laboratory <I>may</I> perform validation testing on modules produced by a company when:<P> <OL TYPE=a> <LI>the laboratory has no ownership in the company, <LI>the laboratory has a completely separate management from the company, and <LI>business between the CMT Laboratory and the company is performed under contractual agreements, as done with other clients. </OL><P> <LI>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. </OL> <P> <H4>Additional Comments</H4> Also see Guidance <A HREF="1401ig-2.htm#4format">4.1</A>, regarding FSM and Security Policy consolidation and formatting. <P> <HR SIZE=4 WIDTH=50%> <H3><EM><A NAME="softval">G.5 Maintaining validation compliance of software cryptographic modules</A></EM></H3> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>11/24/97-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM></EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> For a validated software cryptographic module, how may such a module be implemented so that compliance with the validation is maintained? <P> <H4>Resolution</H4> <OL> <LI>The tested/validated configuration is stated on the validation certificate. The certificate serves as the benchmark for the module-compliant configuration. <P> <LI>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:<P> <OL TYPE=a> <LI>the GPC uses the specified single user operating system/mode specified on the valiation certificate, or another compatible single user operating system, and<P> <LI>the software of the cryptomodule does not require modification when ported (platform specific configuration modifications are excluded). </OL><P> <LI>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:<P> <OL TYPE=a> <LI>the GPC incorporates the specified evaluated C2 (or <A HREF="1401ig-3.htm#7lev2eval">equivalent</A>) operating system/mode/operational settings or another compatible evaluated C2 (or <A HREF="1401ig-3.htm#7lev2eval">equivalent</A>) operating system with like mode and operational settings, and<P> <LI>the software of the cryptographic module does not require modification when ported (platform-specific configuration settings are excluded). </OL><P> </OL> 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. <P> <H4>Additional Comments</H4> <EM><U>Note that this guidance is particularly relevant to <STRONG>USERS</STRONG> who are implementing a software module.</U></EM> <P> <HR SIZE=4 WIDTH=50%> <H3><EM><A NAME="FIPSmode">G.6 Modules with both a FIPS mode and a non-FIPS mode</A></EM></H3> (i.e., modules containing both FIPS-approved and non-FIPS approved security methods)<P> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>3/11/98-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM>4/2/98</EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> How can a module be defined, when it includes both FIPS-approved and non-FIPS approved security methods? <P> <H4>Resolution</H4> <EM>(4/2/98)</EM> A module that contains both FIPS-approved and non-FIPS approved security methods shall have at least one "FIPS mode of operation" - which <EM>only</EM> 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 <U><STRONG>SHALL NOT</STRONG></U> 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. <P> The FIPS 140-1 validation certificate will identify the cryptomodule's "FIPS mode" of operation. <P> 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. <P> There is no requirement that the selection of a "FIPS mode" be permanent. <P> <H4>Additional Comments</H4> FIPS 140-1 gives several examples of "FIPS approved security methods" in <A HREF="/fips/fips1401.htm#sec2.1">Section 2.1</A>, including "e.g., cryptographic algorithm, cryptographic key generation algorithm or key distribution technique, authentication technique, or evaluation criteria". <P> <HR SIZE=4 WIDTH=50%> <H3><EM><A NAME="relation">G.7 Relationships Among Vendors, Laboratories, and NIST/CSE</A></EM></H3> <P> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG>ALL</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>4/14/98-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM></EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD>General</TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> What is the Cryptographic Module Validation Program policy regarding the relationships among vendors, testing laboratories, and NIST/CSE? <P> <H4>Policy</H4> 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. <P> 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 <A HREF="#requests">G.1</A> and the point of contact at the laboratory <STRONG><EM>must</EM></STRONG> be carbon copied. All correspondence from NIST/CSE to the vendor on the issue will be issued through the laboratory point of contact. <P> <H4>Additional Comments</H4> <P> <HR SIZE=4 WIDTH=50%> More FIPS 140-1 Guidance:<P> <UL> <LI><A HREF="1401ig-2.htm">Part 2: Sections 1-4</A> <LI><A HREF="1401ig-3.htm">Part 3: Sections 5-7</A> <LI><A HREF="1401ig-4.htm">Part 4: Sections 8-11</A> <LI><A HREF="1401ig-5.htm">Part 5: Expired Guidance</A> </UL> <P> <!-- The following is a template for each guidance <H3><EM><A NAME="targetname">TITLE</A></EM></H3> <TABLE BORDER=2 WIDTH=50%> <TR WIDTH=40%> <TD><EM>Applicable Levels:</EM></TD> <TD><STRONG></STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Effective Dates:</EM></TD> <TD><STRONG>2/25/97-</STRONG></TD> </TR> <TR WIDTH=40%> <TD><EM>Last Modified:</EM></TD> <TD><EM></EM></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Assertions:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Test Requirements:</EM></TD> <TD></TD> </TR> <TR WIDTH=40%> <TD><EM>Relevant Vendor Requirements:</EM></TD> <TD></TD> </TR> </TABLE> <P> <HR WIDTH=10%> <P> <H4>Question/Problem</H4> <P> <H4>Resolution</H4> <P> <H4>Additional Comments</H4> <P> <HR SIZE=4 WIDTH=50%> --> </BODY> </HTML>