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:
Verification of credentials for each dynamic component in CDSA
Verification of manifests describing the capabilities of each add-in
security service module
Verification of signatures over the dynamic component's object code
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 certificate, which is part of a chain of X.509 certificates
A set of digitally-signed code files, which contain the executables for
A digitally signed manifest, which records the capabilities of the
A signature file, which records all of the signatures on the object
files and manifest
A Module's Certificate Chain
The certificate chain is constructed as follows:
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.
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
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
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
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.