34C3 - KRACKing WPA2 by Forcing Nonce Reuse

34c3 intro

Herald: I'm really happy to be able to
introduce our next speaker. Mathy is a

postdoc in Network Security and Applied
Crypto. He took part in discovering and

implementing quite some attacks in this
field and especially in the wireless

sector. And today he will show us, that all
our Wi-Fi devices are vulnerable.

Especially the ones with Linux and
Android. So, I don't want to go into the

technical details, because he would do
this and I think if you're interested in

even learning more about it, he even linked
the research paper as well as the scripts

and a website for this attack in the
Fahrplan. So for now, give a big round of

applause for Mathy Vanhoef!

applause

Mathy Vanhoef: Ok, thank you for the
introduction and thank you all for

attending the talk, even though it's
already a bit late in the evening. Thank

you CCC for allowing me to speak here. So
today I'm going to talk about my research

on WPA2 and you probably have already
heard about this under the name of KRACK

attacks. Now, the history of this research
is quite interesting, because during my PhD,

I was already researching the security of
wireless networks and during my PhD

defense last year, when I was finishing up
on writing my thesis, one of the jury

members in my PhD asked: "Hey, you're
recommending WPA2 with AES in your thesis,

but are you sure that's really a secure
solution?" And last year my answer was:

"Yeah, I mean it seems secure. It has been
around for more than a decade and if we

ignore some brute-force attacks against
the password, if you select a secure

password, then there are no real weaknesses
that are known. On top of that, there are

also mathematical proofs that state that
if you have the 4-way handshake on the

encryption algorithm, that it's supposed to
be secure. Unfortunately, a year later I

was staring at some OpenBSD code. In
particular, I was looking at this function

called ic_set_key. The details aren't
important here yet, but this key installs

the encryption key for use by the driver,
so frames get encrypted and I was

wondering, what
would happen if this function is called

twice. And I was thinking, like, will it
reinstall the key and what will happen

when you reinstall the key? And it turns
out that answering this question led to

the attack I found and as you know by now,
this uncovered the flaw in WPA2. So in a

sense, this talk is all about how I gave
the wrong answer during my PhD defense. To

explain the attack, I will illustrate it
against the 4-way handshake. After that I

will discuss the impact of the attack in
practice, then I will go over some

common misconceptions that have been
floating around the internet and finally I

will discuss some lessons that we can
learn from this

research and from our findings. Let's get
started with explaining the attack against

the 4-way handshake and the first
question I have to answer here is: what

exactly is this 4-way handshake? And the
4-way handshake is executed whenever

you connect to a protected Wi-Fi network.
It's used when you connect to your home

Wi-Fi network where you just have a pre-
shared password, but it's also used in

enterprise network-networks where you for
example have a username and a password to

log in.
The purpose of this handshake is to verify

that you possess the correct credentials
in order to connect to the network and at

the same time, this 4-way handshake
negotiates a fresh session key that will

be used to encrypt data frames.
This session key is called the PTK, the

pairwise temporal key. And as I mentioned,
this handshake seemed to be really secure

because for over a decade, no attacks have
been found against it, assuming that a

secure password is being used, and on top
of that, the 4-way handshake was

formally proven to be secure and the
encryption algorithm that is used after

the 4-way handshake, which generally
is AES CCMP, that was also formally

proven to be secure.
Yet somehow we did find an attack even

though we have all these formal proofs,
even though this protocol has been around

for that long. So what went
wrong?

To explain this, I'm going to explain how
the 4-way handshake works, using this

specific example. So let's say, we have the
client on the right here that wants to

connect to the access point on the left.
Now, in order to start the 4-way

handshake, there first needs to be some
preshared secrets between the client on

the access point and if you have a network
at home, this preshared secret is basically

the password of the network. But if you
have an enterprise or a more professional

network, then - where you for example have
to log in using a username and a password -

then first 802.1x authentication algorithm
is executed, which in practice is commonly

some form of RADIUS authentication.
The details of that are not important.

What's important here is the result.
Namely, after this authentication phase

there is a shared secret between the
client and the access point.

And once we have this shared secret, we
can execute the 4-way handshake. What

the first two messages in the 4-way
handshake do, is they transport a random

number between both devices.
So in particular, the access point will

generate a random number called the access
point nonce, the ANonce, and it will

transport that to the client.
Then in reaction to that, the client will

generate its own random number called the
supplicant nonce - and supplicant is

basically a synonym for client - and it
will send that random number, the SNonce,

to the access point in the second message
of the handshake. Once both devices have

each other's random number, then we can
derive this unique per session key.

How that key is derived, is fairly simple: we
take the preshared key, that is known

between these two devices, we combine that
with both of these random numbers and the

result is the PTK, this fresh encryption
key, that will later be used to encrypt

data frames.
Now, I want to clarify one thing, and you

might have heard about this research under
the name 'key reinstallation attacks:

forcing nonce reuse in WPA2'.
I want to highlight here that the nonce

reuse does not refer to the nonce reuse
about the ANonce or SNonce during the

4-way handshake. So here we're going [to]
assume, that these ANonce and SNonce, that

they are random and not predictable. The
nonce reuse refers to nonce reuse that

will happen during the encryption
algorithm, which I will explain in a bit.

That's it for the first stage of the 4-way
handshake. The second stage of the 4-way

handshake, a bit simplified, it basically
confirms that both parties negotiate at

the same PTK, the same encryption key. And
in particular, the access point will send

Message 3 to the client. The client will
verify the authenticity of that frame and

