Previous section.

Common Security: CDSA and CSSM, Version 2 (with corrigenda)
Copyright © 2000 The Open Group

Introduction

Common Data Security Architecture

The Common Data Security Architecture (CDSA) defines the infrastructure for a comprehensive set of security services to address the needs of individual users and the business enterprise. CDSA is an extensible architecture that provides mechanisms to manage add-in security service modules. These modules provide cryptographic services and certificate services for use in building secure applications. Common Data Security Architecture for all Platforms shows the four basic layers of the Common Data Security Architecture: Applications, System Security Services, the Common Security Services Manager, and Security Add-in Modules. The Common Security Services Manager (CSSM) is the core of CDSA. It provides a means for applications to directly access security services through the CSSM security API, or to indirectly access security services via layered security services and tools implemented over the CSSM API. CSSM manages the add-in security modules and re-directs application calls through the CSSM API to the selected add-in modules that will service the request.

This four layer architecture defines four categories of basic add-in module security services. Basic services are required to meet the security needs of all applications. CSSM also supports the dynamic inclusion of APIs for new categories of security services, as required by selected, security-aware applications. These elective services are dynamically and transparently added to a running CSSM environment when required by an application. When an elective service is needed, CSSM attaches a module manager for that category of service and then attaches the requested add-in service module. Once attached to the system, the elective module manager is a peer with all other CSSM module managers. Applications interact uniformly with add-in modules of all types.

The five basic categories of security services modules are:

Cryptographic Service Providers (CSPs) are add-in modules, that perform cryptographic operations including encryption, decryption, digital signaturing, key pair generation, random number generation, and key exchange. Trust Policy (TP) modules implement policies defined by authorities, institutions, and applications, such as your Corporate Information Technology Group* (as a certificate authority) or MasterCard* (as an institution), or Secure Electronic Transfer (SET) applications. Each trust policy module embodies the semantics of a trust environment based on digital credentials. A certificate is a form of digital credential. Applications may use a digital certificate as an identity credential and/or an authorization credential. Certificate Library (CL) modules provide format-specific, syntactic manipulation of memory-resident digital certificates and certificate revocation lists. Data Storage Library (DL) modules provide persistent storage for certificates, certificate revocation lists, and other security-related objects.

Examples of elective security service categories are key recovery and audit logging.


Figure: Common Data Security Architecture for all Platforms

Applications dynamically select the modules used to provide security services. These add-in modules can be provided by independent software and hardware vendors. A single add-in module can provide one or more categories of service. Modules implementing more than one category of service are called multi-service modules.

The majority of the CSSM API functions support service operations. Service operations are functions that perform a security operation, such as encrypting data, adding a certificate to a certificate revocation list, or verifying that a certificate is trusted/authorized to perform some action. action. Service providers can require caller authentication before providing services. Application authentication is based on signed manifest credentials associated with the application.

Service modules can leverage other service modules in the implementation of their own services. Service modules acquire attach handles to other modules by:

To prevent stealth attacks, CSSM performs secure linkage checks on function invocation. Modules can also provide services beyond those defined by the CSSM API. Module-specific operations are enabled in the API through pass-through functions whose behavior and use is defined by the add-in module developer. (For example, a CSP implementing signaturing with a fragmented private key can make this service available as a pass-through.) Existence as a pass-through function is viewed as a proving ground for potential additions to the CSSM APIs.

CSSM core services support:

The module management functions are used by applications and by add-in modules to support module installation, registration of module features and attributes, and queries to retrieve information on module availability and features.

Security context management provides runtime caching of algorithm configuration parameters for a service provider in the form of a cryptographic context. Applications may create, delete, and modify these contexts as necessary. CDSA components are checkable if the component has a manifest. Checkable components include add-in service modules, CSSM itself, and applications that use CSSM.

In summary, the direct services provided by CSSM through its API calls include:

Add-In Module Structure


Figure: CDSA Add-In Module Structure

Add-in modules are composed of module administration components and implementations of security service interfaces in one or more categories of service. Module administration components include the tasks required during module load, attach, and detach. The number, categories, and contents of the service implementations are determined by the module developer.

Module Installation

Before an application can use a module, the module must be registered by an installation program. The installation program uses platform-specific services to install all executable code associated with the service module. The installation program must also create records in Module Directory Services database. These records store information about the modules. At runtime this information is used by applications to locate and select service modules that provide the services required by the applications. The information is also used by any CDSA component that must check the integrity and authenticity of the service module.

The MDS Common relation stores the general attributes applicable to the four basic module types. Module installation must insert a new record in this relation, identifying and locating the new module.

MDS defines the EMM Service Provider relation to store general attributes of elective service providers. When installing a service module for an elective category of service, the installation program must insert a new record in this relation, identifying and locating the new module.

In addition to the Common relation, MDS defines numerous relations based on the basic categories of security services. These relations store detailed descriptions of the services provided by the module. New elective categories of service will define additional service-specific relations to store detailed descriptions of those modules that provide that type of service. Applications will search these service-specific relations to select appropriate service modules. The module installation program should consider inserting descriptive records into these additional relations.

Runtime LifeCycle of the Service Provider Module

Applications dynamically select the service modules that will provide security services to the application. Selection and session establishment is a multiple step process. When the module's services are no longer required, de-selection is also a multi-step process. The runtime life cycle of the service module and the sequence of function calls required among applications, CSSM and the service module are as follows:

  1. An application invokes CSSM_ModuleLoad(). CSSM will perform an integrity check on the module and then load the module using SPI_ModuleLoad().

  2. The application invokes CSSM_ModuleAttach() to complete selection of the module.

  3. CSSM carries out the attach process by calling the module interface CSSM_SPI_ModuleAttach(). In response, the service module should perform a cross-check of the calling CSSM's signed manifest credential to guard against rogue callers.

    The CSSM_SPI_ModuleAttach() function is called each time an application invokes the CSSM_ModuleAttach() API.

  4. When the application no longer requires the module's services, the application invokes CSSM_ModuleDetach().

  5. In response, CSSM invokes CSSM_SPI_ModuleDetach()

  6. The application invokes CSSM_ModuleUnload() to deregister the application callback functions and to release all sessions associated with target service provider module.

  7. In response, CSSM invokes CSSM_SPI_ModuleUnload(). The function should disable events and de-register the CSSM event-notification function. The add-in service module may perform cleanup operations, reversing the initialization performed in CSSM_SPI_ModuleLoad().

Contents Next section Index