Key Management: General
70
modifications. The integrity of cryptographic information during transit shall be protected using one or more of the following mechanisms:
1. Manual method physical protection is provided: a An integrity mechanism e.g., a CRC, MAC or digital signature is used on the
information, and the resulting code is provided to the recipient for subsequent verification. Note: A CRC may be used instead of a MAC or digital signature, since
the physical protection is only intended to protect against intentional modifications.
-OR- b The keying material is used to perform the intended cryptographic operation. If the
received information does not conform to the expected format, or the data is inconsistent in the context of the application, then the keying material may have
been corrupted.
2. Automated distribution via communication protocols provided by the user or by the communication protocol:
a An approved cryptographic integrity mechanism e.g., a MAC or digital signature
is used on the information, and the resulting code is provided to the recipient for subsequent verification. Note that a CRC is not approved for this purpose. The
integrity mechanism may be applied only to the cryptographic information, or may be applied to an entire message.
-OR- b The keying material is used to perform the intended cryptographic operation. If the
use of the keying material produces incorrect results, or the data is inconsistent in the context of the application, then the received keying material may have been
corrupted.
The response to the detection of an integrity failure will vary, depending on the specific environment. Improper error handling can allow attacks e.g., side channel attacks. A security
policy see [ SP800-57, Part 2
] should define the response to such an event. For example, if an
error is detected in the received information, and the receiver requires that the information is entirely correct e.g., the receiver cannot proceed when the information is in error, then:
a. The information should not be used, b. The recipient may request that the information be resent retransmissions should be
limited to a predetermined maximum number of times, and
c. Information related to the incident should be stored in an audit log to later identify the
source of the error.
6.2.1.3 Confidentiality
Keying material may require confidentiality protection during transit. If confidentiality protection is required, the keying material shall be protected using one or more of the
following mechanisms:
1. Manual method:
Key Management: General
71
a The keying material is encrypted e.g., wrapped using an approved technique that
provides protection at a security strength that meets or exceeds the security strength required of the keying material.
-OR- b The keying material is separated into key components, with each key component
being generated at a security strength that meets or exceeds the security strength required of the keying material. Each key component is handled, using split-
knowledge procedures see Sections 8.1.5.2.1
and 8.1.5.2.2.1
, so that no single individual can acquire access to all key components.
-OR- c Appropriate physical and procedural protection is provided e.g., by using a trusted
courier. 2. Automated distribution via communication protocols: The keying material is encrypted
e.g., wrapped using an approved technique that provides protection at the security strength that meets or exceeds the security strength required of the keying material.
6.2.1.4 Association with Usage or Application
The association of keying material with its usage or application shall be either specifically identified during the distribution process or be implicitly defined by the use of the application.
See Section 6.2.3
for a discussion of the metadata associated with keys.
6.2.1.5 Association with Other Entities
The association of keying material with the appropriate entity e.g., the entity that shares the keying material shall be either specifically identified during the distribution process e.g.,
using public-key certificates or be implicitly defined by the use of the application. See Section
6.2.3 for a discussion of the metadata associated with keys.
6.2.1.6 Association with Other Related Information
Any association with other related information e.g., domain parameters, the encryptiondecryption key or IVs shall be either specifically identified during the distribution
process or be implicitly defined by the use of the application. See Section 6.2.3
for a discussion of the metadata associated with the other related information.
6.2.2 Protection Mechanisms for Information in Storage
Cryptographic information may be at rest in some device or storage media. This may include copies of the information that is also in transit or in use. Information-at-rest i.e., stored
information, including information contained within a cryptographic module shall be protected in accordance with
Section 6.1 . A variety of protection mechanisms may be used.
The cryptographic information may be stored so as to be immediately available to an application e.g., on a local hard disk or a server; this would be typical for keying material
stored within a cryptographic module or in immediately accessible storage e.g., on a local hard drive. The keying material may also be stored in electronic form on a removable media
e.g., a CD-ROM, in a remotely accessible location, or in hard copy form and placed in a safe; this would be typical for backup or archive storage.
Key Management: General
72
6.2.2.1 Availability
Cryptographic information may need to be readily available for as long as data is protected by the information. A common method for providing this protection is to make one or more copies
of the cryptographic information and store them in separate locations. During a key’s
cryptoperiod, keying material requiring long-term availability should be stored in both normal operational storage see
Section 8.2.1 and in backup storage see
Section 8.2.2.1 .
Cryptographic information that is retained after the end of a key’s cryptoperiod should be placed in archive storage see
Section 8.3.1 . This Recommendation does not preclude the use
of the same storage media for both backup and archive storage. Specifics on the long-term availability requirement for each key type are addressed for backup
storage in Section 8.2.2.1
, and for archive storage in Section 8.3.1
. The recovery of this cryptographic information for use in replacing cryptographic information
that is lost e.g., from normal storage, or in performing cryptographic operations after the end of a key’s cryptoperiod is discussed in Sections
8.2.2.2 recovery during normal operations
and 8.3.1
recovery from archive storage, and in Appendix B
. Even though the primary focus of this section is to provide assurance of the availability of
cryptographic information, there is at least one example where denying the availability of this information may be desired, namely when sanitizing large volumes of information that have
been encrypted. In this case, cryptographic sanitization i.e., destroying the key used to decrypt the information is suggested see [
SP 800-88 ].
6.2.2.2 Integrity
Integrity protection is concerned with ensuring that the information is correct. Absolute protection against modification is not possible. The best that can be done is to use reasonable
measures to prevent modifications, to use methods to detect any modifications that occur with a very high probability, and to restore the information to its original content when
unauthorized modifications have been detected.
All cryptographic information requires integrity protection. Integrity protection shall be provided by physical mechanisms, cryptographic mechanisms or both.
Physical mechanisms include the use of: 1. A validated cryptographic module or operating system that limits access to the stored
information, 2. A computer system or media that is not connected to other systems, and
3. A physically secure environment with appropriate access controls that is outside a computer system e.g., in a safe with limited access.
Cryptographic mechanisms include the use of:
a. An approved cryptographic integrity mechanism e.g., a MAC or digital signature that
