This document gives a general view about encryption, encryption schemes and how they work.

Public Key Distribution System

Public key systems, where each corresponded has a pair of keys, can solve both these problems. A key pair is composed of two mathematically related keys: a public key known to everyone and a private key only known to its owner.

The Diffie-Hellman public key distribution system can be used to share a secret key without communicating any secret information, so a secure channel is not required for the key exchange. Also, under this system, only one key pair needs to be managed for each corresponded. Once the correspondents have computed the share secret, they can use it to encrypt communication between them.

Diffie-Hellman Scheme

Under the Diffie-Hellman Scheme, a secret key is agreed on and exchanged as follows, using the private and public parts of Werder’s and Bremens Diffie-Hellman keys.

Werder gets Bremens public key and performs a calculation involving his own private key and Bremens public key

Bremen gets Werder’s public key and performs a calculation involving his own private key and Werder’s public key

The results of both calculation are the same, and this result serves as the secret key. In this way, a secret key can be agreed on without any secret information being communicated. There is no opportunity for an eavesdropper to determine the secret key.

RSA Public Keys

In contrast to a Diffie-Hellman public-private key pair, an RSA public-private key pair is used for encrypting and decrypting messages. A message encrypted with the public key can only be decrypted with the private key and vice versa.

Digital Signatures

Generating a digital signature: A digital signature acts as proof of the sender’s identity and the message’s integrity. Digital signatures can be created using a public key encryption system, such as RSA, as follows:

Werder wants to send Bremen a message. First, he computes a hash of the messageA hash is a mathematical computation performed on the text of a message. Since changing even one bit in the message results in a completely different hash. It is computationally unfeasible to compute a message from a given hash, the hash uniquely identifies the message.

Werder encrypts the hash with its own private key

Next, Werder encrypts the message with Bremens public key

Werder then sends both the encrypted message and the encrypted hash to Bremen

Verifying a Digital Signature: Upon receiving the message, Bremen can confirm that the message was indeed sent by Werder and that it was not tampered with, as follows:

First, Bremen decrypts the message with its own private key >> Bremen can do this, because only he knows his private key

Next, he decrypts the hash with Werder’s public key

Bremen calculates the hash of the unencrypted message (this is the same calculation that Werder performed) and compares it to the hash received from Werder

If they are the same, then Bremen can be sure that:

The message can only have been sent by Werder, because Werder is the only who knows Werder’s private key and thus the only person who could have encrypted the hash

The message was not tampered, because the hash Werder calculated is the same as the hash Bremen calculated

Certificates

If Werder and Bremen obtain each other’s public key over an insecure channel, such as the Internet, they must be certain that the keys are genuine. For this reason, there must be a trusted third party, known as a Certificate Authority (CA), from which Werder can reliably obtain Bremens public key, even over an insecure channel (and vice versa).

The CA sends Werder a certificate, which consists of:

Bremens unique identifier (for example, his LDAP Distinguished Name)

Bremens public key

The CA’s digital signature, encrypted with the CA’s private key

Werder can then verify the certificate (see above). Werder does not have to obtain Bremens certificate directly from the CA. Bremen can obtain the certificate and send it to anyone who requests it, because a certificate cannot be tampered with.

The certificate is “proof” that the message, in this case, Bremens public key is genuine. Werder and Bremen can use each other’s public keys with confidence only if they are certified by certificates from a trusted CA.

Encryption Schemes

An encryption scheme consists of the following elements:

An encryption algorithm for encrypting messages

An authentication algorithm for ensuring integrity, that is, that the message have not been tampered with

Manual IPSec Encryption Scheme

Manual IPSec is an encryption and authentication scheme. A security association (SA) is associated with each packet, consisting of:

Functionality – indicates whether the packet is encrypted, authenticated, or both

Algorithms – specifies the encryption algorithm (for example AES) and the authentication algorithm (for example SHA-1) used in the packet

Keys used in the above algorithm

Additional data, for example initialization vector (IV)

A 32-bit number, known a the security parameter index (SPI), identifies a specific SA. An SPI is simply an identifier, assigned by correspondents themselves in a particular context, and has no meaning outside the context.

Encryption

IP packets are encrypted in accordance with the Encapsulation Security Payload (ESP) standard (RFC 1825, 1827 and 1829). As its name implies, the ESP standard specifies that the original packet is encrypted and then encapsulated into a new, longer packet. There are two modes of performing this encapsulation:

Tunnel Mode

Transport Mode

Tunnel Mode:

