NIST SP 800-152 日本語訳

Elaine Barker

Miles Smid

Dennis Branstad

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-152

Elaine Barker

Computer Security Division Information Technology Laboratory

Miles Smid G2, Inc.

Annapolis Junction, MD

Dennis Branstad NIST Consultant Austin, TX

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-152

October 2015

U.S. Department of Commerce Penny Pritzker, Secretary

National Institute of Standards and Technology

Willie May, Under Secretary of Commerce for Standards and Technology and Director

This publication has been developed by NIST to further its statutory responsibility under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law (P.L.) 113-283. 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.

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-152 Natl. Inst. Stand. Technol. Spec. Publ. 800-152, 146 pages (October 2015) CODEN: NSPUE2

This publication is available free of charge from: http://dx.doi.org/10.6028/NIST.SP.800-152

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.

原本PDFの抜粋画像

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.

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: FederalCKMSProfile@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 Profile for U. S. Federal Cryptographic Key Management Systems (FCKMSs) contains requirements for their design, implementation, procurement, installation, configuration, management, operation, and use by U. S. Federal organizations. The Profile is based on NIST Special Publication (SP) 800-130, A Framework for Designing Cryptographic Key Management Systems (CKMS).

access control; confidentiality; cryptographic key management system; disaster recovery; federal cryptographic key management system; integrity; metadata; security assessment; security functions; security policies; source authentication.

Acknowledgements

The National Institute of Standards and Technology (NIST) acknowledges and greatly appreciates contributions by all those who participated in the creation, review, and publication of this document. NIST also thanks the many public and private sector contributors whose constructive comments significantly improved its quality and usefulness. Many useful suggestions on Cryptographic Key Management that were made during the workshops held at NIST in 2009, 2010, 2012, and 2014 have been incorporated into this document.

Executive Summary

The National Institute of Standards and Technology (NIST) Cryptographic Key Management project covers major aspects of managing the cryptographic keys that protect sensitive, unclassified federal information. Associated with each key is specific information (e.g., the identifier associated with its owner, its length, and acceptable uses) called metadata. The computers, software, modules, communications, and roles assumed by one or more authorized individuals when managing and using cryptographic key management services are collectively called a Cryptographic Key Management System (CKMS).

This Profile for U. S. Federal Cryptographic Key Management Systems (FCKMSs) has been prepared to assist CKMS designers and implementers in selecting the features to be provided in their “products,” and to assist federal organizations and their contractors when procuring, installing, configuring, operating, and using FCKMSs. Other organizations may use this Profile as desired.

An FCKMS can be owned and operated by a federal organization or by a private contractor that provides key management services for federal organizations or other contractors performing federal information-processing services.

This Profile can also be used by agencies and organizations to understand their FCKMSs, and to adopt, adapt and migrate their FCKMSs to comply with the Profile requirements over time. NIST does not expect that these requirements would be implemented immediately, but that agencies would use these requirements when creating or procuring FCKMSs or FCKMS services for their Enterprise Architectures.

This Profile is based on NIST Special Publication 800-130, A Framework for Designing Cryptographic Key Management Systems. The Framework specifies topics that should be considered by a CKMS designer when selecting the capabilities that a CKMS will have and the cryptographic key management services it will support. This Profile replicates all of the Framework requirements that must be satisfied in a CKMS and its design documentation, and includes additional information about installing, configuring, operating and maintaining an FCKMS.

The Framework and this Profile could be used by other organizations that have security requirements similar to those specified in these documents or could be used as a model for the development of other profiles.

This Profile for U.S. Federal Cryptographic Key Management Systems (FCKMSs¹) is based on [SP 800-130], entitled “A Framework for Designing Cryptographic Key Management Systems (CKMS),” which provides a foundation for designing and implementing CKMSs. The Framework specifies requirements for designing any commercial or Federal CKMS, while this Profile provides more-specific design requirements for an FCKMS, and includes additional requirements for testing, procuring, installing, managing, operating, maintaining, and using FCKMSs.

This Profile specifies requirements for all FCKMSs. It is intended to assist CKMS designers and implementers to select and support appropriate security services and key-management functions, and to assist FCKMS procurers, administrators, service-providing organizations, and service-using organizations to select appropriate CKMSs or CKMS services. This Profile specifies requirements for all organizations desiring to operate or use an FCKMS, either directly or under contract; makes recommendations for Federal organizations having special security needs and desiring to augment the base security and key-management services; and suggests additional FCKMS features that may be desirable for Federal organizations to implement and use now or in the future

This Profile can be used by agencies and organizations to understand their FCKMSs, and to adopt, adapt and migrate their FCKMSs to comply with the Profile requirements over time. NIST does not expect that these requirements would be implemented immediately, but that agencies would use these requirements when creating or procuring FCKMSs or FCKMS services for their Enterprise Architectures. Agencies can also use these requirements to assess and understand potential gaps that exist in their current FCKMSs. As agencies plan for changes, migrations and upgrades, these requirements and the gap assessment can be used to improve the security of FCKMs overall.

This Profile is intended to:

Designing a secure CKMS is the responsibility of CKMS designers, who must choose among various key-management capabilities to be included in a product being designed for a particular market. Purchasing an acceptable FCKMS or FCKMS service is the responsibility of Federal procurement officials and their technical associates. Managing/administering an FCKMS is the responsibility of appropriate FCKMS service providers when installing, configuring, operating, and maintaining an FCKMS.

This Profile is based on the Framework, and readers of this Profile are strongly encouraged to be familiar with the information in the Framework. The Framework contains tutorial information that may be needed to understand the cryptographic key-management topics of this Profile. This Profile introduces each topic that is also covered in the Framework.

The Framework and this Profile could be used by other organizations that have security requirements similar to those specified in these documents, and the Profile could be used as a model for the development of other profiles.

The Profile often uses terminology that is not used in the Framework. A glossary of terms is provided in Appendix B, but some of the more general terms merit an introduction below.

“CKMS” is used to mean any Cryptographic Key Management System that satisfies the requirements of the Framework. The term refers to the system that is designed and implemented, possibly with configurable options.

An “FCKMS” performs the key and metadata functions that are the foundation of all cryptographic key-management services needed by one or more Federal service-using organizations and their employees.

An FCKMS includes a CKMS, possibly after configuring the CKMS functions to support the desired services of a Federal service-using organization. An FCKMS also meets all the requirements of this Profile for its impact-level and provides FCKMS services for a U.S. Federal organization and/or its contractors.

This Profile uses the terms “FCKMS service-providing organization” (or “FCKMS service provider”) and “FCKMS service-using organization”. An FCKMS service provider may be a part of an FCKMS service-using organization or may be an independent organization providing the services required by FCKMS service-using organizations (e.g., under contract). Federal CKMS service providers may be Federal organizations, Federal contractors, or both. This Profile includes requirements for both FCKMS service providers and FCKMS service-using organizations.

This Profile uses the term “impact-level” to refer to the information-system impact-levels identified in [FIPS 200]. [FIPS 200] uses the security categories in [FIPS 199] to specify and define three information-system impact-levels: Low, Moderate and High. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.

