CMSC 414 Computer and Network Security Lecture 10

Preview:

DESCRIPTION

CMSC 414 Computer and Network Security Lecture 10. Jonathan Katz. “Insecurity of 802.11”. WEP encryption: IV, RC4(IV | k)  (M, c(M)) Is this secure against chosen-plaintext attacks? It is randomized… 40-bit key (in some implementations)! - PowerPoint PPT Presentation

Citation preview

CMSC 414Computer and Network Security

Lecture 10

Jonathan Katz

“Insecurity of 802.11”

WEP encryption: IV, RC4(IV | k) (M, c(M))

Is this secure against chosen-plaintext attacks?– It is randomized…

40-bit key (in some implementations)!– Claims that, with IV, this gives a 64-bit effective key(!)

And how is the IV chosen?– Only 24 bits long -- IV repetitions are a problem!

– Reset to 0 upon re-initialization

– Some implementations increment the IV as a counter

“Insecurity of 802.11”

A repeating IV allows the attacker to compute the XOR of two plaintexts– We have discussed already how this can be damaging

Small IV space means the attacker can build a dictionary of (IV, RC4(IV | k)) pairs– If portions of some plaintexts known (e.g., predictable

fields), this enables determination of other plaintexts

“Insecurity of 802.11”

Known-plaintext attacks discovered on this usage of RC4– Possible because the first byte of plaintext is a fixed,

known header!

Chosen-plaintext attacks– Send IP traffic/e-mail to the mobile host and watch it

get forwarded!

– Transmit broadcast messages to access point

“Insecurity of 802.11”

Encryption used to provide authenticationof mobile station (access point sends nonce; station returns an encryption of the nonce)– Allows easy spoofing after eavesdropping

– Enables chosen-plaintext attacks (by masquerading as access point)

What would have been the right primitive to use?

“Insecurity of 802.11”

No cryptographic integrity protection– CRC-32 checksum is linear (i.e., c(xy) = c(x)c(y))

and unkeyed, and therefore easy to attack

• Can effect arbitrary shifts of an unknown message

– Allows IP redirection attack – change destination IP address of a packet to one owned by the attacker

– Allows TCP “reaction” attacks

• Modify ciphertexts, and look at whether TCP checksum is accepted by the receiver

• Form of chosen-ciphertext attack

“Analysis of E-Voting System”

This paper should scare you…– Magnitude of possible attacks by voters

– Not just the security flaws, but also the reaction of Diebold and govt. officials…

Vulnerable to attacks by voters, as well as attacks by insiders

Security through obscurity did not help – In this case, code was leaked

Desiderata? Security against voters

– No double voting– No voting outside place of residence– Unable to disrupt the election, or tamper with results– Privacy of others’ votes

Security against insiders (election officials, district heads, programmers, tech staff, …)– Privacy of votes, except end-of-day total– Unable to disrupt the election, or tamper with results

Public verifiability of the entire process

Overview of Diebold system

Voting terminals initialized; ballots installed

On voting day, voters given voting card– Voter inserts card, gets ballot, makes choices

– After confirmation, voting card is “cancelled”

Election is closed by inserting an admin card– Results can be uploaded for tabulation

Poor cryptography

Smartcards have no cryptographic functionality– Possible to create home-made voting cards!

– Cast multiple votes by disabling “cancellation”, or overwriting card

– Change party affiliation

No cryptographic protection for admin cards– Only a weak PIN…if any

– Possible to shut down the election!

Bad audit mechanism for detecting over-voting– Detected over-vote would nullify the election

“Analysis of E-Voting System” Most data stored without any integrity

• Possible to modify ballots, vote total, or even the software

No authentication of data sent to back-end server

Hard-coded, non-random DES key!

CBC mode with IV = 0!– Deterministic encryption…– Linking voters to votes (encrypted votes stored

sequentially)

CRC used instead of a secure MAC

Poor random number generation

“Padding oracle attacks”

Chosen-ciphertext attack, relying on a single bit of information from the receiver– Is the decrypted message padded properly?

We look at one example

“Padding oracle attacks”

m1 m2 m3 0L

Encrypt using CBC mode…

c1 c2 c3c0IV

message

plaintext

“Padding oracle attacks”

Step 1: recover L– Flip a bit in c2

• Results in a flipped bit in the final plaintext block

• Causes decryption error iff in the ‘0’ portion

– Determine L using binary search

“Padding oracle attacks”

Submit ciphertext IV’ | c0 | R | ck, where IV’ chosen so that L’ = 2n-1– Decryption error iff final bit of recovered plaintext is 1

• I.e., [F-1K(ck) R]n = 1

– Given ck-1, this is enough to learn the last bit of mk

Repeat the same basic idea for all the bits (except some care needed for the first)

Other crypto “pitfalls”?

1. Even good cryptography can be ‘circumvented’ by adversaries operating ‘outside the model’

1. Systems are complex, and your model may not exactly match reality

2. Side channel attacks

3. Misuse of crypto (e.g., poor key management)

Side channel attacks

Side channel attacks

Cryptographic analysis treats primitives/protocols as black boxes

In reality, primitives and protocols implemented in the real world by hardware/software– This may lead to (other) attacks ‘outside the model’

Side channel attacks

CPU retains state in the form of caches, branch prediction buffer, stack data, memory, disk…

Interaction with users influences resource usage, page protections, scheduling

Timing attacks, power analysis, EM radiation, heat/sound/disk access patterns– Especially in embedded systems

Side channel attacks

Side channel attacks may be used to break the crypto– E.g., timing attacks, power analysis

Side channel attacks may also be used to circumvent crypto entirely– E.g., EM radiation from monitors/keyboards, extracting

keys from memory or data from disk

– (Really more of a systems issue than a crypto issue)

Simple timing attack

Consider the following code for verifying a MAC

Vrfy(k, m, t){ correct = MAC(k,m); for (i=0 to 15) if correct[i] != t[i] return FALSE; return TRUE; }

Assume adversary able to measure the response time until authentication fails– Do you see the attack?

Preventing timing attacks

Timing analysis– Make all operations take the same amount of time

– Randomize amount of time operations take (essentially a variant of the above)

“Cold boot attacks”

Attacks on disk encryption products, exploiting poor key management along with the fact that memory contents can be recovered

Basic setup

RAMEncrypted hard drive

Encpw(k)

Enck(data)k

pw

data

What happens when computer is shut off (or put in standby)?

Setup 2

RAM

k

TPM

k

pwok

Before correct password entered, k is loaded into memory

Key observations

If memory can be probed, possible to recover k (and then read all data on hard drive) without the correct password– First case: k not scrubbed after power down

• Memory decays over time

• But not too quickly, and this process can be slowed by cooling

– Second case: k should be loaded only after successful password is entered

Video at http://citp.princeton.edu/memory/media/