New Encryp+on Primi+ves for Uncertain Times Thomas - PowerPoint PPT Presentation

New ¡Encryp+on ¡Primi+ves ¡for ¡ Uncertain ¡Times ¡ Thomas ¡Ristenpart ¡ University ¡of ¡Wisconsin ¡ Covering ¡joint ¡work ¡with: ¡ ¡ Sco@ ¡Coull, ¡Kevin ¡Dyer, ¡Ari ¡Juels, ¡Thomas ¡Shrimpton ¡

Security ¡in ¡our ¡uncertain ¡+mes: ¡ "Encryp+on ¡works. ¡Properly ¡implemented ¡strong ¡ crypto ¡systems ¡are ¡one ¡of ¡the ¡few ¡things ¡that ¡ ¡ you ¡can ¡rely ¡on." ¡ -­‑ ¡Edward ¡Snowden, ¡May ¡2013 ¡ ¡

Some ¡failures ¡of ¡symmetric ¡encryp+on: ¡1970s ¡– ¡today ¡ ¡ M ¡ Example ¡1: ¡primi-ve ¡failure ¡ E K ¡ -­‑ ¡DES ¡with ¡56-­‑bit ¡keys ¡ -­‑ ¡RC4 ¡plaintext ¡recovery ¡a@acks ¡ [Paterson, ¡Poe@ering, ¡ ¡ Schuldt ¡14] ¡ C ¡ M2 ¡ M1 ¡ IV ¡ Example ¡2: ¡ac-ve ¡a3ack ¡failures ¡ -­‑ ¡CBC ¡mode ¡ [Vaudenay ¡02, ¡…] ¡ [Rizzo, ¡Duong ¡11] ¡ E K ¡ E K ¡ [Alfarden, ¡Paterson ¡13] ¡ ¡ -­‑ ¡MAC-­‑then-­‑Encrypt ¡ [Paterson, ¡R., ¡Shrimpton ¡12] ¡ [Degabriele, ¡Paterson ¡10] ¡ C0 ¡ C1 ¡ C2 ¡ Early ¡release ¡of ¡plaintext ¡ Power, ¡+ming, ¡access-­‑driven ¡ ¡ side ¡channel ¡a@acks ¡ Backdoors ¡in ¡PRNGs ¡

Solving ¡all ¡ those ¡problems ¡won’t ¡directly ¡ help ¡ censorship ¡vic,ms ¡and ¡ LastPass ¡users ¡ Deep ¡packet ¡inspec+on ¡systems ¡can ¡block ¡protocols ¡ Ciphertexts ¡don’t ¡“look ¡like” ¡benign ¡ traffic ¡to ¡network ¡monitors ¡ LastPass ¡uses ¡password-­‑based ¡encryp+on ¡that ¡can ¡be ¡cracked ¡ Decryp+on ¡reveals ¡when ¡wrong ¡key ¡is ¡used ¡ Tradi+onal ¡approach: ¡ ¡punt ¡on ¡such ¡problems ¡to ¡systems ¡security ¡ Our ¡approach: ¡ ¡new ¡symmetric ¡encryp-on ¡primi-ves ¡

Today’s ¡talk ¡ • Part ¡1: ¡ ¡ ¡Format-­‑transforming ¡encryp+on ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡[Dyer, ¡Coull, ¡R., ¡Shrimpton ¡– ¡CCS ¡2013] ¡ • Part ¡2: ¡ ¡ ¡Honey ¡encryp+on ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ [Juels, ¡R. ¡– ¡Eurocrypt ¡2014] ¡ ¡ ¡

Current Estimates of Internet Censorship OpenNet Initiative (ONI), Reporters Without Borders (via wikipedia; updated Jan 6, 2014) Magenta-colored countries are “ internet black holes ” : have heavy censorship of political, social, and news sites, internet tools, etc.

Packet ¡inspec+on ¡and ¡exis+ng ¡countermeasures ¡ payload IP info TCP info “ HTTP: … free+speech … ” Network ¡monitor ¡ A packet can tell you: • source address Use a proxy service, • destination address/port e.g. • application-level protocols • keywords in payloads • …

Packet ¡inspec+on ¡and ¡exis+ng ¡countermeasures ¡ payload IP info TCP info “ HTTP: … free+speech … ” “ TLS… ” ??? … ??? Network ¡monitor ¡ Making payload information A packet can tell you: unhelpful is a new challenge • source address Why ¡not ¡just ¡use ¡standard ¡encryp+on ¡tools? ¡ • destination address/port • application-level protocols Hides ¡the ¡protocol/content ¡ • keywords in payloads inside ¡the ¡encrypted ¡tunnel... ¡ • … But ¡use ¡of ¡the ¡encryp-on ¡ protocol ¡is ¡s-ll ¡visible. ¡

Packet ¡inspec+on ¡and ¡exis+ng ¡countermeasures ¡ I ¡don’t ¡recognize ¡ payload this. ¡Drop ¡it. ¡ ??? … ???? IP info TCP info “ TLS… ” ??? … ??? Network ¡monitor ¡ Making payload information A packet can tell you: unhelpful is a new challenge • source address Why ¡not ¡make ¡ all ¡packet ¡contents ¡random ? ¡ • destination address/port • application-level protocols Used ¡by ¡obfsproxy ¡for ¡Tor ¡ • keywords in payloads • … What happens if DPI allows only whitelisted protocols?

