National Institute of Standards and Technology
Implementation Guidance for FIPS PUB 140-1, continued
PART 2 (sections 1-4)
Continued from Part 1 (Overview/General)
Go to:
NOTE: Internal links will be added to this document in the near future...
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
General, AS01.01 |
| Relevant Test Requirements: |
TE01.01.01-.03 |
| Relevant Vendor Requirements: |
VE01.01.01 |
Question/Problem
Will a FIPS PUB 140-1 certificate be issued for a cryptomodule containing non-validated security sub-elements? Or must a vendor use only security-relevant components and sub-elements for which they have complete design information in order to receive FIPS PUB 140-1 validation?
Resolution
It is recognized that vendors may implement security-related cryptomodule sub-elements that are developed by another vendor (e.g., a DES chip). It is the testing laboratory's responsibility, however, to ensure that all security-related functions and elements contained in the cryptomodule meet test requirements. Even if a cryptomodule's sub-elements are proprietary or classified, the laboratory shall have access to the following information:
- security functions performed by the cryptomodule;
- the cryptomodule's interface commands;
- how roles map to services within the cryptomodule; and
- a finite state machine model for the cryptomodule.
Having access to these four items should be sufficient for determining if the cryptomodule passes particular validation tests, including cases where sub-elements may contain proprietary or classified information.
Additional Comments
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
General, AS01.01 |
| Relevant Test Requirements: |
TE01.01.01-.03 |
| Relevant Vendor Requirements: |
VE01.01.01 |
Question/Problem
What is the position on the re-validation of sub-elements that have been validated previously by either the current testing laboratory or another laboratory?
Resolution
Currently, NIST and CSE do not have enough experience to generalize whether a sub-element validated in one FIPS PUB 140-1 cryptomodule validation can be re-used in another validation without being re-tested. If a laboratory wants to accept a cryptomodule sub-element that was tested in another cryptomodule validation, then this must be approved by NIST or CSE on a case-by-case basis. This applies to previous testing by the same lab or a different lab. Once NIST, CSE, and the laboratories have gained more experience regarding sub-element re-testing, then the determination of re-testing may be generalized for particular tests, areas, and/or security levels.
Additional Comments
At the present time, consistent with their quality systems, laboratories may sub-contract tests to non-CMT labs, and so the possibility of sub-contracting testing to another CMT lab exists. However, in both situations, there must be a single laboratory that takes responsibility for the validation.
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS01.02 |
| Relevant Test Requirements: |
TE01.02.03-.04 |
| Relevant Vendor Requirements: |
VE01.02.01 |
Question/Problem
Can the cryptographic boundary include different components at different times?
Resolution
No. The cryptographic boundary must be defined and must be static. FIPS PUB 140-1 states in section 4.1, and VE01.02.01 that "The cryptographic boundary shall be an explicitly defined, contiguous perimeter that establishes the physical bounds of the cryptographic module." There are many requirements throughout the standard that are specified based on the cryptographic boundary of the module. Requirements that are heavily dependent on the cryptographic boundary include (but are not limited to):
- Module Interfaces
- Roles and Services
- Physical Security
- Operating System Security
- Key Management
A defined cryptographic boundary that would allow for some components to be within the module at specific times, and not within it at other times would place a "time" factor on these requirements; some requirements would be applicable to different parts of the module depending on where the cryptographic boundary is at what time. This was not intended, and as a result may reduce the intended strength of the requirements.
Additional Comments
Question/Problem
How does one determine if FIPS 140-1 requirements should apply to a sub-module within a cryptomodule?
Resolution
The following guidelines might be used with any type of sub-module (software, firmware, or hardware) in order to determine if particular FIPS 140-1 requirements apply. If a vendor indicates that a sub-module falls into one of the following three categories, then it is up to the testing laboratory to determine whether or not that is valid. If it is determined to be valid, then the lab shall indicate what requirements and tests are affected in the validation testing report. Certain requirements and tests might not apply if a sub-module can be placed in any of the three following categories:
- The sub-module is isolated from the rest of the cryptomodule so that it cannot adversely affect the security of the cryptomodule. In this case, the sub-module performs no security related functions.
- The sub-module performs one or more generic, basic functions which are used by a cryptographic function, and all of the following conditions hold:
- the sub-module is offered in a generic Commercial-Off-The-Shelf (COTS) product which has been widely distributed and tested;
- in general, the sub-module was not designed for security purposes;
- the vendor did not make any alterations to the sub-module and took steps to ensure that the sub-module was implemented without modification (i.e., shrink-wrapped software is used; source code is re-compiled but not modified; etc.);
- the cryptomodule performs known answer tests (if applicable) which verify the correct operations of the sub-module's security related functions (e.g., KAT's on basic math functions that were not specifically designed for implementing crypto, etc.).
- The sub-module performs security related functions which are classified (e.g., SKIPJACK), and the implementation is vouched for by the U.S. and/or Canadian governments. In this case, the classified details need not be provided. However, requirements that do not conflict with the classified nature of the sub-module still apply (e.g., requirements pertaining to: known answer tests, finite state machine model, sub-module's interface commands, security functions that are performed by the sub-module, and mapping of roles to services provided by the sub-module, etc.).
Additional Comments
An example of such a sub-module might be a resistor, memory chip, power supply, or other component in a hardware cryptomodule. The vendor could argue that such components fall under category II, parts A, B, and C in the above guidance.
Question/Problem
At what level of detail shall the cryptomodule security policy be written? What types of services shall be addressed in the security policy?
Resolution
There is a distinction pertaining to two "types" of security policies which are needed (by the labs and validation authorities):
- First, a security policy of some type must be provided to a laboratory so that it can perform all tests which reference the security policy. There is no requirement that a policy be contained in a single document; it may in fact be embodied in multiple documents, so long as all of the necessary information is available to the laboratory during testing. This policy may perhaps contain proprietary information.
- Second, a NON-PROPRIETARY security policy must be submitted to the validation authorities (NIST and CSE) prior to issuance of a validation certificate. This document MAY be identical to the security policy originally provided to the laboratory, but it does not have to be. This document will be retained by NIST and CSE along with the validation report, so that it can be released to entities (presumably potential customers) which have an interest in the product, and wish to learn more about it by examining the security policy. This document shall incorporate the following features:
- It shall NOT include ANY proprietary information, and there shall be no markings on the document indicating that it contains any of such information.
- It shall list roles and services of the module (and how they are related), different types of critical security parameters (keys, key components), capabilities, protection, etc.
- It shall be relatively brief (on the order of 10 pages or LESS), and understandable to a user who is not necessarily familiar with the cryptomodule.
Additional Comments
(11/24/97)
Also see Guidance 4.1, regarding Security Policy consolidation and formatting.
| Applicable Levels: |
1 |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS02.03 |
| Relevant Test Requirements: |
TE02.03.02 |
| Relevant Vendor Requirements: |
VE02.03.02 |
Question/Problem
If the cryptomodule is implemented as software running on a general purpose PC, does removal of the cover constitute a maintenance action and thus require that a maintenance role be present?
Resolution
No. The removal of a cover on a PC does not constitute a maintenance access for Level 1 (for module interface requirements). Since there is no maintenance access interface, no maintenance role is required (as per AS03.03), and AS03.04 (e.g., the cryptographic module shall clear all keys and other critical security parameters) need not be enforced.
Additional Comments
This resolution applies to Level 1 software cryptomodules running on a PC only. This resolution does not currently apply to Level 1 hardware cryptomodules that may reside within a general purpose PC, nor does it apply to Levels 2-4.
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS02.07 |
| Relevant Test Requirements: |
TE02.07.02 |
| Relevant Vendor Requirements: |
VE02.07.01 |
Question/Problem
Test TE02.07.02 says that "Zeroization techniques may include overwriting memory, or shorting memory to ground if the vendor shows that this drains off all charge within a few seconds." Given knowledge of a cryptomodule's design, along with some basic tools, a `few seconds' might be sufficient for an attacker to obtain keys from memory before they are zeroized. In addition, other parts of the DTR refer to the `immediate' zeroization of keys when tampering is detected. Thus allowing for a `few seconds' would seem to contradict these other requirements.
Resolution
The ability for someone to open a module's cover and access keys in memory before they are zeroized depends heavily on the design and configuration of the cryptomodule. Depending on the design and configuration, the time between tamper detection and zeroization can be on the order of a few milliseconds to several seconds. But in essence, a person shall not be able to physically open the cryptomodule's cover and obtain the keys from memory, even given detailed knowledge of the module's design. If a tester can open a cryptomodule's maintenance access interface and access plaintext private and secret keys, or other critical security parameters in memory (e.g., by methods described in TE02.07.02) before they are zeroized, then this test (TE02.07.02) is failed.
The reference to `immediate' zeroization of keys (e.g., in VE05.10.01) means that upon detection of tampering, the cryptomodule shall `drop everything' and perform zeroization. When tamper detection occurs, the next action of the module is to enter the state where zeroization takes place. `Immediate' is not used in the sense of time, but rather it refers to states and functions of the cryptomodule.
Additional Comments
| Applicable Levels: |
3, 4 |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS02.13 |
| Relevant Test Requirements: |
TE02.13.01 |
| Relevant Vendor Requirements: |
VE02.13.01 |
Question/Problem
There is a requirement at levels 3 and 4 that "plaintext cryptographic keys, plaintext authentication data, and other unprotected critical security parameters" be input and output using ports that are physically separate from all other ports of the module. Do plaintext public keys (for use with a public key cryptographic algorithm) have to likewise be input/output using physically separate ports?
Resolution
No. In this assertion, "cryptographic keys" is referring to secret or private keys, which need to be protected from disclosure. Public keys would fall under the category of "other data" (which is not a critical security parameter). Public keys do not have to be encrypted before they are input/output to/from the module.
Additional Comments
| Applicable Levels: |
3, 4 |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS02.13 |
| Relevant Test Requirements: |
TE02.13.01 |
| Relevant Vendor Requirements: |
VE02.13.01 |
Question/Problem
There is a requirement at levels 3 and 4 that "plaintext cryptographic keys, plaintext authentication data, and other unprotected critical security parameters" be input and output using ports that are physically separate from all other ports of the module. In addition to the physical separation of ports for critical security parameters and all other ports, must the input ports be physically separate from the output ports?
Resolution
No. Although the standard and DTR do not preclude the use of physically separate ports for the input of critical security parameters and the output of critical security parameters, this is not a requirement. The important distinction in this assertion is the separation of ports used for handling critical security parameters and all other ports.
Additional Comments
| Applicable Levels: |
ALL |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS02.02 |
| Relevant Test Requirements: |
TE02.02.01-.04 |
| Relevant Vendor Requirements: |
VE02.02.01-.04 |
Question/Problem
A module is required to have at least four logical interfaces, for: 1) data input, 2) data output, 3) control input, and 4) status output. If there are two buffers being used, one for input and another for output, can one interface be used for both data and control input, and another interface for data and status output?
Resolution
Yes. The standard does not preclude a module from using the same input interface for both data and control input - and the same holds for the output interface. However, there shall be some way for the module to distinguish between data and control (or data and status) information.
Additional Comments
Question/Problem
Does the presence of power-on self-tests, or other self-tests, imply that a maintenance role is necessary to invoke them?
Resolution
Self-tests, as defined under section 4.11 of FIPS 140-1, whether defined as power-up self-tests, conditional self-tests, self-tests that are callable upon demand, or other self-tests as implemented by the vendor, are not to be considered as maintenance tests or actions; hence, a maintenance role is not implied.
Additional Comments
A vendor may choose to define self-tests as maintenance tests if the vendor decides this is necessary.
Question/Problem
Does the presence of two or more roles imply that different services must be available for each role? Can all services be the same for all roles?
Resolution
More than one role can have the same set of services. If a cryptomodule does not delineate between the services accessible to any role (i.e., all services are available to all roles and no delineation of that role exists within the cryptomodule), then it is only necessary for the vendor to document the services offered in terms of two roles - User and Crypto-Officer. Both of these roles, at a minimum, must be supported by a cryptomodule (at any level - see AS03.02). Services need not be restricted in either role.
Additional Comments
Question/Problem
What types of status must be shown by the cryptomodule? Is a "Percentage Complete" status necessary during long operations such as key generation or encryption?
Resolution
For the "Show Status" service, a cryptomodule must, at a minimum, show the status, where practical, in terms of the Finite State Machine at a particular point in time (i.e., current state of the module). VE03.07.01 presents several possible functions to which the "Show Status" service might be applied. "Show Status" does not have to be applied to those functions which are listed, nor is this list exclusive; therefore it is possible to implement a "Percentage Complete" status, but it is not required.
Additional Comments
| Applicable Levels: |
3, 4 |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS03.16 |
| Relevant Test Requirements: |
TE03.16.01 |
| Relevant Vendor Requirements: |
VE03.16.01 |
Question/Problem
Are the authentication mechanisms specified in TE03.16.01 listed in an order of increasing level of security? What types of authentication mechanisms shall be used at particular security levels?
Resolution
The authentication mechanisms listed in section 4.3.3 of FIPS PUB 140-1 are examples of how an operator can be authenticated. This list is not exhaustive. TE03.16.01 and FIPS PUB 140-1 do not imply a hierarchy of these methods (i.e., that one is more robust than the other), nor does FIPS PUB 140-1 require certain mechanisms to be applicable for a certain level. The requirements in FIPS PUB 140-1 (for Levels 3 and 4) is that the module be able to uniquely identify and verify the identity of the operator regardless of the identification and authentication technique used.
Additional Comments
More guidance on these authentication mechanisms can be found in:
- FIPS 112, Password Usage,
- FIPS 181, Automated Password Generator, and
- FIPS 190, Guideline for the Use of Advanced Authentication Technology Alternatives, and
- FIPS 196, Entity Authentication Using Public Key Cryptography.
| Applicable Levels: |
3, 4 |
| Effective Dates: |
2/25/97- |
| Last Modified: |
|
| Relevant Assertions: |
AS03.20 |
| Relevant Test Requirements: |
TE03.20.01 |
| Relevant Vendor Requirements: |
VE03.20.01 |
Question/Problem
Can a single-user module meet the identity-based authentication requirements for Level 3 and 4?
Resolution
Yes. FIPS PUB 140-1 specifies identity-based authentication as the ability of a cryptographic module to "authenticate the identity of an operator and verify that the identified operator is authorized to assume a specific role (or set of roles). The module shall require that the operator be individually identified and that the specified identity be authenticated" [FIPS PUB 140-1, 4.3.3]. For modules that can support multiple users, the requirement for identity-based authentication does require that a user be identified and authenticated against the pool of other users of the module. However it is not the intent of FIPS PUB 140-1 to implicitly require that all modules at Level 3 (of roles & services requirements) have the capability to support multiple simultaneous users. A single-user module must be able to recognize and verify the identity of the one specified user, using an authentication mechanism that is capable of providing identity-based authentication.
Additional Comments
Question/Problem
What are the basic requirements concerning the maintenance role and zeroization of unprotected critical security parameters (CSPs)?
Resolution
At all levels of Roles and Services, a maintenance role is required if the module has a maintenance access interface. When entering this role, the module shall zeroize all unprotected CSPs prior to performing any other maintenance services, whether or not the operator is authenticated. This shall be "active zeroization", which is enforced by the module when the maintenance role is entered.
Level 1 physical security does not provide physical security mechanisms above and beyond the requirement that the module be "production quality". For modules which meet only level 1 in physical security, it is acceptable for zeroization upon entering the maintenance role to be performed procedurally. "Procedural zeroization" refers to zeroization that is not enforced by the module.
If zeroization is implemented procedurally in the module, then the procedure for zeroizing unprotected CSPs shall be clearly described in the module's security policy.
Additional Comments
Question/Problem
May a CMT lab assemble the FSM and Security Policy from existing vendor documentation?
Resolution
A CMT lab may take existing vendor documentation for an existing cryptographic module (design phase completed) and consolidate or reformat the existing information (from multiple sources) into a set format.
For the FSM, the vendor-provided documentation must readily provide a finite set of states, a finite set of inputs, a finite set of outputs, a mapping from the sets of inputs and states into the set of states (i.e., state transitions), and a mapping from the sets of inputs and states onto the set of outputs (i.e., an output function).
For the Security Policy the vendor-provided documentation must readily provide a precise specification of the security rules under which a cryptographic module must operate, including the security rules derived from the requirements of FIPS 140-1 and the additional security rules imposed by the vendor.
In addition, a lab must be able to show a mapping from the consolidated or reformatted FSM and/or Security Policy back the original vendor source documentation. This mapping must be maintained by the lab as part of its validation records.
Additional Comments
Also see Guidance G.4 for more information on what a CMT lab may and may not do.
Continue to Part 3: sections 5-7