Presentation is loading. Please wait.

Presentation is loading. Please wait.

doc.: IEEE <doc#>

Published byÂngelo Padilha Modified over 5 years ago

Similar presentations

Presentation on theme: "doc.: IEEE <doc#>"— Presentation transcript:

1 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Overview of Security PAR CREMA Jesse Walker, Intel Corporation <author>, <company>

2 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Agenda Introduction and Goals Security Today What’s Wrong Today? Proposed Encapsulation Proposed Authentication, Authorization, and Key Management Summary Jesse Walker, Intel Corporation <author>, <company>

3 Goals Develop a wider understanding of network security requirements
March 2001 Goals Develop a wider understanding of network security requirements Explain how security works now Describe its major issues Understand what is being done to address the issues Jesse Walker, Intel Corporation

4 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Agenda Introduction and Goals Security Today What’s Wrong Today? Proposed Encapsulation Proposed Authentication, Authorization, and Key Management Summary Jesse Walker, Intel Corporation <author>, <company>

5 802.11 Security Today Goals of existing 802.11 security
March 2001 Security Today Goals of existing security Existing security consists of two subsystems A data encapsulation technique called Wired Equivalent Privacy (WEP) An authentication algorithm called Shared Key Authentication Jesse Walker, Intel Corporation

6 Existing 802.11 Security Goals
March 2001 Existing Security Goals Create the privacy achieved by a wired network Only prevent intellectual property from leaking through casual browsing Simulate physical access control by denying access to unauthenticated stations Jesse Walker, Intel Corporation

7 WEP Encapsulation WEP Encapsulation Summary:
March 2001 WEP Encapsulation Hdr Data Encapsulate Decapsulate Hdr Data IV ICV WEP Encapsulation Summary: Encryption Algorithm = RC4 Per-packet encryption key = 24-bit IV concatenated to a pre-shared key WEP allows IV to be reused with any frame Data integrity provided by CRC-32 of the plaintext data (the “ICV”) Data and ICV are encrypted under the per-packet encryption key Jesse Walker, Intel Corporation

8 WEP Authentication AP STA 802.11 Authentication Summary:
March 2001 WEP Authentication STA AP Shared secret distributed out of band Challenge (Nonce) Response (Nonce RC4 encrypted under shared key) Decrypted nonce OK? Authentication Summary: Authentication key distributed out-of-band Access Point generates a “randomly generated” challenge Station encrypts challenge using pre-shared secret Jesse Walker, Intel Corporation

9 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Agenda Introduction and Goals Security Today So What’s Wrong Today? Proposed Encapsulation Proposed Authentication, Authorization, and Key Management Summary Jesse Walker, Intel Corporation <author>, <company>

10 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 So What’s Wrong Today? Properties of Vernam Ciphers How to read WEP Encrypted Traffic How to authentication without the key Traffic modification Lessons Requirements for a networked data encapsulation scheme Jesse Walker, Intel Corporation <author>, <company>

11 Properties of Vernam Ciphers (1)
March 2001 Properties of Vernam Ciphers (1) The WEP encryption algorithm RC4 is a Vernam Cipher: Pseudo-random number generator Encryption Key K Random byte b Plaintext data byte p Ciphertext data byte p Decryption works the same way: p = c  b Jesse Walker, Intel Corporation

12 Properties of Vernam Ciphers (2)
March 2001 Properties of Vernam Ciphers (2) Thought experiment 1: what happens when p1 and p2 are encrypted under the same “random” byte b? c1 = p1  b c2 = p2  b Then: c1  c2 = (p1  b)  (p2  b) = p1  p2 Conclusion: it is a very bad idea to encrypt any two bytes of data using the same byte output by a Vernam Cipher PRNG. Ever. Jesse Walker, Intel Corporation

13 How to Read WEP Encrypted Traffic (1)
March 2001 How to Read WEP Encrypted Traffic (1) Hdr Data IV ICV Encrypted under Key +IV using a Vernam Cipher 24 luxurious bits By the Birthday Paradox, probability Pn two packets will share same IV after n packets is P2 = 1/224 after two frames and Pn = Pn–1 + (n–1)(1–Pn–1)/ 224 for n > 2. 50% chance of a collision exists already after only 4823 packets!!! Pattern recognition can disentangle the XOR’d recovered plaintext. Recovered ICV can tell you when you’ve disentangled plaintext correctly. After only a few hours of observation, you can recover all 224 key streams. Jesse Walker, Intel Corporation

