z/OS Open Cryptographic Services Facility Application Programming
Previous topic | Next topic | Contents | Index | Contact z/OS | Library | PDF


Module Management Services

z/OS Open Cryptographic Services Facility Application Programming
SC24-5899-01

The OCSF module management functions support module installation, dynamic selection and loading of modules, and querying of module features and status. System administration utilities use OCSF install and uninstall functions to maintain service provider modules on a local system.

Applications select the particular security services they will use by selectively attaching service provider modules. These modules are provided by Independent Software Vendors (ISVs). Each module has an assigned Globally Unique ID (GUID) and a set of descriptive attributes to assist applications in selecting appropriate modules for their use. A module can implement a range of services across the OCSF APIs (e.g., cryptographic functions, data storage functions) or a module can restrict its services to a single OCSF category of service (e.g., Certificate Library (CL) services only). Modules that span service categories are called multiservice modules.

Applications use a module's GUID to specify the module to be attached. The CSSM_ModuleAttach function returns a handle representing a unique pairing between the caller and the attached module. Applications must provide this handle as an input parameter when requesting services from the attached module. OCSF uses the handle to match the caller with the appropriate service module.

The calling application uses the handle to obtain all types of services implemented by the attached module. Figure 4 shows how the handle for an attached Dual_Provider service provider is used to perform cryptographic operations and persistent storage of certificates. The single handle value can be used as the CSPHandle in cryptographic operations and as the DLHandle in data storage operations.

Multiple calls to attach are viewed as independent requests. Each attach request returns separate, independent handles that do not share execution state.

Before attaching a service module, an application can query the OCSF registry to obtain information on:

  • Modules installed on the system
  • Capabilities (and functions) implemented by those modules
  • GUID associated with a given module.

Applications use this information to select a module for use. A multiservice module has multiple capability descriptions associated with it. Some areas, such as Cryptographic Service Provider (CSP) and Trust Policy (TP), may have multiple independent capability descriptions for a single functional area. There is one OCSF registry entry for a multiservice module. That entry records all service types for the module. OCSF returns all information about a module's capabilities when queried by the application.

Figure 4. Dual_Provider Cryptographic Services and Persistent Storage Services

Applications can query about OCSF themselves. OCSF provides several functions to assist applications in ensuring that the current OCSF version meets the application's needs. CSSM_GetInfo returns version information about OCSF. CSSM_Init verifies whether the application's expected OCSF version is compatible with the currently running OCSF version. (The general function to query service provider module information also returns the module's version information.)

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014