Introduction: Geode uses UDP communication for peer-to-peer membership protocol. It also uses UDP communication for region operations, when a region is configured with multicast enabled.  But all these communications happen through plain text over the wire. In Geode there is no option to encrypt UDP data.  


Proposal: We propose an encryption layer on top of UDP messages. Each message will be encrypted and decrypted using a cluster wide secret key. This secret cluster-key will be created by a coordinator and any member can get the cluster-key using a member-coordinator private key.  Using the existing authentication mechanism, Geode can be configured to authenticate a new member with the coordinator.  This authentication happens when a member joins the cluster. Thus the new member will see the cluster-key only when it is authenticated by an application. In that way all members can have a cluster-key, which can be used to encrypt and decrypt the UDP messages.


We plan to generate these keys using the diffie-hellman key exchange mechanism. Using this each member will have a secret key with other members in the cluster.


We will define the distributed system property “security-udp-dhalgo” to enable UDP message encryption. An application can specify any algorithm available in JDK, such as “AES”, “DES”, or “Blowfish”. Each member needs to define this property with the same algorithm.

Work-flow: In Geode, a new member joins the cluster using the locator. It makes a “FindCoordinatorRequest” request to the configured locator over TCP. It receivers a “FindCoordinatorResponse” response which includes the current coordinator’s address. This response will include the coordinator’s public key, if UDP encryption is enabled. This “FindCoordinatorRequest” request can be made secure by configuring cluster-ssl.  

The member then sends a “JoinRequestMessage” message to the coordinator. This message will be encrypted using member-coordinator key. Apart from this, the member will append its public key to the “JoinRequestMessage” so that the coordinator can decrypt the  “JoinRequestMessage” using the member-coordinator key. Then the coordinator will authenticate the join request, if it is configured. The coordinator then will send a “JoinResponseMessage” with the cluster-key. This “JoinResponseMessage” will be encrypted using the member-coordinator key.


From this point onwards, the member will communicate UDP messages using the cluster-key as described in the following diagram.

 

This diagram shows a member (N) using a locator (L) discovering the Coordinator (C) and joining N L C FindCoordinatorRequest(myId) via tcp/ip over ssl while starting the new node. FindCoordinatorResponse(c) this will have publickey for coordinator Restart of locator will use saved publickey in view.dat file, to encrypt FindCoordinator request over udp.We will prefix its publicKey with FindCoordinator message, so that member can decrypt findCoordinator request. N's Public key and JoinRequest (this request will be encrypted using N-C key) Application can authenticate new member here. coordinator will send joinResponse containing cluster-secret-key. This message will be encrypted using N-C key. From here all communication will happen through cluster-secret-key PrepareView(c,l,n) ack PrepareView(c,l,n) ack InstallView(c,l,n) ack InstallView(c,l,n) ack

Special case: When the locator restarts, it knows the previous view which was saved in view.dat file. This file will contain the public keys of all the members in the view as well. Thus, the locator can now send “FindCoordinatorRequest” using UDP messages instead of TCP as described above. We will encrypt the “FindCoordinatorRequest” request using the saved public key of each member to find the coordinator.

Testing: We will be testing various scenarios with UDP encryption enabled. We will extend unit tests with the distributed config property “secure-udp-dhalgo” enabled. This will ensure testing of all the scenarios (such as multicast, locator HA, reconnect).


Performance: There will be a cost to encrypting/decrypting the message.  But in this approach the message will be encrypted once only, even when sent to more than one member, as we have a cluster wide secret key.

 

 

  • No labels