/
ENCRYPT.html
204 lines (180 loc) · 9.87 KB
/
ENCRYPT.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<blockquote>
<blockquote>
<blockquote>
<h1>
<b>Encryption Protocol Document</b></h1>
</blockquote>
</blockquote>
</blockquote>
<b>(Author : Steve Woodcock)</b>
<h1>
<b>Introduction</b></h1>
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.
<ul>
<li> A suitable Security provider is required. (see security provider instructions later)
<li> The java.security properties need to be configured (see installation guide).
</ul>
<br>
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).
<ul>
<li> 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. <b>Due to issues with Sun's JCE you cannot use this option with JDK1.3</b>
<p>
<li> 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.
</ul>
<h1>
<b>Installation</b></h1>
The following steps need to be followed to make sure that ENCRYPT protocol can be used
<br>
<h2>Installing a Security Provider</h2>
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.<br>
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. <br>
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.
<p>
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.<p>
Assuming <b>$JAVA_HOME</b> to be the JDK the installation root.<p>
<h3>JDK 1.3</h3>
Download the SunJCE file.<br>
Unzip the file and place the jar files contained in the jce/lib folder in the
<b>$JAVA_HOME/jre/lib/ext </b>directory<br>
Place the bouncycastle provider in the <b>$JAVA_HOME/jre/lib/ext</b> directory.<p>
Next configure the security file to add the new providers.
<ul>
<li>Open the <b>java.security</b> file in <b>$JAVA_HOME/jre/lib/security</b>.</li>
<li>
Search for <b>security.provider.{list}</b> in the opened file.</li>
<li>
Add the SunJCE provider as provider 2, and
add the bouncycastle provider as the last.<br>
</li>
<li>
You should end up with the entries similar to that shown below.
<br>
security.provider.1=sun.security.provider.Sun<br>
security.provider.2=com.sun.crypto.provider.SunJCE<br>
security.provider.3=com.sun.rsajca.Provider<br>
security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider<br>
</li>
</ul>
<h3>JDK 1.4</h3>
The JDK1.4 already includes the SunJCE files, so you only need to configure the bouncycastle provider.<br>
Place the bouncycastle provider in the $JAVA_HOME/jre/lib/ext directory.<p>
Next configure the security file to add the new providers.
<ul>
<li>Open the <b>java.security</b> file in <b>$JAVA_HOME/jre/lib/security</b>.</li>
<li>
Search for <b>security.provider.{list}</b> in the opened file.</li>
<li>
Add the bouncycastle provider as the last.<br>
</li>
<li>
You should end up with similar entries as shown below.
<br>
security.provider.1=sun.security.provider.Sun<br>
security.provider.2=com.sun.net.ssl.internal.ssl.Provider<br>
security.provider.3=com.sun.rsajca.Provider<br>
security.provider.4=com.sun.crypto.provider.SunJCE<br>
security.provider.5=sun.security.jgss.SunProvider<br>
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider<br>
</li>
</ul>
<h2>Configure the Encrypt Protocol</h2>
<h2>Option 1 - Using a shared keystore (JDK1.4 Only)</h2><br>
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:<p>
<b>
<ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/><br>
</b><p>
An example bare-bones.xml file showing the keystore version can be found in the conf
directory in a file called <b>EncryptKeyStore.xml</b> - you will need to generate a keystore - see the KeyStoreGenerator file in the demo directory or use the makeKeystore target in the build file.<br>
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.
<p>
<b>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.</b><p>
<h2>Option 2 - Dynamic Key Generation (JDK1.3/1.4)</h2><br>
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.
<br>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.
<br>
An example <b>EncryptNoKeyStore.xml</b> is included in the conf directory as a guide.
<p><p>
<br> 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.
<h1>
<b>Demo</b></h1>
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:
<p>
<blockquote>
04-Aug-2004 21:11:38 org.jgroups.protocols.ENCRYPT setProperties<br>
INFO: key_store_name used is defaultStore1_4.keystore<br>
04-Aug-2004 21:11:38 org.jgroups.protocols.ENCRYPT setProperties<br>
INFO: store_password used is not null<br>
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT setProperties<br>
INFO: key_password used is same as store_password<br>
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT setProperties<br>
INFO: alias used is myKey<br>
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT initSymCiphers<br>
INFO: Initializing symmetric ciphers<br>
04-Aug-2004 21:11:39 org.jgroups.protocols.ENCRYPT initSymCiphers<br>
INFO: Initialized symmetric ciphers with secret key version �;ٺ�8=fԱ;qe2�<br>
</blockquote>
If you want to confirm the encryption/decryption messages then set the logging level to debug
for the protocol.
<p>
If you are using the encryption without a keystore you should see output similar to:
<blockquote>
05-Aug-2004 13:43:52 org.jgroups.protocols.ENCRYPT initSymKey<br>
INFO: Symmetric key generated<br>
05-Aug-2004 13:43:53 org.jgroups.protocols.ENCRYPT initKeyPair<br>
INFO: asym algo initialized<br>
05-Aug-2004 13:43:53 org.jgroups.protocols.ENCRYPT initSymCiphers<br>
INFO: Initializing symmetric ciphers<br>
05-Aug-2004 13:43:53 org.jgroups.protocols.ENCRYPT initSymCiphers<br>
INFO: Initialized symmetric ciphers with secret key version �~6��Ɨ/h%ڤĹ<br>
................<br>
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.<p>
05-Aug-2004 13:43:55 org.jgroups.protocols.ENCRYPT up<br>
INFO: handling view change event<br>
05-Aug-2004 13:43:55 org.jgroups.protocols.ENCRYPT becomeKeyServer<br>
INFO: I have become key server<br>
</blockquote>
<p>
Note: the key version is an MD5 hash of the key in an encoded form from which you cannot get
the original key data.
</body>
</html>