The KRMM in the CSSM layer performs the following functions with respect to key recovery:
The Key Recovery Service Provider performs the following functions with respect to key recovery:
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:
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:
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.
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:
Applications use a CSSM_EXEMPTION_MASK to represents a set of requested exemptions. The Key Recovery Module Manager defines the following exemption request flags in addition to those already defined by CSSM and by other elective module managers:
The CSSM_RequestCssmExemption function is used to request exemptions. Applications can invoke this function at any time after invoking the CSSM_Init function. This allows applications to change exemption status as appropriate during execution. Authentication and implied authorization are checked by CSSM at each request.
The information contained in the profile comprises the following:
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.
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.
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.
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.
| Contents | Next section | Index |