NIST SP 800-130 日本語訳

Elaine Barker

Miles Smid

Dennis Branstad

Santosh Chokhani

http://dx.doi.org/10.6028/NIST.SP.800-130

Elaine Barker Computer Security Division Information Technology Laboratory

Miles Smid Orion Security Solutions Silver, Spring, MD

Dennis Branstad NIST Consultant Austin, TX

Santosh Chokhani Cygnacom McLean, VA

August 2013

U.S. Department of Commerce Penny Pritzker, Secretary

National Institute of Standards and Technology Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such 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 Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.

Nothing in this publication should be taken to contradict the 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. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-130 Natl. Inst. Stand. Technol. Spec. Publ. 800-130, 112 pages (August 2013) CODEN: NSPUE2 http://dx.doi.org/10.6028/NIST.SP.800-130

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by Federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: ckmsdesignframework@nist.gov

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

This Framework for Designing Cryptographic Key Management Systems (CKMS) contains topics that should be considered by a CKMS designer when developing a CKMS design specification. For each topic, there are one or more documentation requirements that need to be addressed by the design specification. Thus, any CKMS that addresses each of these requirements would have a design specification that is compliant with this Framework.

access control; confidentiality; cryptographic key management system; cryptographic keys; framework; integrity; key management policies; key metadata; source authentication.

The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates contributions by all those who participated in the creation, review, and publication of this Framework. 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. Many useful suggestions that were made during the workshops held on CKMS at NIST in 2009, 2010, and 2012 have been incorporated in this document.

This Framework for Designing Cryptographic Key Management Systems (CKMS¹) is a description of the topics to be considered and the documentation requirements (henceforth referred to as requirements) to be addressed when designing a CKMS. The CKMS designer satisfies the requirements by selecting the policies, procedures, components (hardware, software, and firmware), and devices (groups of components) to be incorporated into the CKMS, and then specifying how these items are employed to meet the requirements of this Framework.

A CKMS consists of policies, procedures, components and devices that are used to protect, manage and distribute cryptographic keys and certain specific information, called (associated) metadata herein. A CKMS includes all devices or sub-systems that can access an unencrypted key or its metadata. Encrypted keys and their cryptographically protected (bound) metadata can be handled by computers and transmitted through communications systems and stored in media that are not considered to be part of a CKMS.

This CKMS Framework provides design documentation requirements for any CKMS. In other words, it describes what needs to be documented in the CKMS design. The goal of the Framework is to guide the CKMS designer in creating a complete uniform specification of the CKMS that can be used to build, procure, and evaluate the desired CKMS.

This Framework offers the following advantages:

NIST Standards and Special Publications are referenced in this Framework as examples only. This Framework is intended to be general enough to encompass any reasonably complete and well-designed CKMS.

This Framework is not intended to be a CKMS design. That task is left to the CKMS designers. Rather, the Framework provides specification requirements using lists of options that the designers may choose to incorporate in their design.

This Framework specifies documentation requirements, not security requirements. It does not mandate particular security features. The requirements of this Framework are placed on the CKMS design documentation. The Framework aids the designer by providing the essential implementation choices that form the basis of a good CKMS design. The specific choices that ensure a secure CKMS are left to the designer or to other documents, such as security profiles that are based on this Framework.

This Framework does not mandate requirements for the protection of the information belonging to a given public or private sector (e.g., the U.S. Government, the financial industry, or health care services). It is anticipated that sectors will either develop their own profiles, or they will adopt the profiles of other sectors that fulfill their own requirements.

Requirements for conformance to this Framework are indicated by a “shall” statement. Recommendations are indicated by the use of “should”, but are not requirements for compliance with this Framework. The words “must” or “need(s) to” convey assumptions upon which this Framework is based, but do not constitute a specific requirement on the CKMS design documentation. In this Framework, “FR:i.j” indicates the jth Framework Requirement in Section i.

FR:1.1 A conformant CKMS design shall meet all “shall” requirements of the Framework.

Since the requirements in this Framework are documentation requirements, it may be adequate to address a requirement by stating that the feature specified in the requirement is not implemented in the CKMS. In many requirements, the words “if, how, where, and under what circumstances” may appear. The “if” indicates a conditional requirement. If the answer to the “if” question is “no” then the designer is expected to address the requirement by indicating why the condition does not apply. If the answer to the “if” question is “yes”, then the designer is expected to address the requirement by providing the information levied by the requirement. The “how” response should address how the requirement is met (i.e., how it will be implemented, enforced, and used). The “where” response should address where (logically in the system) the implementing mechanism is located. Finally, the “under what circumstances” response addresses the conditions that must apply before the mechanism is used.

A CKMS design that adequately addresses, specifies, and satisfies all the requirements specified herein can be considered as conforming to, and complying with, this Framework. A conformant CKMS design can be compared to another conformant CKMS design by examining the design specifications meeting each requirement.

A CKMS will be a part of a larger information system that executes information processing applications. While the CKMS supports these applications by providing cryptographic key management services, the particular applications or particular classes of applications are beyond the scope of this Framework.

Some introductory material is provided to describe the Framework topics and to justify the requirements; however, this Framework assumes that the reader has a working knowledge of the principles of key management or is able to find that information elsewhere (e.g., in [SP 800-57-part1]). Appendix A contains a list of references that are useful in understanding cryptography and cryptographic key management and their application to information security.

This Framework is primarily intended for CKMS designers. However, it may also be used by anyone interested in a Cryptographic Key Management System design and related design specifications. It is anticipated that CKMS security analysts, procurement officials, implementers, integrators, operators, and responsible managers would be interested in the CKMS design specifications and products conforming to this Framework.

CKMS designers are expected to use this Framework as a checklist for addressing all the topics covered, for considering all the aspects of a comprehensive CKMS, for selecting those policies, components, and devices to be included in a CKMS, for specifying all the decisions made in the design, and for documenting the decisions with detailed specifications and justifications. The resulting design documentation should be adequate for implementers to create the product, for integrators to incorporate the product in other products or sub-systems, and for procurement officials to understand, evaluate, and compare the product with others having similar characteristics.

Section 1 Introduction provides an introduction to the Key Management Framework and the motivation behind it.

Section 2 Framework Basics covers basic concepts of this Framework and provides an overview of the Framework.

Section 3 Goals defines the goals of a robust CKMS.

Section 4 Security Policies discusses the structure, typical contents, and need for information management, information security, CKMS security, and other related security policies.

Section 5 Roles and Responsibilities presents the roles and responsibilities that support a CKMS.

Section 6 Cryptographic Keys and Metadata covers the most critical elements of a CKMS: keys and metadata, by enumerating and defining possible key types; key metadata; and key and metadata management functions, along with access control considerations, security issues and recovery mechanisms.

Section 7 Interoperability and Transitioning considers the need for interoperability and the ability to easily make transitions in CKMS capabilities in order to accommodate future needs.

Section 8 Security Controls describes security controls applicable to a typical CKMS.

Section 9 Testing and System Assurances describes security testing and assurances.

Section 10 Disaster Recovery deals with disaster recovery in general and of a CKMS specifically.

Section 11 Security Assessment discusses the security assessment of a CKMS.

Section 12 Technology Challenges briefly discusses the technical challenges provided by new attacks on cryptographic algorithms, key establishment protocols, CKMS devices, and quantum computing.

Appendix A enumerates and describes useful references.

Appendix B consists of a glossary of terms used in this Framework.

Appendix C provides a list of acronyms used in this Framework.

This section discusses the motivation, intent, properties, and limitations of a Cryptographic Key Management Framework.

Today’s information systems and the information that they contain are considered to be critical assets that require protection. The information used by government and business is often contained in computer systems consisting of groups of interconnected computers that make use of shared networks, e.g., the Internet. Since the Internet is shared by diverse and often competing organizations and individuals, information systems should protect themselves and the information that they contain from unauthorized disclosure, modification, and use. In addition, denial of service to legitimate users could be considered a significant threat in many service and time-critical application systems and the CKMS used to protect them. Additional security requirements can be derived from the organizational goals for protecting personal privacy, including anonymity, unlinkability, and unobservability of CKMS-supported communications. The information used by these systems requires protection when it is at rest, when it is being processed within a protected facility, and also when it is transported from one location to another.

Cryptography is often used to protect information from unauthorized disclosure, to detect unauthorized modification, and to authenticate the identities of system entities (e.g., individuals, organizations, devices or processes). Cryptography is particularly useful when data transmission or entity authentication occurs over communications networks for which physical means of protection (i.e., physical security techniques) are often cost-prohibitive or even impossible to implement. Thus, cryptography is widely used when business is conducted or when sensitive information is transmitted over the Internet. Cryptography can also provide a layer of protection against insiders and hackers who may have physical or possibly logical access to stored data, but not the authorization to know or modify the data (e.g., maintenance personnel or CKMS users).

Cryptographic techniques use cryptographic keys that are managed and protected throughout their lifecycles by a CKMS. Effectively implemented cryptography can reduce the scope of the information management problem from the need to protect large amounts of information to the need to protect only keys and certain metadata (i.e., information about the key and its authorized uses, such as the algorithm with which the key is to be used, the security service to be provided using the key, etc.).

When designing a CKMS, the cryptographic techniques used to protect the keys managed by the CKMS should offer a level of protection called the security strength that is infeasible for a would-be attacker to bypass or subvert; the security strength of the technique is the base 2 logarithm of the minimum number of operations required to cryptanalyze the algorithm, and is often measured in bits of security. This design principle is comparable to a design principle used in building safes and vaults: the designer builds the vault to a standard that would discourage a rational attacker from attempting entry; the only feasible way to open the safe is to open the safe door by trying possible combinations until the correct combination is selected. Similarly, the only way to decrypt previously encrypted data (without knowledge of the correct key) is to test possible keys until, eventually, the correct key is used to decrypt the ciphertext to obtain the correct plaintext. Just as the protection provided by a safe is dependent on the number of its possible combinations, the strength of a cryptographic algorithm is dependent on the number of possible keys.

Other means of gaining access to the contents of the safe or to the information that has been encrypted may also exist. One can drill through the safe enclosure, and one can attempt to find a shortcut method to cryptanalyze the cryptographic algorithm. Also, one can attempt to steal the correct combination or key. Safe combinations and cryptographic keys both require similar protection. The CKMS should be designed to provide the necessary protection for keys and metadata.

Cryptography can be used to provide three major types of protection to data: confidentiality, integrity, and source authentication.

These protections can be provided to any data protected by the CKMS, including keys and the associated metadata (See Section 6.2.1, items s) and t)).

Cryptographic algorithms should reside within a cryptographic module (consisting of hardware, software, firmware, or a combination thereof) which physically and logically protects its contents (e.g., the algorithms, cryptographic keys, and metadata) from unauthorized modification and disclosure. A cryptographic module is part of a CKMS and can provide cryptographic protections to keys, metadata, and user data.

FR:2.1 The CKMS design shall specify all cryptographic algorithms and supported key sizes for each algorithm used by the system.

FR:2.2 The CKMS design shall specify the estimated security strength of each cryptographic technique that is employed to protect keys and their bound metadata.

A key must be associated with metadata that specifies characteristics, constraints, acceptable uses, and parameters applicable to the key. For example, a key may be associated with metadata that specifies the key type, how it was generated, when it was generated, its owner’s identifier, the algorithm for which it is intended, and its cryptoperiod. Each unit of metadata is called a metadata element. Like keys, metadata needs to be protected from unauthorized modification and may need to be protected from disclosure; the metadata also needs to have its source adequately authenticated.

A metadata element may be implicitly known and therefore may not be specifically recorded for certain keys within a CKMS. For example, if all keys within a device are AES-128 keys, then a metadata element recording key sizes may not be required. However, in many systems, there is a need to differentiate one key from another using one or more explicitly recorded metadata elements. This CKMS framework focuses on those metadata elements that are explicitly recorded and managed by the CKMS. The term “metadata” is used in this context (i.e., the term “metadata” refers to explicitly recorded and managed metadata elements).

There are many possible metadata elements for a given key. A trusted association, between a key and selected metadata elements, is often needed by the CKMS in order to perform key management functions. For example, it is desirable to have a trusted association between a static public key and the owner’s identifier. When used in conjunction with an owner registration process, the trusted association provides assurance that the owner that is specified by the identifier is, or was, in possession of the corresponding private key.

