Previous section.

Common Security: CDSA and CSSM, Version 2 (with corrigenda)
Copyright © 2000 The Open Group

Overview

Introduction

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.

The function calls that perform the Registration, Enablement, and Request, functions identified in Key Recovery Phases are summarized in Summary of Interface Calls, and defined later in Key Recovery Interfaces.

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.

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.

Contents Next section Index