Previous section.

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


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

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 user-specific, cryptographic state information for use by multi-step cryptographic operations, such as staged hashing. These operations require multiple calls to a CSP and produce intermediate state that must be managed. CSSM manages this state information for the CSP, enabling more CSPs to easily support multiple concurrent callers.

The CSSM Embedded Integrity Services Library (EISL) provides tamper resistant verification services. CSSM, add-in modules, and optionally applications use EISL to verify the identity and integrity of components of CDSA. Checkable components include: add-in service modules, CSSM itself, and in the future, applications that use CSSM. The EISL services focus on detecting impostors or unauthorized components and tampering of authorized components.

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 installation, attach, and detach. The number, categories, and contents of the service implementations are determined by the module developer.

Every module implementation shares certain administrative tasks which must be performed during module installation, attach, and detach. As part of module installation, the module developer must register information about the module's services with CSSM. This information is stored in the CSSM registry and may be queried by applications using the CSSM_GetModuleInfo function. On attach, the module's administrative responsibilities include bilateral authentication, module registration, and module initialization. Bilateral authentication is a protocol whereby a module insures the integrity of its own components and of CSSM prior to attaching into the system. Following bilateral authentication, the module registers its functions with CSSM and performs any initialization operations. When the module is detached, it performs any necessary cleanup actions.

The remainder of the module implements one or more sub-services in one or more categories of service. A module developer may choose to implement a single service, such as a CSP, or may provide multiple services, such as Trust Policy and Certificate Library services. Within a single category of service, a module may implement multiple sets of capabilities, called sub-services. For example, a module might implement two Trust Policy sub-services in a single module in order to provide for two levels of authorization.

Additional utility libraries may be provided by a module developer for use by other module developers. Utility libraries are software components which contain functions that may be useful to several modules. For example, a utility library which performs DER encoding might be useful to several modules providing certificate library services. The utility library developer is responsible for making the definition, interpretation, and usage of their library available to other module developers.

Add-In Module Usage

Application Interaction

When a new module is installed on a system, information specific to the module and its services is stored in the CSSM registry. An application uses this information to find an appropriate module sub-service and to request that CSSM attach to it. When CSSM attaches to a module sub-service, it returns a module handle to the application that uniquely identifies the pairing of the application thread to the module sub-service instance. The application uses this handle to identify the module sub-service in future function calls. The module sub-service uses the handle to identify the calling application.

The calling application is responsible for the allocation and de-allocation of all memory that is passed into or out of the module. The application must register memory allocation and de-allocation upcalls with CSSM when it requests a module attach. These upcalls are passed to the module when the it calls the CSSM_RegisterServices function. These functions must be used whenever a module either allocates memory to be passed out of the module or de-allocates memory passed into the module.

CSSM Interaction

As a part of CSSM_ModuleAttach, CSSM and the add-in module perform a bilateral authentication protocol. In this protocol, CSSM insures that the module has not been altered since production by a trusted manufacturer. CSSM also verifies that the module is loaded into the appropriate memory space. The add-in module insures that the CSSM instantiation to which it is attaching is trusted, has not been altered, and is running in its appropriate memory space. The add-in service module implements this check in the AddInAuthenticate function, which is invoked by CSSM. The verification must succeed in order for a module to attach to CSSM.

Once bilateral authentication has been accomplished, the module uses CSSM_RegisterServices to register a function table with CSSM for each sub-service that it supports. The function tables consist of pointers to the sub-service functions supported by the module. During future function calls from the application, CSSM will use these function pointers to direct calls to the appropriate module sub-service.

Module to Module Interaction

Modules may make use of other CSSM add-in modules to implement their functionality. For example, a module implementing a certificate library may use the capabilities of a CSP add-in module to perform the cryptographic operations of sign and verify. In that case, the certificate library module could package the certificate or CRL fields to be signed or verified, attach to the appropriate CSP add-in module, and call CSSM_SignData or CSSM_VerifyData to perform the operation.

Similarly, that same module with certificate library capabilities may be used by other CSSM add-in modules to implement their functionality. For example, Trust Policy modules may choose to perform the syntactic verification of trust by calling a module with certificate library functionality.

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