Metadata elements may be generated by the same entity that generates the key, or they may be received from a trusted entity. Whenever metadata is received from a trusted entity (whether or not the associated key is sent simultaneously) there must be a trusted association between the metadata and the associated key. The trusted association maintained during the distribution may be enforced by a cryptographic binding (binding) of the key and metadata (e.g., a digital signature computed on the combination of the key and metadata), or the association may be enforced by a trusted process (e.g., a face-to-face handover of metadata from an entity who is known and trusted). A CKMS often provides cryptographic binding and verification functions that are used in the key and metadata distribution and management processes. The receiver obtains assurance that the key and its metadata are properly associated, have come from a particular source, have not been modified, and have been protected from unauthorized disclosure during transit. Upon receipt of the metadata, the association between the key and metadata should be verified. A cryptographic binding is verified by applying the appropriate cryptographic verification function to the key and bound metadata elements. A non-cryptographic trusted association is verified by assessing the trusted process (i.e., the trust in the sending entity and the distribution process). See Figure 1 below.

Figure 1: The Trusted Association and Supporting Processes

After being received, the metadata can be combined with other locally generated metadata (if available), and a new trusted association between the key and all available metadata can then be established for the information to be stored.

Metadata stored within a system also needs a trusted association between the key and its metadata. Depending on the storage location and characteristics, the association could be maintained using physical security or cryptographic methods. Physical security methods include storage within a device that is trusted to maintain the association, i.e., the confidentiality (when required) and the integrity of a key and its metadata. As long as the integrity of the trusted association is maintained, one has assurance that the metadata elements belong to the associated key and have not been disclosed to unauthorized entities. However, such physical security methods might not be feasible. A physically secure storage site might be too costly or might not be available. In this case, a cryptographic binding could be required to provide assurance that a key and its metadata are properly associated.

A CKMS can be designed to provide services for a single individual (e.g., in a personal data storage system), an organization (e.g., in a secure VPN for intra-office communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government). A CKMS can be owned or rented.

This Framework contains a list of Framework Topics (FTs) (corresponding to the section headings) and, for each topic, a set of Framework Requirements (FRs) that need to be satisfied when designing a CKMS (see Figure 2 below). These requirements are placed on the CKMS design.

Figure 2: Framework of Topics and Requirements

This Framework does not impose any specific policies, procedures, security requirements, or system design constraints on the CKMS; it simply requires that they be documented in a structured manner so that CKMS designs can be understood and compared.

This Framework is not oriented to a particular CKMS or class of CKMS for a sector (such as the U.S. Federal Government, Aerospace, Health Care, etc.). This Framework is intended to be applicable to all CKMS.

FR:2.3 A compliant CKMS design shall describe design selections and provide documentation as required by the requirements of this Framework.

The purpose of a CKMS design is to describe how a system can be built to provide cryptographic keys to the entities that will use those keys to protect sensitive data. The high-level description of the CKMS should indicate the uses of each key type, where and how keys are generated, how they are protected in storage at each entity where they reside and during delivery, and the types of entities to whom they are delivered.

Figure 3 illustrates how a CKMS Design can be shown to be compliant with this Framework. For each Framework requirement FR:i.j, the appropriate Framework response, fr:i.j, is provided by the CKMS designer to meet the requirement. The complete set of pairs consisting of requirements and responses {FR:i.j, fr:i.j} form the CKMS Design.

Figure 3: The CKMS Design Process for Framework Conformance

FR:2.4 The CKMS design shall specify a high-level overview of the CKMS system that includes:

A CKMS Profile specifies requirements that a qualifying CKMS, its implementation, and its operation must meet for a particular sector of organizations, such as Federal Agencies. A CKMS Profile specifies how the CKMS must be designed, implemented, tested, evaluated, and operated. A sector is a group of organizations that have common requirements for a product, system, or service. A CKMS Profile is a set of requirements concerning security and interoperability that must be satisfied by a CKMS as implemented in an operational system. This Framework may be used to derive a specific CKMS Profile for a particular sector. As with the Framework, one or more Profile Requirements correspond to each Profile Topic.

Figure 4 depicts the relationship between the CKMS Framework and a derived sector Profile. When deriving a CKMS Profile from a Framework, the requirements of the Framework could be augmented and refined to meet the needs of the selected sector. For example, NIST could use this Framework to develop a Federal CKMS Profile for U.S. Federal Government agencies by selecting certain standards and protocols that comply with applicable Federal Information Processing Standards (FIPS), NIST Special Publications (SPs), and guidelines as necessary to meet the refined requirements.

Figure 4: Relationship of CKMS Framework and Sector Profile(s)

A Framework requires that specific topics be addressed in the design of a CKMS, but it is not judgmental on the design itself. Any CKMS could be designed and specified in accordance with this Framework. On the other hand, a Profile states what requirements must be met in order to have a satisfactory CKMS for the designated using sector. A CKMS Profile makes judgments (i.e., specifies what is necessary to be implemented and used to be compliant with the Profile). CKMS that comply with this Framework may not comply with a particular profile. For example, FR:2.1 in Section 2.1 requires that the CKMS design specify all cryptographic algorithms that are used by the CKMS. A U.S. Federal CKMS Profile might require that only NIST-approved cryptographic algorithms be used.

Figure 5 depicts a distributed CKMS that communicates among systems (shown in the figure as System A, System B, and System C) via the Internet. The CKMS consists of the union of all the CKMS modules (shown in the figure as CKMS Module A, CKMS Module B, and CKMS Module C). Each CKMS module is considered a logical entity within its system. Any parts of the system that perform CKMS functions are parts of the logical CKMS module at the time those functions are performed. In addition, parts of the CKMS module (e.g., an encryption algorithm) may be used by other applications (e.g., encrypting general data).

Figure 5: Example CKMS Overview

The actual communication mechanisms that interact with the other systems containing CKMS modules via the Internet are not part of the CKMS. However, the parts of protocols that perform CKMS functions (e.g., generating keys and providing key management information for insertion into the protocols) are considered part of the CKMS.

Figure 6 is an example of an email application that uses a distributed CKMS. The sender’s email application interfaces with the CKMS module, which generates the keys that will be used to apply the required cryptographic protection for the email data to be sent to the intended receiver via the Internet and, if required, to apply cryptographic protection to the keys that will be transported to the receiving entity. The email application then hands off the protected key and the protected data to the communication mechanism for transmission. Note that the communication mechanism may also interact with the CKMS module as discussed for Figure 5.

The communication mechanism in the sender’s system interacts with its CKMS module, as appropriate, prior to sending the cryptographically protected email to the email application. The email application sends the protected key to its local CKMS module to obtain the key that will subsequently be used to process the protected email data.

Figure 6: Example of a Secure Email Application

This CKMS Framework uses the term “component” to mean the hardware, software, and/or firmware required to construct the CKMS. The term “device” denotes a combination of components that serve a specific purpose. A CKMS can be as simple as a software program running on a single-user computer and supporting user applications. It can also be as complex as a variety of sub-systems, each containing many devices that provide key management services to numerous networked users and applications. A CKMS can be implemented in a single computer, or it may be widely distributed geographically and connected with a myriad of communications networks. Processors, communications media, storage units, etc. are all considered devices in this Framework.

A CKMS can be described as a set of policies, procedures, devices, and components that are designed to protect, manage, and establish cryptographic keys and metadata. The CKMS provides a set of functions that perform cryptographic key-management services on behalf of one or more organizations and their users. Collectively, these functions are presented as items for specification in a CKMS design (see Section 6.4).

FR:2.5 The CKMS design shall specify all major devices of the CKMS (e.g., the make, model, and version).

A CKMS should be designed to achieve specific goals. Some possible goals are discussed in this section.

There is an extensive use of cryptography in several security protocol standards (e.g., TLS, IKE, SSH, CMS), where both static keys (i.e., long-term keys) and ephemeral keys (i.e., keys used only for a single session or key management transaction) are used by the protocols themselves. While the focus of a CKMS is on the generation, distribution and storage of the static keys, a CKMS design must also include the generation, storage, and protection of the employed ephemeral keys as well.

The network over which the CKMS operates forms the communications backbone of the CKMS. The CKMS designer needs to understand the efficiency and reliability of the network so that the CKMS can be designed to have minimal negative impact on the network. The network size and scalability will provide some indication as to the number of users that the CKMS will need to handle both initially and in the future. Network characteristics, such as error properties, may also influence the selection of the cryptographic algorithms and cryptographic modes of operation that may extend (or worsen) the effects of communication errors after decryption is performed.

A CKMS can be built to serve a particular application (e.g., E-Mail, data storage, healthcare systems, and payment systems), or it can be designed to serve an entire enterprise, which encompasses many applications. A CKMS designed for a single application tends to be specifically designed for and closely integrated into the application, while an enterprise CKMS should be more generic so that common key-management functions may be shared as much as possible. A CKMS designer needs to have a good understanding of the application(s) that are to be supported, since they will likely affect the design choices.

The CKMS designer should also study the potential users of the system. How many users will use the CKMS and for what purposes? Are the users mobile or stationary? Do the users need to be knowledgeable about the CKMS, or will it be transparent to them? Are users operating under stressful conditions, where time is of the essence in performing their jobs? Some CKMS have failed because the designer assumed that the user understood the purpose and importance of cryptographic keys and public key certificates. If users are hampered from doing their work by a CKMS, then the CKMS will likely not be a successful security solution because it will not be used.

The goal of the CKMS designer is to specify a set of security mechanisms that function well together, provide a desired level of security that meets the needs of the application(s) and using organization(s), are affordable, and have a minimum negative impact on operations. These, as well as other CKMS goals, should be considered before a CKMS is designed, implemented, and operated.

FR: 3.1 The CKMS design shall specify its goals with respect to the communications networks on which it will function.

FR:3.2 The CKMS design shall specify the intended applications that it will support.

FR:3.3 The CKMS design shall list the intended number of users and the responsibilities that the CKMS places on those users.

Customers generally prefer Commercial Off-The-Shelf (COTS) products. Such products are often less costly to acquire, operate, and maintain than custom products designed and built for a single customer. However, COTS products designed and built to satisfy the “least common denominator” requirements of a large number of customers may not completely satisfy any of the customers. If the CKMS designer uses products that meet a range of requirements in a specific market sector, the CKMS will be more likely to be accepted in that market.

Using standard interfaces generally improves the extensibility of the product. Extensions and improvements should be allowed and supported by the COTS design of a CKMS so that the CKMS can be configured to meet varying functional and workload demands, including those based on the number of users, transactions, keys, and application data.

FR:3.4 The CKMS design shall specify the COTS products used in the CKMS.

FR:3.5 The CKMS design shall specify which security functions are performed by COTS products.

FR:3.6 The CKMS design shall specify how COTS products are configured and augmented to meet the CKMS goals.

Much can be learned about a CKMS by examining the extent to which it utilizes applicable standards. Designs that comply with standards have the benefit of the experience and wisdom of those who developed the standards. In addition, if the standards have validation programs that measure compliance, there is increased confidence that the CKMS has been correctly implemented. See Appendix A for a list of appropriate standards with a brief description of each.

Standards specify how something shall or should be done. Multiple vendors can build to the same standard and, thereby, foster interoperability and competition. In addition, the use of standards often increases confidence in the product or implementation. There is increased confidence in a standard that was developed and reviewed by multiple parties working together. Complying with standards may also reduce the time-to-production for a product or the time-to-operation for an implementation, since the essential concepts do not have to be re-invented. Conformance-testing laboratories are useful in that errors in implementations may be found and eliminated before products are available in the marketplace.

FR:3.7 The CKMS design shall specify the Federal, national, and international standards that are utilized by the CKMS.

The availability of commercial products that conform to one or more standards in a CKMS architecture can greatly reduce the time and cost of producing a CKMS. The up-front cost of a conformance-tested product is likely to be more than offset by the saved costs of not having to adapt a non-conforming product or to build a similar product from scratch.

FR:3.8 For each standard utilized by the CKMS, the CKMS design shall specify which CKMS devices implement the standard.

FR:3.9 For each standard utilized by the CKMS, the CKMS design shall specify how conformance to the standard was validated (e.g., by a third party testing program).

Possibly the most significant constraint to the use of a CKMS is the difficulty that some systems present to the untrained user. Since most users are not cryptographic security experts, and security is often a secondary goal for them, the CKMS needs to be as transparent as possible. User interfaces that adapt to the expertise of the user can guide a new and less-trained user, while permitting an expert to use efficient short cuts and to bypass step-by-step guidance.

