Invisible Salamanders & Fast Message Franking

Invisible Salamanders & Fast Message Franking YevgeniyDodis, Paul Grubbs, Tom Ristenpart, Joanne Woodage

End-to-End Encrypted Messaging Message Message Authenticated Encryption Service provider End-to-end security: Provider cannot read or modify messages Desirable in terms of privacy, fears of mass surveillance etc…. …but what about abuse reporting?

Reporting Abuse !%$#! !%$#! Authenticated Encryption He said !%$#! Service provider End-to-end security means cannot verify “ !%$#! ” was message sent

Reporting Abuse   He said !%$#! Service provider Unverifiable abuse reporting can be abused by both sender and receiver In 2016, Facebook introduce message frankingin Secret Conversations Aims to provide a cryptographic proof of message contents that can be verified by service provider to facilitate abuse reporting Subject of talk by Jon Millican at RWC 2017

Talk Outline • What is message franking? • Facebook & invisible salamanders • Our solution for fast message franking

Message Franking Syntax [GLR17] Message franking scheme = Encryption scheme + verification algorithm Binding Tag Ciphertexts have two components Enc(K, M) C1 C2 = (C1, C2) = Encryption of message M C2 = Commitment to message M (which will be checked using the verification algorithm) Decryption of (C1, C2) reveals message M plus verification key Kf Ver(Kf, M’, C2) = true? Verification algorithm uses Kf to check if some claimed message M’ really underlies C2 • Commitment : • - Users who know key Kfcan check if message M really underlies commitment • - Without key, commitmentreveals nothing about message contents Compactness requirement : want C2 to be ‘short’ and independent of length of underlying message.

Message Franking Security Encryption satisfies the usual confidentiality and integrity guarantees, even if the attacker can learn the verification keys for some ciphertexts Binding tag and Vershould be such that if a ciphertext decrypts correctly, then a sender cannot deny its contents… …and a receiver can never lie about the message underlying the binding tag Compactness – for efficiency reasons, we want binding tag C2 to be short

Facebook’s Message Franking Scheme (C1, C2) (C1, C2), Tfb C2 = HMAC(Kf,M) (M, Kf) = Dec(K, C1,C2) Facebook compute MAC over C2, tag Tfb C2 == HMAC(Kf, M)? C1 = Enc(K, M, Kf) FB-Dec FB-Enc Sender encrypts with FB-Enc: 1. Choose verification key Kf 2. Set binding tag C2 = HMAC(Kf,M) 3. Encrypt verification key Kf& message M with encrypt-then-MAC AEAD scheme Receiver decrypts with FB-Dec: 1. Decrypt (C1, C2) to recover M, Kf 2. Verify commitment Good : [GLR17] prove this is a secure message franking scheme  Not so good : Slow compared to regular authenticated encryption, and requires three passes over data for sender to encrypt  Because of this lack of efficiency, Facebook handle attachments differently… To report an abusive message: 1. Receiver sends (M, Kf, Tfb) to Facebook 2. Facebook re-computes the commitment C2 = HMAC(Kf, M) -& verifies Tfb If this process succeeds, the provider is satisfied the claimed message was actually sent. Receiver decrypts with FB-Dec: 1. Decrypts C1 to recover M, Kf 2. Verifies commitment

Facebook’s Message Franking Scheme (C1, C2) (C1, C2), Tfb !%$#!, C2, Kf, Tfb (M, Kf) = Dec(K, C1,C2) C2 == HMAC(Kf, M)? Verification algorithm FB-Ver C2== HMAC(Kf,!%$#!)? Good : [GLR17] prove this is a secure message franking scheme  Not so good : Slow compared to regular authenticated encryption - requires three passes over data  Because of this lack of efficiency, Facebook handle attachments differently… Verify Tfb To report an abusive message: 1. Receiver sends message plus binding tag C2, verification key Kf, and Tfb to Facebook 2. Verifies binding tag commitment (and Facebook tag Tfb). Good : [GLR17] prove this is a secure message franking scheme  Not so good : Slow compared to regular authenticated encryption, and requires three passes over data for sender to encrypt  Because of this lack of efficiency, Facebook handle attachments differently… To report an abusive message: 1. Receiver sends (M, Kf, Tfb) to Facebook 2. Facebook re-computes the commitment C2 = HMAC(Kf, M) -& verifies Tfb If this process succeeds, the provider is satisfied the claimed message was actually sent. Receiver decrypts with FB-Dec: 1. Decrypts C1 to recover M, Kf 2. Verifies commitment