14 How to Read WEP Encrypted Traffic (2)
March 2001 How to Read WEP Encrypted Traffic (2) Ways to accelerate the process: Send spam into the network: no pattern recognition required! Get the victim to send to you The AP creates the plaintext for you! Decrypt packets from one Station to another via an Access Point If you know the plaintext on one leg of the journey, you can recover the key stream immediately on the other Etc., etc., etc. Jesse Walker, Intel Corporation

15 How to Authenticate without the Key
March 2001 How to Authenticate without the Key STA AP Challenge (Nonce) Response (Nonce RC4 encrypted under shared key) Decrypted nonce OK? With our background, an easy attack is obvious: Record one challenge/response with a sniffer Use the challenge to decrypt the response and recover the key stream Use the recovered key stream to encrypt any subsequent challenge Jesse Walker, Intel Corporation

16 Traffic Modification (1)
March 2001 Traffic Modification (1) Vernam cipher thought experiment 2: how hard is it to change a genuine packet’s data, so ICV won’t detect the change? Answer: Easy as pie Represent an n-bit plaintext as an n-th degree polynomial: p = pnxn + pn–1xn–1 +  + p0x0 (each pi = 0 or 1) Then the plaintext with ICV can be represented as : px32 + ICV(p) = pnxn+32 + pn–1xn–31 +  + p0x32 + ICV(p) If the n+32 bit RC4 key stream used to encrypt the body is represented by the n+32nd degree polynomial b, then the encrypted message body is px32 + ICV(p) + b Jesse Walker, Intel Corporation

17 Traffic Modification (2)
March 2001 Traffic Modification (2) But the ICV is linear, meaning for any polynomials p and q IVC(p+q) = ICV(p) + ICV(q) This means that if q is an arbitrary nth degree polynomial, i.e., an arbitrary change in the underlying message data: (p+q)x32 + ICV(p+q) + b = px32 + qx32 + ICV(p) + ICV(q) + b = ((px32 + ICV(p)) + b) + (qx32 + ICV(q)) Conclusion: Anyone can alter an WEP encapsulated packet in arbitrary ways without detection!! Jesse Walker, Intel Corporation

18 Lessons Data encryption by itself offers no protection from attack
March 2001 Lessons Data encryption by itself offers no protection from attack “It’s access control, stupid” there is no meaningful privacy if the data authenticity problem is not solved It is profoundly easy to mis-use a cipher “don’t try this at home” Get any cryptographic scheme reviewed by professionals Jesse Walker, Intel Corporation

19 Requirements for a networked data encapsulation scheme
March 2001 Requirements for a networked data encapsulation scheme Data traffic: packets must be authentication, not just encrypted packets must have sequence numbers to prevent replay Authentication: Mutual authentication required Per-packet keys have to be tied to the authentication Jesse Walker, Intel Corporation

20 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Agenda Introduction and Goals Security Today What’s Wrong Today? Proposed Encapsulation Proposed Authentication, Authorization, and Key Management Summary Jesse Walker, Intel Corporation <author>, <company>

21 Encapsulation Proposal
March 2001 Encapsulation Proposal Current TGe plan of record: Use AES-128 as the new cryptographic primitive Use AES in Offset Codebook Mode OCB mode Phil Rogaway submission to AES modes of operation algorithm provides both privacy and data integrity Add session sequence number to avoid replay Map base key to session key use OCB mode tag to compute session key, to minimize number of cryptographic primitives implemented Jesse Walker, Intel Corporation

22 AES Facts NIST standard for iterated block ciphers
March 2001 AES Facts NIST standard for iterated block ciphers Block cipher: encrypts or decrypts 128-bit blocks of data, not individual bytes Uses 128-, 192-, or 256-bit keys Highly parallelizable Critical path instructions: 88 S-box, XOR6, XOR5, XOR2, MUX2 Performance 200 MHz Pentium Pro: 284 cycles/block Jesse Walker, Intel Corporation

23 Iterated Block Ciphers
March 2001 Iterated Block Ciphers Multiplexor Register Combinational Logic Jesse Walker, Intel Corporation

