Bootstrapping the Cherubim System

The Classloader Hierarchy

The classes in the Cherubim system are split into three categories that are loaded by different classloaders:

Primordial Classes - The primordial classes contain the java core classes (packages that begin with java.), as well as the necessary cryptographic code from the Cherubim and Cryptix packages. The java core classes are assumed to be present and reliable on the client machine, while the other primordial classes are taken to the client machine by the user on a smartcard or similar device.
Jurassic Classes - The jurassic classes consist of those classes present on the user's home machine. This includes the classes the make up the jacorb object request broker, the classes that make up any applications that reside on the user's home machine, and the Cherubim policy library (which consists of the basic blocks from which specific policies are constructed).
CORBA Classes - The CORBA classes are loaded by a classloader using CORBA. These classes include specific policies that need to be evaluated prior to access remote objects and the classes that make up applications that do not reside on the users home machine. These classes are loaded using a Cherubim policy that is located on the user's home machine.

Figure: The Classloader Hierarchy

Implementation

In order to securely load the jurassic classes over the network to the client machine, encryption, authentication, and digital signatures are necessary. This section describes the specifics of how the client and server authenticate one another and agree on a session key, as well as how the client machine loads the jurassic classes from the home machine.

Initial booting of the Cherubim System proceeds as follows:

Client machine boots its Operating System and Java Virtual Machine (this may be done with AEGIS or a similar system)
User runs Boot program
Boot program prompts for passphrase
Boot program hashes passphrase using SHA-1 to an IDEA symmetric key
Boot program uses IDEA key to decrypt smartcard (including private keys)
Client machine makes a socket connection to the user's home machine
Home machine spawns a Connection thread to communicate with the client
Client begins key negotiation with the server

Key Negotiation is accomplished using the Diffie-Hellman protocol:

Client machine sends a SignedDHMessage (a signed Diffie-Hellman message, signed by the Smartcard) to the server
Server verifies the signature, timestamp, and destination on the message
Server sends a SignedDHMessage to the client
Client verifies the signature, timestamp, and destination on the message
Client and Server generate the shared secret
Client and Server hash shared secret using SHA-1 to an IDEA secret key

After this authentication has taken place, the Client can then request classes as follows:

JurassicClassloader receives request for a class on the client
JurassicClassloader checks to see if requested class is in the class cache; if so, return it
JurassicClassloader checks to see if the primordial classloader can load the class (i.e. if the class is in the CLASSPATH); if so, return it
JurassicClassloader checks if existing session key is more than one hour old; if so, negotiate a new one as above
JurassicClassloader sends a SEClassRequest (a signed, encrypted class request, signed by the Smartcard and encrypted with the IDEA session key) to the home server over the existing socket
Server verifies the signature, timestamp, destination, and sequence number on the SEClassRequest
Server loads the requested class off the local disk, if available
Server sends the class in a SEClassResponse (a signed, encrypted class response, encrypted with the IDEA session key) to the client
JurassicClassloader verifies the signature, timestamp, destination, and sequence number on the message
JurassicClassloader adds the class in the message to the class cache
JurassicClassloader returns the class in the message to the process that called it

Specifics:

1024-bit DSA keys are used for signatures
2048-bit prime is used for the Diffie-Hellman exchange
128-bit IDEA keys are used for the session keys
Messages are given 5 minutes before the timestamp is considered invalid to account for transfer time and clock skew
A new session key is generated every hour

The javadoc documentation is available for the cherubim.boot package.

Also available is the techical report describing the Cherubim Core Security Services and Bootstrapping System. The report is available in Microsoft Word and Postscript formats.

Feel free to direct any comments to Chuck Willis ( cfwillis@uiuc.edu ).

Return to the Cherubim Home Page

Last Updated 16 Jun 98 by Chuck Willis (cfwillis@uiuc.edu).