NIST SP 800-57 Part 1 Rev. 5 日本語訳

NIST Special Publication 800-57 Part 1

Revision 5

Part 1 – General

Elaine Barker

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-57pt1r5

NIST Special Publication 800-57 Part 1

Revision 5

Part 1 – General

Elaine Barker

Computer Security Division Information Technology Laboratory

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-57pt1r5

May 2020

U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology

Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

This publication has been developed by the National Institute of Standards and Technology (NIST) in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-57 Part 1, Revision 5

Natl. Inst. Stand. Technol. Spec. Publ. 800-57 Part 1 Rev. 5, 170 pages (May 2020)

CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-57pt1r5

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

National Institute of Standards and Technology

Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Email: keymanagement@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

This Recommendation provides cryptographic key-management guidance. It consists of three parts. Part 1 provides general guidance and best practices for the management of cryptographic keying material, including definitions of the security services that may be provided when using cryptography and the algorithms and key types that may be employed, specifications of the protection that each type of key and other cryptographic information requires and methods for providing this protection, discussions about the functions involved in key management, and discussions about a variety of key-management issues to be addressed when using cryptography. Part 2 provides guidance on policy and security planning requirements for U.S. government agencies. Part 3 provides guidance when using the cryptographic features of current systems.

archive; authentication; authorization; availability; backup; compromise; confidentiality; cryptographic key; cryptographic module; digital signature; hash function; key agreement; key management; key recovery; keying material; key transport; private key; public key; secret key; trust anchor.

The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates contributions by previous authors of this document on the many security issues associated with this Recommendation: William Barker, William Burr, and Timothy Polk from NIST; Miles Smid from Orion Security; and Lydia Zieglar from the National Security Agency. NIST also thanks the many contributions by the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication. NIST especially appreciates the comments submitted before, during, and after the public comment period by Paul Turner from Venafi.

Patent Disclosure Notice

NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

Cryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography. These keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.

The proper management of cryptographic keys is essential to the effective use of cryptography for security. Poor key management may easily compromise strong algorithms. This Recommendation provides guidance on the management of a cryptographic key throughout its lifecycle, including its secure generation, storage, distribution, use, and destruction.

Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of cryptographic mechanisms and protocols associated with the keys, and the protection provided to the keys. Secret and private keys need to be protected against unauthorized disclosure, and all keys need to be protected against modification.

Cryptographic keys are used across a broad range of systems and applications in enterprises, many of which are managed by individuals who may not have expertise in key management. Consequently, organizations must ensure that clear guidance and oversight is provided for the proper management of keys, as well as controls to ensure that the guidance is being properly followed and implemented.

Organizations and developers are presented with many choices in their use of cryptographic mechanisms. Inappropriate choices may result in an illusion of security but little or no real security for the protocol or application. This Recommendation (i.e., Special Publication (SP) 800-57) provides background information and establishes frameworks to support appropriate decisions when selecting and using cryptographic mechanisms.

