Intelligent Key Management in the Cloud – RSA Conference

I was fortunate to be able to attend the RSA Security Conference in San Francisco last week. The conference was bigger than ever with lots of new vendors displaying a wide breath of security products. WinMagic had a booth where we introduced our new SecureDoc for Cloud solution that encrypts files before they are moved into the cloud by file sync services such as Dropbox, etc.

There were also hundreds of educational sessions organized into more than a dozen tracks. I focused on attending sessions in the “Cloud Security & Virtualization” track where I gained knowledge and perspective on encryption and key management for the cloud. Of course for cloud file sharing services, the files should be encrypted on the end point before it goes up into the cloud and the encryption key should not be stored or shared via the cloud. This is what SecureDoc for Cloud does.

There is another whole category of cloud storage that we refer to as “volume” storage.   Basically virtual machines or servers running in the cloud need to have virtual volumes or disks to store their data on. These volumes appear as block level storage devices not files. Unlike the file sync use case the data that is stored on these drives may be created in the cloud not moved to it. This data may be susceptible to unauthorized access by cloud provider insiders or be moved to other jurisdictions or be subject to requests for access by governments. Thus, it would be a good idea to encrypt this data. That brings up the issue of who should encrypt the data and who should manage the encryption keys for cloud volume storage.

In one of the sessions these Cloud Encryption Models were discussed:

Model

Definition

Server Side Encryption (SSE) Encryption performed by the cloud service provider using keys owned and managed by the cloud service provider
Server Side Encryption with Customer Provided Keys (SSE-CPK) Encryption performed by the cloud service provider using keys owned and managed by the customer
Client Side Encryption Encryption performed by the customer (in the cloud) using keys owned and managed by the customer

 

SSE

SSE protects against the use case where the cloud service provider recycles the under lying physical storage. As least plain text customer data shouldn’t end up on eBay but it doesn’t help protect against insider attacks where service provider employees could by mistake or on purpose access the data. Also with SSE governments could require the cloud service provider to use their copy of the encryption keys to decrypt the data without the customer’s knowledge.

SSE-CPK

SSE-CPK provides more protection than SSE because while the cloud provider performs the encryption (probably in the underlying hypervisor) the customer provides and manages the keys. The cloud service provider promises to only keep the keys in its hypervisor memory while the virtual machine is up and running. However, the keys still flow through cloud provider APIs (Application Program Interfaces) and it is not much of a stretch to divert these to disk if, for example, law enforcement insists.

Client side encryption

Client side encryption still occurs in the cloud but it is performed by the customer’s virtual machine not the cloud’s hypervisor. I have also heard this called “in-guest encryption”. The customer selects the encryption method and provides the encryption software. Most importantly the customer owns and manages the encryption keys. The customer could hide the keys in an unencrypted portion of the volume and have the virtual machine automatically find the key and boot. This addresses the use case were the customer wants to zap the storage when it no longer requires it. All they need to do is delete the key to crypto erase the image. (I don’t know how backups of these virtual machines are handled). A better approach would be for the customer to store and manage the keys for the virtual machines on their own premises. When the virtual machine boots up in the cloud it can use a pre-boot network connection to the key manager on the customer premise to retrieve the key. The encryption method should not store the key to disk but rather just keep it in the virtual machine’s memory. This method is the most resilient to insider attacks and government demands but it is still not perfect; while running the virtual machine will have the encryption keys in its virtual memory. This memory could be accessed and a determined advisory could retrieve the key but this is a much more difficult attack.


To sum up there are three models for performing encryption and key management in the cloud: SSE, SSE-CPK and Client Side Encryption. Of the three, I think that only the client side encryption method with keys accessed only when needed from the customer’s on premise key manager earns the title of “Intelligent Key Management for the Cloud”.

 

Previous Post
36% of Canadian Businesses Victim to Cyber Attacks in 2014
Next Post
3 Things to Know About Data at Rest Security

Related Posts

Yahoo! Security!

It’s always fun to come up with headlines around a brand that has an exclamation point as part of their name, but I digress. What this is really about is Yahoo!’s recent announcement that they’re going to start to encrypt…
Read more
Enterprise Encryption for Linux

Enterprise Encryption for Linux

Linux has built in encryption for several years now, yet enterprises still struggle with encryption on Linux laptops.  Why is that? To answer this question, let’s first review the disk encryption capabilities that are built into Linux: (more…)

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu