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:
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.
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.
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).
CDSA is built up from a set of horizontal layers, each providing services to the layer above it. This approach is portable, adaptable, and modular.
The CDSA is fully disclosed for peer review, standardization, and adoption by the industry.
Components of each layer can be chosen as separate modules. An extensible framework supports inserting module managers for new, elective categories of security services. Extensibility fosters industry growth by encouraging development of incremental functionality and performance-competitive implementations of each add-in module.
The CDSA can manage security details, so individual applications do not need to be concerned with security-related details. The CSSM APIs define logical categories of security services to assist developers in easily adding security to their application.
The CDSA incorporates emerging technologies for data security. Fundamental technologies include portable digital tokens and digital certificates.
The architecture is built on two fundamental models:
These are used as a
person's digital persona for commerce, communications, and
access control. These digital tokens are encryption modules,
with some amount of encrypted storage. They can be software
or hardware, depending on the application's security needs.
They come in various form factors, and may have multiple
functions aggregated into a single device, such as a digital
wallet.
These can be used to embody trust. These certificates do not create any new trust models or relationships. They are the digital form for current trust models. A person may have a certificate for each trust relationship (such as multiple credit cards, checkbooks, employer ID). Certificates are used for identity. They can also carry authorization information.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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 |