if everything looks ok, the client will
reply using Msg4 to the access point.

Once these four messages have been
exchanged, both the client on the access

point will install the PTK for use by the
driver, so now data frames can be exchanged

and these data frames will be encrypted.
Ok, so now we covered the 4-way

handshake, we know the highlight of how it
works. Now the final thing I need to

explain, before we can get to the details
of the attack, is: How does encryption work

in a Wi-Fi network? And to explain this,
let's take the example here, where we want

to send some plain text data from, e.g.,
from the client to the access

point. Then the first thing that will
happen, is that we will take the PTK and

the fresh session key, that the 4-way
handshake just negotiated and we will

combine that with a packet number. And here,
this packet number is called a nonce.

The packet number is incremented by 1 for
every frame, that is transmitted and the ID

here is, that by combining the session key
with the packet number we get a unique per

packet key for every packet that we want
to transmit.

The way the encryption now works is fairly
simple, we feed this per packet key as

input to a stream cipher. We get us output
some key stream, we simply XOR that key

stream with the plaintext and the result
is the encrypted data, the ciphertext.

Now we prepense a plaintext header with
some metadata and also the packet number,

the nonce value, that we used, so the
receiver will be able to decrypt the

packet. Essentially, this is just a stream
cipher, where a nonce is used to always

derive a unique per packet key. Now there's
one essential requirements in this

encryption key.
That is, that under a particular session

key, a nonce value should only be used once,
because if you ever reuse a nonce value,

you will generate the same per packet key.
You will generate the same key stream and

this will allow you to decrypt packets,
that are sent and depending on the

specific stream cipher that is being used,
it will also allow you to forge frames.

clears his throat

Now the question here is: Is this nonce
value indeed only used once? And we already

know, that it is incremented by one for
every packet that is transmitted, so the

only question that remains is: To what
value is this packet number initialized?

And the answer is quite simple: when the
PTK is installed, this transmit nonce is

initialized to 0.
At first sight, this makes a lot of sense.

I mean, you initiate that number to 0,
you increment it by one for every packet,

so surely this nonce is a specific nonce
value, is only used once.

Unfortunately, this is not the case. And the
reason this nonce value or a particular

nonce value is sometimes used more than
once, is because we can force

reinstallations of the PTK and those
reinstallations will again reset the nonce

to 0 and then nonce value will be reused.
So, how can we force these key

reinstallations as an attacker?
Let's again take the example where we have

a client on the left, that wants to connect
to the access point on the right and in

this case, we also have an attacker that
sits in the middle and this attacker will

assume a so-called channel-based man-in-
the-middle position and in this-man-in-the-

middle position, the adversary isn't yet
able to decrypt any packets. This man-in-

the-middle position is purely there, so we
can reliably block packets from arriving

and we can reorder the packet and so on. We
are not breaking encryption yet. And the

way we obtain this man-in-the-middle
position is, we simply take all the frames

that the access point which, e.g.,
is on Channel 6, we take all the frames

that it is broadcasting and as an attacker,
we capture them and we rebroadcast them, we

retransmit them on a different channel,
e.g. Channel 1. So we are effectively

cloning the real access point on a rogue
channel and then we force the victim into

connecting to this rogue access point on
this different channel.

So let's assume now that the attacker
obtains this position, this man-in-the-

middle position and the first stage of the
4-way handshake, we don't modify any

frames at all. So e.g. if the
client is using 802.1x authentication, we

simply forward all the frames between
these two different channels and we do the

same thing with the first three messages
of the 4-way handshake, we simply

forward them unmodified. Where the attack
starts, is if the client sends Msg4

of the 4-way handshake. Instead of
forwarding this message to the access

point, we don't forward it, which in our
situation is equivalent to blocking the

message from arriving at the access point.
Now what's interesting in this situation,

is that from the perspective of the client,
the handshake now successfully completed.

After all, it received Msg3, it
replied using Msg4 and it thinks that

the handshake is done, meaning it now
installs the encryption key and installs

the PTK for use. So, let's make some space
here - the client thinks, that the handshake

was completed, it has installed the key,
but the access point hasn't received

Msg4 yet and the access point will
try to recover from this situation and it

will do that by retransmitting a new
Msg3. And as the - as we, as the

attacker, will forward this message to the
client, the client will accept this

retransmitted Msg3 and then the Wi-Fi
standard says, that if you receive a

retransmitted Msg3, you will reply
using a new Msg4. After that you will

also install the encryption key again. Now,
one remark that I want to make here, is

that, when we receive the retransmitted
Msg3, we reply using a new Msg4,

however, this Msg4 will be already
encrypted at the link layer and the reason

it's already encrypted, is because these
handshake messages are normal data frames

and well, we already installed the
encryption key to encrypt data frames. So

nearly all implementations we tested, will
send Msg4, the retransmitted Msg4,

in an encrypted fashion. Now, I want to
remark here, that the Wi-Fi standard

actually demands that Msg4, if it is
retransmitted, should be sent in plain text,

so according to the specification, this
shouldn't happen. But nearly all

implementations we tested, sent a
retransmitted Msg3 using encryption,

and we will abuse this observation later.
So as I mentioned, after the client

receives a retransmitted Msg3, it'll
reply using Msg4, it will again

install the encryption key, and as a
result of that, this transmit nonce will be

reset, which means, that if the client now
sends another data frame, it will again

use this nonce value of 1 to encrypt the
frame, meaning we have nonce reuse, and we

