ENCRYPT layer. Encrypt and decrypt the group communication in JGroups
The file can be used in two ways:
- 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.
- Option 2. Configured with algorithms and key sizes. The Encrypt Layer in this mode sould be used between the
FRAG and PBCast layers in the stack. The coordinator then chooses the
secretkey which it distributes amongst all the peers. In this form no keystore exists as the keys are
distributed 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.
Each message is identified as encrypted with a specific encryption header which identifies
the type of encrypt header and an MD5 digest that identifies the version of the key being used
to encrypt/decrypt the messages.
Option 1
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 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
ina file called EncryptKeyStore.xml - along with a defaultStore.keystore 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.
Option 2
This option is suited to an application that does not ship with a known 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 file 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.
author:
Steve Woodcock
author:
Bela Ban | 