GHCQ's "Exceptional Access", End-To-End Encryption, Decentralization, and Reproducible Builds

Late last November, Ian Levy and Crispin Robinson of the GHCQ (the British intelligence agency) published a proposal for intercepting end-to-end encrypted communications, entitled "Principles for a More Informed Exceptional Access Debate". Since then, there have been a series of notable rebuttals to this proposal arguing why this system would fail in practice and why it should be rejected. Completely absent from these responses, however, is any mention of existing practices that would prohibit this attack outright---the combination of free/libre software, reproducible builds, and decentralized or distributed services.

This proposal is just the latest episode in the crypto wars: Users need secure communications to protect their privacy and defend against attackers, but law enforcement and governments argue that this leaves them in the dark. But this one's a bit different. The proposal states:

The U.K. government strongly supports commodity encryption. The Director of GCHQ has publicly stated that we have no intention of undermining the security of the commodity services that billions of people depend upon and, in August, the U.K. signed up to the Five Country statement on access to evidence and encryption, committing us to support strong encryption while seeking access to data. [...] We believe these U.K. principles will enable solutions that provide for responsible law enforcement access with service provider assistance without undermining user privacy or security.

The suggestions in the article are a pleasant deviation from past proposals, such as key escrow schemes; in fact, it categorically denounces such schemes:

There is no single solution to enable all lawful access, but we definitely don’t want governments to have access to a global key that can unlock any user’s data. Government controlled global key escrow systems would be a catastrophically dumb solution in these cases.

So how do the authors propose intercepting communications? They suggest inserting a third party---a "ghost", as others have been calling it---into the conversation.

To understand the implications of adding a third party to an end-to-end (E2E) encrypted protocol, you have to understand how end-to-end encryption usually works in practice.^[ For another perspective, see Matthew Green's overview in his response to the GHCQ proposal.]

Undermining End-to-End Encrypted Communication Systems

Let's say that three users named Alice, Bob, and Carol wish to communicate with one-another privately. There are many ways to accomplish this, but for the sake of this discussion, we need to choose a protocol that attempts to fit into the model that Levy and Robinson had in mind. Alice and the others will make use of a centralized messaging service that relays messages on behalf of users.¹ Centralized services are commonplace and include popular services like Signal, WhatsApp, Facebook Messenger, iMessage, and many others. They all work in slightly different ways, so to simplify this analysis, I'm going to talk about an imaginary messaging service called FooRelay.

FooRelay offers a directory service that allows participants to find one-another by name or pseudonym. The directory will let Alice know if Bob and Carol are online. FooRelay also offers private chat rooms supporting two or more participants.

Alice, Bob, and Carol don't want anyone else to know what they are saying---that includes FooRelay's servers, their Internet Service Providers (ISPs), their employers, their governments, or whomever else may be monitoring the network that any of them are communicating over.² Fortunately for them, FooRelay makes use of end-to-end encryption.³

Alice, Bob, and Carol each hold secret encryption keys known only to them---their private keys, which are generated for them automatically by the FooRelay client software running on their systems. These keys can be used to decrypt messages sent to them, and can be used to sign messages to assert their authenticity. But these private keys must never be divulged to others, including FooRelay's servers. Instead, each private key has a public key paired with it. The public key can be used to encrypt messages that can only be decrypted using the associated private key.⁴ Alice, Bob, and Carol each publish their public keys into FooRelay's directory so that others may discover and use them. When Alice wants to start a chat with Bob and Carol, she can ask FooRelay to provide their public keys from the directory.

But making the public keys available in a directory is only part of the problem---how do Alice, Bob, and Carol know that the keys published to the directory are actually associated with the real Alice, Bob, and Carol?^[ This topic is known as key distribution.] This is the first opportunity to spy, if FooRelay is poorly designed.

As stated by the proposal:

It’s relatively easy for a service provider to silently add a law enforcement participant to a group chat or call. The service provider usually controls the identity system and so really decides who’s who and which devices are involved - they’re usually involved in introducing the parties to a chat or call. You end up with everything still being end-to-end encrypted, but there’s an extra ‘end’ on this particular communication.

Man-in-the-Middle

Let's start by assuming a pretty grim scenario. This is not quite the plan of attack that Levy and Robinson had in mind, but it's important to understand why it would not work in practice.

The FooRelay client software running on Alice's computer retrieves Bob's public key from the identity service and initiates a chat. FooRelay's server creates a new private chat room to accommodate the request and adds two initial participants---Alice and Bob. The FooRelay client then generates an invitation message containing the identifier of the new room, signs it using Alice's private key to prove that it was from Alice, and sends it off to FooRelay's servers. FooRelay's server verifies Alice's signature to make sure that she is authorized to invite someone to the room, and then sends the invitation off to Bob.⁵

Bob is also running the FooRelay client on his computer. It receives the invitation from Alice, looks up her public key from the identity service, and uses it to verify the signature on the invitation to make sure it originated from Alice. If the signature checks out, FooRelay asks Bob if he'd like to join the chat. Bob accepts.

Alice enters a message into the FooRelay client to send to the chat room. But remember, Alice does not want the FooRelay server to know what message is being sent. So the FooRelay client on Alice's computer encrypts the message using Bob's pubic key, signs it using Alice's private key to assert that it was from her, and sends it. The FooRelay server---and anyone else watching---see junk data. But Bob, upon receiving the message and verifying its signature, is able to decrypt and read it using his private key.⁶

Now let's explore how to intercept communications. Enter Mallory. Mallory works for the GHCQ. FooRelay has been provided with a wiretap order against Carol.

Alice wants to bring Carol into the conversation with her and Bob, so she requests Carol's key from the identity service. FooRelay's identity service, subject to the wiretap order, doesn't return Carol's public key; instead, it returns Mallory's, who is pretending to be Carol. Alice sends the invitation to Mallory (again, thinking he's Carol), and the fake Carol (Mallory) joins the room. Now when sending a message, Alice encrypts using both Bob and Mallory's public keys, so both of them can read it.