Ease-of-use is very subjective. Something easy or obvious for one person may not be easy or obvious for another. Designers should keep in mind that users are not usually security experts, so they may not understand the purpose of the security feature that they are using. Since security is not usually the primary purpose of the product, transparent security is desirable. Negative experiences will likely affect the acceptance and use of a product. Therefore, a large segment of the potential user population needs to be satisfied that a security product is easy to use.

FR:3.10 The CKMS design shall specify all user interfaces to the system.

FR:3.11 The CKMS design shall specify the results of any user-acceptance tests that have been performed regarding the ease of using the proposed user interfaces.

While ease-of-use may be highly subjective and difficult to evaluate, several design principles for achieving this goal have been established. Ease-of-use design goals should assure that:

This approach reduces the total lifecycle cost by reducing user support costs.

FR:3.12 The CKMS design shall specify the design principles of the user interface.

FR:3.13 The CKMS design shall specify all human error-prevention or failsafe features designed into the system.

Performance improvements in computing and communications are major success stories in the computer industry. As performance improves, new applications require that even faster processing and communications be available. In the past, large key-distribution centers often serviced a maximum of several thousand security subscribers. Now, millions of people use the Internet regularly with ever-increasing demands, including new demands for security and for cryptographic keys. The need for secure processing, data storage and communications will continue to grow. This growth will require a CKMS to be scalable in order to meet the growing workload.

FR:3.14 The CKMS design shall specify the performance characteristics of the CKMS, including the average and peak workloads that can be handled for the types of functions and transactions implemented, and the response times for the types of functions and transactions under those respective workloads.

FR:3.15 The CKMS design shall specify the techniques that are supported and can be used to scale the system to increased workload demands.

FR:3.16 The CKMS design shall specify the extent to which the CKMS can be scaled to meet increased workload demands. This shall be expressed in terms of additional workload, response times for the workload, and cost.

A CKMS must be designed in a manner that supports the goals of each organization using the CKMS. Several types of policies will influence the design and use of a CKMS.

An organization may have different policies covering different applications or categories of information. For example, a military-related organization may have one set of policies covering classified information and a totally different set of policies covering personnel information.

An organization often creates and relies on layered policies, with high-level policies addressing issues at the information-management level and lower-level policies addressing specific rules for data-protection. A physical security policy may be specified in one document, and a communication security policy may be specified in another document. Computer systems are often built in accordance with their own computer security policy.

Layers of policies (e.g., information management, information security, physical security, computer security, communications security, and cryptographic key security) interrelate in many ways. Intermediate and lower layers of a policy hierarchy should provide more details on implementation and enforcement than the next higher layer. For example, an organizational Information Management Policy specifying that information must be protected against unauthorized disclosure should result in an Information Security Policy specifying the restriction of access to and use of the information only to properly identified and authorized people.

An organization may use a hierarchy of policies that will determine their requirements for a CKMS. Figure 7 provides an example of the policies that may be used and their relationships. Further discussion about these policies is provided in the following subsections.

Figure 7: Related Security Policies

An organization’s Information Management Policy specifies what information is to be collected or created, and how it is to be managed. An organization’s management establishes this policy using industry standards of good practices, legal requirements regarding the organization’s information, and organizational goals that must be achieved using the information that the organization will be collecting and creating.

An Information Management Policy typically identifies management roles and responsibilities and establishes the authorization required for people performing these information-management duties. It also specifies what information is to be considered valuable and sensitive and how it is to be protected. In particular, this highest policy layer specifies what categories of information need to be protected against unauthorized disclosure, modification or destruction. These specifications form the foundation for an Information Security Policy and dictate the levels of confidentiality, integrity, availability, and source-authentication protections that must be provided for differing categories of sensitive and valuable information.

An organization’s Information Security Policy is created to support and enforce portions of the organization’s Information Management Policy by specifying in more detail what information is to be protected from anticipated threats and how that protection is to be attained. The rules for collecting, protecting, and distributing valuable and sensitive information in both paper and electronic form are specified in this layer of policy. The inputs to the Information Security Policy include, but are not limited to, the Information Management Policy specifications, the potential threats to the security of the organization’s information, and the risks involved with the unauthorized disclosure, modification, and destruction or loss of the information.

The outputs of the Information Security Policy layer include information sensitivity levels (e.g., low, medium, and high) assigned to various categories of information and high-level rules for protecting the information. The Information Security Policy may also be used to create a CKMS Security Policy that specifies the use and protection of cryptographic keys, algorithms, and mechanisms that provide confidentiality and integrity protection of the keys and their metadata for the organization.

The CKMS Security Policy specifies rules for the protection of keys and metadata that the CKMS must support. A CKMS Security Policy needs to establish and specify rules for protecting the confidentiality, integrity, availability, and source authentication of all cryptographic keys and metadata used by the CKMS. These rules cover the entire key lifecycle, including when they are operational, stored, and transported. The CKMS Security Policy may include the selection of all cryptographic mechanisms and cryptographic protocols that can be used by the CKMS. The CKMS Security Policy needs to be consistent with the higher-level policies of the organization. For example, if the Information Security Policy states that the confidentiality of electronically transmitted information is to be protected for up to 30 years, then the CKMS Security Policy and the CKMS design must be capable of supporting that policy.

The designer of a CKMS might not be a member of the organization that will be using the CKMS, and might not have access to the organization’s policies, e.g., the organization may purchase a CKMS or the services of a CKMS that was developed external to the organization. The designer of the CKMS should create a set of security capabilities or features in the design that support the market for which the designer is creating the CKMS. These capabilities or features should be documented by the designer and can be considered to form the designer’s initial CKMS Security Policy. The design documentation should state how and when the features are used to support the CKMS Security Policy. The organization may work with the designer or the CKMS service provider to develop a modified CKMS Security Policy, based on the initial CKMS Security Policy developed by the designer. Ultimately, it is the responsibility of the organizations that use the CKMS to assure that the CKMS design adequately supports, or can be configured to support, the (possibly modified) CKMS Security Policy.

The specific protections applied to each key type and its metadata (see Section 6) may be considered as supporting the Key Security Policy, which would be a part of the CKMS Security Policy. A Key Security Policy would state the policy for confidentiality, integrity and source authentication for the key and its metadata over the entire key lifecycle. These policies would then be supported by the CKMS.

A Key and Metadata Retention Policy specifying the length of time that keys and metadata are to be retained should also be part of the CKMS Security Policy. The Key and Metadata Retention Policy should be based on the sensitivity of the information that the keys and metadata protect. The CKMS should enforce the Key and Metadata Retention Policy. For example, the CKMS should protect keys and metadata throughout their security lifetimes, and then the CKMS should destroy the keys and metadata when they are no longer desired.

A CKMS Security Policy should be written so that the people responsible for maintaining the policy can easily understand the policy and correctly perform their roles and responsibilities. Note that security policies could be specified in a form (e.g., tables, formal specification languages, flow charts) that could be stored electronically and processed automatically within a CKMS. Policies specified in a formal language could be automatically enforced by a CKMS designed to do so. Such systems may be able to check themselves for proper functioning, diagnose current or potential problems, report the problem to the responsible organizational entity, and perhaps even automatically correct the problem.

FR:4.1 The CKMS design shall specify the CKMS Security Policy, including the configurable options and sub-policies that it is designed to enforce.

FR:4.2 The CKMS design shall specify how the CKMS Security Policy is to be enforced by the CKMS (e.g., the mechanisms used to provide the protection required by the policy).

FR:4.3 The CKMS design shall specify how any automated portions of the CKMS Security Policy are expressed in an unambiguous tabular form or a formal language (e.g., XML or ASN.1), such that an automated security system (e.g., table driven or syntax-directed software mechanisms) in the CKMS can enforce them.

A CKMS Security Policy may include or rely on other security policies. A CKMS design should state what other policies are required to be enforced for proper and secure operation of the CKMS. For example, a CKMS could be designed and implemented to provide all the physical protection and access control required to assure protection of the CKMS itself. It could also be designed assuming (and requiring) that external physical security and access control is provided by the facility in which the CKMS is installed and operated. Computer systems are often built to their own Computer Security Policy. An organization should create these policies in a logical structure that assigns roles for managing and enforcing the policies to appropriate parts of the organization.

FR:4.4 The CKMS design shall specify other related security policies that support the CKMS Security Policy.

A CKMS designer should be aware of the various policies of organizations that may procure and use CKMS products or services. The designer could design a simple CKMS that enforces a simple key-management policy for a single organization or a complex CKMS product that can support a variety of security policies.

FR:4.5 The CKMS design shall specify the policies that are supported by the CKMS design and a summary of how they are supported by the design.

A policy of personal accountability requires that every person who accesses sensitive information be held accountable for his or her actions. Personal accountability may be a requirement in an Information Management Policy that results in specific features in the CKMS. A CKMS designer should determine if the CKMS is intended to support personal accountability. If it is, then mechanisms should be provided within the CKMS to support accountability for the management of keys and metadata.

FR:4.6 The CKMS design shall specify if and how personal accountability is supported by the CKMS.

An Information Management Policy may state that users of the secure information-processing system can be assured of anonymity, unlinkability, and unobservability. Anonymity assures that public data cannot be related to the owner. Unlinkability assures that two or more related events in an information-processing system cannot be related to each other. Finally, unobservability assures that an observer is unable to identify or infer the identities of the parties involved in a transaction.

FR:4.7 The CKMS design shall specify the anonymity, unlinkability, and unobservability policies that can be supported by the CKMS.

In order to provide privacy to entities, to adhere to applicable privacy laws, or to enhance security, a CKMS may require anonymity of CKMS transactions in terms of the entities that participate in the transaction. For privacy reasons, a CKMS may also require anonymity when associating keys and/or metadata with entities.

FR:4.8 The CKMS design shall specify which CKMS transactions have or can be provided with anonymity protection.

FR: 4.9 The CKMS design shall specify how CKMS transaction anonymity is achieved when anonymity assurance is provided.

In order to provide privacy to entities, to adhere to applicable privacy laws, or to enhance security (by protecting against inferring who is associated with a given transaction), a CKMS may provide unlinkability protection for CKMS transactions in terms of the entities that participate in the transaction.

FR:4.10 The CKMS design shall specify which CKMS transactions have or can be provided with unlinkability protection.

FR:4.11 The CKMS design shall specify how CKMS transaction unlinkability is achieved.

In order to provide privacy to entities, to adhere to applicable privacy laws, or to enhance security (by protecting against inferring any information whose disclosure might not be desired), a CKMS may provide unobservability of CKMS transactions in terms of the entities that initiate or participate in the transaction.

FR:4.12 The CKMS design shall specify which CKMS transactions have or can be provided with unobservability protection.

FR:4.13 The CKMS design shall specify how CKMS transaction unobservability is achieved.

The security policies of an organization should conform to the laws, rules, and regulations of the locality, state, and nation(s) in which the CKMS will be used. If a CKMS is designed for international use, then it should be flexible enough to conform to national restrictions.

FR:4.14 The CKMS design shall specify the countries and/or regions of countries where it is intended for use and any legal restrictions that the CKMS is intended to enforce.

A security domain is a collection of entities, including their CKMS, in which each CKMS operates under the same security policy − known as the Domain Security Policy. When two mutually trusting entities are in the same security domain, the entities can exchange keys and metadata while providing the protections that are required by the Domain Security Policy.

When two entities are in different security domains, they may not be able to provide equivalent protection to the exchanged keys and metadata because they operate under different domain security policies. However, there are circumstances in which an entity in one domain can send keys and metadata to another entity in a different domain, even though the domain security policies are not completely identical.

An example of a security domain is a Public Key Infrastructure (PKI) that issues public key certificates (see [X.509]). The PKI operates under one or more documented certificate policies, and each public key certificate contains the certificate policies for which the certificate is valid. The relying entity (the certificate user) can examine the certificate and determine if the certificate provides acceptable security. However, when entities from different PKI domains wish to communicate, and hence use each other’s certificates, the certificate policies of the two PKI domains should be examined and verified as offering equivalent security before the certificate should be used.

When an entity wishes to securely send a key and/or metadata to another entity, certain conditions must be satisfied:

If the entities belong to the same security domain, there is a high likelihood that each of these conditions can be met. But, if the entities do not belong to the same security domain, then these conditions are less likely to be satisfied. In the remainder of this section, assume that conditions a), b), and d) are met; the discussion will focus on condition c).

FR:4.15 The CKMS design shall specify design features that allow for the exchange of keys and metadata with entities in other security domains that are considered to offer equivalent but different security protections.