have key stream reuse, meaning we can now
try to abuse this to decrypt the data

frame.
Now, how are we precisely going to abuse

this, because we do somehow need to
recover the key stream that was used? And

we go back to our observation, that we have
a Msg4 here, that is initially sent in

plain text, and a retransmission of
Msg4 is later sent in an encrypted

fashion. Now, there is a small difference
between these two messages, but

essentially we have a message sent in
plaintext, and we have a message sent

encrypted, and all we need to do, is we
need to XOR these two messages and we have

the key stream corresponding to the nonce
value of 1.

This data frame here at the bottom, it
also uses nonce value of 1, meaning it

uses the exact same key stream, so we XOR
this packet with the key stream and there

you go: We decrypted the packets and we
have now defeated WPA2. So...

Applause
Thank you. So, that describes the attack

against the 4-way handshake. And the
4-way handshake is not the only Wi-Fi

handshake that is vulnerable. There are
also other handshakes which can be

attacked in a similar manner, but I'm not
going to explain all of them in detail. If

you want all the nitty-gritty details, I'm
going to refer you to our academic paper.

Here, I'm just going to discuss more the
high-level concepts and the ideas behind

the attack. So, e.g., one handshake
that is also vulnerable, is the group key

handshake, and that handshake is used to
transport the group key from the access

point to the client. And that key is used
to encrypt broadcast and multicast

traffic. Then we also have the FT
handshake. The FT handshake is used, when

you roam from one access point to another
access point of the same Wi-Fi network.

It's used so you can quickly switch
from one access point to another without

a long timeout. And finally, another
handshake that's also vulnerable is the

PeerKey handshake, and that's used when
two clients want to communicate directly

with one another. Okay, so I'm now going
to discuss in a bit more detail, what the

practical impact of our attacks are. And
I'm first going to start with the general

impact that a key reinstallation attack
has. So, let's assume we have a device

that's vulnerable. This device can either
be a client device, e.g. it can be

a smartphone, or a laptop, or these days
it can even be a toaster. They have Wi-Fi

as well. Or it can also be an access
point. So if a client or access point is

vulnerable to our key reinstallation
attack, the first thing that generally

always happens, if this device ever sends
encrypted data frames, we can force it to

reuse the nonce, which in turn we can use
to decrypt frames. But that's not the only

thing we can do when a device is vulnerable.
Another thing we can do, is we can replay

encrypted frames sent towards this device.
Now, why is that the case? That's because

if a key is reinstalled, not only is this
transmit nonce reset to 0, but another

parameter, which is called the replay
counter, it is also reset to 0. And this

replay counter, as the name implies,
it's used to detect retransmissions, or

it's used to detect malicious replays. If
this counter is reset, we can also replay

frames towards a vulnerable device. So,
that's the general impact of a key

reinstallation attack, but there are a lot
of other factors which also influence the

exact impact of the attack, and one of the
things that probably has the biggest

influence, is the encryptions cipher that
is being used. So, e.g., these days

it is quite common that Wi-Fi networks use
AES CCMP. It's the most widely used

encryption algorithm in Wi-Fi networks.
Against this algorithm, the impact in a

sense stays limited to only decrypting and
replaying frames. It's not possible to

abuse our key reinstallation attack to now
forge frames. And really, we got lucky

here, because this is the most widely used
cipher, and against this cipher we cannot

start to forge frames. Because, if we
would have been using the older encryption

algorithm, which is WPA TKIP, against that
algorithm, we would be able to recover the

Message Integrity Check key, which is
basically just a fancy word for the

authentication key. And once we have that
authentication key, we would be able to

forge frames that appear to be sent by the
device under attack. Interestingly, lately

there's also been a new encryption
algorithm that is being introduced, and

that algorithm is
called GCMP. It's fairly new, so only a

few devices currently support it, and
currently it is being rolled out under the

name of WiGig. Against this algorithm, the
impact of a key reinstallation attack is

really the worst, because here we can
again recover the authentication key, but

when we use GCMP, the same authentication
key is used in both communication

directions. So against GCMP, we would be
able to forge frames that are sent from

the client to the access point and also
forge frames that appear to be sent

from the access point to the client, while
for the WPA-TKIP algorithm, we would only

be able to forge frames, that appear to be
sent by the device that is under attack.

So, my opinion - this is a bit surprising,
because GCMP is the latest encryption

algorithm that is defined in the Wi-Fi
standard, yet the impact against it would

be the highest. So, this is also why I
think we got lucky here, because if we

would have found the attack, say maybe
five or ten years later, and everyone

would be using this algorithm, the impact
would have been a lot worse. Another thing

that influences the impact of the attack
is, which specific handshake we are

attacking. For example, if we attack the
group key handshake, then the only thing

we can do is, we can
only replay, broadcast or

multicast frames. Now, why is that the
case? Why can't we decrypt broadcast or

multicast frames, if a key reinstallation
occurs? And the reason is, that if we

attack the group key handshake, we are
attacking the client, and the client is

never sending actual encrypted broadcast
frames, so will never reuse the transmit

nonce when it encrypts frames, because
it's never encrypting frames. Now, why is

it, that the client never sends real
encrypted broadcast frames? Well, the

reason is quite simple. Let's say, we have
the network layout shown here and the

client on the left wants to send a
broadcast frames to all the other clients.

Now, what happens here, is that this client
will send the data frame it wants to

broadcast as a Unicast frame to the access
point only, meaning it won't encrypt it

