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

Key Recovery Enablement in CSSM

Elective Key Recovery Services in the CSSM shows the Key Recovery Module Manager (KRMM) as an elective service in CSSM. The KRMM defines a key recovery API (KR-API) on top and a key recovery SPI (KR-SPI) below. One or more Key Recovery Service Providers may be plugged-in under the KRMM. The KRMM manages these dynamic service modules and brokers their use by applications and layered security-aware services, such as SSL (Secure Sockets Layer) and SMIME (Secure MIME).

Figure: Elective Key Recovery Services in the CSSM

Functionality Definition

CDSA defines the expected functions for each layer of the four layer architecture. Processes, such as protocol handlers, in the security services layer that use key recovery services are assumed to perform the following functions with respect to key recovery:

Determination of key recovery mechanism (perhaps through negotiation with peer) and selection of an appropriate key recovery service provider
Identification of the peers in the cryptographic association
Set up and update of key recovery parameters for the peers in the cryptographic association
Invocation of the key recovery field generation function and associating the generated fields with the ciphertext
Retrieval of the key recovery fields from the protocol message or file and invocation of the key recovery field processing function
Understanding the semantics of the opaque input parameters for the key recovery registration and recovery request operations
Providing callbacks to allow the KRSP to dynamically obtain additional input from the application layer code, and interact with the human interface, if necessary

The KRMM in the CSSM layer performs the following functions with respect to key recovery:

Storing and fetching user key recovery parameters from a persistent repository
Maintaining key recovery context or state information
Determination of when key recovery fields need to be generated or processed
Invocation of the KR-SPI with appropriate parameters when key recovery operations are invoked

The Key Recovery Service Provider performs the following functions with respect to key recovery:

Validation of any and all recovery agent certificates by selection of appropriate certificate library and trust policy service providers
Choosing an appropriate CSP to use as a cryptographic engine for key recovery field generation
Generation of the key recovery fields
Processing of the key recovery fields
Exchanging messages with a possibly remote key recovery agent/server for recovery registration and request operations
Invocation of supplied callbacks to obtain additional input information, as necessary
Maintaining state about asynchronous recovery registration and request operations to allow the application layer code to check (by polling) if the results of a registration or request operation are available

Extensions to the Cryptographic Module Manager

The Cryptographic Module Manager of the CSSM is responsible for handling the cryptographic functions of the CSSM. In order to introduce the necessary dependencies between the cryptographic operations and the key recovery enablement operations, the cryptographic module manager is extended with conditional behavior as specified below.

The cryptographic context data structure, which holds the many parameters that must be specified as input to a cryptographic function, has been augmented to include the following key recovery extension fields:

An enterprise usability flag for key recovery
A law enforcement usability flag for key recovery
A workfactor field for law enforcement key recovery

The two flag parameters denote whether a cryptographic context needs to have key recovery enablement operations performed before it can be used for cryptographic operations such as encrypt or decrypt. The workfactor field holds the allowable workfactor value for law enforcement key recovery. These three additional fields of the cryptographic context are not available through the CSSM-API for modification. They are set by the KRMM when the latter makes the key recovery policy enforcement decision for enterprise and law enforcement policies.

Although the CSSM API has been left intact in the CSSM, the behavior of some of the cryptographic functions will change due to intervention of the KRMM and the cryptographic module manager, which sits between the caller and the service provider module. Behavioral changes in the cryptographic module manager are based on whether the KRMM is present in the system and the values stored in the cryptographic context extensions. The conditional behavior is as follows:

Invoke key recovery policy enforcement functions for cryptographic context creation and update operations
Flag cryptographic context as unusable if key recovery enablement operations are mandated
Check cryptographic context usability flags for encrypt/decrypt operations

Whenever a cryptographic context is created or updated using the CSSM API and the KRMM is present in CSSM, the cryptographic module manager invokes a KRMM policy enforcement function module. The KRMM checks the enterprise and law enforcement policies to determine whether the cryptographic context defines an operation where key recovery is mandated. If so, the key recovery flags are set in the cryptographic context data structure to signify that the context is unusable until key recovery enablement operations are performed on this context. When the appropriate key recovery enablement operations are performed on this context, the flag values are toggled so that the cryptographic context becomes usable for the intended operations.