Protection assurances include protecting a key and/or metadata from unauthorized disclosure, protecting the key and/or metadata from unauthorized modification, and knowing the source and destination of a key and/or metadata as required by the application. Suppose that entity A in security domain A wishes to send a cryptographic key and/or metadata to entity B in security domain B, and that conditions a), b), and d) above are satisfied. Suppose also that entity B wishes to receive the key and/or metadata and treat the received key and/or metadata exactly as it treats its own keys and/or metadata. That is to say, entity B in no way distinguishes the protections provided to the received key and/or metadata from those provided to its own keys and/or metadata. Before entity A sends the key and/or metadata, it must have assurance that the protection requirements in domain B’s security policy are at least as good as those in domain A’s security policy. Also, entity B would desire assurance that the protection requirements in domain A’s security policy are at least as good as those in domain B’s security policy. In essence, the two domains must have equivalent domain security policies

The protection assurances required for data sent from entity A to entity B are shown in Figure 8.

Figure 8: Protection Assurances between Security Domains

FR:4.16 The CKMS design shall specify the source and destination authentication policies that it enforces when sharing a key and/or metadata with entities in differing security domains.

FR:4.17 The CKMS design shall specify the confidentiality and integrity policies that it enforces when sharing a key and/or metadata with entities in differing security domains.

FR:4.18 The CKMS design shall specify what assurances it requires when communicating with entities from other security domains.

Two security domains have equivalent security policies if the authority responsible for each security domain agrees to accept the other domain’s policy as being equivalent to its own policy in terms of the security protections provided. The domain security policies have to be carefully examined before acceptance by the authorities responsible for each domain³. This process may be impossible if the authorities are not able to agree on the equivalence of protections. The authorities responsible for a security domain may restrict the security level of key and/or metadata, and therefore data, that they are willing to share with other domains in order to mitigate the consequences of any potential compromises. If entity A and entity B attempt to share a key and/or metadata, and security domain B has weaker policies than security domain A, then a sophisticated CKMS should, at a minimum, inform entity A of the possible security consequences.

If it is determined that the policies of the two domains are equivalent, an entity in one domain may share data with any entity in another equivalent domain, when appropriate.

FR:4.19 The CKMS design shall specify if and how it supports the review and verification of another domain’s security before intra-domain communications are permitted.

FR: 4.20 The CKMS design shall specify how it detects, prevents or warns an entity of the possible security consequences of communicating with an entity in a security domain with weaker policies.

Suppose that entity A in security domain A and entity B in security domain B have equivalent domain security policies. In that case, it would be reasonable for entity A and entity B to share keys and/or metadata with any of the other members in either domain A or domain B, because each security domain has accepted the other domain’s security policy. However, suppose that entity B also shares keys and metadata with a third entity, entity C in domain C. In this case, entity A and entity B have assurance that their respective domain security policies are equivalent and entity B and entity C have assurance that their respective domain security policies are equivalent. If entity B treats keys and/or metadata received from entity A in the same manner as its own keys and/or metadata, then entity A should expect that keys and/or metadata shared with entity B may also be shared with other equivalent security domains. When two entities examine each other’s domain security policies for equivalence, they should pay close attention to each other’s policies for sharing keys, metadata and other information with entities in other security domains.

A security domain could contain entities, each of which supports the same multi-level Domain Security Policy. For example, the Domain Security Policy could provide either a high level or a low level of protection to the keys and/or metadata that it processes. In this case, the security domain acts much like two separate security domains because it must distinguish between the two levels of protection. Each entity must ensure that keys and/or metadata protected by the higher-level policy are always provided the higher level of protection, that keys and/or metadata protected by the lower-level policy cannot be confused with the higher-level keys and/or metadata, and that higher-level keys and/or metadata do not get confused with lower-level keys and/or metadata. This typically involves a multi-level operating system. See Figure 9. Physical entity B is divided into two logical entities: entity \(B_{HL}\) for high-level protection, and entity \(B_{LL}\) for low-level protection. The separation of the \(B_{HL}\) keys from the \(B_{LL}\) keys is maintained logically (as indicated by the dashed line in the figure) by the operating system. The advantage of a multi-level security domain is that it can process keys and/or metadata from entities operating at different security levels.

Figure 9: Multi-level Security Domain

FR: 4.21 The CKMS design shall specify whether or not it supports multilevel security domains.

FR:4.22 The CKMS design shall specify each level of security domain that it supports.

FR:4.23 If multilevel security domains are supported, the CKMS design shall specify how it maintains the separation of the keys and metadata belonging to each security level.

Under certain conditions, a domain authority may decide that a key and/or metadata from an entity in a lower-level security domain (a domain providing less protection) can be accepted and subsequently protected at the higher level required by its own Domain Security Policy. This process is called upgrading. Upgrading is not without risk and should only be done if the authority responsible for the higher-level domain has trust and confidence in the source and authenticity of the key and/or metadata from the lower level. A mistake in judgment by the domain authority could result in security compromises to the domain entities. Likewise, under certain conditions, the domain authority for a higher-level security domain may wish to pass a key and/or metadata down, or downgrade, to a lower-level domain entity. In this case, the domain authority for the higher-level domain should have confidence that the key and/or metadata being passed down only require the lower level of security provided by the receiver.

FR:4.24 The CKMS design shall specify if and how it supports the upgrading or downgrading of keys and metadata.

FR:4.25 The CKMS design shall specify how upgrading or downgrading capabilities are restricted to the domain authority.

From time to time, it may be desirable to modify or update a Domain Security Policy. The update may be the result of a management decision to upgrade the protections provided to the keys and metadata elements, it may be the result of a desire to be equivalent with another security domain, or it may be to support a new application.

Some CKMS may be designed so that their domain security policies may be configured to permit communications with entities in different domains. For example, a security domain may allow certain management officials to select the key and/or metadata management functions that are used to support various applications. These domains are said to be configurable. Even if a specific Domain Security Policy change is within the capability of a configurable system, the domain management personnel should still approve any policy change before the change is made.

FR:4.26 The CKMS design shall specify if and how its key and/or metadata management functions may be configured to support differing domain security policies and differing applications.

FR:4.27 The CKMS design shall specify if and how it can support changes in its Domain Security Policy by being reconfigured to accommodate communications with entities in different security domains.

A CKMS may need to interface with humans that are performing specific management, user, and/or operational roles. Each role should have specific authorizations defined for it, and the persons performing that role should be provided access to a set of key and metadata management functions that are necessary for carrying out the responsibilities of the role. Examples of possible CKMS roles include, but are not limited to, the following:

Multiple individuals may be assigned to each role, and a single person may have multiple roles. However, certain roles should be separated so that no individual is assigned to both roles at the same time. For example, audit logs should be managed by someone other than a system administrator in order to detect administrative misuse or abuse. In addition, it is wise to rotate individuals from roles so as to minimize the likelihood of long-term abuses.

FR:5.1 The CKMS design shall specify each role employed by the CKMS, the responsibilities of each role, and how entities are assigned to each role.

FR:5.2 The CKMS design shall specify the key and metadata management functions (see Section 6.4) that can be used by entities fulfilling each role employed by the CKMS.

FR:5.3 The CKMS design shall specify which roles require role separation.

FR:5.4 The CKMS design shall specify how the role separation is maintained for the roles that require role separation.

FR:5.5 The CKMS design shall specify all automated provisions for identifying security violations, whether by individuals performing authorized roles (insiders) or by those with no authorized role (outsiders).

In general, cryptographic keys are categorized according to their properties and uses. Key properties may be public, private, or symmetric⁴. Keys may also have static (i.e., long term) or ephemeral (used only for a single session or key management transaction) properties. Key uses include signature, authentication, encryption/decryption, key wrapping, RNG (Random Number Generation), master key, key transport, key agreement, and authorization. [SP 800-57-part1] describes twenty different key types. Twenty-one key types are shown in Table 1 below (one compound key type in SP 800-57-part1 is divided into two simple key types in the table). Note that the italicized items in this paragraph are the actual terms that compose the key type names in the table. A CKMS may use these or other key types in its design.

Table 1: Key Types

FR: 6.1 The CKMS design shall specify and define each key type used.

This section lists and describes the metadata that may be associated with keys. Key metadata is defined as information associated with a particular key that is explicitly recorded and managed by the CKMS. In this Framework, the key associated with a particular set of metadata elements is referred to as “the key”.

The metadata that may be appropriate for a trusted association with a key should be selected by the CKMS designer, based upon a number of factors, including the key type, the key lifecycle state, and the CKMS Security Policy. A CKMS need not associate all applicable metadata with a given key, and a CKMS may not associate any metadata with some or all of the keys. See item u) in Section 6.2.1.

The following are typical metadata elements and their descriptions:

n) Key Security Policy Identifier: This element identifies the security policy applicable to the key or key type. A Key Security Policy is a set of security controls that are used to protect the key or key type during the lifecycle of the key from generation to destruction (see Section 6.7 and [RFC 3647]). A Key Security Policy is typically represented by an object identifier registered by the CKMS organization. The Key Security Policy for individual keys or key types is part of, and should be consistent with, the CKMS Security Policy.

This element may have two sub-elements:

This element may have several sub-elements:

This element may have several sub-elements:

The dates and times used in the above listed metadata elements, as well as various CKMS transaction dates and times, may be required to be both accurate and from an authoritative source, such as a Network Time Protocol (NTP) server. In addition, some of the transactions may require time stamps from a trusted third-party. Trusted third-party time stamping is described in [RFC 3161] and [SP 800-102].

FR:6.2 For each key type used in the system, the CKMS design shall specify all metadata elements selected for a trusted association, the circumstances under which the metadata elements are created and associated with the key, and the method of association (i.e., cryptographic mechanism or trusted process).

FR: 6.3 For each cryptographic mechanism used in the Key Protections metadata element (item s above), the CKMS design shall specify the following:

FR:6.4 For each non-cryptographic trusted process used in the Key Protections metadata element (item s above), the CKMS design shall specify the following:

FR:6.5 For each cryptographic mechanism used in the Metadata Protections metadata element (item t above), the CKMS design shall specify the following:

Generally, the same mechanism will be used for the key and bound metadata, especially if the key and metadata are bundled together.

FR:6.6 For each non-cryptographic trusted process used in the Metadata Protections metadata element (item t above), the CKMS design shall specify the following:

FR:6.7 For each cryptographic mechanism used in the Trusted Association Protections metadata element (item u above), the CKMS design shall specify the following:

FR:6.8 For each non-cryptographic trusted process used in the Trusted Association Protections metadata element (item u above), the CKMS design shall specify the following:

FR:6.9 The CKMS design shall specify the accuracy and precision required for dates and times used by the system.

FR:6.10 The CKMS design shall specify what authoritative time sources are used to achieve the required accuracy.

FR:6.11 The CKMS design shall specify how authoritative time sources are used to achieve the required accuracy⁸.

FR:6.12 The CKMS design shall specify which dates, times, and functions require a trusted third-party time stamp.

A CKMS design needs to make certain information clear regarding how keys and metadata are managed.

FR:6.13 For each key type, the CKMS design shall specify the following information regarding keys and metadata elements:

FR:6.14 The CKMS design shall specify all syntax, semantics, and formats of all key types and their metadata that will be created, stored, transmitted, processed, and otherwise managed by the CKMS.

A key may pass through several states between its generation and its destruction. This section is based on Section 7, Key States and Transitions, from [SP 800-57-part1]. Possible states of a key include: Pre-Activation, Active, Deactivated, Compromised, Destroyed, Destroyed Compromised, and Revoked. Note that the CKMS designer selects and defines the key states and transitions that are appropriate for the CKMS and its likely applications.

FR:6.15 The CKMS design shall specify all the states that the CKMS keys can attain.

FR:6.16 The CKMS design shall specify all transitions between the CKMS key states and the data (inputs and outputs) involved in making the transitions.

The key and metadata management functions described in this section are performed by the CKMS on keys or metadata for management purposes. The authentication and authorization of the calling entities is performed by an Access Control System (ACS), as described in Section 6.7.

A CKMS should provide for the creation, modification, replacement, and destruction of keys and their metadata. Depending on the function, the input and/or output may have integrity, source authentication, and/or confidentiality services applied to them.

In the case of an input to a function, the function may need to process protections placed on the input by another entity. For example, for the key-entry function, the entity providing the key (i.e., the key source⁹) may have digitally signed the plaintext key and then encrypted the signed result. Therefore, for this example, the key-entry function will need to decrypt the input and perform digital signature verification to authenticate the key source and verify the integrity of the key.

In the case of an output from a function, the function may need to apply security services. For example, for the key-output function, the invoker of the function may desire to output a key that is encrypted and then digitally signed. The key-output function would then apply encryption and digital signature generation to the key as appropriate for the intended recipient.

FR:6.17 The CKMS design shall specify the key and metadata management functions to be implemented and supported.

FR:6.18 The CKMS design shall identify the integrity, confidentiality, and source-authentication services that are applied to each key and metadata management function parameter implemented in the CKMS.

When a user requires a key, the user should request that the key be generated by the CKMS. The user may need to specify the type of key and other necessary parameters (e.g., the name of the key-generation technique), including some metadata that needs to be associated with the key when requesting this function. The function may return a key identifier that is a pointer to the key and perhaps its metadata. If the user wishes to actually know the key value, then the key-output function (see Section 6.4.20) could be used in some circumstances.

Key-generation techniques typically depend on the specifications of the cryptographic algorithm paired with the key (see [FIPS 186]). Different algorithms make use of keys conforming to differing specifications (e.g., lengths and formats). Key generation for asymmetric algorithms involves the generation of a key pair. The generation of keys requires the use of a random number generator that is designed for cryptographic purposes. For example, NIST has published several approved random number generators (see [SP 800-90A]) and instructions on key generation (see [FIPS 186]).

The key-generation function may also provide for the selection or input of metadata that is associated with the generated key.

FR:6.19 The CKMS design shall specify the key-generation methods to be used in the CKMS for each type of key.

FR:6.20 The CKMS design shall specify the underlying random number generators that are used to generate symmetric and private keys.

The initial registration of a security entity (i.e., individual (person), organization, device or process) and a cryptographic key with metadata is a fundamental requirement of every CKMS. This requirement is difficult to fully automate while preserving security (i.e., protecting from an impersonation threat) and thus, it usually requires human interactions. There typically exists a registration process in a CKMS that binds each entity’s initial set of secret, public, or private keys with the entity’s identifier and perhaps other metadata. The process of binding an owner’s identifiers and keys involves either an initial identity proofing of the owners or relying on the pre-existing identity of the owner in the CKMS.

FR:6.21 The CKMS design shall specify all the processes involved in owner registration, including the process for binding keys with the owner’s identifier.

The activation function provides for the transition of a cryptographic key from the pre-activation state to the active state. This function may automatically activate the key immediately after generation. Alternatively, this function may generate a date-time metadata value that indicates when the key becomes active and can be used. A deactivation date-time may also be established using this function.

FR:6.22 The CKMS design shall specify how each key type is activated and the circumstances for activating the key.

FR:6.23 For each key type, the CKMS design shall specify requirements for the notification of key activation, including which parties are notified, how they are notified, what security services are applied to the notification, and the time-frames for notification(s)¹⁰.

This function transitions a key into the deactivated state. A cryptographic key is generally given a deactivation date and time when it is created and distributed. In some instances, deactivation may also be based on the number of uses or the amount of data protected. This deactivation information may be associated with the key as metadata. The period of time between activation and deactivation is generally considered the cryptoperiod of a key. This time usually has a maximum value based, in part, on the sensitivity levels of the data it is protecting and the threats that could be brought against the CKMS (see [SP 800-57-part1] for further discussion). The cryptoperiod can be shortened, based on the concerns of the cryptographic officer in charge of the key and data. The CKMS Security Policy should state the maximum allowable cryptoperiod of any key type used to protect the data covered by the policy.

FR: 6.24 The CKMS design shall specify for each key type how deactivation of the key is determined (e.g., by cryptoperiod, by number of uses, or by amount of data).

FR: 6.25 The CKMS design shall specify how each key type is deactivated (e.g., manually or automatically, based on the deactivation date-time, the number of usages, or the amount of protected data).

FR: 6.26 The CKMS design shall specify how the deactivation date-time for each key type can be changed¹¹.

FR:6.27 For each key type, the CKMS design shall specify requirements for advance notification of the deactivation of the key type, including which CKMS supported roles are notified, how they are notified, what security services are applied to the notification, and the time-frames for notification(s).

Key revocation is used in cases where the authorized use of a key needs to be terminated prior to the established cryptoperiod of that key. A cryptographic key should be revoked as soon as feasible after it is no longer authorized for use (e.g., the key has been compromised). Revoking a key includes marking the key as no longer authorized for use to apply cryptographic protection or to process already protected information. Security entities that have been, that are, or that will be using the key (i.e., relying parties) need to be notified that the key has been revoked. This may involve the publication of a revocation list identifying keys that have been revoked. Other forms of revocation notification may be supported in key-management systems.

FR:6.28 The CKMS design shall specify when, how, and under what circumstances revocation is performed and revocation information is made available to the relying parties.

A key may be temporarily suspended and later re-activated¹². Examples of situations that may warrant suspension, as opposed to irreversible revocation, include: the owner is not available for an extended period of time, the key has been misused, a possible compromise is under investigation, or a token containing a key has been misplaced. In addition to a security-issue-related revocation (since suspension is nothing but revocation, albeit reversible), the security of re-activating a suspended key is also critical.

If a suspension is to apply to remote entities holding the key, as well as the local calling entity, then provisions must be made for notifying the other entities of the suspension and also the re-activation.

FR:6.29 The CKMS design shall specify how, and under what circumstances, a key is suspended.

FR:6.30 The CKMS design shall specify how suspension information is made available to the relying or communicating parties.

FR:6.31 The CKMS design shall specify how, and under what circumstances, a suspended key is re-activated.

FR:6.32 The CKMS design shall specify how the suspended key is prevented from performing security services.

FR:6.33 The CKMS design shall specify how re-activation information is made available to the relying or communicating parties.

Public key certificates contain a public key of an asymmetric key pair (i.e., the subject key) and a validity period for that certificate. It may be desirable to have a public key validity period that is shorter than the subject key’s cryptoperiod. This reduces the size of revocation lists and revocation information, but requires certificates to be issued more frequently. Renewal establishes a new validity period for an existing subject public key beyond its previous validity period by issuing a new certificate containing the same public key with a new validity period. The sum of the renewal periods for a given public key must not exceed the cryptoperiod of the key.

Advance notification is useful for continuity of operations and mission so that the appropriate set of new keys and associated metadata can be issued to appropriate parties. For example, upon the expiration of an entity’s current public key certificate, the entity may need to request either the renewal of the existing public key or the establishment of a new public key.

FR:6.34 The CKMS design shall specify how and the conditions under which a public key can be renewed.

FR:6.35 For each key type, the CKMS design shall specify requirements for advance notification of the renewal of the key type, including which parties are notified, how they are notified, what security services are applied to the notification, and the time-frames for notification(s).

When a key is derived from other information, some of which is secret, in a non-reversible manner, the process is called key derivation. Key derivation is often used in key establishment protocols to derive a shared key from a common shared secret (see [SP 800-56A], [SP 800-56B], [SP 800-56C], and [SP 800-135]).

Key derivation may also be used to derive a key from another key (see [SP 800-108]) or from a password (see [SP 800-132]). In the case where a key (e.g., K₁) is used to derive another key (K₂), and the derived key (K₂) is used to replace the original key (i.e., K₁), then the process is called key update. In the past, keys were merely updated in order to avoid having to use a key establishment protocol to establish a new key; all entities sharing the key merely updated the key to form a new key without using any other secret data. This process of key updating has the possible security exposure that an adversary who obtains a key (by compromise or cryptanalysis) and knows the update transformation can update the known key to any of its future updates.

FR:6.36 The CKMS design shall specify all processes used to derive or update keys and the circumstances under which the keys are derived or updated.

FR:6.37 For each key type, the CKMS design shall specify requirements for advance notification of the derivation or update of the keys, including which parties are notified, how they are notified, what security services are applied to the notification, and the time-frames for notification(s).

Keys and some portion of their metadata should be destroyed beyond recovery when they are no longer to be used. Destroying a key in a high-security application can be a complex process, depending on the storage media for the key and the extent of distribution of key copies. Historically, the secure burning of paper keying material (paper tape, punched cards, or printed key lists) in a prescribed manner was used. Keys in electronic storage media may be overwritten with random patterns of zeros and ones. Magnetic media that has a propensity for retaining low levels of magnetism may be physically destroyed, degaussed, or over-written with various bit patterns numerous times. Designers should include provisions for destroying a key in backup storage media if such media are utilized.

FR:6.38 The CKMS design shall specify how and the circumstances under which keys are intentionally destroyed and whether the destruction is local to a component or universal throughout the CKMS.

FR:6.39 For each key type, the CKMS design shall specify requirements for an advance notification of key destruction, including which parties are notified, how they are notified, what security services are applied to the notification, and the time-frames for notification(s).

A cryptographic key may have several metadata elements associated with it. The CKMS designer must determine which metadata must or can be associated with a key and also the protection mechanism that provides the association. Depending on the nature of the information stored in a metadata element, the metadata element may require confidentiality protection, integrity protection, and source authentication. The association function uses cryptography or a trusted process to provide this protection.

FR: 6.40 For each key type used, the CKMS design shall specify what metadata is associated with the key, how the metadata is associated with the key, and the circumstances under which metadata is associated with the key.

FR: 6.41 For each key type used, the CKMS design shall describe how the following security services (protections) are applied to the associated metadata: source authentication, integrity, and confidentiality.

The modify metadata function can be used to modify existing writable metadata that is associated with a key. Metadata that has been associated with a key should not be modifiable by an unauthorized entity. For example, if the identifier of the key’s owner is included in the metadata, an unauthorized entity should not be permitted to modify the key owner identifier or add additional owners. The binding of a key to its metadata can be achieved using a MAC or a digital signature. The integrity of the key and its metadata may be determined by verifying the MAC or digital signature.

FR: 6.42 The CKMS design shall specify the circumstances under which associated metadata is modified.

This function deletes metadata (for which delete permission has been granted) associated with a key. Metadata elements may be deleted as an entire complete group, as individual elements, or as a specific subset of the elements.

FR: 6.43 The CKMS design shall specify the circumstances under which the metadata associated with a key is deleted.

FR: 6.44 The CKMS design shall specify the technique used to delete associated metadata.

This function allows an entity to list the metadata elements of a key for which the entity is authorized. An entity may have multiple keys with associated metadata in storage. There may be keys for digital signature generation and verification, authentication, encryption/decryption, data integrity, key establishment, and key storage. Authorization to use a key does not automatically imply access to every metadata element associated with the key, but it may be impractical to remember all the values of every metadata element associated with a key. Therefore, the list metadata function may be very useful.

FR:6.45 For each key type, the CKMS design shall specify which metadata can be listed by authorized entities.

Operational key and metadata storage involves the moving of keys and/or metadata to a medium from which the stored data may later be recovered. Keys and metadata should be physically or cryptographically protected when stored outside of a cryptographic module (see [SP 800-57-part1]).

FR:6.46 For each key type, the CKMS design shall specify: the circumstances under which keys of each type and their metadata are stored, where the keys and metadata are stored, and how the keys and metadata are protected.

Key and metadata backup involves the copying of keys and/or metadata to a safe facility so that it can be recovered if the original (operational) copy is lost, modified, or otherwise unavailable. Backup copies of keys and metadata may be located in the same or a different facility than the operational keys/metadata to assure that the keys and metadata can be recovered when needed, even after a natural or man-made disaster. Keys/metadata may be backed-up by the owner or a trusted entity.

FR:6.47 The CKMS design shall specify how, where, and the circumstances under which keys and their metadata are backed up.

FR:6.48 The CKMS design shall specify the security policy for the protection of backed-up keys/metadata¹³.

FR:6.49 The CKMS design shall specify how the security policy is implemented during the key and metadata back-up, e.g., how the confidentiality and multi-party control requirements are implemented during transport and storage of the backed-up keys and metadata.

The archive of keys and/or metadata involves placing keys and/or metadata in a safe, long-term storage facility so that they can be recovered when needed. The archive supports the Key and Metadata Retention Policy (see Section 4.3). Archived keys and/or metadata must be physically or cryptographically protected. Keys used to protect the keys and/or metadata in an archive are called archive keys. These archive keys will also have cryptoperiods, and the continued protection provided to the archived keys and/or metadata needs to be considered when the cryptoperiod of the archive key expires. This may include physical protection and/or the generation of a new archive key for the same or a stronger cryptographic algorithm, and re-encryption of the archived keys and/or metadata under the new archive key.

