 Okay, so memories for your eyes only and you will see some of the questions in the previous talk actually applies to my talk apply to my talk okay, so Snapchat is an app that allows Allow people allows people to do peer-to-peer multimedia communication chatting sending video clips Young people typically people who are younger than their parents are typical users and and Recently besides the app the external camera in the form of Glasses that you visibly see the person taking a picture Was added okay, so adding an external device and think that are not That are external that are wearable present some problems and One problem is that when you knew when you want to display what you Film in your camera the video clip you need to move It to a display and then you need the the glasses to to to mobile and you need storage and And you may use different devices to display it So you need essentially cloud cloud storage that can store your your snaps your your video clips and You store them so you remember them it becomes part of your memories and this is this is memories and So I will cover in this talk the The security aspects of memories of this cloud storage And and which was released in in June last year. Sorry the last year. Yes, and And it's essentially it's a cloud self storage I serve my own memory I save my own memories With security against the the servers and the engineers of the the company actually getting it so so Snapchat has a chat part a Camera part which typically which people use and and and a snap part which is the video with the video part and The typical till memories was introduced the typical use of it was Sending snaps from sender to receiver. So you you upload a snap you You send it to to one of your friends. It's a social network and then the recipient on the other side get a notification that they can download this this video clip and and then Download it and and view it and then it disappears Disappears immediately on From the user device and disappears also After some time also from the the storage the central storage So what is memory? It's and it was a newer Snapchat offering one can keep own snaps as I said and So the the question is if I keep it on the cloud Why should they give my content to to the cloud? It's against the the philosophy and it's against privacy and you don't want every engineer in Charge of this storage having access to my own memories. Okay, so this was the idea and So we need to design a subsystem and We needed to design it knowing that extensions are coming We didn't even know that the extension is going to be an external glass at some point then we learned that we had to work on the security of of the of the these glasses these glasses called spectacles and and We need to To account for it. So the development has to be agile for future extensions and we need to exploit the existing cloud relationships So this by the way, how memories look You look at Your snaps or your stories or your your camera roll and so on and and there is a there is this section that that is called my eyes only and On the user side you have to eat your to heat a pin or a password and only then the memory show up on On your device. So it is it looks like pin protected and The users know that if they lose the pin, they lose the memories. I mean, it's just memories and people lose their memories. Yes, I Don't remember 40 years ago Okay So it was introduced But what was desired from Analyzing it from a security point of view So the user is mobile. You can log in from any device people use different devices to To log into the app to their own account The content should be made accessible to the user only the content is not viewable by by the servers And even all the servers collude you still want this pin or password protection and Which serves two things by the way, it also serves if somebody take my my my My device it's it and I didn't put my pin yet. It's not visible even even to to somebody physically holding the device and I mean besides activating the There is receipt of of these memories of these memories, which is in my eye my eyes on it and We want also the flexibility to be able to replace servers if needed so server state should be portable at least initially and And so this implies that the content should be somewhat encrypted on the server the user Should be able to reconstruct the keys because it moves from device to device and only the user can actually decrypt So possible solutions. So the first solution is a password rely entirely on it on the On the pin encryption, but then we know that it's too weak and Force very long password that has 128 bit entropy. Good luck with it Third possibility is that the password encrypts strong key on the local device, but you know this Doesn't work if the user move between devices no mobility We can attempt a device to Secure hardware module on on on on on the cloud, but you know this will mean that No, not easy to change servers it may work for Apple, but doesn't work for us so So given this this kind of constraints the engineers Look at it and say, oh it looks impossible. Okay, what does it mean? So here is a principle. What does it mean for a cryptographer where a software engineer says it's impossible? actually interpreted as cryptographically interesting, okay, so Essentially we need to break something in the setting that makes it impossible. So crypto design of actual Engineering problem in the real world is also in also involves breaking. You don't break the cryptography, but you break the Mental state of thinking about the problem You have to think outside the box. So you have to break the box okay so we Decided we will introduce trust domains kind of like new servers We'll do some key management and we will apply multi-party protocol between the servers and the first idea that comes to you when you do key management is a kind of secret sharing protocol a variant thereof between a the main server s and the key server ks and the user and For a minute forget this to the Typical thing that people usually criticize Theoretical papers, you know, you do secret sharing who tells you that the servers don't talk to each other forget about it You know, we'll take care of it. We can build systems Some things are easy to criticize on a paper then When you really build system and take care of Making sure that your assumption will hold Okay, so if you look at it As it is and you look at the you are familiar with the crypto literature The situation looks like something that is called password protected secret sharing, which is an extension of PAKE So you can you can apply it, but you know this this primitive is is too heavy because PAKE implies public key and And you know typically in cryptography employing employing a given In in crypto engineering if you take a if you take the cryptographic primitive as they are heavy protocols It doesn't you know Always the most economical and the most useful solution and you know cryptographers build very Complex primitives, you know such and such and that that that that that encryption with certain properties and it's very nice very nice intellectually challenging problems, but you know in system like now There is a tendency of cryptographers to work for example our encryption that has Access control build into the encryption if you know the complexity of access control in real system and how they Morph over the lifetime of the system you may wonder or if it's really applicable and when it's going to be applicable Maybe in rare cases, but this is just one example I'm not trying to pick on anyone. I work on this problem, too So so there is a bat there we cannot we don't want to use the the existing one because you know the system already exists This is an incremental step Some actions are already performed in the system take advantage of it Just repeating the crypto for the sake of repeating the crypto is clumsy performance wise and it you know It's not good and you know system needs flexibility of design and to account for modularity and Incrementality that comes with the development process So what we what we decided to do is to employ our own solution, which will use symmetric cryptography They're already in the system authentication flows like user authentication and and servers have their own Public key for signing and and there is a certificate pinning in the system So we can take advantage of all these so we build on these existing components So what we have so what we deployed? so we We have a general design and we have the first deployment so the first deployment is essentially a three-party design with with two servers and and a user and Of course, we have numerous extensions in mind for the lifetime of the system and the emerging needs and the hardening of security and so on it's a principle you have to be clairvoyant about What's coming in the system? Especially when it's not like the function the primary function of the system which security usually is not So we'll have flexible key management The snaps the videos are going to be encrypted with Snap key and there's going to be a master key that is going to encrypt all the keys And then we are going to do that to run the protocols on this on this master key This is the typical way to to compress Information or compress the important information the system and work on it. That's a principle crypto principle And we will share and reconstruct the master key only the master key will be chosen at the user device and All the operations will be on on that master key So the general structure We employ two kind two layers authentication layer and the layering is natural because authentication Aspects Exist and then we will do the the master key sharing and recovery the secret sharing like Operations so secret sharing is a method that you know to to to distribute a secret among different parties It's rarely used commercially there are uses in military Applications everybody know that in a nuclear submarine It's not one person that activates the attack and that's type of secret your type of secret sharing it's used in Distributed storage storage system some of the experimental Multi-party computation Protocols that run also essentially built on on on linear secret sharing. Okay So we'll use this three out of three version and the embedding protocol and the environment that The memories protocol the memories protocol is The user you logs in produces content and then deposits it and It can deposit Also in the my eyes only in the secure section of the storage and Then comes the Retrieval which you logs in and then retrieves the memories Okay, simple. So there are sessions that you load memories and there are sessions that you Recall your memories. That's right like in real life. It's real life crypto here these are memories and You know protocol wise this depict it it's similar to To to the previous The the sender and receiver protocol, but here the same user is the sender and the receiver and It's a little bit more asynchronous in some sense Notify the server puts the memories and then retrieve it to your set Okay, and and now to the protocol. This is the more technical part and the protocol I call it to give and take protocol the user creates and Essentially gives the key to the servers and and then when it wants to read the memories and And open the my eyes only snaps It retrieves it calls back it takes back the keys from the the key from the servers Okay, and then the user will also have a part that it contributes to to protect against collusion of the servers and We don't care about if you lose the pin. It's his problem He knows about it or she knows about it. Okay, so the protocol The the the skeleton of the protocol looks like looks like this this key generation and sharing the give part so the user authenticates to the server first path first factor of attention authentication and The server gives it the short-term session certificates essentially signing that you know this server this time started a session and It gets from the server a high entropy random nonce that is recalled by this server is associated with this user and the server remembers this and as part of its states and The user inserts locally its choice chooses a pin and chooses it locally and then Generates to token based on these Nons and and the password an encryption token and authentication token based on to key this key derivation functions think about it of a pseudo pseudo random function when n is the key and P is the value and and The user draws the the master key and by which with which it will encrypt The keys that are encrypting the snaps and Generates two tokens t1 and t2 to t1 is the encryption of of of the master key with the ink Value and t2 is just the oath value and The user sent to the key server He certified itself Based on the Attestation of the server and it gives t1 and t2 to Ks the key server so the secret this the secret sharing that we see it is that t1 and t2 are in the SK is KS the key server or server of keys and the password P is at you in the in the user's head and and The Nons is at s at the main server Okay And of course the communication is otherwise protected And now comes the The take part we want to retrieve the key so we come to the user comes to even a New device, you know, he lost the old device. He has a new phone Think about it this way. So first he authenticates itself to the server gets into his account and authenticate itself and Based on this authentication gets from the main server denounced and and Again shortly the session certificate and a sign challenge see age with the signature of the server The user itself inserts the the the pin to to regenerate Anc and off because they are function of N and P remember as a two key derivation function to so the random functions And sent to the key server the certificate From the this the session certificate the response the response to the Challenge which is just an encryption with the authentication token of the challenge remember the challenge is signed by the key server and then Sends the respond is sent By the server and the respond is sent to the key server So the key server can verify both the challenge because it's the sign part and the response and The key server is the oath token. So it is sure the key and And It presents the challenge the signature on the challenge together with the session certificate and the respond and The key server check the signature Check the respond is the challenge in the response is the right response to the challenge and if so it sends the token T1 which is the encryption of The master key under under the The ENC key and this enables the user to retrieve the key So it's a give it's a give to the two servers and some protocol between them exploiting the existing flows in the system and then recollection of the snaps and key portions Proving that you can you can do it being able to do it with the pin and You have the master key you can decrypt the keys and you can decrypt the the snaps And you can get the content So the servers both the keys the main server and the key server each by itself cannot perform offline pin attacks by themselves because The key which is a long Long long message is missing to the main server and the nonce and is missing from the from the The key server In its form and and and the pin is kind of garbled into the tokens that are in the key server and If the server get get together they still have The pin protection and of course you take care of it by by having your pseudo random function having some work factor other users Need the two factor so it's protected against other users and the sessions are protected with TLS and and and that's the protocol s is the center of the authentication and authentication verification and The user itself is the center of key management everything is is is built given Recollected and and and recovered Only at the user's current device what whichever current device it is So we combined authentication signing secret sharing password-based derivation key derivation functions To get these the protocol is agile and extendable We can extend it to changing of the pin Changing of the key in the future We have ways to do to increase this the servers if you want more trust and and it's it can be built on What we have but do it a little bit? As we want to adopt it and We can we can exploit polynomial based secret sharing in the future and we can get randomness for more servers and and so on and We know how to do it we you know the basic thing is implemented and the first thing is to really run it this way and fortified the The idea that you have two separate Servers and take care of this and and once this is done right the the extensions of the trust domains We'll be done right and and you know Rome was not built in in a day and so our systems There's something to take into account Okay, I said all these And I just want to Recap that you know often often you see multi-server based security and people believe it's theoretical But with the right risk or analysis and trust model and system understanding and and and hardening It can actually give you real-world security and And we we implemented it in this case So this is a tool not to be Forgotten I mean secret sharing does not exist only to to write pay papers about Okay So this building on the system flow that's very important the system exists and you build them layer by layer by layer and Trust variations on cloud server is possible and and the principle is You know in practice versus theory so the principle that was applied here is Is is a bit of sophistication which gives you a lot of miles So we are at the at the era where Politically correct correctness is Claim to be dead But I advocate that this principle is important and I call it industrially correct Okay Thank you very much Yeah, thanks Monty. Maybe we have time for one question. There's a quick question. Yeah Yeah, I'm interested in how much key-stretching you're able to do if I understand the design correctly the KDF step takes place on the User device when we did something similar to this in Firefox accounts a couple years ago We felt very constrained by the low-power devices on that side. Can you tell us a script be crib PBKDF? Yeah, of course, this was a problem. There was an array of all the possible devices and and we settled on on the one that we could support and wanted to support There was there were performance engineers that are exactly for that and all this was totally checked I mean I'm I as I say the beginning this this talk does not cover all the aspects of the design here There are many many other layers. Thank you. Thank you