When the encryption/decryption operations are invoked through the CSSM-API and the KRMM is present in CSSM, the cryptographic module manager checks the key recovery usability flags in the cryptographic context to determine whether the context is usable for encryption/decryption operations. If the context is flagged as unusable, the cryptographic module manager does not dispatch the call to the CSP and returns an error to the caller. When the appropriate key recovery enablement operations are performed on that context, the KRMM resets the context flags making that context usable for encryption/decryption.

Key Recovery Module Manager

The Key Recovery Module Manager is responsible for handling the KR-API functions and invocation of the appropriate KR-SPI functions. The KRMM enforces the key recovery policy on all cryptographic operations that are obtained through the CSSM. It maintains key recovery state in the form of key recovery contexts.

Operational Scenarios

The CSSM architecture supports three distinct operational scenarios for key recovery, namely, key recovery for law enforcement purposes, enterprise purposes, and individual purposes. The law enforcement and enterprise scenarios for key recovery are mandatory in nature, thus the CSSM layer code enforces the key recovery policy with respect to these scenarios through the appropriate sequencing of KR-API and cryptographic API calls. On the other hand, the individual scenario for key recovery is completely discretionary, and is not enforced by the CSSM layer code. The application/user requests key recovery operations using the KR-APIs at their discretion.

CSSM allows authorized applications to request and be granted exemption from built-in policy checks performed by CSSM module managers such as the KRMM. Applications with appropriate credentials can request exemption from the key recovery checks defined for the enterprise, for law enforcement, or for both. Exemption is granted if the caller provides credentials that:

Are successfully authenticated by CSSM
Carry implied authorization for the requested exemptions

Key Recovery Profiles

The KRSPs require certain pieces of information related to the parties involved in a cryptographic association in order to generate and process key recovery fields. These pieces of information (such as the public key certificates of the key recovery agents) are contained in key recovery profiles. A key recovery profile contains all of the per-user parameters for key recovery field generation and processing for a specific KRSP. In other words, each user has a distinct profile for each KRSP.

The information contained in the profile comprises the following:

A user identity
The public key certificate chain for the user
A set of Key Recovery Agent (KRA) certificate chains for enterprise key recovery
A set of Key Recovery Agent (KRA) certificate chains for law enforcement key recovery
An authentication information field for enterprise key recovery
A set of Key Recovery Agent (KRA) certificate chains for individual key recovery
An authentication information field for individual key recovery
A set of key recovery flags that fine tune the behavior of a KRSP
An extension field

The key recovery profiles support a list of KRA certificate chains for each of the law enforcement, enterprise, and individual key recovery scenarios, respectively. While the profile allows full certificate chains to be specified for the KRAs, it also supports the specification of leaf certificates; in such instances, the KRSP and the appropriate TP modules are expected to dynamically discover the intermediate certificate authority certificates up to the root certificate of trust. One or more of these certificate chains may be set to NULL, if they are not needed or supported by the KRSP involved.

The user public key certificate chain is also part of a profile. This is a necessary parameter for certain key escrow and encapsulation schemes. Similarly certain schemes support the notion of an authentication field for enterprise as well as individual key recovery. This field is used by the key recovery server and/or agent(s) to verify the authorization of the individual/enterprise requesting key. One or more fields can be set to NULL, if their use is not required or supported by the KRSP involved.

The key recovery flags are defined values that are pertinent for a large class of escrow and recovery schemes. The extension field is for use by the KRSPs to define additional semantics for the key recovery profile. These extensions may be flag parameters or value parameters. The semantics of these extensions are defined by a KRSP; the application that uses profile extensions has to be cognizant of the specific extensions for a particular KRSP. However, it is envisioned that these extensions will be for optional use only. KRSPs are expected to have reasonable defaults for all such extensions; this is to ensure that applications do not need to be aware of specific KRSP profile extensions in order to get basic key recovery enablement services from a KRSP. Whenever the extensions field is set to NULL, the defaults should be used by a KRSP.

Key Recovery Context

All operations performed by the KRSPs are performed within a key recovery context. A key recovery context is programmatically equivalent to a cryptographic context; however the attributes of a key recovery context are different from those of other cryptographic contexts. There are three kinds of key recovery contexts- registration contexts, enablement contexts and recovery request contexts. A key recovery context contains state information that is necessary to perform key recovery operations. When the KR-API functions are invoked by application layer code, the KRMM passes the appropriate key recovery context to the KRSP using the KR-SPI function parameters.

