Package org.jgroups.protocols
Class ENCRYPT
java.lang.Object
org.jgroups.stack.Protocol
org.jgroups.protocols.ENCRYPT
ENCRYPT layer. Encrypt and decrypt the group communication in JGroups
The file can be used in two ways:
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.
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.
- 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, Bela Ban
-
Nested Class Summary
Nested Classes -
Field Summary
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionAn event is to be sent down the stack.protected String
protected Cipher
protected int
protected String
protected SecretKey
protected Address
protected String
protected KeyPair
getKpair()
protected Address
getName()
protected PublicKey
protected String
protected Cipher
protected Cipher
protected int
protected static String
void
init()
Called after instance has been created (null constructor) and before protocol is started.void
Generates the public/private key pair from the init paramsvoid
Used to initialise the symmetric key if none is supplied in a keystore.passItDown
(Event evt) void
reset()
Just remove if you don't need to reset any stateprotected void
setKeyServerAddr
(Address keyServerAddr) protected void
setLocal_addr
(Address local_addr) void
setObserver
(org.jgroups.protocols.ENCRYPT.Observer o) boolean
setProperties
(Properties props) Configures the protocol initially.An event was received from the layer below.Methods inherited from class org.jgroups.stack.Protocol
destroy, downThreadEnabled, dumpStats, enableStats, getDownProtocol, getProperties, getProtocolStack, getThreadFactory, getTransport, getUpProtocol, printStats, providedDownServices, providedUpServices, requiredDownServices, requiredUpServices, resetStats, setDownProtocol, setPropertiesInternal, setProtocolStack, setUpProtocol, start, statsEnabled, stop, upThreadEnabled
-
Constructor Details
-
ENCRYPT
public ENCRYPT()
-
-
Method Details
-
getName
-
setObserver
public void setObserver(org.jgroups.protocols.ENCRYPT.Observer o) -
setProperties
Description copied from class:Protocol
Configures the protocol initially. A configuration string consists of name=value items, separated by a ';' (semicolon), e.g.:"loopback=false;unicast_inport=4444"
- Overrides:
setProperties
in classProtocol
-
init
Description copied from class:Protocol
Called after instance has been created (null constructor) and before protocol is started. Properties are already set. Other protocols are not yet connected and events cannot yet be sent. -
initSymKey
Used to initialise the symmetric key if none is supplied in a keystore.- Throws:
Exception
-
initKeyPair
Generates the public/private key pair from the init params- Throws:
Exception
-
reset
public void reset()Just remove if you don't need to reset any state -
up
Description copied from class:Protocol
An event was received from the layer below. Usually the current layer will want to examine the event type and - depending on its type - perform some computation (e.g. removing headers from a MSG event type, or updating the internal membership list when receiving a VIEW_CHANGE event). Finally the event is either a) discarded, or b) an event is sent down the stack usingdown_prot.down()
or c) the event (or another event) is sent up the stack usingup_prot.up()
. -
passItUp
-
down
Description copied from class:Protocol
An event is to be sent down the stack. The layer may want to examine its type and perform some action on it, depending on the event's type. If the event is a message MSG, then the layer may need to add a header to it (or do nothing at all) before sending it down the stack usingdown_prot.down()
. In case of a GET_ADDRESS event (which tries to retrieve the stack's address from one of the bottom layers), the layer may need to send a new response event back up the stack usingup_prot.up()
. -
passItDown
-
getAsymInit
protected int getAsymInit()- Returns:
- Returns the asymInit.
-
getAsymProvider
- Returns:
- Returns the asymProvider.
-
getDesKey
- Returns:
- Returns the desKey.
-
getKpair
- Returns:
- Returns the kpair.
-
getAsymCipher
- Returns:
- Returns the asymCipher.
-
getServerPubKey
- Returns:
- Returns the serverPubKey.
-
getSymAlgorithm
- Returns:
- Returns the symAlgorithm.
-
getSymInit
protected int getSymInit()- Returns:
- Returns the symInit.
-
getSymProvider
- Returns:
- Returns the symProvider.
-
getAsymAlgorithm
- Returns:
- Returns the asymAlgorithm.
-
getKeyStoreName
- Returns:
- Returns the keyStoreName.
-
getSymDecodingCipher
- Returns:
- Returns the symDecodingCipher.
-
getSymEncodingCipher
- Returns:
- Returns the symEncodingCipher.
-
getLocal_addr
- Returns:
- Returns the local_addr.
-
setLocal_addr
- Parameters:
local_addr
- The local_addr to set.
-
getKeyServerAddr
- Returns:
- Returns the keyServerAddr.
-
setKeyServerAddr
- Parameters:
keyServerAddr
- The keyServerAddr to set.
-