LEADTOOLS CCOW Establishing a Chain of Trust

Establishing a Chain of Trust

A chain of trust requires that all Secure Link components (i.e., context manager, applications, mapping agents, authentication repository, etc.) have a means of authenticating each other's identity and does not generally require confidentiality since sensitive data, such as a user's password, is not communicated between applications. The ability to authenticate each other's identity prevents rogue applications and unauthorized users from gaining access to the Secure Link-enabled applications. In addition to preventing a rogue program from modifying the data as it is passed between applications and components manipulating the user context, the applications and components that participate in the chain of trust must be able to validate the integrity of the user context data that they communicate to each other.

The Context Management Architecture uses digital signatures and secure hash functions as the building blocks to create “chains of trust”. User Link-enabled applications and User Link components use digital signatures to authenticate each other's identity each time they communicate. Digital signatures are formed using public key / private key encryption techniques. An application or component creates its digital signature using its private key and sends the signature along with the data to a recipient. The recipient of the signed message applies the sender's public key to the signature to authenticate the sender and verify the integrity of the data.

A secure hash function creates unique numeric representations of data from a data stream. Once the numeric representation of the data stream has been created it is highly improbable that another hash function would be able to reproduce the original data stream. This is essential when computing the digital signatures and reliably distributing public keys during runtime.

The CCOW Context Management Architecture standard defines the interfaces required to enable signature-based security relationships between applications and context management components. CCOW Context Management Architecture defined interfaces enforce the security relationships as applications and components interact over the course of a context change transaction. Digital signatures created using a public key / private key encryption system are incorporated into the component interfaces defined for User Link-enabled applications and components. These signatures (and corresponding keys) are not associated with users, but rather with applications and components. The signatures and keys for a particular application are the same regardless of who is using the application.

Public keys are used for mutual digital verification of communication between an application and a component for the duration of the application's participation in the context session. The context session public keys are exchanged dynamically each time a Secure Link-enabled application or Secure Link-enabled component is launched and joins a context session. This critical process needs to ensure that a receiving entity can reliably establish the identity of the entity that created the key.

The CCOW Context Management Architecture standard defines multiple ways of Public key distribution including through a certificate authority. To minimize the infrastructure changes required to establish a secure link solution, the CMA standard defines a passcode-based two-step secure binding process. This process dynamically distributes an application's or component's context session public key by default. All Secure Link-enabled applications and Secure Link components are required to support this process. In addition, optional PKI-based digital certificates may also be used as the means to dynamically distribute an application's or component's public key.

A passcode is a shared secret in the form of a complex, arbitrary alphanumeric string that is assigned to Secure Link-enabled applications and Secure Link-enabled components. An application or component uses its passcode to identify itself when presenting its context session public key. Passcodes are not transmitted during the secure binding process. Instead, a message authentication code, generated using a secure hash function from a data stream and a shared passcode is transmitted.

The passcode-based binding process involves a “bindee” and a “binder”. In order to bind, a bindee must be assigned a passcode and both the bindee and the binder must have knowledge of the same passcode. Application and Context agents are always bindees. The Authentication Repository and Context Manager are the binders. The bindee initiates the binding process with the binder.

An application passcode is a randomly generated character string comprised of no fewer than 128 characters and no more than 256 characters. A passcode can only be comprised of alphanumeric characters, the underscore (_) and dash (-) characters. A passcode cannot contain white space (e.g., tabs, spaces). A passcode is arbitrary and should not contain any words or phrases. The CMA standard recommends using site-specific versions of an application's passcode to limit the effect of a security breach should one occur.

The specific secure hash algorithm and the public key / private key scheme to be used are technology-specific. Each of the HL7 context management technology mapping specifications indicates the secure hash algorithm and public key / private key scheme that are appropriate for a particular technology-specific implementation.

LEADTOOLS encapsulate the generation, transmission and verification tasks needed to implement context security. Developers can develop a complete secure context system without having to deal with digital signatures, keys and hash function for message authentication codes. LEADTOOLS ActiveX implementation uses the following for Passcode-Based Secure Binding as defined in the standard: