APPENDIX C:
Selected References
This standard specifies the security requirements that are to be satisfied by a
cryptographic module utilized within a security system protecting unclassified information
in computer and telecommunication systems (including voice systems) that are not subject
to Section 2315 of Title 10, U.S. Code, or Section 3502(2) of Title 44, U.S. Code.
Cryptographic modules conforming to this standard shall meet the applicable security
requirements described herein.
This standard was developed by a government and industry working group composed of both
users and vendors. The working group identified 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 (e.g., a guarded facility, an office, and a
completely unprotected location). Each security level offers an increase in security over
the preceding level. These four increasing levels of security will allow cost-effective
solutions that are appropriate for different degrees of data sensitivity and different
application environments.
While the security requirements specified in this standard are intended to maintain the
security of a cryptographic module, conformance to this standard does not guarantee that a
particular module is secure. It is the responsibility of the manufacturer of a
cryptographic module to build the module in a secure manner.
Similarly, the use of a cryptographic module that conforms to this standard in an
overall system does not guarantee the security of the overall system. The security level
of a cryptographic module shall be chosen to provide a level of security appropriate for
the security requirements of the application and environment in which the module is to be
utilized and the security services which the module is to provide. The responsible
authority in each agency or department shall assure that the agency or department's
computer or telecommunication systems which utilize a cryptographic module provide an
acceptable level of security for the given application and environment.
NIST emphasizes the importance of computer security awareness and of making information
security a management priority that is communicated to all employees. Since computer
security requirements will vary for different applications, organizations should identify
their information resources and determine the sensitivity to and potential impact of
losses. Controls should be based on the potential risks and selected from available
controls, including administrative policies and procedures, physical and environmental
controls, information and data controls, software development and acquisition controls,
and backup and contingency planning.
NIST has developed many of the needed basic controls to protect computer information,
and has issued standards and guidelines covering both management and technical approaches
to computer security. These include standards for cryptographic functions which will be
implemented in cryptographic modules as specified in this standard. This standard is
expected to be the foundation for NIST's current and future cryptographic standards.
Security Level 1 provides the lowest level of security. It specifies basic security
requirements for a cryptographic module (e.g., the encryption algorithm must be a FIPS
approved algorithm), but it differs from the higher levels in several respects. No
physical security mechanisms are required in the module beyond the requirement for
production-grade equipment.
Examples of Level 1 systems include Integrated Circuit (IC) cards and add-on security
products. It is commonly felt that IC cards enhance the security of most systems. IC cards
may be used as a secure storage medium when distributing cryptographic keys and may also
implement cryptographic algorithms. Many vendors produce personal computer (PC) encryption
boards which will meet the Level 1 requirements. NIST has validated the correct
implementation of NIST cryptographic standards in several IC cards and encryption boards.
Level 1 allows software cryptographic functions to be performed in a general purpose
personal computer (PC). NIST believes that such implementations are often appropriate in
low-level security applications. The implementation of PC cryptographic software may be
more cost-effective than hardware-based mechanisms. This will enable agencies to avoid the
situation that exists today whereby the decision is often made not to cryptographically
protect data because hardware is considered too expensive.
Security Level 2 improves the physical security of a Security Level 1 cryptographic
module by adding the requirement for tamper evident coatings or seals, or for
pick-resistant locks. Tamper evident coatings or seals, which are available today, would
be placed on a cryptographic module so that the coating or seal would have to be broken in
order to attain physical access to the plaintext cryptographic keys and other critical
security parameters within the module. Pick-resistant locks would be placed on covers or
doors to protect against unauthorized physical access. These requirements provide a low
cost means for physical security and avoid the cost of the higher level of protection
involving hard opaque coatings or significantly more expensive tamper detection and
zeroization circuitry.
Level 2 provides for role-based authentication in which a module must authenticate that
an operator is authorized to assume a specific role and perform a corresponding set of
services.
Level 2 also allows software cryptography in multi-user timeshared systems when used in
conjunction with a C2 or equivalent trusted operating system. The ratings C2, B1 and B2
ratings are in accordance with the TCSEC (see Appendix C).
Many security experts feel that a trusted operating system is needed in order for software
cryptography to be implemented with a level of trust comparable to hardware cryptography.
This enables multi-user timeshared systems to implement cryptographic functions in
software when this level of security is cost effective.
Security Level 3 requires enhanced physical security which is generally available in
many existing commercial security products. Unlike Security Level 2 which employs locks to
protect against tampering with a cryptographic module, or employs coatings or seals to
detect when tampering has occurred, Level 3 attempts to prevent the intruder from gaining
access to critical security parameters held within the module. For example, a multi-chip
embedded module must be contained in a strong enclosure, and if a cover is removed or a
door is opened, the critical security parameters are zeroized. As another example, a
module must be enclosed in a hard, opaque potting material to deter access to the
contents.
Level 3 provides for identity-based authentication, which is stronger than the role
based-authentication used in Level 2. A module must authenticate the identity of an
operator and verify that the identified operator is authorized to assume a specific role
and perform a corresponding set of services.
Level 3 provides stronger requirements for entering and outputting critical security
parameters. The data ports used for critical security parameters must be physically
separated from other data ports. Furthermore, the parameters must either be entered into
or output from the module in encrypted form (in which case they may travel through
enclosing or intervening systems) or be directly entered into or output from the module
(without passing through enclosing or intervening systems) using split knowledge
procedures.
Level 3 allows software cryptography in multi-user timeshared systems when a B1 or
equivalent trusted operating system is employed along with a trusted path for the entry
and output of critical security parameters. A B1 or better trusted operating system with a
trusted path would have the capability to protect cryptographic software and critical
security parameters from other untrusted software that may run on the system. Such a
system could prevent plaintext from being mixed with ciphertext, and it could prevent the
unintentional transmission of plaintext keys.
Security Level 4 provides the highest level of security. Although most existing
products do not meet this level of security, some products are commercially available
which meet many of the Level 4 requirements. Level 4 physical security provides an
envelope of protection around the cryptographic module. Whereas the tamper detection
circuits of lower level modules may be bypassed, the intent of Level 4 protection is to
detect a penetration of the device from any direction. For example, if one attempts to cut
through the enclosure of the cryptographic module, the attempt should be detected and all
critical security parameters should be zeroized. Level 4 devices are particularly useful
for operation in a physically unprotected environment where an intruder could possibly
tamper with the device.
Level 4 also protects a module against a compromise of its security due to
environmental conditions or fluctuations outside of the module's normal operating ranges
for voltage and temperature. Intentional excursions beyond the normal operating ranges
could be used to thwart a module's defense during an attack. A module is required to
either include special environmental protection features designed to detect fluctuations
and zeroize critical security parameters, or to undergo rigorous environmental failure
testing that provides a reasonable assurance that the module will not be affected by
fluctuations outside of the normal operating range in a manner that can compromise the
security of the module.
Level 4 allows software cryptography in multi-user timeshared systems when a B2 or
equivalent trusted operating system is employed. A B2 trusted operating system provides
additional assurances of the correct operation of the security features of the operating
system.
The following definitions are used throughout this standard:
- Automated key distribution:
- the distribution of cryptographic keys, usually in encrypted form, using electronic
means, such as a computer network (e.g., down-line key loading, the automated key
distribution protocols of ANSI X9.17).
- Compromise:
- the unauthorized disclosure, modification, substitution or use of sensitive data
(including plaintext cryptographic keys and other critical security parameters).
- Confidentiality:
- the property that sensitive information is not disclosed to unauthorized individuals,
entities or processes.
- Control information:
- information that is entered into a cryptographic module for the purposes of directing
the operation of the module.
- Critical security parameters:
- security-related information (e.g., cryptographic keys, authentication data such as
passwords and PINs) appearing in plaintext or otherwise unprotected form and whose
disclosure or modification can compromise the security of a cryptographic module or the
security of the information protected by the module.
- Cryptographic boundary:
- an explicitly defined contiguous perimeter that establishes the physical bounds of a
cryptographic module.
- Cryptographic key (key):
- a parameter used in conjunction with a cryptographic algorithm that determines:
- the transformation of plaintext data into ciphertext data,
- the transformation of ciphertext data into plaintext data,
- a digital signature computed from data,
- the verification of a digital signature computed from data, or
- a data authentication code (DAC) computed from data.
- Cryptographic key component (key component):
- a parameter which is combined via a bit-wise exclusive-OR operation with one or more
other identically sized key component(s) to form a plaintext cryptographic key.
- Cryptographic module:
- the set of hardware, software, firmware, or some combination thereof that implements
cryptographic logic or processes, including cryptographic algorithms, and is contained
within the cryptographic boundary of the module.
- Cryptographic module security policy:
- a precise specification of the security rules under which a cryptographic module must
operate, including the security rules derived from the requirements of this standard and
the additional security rules imposed by the manufacturer.
- Data authentication code (DAC):
- a cryptographic checksum, based on DES (see FIPS PUB 113); also known as a Message
Authentication Code (MAC) in ANSI standards.
- Data key:
- a cryptographic key which is used to cryptographically process data (e.g., encrypt,
decrypt, sign, authenticate).
- Data path:
- the physical or logical route over which data passes; a physical data path may be shared
by multiple logical data paths.
- Digital signature:
- a non-forgeable transformation of data that allows the proof of the source (with
non-repudiation) and the verification of the integrity of that data.
- Electromagnetic compatibility (EMC):
- the ability of electronic systems to operate in their intended environments without
suffering an unacceptable degradation of the performance as a result of unintentional
electromagnetic radiation or response.
- Electromagnetic interference (EMI):
- electromagnetic phenomena which either directly or indirectly can contribute to a
degradation in the performance of an electronic system.
- Environmental failure protection (EFP):
- the use of features designed to protect against a compromise of the security of a
cryptographic module due to environmental conditions or fluctuations outside of the
module's normal operating range.
- Environmental failure testing (EFT):
- the use of testing to provide a reasonable assurance that a cryptographic module will
not be affected by environmental conditions or fluctuations outside of the module's normal
operating range in a manner that can compromise the security of the module.
- Electronic key entry:
- the entry of cryptographic keys into a cryptographic module in electronic form using a
key loading device. The user entering the key may have no knowledge of the value of the
key being entered.
- Encrypted key (ciphertext key):
- a cryptographic key that has been encrypted with a key encrypting key, a PIN or a
password in order to disguise the value of the underlying plaintext key.
- Error detection code (EDC):
- a code computed from data and comprised of redundant bits of information designed to
detect, but not correct, unintentional changes in the data.
- Finite state machine (FSM):
- a mathematical model of a sequential machine which is comprised of 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).
- FIPS approved security method:
- a security method (e.g., cryptographic algorithm, cryptographic key generation algorithm
or key distribution technique, authentication technique, or evaluation criteria) that is
either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix
to the FIPS or in a document referenced by the FIPS.
- Firmware:
- the programs and data (i.e., software) permanently stored in hardware (e.g., in ROM,
PROM, or EPROM) such that the programs and data cannot be dynamically written or modified
during execution. Programs and data stored in EEPROM are considered as software.
- Hardware:
- the physical equipment used to process programs and data in a cryptographic module.
- Initialization vector (IV):
- a vector used in defining the starting point of an encryption process within a
cryptographic algorithm (e.g., the DES Cipher Block Chaining (CBC) mode of operation).
- Integrity:
- the property that sensitive data has not been modified or deleted in an unauthorized and
undetected manner.
- Interface:
- a logical section of a cryptographic module that defines a set of entry or exit points
that provide access to the module, including information flow or physical access.
- Input data:
- information that is entered into a cryptographic module for the purposes of
transformation or computation.
- Key encrypting key:
- a cryptographic key that is used for the encryption or decryption of other keys.
- Key loader:
- a self-contained unit which is capable of storing at least one plaintext or encrypted
cryptographic key or key component which can be transferred, upon request, into a
cryptographic module.
- Key management:
- the activities involving the handling of cryptographic keys and other related security
parameters (e.g., IVs, counters) during the entire life cycle of the keys, including their
generation, storage, distribution, entry and use, deletion or destruction, and archiving.
- Manual key distribution:
- the distribution of cryptographic keys, often in a plaintext form requiring physical
protection, but using a non-electronic means, such as a bonded courier.
- Manual key entry:
- the entry of cryptographic keys into a cryptographic module from a printed form, using
devices such as buttons, thumb wheels or a keyboard.
- Microcode:
- the elementary computer instructions that correspond to an executable program
instruction.
- Operator:
- an individual accessing a cryptographic module, either directly or indirectly via a
process operating on his or her behalf, regardless of the specific role the individual
assumes.
- Output data:
- information that is to be output from a cryptographic module that has resulted from a
transformation or computation in the module.
- Password:
- a string of characters used to authenticate an identity or to verify access
authorization.
- Personal Identification Number (PIN):
- a 4 to 12 character alphanumeric code or password used to authenticate an identity,
commonly used in banking applications.
- Physical protection:
- the safeguarding of a cryptographic module or of cryptographic keys or other critical
security parameters using physical means.
- PIN:
- see Personal Identification Number.
- Plaintext key:
- an unencrypted cryptographic key which is used in its current form.
- Port:
- a functional unit of a cryptographic module through which data or signals can enter or
exit the module. Physically separate ports do not share the same physical pin or wire.
- Private key:
- a cryptographic key used with a public key cryptographic algorithm, uniquely associated
with an entity, and not made public.
- Public key:
- a cryptographic key used with a public key cryptographic algorithm, uniquely associated
with an entity, and which may be made public.
- Public key certificate:
- a set of data that unambiguously identifies an entity, contains the entity's public key,
and is digitally signed by a trusted party.
- Public key (asymmetric) cryptographic algorithm:
- a cryptographic algorithm that uses two related keys, a public key and a private key;
the two keys have the property that, given the public key, it is computationally
infeasible to derive the private key.
- Secret key:
- a cryptographic key used with a secret key cryptographic algorithm, uniquely associated
with one or more entities, and which shall not be made public. The use of the term
"secret" in this context does not imply a classification level, rather the term
implies the need to protect the key from disclosure or substitution.
- Secret key (symmetric) cryptographic algorithm:
- a cryptographic algorithm that uses a single, secret key for both encryption and
decryption.
- Security policy:
- see Cryptographic Module Security Policy.
- Software:
- the programs, and possibly associated data that can be dynamically written and modified.
- Split knowledge:
- a condition under which two or more entities separately have key components which
individually convey no knowledge of the plaintext key which will be produced when the key
components are combined in the cryptographic module.
- Status information:
- information that is output from a cryptographic module for the purposes of indicating
certain operational characteristics or states of the module.
- System software:
- the special software (e.g., operating system, compilers or utility programs) designed
for a specific computer system or family of computer systems to facilitate the operation
and maintenance of the computer system, programs, and data.
- Trusted path:
- a mechanism by which a person or process can communicate directly with a cryptographic
module and which can only be activated by the person, process or module, and cannot be
imitated by untrusted software within the module.
- Zeroization:
- a method of erasing electronically stored data by altering the contents of the data
storage so as to prevent the recovery of the data.
The following acronyms and abbreviations are used throughout this standard:
ACRONYMS
| ANSI |
American National Standards Institute |
| ATM |
Automated Teller Machine |
| CBC |
Cipher Block Chaining |
| DAC |
Data Authentication Code |
| DES |
Data Encryption Standard |
| DOC |
Department of Commerce |
| DOD |
Department of Defense |
| EDC |
Error Detection Code |
| EFP |
Environmental Failure Protection |
| EFT |
Environmental Failure Testing |
| EMC |
Electromagnetic Compatibility |
| EMI |
Electromagnetic Interference |
| EPROM |
Erasable Programmable Read-Only Memory |
| E2PROM |
Electronically-Erasable Programmable Read-Only Memory |
| FCC |
Federal Communications Commission |
| FIPS |
Federal Information Processing Standard |
| FIPS PUB |
FIPS Publication |
| FSM |
Finite State Machine |
| IC |
Integrated Circuit |
| IEEE |
Institute of Electrical and Electronics Engineers |
| ISO |
International Organization for Standardization |
| ITSEC |
Information Technology Security Evaluation Criteria |
| IV |
Initialization Vector |
| LCD |
Liquid Crystal Display |
| LED |
Light Emitting Diode |
| MAC |
Message Authentication Code |
| NBS |
National Bureau of Standards |
| NIST |
National Institute of Standards and Technology (formerly the National Bureau of
Standards) |
| NSA |
National Security Agency |
| PC |
Personal Computer |
| PIN |
Personal Identification Number |
| PROM |
Programmable Read-Only Memory |
| RAM |
Random Access Memory |
| ROM |
Read-Only Memory |
| TCB |
Trusted Computing Base |
| TCSEC |
Trusted Computer System Evaluation Criteria |
The security requirements specified in this standard relate to the secure design and
implementation of a cryptographic module. The requirements are derived from the following
high-level functional security objectives for a cryptographic module:
- To protect a cryptographic module from unauthorized operations or use.
- To prevent the unauthorized disclosure of the non-public contents of the cryptographic
module, including plaintext cryptographic keys and other critical security parameters.
- To prevent the unauthorized and undetected modification of the cryptographic module,
including the unauthorized modification, substitution, insertion, and deletion of
cryptographic keys and other critical security parameters.
- To employ FIPS approved security methods for the protection of unclassified information.
- To provide indications of the operational state of the cryptographic module.
- To ensure the proper operation of the cryptographic module.
- To detect errors in the operation of the cryptographic module and to prevent the
compromise of sensitive data and critical security parameters as a result of those errors.
This section specifies the security requirements that shall be satisfied by
cryptographic modules conforming to this standard. The security requirements cover areas
related to the design and implementation of a cryptographic module. These areas include
basic design and documentation, module interfaces, authorized roles and services, physical
security, software security, operating system security, key management, cryptographic
algorithms, electromagnetic interference/electromagnetic compatibility (EMI/EMC), and
self-testing. Table
1 summarizes the security requirements in each of these areas.
A cryptographic module shall be tested against the requirements of each area addressed
in this section. The module shall be independently rated in each area. Several areas
provide for increasing levels of security, with cumulative security requirements for each
security level. In these areas, the module shall receive a rating that reflects the
maximum security level for which the module fulfills all of the requirements of that area.
In areas that do not provide for different levels of security, the module shall receive a
rating that reflects fulfillment of all of the requirements for that area.
In addition to receiving independent ratings for each of the security areas, a
cryptographic module shall also receive an overall rating. The overall rating shall
indicate (1) the minimum of the independent ratings received in the areas with levels, and
(2) fulfillment of all the requirements in the other areas.
Many of the security requirements of this standard include specific documentation
requirements. These requirements are summarized in Appendix A.
The FIPS 140-1
validation procedures may require additional documentation. All documentation shall be
provided to the validation facility by the manufacturer of a cryptographic module.
Requirements for user documentation are beyond the scope of this standard, however, copies
of the user and installation manuals for a cryptographic module shall also be provided to
the validation facility.
Table 1. Summary of Security Requirements
| |
Security Level 1 |
Security Level 2 |
Security Level 3 |
Security Level 4 |
| Crypto Module |
Specification of cryptographic module and cryptographic boundary.
Description of cryptographic module including all hardware, software, and firmware
components. Statement of module security policy. |
| Module Interfaces |
Required and optional interfaces. Specification of all interfaces and of
all internal data paths. |
Data ports for critical security parameters physically separated from
other data ports. |
| Roles & Services |
Logical separation of required and optional roles and services. |
Role-based operator authentication. |
Identity-based operator authentication. |
| Finite State Machine |
Specification of finite state machine model. Required states and optional
states. State transition diagram and specification of state transitions. |
| Physical Security |
Production grade equipment. |
Locks or tamper evidence. |
Tamper detection and response for covers and doors. |
Tamper detection and response envelope. |
| EFP/EFT |
No requirements. |
Temperature and voltage. |
| Software Security |
Specification of software design. Relate software to finite state machine
model. |
High-level language implementation. |
Formal model. Pre- and post-conditions. |
| Operating System Security |
Executable code. Authenticated. Single user, single process. |
Controlled access protection (C2 or equivalent) |
Labelled protection (B1 or equivalent). Trusted communications path. |
Structured protection (B2 or equivalent). |
| Key Management |
FIPS approved generation/distribution techniques. |
Entry/exit of keys in encrypted form or direct entry/exit with split
knowledge procedures. |
| Cryptographic Algorithms |
FIPS approved cryptographic algorithms for protecting unclassified
information. |
| EMI/EMC |
FCC Part 15, Subpart J, Class A (Business use). Applicable FCC
requirements (for voice). |
FCC Part 15, Subpart J, Class B (Home use). |
| Self-Tests |
Power-up tests and conditional tests. |
A cryptographic module shall be a set of hardware, software, firmware, or some
combination thereof, that implements cryptographic logic or processes. A cryptographic
boundary shall be an explicitly defined contiguous perimeter that establishes the
physical bounds of the cryptographic module. If a cryptographic module contains software
or firmware, the cryptographic boundary shall be defined such that it contains the
processor which executes the code. Parts of a cryptographic module can be excluded from
the requirements of this standard if it can be shown that these parts do not affect the
security of the module.
This standard allows three different physical configurations of a cryptographic module:
single-chip modules, multi-chip embedded modules, and multi-chip standalone modules (see Section 4.5).
Documentation shall identify the hardware, software and firmware components of a
cryptographic module, specify the cryptographic boundary surrounding these components, and
describe the physical configuration of the module. The documentation shall include a block
diagram depicting all of the major hardware components of the module and their
interconnections, including any microprocessors, input/output buffers,
plaintext/ciphertext buffers, control buffers, key storage, working memory, and program
memory. The documentation shall also indicate any hardware, software or firmware
components of a module that are excluded from the security requirements of this standard,
and explain the rationale for the exclusion.
Documentation shall also completely specify the cryptographic module security policy,
i.e., the security rules under which a module must operate. In particular, the security
policy shall include the security rules derived from the security requirements of this
standard and the security rules derived from any additional security requirements imposed
by the manufacturer.
A cryptographic module shall be designed to restrict all information flow and physical
access to a cryptographic module to logical interfaces that define all entry and exit
points to and from the module. The module interfaces shall be logically distinct from each
other, although they may physically share one port (e.g., input data and output data may
enter and exit via the same port), or may be physically distributed over one or more ports
(e.g., input data may enter via both a serial and a parallel port).
A cryptographic module shall have the following four logical interfaces
("input" and "output" are indicated from the perspective of the
module):
- Data Input Interface.
- All data (except data entered via the control input interface) that is to be input to
and processed by a module, (including plaintext data, ciphertext data, cryptographic keys
and other key management data, authentication data, and status information from another
module), shall enter via the "data input" interface.
- Data Output Interface.
- All data (except data output via the status output interface) that is to be output from
a module, (including plaintext data, ciphertext data, cryptographic keys and other key
management data, authentication data, and control information for another module), shall
exit via the "data output" interface. All data output via the data output
interface shall be inhibited whenever an error state exists and during self-tests.
- Control Input Interface.
- All input commands, signals, and data (including manual controls such as switches,
buttons, and keyboards) used to control the operation of a module shall enter via the
"control input" interface.
- Status Output Interface.
- All output signals, indicators, and data (including status codes and physical indicators
such as lights, LEDs, buzzers, bells, and displays) used to indicate or display the status
of a module shall exit via the "status output" interface.
For Security Levels 1 and 2, the data input and output port or ports used for
cryptographic keys, authentication data, and other critical security parameters may be
shared with other ports of the module.
For Security Levels 3 and 4, the data input and output port or ports used for plaintext
cryptographic key components, plaintext authentication data, and other unprotected
critical security parameters shall be physically separated from all other ports of the
module. Furthermore, these ports shall allow for direct entry of plaintext cryptographic
key components, plaintext authentication data, and other unprotected critical security
parameters, as required in Section 4.8.3.
A cryptographic module optionally may include the following interfaces:
- Power Interface.
- All external electrical power shall enter or exit via the "power interface".
The power interface is not required when all power is provided or maintained internally to
the cryptographic module.
- Maintenance Access Interface.
- Any data, control and status information used to maintain, service or repair a module
shall enter and exit via the "maintenance access interface". All physical access
paths, including removable covers or doors, used to gain physical access to the contents
of a module, shall be defined as part of the "maintenance access" interface.
Any
removable covers or doors defined as part of the maintenance access interface shall be
safeguarded using the appropriate physical security mechanisms, as specified in Section 4.5.
All access to the maintenance access interface, including physical modifications to the
contents of the module, shall be restricted to the authorized maintenance role as
specified in Section
4.3.1. All plaintext secret and private keys, and other critical security parameters
contained in the module shall be zeroized when accessing the maintenance interface.
Documentation shall include a complete specification of the interfaces of a
cryptographic module, including any physical or logical ports, physical covers or doors,
manual or logical controls, physical or logical status indicators, and their physical,
logical, or electrical characteristics. If a cryptographic module includes a maintenance
access interface, then documentation shall include a complete specification of the set of
authorized maintenance procedures for the module.
All physical and logical input and output data paths within the module shall be
explicitly defined. All input data entering the module via the "data input"
interface shall only pass through the input data path. All output data exiting the module
via the "data output" interface shall pass through the output data path. In
order to prevent the inadvertent output of sensitive information, two independent internal
actions shall be required in order to output data via any output interface through which
plaintext cryptographic keys or other critical security parameters or sensitive data could
be output. The output data path shall be logically disconnected from the circuitry and
processes performing key generation, manual key entry or key zeroization. Documentation
shall include a complete specification of the defined input and output data paths.
A cryptographic module shall be designed to support authorized roles and the
corresponding services that can be performed within those roles. If a module can support
multiple concurrent operators, then the module shall internally maintain the separation of
the roles and services performed by each operator. Furthermore, depending on the security
level, a cryptographic module may be required to employ access control mechanisms to
authenticate an operator accessing the module (either directly or indirectly via a
computer process acting on his or her behalf) and to verify that the operator is
authorized to perform the desired roles and to perform the desired services within that
role.
A cryptographic module shall support the following authorized roles:
- User Role:
- The role assumed by an authorized user obtaining security services, performing
cryptographic operations, or other authorized functions.
- Crypto Officer Role:
- The role assumed by an authorized crypto officer performing a set of cryptographic
initialization or management functions (e.g., cryptographic key and parameter entry,
cryptographic key cataloging, audit functions, alarm resetting).
If a cryptographic module includes a maintenance access interface as specified in Section 4.2,
then the module shall also support the maintenance role.
- Maintenance Role:
- The role assumed by an authorized maintenance person accessing the maintenance access
interface and/or performing specific maintenance tests and obtaining interim results in
order to maintain, service or repair the module. A cryptographic module shall clear all
plaintext secret and private keys and other critical security parameters when entering the
maintenance role. A cryptographic module shall clear all maintenance keys and other
critical security parameters when exiting the maintenance role.
A module may support other roles or sub-roles in addition to the roles specified above.
Documentation shall provide a complete specification of all of the authorized roles
supported by the module.
Services shall refer to all of the services, operations or functions that can be
performed by a cryptographic module. Service inputs shall consist of all data or
control inputs to the module that initiate or obtain specific services, operations, or
functions. Service outputs shall consist of all data and status outputs that result
from services, operations or functions initiated or obtained by service inputs. Each
service shall result in a service output.
A cryptographic module shall, at a minimum, provide the following services:
- Show status.
- Output the current status of the module.
- Self-tests.
- Initiate and run the self-tests as specified in Section 4.11.
A cryptographic module may optionally provide the following service:
- Bypass.
- Activate or deactivate a bypass capability whereby services are provided without
cryptographic processing (e.g., transferring plaintext through the module). If a
cryptographic module implements a bypass capability, then (1) in order to prevent the
inadvertent bypass of data due to a single failure, two independent internal actions shall
be implemented to activate the bypass capability, and (2) the current status of the module
(e.g., the response to a "Show Status" service request) shall indicate whether
or not the bypass capability is activated.
Documentation shall provide a complete specification of each of the authorized
services, operations, and functions that can be performed by the module. For each service,
the service inputs, corresponding service outputs, and the authorized role (or set of
roles) in which the service can be performed, shall be specified. Specific services may be
performed in more than one role (e.g., key entry may be performed in the user role, the
crypto officer role, and the maintenance role).
For Security Levels 2, 3 and 4, a cryptographic module shall perform either role-based
authentication or identity-based authentication of the operator accessing the module
(either directly or indirectly via a computer process acting on his or her behalf) in
order to verify that the operator is authorized to perform desired roles and services.
Role-Based Authentication: A cryptographic module shall
authenticate that the operator is authorized to assume a specific role (or set of roles).
The module shall require that the operator either implicitly or explicitly select one or
more roles, and the module shall authenticate that the operator is authorized to assume
the selected roles and to request the corresponding services. The module is not required
to authenticate the individual identity of each operator. The selection of roles and the
authentication of the authorization to perform those roles may be combined (e.g., a
physical key may both indicate one or more roles and verify the authorization to perform
those roles). A module may permit an operator to change roles, but the module shall
authenticate the authorization of the operator to assume any role that was not previously
authenticated.
Identity-Based Authentication: A cryptographic module shall
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. The
module shall require that the operator either implicitly or explicitly select one or more
roles, and, based on the authenticated identity, verify that the operator is authorized to
assume the selected roles and to request the corresponding services. The authentication of
the identity of the operator, selection of roles, and verification of the authorization to
assume those roles may be combined (e.g., an IC card may both identify, authenticate and
authorize the operator to assume specific roles). A module may permit an operator to
change roles without re-authenticating the identity of the operator, but the module shall
verify the authorization of the authenticated operator to assume the new role.
A cryptographic module may permit an operator to perform all of the services allowed
within an authorized role, or may require separate authorizations for each service or for
different sets of services. When a module is powered up after being powered off (e.g.,
power failure) or after repair or servicing, the results of previous authentications shall
not be retained, i.e., the module shall re-authenticate the authorization of the operator
to assume a desired role.
A module may implement any of a variety of authentication mechanisms, including, but
not limited to, knowledge or possession of a password, PIN, cryptographic key or
equivalent, possession of a physical key, token, or equivalent, or verification of
personal characteristics (i.e., biometrics).
Services that are used to initialize the access control information needed to implement
the access control mechanisms required herein, may require special treatment. For example,
the first time that a crypto officer attempts to access a module, the module may not
contain the authentication and authorization information required to authenticate the
identity of the crypto officer and to verify his or her authorization to assume the crypto
officer role. In these cases, other means (such as procedural controls, or factory-set or
default authentication and authorization information) may be used to control access to the
module.
SECURITY LEVEL 1
For Security Level 1, a cryptographic module is not required to employ authentication
mechanisms to control access to the module. A module optionally may employ either
role-based or identity-based authentication mechanisms in order to verify the
authorization of the operator to assume the desired roles and to request corresponding
services.
SECURITY LEVEL 2
For Security Level 2, a cryptographic module shall employ either role-based
authentication mechanisms or identity-based mechanisms in order to verify the
authorization of the operator to assume the desired roles and to request corresponding
services.
SECURITY LEVELS 3 AND 4
For Security Levels 3 and 4, a cryptographic module shall employ identity-based
authentication mechanisms in order to verify the authorization of the operator to assume
the desired roles and to request corresponding services. Furthermore, plaintext
authentication data (e.g., passwords and PINs), plaintext cryptographic key components,
and other unprotected critical security parameters shall be entered via a port or ports
that are physically separated from other ports, and that allow for direct entry (as
required in Section
4.2).
All cryptographic modules shall be designed using a finite state machine model that
explicitly specifies every operational and error state of the module.
A cryptographic module shall be designed using the following types of states:
- Power on/off states.
- States for primary, secondary or backup power. These states may distinguish between
power applied to different portions of a module.
- Crypto officer states.
- States in which the crypto officer functions are performed (e.g., cryptographic
initialization and key management functions).
- Key entry states.
- States for entering cryptographic keys and other critical security parameters into the
module, and for checking their validity.
- User service states.
- States in which authorized users obtain security services, perform cryptographic
operations, or perform other authorized user functions.
- Self-test states.
- States for performing self-tests on the module (see Section 4.11).
- Error states.
- States when the module has encountered an error (e.g., failed a self-test, attempting to
encrypt while missing operational keys or other critical security parameters, or
cryptographic errors). Error states may include "hard" errors which indicate an
equipment malfunction and which may require maintenance, service or repair of the module,
or error states may include recoverable "soft" errors which may require
initialization or resetting of the module.
All data output via the data output interface shall be inhibited during all error
states. All error states shall be able to be reset to an acceptable operational or
initialization state except for those hard errors which require maintenance, service or
repair of the module.
A cryptographic module may contain other types of states including the following:
- Un-initialized states.
- States in which no operational security parameters are loaded into the module.
- Idle states.
- States in which the module is potentially operational, but is not currently providing
security services or performing cryptographic functions. Cryptographic keys and security
parameters are loaded, and the module is waiting for data or control inputs.
- Safety states.
- States in which the module is not currently operational, but cryptographic keys and
parameters are loaded. These states are used to protect the module from unauthorized use
during the temporary absence of the operator. The safety states shall require an explicit
authenticated action to return to a user/crypto service state. These states are equivalent
to the "standby" mode of former Federal Standard 1027.
- Bypass states.
- States for providing services without cryptographic processing (e.g., transferring
plaintext through the module).
- Maintenance states.
- States for maintaining and servicing a module, including maintenance testing. If a
cryptographic module includes a maintenance access interface (see Section 4.2),
then the module shall include maintenance states.
All states of a cryptographic module shall be explicitly defined in sufficient detail
to assure the verification of the conformance of the module to this standard.
Documentation shall identify and describe all states of the module and shall describe all
of the corresponding state transitions. The descriptions of the state transitions shall
include the internal module conditions, data inputs and control inputs that cause
transitions from one state to another, and shall include the internal module conditions,
data outputs and status outputs resulting from transitions from one state to another.
Documentation shall also include finite state diagrams in sufficient detail to assure the
verification of conformance to this standard.
A cryptographic module shall be designed to employ physical security mechanisms in
order to restrict unauthorized physical access to the contents of the module and to deter
unauthorized use or unauthorized modification of the module (including substitution of the
entire module) when installed. The entire contents of a cryptographic module, including
all hardware, firmware, software and data (including plaintext cryptographic keys and
unprotected critical security parameters) shall be protected.
The physical security mechanisms employed by a cryptographic module depend largely on
the physical embodiment of the module. The physical security requirements are separated
into three distinct physical embodiments: single-chip modules, multiple-chip embedded
modules, and multiple-chip standalone modules. Table 2
summarizes the physical security requirements for the three different physical embodiments
of a module for each of the four security levels.
Table 2. Summary of Physical Security Requirements
| |
Single Chip Modules |
Multi-Chip Embedded Modules |
Multi-Chip Standalone Modules |
| Security Level 1 |
Production-grade chip (with standard passivation). |
Production-grade chip and production-grade multi-chip embodiment. |
Production-grade chips, production-grade multi-chip embodiment, and production-grade
enclosure. |
| Security Level 2 |
Level 1 requirements. Opaque tamper evident coating. |
Level 1 requirements. Opaque tamper evident coating. |
Level 1 requirements. Opaque enclosure with mechanical locks or tamper evident seals
for covers and doors. |
| Security Level 3 |
Levels 1 and 2 requirements. Hard opaque tamper evident coating. |
Levels 1 and 2 requirements. Hard opaque potting material, strong non-removable
enclosure, or strong removable cover with removal detection and zerioization circuitry.
Protected vents. |
Levels 1 and 2 requirements. Hard opaque potting material, or strong enclosure with
tamper response and zeroization circuitry for covers and doors. Protected vents. |
| Security Level 4 |
Levels 1, 2, and 3 requirements. Hard opaque removal resistant coating. EFP/EFT for
temperature and voltage. |
Levels 1, 2, and 3 requirements. Tamper detection envelope with tamper response and
zeroization circuitry. EFP/EFT for temperature and voltage. |
Levels 1, 2, and 3 requirements. Tamper detection/response envelope with zeroization
circuitry. EFP/EFT for temperature and voltage. |
Depending on the security level of a cryptographic module, the physical security
mechanisms may be designed such that unauthorized attempts at access, use or modification
will either have a high probability of being detected subsequent to the attempt by leaving
visible signs (i.e., tamper evident), or have a high probability of being detected during
the attempt (i.e., tamper detection) so that appropriate actions can be taken by the
module to protect itself (i.e., tamper response). Generally speaking, Security Level 1
simply requires minimal physical protection through the use of production-grade
enclosures, Security Level 2 requires the addition of tamper evident counter measures,
Security Level 3 requires the use of strong enclosures with tamper detection and response
counter measures for covers and doors, and Security Level 4 requires the use of strong
enclosures with tamper detection and response counter measures for the entire enclosure.
Documentation shall include a complete specification of the physical embodiment and
security level for which the physical security mechanisms of a cryptographic module are
designed, as well as a complete description of the applicable physical security mechanisms
that are employed by the module.
Single-chip cryptographic modules are implementations in which a single integrated
circuit (IC) chip may be used as a standalone device or may be physically embedded within
some other module or enclosure which may not be physically protected. Single-chip modules
include single IC chips, smart cards with a single IC chip, and other systems that
incorporate a single IC chip to implement cryptographic functions. Because of its small
size and its fabrication, a single chip has some inherent tamper resistance. A few
additional requirements provide reasonable physical security.
SECURITY LEVEL 1
The following requirement shall apply to a single-chip cryptographic module for
Security Level 1.
- The chip shall be of production-grade quality, which shall include standard passivation
techniques (i.e., a sealing coat applied over the chip circuitry to protect it against
environmental or other physical damage).
SECURITY LEVEL 2
In addition to the Security Level 1 requirement, the following requirement shall apply
to a single-chip cryptographic module for Security Level 2.
- The chip shall be covered with an opaque tamper evident coating (e.g., an opaque tamper
evident passivation material, or an opaque tamper evident material covering the
passivation) to deter direct observation, probing or manipulation of the surface features
of the chip. The material shall be opaque within the visible spectrum.
SECURITY LEVEL 3
In addition to the requirements for Security Levels 1 and 2, the following requirement
shall also apply to a single-chip cryptographic module for Security Level 3.
- A hard, opaque tamper evident coating shall be used (e.g., a hard opaque epoxy covering
the passivation).
SECURITY LEVEL 4
In addition to the requirements for Security Levels 1, 2, and 3, the following
requirements shall also apply to a single-chip cryptographic module for Security Level 4.
- A hard, opaque removal-resistant coating shall be used. The hardness and adhesion
characteristics of the material shall be such that attempting to peel or pry the material
from the module will have a high probability of resulting in serious damage to the module
(i.e., the module does not function). The solvency characteristics of the material shall
be such that dissolving the material to remove it will have a high probability of
dissolving or seriously damaging the module.
- The module shall either include environmental failure protection (EFP) features or
undergo environmental failure testing (EFT) as specified in Section 4.5.4.
Multiple-chip embedded cryptographic modules are implementations in which two or more
IC chips are interconnected and are physically embedded within some other module or
enclosure which may not be physically protected. Multiple-chip embedded cryptographic
modules include adaptors and expansion boards, and other modules that are not single chips
and are not contained within physically protected standalone modules. Typical size and
space constraints restrict the physical security mechanisms that can be effectively
employed.
SECURITY LEVEL 1
The following requirements shall apply to a multiple-chip embedded cryptographic module
for Security Level 1.
- The chips shall be of production-grade quality, which shall include standard passivation
techniques (i.e., a sealing coat applied over the chip circuitry to protect it against
environmental or other physical damage).
- The module shall be implemented as a production-grade multiple-chip embodiment (i.e., an
IC printed circuit board, a ceramic substrate, etc.).
SECURITY LEVEL 2
In addition to the requirements for Security Level 1, the following requirement shall
apply to a multiple-chip embedded cryptographic module for Security Level 2.
- The module shall be encapsulated within an opaque tamper evident material (e.g.,
conformal coating, bleeding paint) in order to prevent direct observation of module
components, and to provide evidence of attempts to tamper with or remove module
components. The material shall be opaque within the visible spectrum.
SECURITY LEVEL 3
In addition to the requirements for Security Levels 1 and 2, the following requirements
shall apply to a multiple-chip embedded cryptographic module for Security Level 3.
- A hard opaque potting material (e.g., a hard opaque epoxy).
-or-
The module shall be contained within a strong non-removable enclosure. The enclosure
shall be designed such that attempts to remove or penetrate it will have a high
probability of causing serious damage to the module (i.e., the module does not function).
-or-
The module shall be enclosed within a strong removable cover and shall include tamper
response and zeroization circuitry. The circuitry shall continuously monitor the cover,
and upon the removal of the cover, shall immediately zeroize all plaintext cryptographic
keys and other unprotected critical security parameters. The circuitry shall be
operational whenever plaintext cryptographic keys or other unprotected critical security
parameters are contained within the module.
- If the module is contained within a cover or enclosure and if the cover or enclosure
contains any ventilation holes or slits, then they shall be small and constructed in a
manner that prevents undetected physical probing inside the enclosure (e.g., require at
least one 90 degree bend or block with a substantial blocking material).
SECURITY LEVEL 4
In addition to the requirements for Security Levels 1, 2 and 3, the following
requirements shall also apply to a multiple-chip embedded cryptographic module for
Security Level 4.
- The contents of the module shall be completely contained within a tamper detection
envelope (e.g., a flexible mylar printed circuit with a serpentine geometric pattern of
conductors or a wire-wound package or a non-flexible, brittle circuit) which will detect
tampering by means such as drilling, milling, grinding or dissolving of the potting
material or cover.
- The module shall contain tamper response and zeroization circuitry. The circuitry shall
continuously monitor the tamper detection envelope for tampering, and upon the detection
of tampering, shall immediately zeroize all plaintext cryptographic keys and other
unprotected critical security parameters (see Section 4.8.5).
The circuitry shall be operational whenever plaintext cryptographic keys or other
unprotected critical security parameters are contained within the cryptographic module.
- The module shall either include environmental failure protection (EFP) features or
undergo environmental failure testing (EFT) as specified in Section 4.5.4.
Multiple-chip standalone cryptographic modules are implementations in which the entire
enclosure is physically protected. The modules may contain two or more IC chips that are
interconnected (e.g., an IC printed circuit board or ceramic substrate). Typical size and
space constraints may no longer restrict the physical security mechanisms that can be
effectively employed.
SECURITY LEVEL 1
The following requirements shall apply to a standalone cryptographic module for
Security Level 1.
- The chips shall be of production-grade quality, which shall include standard passivation
techniques (i.e., a sealing coat applied over the chip circuitry to protect it against
environmental or other physical damage).
- The circuitry within the module shall be implemented as a production-grade multiple-chip
embodiment (i.e., an IC printed circuit board, a ceramic substrate, etc.).
- The module shall be entirely contained within a metal or hard plastic production-grade
enclosure, which may include doors or removable covers.
SECURITY LEVEL 2
In addition to the requirements for Security Level 1, the following requirements shall
also apply to a standalone cryptographic module for Security Level 2.
- The enclosure shall be opaque within the visible spectrum.
- If the enclosure includes any doors or removable covers, then either they shall be
locked with pick-resistant mechanical locks that employ physical or logical keys, or they
shall be protected via tamper evident seals (e.g., evidence tape, holographic seals).
SECURITY LEVEL 3
In addition to the requirements for Security Levels 1 and 2, the following requirements
shall also apply to a standalone cryptographic module for Security Level 3.
- The multi-chip embodiment of the circuitry within the module shall be encapsulated
within a hard opaque potting material (e.g., a hard opaque epoxy). The material shall be
opaque within the visible spectrum.
-or-
- The module shall be contained within a strong enclosure. The enclosure shall be designed
such that attempts to remove it will have a high probability of causing serious damage to
the circuitry within the module (i.e., the module does not function). If the enclosure
contains any removable covers or doors, then the module shall contain tamper response and
zeroization circuitry. The circuitry shall continuously monitor the covers and doors, and
upon the removal of a cover or the opening of a door, shall immediately zeroize all
plaintext cryptographic keys and other unprotected critical security parameters. The
circuitry shall be operational whenever plaintext cryptographic keys or other unprotected
critical security parameters are contained within the cryptographic module.
- If the enclosure contains any ventilation holes or slits, then they shall be small and
constructed in a manner that prevents undetected physical probing inside the enclosure
(e.g., require at least one 90 degree bend or block with a substantial blocking material).
SECURITY LEVEL 4
In addition to the requirements for Security Levels 1, 2 and 3, the following
requirements shall also apply to a standalone cryptographic module for Security Level 4.
- The enclosure shall contain tamper detection mechanisms that provide a tamper detection
envelope, such as cover switches (e.g., microswitches, magnetic Hall effect switches,
permanent magnetic actuators, etc.), motion detectors (e.g., ultrasonic, infrared, or
microwave), or other tamper detection mechanisms as described above for multiple-chip
embedded modules. These mechanisms shall be designed to detect tampering by means such as
cutting, drilling, milling, grinding or dissolving of the potting material or cover.
- The module shall contain tamper response and zeroization circuitry. The circuitry shall
continuously monitor the tamper detection mechanisms for tampering, and upon the detection
of tampering, shall immediately zeroize all plaintext cryptographic keys and other
unprotected critical security parameters. The circuitry shall be operational whenever
plaintext cryptographic keys or other unprotected critical security parameters are
contained within the cryptographic module.
- The module shall either include environmental failure protection (EFP) features or
undergo environmental failure testing (EFT) as specified in Section 4.5.4.
Electronic devices and circuitry are designed to operate within a particular range of
environmental conditions. If the devices or circuitry are operated outside of this range,
their correct operation is not guaranteed. Deliberate or accidental excursions outside the
specified normal operating range can cause erratic operation or failure of the electronic
devices or circuitry within a cryptographic module that can compromise the security of the
module. In order to provide reasonable assurance that the security of a cryptographic
module cannot be compromised by environmental conditions, the module may either employ
environmental failure protection (EFP) features or undergo environmental failure testing
(EFT).
For Security Levels 1, 2, and 3, a cryptographic module is not required to employ
environmental failure protection (EFP) features nor undergo environmental failure testing
(EFT). At Security Level 4, a cryptographic module shall either employ environmental
failure protection (EFP) features or undergo environmental failure testing (EFT).
Environmental failure protection (EFP) features shall be designed to protect a
cryptographic module against unusual environmental conditions or fluctuations (accidental
or induced) outside of the module's normal operating range that can compromise the
security of the module. In particular, the module shall monitor and correctly respond to
fluctuations in the operating temperature and voltage outside of a module's specified
normal operating ranges.
The protection features shall involve additional electronic circuitry or devices that
shall continuously measure these environmental conditions. If a condition is determined to
be outside of the module's normal operating range, the protection circuitry shall either
(1) shutdown the module to prevent it from operating outside the normal range, or (2)
immediately zeroize all plaintext cryptographic keys and other unprotected critical
security parameters. Documentation shall provide a complete specification and description
of the environmental failure protection features employed within a module.
Environmental failure testing shall involve a combination of analysis, simulation, and
testing of a cryptographic module in order to give a reasonable guarantee that
environmental conditions or fluctuations (accidental or induced) outside the module's
normal operating range will not result in the compromise of the security of the module.
The manufacturer of a module shall perform the required testing and shall provide
documentation that completely specifies the nature of the environmental failure tests
performed and the results of those tests.
In particular, environmental failure testing shall show that varying the operating
temperature and voltage outside of a cryptographic module's specified normal operating
ranges does not cause electronic devices or circuitry within the module to fail in a
manner that can compromise the security of the module. The temperature range to be tested
shall be from -100 to +200 degrees Celsius. The voltage range to be tested shall be from
the smallest negative voltage (with respect to ground) which causes the destruction of the
electronic devices or circuitry, to the smallest positive voltage (with respect to ground)
which causes the destruction of the electronic devices or circuitry, including reversing
the polarity of the voltages. The module shall be subjected to excursions outside its
specified normal operating range while being operated in a normal manner. The electronic
devices or circuitry may fail at any point outside the normal operating ranges, but at no
time shall the security of the module be compromised. If at any time during the test, the
security of the module is compromised due to the failure of electronic circuitry or
devices, then the design of the electronic circuitry or devices shall be corrected and the
module shall be retested.
The following software security requirements shall apply to all software and firmware
contained within a cryptographic module. These requirements do not apply to microcode or
system software whose source code is not available to the module manufacturer. These
requirements do not apply to any software or firmware that can be shown not to affect the
security of the module. Documentation shall identify any software or firmware that is
excluded from the software security requirements and explain the rationale for the
exclusion.
SECURITY LEVELS 1 AND 2
The following requirements shall apply for Security Levels 1 and 2.
- Documentation shall include a detailed description of the design of the software within
the module (e.g., the finite state machine specification required in Section 4.4).
- Documentation shall include a detailed explanation of the correspondence between the
design of the software and the cryptographic module security policy (i.e., the rules of
operation as documented per the requirements of Section 4.1)
(Security Levels 1, 2, and 3 only).
- Documentation shall include a complete source code listing for all software contained
within the module. For each software module, software function and software procedure, the
source code listing shall be annotated with comments that clearly depict the relationship
of these software entities to the design of the software.
SECURITY LEVEL 3
In addition to the applicable requirements for Security Levels 1 and 2, the following
requirement shall apply for Security Level 3.
- All software within a cryptographic module shall be implemented using a high-level
language, except that the limited use of low-level languages (e.g., assembly languages) is
allowed when it is essential to the performance of the module or when a high-level
language is not available.
SECURITY LEVEL 4
In addition to the applicable requirements for Security Levels 1, 2 and 3, the
following requirements shall apply for Security Level 4.
- Documentation shall include a specification of a formal model (i.e., a precise
mathematical statement) of the cryptographic module security policy (i.e., the security
rules under which the module must operate) as documented per the requirements of Section 4.1.
The formal model shall be specified using a formal specification language that is a
rigorous notation based on established mathematics, such as first order logic or set
theory. Examples include, but are not limited to INAJO, GYPSY, VDM, Z, LOTOS, EHDM and
ESTELLE.
- Documentation shall include a detailed explanation (informal proof) of the
correspondence between the formal model and the cryptographic module security policy.
- For each software module, software function and software procedure, the source code
listing shall be annotated with comments that clearly specify (1) the pre-conditions
required upon entry into the module, function or procedure in order for it to execute
correctly, and (2) the post-conditions expected to be true when execution of the module,
function or procedure is complete. These conditions may be specified using any notation
that is sufficiently detailed to completely and unambiguously explain the behavior of a
module, function or procedure. While a mechanically checked proof is not required, it
shall be possible to prove from the pre- and post-conditions that a module, function or
procedure is consistent with the formal model.
- Documentation shall include a detailed explanation (informal proof) of the
correspondence between the software design (as reflected by the pre- and post-condition
annotations) and the formal model.
RECOMMENDED SOFTWARE DEVELOPMENT PRACTICES
- It is highly recommended that all software within a cryptographic module be implemented
using the set of recommended software development practices listed in Appendix B.
These practices will facilitate the analysis of the software for conformance to the
requirements of this standard, and will reduce the chances of programming errors.
The operating system requirements in this section shall apply to a cryptographic module
only if the module provides a means whereby an operator can load and execute software or
firmware that was not included as part of the validation of the module.
An example of a cryptographic module for which the operating system requirements apply
is a cryptographic module which is a general purpose computer running cryptographic
software as well as untrusted user-supplied software (e.g., a spreadsheet or word
processing program). In this case, the hardware, operating system and cryptographic
software are considered part of the cryptographic module, and hence, the operating system
requirements apply.
SECURITY LEVEL 1
For Security Level 1, the following requirements apply. Note that as a consequence of
these requirements, multi-user, multi-processing operating systems are explicitly excluded
from Security Level 1, and hence, must satisfy the requirements for Security Levels 2, 3
or 4.
- All cryptographic software shall be installed only as executable code in order to
discourage scrutiny and modification by users.
- A cryptographic mechanism using a FIPS approved authentication technique (e.g., the
computation and verification of a data authentication code or NIST digital signature
algorithm) shall be applied to the cryptographic software within the cryptographic module.
This cryptographic mechanism requirement may be incorporated as part of the
Software/Firmware Test (Section 4.11.1)
if a FIPS approved authentication technique is employed for that test.
- Use of the cryptographic module shall be limited to a single user at a time (Security
Level 1 only).
- Use of the cryptographic module shall be dedicated to the cryptographic process during
the time the cryptographic process is in use (Security Level 1 only).
SECURITY LEVEL 2
In addition to the applicable requirements for Security Level 1, the following
requirements shall also apply for Security Level 2.
- All cryptographic software, cryptographic keys and other critical security parameters,
and control and status information shall be under the control of an operating system that
provides controlled access protection (i.e., C2 protection in accordance with the Trusted
Computer System Evaluation Criteria (TCSEC), or FIPS approved equivalent). Only operating
systems that have been evaluated by a NIST accredited evaluation authority and against a
FIPS approved criteria shall be used. (Security Level 2 only).
- The discretionary access control mechanisms provided by a C2 or equivalent operating
system shall be employed to protect all plaintext data, cryptographic software,
cryptographic keys, authentication data, and other critical security parameters from
unauthorized access, per the following requirements:
- The operating system shall provide the capability to specify a set of operators who can
execute cryptographic program images contained on the cryptographic module's secondary
storage.
- The operating system shall provide the capability to specify a separate set of operators
for each of the following cryptographic module software components, such that only
elements within that component's set can modify (i.e., write, replace, delete) entities
within that component:
- cryptographic program images on secondary storage
- cryptographic data (e.g. cryptographic keys, audit data) stored on secondary storage
- cryptographic data (e.g. cryptographic keys, audit data) stored in computer memory
- other critical security parameters stored on secondary storage
- other critical security parameters contained in computer memory.
The operating system shall provide the capability to prevent all operators and
executing processes from modifying executing cryptographic processes (i.e., loaded and
executing cryptographic program images). Executing processes, in this case, means all
non-operating system (i.e., all operator initiated) processes, cryptographic or not.
- The operating system shall provide the capability to specify a separate set of operators
and cryptographic processes for each of the following cryptographic module software
components, such that only elements within a given component's set can read entities
within that component:
- cryptographic data (e.g. cryptographic keys, audit data) stored on secondary storage
- cryptographic data (e.g. cryptographic keys, audit data) stored in computer memory
- other critical security parameters stored on secondary storage
- other critical security parameters contained in computer memory
- plaintext data stored either within the module's memory or on secondary storage
The operating system shall provide the capability to prevent all operators and
processes from reading the following cryptographic module software components:
- cryptographic program images contained on secondary storage
- executing cryptographic program images
- The operating system shall provide the capability to specify a set of operators who are
authorized to enter cryptographic keys and other critical security parameters.
SECURITY LEVEL 3
In addition to the applicable requirements for Security Levels 1 and 2, the following
requirements shall also apply for Security Level 3.
- All cryptographic software, cryptographic keys and other critical security parameters,
control and status information shall be labelled and under the control of an operating
system that provides labelled protection (i.e., B1 protection in accordance with the
Trusted Computer System Evaluation Criteria (TCSEC), or FIPS approved equivalent). Only
operating systems that have been evaluated by a NIST accredited evaluation authority and
against a FIPS approved criteria shall be used.
- All cryptographic keys, authentication data, other critical security parameters, control
inputs and status outputs shall be communicated only via a trusted mechanism (e.g., a
dedicated I/O port or a trusted path). When a trusted path is used, the trusted computing
base (TCB) of the operating system shall support the trusted path between itself and the
operators for use when a positive TCB-to-operator connection is required. Communications
via this trusted path shall be activated exclusively by an operator or the TCB and shall
be logically isolated and unmistakably distinguishable from other paths.
- The operating system shall provide the capability to audit the entry of cryptographic
keys, other critical security parameters, and control inputs and status outputs.
SECURITY LEVEL 4
In addition to the applicable requirements for Security Levels 1, 2 and 3, the
following requirements shall also apply for Security Level 4.
- All cryptographic software, cryptographic keys and other critical security parameters,
control and status information shall be labelled and under the control of an operating
system that provides structured protection (i.e., B2 protection in accordance with the
Trusted Computer System Evaluation Criteria (TCSEC), or FIPS approved equivalent). Only
operating systems that have been evaluated by a NIST accredited evaluation authority and
against a FIPS approved criteria shall be used.
Cryptographic key management is concerned with the entire life cycle of the
cryptographic keys employed with a cryptographic-based security system, including their
generation, distribution, entry and use, storage, destruction and archiving. Cryptography
may play an important role in key management. A cryptographic module will not only have
its own key management requirements, but may also be utilized as part of the key
management process for another cryptographic module or cryptographic-based security
system.
Key management is required for all cryptographic modules, whether the module implements
a secret key (symmetric) algorithm or a public key (asymmetric) algorithm. Secret keys and
private keys shall be protected from unauthorized disclosure, modification and
substitution. Public keys shall be protected against unauthorized modification and
substitution.
A cryptographic module may optionally implement an internal key generation function.
The module shall implement a FIPS approved key generation algorithm. Documentation shall
specify the FIPS approved key generation algorithm that is implemented by the module.
When a random number generator is used in the key generation process, all values shall
be generated randomly or pseudo-randomly such that all possible combinations of bits and
all possible values are equally likely to be generated. A seed key, if used, shall be
entered in the same manner as cryptographic keys (see Section 4.8.3).
Intermediate key generation states and values shall not be accessible outside of the
module in plaintext or otherwise unprotected form.
Key distribution may be performed by manual methods, automated methods, or a
combination of automated and manual methods. A cryptographic module shall implement FIPS
approved key distribution techniques (e.g. FIPS 171 - Key Management Using ANSI X9.17).
Until such time as a FIPS approved public key-based key distribution technique is
established, commercially available public key methods may be used. Documentation shall
specify the key distribution techniques that are implemented by the module.
Manually-distributed cryptographic keys may be entered into or output from a
cryptographic module either by purely manual methods (e.g., via a keyboard, rotary
switches, thumbwheels, or LCD displays) or by electronic methods (e.g., via memory
cards/tokens such as magnetic-striped cards and integrated circuit (IC) chip devices,
smart cards/tokens, or other electronic key loaders).
Manually-entered cryptographic keys (keys entered using manual methods) shall be
verified during entry into a cryptographic module for accuracy using the manual key entry
test specified in Section 4.11.2.
During key entry, keys and key components may be temporarily displayed to allow visual
verification and to improve accuracy. When encrypted keys or key components are entered,
the resulting plaintext secret or private keys shall not be displayed.
A means shall be provided to ensure that a key entered into or output from a module is
associated with the correct entities (i.e., person, group, or process) to which the key is
assigned.
SECURITY LEVELS 1 AND 2
For Security Levels 1 and 2, when manually-distributed secret keys or private keys are
entered into or output from a cryptographic module they may be entered or output as
plaintext keys. Optionally, the keys may be entered or output either (1) in encrypted
form, or (2) under split knowledge procedures (i.e., as two or more plaintext key
components), as required below for Security Levels 3 and 4. Electronically distributed
secret and private keys shall be entered and output in encrypted form.
SECURITY LEVELS 3 AND 4
For Security Levels 3 and 4, manually-distributed secret and private keys shall not be
entered into or output from a cryptographic module in plaintext form. When
manually-distributed secret or private keys are entered into or output from a
cryptographic module, they shall be entered or output either (1) in encrypted form, or (2)
using split knowledge procedures (i.e., as two or more plaintext key components). When a
secret key or private key is entered or output under split knowledge procedures, the
module shall provide the capability to separately authenticate the operator for each key
component. Furthermore, the key components shall be entered directly into the
cryptographic module or output directly from the cryptographic module (e.g., via a trusted
path or directly attached cable), without traveling through any enclosing or intervening
systems where the components could be stored, combined, or otherwise processed.
Electronically distributed secret and private keys shall be entered and output in
encrypted form.
When contained within a cryptographic module, secret and private keys may be stored in
plaintext form. These plaintext keys shall not be accessible from outside the module.
A means shall be provided to ensure that all keys are associated with the correct
entities (i.e., person, group, or process) to which the keys are assigned.
A cryptographic module shall provide the capability to zeroize all plaintext
cryptographic keys and other unprotected critical security parameters within the module.
Zeroization of cryptographic keys and other critical security parameters is not required
if the keys and