But when Alice and Carol meet up tomorrow for lunch, it will be pretty clear that Carol was not part of the conversation. So Mallory is clever---he has FooRelay provide him with Carol's real public key. When Alice sends Mallory an invitation to the room, Mallory instructs FooRelay to create a covert fake chat room with the same identifier. Mallory then sends an invitation to Carol to that new chat room, pretending to be Alice. But Mallory doesn't have access to Alice's private key, and so cannot sign it as her; he instead signs it using his own private key.

FooRelay on Carol's computer receives the invitation, which claims to be from Alice (but is really from Mallory). When it attempts to retrieve the key from the identity service, rather than receiving Alice's key, the identity service sends back Mallory's. Now Mallory is impersonating both Alice and Carol. The signature checks out, and Carol joins the covert chat. FooRelay---still under the wiretap order---announces that Alice and Bob are both in the room, even though they aren't.

Now, when Mallory receives a message from Alice that is intended for Carol, he encrypts it using Carol's public key, signs it using his own, and sends it off to Carol. Since Carol's FooRelay client thinks that Mallory's key is Alice's (remember the invitation?), the signature checks out and she happily decrypts the message and reads it. If Bob sends a message, we repeat the same public key lookup procedure---FooRelay's identity service lies and provides Mallory's key instead, and Mallory proxies the message all the same.^[ Of course, it may be suspicious if Alice and Bob both have the same key, so maybe Mallory has multiple keys. Or maybe the FooRelay software just doesn't care.]

This is a man-in-the-middle (MITM) attack. But notice how the conversation is still fully end-to-end encrypted, between each of Alice, Bob, Carol, and Mallory.

Why is this attack possible? Because FooRelay has not offered any insight into the identity process---there is no authentication procedure. Blind trust is placed in the directory, which in this case has been compromised.

Mutual Authentication

If the FooRelay client allowed Alice, Bob, and Carol to inspect each others' public keys by displaying a public key "fingerprint", then that would have immediately opened up the possibility for them to discover that something odd was going on. For example, if Alice and Carol had previously communicated before Mallory was involved, then maybe they would notice that the fingerprint changed. If they met after the fact, they would notice that the fingerprint Alice had for Carol was not the fingerprint that Carol had for herself. Maybe they would notice---perhaps by communicating in person---that the fingerprint that Alice associated with Carol and the fingerprint that Carol associated with Alice were in fact the same (that is, Mallory's).

To mitigate the first issue, Mallory would have to MITM communications from the moment that Carol first signed up for FooRelay, and permanently thereafter. The second could not be mitigated unless Mallory compromised Carol's device, or FooRelay cooperated with Mallory to plant a defective FooRelay client on Carol's device. To mitigate the third, maybe Mallory would use separate keys. But if Alice, Bob, or Carol ever compared public keys in person with someone else that was outside of their group of three, then they would notice that the fingerprints did not match. So FooRelay would have to always provide the wrong key to everyone trying to communicate with Carol, and for everyone Carol tried to communicate with, in perpetuity---an everlasting wiretap.

