Part 1: General - Computer Security Resource Center - National ...
Part 1: General - Computer Security Resource Center - National ... Part 1: General - Computer Security Resource Center - National ...
March, 2007 B.3.14.1 Domain Parameters Domain parameters are used in conjunction with some public key algorithms to generate key pairs. They are also used with key pairs to create and verify digital signatures, to establish keying material, or to generate random numbers. The same set of domain parameters is often, but not always) used by a large number of entities. When an entity (entity A) generates new domain parameters, these domain parameters are used in subsequent digital signature generation or key establishment processes. The domain parameters need to be provided to other entities that need to verify the digital signatures or with whom keys will be established. If the entity (entity A) determines that its copies of the domain parameters have been lost or corrupted, and if the new domain parameters cannot be securely distributed in a timely fashion, then the domain parameters should be backed up or archived. Another entity (entity B) should backup or archive entity A's domain parameters until no longer required unless the domain parameters can be otherwise obtained (e.g., from entity A). When the same set of domain parameters are used by multiple entities, the domain parameters should be backed up or archived until no longer required unless the domain parameters can be otherwise obtained (e.g., from a trusted source). B.3.14.2 Initialization Vectors (IVs) IVs are used by several modes of operation during the encryption or authentication of information using block cipher algorithms. IVs are often stored with the data that they protect. If not, they should be backed up or archived as long as the information protected using those IVs needs to be processed (e.g., decrypted or authenticated). B.3.14.3 Shared Secrets Shared secrets are generated by each entity participating in a key agreement process. The shared secret is then used to derive the shared keying material to be used in subsequent cryptographic operations. Shared secrets may be generated during interactive communications (e.g., where both entities are online) or during non-interactive communications (e.g., in store and forward applications). A shared secret shall not be backed up or archived. B.3.14.4 RNG Seeds RNG seeds are used in the generation of deterministic random bits that need to remain secret. These seeds shall not be shared with other entities. RNG seeds shall not be backed up or archived. B.3.14.5 Other Public Information Public information is often used during key establishment. The public information may need to be available to process the cryptographically protected information (e.g., to decrypt or authenticate); therefore, the public information should be backed up or archived until no longer needed to process the protected information. B.3.14.6 Intermediate Results The intermediate results of a cryptographic operation shall not be made backed up or archived. The cryptographic operations should be re-initialized or restarted. 135
B.3.14.7 Key Control Information March, 2007 Key control information is used, for example, to determine the keys and other information to be used to process cryptographically protected information (e.g., decrypt or authenticate), to identify the purpose of a key, or the entities that share the key (see Section 6.2.3). Key control information should be backed up or archived for as long as the associated key needs to be available. B.3.14.8 Random Numbers Random numbers are generated by random number generators. The backup or archiving of a random number depends on how it is used. B.3.14.9 Passwords A password is used to acquire access to privileges by an entity. The loss of a password will deny the privileges. If the password can be replaced in a timely fashion, then the password need not be backed up. A password shall not be archived. B.3.14.10 Audit Information Audit information containing key management events shall be backed up and archived. B.4 Key Recovery Systems Key recovery is a broad term that may be applied to several different key recovery techniques. Each technique will result in the recovery of a cryptographic key and other information associated with that key (i.e., the keying material). The information required to recover that key may be different for each application or each key recovery technique. The term “Key Recovery Information” (KRI) is used to refer to the aggregate of information that is needed to recover or verify cryptographically protected information. Information that may be considered as KRI includes the keying material to be recovered or sufficient information to reconstruct the keying material, other associated cryptographic information, the time when the key was created, the identifier of the owner of the key (i.e., the individual, application or organization who created the key or who own the data protected by that key) and any conditions that must be met by a requestor to be able to recover the keying material. When an organization determines that key recovery is required for all or part of its keying material, a secure Key Recovery System (KRS) needs to be established in accordance with a well defined Key Recovery Policy (see Appendix B.5). The KRS shall support the Key Recovery Policy and consists of the techniques and facilities for saving and recovering the keying material, the procedures for administering the system, and the personnel associated with the system. When key recovery is determined to be necessary, the KRI may be stored either within an organization (in backup or archive storage) or may be stored at a remote site by a trusted entity. There are many acceptable methods for enabling key recovery. A KRS could be established using a safe for keying material storage; a KRS might use a single computer that provides the initial protection of the plaintext information, storage of the associated keying material and recovery of that keying material; a KRS may include a network of computers with a central Key Recovery Center; or a KRS could be designed using other configurations. Since a KRS provides an alternative means for recovering cryptographic keys, a risk assessment should be performed to ensure that the KRS adequately protects the organization’s information and reliably provides 136
- Page 85 and 86: March, 2007 8. Domain parameters (e
- Page 87 and 88: March, 2007 6. Destroyed Compromise
- Page 89 and 90: March, 2007 a. A private signature
- Page 91 and 92: 2 Pre-Operational Phase 3 7 1 4 Ope
- Page 93 and 94: March, 2007 8.1 Pre-operational Pha
- Page 95 and 96: 8.1.5.1.1 Distribution of Static Pu
- Page 97 and 98: March, 2007 and then provide eviden
- Page 99 and 100: March, 2007 listed in Section 8.1.5
- Page 101 and 102: March, 2007 encrypting key or publi
- Page 103 and 104: March, 2007 8.1.5.3.5 Intermediate
- Page 105 and 106: March, 2007 of keying material and
- Page 107 and 108: March, 2007 2. The application in w
- Page 109 and 110: March, 2007 and the key derivation
- Page 111 and 112: March, 2007 Type of Key Archive? Re
- Page 113 and 114: March, 2007 All records of the enti
- Page 115 and 116: March, 2007 other cryptographic inf
- Page 117 and 118: March, 2007 access to information e
- Page 119 and 120: March, 2007 1. Private key used to
- Page 121 and 122: March, 2007 10.2 Content of the Key
- Page 123 and 124: March, 2007 Management Specificatio
- Page 125 and 126: March, 2007 is the same value as th
- Page 127 and 128: March, 2007 If the decision is made
- Page 129 and 130: March, 2007 only, and then shall be
- Page 131 and 132: March, 2007 may be stored in backup
- Page 133 and 134: March, 2007 and the method of key r
- Page 135: March, 2007 ephemeral key pairs, an
- Page 139 and 140: March, 2007 to be saved. Keys for t
- Page 141 and 142: [HAC] Handbook of Applied Cryptogra
- Page 143: March, 2007 the owner by the CA tha
March, 2007<br />
B.3.14.1 Domain Parameters<br />
Domain parameters are used in conjunction with some public key algorithms to generate key<br />
pairs. They are also used with key pairs to create and verify digital signatures, to establish keying<br />
material, or to generate random numbers. The same set of domain parameters is often, but not<br />
always) used by a large number of entities.<br />
When an entity (entity A) generates new domain parameters, these domain parameters are used<br />
in subsequent digital signature generation or key establishment processes. The domain<br />
parameters need to be provided to other entities that need to verify the digital signatures or with<br />
whom keys will be established. If the entity (entity A) determines that its copies of the domain<br />
parameters have been lost or corrupted, and if the new domain parameters cannot be securely<br />
distributed in a timely fashion, then the domain parameters should be backed up or archived.<br />
Another entity (entity B) should backup or archive entity A's domain parameters until no longer<br />
required unless the domain parameters can be otherwise obtained (e.g., from entity A).<br />
When the same set of domain parameters are used by multiple entities, the domain parameters<br />
should be backed up or archived until no longer required unless the domain parameters can be<br />
otherwise obtained (e.g., from a trusted source).<br />
B.3.14.2 Initialization Vectors (IVs)<br />
IVs are used by several modes of operation during the encryption or authentication of<br />
information using block cipher algorithms. IVs are often stored with the data that they protect. If<br />
not, they should be backed up or archived as long as the information protected using those IVs<br />
needs to be processed (e.g., decrypted or authenticated).<br />
B.3.14.3 Shared Secrets<br />
Shared secrets are generated by each entity participating in a key agreement process. The shared<br />
secret is then used to derive the shared keying material to be used in subsequent cryptographic<br />
operations. Shared secrets may be generated during interactive communications (e.g., where both<br />
entities are online) or during non-interactive communications (e.g., in store and forward<br />
applications).<br />
A shared secret shall not be backed up or archived.<br />
B.3.14.4 RNG Seeds<br />
RNG seeds are used in the generation of deterministic random bits that need to remain secret.<br />
These seeds shall not be shared with other entities. RNG seeds shall not be backed up or<br />
archived.<br />
B.3.14.5 Other Public Information<br />
Public information is often used during key establishment. The public information may need to<br />
be available to process the cryptographically protected information (e.g., to decrypt or<br />
authenticate); therefore, the public information should be backed up or archived until no longer<br />
needed to process the protected information.<br />
B.3.14.6 Intermediate Results<br />
The intermediate results of a cryptographic operation shall not be made backed up or archived.<br />
The cryptographic operations should be re-initialized or restarted.<br />
135
Change language