Facebook’s Attachment Franking Cfile, (C1, C2) Cfile, (C1, C2), Tfb Kfile= FB-Dec(K, C1, C2) Cfile = GCM-Enc(Kfile,M) Attacker can send abusive attachment which cannot be reported to Facebook M = GCM-Dec(Kfile, Cfile) (C1, C2) = FB-Enc(K, Kfile) Sender: 1. Choose one-time file key Kfileand encrypt file with AES-GCM – fast! 2. Use franking algorithm FB-Encto encrypt and commit to Kfile - less effort to frank! 3.Send Cfile, C1, C2 plus Facebook tag Tfb to receiver 1. GCM is not a secure franking scheme. Moreover, it is not robust [ABN10], [FLQP13], [FOR17] – easy to construct a ciphertext that decrypts validly under different keys 2. Abuse reporting: Facebook checks allrecently received GCM encrypted attachments – but only uniqueciphertexts logged in abuse report

The Attack Step 1: Attacker constructs special GCM ciphertext C* which decrypts to innocuous attachment under key Kand abusive attachment under key K C*, Kfile GCM-Dec(Kfile, C*)  = C*, Kfile GCM-Dec(Kfile, C*) !%$#! = Step 2: Attacker sends C* to victim twice, first with innocuous key and second the abusive key Due to de-duplication, the abusive message never gets added to the abuse report! Isn’t AES-GCM a secure AEAD scheme…? Yes but this is not the standard AEAD setting – the attacker can choose both keys used in the attack! Exploits fact that AES-GCM is not robust (perhaps first real-world attack of this kind) 1. GCM is not a secure franking scheme, and is not robust [ABN10], [FLQP13], [FOR17] – easy to construct a ciphertext that decrypts validly under different keys 2. Abuse reporting: Facebook checks all recently received AES-GCM encrypted attachments – but only uniqueciphertexts logged in abuse report 1. GCM is not a secure franking scheme, and is not robust [ABN10], [FLQP13], [FOR17] – easy to construct a ciphertext that decrypts validly under different keys 2. Abuse reporting: Facebook checks all recently received AES-GCM encrypted attachments – but only uniqueciphertexts logged in abuse report 1. GCM is not a secure franking scheme, and is not robust [ABN10], [FLQP13], [FOR17] – easy to construct a ciphertext that decrypts validly under different keys 2. Abuse reporting: Facebook checks all recently received AES-GCM encrypted attachments – but only uniqueciphertexts logged in abuse report Receiver decrypts with FB-Dec: 1. Decrypts C1 to recover M, Kf 2. Verifies commitment

Invisible Salamanders …but when the receiver tries to report it, all Facebook sees in the abuse report is this cute kitten Facebook Messenger source code refers to encrypted messages as salamanders Disappearing message = an invisible salamander (axolotl)  We show that you can send this ‘abusive’ image in Facebook Secret Conversations… Facebook remediated the vulnerability and rewarded a bug bounty. Thanks to Jon Millican for answering many questions! Full attack details in the paper!

Can a Secure Message Franking Scheme be as Fast as Regular AEAD? • Can we build secure message franking schemes • which match the efficiency of GCM & OCB? • -Single pass • -One block cipher call per block of input Both the answer to this question, and the idea behind our construction lie in collision-resistant hashing… Key observation : the function which computes the binding tag must be collision-resistant Binding tag computation M (How can we be sure which message really underlies the binding tag?) C2 M’

Impossibility Result Bad news : Known impossibility results [BCS05], [RS08] rule out wide class of efficient block cipher-based franking schemes which match the efficiency of OCB and GCM in block cipher calls per message block  Good news: We can adapt the classic Merkle-Damgard hash function to build the first single-pass secure message franking scheme! 

Hash Function Chaining Scheme (HFC) Recall Merkle-Damgard style hash functions built in two steps: 1. Specify a compression function f: {0,1}n x {0,1}d -> {0,1}n 2. Iterate f to hash long message (after some suitable padding) M1 M2 M3 IV C2 17 MD-hash function is CR provided compression function f is CR and suitable padding scheme is used

Hash Function Chaining Scheme (HFC) Our scheme: 1. XOR key into each block 2. Apply MD-hash function to compute binding tag K K⨁M1 K⨁M2 K⨁M3 We prove that this gives a one-time secure variant of message franking (assuming f is CR and a PRF satisfying a weak-form of RKA-security). We then givesimple & efficient transforms which lift our scheme to multi-use message franking  (Full details and proofs in paper!) Binding tag IV C2 M1 M3 M2 Ciphertext blocks C1 C3 C2 Trick!- Reuse intermediate chaining variables as random pads for encryption Compute binding tag andciphertext in single pass over data. For certain parameter settings, incurs no additional overhead over just computing the MD hash function binding tag! 

Thank you! Paper : Message Franking:From Invisible Salamanders to Encryptment – Dodis, Grubbs, Ristenpart, Woodage presented at CRYPTO 2018, full version appearing on ePrintvery soon!

Invisible Salamanders & Fast Message Franking