Previous section.

Common Security: CDSA and CSSM
Copyright © 1997 The Open Group


Problem Statement

When attempting to establish a secure or trusted computing environment, the integrity of each software module in the environment must be verified. Digital signaturing and signature verification is a standard mechanism for demonstrating integrity and even authenticity (depending on the signing key). This is not a total solution. In a dynamic computing environment, modules are constantly being added to and removed from the environment. The verification process must be online and on-demand. Hence even when all modules are signed and signature verification is performed, there remains the question "Who is checking on the verifier?"

Extending Trust

To establish trust in a computing environment, it is essential to begin from a single trusted module and extend the perimeter of trust by verifying the integrity of each software module as it is added to the computing environment. One approach is to insert one or more integrity verification kernels (IVKs) into each module. The embedded IVK can verify digital signatures of itself and the module to improve the chances that any modification, whether accidental or malicious, can be detected prior to performing trusted operations within the scope of the module.

Cryptography is not useful in establishing a secure kernel. It assumes the existence of two secure end-points. It is assumed that the code signing environment is secure, by physical and software means. The problem is establishing a secure verification environment.

The starting point for verification should be one or more small kernels of code that are continually self-checking. This checking makes the IVKs more protected. They, in turn, are used to detect modification in the remainder of the program.

Many complex applications rely on dynamic linking to shared libraries to access program modules. These libraries are often created by diverse organizations and updated at asynchronous times. These libraries must be checked before they are added to the executing environment. It is also desirable to check these libraries after they are running in the system.

Checking is based on credentials. Credentials can also be used to convey authenticated attributes of the signing organization, the signed module, or even attributes of the signature itself. The software module can have some attributes, such as the version number or implementation restrictions, which are necessary for its partner modules. Finally, some attributes, such as the date and time when the signature was made, can be attributes of the signature itself.

A central authority with universal trust is not required. Each software organization can indicate which other organizations can produce trusted software by issuing certificates signed with its digital signature. Each module that evaluates credentials can contain the root public key, or keys, that it trusts. If it uses certificates as a means of introducing new partners, the number of vendors for partner modules need not be limited.

The security of these applications can be further enhanced by having IVKs in each module to check the integrity and credentials of other modules that it serves or that it uses to obtain services.

Why an Embedded Library?

The Embedded Integrity Services Library (EISL) is not extensible. It is intended to be implemented with position-independent code so that it can be used in constructing integrity verification kernels.

EISL implements a self-check procedure that verifies its own digital signature. The public key used for verification is embedded in the library code to avoid being easily modified.

The embedded integrity library contains the minimal set of services to locate partner modules and their credentials, verify credentials and obtain authenticated attributes, and securely link to partner modules. Because these services are used to establish trust in other modules, they must be statically bound to each module.

Once trusted contact has been established, a large, more general Integrity Services Library (ISL) can be used to implement the full range of integrity services. While compatible with the more general integrity library, the embedded integrity library is intended only to securely find other code modules and their attributes. Verification needs that exceed this scope should be met by the integrity services library.

A Phased Approach

The establishment of integrity between two dynamically loaded, executable objects proceeds in three phases:

All three phases are discussed in greater detail in the CSSM Add-in Module Structure and Administration Specification. EISL defines APIs that support all three phases of the process to verify integrity between two objects dynamically loaded, executable objects.

Phase I. Establishing a Foothold: Self-Check

In the first phase, the self-check phase, the software module checks its own digital signature. The Embedded Integrity Services Library (EISL) defines a statically-linked library procedure to perform self-check.

Phase II. Finding our Friends: Bilateral Authentication

In the second phase, bilateral authentication routines in the EISL offer support for securely locating, verifying, and linking to partner software modules.
Figure: Bilateral Authentication Using Software Credentials

The process of bilateral authentication begins in the registry, where each program can find the credentials as well as the object code of the other.