yet under the group key. It's the access
points that will broadcast this frame to

all connected clients, and only the access
point will then encrypt it using the group

key, and this is to assure that all
clients

within range of the access point will
receive this broadcast message. Now, for

us, this means that only the access point
is transmitting real encrypted broadcast

frames, and in the group key handshake we
cannot attack the access point. We are

only attacking the client, meaning in
practice, we can only replay broadcast

frames to the client, at least if we are
targeting the group key handshake. So,

really, the impact is limited in practice
if we attack this handshake, because

generally, replaying broadcast data doesn't
have a high impact. Though, I do want to

note, that some home automation systems use
broadcast traffic to, e.g., send

commands to turn the device on or off,
e.g. to turn your fridge on, or to turn

lights on or off, so although the
impact of replaying broadcast frame is

low, there are situations in practice,
where it does have some impact, but it

really depends on your network setup and
the devices that you use. So, the other

handshake that is vulnerable, is the 4-
way handshake, but we already discussed

that. Against a 4-way handshake we can
attack the clients and the impact, is that

we can replay and decrypt frames, and
depending on the encryption algorithm

being used, we can possibly forge frames
as well. The situation is a lot more

interesting for the FT handshake, though.
And remember, this handshake is used, when

you roam from one access point to another
of the same network. Against the FT

handshake, it's not the clients that we
can attack, but here we can attack the

access point. And on top of that, when
attacking the FT handshake, we no longer

need this man-in-the-middle position. Now,
why is that the case? Well, let's again

explain this using our common example,
where a client wants to connect and where

it is executing the FT handshake. And at a
high level, the FT handshake is the same

as the 4-way handshake, meaning you
also have four frames that are

transmitted, but the big difference here
is, that with the FT handshake it's the

client that sends the first message
in the handshake, while for the 4-way

handshake it was the access point that
sends the first message. So, the handshake

is practically the same as the 4-way
handshake, meaning, initially we have two

messages that transport these random
numbers, these nonces, between both

devices. Then, both these endpoints can
generate the fresh encryption key. Then

the last two frames, they are again used
to confirm that both parties negotiated

the same encryption key. Now, I want to go
in a bit more detail here on this last

phase, and what happens here, is that the
third frame of the handshake is now sent

from the client to the access point and
that is a reassociation request. And after

the access point receives this frame, it
will reply using a reassociation response

frame and it will install the encryption
key. Once it has installed the encryption

key, it can of course start sending
encrypted data frames. So, let's again

make some room here. What we can now do
as an attacker, is we can take this

reassociation request that the client
previously transmitted, and we can simply

replay it. That's because in the FT
handshake, there is no replay protection

against messages of the handshake. So we
can just take that frame, we can send it

again to the access point. The access
point will receive it, it will accept it,

and it will reply using a reassociation
response. Now, so far this is not a

problem. The problem here is, that again
the access point will reinstall the

encryption key, and here it goes wrong
because we are reinstalling this

encryption key. The transmit nonce is
again reset to 0, meaning if we now send

the data frame again, the nonce value of 1
is used to encrypt these data frames,

meaning the same key stream is used,
meaning we can start applying the same

tricks to first derive some known key
stream and to then abuse that to attack

the handshake. So, I want to highlight
here a few things. And the first is, the

reason why we don't need a man-in-the-
middle position, is because handshake

messages in
the FT handshake, they are not protected

against replays, while in the 4-way
handshake, every handshake messages

contains a sequence counter, where the
receiver uses the sequence counter to

detect replays, but for the FT handshake
that's not the case, so we can just take

these messages, we can replay them, and we
don't need a man-in-the-middle position to

block packets and to trigger
retransmissions. Ok, so that's the

explanation for the FT handshake. Another
factor that can influence the impacts of

our attack in practice, is which operating
system and which device precisely we are

attacking. And in particular, we see that
iOS and Windows, they are not vulnerable

against attacks against a 4-way
handshake. And why is that the case? Well,

that's because these two devices don't
really follow the standard, and they don't

accept retransmissions of Msg3,
meaning we cannot abuse these

retransmissions of Msg3 to trigger
these key reinstallations.

Now, I want to make two remarks
here. And the first one is, that

against these devices we can still attack
the group key handshake. And particularly

when looking at iOS, if we look at iOS
version 11, it does implement the standard

properly and it does accept
retransmissions of Msg3, meaning that

one is vulnerable to attacks against the
4-way handshake. Now, Linux is not much

better, because if we look at the Wi-Fi client
that is used on Linux, and for example on

Android, it's called wpa_supplicant, and
against wpa_supplicant 2.4 and higher, we

notice that, if we try to perform a key
reinstallation attack, it won't reinstall

the secret key that was negotiated, but
no, instead it will suddenly install an

all-zero encryption key, and then it of
course becomes very trivial to start

decrypting data that this device is
transmitting. Now, why does this happen?

I can actually sort of understand why this
went wrong. So, I'm going to explain what

the implementation does wrong, to... why it
installs this all-zero key. And to explain

this, I'm going to assume that we have an
Android device that is connecting to an

access point. And we're going to zoom in a
bit on the implementation of the Android.

And we're going to look at two entities.
We're first going to look at wpa_supplicant,

which is represented by the
handshake icon here, and we're also going

to look at another entity, namely the
Linux kernel. It's the Linux kernel that

will be responsible for encrypting data
frames, and wpa_ supplicant will be

responsible for executing the 4-way handshake.
And of course we assume, that we as an

