1 / 46

Message Franking: Invisible Salamanders, Encryptment , and AMFs

Message Franking: Invisible Salamanders, Encryptment , and AMFs. Paul Grubbs Joint work with Jiahui Lu, Thomas Ristenpart , Yevgeniy Dodis , Joanne Woodage , Nirvan Tyagi , Ian Miers , and Julia Len. End-to-end encrypted messaging. Message. Message. Encryption. Service provider.

hnicholson
Download Presentation

Message Franking: Invisible Salamanders, Encryptment , and AMFs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Message Franking: Invisible Salamanders, Encryptment, and AMFs Paul Grubbs Joint work with Jiahui Lu, Thomas Ristenpart, YevgeniyDodis, Joanne Woodage, NirvanTyagi, Ian Miers, and Julia Len

  2. End-to-end encrypted messaging Message Message Encryption Service provider End-to-end (E2E) security: Provider cannot read or modify messages

  3. Providers want to help users with abuse !%$#! !%$#! Encryption He said !%$#! Service provider End-to-end (E2E) security: Provider can’t tell if “!%$#!” was sent Tension between E2E security and functionality

  4. Overview First formalization and analysis of E2EE content moderation, study Facebook’s “message franking” Show vulnerability in message franking Introduce new symmetric-key primitives: compactly committing AE (ccAE) and encryptment Introduce new public-key primitive: asymmetric message franking https://eprint.iacr.org/2017/664 https://eprint.iacr.org/2019/016 Not online yet [G., Lu, Ristenpart– Crypto 2017] [Dodis, G., Ristenpart, Woodage– Crypto 2018] [Tyagi, G., Len, Miers, Ristenpart–Crypto 2019]

  5. Overview First formalization and analysis of E2EE content moderation, study Facebook’s “message franking” Show vulnerability in message franking Introduce new symmetric-key primitives: compactly committing AE (ccAE) and encryptment Introduce new public-key primitive: asymmetric message franking https://eprint.iacr.org/2017/664 https://eprint.iacr.org/2019/016 Not online yet [G., Lu, Ristenpart– Crypto 2017] [Dodis, G., Ristenpart, Woodage– Crypto 2018] [Tyagi, G., Len, Miers, Ristenpart–Crypto 2019]

  6. Background on Message Franking !%$#! !%$#! Service provider [Facebook 2016]: Moderation for E2EE Secret Conversations via cryptographic proof of msg contents. Called technique message franking [Frosch et al. 2014] [Cohn-Gordon et al. 2016] [Bellare et al. 2017] [Jaeger and Stepanovs 2018] [Coretti et al. 2019] Lots of academic work on E2EE chat, but not E2EE + moderation. Many questions arise…

  7. E2EE content moderation !%$#! !%$#! !%$#!, π Service provider 0/1=Verify(!%$#!, π) Proof !%$#! was received If proof verifies, take action against sender (block/ban)

  8. Security for E2EE content moderation !%$#! !%$#! !%$#!, π Service provider 0/1=Verify(!%$#!, π) Proof !%$#! was received If proof verifies, take action against sender (block/ban) 1)Receiver can’t report a message not sent 2) Can’t send a message that can’t be reported 3) Confidentiality for unreported messages 4) Only service provider can verify reports

  9. Facebook’s message franking protocol CB , TFB CB KB , !%$#! KB , !%$#! Service provider Sender commitsto message: CB = HMAC(KB ,M) Encrypt-then-HMAC message along with opening KB Provider signs CBusing HMAC to generate tag TFB (fast because CB short) Receiver decrypts, retrieves KB, and verifies CB

  10. Facebook’s message franking protocol CB , TFB CB KB , !%$#! KB , !%$#! KB,!%$#! , CB , TFB Service provider CB=HMAC(KB, !%$#!) CB=?HMAC(KB, !%$#!) TFB=HMAC(KFB,md,CB) To report abuse, send message as well as KB, CB , TFB Provider can verify CB ,TFB ,convinced that message was “ !%$#! ” Attachments (images, videos) handled differently. URL content not reportable Is Facebook’s approach secure? [GLR17]: without attachments, yes [DGRW18]: with attachments, no!

  11. Security of message franking CB , TFB CB KB , !%$#! KB , !%$#! KB,!%$#! , CB , TFB Service provider CB=HMAC(KB, !%$#!) CB=?HMAC(KB, !%$#!) TFB=HMAC(KFB,md,CB) CB commits, TFB contains identities 1)Receiver can’t report a message not sent 2) CB is verified by receiver 2) Can’t send a message that can’t be reported 3) Confidentiality for unreported messages 3) AE security 4) Only service provider can verify reports 4) only FB knows TFB HMAC key

  12. Security of message franking CB , TFB CB KB , !%$#! KB , !%$#! KB,!%$#! , CB , TFB Service provider CB=HMAC(KB, !%$#!) CB=?HMAC(KB, !%$#!) TFB=HMAC(KFB,md,CB) Attack creates attachment that can’t be reported as abusive 1)Receiver can’t report a message not sent 2) Can’t send a message that can’t be reported 3) Confidentiality for unreported messages 4) Only service provider can verify reports

  13. Facebook’s attachment franking protocol CB , TFB CB KB , Kfile KB , Kfile file file Service provider Sender commitsto attachment key: CB= HMAC(KB, Kfile) Encrypt-then-HMAC file encryption key Kfile along with KB AES-GCM encrypt attachment: AES-GCM( Kfile, file ) Receiver decrypts as before to get Kfileand then decrypts attachment

  14. Facebook’s attachment franking protocol CB , TFB CB KB , Kfile KB , Kfile file file Service provider K , Kfile , CB , TFB To report abuse, receiver opensKfileand other recent messages Facebook checks openings & decrypts all unique AES-GCM ciphertextsto add them to abuse report

  15. Facebook’s attachment franking protocol CB , TFB CB KB , Kfile KB , Kfile file file Service provider C2B C2B ,T2FB KB2 , Kfile2 KB2, Kfile2 file2 file2 KB, Kfile , CB , TFB KB2, Kfile2 , C2B , T2FB To report abuse, receiver opensKfileand other recent messages Facebook checks openings & decrypts all unique AES-GCM ciphertextsto add them to abuse report

  16. Our attack exploits AES-GCM CB , TFB CB KB , Kfile KB , Kfile file file Service provider C2B C2B ,T2FB KB2 , Kfile2 KB2, Kfile2 file file 3.receiver sees both 2. Send ciphertext twice - Kfile,Kfile2 KB, Kfile , CB , TFB KB2, Kfile2 , C2B , T2FB 4. Only the innocuous image appears in report to Facebook! • 1.Craft special AES-GCM ciphertext: • Decrypts under Kfileto innocuous image • Decrypts under Kfile2 to abuse image

  17. Our attack exploits AES-GCM Craft special AES-GCM ciphertext: Decrypts under Kfileto innocuous image Decrypts under Kfile2 to abuse image But isn’t AES-GCM a secure authenticated encryption scheme? Yes, but ... this type of attack is not standard attacker gets to choose Kfileand Kfile2 GCM uses a universal-hash-based MAC not collision resistant (CR) Our attack violates robustness: can find ciphertextthat decrypts under two keys (First robustness attack against real system) [Abdalla, Bellare, Neven 2010] [Farshim et al. 2013] [Farshim et al. 2017]

  18. Abusive JPEG seen by receiver, but not in abuse report Innocuous BMP in abuse report Disclosed to Facebook Thanks to Jon Millican for answering questions! They fixed by changing report generation logic Awarded us a bug bounty

  19. A brief interlude: sender keys In current messaging applications, sender keys pattern is common to reduce bandwidth (Whatsapp, e.g.)

  20. A brief interlude: sender keys In current messaging applications, sender keys pattern is common to reduce bandwidth (Whatsapp, e.g.) Robustness issues can lead to attack* where different group members get different plaintexts from a ciphertext

  21. A brief interlude: sender keys In current messaging applications, sender keys pattern is common to reduce bandwidth (Whatsapp, e.g.) Robustness issues can lead to attack* where different group members get different plaintexts from a ciphertext *not clear what consistency guarantees are desired… still seems weird

  22. A brief interlude: sender keys In current messaging applications, sender keys pattern is common to reduce bandwidth (Whatsapp, e.g.) Robustness issues can lead to attack* where different group members get different plaintexts from a ciphertext Credit for this observation goes to KatrielC-G, who pointed it out to me last year at Oxford *not clear what consistency guarantees are desired… still seems weird

  23. How could the attack have been prevented? CB , TFB CB KB , !%$#! KB , !%$#! KB,!%$#! , CB , TFB Service provider Record layer is short commitment + AE. [GLR] formalized primitive: compactly committing AE (ccAE) We analyzed several ccAE, proved FB’s secure FB used GCM for attachments: much faster than franking Signal uses AES-CBC then HMAC for AE FB needs 3 passes (HMAC-Encrypt-HMAC) Fixes sender keys issue as well How do we build fast ccAE?

  24. Overview First formalization and analysis of E2EE content moderation, study Facebook’s “message franking” Show vulnerability in message franking Introduce new symmetric-key primitives: compactly committing AE (ccAE) and encryptment Introduce new public-key primitive: asymmetric message franking https://eprint.iacr.org/2017/664 https://eprint.iacr.org/2019/016 Not online yet [G., Lu, Ristenpart– Crypto 2017] [Dodis, G., Ristenpart, Woodage– Crypto 2018] [Tyagi, G., Len, Miers, Ristenpart–Crypto 2019]

  25. How do we build fast ccAE? Ideally:~1 blockcipher call per msg block. Can any secure scheme achieve this? No! Thm. Secure ccAE => CR hashing. Leverage prior impossibility results for CR hashing from fixed-key blockciphers [Black, Cochran, Shrimpton 2005] [Rogaway, Steinberger 2008] No similar ccAE scheme can be secure!

  26. How do we build fast ccAE? New primitive: encryptment “one-time” ccAE Step 1 Hash-Function-Chaining(HFC) scheme + Encryptment-to-ccAE transform from compression function Simple transforms from encryptment to ccAE Step 2 ccAE in one SHA-256 call

  27. Encryptment: syntax, semantics, security Should be short: e.g. 256 bits EC(K, M) = C1, CB encrypts and commits to M DO(K, C1,CB) = M/ decrypts (C1, CB) and opens to M EVer(M, K , CB) = 0/1 verifies commitment CB of M Confidentiality: can’t distinguish ciphertexts from random bits Second-ciphertextunforgeability(SCU): can’t forge ciphertexts in particular way Receiver binding: can’t generate K,M pairs that verify for same CB Sender binding: can’t decrypt ciphertext that doesn’t verify properly

  28. The hash-function chaining (HFC) scheme Recall Merkle-Damgard style hash functions (e.g., SHA-256) built in two steps: Specify a compression function f: {0,1}n x {0,1}d -> {0,1}n Iterate f to hash long message (after some suitable padding) M1 M2 M3 M4 IV F(M) (IV is a constant)

  29. Security of HFC Confidentiality SCU (integrity) Receiver binding Sender binding HFC’s security as encryptment follows from fiddly but (mostly) standard analyses. See eprint 2019/016 for details K K⨁M1 K⨁M2 K⨁M3 IV CB M1 M3 M2 (IV is a constant) Ca Cc Cb

  30. How do we build fast ccAE? New primitive: encryptment “one-time” ccAE Step 1 Hash-Function-Chaining(HFC) scheme + Encryptment-to-ccAE transform from compression function Simple transforms from encryptment to ccAE Step 2

  31. (Fast) Encryptment=> (Fast) ccAE Construct fast ccAE from fast encryptment: 2 additional compression function calls 1. Use long-term key Klt 2. Derive encryptment key via 3. MAC the binding tag CB Klt R K K⨁M1 K⨁M2 K⨁M3 Klt IV CB T M1 M3 M2 Ca Cc Cb

  32. (Fast) Encryptment=> (Fast) ccAE Construct fast ccAE from fast encryptment: 2 additional compression function calls Thm. If EC is a secure encryptment scheme and compression function is PRF, this construction is ccAE Encryptment is usefulelsewhere, gives single-pass: - concealments [DH03] - remotely-keyed AE [BFN98] - robust AE [FOR17] See paper for details

  33. Overview First formalization and analysis of E2EE content moderation, study Facebook’s “message franking” Show vulnerability in message franking Introduce new symmetric-key primitives: compactly committing AE (ccAE) and encryptment Introduce new public-key primitive: asymmetric message franking https://eprint.iacr.org/2017/664 https://eprint.iacr.org/2019/016 Not online yet [G., Lu, Ristenpart– Crypto 2017] [Dodis, G., Ristenpart, Woodage– Crypto 2018] [Tyagi, G., Len, Miers, Ristenpart–Crypto 2019]

  34. Metadata-Private Messaging Alice Bob !%$#! !%$#! Service provider SP knows Alice sent something to Bob E2EE does not hide communication metadata.

  35. Metadata-Private Messaging Alice Bob !%$#! !%$#! Service provider SP knows someonesent something to Bob E2EE does not hide communication metadata Metadata-private: messages and communication metadata both hidden Signal’s new “sealed sender” feature: hide sender of message FB’s message franking cannot work in metadata-private settings

  36. Message Franking without Metadata Alice Bob CB ,TFB CB KB , !%$#! KB , !%$#! KB,!%$#! , CB ,TFB Service provider TFB = HMAC(KFB, Alice||Bob||CB) To authenticate report Facebook needs TFB TFB is computed using sender and receiver identities

  37. Message Franking without Metadata Alice Bob CB ,TFB CB KB , !%$#! KB , !%$#! KB,!%$#! , CB ,TFB Service provider TFB = HMAC(KFB, ???||Bob||CB) To authenticate report Facebook needs TFB TFB is computed using sender and receiver identities Without metadata Facebook’s scheme fails – Bob can report anyone Other purely symmetric-key approaches fail: need asymmetric message franking

  38. Asymmetric Message Franking, take 1 Alice Bob !%$#!, σ !%$#!, σ !%$#!, σ Service provider (pkA , skA ) (pkB , skB ) 0/1 <- Ver(pkA , !%$#!, σ) σ <- Sign(skA , !%$#!) 0/1 <- Ver(pkA , !%$#!, σ) Check report with Ver Verify signature during decryption Sign plaintext, encrypt signature and plaintext One seeming solution is standard digital signatures. With PKI, can use signature scheme (Sign, Ver) as follows.

  39. Asymmetric Message Franking, take 1 Alice Bob !%$#!, σ !%$#!, σ !%$#!, σ Service provider (pkA , skA ) (pkB , skB ) 0/1 <- Ver(pkA , !%$#!, σ) σ <- Sign(skA , !%$#!) 0/1 <- Ver(pkA , !%$#!, σ) Check report with Ver Verify signature during decryption Sign plaintext, encrypt signature and plaintext One seeming solution is standard digital signatures. With PKI, can use signature scheme (Sign, Ver) as follows. Service provider does not need metadata, nor does it need to be inline (third-party moderation)

  40. Asymmetric Message Franking, take 1 Alice Bob !%$#!, σ !%$#!, σ !%$#!, σ Service provider (pkA , skA ) (pkB , skB ) 0/1 <- Ver(pkA , !%$#!, σ) σ <- Sign(skA , !%$#!) 0/1 <- Ver(pkA , !%$#!, σ) unforgeability of signature 1)Receiver can’t report a message not sent 2) sig verified during dec. 2) Can’t send a message that can’t be reported 3) Confidentiality for unreported messages 3) sig encrypted ✖ 4) Only service provider can verify reports

  41. Asymmetric Message Franking Alice Bob !%$#!, σ !%$#!, σ !%$#!, σ Service provider (pkA , skA ) (pkB , skB ) 0/1 <- Ver(pkA , !%$#!, σ) σ <- Sign(skA , !%$#!) 0/1 <- Ver(pkA , !%$#!, σ) Public-key cryptography is required, but can’t use (standard) signatures. Can salvage this approach; new cryptography is needed.

  42. Asymmetric Message Franking Alice Bob !%$#!, σ !%$#!, σ !%$#!, σ Service provider (pkA , skA ) (pkB , skB ) 0/1 <- Ver(pkA , !%$#!, σ) σ <- Sign(skA , !%$#!) 0/1 <- Ver(pkA , !%$#!, σ) Starting point: Schnorr signatures of knowledge. Prime-order group (order q) generated by g. pk = gx, sk = x. Sign(x, M): r <-$ Zq R = gr ; c = H(M || R) ; z = r + cx mod q Return (R,z) NIZKPoK ofR = {x, (g, pk) : pk = gx}

  43. Asymmetric Message Franking Alice Bob !%$#!, σ !%$#!, σ !%$#!, σ Service provider (pkA , skA ) (pkB , skB ) 0/1 <- Ver(pkA , !%$#!, σ) The camera-ready will be online shortly, or wait for Nirvan’s talk at CRYPTO! σ <- Sign(skA , !%$#!) 0/1 <- Ver(pkA , !%$#!, σ) Starting point: Schnorr signatures of knowledge. Prime-order group (order q) generated by g. pk = gx, sk = x. Ending point:

  44. Conclusion Thanks for listening! Any questions? First formalization and analysis of E2EE content moderation, study Facebook’s “message franking” Show vulnerability in message franking Introduce new symmetric-key primitives: compactly committing AE (ccAE) and encryptment Introduce new public-key primitive: asymmetric message franking https://eprint.iacr.org/2017/664 https://eprint.iacr.org/2019/016 Not online yet [G., Lu, Ristenpart– Crypto 2017] [Dodis, G., Ristenpart, Woodage– Crypto 2018] [Tyagi, G., Len, Miers, Ristenpart–Crypto 2019]

  45. AMF Accountability and Deniability

More Related