Is Crypto in the Cloud Enough?

By Jon-Michael C. Brook

Box.net, DropBox, iCloud, SkyDrive, Amazon Cloud Drive... the list goes on for convenient cloud storage options. Some have had a security incident; the rest will. All implement some form of protection against accidental exposure with varying degrees of protection. Are these sufficient and, in the ones claiming cryptographic isolation, truly implemented in a manner enough for more than sharing pictures of the kids with Aunt Betty? We’ll examine the technologies, architectures, risks and mitigations associated with cloud storage and the cryptographic techniques employed.

Even with the promise of cloud, all of the providers are looking to monetize their service. For the past couple of years, the draw of "unlimited" to build up the user counts for a service has been adjusted downwards. Mozy was one of the first, discontinuing their unlimited backup service in 2011. Microsoft's SkyDrive dropped their free service in April 2012 from 25 GB down to 7 GB. Why did providers serve up free access and what’s moving them in a different direction?

Online Storage Drivers

There are three components driving requirements for each of these services: Privacy/Security, Locale and good old fashioned cost. They all intertwine into a mishmash of designs and constraints.

Privacy/Security

Some governments/organizations require that, for security, data remain within their borders, regardless of encryption - the locale aspect. A judge or government may compel a Cloud Service Provider to disclose requested data when they hand down a legal order or sign a search warrant. Most of the Providers write into their use policies that they will comply with law enforcement requests.

This sort of blatant disregard for a user's privacy scares European Union citizens. The entire purpose of the EU's Data Protection Directive (Directive 95/46/E) , and its antithesis, the US PATRIOT Act surrounds who can access what private data. Some of the security and privacy aspects may be answered through cryptography. A full treatment of encryption as a service may be found on the Cloud Security Alliance's website.

Location

Locale is the easiest to address and hardest to guarantee. Various laws require data stay within their government's borders. If data migrate past those borders, the service provider is subject to fines. This varies between countries, trust reciprocation and what sorts of protections are/are not considered adequate for ignoring said provisions. In some cases, segregation through cryptography suffices in complying with location based laws.

Costs

The last storage driver is cost (although it might be first from a provider's perspective). The business efficiencies expected for Storage as a Service and the reason the above providers thought they could turn a profit hinge on the type of data de-duplication seen in the enterprise. Separate copies of, for instance, a popular MP3 file or a Power Point presentation are not individually stored; a pointer to that file exists instead that all of the service users may access. The benefits are huge, where enterprises see as much as a 50-90% reduction in storage space necessary. This efficiency requires storage vendors’ access to the data they are storing for comparison.

Compromise

How do you balance these three? Which aspects allow you to meet your privacy/security/regulatory policies without jeopardizing your bottom line? Let’s dissect the solutions:

• Underlying technology – Cost is a mighty significant factor in designing an on-demand storage service. Many of the most popular solutions were created on a shoestring budget. What better way to operate under tight fiscal constraints then to use the power of the cloud and scale up or down with workload. It turns out that at least a couple of the more popular services (currently) use Amazon's S3 (Simple Storage Service ). S3 includes built in cryptography, where key material resides, not on Amazon's servers, but within the application making the S3 API calls. What the services do with the key material is up to them. For simplicity, some services allow Amazon to manage the keys, as discussed later.
• Cryptographic algorithms – With few exceptions, everyone uses 256 bit SSL/TLS for data-in-transit protection and when encrypting data-at-rest, 256 bit AES. These are today's de-facto standards, and there are easier ways to breach security than brute force attacks on 128 bit or longer key lengths.
• Key material – In Server Side cryptography, the service provider manages both the keys and your data. This limits the complexity of the environment and allows for the de-duplication aspects mentioned earlier while still providing user to user data isolation. If a user deletes a file, it may be recovered without much fuss. Crypto hygiene takes place without issue: Keys may be rotated appropriately, split into separate locations and put into Highly Available clusters.

So What Are the Risks?

Put simply, storing key material with the information it is designated to protect is akin to leaving the vault door unlocked at a bank. As long as no one is trying to get in, you might get away with it – for a while. The service provider may be compelled, against your wishes, to produce the key material and data with warrants in the US and similar government requests in other countries. Most privacy policies actually document their compliance for these requests (see table). Trusted insiders can poke around and access keys and thereby data. Programming and operational mistakes may come to light, as was evidenced in the Dropbox disclosure incident.

Client Side Cryptography

There really is no one you can trust besides yourself. Rich Mogul from Securosis makes a couple of duct tape style suggestions for sharing within an insecure environment using various forms of encryption. Newer providers Jungle Disk and Spider Oak label their services as inaccessible to anyone without permission – you have a password which decrypts your keys and then all sharing and use operations occur from there. Jonathan Feldman makes the case that secure sharing defeats the purpose of the cloud file sync and is just wrong.

This is far from an exhaustive list. All of the products listed have their place, and should be used according to your specific application and to their strengths/avoided dependent on their weaknesses.

For a very in-depth treatment of cloud storage security, with a special emphasis on one of the most privacy paranoid countries in the world (Germany), please see the Fraunhofer Institute for Secure Information Technology’s Cloud Storage Technical Report.

Jon-Michael C. Brook is a Sr. Principal Security Architect within Symantec's Public Sector Organization. He holds a BS-CEN from the University of Florida and an MBA from the University of South Florida. He obtained a number of industry certifications, including the CISSP and CCSK, holds patents & trade secrets in intrusion detection, enterprise network controls, cross domain security and semantic data redaction, and has a special interest in privacy. More information may be found on his LinkedIn profile.