Cloud computing is the delivery of computing as a service rather than a product, whereby shared resources, software, and information

are provided to computers and other devices as a metered service over a network (typically the Internet).[1] Computing clouds provide computation, software, data access, and storage resources without requiring cloud users to know the location and other details of the computing infrastructure. Within limits, cloud users can consume any amount of these resources without having first to acquire servers or other computing equipment. A parallel to this concept can be drawn with the electricity grid, wherein end-users consume power without needing to understand the component devices or infrastructure required to provide the service. End users access cloud based applications through a web browser or a light weight desktop or mobile app while the business software and data are stored on servers at a remote location. Cloud application providers strive to give the same or better service and performance as if the software programs were installed locally on end-user computers. At the foundation of cloud computing is the broader concept of infrastructure convergence (or Converged Infrastructure) and shared services.[2] This type of data centre environment allows enterprises to get their applications up and running faster, with easier manageability and less maintenance, and enables IT to more rapidly adjust IT resources (such as servers, storage, and networking) to meet fluctuating and unpredictable business demand.[3][4] Commercial offerings may be required to meet service-level agreements (SLAs), but specific terms are less often negotiated by smaller companies.

Encrypted Storage and Key Management for the cloud By James Hughes

What does it mean to have secure storage in the cloud:

1. 1)Only I can boot my virtual machine, 2. 2)Unauthorized tampering of my virtual machine will be detected, 3. 3)My data is accessed solely by my virtual machine, and 4. 4)The system should not require me to enter a key or passphrase. These seemly simple goals are surprisingly elusive. I dont believe much has been written or done about the vulnerability of your data in the cloud. Maybe it is just obvious. The AWS Customer Agreement clearly states that they have no liability to you for any unauthorized access or use, corruption [...] of Your Content or Applications and strongly encourage you [...to] use encryption technology to protect Your Content from unauthorized access. The effect of someone intentionally corrupting your virtual machine image is clear. Back doors can be added, data siphoned, keys, cryptographic algorithms, and/or random number generators weakened (as if they were not already bad enough). These can lead to a really bad day even if the remainder of your data is encrypted. Given that AWS encourages the use of encryption, this encouragement falls flat since they dont 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 dont 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, 1. 2. 3. your data, -dont store your keys at your provider and -ensure your provider uses standard encryption by contract.
-encrypt

I believe they got most of the goals right right, but they missed one. 1.
-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 customers 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 OVFs AMI would be stored in S3 without confidentiality, integrity or authentication. Some talk about using the cloud to store your encrypted backups. These include Glenn Brunettes Cloud Safety Box, Oracles Database Backup in the Cloud using the RMAN commands, etc. There are others that talk about encrypted volumes in the cloud, one being Istvn Sos who describes an encrypted block partition. These do not address the issue of unencrypted kernels and operating systems. Using cryptography in storage is well understood. There are a plethora of products and now even standards like P1619 that 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 nonexact 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. 1)I get a key from my provider. This is a key that is only usable for this AMI (virtual disk). 2. 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. 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. 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. 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. 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. 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 its possession (by the contract clause discussed above). 8. 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 dont 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. 1)they do not lose them physically and

2. 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 everyones 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.
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. 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

2.

2)Key Register.

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.
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. a key. A registered user can request that their key(s) be destroyed.

4.

4)Delete

Lastly, and I am not sure it is needed is: 5.

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 the providers hypervisor is hacked, all bets are off. Examples include Subverting the Xen Hypervisor. 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, dont 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 Cryptographers 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: 1. -Change the use of symmetric keys to asymmetric keys 2. -Implement the key splitting protocol amongst key storage services. A competent Kernel programmer can: 1. -Implement storing the AMI key in the key storage service, and requesting it as a part of the kernel bringup. 2. -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. Ive demonstrated that key management and key storage can (and should) be separate layers, and have described a simple web based key storage API. Ive 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 Masters 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? Acknowledgements go to (In alphabetical order) Geoff Arnold, Bart Blanquart, Kathy Jenks, Adriana Lucas, Alec Muffett for helping write 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.

With that M&A activity as background, here are my rankings for the Top 30 Cloud Service Providers Gaining Mind Share in 3Q 2010. 1. Amazon Web Services (AWS), Elastic Compute Cloud (EC2), Simple Storage Service (S3), andVirtual Private Cloud (VPC) 2. Salesforce.com / Sales Cloud 2 (CRM), Service Cloud 2 (Support), Force.com (Development Platform), Chatter (Collaboration) 3. Google Apps (AppEngine) 4. Citrix XenServer (Virtualization) 5. VMWare vSphere (Virtualization) 6. Rackspace Mosso 7. 3PAR 8. Cisco 9. IBM Smart Business, Cloudburst 10. AT&T Synaptic 11. Verizon 12. rPath 13. Appistry 14. Rightscale (#7 management) 15. Joyent 16. GoGrid 17. 3Tera AppLogic 18. Microsoft Azure, Hyper-V

19. NetSuite 20. Zuora 21. Eucalyptus 22. CohesiveFT 23. Boomi 24. Red Hat 25. Appirio Cloud Connectors 26. Relational Networks LongJump 27. AppZero 28. Enomaly Elastic Compute Platform (ECP) 29. Intacct 30. Elastra

Characteristics
Cloud computing exhibits the following key characteristics:
y

y y

y y

Empowerment of end-users of computing resources by putting the provisioning of those resources in their own control, as opposed to the control of a centralized IT service (for example) Agility improves with users' ability to re-provision technological infrastructure resources. Application programming interface (API) accessibility to software that enables machines to interact with cloud software in the same way the user interface facilitates interaction between humans and computers. Cloud computing systems typically use REST-based APIs. Cost is claimed to be reduced and in a public cloud delivery model capital expenditure is converted to operational expenditure.[12] This is purported to lower barriers to entry, as infrastructure is typically provided by a third-party and does not need to be purchased for one-time or infrequent intensive computing tasks. Pricing on a utility computing basis is fine-grained with usage-based options and fewer IT skills are required for implementation (in-house).[13] Device and location independence[14] enable users to access systems using a web browser regardless of their location or what device they are using (e.g., PC, mobile phone). As infrastructure is off-site (typically provided by a third-party) and accessed via the Internet, users can connect from anywhere.[13] Virtualization technology allows servers and storage devices to be shared and utilization be increased. Applications can be easily migrated from one physical server to another. Multi-tenancy enables sharing of resources and costs across a large pool of users thus allowing for: o Centralization of infrastructure in locations with lower costs (such as real estate, electricity, etc.) o Peak-load capacity increases (users need not engineer for highest possible loadlevels)

y y

y y

Utilisation and efficiency improvements for systems that are often only 1020% utilised.[15] Reliability is improved if multiple redundant sites are used, which makes well-designed cloud computing suitable for business continuity and disaster recovery.[16] Scalability and Elasticity via dynamic ("on-demand") provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads.[17][18] Performance is monitored, and consistent and loosely coupled architectures are constructed using web services as the system interface.[13] Security could improve due to centralization of data, increased security-focused resources, etc., but concerns can persist about loss of control over certain sensitive data, and the lack of security for stored kernels.[19] Security is often as good as or better than other traditional systems, in part because providers are able to devote resources to solving security issues that many customers cannot afford.[20] However, the complexity of security is greatly increased when data is distributed over a wider area or greater number of devices and in multi-tenant systems that are being shared by unrelated users. In addition, user access to security audit logs may be difficult or impossible. Private cloud installations are in part motivated by users' desire to retain control over the infrastructure and avoid losing control of information security. Maintenance of cloud computing applications is easier, because they do not need to be installed on each user's computer.
o