Cryptographic modules are used to perform cryptographic operations using these keys. This Recommendation does not address the implementation details for cryptographic modules that may be used to achieve the security requirements identified herein. These details are addressed in Federal Information Processing Standard (FIPS) 140 [FIPS 140] and its associated implementation guidance and derived test requirements (available at https://csrc.nist.gov/projects/cmvp/).

This Recommendation is written for several different audiences and is divided into three parts:

The use of cryptographic mechanisms is one of the strongest ways to provide security services for communications, data storage, and other applications. The National Institute of Standards and Technology (NIST) publishes Federal Information Processing Standards (FIPS) and NIST Recommendations (which are published as Special Publications (SPs)) that specify cryptographic techniques for protecting sensitive, unclassified information.

Since NIST published the Data Encryption Standard (DES) in 1977, the suite of approved standardized algorithms has grown. New classes of algorithms have been added, such as secure hash functions and asymmetric key algorithms for digital signatures. The suite of algorithms now provides different levels of cryptographic strength through a variety of key lengths. The algorithms may be combined in many ways to support increasingly complex protocols and applications. This NIST Recommendation applies to U.S. government agencies using cryptography for the protection of their sensitive, unclassified information. On a voluntary basis, this Recommendation may also be followed by other organizations that want to implement sound security principles in their computer systems.

The proper management of cryptographic keys and other key information is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If an adversary knows the combination, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of the information protected by cryptography directly depends on the strength of the keys, the effectiveness of the mechanisms and protocols associated with the keys, and the protection afforded to the keys. Cryptography can be rendered ineffective by the use of weak implementations, inappropriate algorithm pairing, poor physical security, and the use of weak (i.e., vulnerable) protocols.

Key management is the process of managing a key throughout its lifecycle, including its secure generation, storage, distribution, use, and destruction. Keys may be managed manually, but in many cases, an automated system is required to oversee, automate, and secure the key-management process. An automated system that performs key management is commonly known as a (cryptographic) key management system; see SP 800-130¹ and SP 800-152.²

Organizations and developers are presented with many new choices in their use of cryptographic mechanisms. Inappropriate choices may result in an illusion of security but little or no real security for the protocol or application. This Recommendation (i.e., SP 800-57) provides background information and establishes frameworks to support appropriate decisions when selecting and using cryptographic mechanisms.

The audiences for this Recommendation for Key Management include system or application owners and managers, cryptographic module developers, protocol developers, and system administrators. The Recommendation is provided in three parts, which have been tailored to specific audiences.

Part 1 of this Recommendation (i.e., this document) provides general key-management guidance that is intended to be useful to both system developers and system administrators.³ Cryptographic module developers may benefit from this general guidance through a greater understanding of the key-management features that are required to support specific applications. Protocol developers may identify key-management characteristics associated with specific suites of algorithms and gain a greater understanding of the security services provided by those algorithms. System administrators may use Part 1, along with Part 3, to assist in determining configuration settings that would be most appropriate for their systems.

Part 2 of this Recommendation (i.e., SP 800-57, Part 2⁴) is tailored for system or application owners⁵ for their use in identifying appropriate organizational key-management infrastructures, establishing organizational key-management policies, and specifying organizational key-management practices and plans.

Part 3 of this Recommendation (i.e., SP 800-57, Part 3⁶) addresses the key-management issues associated with currently available cryptographic mechanisms and is intended to provide guidance to system installers, system administrators, and end users of existing key-management infrastructures, protocols, and other applications, as well as the people making purchasing decisions for new systems using currently available technology.

Although some background information and rationale are provided for context and to support the recommendations, this document assumes that the reader has a basic understanding of cryptography. For background material, readers may refer to a variety of NIST and commercial publications, including SP 800-175B,⁷ which provides guidance for using cryptography and NIST’s cryptographic standards, and SP 800-32,⁸ which provides an introduction to a public-key infrastructure.

This Recommendation encompasses cryptographic algorithms, infrastructures, protocols, implementations, applications, and the management thereof. All cryptographic algorithms currently approved by NIST for the protection of unclassified but sensitive information are within the scope of the Recommendation.

This Recommendation focuses on issues involving the management of cryptographic keys: their generation, use, and eventual destruction. Related topics such as algorithm selection and appropriate key length, cryptographic policy, and cryptographic module selection are also included in this Recommendation. Some of the topics noted above are also addressed in other NIST standards and guidance. This Recommendation supplements more focused standards and guidelines.

This Recommendation does not address the implementation details for cryptographic modules that may be used to achieve the identified security requirements. These details are addressed in FIPS 140,⁹ the FIPS 140 implementation guidance, and the derived test requirements (available at https://csrc.nist.gov/projects/cmvp).

This Recommendation does not address the requirements or procedures for operating a key archive or backup capability other than discussing the types of keying material that are appropriate to back up or include in an archive and the protection to be provided to that keying material.

This Recommendation often uses “requirement” terms, which have the following meaning in this document:

Federal Information Processing Standards (FIPS) and NIST Recommendations, collectively referred to as “NIST standards,” are valuable because:

Since 1977, NIST has developed a cryptographic “toolkit” of NIST standards¹¹ that form a basis for the implementation of approved cryptography. This Recommendation references many of those standards and provides guidance on how they may be properly used to protect sensitive information.

Part 1, General Guidance, contains basic key-management guidance. It is intended to advise developers and system administrators on the “best practices” associated with key management.

The definitions provided below are defined as used in this document. The same terms may be defined differently in other documents.

This Recommendation uses several terms relating to the management of cryptographic key information. While each of these terms is defined in Section 2.1, it may be useful to compare these terms and show their relationship since they will be used throughout the document.

Keys are owned and used by entities (e.g., individuals (humans), organizations, devices, or processes) that interact with other entities to conduct business. In the case of non-human owners (e.g., the organization, device, or process), the owner is represented or sponsored by one or more humans. For example, if the owner is an organization, then several humans may be authorized to use the key; the humans may be said to represent the organization when conducting its business. In the case of a device or process, the device or process owns and uses the key, but a human sponsor is responsible for managing the key (e.g., generating or replacing the key when required).

Symmetric keys and the private keys of asymmetric-key (public-key) algorithms require confidentiality protection, and some metadata elements may also require this protection. All key information requires integrity protection.

The following abbreviations and acronyms are used in this Recommendation:

2TDEA Two-key Triple Data Encryption Algorithm specified in SP 800-67¹⁴

3TDEA Three-key Triple Data Encryption Algorithm specified in SP 800-67

AES Advanced Encryption Standard specified in FIPS 197¹⁵

ANS American National Standard

ANSI American National Standards Institute

CA Certification Authority

CRC Cyclic Redundancy Check

CRL Certificate Revocation List

DRBG Deterministic Random Bit Generator specified in SP 800-90A¹⁶

DSA Digital Signature Algorithm specified in FIPS 186¹⁷

ECC Elliptic Curve Cryptography

ECDSA Elliptic Curve Digital Signature Algorithm specified in FIPS 186

EdDSA Edwards-Curve Digital Signature Algorithm specified in RFC 8032¹⁸ and approved in FIPS 186

FFC Finite Field Cryptography

FIPS Federal Information Processing Standard

HMAC Keyed-Hash Message Authentication Code specified in FIPS 198

IFC Integer Factorization Cryptography

ISO/ITU-T International Organization for Standardization/International Telecommunication Union − Telecommunication

IV Initialization Vector

KMAC Keccak-based Message Authentication Code specified in SP 800-185.

MAC Message Authentication Code

MQV Menezes-Qu-Vanstone; an algorithm approved in SP 800-56A¹⁹ for key establishment

NIST National Institute of Standards and Technology

PKI Public-Key Infrastructure

POP Proof of Possession

RA Registration Authority

RBG Random Bit Generator

RNG Random Number Generator

RSA Rivest, Shamir, Adelman; an algorithm approved in FIPS 186 for digital signatures and in SP 800-56B²⁰ for key establishment

S/MIME Secure Multipurpose Internet Mail Extensions

SHA-2 Secure Hash Algorithm specified in FIPS 180²¹

SSH Secure Shell protocol

TDEA Triple Data Encryption Algorithm; Triple DEA specified in SP 800-67

TLS Transport Layer Security

Cryptography may be used to provide or support several basic security services: confidentiality, identity authentication, integrity authentication, source authentication, authorization, and non-repudiation. These services may also be required to protect a key and other key information related to that key. In addition, there are other cryptographic and non-cryptographic mechanisms that are used to support these security services. In general, a single cryptographic mechanism may provide more than one service (e.g., the use of digital signatures can provide integrity authentication and source authentication) but not all services.

Confidentiality is the property whereby information is not disclosed to unauthorized parties; secrecy is a term that is often used synonymously with confidentiality. Confidentiality can be obtained using encryption to render the information unintelligible except by an authorized entity who uses an appropriate key to decrypt the encrypted information. In order for encryption to provide confidentiality, the cryptographic algorithm used for encryption and its mode of operation must be designed and implemented so that an unauthorized party cannot determine the decryption key associated with the encryption or be able to derive the plaintext directly without using the key.

Data integrity is a property whereby data has not been modified in an unauthorized manner since it was created, transmitted, or stored. Modification includes the insertion, deletion, and substitution of data. Cryptographic mechanisms, such as message authentication codes or digital signatures, can be used to detect (with a high probability) both accidental modifications (e.g., modifications that sometimes occur during noisy transmissions or by hardware memory failures) and deliberate modifications by an adversary. Non-cryptographic mechanisms are also often used to detect accidental modifications but cannot be relied upon to detect deliberate modifications. A more detailed treatment of this subject is provided in Appendix A.

In this Recommendation, the statement that a cryptographic algorithm “provides data integrity” means that the algorithm can be used to detect unauthorized modifications. Authenticating integrity is discussed in the next section.

Three types of authentication services can be provided using cryptography: identity authentication, integrity authentication, and source authentication.

Source authentication and identity authentication are very similar but have different purposes. For example, source authentication is concerned with who originated a message, whereas identity authentication is used to gain access to some service.

Several cryptographic mechanisms may be used to provide authentication services. Most commonly, digital signatures or message authentication codes are used to provide authentication; some key-agreement techniques may also provide authentication.

When multiple individuals are permitted to share the same identity or source authentication information (such as a password or cryptographic key), it is sometimes called role-based authentication. See FIPS 140.

Authorization is concerned with providing an official sanction or permission to perform a function or activity (e.g., access a document or access a room). Authorization is considered to be a security service that is often supported by a cryptographic service. Normally, authorization is granted only after the execution of a successful identity authentication service. A non-cryptographic analog of the interaction between identity authentication and authorization is the examination of an individual’s credentials to establish their identity (the identity authentication process). After verifying the individual’s identity and verifying that the individual is authorized access to some resource, such as a locked room, the individual is often provided with a key (e.g., an authorization key) or password that will allow access to that resource.

Identity authentication can also be used to authorize a role (such as a system administrator or audit role) rather than identify an individual. Once authenticated for a role, an entity is authorized for all the privileges associated with that role.

In key management, non-repudiation is a term associated with digital signature keys and digital certificates that bind the name of the certificate subject to a public key. When non-repudiation is indicated for a digital signature key, it means that the signatures created by that key not only support the usual integrity and source authentication services of digital signatures but may also (depending upon the context of the signature) indicate commitment by the certificate subject in the same sense that a handwritten signature on a document may indicate commitment to a contract.

A real determination of non-repudiation is a legal decision with many aspects to be considered. Cryptographic mechanisms can only be used as one element in this decision (i.e., a digital signature can only be used to support a non-repudiation decision).

The basic cryptographic security services discussed above often require other supporting services. For example, cryptographic services often require the use of key establishment and random number generation services. Key establishment is the process by which cryptographic keys are securely established among entities using manual transport methods (e.g., key loaders), automated methods (e.g., key-transport and/or key-agreement protocols), or a combination of automated and manual methods. Random numbers are needed during the generation of cryptographic keys, challenge values, and nonces (see SP 800-175B).

In many applications, a combination of security services (e.g., confidentiality, integrity authentication, source authentication, and support for non-repudiation) is desired. Designers of secure systems often begin by considering which security services are needed to protect the information stored and processed by the system. After these services have been determined, the designer then considers what mechanisms will best provide these services. Not all mechanisms are cryptographic in nature. For example, physical security may be used to protect the confidentiality of certain types of data (e.g., by placing the data in a safe), and identification badges or biometric identification devices may be used for identity authentication. However, cryptographic mechanisms consisting of algorithms, keys, and other keying material often provide an additional, cost-effective means of protecting the security of information. This is particularly true in applications where the information would otherwise be exposed to unauthorized entities.

When properly implemented, some cryptographic algorithms provide multiple services. The following examples illustrate this case:

It is often the case that different algorithms and procedures need to be employed in order to provide all of the desired services.

Example:

Consider a system where the secure exchange of information between pairs of internet entities is needed. Some of the exchanged information requires only integrity protection, while other information requires both integrity and confidentiality protection. It is also a requirement that each entity that participates in an information exchange knows the identity of the other entity.

The designers of this example system decide that a Public Key Infrastructure (PKI) needs to be established and that each individual wishing to communicate securely is required to obtain the necessary public key certificates after physically proving their identity. A PKI includes one or more Certificate Authorities (CAs) that are responsible for creating certificates and usually at least one Registration Authority (RA) associated with each CA; an RA is responsible for confirming the identities of entities requesting certificates. The identity-proving process requires the presentation of proper credentials, such as a driver’s license, passport, or birth certificate.

Two types of public key certificates are commonly used: certificates used for digital signatures and certificates used for key establishment (i.e., for key agreement or key transport); see Section 4.3 and SP 800-175B.

When using digital signature certificates, one entity (i.e., a signatory) signs data using the private key and sends the signed data to an intended recipient. The recipient obtains the signatory’s public key certificate (e.g., from the recipient or some repository), verifies the certificate using the CA’s public key that corresponds to the private key used to sign the certificate, and then uses the public key in the certificate (i.e., the public key corresponding to the private key used by the signatory) to verify the signature on the received data. By using this process, the recipient obtains assurances of both the integrity and the source of the received data using a digital signature algorithm.

Two methods of key establishment are generally used: key-agreement and key transport. Key agreement requires that when two entities wish to communicate, they need to exchange information (e.g., their key-establishment certificates and possibly other information) that allows both entities to generate the same key(s). Key transport requires that one entity (the sender) use the other entity's certified public key to encrypt the key(s) to be sent to the other entity. In both cases, the key-establishment certificates are checked by verifying the CA’s signature on the certificate before using the agreed-upon or transported key(s).

The agreed-upon and transported key(s) is/are then used, for example, by an encryption or message authentication algorithm to provide confidentiality or integrity protection for transmitted data. The receiver of the data protected by the symmetric key(s) has assurance that the data came from the other entity indicated by the public-key certificate (i.e., source authentication for the symmetric key(s) has been obtained).

The above example provides a basic sketch of how cryptographic algorithms may be used to support multiple security services. However, it can be easily seen that the security of such systems depends on many factors, including:

Therefore, the design of a security system that provides the desired security services by making use of cryptographic algorithms and sound key-management techniques requires careful consideration of all factors and risk. The design and implementation of such systems should be performed by analysts who have the necessary skills and expertise to effectively consider and address all of these factors and risks.

FIPS-approved or NIST-recommended cryptographic algorithms shall be used whenever cryptographic services are required. These approved algorithms have undergone an intensive security analysis prior to their approval and continue to be examined to ensure that the algorithms provide adequate security. Most cryptographic algorithms require cryptographic keys and other keying material. In some cases, an algorithm may be strengthened by increasing the key size used. This Recommendation advises the users of cryptographic mechanisms on the appropriate choices of algorithms and key sizes.

Important note: Cryptanalytic algorithms, such as Shor’s algorithms running on future quantum computers, are projected to be able to defeat the security provided by currently approved asymmetric algorithms. A transition to post-quantum algorithms is planned for the future. See https://csrc.nist.gov/projects/post-quantum-cryptography for the status of this effort.

This section describes the approved cryptographic algorithms that provide security services, such as confidentiality, identity authentication, integrity authentication, and source authentication. These services may be fulfilled using several different algorithms, and in many cases, the same algorithm may be used to provide multiple services. See SP 800-175B for additional information on providing cryptographic services.

There are three basic classes of approved cryptographic algorithms: hash functions (Section 4.1), symmetric-key algorithms (Section 4.2), and asymmetric-key algorithms (Section 4.3). The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm. The keys required for using these algorithms must be generated using random bit generators (Section 4.4).

Cryptographic hash functions do not require keys for their basic operation. A cryptographic hash function (also called a hash algorithm) is a cryptographic primitive that produces a condensed representation of its input (e.g., a message or other data). Common names for the output of a hash function include hash value, hash, message digest, and digital fingerprint. The maximum number of input and output bits is determined by the design of the hash function. All approved hash functions are cryptographic hash functions and are defined in FIPS 180, FIPS 202,23 and SP 800-185. SP 800-175B²⁴ provides a brief description of how a hash function works.

With a well-designed cryptographic hash function, it is not feasible to construct or find a message that will produce a given hash value (pre-image resistance), nor is it feasible to find two messages that produce the same hash value (collision resistance). Algorithm standards need to specify either the appropriate size for the hash function or provide the hash function selection criteria if the algorithm can be configured to use different hash functions.

Many algorithms and schemes that provide a security service use a hash function as a component of the algorithm (i.e., a hash function is used as a building block). For example:

Symmetric-key algorithms (sometimes known as secret-key algorithms) transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse (e.g., for both encryption and decryption). Symmetric keys are often known by more than one entity; however, the key shall be generated using a random process and shall not be disclosed to entities that are not authorized access to the data protected by that algorithm and key.

Two classes of symmetric-key algorithms have been approved: those based on block cipher algorithms (e.g., AES, as specified in FIPS 197) and those based on the use of hash functions (e.g., a keyed-hash message authentication code, as specified in FIPS 198). SP 800-175B provides discussions on each algorithm type as well as the modes of operation that are used with block cipher algorithms.

Symmetric-key algorithms are used, for example, to:

Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should be under the sole control of the entity that “owns” the key pair.³⁰ Even though the public and private keys of a key pair are related, knowledge of the public key cannot be used to determine the private key.

With an asymmetric-key algorithm, one of the keys of the key pair is used to apply cryptographic protection, and the other key is used to remove or verify that protection. The key to use depends on the algorithm used and the service to be provided. Asymmetric algorithms are used, for example, to:

SP 800-175B provides discussions on the use of asymmetric-key algorithms to generate digital signatures and establish keying material.

Random bit generators (RBGs) (also called random number generators (RNGs)) are required for the generation of keying material (e.g., keys and IVs). RBGs generate sequences of random bits (e.g., 010011); technically, RNGs translate those bits into numbers (e.g., 010011 is translated into the number 19). However, the term “random number generator” (RNG) is commonly used to refer to both concepts. The use of RBGs is discussed in SP 800-175B; approved RBGs are specified in the SP 800-90 series of documents.

This section classifies the different types of keys and other cryptographic information according to their uses; discusses cryptoperiods and suggests appropriate cryptoperiods for each key type; provides recommendations and requirements for other keying material; introduces assurance of domain-parameter validity, public-key validity, and private-key possession; discusses the implications of the compromise of keying material; and provides guidance on the selection, implementation, and replacement of cryptographic algorithms and key sizes according to their security strengths.

There are several different types of cryptographic keys, each used for a different purpose. In addition, there is other information that is specifically related to cryptographic algorithms and keys. The generation of these keys is discussed in SP 800-133.33

Several different types of keys are defined. The keys are identified according to their classification as public, private, or symmetric (i.e., secret) keys, and their use is indicated. For public and private key-agreement keys, their status as static or ephemeral keys is also specified. See Table 5 in Section 6.1.1 for the required protections for each key type.

Other information used in conjunction with cryptographic algorithms and keys also needs to be protected. See Table 6 in Section 6.1.2 for the required protections for each type of information.

In general, a single key shall be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures). There are several reasons for this:

This principle does not preclude using a single key in cases where the same process can provide multiple services. This is the case, for example, when a digital signature provides integrity authentication and source authentication using a single digital signature or when a single symmetric key can be used to encrypt and authenticate data in a single cryptographic operation (e.g., using an authenticated-encryption operation as opposed to separate encryption and authentication operations). Refer to Section 3.7.

This Recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case:

When requesting the (initial) certificate for a static key-establishment key that was generated as specified in FIPS 186 (see SP 800-56A and SP 800-56B), the corresponding private key may be used to sign the certificate request. Refer to Section 8.1.5.1.1.2.

A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect. A suitably defined cryptoperiod:

Sometimes, cryptoperiods are defined by an arbitrary time period or maximum amount of data protected by the key. However, trade-offs associated with the determination of cryptoperiods involve the risk and consequences of exposure, which should be carefully considered when selecting the cryptoperiod (see Section 5.6.4).

If a key is compromised, its cryptoperiod shall no longer be considered valid. See Section 5.5 for discussions on handling compromised keys.

Among the factors affecting the length of a cryptoperiod are:

In general, short cryptoperiods enhance security. For example, some cryptographic algorithms might be less vulnerable to cryptanalysis if the adversary has only a limited amount of information encrypted under a single key. On the other hand, where manual key-distribution methods are subject to human error and frailty, more frequent key changes might actually increase the risk of key exposure. In these cases, especially when very strong cryptography is employed in hardware, it may be more prudent to have fewer, well-controlled manual key distributions rather than more frequent, poorly controlled manual key distributions.

In general, where strong cryptography is employed, physical, procedural, and logical access-protection considerations often have more impact on cryptoperiod selection than do algorithm and key-size factors. In the case of approved algorithms, modes of operation, and key sizes, adversaries may be able to access keys through the penetration or subversion of a system with less expenditure of time and resources than would be required to mount and execute a cryptographic attack.

The consequences of exposure are measured by the sensitivity of the information, the criticality of the processes protected by the cryptography, and the cost of recovery from the compromise of the information or processes. Sensitivity refers to the lifespan of the information being protected (e.g., 10 minutes, 10 days, or 10 years) and the potential consequences of a loss of protection for that information (e.g., the disclosure of the information to unauthorized entities). In general, as the sensitivity of the information or the criticality of the processes protected by cryptography increase, the length of the associated cryptoperiods should decrease in order to limit the damage that might result from each compromise. This is subject to the caveat regarding the security and integrity of the re-keying or key-derivation process (see Sections 8.2.3 and 8.2.4). However, short cryptoperiods may be counter-productive, particularly where denial-of-service is the paramount concern and there is a significant potential for error in the re-keying or key-derivation process.

Keys that are used for confidentiality protection of communication exchanges may often have shorter cryptoperiods than keys used for the protection of stored data. Cryptoperiods are generally made longer for stored data because the overhead of generating new keys and re-encrypting all data that was encrypted using the old keys may be burdensome.

In some cases, the costs associated with changing keys are painfully high. Examples include the decryption and subsequent re-encryption of very large databases, the decryption and re-encryption of distributed databases, and the revocation and replacement of a very large number of keys (e.g., where there are very large numbers of geographically and organizationally distributed key holders). In such cases, the expense of the security measures necessary to support longer cryptoperiods may be justified (e.g., costly and inconvenient physical, procedural, and logical access security and the use of cryptography strong enough to support longer cryptoperiods even where this may result in significant additional processing overhead). In other cases, the cryptoperiod may be shorter than would otherwise be necessary; for example, keys may be changed frequently in order to limit the period of time that a key-management system maintains status information.

For asymmetric-key key pairs, each key of the pair has its own cryptoperiod. One key of the key pair is used to apply cryptographic protection (e.g., create a digital signature), and its cryptoperiod is called the “originator-usage period.” The other key of the key pair is used to process the protected information (e.g., verify a digital signature); its cryptoperiod is called the “recipient-usage period.” The key pair’s originator and recipient-usage periods typically begin at the same time, but the recipient-usage period may extend beyond the originator-usage period. For example:

For a private signature key that is used to generate digital signatures as a proof-of-origin (i.e., for source authentication), the originator-usage period (i.e., the period during which the private key may be used to generate signatures) is often shorter than the recipient-usage period (i.e., the period during which the signature may be verified by the public signature-verification key). In this case, the private key is intended for use for a fixed period of time, after which the key owner shall destroy⁵⁶ the private key. The public key may be available for a longer period for verifying signatures.

The cryptoperiod of a private source-authentication key that is used to sign challenge information is basically the same as the cryptoperiod of the associated public key (i.e., the public source-authentication key). That is, when the private key is no longer to be used to sign challenges, the public key is no longer needed. In this case, the originator and recipient-usage periods are the same.

The originator-usage period (i.e., the period during which the public key may be used for encryption) is often shorter than the recipient-usage period (i.e., the period during which the encrypted information may be decrypted).

Where public keys are distributed in public-key certificates, each certificate has a validity period indicated by the notBefore and notAfter dates in the certificate. Certificates may be renewed (i.e., a new certificate containing the same public key may be issued with a new validity period). The range of time covered by the validity periods of the original certificate and all renewed certificates for the same public key shall not extend beyond the beginning and end dates of the cryptoperiod for the key of the key pair used to apply protection (i.e., the key with the originator-usage period).

See Section 5.3.6 for guidance regarding specific key types.

For symmetric keys, a single key is used for both applying the protection (e.g., encrypting or computing a MAC on data) and processing the protected information (e.g., decrypting the encrypted data or verifying a MAC). The period of time during which cryptographic protection may be applied to data is called the originator-usage period, and the period of time during which the protected information is processed is called the recipient-usage period. A symmetric key shall not be used to provide protection after the end of the originator-usage period. The recipient-usage period may extend beyond the originator-usage period (see Figure 1). This permits all information that has been protected by the originator to be processed by the recipient for an extended period of time after protection has been applied. However, in many cases, the originator and recipient-usage periods are the same. The (total) “cryptoperiod” of a symmetric key is the period of time from the beginning of the originator-usage period to the end of the recipient-usage period, although the originator-usage period has historically been used as the cryptoperiod for the key.

Note that in some cases, predetermined cryptoperiods may not be adequate for the security life of the protected data. If the required security life exceeds the cryptoperiod, then the protection may need to be reapplied using a new key.

Figure 1: Symmetric-key cryptoperiod

Examples of the usage periods for symmetric keys include the following:

The key type, usage environment, and data characteristics described above may affect the cryptoperiod required for a given key. Suggested cryptoperiods for various key types are provided below. Note that the cryptoperiods suggested are only rough order-of-magnitude guidelines; longer or shorter cryptoperiods may be warranted depending on the application and environment in which the keys will be used. However, when assigning a longer cryptoperiod than suggested below, serious consideration should be given to the risks associated with doing so (see Section 5.3.1). Most of the suggested cryptoperiods are based on a desire for maximum operational efficiency and assumptions regarding the minimum criteria for the usage environment (see FIPS 140 and SP 800-37). The factors described in Sections 5.3.1 through 5.3.3 should be used to determine actual cryptoperiods for specific usage environments.

Some systems use a cryptographic timestamping function to place an unforgeable timestamp on each signed message. Even when the cryptoperiod of a private signature key has expired, the corresponding public signature-verification key may be used to verify signatures on messages whose timestamps are within the cryptoperiod of the private signature key. In this case, one is relying on the cryptographic timestamp function to provide assurance that the message was signed within the private signature key’s originator-usage period.

During the originator-usage period, encryption of the data may be performed using the data-encryption key; the key shall not be used for performing an encryption operation on data beyond this period. However, the key may need to be available to decrypt the protected data beyond the originator-usage period (i.e., the recipient-usage period may need to extend beyond the originator-usage period).

In the case of a symmetric data-encryption key that is used to encrypt single messages or single communications sessions, the lifetime of the protected data could be months or years because the encrypted messages may be stored for later reading. Where data is maintained in encrypted form, a symmetric data-encryption key needs to be maintained until that data is re-encrypted under a new key or destroyed. Note that confidence in the confidentiality of the data is reduced with the passage of time.

Some symmetric key-wrapping keys are used for only a single message or communications session. In the case of these very short-term key-wrapping keys, an appropriate cryptoperiod (i.e., which includes both the originator and recipient-usage periods) is a single communication session. It is assumed that the wrapped keys will not be retained in their wrapped form, so the originator-usage period and recipient-usage period of a key-wrapping key is the same. In other cases, a key-wrapping key may be retained so that the files or messages encrypted by the wrapped keys may be recovered later. In such cases, the recipient-usage period may be significantly longer than the originator-usage period of the key-wrapping key, and cryptoperiods lasting for years may be employed.

A public key-transport key can be publicly known. As indicated in the private key-transport key discussion, due to the potential need to decrypt keys at a time after they have been encrypted for transport, the cryptoperiod of a public key-transport key may be shorter than that of the corresponding private key.

As in the case of a symmetric key-agreement key, the cryptoperiod of this key depends on 1) environmental security factors, 2) the nature (e.g., types and formats) and volume of keys that are established, and 3) the details of the key-agreement algorithm and protocol employed. Note that a private static key-agreement key may be used to establish symmetric keys (e.g., key-wrapping keys) or other secret keying material.

