Previous section.

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


The Module Directory Services (MDS) provide facilities to describe and locate executable objects and their associated signed manifest integrity credentials.

MDS is a database and access methods used primarily to support secure loading and use of software modules. It is a system-wide service available to all processes. MDS makes special accommodation for CDSA-defined modules, providing access to registration and capabilities information.

Common Data Security Architecture

MDS provided a locator service that is used extensively by the Common Security Services Manager (CSSM) within the Common Data Security Architecture (CDSA). CDSA defines an open, extensible architecture in which applications can selectively and dynamically access security services.

Common Data Security Architecture for all Platforms shows the three basic layers of the CDSA:

Figure: Common Data Security Architecture for all Platforms

The Common Security Services Manager (CSSM) is the core of CDSA. CSSM manages categories of security services and multiple discrete implementations of those services as security service modules.


Applications request security services through the CSSM security API or via layered security services and tools implemented over the CSSM API. Security service modules perform the requested services. Four basic types of module managers are defined:

Over time, new categories of security services may be defined, and new module managers may be required. CSSM supports elective module managers that dynamically extend the system with new categories of security services.

Below CSSM are security service modules that perform cryptographic operations, manipulate certificates, manage application-domain-specific trust policies, and perform new, elective categories of security services. Independent software and hardware vendors can provide security service modules as competitive products. Applications use CSSM module managers to direct their requests to modules from specific vendors or to any module that performs the required services. A single module can provide one or more categories of service. Modules implementing more than one category of service are called multi-service modules.

CSSM core services support:

CDSA components use MDS to locate executables for CDSA components and the integrity credentials associated with those components. CDSA components and credentials can be stored anywhere on a system (local or remote). MDS allows components to move as required by general system management, while retaining secured use of those components.


Module Directory Services (MDS) is a platform-independent registry service designed to support secure loading and secure use of software modules. MDS is a system-wide service available to all processes. CDSA is a seminal user of MDS. MDS defines a basic Object Directory schema to name and locate software components and the signed manifest credentials associated with those software components. Each software component in the Object Directory is uniquely named by a GUID (Globally Unique ID). CDSA defines an additional set of schemas to store CDSA-specific security attributes of all CDSA components. CDSA components use the MDS-managed data to:

New schemas can be defined to store the properties and capabilities of Elective CDSA Modules as they are defined over time. CDSA applications can also define MDS schemas and use MDS services. CDSA components use MDS managed data to support CDSA's software authentication and integrity checking procedure, known as bilateral authentication.

MDS supports the CDSA Data Storage Library APIs to query the MDS database. These APIs are familiar to CDSA application developers. The database creation and schema creation interfaces are limited to authorized use by database administrators.

The CDSA-specific schema and data formats are well defined in this specification. Interoperability is achieved through these CDSA-specific schema and data formats. Using this schema and MDS query services, CDSA service providers and applications can interact while maintaining a high degree of autonomy. MDS enforces unique values for primary database keys. MDS can implement indexes over primary keys or dependent attributes to improve query performance.

While MDS is a general service available to all applications, the MDS-defined Object Directory schema and the MDS interfaces are defined here to support CDSA as its first user and for completeness of the CDSA specifications.

The general MDS architecture and its use by CDSA is shown in the following figure.

Figure: MDS Architecture

MDS Installation and Access

MDS is a single, system-wide service. When CDSA is installed on a system, the CDSA installation procedure must ensure that MDS is available on the system1. The CDSA schema is generated at MDS installation time. Updates to the schema are made by administrative tools, such as the installation program

MDS may be accessed through either static or dynamically loaded libraries. MDS interfaces are publicly accessible. MDS is a signed software service. Users of MDS can check the integrity of MDS prior to using MDS services. This ensures the caller that the MDS access library has not been previously compromised. This concern, however, is avoided if the library is statically bound to the caller and the caller has successfully performed an integrity self-check. MDS signed manifest credentials are stored in a well-known location outside of MDS to allow bootstrapping of the integrity services model. Once MDS is available to a process, MDS is the primary source of signed manifest credentials for module self-check and cross-check operations. The MDS Object Directory and the CDSA-defined Directory can be queried by all applications on the platform.

Using MDS in Integrity Verification Protocols

Software modules can verify the credentials and integrity of any software module registered in the MDS database. The module performing the cross-check must obtain some information about the module being checked, namely, the target module's credentials and installation location.

MDS is used to support the three-step integrity cross-check procedure shown in Software Module Cross-Check. Module (A) needs to verify the authenticity and integrity of module (B). To accomplish this task, Module A must locate the on-disk executable image of module B, compute a cryptographic hash of B, and compare the result with a correct, known hash value. If modules A and B are manufactured separately, module A will not have apriori knowledge module B's correct hash value. The MDS service associates a module's GUID with the module's signed manifest credentials, and the module's installation location. The GUID is the unique database key for retrieving an Object Directory entry.

Figure: Software Module Cross-Check

Module A uses MDS to support the cross-check procedure as follows:

  1. Module A queries MDS for module B signed manifest credentials based on the GUID for module B. Module A can learn the GUID for module B at manufacturing time or from some runtime source. Typically the software development kit for module B includes the GUID for module B.

  2. MDS retrieves the signed manifest and module B install path based on GUID B. The retrieved database entry was created by the installation program for module B.

  3. Using the installation path information, module A locates the executable for module B and computes a cryptographic hash of the executable. The hash value for module B is included in the signed manifest for module B. Module A verifies the signature on the manifest and then compares the computed hash value with the hash value contained in the signed manifest. If the values are equal, then module A can trust module B. Trust means that module A can load and transfer execution control to module B.

MDS managed data can also be used to support the CDSA bilateral authentication protocol and authentication over arbitrary CDSA call graphs. Examples using MDS are provided in later sections that define these protocols.

Multi-User Access Model

MDS data is shared among all processes using the MDS service. MDS enforces data consistency by serializing access to MDS relations. Write operations wait for all read operations to complete before tables are updated. Relations may be read simultaneously by multiple threads and processes.

Users requiring write access to MDS schema or MDS databases must be appropriately authorized. Authorization is based on access privileges granted to software modules through their signed manifest credentials. Any software module (with or without credentials) is granted read-only access to MDS schema and MDS databases.

API Overview

The MDS API leverages CDSA DL interfaces but uses MDS specific interfaces for initialization and MDS installation. All users of MDS must initialize/terminate using:

Installation and configuration applications can use the following functions to define and modify MDS schema:

Upon successful initialization MDS returns a table of function pointers for MDS services. The function interfaces are a consistent subset of those defined by the CDSA Data Storage Library Interface (DLI).

The DL interfaces supported by MDS are:

The MDS Object Directory and CDSA Directories are defined in this specification. Creation of these databases is encapsulated in the MDS_Install operation. These schemas are well defined and do not require parsing functions to interpret contents. MDS controls access to MDS databases based on authentication credentials presented in the DbOpen operation.


The CDSA installation procedure may be required to install MDS also.

Click here to return to the publication details.

Contents Next section Index