[messaging] Transparency for E2E encrypted messaging at a centralized service

[Tom Ritter]

On 25 March 2014 23:24, Joseph Bonneau <jbonneau at gmail.com> wrote:
>
> Here's an idea that arose between Daniel Kahn Gillmor and I (mistakes all my own). Imagine you're a centralized web service and you want to offer E2E encrypted messaging between your users. Hardening Twitter direct messages could be a target, but potentially others.
>
> The goals and requirements are limiting here and this is not going to be a perfect system:
> *most users can't install software and the browser is all they have (or maybe an app in the best case)
> *users aren't going to compare fingerprints. The user experience has to be push-button
> *the centralized service is a middleperson for all comms, no P2P or out-of-band
> *users must be able to use multiple devices seamlessly and not lose access even if they lose all key material


I think this is an excellent topic and trying to design systems that
work within these restrictions is laudable and worthwhile.


> So here's a proposal:
> *Users can generate a private-key in their browser or app on demand
> *Centralized service, after normal authentication (password, ideally 2-factor) issues certificates for these keys in browser using a private service-specific CA
> *Users can download certs from the central service for their contacts and use these for encrypted messaging.
> *The service runs a Certificate Transparency-style log for every certificate it issues and a similar transparency log for revocation (Revocation Transparency or Mark Ryan's Enhanced Certificate Transparency). Users query these structures to get proof that the certs they are using are genuine and not revoked.
> *Outside auditors scan the log for correctness and provide a web interface to check which certs were issued for your username and when.
>
> This system could be built with very few changes to the user experience and adds some security properties, namely E2E encryption and some visibility if bogus credentials are ever issued due to a subpoena or compromise.
>
> The main challenges are:
> *Synching keys between devices. One option is password-protected private keys you download from the service and decrypt in-browser. This has some security downsides and is a pain. Another option is a device pairing protocol similar to Firefox Synch, but this is also difficult. Finally, you can just have multiple keys/certs per device, but this requires broadcast encrypting messages. I'm not sure what's best here.

There is also the challenge of gaining access to the messages after
the user has lost all key material/changed devices. I think this will
necessitate protected keys being escrowed by the provider, and the key
locked with... a password?


A design I keep circling back to, despite not liking it all that much,
is a 98% Trust, 2% Verify model. It needs a new name, but the idea is
open specifications, and open ability to write outside clients that
interop that you trust more. The outside client may be browser
extensions silently verifying the code, extensions providing the whole
experience, mobile apps, native apps, whatever.  The 2% run these
outside clients and don't 'trust' the service to do the encryption,
the 98% use provider-bootstrapped code that can be tampered with.
Delicately designed, on an individual request, the service shouldn't
know who is the 2% vs the 98% until it's too late to undetectably
tamper. On repeated observations, the service may know, but I think
this can be mitigated a little bit.

In an online-encrypted document sharing model, for the 98%, this would
look like a document being OpenPGP-encrypted in javascript with a
symmetric key you choose, and stored online by the service. The
recipient visits the fileshare, using javascript OpenPGP-decrypts the
document using the password they received out-of-band, and downloads
it. For the 2%, they PGP-encrypt the document using gpg, and upload
it, communicate the secret out of band, and the recipient decrypts it
using javascript. Or, they receive a document encrypted with
javascript and download it and PGP-decrypt it using gpg.  If you build
the service correctly, the service won't know ahead of time if the
document is going to be decrypted in javascript or gpg, and thus can't
reliably attack the user without a chance of detection.

I think this model comes up again and again, like in Opportunistic
Encryption for TLS (or whatever it's being called these days).  If the
server sends a certificate and the client doesn't verify it, an
attacker can MITM it. But if the attacker knows that _some_ unknown
clients _do_ verify it, via Convergence or TOFU or the EFF Distributed
Observatory - attacking the user becomes more dangerous as they could
get caught.

And, in the filesharing scenario I posted above - I think it more
accurately models the notion of "once the data is out of your hands,
you don't control it".  Snapchat, Silent Circle's 'Self Destructing
Messages', Pond's self-erasing messages - none of that can be
enforced. You don't _really_ know how the recipient is going to secure
the data you sent them. They could be backing up PGP-received email in
plaintext to dropbox. Or they could be decrypting it using a
javascript library provided on-demand by Google. You just have to
trust and hope their OPSEC is compatible with yours. If it's not - you
may not want to communicate (or communicate the level of detail) with
them anyway.

> *Serving modified Javascript can violate security, and this might be the attack that government subpoenas would demand. Though this would be theoretically detectable, and might be legally riskier to demand.
> *Messages to users who've never generated a key. Does the service pre-emptively generate one on their behalf and hand it off to them? Or are they unreachable until they opt-in to the new system?

I would just say they're unreachable securely. The sender will be
notified "This user has not generated a private key, and the messages
are not secured." When the recipient receives a message that has a
flag encryptionDesired, they generate a key, reply, and the subsequent
reply is encrypted. For users who care about encryption this will lead
to a flow of "ping", "pong", "I need help buying an engagement ring";
and for users who don't, they'll ignore the notice/encryption anyway.

> *The number of users may be much larger than the number of web domains (100 M or more), with frequent updates, so running a transparency log is a huge task, potentially much bigger than CT.
> *Privacy. Is it okay to have a public structure with usernames, showing every time they've asked for a new key?

I don't think this as stated would be acceptable. Not because of
privacy reasons - but because of competitiveness reasons.  Facebook,
Twitter, Google - all these identity providers are publicly traded
companies that derive a significant amount of their stock value from
the number of people actively using their services and signing up.
Disclosing these numbers in real-time for anyone to analyze is
something I can easily see them saying "No." to for business reasons.

I'd love to see one of them contradict me, but I wanted to throw this
out there as a potential deal-breaker.  As a counter-argument, they do
release these numbers in broad estimates during annual (and
quarterly?) earning calls/reports - so maybe the granularity isn't
concerning to them.


-tom