by Jürgen Schmidt
No specific details of how this works are available at present. The documentation provided by Mega is in this respect also limited in its usefulness. It appears that each file is encrypted using a separate AES key. These keys are, according to Mega, not transferred to the server, instead encryption and decryption is performed locally by an app running in the browser.
The idea is not new – Zerobin, for example, utilises a similar concept to ensure that it can't be held liable for user content on its servers. Mega has also borrowed Zerobin's trick of embedding the keys in HTML anchor elements. Mega URLs take the form:
All of the URL after the # is an internal link to an anchor within the HTML page. Internal anchors of this type are always resolved locally in the browser and are not sent to the server. In this case, 12wlkJza is clearly an index for the file and PRA 8y246I55pJUl-... is the associated key.
It is however alarming, that the one of the first analyses of the service revealed beginner's mistakes in the usage of crypto functions. Mega sideloads code from a content distribution network (CDN) and checks its integrity, but the function it uses for this is by no means fit for this purpose. Instead of a hash function such as SHA256, Mega uses CBC-MAC to perform this check with a constant hard-coded key (111111, 222222, 333333, 444444 ...). But even the Wikipedia page clearly states that CBC-MACs can be easily spoofed if used with a known key.
This leads to a situation where anybody controlling such a CDN server, or anybody who can coerce such a person with a subpoena or the like, can easily manipulate the code stored there. Beginner mistakes like these do not bode well for the remainder of the crypto infrastructure of the service.
The encryption model is primarily intended to protect Mega from legal problems. Whether prosecutors will be impressed by a storage provider using technical measures to achieve ignorance of the content on its servers remains to be seen. Whether the service might contain security vulnerabilities which undermine the concept will only become known following intense scrutiny.
As for Mega's willingness to cooperate with police investigations aimed at its users, one can only speculate. The idea that the company is unable to help investigating authorities in such cases is not correct. Mega could, for example, at any time modify the script loaded by the browser to send the key used for encryption to a web server. This is a basic problem in all situations where the key-handling program comes from an untrusted source.
For the purposes of de-duplicating data, a server keeps lists of hashes from currently stored data blocks. If a user tries to store a file which has previously been uploaded by another user, they are provided with a link to the existing storage location. This saves the user from having to upload the file and saves the operator from having to maintain storage space for multiple copies of the same file. The problems caused by the fact that the data is encrypted can be resolved by means of clever key management.
The service is currently still at the beta stage. It is thus no great surprise if users discover cross-site scripting (XSS) vulnerabilities, as indeed many already have. It may be possible to exploit XSS vulnerabilities to inject code into the browser to compromise keys. The fact that the infrastructure has not been able to cope with the initial demand, that performance has been mediocre and that there have been regular outages is also unextraordinary.
From a technical point of view, Mega has taken some interesting approaches. Even if it's not yet possible to give a definitive verdict on their implementation in practice, one thing is clear – the idea that a storage service can be trusted just because you or your data is protected by means of encryption is completely misguided. And whether Mega founder Kim Dotcom has earned the requisite level of trust is another question entirely.