TO: TACDFIPSFKMI Members DATE: 01 OCT 97 I apologize for being late (one day late as I write this) with this document. I want you to know that the members of Working Group 1 (aka Frameworks) submitted their input in sufficient time to put this together and get it out on time. It was my travel schedule that prevented us from meeting the target date and prevented me from completing the final tasks listed below. Roger French 1.1 OVERVIEW Overview Below is version 2.0 of the Overview and it is for review by the TACDFIPSFKMI. It represents the changes I thought were appropriate after reviewing the NIST comments, Santosh's mark-up, and the notes I took, and can barely read, at the Seattle meeting. Please review this before the Orlando meeting in less than two weeks.. NOTE: I have to add something about Interoperability to the Overview, but have not done that yet. Also note that the paragraph on supporting components will need to be changed to align with the whatever components are described in section 1.3. The Federal Government has a right and a responsibility to protect the information and data contained in, processed by, and transmitted between its IT systems. Ownership of the information is often shared with individuals, companies, and organizations and therefore requires that the government protect that information on its own behalf and on behalf of those co-owners. That protection needs to be meet Federal Government standards and the standards of those co-owners. Protection of information on IT systems is complicated and evolving. One aspect of such protection is the requirement that certain information or information in specific states provide its own protection. An example of such a state is information in transit on the Internet. The method of such self protection is encryption, the process whereby the information is scrambled using methods which make it easy for authorized entities to decrypt and difficult for all others to decrypt. When sufficient strength and protection of the decryption key is provided, encryption can adequately protect the information from disclosure to unauthorized parties. However, the unavailability, loss, or corruption of those keys will also prevent disclosure to authorized parties. The solution to this problem is to provide a method of recovering decryption keys by authorized parties. The generation, storage, and recovery of decryption keys is a complex process. This process needs to be rigidly defined, stringently implemented, and conscientiously managed and operated. Such requirements are needed to ensure that the process provides its proposed benefit and prevents an inappropriate increase in vulnerability. The FIPS addresses those aspects of the encryption process, the recovery process, and the supporting components of both processes. The encryption process described in the FIPS includes their components, their actions and interfaces, and the sum of their interactions. Such components include the Encrypting Party (often the Sender for transmitted data,) the Encrypted Data Medium, the Decrypting Party (often the Receiver for transmitted data,) the Recovery Data Medium, and the Key Recovery Agent. It should be noted that the preparation of recovery information is the responsibility of the encryption process, not the recovery process. The recovery process described in the FIPS includes processes and requirements for recovery requesters; structure, process and requirements including performance of the key recovery agents; and a description of the interactions between the parties involved in the recovery. The supporting components described in the FIPS are integral parts of the key recovery process, and are needed to ensure the functionality of the key recovery process and the security of the keys. Such supporting components include the vendor products for the users, for the key recovery agents, and for the requesters. They also include the registration agent or process, the methods to authenticate the key sources, licensing agents, and system policy authorities. To further the understanding of the overall key recovery process, examples will be presented to describe general key recovery methods. Such examples include Stored Files, Encrypted Email, Real-time Communications, and the recovery of a specific key. NOTE: It should be noted that the output of the TACDFIPSFKMI (TAC) is technical advice to the Secretary of Commerce regarding the technology of and technical use of key recovery. The TAC has not addressed and will not provide policy advice regarding the extent of usage of key recovery on any IT systems nor the scope of systems covered by the proposed FIPS. For Your Consideration: "It is not the purpose of the FIPS to make existing systems that do not interoperate, interoperate now with Key Recovery." Does a statement like that belong in the FIPS. If so, is it enough to state it early, perhaps in the overview. The Overview, and perhaps other parts of Section 1.0, need It is the intent of the FIPS that Key Recovery shouild not effect the interoperability of systems, protocols, or applications. Any entities that interoperate without Key Recovery should, if possible, interoperate with it. The exception is when either the Key Recovery systems technical structure requires less or no interaction or when the application and its usage either require no interoperation or when such interoperation will preclude a specific requirement or capability of the system or of the implementation. 1.2 Key Recovery System A key recovery system enables authorized persons to access plaintext from encrypted data when the decryption key is not otherwise available. Key recovery is a broad term that applies to many different techniques. The key recovery system model defines the minimal set of system components needed to perform key recovery. The key recovery system model is a generalized model, which supports a wide variety of different key recovery techniques and data applications. The data applications supported by the key recovery system model include: * Interactive communication sessions. * Store-and-Forward applications. * Data Storage. The key recovery system model contains the following components: * System A (Encryption-Enabled) * System B (Encryption-Enabled) * Encrypted Data Medium * Recovery Information Medium * Requester * Key Recovery Agent(s) The model depicts a key recovery system capable of encrypting data, creating key recovery information -- for the key to be recovered -- and recovering the key from the key recovery information, for an authorized request. 1.2.1 Encryption and Enablement Process The four components -- System A, System B, Encrypted Data Medium, and Recovery Information Medium -- collectively define a subset of the model called the "Encryption and Enablement Process." The process of encrypting data and creating key recovery information is performed by one or more encryption-enabled systems, denoted in the key recovery system model as System A and System B. An encryption-enabled system is one that can communicate using cryptography, i.e., it can encrypt and decrypt data. It is assumed that System A or System B or both Systems A and B have the capability to create key recovery information. However, the key recovery system model does not prescribe which system or systems must have a key recovery capability. The encrypted data and key recovery information produced by these systems are maintained on some appropriate medium, denoted in the key recovery system model as the Encrypted Data Medium and Recovery Information Medium, respectively. The Recovery Information Medium may be the same or different from the Encrypted Data Medium. 1.2.1.1 Components and Their Interactions 1.2.1.1.1 Systems A & B Systems A and B are systems capable of communicating with each other using cryptography (i.e., they are encryption-enabled). Each system contains a cryptographic application capable of interacting with a like cryptographic application in the other system. Each system contains a cryptographic subsystem that provides a set of cryptographic services to the cryptographic application. At least one system (A or B) must have a key recovery subsystem capable of providing a set of key recovery services to the cryptographic application which, at a minimum, includes services for creating key recovery information. It is also possible for one system (A or B) to implement a set of key recovery services capable of "handling" the key recovery information provided by another system, but has no capability to create key recovery information by itself. A system that meets this minimal requirement is said to be key recovery aware. Thus, the standard assumes that two systems can interoperate in compliance with the standard as long as both systems are key recovery aware and at least one of the systems is capable ! of creating key recovery information. NOTE: In situations where it is convenient to show a directional flow of the encrypted data, System A may be optionally labeled "Sender" or "Encryptor" and System B may be optionally labeled "Receiver" or "Decryptor." However, the key recovery system model itself is intended to be a generalized model, covering interactive sessions, where each system may be both a sender and receiver. 1.2.1.1.1.1 Sender The Sender is the system that encrypts data, either for storage or for transmission to a Receiver. The Sender may or may not create key recovery information. Typically, the Sender will create key recovery information (i.e., enable key recovery) in order to comply with an established key recovery policy. The key recovery policy specifies the conditions under which key recovery information must be created; the policy may also indicate the allowable key recovery agents, and how and where the key recovery information must be maintained (stored or transmitted). However, the Sender may elect to create key recovery information in situations where key recovery is deemed desirable, although not specifically required by the Sender's key recovery policy. The Sender may also create key recovery information for the Receiver, in situations where the Receiver is incapable of creating its own key recovery information. If key recovery is not required by the key recovery policy and the Sender does not desire key recovery, then no key recovery information will be created. 1.2.1.1.1.2 Receiver The Receiver is the system that receives encrypted data and decrypts its. The Receiver may or may not create key recovery information. Typically, the Receiver will create key recovery information in order to comply with an established key recovery policy (see also 1.2.1.1.1.1 Sender). However, the Receiver may elect to create key recovery information in situations where key recovery is deemed desirable, although not specifically required by the Receiver's key recovery policy. The Receiver may also create key recovery information for the Sender, in situations where the Sender is incapable of creating its own key recovery information. If key recovery is not required by the key recovery policy and the Receiver does not desire key recovery, then no key recovery information will be created. In situations where key recovery information is received from the Sender, the Receiver may perform a verification step to validate the correctness or integrity of the key recovery information. The verification step could consist of checking all or part of the received key recovery information, or any other information that could be used beneficially to determine the correctness or integrity of the received key recovery information. In situations where the Receiver creates key recovery information for the Sender, the Sender may receive the key recovery information and perform a simiilar verification step to validate the correctness or integrity of the key recovery information. 1.2.1.1.2 Encrypted Data Medium The encrypted data medium represents the "location" where the encrypted data is stored or communicated, such as a storage device or communications channel. The key recovery system model does not prescribe how or where the encrypted data must be stored or communicated, as long as it can be accessed by an authorized Requester. The key recovery system model assumes that both systems (A and B) can access to the Encrypted Data Medium. 1.2.1.1.3 Recovery Information Medium The recovery information medium represents the "location" where the recovery information is stored or communicated, such as a storage device or a communications channel. The key recovery system model does not prescribe how or where the recovery information must be stored or communicated, as long as it can be accessed by an authorized Requester. The recovery information itself can be managed or handled in a variety of ways. It may exist for only a brief time, during electronic transmission, or it may exist for a relatively long time, on a storage device. The key recovery system model assumes that both systems (A and B) are able, where needed or desired, to access the Recovery Information Medium. 1.2.1.2 Interaction Summary Both systems (A and B) have access to the Encrypted Data Medium. Thus, the key recovery system model simultaneously embraces the following three separate applications: (a) interactive session, (b) store-and-forward, e.g., E-mail, and (c) file storage. Both systems (A and B) are able to access the Recovery Information Medium. Thus, the key recovery system model embraces key recovery systems where one or both systems have the capability to create recovery information and one or both systems can make that recovery information available by putting it on a Recovery Information Medium. The model also embraces key recovery systems where one or both systems have access to the recovery information created by the other system, thus allowing each system to potentially validate the recovery information created by the other system in order to ensure that it is authentic. In a typical interaction scenario, System A (acting as a sender) encrypts an e- mail message and sends it to System B (acting as a receiver). In this case, the Encrypted Data Medium is a communications path. System A also creates key recovery information, which is appended to the encrypted message in the form of a message header. In this case, the Recovery Information Medium is also the same communications path used to transmit the encrypted data, i.e., the Encrypted Data Medium and the Recovery Information Medium are one and the same. Upon receipt of the encrypted message, System B validates the recovery information and decrypts the message. 1.2.2 Recovery Process The Requester and the Key Recovery Agents form another subportion of the key recovery system model called the "Recovery Process." The process of recovering a key from the key recovery information is handled by additional key recovery system components -- denoted in the key recovery system model as Requester and Key Recovery Agents. An authorized Requester -- with access to the Encrypted Data Medium and the Recovery Information Medium -- interacts with one or more Key Recovery Agents to recover the cryptographic key from the key recovery information. A recovered key can then be used to recover the data, either directly or indirectly. The data encrypting key is said to be recovered directly when the recovered key is the same key that was used to encrypt the data. Indirect key recovery occurs when the recovered key is a key encrypting key which is then used to decrypt or recover the data encrypting key. 1.2.2.1 Components and Their Interactions 1.2.2.1.1 Requester The Requester is an entity who seeks to recover information that will allow the decryption of encrypted data. To this end, the Requester always performs the step of key recovery; the step of data recovery is optional. The Requester is defined as the entity who interacts with one or more Key Recovery Agents -- using key recovery information -- to recover a key. Many different algorithms and procedures can be used to recover a key. For example, the Requester might interact with one Key Recovery Agent to recover a whole key, or the Requester might interact with two or more Key Recovery Agents to recover several pieces of information that, in turn, permit the Requester to recover or reconstruct the whole key. The Requester must always have access to the recovery information corresponding to the (desired) key to be recovered. However, the Requester will need access to the encrypted data only if it performs the additional step of data recovery. A request for a key recovery service, made by a Requester to a Key Recovery Agent, must be an authorized request. In other words, the Requester issuing a request for key recovery service must have a legal and lawful right to access the data, in whole or in part, that can be decrypted, either directly or indirectly, using the key which is recovered from the given set of key recovery information. Furthermore, the Requester must prove its right to access that data. Those with the right to access the data "unlocked" by a given set of key recovery information would include the individual or enterprise that "owns" the data, and any person or party with a lawful right to access the data, e.g., law enforcement acting under the authority of a valid warrant or court order, or an agent acting under the authority of another party with a right-of-access to the data. NOTE: The functions performed by a Requester may be separated and performed by two or more components, if doing so would be advantageous. For example, it may be more cost effective for an individual or enterprise to employ the services of a trusted third party who assumes the role of the Requester on behalf of the individual or enterprise. Under such an arrangement, the Requester could recover the key, which in turn would be provided to the individual or enterprise, and the individual or enterprise could then recover the data using the recovered key. 1.2.2.1.2 Key Recovery Agent The Key Recovery Agent is a trusted entity who performs a recovery service in response to an authorized request made by a Requester. Before honoring such a request, the Key Recovery Agent authenticates the Requester's right to receive the requested recovery service. The recovery service consists of processing all or part of the recovery information provided by the Requester to the Key Recovery Agent, and returning an output value to the Requester. The algorithm for processing the recovery information is dependent on the algorithm originally used to create the recovery information, i.e. it is algorithm specific. There are also many algorithms for creating and processing the recovery information. For example, the output value calculated by the Key Recovery Agent could be a whole key, or it could be a key part or piece of information that the Requester will use in combination with other recovered parts or pieces of information to reconstruct or recover the whole key. Note: The present standard does not prescribe a particular algorithm or method for creating and processing the recovery information, or for recovering or reconstructing the key. NOTE: It is assumed that, where necessary, the components in the key recovery system model can make use of cryptography to protect the secrecy and integrity of the information transmitted from one component to another. 1.2.2.2 Interaction Summary In a typical key recovery scenario, the Requester -- who is provided with, or who acquires, a set of key recovery information, and who can "prove" its right to access the data "unlocked" by the key to be recovered from that key recovery information -- sends a request for key recovery service to one or more Key Recovery Agents. With each such request, the Requester provides an appropriate portion of the recovery information to each Key Recovery Agent, which may be all or part of the key recovery information. Before processing the key recovery service request, the Key Recovery Agent authenticates the Requester's right to receive the requested key recovery service. Each Key Recovery Agent processes its respective portion of the recovery information and constructs an output value, which is returned to the Requester. If only one Key Recovery Agent is involved, the output value could be the whole key, and the Requester is finished. On the other hand, two or more Key Recovery Agents could provide key parts or pieces of information that the Requester would use to reconstruct or recover the whole key. If the Requester is a third party who performs a key recovery service on behalf of some other person or party, then the Requester returns the recovered key to that person or party. However, if the Requester has also been engaged to perform a data recovery service, the Requester -- who is provided the encrypted data -- will decrypt the provided encrypted data with the aid of the recovered key and return the recovered data to the person or party. 1.3 Supporting Components Specific implementations of the Key Recovery System model may require "supporting" components to support the interactions between the main Key Recovery System components. This section describes these supporting components and provides example of how they may be used in a Key Recovery System. Product Vendors End User Product Vendors, Key Recovery Agent Product vendors, and Requester Product Vendors produce products for use in the Key Recovery System, and provide information to the Registration Agent as necessary. Registration Agent The Registration Agent receives and archives vendor-specific information required by the Requester to find, acquire, and parse recovery information obtained from the recovery information medium. Recovery information may include the following: (1) product serial number, (2) vendor identification number, (3) recovery fields, (4) certificates, and (5) session information. Authentic Public Key Source In some implementations, an Authentic Public Key Source will be used to provide a certificate infrastructure to support the use of public key cryptography within the Key Recovery System. In a Key Recovery System which provides Private Key Escrow-based recovery, the Authentic Public Key Source may be very similar to a conventional Certificate Authority, but will provide for the binding of properly escrowed public keys to users. In a Key Recovery System based on Key Encapsulation, the Authentic Public Key Source may instead bind public keys to legitimate Key Recovery Agents. Licensing Agent The Licensing Agent is responsible for evaluating and authorizing Key Recovery Agents. Key Recovery System Implementation Examples The following two sections describe two possible types of implementations for the Key Recovery System which require the use of supporting components. Neither example purports to be the only method of satisfying this standard-- instead these examples are intended to illustrate how these supporting components fit into a Key Recovery System implementation. Private Key Escrow Example The core of a Private Key Escrow-based Key Recovery System is the escrow of System A and System B's public/private key exchange keypairs with the Key Recovery Agent(s). This example discusses component interactions for three phases: establishment, normal operation, and recovery. Establishment First, the Key Recovery System's Authentic Public Key Source must generate and securely maintain a public/private keypair. The public portion of this keypair will be embedded or loaded into Key Recovery System components. The private portion of the keypair will be used to digitally sign component information to authorize their use in the Key Recovery System. To establish a Private Key Escrow-based Key Recovery System, End User Product Vendors must describe to the Registration Agent how their systems (A and B) deposit the key exchange field into the Encrypted Data Medium and the Recovery Information Medium. End User Product Vendors must also embed the Authentic Public Key Source root public key into their systems (A and B) to enable authentication of interactions with other Key Recovery System components. Key Recovery Agent Product Vendors must also embed the Authentic Public Key Source root public key into the Key Recovery Agent Product. Key Recovery Agents must demonstrate to the Licensing Agent that they will secure escrowed user private keys in accordance with the Key Recovery System policy. Once approved, the Key Recovery Agent will be authorized via the Authentic Public Key Source. This authorization will allow systems (A and B) and Requesters to verify the legitimacy of a Key Recovery Agent. Systems (A and B) must securely escrow their public/private key exchange keypair with a Key Recovery Agent prior to participating in the Key Recovery System. Systems (A and B) can verify that they are communicating with a legitimate Key Recovery Agent by verifying the Key Recovery Agent information using the Authentic Public Key Source. The Key Recovery Agent will then issue a certificate to the System (A and B) verifying that the public/private keypair was successfully escrowed. Normal Operation System A provides for key recovery whenever it performs a key exchange with System B provided System B's public/private keypair is escrowed with a Key Recovery Agent. System A can determine if System B's public/private keypair was escrowed by verifying System B's certificate (using the Authentic Public Key Source root public key embedded in the product). During key exchange, System A deposits the key exchange field and key recovery information into the Recovery Information Medium. The encrypted data to be communicated to System B is deposited into the Encrypted Data Medium. Recovery A properly authorized Requester may recover the encryption key by first retrieving information from the Registration Agent on how the key recovery information has been deposited in the Recovery Information Medium. The Requester then retrieves the key recovery information from the Recovery Information Medium to determine the Key Recovery Agent. Next, the Requester retrieves the key exchange field and sends it to the Key Recovery Agent. The Key Recovery Agent verifies the authenticity of the request, decrypts the key exchange field using the user's escrowed private key, and securely returns the unwrapped encryption key to the Requester. The Requester uses the recovered encryption key to decrypt the encrypted data which was gathered from the Encrypted Data Medium. Key Encapsulation Example The core of a Key Encapsulation-based Key Recovery System is the encapsulation of the encryption key using the public key of a legitimate Key Recovery Agent(s). This example discusses component interactions for three phases: establishment, normal operation, and recovery. Establishment First, the Key Recovery System's Authentic Public Key Source must generate and securely maintain a public/private keypair. The public portion of this keypair will be embedded or loaded into Key Recovery System components. The private portion of the keypair will be used to digitally sign component information to authorize their use in the Key Recovery System. To establish a Private Key Escrow-based Key Recovery System, End User Product Vendors must describe to the Registration Agent how their systems (A and B) deposit the key exchange field into the Recovery Information Medium. End User Product Vendors must also embed the Authentic Public Key Source root public key into their systems (A and B) to enable authentication of interactions with other Key Recovery System components. Key Recovery Agent Product Vendors must also embed the Authentic Public Key Source root public key into the Key Recovery Agent Product. Key Recovery Agents must demonstrate to the Licensing Agent that they will secure their private keys in accordance with the Key Recovery System policy. Once approved, the Key Recovery Agent will be authorized via the Authentic Public Key Source. This authorization will allow systems (A and B) and Requesters to verify the legitimacy of a Key Recovery Agent. Systems (A and B) must load a public key from the Key Recovery Agent prior to participating in the Key Recovery System. The Key Recovery Agent issues a certificate to the System (A and B) verifying that the public/private keypair is secured and maintained by the Key Recovery Agent. Normal Operation System A provides for key recovery whenever it performs a key exchange by encapsulating the encryption key in the public key(s) provided by the Key Recovery Agent(s) and depositing the resulting key recovery field(s) into the Recovery Information Medium. System B can determine if System A has properly provided for key recovery by verifying the integrity of the key recovery field. The encrypted data to be communicated to System B is deposited into the Encrypted Data Medium. Recovery A properly authorized Requester may recover the encryption key by first retrieving information from the Registration Agent on how the key recovery information has been deposited in the Recovery Information Medium. The Requester then retrieves the key recovery information from the Recovery Information Medium to determine the Key Recovery Agent. Next, the Requester retrieves the key recovery field and sends it to the Key Recovery Agent. The Key Recovery Agent verifies the authenticity of the request, decrypts the key recovery field using the corresponding private key, and securely returns the recovered encryption key to the Requester. The Requester uses the recovered encryption key to decrypt the encrypted data which was gathered from the Encrypted Data Medium. 1.4 SYSTEM POLICY 1.4 A Cryptographic Key Recovery System shall provide a policy establishment mechanism that enables an appropriately designated administrator to implement system policy. Each installed instance of a CKRS should reference a system policy, but the system policy may vary from instance to instance. At a minimum, the system policy shall define each of the following. 1.4.1 Affected data types. 1.4.1.1 The system policy shall define whether or not stored data is to be made available for recovery. 1.4.1.2 The system policy shall define whether or not electronic mail is to made available for recovery. 1.4.1.3 The system policy shall define whether or not real-time communications are to be made available for recovery. 1.4.2 Access policy. 1.4.2.1 For each affected data type for which recovery has been selected, the system policy shall define the recovery mechanism to be used, i.e. precisely how the key recovery is to be done - particularly when a variety of key recovery options are available. 1.4.2.2 For each affected data type for which recovery has been selected, the system policy shall define what recovery agent or agents shall be used. 1.4.2.3 For each recovery agent selected, the system policy shall define what requestors may recover the data. 1.4.2.4 For each requestor selected, the system policy shall define the conditions under which each recovery agent shall make the data available to the requestor. 1.4.2.5 For each recovery agent and affected data type, the system policy shall define what measures are to be taken by the recovery agent to prevent destruction of the data. 1.4.3 Data integrity policy. 1.4.3.1 For each recovery agent and affected data type, the system policy shall define the requirements for maintaining integrity of the data. 1.4.3.2 For each recovery agent and affected data type, the system policy shall define whether a cryptographic "proof" of data integrity shall be required (perhaps utilizing digital signature) and, if so, a security confidence level for this "proof" (e.g. bit length). 1.4.3.3 For each recovery agent and affected data type, the system policy shall define what (if any) measures are required to provide "proof" (perhaps utilizing digital signatures verifiable by a third party) of the source of the recovered data. 1.4.3.4 For each recovery agent and affected data type, the system policy shall define the auditing procedures to be followed by the recovery agent. 1.4.4 Interoperability policy. 1.4.4.1 For each affected data type, the system policy shall define what (if any) interoperability restrictions are to be placed on the system. 1.4.4.2 For each affected data type, the system policy shall define what (if any) interoperability conditions require a warning to the user.