BREVE COMMENTO ALLE NOTE TECNICHE

Transcription

1 a IMPLEMENTAZIONE GlobalTrust/Entrust CHIAVE Solution CRITTOGRAFICA A 256/2048 bit BREVE COMMENTO ALLE NOTE TECNICHE E nell ordine delle cose l aumento della sicurezza nel web, è importante la consapevolezza di tutti coloro che lavorano in Internet che rendere la stessa più sicura è un bene per tutti. Come per la precedente chiave crittografica a 40 bit, era già avvenuto nel lontano; la Electronic Frontier Foundation s Deep Crack formò un gruppo di lavoro con una donazione di dollari per trovare in pochi giorni il sistema per penetrare l algoritmo a 56-bit Data Encryption Standard (DES) key. Il risultato, invece, fu che lo stesso fu craccato in 4 secondi!. All epoca, gli Stati Uniti avevano addirittura proibito l esportazione della chiave di crittografia a 40-bit, comunemente usata prima del 1996, se non dietro un permesso speciale delle Autorità americane. Il risultato fu, che i browser, non c era ancora il prepararono una versione internazionale che aveva la possibilità di usare una chiave a 40 bits quando si entrava in una sessione https ( Secure Sockets Layer) al fine di proteggere l e-commerce e le transazioni bancarie, denominata SGC. Lo stesso destino, come era ovvio, è oggi per la chiave 128/1024 bit, che con l evolversi di Internet e della potenza di calcolo dei computer è divenuto un gioco da ragazzi penetrare in sistemi protetti con questi tipi di chiavi. La RSA aveva già annunciato questo fin dal 1998 dicendo che le chiavi dovevano essere adeguate nel tempo. Il NIST ha ovviamente agito di conseguenza inibendo a tutte le Certification Authority del Mondo di rilasciare certificati a meno di 256/2048 bit comunicandolo già nel 2007, la stessa cosa fatta da Microsoft nel 2009, da Mozilla Foundation e da tutti gli altri. Ovviamente non ci vanno leggeri, infatti, riportiamo una delle pragmatiche frasi in lingua originale: Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits. Abbiamo da oltre un anno iniziato ad erogare certificati a 256/2048 bit ed ora non accettiamo più CSR con chiavi inferiori a 256/2048. Chiunque abbia un certificato con chiavi da 128/1024 potrà chiedere l upgrade gratuito alla nuova chiave crittografica con una semplice al nostro supporto clienti ricordando di allegare il nuovo CSR. A scadenza del certificato lo stesso verrà da noi riemesso con la nuova chiave. In questo documento le disposizioni di Mozilla Foundation, Microsoft e NIST. In allegato la documentazione originale del NIST, Mozilla, Microsoft. GlobalTrust Phone: Fax: info@globaltrust.it -

2 CA:MD5and1024 FROM MOZZILLA FUNDATION Dates for Phasing out MD5-based signatures and 1024-bit moduli High Level Summary of Dates: June 30, 2011 Mozilla will stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After this date software published by Mozilla will return an error when a certificate with an MD5-based signature is used. o This change is being tracked in Bugzilla # December 31, 2010 All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits. Additionally, CAs with root certificates that have RSA key size smaller than 2048 bits should stop issuing intermediate and end-entity certificates from those roots. o o o DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes:Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after This means that CAs should only consider issuing a 1024-bit certificate if it is requested and justified by the subscriber for a specific reason, such as interoperability with devices that do not yet support certificates with larger key sizes. The CA must assess the risk involved in issuing such a certificate for legacy use/interoperability, and determine if they are willing to accept the risk, as well as any possible liability. The subject and relying parties also need to determine if they will accept any risks and liabilities. All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, This date could get moved up substantially if necessary to keep our users safe. We recommend all parties involved in secure transactions on the web move away from bit moduli as soon as possible. CAs who continue to issue certificates with RSA key size smaller than 2048 bits must use randomness in the serial number or in one of the fields in the DN. December 31, 2013 Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits. Caveats to proposed dates: 1. Mozilla will take these actions earlier and at its sole discretion if necessary to keep our users safe. 2. CAs may request that their legacy roots be disabled or removed from NSS earlier, according to the Root Change Process Background MD5 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for MD5-based signatures. The MD5 root certificates don t necessarily need to be removed from NSS, because the signatures of root certificates are

