Mike Gerwitz

Free Software Hacker+Activist

aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMike Gerwitz <mtg@gnu.org>2019-02-18 01:10:57 -0500
committerMike Gerwitz <mtg@gnu.org>2019-02-18 01:10:57 -0500
commitf16c0f0f0e3dbb5d14f5b88d765886b23e3d55a7 (patch)
tree18a62add4d3056aacfd62aa18ff2a2cc6e3519b0
parent92afc7f1c02546725d3cd387f6418ab9c0efcca6 (diff)
downloadthoughts-f16c0f0f0e3dbb5d14f5b88d765886b23e3d55a7.tar.gz
thoughts-f16c0f0f0e3dbb5d14f5b88d765886b23e3d55a7.tar.bz2
thoughts-f16c0f0f0e3dbb5d14f5b88d765886b23e3d55a7.zip
post: GHCQ's Exceptional Access
Wow. I had wanted to spend less than an hour on a response, and instead I wound up writing my largest article since the NSA revelations and GHS. Hopefully others find this useful. I've been sitting on this for weeks because I didn't have the time to finish final proofreading and changes. I need to release this before I sit on it for another couple; I have to start working on my LP2019 talk soon. * post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md: New post. * src/papers.rec: Add post to top.
-rw-r--r--post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md973
-rw-r--r--src/papers.rec4
2 files changed, 977 insertions, 0 deletions
diff --git a/post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md b/post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md
new file mode 100644
index 0000000..ebdd49b
--- /dev/null
+++ b/post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md
@@ -0,0 +1,973 @@
+# 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"][proposal].
+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.
+
+[proposal]: https://www.lawfareblog.com/principles-more-informed-exceptional-access-debate
+
+<!-- more -->
+
+This proposal is just the latest episode in the [crypto
+ wars][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:
+
+[crypto-wars]: https://en.wikipedia.org/wiki/Crypto_wars
+
+> 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][key-escrow-eff];
+ in fact,
+ it categorically denounces such schemes:
+
+[key-escrow-eff]: https://www.eff.org/deeplinks/2015/04/clipper-chips-birthday-looking-back-22-years-key-escrow-failures
+
+> 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][green-ghost] in his response to
+ the GHCQ proposal.]
+
+[green-ghost]: https://blog.cryptographyengineering.com/2018/12/17/on-ghost-users-and-messaging-backdoors/
+
+
+## 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]
+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.
+
+[^centralized]: See section [The Problem With Centralized
+ Services](#centralized-services).
+
+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.[^threat-model]
+Fortunately for them,
+ FooRelay makes use of _end-to-end encryption_.[^primitive-e2e]
+
+[^threat-model]: The process of determining potential threats and
+ adversaries is called [threat modeling][].
+ Since this article is about a proposal from a government spy agency,
+ it's also worth noting that global passive adversaries like the GHCQ and
+ NSA have the ability to monitor and store global traffic with the hopes
+ of later decrypting it.
+ [I have written about pre-Snowden revelations][national-uproar],
+ and [the EFF has compiled a bunch of information on NSA spying][eff-nsa].
+
+[threat modeling]: https://en.wikipedia.org/wiki/Threat_model
+[national-uproar]: /2013/06/national-uproar-a-comprehensive-overview-of-the-nsa-leaks-and-revelations
+[eff-nsa]: http://eff.org/nsa-spying
+
+[^primitive-e2e]: Here I will describe a fairly elementary public-key
+ end-to-end encrypted protocol that omits many important features
+ (most notably, forward secrecy).
+ For detailed information on a modern and well-regarded key exchange
+ protocol,
+ see [X3DH][] (Extended Triple Diffie-Hellman),
+ which is employed by Signal.
+ Following a key agreement,
+ the [Double Ratchet][] algorithm is widely employed for forward
+ secrecy even in the event of a compromised session key.
+
+[X3DH]: https://signal.org/docs/specifications/x3dh/
+[Double Ratchet]: https://www.signal.org/docs/specifications/doubleratchet/
+
+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.[^pke]
+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.
+
+[^pke]: This is called [_public-key cryptography_][public-key-crypto]
+ (or _asymmetric encryption_).
+
+[public-key-crypto]: https://en.wikipedia.org/wiki/Public-key_cryptography
+
+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_][key-distribution].]
+**This is the first opportunity to spy**,
+ if FooRelay is poorly designed.
+
+[key-distribution]: https://en.wikipedia.org/wiki/Key_distribution
+
+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.[^whatsapp-group-chat]
+
+[^whatsapp-group-chat]: As it turns out,
+ getting invitations right can be difficult too.
+ [WhatsApp had a vulnerability that allowed for users to insert themselves
+ into group conversations][whatsapp-vuln] because it didn't implement a
+ similar protocol.
+ A better defense would be for Bob to publish the invitation from Alice
+ when he joins the room,
+ allowing anyone else in the room (like Carol) to verify that he was
+ invited by someone authorized to do.
+ Only after verifying the invitation's signature would Carol decide to
+ encrypt messages to him.
+
+[whatsapp-vuln]: https://techcrunch.com/2018/01/10/security-researchers-flag-invite-bug-in-whatsapp-group-chats/
+
+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.[^sending]
+
+[^sending]: This is omitting many very important details that are necessary
+ for a proper implementation.
+ While this portrayal isn't necessarily dishonest at a high level,
+ there is a lot more that goes into sending a message.
+ See information on the [Double Ratchet][] algorithm for information on
+ one robust way to handle this exchange.
+
+**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)][mitm] attack.
+But notice how **the conversation is still fully end-to-end encrypted**,
+ between each of Alice, Bob, Carol, and Mallory.
+
+[mitm]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
+
+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"][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).
+
+[fingerprint]: https://en.wikipedia.org/wiki/Key_fingerprint
+
+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.[^wot]
+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"][safety-number] concept that Signal employs.
+
+[^wot]: One distributed model of assoicating a key with an owner is PGP's
+ [Web of Trust][wot],
+ which has been in use since the 1990s.
+ While it does enjoy use in certain communities,
+ it has failed to take off with average users due to the [complexities of
+ implementing the model properly][debian-keysign].
+ PGP's author also came up with short authentication string (SAS)
+ authentication protocol for VoIP systems called [ZRTP][],
+ but it relies on users being able to identify the authenticity of
+ one-anothers' voices,
+ a luxury that may be undermined in the near future by speech
+ synthesis systems [trained to reproduce real voices][ss-deep].
+
+[safety-number]: https://signal.org/blog/safety-number-updates/
+[wot]: https://en.wikipedia.org/wiki/Web_of_trust
+[debian-keysign]: https://wiki.debian.org/Keysigning/
+[zrtp]: https://en.wikipedia.org/wiki/ZRTP
+[ss-deep]: https://en.wikipedia.org/wiki/Speech_synthesis#Deep_learning
+
+FooRelay could also implement a [trust-on-first-use (TOFU)][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.[^ssh-tofu]
+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!"
+
+[tofu]: https://en.wikipedia.org/wiki/Trust_on_first_use
+
+[^ssh-tofu]: SSH users, for example, may be familiar with the almost-violent
+ warning when the server fingerprint changes.
+ Server fingerprints are stored in `~/.ssh/known_hosts` the first time they
+ are contacted,
+ and those fingerprints are used for verification on all subsequent
+ connection attempts.
+
+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.
+
+[alligator clips]: https://en.wikipedia.org/wiki/Crocodile_clip
+
+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][eff-ghost].
+
+[eff-ghost]: https://www.eff.org/deeplinks/2019/01/give-ghost-backdoor-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][detect-ghosts],
+ which would tip Alice, Bob, and Carol off that Mallory is watching them.
+
+[detect-ghosts]: https://www.lawfareblog.com/detecting-ghosts-reverse-engineering-who-ya-gonna-call
+
+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 {#betrayed}
+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][detect-ghosts] are discussed in terms of binary
+ profiling and side-channels.
+[The GHCQ's proposal itself][proposal] 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_][free-sw].
+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,[^proprietary-malware]
+ 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.
+
+[free-sw]: https://www.gnu.org/philosophy/free-sw.en.html
+
+[^proprietary-malware]: Unfortunately,
+ [proprietary (non-free) software is often malware][proprietary-malware],
+ hiding things that work in the interests of its developers but
+ _against_ the interests of its users.
+
+[proprietary-malware]: https://www.gnu.org/philosophy/proprietary.html
+
+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_][software-fork] it,
+ making their own version and ditching FooRelay entirely.
+Forking is a commonly exercised and essential right in the free
+ software community.
+
+[software-fork]: https://en.wikipedia.org/wiki/Software_fork
+
+The popular program Signal is free software.[^moxie-signal]
+The [OMEMO specification][omemo]---which
+ implements many of the encryption standards that were developed by
+ Signal---is
+ also [implemented by multiple free software projects][omemo-yet],
+ some of which include [Pidgin][] (GNU/Linux, Windows, Mac OSX),
+ [Conversations][] (Android),
+ [ChatSecure][] (iOS),
+ and [Gajim][] (GNU/Linux, Windows).
+
+[omemo]: https://conversations.im/omemo/
+[omemo-yet]: https://omemo.top/
+[pidgin]: https://pidgin.im/
+[conversations]: https://conversations.im/
+[chatsecure]: https://chatsecure.org/
+[gajim]: https://gajim.org/
+
+[^moxie-signal]: Unfortunately,
+ its author has caused some friction in the free software community by
+ [strongly discouraging forks and saying they are unwelcome to connect to
+ Signal's servers][moxie-fdroid].
+ This also relates to the issue of centralization,
+ which is the topic of the next section;
+ Moxie [explains in a blog post why he disagrees with a federated
+ Signal][moxie-federation].
+
+[moxie-fdroid]: https://github.com/LibreSignal/LibreSignal/issues/37
+[moxie-federation]: https://signal.org/blog/the-ecosystem-is-moving/
+
+
+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][facetime-vuln] 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.[^bugs-shallow]
+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][bad-apple],
+ 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.[^embargo]
+
+[facetime-vuln]: https://9to5mac.com/2019/01/28/facetime-bug-hear-audio/
+[bad-apple]: https://www.wsj.com/articles/teenager-and-his-mom-tried-to-warn-apple-of-facetime-bug-11548783393
+
+[^bugs-shallow]: This is often cited as [Linus's Law][linus-law],
+ which states that "given enough eyeballs, all bugs are shallow".
+ While this may be true,
+ that is certainly not always the case.
+ It is a common argument in support of open source,
+ [which covers the same class of software][floss-class] as free software.
+ However,
+ it's important not to fixate too much on this argument---it
+ [misses the point of free software][oss-misses-point],
+ and is a shallow promise,
+ since open source software is not always superior in technical
+ quality to proprietary software.
+
+[linus-law]: https://en.wikipedia.org/wiki/Linus's_Law
+[floss-class]: https://www.gnu.org/philosophy/free-open-overlap.html
+[oss-misses-point]: https://www.gnu.org/philosophy/open-source-misses-the-point.html
+
+[^embargo]: Sometimes an exception is made for severe security
+ vulnerabilities.
+ For example,
+ the [`linux-distros` mailing list][linux-distros] is used to coordinate
+ security releases amongst GNU/Linux distributions,
+ imposing an embargo period.
+ This practice ensures that exploits are not made publicly available to
+ malicious actors before users are protected.
+
+[linux-distros]: https://oss-security.openwall.org/wiki/mailing-lists/distros
+
+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 {#reproducibility}
+
+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.[^bootstrap]
+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?
+
+[^bootstrap]: And then you have the issue of ensuring that you have the
+ corresponding source to the rest of your system so that it does not
+ [alter the behavior of the produced binary][trusting-trust].
+ System-wide reproducibility is the topic of [_bootstrappable
+ builds_][bootstrappable-builds].
+
+[trusting-trust]: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
+[bootstrappable-builds]: http://bootstrappable.org/http://bootstrappable.org/
+
+[_Reproducible builds_][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.[^unreproducible]
+
+[reproducible-builds]: http://reproducible-builds.org/
+
+[^unreproducible]: Additional effort often has to be put into building
+ reproducibly because a build may produce timestamps corresponding to the
+ time of the build,
+ information specific to the environment in which the program is being
+ built,
+ and various other sources of nondeterminism.
+
+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.[^verify-checksum]
+They could even accept FooRelay from complete strangers and _still_ be
+ confident that it was compiled from the published source code!
+
+[^verify-checksum]: This verification can be done trivially by verifiying
+ the _checksum_ of a program or distribution archive.
+ For example,
+ running `sha512sum foorelay` on a GNU/Linux system would output a _hash_
+ of the contents of the file `foorelay`.
+ Alice, Bob, and Carol could then compare this value if they are all
+ running the same operating system and CPU architecture.
+ Otherwise they can compare it published checksums,
+ or with others they trust.
+
+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][debian-reproducible],
+ which includes the aforementioned Pidgin and Gajim projects that
+ implement OMEMO.
+[Signal also offers a reproducible Android build][signal-reproducible].
+
+[debian-reproducible]: https://tests.reproducible-builds.org/debian/reproducible.html
+[signal-reproducible]: https://signal.org/blog/reproducible-android/
+
+
+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 {#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.[^decentralize-term]
+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.
+
+[^decentralize-term]: While the term "decentralized" has been around for
+ some time,
+ there's not really a solid agreed-upon definition for "federated".
+ [Some people use the terms interchangeably][uu-federated].
+ The term "federation" is frequently used when talking about social
+ networking.
+
+[uu-federated]: http://networkcultures.org/unlikeus/resources/articles/what-is-a-federated-network/
+
+[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.[^me-prosody]
+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.[^risk-popular]
+
+[^me-prosody]: I run my own [Prosody][] server,
+ for example,
+ which supports OMEMO.
+
+[^risk-popular]: Of course,
+ there's always the risk of a few small instances becoming very
+ popular,
+ which once again makes Mallory's job easier.
+
+[xmpp]: https://en.wikipedia.org/wiki/XMPP
+[prosody]: https://prosody.im/
+[activitypub]: https://www.w3.org/TR/activitypub/
+[mastodon]: https://joinmastodon.org/
+[nextcloud]: http://nextcloud.org/
+[peertube]: https://joinpeertube.org/
+[riot]: https://about.riot.im/
+[matrix]: https://matrix.org/docs/guides/faq
+
+[_Peer-to-peer (P2P)_][p2p] (or _distributed_) services forego any sort of
+ central server and users instead communicate directly with
+ one-another.[^dht]
+In this case,
+ Mallory has no server operator to go to;
+ Levy and Robinson's proposal is ineffective in this
+ environment.[^excuse-me]
+[Tox][] is an end-to-end encrypted P2P instant messaging program.
+[GNU Jami][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.
+
+[^excuse-me]: "Excuse me, kind sir/madam,
+ may I please have your cooperation in spying on your
+ conversations?"
+ Another benefit of distributed systems is that they help to
+ evade censorship,
+ since no single server can be shut down to prohibit speech.
+
+[^dht]: Though some P2P services offer discovery services.
+ For example,
+ [GNU Jami][jami] offers a distributed identity service using
+ [_distributed hash tables_][dht] (DHTs).
+ Bittorrent uses DHTs for its trackers.
+
+[p2p]: https://en.wikipedia.org/wiki/Peer-to-peer
+[tox]: https://tox.chat/
+[jami]: https://jami.net/
+[ipfs]: https://ipfs.io/
+[dht]: https://en.wikipedia.org/wiki/Distributed_hash_table
+
+_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.[^metadata-leak]
+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.
+
+[^metadata-leak]: Though it is important to understand what sort of data are
+ leaked (including metadata) in decentralized and distributed systems.
+ When you send a message in a decentralized system,
+ that post is being broadcast to many individual servers,
+ increasing the surface area for Mallory to inspect those data.
+ If there are a couple popular servers that host the majority of users,
+ Mallory can also just target those servers.
+ For example,
+ even if you self-host your email,
+ if any of your recipients use GMail,
+ then Google still has a copy of your message.
+
+Self-hosting has another benefit: it helps to [put users in control of their
+ own computing][saass].[^online-freedom]
+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][whatsapp-vuln],
+ 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.
+
+[^online-freedom]: I go into more information on the problems with modern
+ software on the web in [my LibrePlanet 2016 talk "Restore Online
+ Freedom!"][rof].
+
+[saass]: http://www.gnu.org/philosophy/who-does-that-server-really-serve.html
+[rof]: https://mikegerwitz.com/talks#online-freedom
+
+
+## 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][landau],
+ [Matthew Green][green-ghost],
+ [Bruce Schneier][schneier],
+ [Nate Cardozo and Seth Schoen of the EFF][detect-ghosts],
+ and [another by Nate Cardozo][eff-ghost].
+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](#betrayed),
+ [reproducibility](#reproducibility), and
+ [decentralization](#centralized-services).
+These are essential topics that I feel must be encouraged if we are to
+ ensure the [safety and security][sapsf] of people everywhere.[^disagree]
+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.
+
+[landau]: https://www.lawfareblog.com/exceptional-access-devil-details-0
+[schneier]: https://www.schneier.com/essays/archives/2019/01/evaluating_the_gchq_.html
+[sapsf]: /talks/#sapsf
+
+[^disagree]: But I also know that there are many people that disagree with
+ me on each of these points!
+ If that weren't the case,
+ I wouldn't need to be an activist.
diff --git a/src/papers.rec b/src/papers.rec
index 137a620..b40c277 100644
--- a/src/papers.rec
+++ b/src/papers.rec
@@ -1,3 +1,7 @@
+id: ghcq-exceptional-access
+type: post
+ref: 2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible
+
id: git-horror-story
type: post
ref: 2012-05-22-a-git-horror-story-repository-integrity-with-signed-commits