Analysis of 802.11 Securit y or Wired Equivalent Privacy I snt - - PowerPoint PPT Presentation

Analysis of 802.11 Securit y

• r Wired Equivalent Privacy

I sn’t

Nikit a Borisov, I an Goldberg, and David Wagner

WEP Prot ocol

“Wired Equivalent Privacy” Part of t he 802.11 Link-layer securit y prot ocol

Securit y Goals

Prevent link-layer eavesdropping

… not end-t o-end securit y

Secondary goal: cont rol net work access

Not always an explicit goal

Essent ially, equivalent t o wired access point securit y

“Open Design”?

An indust ry-driven commit t ee (?) No apparent public review (X) Result ing st andard is open …(

)

…but cost s $$$ (X) Use a well-st udied cipher (

)

Prot ocol Set up

Mobile St at ion Mobile St at ion Mobile St at ion Access Point Shared Key LAN

Prot ocol Set up

Mobile st at ion shares key wit h access point Each packet is encrypt ed wit h shared key + init ializat ion vect or (I V) Each packet includes an int egrit y check I C f ails => packet rej ect ed Opt ionally, rej ect all unencrypt ed packet s

Packet Format

I V CRC-32

…

Payload Key I D byt e RC4 encrypt ed

Problem 1: St at eless Prot ocol

Mobile st at ions and access point s are not required t o keep past st at e Fundament al consequence: can replay packet s But I P allows f or duplicat ion anyway, right ?

St ream Ciphers

RC4 is a st ream cipher Expands a key int o an inf init e pseudorandom keyst ream To encrypt , XOR keyst ream wit h plaint ext Random ^ Anyt hing = Random Encrypt ion same as decrypt ion

Example

“WI RELESS” = 584952454C455353 4A7D043D6FBE9C “WI RELESS” = 584952454C455353 RC4(“f oo”) = 123456789ABCDEF RC4(“f oo”) = 123456789ABCDEF XOR XOR

Problem 2: Linear Checksum

Encrypt ed CRC-32 used as int egrit y check

Fine f or random errors, but not deliberat e ones

CRC is linear I .e. CRC(X^Y) = CRC(X)^CRC(Y) RC4(k,X^Y) = RC4(k,X)^Y

Hence we can change bit s in t he packet

Packet Modif icat ion

Payload CRC-32 000… … … … … 00100… … … … … … … … … … 010010 XOR Modif ied Payload CRC-32’

Can replay modif ied packet s!

“I nt egrit y check” does not prevent packet modif icat ion Can maliciously f lip bit s in packet s

Modif y act ive st reams!

TCP checksum: not quit e linear, but can guess right about half t he t ime Known plaint ext f or a single packet allows t o send arbit rary t raf f ic!

What about I Vs?

RC4 keyst ream should not be reused, since RC4(k,X)^RC4(k,Y) = X^Y Use init ializat ion vect or t o generat e dif f erent keyst ream f or each packet by augment ing t he key Key = base_key | | I V I nclude I V (plaint ext ) in header

Problem 3: I V reuse

Same shared key used in bot h direct ions

…

• n some inst allat ions all st at ions share

same key I .e. a “net work password”

Some implement at ions reset I V t o 0 when init ialized Easy t o f ind collisions!

I V collision

Two packet s P1 and P2 wit h same I V C1 = P1 xor RC4(k| | I V) C2 = P2 xor RC4(k| | I V) C1 xor C2 = P1 xor P2 Known plaint ext P1 gives P2, or use st at ist ical analysis t o f ind P1 and P2 Even easier if you have t hree packet s!

I mplement at ion bug or design f law?

What if random I Vs were used? I V space – 224 possibilit ies Collision af t er 4000 packet s Rough est imat e: a busy AP sends 1000 packet s/ sec Collision every 4s! Even wit h count ing I V (best case), rollover every f ew hours

I V collisions, cont inued

I f we have 224 known plaint ext s, can decrypt every packet

Becomes more of a problem if st ronger crypt o (ie. 128-bit RC4) is deployed

How t o get known plaint ext ? I P t raf f ic pret t y predict able Aut hent icat ion challenge? Send packet s f rom out side?

At t ack f rom Bot h Ends

Mobile St at ion Access Point I nt ernet Evil 1 Evil 2

Packet Packet Packet

Problem 4: Encrypt ion Oracle

Access Point s encrypt s packet s coming f rom t he LAN bef ore sending

• ver air

LAN event ually connect s t o I nt ernet ; at t ack AP f rom bot h ends Send packet s f rom I nt ernet wit h known cont ent t o a wireless node Voila! Known plaint ext

At t ack f rom Bot h Ends (2)

Mobile St at ion Access Point I nt ernet Evil 1 Evil 2

Packet Packet Packet

Decrypt ion Oracle??

Recall Problem 2: can f lip bit s in packet s Suppose we can guess dest inat ion I P in encrypt ed packet Flip bit s t o change I P t o host we cont rol, send it t o AP

Tricks t o adj ust I P checksum

AP happily f orwards it t o t he our host Set port 80 t o bypass f irewalls I ncorrect TCP checksum not checked unt il we see t he packet !

At t ack Pract icalit y

Sit out side compet it or’s of f ice, use a sof t ware radio …

• r an of f t he shelf wireless card!

Wit h minimal work, possible t o monit or encrypt ed t raf f ic Reverse engineer f irmware f or act ive at t acks Economies of scale: only has t o be done

• nce!

Lessons Not Learned

Most at t acks are not new! Earlier versions of I PSEC had many similar problems (e.g. [Bel96])

Ot her at t acks (e.g. react ion) applicable

SSH (and many ot hers) had CRC checksum problems Microsof t PPTP had RC4 direct ionalit y problems

Lessons t o t ake away

Prot ocol design is harder t han it looks Can be circumvent ed at many point s Public review is a Good I deaTM

Time t o develop at t acks is short !

Use previous work (and t heir f ailures)

Put wireless net work outside f irewall, run VPN t o inside f irewall Bet t er yet , use end-t o-end encrypt ion