3 not validated (roots are self-signed). Disabling MD5 will impact intermediate and end entity certificates, where the signatures are validated. The relevant CAs have confirmed that they stopped issuing MD5 certificates. However, there are still many end entity certificates that would be impacted if support for MD5-based signatures was turned off in Therefore, we are hoping to give the affected CAs time to react, and are proposing the date of June 30, 2011 for turning off support for MD5-based signatures. The relevant CAs are aware that Mozilla will turn off MD5 support earlier if needed. The other concern that needs to be addressed is that of RSA1024 being too small a modulus to be robust against faster computers. Unlike a signature algorithm, where only intermediate and endentity certificates are impacted, fast math means we have to disable or remove all instances of 1024-bit moduli, including the root certificates. The NIST recommendation is to discontinue 1024-bit RSA certificates by December 31, Therefore, CAs have been advised that they should not sign any more certificates under their 1024-bit roots by the end of this year. The date for disabling/removing 1024-bit root certificates will be dependent on the state of the art in public key cryptography, but under no circumstances should any party expect continued support for this modulus size past December 31, As mentioned above, this date could get moved up substantially if new attacks are discovered. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible. NIST Recommendations According to NIST SP the recommended algorithms and minimum key sizes are as follows: Through 2010 (minimum of 80 bits of strength) o FFC (e.g., DSA, D-H) Minimum: L=1024; N=160 o IFC (e.g., RSA) Minimum: k=1024 o ECC (e.g. ECDSA) Minimum: f=160 Through 2030 (minimum of 112 bits of strength) o FFC (e.g., DSA, D-H) Minimum: L=2048; N=224 o IFC (e.g., RSA) Minimum: k=2048 o ECC (e.g. ECDSA) Minimum: f=224 Beyond 2030 (minimum of 128 bits of strength) o FFC (e.g., DSA, D-H) Minimum: L=3072; N=256 o IFC (e.g., RSA) Minimum: k=3072 o ECC (e.g. ECDSA) Minimum: f=256 The NIST document also has this footnote about the SHA-1 Hash Function: SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. (SHA-224, SHA-256, SHA-384 and SHA-512)

4 NIST has provided: DRAFT Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes. As of September 14, 2010, NIST representatives are addressing the comments and hope to have a final version posted in the next few weeks. The document (dated June 2010) includes the following guidance. Digital signature generation: o o o o The use of key lengths providing 80 bits of security strength is acceptable for digital signature generation through December 31, From January 1, 2011 through December 31, 2013, the use of key lengths providing 80 bits of security strength is deprecated. The user must accept risk when using these keys, particularly when approaching the December 31, 2013 upper-limit date. This is especially critical for digital signatures on data whose signature is required to be valid beyond this date. Appendix A.2 provides rationale for this modified guidance. See Section of [SP ] for further guidance. After December 31, 2013, key lengths providing less than 112 bits of security strength shall not be used to generate signatures. Key lengths providing at least 112 bits of security are acceptable. Digital signature verification: o o o Key lengths providing 80 bits of security using approved digital signature algorithms are acceptable through Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after Key lengths providing at least 112 bits of security using approved digital signature algorithms are acceptable.