The Profile uses the term “security control” to refer to the security controls provided in [SP 800-53] that support the executive agencies of the Federal government to meet the requirements of [FIPS 200]. [SP 800-53], and [SP 800-53A] apply to all components of an information system that process, store, or transmit Federal information.

The term “FIPS-140 security level” refers to the security levels defined for cryptographic modules in [FIPS 140]. Four levels are defined, where a level 1 cryptographic module provides the least amount of protection, and a level 4 module provides the greatest amount of protection. The cryptographic modules and their implemented FIPS-140 security levels are validated by NIST’s Cryptographic Module Validation Program (CMVP).

The term “security strength” is used to measure the amount of cryptographic protection that can be provided by a combination of a cryptographic algorithm and a key. Further discussion of key strengths is provided in [SP 800-57 Part 1].

In CKMS and FCKMS topic discussions, statements of fact are indicated by “is” or “are”; statements of permission or of possibility are indicated by “may”; statements of capability are indicated by “can”. Statements including “could” are used in discussing possible optional or alternative actions. These terms do not indicate requirements or recommendations of this publication.

An FCKMS is intended for use by Federal agencies and contractors (who use cryptography to protect U.S. government information) to manage all the cryptographic keys and associated metadata.

While individual people are outside the scope of an FCKMS, the roles assumed by these people (e.g., administrators, managers, operators, auditors, and users) are within the scope of an FCKMS. Physical and logical interfaces between an FCKMS and any or all these roles are also within an FCKMS’s scope.

Federal agencies and their contractors are required to select appropriate [FIPS 199] impact levels for their information and to select security controls from those identified in [SP 800-53] to use in procurements, implementations and planning. After selecting the applicable security control(s), organizations can initiate the tailoring process to appropriately modify and align the controls more closely with the specific conditions within the organization (i.e., conditions related to organizational missions/business functions, information systems, or environments of operation). This Profile addresses the selection of several of the security controls specified in [SP 800-53], indicating the minimum requirements for those security controls for each impact level. Other security controls not specifically addressed herein should be selected as appropriate for the organization's systems.

This Profile is intended for CKMS designers and implementers, as well as FCKMS procurers, installers, configuration personnel, administrators, managers, operators, and users.

Federal employees and Federal contractors are the anticipated users of the services provided by an FCKMS. Members of the public sector could be authorized to use the services of an FCKMS when interacting with Federal organizations and their contractors.

Section 1, Introduction, introduces Cryptographic Key Management, CKMSs, FCKMSs, and the Profile.

Section 2, Profile Basics, covers the fundamentals of the Profile and an FCKMS.

Section 3, Goals, defines the goals of an FCKMS.

Section 4, Security Policies, presents the need for and the scope of one or more policies governing the management and use of an FCKMS.

Section 5, Roles and Responsibilities, describes various roles and responsibilities of the people managing, operating, and using an FCKMS.

Section 6, Cryptographic Keys and Metadata, discusses cryptographic algorithms, keys and metadata, various key and metadata management functions, security issues, and error/damage recovery mechanisms.

Section 7, Interoperability and Transitioning, considers the interoperability of FCKMSs and their ability to satisfy future key-management needs.

Section 8, Security Controls, describes the security controls used to protect an FCKMS.

Section 9, Testing and System Assurances, describes security testing and obtaining assurances that security services are being performed correctly.

Section 10, Disaster Recovery, discusses various FCKMS service and data backup capabilities and recovering from several types of disasters.

Section 11, Security Assessment, discusses assessing the operation and security of an FCKMS.

Section 12, Technology Challenges, discusses the technical advances that could affect the security of an FCKMS.

Appendix A, References, provides relevant information for accessing each publication referenced herein.

Appendix B, Glossary, provides a glossary of terms used in this Profile.

This Profile provides a structured view of a Federal CKMS, discussing security provisions that shall, should or could be used by a Federal organization or contractor to manage and protect cryptographic keys and metadata.

This Profile consists of a set of topics that is similar to the topics found in the Framework. Each topic heading is typically followed by an overview of the topic, a list of Framework requirements from [SP 800-130], a list of Profile requirements, a list of recommended Profile augmentations, and a list of possible Profile features. In some cases, there may be no requirements, augmentations, or features that apply to the topic.

Framework requirements for CKMSs are indicated by “shall” or “shall not,” and are numbered beginning with an “FR” designation. Profile requirements for all FCKMSs are indicated by “shall” or “shall not,” and are numbered beginning with a “PR” designation. Some Profile requirements are conditional (e.g., based on the applicable [FIPS 200] impact-level). Only the Framework requirements and the non-conditional Profile requirements are necessary to conform to and comply with this document. A CKMS design conforming to this Profile, must support a configuration that is compatible with both sets of requirements. Recommended augmentations are indicated by “should,” and are numbered beginning with a “PA” designation. Recommended augmentations are strongly recommended by NIST for implementation in most systems. Possible features are indicated by “could,” and are numbered beginning with a “PF” designation. Profile features are optional features that are often intended for complex or future systems. Their possible implementation, if desired, is left to the stakeholders of the system. Federal CKMS service-using organizations could selectively require that their FCKMSs support some of the recommended augmentations or suggested features, but such requirements are beyond the scope of this document.

In order to easily recognize Profile requirements, augmentations and features from the surrounding text, each type is presented in separate tables. For each table:

The first Framework requirement and the first Profile requirement, recommended augmentation and suggested feature are concerned with the overall conformance to the Framework and Profile.

FR:1.1 A conformant CKMS design shall meet all “shall” requirements of the Framework [SP 800-130].

Today’s information systems require protection against the denial of authorized use of their services; unauthorized access to, or modification of, their information processing capabilities; and unauthorized destruction of their equipment and facilities. The information systems themselves must also protect the information that they contain from unauthorized disclosure, modification, and destruction. These protections may be provided by physical means, such as enclosures, locks, and guards, or they can be provided by logical means, such as cryptography or software-based access control.

Cryptography is the only means for protecting data during transmission when physical protection is cost-prohibitive or impossible to provide. Thus, cryptography is widely used when business is conducted or sensitive information is transmitted over a network. Cryptography also provides excellent protection for stored data against entities that are not authorized to obtain or modify the data.

Cryptographic protection for data requires algorithms designed specifically for that purpose. These algorithms often require the use of cryptographic keys, which are managed by an FCKMS. The combination of the cryptographic algorithms and keys of an appropriate length can be used to provide a level of protection for data; this level is commonly referred to as the security strength (see [SP 800-57 Part1] for additional information).

Cryptographic-based security requires the secure management of keys throughout their lifetime. Cryptography can reduce the scope of information management from protecting large amounts of information to protecting a key and its associated metadata (i.e., information about the key). This Profile specifies requirements for the management of the keys used to protect sensitive Federal information and the metadata associated with those keys.

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.

Among the initial requirements for this Profile are requirements for the use of NIST-approved cryptography and the minimum security strengths required for each [FIPS 199] impact level.

The current minimum security strength recommended for Federal applications is 112 bits; this minimum has been required for the protection of Low impact-level information and allows the use of a range of algorithms and key lengths commonly in use that provide at least 112 bit of security, including three-key Triple DEA for encryption and 2048-bit RSA.

