Sophos Cloud Optix
The party-time news of the past weekend was the launch of Kim Dotcom’s comeback file sharing service, Mega.
If you’ve been out of touch with security shenaningans for the past twelve months, Kim Dotcom is a larger-than-life German-Finnish entrepreneur currently based in New Zealand.
He was born Kim Schmitz, and was variously known as Kimble and by the Goonshowesque moniker of Kim Tim Jim Vestor before changing his name to Dotcom and settling flamboyantly into the digital storage locker business with his company Megaupload.
Things got a bit wild last year, when the FBI enlisted the help of Kiwi law enforcement to try to take him down for piracy and racketeering.
The allegations seemed fairly straightforward: a huge proportion of Megaupload’s stored content was pirated material. Yet the company had annual revenues of nearly $200,000,000 per year, and Dotcom lived in New Zealand’s most expensive house. (As he had a criminal record, he wasn’t able to buy it, but had to rent it instead.)
Dotcom was dragged out of a safe room in the house, arrested, managed to make bail, was in and out of court fighting against extradition and for access to his frozen assets…and also found time to to reinvent his business under the brand name Mega.
The launch took place last weekend because it was the anniversary of his controversial arrest.
The difference this time is that the service has been designed to shield Mega from allegations of knowingly hosting and profiting from rampant piracy. That’s been done using cryptography.
Everything you upload is encrypted before it leaves your browser, using a key that is only ever known to you. When you download it, it’s decrypted at your end of the connection.
So, the theory goes, it’s not a file sharing service, because Mega itself is ignorant of your folders, files and contents. In its own words, it’s:
An awesome cloud storage service that will help protect your privacy.
Put another way, all it does is to store a giant pile of shredded cabbage on your behalf.
So that you don’t need to install any specialised software or drivers on your computer, Mega is driven by JavaScript (not Java!) inside your browser.
Writing crypto services in JavaScript doesn’t give you the fastest software around, but it does make your service much easier and therefore, you might argue, safer to use.
(The crooks have known this for years, with online malware toolkits like Luckysploit using JavaScript-based public key cryptography so that sniffed copies of its HTTP payloads can’t be decrypted once the attack is over.)
But critics have already taken issue with some aspects of Mega’s implementation, notably including the following observations:
1. The private key generated in your browser when you first use Mega relies on JavaScript’s Math.random() function.
Software random number generators are notoriously risky.
If you can guess the starting seed that was used, you can repeat a previously-issued sequence and attack the security of the cryptosystem that used it.
As the famous mathematician and computer scientist John von Neumann is supposed to have said:
Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number. There are only methods to produce random numbers, and a strict arithmetic procedure ... is not such a method.
2. Mega’s terms of service explicitly state that the service “may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service.”
But critics want to know why this possibility is even entertained, if Mega really does encrypt every uploaded object uniquely for each user in a fashion that makes its name and content invisible to Mega’s servers.
Deduplication ought to be impossible.
Indeed, Mega’s FAQ explains that you won’t see thumbnails or video previews on the service precisely because its end-to-end encryption model “precludes any server-side manipulation of your data”.
Even if the duplicated content can’t be retrieved, merely knowing that user A and user B have the same stuff is a privacy problem, because a leak by user A (or a confession to law enforcment) then turns into a leak for user B.
3. The Mega signup service sends a confirmation email containing an AES-based hash of your master key, thus allowing an off-line dictionary attack.
A online cracking tool has already appeared for these confirmation emails.
It’s rather slow, but critics point to it as evidence of a cryptographic design decision that ought to have been avoided.
The company has responded with some rebuttals and reassurances on its blog, notably:
1. The key generation stage uses mouse movements and keystroke timings to improve randomness slightly, and a feature will be added soon allowing you to add your own randomness into the process.
2. Deduplication is only ever done on the already-encrypted data, so Mega still doesn’t see the raw content.
3. Choose a decent password.
To which critics will probably reply to say:
1. Mouse and keyboard movements aren’t very good additional sources of randomness.
2. Knowing that two files are the same, even without knowing the content, nevertheless leaks information about the data.
3. That’s still a bit like saying to a driver before he sets off, “Don’t have a crash!”
There are other issues to consider, too, like just how much you want to entrust to the cloud under any circumstances.
As Naked Security’s Chester Wisniewski warns on Technews Daily:
I wouldn't recommend storing your most sensitive information in the cloud, encryption or not. How much trust do you grant to convicted felons under other circumstances?
In short, expect more controversy about Mega and its perceived security. I’m sure that Kim Dotcom wouldn’t want it any other way!
I'll be using it to store website backups. You can always use your own encryption and then upload it. They give you 50GB and without deduplication methods with all files I don't understand how they can survive with this huge freemium model. Dropbox only gives 2GB and 10GB/day bandwidth.
Regarding point 2: Duplication control is done on encrypted files. Now, given that those two files are from different users with -hopefully- different encryption keys, does the fact that the two encrypted files are exact duplicates mean that the original, unencrypted files are also duplicates? Almost certainly not. So, as long as the one left over encrypted copy can be decrypted by both users into their respective original files, no one is worse off. The fact that the encrypted copies are duplicates (can anyone calculate the odds for that?) should yield no information about the correspondence of the original files, which is what matters, just as the fact that two ATM cards have the same PIN does not mean that they are the same ATM cards.
De-duplication on encrypted files or blocks would be highly unfeasable. If the blocks were 256 bits long (read: very short – 1/28672th of a digital photo, or about 1/2 of a text message), there would be a 2^256 chance of a collision for any given pair of blocks. If a petabyte of data were uploaded, there would be about 19342813113834066795298816 pairs of blocks. This would result in about 1.670 x 10^-52 collisions per petabyte of data.
If anybody thinks that my math is off, please let me know.
TL;DR De-duplication of a petabyte of random data results in negligable space savings.
"2. Deduplication is only ever done on the already-encrypted data, so Mega still doesn't see the raw content."
Surely, if the same file is enctypted by two different users using different keys, the uploaded files will be different – so how can they then dedupe?
I think the idea is that when dealing with the volume of data they deal with then you start having things happen such as 2 different files being encrypted to the same value. So one key decrypts to one file and other key to the other file.
Admittedly this is almost unbelievably rare….. but you just have to think about the quantity of data that was in Mega-upload. I bet there were more than a few odd statistical improbabilitys in that data.
These are all good points from a security perspective… but the security he is interested in, is his own. Not his customers. This is Mega-Protection from Liability (HIS liability). Not Mega-Security Storage. Remember his old biz model – you the user are not his direct customer.
Mr. Dotcom's "new" business model seems more than a little like someone who makes a house available to anyone who wants to use it for any purpose, and then absolves himself of all responsibility for what goes on there by saying he won't peep in the windows. If you want to use it to distribute crack or stolen property…no matter; he claims he's off the hook because he's ignorant of what you do there.
Arguments about the technical aspects aside, it's difficult to imagine that the legal powers-that-be are going to be amused (or tolerant) for very long.
It looks like the marketing story is "we're more secure than our competitors because you encrypt your files in-browser, before uploading then to us; we can't decipher them".
But also, the fine print on the website and third party research reveal that the encryption would be trivial to circumvent, so Mega needs to be trusted to "not do that"? Is that right?
I'm with JC, 2 words, plausible deniability. I would expect that the crypto system is not so much a method of securing data and protecting privacy, as it's more simply a way for Mega to protect themselvse from litigation.
"Sorry Mr. US Federal investigator, we at Mega have no idea what data is stored, it's 'encrypted'.. Have a nice day."
Surprised to hear they are using Math.random(), as their preferred browser, Chrome, has supported a secure way of getting random random numbers for quite a while now: https://developer.mozilla.org/docs/DOM/window.cry…
Ok, looks like they knew of that (see the source: https://eu.static.mega.co.nz/keygen_1.js#).
So the key generation is not as insecure in Chrome as it is in other browsers.