Kim Dotcom has offered a 10,000 euro bounty on the first person to crack his new Mega file storage and sharing service. The bounty is likely to be collected, as the encryption keys are stored along with the users’ files on the system. This means that anyone gaining access to a user’s ID and password will gain access to their encryption key as well, dramatically increasing the compromise likelihood.
This bizarre, and quite frankly, less secure approach to encryption seems to be in place solely to protect Mr Dotcom from prosecution, on the basis that he and his staff cannot have any knowledge of the data that is being stored on their cloud computing servers.
While this is perhaps understandable given the fact that Mr Dotcom was arrested in New Zealand 12 months ago in connection with copyright infringement surrounding his original MegaUpload file storage and sharing service, the lack of security surrounding the encryption keys leaves the system vulnerable. The encryption keys are the figurative keys to the kingdom, and the attackers can wreak havoc with unfettered access to data and systems with the keys in hand.
Mr Dotcom’s offer of a bounty to successful crackers of his new system is good publicity, but a more practical governance approach would have been to stage a private launch of Mega, inviting cryptographers to use – and abuse – the system, and then offer up their recommendations in return for a lifetime paid-for subscription.
The problem with Mega is that the user’s password has the double burden of supporting account authentication – without disclosing that password to Mega’s servers – as well as outer level data encryption. The outer level key is derived from the user’s password using a key derivation approach, generating a master key for symmetric AES encryption – all data from that point on is encrypted to the master key or its subsets.
When the user logs into the Mega service, their email address and user hash data is used to authenticate them, with Mega’s servers returning the user’s master key, as well as a session identifier. This approach is a weak security system as obtaining the master key is based on a simple token system that can be replayed, rather than the more usual secure challenge/response technology seen on commercial services.
This weakness could be exploited through the use of a timing vulnerability when the server compares the user’s hash data, allowing a hacker to progressively learn how to access the system using multiple attempts. I fully expect this methodology to be exploited by would-be crackers wanting to collect the 10,000 euro bounty.
In the end, it’s critical that the encryption keys that secure the data and authenticate systems and applications are properly controlled and managed. The admins who create and issue the keys should not be the same as the admins and app owners who use the same keys to encrypt, decrypt and access the data.