For Moderate impact-level information, at least128 bits of security is required, which allows, for example, the use of AES-128 for encryption and 3072-bit Diffie-Hellman for key establishment.

While 128 bits of security might also be currently acceptable for most High-level information, it is anticipated that future technology (e.g., quantum computers) will necessitate a higher level of protection for High-impact level information (either 192 or 256 bits of security). This Recommendation requires at least 192 bits of security for the protection of High-impact information in order to align with [Suite B].

Cryptographic keys are used when applying cryptographic protection to information² or processing already-protected information³. All keys require integrity protection that should be verified before a key is used. Secret and private keys also require confidentiality protection. Before a key is used, the source of the key should be authenticated.

Information about a cryptographic key that specifies its characteristics, acceptable uses, and applicable parameters must be associated with the key. This information is called the key’s metadata, and each descriptive item is called a metadata element. A key and its metadata must be logically or cryptographically linked together and then protected, either cryptographically or physically. These operations are further discussed in Section 6.4.10.

A metadata element for a key could be implicitly known by the FCKMS, but is often explicitly associated and stored with the key. Some metadata elements are sensitive to unauthorized disclosure and, therefore, require confidentiality protection. Like keys, metadata needs protection against unauthorized modification, and the source should be authenticated before the metadata is used. The amount of protection provided to a key and its metadata should be commensurate with the [FIPS 199] security category and [FIPS 200] information-system impact-level of the data being protected by that key and its metadata.

Keys are considered as being either static or ephemeral. Static keys are typically used multiple times and are considered as being “long-term” keys. Ephemeral keys are usually generated when needed and used only once; they are considered to be “short-term” keys.

A trusted association must be established between each static key and its metadata when they are created by the FCKMS, and this association should be maintained throughout the lifetime of the key. A trusted association can be established by a cryptographic binding between a key and its metadata (e.g., a digital signature computed on a key and its metadata), or by a trusted process (e.g., a face-to-face handover of metadata from an entity who is known and trusted). An FCKMS should provide cryptographic binding and verification functions that are used in the key and metadata distribution and management processes.

An FCKMS provides key and metadata management functions for cryptographic-based security in user applications, such as secure data communication and storage. These functions include the generation, distribution and destruction of cryptographic keys and their associated metadata (see Section 6.4).

In accordance with the Framework, any CKMS design should describe how it provides cryptographic keys to the entities that will use those keys to protect sensitive data. The CKMS design documentation should specify the use of each key type, where and how keys can be generated, how they can be protected in storage and during delivery, and the types of entities to whom they can be delivered.

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

FR:2.4 The CKMS design shall specify a high-level overview of the CKMS system that includes: a) The use of each key type, b) Where and how the keys are generated, c) The metadata elements that are used in a trusted association with each key type, d) How keys and/or metadata are protected in storage at each entity where they reside, e) How keys and/or metadata are protected during distribution, and f) The types of entities to which keys and/or metadata can be delivered (e.g., user, user device, network device).

A CKMS Profile provides the requirements that a qualifying CKMS, its implementation, and its operation must meet for a particular sector of interest, such as the Federal government. A CKMS Profile specifies how the CKMS must be designed, implemented, tested, evaluated, and operated. A CKMS Profile is a set of requirements that must be satisfied for a given impact-level by a CKMS as implemented in an operational system.

This FCKMS Profile (i.e., [SP 800-152]) specifies requirements, augmentations, and features for the U.S. Federal government that will allow a CKMS designer and implementer to create an FCKMS that can be used to protect Federal government information.

In the Framework, this section discusses the differences between a Framework and a profile of that Framework. Essentially, the Framework requires that specific topics be addressed during the design of a CKMS and described in design documentation. Any CKMS complies with the Framework if its design documentation satisfies all the Framework Requirements. A profile states the specific requirements that must be met in order to have a satisfactory CKMS for the designated using sector. This Profile (i.e., SP 800-152) imposes specific design and implementation requirements on a CKMS that can be used as an FCKMS, and provides additional requirements for testing, procurement, installation, configuration, administration, operation, maintenance and use.

In the Framework, this section provides a useful example of a secure email application.

This Profile uses the term “component” to mean any hardware, software, and/or firmware required to construct a CKMS. The term “device” denotes a combination of components that function together to serve a specific purpose. An FCKMS module is a device that performs a set of key and metadata management functions for at least one FCKMS.

As shown in Figure 1, an FCKMS includes one or more computers, each with an FCKMS module that interacts with the FCKMS modules in other computers, often using a means of communication that requires cryptographic protection. An FCKMS module is the hardware and/or software that can interact with identical or compatible FCKMS modules located wherever keys and their metadata are required. Each FCKMS module is associated with a cryptographic module. A cryptographic module is the hardware and/or software that performs the actual cryptographic operations, e.g., encryption, decryption and generating a digital signature. Each FCKMS module must have access to a cryptographic module that functions as a sub-module of the FCKMS module.

Figure 1: FCKMS and its FCKMS Modules

The cryptographic modules used in an FCKMS must be FIPS 140-validated at an appropriate FIPS 140 security level for the impact-level associated with the information that the keys will protect. A higher FIPS 140 security level than the minimum level is acceptable.

At a minimum, low impact data must be protected by employing a cryptographic module that has been validated at level 2 or higher, or at security level 1 if the FCKMS provides either identity-based or role based authentication and physical-security protection that compensates for the level 2 physical-security requirements not included in the module. Accordingly, the higher impact-levels must use cryptographic modules that provide increasingly more protection than is provided at the Low impact-level, i.e.. the Moderate impact-level requires a level 3 cryptographic module or higher, and the High impact-level requires level 4 physical security, with all other areas at security levels 3 or higher.

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

A Federal CKMS should achieve goals and satisfy requirements that are specified in the security policies of one or more Federal organizations. The typical primary security goal of an organization is to protect its information at a level commensurate with its value, sensitivity, and perceived risks. Three information-system impact-levels are defined in [FIPS 200] and [FIPS 199]: Low, Moderate, and High. As discussed in Section 8.5, Federal organizations are required to establish the appropriate impact-levels for the various categories of information processed, stored, and transmitted within Federal information systems, based on the potential adverse impact to organizational operations and assets, if such information is lost or compromised. After the impact-level is determined, the appropriate controls for an FCKMS may be selected from [SP 800-53] and this Profile (i.e., SP 800-152), and then assessed using [SP 800-53A].

The information-processing network in which an FCKMS operates is also typically used as the communications backbone of both the user’s applications and the FCKMS. Network characteristics, such as error properties, could influence the selection of the cryptographic algorithms and cryptographic modes of operation, because some modes of operation extend communication errors, which could make the decrypted communication unintelligible. Other modes can minimize the effects of a communication error.

An FCKMS could provide key-management services for a single organization, application, or user, or for many of each. An FCKMS designed for a single application could be integrated into that application, while an FCKMS supporting many applications and/or users in geographically distributed locations could be distributed to wherever key-management services are needed and require communication networks to provide interaction between the distributed applications and users.

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.

