(originally posted July 23, 2009
here)
What does it mean to have secure storage in the cloud:
1)Only I can boot my virtual machine,
2)Unauthorized tampering of my virtual machine will be detected,
3)My data is accessed solely by my virtual machine, and
4)The system should not require me to enter a key or passphrase.
These seemly simple goals are surprisingly elusive.
Given that AWS encourages the use of encryption, this encouragement falls flat since they don’t provide any means of booting an encrypted virtual machine image. Someone corrupting your kernel with malware will be a bad day for you, but seems to be considered business as usual for AWS.
The
Cloud Security Alliance has issued their
“guidance”. Some may argue this guidance simply argues against using the cloud since they don’t offer any advice on how to meet their requirements. That said, there are important areas that can be addressed with technical solutions. This posting is an attempt to address one, data security. I paraphrase their requirement for data security to state,
-encrypt your data,
-don’t store your keys at your provider and
-ensure your provider uses standard encryption by contract.
I believe they got most of the goals right right, but they missed one.
-ensure your provider destroys all key material once it is no longer needed.
Contracts with the cloud provider should include a “no key storage” clause that states, “Any keys provided for use will not be retained any longer than absolutely necessary”. This kind of clause is not unprecedented. The
Payment Card Industry Security Standards state that merchants must not save the CVS number that is on the customer’s credit card even if they use it to authenticate the customer.
If encrypting virtual machine images are valuable, has the the
Open Virtualization Format group addressed this? Alas, no. Upon review the Open VIrtualization Format standard
document version 1.0.0, it states that they have described “
an ‘open,secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines’”. I highlight the term
secure because the definition of this statement is not contained in the document. What it does say is the files
may be signed. Signing the files is valuable as it provides integrity or authentication, but is it a basis for saying the format is “secure”? It might be more accurate to use the term “dependable”. Signatures do not provide confidentiality, and as such provides no protection from “unauthorized access” since the contents of a signed document is still in the clear.
Even if the AMI contains an OVF signature, most virtual machines modify their disk images. There are no indications that AWS will put the signatures back on a disk image after they bring the virtual machine down. As a result, after the first boot, the OVF’s AMI would be stored in S3 without confidentiality, integrity or authentication.
Using cryptography in storage is well understood. There are a plethora of products and now even standards like
P1619that address this. Why is the cloud so far behind? It may be because of a common belief that key management is complicated. Later in this document I will describe a key storage mechanism that can only be described as simple.
NIRVANA
I will describe the bring up sequence that meets the four objectives listed above using a non-exact pseudo code for description. I won't dive into the math as I wish to concentrate on the ideas.
The setup is as follows
1)I get a key from my provider. This is a key that is only usable for this AMI (virtual disk).
2)The first goal is to copy the kernel out of the AMI (an identical copy of the kernel is still in the AMI). I encrypt the kernel by a key which is the combination (hash of?) the kernel key I received from my provider, and a key of my choosing. I need to use an authenticated encryption mode (such as GCM). I then hash the encrypted kernel for use in step 4.
3)I encrypt the virtual disk by a key that is contained in the my own kernel. One can consider this sort placing keys in a kernel as a a bug, but in this key is wrapped by step 2. The kernel can do whatever it needs to during initialization to hide the key (which is itself an interesting exercise, see Residual Vulnerabilities below).
4)I then encrypt the “key of my choosing” (step 2) with the “hash of the encrypted kernel” (also step 2) and a “Boot Key” that I just created. I then prepare for encrypted key to be requested by my provider. I provide my provider with the REST URL it can use to obtain the encrypted key.
This is it. Simple, straight forward. My machine is now ready to be booted.
The bring up sequence is as follows.
5)I command my provider to bring up my virtual machine. This interface is not talking to the actual machine that is going to do the boot, it is talking to a service. As a result, a boot is initiated on some machine. I pass my “boot key” in.
6)The booting machine makes a REST call to the address that I prepared in step 4 to obtain the encrypted “key of my choosing”. My nirvana is that this key is stored under my control on my iPhone, the application on my iPhone will check that the request is authentic, protected by some encryption (ssl?), and (if all is good), the booting machine receives the encrypted “key of my choosing”. Even better, my iPhone alerts me to this request and possibly requests my permission.
7)The booting machine decrypts the received key with the calculated “hash of the encrypted kernel” and “boot key” to obtain the “key of my choosing”. The booting machine combines (hash of) the “provider key” and the just decrypted “key of my choosing” to decrypt and load the broken out kernel into memory (remember to check the GCM hash). At this time, my provider will destroy all the key material in it’s possession (by the contract clause discussed above).
8)Control is passed to my kernel which already has the key to my virtual disk(s) embedded in it.
All is good. My kernel is up. I have met the goals 1-4 above. My kernel can encrypt my virtual disk with
P1619 or any other encrypted disk format.
Enterprise version
So, how would I change steps 1-8 above for enterprise usage of the cloud? I simply store the key described in step 4 either at some internet accessible service, possibly even on my enterprise or at some “relatively trusted” third party key storage system. One could put the key into my provider storage service, but this would violate the “don’t store your keys at your provider” rule.
Relatively Trusted Third Party
A relatively trusted third party holds short blobs of information with the following security goals.
1)they do not lose them physically and
2)they do not allow the wrong people to access them.
This only needs to be relatively trusted because the deposited key is already wrapped. This key alone does not allow access to any data. It would require collusion with my provider, and violation of my service contract to gain access to my information.
I now need to rant a few moments.
<rant>Key management systems that exist or are being created combine key storage with key management. To be blunt, this is nonsense.
I will use a simile to banks. Banks have safety deposit boxes. There are lots of valuable “stuff” of various types in these boxes. The only goal of this service is to store contents securely (in protection from loss, and with privacy) and allow access to this information by authorized people. In this context authorized people is anyone the box owner elects.
All existing key management solutions that I know of combine key storage and management. This is like a bank that offers a service to manage the contents of everyone’s safety deposit boxes. If you store a passport in the safety deposit box, they will tell you when it expires, and maybe even when you great-great-grandmother's silver needs cleaning. Clearly, such a service for all possible things stored in safety deposit boxes is ridiculous.
I am not arguing that key management is not needed, I am arguing that key management is a layer that can and should be layered on top of, and independently of, the key storage service.
No key management system can know the motivation of all forms of short secrets someone may want to store. Assuming that you know all the key type or how to manage them is either folly or naiveté. Most claims to the contrary are by companies looking to get rich quick on the fact that they have patented the one and only solution to the “key management problem”. If you think your key management center does not apply, comment and tell me that it can store and retrieve arbitrarily short binary blobs without problem. I would really like to use such a service. Personal data assistants such as
spashid and
1password come the closest. </rant>
Key Storage Service
I guess I could call this a “Cloud Key Storage Service” but putting the word Cloud in front of everything runs shivers up my spine (but I digress again).
The API for a Key Storage Service service has 4 or 5 simple REST calls.
1)User Register. This allows a random person to register keys. This could be with the exchange of money, email addresses, anonymous, or any form of DoS prevention.
2)Key Register. A registered user can register a small binary blob (key) and specifies the identity (or identities) whom are authorized to extract the key. This returns a secure REST query URL that will be used to extract the key. If the user does not authorize themselves, they can not extract the key.
3)Extract a key. An authorized entity uses the REST query URL to extract the key providing their identifying information and receiving the key over a secure channel.
4)Delete a key. A registered user can request that their key(s) be destroyed.
Lastly, and I am not sure it is needed is:
5)Update key. A user may change the stored value and/or update the list of authorized users.
If anyone has or wants to build such a web service, please let me know. I would like to standardize such a service so that a M of N secret splitting amongst key storage services can be performed separate from this layer.
Security issues
This protocol protects the Kernel by encrypting it with keys from the provider, two keys provided by the user, and the hash of the encrypted kernel, and requires interaction with an external key storage system.
The key stored at the key storage service is protected by the hash of the kernel and the boot key, and is communicated securely over ssl. This key has no value by itself.
The user data on the disk image is protected by a key stored in the kernel.
The entire kernel and AMI can be revoked by forgetting the “boot key” or commanding the key storage service and/or the provider to delete the key. (Better yet, do all of them.)
Key loss
Any one item being disclosed has no consequences for privacy. In the event of the known compromise of any key, the disclosure of the encrypted kernel, or the disclosure of the encrypted AMI, the requirement is to revoke all the keys. The easiest way to think of this is to recover the AMI from the provider, decrypt it, revoke all the keys, and start again at step 1. In some cases, it is possible just to re-encrypt the kernel and change the boot key, but this is risky in my book.
Residual Vulnerabilities
Cloud computing has risks. Your machine could be running on top of the ultimate root kit, a hypervisor. Even if you are careful about encrypting all your data, you are still vulnerable if the provider wants (or is obliged to) access your virtual machine when it is running, or live migrate it over an unencrypted link. The most trivial case is to suspend your virtual machine and then look in the memory file for key material. The provider can trace the execution to discover encryption algorithms, etc. failing that, they can still install a backdoor to allow them to log in, etc.
If your provider keeps the keys, they can use them to access your AMI any time they wish. Although, this is not a vulnerability until your VM has been booted at least once since the vendor does not have the “boot key”.
Cloud computing has risks, if you don not trust your cloud vendor, don’t use the cloud. The safeguards described here are really to protect your machine while it is powered off.
There is one residual cryptographic issue, the virtual disk is encrypted by a key that is inside the the kernel (which is also in the virtual disk). This self-encryption of a key is an issue discussed in “
Storage Encryption: A Cryptographer’s View”. One solution is to only put the AMI key into the external version of the kernel, and not in the internal version.
What should be obvious is that if your machine is insecure while running, all bets are off, but that is a completely different subject entirely.
Lastly, commanding a Key Storage Service to delete a key is more advisory than absolute. One of their goals is to not lose it, so they probably have backups. One can argue that this is more likely correct to say unlink the key and leave it unreferenced and unavailable, but I can still imagine that there would be possibilities that a deleted key could accidently become undeleted. One can argue that this is why on any Key loss, revocation and re-encryption are necessary. .
Items left for the reader.
A competent cryptographer can:
-Change the use of symmetric keys to asymmetric keys
-Implement the key splitting protocol amongst key storage services.
A competent Kernel programmer can:
-Implement storing the AMI key in the key storage service, and requesting it as a part of the kernel bringup.
-Implement getting the “my provider” key in a secure manner during the boot sequence using a key storage service within the cloud infrastructure.
Conclusion and future work
First, I applaud your getting this far. You can signify this fact by unobtrusively working the word “wombat” into your comments or email.
The safeguards described here are to protect your machine while it is powered off and provide a key management scheme that allows the transition from off to on and on to off in a secure manner.
I’ve demonstrated that key management and key storage can (and should) be separate layers, and have described a simple web based key storage API. I’ve have discussed what to do in the case of a known breach, what are the residual vulnerabilities and obvious extensions to this scheme.
Next steps could be to work on a prototype. It will require changes to the boot process in Xen or KVM as well as some more formal crypto work. Sounds like a great Master’s or even PhD project? There are papers to be written and even the possibility of standardization. Anyone want to create a
standards group for this?
Feel free to leave a comment or contact me directly at
jphughes@mac.com if you have the urge to write something, Develop something, or just comment. I would be happy to work with University students or teams that want to take this project on.
Thanks or your attention. 谢谢您, Большое спасибо, Merci beaucoup
