… | |
… | |
142 | |
142 | |
143 | RAND is a sequence of fully random bytes, used to increase the entropy of |
143 | RAND is a sequence of fully random bytes, used to increase the entropy of |
144 | the data for encryption purposes. |
144 | the data for encryption purposes. |
145 | |
145 | |
146 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
146 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
147 | initialization and starts at some random 31 bit value. VPE currently uses |
147 | initialization and starts at some random 31 bit value. GVPE currently uses |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
149 | duplication and replay attacks. |
149 | duplication and replay attacks. |
150 | |
150 | |
|
|
151 | The encryption is done on RAND+SEQNO+DATA in CBC mode with zero IV (or, |
|
|
152 | equivalently, the IV is RAND+SEQNO, encrypted with the block cipher, |
|
|
153 | unless RAND size is decreased or increased over the default value). |
|
|
154 | |
|
|
155 | The random prefix itself is generated by using AES in CTR mode with a |
|
|
156 | random key and starting value, which should make them unpredictable even |
|
|
157 | before encrypting them again. The sequence number additionally ensures |
|
|
158 | that the IV is unique. |
|
|
159 | |
151 | =head2 The authentication protocol |
160 | =head2 The authentication/key exchange protocol |
152 | |
161 | |
153 | Before nodes can exchange packets, they need to establish authenticity of |
162 | Before nodes can exchange packets, they need to establish authenticity of |
154 | the other side and a key. Every node has a private RSA key and the public |
163 | the other side and a key. Every node has a private RSA key and the public |
155 | RSA keys of all other nodes. |
164 | RSA keys of all other nodes. |
156 | |
165 | |
157 | A host establishes a simplex connection by sending the other node an |
166 | When a node wants to establish a connection to another node, it sends an |
158 | RSA encrypted challenge containing a random challenge (consisting of |
167 | RSA-OEAP-encrypted challenge and an ECDH key. The other node replies with |
159 | the encryption key to use when sending packets, more random data and |
168 | it's own ECDH key and a HKDF of the challange and both ECDH keys to proof |
160 | PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
169 | it's identity. |
161 | duplicate auth packets). The destination node will respond by replying |
|
|
162 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
|
|
163 | will authenticate that node. The destination node will also set the |
|
|
164 | outgoing encryption parameters as given in the packet. |
|
|
165 | |
170 | |
166 | When the source node receives a correct auth reply (by verifying the |
171 | The remote node enganges in exactly the same protocol. When both nodes |
167 | hash and the id, which will expire after 120 seconds), it will start to |
172 | have exchanged their challenge and verified the response, they calculate a |
168 | accept data packets from the destination node. |
173 | cipher key and a HMAC key and start exchanging data packets. |
169 | |
174 | |
170 | This means that a node can only initiate a simplex connection, telling the |
175 | In detail, the challenge consist of: |
171 | other side the key it has to use when it sends packets. The challenge |
|
|
172 | reply is only used to set the current IP address of the other side and |
|
|
173 | protocol parameters. |
|
|
174 | |
176 | |
175 | This protocol is completely symmetric, so to be able to send packets the |
177 | RSA-OAEP (SEQNO MAC CIPHER SALT EXTRA-AUTH) ECDH1 |
176 | destination node must send a challenge in the exact same way as already |
178 | |
177 | described (so, in essence, two simplex connections are created per node |
179 | That is, it encrypts (with the public key of the remote node) an initial |
178 | pair). |
180 | sequence number for data packets, key material for the HMAC key, key |
|
|
181 | material for the cipher key, a salt used by the HKDF (as shown later) and |
|
|
182 | some extra random bytes that are unused except for authentication. It also |
|
|
183 | sends the public key of a curve25519 exchange. |
|
|
184 | |
|
|
185 | The remote node decrypts the RSA data, generates it's own ECDH key (ECDH2), and |
|
|
186 | replies with: |
|
|
187 | |
|
|
188 | HKDF-Expand (HKDF-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2 |
|
|
189 | |
|
|
190 | That is, it extracts from the decrypted RSA challenge, using it's ECDH |
|
|
191 | key as salt, and then expands using the requesting node's ECDH1 key. The |
|
|
192 | resulting has is returned as a proof that the node could decrypt the RSA |
|
|
193 | challenge data, together with the ECDH key. |
|
|
194 | |
|
|
195 | After both nodes have done this to each other, they calculate the shared |
|
|
196 | ECDH secrets, cipher and HMAC keys for the session (each |
|
|
197 | node generates two cipher and HMAC keys, one for sending and one for |
|
|
198 | receiving). |
|
|
199 | |
|
|
200 | The HMAC key for sending is generated as follow: |
|
|
201 | |
|
|
202 | HMAC_KEY = HKDF-Expand (HKDF-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE) |
|
|
203 | |
|
|
204 | It extracts from MAC and ECDH_SECRET using the I<remote> SALT, then |
|
|
205 | expands using a static info string. |
|
|
206 | |
|
|
207 | The cipher key is generated in the same way, except using the CIPHER part |
|
|
208 | of the original challenge. |
|
|
209 | |
|
|
210 | The result of this process is to authenticate each node to the other |
|
|
211 | node, while exchanging keys using both RSA and ECDH, the latter providing |
|
|
212 | perfect forward secrecy. |
|
|
213 | |
|
|
214 | The protocol has been overdesigned where this was possible without |
|
|
215 | increasing implementation complexity, in an attempt to protect against |
|
|
216 | implementation or protocol failures. For example, if the ECDH challenge |
|
|
217 | was found to be flawed, perfect forward secrecy would be lost, but |
|
|
218 | the data would still be protected. Likewise, standard algorithms and |
|
|
219 | implementations are used where possible. |
179 | |
220 | |
180 | =head2 Retrying |
221 | =head2 Retrying |
181 | |
222 | |
182 | When there is no response to an auth request, the node will send auth |
223 | When there is no response to an auth request, the node will send auth |
183 | requests in bursts with an exponential back-off. After some time it will |
224 | requests in bursts with an exponential back-off. After some time it will |
… | |
… | |
203 | will try to connect every few seconds. |
244 | will try to connect every few seconds. |
204 | |
245 | |
205 | =head2 Routing and Protocol translation |
246 | =head2 Routing and Protocol translation |
206 | |
247 | |
207 | The GVPE routing algorithm is easy: there isn't much routing to speak |
248 | The GVPE routing algorithm is easy: there isn't much routing to speak |
208 | of: When routing packets to another node, GVPE trues the following |
249 | of: When routing packets to another node, GVPE tries the following |
209 | options, in order: |
250 | options, in order: |
210 | |
251 | |
211 | =over 4 |
252 | =over 4 |
212 | |
253 | |
213 | =item If the two nodes should be able to reach each other directly (common |
254 | =item If the two nodes should be able to reach each other directly (common |