Commercial Off-The-Shelf (COTS) products that are designed and produced for many customers are typically less costly to acquire, operate, and maintain than custom products that have been designed for a single customer. A CKMS that satisfies a wide range of requirements is often a goal of CKMS designers, FCKMS service providers and FCKMS service-using organizations because of its reduced cost, wider market acceptance, and greater interoperability among FCKMSs. A COTS CKMS could be configurable to meet the special needs of multiple customers and, therefore, be widely accepted in the marketplace.

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 goal.

An FCKMS that conforms to widely accepted security standards often increases confidence in its ability to provide the desired protection, since it benefits from the wisdom that went into developing the standards. If the standards have validation programs that measure compliance and those validations are obtained, there is increased confidence that the FCKMS has implemented that standard correctly. The use of standards also fosters interoperability when different FCKMSs need to interoperate.

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

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

Ease-of-use is very subjective. Something easy for one person to do may not be easy for another. An FCKMS should be easy to use by both untrained and experienced users. For example, the FCKMS could assist untrained users by performing the required actions automatically, but provide an interface for experienced users to select and use acceptable alternative actions. Negative user experiences could affect the acceptability and use of a security service or product. A Federal CKMS should be designed to support a range of user expertise and experience.

Ease-of-use testing is discussed in Section 9.8.

An FCKMS should accommodate differences in user abilities and preferences when managing their keys and metadata. Differences generally include user knowledge, experience, task familiarity, and motivation. Preferences often vary between user control and system control.

An FCKMS could provide fully automated security services to a user or an application, based on the organizational policy. It could provide a combination of automated security services and those selected and controlled by a user or application. An FCKMS should support user control, based on organizational policy and user desires, and provide one or more security-service-control interfaces for its users and managers.

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.

Ease-of-use design goals should assure that: a) It is intuitive and easy to do the right thing, b) It is not easy to do the wrong thing, and c) It is intuitive and easy to recover when a wrong thing is done.

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 and scalability should be considered when designing a CKMS. The performance of an FCKMS will generally depend on factors that include 1) the simplicity of the overall design, 2) the number and type of service-using organizations, 3) the sensitive applications and number of users being supported, 4) the communications capabilities and geographical distribution among the distributed devices of the FCKMS, and 5) the capabilities of the computers, modules, and devices comprising it. The scalability of an FCKMS depends on such factors as the flexibility of the underlying CKMS design and implementation to support increasing service demands, and the ability to replace or upgrade its devices and components as necessary.

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 goal of designing, implementing, and operating any system is to avoid complex and expensive litigation. Intellectual property rights, such as copyrights, trademarks, and patents should be respected as required by law. Therefore, it is best to identify and resolve possible legal issues as soon as possible.

An organization often creates and supports layered security policies, with high-level policies addressing the management of its information and lower-level policies specifying the rules for protecting the information.

An organization could have different policies covering different applications or categories of information. For example, a Federal organization could have one set of policies covering its financial information and a different set of policies covering its personnel information.

This section describes a layered set of policies, including an Information Management Policy, an Information Security Policy, and an FCKMS Security Policy.

An organization’s Information Management Policy governs the collection, processing, and use of an organization’s information, and should specify, at a high level, 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.

These specifications are the foundation of an Information Security Policy (see Section 4.2) and dictate the levels of confidentiality, integrity, availability, and source-authentication protections that must be provided for each category of sensitive and valuable information covered by the Information Management Policy.

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. A Federal organization may have different Information Security Policies covering different applications or categories of information (e.g., the policies may be different for non-personnel information than for personnel information).

The Information Security Policy should be used to create an FCKMS Security Policy (see Section 4.3).

This Profile is based on the assumption that a CKMS designer will either build a product that supports the specific policies of its known potential customers or one that is comprehensive and flexible enough to be configured to satisfy different security policies for a large number of future customers.

A CKMS designer creates a CKMS Security Policy to protect the cryptographic keys and metadata used by the CKMS and to enforce restrictions associated with their use. The protections should cover the entire key lifecycle, including when they are operational, stored, and transported. A CKMS Security Policy includes an identification of all cryptographic mechanisms and cryptographic protocols that can be used by the CKMS.

The FCKMS Security Policy of a security domain should be derived from the Information Management policies of all organizations comprising the security domain. All entities that constitute a security domain are responsible for being aware of and following the FCKMS Security Policy. All entities in the domain are responsible for protecting the keys and associated metadata used to cryptographically protect data in accordance with the FCKMS Security Policy.

Figure 2: CKMS Security Policy Configurations

An FCKMS Security Policy is intended to support the Information Security Policy of the FCKMS service-using organization(s) by specifying the rules for managing the cryptographic keys and metadata used to protect the information. An FCKMS Security Policy may be a configured subset of the designer’s CKMS Security Policy, which specifically meets Federal government requirements and also the specific requirements of the service-using organization(s). See Figure 2 for an example.

Figure 2 depicts a CKMS Security Policy (in the top-level box) with general features and capabilities, as well as optional features/capabilities that can be selected or prohibited to create a sub-policy appropriate for a specific CKMS service provider. The green text is used to indicate features that are compliant with the United States Government (USG) requirements of this document. Options A, C, and D (indicated in green text) are all approved for USG use. However, Option B (indicated by red text) is not approved. For example, Option B may involve the use of a cryptographic algorithm that is not approved for USG use. The second-level boxes show three possible configurations that could be selected using the CKMS options. Configuration 1 contains Options A, C, and D; Configuration 2 contains Options A and B; and Configuration 3 contains only Option B. Configuration 1 can always function as an FCKMS, since all its features and options are consistent with USG use. Configuration 2 can function as an FCKMS when Option A is used, but it can function only as a CKMS when Option B is used. Finally, Configuration 3 can never function as an FCKMS, since the non-approved Option B is always used. Federal agencies could always use Configuration 1. They could use Configuration 2 if only Option A was selected, but they could never use Configuration 3 for sensitive U.S. Government data.

Ultimately, it is the responsibility of the organization that owns the data to assure that the data is properly protected. That organization is often the FCKMS service-using organization. An FCKMS service-using organization must use an FCKMS that supports a security policy that is consistent with its higher-level policies (e.g., its Information Management Policy and Information Security Policy) and other applicable U.S. Government requirements. A Federal organization that is considering the procurement of a CKMS or the services of a CKMS provider should review the security policy of each candidate CKMS and verify that the CKMS has the necessary capabilities. An appropriate FCKMS Security Policy should then be created. The FCKMS Security Policy should specify the rules that can assure the availability, confidentiality, and integrity of the organization’s cryptographic keys and bound metadata that will be used to protect the sensitive information to be protected by the FCKMS. An FCKMS service-using organization should verify that its security policies are consistent with, and can be supported by, an FCKMS service provider, both administratively and technically.

The FCKMS Security Policy should specify how to protect each type of key and its associated metadata throughout their lifecycles, including when they are stored, transported, or used.

