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