HP Open Source Security for OpenVMS Volume 1: Common Data Security Architecture > Chapter 1 Introduction to CDSA

CDSA Overview

 » Table of Contents

 » Glossary

 » Index

The CDSA layered architecture is shown in Figure 1-1 “CDSA Layered Architecture”.

Figure 1-1 CDSA Layered Architecture

CDSA Layered Architecture

Applications call the Common Security Services Manager (CSSM), which implements the CDSA APIs. The CSSM also implements the CDSA integrity services and security contexts. The managers for each of the CDSA add-ins are also part of CSSM. CSSM is described in more detail in “Common Security Services Manager (CSSM)”.

In addition to the CSSM, CDSA includes the following:

Chapter 5 “CDSA Programming Concepts” provides sample C programs that illustrate the use of CDSA.

For additional information about CDSA, see the web links listed in the Preface.

Common Security Services Manager (CSSM)

The Common Security Services Manager (CSSM) is the heart of CDSA. It is a shared library (in SYS$SHARE:CDSA$INCSSM300_SHR.EXE) to which applications can link to obtain security services. It defines both the API and the service provider interface (SPI) for add-in security service modules. CSSM includes a set of core services that are common to all categories of security services. These services perform functions such as:

  • Dynamic attach of an add-in security module

  • Enforced integrity, authentication, and exemption verification when dynamically attaching services

  • Secure linkage checks on calls to service provider modules

  • General integrity services