Key and metadata archiving usually requires provisions for moving archived keys and/or metadata to new storage media when the old media are no longer readable because of the aging of, or technical changes to, the media and media readers. Archived keys and/or metadata should be recovered from the old storage medium and stored on the new storage medium; the keys should be destroyed on the old storage medium after the transfer. When performing key and/or metadata archival or destruction, applicable laws and regulations must be considered so that the keys and/or metadata are available for the required period of time.

FR:6.50 The CKMS design shall specify how, where, and the circumstances under which keys and/or their metadata are archived.

FR:6.51 The CKMS design shall specify the technique for the secure destruction of the key and/or metadata or the secure destruction of the old storage medium after being written onto a new storage medium.

FR:6.52 The CKMS design shall specify how keys and/or their metadata are protected after the cryptoperiod of an archive key expires.

Key and/or metadata recovery involves obtaining a copy of a key and/or its metadata that has been previously backed-up, archived, or stored. The key and/or metadata can be recovered by an authorized entity (e.g., its owner or by a trusted entity) after all the rules for recovery have been fulfilled and verified. The CKMS Security Policy should state the conditions under which a key and/or metadata may be recovered.

FR: 6.53 The CKMS design shall specify the CKMS recovery policy for keys and/or metadata.

FR:6.54 The CKMS design shall specify the mechanisms used to implement and enforce the recovery policy for keys and/or metadata.

FR:6.55 The CKMS design shall specify how, and the circumstances under which, keys and/or metadata are recovered from each key database or metadata storage facility.

FR: 6.56 The CKMS design shall specify how keys and/or metadata are protected during recovery.

Key establishment is the process by which a key is securely shared between two or more entities. The key may be transported from one entity to another (key transport), or the key may be derived from information shared by the entities (key agreement). The method of transporting keys or sharing information may be either manual (e.g., sent by courier) or automated (e.g., sent over the Internet).

FR: 6.57 The CKMS design shall specify how, and the circumstances under which, keys and their metadata are established.

The key entry function is used to enter one or more keys and associated metadata into a cryptographic module in preparation for active use. Keys and metadata may be entered in plaintext form, in encrypted form, as key splits, in an integrity-protected form (e.g., in a signed certificate) or any combination thereof.

FR: 6.58 The CKMS design shall specify how, and the circumstances under which, keys and metadata are entered into a cryptographic module, the form in which they are entered, and the method used for entry¹⁴.

FR: 6.59 The CKMS design shall specify how the integrity and confidentiality (if necessary) of the entered keys and metadata are protected and verified upon entry.

The key output function outputs one or more keys and associated metadata from a cryptographic module for external use or storage. Output may be for archive, backup, or normal, operational purposes. A module that serves as a key generation facility may output keys for subsequent distribution. Keys and metadata may be output in plaintext form, in encrypted form, as key splits, in integrity-protected form, or any combination thereof.

FR: 6.60 The CKMS design shall specify how, and the circumstances under which, keys and metadata are output from a cryptographic module and the form in which they are output.

FR:6.61 The CKMS design shall specify how the confidentiality and integrity of the output keys and metadata are protected while outside of a cryptographic module.

FR: 6.62 If a private key, symmetric key, or confidential metadata is output from the cryptographic module in plaintext form, the CKMS design shall specify if and how the calling entity is authenticated before the key and metadata are provided.

This function performs certain validity checks on the public domain parameters of some public key algorithms. Passing these tests provides assurance that the domain parameters are arithmetically correct (see [SP 800-89] and [SP 800-56A]).

FR: 6.63 The CKMS design shall specify how, where, and the circumstances under which, public key domain parameters are validated.

This function performs certain validity checks on a public key to provide some assurance that it is arithmetically correct. These tests typically depend on the public key algorithm for which the key is intended, but do not depend on knowledge of the private key (see [SP 800-89], [SP 800-56A], and [SP 800-56B]). Note that Sections 6.4.22, 6.4.23, and 6.4.28 are related to providing an overall trust scenario for the validation of these keys.

FR: 6.64 The CKMS design shall specify how, where, and the circumstances under which, public keys are validated.

This function validates the certification path (also known as a certificate chain), from the trust anchor of the relying entity to a public key in which the relying entity needs to establish trust (i.e., the public key of the other entity in a transaction). The validation of the certification path provides assurance that the subject identity that is given in the certificate is, in fact, the identity of the owner of the static public key and the holder of the corresponding static private key (assuming that proof of private key possession was verified by the certificate authority or some other entity trusted by the relying entity).

FR: 6.65 The CKMS design shall specify how, where, and the circumstances under which, a key certification path are validated.

This function performs tests on the symmetric key and its metadata. For example, tests may include checking for the proper length and format of the key. This command may also verify any error detection/correction codes or integrity checks placed upon the key and/or its metadata.

FR: 6.66 The CKMS design shall specify how, where, and the circumstances under which, symmetric keys and/or metadata are validated.

This function performs certain tests on a private key to provide assurance that it meets its specifications. The test can only be performed by the private-key owner or by a trusted third-party acting on behalf of the private-key owner. This test may also involve a pair-wise consistency test that verifies that the private key performs a complementary function to the public key. For example, in the case of an RSA key pair, applying the private key to a given input block, followed by applying the public key to the result should always yield the given input block (see Section 6.4.1 of [SP 800-56B] for more information).

FR:6.67 The CKMS design shall specify how, where and the circumstances under which, private keys or key pairs and/or metadata are validated.

This function is used by an entity that receives a public key and wishes to obtain assurance that the claimed owner of the public key has possession of the corresponding private key, and is therefore the owner of the key pair. The key-pair owner is typically required to use the private key in a cryptographic transaction in which another entity uses the public key in an attempt to verify the possession. For example, the owner may sign data (e.g., the public key and other information) using the private key before sending it to the receiver. The receiver uses the received public key to validate the signature on the received data (see [SP 800-56A], [SP 800-56B], and [SP 800-89]). This function may also contain the capability for a private-key owner to validate the possession of the owner’s own private key.

FR: 6.68 The CKMS design shall specify how, where, and the circumstances under which, possession of private keys and their metadata are validated.

The main usage functions are the actual functions that provide the cryptographic protection to data. These functions may include signature generation, signature verification, encryption, decryption, key wrapping, key unwrapping, MAC generation, and MAC verification. They should be performed within a cryptographic module.

FR: 6.69 The CKMS design shall specify all cryptographic functions that are supported and where they are performed in the CKMS (e.g., CA, host, or end user system).

A CKMS may require that certain entities have one or more trusted public keys. These public keys are also referred to as trust anchors. A trust anchor is used to establish trust in other public keys that are not otherwise trusted. The trust in these otherwise un-trusted public keys is established by verifying all signatures in a chain of public key certificates (termed “certification path” in Section 6.4.23), starting with a trust anchor that is trusted by the relying entity. Thus, the integrity of trust anchors is critical to the security of the CKMS. The CKMS typically supports trust anchor management functions, such as adding, deleting and storing trust anchors. Trust anchor formats are specified in [RFC 5914]. The Secure Trust Anchor Management Protocol (TAMP) is defined in [RFC 5934].

FR: 6.70 The CKMS design shall specify all trust anchor management functions that are supported (see [RFC 6024]).

FR: 6.71 The CKMS design shall specify how the trust anchors are securely distributed so that the relying parties can perform source authentication and integrity verification on those trust anchors.

FR: 6.72 The CKMS design shall specify how the trust anchors are managed in relying-entity systems to ensure that only authorized additions, modifications, and deletions are made to the relying-entity system’s trust anchor store.

When cryptographic keys are submitted for storage, they are typically submitted with their metadata. The metadata may include an owner identifier or user access control list. If any of the metadata is incorrect, then the false information will be perpetuated by the CKMS system. Therefore, a CKMS storage system should verify the authorization of the submitting entity and the integrity of the submitted data before any data is stored¹⁵. When cryptographic keys are stored, they require protection. Symmetric keys and private keys require confidentiality protection and access control. All keys require integrity protection. For confidentiality protection, cryptography, computer security, and/or physical security can be employed. If symmetric key cryptography is used for key confidentiality, then there often exists a symmetric key wrapping key that is used to encrypt and decrypt the stored keys and confidential metadata. At the top level in the key encrypting key hierarchy, there typically is a key that must be physically protected.

If asymmetric key cryptography is used for key confidentiality, then a public key could be used to encrypt stored keys. The corresponding private key that is used to decrypt the keys must be protected in some manner, e.g., using physical security and key splitting (see Section 6.7.5), that usually does not involve encryption.

All stored keys require integrity protection because a garbled key will not correctly perform its intended function and may compromise another key under some circumstances. Physical security can provide integrity protection for keys, but additional methods are frequently used. An error detection code can detect an unintentional garble in a key, and an error correction code can correct certain garbles. However, if a key could be intentionally garbled, then a cryptographic integrity check like a MAC or digital signature should be implemented for error detection. If an uncorrectable garble is detected, the garbled key should not be used. When public keys are contained within a certificate, they are provided integrity protection by means of the digital signature on the certificate. If public keys are stored outside of their certificate, then their integrity needs to be protected by some other means.

A CKMS should only allow authorized users to have access to stored keys. Thus, a CKMS should have some type of access control system (ACS) (see Section 6.7.1). The ACS may be as simple as requiring a password or cryptographic key from the authorized user of the key, and/or it may make use of biometric authentication techniques.

A key may be garbled, lost, or destroyed to the extent that it cannot be reconstructed by error correction codes. If the key is a symmetric key or a private key, this could result in the loss of the data protected by the key. A CKMS should employ methods for backing-up, archiving, and recovering keys as necessary to provide for the recovery of valuable data. For example, Appendix B of [SP 800-57-part1] provides guidance on recovery procedures for various key types.

A garble in key metadata could result in the misuse of the key or the denial of service. Therefore, metadata may also require backup, archiving, and recovery.

FR: 6.73 The CKMS design shall specify the methods used to authenticate the identity and verify the authorization of the entity submitting keys and/or metadata for storage.

FR: 6.74 The CKMS design shall specify the methods used to verify the integrity of keys and/or metadata submitted for storage.

FR: 6.75 The CKMS design shall specify the methods used to protect the confidentiality of symmetric and private stored keys and metadata.

FR: 6.76 If a key wrapping key (or key pair) is used to protect stored keys, then the CKMS design shall specify the methods used to protect the key wrapping key (or key pair) and control its use.

FR: 6.77 The CKMS design shall specify the methods used to protect the integrity of stored keys and metadata.

FR: 6.78 The CKMS design shall specify how access to stored keys is controlled.

FR: 6.79 The CKMS design shall specify the techniques used for correcting or recovering all stored keys.

Keys and metadata can be established between entities wishing to communicate using key transport or key agreement methods. These methods are typically used to establish keys over electronic communications networks, but they could also be used to provide extra security (beyond physical protection) when keys are manually distributed. When keys are transported, one entity generates the key to be shared, and the key and possibly its metadata are distributed to the other entity. When keys are agreed upon, both entities contribute information that is used to derive a shared key. Metadata may be transported under the protection of the shared key. [SP 800-56A] and [SP 800-56B] specify cryptographic schemes for key establishment.

When cryptographic keys and metadata are transported (distributed) from one entity (the sender) to another (the intended receiver), they should be protected. Symmetric keys and private keys require confidentiality protection and access control. For confidentiality protection, either physical security or cryptography is used. A manually distributed key could be physically protected by a trusted courier, or a physically protected channel could be used. Very often, the keys are sent electronically over networks that are susceptible to data eavesdropping and modification. If cryptography is used to protect the confidentiality of symmetric and private keys during transport, then a key establishment technique involving either a symmetric key wrapping key or one or more asymmetric transport key pairs is used. These wrapping and transport keys also should be protected by the end entities involved in the transport.

All transported keys require integrity protection because a garbled key will not correctly perform its intended function, and attacker-controlled key garbles could result in spoofing or cryptanalytic attacks. Thus, detecting garbled keys prior to their use improves the security and reliability of the system. Physical security can provide integrity protection for keys, but often other methods are used, due to the lack of physical protection of electronic data on typical networks. An error detection code can detect an unintentional garble to a key, and an error correction code can correct certain garbles. However, if a key could be intentionally garbled, then a cryptographic integrity check, like a MAC or digital signature, should be used for error detection. If an uncorrectable garble is detected, a new or corrected key should be established before use. When public keys are contained within a certificate, they are provided integrity protection by the digital signature on the certificate.

