mikegerwitz
/
thoughts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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.
master
Mike Gerwitz 2019-02-18 01:10:57 -05:00
parent 92afc7f1c0
commit f16c0f0f0e
Signed by: mikegerwitz
GPG Key ID: 8C917B7F5DC51BA2
2 changed files with 977 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

973
post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md 100644
View File

@ -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.

4
src/papers.rec
View File

@ -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