WEBVTT
00:00:00.000 --> 00:00:16.620
34c3 intro
00:00:16.620 --> 00:00:23.720
Herald: I'm really happy to be able to
introduce our next speaker. Mathy is a
00:00:23.720 --> 00:00:30.180
postdoc in Network Security and Applied
Crypto. He took part in discovering and
00:00:30.180 --> 00:00:35.860
implementing quite some attacks in this
field and especially in the wireless
00:00:35.860 --> 00:00:43.490
sector. And today he will show us, that all
our Wi-Fi devices are vulnerable.
00:00:43.490 --> 00:00:49.120
Especially the ones with Linux and
Android. So, I don't want to go into the
00:00:49.120 --> 00:00:53.140
technical details, because he would do
this and I think if you're interested in
00:00:53.140 --> 00:00:57.960
even learning more about it, he even linked
the research paper as well as the scripts
00:00:57.960 --> 00:01:04.190
and a website for this attack in the
Fahrplan. So for now, give a big round of
00:01:04.190 --> 00:01:06.699
applause for Mathy Vanhoef!
00:01:06.699 --> 00:01:11.510
applause
00:01:11.510 --> 00:01:15.960
Mathy Vanhoef: Ok, thank you for the
introduction and thank you all for
00:01:15.960 --> 00:01:19.921
attending the talk, even though it's
already a bit late in the evening. Thank
00:01:19.921 --> 00:01:25.480
you CCC for allowing me to speak here. So
today I'm going to talk about my research
00:01:25.480 --> 00:01:30.750
on WPA2 and you probably have already
heard about this under the name of KRACK
00:01:30.750 --> 00:01:37.770
attacks. Now, the history of this research
is quite interesting, because during my PhD,
00:01:37.770 --> 00:01:44.490
I was already researching the security of
wireless networks and during my PhD
00:01:44.490 --> 00:01:50.840
defense last year, when I was finishing up
on writing my thesis, one of the jury
00:01:50.840 --> 00:01:57.230
members in my PhD asked: "Hey, you're
recommending WPA2 with AES in your thesis,
00:01:57.230 --> 00:02:03.390
but are you sure that's really a secure
solution?" And last year my answer was:
00:02:03.390 --> 00:02:08.229
"Yeah, I mean it seems secure. It has been
around for more than a decade and if we
00:02:08.229 --> 00:02:11.920
ignore some brute-force attacks against
the password, if you select a secure
00:02:11.920 --> 00:02:16.910
password, then there are no real weaknesses
that are known. On top of that, there are
00:02:16.910 --> 00:02:21.190
also mathematical proofs that state that
if you have the 4-way handshake on the
00:02:21.190 --> 00:02:27.490
encryption algorithm, that it's supposed to
be secure. Unfortunately, a year later I
00:02:27.490 --> 00:02:32.800
was staring at some OpenBSD code. In
particular, I was looking at this function
00:02:32.800 --> 00:02:39.440
called ic_set_key. The details aren't
important here yet, but this key installs
00:02:39.440 --> 00:02:44.470
the encryption key for use by the driver,
so frames get encrypted and I was
00:02:44.470 --> 00:02:48.240
wondering, what
would happen if this function is called
00:02:48.240 --> 00:02:53.459
twice. And I was thinking, like, will it
reinstall the key and what will happen
00:02:53.459 --> 00:02:58.380
when you reinstall the key? And it turns
out that answering this question led to
00:02:58.380 --> 00:03:06.540
the attack I found and as you know by now,
this uncovered the flaw in WPA2. So in a
00:03:06.540 --> 00:03:13.589
sense, this talk is all about how I gave
the wrong answer during my PhD defense. To
00:03:13.589 --> 00:03:19.590
explain the attack, I will illustrate it
against the 4-way handshake. After that I
00:03:19.590 --> 00:03:24.470
will discuss the impact of the attack in
practice, then I will go over some
00:03:24.470 --> 00:03:28.720
common misconceptions that have been
floating around the internet and finally I
00:03:28.720 --> 00:03:31.940
will discuss some lessons that we can
learn from this
00:03:31.940 --> 00:03:37.819
research and from our findings. Let's get
started with explaining the attack against
00:03:37.819 --> 00:03:42.290
the 4-way handshake and the first
question I have to answer here is: what
00:03:42.290 --> 00:03:48.740
exactly is this 4-way handshake? And the
4-way handshake is executed whenever
00:03:48.740 --> 00:03:53.349
you connect to a protected Wi-Fi network.
It's used when you connect to your home
00:03:53.349 --> 00:03:57.290
Wi-Fi network where you just have a pre-
shared password, but it's also used in
00:03:57.290 --> 00:04:02.489
enterprise network-networks where you for
example have a username and a password to
00:04:02.489 --> 00:04:06.239
log in.
The purpose of this handshake is to verify
00:04:06.239 --> 00:04:10.800
that you possess the correct credentials
in order to connect to the network and at
00:04:10.800 --> 00:04:15.250
the same time, this 4-way handshake
negotiates a fresh session key that will
00:04:15.250 --> 00:04:19.979
be used to encrypt data frames.
This session key is called the PTK, the
00:04:19.979 --> 00:04:27.610
pairwise temporal key. And as I mentioned,
this handshake seemed to be really secure
00:04:27.610 --> 00:04:33.769
because for over a decade, no attacks have
been found against it, assuming that a
00:04:33.769 --> 00:04:40.020
secure password is being used, and on top
of that, the 4-way handshake was
00:04:40.020 --> 00:04:43.729
formally proven to be secure and the
encryption algorithm that is used after
00:04:43.729 --> 00:04:48.659
the 4-way handshake, which generally
is AES CCMP, that was also formally
00:04:48.659 --> 00:04:53.550
proven to be secure.
Yet somehow we did find an attack even
00:04:53.550 --> 00:04:57.199
though we have all these formal proofs,
even though this protocol has been around
00:04:57.199 --> 00:05:01.230
for that long. So what went
wrong?
00:05:01.230 --> 00:05:08.050
To explain this, I'm going to explain how
the 4-way handshake works, using this
00:05:08.050 --> 00:05:12.550
specific example. So let's say, we have the
client on the right here that wants to
00:05:12.550 --> 00:05:17.710
connect to the access point on the left.
Now, in order to start the 4-way
00:05:17.710 --> 00:05:22.020
handshake, there first needs to be some
preshared secrets between the client on
00:05:22.020 --> 00:05:26.749
the access point and if you have a network
at home, this preshared secret is basically
00:05:26.749 --> 00:05:30.750
the password of the network. But if you
have an enterprise or a more professional
00:05:30.750 --> 00:05:35.649
network, then - where you for example have
to log in using a username and a password -
00:05:35.649 --> 00:05:41.789
then first 802.1x authentication algorithm
is executed, which in practice is commonly
00:05:41.789 --> 00:05:47.079
some form of RADIUS authentication.
The details of that are not important.
00:05:47.079 --> 00:05:51.180
What's important here is the result.
Namely, after this authentication phase
00:05:51.180 --> 00:05:55.509
there is a shared secret between the
client and the access point.
00:05:55.509 --> 00:06:01.460
And once we have this shared secret, we
can execute the 4-way handshake. What
00:06:01.460 --> 00:06:06.879
the first two messages in the 4-way
handshake do, is they transport a random
00:06:06.879 --> 00:06:11.099
number between both devices.
So in particular, the access point will
00:06:11.099 --> 00:06:15.569
generate a random number called the access
point nonce, the ANonce, and it will
00:06:15.569 --> 00:06:20.379
transport that to the client.
Then in reaction to that, the client will
00:06:20.379 --> 00:06:24.150
generate its own random number called the
supplicant nonce - and supplicant is
00:06:24.150 --> 00:06:29.119
basically a synonym for client - and it
will send that random number, the SNonce,
00:06:29.119 --> 00:06:36.550
to the access point in the second message
of the handshake. Once both devices have
00:06:36.550 --> 00:06:41.690
each other's random number, then we can
derive this unique per session key.
00:06:41.690 --> 00:06:46.860
How that key is derived, is fairly simple: we
take the preshared key, that is known
00:06:46.860 --> 00:06:51.669
between these two devices, we combine that
with both of these random numbers and the
00:06:51.669 --> 00:06:56.849
result is the PTK, this fresh encryption
key, that will later be used to encrypt
00:06:56.849 --> 00:07:02.930
data frames.
Now, I want to clarify one thing, and you
00:07:02.930 --> 00:07:07.849
might have heard about this research under
the name 'key reinstallation attacks:
00:07:07.849 --> 00:07:13.610
forcing nonce reuse in WPA2'.
I want to highlight here that the nonce
00:07:13.610 --> 00:07:17.990
reuse does not refer to the nonce reuse
about the ANonce or SNonce during the
00:07:17.990 --> 00:07:22.479
4-way handshake. So here we're going [to]
assume, that these ANonce and SNonce, that
00:07:22.479 --> 00:07:27.249
they are random and not predictable. The
nonce reuse refers to nonce reuse that
00:07:27.249 --> 00:07:34.000
will happen during the encryption
algorithm, which I will explain in a bit.
00:07:34.000 --> 00:07:40.249
That's it for the first stage of the 4-way
handshake. The second stage of the 4-way
00:07:40.249 --> 00:07:47.429
handshake, a bit simplified, it basically
confirms that both parties negotiate at
00:07:47.429 --> 00:07:51.999
the same PTK, the same encryption key. And
in particular, the access point will send
00:07:51.999 --> 00:07:56.909
Message 3 to the client. The client will
verify the authenticity of that frame and
00:07:56.909 --> 00:08:04.309
if everything looks ok, the client will
reply using Msg4 to the access point.
00:08:04.309 --> 00:08:08.739
Once these four messages have been
exchanged, both the client on the access
00:08:08.739 --> 00:08:15.569
point will install the PTK for use by the
driver, so now data frames can be exchanged
00:08:15.569 --> 00:08:22.139
and these data frames will be encrypted.
Ok, so now we covered the 4-way
00:08:22.139 --> 00:08:29.010
handshake, we know the highlight of how it
works. Now the final thing I need to
00:08:29.010 --> 00:08:34.639
explain, before we can get to the details
of the attack, is: How does encryption work
00:08:34.639 --> 00:08:40.059
in a Wi-Fi network? And to explain this,
let's take the example here, where we want
00:08:40.059 --> 00:08:44.510
to send some plain text data from, e.g.,
from the client to the access
00:08:44.510 --> 00:08:49.399
point. Then the first thing that will
happen, is that we will take the PTK and
00:08:49.399 --> 00:08:53.309
the fresh session key, that the 4-way
handshake just negotiated and we will
00:08:53.309 --> 00:08:59.940
combine that with a packet number. And here,
this packet number is called a nonce.
00:08:59.940 --> 00:09:04.750
The packet number is incremented by 1 for
every frame, that is transmitted and the ID
00:09:04.750 --> 00:09:09.579
here is, that by combining the session key
with the packet number we get a unique per
00:09:09.579 --> 00:09:15.930
packet key for every packet that we want
to transmit.
00:09:15.930 --> 00:09:20.329
The way the encryption now works is fairly
simple, we feed this per packet key as
00:09:20.329 --> 00:09:25.911
input to a stream cipher. We get us output
some key stream, we simply XOR that key
00:09:25.911 --> 00:09:31.610
stream with the plaintext and the result
is the encrypted data, the ciphertext.
00:09:31.610 --> 00:09:36.620
Now we prepense a plaintext header with
some metadata and also the packet number,
00:09:36.620 --> 00:09:40.479
the nonce value, that we used, so the
receiver will be able to decrypt the
00:09:40.479 --> 00:09:46.120
packet. Essentially, this is just a stream
cipher, where a nonce is used to always
00:09:46.120 --> 00:09:52.899
derive a unique per packet key. Now there's
one essential requirements in this
00:09:52.899 --> 00:09:58.000
encryption key.
That is, that under a particular session
00:09:58.000 --> 00:10:04.300
key, a nonce value should only be used once,
because if you ever reuse a nonce value,
00:10:04.300 --> 00:10:08.299
you will generate the same per packet key.
You will generate the same key stream and
00:10:08.299 --> 00:10:12.080
this will allow you to decrypt packets,
that are sent and depending on the
00:10:12.080 --> 00:10:19.359
specific stream cipher that is being used,
it will also allow you to forge frames.
00:10:19.359 --> 00:10:20.549
clears his throat
00:10:20.549 --> 00:10:28.040
Now the question here is: Is this nonce
value indeed only used once? And we already
00:10:28.040 --> 00:10:32.350
know, that it is incremented by one for
every packet that is transmitted, so the
00:10:32.350 --> 00:10:37.070
only question that remains is: To what
value is this packet number initialized?
00:10:37.070 --> 00:10:44.050
And the answer is quite simple: when the
PTK is installed, this transmit nonce is
00:10:44.050 --> 00:10:49.279
initialized to 0.
At first sight, this makes a lot of sense.
00:10:49.279 --> 00:10:53.550
I mean, you initiate that number to 0,
you increment it by one for every packet,
00:10:53.550 --> 00:11:00.700
so surely this nonce is a specific nonce
value, is only used once.
00:11:00.700 --> 00:11:06.959
Unfortunately, this is not the case. And the
reason this nonce value or a particular
00:11:06.959 --> 00:11:11.930
nonce value is sometimes used more than
once, is because we can force
00:11:11.930 --> 00:11:17.540
reinstallations of the PTK and those
reinstallations will again reset the nonce
00:11:17.540 --> 00:11:23.980
to 0 and then nonce value will be reused.
So, how can we force these key
00:11:23.980 --> 00:11:29.339
reinstallations as an attacker?
Let's again take the example where we have
00:11:29.339 --> 00:11:34.660
a client on the left, that wants to connect
to the access point on the right and in
00:11:34.660 --> 00:11:38.970
this case, we also have an attacker that
sits in the middle and this attacker will
00:11:38.970 --> 00:11:45.410
assume a so-called channel-based man-in-
the-middle position and in this-man-in-the-
00:11:45.410 --> 00:11:50.800
middle position, the adversary isn't yet
able to decrypt any packets. This man-in-
00:11:50.800 --> 00:11:56.020
the-middle position is purely there, so we
can reliably block packets from arriving
00:11:56.020 --> 00:12:01.909
and we can reorder the packet and so on. We
are not breaking encryption yet. And the
00:12:01.909 --> 00:12:06.690
way we obtain this man-in-the-middle
position is, we simply take all the frames
00:12:06.690 --> 00:12:11.250
that the access point which, e.g.,
is on Channel 6, we take all the frames
00:12:11.250 --> 00:12:16.250
that it is broadcasting and as an attacker,
we capture them and we rebroadcast them, we
00:12:16.250 --> 00:12:21.220
retransmit them on a different channel,
e.g. Channel 1. So we are effectively
00:12:21.220 --> 00:12:26.829
cloning the real access point on a rogue
channel and then we force the victim into
00:12:26.829 --> 00:12:31.069
connecting to this rogue access point on
this different channel.
00:12:31.069 --> 00:12:36.020
So let's assume now that the attacker
obtains this position, this man-in-the-
00:12:36.020 --> 00:12:42.620
middle position and the first stage of the
4-way handshake, we don't modify any
00:12:42.620 --> 00:12:48.579
frames at all. So e.g. if the
client is using 802.1x authentication, we
00:12:48.579 --> 00:12:52.800
simply forward all the frames between
these two different channels and we do the
00:12:52.800 --> 00:12:56.600
same thing with the first three messages
of the 4-way handshake, we simply
00:12:56.600 --> 00:13:03.970
forward them unmodified. Where the attack
starts, is if the client sends Msg4
00:13:03.970 --> 00:13:08.990
of the 4-way handshake. Instead of
forwarding this message to the access
00:13:08.990 --> 00:13:14.329
point, we don't forward it, which in our
situation is equivalent to blocking the
00:13:14.329 --> 00:13:20.860
message from arriving at the access point.
Now what's interesting in this situation,
00:13:20.860 --> 00:13:26.670
is that from the perspective of the client,
the handshake now successfully completed.
00:13:26.670 --> 00:13:32.040
After all, it received Msg3, it
replied using Msg4 and it thinks that
00:13:32.040 --> 00:13:35.860
the handshake is done, meaning it now
installs the encryption key and installs
00:13:35.860 --> 00:13:44.439
the PTK for use. So, let's make some space
here - the client thinks, that the handshake
00:13:44.439 --> 00:13:48.660
was completed, it has installed the key,
but the access point hasn't received
00:13:48.660 --> 00:13:55.339
Msg4 yet and the access point will
try to recover from this situation and it
00:13:55.339 --> 00:14:02.269
will do that by retransmitting a new
Msg3. And as the - as we, as the
00:14:02.269 --> 00:14:06.620
attacker, will forward this message to the
client, the client will accept this
00:14:06.620 --> 00:14:11.579
retransmitted Msg3 and then the Wi-Fi
standard says, that if you receive a
00:14:11.579 --> 00:14:16.940
retransmitted Msg3, you will reply
using a new Msg4. After that you will
00:14:16.940 --> 00:14:23.449
also install the encryption key again. Now,
one remark that I want to make here, is
00:14:23.449 --> 00:14:30.519
that, when we receive the retransmitted
Msg3, we reply using a new Msg4,
00:14:30.519 --> 00:14:36.149
however, this Msg4 will be already
encrypted at the link layer and the reason
00:14:36.149 --> 00:14:40.980
it's already encrypted, is because these
handshake messages are normal data frames
00:14:40.980 --> 00:14:45.879
and well, we already installed the
encryption key to encrypt data frames. So
00:14:45.879 --> 00:14:51.610
nearly all implementations we tested, will
send Msg4, the retransmitted Msg4,
00:14:51.610 --> 00:14:56.709
in an encrypted fashion. Now, I want to
remark here, that the Wi-Fi standard
00:14:56.709 --> 00:15:02.649
actually demands that Msg4, if it is
retransmitted, should be sent in plain text,
00:15:02.649 --> 00:15:07.020
so according to the specification, this
shouldn't happen. But nearly all
00:15:07.020 --> 00:15:12.999
implementations we tested, sent a
retransmitted Msg3 using encryption,
00:15:12.999 --> 00:15:17.730
and we will abuse this observation later.
So as I mentioned, after the client
00:15:17.730 --> 00:15:22.339
receives a retransmitted Msg3, it'll
reply using Msg4, it will again
00:15:22.339 --> 00:15:27.499
install the encryption key, and as a
result of that, this transmit nonce will be
00:15:27.499 --> 00:15:34.160
reset, which means, that if the client now
sends another data frame, it will again
00:15:34.160 --> 00:15:41.569
use this nonce value of 1 to encrypt the
frame, meaning we have nonce reuse, and we
00:15:41.569 --> 00:15:46.220
have key stream reuse, meaning we can now
try to abuse this to decrypt the data
00:15:46.220 --> 00:15:51.879
frame.
Now, how are we precisely going to abuse
00:15:51.879 --> 00:15:57.740
this, because we do somehow need to
recover the key stream that was used? And
00:15:57.740 --> 00:16:03.309
we go back to our observation, that we have
a Msg4 here, that is initially sent in
00:16:03.309 --> 00:16:08.180
plain text, and a retransmission of
Msg4 is later sent in an encrypted
00:16:08.180 --> 00:16:12.161
fashion. Now, there is a small difference
between these two messages, but
00:16:12.161 --> 00:16:15.600
essentially we have a message sent in
plaintext, and we have a message sent
00:16:15.600 --> 00:16:20.820
encrypted, and all we need to do, is we
need to XOR these two messages and we have
00:16:20.820 --> 00:16:24.350
the key stream corresponding to the nonce
value of 1.
00:16:24.350 --> 00:16:28.680
This data frame here at the bottom, it
also uses nonce value of 1, meaning it
00:16:28.680 --> 00:16:33.130
uses the exact same key stream, so we XOR
this packet with the key stream and there
00:16:33.130 --> 00:16:41.659
you go: We decrypted the packets and we
have now defeated WPA2. So...
00:16:41.659 --> 00:16:50.530
Applause
Thank you. So, that describes the attack
00:16:50.530 --> 00:16:56.129
against the 4-way handshake. And the
4-way handshake is not the only Wi-Fi
00:16:56.129 --> 00:17:00.310
handshake that is vulnerable. There are
also other handshakes which can be
00:17:00.310 --> 00:17:05.140
attacked in a similar manner, but I'm not
going to explain all of them in detail. If
00:17:05.140 --> 00:17:09.650
you want all the nitty-gritty details, I'm
going to refer you to our academic paper.
00:17:09.650 --> 00:17:14.260
Here, I'm just going to discuss more the
high-level concepts and the ideas behind
00:17:14.260 --> 00:17:18.880
the attack. So, e.g., one handshake
that is also vulnerable, is the group key
00:17:18.880 --> 00:17:23.260
handshake, and that handshake is used to
transport the group key from the access
00:17:23.260 --> 00:17:27.398
point to the client. And that key is used
to encrypt broadcast and multicast
00:17:27.398 --> 00:17:33.570
traffic. Then we also have the FT
handshake. The FT handshake is used, when
00:17:33.570 --> 00:17:38.460
you roam from one access point to another
access point of the same Wi-Fi network.
00:17:38.460 --> 00:17:42.730
It's used so you can quickly switch
from one access point to another without
00:17:42.730 --> 00:17:47.450
a long timeout. And finally, another
handshake that's also vulnerable is the
00:17:47.450 --> 00:17:51.990
PeerKey handshake, and that's used when
two clients want to communicate directly
00:17:51.990 --> 00:17:59.510
with one another. Okay, so I'm now going
to discuss in a bit more detail, what the
00:17:59.510 --> 00:18:05.500
practical impact of our attacks are. And
I'm first going to start with the general
00:18:05.500 --> 00:18:11.770
impact that a key reinstallation attack
has. So, let's assume we have a device
00:18:11.770 --> 00:18:15.690
that's vulnerable. This device can either
be a client device, e.g. it can be
00:18:15.690 --> 00:18:20.370
a smartphone, or a laptop, or these days
it can even be a toaster. They have Wi-Fi
00:18:20.370 --> 00:18:26.970
as well. Or it can also be an access
point. So if a client or access point is
00:18:26.970 --> 00:18:32.520
vulnerable to our key reinstallation
attack, the first thing that generally
00:18:32.520 --> 00:18:38.930
always happens, if this device ever sends
encrypted data frames, we can force it to
00:18:38.930 --> 00:18:44.929
reuse the nonce, which in turn we can use
to decrypt frames. But that's not the only
00:18:44.929 --> 00:18:50.529
thing we can do when a device is vulnerable.
Another thing we can do, is we can replay
00:18:50.529 --> 00:18:57.530
encrypted frames sent towards this device.
Now, why is that the case? That's because
00:18:57.530 --> 00:19:02.500
if a key is reinstalled, not only is this
transmit nonce reset to 0, but another
00:19:02.500 --> 00:19:08.380
parameter, which is called the replay
counter, it is also reset to 0. And this
00:19:08.380 --> 00:19:12.490
replay counter, as the name implies,
it's used to detect retransmissions, or
00:19:12.490 --> 00:19:18.690
it's used to detect malicious replays. If
this counter is reset, we can also replay
00:19:18.690 --> 00:19:24.510
frames towards a vulnerable device. So,
that's the general impact of a key
00:19:24.510 --> 00:19:33.110
reinstallation attack, but there are a lot
of other factors which also influence the
00:19:33.110 --> 00:19:41.250
exact impact of the attack, and one of the
things that probably has the biggest
00:19:41.250 --> 00:19:48.100
influence, is the encryptions cipher that
is being used. So, e.g., these days
00:19:48.100 --> 00:19:52.350
it is quite common that Wi-Fi networks use
AES CCMP. It's the most widely used
00:19:52.350 --> 00:19:58.659
encryption algorithm in Wi-Fi networks.
Against this algorithm, the impact in a
00:19:58.659 --> 00:20:04.070
sense stays limited to only decrypting and
replaying frames. It's not possible to
00:20:04.070 --> 00:20:10.230
abuse our key reinstallation attack to now
forge frames. And really, we got lucky
00:20:10.230 --> 00:20:16.690
here, because this is the most widely used
cipher, and against this cipher we cannot
00:20:16.690 --> 00:20:22.260
start to forge frames. Because, if we
would have been using the older encryption
00:20:22.260 --> 00:20:28.130
algorithm, which is WPA TKIP, against that
algorithm, we would be able to recover the
00:20:28.130 --> 00:20:32.200
Message Integrity Check key, which is
basically just a fancy word for the
00:20:32.200 --> 00:20:37.179
authentication key. And once we have that
authentication key, we would be able to
00:20:37.179 --> 00:20:44.880
forge frames that appear to be sent by the
device under attack. Interestingly, lately
00:20:44.880 --> 00:20:50.100
there's also been a new encryption
algorithm that is being introduced, and
00:20:50.100 --> 00:20:53.850
that algorithm is
called GCMP. It's fairly new, so only a
00:20:53.850 --> 00:20:59.169
few devices currently support it, and
currently it is being rolled out under the
00:20:59.169 --> 00:21:06.190
name of WiGig. Against this algorithm, the
impact of a key reinstallation attack is
00:21:06.190 --> 00:21:14.000
really the worst, because here we can
again recover the authentication key, but
00:21:14.000 --> 00:21:18.520
when we use GCMP, the same authentication
key is used in both communication
00:21:18.520 --> 00:21:23.490
directions. So against GCMP, we would be
able to forge frames that are sent from
00:21:23.490 --> 00:21:27.580
the client to the access point and also
forge frames that appear to be sent
00:21:27.580 --> 00:21:32.630
from the access point to the client, while
for the WPA-TKIP algorithm, we would only
00:21:32.630 --> 00:21:37.509
be able to forge frames, that appear to be
sent by the device that is under attack.
00:21:37.509 --> 00:21:42.630
So, my opinion - this is a bit surprising,
because GCMP is the latest encryption
00:21:42.630 --> 00:21:46.880
algorithm that is defined in the Wi-Fi
standard, yet the impact against it would
00:21:46.880 --> 00:21:51.950
be the highest. So, this is also why I
think we got lucky here, because if we
00:21:51.950 --> 00:21:55.490
would have found the attack, say maybe
five or ten years later, and everyone
00:21:55.490 --> 00:22:01.710
would be using this algorithm, the impact
would have been a lot worse. Another thing
00:22:01.710 --> 00:22:06.280
that influences the impact of the attack
is, which specific handshake we are
00:22:06.280 --> 00:22:11.169
attacking. For example, if we attack the
group key handshake, then the only thing
00:22:11.169 --> 00:22:14.159
we can do is, we can
only replay, broadcast or
00:22:14.159 --> 00:22:20.390
multicast frames. Now, why is that the
case? Why can't we decrypt broadcast or
00:22:20.390 --> 00:22:26.390
multicast frames, if a key reinstallation
occurs? And the reason is, that if we
00:22:26.390 --> 00:22:30.150
attack the group key handshake, we are
attacking the client, and the client is
00:22:30.150 --> 00:22:35.380
never sending actual encrypted broadcast
frames, so will never reuse the transmit
00:22:35.380 --> 00:22:40.050
nonce when it encrypts frames, because
it's never encrypting frames. Now, why is
00:22:40.050 --> 00:22:44.519
it, that the client never sends real
encrypted broadcast frames? Well, the
00:22:44.519 --> 00:22:49.100
reason is quite simple. Let's say, we have
the network layout shown here and the
00:22:49.100 --> 00:22:54.229
client on the left wants to send a
broadcast frames to all the other clients.
00:22:54.229 --> 00:22:58.419
Now, what happens here, is that this client
will send the data frame it wants to
00:22:58.419 --> 00:23:03.690
broadcast as a Unicast frame to the access
point only, meaning it won't encrypt it
00:23:03.690 --> 00:23:09.980
yet under the group key. It's the access
points that will broadcast this frame to
00:23:09.980 --> 00:23:14.149
all connected clients, and only the access
point will then encrypt it using the group
00:23:14.149 --> 00:23:16.350
key, and this is to assure that all
clients
00:23:16.350 --> 00:23:20.690
within range of the access point will
receive this broadcast message. Now, for
00:23:20.690 --> 00:23:24.659
us, this means that only the access point
is transmitting real encrypted broadcast
00:23:24.659 --> 00:23:28.940
frames, and in the group key handshake we
cannot attack the access point. We are
00:23:28.940 --> 00:23:33.059
only attacking the client, meaning in
practice, we can only replay broadcast
00:23:33.059 --> 00:23:37.560
frames to the client, at least if we are
targeting the group key handshake. So,
00:23:37.560 --> 00:23:42.980
really, the impact is limited in practice
if we attack this handshake, because
00:23:42.980 --> 00:23:47.769
generally, replaying broadcast data doesn't
have a high impact. Though, I do want to
00:23:47.769 --> 00:23:53.250
note, that some home automation systems use
broadcast traffic to, e.g., send
00:23:53.250 --> 00:23:59.250
commands to turn the device on or off,
e.g. to turn your fridge on, or to turn
00:23:59.250 --> 00:24:03.970
lights on or off, so although the
impact of replaying broadcast frame is
00:24:03.970 --> 00:24:08.120
low, there are situations in practice,
where it does have some impact, but it
00:24:08.120 --> 00:24:13.090
really depends on your network setup and
the devices that you use. So, the other
00:24:13.090 --> 00:24:17.129
handshake that is vulnerable, is the 4-
way handshake, but we already discussed
00:24:17.129 --> 00:24:21.809
that. Against a 4-way handshake we can
attack the clients and the impact, is that
00:24:21.809 --> 00:24:25.610
we can replay and decrypt frames, and
depending on the encryption algorithm
00:24:25.610 --> 00:24:31.690
being used, we can possibly forge frames
as well. The situation is a lot more
00:24:31.690 --> 00:24:36.080
interesting for the FT handshake, though.
And remember, this handshake is used, when
00:24:36.080 --> 00:24:40.959
you roam from one access point to another
of the same network. Against the FT
00:24:40.959 --> 00:24:45.669
handshake, it's not the clients that we
can attack, but here we can attack the
00:24:45.669 --> 00:24:51.450
access point. And on top of that, when
attacking the FT handshake, we no longer
00:24:51.450 --> 00:24:56.679
need this man-in-the-middle position. Now,
why is that the case? Well, let's again
00:24:56.679 --> 00:25:01.370
explain this using our common example,
where a client wants to connect and where
00:25:01.370 --> 00:25:08.330
it is executing the FT handshake. And at a
high level, the FT handshake is the same
00:25:08.330 --> 00:25:11.520
as the 4-way handshake, meaning you
also have four frames that are
00:25:11.520 --> 00:25:16.730
transmitted, but the big difference here
is, that with the FT handshake it's the
00:25:16.730 --> 00:25:21.220
client that sends the first message
in the handshake, while for the 4-way
00:25:21.220 --> 00:25:26.250
handshake it was the access point that
sends the first message. So, the handshake
00:25:26.250 --> 00:25:29.860
is practically the same as the 4-way
handshake, meaning, initially we have two
00:25:29.860 --> 00:25:34.190
messages that transport these random
numbers, these nonces, between both
00:25:34.190 --> 00:25:40.770
devices. Then, both these endpoints can
generate the fresh encryption key. Then
00:25:40.770 --> 00:25:46.090
the last two frames, they are again used
to confirm that both parties negotiated
00:25:46.090 --> 00:25:51.210
the same encryption key. Now, I want to go
in a bit more detail here on this last
00:25:51.210 --> 00:25:56.600
phase, and what happens here, is that the
third frame of the handshake is now sent
00:25:56.600 --> 00:26:01.970
from the client to the access point and
that is a reassociation request. And after
00:26:01.970 --> 00:26:06.779
the access point receives this frame, it
will reply using a reassociation response
00:26:06.779 --> 00:26:12.799
frame and it will install the encryption
key. Once it has installed the encryption
00:26:12.799 --> 00:26:18.590
key, it can of course start sending
encrypted data frames. So, let's again
00:26:18.590 --> 00:26:23.820
make some room here. What we can now do
as an attacker, is we can take this
00:26:23.820 --> 00:26:28.840
reassociation request that the client
previously transmitted, and we can simply
00:26:28.840 --> 00:26:36.450
replay it. That's because in the FT
handshake, there is no replay protection
00:26:36.450 --> 00:26:41.730
against messages of the handshake. So we
can just take that frame, we can send it
00:26:41.730 --> 00:26:45.380
again to the access point. The access
point will receive it, it will accept it,
00:26:45.380 --> 00:26:51.490
and it will reply using a reassociation
response. Now, so far this is not a
00:26:51.490 --> 00:26:57.440
problem. The problem here is, that again
the access point will reinstall the
00:26:57.440 --> 00:27:01.269
encryption key, and here it goes wrong
because we are reinstalling this
00:27:01.269 --> 00:27:05.889
encryption key. The transmit nonce is
again reset to 0, meaning if we now send
00:27:05.889 --> 00:27:11.930
the data frame again, the nonce value of 1
is used to encrypt these data frames,
00:27:11.930 --> 00:27:14.950
meaning the same key stream is used,
meaning we can start applying the same
00:27:14.950 --> 00:27:19.029
tricks to first derive some known key
stream and to then abuse that to attack
00:27:19.029 --> 00:27:24.250
the handshake. So, I want to highlight
here a few things. And the first is, the
00:27:24.250 --> 00:27:27.740
reason why we don't need a man-in-the-
middle position, is because handshake
00:27:27.740 --> 00:27:30.170
messages in
the FT handshake, they are not protected
00:27:30.170 --> 00:27:34.720
against replays, while in the 4-way
handshake, every handshake messages
00:27:34.720 --> 00:27:40.330
contains a sequence counter, where the
receiver uses the sequence counter to
00:27:40.330 --> 00:27:44.450
detect replays, but for the FT handshake
that's not the case, so we can just take
00:27:44.450 --> 00:27:48.090
these messages, we can replay them, and we
don't need a man-in-the-middle position to
00:27:48.090 --> 00:27:55.351
block packets and to trigger
retransmissions. Ok, so that's the
00:27:55.351 --> 00:28:01.630
explanation for the FT handshake. Another
factor that can influence the impacts of
00:28:01.630 --> 00:28:06.660
our attack in practice, is which operating
system and which device precisely we are
00:28:06.660 --> 00:28:12.120
attacking. And in particular, we see that
iOS and Windows, they are not vulnerable
00:28:12.120 --> 00:28:17.970
against attacks against a 4-way
handshake. And why is that the case? Well,
00:28:17.970 --> 00:28:22.360
that's because these two devices don't
really follow the standard, and they don't
00:28:22.360 --> 00:28:26.659
accept retransmissions of Msg3,
meaning we cannot abuse these
00:28:26.659 --> 00:28:33.180
retransmissions of Msg3 to trigger
these key reinstallations.
00:28:33.180 --> 00:28:36.380
Now, I want to make two remarks
here. And the first one is, that
00:28:36.380 --> 00:28:41.550
against these devices we can still attack
the group key handshake. And particularly
00:28:41.550 --> 00:28:46.860
when looking at iOS, if we look at iOS
version 11, it does implement the standard
00:28:46.860 --> 00:28:50.679
properly and it does accept
retransmissions of Msg3, meaning that
00:28:50.679 --> 00:28:58.580
one is vulnerable to attacks against the
4-way handshake. Now, Linux is not much
00:28:58.580 --> 00:29:04.460
better, because if we look at the Wi-Fi client
that is used on Linux, and for example on
00:29:04.460 --> 00:29:11.750
Android, it's called wpa_supplicant, and
against wpa_supplicant 2.4 and higher, we
00:29:11.750 --> 00:29:17.919
notice that, if we try to perform a key
reinstallation attack, it won't reinstall
00:29:17.919 --> 00:29:22.990
the secret key that was negotiated, but
no, instead it will suddenly install an
00:29:22.990 --> 00:29:27.870
all-zero encryption key, and then it of
course becomes very trivial to start
00:29:27.870 --> 00:29:36.919
decrypting data that this device is
transmitting. Now, why does this happen?
00:29:36.919 --> 00:29:42.659
I can actually sort of understand why this
went wrong. So, I'm going to explain what
00:29:42.659 --> 00:29:48.990
the implementation does wrong, to... why it
installs this all-zero key. And to explain
00:29:48.990 --> 00:29:52.460
this, I'm going to assume that we have an
Android device that is connecting to an
00:29:52.460 --> 00:29:56.660
access point. And we're going to zoom in a
bit on the implementation of the Android.
00:29:56.660 --> 00:30:01.080
And we're going to look at two entities.
We're first going to look at wpa_supplicant,
00:30:01.080 --> 00:30:05.330
which is represented by the
handshake icon here, and we're also going
00:30:05.330 --> 00:30:10.429
to look at another entity, namely the
Linux kernel. It's the Linux kernel that
00:30:10.429 --> 00:30:15.239
will be responsible for encrypting data
frames, and wpa_ supplicant will be
00:30:15.239 --> 00:30:20.889
responsible for executing the 4-way handshake.
And of course we assume, that we as an
00:30:20.889 --> 00:30:27.410
attacker are nearby, and we again have
this man-in-the-middle position. So, what
00:30:27.410 --> 00:30:31.149
does an attacker have to do to cause this
installation of an all-zero encryption
00:30:31.149 --> 00:30:36.780
key? Well, again, we simply let the first
phase of the 4-way handshake execute
00:30:36.780 --> 00:30:42.460
normally, and when the access point sends
Msg3 of the 4-way handshake, we
00:30:42.460 --> 00:30:48.679
forward that to the Android. Android will
reply using Msg4. And we will
00:30:48.679 --> 00:30:53.510
again block Msg4 from arriving at the
access point.
00:30:53.510 --> 00:30:58.090
Now, completely similar to the case with
the 4-way handshake, the client thinks that
00:30:58.090 --> 00:31:02.019
the handshake now successfully completed,
meaning it will install the encryption
00:31:02.019 --> 00:31:07.600
key. How it will install the encryption
key is as follows: It commands the Linux
00:31:07.600 --> 00:31:15.059
kernel into installing the encryption key
in the driver. And the driver itself will
00:31:15.059 --> 00:31:19.080
make a copy of the encryption key. And it
will store it locally. And the driver can
00:31:19.080 --> 00:31:24.280
then encrypt frames. Now this means that
wpa_supplicant, which is just a user land
00:31:24.280 --> 00:31:28.139
program, no longer needs to store the
encryption key, meaning it will clear it
00:31:28.139 --> 00:31:34.270
from memory. What will happen now, if we
continue with the attack, is that the
00:31:34.270 --> 00:31:38.969
access point will retransmit Msg3,
because it did not receive Msg4. The
00:31:38.969 --> 00:31:42.790
client will again happily accept this
retransmitted Msg3 and reply using
00:31:42.790 --> 00:31:48.289
Msg4. And again it will instruct the
Linux kernel saying "Hey, please install
00:31:48.289 --> 00:31:52.389
this encryption key that is located at
this address in the memory." But of
00:31:52.389 --> 00:31:56.789
course, that memory is now all zeros,
because that key has just been cleared
00:31:56.789 --> 00:31:59.720
from memory. So,
now it's basically commanding the Linux
00:31:59.720 --> 00:32:04.139
kernel into installing an all-zero
encryption key. And the Linux kernel and
00:32:04.139 --> 00:32:09.080
driver will happily obey this command and
they will install an all-zero encryption
00:32:09.080 --> 00:32:13.690
key, meaning at this point, all the data
that the client is sending, is encrypted
00:32:13.690 --> 00:32:18.370
using a known key, so we can easily
decrypt all the traffic, and of course we
00:32:18.370 --> 00:32:23.470
can also send any traffic we want to the
client. Basically, we are now a rogue
00:32:23.470 --> 00:32:28.529
access point and we can manipulate the
traffic of the client as we wish.
00:32:28.529 --> 00:32:37.699
Applause
MV: Thank you. So, after this you might be
00:32:37.699 --> 00:32:42.940
wondering, "Well, gee, is my device
vulnerable?" And you can test your own
00:32:42.940 --> 00:32:50.039
device using the following script. It's on
github. I have tested the script on Kali
00:32:50.039 --> 00:32:54.870
Linux, on Arch Linux, and also on Ubuntu,
so I could recommend using one of these
00:32:54.870 --> 00:33:00.270
distributions, and I also recommend to use
a Wi-Fi dongle that we or someone else has
00:33:00.270 --> 00:33:05.409
tested ourselves, because we noticed that
if you use our testing scripts with some
00:33:05.409 --> 00:33:08.960
older
Wi-Fi devices, then there are some bugs in
00:33:08.960 --> 00:33:16.279
these Wi-Fi devices which cause our
scripts to fail. And one way to also
00:33:16.279 --> 00:33:20.010
prevent our scripts to fail, is to disable
hardware encryption. Now, how you should do
00:33:20.010 --> 00:33:25.409
that is also explained on this page. Using
these scripts, you can test both your
00:33:25.409 --> 00:33:29.140
client devices, you can test against
attacks against the 4-way handshake,
00:33:29.140 --> 00:33:33.799
the group key handshake, and there's also
a script to test the access point, whether
00:33:33.799 --> 00:33:40.519
it's vulnerable against attacks against
the FT handshake. Now, if you're going to
00:33:40.519 --> 00:33:45.500
try to see which devices are vulnerable,
you are most likely going to see that
00:33:45.500 --> 00:33:52.559
quite some clients are still vulnerable to
our attacks. Luckily, we can modify the
00:33:52.559 --> 00:33:58.129
access point to prevent attacks against
the client. In particular, we can make
00:33:58.129 --> 00:34:02.620
additional modifications to the access
point, such that the access points never
00:34:02.620 --> 00:34:07.149
retransmits Msg3 of the 4-way
handshake, and that it also never
00:34:07.149 --> 00:34:11.640
retransmits the first message of the group
key handshake. And if we do that, then
00:34:11.640 --> 00:34:17.060
clients that are connected to such a
modified access points, they are no longer
00:34:17.060 --> 00:34:19.130
vulnerable against most attacks. There are
00:34:19.130 --> 00:34:24.660
still some edge cases where the device is
vulnerable, but these have a very low
00:34:24.660 --> 00:34:29.909
impact. So, if we modify an access point
in this way, then connected clients are no
00:34:29.909 --> 00:34:34.719
longer vulnerable. One downside here is,
that because we are no longer
00:34:34.719 --> 00:34:40.530
retransmitting certain messages, it could
be that especially in a noisy environment,
00:34:40.530 --> 00:34:44.520
because we don't retransmit these messages
anymore, that the handshake may fail
00:34:44.520 --> 00:34:50.500
because the reliability is now less. Now,
one thing I also want to remark here,
00:34:50.500 --> 00:34:57.310
that... if you have a router, which is
vulnerable against our attack and a
00:34:57.310 --> 00:35:02.090
vendor says "Hey, we patched our router,
so we patched our access point to defend
00:35:02.090 --> 00:35:07.400
against attacks," then this does not mean
that this access point implements these
00:35:07.400 --> 00:35:10.780
countermeasures. Because these
countermeasures, they are additional
00:35:10.780 --> 00:35:15.920
modifications on top of the normal
patches to defend against the attack. So,
00:35:15.920 --> 00:35:21.130
only if a vendor explicitly says that "Our
patches of the access point also prevent
00:35:21.130 --> 00:35:26.320
attacks against clients," then, only if
they explicitly say that, are attacks
00:35:26.320 --> 00:35:32.640
against the client also prevented. Ok,
so now I want to cover some misconceptions
00:35:32.640 --> 00:35:39.810
that have been floating around the
internet. And the first one is, that some
00:35:39.810 --> 00:35:43.490
people claim, if you only patch the
clients, or if you only patch the access
00:35:43.490 --> 00:35:46.980
point, then you're fine. But that's not
the case. Because if you only patch the
00:35:46.980 --> 00:35:51.420
client and the access point is vulnerable,
then we can still attack the access point.
00:35:51.420 --> 00:35:54.810
If the access point only contains these
normal patches, the normal patches to
00:35:54.810 --> 00:36:00.021
defend against attacks, then connected
clients are also still vulnerable. So, as
00:36:00.021 --> 00:36:05.660
I mentioned, connected clients are only
defended, if the access point contains
00:36:05.660 --> 00:36:11.530
really extra modifications on top of the
default patches. Now, another common
00:36:11.530 --> 00:36:17.081
misconception is, that some people might
say "But, yeah, it's a cool attack, but
00:36:17.081 --> 00:36:22.490
you have to be close to the network in
order to pull off these attacks."
00:36:22.490 --> 00:36:26.920
Unfortunately, that's not the case because
we can use special antenna. And this
00:36:26.920 --> 00:36:30.171
special antenna, they can be made
really cheap out of, e.g. just a
00:36:30.171 --> 00:36:36.040
tin can, and with this special antenna, we
can manipulate Wi-Fi traffic from up to,
00:36:36.040 --> 00:36:41.450
say, 2 miles. And there are even leaked
NSA documents, where the NSA is able to
00:36:41.450 --> 00:36:47.440
exploit a Wi-Fi network using other
attacks from up to 8 miles away. Now,
00:36:47.440 --> 00:36:51.010
that's of course with a clear line of
sight, but still this shows that you don't
00:36:51.010 --> 00:36:54.620
have to be physically close to the
network. You can still be relatively far
00:36:54.620 --> 00:37:02.370
away. Another strange remark that I
sometimes hear, is that you need to be
00:37:02.370 --> 00:37:06.630
connected to the network in order to pull
off these attacks, which would basically
00:37:06.630 --> 00:37:10.440
mean, you need to know the password of the
network to carry out the attacks. But
00:37:10.440 --> 00:37:14.540
that's not the case. As I mentioned,
during the attacks, you only need to be
00:37:14.540 --> 00:37:19.740
close enough. You need to be able to
manipulate some encrypted packets. But you
00:37:19.740 --> 00:37:23.740
don't need to know anything about the
network. You simply need to know the
00:37:23.740 --> 00:37:27.210
network is there and there's a vulnerable
client and access point and then you can
00:37:27.210 --> 00:37:34.450
start attacking them. One remark that I
can understand, is that some people
00:37:34.450 --> 00:37:39.430
say that "Yeah, Ok, you can attack these
handshakes, and you can decrypt data that
00:37:39.430 --> 00:37:43.630
is sent right after these handshakes, but
generally right after you connect to an
00:37:43.630 --> 00:37:48.690
Wi-Fi network, you're not really sending
interesting data, because at that point
00:37:48.690 --> 00:37:53.520
your device is sending e.g. ARP
requests, or it's sending DHCP requests,
00:37:53.520 --> 00:37:59.770
or is just creating TCP connections. But
no useful information is transmitted at
00:37:59.770 --> 00:38:06.260
this time." Unfortunately, at least for a
defender, this is again not true. Because,
00:38:06.260 --> 00:38:10.090
what we can do as an attacker is, we can
first let the client connect blackout out
00:38:10.090 --> 00:38:14.041
manipulating any traffic. The client, the
victim, will then, e.g. start
00:38:14.041 --> 00:38:20.120
browsing the internet, start
opening TCP connections, and in the middle
00:38:20.120 --> 00:38:24.070
of that, while the victim is e.g.
surfing the internet, we can
00:38:24.070 --> 00:38:28.090
deauthenticate the client from the
network, and all operating system will
00:38:28.090 --> 00:38:32.020
then immediately execute a new 4-way
handshake. And once that 4-way
00:38:32.020 --> 00:38:37.500
handshake is then completed, it will
send all the buffered TCP packets again
00:38:37.500 --> 00:38:41.280
to the access point and also in a reverse
direction. So, basically, what we as an
00:38:41.280 --> 00:38:45.170
attacker can do, we can wait until we
expect the victim to send interesting
00:38:45.170 --> 00:38:49.190
information. Then we deauthenticate the
victim. It will execute a new handshake.
00:38:49.190 --> 00:38:56.010
And then we can decrypt the data that will
be transmitted right after that handshake.
00:38:56.010 --> 00:38:59.520
Another thing that makes the attack
possibly hard, is that obtaining this
00:38:59.520 --> 00:39:03.500
channel based man-in-the-middle is
difficult. For example, you might be
00:39:03.500 --> 00:39:07.760
thinking that in order to force the
clients to connect to the rogue access
00:39:07.760 --> 00:39:13.150
point, you need a stronger signal strength
than a real access point. But again,
00:39:13.150 --> 00:39:17.870
that's not the case. And the reason this
is not the case, is because we can use
00:39:17.870 --> 00:39:23.350
special Wi-Fi packets and so-called
channel switch announcements, which
00:39:23.350 --> 00:39:28.680
command the client into switching to a
different Wi-Fi channel, and effectively
00:39:28.680 --> 00:39:32.400
blackout to a rogue access point. So we don't
need a high signal strength, we can simply
00:39:32.400 --> 00:39:36.520
command a victim into saying "Hey, switch
to this channel and connect to our access
00:39:36.520 --> 00:39:40.820
point." And these frames are not
authenticated, so we can just forge them
00:39:40.820 --> 00:39:47.780
as an attacker. Another thing you might
say, that the complexity of the attack is
00:39:47.780 --> 00:39:52.871
hard, meaning it requires some expertise
to implement this. And this is true. You
00:39:52.871 --> 00:39:59.110
do need to know a bit about Wi-Fi in order
to make a proof of concept reliable, but
00:39:59.110 --> 00:40:03.480
as usual you only need to write this
attack once, and then people can use your
00:40:03.480 --> 00:40:07.880
script in order to attack others. And this
is similar to, e.g., memory
00:40:07.880 --> 00:40:13.350
corruption attacks, such as buffer
overflows or stack overflows. Writing the
00:40:13.350 --> 00:40:17.040
proof of concept may be hard, but if you
then give it to someone else, or if you
00:40:17.040 --> 00:40:22.000
put it in Metasploit or some other tool,
all the user has to do, is basically start
00:40:22.000 --> 00:40:29.270
the script, and you can start attacking
people. One other misconception that I
00:40:29.270 --> 00:40:35.630
sometimes encounter, is that people say "If
you use AES-CCMP, this mitigates the
00:40:35.630 --> 00:40:41.840
attack." Again, unfortunately, this is not
true, because the only advantage of using
00:40:41.840 --> 00:40:47.260
AES-CCMP is that
the attacker can no longer forge frames.
00:40:47.260 --> 00:40:52.680
The attacker is still able to decrypt and
replay frames. And finally, the last
00:40:52.680 --> 00:40:57.800
misconception is, that some people say that
enterprise networks aren't vulnerable,
00:40:57.800 --> 00:41:02.830
because they e.g. don't execute
the 4-way handshake. But again,
00:41:02.830 --> 00:41:07.450
unfortunately, that's wrong, because even
these networks use the 4-way handshake
00:41:07.450 --> 00:41:13.610
and they can be attacked as well. So, then
you have some people that say "OK, WPA2 is
00:41:13.610 --> 00:41:19.880
now completely broken. It's the end of the
world and we're all doomed." Let's not get
00:41:19.880 --> 00:41:25.530
carried away, though. We can patch these
vulnerabilities in a backwards compatible
00:41:25.530 --> 00:41:30.190
way. And as I illustrated here in my talk,
the impact also really depends on the
00:41:30.190 --> 00:41:34.530
devices that you are using and your own
network setup. So, sometimes the impact is
00:41:34.530 --> 00:41:38.150
actually really low, but of course
sometimes the impact can be very high,
00:41:38.150 --> 00:41:43.250
e.g. if you have a Linux device, then
attacker can do what he or she wishes,
00:41:43.250 --> 00:41:49.660
essentially. Now, for the last part of the
talk, I'm going to discuss some lessons
00:41:49.660 --> 00:41:56.150
that we can learn from this attack and
also the research. I think one of the most
00:41:56.150 --> 00:42:01.320
important and interesting observations -
it's also the reason why I really like
00:42:01.320 --> 00:42:06.500
this attack myself - is that the 4-way
handshake was proven to be secure. The
00:42:06.500 --> 00:42:11.270
encryption protocol, and in particular
AES, has also been proven as secure.
00:42:11.270 --> 00:42:18.560
However, if we combine these two things,
then suddenly we lose all security. And
00:42:18.560 --> 00:42:27.400
this is quite unfortunate. And what this
teaches us, is that even though individual
00:42:27.400 --> 00:42:33.080
parts of a system were really investigated
and perhaps formally analyzed, we also
00:42:33.080 --> 00:42:37.560
need to analyze the combination of these
different entities and models, and we also
00:42:37.560 --> 00:42:43.540
need to prove that these combinations are
secure as well. And another way to look at
00:42:43.540 --> 00:42:50.830
this, is that in the proof of the 4-way
handshake, the authors, they modeled the
00:42:50.830 --> 00:42:56.780
handshake in a rather abstract way. And
their proofs, specifically, they did not
00:42:56.780 --> 00:43:00.780
model retransmissions of handshake
messages. And that's one of the things we
00:43:00.780 --> 00:43:06.310
abuse. So, on one hand we need to assure
that we also look
00:43:06.310 --> 00:43:11.140
at the combinations of these different
entities, but we also need to assure that
00:43:11.140 --> 00:43:17.080
the abstract models that we use reflect
reality. Another thing that we can learn,
00:43:17.080 --> 00:43:21.690
is that we should keep the protocols and
also the implementations simple.
00:43:21.690 --> 00:43:28.490
E.g., if we look at wpa_supplicant 2.6,
when we were studying this version
00:43:28.490 --> 00:43:34.600
ourself, we thought it wasn't vulnerable
to key reinstallation attacks. However,
00:43:34.600 --> 00:43:40.550
when we were notifying companies of the
vulnerabilities, another researcher found
00:43:40.550 --> 00:43:46.800
an attack against this version which did
work. The reason we missed this attack
00:43:46.800 --> 00:43:52.780
against version 2.6, is because
wpa_supplicant uses a fairly complex
00:43:52.780 --> 00:43:57.600
implementation of the 4-way handshake
and the state machine is fairly complex to
00:43:57.600 --> 00:44:02.690
reason about. And there are two ways to
combat this. The first is to keep the
00:44:02.690 --> 00:44:07.210
protocol simple. The second way to combat
this, is to formally verify
00:44:07.210 --> 00:44:12.630
implementations. Now of course, we cannot
formally verify all the code, but what we
00:44:12.630 --> 00:44:17.410
can do is, really, these cryptographic
protocols which play a very important
00:44:17.410 --> 00:44:23.950
role, at least we should pay enough
attention to that. What's also
00:44:23.950 --> 00:44:29.330
interesting, is that I encountered a
document of the CIA which also agrees, that
00:44:29.330 --> 00:44:34.220
complex implementations or protocols are
bad. Specifically, they have a document,
00:44:34.220 --> 00:44:39.770
where the CIA advises people how to
properly implement backdoors, essentially,
00:44:39.770 --> 00:44:44.760
and they're saying that "Yeah, if you want
to send data back to us, of course, use
00:44:44.760 --> 00:44:48.970
encryption, but in that encryption
algorithm, don't enable re-key
00:44:48.970 --> 00:44:53.451
functionality, because that enables
additional features of the encryption
00:44:53.451 --> 00:44:58.860
algorithm. And these additional features,
they cause unnecessary complexity and that
00:44:58.860 --> 00:45:05.031
generally leads to bugs." Another thing
that we can learn, is that the standard
00:45:05.031 --> 00:45:10.560
needs to be specified rigorously and as
precisely as possible. Because the
00:45:10.560 --> 00:45:17.500
original WPA2 standard, it was a bit fake.
It didn't really define a state machine.
00:45:17.500 --> 00:45:23.720
Well, the state machine that it defined
says, what an implementation - sorry -
00:45:23.720 --> 00:45:30.360
should do if it receives a message, but -
let's go back to the slides - but it
00:45:30.360 --> 00:45:35.270
doesn't define what an implementation
should do when it receives an unexpected
00:45:35.270 --> 00:45:41.550
message. So, it doesn't define the order,
in which messages should be accepted. Now,
00:45:41.550 --> 00:45:46.760
there is an amendment of the Wi-Fi
standard which better defines how and when
00:45:46.760 --> 00:45:52.820
to handle messages, but even that standard
is a bit fake. And I want to remark here
00:45:52.820 --> 00:45:58.430
that because the original WPA2 standard
was a bit fake, I can forgive iOS and
00:45:58.430 --> 00:46:02.250
Windows for deviating a bit from the
standard. Because the standard was
00:46:02.250 --> 00:46:08.750
difficult to interpret correctly. Now, on
a bit of a related note, I want to briefly
00:46:08.750 --> 00:46:13.760
mention a workshop that we are organizing,
which is exactly about how to implement
00:46:13.760 --> 00:46:18.951
these security protocols properly, how to
e.g. fuzz security protocols, how
00:46:18.951 --> 00:46:23.620
to prove that they are correct, how to
make sure that we specify them rigorously.
00:46:23.620 --> 00:46:30.070
So, if you are working in this field, do
consider submitting to this. Now, the last
00:46:30.070 --> 00:46:35.500
thing that I want to mention on what we
can learn from this research, is how we
00:46:35.500 --> 00:46:42.520
can coordinate the disclosure of a
vulnerability like this. Because this is
00:46:42.520 --> 00:46:45.730
not an ordinary vulnerability,
that is, just affects one
00:46:45.730 --> 00:46:52.450
vendor, it really affects possibly every
Wi-Fi device that is around. So, how on
00:46:52.450 --> 00:46:56.880
earth are you going to start notifying
companies? Who are you going to notify?
00:46:56.880 --> 00:47:02.360
What would be the deadlines, and so on?
Well, I'm going to discuss a bit about the
00:47:02.360 --> 00:47:07.750
strategy that we used, and what we used
first is... we first wanted to determine,
00:47:07.750 --> 00:47:12.470
you know, is this really a widespread
issue? We wanted to be sure of that before
00:47:12.470 --> 00:47:18.620
we started to notify a lot of companies.
And the way we tackled that problem is, we
00:47:18.620 --> 00:47:25.040
first contacted a few selected vendors and
we told them that "Hey, we possibly found
00:47:25.040 --> 00:47:30.630
this flaw in the WPA2 protocol, but we
weren't able to test your devices, but you
00:47:30.630 --> 00:47:36.210
should check this out." And quite quickly
we got a few responses from vendors, saying
00:47:36.210 --> 00:47:41.960
that "Yes, we looked at your attack and
indeed, some of our devices are
00:47:41.960 --> 00:47:45.270
vulnerable," and this really confirmed to
us, that a device
00:47:45.270 --> 00:47:49.500
that we didn't test ourself was
vulnerable to the attack that we found.
00:47:49.500 --> 00:47:52.870
So, it confirmed that the issue is
widespread, and we also got a bit of
00:47:52.870 --> 00:47:57.160
feedback on the report that we sent
towards them on the description of our
00:47:57.160 --> 00:48:02.550
attack. So, at this point we were
convinced ourselves, that this really was a
00:48:02.550 --> 00:48:07.870
flaw in the standard and that a lot of
companies will be affected. Then the next
00:48:07.870 --> 00:48:12.620
question we had is, "Okay, who are we now
all going to notify?" We of course
00:48:12.620 --> 00:48:16.240
notified the big names and the big
companies, but who else do we have to
00:48:16.240 --> 00:48:22.810
notify? And at this point, our tactic was
to rely on a CERT team, specifically a
00:48:22.810 --> 00:48:28.680
CERT from the US and they did all the
coordination for us.
00:48:28.680 --> 00:48:33.760
But one other thing that you can do is,
that if you're not sure who all is
00:48:33.760 --> 00:48:38.690
affected or what, who all the vendors are,
then you can just ask a vendor that you
00:48:38.690 --> 00:48:42.760
contacted already for other
vendors, that also might be affected
00:48:42.760 --> 00:48:48.790
by the bug that you found, e.g.
Now one thing that is more difficult here,
00:48:48.790 --> 00:48:55.580
is that on one hand you want to notify as
much vendors as possibly, on the other hand
00:48:55.580 --> 00:49:01.260
you also can't notify everyone because if
you are going to notify everyone, then the
00:49:01.260 --> 00:49:10.450
chance of the details leaking, they become
close to one. Another difficult thing to
00:49:10.450 --> 00:49:15.580
decide is, how long should you give time to
companies in order to patch this. And again,
00:49:15.580 --> 00:49:23.110
here you're mixed between two decisions:
on one hand you can give give them a long
00:49:23.110 --> 00:49:27.950
period to patch everything, but then again,
the risk of this details leasing... err,
00:49:27.950 --> 00:49:33.300
leaking increase. On the other hand, if the
embargo period is too short, people won't
00:49:33.300 --> 00:49:36.950
have time to patch it. So this is quite a
hard decision. In the end,
00:49:36.950 --> 00:49:42.310
what we did is - and which I would
again do in the future - is, it's hard to
00:49:42.310 --> 00:49:47.490
pick a deadline, but still do pick a
deadline to avoid any uncertainty and so
00:49:47.490 --> 00:49:54.300
that people know, what to expect. And
finally, I want to thank CERT and ICASI
00:49:54.300 --> 00:49:59.960
for helping with the coordination and you
also want to thank Cisco for some of the
00:49:59.960 --> 00:50:05.700
advice that they give.
So, with that I can conclude the talk, so
00:50:05.700 --> 00:50:11.980
what we discussed, is a flaw and the WPA2
standard itself and the most surprising
00:50:11.980 --> 00:50:17.770
thing about this research is, that WPA2 was
proven to be correct, yet we still found
00:50:17.770 --> 00:50:23.041
his attack after more than a decade.
And more than that, not only is this just a
00:50:23.041 --> 00:50:27.880
theoretical attack, the attack has actual
impact and practice.
00:50:27.880 --> 00:50:32.740
And finally, in order to defend against
this, you should update all your clients
00:50:32.740 --> 00:50:38.220
and also check if your access points are
affected. So with that, thank you for your
00:50:38.220 --> 00:50:41.360
attention and if there are any questions,
feel free to ask.
00:50:41.360 --> 00:50:50.510
applause
00:50:50.510 --> 00:50:52.650
Herald: So, do we have any questions?
00:50:52.650 --> 00:50:57.760
There is mics everywhere, so please come
in front. And I think, we already have the
00:50:57.760 --> 00:51:01.770
first question directly here in front on
mic number 1.
00:51:01.770 --> 00:51:11.540
Mic1: You mentioned, that GCMP is most
vulnerable. Do you know if there's any
00:51:11.540 --> 00:51:18.300
standardization going on, about switching
to nonce misuse resistant scheme like
00:51:18.300 --> 00:51:28.100
AES-GCM, Synthetic Initialization Vector?
MV: Yes, so there have been
00:51:28.100 --> 00:51:33.710
some proposals in order to make the
encryption algorithm defend against nonce
00:51:33.710 --> 00:51:40.020
reuse. Now the impression I have, that this
is still a bit of ongoing research. So
00:51:40.020 --> 00:51:45.450
there are proposals, where you have an
algorithm that you can use, but I'm not
00:51:45.450 --> 00:51:50.640
aware of actual encryption protocols, e.g.
TLS or Wi-Fi, that are using them.
00:51:50.640 --> 00:51:54.790
But they exist, but I... they're not yet being
really used.
00:51:54.790 --> 00:52:02.920
Mic1: It is standardisation going on in
CFRG, so Crypto Forum Research Group in
00:52:02.920 --> 00:52:10.600
IETF standardization, but I was asking about
Wi-Fi standardization, if they are planning
00:52:10.600 --> 00:52:20.230
to use this? And [a] related question would be,
if you would use in AES-GCM instead of
00:52:20.230 --> 00:52:30.500
the deterministic initialization vector,
there's a random IV possible, if you use
00:52:30.500 --> 00:52:38.850
96 bit, then the impact wouldn't be
bounded.
00:52:38.850 --> 00:52:45.030
MV: So to answer the first question: I'm
not aware of the Wi-Fi standard
00:52:45.030 --> 00:52:51.730
from really modifying the standard to use
a nonce misuse resistant encryption
00:52:51.730 --> 00:52:57.340
cipher. They are modifying the standard to
defend against key reinstallation attacks,
00:52:57.340 --> 00:53:00.820
but I think they're not yet going to
incorporate a nonce misuse resistant
00:53:00.820 --> 00:53:05.430
encryption cipher, because they still have
the impression that they're going to wait
00:53:05.430 --> 00:53:11.760
probably a while and once that technology
is more mature they're going to use that.
00:53:11.760 --> 00:53:15.900
If I understood your second question, you
also have encryption algorithms, where you
00:53:15.900 --> 00:53:20.550
don't have deterministic nonce, but you
have a nonce, which for every encryption
00:53:20.550 --> 00:53:27.560
operation e.g. is random.
Mic1: Actually in the GCM standard there
00:53:27.560 --> 00:53:32.470
are two possibilities: one deterministic,
MV: Yeah.
00:53:32.470 --> 00:53:38.270
Mic1: and the second random.
MV: So the risk of using a random
00:53:38.270 --> 00:53:43.130
initialization vector is, that you may
have a bad random generator,
00:53:43.130 --> 00:53:52.010
that it can go wrong there. On that, that
you still have nonce reuse, so even with a
00:53:52.010 --> 00:53:56.680
randomly generated nonce it can
also go bad, but then there are different
00:53:56.680 --> 00:54:02.050
attacks. And I think, there has been a
paper that analyzes a certain TLS
00:54:02.050 --> 00:54:07.210
libraries, where they do find attacks, where
in that case the GCM algorithm can still
00:54:07.210 --> 00:54:11.930
be attacked, not through key reinstallation
attacks, but because there is, because
00:54:11.930 --> 00:54:15.780
basically the nonce isn't really random,
e.g. sometimes a bad implementation
00:54:15.780 --> 00:54:21.070
always uses the same random nonce.
Person X: Um, direct answer...
00:54:21.070 --> 00:54:22.610
Herald: Err, sorry,...
X: Direct answer to his question number
00:54:22.610 --> 00:54:30.590
one: because he asked, whether there's
right now an approach to modify the
00:54:30.590 --> 00:54:38.340
standard towards being resistant against
this attack, right now there is no IEEE
00:54:38.340 --> 00:54:46.170
task group working on an amendment which
will fix this.
00:54:46.170 --> 00:54:50.910
MV: Well, there is... they are working to
prevent the key reinstallation attack.
00:54:50.910 --> 00:54:54.320
X: Well, there is no official
active task group right now.
00:54:54.320 --> 00:54:57.030
MV: Okay that could be, but there are still
people working on that.
00:54:57.030 --> 00:54:58.980
X: Yeah, they're working on that,
but no
00:54:58.980 --> 00:55:00.600
task group, right?
MV: Ok. Thank you.
00:55:00.600 --> 00:55:03.400
Herald: Okay thank you.
Here in number 3.
00:55:03.400 --> 00:55:07.510
Mic3: Yes, thanks for your
amazing talk.
00:55:07.510 --> 00:55:11.320
Just for my personal understanding:
could you briefly go back to
00:55:11.320 --> 00:55:17.370
the slide with the 4-way
handshake, like, right in the beginning?
00:55:17.370 --> 00:55:21.010
MV: Yup, so the attack or the handshake
itself?
00:55:21.010 --> 00:55:28.770
Mic3: Yeah, yeah the attack.
MV: So let's go to this slide.
00:55:28.770 --> 00:55:37.270
Mic3: Yeah so all you get from this, is the
keystream that is used to encrypt
00:55:37.270 --> 00:55:41.880
the the Msg4, right,
that's all you get?
00:55:41.880 --> 00:55:45.550
MV: Yes, but you can already use that to
start decrypting frames and what you can
00:55:45.550 --> 00:55:51.480
do as an attacker, you have several options.
The first thing you can do is, you can keep
00:55:51.480 --> 00:55:54.960
triggering new handshakes by
deauthenticating the client, so you can
00:55:54.960 --> 00:56:02.940
always decrypt one packet at a time.
What you can also do is, you can wait with
00:56:02.940 --> 00:56:09.090
sending this retransmitted Msg3
to the clients, because sometimes you know
00:56:09.090 --> 00:56:12.090
the encrypted data that is sent. So you
know that a packet is an ARP request, you
00:56:12.090 --> 00:56:16.650
know that the HTTP requests. You can capture
quite some packets where you know the
00:56:16.650 --> 00:56:22.370
content, to derive some known key stream
and once you have that, you can forward
00:56:22.370 --> 00:56:27.780
Msg3 to trigger a key
reinstallation and then you have collected
00:56:27.780 --> 00:56:33.830
quite some key stream to be able to
decrypt several packets at a time. So you
00:56:33.830 --> 00:56:38.910
can use tactics like that, you can rely on
the packet length to basically determine,
00:56:38.910 --> 00:56:43.770
what the type of packet is, where you have
known plaintext and you can use that to
00:56:43.770 --> 00:56:47.780
derive new key stream and there are a lot
of ways to play around with that.
00:56:47.780 --> 00:56:51.680
Mic3: Yeah but, all you get here is the -
because the key stream that you get is
00:56:51.680 --> 00:56:59.630
already being used immediately, because
it's being used to encrypt Msg4.
00:56:59.630 --> 00:57:02.940
MV: Well, we know the content of Msg4
00:57:02.940 --> 00:57:08.550
and we abuse, that Msg4 is
encrypted to derive known key stream and
00:57:08.550 --> 00:57:14.130
we can then use that to encrypt data
frames, which we do not know and... we
00:57:14.130 --> 00:57:15.740
should discuss this offline.
Mic3: Yeah.
00:57:15.740 --> 00:57:19.850
Herald: Perhaps this is for later
discussion with more in detail. Now we
00:57:19.850 --> 00:57:24.750
switch to number two... number four, I
think it is. Yeah, thanks.
00:57:24.750 --> 00:57:30.940
Mic4: Yes. Great find really and an
awesome talk. Could you maybe elaborate a
00:57:30.940 --> 00:57:38.100
bit on how to still use the advantage of
formal verification in the sense of, let's
00:57:38.100 --> 00:57:44.330
say, the flaws that it has, it gives a very
false sense of security in your sense, how
00:57:44.330 --> 00:57:48.990
can you still benefit from formal
verification?
00:57:48.990 --> 00:57:55.540
MV: Well, I think the attitude we should
adopt is, that formal verification of code
00:57:55.540 --> 00:58:01.670
or of algorithms increases the amount of
trust we can put into a program or into a
00:58:01.670 --> 00:58:07.450
protocol, but it's not just because it's
formally verified that it's secure.
00:58:07.450 --> 00:58:12.270
Perhaps one of the attitudes that people
had was: 'oh it's firmly verified, it must
00:58:12.270 --> 00:58:17.840
be fine'. We should abandon that attitude
and instead we should say: "Ok, it's
00:58:17.840 --> 00:58:21.750
formally verified but, you know, let's
check if the model they used reflects
00:58:21.750 --> 00:58:28.480
reality. Let's see if the proof is correct"
and so on. So, we should still employ a
00:58:28.480 --> 00:58:33.470
formal verification but we should just
treat it as additional evidence, that
00:58:33.470 --> 00:58:41.540
something looks secure.
Herald: Ok, there's another question on mic 2
00:58:41.540 --> 00:58:47.250
Mic2: The first part is on the slide
you're currently on. As far as I
00:58:47.250 --> 00:58:52.880
understood it in the talk, the
retransmission of Msg4 is not
00:58:52.880 --> 00:58:56.860
supposed to be encrypted by the standard.
MV: Correct.
00:58:56.860 --> 00:59:02.240
Mic2: So if you follow the standards, you
shouldn't have a problem here.
00:59:02.240 --> 00:59:05.630
MV: No, then you still have a problem,
because what you can then you do, is just
00:59:05.630 --> 00:59:10.000
wait for a data packet where you know that
contents of, e.g.it can be an ARP
00:59:10.000 --> 00:59:14.660
request, you can derive most fields of
that, it can be a DHCP request, it can be
00:59:14.660 --> 00:59:22.101
be a TCP SYN packet, or it can be some
plain text HTML frames. E.g. there
00:59:22.101 --> 00:59:28.770
has been work to fingerprint the length of
HTTP requests, to be able to determine
00:59:28.770 --> 00:59:32.440
which page you are visiting, so purely
based on the length, we can determine the
00:59:32.440 --> 00:59:37.260
contents of the website you are looking
for. We can then derive known plaintext
00:59:37.260 --> 00:59:44.020
and basically there are a lot of ways to
predict the content of a frame, to then
00:59:44.020 --> 00:59:51.750
derive known keystream and to then trigger
a key reinstallation attack to then abuse this.
00:59:51.750 --> 00:59:55.190
Herald: Ok we have time for one last
question. Mic number 1?
00:59:55.190 --> 01:00:04.730
Mic1: Um, so as far as I understood your
research, and so we, if we have like 11W
01:00:04.730 --> 01:00:11.240
deployed in the network, we are still
vulnerable to the attack, because as 11W
01:00:11.240 --> 01:00:19.590
specifies the encryption, I'm supposed by
this amendment, is also done by the
01:00:19.590 --> 01:00:28.020
encryption use on the network like before,
so 11W is not really a way to secure
01:00:28.020 --> 01:00:33.690
the network?
MV: Well, if I got it right, 11W is, one of
01:00:33.690 --> 01:00:36.380
the things it does, is protect the
management's frames, if I'm correct?
01:00:36.380 --> 01:00:39.122
Mic1: Yes.
MV: Yes.
01:00:39.122 --> 01:00:44.620
MV: So using that does not defend against
these attacks.
01:00:44.620 --> 01:00:50.710
Herald: Ok, I think there's still quite
details, where people are curious about,
01:00:50.710 --> 01:00:55.160
because it's everybody starting this
question "as far as I understood". So I think,
01:00:55.160 --> 01:00:58.840
this was a really nice comprehensive talk
and I want to thank you. And everybody who
01:00:58.840 --> 01:01:03.660
has more questions, perhaps can find you
here and ask you more or have a look into
01:01:03.660 --> 01:01:06.990
the paper, perhaps read everything in
detail there.
01:01:06.990 --> 01:01:11.540
So, please another big round of applause
for Mathy and his amazing talk!
01:01:11.540 --> 01:01:13.276
Thank you very much.
MV: Thank you!
01:01:13.276 --> 01:01:20.510
applause
01:01:20.510 --> 01:01:26.095
34c3 outro
01:01:26.095 --> 01:01:41.861
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!