Common Data Security Architecture (CDSA) White Paper
70 Chapter1
Common Data Security Architecture (CDSA) White Paper
Validating the CSP Credentials
Bilateral Authentication
In the final set of integrity checks, known as bilateral authentication, the CSP add-in module
checks the integrity of the CSSM manager that requested the CSP’s loading to ensure the
CSSM has not been tampered with.
1. The CSP reconstructs the certificate chain from the root public key embedded in the CSP
shared library to the CSSM signer’s certificate, using the certificates embedded in the
credential file.
2. Once the certificate chain is verified, the signature in the .DSA file is verified, using the
public key of the last certificate in the chain (that is, the CSSM signer’s certificate).
3. An SHA-1 hash is calculated of the CSSM section in the .MF file and compared to the hash
in the .SF file.
4. If the hashes match, an SHA-1 hash of the CSSM shared lbrary is calculated and
compared to the hash n the .MF file.
5. If the hash matches, the CSP looks for the function that called the bilateral authentication
function (AddInAuthenticate()) and verifies that the function was called by the CSSM
shared library.
After this is done, the integrity checks for the loaded shared library are complete. At this
point, another add-in can be loaded and verified, if necessary.
In-Memory vs. Static Checking
A difference exists in the way NT and HP-UX ensures the integrity of processes in memory.
In the original Intel CDSA Framework, which operates on the Windows NT operating system,
hash evaluations are made of loaded shared libraries (called DLLs in NT) that are in
computer memory. These in-memory checks are necessary because the NT operating system
does not protect running processes from tampering. By contrast, once an HP-UX process is
running, it can be accessed only by the user who owns that process or the superuser. Thus,
in-memory checks are not performed in the HP CDSA Framework.