Previous section.

Common Security: CDSA and CSSM
Copyright © 1997 The Open Group

CSSM Integrity Services-The Foundation

The fundamental CSSM mechanism supporting general, policy-based control of service offerings and service usage is authentication. Authentication is performed by a three step verification process:

The interfaces for these services are described in detail in the CSSM Embedded Integrity Services Library API Spec and is summarized here.

CSSM uses this mechanism to authenticate dynamic components that attach to CSSM.

CSSM Integrity Services can verify the identity and the integrity of each component that attaches to the CSSM. Identity verification of an add-in module is based on an X.509 certificate chain. Integrity verification of an add-in module is based on a sequence of signature verifications covering signed object code files and signed manifests, describing a module's capabilities.

A complete set of credentials must be created for each add-in security service module as part of the module manufacturing process. A full set of credentials includes:

A Module's Certificate Chain

The certificate chain is constructed as follows:

  1. A "root" certificate, owned by a CSSM vendor is used to sign a module manufacturer's certificate. The manufacturer's certificate identifies the manufacturer as a licensed vendor who has agreed to comply with all specified licensing conditions.

  2. The manufacturer's certificate is used to sign the specific module's certificate. This is the manufacturer's certification of the product and assurance that the distribution and execution of the product will comply with all applicable export, import, and use restrictions. The root certificate owner is not responsible for the behavior of the manufacturer's product.

Checking a Module's Credentials

The certified module presents its complete credentials (certificate, manifest, and object code files) to CSSM during the installation process. CSSM verifies the credentials and if they are valid, the installation process is completed. It is of the utmost importance that the object code files and the manifest be signed using the private key associated with the module's certificate. This tightly binds the identity in the certificate with "what the module is" (in this case, the object code files themselves), and with "what the module claims it is" (in this case, the capability descriptions in the manifest).

When attaching a module, CSSM retrieves the module's credentials, verifies them and executes a bilateral authentication procedure with the attaching module. CSSM has the equivalent credentials which can be verified by the attaching module. If the bilateral verification is successful, the attach is completed. CSSM integrity services must embed a mechanism for validating module or application certificates. This mechanism verifies the certificate signature chain starting with the root public-key that is stored within CSSM. The removal or alteration of the public root key or the signature verification mechanism itself is deemed to be at least as hard as re-implementation of the entire CSSM infrastructure.

Applications can also be issued credentials during their manufacturing process. These credentials can certify that the application is exempt from a class of policy controls, can list required security services, and can identify the specific service modules required to perform those services.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.
You should also read the legal notice explaining the terms and conditions relating to the CDSA documentation.

Contents Next section Index