Introduction

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

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

• System Security Services

• The Common Security Services Manager (CSSM)

• Security Service Provider Modules

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.

CSSM:

• Defines the application programming interface for accessing security services.

• Defines the service provider interface for security service modules.

• Dynamically extends the categories of security services available to an application.

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:

• Cryptographic Services Manager

• Trust Policy Services Manager

• Certificate Library Services Manager

• Data Storage Library Services Manager

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:

• Module management
  The module management functions are used by applications and by modules to support dynamic module selection and module load.

• Security context management
  Security context management provides secured runtime caching of user-specific, cryptographic state information for use by multi-step cryptographic operations, such as staged hashing. These operations require multiple calls to a CSP and produce an intermediate state that must be managed.

• System integrity services.
  CSSM, service modules, elective module managers, and optionally applications verify the identity and integrity of dynamic components as they are added to the runtime environment.

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.

MDS in CDSA

• Discover other available CDSA components

• Learn about the capabilities and properties of other CDSA components

• Locate the executables for CDSA components

• Locate the signed manifest credentials associated with a CDSA software component.

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.

MDS Installation and Access

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

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.

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

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

• MDS_Initialize()

• MDS_Terminate()

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

• MDS_Install()

• MDS_Uninstall()

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:

• DbOpen()

• DbClose()

• GetDbNames()

• GetDbNameFromHandle()

• FreeNameList()

• DataInsert()

• DataDelete()

• DataModify()

• DataGetFirst()

• DataGetNext()

• DataAbortQuery()

• DataGetFromUniqueRecordId()

• FreeUniqueRecord()

• CreateRelation()

• DestroyRelation()

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.

Footnotes

1.

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