The receiver of a transported key desires assurance that the key came from the expected authorized key sender. When transported using automated methods, this assurance is typically provided by the use of a cryptographic mechanism that authenticates the identity of the sender to the receiver. When a key is transported manually, this assurance may be provided by the authentication of the trusted courier who transports the key.

FR: 6.80 The CKMS design shall specify the methods used to protect the confidentiality of symmetric and private keys during their transport.

FR: 6.81 The CKMS design shall specify the methods used to protect the integrity of transported keys and how the keys can be reconstructed or replaced after detecting errors.

FR: 6.82 The CKMS design shall specify how the identity of the key sender is authenticated to the receiver of transported keying material.

Two entities, working together, can create and agree on a cryptographic key without the key being transported from one to the other. Each entity supplies some information that is used to derive a common key, but when secure key agreement schemes are used, an eavesdropper obtaining this information is not able to determine the agreed-upon key. Cryptographic algorithms employing key agreement keys are used by each entity.

Each entity participating in a key agreement process typically needs assurance as to the identity of the other entity. This assurance is often provided by the key agreement protocol.

FR: 6.83 The CKMS design shall specify each key agreement scheme supported by the CKMS.

FR: 6.84 The CKMS design shall specify how each entity participating in a key agreement is authenticated.

When keys are established between two entities, each entity may wish to have confirmation that the other entity did, in fact, establish the correct key. Key confirmation schemes are used to provide this capability. [SP 800-56A] and [SP 800-56B] specify key confirmation schemes for use in Federal CKMS. Other methods may also be appropriate.

FR: 6.85 The CKMS design shall specify each key confirmation method used to confirm that the correct key was established with the other entity.

FR: 6.86 The CKMS design shall specify the circumstances under which each key confirmation is performed.

Several automated protocols have been developed for the provision of cryptographic keys for both storage and transmission. Often, these protocols are designed for a particular application or set of applications. Some well-known key establishment protocols include:

A high-level overview of items a) through f) can be found in [SP 800-57-part3], along with guidance as to which cryptographic options are recommended for U.S. Government use. For Secure Shell information, see [RFC 4251].

FR: 6.87 The CKMS design shall specify all the protocols that are employed by the CKMS for key establishment and storage purposes.

This section describes how access to the key and metadata management functions may be controlled. The requesting entity may be authenticated, and human exposure to keys and other sensitive metadata may be prevented or severely restricted.

The security of a CKMS depends on the proper sequence and execution of the key and metadata management functions described in Section 6.4. The execution of these functions may be driven by time, an event, an entity’s request, or some combination of these options. An access control system is necessary to assure that key and metadata management functions are only performed in response to requests (calls) by authorized entities¹⁶ and that all applicable constraints are met¹⁷. For example, the recover key function (see Section 6.4.17) may be restricted to the cryptographic officer role, and input parameters may be verified to be within specified bounds and have specified formats.

原本PDFの抜粋画像

The Access Control System works in conjunction with cryptographic modules to control access to sensitive keys and metadata. An Access Control System (ACS) protects keys by ensuring that only authorized entities are permitted to execute key and metadata management functions. In addition, administrative access is typically logged and audited for personal accountability. An ACS could be very simple; for example, any user submitting an appropriate identifier and password might be authorized to perform any key management function with any key, or the ACS may be much more complex.

Figure 10 illustrates the relationships between the calling entity, the Access Control System, protected memory, and the cryptographic module. These devices may be collocated, or they may be connected by a secure channel as shown in the figure. A calling entity makes CKMS function calls that are serviced by the ACS. The ACS makes use of protected memory and a cryptographic module to authenticate the calling entity. If the authentication is successful, and the entity is properly authorized, then the function is performed by making cryptographic service requests to the cryptographic module. Finally, the response is then passed back to the calling entity.

Additional details of a sample key management function operation are shown in Figure 11. A function call consisting of the calling entity’s identifier, the calling entity’s authenticator, the function name, and the key identifier is presented to the ACS. The entity is first authenticated. Then the entity’s authorization to exercise the command is verified by checking that the entity’s ID is in the access control list (located in the key metadata) for the key and the function. If the ACS determines that the function should not be permitted, then it returns a function-denied indicator. If, however, the function is permitted for the authenticated entity using the key and metadata, then the ACS notifies the function logic to perform the requested operation. The function logic may call upon the cryptographic module to encrypt, decrypt, sign, verify or compute a MAC, as necessary. Finally, the response to the function call is provided to the calling entity.

Figure 10: Management Function Access Control

The ACS makes the decision to perform the requested function or not. This decision is primarily based on the authenticated identity (or role) of the calling entity, the authorizations of the entity, the security policies of the CKMS, the function, the key, and its metadata. The metadata of a key may play a critical role in determining the controls that are to be enforced. For example, an organization may decide that multiple users will be permitted to use a shared key to encrypt and decrypt a particular file, while another file can be decrypted only by a single user. The CKMS policies should support and enforce the information management policies of the managing organization. Therefore, it is highly desirable that a CKMS access control system be flexible enough to accommodate the requirements of the CKMS Security Policy.

Figure 11: Sample Key Management Function Control Logic

FR: 6.88 The CKMS design shall specify the topology of the CKMS by indicating the locations of the entities, the ACS, the function logic, and the connections between them.

FR: 6.89 The CKMS design shall specify the constraints on the key management functions that are implemented to assure proper operation.

FR: 6.90 The CKMS design shall specify how access to the key management functions is restricted to authorized entities.

FR: 6.91 The CKMS design shall specify the ACS and its policy for controlling access to key management functions.

FR: 6.92 The CKMS design shall specify at a minimum:

FR: 6.93 The CKMS design shall specify the capabilities of its ACS to accommodate, implement, and enforce the CKMS Security Policy.

A well-designed CKMS will minimize the access of humans to plaintext keys. The primary need for keys to be in plaintext is when they are performing cryptographic functions within a cryptographic module. These modules usually provide physical protection to the plaintext keys so that they will not be exposed. The module may generate the keys and perform cryptographic functions on behalf of humans, and the humans need never see a plaintext symmetric or private key. This feature makes a CKMS using such modules more transparent and more secure. For example, a private key transport key could be generated within the module and never be allowed to leave the module. Keys that are output from the module could be transported (in encrypted form) using a key transport scheme. A symmetric encryption/decryption key could be encrypted and transported using the public key of the receiving entity. A key may be securely stored outside of the module when encrypted under a public key storage key or symmetric key wrapping key. Sometimes, plaintext key output is permitted to support legacy systems. In such cases, multi-party control, discussed in Section 6.7.4 below, should be considered.

Requirements for the entry and output of keys into and from a cryptographic module are specified in Section 6.4.19 and Section 6.4.20, respectively.

FR: 6.94 The CKMS design shall specify the circumstances under which plaintext secret or plaintext private keys are entered into or output from a cryptographic module.

FR: 6.95 If plaintext secret or plaintext private keys are entered into or output from any cryptographic module, then the CKMS design shall specify how the plaintext keys are protected and controlled outside of the cryptographic module.

FR: 6.96 If plaintext secret or plaintext private keys are entered into or output from any cryptographic module, then the CKMS design shall specify how such actions are audited.

If a key management function requires the human input of keys or sensitive metadata, then there is a dependence on the human for the accuracy and perhaps the security of the input. In addition, there could be a dependency on the human to enter the input at the proper time or when the proper event occurs. In this case, the issue arises as to what action the system should take if the human input is not provided. If such functions can be performed automatically by the CKMS when they are necessary, the system becomes more transparent to the user and possibly more secure.

FR: 6.97 For each key and metadata management function, the CKMS design shall specify all human input parameters, their formats, and the actions to be taken by the CKMS if they are not provided.

Certain key management functions could require multiple cooperating entities to perform the function. This multiparty control could be enforced by requiring k of n entities to authenticate to and be authorized by the function’s access control system before the function is performed. Multiparty controls should be used for highly sensitive functions. For example, a highly sensitive function should require that two or more individuals be logged on and authenticated to perform the function.

FR: 6.98 The CKMS design shall specify all functions that require multiparty control, specifying k and n for each function.

FR: 6.99 For each multiparty function, the CKMS design shall cite or specify any known rationale (logic, mathematics) as to why any \(k\) of the \(n\) entities can enable the desired function, but \(k-1\) of the entities cannot.

Key splitting is a technique for multiparty control. When a highly sensitive key is required, \(n\) key splits are generated so that any \(k\) of the key splits can be used to form the key, but any \(k-1\) key splits provide no knowledge of the key. Each of the \(n\) key splits is then assigned to one of \(n\) trusted entities so that the key cannot be formed unless \(k\) of the entities agree to take part. If any \(k-1\) of the entities had their key splits compromised, the key could still not be reconstructed by an attacker having all the \(k-1\) key splits. Thus, the security of the key is distributed. Split knowledge procedures have been used to establish root or master keys that provide protection to many other keys and whose compromise would result in a major disaster. These key splits (rather than the plaintext key resulting from combining the key splits) are often entered into, or output from, the CKMS in plaintext form for backup purposes.

FR:6.100 The CKMS design shall specify all keys that are managed using key splitting techniques and shall specify n and k for each technique.

FR:6.101 For each \((k, n)\) key splitting technique used, the CKMS design shall specify how key splitting is done, and any known rationale (logic, mathematics) as to why any \(k\) of the \(n\) key splits can form the key, but \(k-1\) of the key splits provide no information about the key.

In an ideal situation, the CKMS would protect all keys and sensitive metadata so that they are never compromised or modified by unauthorized parties. However, since it is difficult or even impossible to design a perfect CKMS that prevents all potential security problems, a CKMS should be designed to detect compromises and unauthorized modifications, to mitigate their undesirable effects, to alert the appropriate parties of compromises, and to recover (or help recover) to a secure state once a compromise or unauthorized modification is discovered. This section addresses how the recovery from a compromise should occur.

When a CKMS compromise is detected

Depending on the key type and key usage, the compromise of a key could result in

Note that the loss of a security service provided to a key is likely to result in a loss of the same and potentially other security services for data protected by the key. For example, a loss of the integrity for a public key transport key could impact the confidentiality of the data encryption key protected by the public key and that, in turn, could compromise the confidentiality of the data protected by the data encryption key. (More specifically, if a public RSA key is changed to have the value 1 modulo n, then any data encrypted by that altered key would be compromised.)

A key compromise could be undetected, detected or suspected. A CKMS should limit the exposure of undetected key compromises by establishing a cryptoperiod or usage limit for each key that it uses¹⁸. At the end of each cryptoperiod, a new key could be established to replace the old key. When a new key is established and activated to protect new data, the old key should no longer be used to protect the new data. Thus, unless the compromise recurs with the new key, the new data will be protected. Of course, the old data that was protected with the old key could have been compromised, but the extent of the compromise is limited, as long as the old key was not used to protect the new key (e.g., the old key was not used to protect the new key during key transport). If a key compromise is detected, then the compromised key and other keys whose security depends upon the security of the compromised key should be replaced as soon as possible. Since the compromise of a key may result in the compromise of many other keys that it protects, it is important to design a CKMS to minimize the impact of key compromise. [SP 800-57-part1] provides guidance as to appropriate cryptoperiods for various key types.

If a symmetric key wrapping key, a private key transport key, or a private key agreement key is compromised, then transported or agreed-upon keys might be compromised as well. If the compromise is undetected, the compromise of additional keys might continue indefinitely. Some protocols are designed to prevent or mitigate such attacks. However it is generally considered a good idea to keep the cryptoperiods of the symmetric key wrapping, key transport, and key agreement keys to the minimum practical period of time.

If a key derivation key or master key is compromised, then any key derived from the key derivation or master key could also be compromised. Therefore, key derivation and master keys should also be changed on a periodic basis.

FR: 6.102 The CKMS design shall specify the range of acceptable cryptoperiods or usage limits of each type of key used by the system.

FR:6.103 For each key, a CKMS design shall specify the other key types that depend on the key for their security and how those dependent keys are to be replaced in the event of a compromise of the initial key.

FR: 6.104 The CKMS design shall specify the means by which other compromised keys can be identified when a key is compromised. For example, when a key derivation key is compromised, how are the derived keys determined?

Depending on the metadata element and how it is used, the compromise of a metadata element could result in the compromise of a key or the data protected by a key. For example, a metadata element of a symmetric encryption/decryption key could be a list of identities corresponding to the legitimate users of the key. The Access Control System verifies the authenticated identity of the user against the metadata element to determine whether the user is permitted to exercise the decrypt function and thus obtain plaintext data. If the metadata element could be modified to add an unauthorized user to the list of authorized users, then the encrypted data could be compromised. If different keys have common metadata elements, then the compromise of one metadata element could compromise the data protected by each of the keys. Metadata elements that are sensitive to unauthorized modification should be cryptographically bound to their associated keys so that the integrity of the metadata can be easily verified.

