Fundamentals of Secure Delivery
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
The following sections discuss the fundamental parts of Secure Delivery, including CDSA architecture, the certificate, the manifest, and validation routines.
Secure Delivery is built on the Common Data Security Architecture (CDSA), which is a multilayered security infrastructure that provides an integrated and dynamic set of security services to applications. CDSA provides a secure execution environment using two mechanisms, bilateral authentication and secure linkage.
CDSA checks the integrity of CDSA modules as they are dynamically loaded into the CDSA environment. A bilateral authentication procedure is designed for two entities to establish trust in the identity and integrity of each other. When loading a service provider module CDSA requires that the attaching party participate in this authentication protocol. If authentication fails, the module is denied the ability to be used by CDSA. Both parties in the bilateral authentication procedure must have signed credentials that bind them to the trust hierarchy used by CDSA.
Bilateral authentication can also be performed between applications and the CDSA. The only difference is that the application takes on the role of the initiator and verifies CDSA before loading and using it. Secure Delivery is an application that performs bilateral authentication.
For a CDSA application or CDSA itself, Secure Linkage checks that the address called is actually in the code module of the shareable image. For the called component, the return address must be verified as being within the calling module.
For the purpose of Secure Delivery, Secure Linkage is not of interest.
CDSA provides tools to generate X509 certificates. These tools are invoked along with additional features but the format of the certificates remains the same. For information about generating CDSA certificates, see “Writing Signed Applications”.
CDSA also provides a tool to create a digital signature using the X509 certificates. The digital signature takes the form of a separate file called a manifest. The manifest contains the encrypted digest of the target file and the X509 certificates of the signers. This data is sufficient to guarantee the identity of the signer of a file and the authenticity of the file's contents.
The manifest is the key part of the mechanism that is used for bilateral authentication. It is the signed credential that each component must have to carry out the bilateral authentication.
When software kits are built, a manifest should be generated for each kit. This is the signing process. When Secure Delivery is started, the accompanying manifest is used to accomplish the bilateral authentication. This is the validation process.
Table 3-1 lists the CDSA programs that implement Secure Delivery.
Table 3-1 CDSA Secure Delivery Programs
| CDSA Program | Function |
|---|---|
CDSA$SD_SIGN.COM | Generates manifests. See “The CDSA$SD_SIGN.COM Procedure”. |
CDSA$REVOKE.EXE | Revokes a certificate. See “CDSA$REVOKE.EXE”. |
| CDSA$VALIDATE.EXE (new in V2.2) | Checks manifests. See “CDSA$VALIDATE.EXE”. |
CDSA$VALIDATE_LIBSHR.EXE (A CDSA_FileValidate API is implemented in CDSA$VALIDATE_LIBSHR.EXE) | Validates files programmatically. See “The CDSA$VALIDATE_LIBSHR.EXE File”. |
| |
| |
| |
 | NOTE: Validation programs are CDSA signed applications and are mutually authenticated with the rest of CDSA to prevent tampering. |
| |
| |
| |