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.
EISL implements a self-check procedure that verifies the signature of the containing module. The public key used for verification is embedded in the containing module 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.
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 dynamically loaded, executable objects.
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.
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.
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.
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.
For convenience, a brief introduction 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.
Creating a signed manifest is one of the last steps in manufacturing a CDSA component. The manufacturing process creates at least three separate files for the manifest sections, signer information, and signature block. The files are zipped to create a single credential file in PKZIP format. Each file has an identifying suffix:
When providing credentials as input to an EISL function, two methods are supported. The credentials can be referenced by providing:
Optionally a manifest section in the credential can include a direct reference to the object code file whose integrity hash is stored in that manifest section. EISL provides functions supporting the use of these direct file references. If a manifest section does not directly reference an object code file, to verify the integrity of an object code module, a caller must use equivalent EISL functions that accept a fully-qualified file system pathname locating the object code module.
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.
| Contents | Next section | Index |