Table 1 below is a summary of the cryptoperiods that are suggested for each key type. Longer or shorter cryptoperiods may be warranted, depending on the application and environment in which the keys will be used. However, when assigning a longer cryptoperiod than suggested below, serious consideration should be given to the risks associated with doing so (see Section 5.3.1).

Table 1: Suggested cryptoperiods for key types

Information other than keys does not have well-established cryptoperiods, per se. The following recommendations are offered regarding the disposition of this other information:

When keying material (e.g., keys, IVs, and domain parameters) is stored or distributed, it may pass through unprotected environments. In such cases, specific assurances are required before the keying material is used to perform normal cryptographic operations.

Assurance of integrity shall be obtained prior to using all keying material.

At a minimum, assurance of integrity shall be obtained by verifying that the keying material has the appropriate format and came from an authorized source. Additional assurance of integrity should be obtained by the proper use of error detection codes, message authentication codes, and digital signatures to provide assurance that keying material has not changed. For example, a message authentication code could be generated on stored key information to provide assurance that the key information has not changed while in storage; the message authentication could be stored with the key information for easy access.

Domain parameters are used by discrete log public-key algorithms during the generation of key pairs, digital signature generation, signature verification, and the generation of shared secrets (during the execution of a key-agreement scheme) that are subsequently used to derive keying material. Assurance of the validity of the domain parameters is important to applications of public-key cryptography and shall be obtained prior to using them.

