Introduction

• An overview of the Common Data Security Architecture

• An overview of the Common Security Services Manager Application Programming Interface specification

Common Data Security Architecture

This four layer architecture defines five 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 five basic categories of security services modules are:

• Cryptographic Service Providers (CSP)

• Trust Policy Modules (TPM)

• Certificate Library Modules (CLM)

• Data Storage Library Modules (DLM)

• Authorization Computation Modules (ACM)

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.

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. A standalone registry system called the Module Directory Services (MDS) provides applications with information about the service modules available for use by applications.

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

• Receiving additional module handles from an invoking application

• Selecting and attach additional service module directly.

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.) The PassThrough is viewed as a proving ground for potential additions to the CSSM APIs.

CSSM core services support:

• Module management

• Security context management

• System integrity services

The module management functions are used by applications and by add-in modules to support runtime access to security service modules.

Security context management provides runtime caching of user-specific, cryptographic context information. Multi-step cryptographic operations, such as staged hashing, require multiple calls to a CSP.

CSSM, security services modules, and optionally applications, 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.

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

• Comprehensive, extensible SPIs for each of five categories of security services.

• Runtime management and access to all security service modules.

• Runtime management and access to elective module managers providing new security services.

• Caching of context information for cryptographic operations.

• Call-back functions used by add-in modules and CSSM to interact with an application process.

• Notification services to inform add-in modules of selected actions taken by an application.

• Management support for concurrent security operations.

Selecting CDSA Components

• a unique identification GUID, which distinguishes the component and its manufacturer

• major and minor version numbers, which further distinguishes the supported APIs, feature set, and bug fixes of the component.

The Module Directory Services (MDS), which is a standalone service outside of CDSA, implements a database describing CDSA components available from the local platform. Applications and CDSA components can query MDS to obtain the compatibility information and numerous other attributes describing features of the CDSA components. This information can be used as the basis for selecting appropriate and compatible components at runtime.

Every CDSA component must have a unique identification GUID. Not all CDSA applications are required to have an identifying GUID, but it is highly recommended. MDS uses the GUID as the primary database key for locating information about the CDSA component. Specification of the the version numbers is optional, but believed to be of value as an augmentation to the distinguished name for an executable CDSA component.

When components are selected at runtime, applications use the MDS query functions to select components based on GUID or based on other properties of the component (such as the algorithms or features provided by the component).

If the application is selecting a CSSM at runtime, the application is responsible for loading the selected CSSM using services provided by the platform-specific environment. The application is also responsible for any load-specific initialization, such as symbol resolution. Once a CSSM has been loaded with the application, CSSM initialization proceeds as usual with the application invoking CSSM_Init() prior to calling any other CSSM interfaces.

Note:

Applications can be statically bound with a particular version of CSSM. In this case, the application proceeds with CSSM initialization by invoking CSSM_Init().

Applications also use MDS to identify a service module providing the features and services required by the application. Once the service module has been identified, the application must use the CSSM services CSSM_ModuleLoad() and CSSM_ModuleAttach() to select and initiate a session with the service module. CSSM and service provider enforced integrity checks ensure that the application can not obtain direct access to service module. All service module access is mediated by the selected CSSM.