You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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


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


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


We will have distributed system property “secure-udp-dhalgo” to enable UDP message encryption. Application can define algorithm available in JDK like “AES”, “DES”, “Blowfish” etc. Each member need to define this property with same algorithm.

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


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


From this point onwards member will communicate UDP messages using cluster-key as described in 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 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, now locator sends “FindCoordinatorRequest” using udp message instead of tcp as described above. We will encrypt “FindCoordinatorRequest” request using saved public key of member to find the coordinator.

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


Performance: There will be cost of encrypting/decrypting the message.  But in this approach message will be encrypted once only, even that need to send more than one member. As we have cluster wide secret key.

 

 

  • No labels