Invalid domain parameters could void all intended security for all entities using the domain parameters. Methods for obtaining assurance of domain-parameter validity for digital signature algorithms are provided in SP 800-89.64 Methods for obtaining assurance of domain-parameter validity for finite-field and elliptic-curve discrete-log key-agreement algorithms are provided in SP 800-56A.

Note that if a public key is certified by a CA for these algorithms, the CA could obtain this assurance during the certification process. Otherwise, the key-pair owner and any relying parties are responsible for obtaining the assurance.

Assurance of public-key validity shall be obtained on all public keys before using them.

Assurance of public-key validity gives the user confidence that the public key is arithmetically correct. This reduces the probability of using weak or corrupted keys. Invalid public keys could result in voiding the intended security, including the security of the operation (e.g., digital signature generation or key establishment), leaking some or all information from the owner’s private key, and leaking some or all information about a private key that is combined with an invalid public key (as may be done when key agreement or public-key encryption is performed). One of several ways to obtain assurance of public-key validity is for an entity to verify certain mathematical properties that the public key should have. Another way is to obtain the assurance from a trusted third party (e.g., a CA) that the trusted party validated the properties.

Methods for obtaining assurance of public-key validity for the DSA, ECDSA, and RSA digital signature algorithms are provided in SP 800-89. Methods for obtaining this assurance for the finite-field and elliptic-curve discrete-log key-establishment schemes are provided in SP 800-56A. Methods for obtaining assurance of (partial) public-key validity for the RSA key-establishment schemes are provided in SP 800-56B.