attacker are nearby, and we again have
this man-in-the-middle position. So, what

does an attacker have to do to cause this
installation of an all-zero encryption

key? Well, again, we simply let the first
phase of the 4-way handshake execute

normally, and when the access point sends
Msg3 of the 4-way handshake, we

forward that to the Android. Android will
reply using Msg4. And we will

again block Msg4 from arriving at the
access point.

Now, completely similar to the case with
the 4-way handshake, the client thinks that

the handshake now successfully completed,
meaning it will install the encryption

key. How it will install the encryption
key is as follows: It commands the Linux

kernel into installing the encryption key
in the driver. And the driver itself will

make a copy of the encryption key. And it
will store it locally. And the driver can

then encrypt frames. Now this means that
wpa_supplicant, which is just a user land

program, no longer needs to store the
encryption key, meaning it will clear it

from memory. What will happen now, if we
continue with the attack, is that the

access point will retransmit Msg3,
because it did not receive Msg4. The

client will again happily accept this
retransmitted Msg3 and reply using

Msg4. And again it will instruct the
Linux kernel saying "Hey, please install

this encryption key that is located at
this address in the memory." But of

course, that memory is now all zeros,
because that key has just been cleared

from memory. So,
now it's basically commanding the Linux

kernel into installing an all-zero
encryption key. And the Linux kernel and

driver will happily obey this command and
they will install an all-zero encryption

key, meaning at this point, all the data
that the client is sending, is encrypted

using a known key, so we can easily
decrypt all the traffic, and of course we

can also send any traffic we want to the
client. Basically, we are now a rogue

access point and we can manipulate the
traffic of the client as we wish.

Applause
MV: Thank you. So, after this you might be

wondering, "Well, gee, is my device
vulnerable?" And you can test your own

device using the following script. It's on
github. I have tested the script on Kali

Linux, on Arch Linux, and also on Ubuntu,
so I could recommend using one of these

distributions, and I also recommend to use
a Wi-Fi dongle that we or someone else has

tested ourselves, because we noticed that
if you use our testing scripts with some

older
Wi-Fi devices, then there are some bugs in

these Wi-Fi devices which cause our
scripts to fail. And one way to also

prevent our scripts to fail, is to disable
hardware encryption. Now, how you should do

that is also explained on this page. Using
these scripts, you can test both your

client devices, you can test against
attacks against the 4-way handshake,

the group key handshake, and there's also
a script to test the access point, whether

it's vulnerable against attacks against
the FT handshake. Now, if you're going to

try to see which devices are vulnerable,
you are most likely going to see that

quite some clients are still vulnerable to
our attacks. Luckily, we can modify the

access point to prevent attacks against
the client. In particular, we can make

additional modifications to the access
point, such that the access points never

retransmits Msg3 of the 4-way
handshake, and that it also never

retransmits the first message of the group
key handshake. And if we do that, then

clients that are connected to such a
modified access points, they are no longer

vulnerable against most attacks. There are

still some edge cases where the device is
vulnerable, but these have a very low

impact. So, if we modify an access point
in this way, then connected clients are no

longer vulnerable. One downside here is,
that because we are no longer

retransmitting certain messages, it could
be that especially in a noisy environment,

because we don't retransmit these messages
anymore, that the handshake may fail

because the reliability is now less. Now,
one thing I also want to remark here,

that... if you have a router, which is
vulnerable against our attack and a

vendor says "Hey, we patched our router,
so we patched our access point to defend

against attacks," then this does not mean
that this access point implements these

countermeasures. Because these
countermeasures, they are additional

modifications on top of the normal
patches to defend against the attack. So,

only if a vendor explicitly says that "Our
patches of the access point also prevent

attacks against clients," then, only if
they explicitly say that, are attacks

against the client also prevented. Ok,
so now I want to cover some misconceptions

that have been floating around the
internet. And the first one is, that some

people claim, if you only patch the
clients, or if you only patch the access

point, then you're fine. But that's not
the case. Because if you only patch the

client and the access point is vulnerable,
then we can still attack the access point.

If the access point only contains these
normal patches, the normal patches to

defend against attacks, then connected
clients are also still vulnerable. So, as

I mentioned, connected clients are only
defended, if the access point contains

really extra modifications on top of the
default patches. Now, another common

misconception is, that some people might
say "But, yeah, it's a cool attack, but

you have to be close to the network in
order to pull off these attacks."

Unfortunately, that's not the case because
we can use special antenna. And this

special antenna, they can be made
really cheap out of, e.g. just a

tin can, and with this special antenna, we
can manipulate Wi-Fi traffic from up to,

say, 2 miles. And there are even leaked
NSA documents, where the NSA is able to

exploit a Wi-Fi network using other
attacks from up to 8 miles away. Now,

that's of course with a clear line of
sight, but still this shows that you don't

have to be physically close to the
network. You can still be relatively far

away. Another strange remark that I
sometimes hear, is that you need to be

connected to the network in order to pull
off these attacks, which would basically

mean, you need to know the password of the
network to carry out the attacks. But

that's not the case. As I mentioned,
during the attacks, you only need to be

close enough. You need to be able to
manipulate some encrypted packets. But you

don't need to know anything about the
network. You simply need to know the

network is there and there's a vulnerable
client and access point and then you can

start attacking them. One remark that I
can understand, is that some people

say that "Yeah, Ok, you can attack these
handshakes, and you can decrypt data that

is sent right after these handshakes, but
generally right after you connect to an

Wi-Fi network, you're not really sending
interesting data, because at that point

