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
parent
92afc7f1c0
commit
f16c0f0f0e
|
@ -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.
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue