Previous section.

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

Common Security Services Manager

This section provides details on the main infrastructure component of the CDSA, the Common Security Services Manager (CSSM).

Overview

The Common Security Services Manager integrates the security functions required by applications to use cryptographic service provider modules (or tokens) and certificate libraries. In particular, it facilitates linking digital certificates to cryptographic actions and trust protocols. Tokens and certificate libraries plug into the CSSM as add-in modules.

Functionally, CSSM provides the services shown in Services Provided by CSSM :

Figure: Services Provided by CSSM

General Module Management Services

CSSM manages a registry that records each component's logical name, attached components in the CSSM environment. CSSM manages a registry that records information about each installed add-in module and elective module manager. This information can be queried by applications, add-in modules, and components of CSSM. The registry is CSSM's critical information base. CSSM must protect this information base by controlling access to the information, (particularly write access), and checking the integrity of stored values upon retrieval.

The CSSM registry records the logical name of each add-in module and elective module manager, the information required to locate and dynamically initiate the component, and some minimal meta-data describing the capabilities and services implemented by the component. An add-in module may or may not implement all of the APIs defined by CSSM. Unimplemented functions are registered as null. For extensibility, an add-in module can implement additional functions outside of the CSSM-defined API calls. CSSM defines a single pass-through function, which an add-in module can overload with multiple custom functions. The meaning and use of these functions is documented outside of CSSM by the module vendor.

CSSM APIs allow an application to query the registry of installed (known) add-in modules to determine the availability of various security services. Applications must be able to search the registry by module name and by features and capabilities. This allows applications to select specific vendor's modules or to select any module that provides the desired services. Once an applicable module is located in the registry information, an application uses the CSSM attach operation to load and initiate the module.

For each attach call, CSSM creates a unique attach handle to identify the logical connection between the application and the add-in module. CSSM maintains a separate context state for each attach operation. This enables non-cooperating threads of execution to maintain their independence, even though they may share the same process space.

When dynamically loading components, CSSM ensures the integrity of the expanding system using the CSSM Integrity Services Library. (The complete set of integrity services are described in more detail later in this section.) When a module is loaded and initiated, it must present a digitally-signed credential, such as a certificate, to identify its author and publisher. The signature represents the module provider's attestation of ownership and a guarantee that the module conforms to the CSSM specification. CSSM checks the authenticity of the module's credentials and the integrity of the module's code before attaching the module to the CSSM execution environment.

Once the module has been loaded into the CSSM runtime environment, CSSM exchanges state information with the application and with the module. This allows CSSM to act as a broker between the application and a set of add-in modules. An excellent example of this brokerage service is CSSM's memory usage model. Often cryptographic operations and operations on certificates make pre-calculation of memory block sizes difficult and inefficient. CSSM rectifies this problem through registration of application memory allocation callback functions. CSSM and attached add-in modules use the applications memory functions to create complex or opaque objects in the application's memory space. Memory blocks allocated by an add-in module and returned to the application can be freed by the application using its chosen free routine.

When an application no longer requires a module's services, the add-in module can be detached. An application should not invoke this operation unless all requests to the target module have been completed. Modules can also be uninstalled. This operation removes the module name and its associated attributes from the CSSM's registry. Uninstall must be performed before a new version of the module is installed in the CSSM registry.

Elective Module Managers

To ensure long-lived utility of CDSA and CSSM APIs, the architecture includes several extensibility mechanisms. Elective module managers is a transparent mechanism supporting the dynamic addition of new categories of service. For example, key recovery can be an elective service. Some applications will use key recovery services (by explicit invocation) and other applications will not use it. Audit logs can be an elective service. Applications wishing to maintain a log can do so, other applications will not use that facility.

Transparent, Dynamic Attach

Applications are not explicitly aware of module managers. Applications are aware of instances of add-in modules. Before requesting services from an add-in service provider (via CSSM API calls), the application invokes attach to obtain an instance of the add-in service provider. Processing Steps to Attach an Add-In Module shows the sequence of processing steps. If the module is of an elective category, then CSSM transparently attaches the module manager for that category of service (if that manager is not currently loaded). Once the manager is loaded, the APIs defined by that module are available to the application.

The dynamic nature of the elective module manager is transparent to the add-in module also. This is important. It means that an add-in module vendor should not need to modify their module implementation to work with an elective module manager, versus a basic module manager.

There is at most one module manager for each category of service loaded in CSSM at any given time. When an elective module manager is dynamically added to service an application, that module is a peer of all other module managers and can cooperate with other managers as appropriate.

When an attached application detaches from an add-in service module, CSSM will also unload the associated module manager if it is not in use by another application.