FR: 6.105 For each key type employed, the CKMS design shall specify which metadata elements are sensitive to compromise (confidentiality, integrity, or source).

FR: 6.106 The CKMS design shall specify the potential security consequences, given the compromise (confidentiality, integrity or source) of each sensitive metadata element of a key.

FR: 6.107 The CKMS design shall specify how each sensitive metadata element compromise can be remedied.

Keys are revoked for a number of reasons, including key compromise and the termination of an employee or the employee’s role within an organization. A CKMS should have the ability to rapidly replace keys (both asymmetric and symmetric) and the ability to notify the relying parties (those who make use of the key) of compromise/revocation.

Compromised Key Lists (CKLs), Certificate Revocation Lists (CRLs) (see [RFC 5280]), White Lists, Query White Lists, and the Online Certificate Status Protocol (OCSP) (see [RFC 6960]) are examples of mechanisms in use for the promulgation of key revocation information to the relying entities. Each mechanism has its benefits and drawbacks. For example, CRLs and CKLs have problems with growing very large and becoming out of date (i.e., stale). Growth adversely impacts communication, computing, and storage requirements. The growth problems for the end entity can be mitigated by partitioning the revocation information into smaller chunks, each chunk handling fewer keys. Staleness cannot be fully eliminated, but can be mitigated by issuing lists more frequently. Note that in some instances, more than one revocation mechanism can be used to meet the security requirements and limitations of the relying parties.

Key revocation mechanisms should consider:

FR:6.108 A CKMS design shall specify the key revocation mechanism(s) and associated relying entity notification mechanism(s) used or available for use.

Since a cryptographic module contains plaintext keys at some point in time, the compromise of the module has the potential to compromise the symmetric and private keys contained within the module (see Section 8.4). This could lead to the loss of confidentiality, the loss of integrity, or the loss of the ability to authenticate, as described in Section 6.8.1 above. Cryptographic modules can be compromised either physically (i.e., obtaining direct access to the keys within the module) or by non-invasive methods so that knowledge of the keys within the module is obtained by some external action. To provide physical protection, modules should operate in a space where unauthorized access is not permitted or where unauthorized access is quickly detected before a serious compromise occurs. Some modules provide this protection at their cryptographic boundary, but larger boundaries may also be involved. See [FIPS 140] for more information on the physical protection of a cryptographic module’s contents. If access to the contents of a cryptographic module is permitted, then an access control system may be required to ensure that only authorized parties succeed.

Following an actual or suspected cryptographic module compromise, a secure state of the module should be re-established. The actions required to return to this state are collectively called recovery. Recovery sometimes requires the replacement of internal hardware and/or software of the module. The module should be returned to a secure state before the module is returned to normal operation. Following repair or replacement, a module must be tested for its operational capability, as well as its security status.

To provide protection against non-invasive attacks on a cryptographic module, either the use of the module should be restricted to only trusted users, or the module should be designed to prevent this specific type of attack. In the first case, there is always the threat that a module will be lost or stolen or that a trusted user will become dishonest. In the second case, it can become very costly to protect against every possible type of non-invasive attack. An attacker might determine information about a cryptographic key used by the module by examining the detailed power consumption patterns of the module during the cryptographic processing. Other potential non-invasive attacks are based on carefully analyzing the amount of time certain cryptographic functions take to execute, or the emanations given off by the module during its normal operation.

FR:6.109 The CKMS design shall specify how physical and logical access to the cryptographic module contents is restricted to authorized entities.

FR:6.110 The CKMS design shall specify the approach to be used to recover from a cryptographic module compromise.

FR:6.111 The CKMS design shall describe what non-invasive attacks are mitigated by the cryptographic modules used by the system and provide a description of how the mitigation is performed.

FR:6.112 The CKMS design shall identify any cryptographic modules that are vulnerable to non-invasive attacks.

FR:6.113 The CKMS design shall provide the rationale for accepting the vulnerabilities caused by possible non-invasive attacks.

The unauthorized modification of CKMS software or major portions of a computer operating system can be detected using tools that run on a separate secure platform and monitor any modification to a file, changes to the hash value of a file’s contents, or changes to a file’s attributes (e.g., who the owner is, or who is on the ACL) (see Section 8.2.4). Alternatively, a layered system of protections is often built into a CKMS. When protective mechanisms are built into the system, they need to be protected from the same threats as the system itself. When critical files undergo unauthorized modifications that are detected by the monitoring utility or indicated in the event log, these files should be replaced using known valid and secure files located in secure storage.

If pervasive, unauthorized changes to software are made, the software should be recovered as described in Section 10.5.

FR:6.114 The CKMS design shall specify the mechanisms used to detect unauthorized modifications to the CKMS system hardware, software and data.

FR:6.115 The CKMS design shall specify how the CKMS recovers from unauthorized modifications to the CKMS system hardware, software and data.

The compromise of network security controls that provide protection to the CKMS could result in the compromise of the CKMS itself. The scope of network security controls includes boundary devices, such as a firewall, a VPN, an intrusion detection system, and an intrusion protection system. The scope of network security controls excludes cryptographic functions, cryptographic protocols, and cryptographic services, except when used for the operation of the aforementioned network security control devices.

The following are some of the examples of compromises of network security controls:

If physical security is compromised, the device should be replaced with a new device and physical security controls should be reviewed, repaired, and enhanced, as appropriate.

If device or administration keys are compromised, the keys should be replaced. An assessment should be conducted to determine the cause of the compromise, the extent of the damage, and corrective actions should be taken. In the unlikely event of the security strength of the key being an issue, the key sizes may need to be increased and/or more secure cryptographic algorithms may need to be used.

If the network architecture assumptions are violated, the cause of the violation should be reviewed, and appropriate actions should be taken.

Compromised network devices should be restored to a secure state before normal operation is continued.

If passwords are compromised, the passwords should be replaced. The users may require further training in selecting the password, in understanding password entropy, in changing passwords frequently, and in maintaining the confidentiality of written-down passwords. An examination should also be made of the authentication protocols to determine if password sniffing, online dictionary attacks or offline dictionary attacks are feasible.

If the platform operating system is compromised, one or more of the following actions should be considered and appropriate corrective measures taken:

If the network security application is compromised, one or more of the following actions should be considered, and appropriate corrective measures should be taken:

If the compromise is due to an inadequate network security protocol, one or more of the following actions should be considered, and appropriate corrective measures should be taken:

In all of these situations, the incident should be fully investigated to determine what other systems and keys may have been compromised due to a compromise of network security controls. This damage assessment could lead to additional compromise declarations and additional compromise recovery procedures.

FR:6.116 The CKMS design shall specify how to recover from the compromise of the network security control used by the system. Specifically,

The humans who are responsible for the correct and secure operation of a CKMS often have the capability to compromise its security. However, a CKMS can be designed with its own capabilities to minimize the likelihood of human compromises, detect the compromises, minimize the negative consequences of the compromises, and efficiently recover from the compromises.

A CKMS should be designed to:

Any detected security failure should result in the initiation of recovery procedures based upon the Information Security Policy and the CKMS capabilities.

Typical responses include:

In addition to the above responses, failures involving personnel compromise could vary from administrative reprimands, to removal from the role or position and legal action involving civil or criminal courts.

FR:6.117 The CKMS design shall specify any personnel compromise detection features that are provided for each supported role.

FR: 6.118 The CKMS design shall specify any personnel compromise minimization features that are provided for each supported role.

FR:6.119 The CKMS design shall specify the CKMS compromise recovery capabilities that are provided for each supported role.

The physical security of a cryptographic module is discussed in Section 6.8.4, and the general compromise of keys and metadata is discussed in Section 6.8.1 and Section 6.8.2, respectively. However a physical security breach of a CKMS could involve compromises other than the compromise of keys or cryptographic modules. If security-related logic resides outside of the CKMS cryptographic modules, then the integrity of that logic also should be protected. Typically, techniques similar to those used by the cryptographic module are employed. Physical protection can be provided that prevents the potential attacker from gaining physical access to the components and devices. Alternatively, detection mechanisms could be used to detect an unauthorized access and then take some defensive action. For example, a detected unauthorized access could sound an alarm or send an alert to the security officer. Often, a combination of prevention and detection measures is used.

Once security is breached, the integrity of the entire breached area should be suspect. If the CKMS detects a breach, it should inform the appropriate entity about the breach, as specified in the CKMS Security Policy, so that mitigation actions can be taken. In addition, it might not be sufficient to replace all sensitive data within the breached area, because the attacker could have modified or added to the logic within the area so that the new keys and sensitive information could also be compromised in the future.

FR:6.120 The CKMS design shall specify how all CKMS components and devices are protected from unauthorized physical access.

FR:6.121 The CKMS design shall specify how the CKMS detects unauthorized physical access.

FR:6.122 The CKMS design shall specify how the CKMS recovers from unauthorized physical access to components and devices other than cryptographic modules.

FR:6.123 The CKMS design shall specify the entities that are automatically notified if a physical security breach of any CKMS component or device is detected by the CKMS.

FR:6.124 The CKMS design shall specify how breached areas can be re-established to a secure state.

Interoperability is the ability of diverse systems to communicate and work together (i.e., interoperate)¹⁹. A CKMS may interoperate with an application or a peer CKMS. Interoperability can only be achieved by having a detailed specification of the interfaces to systems with which the CKMS intends to interoperate. This inherently includes the following:

Current cryptographic algorithms should be implemented so that they can be augmented or replaced when needed. [SP 800-57-part1] and [SP 800-131A] specify NIST-recommended lifetimes of government-approved cryptographic algorithms. A CKMS should only use algorithms whose security lifetime will cover the anticipated lifetime of the CKMS and the information that it protects. If the CKMS is intended to remain in service beyond the security lifetimes of its cryptographic algorithms and key lengths, then there should be a transition strategy for migration to stronger algorithms and key lengths in the future.

When transitioning from one cryptographic algorithm to another, a smooth transition often requires the capability to support the use of at least two algorithms (perhaps with different key lengths) simultaneously so that interoperability can be maintained until all participants have the capability to operate with the new algorithm. In this case, the cryptographic protocols should be designed to identify and negotiate which algorithm will be used in a particular key establishment transaction. It should also be noted that the security of data protected by different algorithms at different times is no greater than the weakest algorithm. Therefore, it may be best to transition as quickly as feasible.

FR:7.1 The CKMS design shall specify how interoperability requirements across device interfaces are to be satisfied.

FR:7.2 The CKMS design shall specify the standards, protocols, interfaces, supporting services, commands and data formats required to interoperate with the applications it is intended to support.

FR:7.3 The CKMS design shall specify the standards, protocols, interfaces, supporting services, commands and data formats required to interoperate with other CKMS for which interoperability is intended.

FR:7.4 The CKMS design shall specify all external interfaces to applications and other CKMS.

FR:7.5 The CKMS design shall specify all provisions for transitions to new, interoperable, peer devices.

FR:7.6 The CKMS design shall specify any provisions provided for upgrading or replacing its cryptographic algorithms.

FR:7.7 The CKMS design shall specify how interoperability will be supported during cryptographic algorithm transition periods.

FR:7.8 The CKMS design shall specify its protocols for negotiating the use of cryptographic algorithms and key lengths.

A CKMS requires security controls to protect its components and devices, along with the data that they contain. For example:

The following subsections of this section describe requirements for each of these types of security controls.

CKMS components and devices should be physically protected in order to ensure information security. Without good physical security, the components and devices could be tampered with and the hardware and/or software could be modified to bypass security.

A CKMS may include facilities that provide third-party key management services, such as a Certification Authority, Key Distribution Center, Registration Authority, or Certificate Directory and also end-to-end communication devices, such as personal computers, personal digital assistants, smart phones, and intelligent sensing devices.

A CKMS may include one or more primary facilities and one or more backup facilities that provide disaster recovery capabilities. Each of these facilities should have physical protection, either by controlling access to the entire facility or by controlling access to the sensitive components or devices within the facility. The use of backup systems for disaster recovery is discussed in Section 10.4.

One or more of the following mechanisms should be chosen to physically protect a CKMS facility, depending on the security criticality of its components and devices. The following are examples of physical security mechanisms. Some of the mechanisms listed below are detection mechanisms that should be augmented with appropriate prevention mechanisms.