Design, Implementation and Performance Analysis of a Distributed Key Encryption System Deployed within a Public Cloud

The advent of cloud computing has decreased the cost of enterprise level system design and implementation, while at the same time increasing the need for a sound and secure strategy for security. While the use of encryption algorithms continues to be the main line of defense in performing secure data transmissions, the use of a Cloud Computing environment offers both advantages and disadvantages in the encryption process. Though the new series of encryption algorithms are quite robust, they require a "key" to make their use unique for an individual session, thus if the key is compromised then the underlying encryption algorithm can be broken. In a classically designed system, the entire cryptographic key is contained on one node within the network, if this node is compromised even though robustly protected, then the entire network would be at risk.

The flip side to the potential breaking in dilemma outlined above is perhaps an even scarier option, one in which the node on which the key is kept is corrupted either through malicious intent, unintended mishap, or simple system failure. This scenario opens up the possibility that the key is unrecoverable, in which case the data that has been encrypted with the cryptographic key may be rendered unrecoverable as well.

This paper analyzed how a distributed key system, broken up over varying numbers of multiple nodal instances, and distributed across the Amazon Web Services (AWS) Cloud reacted and performed their intended task of authenticating a web service. Different numbers of nodes were evaluated and timing was recorded to assure that latency did not exceed the specified level of three seconds, where e-commerce or other Web based activities would be negatively impacted. As additional numbers of nodes were added to the system the latency increased. Also, as nodes were taken offline the latency also increased, as there were fewer options of key nodes that could reply to the system to replicate the key. And finally, when more than the required nodes were taken offline the system failed to authenticate the Client.