your device is sending e.g. ARP
requests, or it's sending DHCP requests,

or is just creating TCP connections. But
no useful information is transmitted at

this time." Unfortunately, at least for a
defender, this is again not true. Because,

what we can do as an attacker is, we can
first let the client connect blackout out

manipulating any traffic. The client, the
victim, will then, e.g. start

browsing the internet, start
opening TCP connections, and in the middle

of that, while the victim is e.g.
surfing the internet, we can

deauthenticate the client from the
network, and all operating system will

then immediately execute a new 4-way
handshake. And once that 4-way

handshake is then completed, it will
send all the buffered TCP packets again

to the access point and also in a reverse
direction. So, basically, what we as an

attacker can do, we can wait until we
expect the victim to send interesting

information. Then we deauthenticate the
victim. It will execute a new handshake.

And then we can decrypt the data that will
be transmitted right after that handshake.

Another thing that makes the attack
possibly hard, is that obtaining this

channel based man-in-the-middle is
difficult. For example, you might be

thinking that in order to force the
clients to connect to the rogue access

point, you need a stronger signal strength
than a real access point. But again,

that's not the case. And the reason this
is not the case, is because we can use

special Wi-Fi packets and so-called
channel switch announcements, which

command the client into switching to a
different Wi-Fi channel, and effectively

blackout to a rogue access point. So we don't
need a high signal strength, we can simply

command a victim into saying "Hey, switch
to this channel and connect to our access

point." And these frames are not
authenticated, so we can just forge them

as an attacker. Another thing you might
say, that the complexity of the attack is

hard, meaning it requires some expertise
to implement this. And this is true. You

do need to know a bit about Wi-Fi in order
to make a proof of concept reliable, but

as usual you only need to write this
attack once, and then people can use your

script in order to attack others. And this
is similar to, e.g., memory

corruption attacks, such as buffer
overflows or stack overflows. Writing the

proof of concept may be hard, but if you
then give it to someone else, or if you

put it in Metasploit or some other tool,
all the user has to do, is basically start

the script, and you can start attacking
people. One other misconception that I

sometimes encounter, is that people say "If
you use AES-CCMP, this mitigates the

attack." Again, unfortunately, this is not
true, because the only advantage of using

AES-CCMP is that
the attacker can no longer forge frames.

The attacker is still able to decrypt and
replay frames. And finally, the last

misconception is, that some people say that
enterprise networks aren't vulnerable,

because they e.g. don't execute
the 4-way handshake. But again,

unfortunately, that's wrong, because even
these networks use the 4-way handshake

and they can be attacked as well. So, then
you have some people that say "OK, WPA2 is

now completely broken. It's the end of the
world and we're all doomed." Let's not get

carried away, though. We can patch these
vulnerabilities in a backwards compatible

way. And as I illustrated here in my talk,
the impact also really depends on the

devices that you are using and your own
network setup. So, sometimes the impact is

actually really low, but of course
sometimes the impact can be very high,

e.g. if you have a Linux device, then
attacker can do what he or she wishes,

essentially. Now, for the last part of the
talk, I'm going to discuss some lessons

that we can learn from this attack and
also the research. I think one of the most

important and interesting observations -
it's also the reason why I really like

this attack myself - is that the 4-way
handshake was proven to be secure. The

encryption protocol, and in particular
AES, has also been proven as secure.

However, if we combine these two things,
then suddenly we lose all security. And

this is quite unfortunate. And what this
teaches us, is that even though individual

parts of a system were really investigated
and perhaps formally analyzed, we also

need to analyze the combination of these
different entities and models, and we also

need to prove that these combinations are
secure as well. And another way to look at

this, is that in the proof of the 4-way
handshake, the authors, they modeled the

handshake in a rather abstract way. And
their proofs, specifically, they did not

model retransmissions of handshake
messages. And that's one of the things we

abuse. So, on one hand we need to assure
that we also look

at the combinations of these different
entities, but we also need to assure that

the abstract models that we use reflect
reality. Another thing that we can learn,

is that we should keep the protocols and
also the implementations simple.

E.g., if we look at wpa_supplicant 2.6,
when we were studying this version

ourself, we thought it wasn't vulnerable
to key reinstallation attacks. However,

when we were notifying companies of the
vulnerabilities, another researcher found

an attack against this version which did
work. The reason we missed this attack

against version 2.6, is because
wpa_supplicant uses a fairly complex

implementation of the 4-way handshake
and the state machine is fairly complex to

reason about. And there are two ways to
combat this. The first is to keep the

protocol simple. The second way to combat
this, is to formally verify

implementations. Now of course, we cannot
formally verify all the code, but what we

can do is, really, these cryptographic
protocols which play a very important

role, at least we should pay enough
attention to that. What's also

interesting, is that I encountered a
document of the CIA which also agrees, that

complex implementations or protocols are
bad. Specifically, they have a document,

where the CIA advises people how to
properly implement backdoors, essentially,

and they're saying that "Yeah, if you want
to send data back to us, of course, use

encryption, but in that encryption
algorithm, don't enable re-key

functionality, because that enables
additional features of the encryption

algorithm. And these additional features,
they cause unnecessary complexity and that

generally leads to bugs." Another thing
that we can learn, is that the standard

needs to be specified rigorously and as
precisely as possible. Because the

original WPA2 standard, it was a bit fake.
It didn't really define a state machine.

Well, the state machine that it defined
says, what an implementation - sorry -

