Hi guys,
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.
?
CC'd Richard Jones, as he pointed out the password extraction thought to me ages ago, and is more across this kind of thing.
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
On Wed, Oct 26, 2011 at 06:17:28AM +1100, Justin Clift wrote:
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?
I think the answer is ... you can't.
Unless someone invents practical fully homomorphic encryption.
However providers like Amazon are offering guarantees (unverifiable) that they take this sort of security seriously: https://aws.amazon.com/security/
Rich.
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.
cloudfs-devel@lists.fedorahosted.org