Security experts have found a host of security vulnerabilities in Kim Dotcom’s new online storage venture Mega, but many suspect his claims of tough data protection were only a smokescreen to distract attention by law enforcement agencies.
Mega, a follow-up to Dotcom’s Megaupload service shut down by law enforcement, launched on Sunday. Its founder boasted it was “the privacy company”, offering 50GB of free online storage to every user and blanket encryption across the site.
Yet many potential security vulnerabilities have been highlighted by the community, including flawed encryption key handling, a cross-site scripting hole and problematic claims surrounding deduplication.
The encryption “is less than ideal”, according to Alan Woodward, from the Department of Computing at the University of Surrey. That’s largely because it is all done through Javascript in the browser, which means that anyone who can break the SSL encryption on Mega could get hold of the keys.
The SSL encryption being used on some Mega domains appears to be 1024-bit encryption, which can be broken with far greater ease than 2048-bit encryption – viewed as best-practice amongst experts. At least one of Mega’s sites uses only 1024-bit encryption to “reduce CPU load”, although Mega.co.nz uses 2048-bit.
Furthermore, if a hacker gained control of the Mega server they could either just turn off the encryption or get hold of the private key to decrypt users’ files. Even though Mega says it doesn’t hold the keys, Mega admins could get hold of them, as it would only take a minor code change on Mega’s servers to access those keys.
Some are concerned US law enforcement agencies, who are already trying to extradite Kim Dotcom over Megaupload’s alleged support for copyright infringement, will simply order Mega to hand over the keys.
“I can imagine the FBI are typing up their warrant as I type requiring the keys to be collected and the content of the servers to be analysed,” Woodward told TechWeekEurope.
Deduplication is another problematic issue. As was seen with Nokia recently, deduplication of encrypted data requires that information to be decrypted, repackaged and then encrypted again. The case of Mega is different, as it claims it can identify duplicated files, hinting the content may not be entirely secret.
According to Mega’s co-founder Bram van der Kolk, speaking to Forbes, it is looking at the entire encrypted file. So if a user uploads the same file encrypted with the same key twice, or if a copied file from a file manager is uploaded, one of those duplicate files will be deleted.
But the fact that Mega uses Javascript’s pseudorandom-number generator to produce the RSA keys, so users can share information with each other using public and private key infrastructure, is also an issue, as it is a method known to be predictable and lacking in entropy.
Despite the numerous security issues, many have questioned whether Mega isn’t simply boasting about its security to protect itself from law enforcement action. If it does not own the keys, and does not access user data, it will be oblivious to the legality of content uploaded to Mega.
“I think Mega is using encryption not for the security of their users but their own personal legal protection,” Woodward added.
“I cannot imagine anyone who understands encryption would trust their precious data to Mega’s scheme as it currently stands. It would appear that Mega is after people who are looking for somewhere to store their data with a provider who wishes to adopt a position of ‘see no evil’.”
The password problem remains both a security and usability issue, but Mega has promised to let users reset passwords soon. Currently, if they forget their password, they can wave goodbye to their files, regardless of the level of encryption.
UPDATE: Co-founder of Mega, Bram ven der Kolk, promised TechWeekEurope an update from Mega on the issues and has delivered in a company blog.
He confirmed the user password is used to create the master AES-128 master encryption key, which is held on Mega servers, which in turn unlocks private keys and the user’s content. This means Mega could indeed be ordered to find keys and then open up user content.
It also means that the lack of password reset is a big problem – if you forget your password you will have lost the key, meaning even if you got a new password, it wouldn’t recover your files. But van der Kolk has promised some changes.
“A password change feature will re-encrypt the master key with your new password and update it on our servers,” he explained. “A password reset mechanism will allow you to log back into your account, with all files being unreadable.
“Now, if you have any pre-exported file keys, you can import them to regain access to those files. On top of that, you could ask your share peers to send you the share-specific keys, but that’s it – the remainder of your data appears as binary garbage until you remember your password.”
To deal with the JavaScript pseudorandom-number key generation, used to produce a 2048-bit RSA key pair during sign-up for sharing files, Mega will add a feature that allows the user to add as much entropy manually as they see fit before proceeding to the key generation. That’s on top of the entropy provided by user mouse movements and key inputs.
Answering the SSL questions, the Mega co-founder added that a JavaScript verification system had been created to check code uploaded from 1024-bit encrypted connections against 2048-bit-protected connections, to ensure content hasn’t been changed.
“All active content loaded from these ‘insecure’, static servers is integrity-checked by JavaScript code loaded from the ‘secure’ static server, rendering manipulation of the static content or man-in-the-middle attacks ineffective. The only reason why HTTPS is supported/used at all is that most browsers don’t like making HTTP connections from HTTPS pages. And, using more than 1024-bit would just waste a lot of extra CPU time on those static servers.
“A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers. This basically enables us to host the extremely integrity-sensitive static content on a large number of geographically diverse servers without worrying about security.”
How well do you know Internet security? Try our quiz and find out!
Thoma Bravo agrees to acquire Darktrace for $5.32 billion in cash, delivering some welcome news…
Customer adoption of AI services embedded in cloud services continues to deliver results for Microsoft,…
TikTok's 'secret source' algorithm is so core to ByteDance, it would rather shut down US…
After relocating from California to Texas in 2020, Oracle's Larry Ellison now reveals plan to…
Share price hit after Meta admits heavy AI spending plans, after posting strong first quarter…
For third time Google delays phase-out of third-party Chrome cookies after pushback from industry and…
View Comments
To me this article is a lot of 'what ifs?'. First it says "anyone who can break the SSL encryption on Mega could get hold of the keys", which is true 128 bit is not as good as 256 but the overhead for 256 would be too high especially for file sharing. This should be substantial and if a breach happened then Mega would have to revoke the cert. This has happened to even some of the biggest tech companies in the world. Second, the article says, "If a hacker gained control of the Mega server they could either just turn off the encryption or get hold of the private key to decrypt users’ files." Well this suggest MEGA is lying thru their teeth when they say they don't hold any keys! If their lying then I'm sure ppl will run for the exits quickly. Time will tell but if BIG GOV stays outta way Mega will get better and better.
"If anyone can break Mega's SSL" come on, COME ON!
If anyone can do that, why do you not care about Governments' and banks' SSLs? I mean, most of them do not use more than 1024bit keys.
And 1024 being worse than 2048 sounds very well. Las I heard, the greatest RSA integer to be factored had 768 bits.
Please, there are problems with the security of MEGA but 1024 bits SSL is not one of them.
WTF? How would the "break of the SSL encryption" give the attacker the actual encryption keys? The encryption keys seem to be protected with the user password entered during registration. Moreover the original article clearly states that the checks are done using 2048-bit encryption.
Hi all,
Some links on potential for breaking 1024-bit encryption and SSL for your delectation:
http://techie-buzz.com/tech-news/1024-bit-rsa-cracked.html
http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
http://arstechnica.com/security/2012/09/many-ways-to-break-ssl-with-crime-attacks-experts-warn/
Plus, if you can get hold of the right certificates from leaky certificate authorities then there's no need to break SSL at all. You can just snoop on the traffic and pick up keys that way. Recent example of CA cock-up here: http://www.techweekeurope.co.uk/news/turkish-government-digital-certificate-google-103125
SSL system as it is is weak, so it's a worry that if you can watch over a users' browser activity, you can get hold of the keys, as that's where all the encryption is happening on Mega.
Message is that there are better ways to manage the encryption here.
Thanks
Tom Brewster
Deputy Editor
http://techie-buzz.com/tech-news/1024-bit-rsa-cracked.html
"They varied the voltage levels at the sender end to make faulty encryptions."
And this is a crack? Whoever can actually have this kind of control on your computer can just as well install a keylogger on your pc... at that point any encryption is useless.
The reason for client-side encryption is so that the data will be secure "at rest" in the cloud storage. The SSL is not pertinent to this since the HTTPS protects the data only during transport.
Of course if the server can be commandeered, the provider coerced, or the SSL monkeyed with, then the security is broken easily, because the client can be instructed to hand over the pertinent secrets. Using signed executable on the client side would mitigate that, meaning that doing everything in Java Script is a sacrifice.
But besides that, another main problem is that, although the client-side encryption of the user's data may be done at AES 128 (which is good, but of course not as good as AES 256), the encryption key is not random. The encryption key is actually derived directly from the user's password. And the process by which the key is derived from the password is quite fast, so that if someone has a hash of the password, the password can be recovered (and the corresponding key re-synthesized) quite easily.
Mega has a copy of the password hash for your account, and they even send it to you via plain email as an element of the URL in the "confirm my account" link.
So the bottom line is that the data is not actually safe "at rest" because the data is stored on the server along with the password hash, which can quickly be reversed to the password, which can directly produce the decryption key. And to boot, the hashed password is also sent to you via email, so if somebody gets into your email account (and your Mega confirmation email is there), they can also get into your Mega account by cracking your password using a freely available tool.
So Mega may point to 2048-bit SSL on the web session as though it were keeping everything secure, and in fact it probably is keeping the communication reasonably secure. At least we generally trust it to do that. But the encrypted cloud storage problem is not just about data in motion. Customers expect their data to be encrypted as stored on disk. In this case, the data is encrypted, even encrypted using a reasonable cipher (AES 128), but the symmetric key is not a secret - it's more or less stored right on the server along with the encrypted data.
That's mostly true, but missing a point. Most secure cloud storage providers a) rely on SSL to keep data secure to the cloud, then b) encrypt the data in the cloud before writing it to disk.
Where Mega is deviating from this is by a) encrypting the data on the desktop - the SSL from the desktop to the cloud doesn't hurt but the data is already encrypted on the desktop, then b) writes the data to disk. So instead of the data encryption being done on the server side, it's done on the desktop.
Mega's approach actually has the potential to be superior in that, if done properly, the cloud provider actually has zero knowledge of the contents of the data, because the data is encrypted before they see it.
The problem here is that the encryption is done wrong. Mega isn't supposed to have the keys (they claim that only the user holds the key) but actually the system is designed weakly, so that Mega could figure out the key within probably a single CPU hour or less (probably much less since, without any salting, they would only need run the program once to crack all passwords, past and future).
But if you confront Mega with this, their answer somehow is to point back to the 2048-bit SSL on the HTTPS connection, as if throwing around buzzwords somehow made it secure. Yes there is SSL on that connection, but that's really just a distraction from the actual issue.
The issue isn't the security of the data in transit, it's the security of the data if somebody seizes the servers or produces a warrant for the data. They're claiming that they can't decipher the data on the disks, which is what makes the data safe.
But in actuality they could easily read the data if they wanted to. Or they could be compelled to turn over the various pertinent data to an entity and the receiving entity could easily crack it.
The point is that the crypto is not done correctly. The data is only protected by the login password, which they can figure out trivially given information that they already have on hand at all times, information which they even email to you when you signup for your account.
"deduplication of encrypted data requires that information to be decrypted, repackaged and then encrypted again" ... This is _so_ not true (along with much of the rest of the article it seems).
Most of your points seem to be rushed, I'm assuming, because they have no substance.