Previous section.

Common Security: CDSA and CSSM, Version 2 (with corrigenda)
Copyright © 2000 The Open Group

Introduction

The Common Data Security Architecture (CDSA) is a set of layered security services that addresses communications and data security problems in the emerging Internet and Intranet application space. Intel Architecture Labs (IAL) defined the CDSA to:

The motivation for a robust, broadly diffused, multi-platform, industry-standard security infrastructure is clear. The definition of such an infrastructure, however, must accommodate the emerging Internet and Intranet business opportunities and address the requirements unique to the most popular client systems, namely personal computers (PCs) and networked application servers. CDSA focuses on security in peer-to-peer distributed systems with homogeneous and heterogeneous platform environments. The architecture also applies to the components of a client-server application. The CDSA addresses security issues in a broad range of applications, including:

The architecture addresses the security requirements of this broad range of applications by:

The Threat Model

The need for a security infrastructure like CDSA has been fueled by the desire to provide new applications in the face of increasing incidents of unauthorized access and manipulation of computer systems, data, and communications. Malicious observation and manipulation of computer systems can be classified into three categories, based on the origins of threats. The origins of threats are expressed in terms of the security perimeter that's been breached in order to effect the malicious act:

Category I
The malicious threat originates outside of the computer system. The perpetrator breaches communications access controls, but still operates under the constraints of the communications protocols. This is the standard hacker attack.

Category I attacks are best defended against by correctly designed and implemented access-control protocols and mechanisms, and proper system administration, rather than by the use of secured software.

Frequently, the goal of a Category I attack is to mount a Category II attack.

Category II
The malicious attack originates as software running on the platform. The perpetrator introduces malicious code onto the platform and the operating system executes it. The attack moves inside the communications perimeter, but remains bounded by the operating system and BIOS (Basic Input-Output System), using their interfaces. The malicious software may have been introduced with or without the user's consent. This is the common virus attack.

