| Donate $25 for two DVDs of the Cryptome collection of files from June 1996 to the present |
11 December 2009
[Federal Register: December 11, 2009 (Volume 74, Number 237)][Notices] [Page 65753-65755] From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr11de09-34] [[Page 65753]] ----------------------------------------------------------------------- DEPARTMENT OF COMMERCE National Institute of Standards and Technology [Docket No.: [070321067-91333-02] Announcing Revised Draft Federal Information Processing Standard (FIPS) 140-3, Security Requirements for Cryptographic Modules AGENCY: National Institute of Standards and Technology (NIST), Commerce. ACTION: Notice; request for comments. ----------------------------------------------------------------------- SUMMARY: The National Institute of Standards and Technology (NIST) announces the Revised Draft Federal Information Processing Standard 140-3, Security Requirements for Cryptographic Modules, for public review and comment. The draft standard, designated ``Revised Draft FIPS 140-3,'' is proposed to supersede FIPS 140-2. DATES: Comments must be received on or before March 11, 2010. ADDRESSES: Written comments may be sent to: Chief, Computer Security Division, Information Technology Laboratory, Attention: Dr. Michaela Iorga, 100 Bureau Drive, Mail Stop 8930, National Institute of Standards and Technology, Gaithersburg, MD 20899-8930. Electronic comments may also be sent to: FIPS140-3@nist.gov. The proposed revised standard can be reviewed electronically at http://csrc.nist.gov/ publications/PubsDrafts.html. The complete set of all comments received in response to the July 2007 notice and NIST's responses to these comments may be accessed at http://csrc.nist.gov/groups/ST/documents/ CommentsFIPS140-3_draft1.pdf. The current FIPS 140-2 standard can be found at: http://csrc.nist.gov/publications/PubsFIPS.html. FOR FURTHER INFORMATION CONTACT: Dr. Michaela Iorga, Computer Security Division, 100 Bureau Drive, Mail Stop 8930, National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, Telephone (301) 975-8431. SUPPLEMENTARY INFORMATION: FIPS 140-1, Security Requirements for Cryptographic Modules, was issued in 1994 and was superseded by FIPS 140-2 in 2001. FIPS 140-2 identifies requirements for four security levels for cryptographic modules to provide for a wide spectrum of data sensitivity (e.g., low value administrative data, million dollar funds transfers, and life protecting data), and a diversity of application environments. Under NIST's Cryptographic Module Validation Program (CMVP), over 2000 modules have been tested by accredited private-sector laboratories and validated as conforming to FIPS 140-1 and FIPS 140-2. FIPS 140-2 provided that it be reviewed within five years to address new and revised requirements that might be needed to meet technological and economic changes. In 2005, NIST announced that it planned to develop FIPS 140-3 and solicited public comments on new and revised requirements for cryptographic systems. On January 12, 2005, a notice was published in the Federal Register (70 FR 2122), soliciting public comments on a proposed revision of FIPS 140-2. The comments received by NIST supported reaffirmation of the standard, but suggested technical modifications to address advances in technology that had occurred after the standard had been approved. Using these comments, NIST prepared a Draft FIPS 140-3 (hereafter referred to as the ``2007 Draft''), which was announced for review and comment in the Federal Register (72 FR 38566) on July 13, 2007. NIST developed the Revised Draft FIPS 140-3 that is announced in this notice using the comments received in response to the July 13, 2007 notice and the feedback on requirements for software cryptographic modules obtained during the March 18, 2008 FIPS 140-3 Software Security Workshop organized by NIST. Comments and questions regarding the 2007 Draft were submitted by approximately 45 entities, including two U.S. federal government organizations, two government organizations of other countries, thirty private sector and research organizations, ten private individuals, and one or more anonymous reviewers. These comments have all been made available by NIST at http://csrc.nist.gov/groups/ST/documents/ CommentsFIPS140-3_draft1.pdf. None of the comments opposed the approval of a revised standard. Some comments asked for clarification of the text of the standard or recommended editorial and formatting changes. Other comments suggested modifying requirements, or applying the requirements at a different security level. All of the suggestions, questions and recommendations within the scope of the FIPS revision were carefully reviewed, and changes were made to the standard, where appropriate. Some reviewers submitted questions or raised issues that are related but outside the scope of this FIPS. Comments that were outside of scope of the FIPS revision were deferred for later consideration in the context of the NIST/CMVP supporting documents. The primary interests and issues that were raised in the comments included implementability, testability, performance, usability and cost. Detailed technical comments covered issues including the following: Authentication mechanisms; non-invasive attacks; random bit generators (RBGs); randomness of Initialization Vectors (IVs); operating system requirements; zeroization; status indicators; issues regarding the cryptographic module boundary and computing environment; and issues pertaining to self-testing requirements. The following is a summary and analysis of the comments received and NIST's responses to them: Comment: The 2007 Draft required the module to directly prevent the selection of weak passwords for password-based authentication mechanisms. Eighteen commenters stated that this requires standardized guidance on weak passwords and Personal Identification Numbers (PINs) and also implies that modules are required to store multi-language dictionaries, which is impractical in many cases. Response: NIST removed the requirement that the cryptographic module directly prevent selection of weak passwords. Comment: The 2007 Draft required that default authentication data be unique per module unit delivered if the module employs default authentication data to control access to the module for first-time authentication. Six commenters stated that this is an onerous requirement for vendors who deliver high volume products, and is unnecessary given the requirement to change the authentication data upon first use. Response: NIST removed the requirement that the default authentication data be unique per module unit delivered. Comment: The 2007 Draft specified Mitigation of Simple Power Analysis (SPA) attacks at Security Level 4. Eight commenters stated that this requirement should be introduced at a lower level (Security Level 2 or 3) for consistency with tamper evidence requirements, with stronger requirements at Security Levels 3 and 4. Similarly, the 2007 Draft specified that Mitigation of Differential Power Analysis (DPA) attacks is required starting with the Security Level 4. Eight commenters stated that this requirement should be introduced at Security Level 2 or 3. Response: The tamper evidence mechanisms specified at Security Level [[Page 65754]] 2 provide security against an unprepared attacker. While SPA and DPA attacks leave no physical traces of the attack, they require, in addition to access to the module's power line, minimum equipment to collect the data; therefore, the attacker has to be prepared with appropriate equipment. NIST determined that protection against non- invasive attacks is required starting with the Security Level 3 to provide consistent protection for the modules Critical Security Parameters (CSPs). Comment: Four comments were received about the manual entry and display of Sensitive Security Parameters (SSP), such as passwords. These comments focused on password change operations, since other requirements apply to password entry for authentication. Response: The standard does not mandate visual verification of SSPs during manual entry; rather, it permits the option that, when SSPs are long and possibly in hexadecimal representation, they may be temporarily displayed to allow visual verification for improved accuracy. This flexibility is retained in the Revised Draft FIPS 140-3. In addition, the concept of the Trusted Channels and its use for input/ output of SSPs at Security Levels 3 and 4 is clarified in the Revised Draft FIPS 140-3. Comment: Twenty-one comments were received regarding conflicts in the specifications pertaining to Random Bit Generator (RBG) entropy sources and difficulties in satisfying the RBG self-testing requirements during conditional self-tests. Response: NIST considered all comments related to the Random Bit Generator (RBG) Entropy Source Test, and removed the RBG Entropy Source Test from the list of required conditional self-tests in the Revised Draft FIPS 140-3. For consistency, the Revised Draft FIPS 140-3 defines the minimum entropy as the min-entropy defined in NIST SP 800-90, ``Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)'', as amended, and points to it for additional requirements. Comment: Thirty-one commenters stated that ambiguities in the Operating System Requirements for Modifiable Operational Environments needed to be clarified. Depending on how the various terms were interpreted these requirements might be impossible to satisfy. Response: The entire section 4.5.1 ``Operating System Requirements for Modifiable Operational Environments'' has been re-written to improve clarity. Comment: Three comments were received indicating that thorough review of the 2007 Draft required access to all annexes pertaining to the standard. Response: All annexes (A through F) pertaining to the Revised Draft FIPS 140-3 have been made available for concurrent review with the Revised Draft FIPS. Comment: One comment was received recommending a key status indicator to show whether the module is keyed, not keyed, or zeroized. Response: The Revised Draft FIPS requires a physical or logical status indicator, but only for self-tests and error states. Comment: Two comments were received noting that zeroization for physical security reasons must occur in a sufficiently small time period to prevent the recovery of sensitive data, but no such constraints were indicated in the 2007 Draft. Response: NIST updated the Revised Draft FIPS to specify that zeroization shall be immediate and non-interruptible and shall occur in a sufficiently small time period so as to prevent the recovery of the sensitive data between the time zeroization is initiated and the actual zeroization completed. Comment: Two comments were received stating that operating system requirements disallowed most debuggers and suggested an exception for maintenance mode. Response: NIST restored the maintenance role and allowed debuggers when operating in maintenance mode. The operating system shall prevent all operators and running processes from modifying running cryptographic processes (i.e., loaded and executing cryptographic program images) only when not in the maintenance mode. In this case, running processes refer to all processes, cryptographic or not, not owned or initiated by the operating system (i.e., operator-initiated). Comment: The 2007 Draft defined the cryptographic module's electrical power as a physical port. Two comments were received regarding the requirements applicable to the power port in order to restrict unintended information flow. Response: NIST defined a ``power interface'' for the cryptographic module and replaced all references to ``power port'' with ``power interface'' in the Revised Draft FIPS. No additional requirements related to power interfaces were added. Clarifications triggered by questions related to this topic will be addressed in standard's supplementary documentation such as the ``FIPS 140-3 Implementation Guidance''. Comment: Six comments were received regarding the specified false acceptance rate (FAR) of 1 in 10[caret]8 for authentication mechanisms in the 2007 Draft, and noted that the 2007 Draft was silent with respect to false rejection rate (FRR). Some comments suggested that the engineering tradeoffs required to achieve an FAR of 10[caret]8 will have a strongly negative impact on usability. Response: NIST reviewed the requirements for group authentication mechanism and acknowledges the impact of such requirement on usability and on the FRR of cryptographic modules using multi-factor authentication mechanisms. The requirement was removed from the Revised Draft FIPS and will be addressed in the Implementation Guidance or other supplemental documentation. Comment: Eleven comments were received regarding the self-testing requirements specified by the 2007 Draft. The commenters considered the requirements inappropriate for devices with aggressive power conservation modes, such as newer portable devices and embedded devices. Response: NIST reviewed the self-test section and redefined the cases when the pre-operational self-tests must be performed. Comment: One comment was received highlighting a conflict between self-tests for random bit generators (RBGs) and NIST Special Publication (SP) 800-90. Response: NIST reviewed the self-test section and removed the conflicting requirement from the continuous RBG test section of the draft. In addition to the public comment period, NIST hosted a public workshop on March 18, 2008 to obtain additional feedback on requirements for software crypto modules. The FIPS 140-3 Software Security Workshop addressed a range of topics, including the following: single user mode at Security Level 1; the logical boundary of a software module; the modifiable operational environment; audit logs; software integrity tests; ``firmware'' modules; security strength of a crypto module; and the number of security levels for software modules. Based on the combination of public comments and the discussions at the FIPS 140-3 Software Security Workshop, NIST implemented further changes to rationalize and simplify the security levels in the Revised Draft FIPS 140-3. In particular, the Revised Draft FIPS 140-3 specifies four security levels instead of five, reintroduces the notion of firmware cryptographic module and [[Page 65755]] defines the security requirements for it, limits the overall security level for software cryptographic modules of Security Level 2, and removes the formal model requirement. The following significant substantive differences between this Revised Draft FIPS 140-3 and the current FIPS 140-2 standard are noted: Inclusion of a separate section for software security; limiting the overall security level for software cryptographic modules of Security Level 2; requirement for modules to mitigate against the non-invasive attacks when validating at higher security levels; introduction of the concept of public security parameters; allowing modules to defer various self-tests until specified conditions are met; removing the formal model requirement; and strengthening the requirements for integrity testing. The Revised Draft FIPS 140-3 can be found at http://csrc.nist.gov/ publications/PubsDraft.html, and is available for public review and comment. Prior to the submission of this proposed revised standard to the Secretary of Commerce for review and approval, it is essential that consideration is given to the needs and views of the public, users, the information technology industry, and Federal, State and local government organizations. The purpose of this notice is to solicit such views. Authority: Federal Information Processing Standards (FIPS) are issued by the National Institute of Standards and Technology after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Management Reform Act of 1996 and the Federal Information Security Management Act of 2002 (Pub. L. 107- 347). E.O. 12866: This notice has been determined not be significant for the purpose of E.O. 12866. Dated: December 7, 2009. Patrick Gallagher, Director. [FR Doc. E9-29567 Filed 12-10-09; 8:45 am] BILLING CODE 3510-13-P