CS 361 S Introduction to Stream Ciphers Attacks

CS 361 S Introduction to Stream Ciphers Attacks on CSS, WEP, MIFARE Vitaly Shmatikov

Stream Ciphers u. One-time pad: Ciphertext(Key, Message)=Message Key • Key must be a random bit sequence as long as message u. Idea: replace “random” with “pseudo-random” • Use a pseudo-random number generator (PRNG) • PRNG takes a short, truly random secret seed and expands it into a long “random-looking” sequence – E. g. , 128 -bit seed into a 106 -bit pseudo-random sequence No efficient algorithm can tell this sequence from truly random u. Ciphertext(Key, Msg)=IV, Msg PRNG(IV, Key) • Message processed bit by bit (unlike block cipher) slide 2

Stream Cipher Terminology u. The seed of a pseudo-random generator typically consists of initialization vector (IV) and key • The key is a secret known only to the sender and the recipient, not sent with the ciphertext • IV is usually sent with the ciphertext u. The pseudo-random bit stream produced by PRNG(IV, key) is referred to as the keystream u. Encrypt message by XORing with keystream • ciphertext = message keystream slide 3

Properties of Stream Ciphers u. Usually very fast (faster than block ciphers) • Used where speed is important: Wi. Fi, DVD, RFID, Vo. IP u. Unlike one-time pad, stream ciphers do not provide perfect secrecy • Only as secure as the underlying PRNG • If used properly, can be as secure as block ciphers u. PRNG must be cryptographically secure slide 4

Using Stream Ciphers u. No integrity • Associativity & commutativity: (M 1 PRNG(seed)) M 2 = (M 1 M 2) PRNG(seed) • Need an additional integrity protection mechanism u. Known-plaintext attack is very dangerous if keystream is ever repeated • Self-cancellation property of XOR: X X=0 • (M 1 PRNG(seed)) (M 2 PRNG(seed)) = M 1 M 2 • If attacker knows M 1, then easily recovers M 2 … also, most plaintexts contain enough redundancy that can recover parts of both messages from M 1 M 2 slide 5

How Random is “Random”? slide 6

Cryptographically Secure PRNG u. Next-bit test: given N bits of the pseudo-random sequence, predict (N+1)st bit • Probability of correct prediction should be very close to 1/2 for any efficient adversarial algorithm (means what? ) u. PRNG state compromise • Even if the attacker learns the complete or partial state of the PRNG, he should not be able to reproduce the previously generated sequence – … or future sequence, if there’ll be future random seed(s) u. Common PRNGs are not cryptographically secure slide 7

LFSR: Linear Feedback Shift Register Example: 4 -bit LFSR b 0 b 1 b 2 b 3 add to pseudo-random sequence u. For example, if the seed is 1001, the generated sequence is 1001101011110001001… u. Repeats after 15 bits (24 -1) slide 8

Content Scrambling System (CSS) u DVD encryption scheme from Matsushita and Toshiba Each player has its own PLAYER KEY (409 player manufacturers, each has its player key) KEY DATA BLOCK contains disk key encrypted with 409 different player keys: Each DVD is encrypted with a disk-specific 40 -bit DISK KEY • Encrypt. Disk. Key(Disk. Key) • Encrypt. Player. Key 1(Disk. Key) … Encrypt. Player. Key 409(Disk. Key) This helps attacker verify his guess of disk key What happens if even a single player key is compromised? slide 9

Attack on CSS Decryption Scheme [Frank Stevenson] “ 1” seeded in 1 st bit 16 key bits disk key … 4 th +mod 256 … 24 key bits “ 1” seeded in LFSR-17 bit Encrypt. Disk. Key(Disk. Key) stored on disk LFSR-25 Decrypted title key invert carry Encrypted title key Table-based “mangling” Given known 40 -bit plaintext, repeat the following 5 times (once for each plaintext byte): guess the byte output by the sum of the two LFSRs; use known ciphertext to verify – this takes O(28) For each guessed output byte, guess 16 bits contained in LFSR-17 – this takes O(216) Clock out 24 bits out of LFSR-17, use subtraction to determine the corresponding output bits of LFSR-25 – this reveals all of LFSR-25 except the highest bit “Roll back” 24 bits, try both possibilities – this takes O(2) This attack takes O(225) Clock out 16 more bits out of both LFSRs, verify the key slide 10

De. CSS u. In CSS, disk key is encrypted under hundreds of different player keys… including Xing, a software DVD player u. Reverse engineering the object code of Xing revealed its player key • Every CSS disk contains the master disk key encrypted under Xing’s key • One bad player entire system is broken! u. Easy-to-use De. CSS software slide 11

De. CSS Aftermath u. DVD CCA sued Jon Lech Johansen (“DVD Jon”), one of De. CSS authors eventually dropped u. Publishing De. CSS code violates copyright • Underground distribution as haikus and T-shirts • “Court to address De. CSS T-Shirt: When can a T-shirt become a trade secret? When it tells you how to copy a DVD. ” - Wired News slide 12

RC 4 u. Designed by Ron Rivest for RSA in 1987 u. Simple, fast, widely used • SSL/TLS for Web security, WEP for wireless Byte array S[256] contains a permutation of numbers from 0 to 255 i = j : = 0 loop i : = (i+1) mod 256 j : = (j+S[i]) mod 256 swap(S[i], S[j]) output (S[i]+S[j]) mod 256 end loop slide 13

RC 4 Initialization Key can be any length Divide key K into L bytes up to 2048 bits for i = 0 to 255 do S[i] : = i j : = 0 for i = 0 to 255 do Generate initial permutation j : = (j+S[i]+K[i mod L]) mod 256 from key K swap(S[i], S[j]) u To use RC 4, usually prepend initialization vector (IV) to the key • IV can be random or a counter u RC 4 is not random enough… First byte of generated sequence depends only on 3 cells of state array S - this can be used to extract the key! • To use RC 4 securely, RSA suggests discarding first 256 bytes Fluhrer-Mantin. Shamir attack slide 14

802. 11 b Overview u. Standard for wireless networks (IEEE 1999) u. Two modes: infrastructure and ad hoc IBSS (ad hoc) mode BSS (infrastructure) mode slide 15

Access Point SSID u. Service Set Identifier (SSID) is the “name” of the access point • By default, access point broadcasts its SSID in plaintext “beacon frames” every few seconds u. Default SSIDs are easily guessable • Manufacturer’s defaults: “linksys”, “tsunami”, etc. • This gives away the fact that access point is active u. Access point settings can be changed to prevent it from announcing its presence in beacon frames and from using an easily guessable SSID • But then every user must know SSID in advance slide 16

WEP: Wired Equivalent Privacy u. Special-purpose protocol for 802. 11 b u. Goals: confidentiality, integrity, authentication • Intended to make wireless as secure as wired network u. Assumes that a secret key is shared between access point and client u. Uses RC 4 stream cipher seeded with 24 -bit initialization vector and 40 -bit key • Terrible design choice for wireless environment slide 17

Shared-Key Authentication Prior to communicating data, access point may require client to authenticate Access Point Client beacon probe request unauthenticated & unassociated OR authenticated & unassociated challenge IV, challenge RC 4(IV, K) association request association response authenticated & associated Passive eavesdropper recovers RC 4(IV, K), can respond to any subsequent challenge without knowing K slide 18

How WEP Works (IV, shared key) used as RC 4 seed • Must never be repeated (why? ) • There is no key update protocol, so security relies on never repeating IV 24 bits 40 bits CRC-32 checksum is linear in : if attacker flips some plaintext bits, he knows which bits of CRC to flip to produce the same checksum no integrity! IV sent in the clear Worse: changing IV with each packet is optional! slide 19

RC 4 Is a Bad Choice for Wireless u. Stream ciphers require sender and receiver to be at the same place in the keystream • Not suitable when packet losses are common u. WEP solution: a separate keystream for each packet (requires a separate seed for each packet) • Can decrypt a packet even if a previous packet was lost u. But there aren’t enough possible seeds! • RC 4 seed = 24 -bit initialization vector + fixed key • Assuming 1500 -byte packets at 11 Mbps, 224 possible IVs will be exhausted in about 5 hours u. Seed reuse is deadly for stream ciphers slide 20

Recovering the Keystream u. Get access point to encrypt a known plaintext • Send spam, access point will encrypt and forward it • Get victim to send an email with known content u. With known plaintext, easy to recover keystream • C M = (M RC 4(IV, key)) M = RC 4(IV, key) u. Even without knowing the plaintext, can exploit plaintext regularities to recover partial keystream • Plaintexts are not random: for example, IP packet structure is very regular u. Not a problem if the keystream is not re-used slide 21

Keystream Will Be Re-Used u. In WEP, repeated IV means repeated keystream u. Busy network will repeat IVs often • Many cards reset IV to 0 when re-booted, then increment by 1 expect re-use of low-value IVs • If IVs are chosen randomly, expect repetition in O(212) due to birthday paradox u. Recover keystream for each IV, store in a table • (Known. M RC 4(IV, key)) Known. M = RC 4(IV, key) u. Wait for IV to repeat, decrypt, enjoy plaintext • (M’ RC 4(IV, key)) RC 4(IV, key) = M’ slide 22

It Gets Worse u. Misuse of RC 4 in WEP is a design flaw with no fix • Longer keys do not help! – The problem is re-use of IVs, their size is fixed (24 bits) • Attacks are passive and very difficult to detect u. Perfect target for the Fluhrer et al. attack on RC 4 • Attack requires known IVs of a special form • WEP sends IVs in plaintext • Generating IVs as counters or random numbers will produce enough “special” IVs in a matter of hours u. This results in key recovery (not just keystream) • Can decrypt even ciphertexts whose IV is unique slide 23

Fixing the Problem u. Extensible Authentication Protocol (EAP) • Developers can choose their own authentication method – Passwords (Cisco EAP-LEAP), public-key certificates (Microsoft EAP-TLS), passwords OR certificates (PEAP), etc. u 802. 11 i standard fixes 802. 11 b problems • Patch (TKIP): still RC 4, but encrypts IVs and establishes new shared keys for every 10 KBytes transmitted – Use same network card, only upgrade firmware – Deprecated by the Wi-Fi alliance • Long-term: AES in CCMP mode, 128 -bit keys, 48 -bit IVs – Block cipher in a stream cipher-like mode slide 24

Hacking MIFARE Chips u. Multi-year project on evaluating security of MIFARE cards at Radboud University in Holland • http: //www. ru. nl/ds/research/rfid/ u. MIFARE = a case study in how not to design cryptographic authentication systems u. The following slides are from Peter Van Rossum slide 25

MIFARE Chips u. Series of chips used in contactless smart cards • Developed by NXP Semiconductors in the Netherlands u. Very common in transport payment cards u. MIFARE Classic: 80% of the market • Over 1 billion sold, over 200 million in use slide 26

Memory Structure of the Card 64 blocks 0 1 2 3 uid, manufacturer data key A, access conditions, key B 0 4 5 6 7 data key A, access conditions, key B 1 60 61 62 63 data key A, access conditions, key B 15 48 bits 16 bytes 16 sectors 48 bits slide 27

LFSR Home-brewed “filter” function slide 28

Challenge-Response in CRYPTO 1 Tag Reader LFSR stream: Initial state of the LFSR is the key ai : = ki i ∈ [0, 47] uid auth(block) pick n. T pick n. R Generated by PRNG {n. R, a. R} a. R: =suc 64(n. T) Shift n. T + uid into the LFSR ai+48 : = L(ai, …, ai+47) + n. Ti + uidi i ∈ [0, 31] check a. R a. T: =suc 96(n. R) {a. T} check a. T auth. ok Shift n. R into the LFSR ai+48 : = L(ai, …, ai+47) + n. Ri-32 i ∈ [32, 63] After authentication, LFSR keeps shifting ai+48 : = L(ai, …, ai+47) i ∈ [64, ∞) Keystream: bi : = f(ai+9, ai+11, …, ai+47) i ∈ [32, ∞) slide 29

PRNG in CRYPTO 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 • Linear feedback shift register • 16 -bit internal state • Period 216 – 1 = 65535 Feedback: L 16(x 0, x 1, …, x 15) : = x 0+x 2+x 3+x 5 Successor: suc(x 0, x 1, …, x 31) : = (x 1, x 2, …, x 30, L 16(x 16, x 17, …, x 31)) slide 30

Replay Attack [Gans, Hoepman, Garcia] u. Good challenge-response authentication requires some form of “freshness” in each session • For example, timestamp or strong (pseudo)randomness u. MIFARE Classic: no clock + weak randomness • “Random” challenges repeat a few times per hour u. Eavesdrop and record communication session u. When challenge repeats, send known plaintext, extract keystream, use it to decrypt recorded communication that used the same challenge slide 31

Extracting the Key from Reader 1. Acquire keystream • • Observe authentication keystream 1 to 3 authentication sessions – takes microseconds 2. Invert the filter function • • Keystream internal state of LFSR Approx. 226 operations – takes seconds 3. Roll back (“unshift”) the LFSR • • Internal state of LFSR at any time seed (= key) Problem: bad PRNG design… cryptographically secure PRNG should not allow rollback and recovery of the seed even if state is compromised slide 32

Acquiring Keystream Tag Reader Intercepted communication: • n. T, {a. R}, {a. T} visible to attacker • {a. R} = suc 64(n. T), {a. T} = suc 96(n. T) • 64 keystream bits uid auth(block) pick n. T pick n. R {n. R, a. R} a. R: =suc 64(n. T) check a. R a. T: =suc 96(n. T) OR Access to reader only: • n. T under attacker control • {a. R} = suc 64(n. T) visible to attacker • 32 keystream bits {a. T} check a. T auth. ok slide 33

Inverting the Filter Function # # # # # keystream: 01100110110 219 ########## # ## ######### # 00000000001 00000000011 000000000100 000000000110 … produces ‘odd’ keystream 0 0 0000000000000000000 1 0 00000000011 1 0 00000000100 0 … produces ‘odd’ keystream 01 00 0000000001 1 00 00000000111 0 00 00000000111 1 00 00000001000 … produces ‘odd’ keystream 010 Filter function only depends only on 20 odd bits of input easily inverted • Compute ‘odd’ bits of LFSR using table and deduce ‘even’ bits (linear relation) OR • Compute ‘odd’ and ‘even’ bits of LFSR using tables separately and combine tables slide 34

Rolling Back the LFSR Feedback: L(x 0, x 1, …, x 47) : = x 0+x 5+x 9+x 10+x 12+x 14 +x 15+x 17+x 19+x 24+x 25+x 27+x 29+x 35+x 39 +x 41+x 43 LFSR stream: Initial state of the LFSR is the key ai : = ki i ∈ [0, 47] Shift n. T + uid into the LFSR ai+48 : = L(ai, …, ai+47) + n. Ti + uidi i ∈ [0, 31] Shift n. R into the LFSR ai+48 : = L(ai, …, ai+47) + n. Ri-32 i ∈ [32, 63] After authentication, LFSR keeps shifting ai+48 : = L(ai, …, ai+47) i ∈ [64, ∞) Keystream: bi : = f(ai+9, ai+11, …, ai+47) i∈ℕ Inverting feedback: R(x 1, …, x 47, x 48) : = x 5+x 9+x 10+x 12+x 14 +x 15+x 17+x 19+x 24+x 25+x 27+x 29+x 35+x 39 +x 41+x 43+x 48 R(x 1, …, x 47, L(x 0, x 1, …, x 47)) = x 0 Inverting LFSR stream: Unshift LFSR until end of authentication ai = R(ai+1, …, ai+48) i ∈ [64, ∞) Unshift n. R from the LFSR ai = R(ai+1, …, ai+48) + n. Ri-32 i ∈ [32, 63] = R(ai+1, …, ai+48) + {n. R}i-32 + bi = R(ai+1, …, ai+48) + {n. R}i-32 + f(ai+9, …, ai+47) Unshift n. T + uid from the LFSR ai = R(ai+1, …, ai+48) + n. Ti + uidi i ∈ [0, 31] Key is the initial state of the LFSR ki = ai i ∈ [0, 47] slide 35

Summary: Weaknesses of CRYPTO 1 u. Stream cipher with 48 -bit internal state • Enables brute-force attack u. Weak 16 -bit random number generator • Enables chosen-plaintext attack and replay attack u. Keystream based on simple LFSR structure + weak “one-way” filter function • Invert filter function obtain state of LFSR • Roll back LFSR recover the key – 64 -bit keystream recover unique key – 32 -bit keystream 216 candidate keys slide 36

Extracting the Key (Card Only) u. Parity bit of plaintext is encrypted with the same bit of the keystream as the next bit of plaintext • “One-time” pad is used twice u. If parity bit is wrong, encrypted error message is sent before authentication • Opens the door to card-only guessing attacks (chosenplaintext, chosen-ciphertext) – why? • Wireless-only attack u. Recover secret key from the card in seconds • Result: full cloning of the card slide 37