Previous section.

Common Security: CDSA and CSSM
Copyright © 1997 The Open Group

Cryptographic Service Provider Modules

The CSSM infrastructure doesn't implement general purpose cryptography. It has been termed "crypto with a hole." The Cryptographic Services Manager provides applications with access to cryptographic functions that are implemented by Cryptographic Service Provider (CSP) modules. This centralizes all the cryptography into exchangeable modules.

The nature of the cryptographic functions contained in any particular CSP depends on what task the CSP was designed to perform. For example, a VISA cryptographic hardware token would be able to digitally sign credit card transactions on behalf of the card's owner. A digital employee badge would be able to authenticate a user for physical or electronic access.

A CSP can perform one or more of these cryptographic functions and services:

Every CSP must provide secured storage of private keys. Applications may query the CSP to retrieve private keys stored within the CSP. The CSP is responsible for controlling access to the private keys it secures. The application must prove it is authorized to use the private key. A passphrase is used for this purpose. It can be provided by a callback function invoked by the CSP and implemented by the requester to identify and authorize the user or process requesting the private key. Most CSPs are capable of importing private keys created by other CSPs and providing secured storage for such keys.

Applications can create complex execution models for interacting with one or more CSPs, while a given CSP implementation can have a much simpler execution model. For example, an application could attach to the same CSP multiple times with different threads of execution each time. Each thread would get the appearance of having exclusive access to the CSP. Meanwhile the CSP may be implemented according to a single-threaded model. Additionally, the CSP may be managing multiple installed cards or multiple portable card slots on the system. An application may attach to the same CSP once for each card, as it looks like a different CSP, even though there is a single instance of the CSP attached to the CSSM.

Most applications use the CSSM CSP-APIs directly to request cryptographic operations. Applications also use CSP services indirectly through the certificate-based services of another add-in module (such as a trust policy).

CSP Form Factor

No particular form factor is assumed for a CSP. CSPs can be instantiated in hardware, software or both. Operationally, the distinction must be transparent. The two visible distinctions between hardware and software implementations are the degree of trust the application receives by using a given CSP, and the cost of developing that CSP. A hardware implementation should be more tamper-resistant than a software implementation. Hence a higher level of trust is achieved by the application.

Cryptographic service providers, whose capabilities may change after installation, may make dynamic requests to update CSSM registration information. The dynamic nature of removable and software-loadable cryptographic service providers is supported by CDSA.

Software CSPs are convenient and portable. Software CSPs can be carried as an executable file on common forms of removable media. The components that implement a CSP must be digitally signed, to authenticate their origin and integrity. This requirement extends to composite implementations involving both software and hardware. Multiple CSPs may be loaded and active within the CSSM at any time. A single application may use multiple CSPs concurrently. Interpreting the resulting level of trust and security is the responsibility of the application or the trust policy module used by the application.

Legacy CSPs

CSPs existed prior to the definition of the CSSM Cryptographic API. These legacy CSPs have defined their own APIs for cryptographic services. These interfaces are CSP-specific, nonstandard, and (in general) low-level, key-based interfaces. They present a considerable development effort to the application developer attempting to secure an application by using those services.

CSSM defines a high-level, certificate-based API for cryptographic services to support application development. The Cryptographic Services Module Manager defines a lower-level Service Provider Interface (SPI) that more closely resembles typical CSP APIs, and provides CSP developers with a single interface to support.

Embracing legacy CSPs, the CSSM architecture defines an optional adaptation layer between the Cryptographic Services Module Manager and a CSP. The adaptation layer allows the CSP vendor to implement a shim to map the CSSM SPI to the CSP's existing API, and to implement any additional management functions that are required for the CSP to function as an add-in module in the extensible CSSM architecture. New CSPs may support the CSSM SPI directly (without the aid of an adaptation layer).

A CSP may or may not support multi-threaded applications.

Cryptographic Service Provider Registration

Each CSP registers a description of its functions and services with CSSM. Applications query this information to select appropriate CSPs for their use. CSPs with dynamic capabilities will not register this information with CSSM. When no capability description is provided, CSSM will refresh information about the CSP whenever an application queries the CSPs registry. In this fashion an application can poll a CSP to become informed of a change in its status.

It is anticipated that some CSP add-in modules will span SPI functional boundaries. For example, a smart card may also register as a data storage module that contains certificates and credentials in tamper-resistant storage.

Cryptographic Services API

The security services API defined by the Cryptographic Service Providers Module Manager (CSPMM) is certificate-based. This contrasts with the approach taken by many CSPs, where low-level concepts such as key type, key size, hash functions, and byte ordering are the standard granularity of interface options. The CSPMM hides these behind high-level operations such as:

Security-conscious applications use these high-level concepts to provide authentication, data integrity, data and communication privacy, and nonrepudiation of messages to the end-users.

The CSP may implement any algorithm. For example, CSPs may provide one or more of the following algorithms, in one or more modes:

The application's associated security context defines parameter values for the low-level variables that control the details of cryptographic operations. Applications use CSPs that provide the services and features required by the application. For example, an application issuing a request to EncryptData may reference a security context that defines the following parameters:

Most applications will use default (predefined) contexts. Typically a distinct context will be used for encrypting, hashing, and signing. For a given application, once initialized, these contexts will 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.

Application developers who demand fine-grained control of cryptographic operations can achieve this by directly and repeatedly updating the security context to direct the CSP for each operation, and by using the Cryptographic Services API pass-through feature.

The pass-through feature allows a highly knowledgeable application to call low-level CSP functions that are not available through to the common Cryptographic API. The CSPMM will either reject the call or pass it through to the selected CSP. The CSPMM will not alter the result of the request, or generate other side effects based on the request. The philosophy of CDSA and the numerous services provided by CSSM is to reduce the need for applications to work at this low level.

Additional CSP Services

Unique services

Application processes may use the unique cryptographic services provided by a CSP via a pass-through capability in the Cryptographic Services API. The parameters to the pass-through interface include a security context, a CSP-specific function name, and the arguments to the function. After determining the authorization for the call (based on the invoking process, the CSP selected by the security context, and the specific function requested), the call is passed through to the specified CSP. The application process is responsible for the correctness of the arguments supplied to the call.

Key management

Every CSP is responsible for implementing its own secure, persistent storage and management of private keys. To support chains of trust across application domains, CSPs must support importing and exporting both public and private keys. This means transferring keys among remote and possibly foreign systems. The ability to transfer keys assumes the ability 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.

Note that each CSP will create and manage its own private-key database. If an application requires that more than one CSP perform operations using the same private key, then that key must be exported from some source and imported to all CSPs needing to use it. Wrapping keys as key blobs manages the problem of different key formats among different CSPs. This assumes that the key length is acceptable to all CSPs using the same key.

Each CSP defines and implements its own key-management functions. Recent CSP implementations, such as Microsoft's Crypto API, define internal storage formats and key-blob wrappers for exporting keys outside of the CSP. CSPs will exchange private keys through secured communication protocols (such as wrappers), rather than through access to a shared database for private keys.

The CSPMM API defines how private keys will be passed up and down through the layers of the CDSA, but it does not specify how private keys will be stored within the CSP.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.
You should also read the legal notice explaining the terms and conditions relating to the CDSA documentation.

Contents Next section Index