Assurance of static (i.e., long-term) private-key possession shall be obtained before the use of the corresponding static public key. Assurance of public-key validity shall always be obtained prior to or concurrently with assurance of possession of the private key. Assurance of possession of the correct private key shall be obtained by the key-pair owner (e.g., ensuring that it is available and has not been modified before use). Entities that receive a public key shall obtain assurance that the key-pair owner possesses the private key corresponding to the received public key.

For specific details regarding the assurance of the possession of private key-establishment keys, see SP 800-56A and SP 800-56B. For specific details regarding assurance of the possession of private digital-signature keys, see SP 800-89. Note that for public keys that are certified by a CA, the CA could obtain this assurance during the certification process. Otherwise, the owner and relying parties are responsible for obtaining the assurance.

Key establishment is the process by which keying material is securely established among entities for subsequent use, usually between pairs of entities. Key confirmation is a procedure used to provide assurance that these entities actually share the same keying material. This procedure is highly recommended and can be performed either within a key-establishment process or after the conclusion of the process. SP 800-56A and SP 800-56B discuss key confirmation performed during automated key establishment.

Information protected by cryptographic mechanisms is secure only if the algorithms remain strong and the keys have not been compromised. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Key compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail; see Section 6) and the key can no longer be trusted to provide the required security. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).