should do if it receives a message, but -
let's go back to the slides - but it

doesn't define what an implementation
should do when it receives an unexpected

message. So, it doesn't define the order,
in which messages should be accepted. Now,

there is an amendment of the Wi-Fi
standard which better defines how and when

to handle messages, but even that standard
is a bit fake. And I want to remark here

that because the original WPA2 standard
was a bit fake, I can forgive iOS and

Windows for deviating a bit from the
standard. Because the standard was

difficult to interpret correctly. Now, on
a bit of a related note, I want to briefly

mention a workshop that we are organizing,
which is exactly about how to implement

these security protocols properly, how to
e.g. fuzz security protocols, how

to prove that they are correct, how to
make sure that we specify them rigorously.

So, if you are working in this field, do
consider submitting to this. Now, the last

thing that I want to mention on what we
can learn from this research, is how we

can coordinate the disclosure of a
vulnerability like this. Because this is

not an ordinary vulnerability,
that is, just affects one

vendor, it really affects possibly every
Wi-Fi device that is around. So, how on

earth are you going to start notifying
companies? Who are you going to notify?

What would be the deadlines, and so on?
Well, I'm going to discuss a bit about the

strategy that we used, and what we used
first is... we first wanted to determine,

you know, is this really a widespread
issue? We wanted to be sure of that before

we started to notify a lot of companies.
And the way we tackled that problem is, we

first contacted a few selected vendors and
we told them that "Hey, we possibly found

this flaw in the WPA2 protocol, but we
weren't able to test your devices, but you

should check this out." And quite quickly
we got a few responses from vendors, saying

that "Yes, we looked at your attack and
indeed, some of our devices are

vulnerable," and this really confirmed to
us, that a device

that we didn't test ourself was
vulnerable to the attack that we found.

So, it confirmed that the issue is
widespread, and we also got a bit of

feedback on the report that we sent
towards them on the description of our

attack. So, at this point we were
convinced ourselves, that this really was a

flaw in the standard and that a lot of
companies will be affected. Then the next

question we had is, "Okay, who are we now
all going to notify?" We of course

notified the big names and the big
companies, but who else do we have to

notify? And at this point, our tactic was
to rely on a CERT team, specifically a

CERT from the US and they did all the
coordination for us.

But one other thing that you can do is,
that if you're not sure who all is

affected or what, who all the vendors are,
then you can just ask a vendor that you

contacted already for other
vendors, that also might be affected

by the bug that you found, e.g.
Now one thing that is more difficult here,

is that on one hand you want to notify as
much vendors as possibly, on the other hand

you also can't notify everyone because if
you are going to notify everyone, then the

chance of the details leaking, they become
close to one. Another difficult thing to

decide is, how long should you give time to
companies in order to patch this. And again,

here you're mixed between two decisions:
on one hand you can give give them a long

period to patch everything, but then again,
the risk of this details leasing... err,

leaking increase. On the other hand, if the
embargo period is too short, people won't

have time to patch it. So this is quite a
hard decision. In the end,

what we did is - and which I would
again do in the future - is, it's hard to

pick a deadline, but still do pick a
deadline to avoid any uncertainty and so

that people know, what to expect. And
finally, I want to thank CERT and ICASI

for helping with the coordination and you
also want to thank Cisco for some of the

advice that they give.
So, with that I can conclude the talk, so

what we discussed, is a flaw and the WPA2
standard itself and the most surprising

thing about this research is, that WPA2 was
proven to be correct, yet we still found

his attack after more than a decade.
And more than that, not only is this just a

theoretical attack, the attack has actual
impact and practice.

And finally, in order to defend against
this, you should update all your clients

and also check if your access points are
affected. So with that, thank you for your

attention and if there are any questions,
feel free to ask.

applause

Herald: So, do we have any questions?

There is mics everywhere, so please come
in front. And I think, we already have the

first question directly here in front on
mic number 1.

Mic1: You mentioned, that GCMP is most
vulnerable. Do you know if there's any

standardization going on, about switching
to nonce misuse resistant scheme like

AES-GCM, Synthetic Initialization Vector?
MV: Yes, so there have been

some proposals in order to make the
encryption algorithm defend against nonce

reuse. Now the impression I have, that this
is still a bit of ongoing research. So

there are proposals, where you have an
algorithm that you can use, but I'm not

aware of actual encryption protocols, e.g.
TLS or Wi-Fi, that are using them.

But they exist, but I... they're not yet being
really used.

Mic1: It is standardisation going on in
CFRG, so Crypto Forum Research Group in

IETF standardization, but I was asking about
Wi-Fi standardization, if they are planning

to use this? And [a] related question would be,
if you would use in AES-GCM instead of

the deterministic initialization vector,
there's a random IV possible, if you use

96 bit, then the impact wouldn't be
bounded.

MV: So to answer the first question: I'm
not aware of the Wi-Fi standard

from really modifying the standard to use
a nonce misuse resistant encryption

cipher. They are modifying the standard to
defend against key reinstallation attacks,

but I think they're not yet going to
incorporate a nonce misuse resistant

encryption cipher, because they still have
the impression that they're going to wait

probably a while and once that technology
is more mature they're going to use that.

If I understood your second question, you
also have encryption algorithms, where you

don't have deterministic nonce, but you
have a nonce, which for every encryption

operation e.g. is random.
Mic1: Actually in the GCM standard there

are two possibilities: one deterministic,
MV: Yeah.

Mic1: and the second random.
MV: So the risk of using a random

