Previous section.

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


CDSA Add-In Module Overview

Figure: CDSA Add-In Module Structure

A CDSA add-in module is a dynamically-linkable library, composed of functions that implement some or all of the CSSM Module Interfaces. Add-in module functionality is partitioned into two areas:

Add-in modules provide one or more categories of security services to applications. The service categories are Cryptographic Service Provider (CSP) services, Trust Policy (TP) services, Certificate Library (CL) services, and Data Storage Library (DL) services. Each security service contains one or more implementation instances, called sub-services. For a CSP service providing access to hardware tokens, a sub-service would represent a slot. For a DL service provider, a sub-service would represent a type of persistent storage. These sub-services each support the module interface for their respective service categories. This documentation-part describes the module interface functions in the CSP service category. More information about DL services can be found in the CSSM Data Storage Library Interface Specification. More information about TP services can be found in the CSSM Trust Policy Interface Specification. More information about CL services can be found in the CSSM Certificate Library Interface Specification.

Each module, regardless of the security services it offers, has the same set of administrative responsibilities. Every module must expose functions which allow CSSM to indicate events such as module attach and detach. In addition, as part of the attach operation, every module must be able to verify its own integrity, verify the integrity of CSSM, and register with CSSM. Detailed information about add-in module structure, administration, and interfaces can be found in the CSSM Add-in Module Structure and Administration Specification.

Cryptographic Service Provider Overview

The CSSM infrastructure does not implement any 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 achieves the objective of centralizing all the cryptography into exchangeable modules.

The Cryptographic Services Manager defines two categories of services:

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* smart card* would be able to digitally sign credit card transactions on behalf of the card's owner, whereas 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:

The Cryptographic Services Manager doesn't assume any particular form factor for a CSP. Indeed, 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.

Software CSPs are the default and are portable in that they can be carried as an executable file. Additionally, the modules that implement a CSP must be digitally signed (to authenticate their origin and integrity), and they should be made as tamper-resistant as possible. This requirement extends to software implementations 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.

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

The Cryptographic Services Manager defines a high-level, certificate-based API for cryptographic services to better support application development. In consideration of legacy and divergent CSPs, the Cryptographic Services 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. A CSP may or may not support multithreaded applications.

Acknowledging legacy CSPs, the CSSM architecture defines an optional adaptation layer between the Cryptographic Services 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).

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