Feature - Secure encryption, with Hydra
Greek mythology tells of the Lernaean Hydra, a nine-headed serpent with poisonous breath and a unique defensive system: every time you cut off one head, two more grew in its place.
According to legend, the acted as an effective guardian; if it were real, you might want one to guard your most important belongings.
In the world of grid computing, the Hydra data encryption system does just that: it is designed to help protect sensitive data while being stored and transferred.
It may be especially useful in the worlds of medicine and finance, where data is often highly sensitive and security is paramount. (In contrast, while the high energy physics community produces and processes huge volumes of data, the information itself is not financially valuable or personally sensitive.)
Grids provide researchers with the computing resources they need, but in some fields, users need assurances that their data is protected from opportunistic hackers and corporate espionage.
This is where data encryption on the grid can help. The sensitive information can be used to generate a passkey required by the user to unscramble it. This means that it is less important if an unauthorized user manages to access the file, because they will be unable to read it without the decryption key.
Hydra, part of the European Middleware Initiative, encrypts data using a distributed key storage system. The passkey is generated and then split into components which are shared across multiple key stores on different servers and, if possible, in different countries. This is more secure than a central key storage system, which requires only one security breach to be compromised. In contrast, to obtain the passkey generated by Hydra, a coordinated attack on multiple servers is required.
The key is split using the Shamir Secret Sharing Scheme, a polynomial system which splits the key into a number of fragments, a specified number of which are required for the key to work.
For example, the key may be split into ten fragments stored on different servers, eight of which are required to decrypt a secured file. This means that if two servers are down, the key can still be obtained by accessing the other eight. However, seven fragments or less is not enough and the key will not work.
One use of Hydra is in conjunction with Digital Imaging and Communications in Medicine (DICOM) storage as part of the Medical Data Manager. DICOM entries are anonymized, as normal with patient information, and then Hydra encrypts the data to add an extra level of protection.
The Hydra system does not guarantee absolute security - compromised user credentials remain a problem and worker nodes are still vulnerable as users work on the decrypted files.
In the case of the latter problem, the developers of Hydra have attempted to reduce the risk by running most of the client work solely in the memory, so the decrypted information is not stored.
They are updating the code after a recent security audit.
The developers are also in discussion with a company to explore the possibility of using Hydra as a front end for generic cloud storage. Clouds are increasingly popular and if we want to start storing personal data on the cloud we need it to be protected - Hydra may be one way to achieve this.
-Seth Bell for iSGTW