24 OCB Mode (Full last block)
March 2001 OCB Mode (Full last block) Message M = m1 m2 m3 … mn-1 mn m1  …  mn tag +  (n+1)L+R EK +  1L+R EK m1 c1 m2 c2 +  2L+R ... mn cn  nL+R +  nL+R EK IV R Jesse Walker, Intel Corporation

25 OCB Mode (Partial last block)
March 2001 OCB Mode (Partial last block) Message M = m1 m2 m3 … mn-1 mn m1  …  pad(mn) +  1L+R EK m1 c1 m2 c2 +  2L+R ... mn cn  nL+R +  nL+R tag +  (n+1)L+R EK +  (n+2)L+R EK IV R Jesse Walker, Intel Corporation

26 AES-Based WEP Format Decapsulate Encapsulate 802.11 Hdr Data Seq Num
March 2001 AES-Based WEP Format Hdr Data Decapsulate Encapsulate Seq Num Data Hdr 128-bit IV 128-bit MIC Jesse Walker, Intel Corporation

27 Rationale AES strong and fast and parallelizable
March 2001 Rationale AES strong and fast and parallelizable OCB mode provides both data authenticity and encryption This avoids many common implementation and design errors Minimizes number of gates to implement Fast and parallelizable Doesn’t fail catastrophically if IV is reused Jesse Walker, Intel Corporation

28 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Agenda Introduction and Goals Security Today What’s Wrong Today? Proposed Encapsulation Proposed Authentication, Authorization, and Key Management Summary Jesse Walker, Intel Corporation <author>, <company>

29 Approach Based on existing protocols 802.11enhancements
March 2001 Approach Based on existing protocols Kerberos V (RFC 1510) GSS-API (RFC 2743) IAKERB (draft-ietf-cat-iakerb-05.txt) EAP-GSS (draft-aboba-pppext-eapgss-02.txt) EAP (RFC 2284) 802.1X/EAPOL 802.11enhancements MAC security management New model for authentication/association sequences Jesse Walker, Intel Corporation

30 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 IEEE 802.1X Terminology Authenticator Authentication Server Supplicant Controlled port Uncontrolled port 802.1X created to control access to any 802 LAN used as a transport for Extensible Authentication Protocol (EAP, RFC 2284) Jesse Walker, Intel Corporation <author>, <company>

31 Authentication Server
March 2001 802.1X Model AP Authentication Server STA Associate EAP Identity Request EAP Identity Response EAP Auth Request EAP Auth Response EAP-Success EAP-Success Authentication traffic Normal Data Port Status: Jesse Walker, Intel Corporation

32 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 EAP Framework EAP provides a flexible link layer security framework Simple encapsulation protocol No dependency on IP ACK/NAK, no windowing No fragmentation support Few link layer assumptions Can run over any link layer (PPP, 802, etc.) Assumes no re-ordering Can run over lossy or lossless media Retransmission responsibility of authenticator (not needed for 802.1X or ) EAP methods based on IETF standards Transport Level Security (TLS) (supported in Windows 2000) GSS_API (including Kerberos) Jesse Walker, Intel Corporation <author>, <company>

33 EAP-GSS and IAKERB EAP-GSS (draft-aboba-pppext-eapgss-02.txt)
March 2001 EAP-GSS and IAKERB EAP-GSS (draft-aboba-pppext-eapgss-02.txt) Use of GSS_API authentication methods within EAP IAKerb (draft-ietf-cat-iakberb-05.txt) GSS-API method enabling proxy Kerberos STA not able to talk to KDC directly prior to authentication Initial authentication IAKERB enables STA to obtain TGT, Ticket to AP Handoff Ticket to AP Jesse Walker, Intel Corporation

34 Advertising Security Options
March 2001 Advertising Security Options Modeled on “supported rates” AP advertises security options in probe response Placed in probe response only if STA requests it in probe request STAs collect this information prior to associations and can make association and roaming decisions based upon it Jesse Walker, Intel Corporation

35 Selecting security options
March 2001 Selecting security options STA requests security options in association request from available options contained in probe response AP accepts/rejects association based on request contents No additional protocol handshakes necessary No impact on roaming performance Jesse Walker, Intel Corporation

