November 11, 2012

The Risk to Your Encryption Keys when Using Virtual Hosting

by with 3 comments

Dan Goodin over at Ars Technica has a nice article with an example of one of the privacy risks of using virtual hosting (such as Amazon EC2 and other cloud computing services.) This particular scenario allowed attackers to recover GPG keys from other virtual machines that happened to be running on the same physical machine. It’s likely possible to recover SSH keys in a similar way.

Since a few customers have asked, SpiderOak owns and operates all of its own physical hardware. None of it is virtual hosting with other organizations.

  1. I have a few VPS'es running SpiderOak (headless servers). Would someone be able to somehow gain full access to my SpiderOak-account if they gained control over the VPS?

  2. wow, that's the one question I was wondering about SpiderOak. Is nice to know the answer as nice the answer is :)

  3. Wow, thanks for posting this information. I read the Ars Technica article and found in very interesting. I believe L3 processor cache, is the only cache level that is shared between all cores in newer multi-core processors. So I'm guessing this side channel attack must be targeting newer multi-core processors that employ L3 cache sharing. Seeing as VPS providers usually partition off one CPU core to each customer, perhaps it would be more secure for a multi-core server CPU to have seperated L3 cache address space for each core. If a VPS customer rents all the cores, then the L3 address space could be merged back together into a single unified L3 address space.

    Unless the scientists where running multiple VPS servers on the same processor core. I'd be upset if a VPS provider did this to me, because I'd want my own dedicated CPU core on the system I was renting. Anyways, it's nice to know that SpiderOak deploys their own hardware, and their customers don't have to worry about this.