Secure Session Creation

This section describes how two parties establish a secure communication session over an untrusted network. We have developed our own non-standard protocol that avoids certificate exchange between parties. Instead, our protocol forces each party to prove which key it controls and allows each party to check the authorization of their peer’s key locally.

This differs from standard protocols, such as SSL, that exchange authorization certificates during key exchange. Since our protocol has not been analyzed fully, future work should explore adapting TEP to use a more proven protocol. We also expect that better protocols can reduce the time required to establish a secure session, as described in Section 5.2.5.

A secure session guarantees these properties:

Privacy Eavesdroppers on the network cannot read session data.

Integrity Attackers on the network cannot change session data without detection.

Authentication Each party knows what private key their peer controls.

To achieve these properties, communicating parties must engage in a mutual authen-tication protocol. The protocol proves to each party what private key the other party controls, and allows parties to reject unrecognized peers. The parties also exchange secret session keys for encrypting session data. Finally, the parties include message authentication codes (MACs) with their messages to protect the integrity of their data.

The principals Alice (the client) and Bob (the server) run the protocol as follows:

1. Alice sends Bob her public key, a fresh nonce (a 64-bit random number), and her signature over the data:

PA, RA, SA(PA, RA)

2. Bob verifies Alice’s signature and replies with his public key, a fresh nonce, a fresh secret key encrypted with Alice’s public key, and his signature overall the data:

PB, RB, EA(KB), SB(PA, RA, PB, RB, EA(KB))

3. Alice verifies Bob’s signature and decrypts his secret key. She then sends Bob a fresh secret key encrypted with Bob’s public key and her signature over all the data:

EB(KA), SA(PA, RA, PB, RB, EA(KB), EB(KA))

4. Bob verifies Alice’s signature and decrypts her secret key.

5. To protect the privacy of their data, Alice and Bob encrypt their output streams.

Alice encrypts her output stream with KA and decrypts her input stream with KB. Bob encrypts his output stream with KB and decrypts his input stream with KA.

6. The protect the integrity of their data, Alice and Bob append a MAC to each message they send. Alice derives her output MAC key from KA and her input MAC key from KB. Bob derives his output MAC key from KB and his input MAC key fromKA.

7. To defeat Man-In-The-Middle attacks, Alice and Bob check their peer’s public key against a set of expected public keys. If their peer’s key is not a member of the expected set, they close the session.

We discuss each of these steps in turn:

Step 1 provides Bob with Alice’s public key and a fresh nonce. For now, Bob

message could be a replay of an earlier instance of the protocol; this attack will be defeated by later steps in the protocol.

Step 2 provides Alice with Bob’s public key, a fresh nonce, and his session key.

The session key is encrypted with Alice’s public key, so Alice can decrypt it with her private key. The signature is calculated over all the data from the first two steps, so it includes both nonces. This message defeats most replay attacks by Bob, since it is very improbable that those two nonces were used together in a previous instance of the protocol.

Step 3 provides Bob with Alice’s session key. Again, the signature includes both nonces, so this message defeats most replay attacks by Alice. By step 4, both parties have each other’s public key, session key, and evidence that the other controls the given key (using signatures). The signatures also protect the integrity of each message.

Step 5 protects data sent during the session from eavesdroppers. Symmetric-key encryption has good performance and is difficult to break, and so works well to protect the privacy of data. This implementation uses the RC4 stream cipher with 128-bit keys.

Step 6 protects data sent during the session from attackers. It is possible for an attacker to overwrite a message in such a way that, when decrypted, it means something else. Alice and Bob protect their messages with MACs: MACs are message digests that include a shared secret (usually derived from the session keys), so they cannot be created by an attacker. MACs are included with each message before it is encrypted. If either party receives a message without a matching MAC, they discard the message. This implementation uses HMAC-MD5, a MAC algorithm based on the MD5 message digest algorithm.

Step 7 protects the session from man-in-the-middle attacks. These attacks occur when an attacker intercepts the keys being sent during the first three steps and substitutes its own keys. The attacker can convince both parties that the protocol has completed successfully while gaining access to all data sent during the session.

This attack is very hard to defeat without a shared secret or prior knowledge about the parties.

In TEP, most secure sessions are between parties that know something about one another. We assume TEP’s public key is well known, so invokers that contact TEP can reject peers that do not use TEP’s key. TEP does not have prior knowledge about the invoker, but Jif programs can check the identity of the invoker with a runtime actsfor test. For example, the test actsfor(invoker, Bob), where invoker is the invoker’s runtime principal, will succeed only if the invoker’s key is bound to the name Bob or if the invoker acts for Bob.

When TEP contacts a principal to open a secure channel, the receiving party can check its peer’s public key against its set of known TEP keys. TEP checks that the remote principal’s key is bound to one of the readers in the channel label, so it is guaranteed that data is leaked only to authorized principals. Section 4.3.5 presents channel creation in detail.

Provider

handoff or error

if no error,

Invoker TEP

URL, classname, method

fetch program @URL program

Checker Prover

check JAR digest

run program with channel

check class authority declarations check method signature

check classes create secure session

Figure 4-2: Invocation Protocol