NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 5
All1 The unauthorized disclosure of a key means that another entity (an unauthorized entity)2 A compromise of the integrity of a key means that the key is incorrect − either that the key3 A compromise of a key’s usage or application association means that the key could be used4 A compromise of a key’s association with the owner or other entity means that the identity5 A compromise of a key’s association with other information means that there is no6 Establishing an accountability system that keeps track of each access to secret symmetric7 Providing a cryptographic integrity check on the key (e.g., using a MAC or a digital8 Transition: A transition plan should be developed and followed so that the changeover9 Additional Considerations
| Ref | Title | Text | |
|---|---|---|---|
| 1 | The unauthorized disclosure of a key means that another entity (an unauthorized entity) | may know the key and be able to use that key to perform computations requiring the use of the key. In general, the unauthorized disclosure of a key that is used to provide confidentiality protection 65 (i.e., via encryption) means that all | changed here |
| 2 | A compromise of the integrity of a key means that the key is incorrect − either that the key | has been modified (either deliberately or accidentally) or that another key has been substituted; this includes a deletion (non-availability) of the key. The substitution or modification of a key used to provide integrity 66 calls into ques | changed here |
| 3 | A compromise of a key’s usage or application association means that the key could be used | for the wrong purpose (e.g., for key establishment instead of digital signatures) or for the wrong application and could result in the compromise of information protected by the key. | changed here |
| 4 | A compromise of a key’s association with the owner or other entity means that the identity | of the entity cannot be assured (i.e., one does not know who the entity really is). | changed here |
| 5 | A compromise of a key’s association with other information means that there is no | association at all or that the association is with the wrong information. This could cause the cryptographic services to fail, information to be lost, or the security of the information to be compromised. 5.5.2 Protective Measures Certain p | changed here |
| 6 | Establishing an accountability system that keeps track of each access to secret symmetric | and asymmetric private keys in plaintext form; | changed here |
| 7 | Providing a cryptographic integrity check on the key (e.g., using a MAC or a digital | signature); 8. Using trusted timestamps for signed data; 9. Destroying keys as soon as they are no longer needed; and 10. Creating a compromise-recovery plan, especially in the case of the compromise of a CA key. The worst form of key compr | changed here |
| 8 | Transition: A transition plan should be developed and followed so that the changeover | from the old to the new system runs as smoothly as possible. 9. Post-implementation evaluation: The system should be evaluated to verify that the implemented system meets the system’s security requirements. 5.6.5 Decrease of Security Streng | changed here |
| 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 |
Entity Registration Function | During registration into a key management system, an entity interacts with a registration authority to become an authorized member of a security domain. In this phase, an entity identifier may be established to identify the member during fu | changed here |
| 8.1.2 in 8.1 |
System Initialization Function | System initialization involves setting up or configuring a system for secure operation. For systems handling keys, this may include algorithm preferences, the identification of trusted parties, and the definition of domain-parameter policie | changed here |
| 8.1.3 in 8.1 |
Initialization Function | 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 may be | changed here |
| 8.1.4 in 8.1 |
Keying-Material Installation Function | The security of keying-material installation is crucial to the security of a system, whether the keying material is generated within the system (e.g., in the system’s cryptographic module) or generated within another system and subsequently | changed here |
| 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 source | changed here |
| 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 either: 1) the entity that owns the key pair (i.e., the entity | changed here |
| 8.1.5.1.1 in 8.1.5.1 |
Distribution of Public Keys | Static public keys are relatively long-lived and are typically used for several executions of an algorithm. Ephemeral public keys are short-lived. The distribution of the static or ephemeral public key should provide assurance to the receiv | changed here |
| 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 | changed here |
| 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 f | changed here |
| 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 | changed here |
| 8.1.5.2.1 in 8.1.5.2 |
Key Generation | Symmetric keys shall be either generated by an approved method (e.g., using an approved random number generator; see SP 800-133 ) or derived from a master key/key-derivation key (see Section 8.2.4 ) using an approved key-derivation function | changed here |
| 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/key-derivation keys to be used for key derivation, or for the protection of communicated information are distributed manually (m | changed here |
| 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 by only two entities) without actually sending the keying material. Only app | changed here |
| 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, compute digital signatures, or establish keys. Typically, domain parameters are generated infrequently and used by a community of entities for a substantial per | changed here |
| 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 SP 800-38 series | changed here |
| 8.1.5.3.3 in 8.1.5.3 |
Shared Secrets | Shared secrets are computed during the execution of 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 SP 800-56A and | changed here |
| 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 the SP 800-90 series of publications. RBGs depend on | changed here |
| 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 SP 800-56A , SP 800-56B , and SP 800-108 98 ). Public information may be distr | changed here |
| 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 the execution of communication protocols. Random bits may be distributed, but whether or not confidentiali | changed here |
| 8.1.5.3.8 in 8.1.5.3 |
Passwords | Passwords are used for identity authentication, authorization, and, in some cases, to derive keying material (see SP 800-132 ). Passwords may be distributed, but their protection during distribution shall be consistent with the protection r | changed here |
| 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 | changed here |
| 8.2 in 8 |
Operational Phase | Keying material used during the cryptoperiod of a key is often stored for access as needed. During storage, the keying material and other key information shall be protected as specified in Section 6.2.2 . During normal use, the key informat | changed here |
| 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 | changed here |
| 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 FIPS 140 . | changed here |
| 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 continuity, it is often necessary for users and/or administrators | changed here |
| 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 key information that is also currently available in normal operationa | changed here |
| 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 | changed here |
| 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. Replacement shall be accomplished using one of the key- establishment methods discussed in Section 8.1.5 | changed here |
| 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 th | changed here |
| 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). The derivation method shall | changed here |
| 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 |
Key Archive and Key Recovery Functions | A key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. An organization’s security plan should discuss key ar | changed here |
| 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 | changed here |
| 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 i | changed here |
| 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 (e.g., the identity of sharing parties could be recorded in the key’s metadata). All copies of a private or secret (symmetric) key sh | changed here |
| 8.3.5 in 8.3 |
Key Revocation Function | Key revocation is used in cases where 1) the authorized use of a key needs to be terminated prior to the end of the established cryptoperiod of that key, or 2) a key whose usage period has expired has been compromised. A key may be revoked | changed here |
| 8.4 in 8 |
Destroyed Phase | The key is no longer available. All records of its existence may have been deleted, although this is not required. Some organizations may require the retention of certain metadata elements for audit purposes. For example, if a copy of an os | changed here |
| 9 | Additional Considerations | Many aspects of key management can be handled by a key-management system that is designed to manage cryptographic keys and their metadata. An automated key management system may be used to oversee, automate, and secure the key management pr | changed here |
| 9.1 in 9 |
Access Control and Identity Authentication | An access control system is needed to ensure that every key and metadata management function can only be initiated in response to a request by an authorized entity. When key-management functions are initiated by an entity, an access control | changed here |
| 9.2 in 9 |
Inventory Management | When using cryptographic mechanisms employing keys, all long-term keys shall be inventoried. In the case of symmetric keys, this includes the keys used for the protection of information in transit and in storage. For asymmetric key pairs, t | changed here |
| 9.2.1 in 9.2 |
Key Inventories | A key inventory shall include information about each key (e.g., all or part of the metadata associated with the key); unless the inventory is also used for key backup or archiving, the inventory shall not include secret or private keys but | changed here |
| 9.2.2 in 9.2 |
Certificate Inventories | Over the years, the use of public-key certificates has grown; certificates are used by communication servers (e.g., TLS and SSH), for providing web applications and services (e.g., government services, online banking, flight operations, mis | changed here |
| 9.3 in 9 |
Accountability | Accountability has two different aspects with respect to key management: responsibility and traceability. Each human involved with key management must be clearly informed about their key- management responsibilities and held accountable for | changed here |
| 9.4 in 9 |
Audit | The auditing of activities associated with key management is required. Three types of audit should be performed on key-management systems: | changed here |
| 9.5 in 9 |
Key-Management System Survivability | A failure in a key-management system or its environment could hamper or prevent access to an organization’s stored information. Disaster recovery requires having procedures and a sufficient backup capability to recover from facility damage, | changed here |
| 9.5.1 in 9.5 |
Backed Up and Archived Key | OMB11/01 focused on the need to recover decryption keys to decrypt encrypted information (see Section 9.5.1). However, as the tables in Section 8.2.2.1 show, there are other operational keys in addition to those associated with decryption t | changed here |
| 9.5.2 in 9.5 |
Key Recovery | Key recovery is the process of retrieving or reconstructing a key from key backups or archives in order to process cryptographically protected information (e.g., to decrypt encrypted information or verify a signature on signed information). | changed here |
| 9.5.3 in 9.5 |
System Redundancy/Contingency Planning | Cryptography is a useful tool for preventing unauthorized access to data and/or resources, but when the mechanism fails, it can prevent access by valid entities to critical information and 107 If the corresponding public key has been inclu | changed here |
| 9.5.3.1 in 9.5.3 |
General Principles | Planning for recovery from system failures is an essential management function. Interruptions of critical infrastructure services should be anticipated, and planning for maintaining the continuity of operations in support of an organization | changed here |
| 9.5.3.2 in 9.5.3 |
Cryptography and Key-Management-Specific Recovery Issues | A key recovery capability generally involves some redundancy or multiple copies of key information. If one copy of critical key information is lost or corrupted, another copy usually needs to be available in order to recover data and/or res | changed here |
| 9.5.4 in 9.5 |
Compromise Recovery | When a secret or private key that is used to protect sensitive information or critical processes is disclosed to unauthorized entities, all of the information and/or processes protected by that key become immediately subject to disclosure, | changed here |
64 of 64.