Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

Overview of 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. Elective service categories create areas for totally new products. When an elective service category is defined, at least one instance of an add-in module will also be developed to provide that service. One elective module manager should support only one service type.

Elective services extend CSSM. They define their own application programming interfaces and service provider interfaces. 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. The module manager for key recovery could be loaded on demand as required but need not be a static part of a system. User authentication based on biometric data can be an elective service. Systems where biometric devices are deployed and required only for authenticating system administrators would not need a biometric module manager as a standard, loaded component on the environment. Elective module management supports on-demand inclusion of a module manager. The module manager defines a new set of APIs and their corresponding SPIs. Standardization of the new APIs and SPIs is in addition to the current CDSA standards. The additions can be standardized as an enhancement to CDSA or as an independent standard that is adopted and used within CDSA. The elective module management mechanisms allow CDSA implementations to easily and quickly incorporate these new standards. CSSM does not have a priori knowledge of the elective APIs, but applications have complete knowledge of the new APIs in order to explicitly invoke the services provided through those APIs.

Transparent, Dynamic Attach

Applications are not explicitly aware of module managers within CSSM. Applications see a uniform set of interface management services provided by CSSM across all types of security service categories. In reality, some of those services are provided by the CSSM core functions (that is, applicable to all service types) and the remainder are provided by each module manager for their respective security service category.

Applications are aware of instances of add-in modules, not the module managers that control access to those modules. Before requesting services from an add-in service provider (via APIs defined by a module manager), the application invokes CSSM_ModuleLoad() and CSSM_ModuleAttach() to select an instance of the add-in service provider. Steps to Load a Service Module and its Corresponding EMM shows the sequence of processing steps. If the module is of an elective category of service, then CSSM transparently attaches the module manager for that category of service (if that manager is not currently loaded). The module manager must perform the CSSM-defined bilateral authentication protocol. This protocol is used to ensure CSSM-wide integrity when any component is dynamically added to the CSSM runtime environment. (This protocol is described in more detail in a later section of this specification.) 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 need not modify their module implementation to work with an elective (dynamically loaded) module manager versus a basic module manager (which is always resident in the system).

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 serve an application, that module manager is a peer of all other module managers and can cooperate with other managers as appropriate.

Elective module management defines a set of mechanisms that support runtime inclusion of new APIs and their corresponding SPIs. Standardization of the new APIs and SPIs is in addition to the current CDSA standards. The additions can be standardized as an enhancement to CDSA or as an independent standard that is adopted and used within CDSA. The elective module management mechanisms allow CDSA implementations to easily and quickly incorporate these new standards. CSSM does not have a priori knowledge of the elective APIs, but applications have complete knowledge of the new APIs in order to explicitly invoke the services provided through those APIs.

The elective module manager is responsible for checking instance compatibility with the CSSM that loaded the manager. Compatibility can be based on a combination of the CSSM's GUID and CSSM's major and minor version number. CSSM APIs can be invoked to obtain these values. These values also represent the instance level of the basic module managers that are always present in the CSSM. In rare cases, elective module managers may have dependencies on each other. In this case compatibility between elective module managers is the responsibility of the elective module managers. These checks must be performed in a manner that does not depend on the order in which the caller attaches dependent services that are supported by elective module managers. Compatibility checks among dependent, elective module managers can be checked using the event notification interface for communication among module managers. 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 thread, process, or application.


Figure: Steps to Load a Service Module and its Corresponding EMM

Registering Module Managers

Elective module managers are installed using platform-specific installation services. During installation the EMM installation program must registered the EMM with CSSM using the Module Directory Services (MDS). MDS defines the EMM relation that stores basic information about the elective module manager. The EMM relation can be queried by anyone, but typically only system administration applications and CSSM will use registry information about module managers. For example, a smart installer for a service module should confirm that the corresponding module manager is also installed on the local system. If not, then the installer can install the required module manager with the service module. CSSM uses the EMM relation to obtain the module manager's signed manifest credentials.

Interaction with CSSM

CSSM supports elective module managers with a number of EMM-specific services. These service functions are defined as upcalls to CSSM. The upcalls support the elective module manager in:

CSSM provides this information so CSSM and the elective module manager can effectively support the service module without the module being aware that the elective module manager was dynamically loaded and that CSSM had no prior knowledge of the structures, functions, and services provided by the service module.

Integrity and Secure Linkage

In general, CSSM provides secure linkage checks between applications and CSSM, and between service modules and CSSM. To perform this service on behalf of an EMM, CSSM must proxy all function calls into and out of the EMM. For this reason, it is inappropriate for the elective module manager to invoke functions other than those functions CSSM has registered with the EMM. This includes application callback functions and service module interfaces via the SPI function table.

CSSM provides upcall proxies to the elective module manager. When performing secure linkage checks, CSSM is aware of the EMM and verifies that the upcall originated from the service provider module or the EMM before passing the upcall on to the application.

To ensure integrity of the execution environment, CDSA recommended that applications and service modules perform secure linkage checks of CSSM. Elective module managers pose a problem for these checks. The EMM's dynamic nature is transparent to the application and to the service module, hence the EMM not included in the CSSM authentication and secure linkage checks performed by the application or the service provider during CSSM_ModuleAttach() processing. If applications and service modules must perform secure linkage checks on every invocation, then EMM transparency may not be possible. To achieve complete cover for linkage checks, applications and service modules should use Module Directory Service (MDS) facilities to locate the EMM module and perform cross-check. The verified address range for the EMM can be added to the verified address range of CSSM for the purpose of secure linkage checks.

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. Two module managers can share state information by several different mechanisms:

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


Click here to return to the publication details.

Contents Next section Index