This issue of mutual authentication is another complex topic that is very difficult to solve in a manner that is convenient for users.⁷ For example, Alice, Bob, and Carol could all meet in person and verify that one-anothers' fingerprints look correct. Or they could post their fingerprints to something outside of FooRelay's control, like social media. This is the "safety number" concept that Signal employs.

FooRelay could also implement a trust-on-first-use (TOFU) policy---the client software would remember the last public key that it saw for a user, and if that key ever changed, then a prominent warning would be displayed.⁸ For example, if Alice communicates once with the real Carol, the TOFU policy in the FooRelay client would record that real public key. Then, when Mallory tries to MITM the conversation, Alice's FooRelay client would say: "Hold up; the key changed! Something is wrong!"

In any case, let's assume that FooRelay's cooperation in serving up the wrong public key is no longer sufficient because of these mitigations. What does Mallory do without the ability to MITM?

No respectable communication software should be vulnerable to this sort of attack. Knowing this, Levy and Robinson had a different type of attack in mind.

A Ghost in the Room

Back when most people used land lines for communication via telephone, wiretapping was pretty easy. Conversations were transmitted in an unencrypted, analog form; anyone could listen in on someone else's conversation if they had some elementary technical know-how and knew where to apply it. By severing or exposing the line at any point, an eavesdropper could attach alligator clips---or "crocodile clips", if you're east of the Atlantic---to route the analog signal to another phone or listening device.

Levy and Robinson try to apply this same concept as a metaphor for Internet communications, presumably in an effort to downplay its significance. But the concepts are very different. Continuing from the previous quote of Levy and Robinson's proposal:

This sort of solution seems to be no more intrusive than the virtual crocodile clips that our democratically elected representatives and judiciary authorise today in traditional voice intercept solutions and certainly doesn’t give any government power they shouldn’t have.

We’re not talking about weakening encryption or defeating the end-to-end nature of the service. In a solution like this, we’re normally talking about suppressing a notification on a target’s device, and only on the device of the target and possibly those they communicate with. That’s a very different proposition to discuss and you don’t even have to touch the encryption.

This statement is disingenuous. We can implement the quoted suggestion in two different ways: The first is precisely the situation that was just previously described---allow MITM and remain ignorant about it. The second way is to have the FooRelay server actually invite Mallory to the chat room, but have the FooRelay client hide him from other participants. He would be a ghost in the room; nobody would see him, but Alice, Bob, and Carol's FooRelay software would each surreptitiously encrypt to him using his public key, as a third recipient.

Sure, the actual ciphers used to encrypt the communications are not weakened. Sure, it is still end-to-end encrypted. But this is nothing like alligator clips on a phone line---instead, an anti-feature has been built into the software. As the EFF notes, this is just a backdoor by another name.

If software has to be modified to implement this backdoor, then it has to either be done for every user of FooRelay, or individual users have to be targeted to install a malicious version of the program. If either of these things are possible, then everyone is made less secure. What if a malicious actor figures out how to exploit either of those mechanisms for their own purposes? Or what if someone tricks FooRelay into thinking they're from the GHCQ?

And since this is a backdoor in the software running on the user's computer, it is very difficult to be covert. Nate Cardozo and Seth Schoen of the Electronic Frontier Foundation analyze various ways to detect ghosts, which would tip Alice, Bob, and Carol off that Mallory is watching them.

This is bad, and everyone knows it. The proposal is a non-starter. But this shouldn't be the end of the conversation---there is a much more fundamental issue is at play which has received no attention from the mainstream responses.

Betrayed By Software

All of these mainstream discussions make an implicit assumption: that users are not in control of the software running on their systems. The detection methods are discussed in terms of binary profiling and side-channels. The GHCQ's proposal itself fundamentally relies on the software being modified in ways that are a disservice to the user---adding a backdoor that surreptitiously exfiltrates messages to a third party (Mallory) without the consent of other participants (Alice, Bob, or Carol).

When a user has full control over their software---when they have the freedom to use, study, modify, and share it as they please---we call it free software. If FooRelay's client were free software, then Alice, Bob, and Carol would all have the right to inspect it to make sure no nasty backdoors were added,⁹ or ask someone else to inspect it for them. Or maybe they could depend on the fact that many other people are watching---essentially anyone in the world could at any moment look at FooRelay's client source code. This helps to keep FooRelay honest---if they did implement a feature that suppresses notifications as Levy and Robinson suggest, then they would have done so in plain sight of everyone, and they would immediately lose the trust of their users.

