 Hi, I'm John from the Facebook's London security team, where I work on some privacy preserving products, and primarily end-to-end encryption and messenger. So this is something that we built and launched in July 2016 when we call it secret conversations, which enables you to talk end-to-end encrypted between one device of yours and then one of the recipient of these messages with optional ephemerality as well. So in this talk I'm going to give a bit of an overview of why this feature looks the way it does, and then take a deeper look into some of the cryptography that we chose. So to first disfraim this discussion, let's start with a higher level model of how regular message conversations work. So first and foremost, Messenger is indexed by your Facebook account, so as opposed to many messaging systems where you might be talking to essentially a phone number, with Facebook you're talking to an identity, a name, a profile picture, a friend graph, and this is an identity that's cloud-based. It's administered by Facebook essentially, and it's accessible across all of your devices. You can log on anywhere to access Messenger from your smartphone, your laptop, your friend's laptop, an internet cafe, an old feature phone, and you'll have all of your message history available. So a totally valid use case is you've forgotten your computer and you log on on your friends, you want to check your messages, which leads me to the final point of this model where devices can be shared between people. So this is particularly notable with web browsers, but also our mobile apps, say in Android you're able to switch between different users too. So that's a sort of overall model of how Messenger tends to look. Let's look at what an E2E Messenger would typically offer. So first and foremost, you wouldn't really be E2E if the provider could read your messages. It would completely defeat the object. You ideally want perfect forward secrecy to make sure, of course, that if your keys are compromised at some point or your overall device state, that earlier messages don't leak. Ideally you'd also have future secrecy so that you can be safe post-compromise as well. You want to be able to verify that the person you're talking to truly is who you think they are. It's not that much use having an encrypted connection to someone if you don't know who the other endpoint is. And then a slightly subtler point is that you want to make sure if your device is shared that only the person using the device at the time or the person who's meant to be using the device at the time messages are available and anyone else who may have used that device at some other point, their messages still remain secure. So with this sort of list of prerequisites for what we'd want from an E2E map, how would we expect this to look at a sort of slightly higher level? Well to start with you've got to have a well-defined set of endpoints. If you're messaging someone E2E you've got to know which keys you're encrypting to. You've got to have some level of consistency in identity so that you know that say if you checked someone's key yesterday you're still messaging the same person. If it's constantly changing then that's not as useful because again you could just be swapped out and talking to some completely different man in the middle. You're not going to be able to have message history in a reliable manner so if you switch to a new device we couldn't find any way to really marry this with perfect forward secrecy and still reliably have your message history available. This one sort of goes without saying but your client needs to be able to encrypt and store crypto state and messaging data. So this excludes for example some basic browsers without JavaScript support. And finally because you might have shared devices you're going to need some mechanism by which to protect the data from one account from another account on a shared device. There are a bunch of apps out there which already fit this model. WhatsApp, SQL and Viber are some of the most obvious ones. Allo is also pretty close. And notably these are all indexed by your phone number so this already provides that well-defined set of endpoints that you need. They do have some sort of model of secondary device each of them but they all share the same identity still so this consistently verifiable identity isn't broken and you've still got message history not being available when you use a new device. Then also these clients are all apps provided by the vendor so they can make sure that this binary has the necessary crypto, the necessary storage capabilities in. But messenger really doesn't fit this model at all. The endpoints will constantly change but still have full message history. We've got messaging over a number of services including ones which don't support JavaScript on our basic mobile site. So as we want to add end-to-end encryption, one option is to try and do this by default and in doing so totally change the product and actually remove a bunch of features that people use messenger for, a lot of the things that people rely on. Or we can build it as an optional mode and not force people to use it and this is of course what we did. So this is the model for messenger and how we would undertake this forward. Let's take a look at some of the high-level choices. There were still many degrees of freedom in how this can look. So from the start we wanted to use off the shelf crypto. We didn't want to roll our own where we could avoid it and there is a small aspect in the message franking which is slightly novel and I'll cover that later but in general we were using off the shelf tools. One of the earlier decisions we had to make was how many devices could be in any given thread. So we knew from the start that it would have to be a subset of devices for messenger because there are always some particularly the no JavaScript versions which won't have access to secret conversations. So we had to have some sort of device management model. Multi device in this world would be somewhat complex to come up with and potentially more difficult for a user to understand. So we ended up just saying each thread has one device per person in. Very simple to understand what's going on and also somewhat simplifies the engineering as in general the multi device protocols that we could use would bootstrap off a one-to-one protocol so we'd have to have created this one-to-one version in the first place. So with one device per thread per person the next option is well is that your only device that you can use for all secret conversations or can you actually use different devices for different threads and we did actually experiment with the latter model a bit but this ended up adding extra complications for starters to get this well-defined set of end points you now actually had to have a symmetric setup sorry not symmetric synchronous so I actually send a request from my device which defines well defines which device I'm using but I don't know which you are until you respond. So this was far less good user experience and so we ended up going with the single device per account meaning your model is really simple particularly with the previous point that any device that you can use for secret conversations is the only one that you can use for secret conversations you know exactly who you're messaging you know exactly where your messages are going then finally we had to decide which services were going to support here we just went for our main apps so iOS and Android web presents a number of challenges not least trust in the JavaScript cryptography and we didn't want to address this in the initial version so that's what we aim to build let's take a look into some of the deeper specifics of the crypto so the first main decision was what end-to-end protocol should we use and we quickly settled on the signal protocol here or the axolotl ratchet at the time that we started designing this and pretty much because it is the best in class it's what's apps using signal of course uh google alo uh viber I think with their own implementation so it's pretty much an industry standard I won't go too deeply into this as I think there are two talks on this protocol later on but suffice to say it's really good another feature that we wanted to support was abuse reporting so we care a lot about people feeling safe on Facebook meaning that having an ability to address abusive behavior in some degree is is important for us to maintain so in an end-to-end encrypted model this is much more limited compared to channels where we do have the plain text available but we did want people to at least be able to report these messages to us now naively you could have a simple model where when Alice sends something to Bob over the encrypted channel in this diagram denoted by the the green channel and Bob sends it up to Facebook saying this is what Alice sent me but the problem here is we've no way of verifying that Bob's being honest because because we're not permanently storing the ciphertext server side just during the delivery process and we didn't want Bob to have to store this either so he ends up building a mechanism that we called message franking which allows us to verify that messages truly were sent over our infrastructure as claimed but without leaking the message contents to us in less they are explicitly reporting and without us having to store anything about this server side so I'll cover this more deeply in the next few slides if this diagram isn't particularly clear but so at a high level you've got Alice is adding an HMAC over her contents over her plain text to be sent up to Facebook and then we add our own HMAC on top of this so that when Bob reports it we have enough data to verify that the plain text that he sent is matches what Alice sent him because of the HMAC and we can verify that the HMAC truly was accurate because of the one that we added so Alice has to send a message it's called this M and she generates a random nonce and appends this to the message or contains it within the message structure she then generates an HMAC over this which we're going to call the franking tag keyed with this random nonce then encrypts the structure containing the message and the nonce using lib signal and sends up to Facebook I want to send this message to Bob here's the franking tag and here's the cipher text on our end we compute what we call the authentication tag which is an HMAC over this franking tag combined with some basic metadata so went from Alice to Bob at this time and then we forward all of this to Bob so that it came from Alice here's Alice's franking tag here's our authentication tag and here's the actual cipher text on Bob's side he ignores the authentication tag because this is meaningless to him because he doesn't have Facebook's secret key but having decrypted the cipher text from Alice is able to verify that Alice was honest with the franking tag because he has both the plain text and the secret nonce then this verification ensures that the authentication tag that Facebook has sent is computed over the correct data because he knows that Alice was honest in her initial franking tag so if Bob then wants to report the message he just needs to send the plain text up with the original nonce the timestamp the fact that it came from Alice and then this authentication tag which we can receive from this we can recompute the franking tag and then we compute the authentication tag verify that it was correct and then we've now proved that it truly was sent from Alice to Bob at the same time that we thought and we've got a similar level of assurance on this as with any normal message sent of a messenger in plain text in our regular mode so next we have a mechanism to send attachments we used a separate data store for attachment data rather than inlining this within the signal protocol it's this better suited the messaging transport that we're using and gave shorter latency so here's a diagram of how this works and the next slide will again cover this slightly more clearly but you're generating a random key alongside the image you're encrypting it using the concealed library if you're on android or a re-implementation of the same protocol if you're on ios then this cipher text is being uploaded to facebook stored for 30 days in our back end and facebook returns to us an id and authentication string for us to download it later on we also then include in the message packet this key that decrypts the message a checksum of the cipher text and potentially a thumbnail of the image to improve the ux on the initial delivery so here's it laid out i think i'm pretty much covered covered that so i'll just leave that up for a sec and i'd note here that this authentication string alongside the id is just there to prevent people from scraping through the attachment id space so that they can't just iterate over it until they find random cipher text to download uh which should be meaningless to them because they're cipher texts but we wanted to avoid that anyway and so the received path here is fairly simple you've uh you decrypt your cipher text giving you the thumbnail the key um the id the authentication string and the checksum you displayed this thumbnail you download the cipher text check the checksum decrypt it display it so finally we wanted to address this shared device issue that we have um and protect the on device secret conversations database when you might be logged out um so this is partly because good practice for sensitive data being stored but uh largely motivated motivated by the this shared device model so to isolate data between users we simply provide an author we provide a key from facebook at the point of login um and then we store all of our secret conversations database for a given user under that key um and then as soon as you log out it's wiped from memory on the phone and so you don't have access to it anymore um this looks roughly like this um each arrow donating a layer of encryption um so you've got a storage key on the device which is encrypted by this server provided key from facebook uh that stores first your private keys so your lip signal identity key your signed pre key etc and also your thread storage keys each threads being encrypted under a separate key which then contains the messaging data and the session keys for that thread so that's the product let's and why it looks as it does let's finish up with just some of the challenges we're looking into and hoping to get good solutions for in future in which this community may have some thoughts on so a huge one here is that of actually authenticating your pairs um we wanted to be able to provide some simple model whereby you can trust the person you're talking to truly is who they claim to be um this is our current solution um it's uh probably a fairly familiar type of screen to most people so you can just compare your public identity keys people but we're fully aware that the vast majority of people won't do this um so we want Alice to really be able to verify she's truly talking to bob without this having specialist knowledge without knowing that you need to go check your keys without having sort of any certificate authority and ideally come up with this sort of ux that browsers have sort of perfected well maybe not perfected yet but uh browsers are doing pretty well on with tls and require very little little knowledge from the actual user next uh we would like to extend this feature beyond a single device per account to multiple to support multiple devices um to better reflect how regular messenger is used by many people um so our current model is really quite simple and very easy to understand this is your secret conversation device this is your identity key you can message someone else's designated device you compare with their identity key and you know exactly where the channel for these messages is but we'd like to remove this restriction um there are engineering challenges there but ultimately we had some higher level ux concerns so we've got to manage how devices get enrolled for your accounts um how they then get subsequently disenrolled um whether this disenrollment can happen automatically at some points and how that will affect the overall experience because of course you don't want people again to have to understand how will the crypto works in real life and so they shouldn't have to know that they need to disenroll a device at some point and also once you're dealing with multiple devices it makes the authentication problem trickier um so you're no longer verifying a single key but you could be verifying a collection of keys for a given account uh and a collection which is more likely to change more frequently so a common option used in multi party chat uh such as with whatsapp and signal is conversation codes which provides a fingerprint over all participants of the thread um but in our case we feel it's not quite that simple as that relies on you knowing that you have all all of the devices within the thread so when you when you're comparing um this is this phone number this is this phone number and this one and between them we know that there are three devices in this thread and we can see all three are sharing the same key you know that that's okay but for us if you're unlikely to have a large number of all of your devices in the same place at once verifying that you share the same key isn't sufficient as you don't know how many other people out there share the same key as you well people devices sorry so it's probably not the a complete solution for us and finally I've said that we didn't want to address this initially but we would eventually like to add web support now this compounds the multi device concerns significantly as with web sessions you're more likely to have many more of them um over time you're much more likely to say be logging in in incognito mode in your browser in very frequently as opposed to logging in on your phone once and leaving it there until you get a new phone so this means there'll be a lot lot many more keys on any device it's uh risk significantly scaling issues particularly with client side computation and then combines this problem of well how do we disenroll these devices particularly given that with lots of single-use browsing sessions there's a risk of forward secrecy that suddenly you're creating a lot of states out there which are okay need to be capable of decrypting all future conversations until until that device is disenrolled and then finally we have to overcome the general trust issues with JavaScript crypto being provided by a remote provider and potentially changed every web request and how can you trust that this code is actually correct and it's an unsolved problem as far as I'm aware this is fundamentally different from our mobile apps where we're actually serving a binary through a third party and you've got a pretty good idea that you're seeing the same binary that everyone else in the world is so it's a big difference there that's all I've got thanks very much for listening I'm not sure if I have time for questions we can take one or two questions oh great so the end to end encryption is protecting against wire tapping it doesn't protect against civilians which is like who is talking to who so if facebook doesn't add end to end encryption right people then know that it's not good to say to talk to a journalist over facebook so they will self-censor and instead will use signal that doesn't collect metadata as we know from the documents from the court right so maybe why guys you bother and adding end to end like I mean honestly it will just people will get in trouble so yes as you've observed protecting metadata wasn't really part of our overall model it's very difficult to achieve within our world and we get a lot of benefits from it for example being able to perform better spam protections in general yes if you're if you're trying to protect your metadata from your provider then this perhaps may not be what you're trying to use but what you need to use but we wanted to provide something which at least can protect your content which is what we were really focused on and provide this to as many people as we can and so with this update we were able to ship end to end encryption as an option to a billion people without them having to do anything which yes doesn't protect their metadata but does give them significant increase in messaging security I had a question about the web or the storage encryption it looked like the key was to encrypt the storage was provided by facebook is that is that are you able to be compelled to decrypt the storage on the device then or I guess I'm not clear on the why that why this choice is made so I'm probably not the best person to answer policy questions as I um I largely had handled the technical side of things um so if there were a physical device um then like it would be possible for facebook to access that storage key um but um in general this is this attack this is to prevent the attack where you have a device um which you know someone else has been using but they're logged out of now and you as someone um without access to that storage key I want to read that those messages and so it's to protect I get it's to protect against other people accessing your physical device and to raise the bar yeah I mean I get that I was just wondering if there was a usability or some other reason for that control of the key by facebook um no it was it was just just to raise the bar when when switching devices hi thank you for this presentation and thank you for rolling this out um I agree it doesn't solve all the problems but I'm happy to see it being pushed into the real world at least we can raise the bar and um leave you with some data that you can that you don't have immediate access to um if you want to try to solve this I recommend thinking about mixing the user's password into this I'm assuming you don't store a clear text of the user's password if you mix the user's password into the account key then you can potentially protect this against both you're being able to recover and everyone else um yes that so that that could work aside from in cases of say account recovery where someone has actually lost access to their password um so right so if you're doing this as an optional opt-in thing you can say hey if you want us to be unable to have access to this check this extra box during opt-in this is just an option for you thank you thank you is it quick because we have to actually move on uh sure yeah just on the last point about making this work on the web um I work on firefox I'm very keen to have this work on the web uh so do you have any thoughts on things we could do to make the web more friendly to this stuff things we could add to the browser to to make make it more amenable to this sort of thing that sounds like probably a slightly longer point when we have time for but should we talk after we take it offline yep great thank you I think we should actually move on so uh John thank you very much this is a great thank you