Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

Overview

Key recovery mechanisms serve many useful purposes. They may be used by individuals to recover lost or corrupted keys; they may be used by enterprises to deter corporate insiders from using encryption to bypass the corporate security policy regarding the flow of proprietary information. Corporations may also use key recovery mechanisms to recover employee keys in certain situations, for example, in the employee's absence. The use of key recovery mechanisms in web based transactional scenarios can serve as an additional technique of non-repudiation and audit, that may be admissible in a court of law. Finally, key recovery mechanisms may be used by jurisdictional law enforcement bodies to access the contents of confidentiality protected communications and stored data. Thus, there appear to be multiple incentives for the incorporation as well as adoption of key-recovery mechanisms in local and distributed encryption based systems.

Key Recovery Nomenclature

Denning and Brandstad [Key Escrow], present a taxonomy of key escrow systems. Here, a different scheme of nomenclature was adopted in order to exhibit some of the finer nuances of key recovery schemes. The term key recovery encompasses mechanisms that allow authorized parties to retrieve the cryptographic keys used for data confidentiality, with the ultimate goal of recovery of encrypted data. The remainder of this section will discuss the various types of key recovery mechanisms, the phases of key recovery, and the policies with respect to key recovery.

Key Recovery Types

There are two classes of key recovery mechanisms based on the way keys are held to enable key recovery:

There may also be hybrid schemes that use some escrow mechanisms in addition to encapsulation mechanisms.

An orthogonal way to classify key recovery mechanisms is based on the nature of the key:

Both types can be escrowed or encapsulated. Since escrow schemes involve the actual archival of keys, they typically deal with long-term keys, in order to avoid the proliferation problem that arises when trying to archive the myriad ephemeral keys. Key encapsulation techniques, on the other hand, usually operate on the ephemeral keys.

For a large class of key recovery (escrow as well as encapsulation) schemes, there are a set of key recovery fields that accompany an enciphered message or file. These key recovery fields may be used by the appropriate authorized parties to recover the decryption key and or the plaintext. Typically, the key recovery fields comprise information regarding the key escrow or recovery agent(s) that can perform the recovery operation; they also contain other pieces of information to enable recovery.

In a key escrow scheme for long-term private keys, the "escrowed" keys are used to recover the ephemeral data confidentiality keys. In such a scheme, the key recovery fields may comprise the identity of the escrow agent(s), identifying information for the escrowed key, and the bulk encryption key wrapped in the recipient's public key (which is part of an escrowed key pair); thus the key recovery fields include the key exchange block in this case. In a key escrow scheme where bulk encryption keys are archived, the key recovery fields may comprise information to identify the escrow agent(s), and the escrowed key for that enciphered message.

In a typical key encapsulation scheme for ephemeral bulk encryption keys, the key recovery fields are distinct from the key exchange block, (if any.) The key recovery fields identify the recovery agent(s), and contain the bulk encryption key encapsulated using the public keys of the recovery agent(s).

The key recovery fields are generated by the party performing the data encryption, and associated with the enciphered data. To ensure the integrity of the key recovery fields, and its association with the encrypted data, it may be required for processing by the party performing the data decryption. The processing mechanism ensures that successful data decryption cannot occur unless the integrity of the key recovery fields are maintained at the receiving end. In schemes where the key recovery fields contain the key exchange block, decryption cannot occur at the receiving end unless the key recovery fields are processed to obtain the decryption key; thus the integrity of the key recovery fields are automatically verified. In schemes where the key recovery fields are separate from the key exchange block, additional processing must be done to ensure that decryption of the ciphertext occurs only after the integrity of the key recovery fields are verified.


Key Recovery Phases


Figure: Key Recovery Phases

The process of cryptographic key recovery involves three major phases. First, there is an optional key recovery registration phase where the parties that desire key recovery perform some initialization operations with the escrow or recovery agents; these operations include obtaining a user public key certificate (for an escrowed key pair) from an escrow agent, or obtaining a public key certificate from a recovery agent . Next, parties that are involved in cryptographic associations have to perform operations to enable key recovery (such as the generation of key recovery fields, and so on)-this is typically called the key recovery enablement phase. Finally, authorized parties that desire to recover the data keys, do so with the help of a recovery server and one or more escrow agents or recovery agents-this is the key recovery request phase.

Key Recovery Phases illustrates the three phases of key recovery. In Key Recovery Phases(a), a key recovery client registers with a recovery agent prior to engaging in cryptographic communication. In Key Recovery Phases(b), two key-recovery-enabled cryptographic applications are communicating using a key encapsulation mechanism; the key recovery fields are passed along with the ciphertext and key exchange block, to enable subsequent key recovery. The key recovery request phase is illustrated in Key Recovery Phases(c), where the key recovery fields are provided as input to the key recovery server along with the authorization credentials of the client requesting service. The key recovery server interacts with one or more local or remote key recovery agents to reconstruct the secret key that can be used to decrypt the ciphertext.

It is envisaged that governments or organizations will operate their own recovery server hosts independently, and that key recovery servers may support a single or multiple key recovery mechanisms. There are a number of important issues specific to the implementation and operation of the key recovery servers, such as vulnerability and liability. The focus of this documentation is a framework-based approach to implementing the key recovery operations pertinent to end parties that use encryption for data confidentiality. The issues with respect to the key recovery server and agents will not be discussed further here.

Lifetime of Key Recovery Fields

Cryptographic products fall into one of two fundamental classes: archived-ciphertext products, and transient-ciphertext products. When the product allows either the generator or the receiver of ciphertext to archive the ciphertext, the product is classified as an archived-ciphertext product. On the other hand, when the product does not allow the generator or receiver of ciphertext to archive the ciphertext, it is classified as a transient-ciphertext product.