FooRelay could try make the change in a plausibly deniable way---to make the change look like a bug---but then anyone with sufficient skill in the community could immediately fix it and issue a patch. That patch could be immediately circulated and adopted by other users without the blessing of FooRelay itself. If FooRelay didn't implement that patch, then users would fork it, making their own version and ditching FooRelay entirely. Forking is a commonly exercised and essential right in the free software community.

The popular program Signal is free software.¹⁰ The OMEMO specification---which implements many of the encryption standards that were developed by Signal---is also implemented by multiple free software projects, some of which include Pidgin (GNU/Linux, Windows, Mac OSX), Conversations (Android), ChatSecure (iOS), and Gajim (GNU/Linux, Windows).

If a program does not respect users' freedoms, we call it non-free, or proprietary. Most of the popular chat programs today are non-free: Apple iMessage, Facebook Messenger, and WhatsApp are all examples of programs that keep secrets from their users. Those communities are unable to inspect the program, or modify it to remove anti-features; they are at the mercy of the companies that write the software.

For example, a recent bug in Apple's FaceTime left users vulnerable to surveillance by other FaceTime users. FaceTime likely has hundreds of thousands of users. If it were free software and only a tiny fraction of those users actually inspected the source code, it's possible that somebody would have noticed and maybe even fixed the bug before it was exploited.¹¹ Further, after it was discovered, users had no choice but to wait for Apple themselves to issue a fix, which didn't come until a week later. The person who did discover it tried to contact Apple with no success, and the world only found out about the issue when a video demoing the exploit went viral eight days after its initial discovery. This differs from free software communities, where bugs are typically posted to a public mailing list or bug tracker, where anybody in the community can both view and immediately act upon it.¹²

But free software alone isn't enough. How does Alice know that she actually has the source code to the program that she is running?

Reproducibility and Corresponding Source Code

The source code to FooRelay can't provide Alice with any security assurances unless she can be confident that it is actually the source code to the binary running on her machine. For example, let's say that FooRelay has agreed to cooperate with the GHCQ to implement ghosts by introducing a backdoor into the FooRelay client. But since FooRelay is a free software project, anyone can inspect it. Rather than tipping off the community by publishing the actual source code, they publish the source code for a version that does not have the backdoor. But when Alice downloads the compiled (binary) program from FooRelay, she receives a backdoored version.

To mitigate this, Alice wants to be sure that she has the corresponding source code.

One way for Alice to be confident is for her to compile the FooRelay client herself from the source code. But not everybody has the technical ability or desire to do this.¹³ Most users are instead going to download binaries from their operating system's software repositories, or from FooRelay's website, or maybe even from other convenient third parties. How can all users be confident that the FooRelay client they download actually corresponds to the source code that has been published and vetted by the community?

Reproducible builds are required to solve this problem. When FooRelay is built, it is done so in a manner that can be completely reproduced by others. Bit-for-bit reproducibility means that, if two people on different systems follow the same instructions for building a program in similar enough environments, every single bit of the resulting binary will match--- they will be exact copies of one-another.¹⁴

This has powerful consequences. Alice no longer has to build the program herself---she can trust that others have checked FooRelay's work. FooRelay wouldn't dare try to distribute a tainted binary now, since the community could trivially detect it. Further, Alice, Bob, and Carol could all verify that they have the exact same verison of the FooRelay client, and all be confident that it was compiled from the same source code that was published.¹⁵ They could even accept FooRelay from complete strangers and still be confident that it was compiled from the published source code!

Reproducible builds have made a lot of progress in recent years. As of February 2019, for example, over 93% of all packages on Debian GNU/Linux are reproducible on the amd64 architecture, which includes the aforementioned Pidgin and Gajim projects that implement OMEMO. Signal also offers a reproducible Android build.

So let's go back to Levy and Robinson's proposal. How do you implement a ghost in FooRelay where its client source code is publicly available and its builds are reproducible? You don't, unless you can hide the implementation in a plausibly-deniable way and write it off as a bug. But anyone that finds that "bug" will fix it and send FooRelay a patch, which FooRelay would have no choice but to accept unless it wishes to lose community trust (and provoke a fork).

