Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 Mathy - - PowerPoint PPT Presentation

key reinstallation attacks
SMART_READER_LITE
LIVE PREVIEW

Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 Mathy - - PowerPoint PPT Presentation

Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 Mathy Vanhoef, PhD Wi-Fi Alliance meeting Bucharest, 24 October 2017 Overview 1. Key reinstallation in 4-way handshake 2. Misconceptions and remarks 3. Steps to improve Wi-Fi


slide-1
SLIDE 1

Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2

Mathy Vanhoef, PhD Wi-Fi Alliance meeting Bucharest, 24 October 2017

slide-2
SLIDE 2

Overview

  • 1. Key reinstallation in

4-way handshake

  • 2. Misconceptions

and remarks

  • 3. Steps to improve

Wi-Fi security?

slide-3
SLIDE 3

The 4-way handshake

Two main purposes: › Mutual authentication › Negotiate fresh PTK: pairwise temporal key Appeared to be secure: › No attacks in more than a decade › Proven as secure in 20051 › That is: negotiated key (PTK) is secret

slide-4
SLIDE 4

Wi-Fi handshake (simplified)

4

PTK = Combine(shared secret, ANonce, SNonce)

slide-5
SLIDE 5

Wi-Fi handshake (simplified)

5

PTK = Combine(shared secret, ANonce, SNonce)

Attack isn’t about ANonce or SNonce reuse

slide-6
SLIDE 6

Wi-Fi handshake (simplified)

6

slide-7
SLIDE 7

Wi-Fi handshake (simplified)

7

PTK is installed

slide-8
SLIDE 8

Wi-Fi handshake (simplified)

8

slide-9
SLIDE 9

Encrypting data frames (simplified)

9

Nonce Plaintext data

Keystream should never be reused

  • Each nonce results in a unique keystream

Nonce

= Packet Number

slide-10
SLIDE 10

Wi-Fi handshake (simplified)

10

Installing PTK resets nonce to zero

slide-11
SLIDE 11

11

Key Reinstallation Attack

slide-12
SLIDE 12

12

slide-13
SLIDE 13

13

Block Msg4

slide-14
SLIDE 14

14

slide-15
SLIDE 15

15

In practice Msg4 is sent encrypted

slide-16
SLIDE 16

16

slide-17
SLIDE 17

17

Key reinstallation! nonce is reset

slide-18
SLIDE 18

18

slide-19
SLIDE 19

19

Same nonce is used!

slide-20
SLIDE 20

20

keystream

slide-21
SLIDE 21

21

keystream Decrypted!

slide-22
SLIDE 22

Overview

  • 1. Key reinstallation in

4-way handshake

  • 2. Misconceptions

and remarks

  • 3. Steps to improve

Wi-Fi security?

slide-23
SLIDE 23

Misconceptions I

No useful data is transmitted after handshake › Trigger handshakes during TCP connection Difficult to derive keystream › Already have 82 bytes from encrypted Msg4 Need high signal strength to get MitM › Use channel switch announcements, BSS Transition Requests, jammers, …

slide-24
SLIDE 24

Misconceptions II

Need to be close to network › Can use special antenna2,3 Using (AES-)CCMP mitigates the attack › No, still allows decryption & replay of frames Enterprise networks (802.1x) are not vulnerable › Also use 4-way handshake and are affected

slide-25
SLIDE 25

Misconceptions III

You need the password to perform attacks › Nope. Then you could decrypt all already … Updating only client or AP is sufficient › Both vulnerable clients and vulnerable APs need to apply patches Attack complexity is hard › Script only needs to be written once

slide-26
SLIDE 26

“Attacks only get better, they never get worse.”

— Bruce Schneier

slide-27
SLIDE 27

Overview

  • 1. Key reinstallation in

4-way handshake

  • 2. Misconceptions

and remarks

  • 3. Steps to improve

Wi-Fi security?

slide-28
SLIDE 28

Countermeasures

Problem: many clients will not get updated Solution: AP can prevent attacks on clients! › Don’t retransmit message 3/4 › Don’t retransmit group message 1/2 However: › Impact on reliability currently unclear › Clients still vulnerable when connected to other unmodified APs

28

slide-29
SLIDE 29

Fuzzing

Basic fuzzing as part of device certification › Test against key reinstallations › Fuzzing length fields: avoid well-known bugs › Plaintext frames rejected if encryption enabled? › … Advanced fuzzing of widely used tools: › Can do more costly fuzzing on specific tools › Make these fuzzing tools open source

slide-30
SLIDE 30

“Millions of dollars saved (for Microsoft and the world).”

Patrice Godefroid, Microsoft Research

slide-31
SLIDE 31

Other recommendations

Not Wi-Fi Alliance task, but … › Make standards easier to access. Just a download link, nothing on top. › Anyone should be able to easily follow

  • discussions. Mailing list?
slide-32
SLIDE 32

Need open source firmware

Code is getting more closed: › Functionality is offloaded to closed firmware › E.g. 4-way handshake is being offloaded › We cannot trust this code! At least open source security critical parts? › Catch problems earlier & get help

slide-33
SLIDE 33

Long-term: formal verification

Programming is hard. Are patches correct? › Missed attack against wpa_supplicant 2.6 Collaboration with academia: › Create formal and precise state machines › Formal verification of core code › E.g. prove correctness of open source tools

slide-34
SLIDE 34

Questions?

krackattacks.com

Thank you!

slide-35
SLIDE 35

References

  • 1. C. He, M. Sundararajan, A. Datta, A. Derek, and J. Mitchell.

A Modular Correctness Proof of IEEE 802.11i and TLS. In CCS, 2005.

  • 2. S. Antakis, M. van Cuijk, and J. Stemmer. Wardriving -

Building A Yagi Pringles Antenna. 2008.

  • 3. M. Parkinson. Designer Cantenna. 2012. Retrieved 23

October 2017 from https://www.mattparkinson.eu/designer- cantenna/

3 5