A key recovery registration context contains no special attributes. A key recovery enablement context maintains information about the profiles of the local and remote parties for a cryptographic association. When the KR-API function to create a key recovery enablement context is invoked, the key recovery profiles for the specified communicating peers are specified by the application layer code using the API parameters. A key recovery request context maintains a set of key recovery fields, which are being used to perform a recovery request operation, and a set of flags that denotes the operational scenario of the recovery request operation. Since the establishment of a context implies the maintaining of state information within the CSSM, contexts acquired should be released as soon as their need is over.

Key Recovery Policy

The CSSM enforces the applicable key recovery policy on all cryptographic operations. There are two key recovery policies enforced by the CSSM, a law enforcement (LE) key recovery policy, and the enterprise (ENT) key recovery policy. Since the requirements for these two mandatory key recovery scenarios are somewhat different, they are implemented by different mechanisms within the CSSM.

The law enforcement key recovery policy is predefined (based on the political jurisdictions of manufacture and use of the cryptographic product) for a given product. The parameters on which the policy decision is made are predefined as well. Thus, the LE key recovery policy is implemented using a key recovery policy table and a key recovery policy enforcement function, both of which are used by the CSSM in making a key recovery policy decision. The LE policy table is implemented as a separate physical file for ease of implementation and upgrade (as law enforcement policies evolve over time); however, this file is protected using the same integrity mechanisms as the CSSM module.

The ENT key recovery policy, could vary anywhere between being set to NULL, and being very complex (for example, based on parameters such as time of day.) Enterprises are allowed total flexibility with respect to the enterprise key recovery policy. The enterprise policy is implemented within the CSSM by invoking a key recovery policy function that is defined by the enterprise administrator. The KR-API provides a function that allows an administrator to specify the name of a file that contains the enterprise key recovery policy function. The first time this function is used, the administrator can establish a passphrase for all subsequent calls on this function. This mechanism assures a level of access control on the enterprise policy, once a policy function has been established. It goes without saying that the file containing the policy function should be protected using the maximal possible protection afforded by the operating system platform. The actual structure of the policy function file is operating system platform-specific.

Every time a cryptographic context handle is returned to application layer code, the CSSM enforces the LE and ENT key recovery policies. For the LE policy, the CSSM policy enforcement function and the LE policy table are used. For the ENT policy, the ENT policy function file is invoked in an operating system platform-specific way. If the policy check determines that key recovery enablement is required for either LE or ENT scenarios, then the context is flagged as unusable, otherwise, the context is flagged as usable. An unusable context handle becomes flagged as usable only after the appropriate key recovery enablement operation is completed using that context handle. A usable context handle can then be used to perform cryptographic operations.

Key Recovery Enablement Operations

The CSSM key recovery enablement operations comprise the generation and processing of key recovery fields. Within a cryptographic association, key recovery field generation is performed by the sending side; key recovery field processing is performed on the receiving side to ensure that the integrity of the recovery fields have been maintained in transmission between the sending and receiving sides. These two vital operations are performed via the CSSM_KR_GenerateRecoveryFields() and the CSSM_KR_ProcessRecoveryFields() functions, respectively. These functions are covered summarily in a subsequent section of this chapter.

The key recovery fields generated by the CSSM potentially comprise three sub-fields, for law enforcement, enterprise, and individual key recovery scenarios, respectively. The law enforcement and enterprise key recovery sub-fields are generated when the law enforcement and enterprise usability flags are appropriately set in the cryptographic context used to generate the key recovery fields. When an application invokes the API function to generate the key recovery fields, a certain flag value is set indicating the fields have been generated. The processing of the key recovery fields only applies to the law enforcement and enterprise key recovery sub-fields; the individual key recovery sub-fields are ignored by the key recovery fields processing function.

Key Recovery Registration and Request Operations

The CSSM also supports the operations of registration and recovery requests. The KRSP exchanges messages with the appropriate key recovery agent/server to obtain the results required. If additional inputs are required for the completion of the operation, the supplied callback may be used by the KRSP. The recovery request operation can be used to request a batch of recoverable keys . The result of the registration operation is a key recovery profile data structure, while the results of a recovery request operation are a set of recovered keys.

Click here to return to the publication details.

Contents

Next section

Index