Mallory could instead target specific users and compromise them individually, but this goes beyond the original proposal; if Mallory can cause Alice, Bob, or Carol to run whatever program he pleases, then he doesn't need to be a ghost---he can just intercept communications before they are encrypted. Therefore, reproducible builds---if done correctly---make Levy and Robinson's attack risky and impractical long-term.

But there is still one weak link---the fact that Alice, Bob, and Carol are communicating with FooRelay's servers at all means that Mallory still has the ability to target them by coercing FooRelay to cooperate with him.

The Problem With Centralized Services

The final issue I want to discuss is that of centralized services.

A centralized service is one where all users communicate through one central authority---all messages go through the same servers. The hypothetical FooRelay is centralized. Signal, iMessage, Facebook Messenger, WhatsApp, and many other popular chat services are centralized. And while this offers certain conveniences for users, it also makes certain types of surveillance trivial to perform, as they are bountiful targets for attackers, governments, and law enforcement.

But services don't have to be centralized. Decentralized services contain many separate servers to which users connect, and those servers can communicate with one-another. The term "federated" is also used, most often when describing social networks.¹⁶ Consider email. Let's say that Alice has an email address alice@foo.mail and Bob has an email address bob@quux.mail. Alice uses foo.mail as her provider, but Bob uses quux.mail. Despite this, Alice and Bob can still communicate with one-another. This works because the foo.mail and quux.mail mailservers send and receive mail to and from one-another.

XMPP---the protocol on which OMEMO is based---is a federated protocol. Users can choose to sign up with existing XMPP servers, or they can even run their own personal servers.¹⁷ Federation is also the subject of the ActivityPub social networking protocol, which is implemented by projects like Mastodon, NextCloud, and PeerTube. Riot is an implementation of the Matrix protocol for real-time, decentralized, end-to-end encrypted communication including chat, voice, video, file sharing, and more. All of these things make Mallory's job much more difficult--- instead of being able to go to a handful of popular services like FooRelay, Signal, WhatsApp, iMessage, Facebook Messenger, and others, Mallory has to go to potentially thousands of server operators and ask them to cooperate.¹⁸

Peer-to-peer (P2P) (or distributed) services forego any sort of central server and users instead communicate directly with one-another.¹⁹ In this case, Mallory has no server operator to go to; Levy and Robinson's proposal is ineffective in this environment.²⁰ Tox is an end-to-end encrypted P2P instant messaging program. GNU Jami is an end-to-end encrypted P2P system with text, audio, and video support. Another example of a different type of P2P software is Bittorrent, which is a very popular filesharing protocol. IPFS is a peer-to-peer Web.

Decentralization puts users in control. Users have a choice of who to entrust their data and communications with, or can choose to trust no one and self-host.²¹ Alice, Bob, and Carol may have different threat models---maybe Carol doesn't want to trust FooRelay. Maybe Alice, Bob, and Carol can't agree at all on a host. Nor should they have to.

Self-hosting has another benefit: it helps to put users in control of their own computing.²² Not only do they have control over their own data, but they also have full control over what the service does on their behalf. In the previous section, I mentioned how free software helps to keep FooRelay honest. What if FooRelay's server software were also free software? If Alice can self-host FooRelay's server software and doesn't like how FooRelay implements their group chat, for example, she is free to change it. If Mallory forces FooRelay to implement a feature on their server to allow him to be added to group chats, the community may find that as well and Alice can remove that anti-feature from her self-hosted version.

Please Continue Debating

This article ended up being significantly longer and more substantive than I had originally set out to write. I hope that it has provided useful information and perspective that was missing from many of the existing discussions, and I hope that I have provided enough resources for further research.

The prominent responses to which I referred (some of which were already referenced above) are analyses by Susan Landau, Matthew Green, Bruce Schneier, Nate Cardozo and Seth Schoen of the EFF, and another by Nate Cardozo. There are surely others, but these were the ones that motivated this article.

It is important to keep these encryption debates alive. The crypto wars are far from over. We must ensure that we provide users with the tools and information necessary to defend themselves and one-another---tools and practices that are immune from government interference unless they themselves become illegal. What a grim and dangerous world that would be.

I'm most concerned by the lack of debate from community leaders about the issues of software freedom, reproducibility, and decentralization. These are essential topics that I feel must be encouraged if we are to ensure the safety and security of people everywhere.²³ We need more people talking about them! If you found these arguments convincing, I would appreciate your help in spreading the word. If you didn't, please reach out to me and tell me why; I would very much like to hear and understand your perspective.