Hunting Invisible Salamanders: Cryptographic (in)Security with Attacker-Controlled Keys Paul Grubbs Cornell Tech, New York University, University of Michigan
1 About Me
Now: PhD student in Next fall: starting This fall: starting Computer Science at as junior professor postdoc at NYU Cornell’s NYC campus at Michigan EECS
2 This Talk
Intended audience: those who design, implement, and use cryptography. Others will find talk interesting and enjoyable but may lack some context.
This is a talk about cryptography. This symbol: if you don’t understand Some of the slides involve math. all the details, don’t worry about it!
3 Authenticated Encryption
Cat Picture ???
Agree on random key Encrypt message with using authenticated encryption (AE) (Galois/Counter Mode, Chacha20/Poly1305) If key is random + hidden: AE hides cat pictures, Core of protocols prevents modifications like TLS, IPSec, SSH
4 New Settings, New Needs
Attacker Message
Attacker chooses key(s) Encrypt message with using authenticated encryption (AE) (Galois/Counter Mode, Chacha20/Poly1305) Key isn’t random + hidden! What security do we need? Increasingly important setting for AE: What security do we expect? • Password-Based Encryption/PAKE • E2EE Group Messaging • Abuse Reporting in Encrypted Messaging
5 Overview
Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks
Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 6 Overview
Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks
Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 7 Attacker-Controlled Keys
Cat Picture
is hidden, has Try to learn message or lots of randomness change decryption output
Attacker Message
Message and encryption key both chosen by adversary
8 Example: Password-based AE
They’re using password1! Guess Can’t decrypt!
123 … password1 456
Guess
password1 Decryption succeeded!
If attacker doesn’t Brute-force feasible if key is not very random know decryption key, (e.g. password/PIN) or if side channel leaks key bits can learn using (online) brute-force attack
9 Example: Reporting Plaintexts
Can’t let the auditor see records… Fraudulent Records
AE.Decrypt( , Fraudulent Records ) Auditor Decrypt outputs something other than fraudulent records Attacker chooses encryption and decryption key: tries to lie about ciphertext contents
10 Committing Security for AE Useful to imagine AE as a lockbox Intuition holds for hidden random key: ??? • Can’t see inside (confidentiality) • Can’t change contents (integrity) No matter the key, only one thing can come out when it’s unlocked
11 Committing Security for AE Useful to imagine AE as a lockbox Intuition holds for hidden random key: Committing security binds attacker • Can’t see inside (confidentiality) to a single AE decryption, prevents • Can’t change contents (integrity) invisible salamanders in ciphertexts Without this, AE lockboxes could unlock many ways…
12 Reporting Salamanders
Committing AE
Committing AE AE.Decrypt( , ) Auditor Decrypt fails - can’t report salamanders If AE is committing, attacker can’t lie about plaintext by choosing different key
13 Overview
Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks
Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 14 Invisible Salamanders for CTR Mode
Plaintext ⨁ Pad Derive Pad = IV Ciphertext Derive Pad’ ⨁ Pad’ =
Plaintext’
15 Galois/Counter Mode (GCM) Input GCM is a fast, modern AE. NIST/IEEE/ISO standard Message Uses AES-CTR + message authentication code (MAC) to prevent tampering AES-CTR MAC Decryption recomputes, checks tag, fails if tags do not match Output IV Message Tag To get invisible salamanders for GCM, need to find IV Message with same MAC output Tag for and AES-CTR MAC
Salamander Input
16 Colliding GCM’s MAC MAC is polynomial evaluation + XOR. Fast but not collision-resistant (cf. SHA-256) IV
1. Split ciphertext into blocks (coefficients) MAC( , IV ): 1. C1 = Blocks( ) 2. Compute hash point (H) and pad (Pad) H = AES( , 0) 2. 3. Evaluate polynomial at H, then XOR Pad Pad = AES( , IV ) 2 (‘len’ is encoded ciphertext length) 3. Tag = C1*H + len*H + Pad
Tag
17 Colliding GCM’s MAC Tag is a “simple” algebraic function of ciphertext: solve one equation to collide for two keys IV
1. Choose any IV MAC( , IV ): 2. For key , derive H1, Pad1 C1 = Blocks( ) H = AES( , 0) 3. For key , derive H2, Pad2 Pad = AES( , IV ) 4. Set tag equations equal, solve for C : 2 1 Tag = C1*H + len*H + Pad 2 C1*H1 + len*H1 + Pad1 2 Tag = C1*H2 + len*H2 + Pad2 Not true for collision-resistant
Message Tag hashes like SHA-256 5. Let be C1 , recompute 6. Output IV Message Tag
2 2 C1*(H1 + H2 ) = len*(H1 + H2) + Pad1 + Pad2 2x = 6 One equation, 2 2 -1 one unknown! C1 = [len*(H1 + H2) + Pad1 + Pad2]*(H1 + H2 ) x = 3
18 From Two Keys to Many Colliding GCM’s MAC on two keys is pretty easy. Can even collide many (>>2) keys: use interpolation IV