initialization vector is, that you may
have a bad random generator,

that it can go wrong there. On that, that
you still have nonce reuse, so even with a

randomly generated nonce it can
also go bad, but then there are different

attacks. And I think, there has been a
paper that analyzes a certain TLS

libraries, where they do find attacks, where
in that case the GCM algorithm can still

be attacked, not through key reinstallation
attacks, but because there is, because

basically the nonce isn't really random,
e.g. sometimes a bad implementation

always uses the same random nonce.
Person X: Um, direct answer...

Herald: Err, sorry,...
X: Direct answer to his question number

one: because he asked, whether there's
right now an approach to modify the

standard towards being resistant against
this attack, right now there is no IEEE

task group working on an amendment which
will fix this.

MV: Well, there is... they are working to
prevent the key reinstallation attack.

X: Well, there is no official
active task group right now.

MV: Okay that could be, but there are still
people working on that.

X: Yeah, they're working on that,
but no

task group, right?
MV: Ok. Thank you.

Herald: Okay thank you.
Here in number 3.

Mic3: Yes, thanks for your
amazing talk.

Just for my personal understanding:
could you briefly go back to

the slide with the 4-way
handshake, like, right in the beginning?

MV: Yup, so the attack or the handshake
itself?

Mic3: Yeah, yeah the attack.
MV: So let's go to this slide.

Mic3: Yeah so all you get from this, is the
keystream that is used to encrypt

the the Msg4, right,
that's all you get?

MV: Yes, but you can already use that to
start decrypting frames and what you can

do as an attacker, you have several options.
The first thing you can do is, you can keep

triggering new handshakes by
deauthenticating the client, so you can

always decrypt one packet at a time.
What you can also do is, you can wait with

sending this retransmitted Msg3
to the clients, because sometimes you know

the encrypted data that is sent. So you
know that a packet is an ARP request, you

know that the HTTP requests. You can capture
quite some packets where you know the

content, to derive some known key stream
and once you have that, you can forward

Msg3 to trigger a key
reinstallation and then you have collected

quite some key stream to be able to
decrypt several packets at a time. So you

can use tactics like that, you can rely on
the packet length to basically determine,

what the type of packet is, where you have
known plaintext and you can use that to

derive new key stream and there are a lot
of ways to play around with that.

Mic3: Yeah but, all you get here is the -
because the key stream that you get is

already being used immediately, because
it's being used to encrypt Msg4.

MV: Well, we know the content of Msg4

and we abuse, that Msg4 is
encrypted to derive known key stream and

we can then use that to encrypt data
frames, which we do not know and... we

should discuss this offline.
Mic3: Yeah.

Herald: Perhaps this is for later
discussion with more in detail. Now we

switch to number two... number four, I
think it is. Yeah, thanks.

Mic4: Yes. Great find really and an
awesome talk. Could you maybe elaborate a

bit on how to still use the advantage of
formal verification in the sense of, let's

say, the flaws that it has, it gives a very
false sense of security in your sense, how

can you still benefit from formal
verification?

MV: Well, I think the attitude we should
adopt is, that formal verification of code

or of algorithms increases the amount of
trust we can put into a program or into a

protocol, but it's not just because it's
formally verified that it's secure.

Perhaps one of the attitudes that people
had was: 'oh it's firmly verified, it must

be fine'. We should abandon that attitude
and instead we should say: "Ok, it's

formally verified but, you know, let's
check if the model they used reflects

reality. Let's see if the proof is correct"
and so on. So, we should still employ a

formal verification but we should just
treat it as additional evidence, that

something looks secure.
Herald: Ok, there's another question on mic 2

Mic2: The first part is on the slide
you're currently on. As far as I

understood it in the talk, the
retransmission of Msg4 is not

supposed to be encrypted by the standard.
MV: Correct.

Mic2: So if you follow the standards, you
shouldn't have a problem here.

MV: No, then you still have a problem,
because what you can then you do, is just

wait for a data packet where you know that
contents of, e.g.it can be an ARP

request, you can derive most fields of
that, it can be a DHCP request, it can be

be a TCP SYN packet, or it can be some
plain text HTML frames. E.g. there

has been work to fingerprint the length of
HTTP requests, to be able to determine

which page you are visiting, so purely
based on the length, we can determine the

contents of the website you are looking
for. We can then derive known plaintext

and basically there are a lot of ways to
predict the content of a frame, to then

derive known keystream and to then trigger
a key reinstallation attack to then abuse this.

Herald: Ok we have time for one last
question. Mic number 1?

Mic1: Um, so as far as I understood your
research, and so we, if we have like 11W

deployed in the network, we are still
vulnerable to the attack, because as 11W

specifies the encryption, I'm supposed by
this amendment, is also done by the

encryption use on the network like before,
so 11W is not really a way to secure

the network?
MV: Well, if I got it right, 11W is, one of

the things it does, is protect the
management's frames, if I'm correct?

Mic1: Yes.
MV: Yes.

MV: So using that does not defend against
these attacks.

Herald: Ok, I think there's still quite
details, where people are curious about,

because it's everybody starting this
question "as far as I understood". So I think,

this was a really nice comprehensive talk
and I want to thank you. And everybody who

has more questions, perhaps can find you
here and ask you more or have a look into

the paper, perhaps read everything in
detail there.

So, please another big round of applause
for Mathy and his amazing talk!

Thank you very much.
MV: Thank you!

applause

34c3 outro

subtitles created by c3subtitles.de
in the year 2018. Join, and help us!