Part 1: General - Computer Security Resource Center - National ...

More documents

Recommendations

Info

March, 2007 Overview The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination becomes known to an adversary, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of mechanisms and protocols associated with keys, and the protection afforded to the keys. All keys need to be protected against modification, and secret and private keys need to be protected against unauthorized disclosure. Key management provides the foundation for the secure generation, storage, distribution, and destruction of keys. Users 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., SP 800-57) provides background information and establishes frameworks to support appropriate decisions when selecting and using cryptographic mechanisms. This recommendation does not address implementation details for cryptographic modules that may be used to achieve the security requirements identified. These details are addressed in [FIPS140-2] and the derived test requirements (available at http://csrc.nist.gov/cryptval/). This recommendation is written for several different audiences and is divided into three parts. Part 1, General, contains basic key management guidance. It is intended to advise developers and system administrators on the "best practices" associated with key management. Cryptographic module developers may benefit from this general guidance by obtaining a greater understanding of the key management features that are required to support specific intended ranges of 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 this document to determine which configuration settings are most appropriate for their information. Part 1 of the recommendation: 1. Defines the security services that may be provided and key types employed in using cryptographic mechanisms. 2. Provides background information regarding the cryptographic algorithms that use cryptographic keying material. 3. Classifies the different types of keys and other cryptographic information according to their functions, specifies the protection that each type of information requires and identifies methods for providing this protection. 4. Identifies the states in which a cryptographic key may exist during its lifetime. 5. Identifies the multitude of functions involved in key management. 6. Discusses a variety of key management issues related to the keying material. Topics discussed include key usage, cryptoperiod length, domain parameter validation, public 5
March, 2007 key validation, accountability, audit, key management system survivability, and guidance for cryptographic algorithm and key size selection. Part 2, General Organization and Management Requirements, is intended primarily to address the needs of system owners and managers. It provides a framework and general guidance to support establishing cryptographic key management within an organization and a basis for satisfying key management aspects of statutory and policy security planning requirements for Federal government organizations. Part 3, Implementation-Specific Key Management Guidance, is intended to address the key management issues associated with currently available implementations. 6
Page 1 and 2: ARCHIVED PUBLICATION The attached p
Page 3 and 4: Abstract March, 2007 This Recommend
Page 5: Authority March, 2007 This document
Page 9 and 10: March, 2007 4.2.4.1 DSA............
Page 11 and 12: March, 2007 8 KEY MANAGEMENT PHASES
Page 13 and 14: March, 2007 10.2.9 Compromise Manag
Page 15 and 16: March, 2007 Figure 3: Key states an
Page 17 and 18: March, 2007 1.2 Audience The audien
Page 19 and 20: March, 2007 1. Section 1, Introduct
Page 21 and 22: March, 2007 Backup A copy of inform
Page 23 and 24: March, 2007 Digital signature The r
Page 25 and 26: Key Management Policy Key Managemen
Page 27 and 28: Proof of possession (POP) Pseudoran
Page 29 and 30: March, 2007 Split knowledge A proce
Page 31 and 32: March, 2007 3 Security Services Cry
Page 33 and 34: March, 2007 However, it is often th
Page 35 and 36: March, 2007 4 Cryptographic Algorit
Page 37 and 38: March, 2007 operates on blocks (chu
Page 39 and 40: March, 2007 minimum key size 7 of 1
Page 41 and 42: March, 2007 2. The protocols trigge
Page 43 and 44: March, 2007 7. Symmetric key wrappi
Page 45 and 46: March, 2007 9. Random numbers: The
Page 47 and 48: March, 2007 In general, where stron
Page 49 and 50: March, 2007 a. When a symmetric key
Page 51 and 52: March, 2007 information. For less s
Page 53 and 54: 8. Symmetric and Asymmetric RNG key
Page 55 and 56: 15. Private ephemeral key agreement
Page 57 and 58:
Key Type 12. Symmetric Key Agreemen
Page 59 and 60:
March, 2007 establishment keys, see
Page 61 and 62:
March, 2007 c. Restricting plaintex
Page 63 and 64:
March, 2007 algorithms completely i
Page 65 and 66:
March, 2007 Table 3: Hash function
Page 67 and 68:
Table 4: Recommended algorithms and
Page 69 and 70:
March, 2007 size is available, the
Page 71 and 72:
Security life of data up to 4 years
Page 73 and 74:
March, 2007 6 Protection Requiremen
Page 75 and 76:
Table 5: Protection requirements fo
Page 77 and 78:
Key Type Security Service Private e
Page 79 and 80:
March, 2007 Crypto. Security Securi
Page 81 and 82:
March, 2007 may be applied only to
Page 83 and 84:
March, 2007 All cryptographic infor
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 and 136:
March, 2007 ephemeral key pairs, an
Page 137 and 138:
B.3.14.7 Key Control Information Ma
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
show all

Part 1: General - Computer Security Resource Center - National ...

Create successful ePaper yourself

Delete template?

Save as template?