Previous section.

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

Introduction

This chapter provides:

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. The 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, required by selected applications. These elective services are dynamically, and transparently added to a running CSSM environment when required by an application. Elective services are required by only a subset of security aware applications. When an elective service is needed a module manager for that category of service can be transparently attached to the system followed by 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), 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: The 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 services in multiple categories of service. These are called multi-service modules.

The majority of the CSSM APIs 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 and/or 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.) The PassThrough 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. Multi-step cryptographic operations, such as staged hashing, require multiple calls to a CSP. Intermediate operation state 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 check 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 in the system and tampering of authorized components.

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

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