36 Initial Contact AP KDC STA March 2001 Associate EAP Identity Request
EAP Identity Response EAP-GSS Request (Empty) EAP-GSS Response (IAKERB: AS_REQ) AS_REQ AS_REP EAP-GSS Request (IAKERB: AS_REP) EAP-GSS Response (IAKERB: TGS_REQ) TGS_REQ EAP-GSS Request (IAKERB: TGS_REP) TGS_REP EAP IAKERB Response (Empty) EAP-Success EAP-Key (AP_REQ) EAP-Key (AP_REP) Jesse Walker, Intel Corporation

37 Operational Details Authentication method defaults to IAKERB
March 2001 Operational Details Authentication method defaults to IAKERB STA can attempt SPNEGO AP can choose IAKERB if it doesn’t support anything else EAP-Key packets passed up and down via driver interface and SAP On STA, GSS_API implementation needs to be able to generate AP_REQ, send it down to driver On AP, need ability to validate received AP_REQ, force 802.1X controlled port into authorized state encryption turned on after AP_REQ/AP_REP exchange AP turns on encryption after sending AP_REP STA turns on encryption after receiving AP_REP If EAP-Key exchange occurs prior to completion of 802.1X, then part of the 802.1X exchange may be encrypted! Jesse Walker, Intel Corporation

38 Security Services Authentication of client to KDC (TGS_REQ)
March 2001 Security Services Authentication of client to KDC (TGS_REQ) PADATA typically NOT used with AS_REQ! Authentication of KDC to client (AS_REP, TGS_REP) Session key for client-AP communication (TGS_REP, AP_REQ) TGT, Session key for client-KDC communication (AS_REP) Authentication of client to AP (AP_REQ) Authentication of AP to client (AP_REP) Jesse Walker, Intel Corporation

39 Assumes: APs can share identity and key
March 2001 Roaming Within Realm AP KDC STA Reassociate EAP-Key (AP_REQ) EAP-Key (AP_REP) EAP-Success Assumes: APs can share identity and key Jesse Walker, Intel Corporation

40 Security Services Authentication method defaults to IAKERB
March 2001 Security Services Authentication method defaults to IAKERB encryption turned on after AP_REQ/AP_REP exchange Authentication of client to KDC (TGS_REQ) Authentication of KDC to client (AS_REP, TGS_REP) Session key for client-AP communication (TGS_REP, AP_REQ) TGT, Session key for client-KDC communication (AS_REP) Authentication of client to AP (AP_REQ) Authentication of AP to client (AP_REP) Jesse Walker, Intel Corporation

41 doc.: IEEE 802.15-<doc#>
<month year> doc.: IEEE <doc#> March 2001 Agenda Introduction and Goals Security Today What’s Wrong Today? Proposed Encapsulation Proposed Authentication, Authorization, and Key Management Summary Jesse Walker, Intel Corporation <author>, <company>

42 March 2001 Summary security doesn’t meet any of its security objectives today TGe is working to replace Authentication scheme using 802.1X and Kerberos Encryption scheme using AES in OCB mode More to come “The paint’s not dry” Jesse Walker, Intel Corporation

Download ppt "doc.: IEEE <doc#>"

Similar presentations

Doc.: IEEE 802.11-01/039 Submission January 2001 Haverinen/Edney, NokiaSlide 1 Use of GSM SIM Authentication in IEEE802.11 System Submitted to IEEE802.11.

Doc.: IEEE /039 Submission January 2001 Haverinen/Edney, NokiaSlide 1 Use of GSM SIM Authentication in IEEE System Submitted to IEEE
CS470, A.SelcukStream Ciphers1 CS 470 Introduction to Applied Cryptography Instructor: Ali Aydin Selcuk.

CS470, A.SelcukStream Ciphers1 CS 470 Introduction to Applied Cryptography Instructor: Ali Aydin Selcuk.
IEEE 802.11i IT443 Broadband Communications Philip MacCabe October 5, 2005

IEEE i IT443 Broadband Communications Philip MacCabe October 5, 2005
WEP 1 WEP WEP 2 WEP  WEP == Wired Equivalent Privacy  The stated goal of WEP is to make wireless LAN as secure as a wired LAN  According to Tanenbaum:

