Introduction

The encryption protocol provides encryption of messages in JGroups that are generated by applications. There are a few requirements in order to make use of the Encryption layer.

A suitable Security provider is required. (see security provider instructions later)
The java.security properties need to be configured (see installation guide).

The Encrypt layer can be used in one of two ways (the options are mutually exclusive so all participants in a JGroup must have the same settings).

Option 1. Configured with a secretKey in a keystore so it can be used at any layer in JGroups without the need for a coordinator, or if you want protection against passive monitoring but do not want the key exchange overhead and complexity. In this mode all nodes must be distributed with the same keystore file. Due to issues with Sun's JCE you cannot use this option with JDK1.3
Option 2. Configured with only algorithms and key sizes. The Encrypt Layer in this mode should be used between the FRAG and PBCast layers in the stack. The coordinator chooses the secretkey which it distributes amongst all the peers. In this form no keystore exists as the keys are the key is generated and distributed by the controller using a public/private key exchange. View changes that identify a new controller will result in a new session key being generated and then distributed to all peers. This overhead can be substantial in a an application with a reasonable peer churn.

Installation

The following steps need to be followed to make sure that ENCRYPT protocol can be used

Installing a Security Provider

First you need to download an appropriate security provider. A good option is an organisation called bouncycastle, who provide an open-source clean room implementation of the JCE. You can find them at www.bouncycastle.org.
You must download the correct jar file for the JDK you are using - at the time of writing the 1.3 version is: jce-jdk13-124.jar and the 1.4 version is: bcprov-jdk14-124.jar.
You do not have to use the bouncycastle provider - others available include those from Phaos Technology, RSA and Wedgetail Communications. See the appropriate documentation for each provider.

If you are using 1.3 you must also install the SUN JCE provider (current version 1.2.2) to give access to the JCEKS keystore formats. This can be downloaded from the www.javasoft.com site. The following instructions are for JDK1.3 and 1.4.

Assuming $JAVA_HOME to be the JDK the installation root.

JDK 1.3

Download the SunJCE file.
Unzip the file and place the jar files contained in the jce/lib folder in the $JAVA_HOME/jre/lib/ext directory
Place the bouncycastle provider in the $JAVA_HOME/jre/lib/ext directory.

Next configure the security file to add the new providers.

Open the java.security file in $JAVA_HOME/jre/lib/security.
Search for security.provider.{list} in the opened file.
Add the SunJCE provider as provider 2, and add the bouncycastle provider as the last.
You should end up with the entries similar to that shown below.
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.crypto.provider.SunJCE
security.provider.3=com.sun.rsajca.Provider
security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider

JDK 1.4

The JDK1.4 already includes the SunJCE files, so you only need to configure the bouncycastle provider.
Place the bouncycastle provider in the $JAVA_HOME/jre/lib/ext directory.

Next configure the security file to add the new providers.

Open the java.security file in $JAVA_HOME/jre/lib/security.
Search for security.provider.{list} in the opened file.
Add the bouncycastle provider as the last.
You should end up with similar entries as shown below.
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider

Configure the Encrypt Protocol

Option 1 - Using a shared keystore (JDK1.4 Only)

This is the simplest option and can be used by simply inserting the Encryption layer at any point in the JGroup stack - it will encrypt all Events of a type MSG that have a non-null message buffer. The format of the JGroup XML entry in this form is:

<ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>

An example bare-bones.xml file showing the keystore version can be found in the conf directory in a file called EncryptKeyStore.xml - you will need to generate a keystore - see the KeyStoreGenerator file in the demo directory or use the makeKeystore target in the build file.
In order to use the Encrypt layer in this manner it is necessary to have the secretKey already generated in a keystore file. The directory containing the keystore file must be on the application's classpath. You cannot create a SecretKey keystore file using the keytool application shipped with the JDK. A java file called KeyStoreGenerator is included in the demo package that can be used from the command line (or IDE) to generate a suitable keystore.

IMPORTANT- A keystore generated under each version of the 1.4 JDK can be incompatible with other JDK versions. Make sure you generate the keystore with the same JDK version as you are going to use at runtime. This is important for 1.4.2_04 and 1.4.2_05.

Option 2 - Dynamic Key Generation (JDK1.3/1.4)

This option is suited to an application that does not ship with a shared key but instead it is generated and distributed by the controller. The secret key is first generated by the Controller (in JGroup terms). When a view change occurs a peer will request the secret key by sending a key request with its own public key. The controller encrypts the secret key with this key and sends it back to the peer who then decrypts it and installs the key as its own secret key.
All encryption and decryption of Messages is done using this key. When a peer receives a view change that shows a different keyserver it will repeat this process - the view change event also trigger the encrypt layer to queue up and down messages until the new key is installed. The previous keys are retained so that messages sent before the view change that are queued can be decrypted if the key is different.
An example EncryptNoKeyStore.xml is included in the conf directory as a guide.

Note: the current version does not support the concept of perfect forward encryption (PFE) which means that if a peer leaves the group, the keys are re-generated preventing the departed peer from decrypting future messages if it chooses to listen in on the group. This is not included as it really requires a suitable authentication scheme as well to make this feature useful as there is nothing to stop the peer rejoining and receiving the new key. A future release will address this issue.

Demo

To test the usage of the protocol use any demo and change the xml config file to include the encrypt protocol. Starting up an application using the keystore option will result in an output similar to:

04-Aug-2004 21:11:38 org.jgroups.protocols.ENCRYPT setProperties
INFO: key_store_name used is defaultStore1_4.keystore
04-Aug-2004 21:11:38 org.jgroups.protocols.ENCRYPT setProperties
INFO: store_password used is not null
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT setProperties
INFO: key_password used is same as store_password
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT setProperties
INFO: alias used is myKey
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT initSymCiphers
INFO: Initializing symmetric ciphers
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT initSymCiphers
INFO: Initialized symmetric ciphers with secret key version �;ٺ�8=fԱ;qe2�

If you want to confirm the encryption/decryption messages then set the logging level to debug for the protocol.

If you are using the encryption without a keystore you should see output similar to:

05-Aug-2004 13:43:52 org.jgroups.protocols.ENCRYPT initSymKey
INFO: Symmetric key generated
05-Aug-2004 13:43:53 org.jgroups.protocols.ENCRYPT initKeyPair
INFO: asym algo initialized
05-Aug-2004 13:43:53 org.jgroups.protocols.ENCRYPT initSymCiphers
INFO: Initializing symmetric ciphers
05-Aug-2004 13:43:53 org.jgroups.protocols.ENCRYPT initSymCiphers
INFO: Initialized symmetric ciphers with secret key version �~6��Ɨ/h%ڤĹ
................
Later in the output you should see logging identifying that the JGroups peer has become the keyServer - this will be the same peer that is the group coordinator.
05-Aug-2004 13:43:55 org.jgroups.protocols.ENCRYPT up
INFO: handling view change event
05-Aug-2004 13:43:55 org.jgroups.protocols.ENCRYPT becomeKeyServer
INFO: I have become key server

Note: the key version is an MD5 hash of the key in an encoded form from which you cannot get the original key data.