Applications call functions in the CSSM API, which is fully specified by the CDSA Technical Standard (located at http://www.opengroup.org/onlinepubs/009609799/). API function names are prefaced with CSSM_ and are sometimes followed by the designation of the module that will actually handle the request. For instance, applications call CSSM_DL_DbOpen() to direct a DL module to open a data store. The associated SPI for this module is DL_DbOpen(). (The SPI interface is not directly callable by CDSA applications.)

An application begins by initializing its connection to CSSM using the CSSM_Init() routine. The application can use Module Directory Services (MDS) to inquire about available modules and their supported functionality (see an MDS example in “MDS Example Program”) or it can directly access a specific service provider by using its global unique identifier (GUID). The application loads the desired module using the CSSM_ModuleLoad() routine and then attaches to it using the CSSM_ModuleAttach() routine.

The CSSM is implemented as a sharable image on OpenVMS. Header files (in CDSA_SYSDIR:[INCLUDES]*.H) define the CSSM API.

Service Provider Modules

There are several types of add-ins for CDSA, each supporting a different security task:

On OpenVMS, service providers are implemented as sharable images.

Cryptographic Service Providers (CSPs)

The Cryptographic Service Providers (CSPs) are add-in modules to the Common Security Services Manager (CSSM). CSPs perform cryptographic operations and securely store cryptographic keys for the applications that call them through the CSSM API. A CSP can be in the form of software, hardware, or both.

Applications call these CSPs to provide authentication, data integrity, data and communication privacy, and nonrepudiation of messages to users.

CSPs implement the following cryptographic algorithms, among others, in one or more modes:

  • Bulk encryption algorithm in modes AES, DES, Triple DES, DESX, RC2, RC4, and RC5

  • Digital signature algorithm in modes RSA and DSS

  • Key negotiation algorithm in modes Diffie-Hellman and DSA

  • Cryptographic hash algorithm in modes MD4, MD5, and SHA1

CSPs also provide the following services:

  • Unique identification number: hard coded or random generated

  • Random number generator: attended and unattended

  • Encrypted data: symmetric keys and private keys

  • Secure key storage

  • Custom facilities unique to the CSP

The CSP module manager administers the CSPs that are installed on the local system. It defines a common API to access all of the Cryptographic Service Providers that can be attached and used by any caller in the system.

The specific security services API functions that are defined by the CSP module manager include the following service categories:

SignData
VerifyData
DigestData
EncryptData
DecryptData
GenerateKeyPair
GenerateRandom
WrapKey
UnwrapKey

CDSA on OpenVMS provides CSPs based on OpenSSL and RSA BSAFE:

  • OpenSSL CSP

    • Message authentication based on MD5 and SHA1

    • Symmetric encryption based on DES, Triple DES, and AES

  • RSA BSAFE CSP

    • Message authentication based on MD5 and SHA1

    • Symmetric encryption based on DES, triple DES, DESX, and RC2, RC4, and RC5.

    • Asymmetric encryption based on RSA, DSA, and Diffie-Hellman

The following sections discuss these topics:

Establishing a Session

An application establishes a session to select a particular CSP. Once attached, the application can initiate a cryptographic login session with the CSP. The application requests additional credentials, such as a passphrase or PIN, to gain access to specific keys and services managed by the CSP.

Within a module attach session or a cryptographic login session, an application creates, uses, and discards cryptographic contexts. A cryptographic context carries the parameters required to perform a cryptographic service. The cryptographic context can be used for the following:

  • A one-step cryptographic operation in which only one call is needed to obtain the result.

  • A cryptographic session of a multistaged cryptographic service, in which an initialization call is followed by one or more update calls, ending with a completion (final) call. For most cryptographic operations, the result is available after the final function completes its execution. An exception is staged encryption/decryption, in which each update call generates a portion of the result.

Depending on the class of cryptographic operations, individualized attributes are available for the cryptographic context. In addition to specifying an algorithm when creating the context, the application can also initialize a session key, pass an initialization vector, or pass padding information to complete the description of the session. A successful return value from the create function indicates that the desired CSP is available.

Functions are also provided to manage the created context. The cryptographic context contains most or all of the input parameters required for an operation. Some cryptographic service functions accept input parameters in addition to the CSP handle and the context handle. These input parameters always take precedence over any duplicate or conflicting parameters in the cryptographic context. When a context is no longer required, the application calls a DeleteContext function. Resources allocated for that context can then be reclaimed by the operating system.

Defining a Security Context

The application's associated security context defines parameter values for the low-level variables that control the details of cryptographic operations. For example, an application issuing a request to the EncryptData call can reference a security context that defines the following parameters:

  • The algorithm to be used (such as DES)

  • Algorithm-specific parameters (such as key length)

  • The object on which the operation is conducted (such as a set of buffers)

  • The cryptographic variables (such as the key)

Most applications use predefined, default contexts. Typically, a distinct context is used for encrypting, hashing, and signing. For an initialized application, these contexts change little, if at all, during the application's execution or between executions. This allows the application developer to implement security by manipulating certificates, using previously defined security contexts, and maintaining a high-level view of security operations.

Using Keys

In CDSA, there are two main types of cryptographic algorithms that use keys:

  • Asymmetric algorithms use one key to encrypt and a second key to decrypt. They are often called public-key algorithms. One key is called the public key and the other is called the private key or secret key. RSA (Rivest-Shamir-Adelman) is the most commonly used public-key algorithm. It can be used for encryption and for signing.

  • Symmetric algorithms use a single secret key for encryption and decryption. Both the sender and receiver must know the secret key. Well-known symmetric functions include DES (Data Encryption Standard) and IDEA. DES was endorsed by the U.S. Government as a standard in 1977. It's an encryption block cipher that operates on 64-bit blocks with a 56-bit key. It is designed to be implemented in hardware, and works well for bulk encryption. IDEA (International Data Encryption Algorithm) uses a 128-bit key.

Every CSP implements its own secure, persistent storage and management of private keys. To support chains of trust across application domains, CSPs support importing and exporting of public and private keys among remote and possibly foreign systems. To transfer keys, the CSP must be able to convert one key format into any other key format and to secure the transfer of private and symmetric keys.

Each CSP is responsible for securely storing the private keys it generates or imports from other sources. Additional storage-related operations include retrieving a private key when given its corresponding public key and wrapping private keys as key blobs for secure exportation to other systems.

On an OpenVMS Alpha system, the CSP stores private key files in EAYCSP.PRI and MAF_BSAFE.PRI. The protections on the key files are OWNER:READ,WRITE,DELETE. The key files are user-specific and are stored in the [.CDSA.PKD] subdirectory in the user's login directory.

Public Key Infrastructure (PKI)

The Public Key Infrastructure (PKI) is the state-of-the-art method, ultimately to be applied worldwide, for secure and confidential electronic transactions. It employs public and private keys.

The two PKI algorithms in widespread use are:

  • RSA-based algorithms

  • DSA-based algorithms

For RSA-based algorithms, CDSA uses the PKCS#1 standard for key representation. For DSA-based algorithms, no organization has published a standard. CDSA's representation of the DSA key is based on the DSA algorithm definitions in the FIPS 186 standard. (See the Preface for web links to this and other standards.)

A DSA public key is represented as a BER-encoding of a sequence list that contains the following:

PrimeModulus; /* p */ 
PrimeDivisor; /* q */
OrderQ; /* g */
PublicKey; /* y */

A DSA private key is represented as a BER-encoded sequence list that contains the following:

PrimeModulus; /* p */ 
PrimeDivisor; /* q */
OrderQ; /* g */
PrivateKey; /* x */

These key components are defined as follows by FIPS 186 and FIPS 186a:

  • PrimeModulus. This is the public prime modulus.

    p = A prime modulus, where 2L-1 < p < 2L for 512 <= L <= 1024, and L is a multiple of 64.

  • PrimeDivisor. Another public prime number dividing (p-1).

    q = A prime divisor of p-1, where 2159 < q < 2160

  • OrderQ. This public number has order q mod p.

    g = h (p-1)/q mod p, where h is any integer with 1 < h < p-1, such that h (p-1) /q mod p > 1.

  • PrivateKey. The private key.

    x = a pseudorandomly generated integer with 0 < x < q.

  • PublicKey. The public key.

    y = gx mod p.

A DSA-wrapped private key is defined by the PKCS#8 specification. The PKCS#8 standard specifies the wrapped key format resulting from encoding an algorithm object identifier (OID) with an encoded private key.

Trust Policy (TP) Modules

Trust Policy modules allow applications to request security services that require "policy review and approval" as the first step in performing the operation. Approval can be based on the identity, integrity, and authorization represented in a group of digital certificates.

Trust Policy modules implement policies defined by authorities and institutions. Policies define the level of trust required before certain actions can be performed. Three basic action categories exist for all certificate-based trust domains:

  • Actions on certificates

  • Actions on certificate revocation lists

  • Domain-specific actions (such as issuing a check or writing a file)

The Trust Policy function can invoke certificate and data storage library functions to carry out the mechanics of the approved action.

Authorization Computation (AC) Modules

Authorization Computation modules define a general authorization evaluation service that computes whether a set of credentials and samples are authorized to perform a specific operation on a specific object. AC modules implement an authorization evaluation mechanism based on caller inputs. Callers provide:

  • The assumptions forming the basis of the caller's policy

  • The request for which authorization is being checked

  • The credentials, samples, and exhibits that could demonstrate authorization to perform the request

The Authorization Computation engine determines whether the request is authorized based on the assumptions and caller credentials. The AC module can provide other services related to authorization computations through the CSSM_AC_PassThrough() function.

Certificate Library (CL) Modules

The Certificate Library API allows applications to manipulate memory-resident certificates and certificate revocation lists. Operations must include creating, signing, verifying, and extracting field values from certificates. Each add-in certificate library incorporates knowledge of certificate data formats, and how to manipulate that format.

The CSSM Certificate API defines the generic operations that should be supported by every CL module. Each module can choose to implement only those operations required to manipulate a specific certificate data format, such as X.509, SDSI, etc.

The implementation of these operations is intended to be semantic-free. Semantic interpretation of certificate values is designed to be implemented in Trust Policy modules, layered services, and applications.

The Certificate Library module provided on OpenVMS systems can manipulate X509V3 certificates and SPKI (Simple Public Key Infrastructure) certificates.

Data Storage Library (DL) Modules

The Data Storage Library allows applications to search and select stored data objects, and to query meta-information about each data store (such as its name, date of last modification, size of the data store, and so on).

Data Storage Library modules provide stable storage for security-related data objects. These objects can be certificates, certificate revocation lists, cryptographic keys, integrity and authentication credentials, policy objects, or application-specific objects. Stable storage can be provided by one of the following:

  • Commercially-available database management system product

  • Native file system

  • Custom hardware-based storage device

  • Remote directory services (e.g., LDAP)

  • In-memory storage

Each Data Storage Library module can choose to implement only those operations required to provide persistence under its selected model of service.

The Data Storage Library module currently provided on OpenVMS uses OpenVMS flat files.

Elective Module Managers (EMMs)

The CDSA architecture includes several extensibility mechanisms. Elective module managers support the dynamic addition of entire new categories of service. Prior to requesting services from an add-in service provider module, the application attaches to an instance of the service provider. For elective module managers, the CSSM transparently attaches the associated module manager if it is not already loaded. Once the manager is loaded, the APIs defined by that module are available to the application.

This process is transparent to the add-in module as well as to the application. Therefore, an add-in module vendor should not need to modify their module implementation to work with an elective module manager versus a basic module manager.

Module Directory Services (MDS)

The Module Directory Services provide facilities to describe and locate executable objects and their associated signed manifest integrity credentials.

MDS consists of a database and a set of access methods. It is used primarily to support secure loading and the use of add-in software modules. It is a system-wide service available to all processes. MDS defines a basic object directory schema to name and locate software components and the signed manifest credentials associated with those software components. Each software component in the object directory is uniquely named by a globally unique identifier (GUID). CDSA defines an additional set of schemas to store CDSA-specific security attributes of all CDSA components. CDSA components use the MDS-managed data to do the following:

  • Discover other available CDSA components

  • Learn about the capabilities and properties of other CDSA components

  • Locate the executables for CDSA components

  • Locate the signed manifest credentials associated with a CDSA software component

New schemas can be defined to store the properties and capabilities of elective CDSA modules as they are defined. CDSA applications can also define MDS schemas and use MDS services. CDSA components use MDS managed data to support CDSA's software authentication and integrity checking procedure, known as bilateral authentication.

Chapter 5 “CDSA Programming Concepts” provides an example of how to use MDS.