When a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) shall cease, and the compromised key shall be revoked (see Section 8.3.5). However, the continued use of the key under controlled circumstances to remove or verify the protections (e.g., to decrypt or verify a digital signature) may be warranted, depending on the risks of continued use and an organization’s Key-Management Policy (see SP 800-57, Part 2). The continued use of a compromised key shall be limited to processing information that has already been protected. In this case, the entity that uses the information must be made fully aware of the dangers involved. Limiting the cryptoperiod of the key limits the amount of material that would be compromised (exposed) if the key were compromised; using different keys for different purposes (e.g., different applications as well as different cryptographic mechanisms) and limiting the amount of information protected by a single key also achieves this purpose (see Section 5.3).

The compromise of a key has the following implications:

In general, the unauthorized disclosure of a key that is used to provide confidentiality protection⁶⁵ (i.e., via encryption) means that all information encrypted by that key could be determined by unauthorized entities. For example, if a symmetric data-encryption key is compromised, an unauthorized entity might use the key to decrypt past or future encrypted information (i.e., the information is no longer confidential between the authorized entities). In addition, a compromised key could be used by an adversary to encrypt information of the adversary’s choosing, thus providing false information.

The unauthorized disclosure of a private signature key means that the integrity and non-repudiation qualities of all data signed by that key are suspect. An unauthorized party in possession of the private key could sign false information and make it appear to be valid. In cases where it can be shown that the signed data was protected by other mechanisms (e.g., physical security) from a time before the compromise, the signature may still have some value. For example, if a signed message was received on day 1 and it was later determined that the private signing key was compromised on day 15, the receiver may still have confidence that the message is valid because it was maintained in the receiver’s possession before day 15. Note that cryptographic timestamping may also provide protection for messages signed before the private signature key was compromised. However, the security provided by these other mechanisms is now critical to the security of the signature. In addition, the authenticity of the signed message may be questioned since the private signature key may have been disclosed to the message receiver or some other entity who then altered the message in some way.