5 FROM MICROSOFT ( ) What is the significance of the MD5 collision attack?(january 2009) In late December 2008, research was published at a security conference proving a successful attack against X.509 digital certificates signed using the MD5 hashing algorithm. This attack method could allow an attacker to generate additional digital certificates with different content that have the same digital signature as an original certificate. The MD5 algorithm had been shown to be vulnerable, but a practical attack had not been demonstrated. Microsoft is not aware of any active attacks using this issue and is actively working with certificate authorities to ensure they are aware of this new research, and encourages them to migrate to the newer SHA-1 and SHA-2 algorithms. For how long will you distribute legacy 1024-bit RSA root certificates?(january 2009) In most cases, we will continue to distribute legacy 1024-bit RSA root certificates until the NIST deadline of December 31, However we may also move 1024-bit RSA root certificates in the event of an algorithm attack that threatens the root certificate. We may also continue to distribute 1024-bit RSA root certificates at the CA s request past the NIST deadline, as long as there are unexpired endcertificates that rely on them and there are no attacks that threaten the root certificate. This is subject to several important conditions. Microsoft has not accepted for several years now any new 1024-bit RSA root certificate for distribution, but there remain a number of bit root certificates in distribution that are commonly used to secure websites. We stopped accepting new 1024-bit root certificates on the advice of NIST , which recommends discontinuing reliance on 1024-bit RSA keys and certificates no later than December 31, All versions of Microsoft Windows released since 1996 support 2048-bit RSA or greater. All root certificates accepted into the Program in recent years have been 2048-bit RSA or 4096-bit RSA or ECC equivalent, and are good for distribution according to current NIST guidance until at least In most cases, we will continue to distribute legacy 1024-bit root certificates past the NIST deadline as long as there are unexpired end-certificates that rely on them, subject to three important conditions: No new certificates are issued with MD2, MD4 or MD5 either by the root CA, or any subordinate CA under the root. The CA discontinues issuing 1024-bit RSA certificates from the root certificate, no later than the NIST deadline of December 31, The period before a relying end-certificate expires is not unreasonably long, given the fact that 1024-bit RSA is no longer recommended after December 31, Most importantly, there are no successful attacks against 1024-bit RSA, or against MD5, which is utilized by a subset of 1024-bit RSA root certificates. CAs may request and receive extensions of the December 31, 2010 deadline for 1024-bit root certificate removal provided they meet these conditions. Microsoft may assign a different certificate removal date that does not take into account the expiration of any or all certificates. In particular, Microsoft reserves the right to remove any root certificate if it becomes insecure, such as in the event of a successful algorithm attack. Particularly in cases where the CA has requested that they receive an extension of the period for distribution of their 1024-bit RSA root certificate, the CA must be aware that in the event of a 1024-bit compromise attack, the root certificate will be subject to automatic removal from distribution regardless of the number of relying subordinate and end-entity certificates. CAs that are members of the Program are advised to begin their transition to issuing 2048-bit endcertificates now, and to make the transition to 2048-bit RSA certificate chains complete no later than the NIST deadline, December 31, CAs should consider transitioning to 2048-bit certificates even earlier, as it would reduce the risk to their operations and their customers in the event of a successful attack on 1024-bit RSA. We will consider other dates both before and after the NIST deadline; however any request for a date after the NIST deadline must be supported with information on the type and the number of relying subordinate and end-certificates that will be time-valid and may require support. Example 1: a 1024-bit RSA root certificate expires on Jan 1, Microsoft will assign a default root certificate removal date of December 31, 2010, the NIST deadline. If notified by a CA that they have issued 2 year end-certificates right up to the end of the NIST deadline of December 31, 2010, the CA may request and we will assign a root certificate removal date of December 31, 2012, to allow end-certificates that rely on the root certificate to expire. If notified by a CA that their last time valid end-certificate expires before that date, we will assign a root certificate removal date that corresponds to that end-certificate expiration date. Example 2: a 1024-bit RSA root certificate expires on Jan 1, Microsoft will assign a default root certificate removal date of December 31, 2010, the NIST deadline. If notified by a CA that they have issued 2 year end-certificates right up to the expiration of the root certificate on Jan 1, 2009, the CA may request and we will assign a root certificate removal date of Jan 1, 2011, to allow end-certificates that rely on the root certificate to expire. If notified by a CA that their last time valid end-certificate expires before that date, we will assign a root certificate removal date that corresponds to that end-certificate expiration date.

6 NIST Special Publication March, 2007 Recommendation for Key Management Part 1: General (Revised) Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid C O M P U T E R S E C U R I T Y

7 Abstract This Recommendation provides cryptographic key management guidance. It consists of three parts. Part 1 provides general guidance and best practices for the management of cryptographic keying material. Part 2 provides guidance on policy and security planning requirements for U.S. government agencies. Finally, Part 3 provides guidance when using the cryptographic features of current systems. KEY WORDS: assurances; authentication; authorization; availability; backup; compromise; confidentiality; cryptanalysis; cryptographic key; cryptographic module; digital signature; hash function; key agreement; key management; key management policy; key recovery; key transport; originator usage period; private key; public key; recipient usage period; secret key; split knowledge; trust anchor. 2

8 Acknowledgements The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates contributions by Lydia Zieglar from the National Security Agency concerning the many security issues associated with this Recommendation. NIST also thanks the many contributions by the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication. 3

