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 five 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.
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. 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:
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.) 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 algorithm configuration parameters for a service provider in the form of a cryptographic context. Applications may create, delete, and modify these contexts as necessary. CDSA components are checkable if the component has a manifest. Checkable components include add-in service modules, CSSM itself, and applications that use CSSM.
In summary, the direct services provided by CSSM through its API calls include:
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 load, attach, and detach. The number, categories, and contents of the service implementations are determined by the module developer.
The MDS Common relation stores the general attributes applicable to the four basic module types. Module installation must insert a new record in this relation, identifying and locating the new module.
MDS defines the EMM Service Provider relation to store general attributes of elective service providers. When installing a service module for an elective category of service, the installation program must insert a new record in this relation, identifying and locating the new module.
In addition to the Common relation, MDS defines numerous relations based on the basic categories of security services. These relations store detailed descriptions of the services provided by the module. New elective categories of service will define additional service-specific relations to store detailed descriptions of those modules that provide that type of service. Applications will search these service-specific relations to select appropriate service modules. The module installation program should consider inserting descriptive records into these additional relations.