The disclosure of a CA’s private signature key means that an adversary can create fraudulent certificates and Certificate Revocation Lists (CRLs).

Certain protective measures may be taken in order to minimize the likelihood or consequences of a key compromise. The following procedures are usually involved:

The worst form of key compromise is one that is not detected. Nevertheless, even in this case, certain protective measures can be taken. A key management system should be designed to mitigate the negative effects of a key compromise; the system should be designed so that the compromise of a single key compromises as little data as possible (see SP 800-152). For example, a single cryptographic key could be used to protect the data of only a single human entity or a limited number of such entities. Often, systems have alternative methods to authenticate communicating entities that do not rely solely on the possession of keys. The intent is to avoid building a system with catastrophic weaknesses.

A compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan shall be documented and easily accessible. The plan may be included in a Key-Management Practices Statement (see SP 800-57, Part 2). If not, the Key-Management Practices Statement should reference the compromise-recovery plan.

Although compromise recovery is primarily a local action, the entire community that uses the system or equipment is affected by the repercussions. Therefore, compromise-recovery procedures should include the community at large. For example, recovery from the compromise of a root CA’s private signature key requires that all entities using the infrastructure obtain and install a new trust anchor certificate. Typically, this involves physical procedures that are expensive to implement. To avoid these expensive procedures, elaborate precautions to avoid compromise may be justified.