9 Authority This document has been developed by the National Institute of Standards and Technology (NIST) in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III. This guideline has been prepared for use by federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright. (Attribution would be appreciated by NIST.) Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. Conformance testing for implementations of key management as specified in this Recommendation will be conducted within the framework of the Cryptographic Module Validation Program (CMVP), a joint effort of NIST and the Communications Security Establishment of the Government of Canada. Cryptographic implementations must adhere to the requirements in this Recommendation in order to be validated under the CMVP. The requirements of this Recommendation are indicated by the word shall. 4

10 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 ) 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 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

11 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

12 Table of Contents PART 1: GENERAL INTRODUCTION Goal/Purpose Audience Scope Purpose of FIPS and NIST Recommendations Content and Organization GLOSSARY OF TERMS AND ACRONYMS Glossary Acronyms SECURITY SERVICES Confidentiality Data Integrity Authentication Authorization Non-repudiation Support Services Combining Services CRYPTOGRAPHIC ALGORITHMS Classes of Cryptographic Algorithms Cryptographic Algorithm Functionality Hash Functions Symmetric Key Algorithms used for Encryption and Decryption Advanced Encryption Standard (AES) Triple DEA (TDEA) Modes of Operation Message Authentication Codes (MACs) MACs Using Block Cipher Algorithms MACs Using Hash Functions Digital Signature Algorithms

13 DSA RSA ECDSA Key Establishment Schemes Discrete Log Key Agreement Schemes Using Finite Field Arithmetic Discrete Log Key Agreement Schemes Using Elliptic Curve Arithmetic RSA Key Transport Key Wrapping Key Confirmation Key Establishment Protocols Random Number Generation GENERAL KEY MANAGEMENT GUIDANCE Key Types and Other Information Cryptographic Keys Other Cryptographic or Related Information Key Usage Cryptoperiods Risk Factors Affecting Cryptoperiods Consequence Factors Affecting Cryptoperiods Other Factors Affecting Cryptoperiods Communications versus Storage Cost of Key Revocation and Replacement Cryptoperiods for Asymmetric Keys Symmetric Key Usage Periods and Cryptoperiods Cryptoperiod Recommendations for Specific Key Types Recommendations for Other Keying Material Assurances Assurance of Integrity (Also Integrity Protection) Assurance of Domain Parameter Validity Assurance of Public Key Validity Assurance of Private Key Possession Compromise of Keys and other Keying Material

14 5.6 Guidance for Cryptographic Algorithm and Key Size Selection Comparable Algorithm Strengths Defining Appropriate Algorithm Suites Using Algorithm Suites Transitioning to New Algorithms and Key Sizes PROTECTION REQUIREMENTS FOR CRYPTOGRAPHIC INFORMATION Protection Requirements Summary of Protection Requirements for Cryptographic Keys Summary of Protection Requirements for Other Cryptographic or Related Information Protection Mechanisms Protection Mechanisms for Cryptographic Information in Transit Availability Integrity Confidentiality Association with Usage or Application Association with Other Entities Association with Other Related Information Protection Mechanisms for Information in Storage Availability Integrity Confidentiality Association with Usage or Application Association with the Other Entities Association with Other Related Information Labeling of Cryptographic Information Labels for Keys Labels for Related Cryptographic Information KEY STATES AND TRANSITIONS Key States Key State Transitions States and Transitions for Asymmetric Keys

15 8 KEY MANAGEMENT PHASES AND FUNCTIONS Pre-operational Phase User Registration Function System Initialization Function User Initialization Function Keying Material Installation Function Key Establishment Function Generation and Distribution of Asymmetric Key Pairs Distribution of Static Public Keys Distribution of a Trust Anchor's Public Key in a PKI Submission to a Registration Authority or Certification Authority General Distribution Distribution of Ephemeral Public Keys Distribution of Centrally Generated Key Pairs Generation and Distribution of Symmetric Keys Key Generation Key Distribution Manual Key Distribution Electronic Key Distribution/Key Transport Key Agreement Generation and Distribution of Other Keying Material Domain Parameters Initialization Vectors Shared Secrets RNG Seeds Intermediate Results Key Registration Function Operational Phase Normal Operational Storage Function Device or Module Storage Immediately Accessible Storage Media Continuity of Operations Function Backup Storage Key Recovery Function Key Change Function