In tunnel mode, the entire packet (including the IP header) is encrypted in accordance with the SA previously decided upon the correspondents. An ESP header containing the SPI and other data is added to the start of the packet, and a new IP header is constructed.

The new IP packet consists of:

The new IP header

The ESP header

The encrypted original packe

The new packet is then send on its way. An advantage of this mode is that the destination specified in the new IP header may be different from the one in the original IP header. The picture below shows a paket in IPv4 tunnel mode.

Transport Mode:

In the transport mode, the IP header is not encrypted. An ESP header is inserted between the IP header and the transport layer header. The transport layer header and everything following is encrypted.

This mode does not increase the length of a packet as much as the tunnel mode does. The encrypted packet must be sent to its original destination.

Authentication

If authentication is specified by the SA, then an Authentication header (AH) is added to the packet, in addition to the ESP header (and to the second IP header in Tunnel Mode). The picture below shows a paket in IPv4 transport mode.

Manual IPSec has two shortcomings:

The keys are fixed for the connection’s duration

There is no mechanism for exchanging keys

Both SKIP and ISAKMP/OAKLEY addresses these shortcomings.

SKIP Encryption Scheme

SKIP provides a hierarchy of keys that change over time, which are used to encrypt the connection as well as to implement a key management protocol. SKIP also includes ESP and AH, and adds his own header to the packet.

The Encryption Key and the Authentication Key are derived from the Session Key, which changes at fixed intervals or when the amount of data encrypted exceeds a given threshold. The newly changed Session Key is communicated by encrypting it with the Kijn key, which changes once every hour. The Kijn key is derived from the Diffie-Hellman shared secret Kij key, using a cryptographic hash function. Each correspondent obtains the public part of the others correspondent’s Diffie-Hellman key from a Certificate Authority, which signs the transmission with its own RSA key.

SKIP includes a protocol (Certificate Discovery Protocol) for exchange of public keys. However, this protocol is not supported by FireWall-1, which uses instead a proprietary protocol (RDP = Reliable Data Protocol) for key exchange.

ISAKPMP/OAKLEY Encryption Scheme

ISAKPMP/OAKLEY is a standard for negotiating Security Associations (SA) between two hosts that will be using IPSec, and is the key management scheme that was chosen for IP Version 6. In IP Version 4, ISAKMP/OAKLEY is optional. ISAKPMP/OAKLEY offers improved authentication and Perfect Forward Secrecy (PFS).

ISAKPMP/OAKLEY key exchange is divided into two phases:

ISAKPMP Phase One (Main/Aggressive Mode)

In this phase, the peers negotiate an ISAKPMP Security Association that will be used for encrypting and authentication Phase Two exchanges. Phase One involves long and CPU-intensive computations, and so is executed infrequentl. The negotiated SA includes the encryption method, authentication method and keys. This SA is used in Phase two negotiation.

ISAKPMP Phase Two (Quick Mode)

Using the SA negotiate in Phase One, the peers negotiating an SA for encrypting the IPSec traffic. Keys can be modified as often as required during a connection’s lifetime by performing Phase Two.

Comparison of Encryption Schemes

Feature

Manual IPSec

SKIP

ISAKMP / OAKLEY

Portability

Standard

Standard supported by Sun and other vendors

Industry standard

Key Management

No

Yes

Yes

Session Keys

Fixed

Keys change over time or as amount of data encrypted exceeds a given threshold

Keys change at configurable time during a connection’s lifetime

Number of keys required is proportional to the ..

Square of the number of correspondents

Number of correspondents

Square of the number of correspondents

Packet size

Increased

Increased

Increased

Gateway can encrypt/decrypt on behalf of other hosts

Yes (in tunnel mode)

Yes (in tunnel mode)

Yes (in tunnel mode)

Glossary

Encryption

Encrypting a message modifies (encrypts) its text (plaintext) or „cleartext“ so that the encrypted text (ciphertext) can only be read (decrypted) with the aid of some additional information (e.g. a key) known only to the sender and the intended recipient.

Authentication

Authenticating a message verifies the authenticity of both the sender and the message, checking for possible tampering and interference with the communication.

Encrypting a message

The simplest way to encrypt a message is by using a secret key, one that both encrypts and decrypts the message. Ensuring this key is very critical, since anyone who knows the key can decrypt and read the message.

Sharing a Secret Key

Secret key encryption is simple and fast, but there are two problems associated with its use:

A secure channel is required by which the correspondents can agree on a key

The number of keys can quickly become unmanageable, since there must be a different key for each pair of possible correspondents