Some previous efforts in DPI Circumvention Stegotorus [Weinberg et al., 2012] , SkypeMorph [Moghaddam et al. 2012] , FreeWave [Houmansadr et al., 2013] , etc. These represent nice steps in the right direction, but 1. Poor performance: 16-256 Kbps reported (best case) 2. Inflexible: not quickly adaptable to changes in DPI rules. e.g. what if you ’ re using SkypeMorph, and Skype becomes blocked? (Ethiopia 2013) 3. Not empirically validated: do they work against real DPI?

Our goal: cause real DPI systems to reliably misclassify our traffic for example: HTTP misclassified as FTP “ HTTP: … free+speech … ” “ This is a benign FTP message. Let it pass. ” ciphertext TCP/IP crypto magic (and in a way that is flexible and has good throughput/low latency…)

Our goal: cause real DPI systems to reliably misclassify our traffic as whatever protocol we want. “ HTTP: … free+speech … ” ciphertext TCP/IP crypto magic (and in a way that is flexible and has good throughput/low latency…)

We took inspiration from Format-Preserving Encryption [Bellare et al., 2009] key crypto a ciphertext string plaintext that DPI will classify magic as protocol X { strings that DPI will classify as protocol X } The desired ciphertext “ format ”

Format- Transforming Encryption key a ciphertext string plaintext FTE that DPI will classify as protocol X { strings that DPI will classify as protocol X } Like traditional encryption, with the extra operational requirement that ciphertexts fall within the format.

Ciphertext flexibility is built into the FTE syntax key a ciphertext string plaintext FTE that DPI will classify as protocol X { strings that DPI will classify as protocol X } Adapting to new DPI rules or different protocols requires changing only the format

Ciphertext flexibility is built into the FTE syntax key a ciphertext string plaintext FTE that DPI will classify as protocol Y { strings that DPI will classify as protocol Y } Adapting to new DPI rules or different protocols requires changing only the format

Surveying ¡modern ¡DPI ¡systems ¡ System ¡ Protocol ¡classifica-on ¡uses ¡ Costs ¡ AppID ¡ Free ¡ Regular expressions L7-­‑filter ¡ Free ¡ Regular expressions Yaf ¡ Regular expressions Free ¡ (sometimes hierarchical) Bro ¡ Simple regular expression triage, Free ¡ then additional parsing and heuristics nProbe ¡ ~300 ¡euros ¡ Parsing and heuristics (many of them “ regular ” ) Proprietary ¡ ~10,000 ¡USD ¡ ??? Can ¡we ¡build ¡FTE ¡schemes ¡that ¡support ¡ formats ¡defined ¡by ¡regexes? ¡

Realizing regex-based FTE key plaintext ciphertext in L(R) regex R How should we realize regex-based FTE? Cryptographic protection for the plaintext We want: Ciphertexts in L(R)

Realizing regex-based FTE key authenticated plaintext encryption ciphertext in L(R) regex R How should we realize regex-based FTE? Cryptographic protection for the plaintext We want: Ciphertexts in L(R)

Ranking a Regular Language [Goldberg, Sipser ’ 85] [Bellare et al. ’ 09] x i ¡ Let L(R) be lexicographically ordered L(R) x 0 < x 1 < … < x i < … < x |L(R)-1| i 0 1 2 |L(R)|-1 Given a DFA (deterministic finite automaton) for L(R), there are efficient algorithms

Ranking a Regular Language [Goldberg, Sipser ’ 85] [Bellare et al. ’ 09] rank(x i )=i x i ¡ Let L(R) be lexicographically ordered L(R) x 0 < x 1 < … < x i < … < x |L(R)-1| i 0 1 2 |L(R)|-1 Given a DFA (deterministic finite automaton) for L(R), there are efficient algorithms rank: L(R) {0,1,…,|L(R)|-1}

Ranking a Regular Language [Goldberg, Sipser ’ 85] [Bellare et al. ’ 09] rank(x i )=i x i ¡ Let L(R) be lexicographically ordered L(R) x 0 < x 1 < … < x i < … < x |L(R)-1| unrank(2)=x 2 x 2 ¡ i 0 1 2 |L(R)|-1 Given a DFA (deterministic finite automaton) for L(R), there are efficient algorithms rank: L(R) {0,1,…,|L(R)|-1} With precomputed tables, unrank: {0,1,…,|L(R)|-1} L(R) rank, unrank are O (n) such that rank( unrank(i) ) = i and unrank( rank(x i ) ) = x i

Realizing regex-based FTE Intermediate ciphertext, interpreted as an integer i… …outputs i th string in lexicographic ordering of L(R) key authenticated [integer] plaintext encryption ciphertext in L(R) unrank ¡ regex R regex-to-DFA [DFA] Regex ¡R ¡ NFA ¡M ¡ DFA ¡M’ ¡ Exponen+al ¡blow-­‑up ¡in ¡worst ¡case. ¡Regexes ¡we ¡needed ¡avoid ¡this. ¡ [Luchaup, ¡Dyer, ¡Jha, ¡R., ¡Shrimpton ¡– ¡ ¡ ¡ FTE ¡using ¡NFAs ¡directly ¡ In ¡submission ¡2014] ¡

We ¡built ¡a ¡complete ¡FTE ¡record ¡layer ¡and ¡proxy ¡system ¡ FTE(K,R 1 , ¡M 1 ) ¡ FTE(K,R 2 , ¡M 2 ) ¡ FTE ¡ FTE ¡ client ¡ server ¡ Client ¡of ¡ ¡ Server ¡of ¡ protocol ¡X ¡ protocol ¡X ¡ Involved ¡significant ¡engineering ¡effort. ¡ Paper ¡has ¡more ¡details ¡or ¡ask ¡Kevin ¡Dyer ¡