JGroups Protocol ENCRYPT

External

• http://www.jgroups.org/manual/index.html#Security
• https://github.com/belaban/JGroups/blob/master/doc/ENCRYPT.html

Internal

• JGroups

Overview

The ENCRYPT protocol has the role of encrypting messages in transit between JGroups nodes that belong to the same group. Message body data in clear coming down the JGroups stack on the sending node enters the ENCRYPT layer, gets encrypted and travels in encrypted form to all peers in the JGroups group, thus becoming opaque to whoever would monitor the low level traffic on the network. Once inside the receiving node JGroups stack, data is sent up the stack until it reaches the ENCRYPT layer, where it gets decrypted and turned into clear text which then gets sent up the stack.

Encryption Modes

The modes are mutually exclusive, all JGroups members in the group must be configured in the same way.

Shared Keystore Encryption

The shared keystore encryption encrypts all events of a type MSG that have a non-null message buffer. The protocol can be inserted at any position in the stack, and it is not dependent by a coordinator to generate and distribute the key. This is using symmetric encryption with a secret key that is stored in a keystore.

The configuration is similar to:

<ENCRYPT 
          key_store_name="defaultStore.keystore"
          store_password="some_password"
          alias="the_secret_key_alias_in_store"/>

Dynamic Key Generation

This option is appropriate for an application that does not have a shared key. The key is generated and distributed by the controller.

The secret key is first generated by the controller. 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.

Configuration

WildFly Configuration

Shared Store Encryption

1. Create the shared store.

keytool -genseckey -alias key1 -keypass password123 -storepass password123  -keyalg Blowfish -keysize 56 -keystore ./test.keystore -storetype  JCEKS

2. Place the keystone in a directory accessible to the application server instance.

2.1 It is also possible the place the keystone in a location that is available to the JGroups stack on its classpath. TODO.

3. Configure the protocol as follows:

<subsystem xmlns="urn:jboss:domain:jgroups:1.1" ...>
    <stack name="tcp">
        ...
        <protocol type="ENCRYPT">
             <property name="key_store_name">/absolute/path/to/the/test.keystore</property>
             <property name="store_password">password123</property>
             <property name="alias">key1</property>
        </protocol>
        ...
    </stack>
</subsystem>