Figure: Processing Steps to Attach an Add-In Module
and Load its Elective Module Manager

Registering Module Managers

Module managers are installed and registered with CSSM in a similar manner to add-in modules. CSSM records module manager information in the CSSM registry. This information can be queried, but typically only system administration applications will use registry information about module managers. For example, a smart installer for an add-in module may check to see that the corresponding module manager is also installed on the local system. If not, then the installer can also install the required module manager. This does not effect the implementation of the add-in module itself, just the install program for that module.

State Sharing Among Module Managers

Module managers may be required to share state information in order to correctly perform their services. When two or more module managers share state, each manager must be able to:

The other module managers must be able to:

When module managers share state information they must implement conditional logic to interact with each other. Different mechanisms can be used to share state information:

The first two mechanisms depend on platform services outside of CDSA. Module managers that share state information can use all of these mechanisms.

CSSM-supported event notifications requires that all module managers implement and register with CSSM an event notification entry point. Module managers issue notifications by invoking a CSSM function, specifying:

CSSM delivers the notification to the destination module manager by invoking the manager's notification entry point.

Typical event types include:

Module managers that share state information are not required to use the CSSM event notification mechanism. These types of events, requests, and notifications can be shared using the other platform dependent mechanisms. CSSM provides this simple mechanism specifically for situations where other platform services are not readily available.

Basic Module Managers

CDSA defines module managers for four basic types of service:

These service categories are considered basic because we believe that all applications using security services must use these services. Cryptographic services are the heart of security services and protocols. Identity, authentication, and integrity are embodied in digital credentials (such as certificates). A user's certificates must be persistently stored for use as long-term credentials. Policies will exist for how and when the credentials can be used. A security-aware application that does not use these services is unusual.

CSSM maintains these module managers in the system at all times and exports their respective APIs to all applications. Elective module managers export their APIs to applications on demand. When active in the CSSM environment, all modules managers are peers, all are managed uniformly by CSSM, and all may cooperate and coordinate with each other as required to perform their tasks.

Dispatching Application Calls for Security Services

Multiple add-in modules of each type may be concurrently active within the CSSM infrastructure. CSSM module managers use unique handles to identify and maintain logical connections between an application and attached service modules. The handle maintains the state of the connection, enabling add-in modules to be re-entrant. When an application invokes the CSSM API, the module manager who exports the invoked API dispatches the call to the appropriate module by invoking the corresponding Service Provider Interface (SPI) supported by the add-in module. CSSM Dispatches Calls to Selected Add-In Security Modules shows how managers dispatch function calls to attached add-in modules.

In CSSM Dispatches Calls to Selected Add-In Security Modules , the application invokes func1 in the cryptographic module identified by the handle CSP1. A dispatcher forwards the function call to func1 in the CSP1 module. The application also invokes func7 in the trust policy module, identified by the handle TP2. A dispatcher forwards the function call to func7 in the TP2 module. The implementation of func7 in the TP2 module uses functions implemented by a certificate library module. The TP2 module must invoke the certificate library functions via the dispatching mechanism. To accomplish this, the TP2 module attaches the certificate library module, obtaining the handle CL1, and invokes func13 in the certificate library identified by the handle CL1. A dispatcher forwards the function call to func13 in the CL1 module.

Calls to the CSSM security API can originate in an application, in another add-in security module, or in CSSM itself. The dispatching mechanism forwards all calls uniformly, regardless of their origin. CSSM ensures access to CSSM internal structures is serialized through thread synchronization primitives. If CSSM is implemented as a shared library then process synchronization primitives are also employed. Add-in modules need not have multi-threaded implementations to interoperate with CSSM. Multi-threaded capabilities are registered with CSSM at module install time. Access to non-multithreaded add-ins is serialized by CSSM.

Figure: CSSM Dispatches Calls to Selected Add-In Security Modules

Modules must be loaded before they can receive function calls from a dispatcher. An error condition occurs if the invoked function is not implemented by the selected module.

Integrity Services

CSSM provides a set of integrity services used by CSSM, module managers, add-in modules, and applications to verify the integrity of themselves and other components in the CSSM environment. The dynamic, configurable environment defined by CDSA and supported by CSSM provides the level of service and flexibility that applications require. In balance with the benefits are the increased risk of introducing tampered components into the environment. To address this, CSSM provides a set of integrity verification and identity verification functions. CSSM also requires their use during each dynamic reconfiguration of the CDSA environment.

CSSM-Enforced Integrity Verification

CDSA checks the integrity of modules as they are dynamically attached to the system. A bilateral authentication procedure is designed for two entities to establish trust in the identity and integrity of each other. When attaching an add-in module or an elective module manager, CSSM requires that the attaching party participates in a bilateral procedure to verify the identity and the integrity of both parties. If authentication fails, the module is not attached and system execution is interrupted.