The compromise-recovery plan should contain:

Other compromise-recovery procedures may include:

Cryptographic algorithms that provide the security services identified in Section 3 are specified or adopted in FIPS and NIST Recommendations. Some of these algorithms are defined for several key sizes. This section provides guidance for the selection of appropriate algorithms and key sizes to provide adequate protection for 1) the expected lifetime of a system and 2) any sensitive data protected by that system during the expected lifetime of the data.

Cryptographic algorithms can provide different “strengths” of security, depending on the algorithm and the key size used (when keys are required by the algorithm). A security strength is a number associated with the amount of work (i.e., the number of operations) that is required to break a cryptographic algorithm or system. Sections 5.6.1.1 and 5.6.1.2 provide the estimated maximum security strengths of the approved cryptographic algorithms for commonly used security strengths: 80, 112, 128, 192, and 256 bits. Note that a security strength of 80 bits is no longer considered adequate.

The comparable security strengths provided below are based on accepted estimates as of the publication of this Recommendation using currently known methods. Advances in factoring algorithms, general discrete-logarithm attacks, elliptic-curve discrete-logarithm attacks, and other algorithmic advances as well as quantum computing may affect these equivalencies in the future. New or improved attacks or technologies may be developed that leave some of the current algorithms completely insecure.

Important note: When large-scale quantum computers become available, they will threaten the security of the approved public-key algorithms. In particular, the digital signature schemes, key-agreement schemes using Diffie-Hellman and MQV,⁶⁷ and the key-agreement and key-transport schemes using RSA may need to be replaced with secure quantum-resistant (or “post-quantum”) counterparts. At the time that this revision of the Recommendation was published, NIST was undergoing a process to select post-quantum cryptographic algorithms for standardization. This process is a multi-year project; when these new standards are available, this Recommendation will be updated with the appropriate guidance. Information on the post-quantum project is available at https://csrc.nist.gov/projects/post-quantum-cryptography.

The use of strong cryptographic algorithms is critical for cryptographic security. However, their implementation and use are also of vital concern since algorithms may unintentionally be implemented in a manner that leaks small amounts of information about the key. In this case, a larger key may reduce the likelihood that this leaked information will eventually compromise that key.

The approved symmetric-key block ciphers (e.g., AES) and public-key (i.e., asymmetric-key) algorithms require the use of cryptographic keys. Security-strength estimates were made under the assumption that the keys are a specified length and are generated and handled in accordance with specific rules (e.g., the keys are generated using RBGs that were seeded with sufficient entropy and meet certain criteria). However, these rules are often not followed, and the security provided to the data protected by those keys may be somewhat less than the security-strength estimates provided (see Section 5.6.2).

Two algorithms are considered to be of comparable strength for the given key sizes (X and Y) if the amount of work needed to “break the algorithms” or determine the keys (with the given key sizes and sufficient entropy) is approximately the same using a given resource. The security strength of an algorithm for a given key size is traditionally described in terms of the amount of work it takes to try all keys for a symmetric-key algorithm with a key size of “X” that has no shortcut attacks (i.e., the most efficient attack is to try all possible keys). In this case, the best attack is said to be an exhaustion attack. An algorithm that has a Y-bit key and an estimated maximum security strength that is comparable to a symmetric-key algorithm with an X-bit key is said to have an “estimated maximum security strength of X bits” or to be able to provide “X bits of security.” Given a few plaintext blocks and the corresponding ciphertext, an algorithm that can provide X bits of security would, on average, take \(2^{X-1}T\) units of time to attack, where T is the amount of time that is required to perform one encryption of a plaintext value and compare the result against the corresponding ciphertext value.

Determining the security strength of an algorithm can be nontrivial. The strength depends on many factors, including the attacker’s capabilities, the key lengths, the amount of data processed using the same key, and how closely keys are related. The attacker's capabilities could include the cryptanalysis techniques used to reduce the time to attack an algorithm, the processing power available to the attacker, and the advent of new types of computing systems (e.g., quantum computers).

Table 2 provides estimated, comparable, maximum-security strengths for the approved symmetric block cipher and asymmetric-key algorithms and key lengths.

Table 2: Comparable security strengths of symmetric block cipher and asymmetric-key algorithms