[Federal Register Volume 74, Number 237 (Friday, December 11, 2009)]
[Notices]
[Pages 65753-65755]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: E9-29567]



[[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: [email protected]. 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