An FCKMS service-using organization should assist in adopting, supporting, and enforcing its own security policies and implementation rules by providing for tutorials to new managers and users on how services should be managed and used. If a user can select and initiate security services for an application or category of information, then the FCKMS service-providing organization should assist in selecting appropriate security services by informing the user of the rules and how the rules can and should be followed. The FCKMS should be configured so as to minimize the likelihood that a user could select an inappropriate option.

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 security policy should be written so that the people responsible for managing and using the policy can understand the goals of the policy and can follow its implementation rules. A security policy could be encoded in an electronic form (e.g., a policy specification formal language, table of security rules, or computer program) such that an FCKMS could automatically support and enforce parts of the policy. Automated security policy support systems could be programmed to detect security problems and resolve them in accordance with the policy.

A Security policy can be described in a formal language that can be used to explicitly define the syntax (i.e., acceptable sentences) of a policy such that a computer program can recognize and follow the rules of the policy. These rules could be called the semantics (i.e., acceptable meaning) of each sentence of the language. If a security policy is encoded correctly, a Federal CKMS could support and enforce it.

As shown in Figure 1 of Section 2.10, an FCKMS consists of one or more computers containing an FCKMS module, with an associated cryptographic module. The computer could, in fact, have more than one FCKMS module and more than one cryptographic module. Each FCKMS module is designed to support one or more FCKMSs, along with their FCKMS Security Policies.

Each FCKMS module must have its own FCKMS Module Security Policy, which supports one or more FCKMS Security Policies. However, the security policy for an FCKMS module may not be a full FCKMS Security Policy. The FCKMS Module Security Policy need only deal with the subset of the FCKMS Security Policy that applies to the module itself.

Figure 3 depicts an example of a network consisting of three Federal Entities and three FCKMSs, each with its own FCKMS Security Policy as indicated by the colors red, blue, and green. The arrowed lines between FCKMS modules indicate communications links over which cryptographic keys and metadata may be established according to the policy indicated by the color of the line. Thus, Federal Entity 1 can establish keys with Federal Entity 2 using the blue FCKMS with the blue FCKMS Security Policy. Federal Entity 1 can also establish keys with Federal Entity 3 using the red FCKMS with the red FCKMS Security Policy. Finally, Federal Entity 1 could store keys that it uses only for its own purposes using the green FCKMS with the green FCKMS Security Policy.

Figure 3: An FCKMS Network

Figure 3 shows that a module may function in different FCKMSs and support different FCKMS Security Policies. For example, Federal Entity 1 has a module that can support either a blue FCKMS Security Policy or a red FCKMS Security Policy. Such FCKMS modules must be capable of maintaining the separation of the keys and metadata of each FCKMS that it supports. Federal Entity 3 cannot exchange keys and metadata with Federal Entity 2 or Federal Entity 4 unless the red and blue FCKMS Security Policies are determined to be equivalent or compatible (see Section 4.11.3) by the red and blue system authorities.

A cryptographic module security policy is a statement of the rules that the cryptographic module will follow when performing cryptographic functions (e.g., key generation and signature verification). This policy specifies the mechanisms to be used to maintain the security of the module and to protect sensitive data, including secret and private plaintext keys and sensitive metadata. The cryptographic module security policy includes specifications for controlling access to the keys and metadata, the physical security provided to protect the module’s storage and processing capabilities, and the mitigation of other attacks specified in the policy. See [FIPS 140] for further information.

An FCKMS Security Policy could include or rely on other security policies or provisions, such as a Physical Security Policy, a Communications Security Policy, and/or a Computer Security Policy. Organizations typically develop their own physical security policies, and computer systems are often built to their own computer security policies. An organization should organize 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.

The Information Management Policy, Information Security Policy, FCKMS Security Policy, FCKMS Module Security Policy, Cryptographic Module Security Policy and other related security policies typically form a top-down layered set of policies in which a lower-layer policy supports the policy/policies at the higher layers. For example, an Information Management Policy for protecting certain categories of information from unauthorized disclosure may result in an Information Security Policy for encrypting data before being transmitted or stored. This Policy may dictate an FCKMS Security Policy specifying the use of symmetric-key encryption/decryption using a specific algorithm and key length. The FCKMS Module Security Policy may specify the necessary key and metadata management functions, and the Cryptographic Module Security Policy would describe how the keys would be protected while in a Cryptographic Module.

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 Personal Accountability Policy 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 needs to be supported by specific features in the FCKMS for the management of keys and metadata, such as an access control system that requires users to authenticate their identity before access is granted to an FCKMS capability.

An FCKMS that supports a Personal Accountability Policy needs to be able to correctly identify each person accessing and using the FCKMS, determine who is authorized to access controlled items, grant access only upon verification of the authorization, and detect and report any attempts for unauthorized access.

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

An Information Security Policy could require that certain users or categories of users of a secure information-processing system be assured of anonymity, unlinkability, and/or unobservability. a) Anonymity assures that an entity cannot be associated with specific information or actions; b) Unlinkability assures that two or more events in an information processing system cannot be determined to be related; and c) Unobservability assures that an attacker is unable to identify or infer the existence of a transaction and the identities of the entities that initiate or participate in the transaction.

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

An FCKMS often requires information about the identity of entities participating in FCKMS transactions (e.g., to determine the keys to be used); an entity assuming the audit role may also require this information. However, an FCKMS could protect the anonymity of the entities operating in the user role when viewed by entities assuming non-audit roles and entities not involved in the transactions. Since personal accountability is required at the Moderate and High impact-levels, anonymity can only be provided at the Low impact-level.

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.

An FCKMS may need to link FCKMS transactions together, e.g., a transaction that requests the generation of a key, and another that uses it; an entity assuming the audit role may also require this information. However, an FCKMS could provide unlinkability protection of FCKMS transactions such that entities cannot be linked to initiating or participating in an FCKMS transaction when viewed from outside the FCKMS or by entities assuming non-audit roles within the FCKMS that are not involved in those transactions.

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.

An FCKMS could protect the existence of transactions and the identities of the entities that initiate or participate in the transactions from being observed (i.e., monitored, recorded).

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 its FCKMS will be used. If an FCKMS is designed for international use, then it should be flexible enough to conform to the restrictions of multiple nations.

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 that support the same FCKMS Security Policy (see Section 4.3). When two mutually trusting entities are operating in the same security domain, the entities can exchange keys and metadata while providing the protections that are required by the FCKMS Security Policy.

Security domains can be useful when managing an organization’s users and computers that can connect to users and computers in other organizations. If different entities are in the same Security Domain, sharing information securely is relatively easy. If they are in different Security Domains, then the sharing of information becomes difficult or even impossible.

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 are operating in different FCKMSs under different FCKMS 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 their policies are not identical.

Before information is shared between entities in two or more Security Domains, their FCKMS Security Policies must be carefully examined before exchanging or combining their information. The domain authorities for the domains intending to share information should verify that the different FCKMS Security Policies provide acceptable protection for each other’s data. Computers could verify the equivalence or compatibility of two or more FCKMS Security Policies if they are encoded to enable such verification.

A security domain could be defined for a single information impact-level (e.g., Low) or could be defined for multiple impact-levels (e.g., Low and Moderate). The computer systems that are processing multiple levels of sensitive information must be designed, programmed, and operated to separate and protect the processing of information at the different impact-levels.

Both the entity intending to send sensitive data to another entity in a different domain, and the intended receiving entity, should satisfy the following conditions:

If two entities belong to the same security domain, it is likely that these conditions can be met. If the entities do not belong to the same security domain, then these conditions are less likely to be satisfied. See Section 4.9.2 of the Framework for additional information.

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 within security domains include protecting a key and/or metadata from unauthorized disclosure and unauthorized modification, as well as verifying the source and destination of a key and/or metadata.

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.

When entities in different security domains need to share or mix data, their respective security policies must be equivalent or compatible.

Two security domains have equivalent FCKMS Security Policies if the authority responsible for each security domain agrees to accept the other domain’s FCKMS Security Policy as being equivalent to its own FCKMS Security Policy in terms of the security protections, including the levels of protection provided. If it is determined that the policies of two FCKMSs are equivalent, then an entity in one security domain may share data with an entity in another equivalent domain.

Two security domains are compatible if they can exchange a key and its metadata without changing the protection provided to the key and metadata and without violating (or altering) either domain’s FCKMS Security Policy. For example, suppose that domain 1 allows domain 1 entities to bind keys and metadata using RSA-2048, and domain 2 allows domain 2 entities to receive and verify the binding on keys with RSA-2048, but domain 1 does not permit using RSA-2048 for verifying the binding on keys, and domain 2 does not permit using RSA-2048 for binding keys. Clearly, their security policies are different and not equivalent, yet a key may be sent from a domain 1 entity to a domain 2 entity because the two domains are compatible for a transaction that sends a key from domain 1 to domain 2.

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.

When two domain authorities examine each other’s FCKMS Security Policy for equivalence to or compatibility with their own FCKMS Security Policy, they should carefully examine each other’s policies for sharing keys, metadata and other information with other third-party entities. For example, if domain A shares keys with domain B, can domain B share the same key and metadata with an equivalent domain C? See the Framework for further discussion.

A security domain could contain information having more than one impact-level (e.g., Moderate and High). In this case, an FCKMS must support key management for protecting the information at both impact-levels. For this multi-level situation, the security domain acts much like two separate security domains because it must distinguish between the two levels of protection. Each entity in the domain must ensure 1) that keys and/or metadata protected by the higher-level policy are always provided with the higher level of protection, 2) that keys and/or metadata protected by the lower-level policy cannot be confused with the higher-level keys and/or metadata, and 3) that higher-level keys and/or metadata do not get confused with lower-level keys and/or metadata. This typically involves a multi-level secure computer operating system.

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

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

FR:4.23 If multi-level 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 could 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 protected at the higher level required by its own FCKMS Security Policy. This process is called upgrading. Upgrading should only be done if the authority responsible for the higher-level domain trusts the source and authenticity of the key and/or metadata to be provided from the lower level. Likewise, the domain authority for a higher-level security domain might need to pass a key and/or metadata to a lower-level security domain entity, requiring the protection on the key and/or metadata to be downgraded. In this case, the domain authority for the higher-level domain must be assured that the key and/or metadata being passed down only require the lower level of security provided by the receiver’s lower-level domain.

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.

It may be desirable to change an FCKMS Security Policy. Some FCKMSs could have been designed so that their FCKMS Security Policies can be configured to permit changes. The domain authority should approve any policy change before it is made. It is the responsibility of the Domain Authority initiating the change to inform other affected Security Domain Authorities (e.g., other domains that have been determined to be equivalent or compatible) when such changes to a security policy are 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 FCKMS Security Policies and differing applications.

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

An FCKMS could interface with humans who are performing specific management, user, and/or operator roles. Each role should have specific requirements for a person that will be authorized to perform it. Each person that is authorized to perform a role should be provided access to a set of key and metadata management functions that will assist in carrying out the responsibilities of the role. In order to be authorized to perform a role and its associated functions, each entity must be authenticated; note that this is a requirement for all FCKMS impact-levels. This requirement may be satisfied by identity-based authentication at all impact-levels or role-based authentication at the Low impact-level. Also, note that role-based authentication is a less restrictive requirement than personal accountability, which is addressed in Section 4.8.

Examples of FCKMS roles include, but are not limited to, the following. A description of each role is provided in the Framework.

a) System Authority, b) System Administrator, c) Cryptographic Officer, d) Domain Authority, e) Key Custodian, f) Key Owner, g) CKMS User, h) Audit Administrator, i) Registration Agent, j) Key-Recovery Agent, and k) CKMS Operator. Multiple individuals could be assigned to perform a role, and/or one person could be authorized to perform multiple roles. The same individual should not perform certain roles indefinitely. It is prudent to periodically (and perhaps randomly) rotate individuals among different roles to minimize the likelihood of long-term abuses. All persons should be properly trained for the roles that they are assigned to perform. Highly sensitive roles may require multiple individuals to perform the role (e.g., multiparty control).

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

Cryptographic algorithms and their keys can be categorized according to their properties and uses. Algorithms and keys can be categorized as being symmetric (with secret keys) or asymmetric (with key pairs, one being public and the other private). Keys can be static (i.e., long term) or ephemeral (i.e., typically used only for a single secure session or key management transaction). Cryptographic algorithms can be used for signature generation, signature verification, data integrity, entity identity verification, information encryption and decryption, and random number generation (RNG). Each type of cryptographic algorithm requires a type of key appropriate for that algorithm and its current application. Key uses include signature, authentication, encryption/decryption, key wrapping, random number generation (RNG), master key, key transport, key agreement, and authorization. General requirements relating to cryptographic algorithms and key strengths have been addressed in Section 2.1.

The Framework provides a list of twenty-one key types (shown below in Table 1) and a short description of each key type.

Table 1: Key Types

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

All keys managed by an FCKMS require integrity protection. Secret and private keys also require confidentiality protection. FIPS-validated cryptographic modules have been designed to provide this protection when used in accordance with the associated security policy. However, when outside a FIPS-validated cryptographic module, either physical or logical protection is required for these keys. Cryptographic protection is one form of logical protection.

When cryptographic keys and domain parameters⁴ are stored or distributed, they may pass through unprotected environments. In this case, specific assurances are required before the key and/or domain parameters may be used to perform cryptographic operations. Assurance of integrity is needed for all keys and metadata. Assurance of possession is needed for both secret and private keys. Assurance of domain parameter validity is needed for certain public-key algorithms. Assurance of validity is needed for symmetric keys and the key pairs of public-key algorithms (which includes pairwise consistence). See [SP 800-89], [SP 800-56A] and [SP 800-56B] for further discussion. Other assurances that may be needed include source authenticity.

Key metadata is defined as information associated with a particular key that is managed by the FCKMS.

The CKMS designer should select the metadata that is appropriate for a trusted association with a key, based upon a number of factors, including the key type, the key lifecycle states, and the CKMS Security Policy.

The following are metadata elements that are described in the Framework and may be explicitly recorded. The descriptions in the Framework should be carefully reviewed when making decisions with regard to their applicability. The metadata elements are:

a) Key label, b) Key identifier, c) Owner identifier, d) Key lifecycle state, e) Key format specifier, f) Product used to create the key, g) Cryptographic algorithm using the key, h) Schemes or modes of operation, i) Parameters for the key, j) Length of the key, k) Security strength of the key/algorithm pair, l) Key type, m) Appropriate application(s) for the key, n) Key security policy identifier, o) Key list (ACL), p) Key usage count, q) Parent key: This element could have two sub-elements:

i. Key identifier, and ii. Nature of the relationship.

r) Key sensitivity, s) Key protections: This element could have several sub-elements: i. The mechanism used for integrity protection, ii. The mechanism used for confidentiality protection iii. The mechanism used for source authentication, and iv. An indication of the protections that are enforced by a particular non-cryptographic trusted process.

t) Metadata protections: This element could have several sub-elements: i. The mechanism used for integrity protection, ii. The mechanism used for confidentiality protection, iii. The mechanism used for source authentication, and iv. An indication of the protections that are enforced by a particular non-cryptographic trusted process. u) Trusted association protections: The following may need to be provided for each trusted association protection: i. The mechanism used for integrity protection, and ii. The mechanism used for source authentication.

v) Date-Times:

i. The generation date, ii. The association date, iii. The activation date, iv. The future activation date, v. The renewal date, vi. The future renewal data, vii. The date of the last rekey, viii. The future rekey date, ix. The date of the last usage of the key, x. The deactivation date, xi. The future deactivation date, xii. The expiration date, xiii. The revocation date, xiv. The compromise date, xv. The destruction date, and xvi. The future destruction date.

w) Revocation Reason.

These metadata elements specify a key’s important characteristics, its acceptable uses, and other information that is related to the key. This information is used by an FCKMS when managing and protecting the key. Metadata elements relevant to the management and use of a key should be correctly associated with a key and used whenever a key is stored, retrieved, loaded into a cryptographic module, used to protect data (e.g., other keys), exchanged with peer entities authorized to use the key, and when assuring that a key is correctly protected.

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: i. The cryptographic algorithm: See item g) above. ii. The parameters for the key: See item i) above. iii. The key identifier: See item b) above. iv. The protection value: This element contains the protection value for integrity protection, confidentiality protection, or source authentication. For example, a properly implemented MAC or digital signature technique may provide for integrity protection and/or source authentication. v. When the protection was applied. vi. When the protection was verified.

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: i. The identifier of the process used to distinguish it from other processes, and ii. A description of the process or a pointer to a description of the process.

FR:6.5 For each cryptographic mechanism used in the Metadata Protections metadata element (item t above), the CKMS design shall specify the following: i. The cryptographic algorithm. ii. The parameters for the key. iii. The key identifier. iv. The protection value (e.g., MAC, digital signature). v. When the protection was applied. vi. When the protection was verified.

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: i. The identifier that is used to distinguish this process from other processes, and ii. A description of the process or a pointer to a description of the process.

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: i. The cryptographic algorithm, ii. The parameters for the key, iii. The key identifier, iv. The protection value (e.g., MAC, digital signature), v. When the protection was applied, and vi. When the protection was verified.

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: i. The identifier that is used to distinguish this process from other processes, and ii. A description of the process or a pointer to a description of the process.

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.

Each key type requires certain metadata information to be available when a key is used, whether the information is explicitly recorded as metadata or is otherwise known by the FCKMS.

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. For a discussion of key states, see Section 7 of [SP 800-57 Part 1]. A CKMS designer will select and define the key states and transitions that will be supported by the FCKMS.

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.

In an FCKMS, an entity can initiate key and metadata management functions. The functions themselves are performed entirely within an FCKMS module, which contains a cryptographic module to perform the cryptographic functions used by the FCKMS module. An Access Control System (ACS) (see Section 6.7.1) performs the authentication and authorization of an entity initiating a function.

An FCKMS should provide for the creation, modification, replacement, and destruction of keys and their metadata. Depending on the impact-level and key type, the input and/or output could have integrity authentication, source authentication, and/or confidentiality services applied to them.

A trusted channel is a protected communication link established between the cryptographic module and a sender or receiver to securely communicate unprotected plaintext CSPs, keys, and authentication data. A trusted channel protects its contents from unauthorized modification and disclosure along the communication link (see [ISO19790]).

A trusted channel exhibits a verification capability that permits the operator or the module to confirm that the trusted channel has been established. The trusted channel must use only NIST-approved security functions (see [FIPS 140]) to establish the channel and transfer data.

In the following subsections, the use of "key" applies to a symmetric key and an asymmetric key pair, as appropriate, unless otherwise indicated.

Parameters for a cryptographic function should be verified during input to an FCKMS and a cryptographic module by verifying the protections (e.g., integrity codes) that have been placed on the parameters.

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 an entity requires a key, and it is not automatically provided by an FCKMS, the entity should request that a key be generated by the FCKMS. The entity may need to specify the type of key and other necessary information (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 not return the newly generated key, but could, for example, return a key identifier that points to the key and its associated metadata.

Key-generation techniques typically depend on the cryptographic algorithm that will be used with the key and the use of a random number generator. Different algorithms use keys that have differing specifications (e.g., lengths and formats). Key generation for an asymmetric algorithm results in the generation of a key pair, rather than a single key, which is the case for symmetric algorithms. NIST has approved several random number generators (see [SP 800-90A], [SP 800-90B], [SP 800-90C] and [SP 800-131A]) and specifications for key generation (see [SP 800-133]).

The key-generation function could provide, or require the input of, metadata that is to be 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., an individual (person), organization, device or process) and a cryptographic key with metadata is a fundamental requirement of every FCKMS. This requirement is difficult to fully automate while preserving security (i.e., protecting from an impersonation threat), and thus, it usually requires verified and authorized human interactions. There typically exists a registration process in an FCKMS that associates each entity’s initial set of long-term (i.e., static) secret, public, and/or private keys with the entity’s identifier and perhaps other metadata. The process of associating a key-owner’s identifier, key, and metadata involves either an initial identity-based authentication by a human relying on specific identification information, or relying on the pre-existing identity of the owner in some FCKMS.

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 (see [SP 800-57 Part 1] for further information). A key could be automatically activated immediately after generation, upon request, or in accordance with a date-time metadata value (e.g., set at the time of key generation) that indicates when the key needs to become active and can be used.

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 from an active state to a deactive state (see [SP 800-57 Part 1] for further information). A cryptographic key is generally given a deactivation date and time when it is created and distributed. Deactivation may also be based on the number of times a key has been used to apply cryptographic protection or the amount of data that it has been used to protect. This period usually has a maximum value, based in part on the impact-levels of the data that the key is protecting and the threats that could be brought against that key or the entire FCKMS.

FR:6.24 The CKMS design shall specify, for each key type, how deactivation of the key is determined (e.g., by crypto period, by number of uses, or by the 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).

When a key is to be removed from service, it may be revoked. Key revocation should be used when the authorized use of a key must be terminated prior to the end of its cryptoperiod. A cryptographic key should be revoked as soon as feasible after its use is no longer authorized (e.g., the key has been compromised). Entities that have been, are, or will be using the key (i.e., relying parties) need to be notified that the key has been revoked. Such notification is accomplished by sending the notification to all relying parties and/or providing a notification that can be accessed by the relying parties, when needed. In this publication, revocation applies to both symmetric and asymmetric keys.

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, i.e., suspension is a temporary revocation of the key. While revocation is generally irreversible, suspension can be reversed. Entities that may be using or relying on a key must be notified of both the suspension and the re-activation of the key.

