Introduction

CDSA Add-In Module Overview

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:

• The provision of security services to applications

• Module administration

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, Authorization Computation (AC) 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 Part 10 describes the module interface functions in the CSP service category.

Each module, regardless of the security services it offers, has the same set of administrative responsibilities. Every module must expose functions that 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 Part 9 of this Technical Standard.

Cryptographic Service Provider Overview

The Cryptographic Services Manager defines two categories of services:

• Support for dynamic module attach with integrity checking, and event notification handling

• Selection, initialization, and use of cryptographic operations, which are implemented by a CSP

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:

• Bulk encryption

• Digital signature

• Cryptographic hash

• Key generation

• Random number generation

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.

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