Examples include viruses, Trojan horses, and software used to discover secrets stored in other software (such as another user's access control information). Category II attacks tend to attack classes of software. Viruses are a good example. Viruses must assume certain coding characteristics to be constant among the target population, such as the format of the execution image. It's the consistency of software across individual computer systems and even across platforms that enables Category II attacks.

Category III
The perpetrator completely controls the platform, may substitute hardware or system software, and may observe any communications channel (such as using a bus analyzer). This attack faces no security perimeter and is limited only by technical expertise and financial resources.

In an absolute sense, Category III attacks are impossible to prevent on the computer system. Defense against a Category III attack merely raises a technological bar to a height sufficient to deter a perpetrator by providing a poor return on investment. That investment might be measured in terms of the tools necessary, or the skills required to observe and modify the software's behavior. The technological bar, from low to high would be:

The CDSA goal is to defend against Category II and Category III attacks, up to but not including the level of specialized hardware analysis tools. This provides a reasonable compromise. As threat follows value, this level of security is adequate for low-to-medium-value applications and high-value applications where the user is unlikely to be a willing perpetrator (such as applications involving the user's personal property).

Common Data Security Architecture

The Common Data Security Architecture is a set of layered services and associated programming interfaces, providing an integrated, but dynamic set of security services to applications. The lowest layers begin with fundamental components such as cryptographic algorithms, random numbers, and unique identification information. The layers build up to digital certificates, key management mechanisms, integrity and authentication credentials, and secure transaction protocols in higher layers.

Architectural Assumptions

The CDSA design follows five architectural principles:

The architecture is built on two fundamental models:

The ability of client platforms to accommodate these two new technologies is critical to the success of such platforms for digital commerce and information management as the Intranet extends seamlessly into the Internet.

Architectural Overview

CDSA defines an open, extensible architecture in which applications can selectively and dynamically access security services. The Common Data Security Architecture for all Platforms shows the three basic layers of the Common Data Security Architecture:

It is the goal of CDSA to be a leading, multi platform security architecture that is horizontally broad and vertically robust. Horizontal breadth is achieved by an extensible design that can incorporate new categories of security services and the application programming interfaces for accessing those services. A vertically robust architecture defines layers that can support a full range of applications from security-naive to security-aware to a security service.

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 add-in security modules. CSSM:

Applications request security services through the CSSM security API, or via layered security services and tools implemented over the CSSM API. The requested security services are performed by add-in security modules. Five basic types of module managers are defined:

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

Below CSSM are add-in security modules that perform cryptographic operations and manipulate certificates. Add-in security modules may be provided by independent software and hardware vendors as competitive products. Applications use CSSM to direct their requests to modules from specific vendors or to any module that performs the required services. Applications can use multiple service providers of all types concurrently. Add-in modules augment the set of available security services.

CDSA's extensible architecture allows new module types to be included that accommodate prudent division of labor. Signing services and key management services can be added at the System Security Services Layer and the Security Add-in Modules layer in CDSA. An appropriate degree of visibility of lower layers may be reflected at higher layers, such that a complete security profile can be managed uniformly. Independent software and hardware vendors may specialize in their chosen area of expertise and package their products as appropriate. For example, hardware-specific cryptographic device vendors can also provide tamper-resistant storage facilities in the same add-in module.


Figure: The Common Data Security Architecture for all Platforms

Layered Security Services

Layered Security Services are between application and basic CSSM services. Software at this layer may:

Applications can invoke the CSSM APIs directly, or use layered services to access security services on a platform. The use of security services through a layered service can be opaque. Legacy layered services, such as the Sockets protocol and HTTP, can be enhanced with security features for privacy and authentication. If this can be accomplished without changing the service interface, then applications can benefit from these services without change to the application code. Examples include:

Additionally, new security-related layered services that define new interfaces can be developed. Applications that have only a high-level conceptual awareness of security can use these services with some modification of the application code. Examples include:

Another category of layered service is the language interface adapter. A language adapter extends the CSSM API calls (defined in the C language) to other programming languages and programming environments. These language-specific wrappers may export the CSSM C language API calls directly to another language, or may abstract the CSSM concepts and present them through the target language. For example, a Java package defines object-oriented classes and methods by which Java applications and Java applets can use security functionality provided by and through CSSM.

CSSM accommodates many new and existing standards as layered services. The broad spectrum of layered security services is easier to implement by virtue of CSSM's modularity. Layered service developers are included in the category of application developers for purposes of this document.

Common Security Services Manager Layer

The second level of CDSA is the Common Security Services Manager (CSSM). CSSM, the essential component in the CDSA, integrates and manages all categories of security service. It enables tight integration of individual services, while allowing those services to be provided by interoperable modules. The CSSM defines a rich, extensible API to support developing secure applications and system services, and an extensible SPI supporting add-in security modules that implement building blocks for secure operations.

CSSM provides a set of core services that are common to all categories of security services. Examples include:

Module managers within CSSM are responsible for matching API calls to one or more SPI calls that result in an add-in service module performing the requested service.

CSSM APIs are logically partitioned into functional subsets. The goal of this logical partitioning is to assist application developers in understanding and making effective use of the security APIs. CSSM itself is partitioned into a set of core services, context management services, integrity services, and a set of basic module managers. There is one module manager (MM) for each functional subset of the CSSM API. Each Module Manager concurrently manages service modules for the manager's respective functional category. CSSM defines five basic categories of service and their corresponding managers:

The Cryptographic Services Manager administers the Cryptographic Service Providers that may be installed on the local system. It defines a common API for accessing all of the Cryptographic Service Providers that may be attached and used by any caller in the system. All cryptography functions are implemented by the CSPs.

The Trust Policy Services Manager administers the trust policy modules that may be installed on the local system. It defines a common API for these libraries. The API allows applications to request security services that require "policy review and approval" as the first step in performing the operation. Approval can be based on the identity, integrity, and authorization represented in a group of digital certificates. All domain-specific policy tests and decisions are implemented by the add-in trust policy module.

The Certificate Services Manager administers the Certificate Libraries that may be installed on the local system. It defines a common API for these libraries. The API allows applications to manipulate memory-resident certificates and certificate revocation lists. Operations must include creating, signing, verifying, and extracting field values from certificates. All certificate operations are implemented by the add-in certificate libraries. Each library incorporates knowledge of certificate data formats and how to manipulate that format.

The Data Store Services Manager defines an API for secure, persistent storage of certificates, certificate revocation lists (CRLs) and other security objects. The API must allow applications to search and select stored data objects, and to query meta-information about each data store (such as its name, date of last modification, size of the data store, and so on). Data store operations are implemented by add-in data storage library modules.

The Authorization Computation Services Manager administers the Authorization Computation Service Providers that may be installed on the local system. It defines a common API for accessing Authorization Computation Service Providers. The API defines a general authorization evaluation service that computes whether a set of credentials and samples are authorized to perform a specific operation on a specific object. All authorization evaluation functions are implemented by an AC service provider.

CSSM also extends to dynamically include elective module managers. These module managers define additional APIs for a new category of service. An example of an elective category of security services is Key Recovery. A Key Recovery Module Manager (KRMM) defines a set of APIs that provide applications access to key recovery services and SPIs, that allow vendors to implement competitive key recovery service modules. If an application chooses to use an elective service API, CSSM extends the services available to that application by dynamically attaching the appropriate module manager and an add-in service module to the running CSSM.

Two additional CSSM core services include:

As the foundation of the security framework, CSSM must provide a set of integrity services that can be used by CSSM, module managers, add-in modules, and applications to verify the integrity of themselves, and the integrity, identity, and use authorizations of other components in the CSSM environment.

CSSM's minimal set of self-contained security services establishes its security perimeter. These self-contained services incorporate techniques to protect against category II and most category III attacks. Because application and add-in security service modules are dynamic components in the system, CSSM uses and requires the use of a strong verification mechanism to screen all components as they are added to the CSSM environment.

Applications can extend CSSM's security perimeter to include themselves by using bilateral authentication, integrity verification, and authorization checks during dynamic binding. These procedures and interfaces are defined in the CSSM Embedded Integrity Services Library API specification. By extending the security perimeter, CSSM helps applications address category II and category III attacks.

CSSM provides security context services to assist applications in specifying and managing the numerous parameters required for cryptographic operations. CSSM assists by managing the data structures used to hold these parameters.

Security Add-In Modules Layer

CSSM supports an extensible set of add-in service modules. The five basic service categories are:

Every instance of an add-in module must be installed with the Module Directory Services (MDS) making the module accessible for use on the local system. The installation process persistently records the module's identifying name, a description of the services it provides, and the information required to dynamically load the module. Applications can query MDS to obtain information used to select one or more service modules based on their capabilities.

Module implementors can provide multiple categories of service in a single module. These multi-service add-in modules separate module packaging from the application developer's functional view of CSSM APIs. The module simply inserts multiple MDS records defining interfaces in multiple categories. For example, a hardware cryptographic token vender may register CSP and DL interfaces which may capitalize on the vendor's tamper-resistant persistent storage technology. Other vendors may find synergy in supporting both TP and CL modules.

Cryptographic Service Providers (CSPs)
Cryptographic service providers (CSPs) are modules equipped to perform cryptographic operations and to securely store cryptographic keys. A CSP may implement one or more of these cryptographic functions:

A CSP may be instantiated in software, hardware, or both.

CSPs can be constructed to provide a subset of the services listed above. These subsets should be self-consistent. If an operation O is supported then related operations, such as the inverse of operation O should also be supported. CSPs must also provide:

It is highly desirable that CSPs support key import and key export. A primary goal of key export is portability of keys. Some CSPs can achieve this goal by physical portability of the cryptographic device versus logical portability of a key. CSPs should not reveal key material unless it's been wrapped. A CSP or an independent module can also deliver key management services, such as key escrow, key archive, or key recovery.

Trust Policy Modules (TPs)
Trust policy modules implement policies defined by authorities and institutions. Policies define the level of trust required before certain actions can be performed. Three basic action categories exist for all certificate-based trust domains:

The CSSM Trust Policy API defines the generic operations that should be supported by every TP module. Each module may choose to implement the subset of these operations that are required for its policy.

When a TP function has determined the trustworthiness of performing an action, the TP function may invoke certificate library functions and data storage library functions to carry out the mechanics of the approved action.

Certificate Library Modules (CLs)
Certificate library modules implement syntactic manipulation of memory-resident certificates and certificate revocation lists. The CSSM Certificate API defines the generic operations that should be supported by every CL module. Each module may choose to implement only those operations required to manipulate a specific certificate data format, such as X.509, SDSI, and so on.

The implementation of these operations should be semantic-free. Semantic interpretation of certificate values should be implemented in TP modules, layered services, and applications.

The CSSM architecture makes manipulation of certificates and certificate revocation lists orthogonal to persistence of those objects. Hence, it is not recommended that CL modules invoke the services of data storage library modules. Decisions regarding persistence should be made by TP modules, layered security services, and applications, and carried out by DL modules.

CL modules may implement their services locally or remotely. For example, certificates can be issued by a remote CA. Access to that CA process can be implemented using standard message protocols such as PKCS#10, and may be transport-independent.

Data Storage Library Modules (DLs)
Data storage library modules provide stable storage for security-related data objects. These objects can be certificates, certificate revocation lists (CRLs), cryptographic keys, integrity and authentication credentials, policy objects, or application-specific objects. Stable storage could be provided by a

Each DL module may choose to implement only those operations required to provide persistence under its selected model of service.

The implementation of DL operations should be semantic-free. Semantic interpretation of stored objects such as certificate values, CRL values, key values, credentials, and policy should be interpreted by layered services, TP modules and applications. To ensure necessary interoperability among DL modules, a minimal schema is defined for each DL record type. The schema prescribes the minimum set of attributes that all applications can use to select records from a data store. A DL module can support additional application-defined and modules-defined attributes for a DL record type.

An extensible function interface is defined in the DL API. This mechanism allows each DL to provide additional functions to store and retrieve security objects, such as performance-enhancing retrieval functions or unique administrative functions required by the nature of the implementation.

Authorization Computation Modules (ACs)
Authorization Computation modules implement an authorization evaluation mechanism based on caller inputs. Callers provide:

The AC evaluation engine determines whether the request is authorized based on the assumptions and the caller credentials. The AC Module can provide other services related to authorization computations through the CSSM_AC_PassThrough() function.

Multi-Service Library Module
Vendors building add-in security module products can provide services for CSSM APIs from multiple CSSM-functional categories. The result is a multi-service add-in module. A multi-service module is a single, dynamic add-in module that implements CSSM functions from two or more functional categories of the CSSM APIs.

Applications use distinct runtime identifiers to reference the module for each category of service. The multiple identifiers reference a single, dynamic service module implementation. Multi-service add-in modules separate product packaging from the application developer's functional view of CSSM APIs.

Interoperability Goals

Interoperability is essential among CDSA components and among instances of CDSA service modules. CDSA's interoperability goals include:

These goals could be achieved by the following combined efforts:

Results of the first two efforts can be seen in the CDSA specification set. The CDSA conformance test suite checks API conformance of a CSSM implementation and SPI conformance for add-in service modules. All adopters of CDSA specifications, in whole or in part, are expected to use the conformance test suite to determine conformance of their products and to increase interoperability with other CDSA-based products.

The CDSA conformance test suite for a CSSM implementation checks:

The CDSA conformance test suite for an add-in service module must use a conformant real (or dummy) CSSM implementation to test add-in service modules for:

The conformance test suites contribute to interoperability, but they are not the complete solution. The conformance test suites are not intended to be:

Complete multi-vendor interoperability is outside the scope of typical conformance testing. Industry support could be demonstrated by voluntary participation in interoperability testing events organized by standards organizations, or a committee of active, CDSA developers.

CDSA bases integrity of the runtime environment on signature verification of a CDSA component's object code and other signed credentials. Object code signing is inherently platform-specific. To ensure that the signature of a service provider module can be correctly checked on all instances of a specific base-platform type, there must be a standard signing mechanism defined and used to sign all object code modules for that base-platform type. Without this standard, executable modules must be platform-provider specific, which is more constraining than being specific only to the base-platform type. CDSA defines the integrity service interfaces to perform signing and verifying on all platforms. CDSA reference implementations pave the way for the standardization of object code signing mechanisms for each base-platform type.

Contents Next section Index