NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 4
All1 Verify a digital signature that is signed by the corresponding2 Encrypt keys that can be decrypted using the corresponding3 Security Services4 Cryptographic Algorithms5 General Key Management Guidance6 Training: If the new system requires that new or different tasks (e.g., key7 Key States and Transitions8 Key-Management Phases and Functions9 Accountability, Audit, and Survivability
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Verify a digital signature that is signed by the corresponding | private key, | |
| 2 | Encrypt keys that can be decrypted using the corresponding | private key, or 3. Compute a shared secret during a key-agreement transaction. Public-key certificate A set of data that uniquely identifies an entity, contains the entity's public key and possibly other information, and is digitally signe | |
| 3 | Security Services | Cryptography may be used to perform or support several basic security services: confidentiality, integrity authentication, source authentication, authorization and non- repudiation. These services may also be required to protect cryptograph | |
| 3.1 in 3 |
Confidentiality | Confidentiality is the property whereby information is not disclosed to unauthorized parties. Secrecy is a term that is often used synonymously with confidentiality. Confidentiality using cryptography is achieved using encryption to render | |
| 3.2 in 3 |
Data Integrity | 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 | |
| 3.3 in 3 |
Authentication | Two types of authentication services can be provided using cryptography: integrity authentication and source authentication. • An integrity authentication service is used to verify that data has not been modified, i.e., this service provid | |
| 3.4 in 3 |
Authorization | Authorization is concerned with providing an official sanction or permission to perform a security function or activity (e.g., accessing a room). Authorization is considered as a security service that is often supported by a cryptographic s | |
| 3.5 in 3 |
Non-repudiation | 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 me | |
| 3.6 in 3 |
Support Services | 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. | |
| 3.7 in 3 |
Combining Services | In many applications, a combination of security services (confidentiality, integrity authentication, source authentication, and support for non-repudiation) is desired. Designers of secure systems often begin by considering which security s | |
| 4 | Cryptographic Algorithms | FIPS- approved or NIST-recommended cryptographic algorithms shall be used whenever cryptographic services are required. These approved algorithms have received an intensive security analysis prior to their approval and continue to be examin | |
| 4.1 in 4 |
Classes of Cryptographic Algorithms | There are three basic classes of approved cryptographic algorithms: hash functions, symmetric-key algorithms and asymmetric-key algorithms. The classes are defined by the number of cryptographic keys that are used in conjunction with the al | |
| 4.2 in 4 |
Cryptographic Algorithm Functionality | Security services are fulfilled using a number of different algorithms. In many cases, the same algorithm may be used to provide multiple services. | |
| 4.2.1 in 4.2 |
Hash Functions | Many algorithms and schemes that provide a security service use a hash function as a component of the algorithm. Hash functions are used by digital signature algorithms (see [FIPS186] ), Keyed-Hash Message Authentication Codes (HMAC) (see [ | |
| 4.2.2 in 4.2 |
Symmetric-Key Algorithms used for Encryption and Decryption | Encryption is used to provide confidentiality for data. The data to be protected is called plaintext when in its original form. Encryption transforms the data into ciphertext. Ciphertext can be transformed back into plaintext using decrypti | |
| 4.2.2.1 in 4.2.2 |
Advanced Encryption Standard (AES) | The AES algorithm is specified in [FIPS197] . AES encrypts and decrypts data in 128-bit blocks, using 128-, 192- or 256-bit keys. The nomenclature for AES for the different key sizes is AES- x , where x is the key size (e.g., AES-256). 3 S | |
| 4.2.2.2 in 4.2.2 |
Triple DEA (TDEA) | Triple DEA is defined in [SP800-67] . TDEA encrypts and decrypts data in 64-bit blocks, using three 56-bit keys. Two variations of TDEA have been defined: two-key TDEA (2TDEA), in which the first and third keys are identical, and three-key | |
| 4.2.2.3 in 4.2.2 |
Modes of Operation | With a block-cipher encryption operation, the same plaintext block will always encrypt to the same ciphertext block whenever the same key is used. If the multiple blocks in a typical message are encrypted separately, an adversary can easily | |
| 4.2.3 in 4.2 |
Message Authentication Codes (MACs) | Message Authentication Codes (MACs) can be used to provide source and integrity authentication. A MAC is a cryptographic checksum on the data that is used in order to provide assurance that the data has not changed and that the MAC was comp | |
| 4.2.3.1 in 4.2.3 |
MACs Using Block Cipher Algorithms | [SP800-38B] defines the CMAC mode: a mode that can be used to compute a MAC using approved block cipher algorithms, such as AES and TDEA. [ SP 800-38D ] defines the GMAC mode that can be used with AES. The key and block size used to compute | |
| 4.2.3.2 in 4.2.3 |
MACs Using Hash Functions | [FIPS198] specifies the computation of a MAC using an approved hash function. A variety of key sizes are allowed for HMAC, which is the MAC algorithm specified in [FIPS198]; the choice of key size depends on the amount of security to be pro | |
| 4.2.4 in 4.2 |
Digital Signature Algorithms | Digital signatures are used to provide source authentication, integrity authentication and support for non-repudiation. Digital signatures are used in conjunction with hash functions and are computed on data of any length (up to a limit tha | |
| 4.2.5 in 4.2 |
Key Establishment Schemes | Automated key-establishment schemes are used to set up keys to be used between communicating entities. Two types of automated key-establishment schemes are defined: key 4 Two general types of digital signature methods are discussed in lite | |
| 4.2.5.1 in 4.2.5 |
Discrete-Log Key-Agreement Schemes | [SP800-56A] specifies key-establishment schemes that use discrete-logarithm-based public- key algorithms. These schemes are specified using either finite-field math (the form of math that most of us use) or elliptic curve math. With the key | |
| 4.2.5.2 in 4.2.5 |
Key Establishment Using Integer-Factorization Schemes | [SP800-56B] provides key-establishment schemes that use integer-factorization-based public- key algorithms (e.g., RSA). These schemes are provided in [SP 800-56B] for both key agreement and key transport, and, in some cases, key confirmatio | |
| 4.2.5.3 in 4.2.5 |
Security Properties of the Key-Establishment Schemes | Cryptographic protocol designers need to understand the security properties of the schemes in order to assure that the desired capabilities are available to the user. In general, schemes where each party uses both an ephemeral and a static | |
| 4.2.5.4 in 4.2.5 |
Key Encryption and Key Wrapping | Key encryption provides confidentiality protection for a key by encrypting that key using a key-encrypting key; decryption reverses the process using the same key. Key wrapping provides both confidentiality and integrity protection for a ke | |
| 4.2.5.5 in 4.2.5 |
Key Confirmation | Key confirmation is used by two parties in a key-establishment process to provide assurance that common keying material and/or a shared secret 5 has been established. The assurance may be provided to only one party (unilateral) or it may be | |
| 4.2.6 in 4.2 |
Key Establishment Protocols | Key establishment protocols use key-establishment schemes in order to specify the processing necessary to establish a key. However, key-establishment protocols also specify message flow and format. Key-establishment protocols need to be car | |
| 4.2.7 in 4.2 |
Random Bit Generation | 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 bit | |
| 5 | General Key Management Guidance | This section classifies the different types of keys and other cryptographic information according to their uses; discusses cryptoperiods and recommends appropriate cryptoperiods for each key type; provides recommendations and requirements f | |
| 6 | Training: If the new system requires that new or different tasks (e.g., key | management procedures) be performed, then the individuals who will perform those tasks should be properly trained. Features that are thought to be improvements may be viewed as annoyances by an untrained user. 7. System implementation and t | |
| 6.1 in 6 |
Protection and Assurance Requirements | Keying material should be (operationally) available as long as the associated cryptographic service is required. Keys may be maintained within a cryptographic module while they are being actively used, or they may be stored externally (prov | |
| 6.1.1 in 6.1 |
Summary of Protection and Assurance Requirements for Cryptographic Keys | Table 5 provides a summary of the protection requirements for keys during distribution and storage. Methods for providing the necessary protection are discussed in Section 6.2 . Guide to Table 5 : a. Column 1 (Key Type) identifies the key t | |
| 6.1.2 in 6.1 |
Summary of Protection Requirements for Other Cryptographic or Related | Information Table 6 provides a summary of the protection requirements for other cryptographic information during distribution and storage. Mechanisms for providing the necessary protection are discussed in Section 6.2 . Guide to Table 6 : a | |
| 6.2 in 6 |
Protection Mechanisms | During the lifetime of cryptographic information, the information is either “in transit” (e.g., is in the process of being manually distributed or distributed using automated protocols to the authorized communication participants for use by | |
| 6.2.1 in 6.2 |
Protection Mechanisms for Cryptographic Information in Transit | Cryptographic information in transit may be keying material that is being distributed in order to obtain a cryptographic service (e.g., establish a key that will be used to provide confidentiality) (see Section 8.1.5 ), cryptographic inform | |
| 6.2.1.1 in 6.2.1 |
Availability | Since communications may be garbled, intentionally altered, or destroyed, the availability of cryptographic information after transit cannot be assured using cryptographic methods. However, availability can be supported by redundant or mult | |
| 6.2.1.2 in 6.2.1 |
Integrity | Integrity protection involves both the prevention and detection of modifications to information. When modifications are detected, measures may be taken to restore the information to its unaltered form. Cryptographic mechanisms are often use | |
| 6.2.1.3 in 6.2.1 |
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: (a) The keying materia | |
| 6.2.1.4 in 6.2.1 |
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 metad | |
| 6.2.1.5 in 6.2.1 |
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 | |
| 6.2.1.6 in 6.2.1 |
Association with Other Related Information | Any association with other related information (e.g., domain parameters, the encryption/decryption key or IVs) shall be either specifically identified during the distribution process or be implicitly defined by the use of the application. S | |
| 6.2.2 in 6.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 | |
| 6.2.2.1 in 6.2.2 |
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 s | |
| 6.2.2.2 in 6.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 d | |
| 6.2.2.3 in 6.2.2 |
Confidentiality | One of the following mechanisms shall be used to provide confidentiality for private or secret keying material in storage: | |
| 6.2.2.4 in 6.2.2 |
Association with Usage or Application | Cryptographic information is used with a given cryptographic mechanism (e.g., digital signatures or a key establishment scheme) or with a particular application. Protection shall be provided to ensure that the information is not used incorr | |
| 6.2.2.5 in 6.2.2 |
Association with the Other Entities | Some cryptographic information needs to be correctly associated with another entity (e.g., the key source), and the integrity of this association shall be maintained. For example, a symmetric (secret) key used for the encryption of informat | |
| 6.2.2.6 in 6.2.2 |
Association with Other Related Information | An association may need to be maintained between protected information and the keying material that is used to protect that information. In addition, keys may require association with other keying material (see Section 6.2.1.6 ). Storing th | |
| 6.2.3 in 6.2 |
Metadata Associated with Cryptographic Information | Metadata may be used with cryptographic information to define the use of that information or to provide a linkage between cryptographic information. | |
| 6.2.3.1 in 6.2.3 |
Metadata for Keys | Metadata is used to provide information about the key, including its parameters, or the intended use of a key, and as such, contains the key’s control information. Different applications may require different metadata elements for the same | |
| 6.2.3.2 in 6.2.3 |
Metadata for Related Cryptographic Information | Cryptographic information other than keying material may need metadata to “point to” the keying material that was used to provide the cryptographic protection for the information. The metadata may also contain other related cryptographic in | |
| 7 | Key States and Transitions | A key may pass through several states between its generation and its destruction. Figure 3 depicts an example of the key states that a key could assume and the transitions among them. Figure 3: Key state and transition example. A key is u | |
| 7.1 in 7 |
Pre-activation State | The key has been generated, but has not been authorized for use. In this state, the key may only be used to perform proof-of-possession ( Section 8.1.5.1.1.2 ) or key confirmation ( Section 4.2.5.5 ). Other than for proof-of-possession or k | |
| 7.2 in 7 |
Active State | The key may be used to cryptographically protect information (e.g., encrypt plaintext or generate a digital signature), to cryptographically process previously protected information (e.g., decrypt ciphertext or verify a digital signature) o | |
| 7.3 in 7 |
Suspended State | The use of a key or key pair may be suspended for several possible reasons; in the case of asymmetric key pairs, both the public and private keys shall be suspended at the same time. One reason for a suspension might be a possible key compr | |
| 7.4 in 7 |
Deactivated State | Keys in the deactivated state shall not be used to apply cryptographic protection, but in some cases, may be used to process cryptographically protected information. If the key has been revoked (i.e., for reasons other than a compromise), t | |
| 7.5 in 7 |
Compromised State | Generally, keys are compromised when they are released to or determined by an unauthorized entity. A compromised key shall not be used to apply cryptographic protection to information. However, in some cases, a compromised key or a public k | |
| 7.6 in 7 |
Destroyed State | The key has been destroyed as specified in Section 8.3.4 . Even though the key no longer exists when in this state, certain key metadata (e.g., key state transition history, key name, type, and cryptoperiod) may be retained for audit purpos | |
| 8 | Key-Management Phases and Functions | The cryptographic key-management lifecycle can be divided into four phases. During each phase, the keys are in certain specific key states as discussed in Section 7 . In addition, within each phase, certain key-management functions are typi | |
| 8.1 in 8 |
Pre-operational Phase | During the pre-operational phase of key management, keying material is not yet available for normal cryptographic operations. | |
| 8.1.1 in 8.1 |
User Registration Function | During user registration, an entity interacts with a registration authority to become an authorized member of a security domain. In this phase, a user identifier or device name may be established to identify the member during future transac | |
| 8.1.2 in 8.1 |
System Initialization Function | System initialization involves setting up or configuring a system for secure operation. This may include algorithm preferences, the identification of trusted parties, and the definition of domain-parameter policies and any trusted parameter | |
| 8.1.3 in 8.1 |
User Initialization Function | User initialization consists of an entity initializing its cryptographic application (e.g., installing and initializing software or hardware). This involves the use or installation (see Section 8.1.4 ) of the initial keying material that ma | |
| 8.1.4 in 8.1 |
Keying-Material Installation Function | The security of keying-material installation is crucial to the security of a system. For this function, keying material is installed for operational use within an entity’s software, hardware, system, application, cryptographic module, or de | |
| 8.1.5 in 8.1 |
Key Establishment Function | Key establishment involves the generation and distribution, or the agreement of keying material for communication between entities. All keys shall be generated within a FIPS 140- validated cryptographic module or obtained from another sourc | |
| 8.1.5.1 in 8.1.5 |
Generation and Distribution of Asymmetric Key Pairs | Key pairs shall be generated in accordance with the mathematical specifications of the appropriate approved FIPS or NIST Recommendation. A static key pair shall be generated by the entity that “owns” the key pair (i.e., the entity that uses | |
| 8.1.5.1.1 in 8.1.5.1 |
Distribution of Static Public Keys | Static public keys are relatively long-lived and are typically used for several executions of an algorithm. The distribution of the public key should provide assurance to the receiver of the public key that the true owner of the key is know | |
| 8.1.5.1.2 in 8.1.5.1 |
Distribution of Ephemeral Public Keys | When used, ephemeral public keys are distributed as part of a secure key-agreement protocol. The key-agreement process (i.e., the key-agreement scheme + the protocol + key confirmation + any associated negotiation + local processing) should | |
| 8.1.5.1.3 in 8.1.5.1 |
Distribution of Centrally Generated Key Pairs | When a static key pair is centrally generated, the key pair shall be generated within a FIPS 140-validated cryptographic module or obtained from another source approved by the U.S. government for protecting national security information for | |
| 8.1.5.2 in 8.1.5 |
Generation and Distribution of Symmetric Keys | The symmetric keys used for the encryption and decryption of data or other keys and for the computation of MACs (see Sections 4.2.2 and 4.2.3 ) shall be determined by an approved method and shall be provided with protection that is consiste | |
| 8.1.5.2.1 in 8.1.5.2 |
Key Generation | Symmetric keys determined by key generation methods shall be either generated by an approved method (e.g., using an approved random number generator), or derived from a master key (see Section 8.2.4 ) using an approved key-derivation functi | |
| 8.1.5.2.2 in 8.1.5.2 |
Key Distribution | Keys generated in accordance with Section 8.1.5.2.1 as key-wrapping keys (i.e., key- encrypting keys), as master keys to be used for key derivation, or for the protection of communicated information are distributed manually (manual key tran | |
| 8.1.5.2.3 in 8.1.5.2 |
Key Agreement | Key agreement is used in a communication environment to establish keying material using information contributed by all entities in the communication (most commonly, only two entities) without actually sending the keying material. Only appro | |
| 8.1.5.3 in 8.1.5 |
Generation and Distribution of Other Keying Material | Keys are often generated in conjunction with or are used with other keying material. This other keying material shall be protected in accordance with Section 6.2 . Table 6 specifies the type(s) of protection required for keying material oth | |
| 8.1.5.3.1 in 8.1.5.3 |
Domain Parameters | Domain parameters are used by some public-key algorithms to generate key pairs, to compute digital signatures, or to establish keys. Typically, domain parameters are generated infrequently and used by a community of users for a substantial | |
| 8.1.5.3.2 in 8.1.5.3 |
Initialization Vectors | Initialization vectors (IVs) are used by symmetric-key algorithms in several modes of operation for encryption and decryption, for authentication, or both. The criteria for the generation and use of IVs are provided in the [SP800-38] series | |
| 8.1.5.3.3 in 8.1.5.3 |
Shared Secrets | Shared secrets are computed during an asymmetric key-agreement scheme and are subsequently used to derive keying material. Shared secrets are generated as specified by an appropriate key-agreement scheme (see [SP800-56A] and [SP800-56B] ), | |
| 8.1.5.3.4 in 8.1.5.3 |
RBG Seeds | A Random Bit Generator (RBG) is a device or algorithm that outputs a sequence of bits that is unpredictable; RBGs are often called Random Number Generators. Approved RBGs are specified in [SP800-90] . RBGs depend on the introduction of trul | |
| 8.1.5.3.5 in 8.1.5.3 |
Other Public and Secret Information | Public and secret information may be used during the seeding of an RBG (see Section 8.1.5.3.4 ) or during the generation or establishment of keying material (see [SP800-56A] , [SP800-56B] and [SP800-108] ). Public information may be distrib | |
| 8.1.5.3.6 in 8.1.5.3 |
Intermediate Results | Intermediate results occur during computation using cryptographic algorithms. These results shall not be distributed as or with the keying material. | |
| 8.1.5.3.7 in 8.1.5.3 |
Random Bits/Numbers | Random bits (or numbers) are used for many purposes, including the generation of keys and nonces, and the issuing of challenges during communication protocols. Random bits may be distributed, but whether or not confidentiality protection is | |
| 8.1.5.3.8 in 8.1.5.3 |
Passwords | Passwords are used for identity authentication or authorization, and, in some cases, to derive keying material (see [SP800-132] ). Passwords may be distributed, but their protection during distribution shall be consistent with the protectio | |
| 8.1.6 in 8.1 |
Key Registration Function | Key registration results in the binding of keying material to information associated with a particular entity. Keys that would be registered include the public key of an asymmetric key pair and the symmetric key used to bootstrap an entity | |
| 8.2 in 8 |
Operational Phase | Keying material used during the cryptoperiod of a key is often stored for easy access as needed. During storage, the keying material shall be protected as specified in Section 6.2.2 . During normal use, the keying material is stored either | |
| 8.2.1 in 8.2 |
Normal Operational Storage Function | One objective of key management is to facilitate the operational availability of keying material for standard cryptographic purposes. Usually, a key remains operational until the end of the key’s cryptoperiod (i.e., the expiration date). Du | |
| 8.2.1.1 in 8.2.1 |
Cryptographic Module Storage | Keying material may be stored in the cryptographic module that adds, checks, or removes the cryptographic protection on information. The storage of the keying material shall be consistent with Section 6.2.2 , as well as with [FIPS140] . | |
| 8.2.1.2 in 8.2.1 |
Immediately Accessible Storage Media | Keying material may need to be stored for normal cryptographic operations on an immediately accessible storage media (e.g., a local hard drive) during the cryptoperiod of the key. The storage requirements of Section 6.2.2 shall apply to thi | |
| 8.2.2 in 8.2 |
Continuity of Operations Function | Keying material can become lost or unusable, due to hardware damage, corruption or loss of program or data files, system policy, or configuration changes. In order to maintain the continuity of operations, it is often necessary for users an | |
| 8.2.2.1 in 8.2.2 |
Backup Storage | The backup of keying material on an independent, secure storage media provides a source for key recovery (see Section 8.2.2.2 ). Backup storage is used to store copies of information that are also currently available in normal operational s | |
| 8.2.2.2 in 8.2.2 |
Key Recovery Function | Keying material that is in active memory or stored in normal operational storage may sometimes be lost or corrupted (e.g., from a system crash or power fluctuation). Some of the keying material is needed to continue operations and cannot ea | |
| 8.2.3 in 8.2 |
Key Change Function | Key change is the replacement of a key with another key that performs the same function as the original key. There are several reasons for changing a key. 1. The key may have been compromised, 2. The key’s cryptoperiod may be nearing expira | |
| 8.2.3.1 in 8.2.3 |
Re-keying | If the new key is generated in a manner that is entirely independent of the “value” of the old key, the process is known as re-keying. This replacement shall be accomplished using one of the key-establishment methods discussed in Section 8. | |
| 8.2.3.2 in 8.2.3 |
Key Update Function | If the “value” of the new key is dependent on the value of the old key, the process is known as key update (i.e., the current key is modified to create a new key). Key update is a special case of key derivation (see Section 8.2.4 ), where t | |
| 8.2.4 in 8.2 |
Key Derivation Methods | Cryptographic keys may be derived from a secret value. The secret value, together with other information, is input into a key-derivation method (e.g., a key-derivation function) that outputs the required key(s). In contrast to key change (a | |
| 8.3 in 8 |
Post-Operational Phase | During the post-operational phase, keying material is no longer in operational use, but access to the keying material may still be possible. | |
| 8.3.1 in 8.3 |
Archive Storage and Key Recovery Functions | A key archive is a repository containing keying material and other related information for recovery beyond the cryptoperiod of the keys. Not all keying material needs to be archived. An organization’s security plan should indicate the types | |
| 8.3.2 in 8.3 |
Entity De-registration Function | The entity de-registration function removes the authorizations of an entity to participate in a security domain. When an entity ceases to be a member of a security domain, the entity shall be de-registered. De-registration is intended to pr | |
| 8.3.3 in 8.3 |
Key De-registration Function | Registered keying material may be associated with the identity of a key owner, owner information (e.g., email address), role, or authorization information. When the keying material is no longer needed, or the associated information becomes | |
| 8.3.4 in 8.3 |
Key Destruction Function | When copies of cryptographic keys are made, care should be taken to provide for their eventual destruction. All copies of the private or symmetric key shall be destroyed as soon as they are no longer required (e.g., for archival or reconstr | |
| 8.3.5 in 8.3 |
Key Revocation Function | It is sometimes necessary to remove keying material from use prior to the end of its normal cryptoperiod for reasons that include key compromise, removal of an entity from an organization, etc. This process is known as key revocation and is | |
| 8.4 in 8 |
Destroyed Phase | The keying material is no longer available. All records of its existence may have been deleted, though this is not required. Some organizations may require the retention of certain key metadata elements for audit purposes. For example, if a | |
| 9 | Accountability, Audit, and Survivability | Systems that process valuable information require controls in order to protect the information from unauthorized disclosure and modification. Cryptographic systems that contain keys and other cryptographic information are especially critica |
104 of 104.