CDSA Overview

An application establishes a session to select a particular CSP. Once attached, the application can initiate a cryptographic login session with the CSP. The application requests additional credentials, such as a passphrase or PIN, to gain access to specific keys and services managed by the CSP.

Within a module attach session or a cryptographic login session, an application creates, uses, and discards cryptographic contexts. A cryptographic context carries the parameters required to perform a cryptographic service. The cryptographic context can be used for the following:

Depending on the class of cryptographic operations, individualized attributes are available for the cryptographic context. In addition to specifying an algorithm when creating the context, the application can also initialize a session key, pass an initialization vector, or pass padding information to complete the description of the session. A successful return value from the create function indicates that the desired CSP is available.

Functions are also provided to manage the created context. The cryptographic context contains most or all of the input parameters required for an operation. Some cryptographic service functions accept input parameters in addition to the CSP handle and the context handle. These input parameters always take precedence over any duplicate or conflicting parameters in the cryptographic context. When a context is no longer required, the application calls a DeleteContext function. Resources allocated for that context can then be reclaimed by the operating system.

The application's associated security context defines parameter values for the low-level variables that control the details of cryptographic operations. For example, an application issuing a request to the EncryptData call can reference a security context that defines the following parameters:

Most applications use predefined, default contexts. Typically, a distinct context is used for encrypting, hashing, and signing. For an initialized application, these contexts change little, if at all, during the application's execution or between executions. This allows the application developer to implement security by manipulating certificates, using previously defined security contexts, and maintaining a high-level view of security operations.

In CDSA, there are two main types of cryptographic algorithms that use keys:

Every CSP implements its own secure, persistent storage and management of private keys. To support chains of trust across application domains, CSPs support importing and exporting of public and private keys among remote and possibly foreign systems. To transfer keys, the CSP must be able to convert one key format into any other key format and to secure the transfer of private and symmetric keys.

Each CSP is responsible for securely storing the private keys it generates or imports from other sources. Additional storage-related operations include retrieving a private key when given its corresponding public key and wrapping private keys as key blobs for secure exportation to other systems.

On an OpenVMS Alpha system, the CSP stores private key files in EAYCSP.PRI and MAF_BSAFE.PRI. The protections on the key files are OWNER:READ,WRITE,DELETE. The key files are user-specific and are stored in the [.CDSA.PKD] subdirectory in the user's login directory.

Public Key Infrastructure (PKI)

The Public Key Infrastructure (PKI) is the state-of-the-art method, ultimately to be applied worldwide, for secure and confidential electronic transactions. It employs public and private keys.

The two PKI algorithms in widespread use are:

For RSA-based algorithms, CDSA uses the PKCS#1 standard for key representation. For DSA-based algorithms, no organization has published a standard. CDSA's representation of the DSA key is based on the DSA algorithm definitions in the FIPS 186 standard. (See the Preface for web links to this and other standards.)

A DSA public key is represented as a BER-encoding of a sequence list that contains the following:

PrimeModulus; /* p */ 
PrimeDivisor; /* q */
OrderQ; /* g */
PublicKey; /* y */

A DSA private key is represented as a BER-encoded sequence list that contains the following:

PrimeModulus; /* p */ 
PrimeDivisor; /* q */
OrderQ; /* g */
PrivateKey; /* x */

These key components are defined as follows by FIPS 186 and FIPS 186a:

A DSA-wrapped private key is defined by the PKCS#8 specification. The PKCS#8 standard specifies the wrapped key format resulting from encoding an algorithm object identifier (OID) with an encoded private key.