{"id":641036,"date":"2013-02-02T15:00:34","date_gmt":"2013-02-02T20:00:34","guid":{"rendered":"http:\/\/gigaom.com\/?p=604638"},"modified":"2013-02-02T15:00:34","modified_gmt":"2013-02-02T20:00:34","slug":"where-kim-dotcom-and-mega-have-the-edge-on-dropbox-and-box-net","status":"publish","type":"post","link":"https:\/\/mereja.media\/index\/641036","title":{"rendered":"Where Kim Dotcom and Mega have the edge on Dropbox and Box.net"},"content":{"rendered":"

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<\/a>. 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.<\/p>\n

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\u2019s incredible run ended in the fall of 2012 when the FBI forcefully took down the site and sought Kim\u2019s extradition from New Zealand to face a litany of criminal charges.<\/p>\n

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\u00a0a security- and privacy-conscious file-sharing service that audaciously targets storage industry magnates like Dropbox and Box.net.<\/p>\n

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\u2019s local machine rather than encrypting everything in the cloud. The result of such client-side encryption is not only a far more secure product \u2013 and a security practice the industry should embrace \u2013 but a significant reduction in cost and legal liability for Mega and other cloud storage providers that use this architecture.<\/p>\n

How Mega is different<\/h2>\n

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\u00a0desire for privacy <\/a>and concerns of regulatory and legal exposure.<\/p>\n

In the movement to the cloud, data is exposed at two points to attack or compromise:\u00a0in-flight\u00a0(when it is being transmitted over the security no-man\u2019s land of the public internet) and\u00a0at-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.<\/p>\n

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

But Mega is unique in its approach to handling encryption at rest. Rather than encrypting and storing keys for a client\u2019s data within Mega\u2019s infrastructure, Mega pushes their cryptography back to their users. So Mega users encrypt their own data prior<\/em> to sending it to Mega\u2019s servers, and store keys locally such that even Mega can\u2019t read their data \u2013 or be forced to yield it to authorities.<\/p>\n

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”\u00a0(rather than unencrypted “plaintext)” is actually one shared by mainstream small businesses and enterprises alike.<\/p>\n

Benefit for providers<\/h2>\n

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.<\/p>\n

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 \u2013 a critical concern for compliance regulations like PCI-DSS that incorporate strict rules on cryptography.<\/p>\n

By having their customers manage keys locally, service providers can also significantly reduce costs. Many modern PCs incorporate a Trusted Platform Module (TPM) \u2013 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.<\/p>\n

The cost of encryption<\/h2>\n

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.<\/p>\n

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\u2019s data will be encrypted in a way that can\u2019t be decrypted using its service provider\u2019s security infrastructure. There\u2019s 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.<\/p>\n

It\u2019s 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<\/a> (in short, a process where copies or parts of files are deleted and data is instead \u201cpointed\u201d towards a single instance) are generally rendered impossible.<\/p>\n

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.<\/p>\n

Holes in Mega’s strategy<\/h2>\n

Mega\u2019s 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, \u00a0hackers could work around encryption and access plaintext data (what\u2019s called a “side-channel attack”).<\/p>\n

Regardless, to give credit where it’s due, Kim Dotcom\u2019s 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.<\/p>\n

Andrew \u201cAndy\u201d Manoske is an Associate at GGV Capital, a Sand Hill and Shanghai-based venture capital firm. Prior to GGV, he was a product manager at NetApp and managed the design of security features across the company\u2019s entire product line. Follow him on Twitter\u00a0@a2d2.<\/a><\/em><\/p>\n

\"\"<\/p>\n

<\/a><\/p>\n

Related research and analysis from GigaOM Pro:<\/strong>
Subscriber content. Sign up for a free trial<\/a>.<\/p>\n