On Wed, 26 Oct 2011 06:17:28 +1100 Justin Clift jclift@redhat.com wrote:

With the way HekaFS is encrypting data (tenant specific certs), it's pretty clear the data will be safe "at rest".

How do we protect against the hosting provider from reading certs/keys out of tenant memory while it's running, and keeping them for later?

Asking because apparently it isn't hard to extract encryption passwords from traditional encrypted file systems if they're running in a VM (and you're superuser on the host). So, same thought, but with the certs.

Right now we keep certs and keys away from the HekaFS (GlusterFS) servers, but they're still vulnerable on the clients. If the clients are also in a public cloud, then the public cloud provider could get them from memory as you describe. Unfortunately, there's not much one can do about this. Those keys have to exist in memory at least during the lifetime of an I/O, and as soon as you do that you're vulnerable to trapping and freezing the instance to get it.

In a way, this is where the future replication/caching features of HekaFS really become essential. If you want to put your storage in the cloud but run private clients somewhere else to avoid this particular vulnerability, then you're going to be dealing with higher latency. However, with caching at the client side you can avoid that latency most of the time and also get the full advantage of client-side encryption. Otherwise you're stuck choosing between security and performance.