Situations that may warrant suspension of a key, rather than irreversible revocation, include: the unavailability of the owner for an extended period of time, a misuse of the key, a possible compromise that is under investigation, and the misplacement of a token containing the key.

FR:6.29 The CKMS design shall specify how, and under what circumstances, a key can be 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 the public key of an asymmetric key pair and a validity period for that certificate. Renewal establishes a new validity period by issuing a new certificate containing the same public key, but a new validity period.

The public key in a certificate corresponds to a private key (which is kept secret). One key of the key pair is used to apply cryptographic protection (e.g., to generate a digital signature), and the other key is used to process the protected information (e.g., to verify a digital signature). Each key of the key pair has its own cryptoperiod. The cryptoperiod of a key used to apply protection can be considered as being the "originator usage period," and the cryptoperiod of a key used to process the protected information can be considered to be the "recipient usage period." The validity period in a certificate applies to the key that is used to apply protection, and must not exceed the key's originator usage period.

Several algorithms have been approved that use key pairs, and the role of each key of the key pair is not necessarily the same. See [SP 800-57 Part 1] for more information.

The sum of the validity periods for the original certificate and all renewed certificates for the same key must not exceed the cryptoperiod of the key used to apply protection (i.e., the key with the originator usage period).

An FCKMS could notify the owner of a certificate when a certificate is about to expire so that the certificate could be renewed prior to the end validity date on the certificate.

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 key type renewal, 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 update is a special case of key derivation in which the secret information includes a symmetric key (\(K_1\)), and the derived symmetric key (\(K_2\)) replaces \(K_1\) for the next key-update process. Key updating could result in a security exposure if an adversary obtains a key and knows the update process used. Key update is not supported in this Profile.

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 for deriving or updating 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).

When a key and its sensitive metadata are no longer to be used for normal operations, then all copies residing in operational storage (including within a cryptographic module) and in backup storage should be destroyed as soon as possible. Keys and sensitive metadata in an archive should be destroyed when no longer needed. Non-sensitive metadata may be retained for administrative purposes.

This Profile considers this function to be a local function, destroying only locally stored keys upon request. Destroying keys in remote locations may require special messages that request a key's destruction.

FR:6.38 The CKMS design shall specify how and the circumstances under which keys are intentionally destroyed and whether the destruction is local 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 could have several metadata elements associated with it. The CKMS designer determines which metadata are to be associated with a key and selects the protection mechanism(s) that provide(s) the association. Depending on the sensitivity of a metadata element, the metadata element could require confidentiality protection, integrity protection, and source authentication. The association function uses cryptography or a trusted process to provide these protections.

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 metadata that is associated with a key. Some metadata elements for a key type may be fixed after creation and not modifiable; other metadata elements may by modified by some entities, but not by others. Attempted unauthorized modification of metadata that are associated with a key must be detected, prevented, and should be reported.

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

This function deletes metadata associated with a key. A deletion of the metadata requires the authentication of the requestor and verification of his/her authorization. Metadata elements may be deleted as an entire group, as an individual element, 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 authorized entity to list one or more metadata elements of a key. The authorization of an entity to use a key does not automatically authorize that entity to list the key’s metadata elements. Each metadata element could be assigned with a different set of permissions (e.g., some metadata elements could be prohibited from being listed at all), others could be listed by any user, while still others could be listed by only persons assuming a particular role (e.g., an administrator or auditor).

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

This function involves placing a key and/or metadata in storage outside of a cryptographic module for use during the key’s cryptoperiod without retaining the original copy in the cryptographic module (as opposed to a copy function, where the key resides in two locations). Keys and metadata must be physically or cryptographically protected when stored outside a cryptographic module (see the requirements specified in Section 6.1.2, Section 6.2.1, and [SP 800-57 Part 1]).

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.

The backup of keys and metadata involves copying the keys and/or metadata to a separate medium than is used for the operational storage of keys and from which the keys can be recovered if the original (operational) copy is lost, modified, or otherwise becomes unavailable. The FCKMS, the owner, or a trusted entity could back up keys and metadata.

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 multiparty control requirements are implemented during transport and storage of the backed-up keys and metadata.

Key and/or metadata archiving involves placing a copy of a key and/or metadata in a safe storage facility so that they can be recovered if and when needed. Key and/or metadata archiving includes provisions for moving the key and/or metadata to a new storage medium before the old medium is replaced or becomes unreadable.

An archive should support the FCKMS Security Policy (see Section 4.3) in archive facilities and when moving keys and metadata to and from an archive. Archived keys and/or metadata must be physically or cryptographically protected. Keys used to protect archived keys and/or metadata will have cryptoperiods, and must be replaced when their cryptoperiods expire. Changing an archive key may involve changing to a stronger cryptographic algorithm and archive key, and re-encryption of the archived keys and/or metadata under the new archive key and algorithm.

Maintaining a key and metadata archive could require 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. When the archived keys and/or metadata have been transferred to a new storage medium, the copies on the old storage medium must be destroyed (see [SP 800-88]).

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 or archived. The key and/or metadata must be recovered by an authorized entity (e.g., its owner or a key-recovery agent) following the rules for recovery stated in the FCKMS Security Policy and in accordance with Section 6.1.2 and Section 6.2.1.

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 a shared secret generated by the entities (key agreement). The method of transporting or sharing keys may be either manual (e.g., sent by a 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 of a cryptographic module is used to enter one or more keys and associated metadata into the module in preparation for use by the module. Section 2.10 above requires the use of FIPS-140-validated cryptographic modules and relates the impact-levels of data requiring protection to the [FIPS 140] security levels.

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 of a cryptographic module outputs one or more keys and their associated metadata from the module. The output of keys and metadata could be needed in order to store (outside the cryptographic module), transfer, back up, or archive them. A cryptographic module that serves as a key-generation facility for other FCKMS modules would output keys prior to distribution.

As with key entry, a trusted channel is either required or recommended for key and sensitive data output, depending on the impact-level of the system.

FR:6.60 The CKMS design shall specify how, and the circumstances under which, keys and metadata can be 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 (e.g., Diffie-Hellman key establishment and ECDSA).

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.

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 relying entity's trust anchor⁵ 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). Validation of the certification path provides assurance that the identity of the originating entity, as specified in the certificate, is the owner of the public key in the certificate and is the holder of the corresponding private key. The latter assumes that a trusted certificate authority obtained proof of private-key possession.

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

This function performs a validity check on a symmetric key, e.g., to verify that the length and format are correct. The function could 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 is used by an entity who receives an encrypted symmetric key and who needs assurance that the claimed sender of the key has possession of the plaintext key. This assurance may be obtained by encapsulating the plaintext key in a key package that has sufficient redundancy known by the receiver. The receiver verifies the redundancy after decryption. Alternatively, the sender and receiver may undergo a handshake that provides assurance that the sender possesses the correct key.

This function performs tests on private keys or key pairs to verify that they meet their specifications. Only the private-key owner or a trusted third party acting on behalf of the private-key owner can perform this test.