 Hi, I'm Joseph. I'm here to talk about optimal channel security against fine-grained state compromise Which is joint work with Igor Stepanov. So there's a growing recognition that ordinary people deserve end-to-end encrypted communication As cryptographers, we've long understood the theory of how this can be achieved but in practice there's A dearth of available easy-to-use tools TLS is designed for web servers, not for person-to-person communication PGP is widely accepted to be a pain to use Messaging apps are arising as an easy-to-use alternative Here I show several examples of messaging apps which aim for end-to-end encryption To give a sense of scale here, WhatsApp alone encrypts around 55 billion messages every day There's somewhere around 700 million iPhones in use Given this widespread use, it's important to understand exactly what security they're achieving In my talk, we're motivated by the double-ratchet algorithm used, for example, by Signal In particular, we're trying to gain a better understanding of the goal it's aiming for Which is communication in the face of state compromise So if we think about traditional encryption, Alice and Bob will share some key K Throughout their conversation, they'll encrypt and decrypt all of their communications with this key But now in the threat of state compromise, some attacker somehow gains access to the secret state on the phone Given this key K, the security of this communication is completely and irrevocably lost In practice, to address this, various messaging apps are using techniques where they update their keys over time K1, K2, K3 And then the idea is that an adversary, say, steals K1, they shouldn't be able to learn anything about what was encrypted using a different key, say K2 In slightly more detail, the general goals we're aiming for here are often referred to as forward and backward security Forward security asks that in the face of an exposure of prior keys in communications, security is maintained Backward security asks for the opposite Of course, exactly what is being achieved by these goals needs careful considerations If, for example, our threat is malware, which can just directly exfiltrate our messages, we're not really gaining anything by using these techniques These techniques will be more useful when our threat is some sort of malware, which can only exfiltrate keys instead of messages And if users actively delete their messages over time These notions are of particular relevance in the secure messaging setting because messaging sessions can be particularly long-lived There's been a few recent academic works motivated by ratcheting And generally, what all of them aim for is they ask what security goal does ratcheting achieve They formalize this goal and then they build some sort of ratcheting which achieves this goal A first example of this was by CCDGS, which looked at the particular ratcheting used by Signal, analyzed the entirety of their key exchange Did not model encryption at all Last year at Crypto, there's a paper I was a co-author on, which introduced as separate primitives, ratcheted key exchange and ratcheted encryption But as we just heard, the important limitation was that we only considered communication in one direction And finally, the talk we just heard about bi-directional ratcheting, which extended this previous work, but did not specifically model encryption The goal of my work today is slightly different Instead, we asked what is the best possible messaging security we can hope for in the face of fine-grained state compromise We formalized this and then achieved it And notably, the techniques we used don't really look like ratcheting To give a summary of our contributions, which I'll be covering in the rest of the talk First, we defined the strongest possible security of a channel against fine-grained state compromise We defined two new forms of public key primitives, key-updatable digital signatures and public key encryption Provided constructions for these primitives Showed how they can be combined with a collision-resistant hash function to build a secure channel meeting our strong notion And we, of course, provide proofs that all of these constructions meet the desired notions of security One quick point I should make, this public key encryption actually differs slightly from what we had in the proceedings version We realized there was a small bug in our original proof My co-author is supposed to push the full version to E-Print today, which fixes this Might be up there now, I'm not sure Okay So, at a very broad level, the threat model we've tried to formalize Is looking for both integrity and privacy in the face of an adversary which has complete control of the communications sent between the two parties And is able, at any time, and perhaps repeatedly, to steal the secret state stored by one or both parties By best achievable, how I want us to think of that is that any attack which could be prevented is prevented We, of course, can't hope to prevent the attacks which are unpreventable An obvious question to ask then is, does the double ratchet algorithm used by Signal achieve the strong notion that we came up with? Unfortunately not. Some examples of preventable attacks which would not be prevented by Signal include that Given the state of one user, you're able to forge messages to that same user You're also given the state of a user capable of reading messages that that user sent to the other user And some more subtle attacks One implication here is that with the single exposure of Alice using the Signal protocol I would be able both to impersonate Alice to Bob, which we can't hope to prevent And impersonate Bob to Alice, which we'll see that can be prevented Of course, then there's the question of how much do attacks like this matter in practice I can't really give a full answer here that would require having a better understanding of exactly where such attacks occur in practice Than I think we really have And then you might also wonder is there any kind of small tweaks we can make to Signal to meet these stronger notions of security I can't say definitively, but it doesn't seem like it It seems like the stronger notion of security we defined really requires stronger primitives than is used in Signal Okay, so now to dig slightly more into the formalism The kind of syntax of the object we use to study bidirectional communication Is what's known as bidirectional channels, which were introduced recently by Marcel and Portering In particular, it consists of three algorithms, first an initialization algorithm, which gives the initial state to both Alice and Bob The sending algorithm, given that state, a message and some associated data produces a ciphertext Then if we give the same associated data and the ciphertext to the other user, they can decrypt and recover the same message Because communication is bidirectional, we want our primitive to work in both directions And furthermore, we need our correctness to be maintained, even if ciphertexts happen to cross each other on the wire We wanted to approach this idea of kind of the best achievable security notion in a somewhat principled manner So in particular, how we started that process was by defining just a very general interface of how an attacker is able to interact with the channel In particular, this consists of a couple of oracles, a sending and receiving oracles where you can ask either of the parties to send a message or receive a ciphertext And then we augment this with an exposure oracle where you can act to be given the current secret state of either of the two users And a particular point to note here is that the secret state may include the randomness that is being used by one of the users If they're in the middle of performing one of these two operations With that in mind, the goal of the adversary with its complete control of the communication is to tell either which of two messages was encrypted in a typical left or right notion Or to forge a new ciphertext to either of the parties The next process in obtaining our final security definition was understanding some generic attacks In the interface as I just defined it, there are attacks which will breach the security of any channel So we specify eight different classes of such attacks Some examples of this include that if I expose the state of one of the users, I'm necessarily able to forge a message to the other user Given the state of a user, I can necessarily decrypt the next ciphertext that's supposed to receive a slightly more complicated one If I expose the sending randomness together with the state of a user, I should be able to decrypt or tell what the next message is sent was To kind of understand what's happening here, it's worth also pointing out some attacks which are not prevented Which are not generic attacks and thus we want to prevent These include that if I steal the state of a user, I should not be able to forge a message to that same user or to read any ciphertext that was sent by that user So given these generic attacks, the kind of final step in defining our security notion is that we augmented the interface to obtain what we called authenticated encryption against compromise or AEAC Where we just minimally added restrictions that those particular generic attacks are not allowed, any other attacks are valid Some implications of what we're requiring then include the two I just mentioned in addition that after a user has decrypted the ciphertext Exposing their state should no longer allow you to read what was in that ciphertext After a user has sent a ciphertext, exposing their state shouldn't let you change what that ciphertext said Or more subtle attacks where if I'm able to forge a message to one of the users by exposing the state of the other user The state of that other user after receiving the forged ciphertext should no longer be useful in performing any attacks on the first user Very roughly these different implications are achieved with the new forms of digital signatures and public key encryption that we define So let me talk briefly about those First, key-updatable digital signatures We start with our standard syntax of assigning and verification oracle And then we add two algorithms for updating both of the keys with respect to some arbitrage string delta How this update should work is that if two keys are updated with the same sequence of deltas they should work together Otherwise the keys should no longer work with each other For security we defined a variant of strong unforgeability Where in addition to the usual signing algorithm given to attacker there's an update algorithm oracle Which will update the secret key with an attacker chosen delta And an exposure oracle which gives the current secret key back to the attacker Their goal is to create a forgery with the obvious restriction that we prevent trivial attacks of exposing a signing key Maybe updating it a few times and then just signing your own message To construct this we were able to do so from any normal forward secure digital signatures Kind of the only difference of this new primitive is that our updates need to happen with respect to delta And the way we kind of incorporate into that into the update is before you retake your key forward You first sign delta with your old key And then that signature will be included in future signatures Next our public key encryption Again we take normal public key encryption this time public key encryption with labels And we add algorithms for updating the encryption and decryption key with respect to delta This works kind of in the same way For security our definition was a variant of CCA security Where we add two oracles for updating the keys with respect to an attacker chosen delta And an oracle which gives back the current decryption key Again we have the same sort of trivial restriction that you can't do the obvious attacks by exposing a decryption key And then using that to decrypt a challenge psychotext The construction of this is actually somewhat straightforward from hierarchical identity based encryption If you kind of look carefully at what we defined What we really defined is a special case of hibes Where the deltas correspond to parts of the identity we're updating And we just take a single path down the hybrid tree So like I said we can then combine these two primitives together with a collision visits and hash function To ultimately obtain the channel that we want At a high level the state will be storing at any particular time as a counter The public keys for both of our types of primitives The private keys including possibly multiple decryption keys And then also transcripts of the messages we've sent to the other party And transcripts of what we've received from the other party together with of course our hash function key The construction which I'm not expecting you to read this pseudo code in detail But at a very kind of high level what we did is that the public key encryption provides the privacy The integrity comes from the digital signature scheme The kind of first main part of how we're achieving the forward and backward security Is that with every psychotext we send we're going to include new encryption and verification keys For key pairs that we just generated A more complicated part of the forward security is what we're achieving with the key updates In particular we're updating the public parts of our keys with the transcripts of what we've sent to the other user We're updating the secret parts with the transcripts we've received And the sorts of attack which are being prevented by these key updates Are the ones I talked about where if I expose one user state use that to send a forgery to the other user The other user state should no longer be useful in breaching security of the first user That's somewhat complicated attacks are what the key updates really are preventing Then finally the counter just prevents simple sort of reordering attacks In our paper to provide some intuition for all of the kind of fine details of how our construction worked We provide nine different attacks against small variants of our construction Which show why the security would be lost if we had done things kind of slightly differently in a number of ways Finally a construction is not very useful without a proof of security We proved that our channel is secure under kind of the expected security notions We've been discussing together with a notion of uniqueness for the digital signature scheme Clearly this proof consisted of a tight reduction from AEAC to multi-user versions of the underlying security notions The kind of multi-user security notions arise quite naturally because we're sampling new key pairs with every attack we send Very roughly we can divide the proof into two steps First we need to do a couple arguments so that we can show that the integrity holds and then we move on to privacy The first step is actually a somewhat subtle one which has been missed by some of the related work The terms are slightly false which is that as the first step we have to argue that future ciphertexts cannot be predicted beforehand Which we do by simple just min entropy of the various algorithms involved Next we use the hash function to say that transcripts and our collisions won't occur Collisions in the transcripts would allow some trivial attacks Once we've ruled out those possibilities then we can directly use the digital signature to argue that the integrity part holds One final step before we use our public encryption We need to use the uniqueness of the digital signature to argue that an adversary can't take a ciphertext And just switch the signature part of it and leave the rest the same And then we use the public encryption Thank you, any questions?