read

Let me say this right off of the bat: I'm not weighing in on the business model or the controversies of MEGA when I say that its model is genius. What I am specifically talking about is only its security model. MEGA uses an often misunderstood scheme of encryption as part of its threat model and mitigation that is nothing short of brilliant. This isn't, of course, a new scheme - plenty of others have done similar in the past (Spideroak, for example, among many others.) Still, it's brilliant.

Before we delve into the specifics of MEGA, let's work with a hypothetical example that can better show some of the balancing act that is involved, not just between security and usability, but also with whose security we are discussing.

Imagine a particular kind of chat service that enables pseudonymous conversations between two, randomly paired users of the service. These users can have a conversation of whatever length they desire, and at the option of either of the users, be rematched to a new random pairing. Let's set out some of the attributes that we would like this service to have.

  1. Only the sender and recipient of a message can access and read that message.
  2. Users cannot send messages that have no useful purpose - aka, spam.

Even with that very limited set of constraints, we run face-first into an immediate conflict. The usability demand ("no spam") requires that the server operator can, in some way, monitor the content of the messages, flying in the face of the demand for privacy ("no spying"). How can we resolve this? Thinking a bit more about what the purposes of these restrictions are, let's break these constraints out a bit more to see if we can come up with an area that we are OK with compromising on.

When designing the threat model, there are two different sets of reasons that we might want to ensure that the server operator is unable to read the messages of its users. On the one hand, there is the simple case - we want users to have privacy and for their messages to be secure. Simple. But there is a second, hidden reason that we might want to have this property: we, as the server operator, don't want to be put into a position where we /have/ to monitor our users messages.

Let's assume for a second that we simply off-load the burden for securing the messages onto our users, in the same way that email providers do. The users can use PGP or similar for whatever messages they want to remain private, and for messages that they don't care, they can just use plaintext. (Ignoring, for a moment, the problems of actually educating the users on how to use PGP or similar.) Let's say that a user ends up engaging in some kind of criminal activity using this service, somehow - harassment, maybe, or something else undesirable. It is quite reasonable to assume that the investigating officers will come knocking on the server operator's door with a subpoena, wanting whatever records that the server operator has. Or, more dramatic, they may want to wiretap those users messages into the future. Another possibility, a copyright owner may want us to block certain copyrighted content from being shared on the network.

This is, for many reasons, not a great position to be in as the server operator! We are having to do a bunch of extra work, both political and technological, including some that might conflict with personal beliefs. Let's make this explicit in our goals:

  1. Users can only access messages for which they are the sender or recipient.
  2. The server operator cannot monitor the content of any user messages.
  3. Users cannot send messages that have no useful purpose - aka, spam.

Now, it is clear that the real conflict in goals here is between the latter two, not the former. How can we resolve this conflict? We will need to weaken one of our security goals in order to resolve this problem. How can we do so, without trapping us in the earlier bind? Let's think about the goals of our attacker - in this case, the spammer.

  • A spammer wants to send their messages to as many users as possible.
  • A spammer wants either to:
    • gain some monetary advantage from the messages, even if indirectly ("commercial spam")
    • disrupt the service, either through technological means or by scaring off legitimate users ("lulz spam")

Clearly, regardless of the reason, spammers are incentivized to not have extended conversations with the people they are communicating with. They wield a shotgun, not a sniper rifle. This gives us multiple advantages - not only can we apply technological mechanisms such as rate limiting to interfere with their aims, we have a potential option for weakening one of our security goals without causing a major loss. Since there is not a substantial amount of "metadata" to be leaked in a service that's randomly pairing users - since they can't choose who they are communicating with - our core goals around privacy of the users is aimed at the content of the messages. For spammers, who are likely to want to spew their message and re-pair as fast as possible, it means there is not a whole lot of value to communicating for an extended period of time (thus causing messages to contain more and more private information). How about structuring our goals to recognize that?

  1. Users can only access messages for which they are the sender or recipient.
  2. The server operator cannot monitor the content of any user messages, unless one of the participants chooses to enable them to.
  3. Users cannot send messages that have no useful purpose - aka spam - without detection.

If messages can be revealed by one of the participating users - with, say, a "Report" button - the server operator is able to gain information about people misusing the service and take action against them, without having to risk a broad ability to access the content of messages.

With this weakened set of goals, there is a pretty clear path towards how one can construct a system to achieve them. Let's turn our attention back to MEGA. MEGA is the successor to Megaupload, which was taken down after a Department of Justice investigation into criminal copyright infringement in 2012. One of the prime elements of the controversy around Megaupload was that they had tools in place to seek out certain kinds of content across the network and remove it, regardless of the links to it (as they did with child pornography), and yet they refused to use those techniques to remove copyrighted files. Their ability to access the content that was uploaded to their system caused them to be put into a position where they were being forced to use it - or suffer the consequences.

MEGA, its successor, advertises that it uses client-side encryption to ensure that they cannot read the content of the files which are uploaded to them. This, however, is not to ensure user privacy. In the (vastly) most common usecase, the encryption key is simply provided to those who would access the files as part of the URL and publicly posted. It is obvious that linking to a file, unencrypted, at the path example.com/fileA is no more or less secure than linking to a file, encrypted, at the path example.com/fileA#encryption-key - for the users. It is, however, a tremendous difference to the server operator's ability to make statements about whether or not they are able to access the content stored on their system.

This is a "hack" in the traditional sense, twisting the normal purpose of encrypting prior to upload -- to make the information accessible only to authorized people -- into a different security model altogether, one that blinds only a single person -- the operator -- to the content. For better or worse, MEGA is genius.

Blog Logo

Harlan Lieberman-Berg


Published

The postings on this site are my own and do not express the positions, strategies or opinions of Akamai.
The source for this blog can be found at gitlab.com.
Image

Setec Astronomy

Random rants on politics and discussions on tech.

Back to Overview