It is important to note that the lifetime of key recovery fields should never be greater than the lifetime of the associated ciphertext. This is somewhat obvious, since recovery of the key is only meaningful if the key can be used to recover the plaintext from the ciphertext. Hence, when archived-ciphertext products are key recovery enabled, the key recovery fields are typically archived for the same duration as the ciphertext. Similarly, when transient-ciphertext products are key recovery enabled, the key recovery fields are associated with the ciphertext for the duration of its lifetime. It is not meaningful to archive key recovery fields without archiving the associated ciphertext.

Key Recovery Policy

Key recovery policies are mandatory policies that may be derived from enterprise-based or jurisdiction-based rules on the use of cryptographic products for data confidentiality. Political jurisdictions may choose to define key recovery policies for cryptographic products based on export, import, or use controls. Enterprises may define internal and external domains, and may mandate key recovery policies on the cryptographic products within their own domain.

Key recovery policies come in two flavors: key recovery enablement policies and key recovery inter-operability policies. Key recovery enablement policies specify the exact cryptographic protocol suites (algorithms, modes, key lengths and so on) and perhaps usage scenarios, where key recovery enablement is mandated. Furthermore, these policies may also define the number of bits of the cryptographic key that may be left out of the key recovery enablement operation; this is typically referred to as the workfactor. Key recovery inter-operability policies specify to what degree a key-recovery-enabled cryptographic product is allowed to interoperate with other cryptographic products.

Operational Scenarios for Key Recovery

There are three basic operational scenarios for key recovery:

Enterprise key recovery allows enterprises to enforce stricter monitoring of the use of cryptography, and the recovery of enciphered data when the need arises. The user in this scenario is the enterprise employee. Enterprise key recovery is based on a mandatory key recovery policy; however, this policy is set (typically through administrative means) by the organization or enterprise at the time of installation of a recovery-enabled cryptographic product. The enterprise key recovery policy should not be modifiable or by-passable by the individual using the cryptographic product. Enterprise key recovery mechanisms may use special, enterprise-authorized escrow or recovery agents.

In the law enforcement scenario, key recovery is mandated by the jurisdictional law enforcement authorities in the interest of national security and law enforcement. The user in this scenario is the private citizen in the jurisdiction where the product is being used. For a specific cryptographic product, the key recovery policies for multiple jurisdictions may apply simultaneously. The policies (if any) of the jurisdiction(s) of manufacture of the product, as well as the jurisdiction of installation and use, need to be applied to the product such that the most restrictive combination of the multiple policies is used. Thus, law enforcement key recovery is based on mandatory key recovery policies; these policies are logically bound to the cryptographic product at the time the product is shipped. There may be some mechanism for vendor-controlled updates of such law enforcement key recovery policies in existing products; however, organizations and end users of the product are not able to modify this policy at their discretion. The escrow or recovery agents used for this scenario of key recovery need to be strictly controlled in most cases, to ensure that these agents meet the eligibility criteria for the relevant political jurisdiction where the product is being used.

Individual key recovery is user-discretionary in nature, and is performed for the purpose of recovery of enciphered data by the owner of the data, if the cryptographic keys are lost or corrupted. The user in this scenario is the traditional end-user of the software product. Since this is a non-mandatory key recovery scenario, it is not based on any policy that is enforced by the cryptographic product; rather, the product may allow the user to specify when individual key recovery enablement is to be performed. There are few restrictions on the use of specific escrow or recovery agents.

Key recovery-enabled cryptographic products must be designed so that the key recovery enablement operation is mandatory and noncircumventable in the law enforcement and enterprise scenarios, and discretionary for the individual scenario. The escrow and recovery agent(s) that are used for law enforcement and enterprise scenarios must be tightly controlled. These agents must be validated as as authorized or approved agents. In the law enforcement and enterprise scenarios, the key recovery process typically needs to be performed without the knowledge and cooperation of the parties involved in the cryptographic association.

The components of the key recovery fields also varies somewhat between the three scenarios. In the law enforcement scenario, the key recovery fields must contain identification information for the escrow or recovery agent(s); whereas for the enterprise and individual scenarios, the agent identification information is not so critical, since this information may be available from the context of the recovery enablement operation. For the individual scenario, there needs to be a strong user authentication component in the key recovery fields, to allow the owner of the key recovery fields to authenticate themselves to the agents; however, for the enterprise and law enforcement scenarios, the authorization credentials checked by the agents may be in the form of legal documents, or enterprise-authorization documents for key recovery, that may not be tied to any authentication component in the key recovery fields. For the law enforcement and enterprise scenarios, the key recovery fields may contain recovery information for both the generator and receiver of the enciphered data; in the individual scenario, only the information of the generator of the enciphered data is typically included (at the discretion of the generating party).

Key Recovery in the Common Data Security Architecture

The Common Data Security Architecture (CDSA) defines an open infrastructure for security services. Within the four layer architecture, the Common Security Services Manager (CSSM) is the central layer that manages the range of security service options available to applications. CSSM allows applications to dynamically select:

CSSM acts as a broker between applications requesting security services and dynamically-loadable security service modules. The CSSM application programming interface (CSSM-API) defines the interface for accessing security services. The CSSM service provider interface (CSSM-SPI) defines the interface for service providers who develop plug-able security service products.

CSSM is extensible in that it also provides dynamic loading of module managers that provide elective categories of security services. Key recovery is an important security service for applications and institutions that choose to use it. CSSM accommodates key recovery as an elective category of security service.

A complete architectural description of CDSA and CSSM is contained in the Common Data Security Architecture (CDSA) Specification.


Click here to return to the publication details.

Contents Next section Index