Common Data Security Architecture (CDSA) White Paper

Chapter 1 65
Common Data Security Architecture (CDSA) White Paper
Validating the CSP Credentials
Validating the CSP Credentials
Before a CSP add-in module can be loaded by CSSM, CDSA must ensure that the module has
not been tampered with. This is done by performing a series of verifications on the shared
library.
Every CSP add-in module has a corresponding credential file that contains a digitally signed
hash of the CSP shared library. Every time an application uses the CSP, a new SHA-1 hash of
the CSP shared library is calculated and compared with the pre-calculated hash in the shared
library’s corresponding credential file.
CDSA operations proceed only when the pre-calculated hash and the dynamically calculated
hash match exactly and the signature authenticating the pre-calculated hash is verified.
The signature algorithm utilized is DSA, the hash algorithm SHA-1.
The Credential File
The credential file is a ZIP-formatted file containing three uncompressed files:
• .MF file, containing the hash of the shared library and the library name. Also called
manifest file.
• .SF file, containing the hash of data in the .MF file This hash serves to validate the
contents of the .MF file. Also called signature file.
• .DSA file, containing the signer’s DSA signature on the .SF file. The .DSA file also
contains X.509v3 certificates.
.DSA file contents are in a PKCS7 format [4].
For specifications of ZIP format, see “ZIP format” on page 333.
X.509 Certificate Chain
The embedded certificates provide a validation path from the root to the signer’s certificate.
The HP CDSA software has one root public key embedded in its framework. If the X.509
certificate chain cannot be constructed using the embedded key, the credential file cannot be
validated.
The certificate chaining concept is illustrated in Figure 1-8 on page 66. Certificate 1 is signed
with the root private key. Certificate 1 can be verified using the public key in Certificate 0.
Certificate 2 is signed with Certificate 1’s private key and can be verified using Certificate 1’s
public key. Certificate 3 is signed with Certificate 2’s private key and can be verified using