through h4x0r3d's eyes

As a world (in)famous technologist with the literal last name “Dotcom,” Kim Dotcom is a man whose swag is matched only by the damages sought against him by the U.S. government. His filesharing site Megaupload was long the ire of record companies and movie studios, who say it was a massive and sprawling repository of pirated content.

If the accusations are true, it was one of the more successful pirate operations in history. At its peak, Megaupload saw approximately 7 percent of internet traffic and grossed over $150 million in annual revenue. But Megaupload’s incredible run ended in the fall of 2012 when the FBI forcefully took down the site and sought Kim’s extradition from New Zealand to face a litany of criminal charges.

Of course, you can’t expect to keep a guy with the last name Dotcom down, and sure enough he recently announced the relaunch of a Megaupload redux dubbed Mega. Only Mega is a security- and privacy-conscious file-sharing service that audaciously targets storage industry magnates like Dropbox and Box.net.

And loathe as some of us may be to admit it, he just may be on to something. Mega differentiates itself by embracing client-side encryption: generating and storing the keys on a user’s local machine rather than encrypting everything in the cloud. The result of such client-side encryption is not only a far more secure product – and a security practice the industry should embrace – but a significant reduction in cost and legal liability for Mega and other cloud storage providers that use this architecture.

How Mega is different

Security is one of the biggest inhibitors to cloud adoption. Yielding sensitive data to a third party over the public internet continues to be a dealbreaker for many medium- to large-scale enterprises, with their desire for privacy and concerns of regulatory and legal exposure.

In the movement to the cloud, data is exposed at two points to attack or compromise: in-flight (when it is being transmitted over the security no-man’s land of the public internet) and at-rest (when it physically sits on servers within the cloud system). In both instances there are a myriad of threats that could allow that data to be stolen or compromised.

Mega employs cryptography to protect data in-flight and at-rest. Now by all means, using encryption to protect data in-flight isn’t really game changing. Similar to most security-conscious sites, Mega wraps communication between its users with Secure Socket Layer (SSL) encryption.

But Mega is unique in its approach to handling encryption at rest. Rather than encrypting and storing keys for a client’s data within Mega’s infrastructure, Mega pushes their cryptography back to their users. So Mega users encrypt their own data prior to sending it to Mega’s servers, and store keys locally such that even Mega can’t read their data – or be forced to yield it to authorities.

While this sounds like a feature tailored solely to the needs of a company that will frequently find itself at the end of a subpoena, the desire to have users keep their own keys and send data in the form of encrypted “ciphertext” (rather than unencrypted “plaintext)” is actually one shared by mainstream small businesses and enterprises alike.

Benefit for providers

Having cloud providers hold ciphertext and having users handle their own encryption and keep their own keys makes sense on both sides of the fence.

In an architecture where customers are responsible for their own encryption and key management, significant legal liabilities are lifted from the service provider. Customers would assume personal liability for the selection and correct implementation of encryption algorithms – a critical concern for compliance regulations like PCI-DSS that incorporate strict rules on cryptography.

By having their customers manage keys locally, service providers can also significantly reduce costs. Many modern PCs incorporate a Trusted Platform Module (TPM) – a hardware device that can safely store cryptographic keys for prolonged periods of time. Storing keys locally on a TPM is relatively costless for the customer, but safely storing keys en masse in the cloud requires the use of expensive key management servers.

The cost of encryption

Encryption is also still not a costless process. By pushing customers to encrypt and decypt their own data, cloud providers can also redirect the significant compute time required to handle cryptography towards providing a higher quality of service for their customers.

For customers, sending only ciphertext to the cloud and keeping keys locally has real benefits beyond peace of mind. If a cloud services provider is ever hacked, that customer’s data will be encrypted in a way that can’t be decrypted using its service provider’s security infrastructure. There’s no master database of passwords that an attacker can break into. Customer data on the service provider remains locked in ciphertext and encrypted using one of any number of symmetric key algorithms.

It’s important to note, though, that there are consequences for moving to a client-side encryption architecture. For instance, when customers send only ciphertext to the cloud, popular means of reducing the on-disk footprint of data such as deduplication (in short, a process where copies or parts of files are deleted and data is instead “pointed” towards a single instance) are generally rendered impossible.

It’s also important to note that, for the server to dedupe data encrypted by the client, the client must yield sensitive information about the plaintext at various points during its encryption. The fact that Mega seems to perform client-side encryption with deduplication is a red flag to many security cognoscenti, and may even be a sign that Mega has more visibility into its clients; data then it otherwise claims.

Holes in Mega’s strategy

Mega’s security infrastructure is far from perfect. Their decision to handle cryptography in browser-based Javascript has already earned wide-spread criticism, and due to implementation issues in how Mega creates keys for users,  hackers could work around encryption and access plaintext data (what’s called a “side-channel attack”).

Regardless, to give credit where it’s due, Kim Dotcom’s decision to push encryption to the client is an impressively forward-thinking maneuver that should be replicated by Dropbox and other cloud storage providers. Client-side encryption makes financial and legal sense for customers and service providers, helping to enable even regulatory compliance-bound customers to embrace cloud computing at scale.