On 25 March 2014 23:24, Joseph Bonneau <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
