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

Analysis of 802.11 Securit y or 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 LAN Access Point Shared Key Mobile Mobile Mobile St at ion St at ion St at ion

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 RC4 encrypt ed … I V Payload CRC-32 Key I D byt e

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 RC4(“f oo”) = 123456789ABCDEF XOR 4A7D043D6FBE9C RC4(“f oo”) = 123456789ABCDEF XOR “WI RELESS” = 584952454C455353

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… … … … … … … … … … 0 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 … on 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 – 2 24 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 2 24 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 Packet Packet Access Evil 1 I nt ernet Point Packet Evil 2 Mobile St at ion

Problem 4: Encrypt ion Oracle Access Point s encrypt s packet s coming f rom t he LAN bef ore sending over 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) Packet Packet Access Evil 1 I nt ernet Point Packet Evil 2 Mobile St at ion

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 … or 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 once!

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 dea TM 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