Previous section.
Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group
Introduction
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:
-
System Security Services
-
The Common Security Services Manager (CSSM)
-
Security Service Provider Modules
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.
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
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:
-
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.
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:
-
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.
-
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.
-
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:
-
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.
Click here to return to the publication details.