Both parties in the bilateral procedure must have three pieces of signed credentials:

These credentials are stored in the local file system and are associated with the component. CSSM's credentials are also placed on the system during installation. The credentials of a dynamic component are placed on the system when that component is installed with CSSM.

As part of attach processing, CSSM performs the first half of the bilateral protocol, which proceeds as follows:

The component completes the authentication procedure as follows:

When the three credentials verify, it is still necessary to ensure secure linkage between the components. For the CSSM, this entails checking that the called address is in fact in the appropriate code module. For the attaching component, the return address must be verified to be within the CSSM calling module. (Even in the case of self-checking, one may require that the return address be within the module being checked.)

Linkage checks prevent attacks of the stealth class, where the object being verified is not the object that is being used. Also, the checks increase the difficulty of the man-in-the-middle attack, where a rogue component will insert itself between two communicating modules, masquerading itself as the other component to each component.

Bilateral authentication should also be performed between applications and CSSM. This requires a manufacturing, installation and start-up process in which applications can:

Applications that do not want to implement or cannot implement the entire bilateral procedure can still benefit from CSSM integrity services by invoking selected CSSM integrity functions to:

Creating Checkable Components

The integrity of a CDSA component is based on verification of a digital signature on that component. The identity of a CDSA component is based on verification of a certificate belonging to that component. To verify a certificate and the signature of an object module requires that these credentials be created as part of the manufacturing process.

The enhanced, off-line manufacturing process for all dynamic components of CDSA is as follows:

When manufactured in this manner, the identity and integrity of the component can be checked. Applications that wish to present credentials for privileged services or to be authenticated by CSSM must follow an analogous manufacturing process.

Verifying Components

CSSM provides signature verification functions to authenticate the manufacturer as the author and publisher of the binary object and determine whether or not the CSSM object was modified after it was signed. Signature verification requires the use of public keys. Public keys are public information stored in certificates. They are not secrets to be protected, but they must be protected from modification. If replaced with an impostor's public key, an unauthorized component could pass the integrity check and be erroneously added to the system.

CSSM must provide verification services without assuming any central authority as the universal base of trust. Software vendors can cross-license with other vendors using their digital signature. These root keys can be provided to CSSM integrity services. CSSM can perform authentication based on these additional roots of trust only if the keys are signed and that signature can be verified by CSSM based on previously known roots of trust. By using certificates to introduce new vendors, the number of verifiable vendors need not be limited.

The verification tests can be applied as a self-check or to check another component in the CSSM environment. Periodic, runtime re-checks can be performed to verify constancy of a component's integrity. If tampering is detected in any component, the verification function will interrupt system execution.

Verification services are available for use on demand by add-in modules, module managers, applications, and CSSM itself.

Security Context Services

Security Context Services creates, initializes, and maintains concurrent security contexts. A security context is a run-time structure containing security-related execution parameters, and potentially secrets of an application process or thread. The structure aggregates the numerous parameters an application must specify when requesting a cryptographic operation.

Once cryptographic contexts have been created the application may freely use those contexts without CSSM-imposed security checks. Security contexts may contain secrets, such as encryption keys, passphrases and passphrase functions. Applications are responsible for protecting these secrets. Applications desiring maximal protection should use passphrase callback functions that limit the duration in which the passphrase is present in the system.

Applications retain handles to each security context used during execution. The context handle is a required input parameter to many security service functions. Most applications instantiate and use multiple security contexts. Only one context may be passed to a function, but the application is free to switch among contexts at will, or as required (even per function call).

A knowledgeable CSP-aware application initializes the security context structure with values obtained by querying CSSM to obtain the capabilities of the Cryptographic Services Provider (CSP) from the CSSM Registry.

An application may create multiple contexts directly or indirectly. Indirect creation may occur when invoking layered services, system utilities, trust policy modules, certificate library modules, or data storage library modules, that create and use their own appropriate security context as part of the service they provide to the invoking application. shows an example of a hidden security context. An application creates a context specifying the use of sec_context1. The application invokes func1 in the certificate library using sec_context1 as a parameter. The certificate library performs two calls to the cryptographic service provider. For the call to func5, the hidden security context is used. For the call to func6, the application's security context is passed as a parameter to the CSP.

Figure: Indirect Creation of a Security Context

These transparent contexts do not concern the application developer, as they are managed entirely by the layered service or add-in module that creates them. Each process or thread that creates a security context is responsible for explicitly terminating that context.

Security context management provides mechanisms that:

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