WEP 1 WEP WEP 2 WEP  WEP == Wired Equivalent Privacy  The stated goal of WEP is to make wireless LAN as secure as a wired LAN  According to Tanenbaum:
Doc.: IEEE 802.11-00/275 Submission September 2000 David Halasz, Cisco Systems, Inc.Slide 1 IEEE 802.1X for IEEE 802.11 David Halasz, Stuart Norman, Glen.

Doc.: IEEE /275 Submission September 2000 David Halasz, Cisco Systems, Inc.Slide 1 IEEE 802.1X for IEEE David Halasz, Stuart Norman, Glen.
Doc.: IEEE 802.11-00/037 Submission March 2000 Duncan Kitchin, Jesse Walker, Intel NIDSlide 1 Proposal for Enhanced Encryption Duncan Kitchin Jesse Walker.

Doc.: IEEE /037 Submission March 2000 Duncan Kitchin, Jesse Walker, Intel NIDSlide 1 Proposal for Enhanced Encryption Duncan Kitchin Jesse Walker.
Wireless Security Ryan Hayles Jonathan Hawes. Introduction  WEP –Protocol Basics –Vulnerability –Attacks –Video  WPA –Overview –Key Hierarchy –Encryption/Decryption.

Wireless Security Ryan Hayles Jonathan Hawes. Introduction  WEP –Protocol Basics –Vulnerability –Attacks –Video  WPA –Overview –Key Hierarchy –Encryption/Decryption.
16-1 Last time Internet Application Security and Privacy Authentication Security controls using cryptography Link-layer security: WEP.

16-1 Last time Internet Application Security and Privacy Authentication Security controls using cryptography Link-layer security: WEP.
WEP Weaknesses Or “What on Earth does this Protect” Roy Werber.

WEP Weaknesses Or “What on Earth does this Protect” Roy Werber.
1 Enhancing Wireless Security with WPA CS-265 Project Section: 2 (11:30 – 12:20) Shefali Jariwala Student ID 001790660.

1 Enhancing Wireless Security with WPA CS-265 Project Section: 2 (11:30 – 12:20) Shefali Jariwala Student ID
COMP4690, HKBU1 Security of 802.11 COMP4690: Advanced Topic.

COMP4690, HKBU1 Security of COMP4690: Advanced Topic.
Intercepting Mobiles Communications: The Insecurity of 802.11 Danny Bickson ACNS Course, IDC Spring 2007.

Intercepting Mobiles Communications: The Insecurity of Danny Bickson ACNS Course, IDC Spring 2007.
How To Not Make a Secure Protocol 802.11 WEP Dan Petro.

How To Not Make a Secure Protocol WEP Dan Petro.
Wired Equivalent Privacy (WEP)

Wired Equivalent Privacy (WEP)
Security in Wireless LAN 802.11 Layla Pezeshkmehr CS 265 Fall 2003-SJSU Dr.Mark Stamp.

Security in Wireless LAN Layla Pezeshkmehr CS 265 Fall 2003-SJSU Dr.Mark Stamp.
An Initial Security Analysis of the IEEE 802.1x Standard Tsai Hsien Pang 2004/11/4.

An Initial Security Analysis of the IEEE 802.1x Standard Tsai Hsien Pang 2004/11/4.
E-mail: kemal@cs.siu.edu Department of Computer Science Southern Illinois University Carbondale Wireless and Network Security Lecture 9: IEEE 802.11.

Department of Computer Science Southern Illinois University Carbondale Wireless and Network Security Lecture 9: IEEE
IEEE 802.11 Wireless Local Area Networks (WLAN’s).

IEEE Wireless Local Area Networks (WLAN’s).
WIRELESS NETWORK SECURITY. Hackers Ad-hoc networks War Driving Man-in-the-Middle Caffe Latte attack.

WIRELESS NETWORK SECURITY. Hackers Ad-hoc networks War Driving Man-in-the-Middle Caffe Latte attack.
WPA2 By Winway Pang. Overview  What is WPA2?  Wi-Fi Protected Access 2  Introduced September 2004  Two Versions  Enterprise – Server Authentication.

WPA2 By Winway Pang. Overview  What is WPA2?  Wi-Fi Protected Access 2  Introduced September 2004  Two Versions  Enterprise – Server Authentication.

Similar presentations

Ads by Google