Verification of the other module can be done prior to loading, or if it is already loaded, it can be verified in memory. Verification prior to loading prevents activating file viruses in infected modules. Verification in memory prevents stealth viral attacks where the file is healthy, but the loaded code is infected.

Phase III. Secure Linkage Check

Once verified, the programs can use the verified in-memory representation of the credentials to perform validity checks of addresses to provide secure linkage to modules. The addresses of both callers and procedures to be called can be verified using this facility.

Using Library Services

EISL defines a comprehensive set of services for extending the perimeter of trust based on integrity verification. EISL Users must make appropriate use of the library to obtain the full benefits of its services. This section discusses how to use the services defined by EISL.

Location of Modules and Credentials

The embedded integrity services library defines a service to locate a partner module in a central registry. This function assists applications in finding the module code as well as the credentials of a partner module. The credentials are external to the module's object code and publicly documented so that they can be verified by any party. Acceptable credentials are signed manifests and digital certificates. Each module must be issued a set of credentials as part of the module manufacturing process. Credentials consist of at least one digital certificate and one manifest. Over time, additional certificates can be added and the original manifest can be augmented with additional descriptions of the module. See the Signed Manifest Specification, Intel Architecture Lab, 1997, for an overview of manifests and their use in integrity verification.

While the credentials can be easily parsed and examined by the program directly, it is discouraged. External credentials are in a very public place, which allows multiple independent verifications, but they can therefore be easily modified between the time that they are verified and subsequent examination of them by the program. The library is intended to atomically retrieve, parse, and verify the credentials, and use (unspecified) methods to preserve the integrity of the attributes in memory after verification.

Verification of Modules and their Credentials

If a called partner module is not already loaded, the credentials and object code can be examined prior to loading and execution of the object code, preventing common file virus infections. Modules that are already loaded can be checked in memory as they execute.

Most aspects of the EISL specification can be implemented in a portable (platform-independent) manner. However, the object code format and return addresses are platform-specific.

Secure Linkage

Another service defined by EISL is secure linkage to a partner module. For the caller, this entails checking that the called address is in fact in the appropriate code module. For the called module, the return address can be verified to be within the appropriate calling module. Even in the case of self-checking, one can require that the return address be within the module being checked.

Linkage checks prevent attacks of the stealth class, where the object being verified is not the object that is being used. Also, the checks increase the difficulty of the man-in-the-middle attack, where a rogue module will insert itself between two communicating modules, masquerading itself as the other module to each module.

The specification supports modules that reside in a single address space, and have uncontrolled read and execute access to the code space of all modules.

Integrity Credentials

EISL integrity checks verify the integrity of an object code module and a set of credentials associated with that object module. These credentials must be signed manifests and digital certificates. A detailed description of these credentials are contained in two specifications:

An overview is provided here.

A credential is a set of persistent objects. A full set of credentials includes:

The certificate must be verifiable based on a one or more specified public root keys. The complete certificate chain required for successful verification must be included in the signature block. This certificate must be used to sign the objects referenced by the manifest sections. This creates a tight integrity-binding between the certificate and the objects referenced by the manifest.

Each manifest section can contain additional descriptive information about the object referenced by the manifest section, such as their creation date.

The signature block is encoded in the format required by the signature block representation. For example, for a PKCS#7 signature block, the encoding format is BER/DER.

The manifest, signer information, and signature block are each stored in a separate file with an identifying suffix:

It must be possible to specify a pathname and single common filename to locate the credential files. A convention for storing the credential files with the object code files could be adopted but is not required. For example, the credential files can be local to a system and the object code files could be remote. In this case the credential files and the object code files would not reside in the same file system path.

Based on these credentials EISL functions can be used to verify the identity and the data integrity of the object code modules referenced by the manifest sections.

EISL Uses Other Standards or Specifications

This specification uses other industry specifications or standards for certificates, keys, signatures, and cryptographic algorithms. Utilized standards include:
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.
You should also read the legal notice explaining the terms and conditions relating to the CDSA documentation.

Contents Next section Index