HP UX Security Products and Features Software manual Bilateral Authentication

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.

70 Chapter 1