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.
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:
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).
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 |