This is a copy of an email sent to the TRVE DATA mailing list.
TRVE DATA monthly update: April 2016
Hi everyone, thanks for subscribing to the TRVE DATA mailing list! We're going to try to build a habit of posting a monthly project update here, and this is the first one.
For background, we published a blog post explaining the rationale and goals of the TRVE project. And here's a little video showing our collaborative text editor prototype.
Today I'd like to briefly introduce the people in Cambridge who are working on various aspects of TRVE:
Diana is working on the issue of trust establishment, that is: knowing whether you're really talking to the right person, and not a "man in the middle". The most common solutions to this problem today involve a trusted authority (a certificate authority or a key server) -- for example Signal/WhatsApp and iMessage rely on a trusted key server. The problem with this approach is that an attacker or a government authority could subvert the key server, or compel it to add another key for a user, and thus gain access to the user's data. Diana is exploring ideas from certificate transparency and gossip protocols to make it harder for an attacker to subvert the trust establishment.
Stephan is looking into peer-to-peer messaging protocols. Our prototype collaborative editor relies on a cloud server to relay messages from one device to another; even if those messages are encrypted and signed, the server can still see who is collaborating with who. The mere fact that communication is happening might itself be sensitive information (consider communication with your doctor or lawyer, for example). A peer-to-peer system, e.g. via the Tor anonymisation network, would provide better privacy. Stephan is doing some experiments to figure out how feasible this approach would be on mobile devices.
I have been working on collaborative editing protocols. If you want to build any kind of document-editing app (be it for text documents, or spreadsheets, or graphics, or an address book, or anything else), you can probably express a document using a general-purpose format like JSON. Thus, if we can figure out how to efficiently sync JSON documents across devices, and automatically resolve conflicts from concurrent edits, we've got a good foundation for building collaborative apps. For this purpose, I'm using Conflict-Free Replicated Datatypes (CRDTs), and currently trying to construct a generic CRDT for JSON.
Alastair is advising Diana, Stephan and myself and contributing to all parts of the project. He has a lot of experience in empirically observing the behaviour and security of mobile devices through the Device Analyzer and Android Vulnerabilities projects.
You may notice that nobody has been working on the actual end-to-end encryption part of the project, even though that's our headline goal! That is a deliberate choice: crypto protocols are hard, and we're hoping that we can just use an existing protocol "off the shelf", rather than trying to invent our own. For now we're focussing on the areas of the project that are less well understood.
We're thinking the Signal protocol (recently adopted by WhatsApp) will be a good starting point, but we're also considering others. For a good overview of secure messaging protocols, we recommend this survey paper:
Nik Unger, Sergej Dechand, Joseph Bonneau, et al.: "SoK: Secure Messaging," at 36th IEEE Symposium on Security and Privacy, May 2015.
What's happened in April?
Diana and Stephan attended the Google security PhD summit in Munich, presented posters on their work, and had some useful conversations.
Diana passed her first-year PhD viva and report, congratulations!
Martin attended the workshop on Principles and Practice of Consistency for Distributed Data (PaPoC) in London, which brought him up-to-date with the latest research on CRDTs.
Opening the discussion
Anyone is welcome to post on this mailing list. There are currently 26 subscribers. Just to set the tone, I would ask you to consider this blog post.
The best ideas are sometimes those where you just have an inkling, but you're not yet ready to defend the idea against harsh criticism. I hope that this mailing list can be a safe place where questions and early-stage ideas can be discussed openly, without fear of looking stupid or being shot down. Building secure systems requires the very best ideas we can find, and in order to find them, we need to give ideas and people a chance to grow and be nurtured.
And with that out of the way, I look forward to many good discussions :-)