16 Re-keying Key Update Function Key Derivation Function Post-Operational Phase Archive Storage and Key Recovery Functions Entity De-registration Function Key De-registration Function Key Destruction Function Key Revocation Function Destroyed Phase ACCOUNTABILITY, AUDIT, AND SURVIVABILITY Accountability Audit Key Management System Survivability Back-up Keys Key Recovery System Redundancy/Contingency Planning General Principles Cryptography and Key Management-specific Recovery Issues Compromise Recovery KEY MANAGEMENT SPECIFICATIONS FOR CRYPTOGRAPHIC DEVICES OR APPLICATIONS Key Management Specification Description/Purpose Content of the Key Management Specification Cryptographic Application Communications Environment Key Management Component Requirements Key Management Component Generation Key Management Component Distribution Keying Material Storage Access Control Accounting

17 Compromise Management and Recovery Key Recovery APPENDIX A: CRYPTOGRAPHIC AND NON-CRYPTOGRAPHIC INTEGRITY AND AUTHENTICATION MECHANISMS APPENDIX B: KEY RECOVERY B.1 Recovery from Stored Keying Material B.2 Recovery by Reconstruction of Keying Material B.3 Conditions Under Which Keying Material Needs to be Recoverable B.3.1 Signature Key Pairs B Public Signature Verification Keys B Private Signature Keys B.3.2 Symmetric Authentication Keys B.3.3 Authentication Key Pairs B Public Authentication Keys B Private Authentication Keys B.3.4 Symmetric Data Encryption Keys B.3.5 Symmetric Key Wrapping Keys B.3.6 Random Number Generation Keys B.3.7 Symmetric Master Keys B.3.8 Key Transport Key Pairs B Private Key Transport Keys B Public Key Transport Keys B.3.9 Symmetric Key Agreement Keys B.3.10 Static Key Agreement Key Pairs B Private Static Key Agreement Keys B Public Static Key Agreement Keys B.3.11 Ephemeral Key Pairs B Private Ephemeral Keys B Public Ephemeral Keys B.3.12 Symmetric Authorization Keys B.3.13 Authorization Key Pairs B Private Authorization Keys

18 B Public Authorization Keys B.3.14 Other Cryptographically Related Material B Domain Parameters B Initialization Vectors (IVs) B Shared Secrets B RNG Seeds B Other Public Information B Intermediate Results B Key Control Information B Random Numbers B Passwords B Audit Information B.4 Key Recovery Systems B.5 Key Recovery Policy APPENDIX C: REFERENCES APPENDIX D: REVISIONS Tables Table 1: Recommended Cryptoperiods for key types Table 2: Comparable strengths Table 3: Hash function security strengths for cryptographic applications Table 4: Recommended algorithms and minimum key sizes Table 5: Protection requirements for cryptographic keys Table 6: Protection requirements for other cryptographic or related material Table 7: Backup of keys Table 8: Backup of other cryptographic or related information Table 9: Archive of keys Table 10: Archive of other cryptographic related information Figures Figure 1: Symmetric key cryptoperiod (Example C) Figure 2: Algorithm Originator Usage Period Example

19 Figure 3: Key states and transitions Figure 4: Key management phases Figure 5: Key management states and phases

20 RECOMMENDATION FOR KEY MANAGEMENT Part 1: General 1 INTRODUCTION Cryptographic mechanisms are one of the strongest ways to provide security services for electronic applications and protocols and for data storage. The National Institute of Standards and Technology (NIST) publishes Federal Information Processing Standards (FIPS) and NIST Recommendations (which are published as Special Publications) that specify cryptographic techniques for protecting sensitive unclassified information. Since NIST published the Data Encryption Standard (DES) in 1977, the suite of Approved standardized algorithms has been growing. New classes of algorithms have been added, such as secure hash algorithms and asymmetric key algorithms for digital signatures. The suite of algorithms now provides different levels of cryptographic strength through a variety of key sizes. The algorithms may be combined in many ways to support increasingly complex protocols and applications. This NIST Recommendation applies to U.S. government agencies using cryptography for the protection of their sensitive unclassified information. This recommendation may also be followed, on a voluntary basis, by other organizations that want to implement sound security principles in their computer systems. 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 the 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 the keys. Cryptography can be rendered ineffective by the use of weak products, inappropriate algorithm pairing, poor physical security, and the use of weak protocols. All keys need to be protected against unauthorized substitution and modification. 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. 1.1 Goal/Purpose Users and developers are presented with many new 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. Basic key management guidance is provided in [SP800-21]. This recommendation (i.e., SP ) expands on that guidance, provides background information and establishes frameworks to support appropriate decisions when selecting and using cryptographic mechanisms. 15