Blog

This article discusses some of the threats considered and the tradeoffs made around them.

Conversations do not provide forward secrecy. If a Secret becomes known to an attacker, all contents of that Conversation are visible to them.

Identities should be protected against tampering. This can be done by using design documents to render the public key document read-only after it is first written. If an attacker were able to overwrite a public key document in a way that was not obvious to readers, they would be able to intercept any new invitations to that Identity. It would then be up to the owner of the Identity to disavow the Identity through other channels. Importantly, this attack would not compromise the security of any existing Invitations or Conversations.

Conversations are publicly readable and writable. Without the relevant Secret, the Messages are gibberish so an attacker does not profit by gaining access to them. There is, however, a Denial of Service threat through an attacker POSTing random data as Messages. Clients could trivially filter these out from appearing to the user, however they would only be able to do so after downloading and attempting to decrypt them. This is mitigated by only publishing the URLs to Conversations as part of encrypted Invitations. URLs to Conversations should be complex enough to avoid attackers being able to easily guess them.

Attackers may attempt to ascertain who is conversing by watching the metadata flowing into and out of the central CouchDB installation. Watching this from the outside (say, packet sniffing on datacenter’s network) would be useless so long as SSL is enforced on all connections. Attackers would be able to ascertain who is using UTR, but not who they are conversing with. Being centralised actually provides better security here, as if a user hosts their own Identity it becomes easier for attackers to know who is sending them Invitations. If a user hosts their own

Attackers may attempt to ascertain who is conversing by watching the metadata flowing into and out of the central CouchDB installation. Watching this from the outside (say, packet sniffing on datacenter’s network) would be useless so long as SSL is enforced on all connections. Attackers would be able to ascertain who is using UTR, but not who they are conversing with. Being centralised actually provides better security here, as if a user hosts their own Identity on a server with no other UTR traffic it becomes easier for attackers to know who is sending them Invitations. The same holds true for Conversations. There is anonymity in the herd.

Attackers may use the legal apparatus to force the entity hosting the central server to log and hand over metadata from within the application server itself. This is difficult to defend against legally, but the technical implementation gives us some extra degrees of freedom. If the controlling structure of the host entity was set up in such a way that it could still take overt actions after recieving a court order, and the entity still had control of their domain name, it would be possible to move all Conversations to another jurisdiction with minimal user impact. Even if the data could not be transferred to another server, each user has a durable store of the conversatiosn that would automatically repopulate the central public repository the next time they reconnected.

These are some details about the implementation of Under the Radar. These follow on from the architectural details.

UTR utilises CouchDB as its server and PouchDB for its client storage. CouchDB’s replication protocol forms the transport layer.

UTR is implemented as a collection of modules strung together with browserify. This aids auditability by keeping each component as small and insular as possible.

UTR is written in CoffeeScript because I like it.

All of the logic of UTR should be under test. We don’t aim for 100% coverage, rather 100% of the tricky bits.

Browser crypto is done with forge. It seems complete and well written, but to the best of my knowledge has not been independently audited.

Now go check out what this lets us do in the ecosystem

There is some great prior art in this space, but none of them scratch my itch satisfactorily.

TextSecure is an example of great cryptography and you should definitely have it installed, but its identity mechanism frustrates me. The primary identifier for users is their mobile phone number. Practically, this is a pain if you need to switch numbers. If you travel overseas frequently this is a common need. Also, since it uses the mobile network’s SMS system as its transport protocol there’s no protection of metadata.

NB: Whisper Systems is working on updating TextSecure to use the device’s data connection instead of the SMS protocol, which should fix this. Moxie is Serious Business and I respect the hell out of him. Finally, though, there’s no way to use TextSecure on anything other than your phone. I spend most of my day in front of a computer and want to be able to use it for my conversations.

Bittorrent Bleep is really interesting software. The fact that its closed source, however, means we can’t trust it. On a practical level, it currently only supports sending messages when both parties are online which severely limits its utility.

OTR is really good software, but it has some limitations. Adium and Pidgin are fine clients, but I don’t love them. ChatSecure is a great mobile implementation, but it suffers from the structural problems of XMPP on mobile.

Cryptocat seems to be heading in the right direction, but there’s no Android client as yet. Crytpocat has a much more ambitious cryptography goal than UTR, implementing its own protocol to ensure forward secrecy, origin authentication, etc. This is definitely one to watch, but I worry it will be a while before its ready.