1
00:00:00,000 --> 00:00:16,620
<i>34c3 intro</i>

2
00:00:16,620 --> 00:00:23,720
Herald: I'm really happy to be able to
introduce our next speaker. Mathy is a

3
00:00:23,720 --> 00:00:30,180
postdoc in Network Security and Applied
Crypto. He took part in discovering and

4
00:00:30,180 --> 00:00:35,860
implementing quite some attacks in this
field and especially in the wireless

5
00:00:35,860 --> 00:00:43,490
sector. And today he will show us, that all
our Wi-Fi devices are vulnerable.

6
00:00:43,490 --> 00:00:49,120
Especially the ones with Linux and
Android. So, I don't want to go into the

7
00:00:49,120 --> 00:00:53,140
technical details, because he would do
this and I think if you're interested in

8
00:00:53,140 --> 00:00:57,960
even learning more about it, he even linked
the research paper as well as the scripts

9
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

10
00:01:04,190 --> 00:01:06,699
applause for Mathy Vanhoef!

11
00:01:06,699 --> 00:01:11,510
<i>applause</i>

12
00:01:11,510 --> 00:01:15,960
Mathy Vanhoef: Ok, thank you for the
introduction and thank you all for

13
00:01:15,960 --> 00:01:19,921
attending the talk, even though it's
already a bit late in the evening. Thank

14
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

15
00:01:25,480 --> 00:01:30,750
on WPA2 and you probably have already
heard about this under the name of KRACK

16
00:01:30,750 --> 00:01:37,770
attacks. Now, the history of this research
is quite interesting, because during my PhD,

17
00:01:37,770 --> 00:01:44,490
I was already researching the security of
wireless networks and during my PhD

18
00:01:44,490 --> 00:01:50,840
defense last year, when I was finishing up
on writing my thesis, one of the jury

19
00:01:50,840 --> 00:01:57,230
members in my PhD asked: "Hey, you're
recommending WPA2 with AES in your thesis,

20
00:01:57,230 --> 00:02:03,390
but are you sure that's really a secure
solution?" And last year my answer was:

21
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

22
00:02:08,229 --> 00:02:11,920
ignore some brute-force attacks against
the password, if you select a secure

23
00:02:11,920 --> 00:02:16,910
password, then there are no real weaknesses
that are known. On top of that, there are

24
00:02:16,910 --> 00:02:21,190
also mathematical proofs that state that
if you have the 4-way handshake on the

25
00:02:21,190 --> 00:02:27,490
encryption algorithm, that it's supposed to
be secure. Unfortunately, a year later I

26
00:02:27,490 --> 00:02:32,800
was staring at some OpenBSD code. In
particular, I was looking at this function

27
00:02:32,800 --> 00:02:39,440
called ic_set_key. The details aren't
important here yet, but this key installs

28
00:02:39,440 --> 00:02:44,470
the encryption key for use by the driver,
so frames get encrypted and I was

29
00:02:44,470 --> 00:02:48,240
wondering, what
would happen if this function is called

30
00:02:48,240 --> 00:02:53,459
twice. And I was thinking, like, will it
reinstall the key and what will happen

31
00:02:53,459 --> 00:02:58,380
when you reinstall the key? And it turns
out that answering this question led to

32
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

33
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

34
00:03:13,589 --> 00:03:19,590
explain the attack, I will illustrate it
against the 4-way handshake. After that I

35
00:03:19,590 --> 00:03:24,470
will discuss the impact of the attack in
practice, then I will go over some

36
00:03:24,470 --> 00:03:28,720
common misconceptions that have been
floating around the internet and finally I

37
00:03:28,720 --> 00:03:31,940
will discuss some lessons that we can
learn from this

38
00:03:31,940 --> 00:03:37,819
research and from our findings. Let's get
started with explaining the attack against

39
00:03:37,819 --> 00:03:42,290
the 4-way handshake and the first
question I have to answer here is: what

40
00:03:42,290 --> 00:03:48,740
exactly is this 4-way handshake? And the
4-way handshake is executed whenever

41
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

42
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

43
00:03:57,290 --> 00:04:02,489
enterprise network-networks where you for
example have a username and a password to

44
00:04:02,489 --> 00:04:06,239
log in.
The purpose of this handshake is to verify

45
00:04:06,239 --> 00:04:10,800
that you possess the correct credentials
in order to connect to the network and at

46
00:04:10,800 --> 00:04:15,250
the same time, this 4-way handshake
negotiates a fresh session key that will

47
00:04:15,250 --> 00:04:19,979
be used to encrypt data frames.
This session key is called the PTK, the

48
00:04:19,979 --> 00:04:27,610
pairwise temporal key. And as I mentioned,
this handshake seemed to be really secure

49
00:04:27,610 --> 00:04:33,769
because for over a decade, no attacks have
been found against it, assuming that a

50
00:04:33,769 --> 00:04:40,020
secure password is being used, and on top
of that, the 4-way handshake was

51
00:04:40,020 --> 00:04:43,729
formally proven to be secure and the
encryption algorithm that is used after

52
00:04:43,729 --> 00:04:48,659
the 4-way handshake, which generally
is AES CCMP, that was also formally

53
00:04:48,659 --> 00:04:53,550
proven to be secure.
Yet somehow we did find an attack even

54
00:04:53,550 --> 00:04:57,199
though we have all these formal proofs,
even though this protocol has been around

55
00:04:57,199 --> 00:05:01,230
for that long. So what went
wrong?

56
00:05:01,230 --> 00:05:08,050
To explain this, I'm going to explain how
the 4-way handshake works, using this

57
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

58
00:05:12,550 --> 00:05:17,710
connect to the access point on the left.
Now, in order to start the 4-way

59
00:05:17,710 --> 00:05:22,020
handshake, there first needs to be some
preshared secrets between the client on

60
00:05:22,020 --> 00:05:26,749
the access point and if you have a network
at home, this preshared secret is basically

61
00:05:26,749 --> 00:05:30,750
the password of the network. But if you
have an enterprise or a more professional

62
00:05:30,750 --> 00:05:35,649
network, then - where you for example have
to log in using a username and a password -

63
00:05:35,649 --> 00:05:41,789
then first 802.1x authentication algorithm
is executed, which in practice is commonly

64
00:05:41,789 --> 00:05:47,079
some form of RADIUS authentication.
The details of that are not important.

65
00:05:47,079 --> 00:05:51,180
What's important here is the result.
Namely, after this authentication phase

66
00:05:51,180 --> 00:05:55,509
there is a shared secret between the
client and the access point.

67
00:05:55,509 --> 00:06:01,460
And once we have this shared secret, we
can execute the 4-way handshake. What

68
00:06:01,460 --> 00:06:06,879
the first two messages in the 4-way
handshake do, is they transport a random

69
00:06:06,879 --> 00:06:11,099
number between both devices.
So in particular, the access point will

70
00:06:11,099 --> 00:06:15,569
generate a random number called the access
point nonce, the ANonce, and it will

71
00:06:15,569 --> 00:06:20,379
transport that to the client.
Then in reaction to that, the client will

72
00:06:20,379 --> 00:06:24,150
generate its own random number called the
supplicant nonce - and supplicant is

73
00:06:24,150 --> 00:06:29,119
basically a synonym for client - and it
will send that random number, the SNonce,

74
00:06:29,119 --> 00:06:36,550
to the access point in the second message
of the handshake. Once both devices have

75
00:06:36,550 --> 00:06:41,690
each other's random number, then we can
derive this unique per session key.

76
00:06:41,690 --> 00:06:46,860
How that key is derived, is fairly simple: we
take the preshared key, that is known

77
00:06:46,860 --> 00:06:51,669
between these two devices, we combine that
with both of these random numbers and the

78
00:06:51,669 --> 00:06:56,849
result is the PTK, this fresh encryption
key, that will later be used to encrypt

79
00:06:56,849 --> 00:07:02,930
data frames.
Now, I want to clarify one thing, and you

80
00:07:02,930 --> 00:07:07,849
might have heard about this research under
the name 'key reinstallation attacks:

81
00:07:07,849 --> 00:07:13,610
forcing nonce reuse in WPA2'.
I want to highlight here that the nonce

82
00:07:13,610 --> 00:07:17,990
reuse does not refer to the nonce reuse
about the ANonce or SNonce during the

83
00:07:17,990 --> 00:07:22,479
4-way handshake. So here we're going [to]
assume, that these ANonce and SNonce, that

84
00:07:22,479 --> 00:07:27,249
they are random and not predictable. The
nonce reuse refers to nonce reuse that

85
00:07:27,249 --> 00:07:34,000
will happen during the encryption
algorithm, which I will explain in a bit.

86
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

87
00:07:40,249 --> 00:07:47,429
handshake, a bit simplified, it basically
confirms that both parties negotiate at

88
00:07:47,429 --> 00:07:51,999
the same PTK, the same encryption key. And
in particular, the access point will send

89
00:07:51,999 --> 00:07:56,909
Message 3 to the client. The client will
verify the authenticity of that frame and

90
00:07:56,909 --> 00:08:04,309
if everything looks ok, the client will
reply using Msg4 to the access point.

91
00:08:04,309 --> 00:08:08,739
Once these four messages have been
exchanged, both the client on the access

92
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

93
00:08:15,569 --> 00:08:22,139
and these data frames will be encrypted.
Ok, so now we covered the 4-way

94
00:08:22,139 --> 00:08:29,010
handshake, we know the highlight of how it
works. Now the final thing I need to

95
00:08:29,010 --> 00:08:34,639
explain, before we can get to the details
of the attack, is: How does encryption work

96
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

97
00:08:40,059 --> 00:08:44,510
to send some plain text data from, e.g.,
from the client to the access

98
00:08:44,510 --> 00:08:49,399
point. Then the first thing that will
happen, is that we will take the PTK and

99
00:08:49,399 --> 00:08:53,309
the fresh session key, that the 4-way
handshake just negotiated and we will

100
00:08:53,309 --> 00:08:59,940
combine that with a packet number. And here,
this packet number is called a nonce.

101
00:08:59,940 --> 00:09:04,750
The packet number is incremented by 1 for
every frame, that is transmitted and the ID

102
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

103
00:09:09,579 --> 00:09:15,930
packet key for every packet that we want
to transmit.

104
00:09:15,930 --> 00:09:20,329
The way the encryption now works is fairly
simple, we feed this per packet key as

105
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

106
00:09:25,911 --> 00:09:31,610
stream with the plaintext and the result
is the encrypted data, the ciphertext.

107
00:09:31,610 --> 00:09:36,620
Now we prepense a plaintext header with
some metadata and also the packet number,

108
00:09:36,620 --> 00:09:40,479
the nonce value, that we used, so the
receiver will be able to decrypt the

109
00:09:40,479 --> 00:09:46,120
packet. Essentially, this is just a stream
cipher, where a nonce is used to always

110
00:09:46,120 --> 00:09:52,899
derive a unique per packet key. Now there's
one essential requirements in this

111
00:09:52,899 --> 00:09:58,000
encryption key.
That is, that under a particular session

112
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,

113
00:10:04,300 --> 00:10:08,299
you will generate the same per packet key.
You will generate the same key stream and

114
00:10:08,299 --> 00:10:12,080
this will allow you to decrypt packets,
that are sent and depending on the

115
00:10:12,080 --> 00:10:19,359
specific stream cipher that is being used,
it will also allow you to forge frames.

116
00:10:19,359 --> 00:10:20,549
<i>clears his throat</i>

117
00:10:20,549 --> 00:10:28,040
Now the question here is: Is this nonce
value indeed only used once? And we already

118
00:10:28,040 --> 00:10:32,350
know, that it is incremented by one for
every packet that is transmitted, so the

119
00:10:32,350 --> 00:10:37,070
only question that remains is: To what
value is this packet number initialized?

120
00:10:37,070 --> 00:10:44,050
And the answer is quite simple: when the
PTK is installed, this transmit nonce is

121
00:10:44,050 --> 00:10:49,279
initialized to 0.
At first sight, this makes a lot of sense.

122
00:10:49,279 --> 00:10:53,550
I mean, you initiate that number to 0,
you increment it by one for every packet,

123
00:10:53,550 --> 00:11:00,700
so surely this nonce is a specific nonce
value, is only used once.

124
00:11:00,700 --> 00:11:06,959
Unfortunately, this is not the case. And the
reason this nonce value or a particular

125
00:11:06,959 --> 00:11:11,930
nonce value is sometimes used more than
once, is because we can force

126
00:11:11,930 --> 00:11:17,540
reinstallations of the PTK and those
reinstallations will again reset the nonce

127
00:11:17,540 --> 00:11:23,980
to 0 and then nonce value will be reused.
So, how can we force these key

128
00:11:23,980 --> 00:11:29,339
reinstallations as an attacker?
Let's again take the example where we have

129
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

130
00:11:34,660 --> 00:11:38,970
this case, we also have an attacker that
sits in the middle and this attacker will

131
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-

132
00:11:45,410 --> 00:11:50,800
middle position, the adversary isn't yet
able to decrypt any packets. This man-in-

133
00:11:50,800 --> 00:11:56,020
the-middle position is purely there, so we
can reliably block packets from arriving

134
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

135
00:12:01,909 --> 00:12:06,690
way we obtain this man-in-the-middle
position is, we simply take all the frames

136
00:12:06,690 --> 00:12:11,250
that the access point which, e.g.,
is on Channel 6, we take all the frames

137
00:12:11,250 --> 00:12:16,250
that it is broadcasting and as an attacker,
we capture them and we rebroadcast them, we

138
00:12:16,250 --> 00:12:21,220
retransmit them on a different channel, 
e.g. Channel 1. So we are effectively

139
00:12:21,220 --> 00:12:26,829
cloning the real access point on a rogue
channel and then we force the victim into

140
00:12:26,829 --> 00:12:31,069
connecting to this rogue access point on
this different channel.

141
00:12:31,069 --> 00:12:36,020
So let's assume now that the attacker
obtains this position, this man-in-the-

142
00:12:36,020 --> 00:12:42,620
middle position and the first stage of the
4-way handshake, we don't modify any

143
00:12:42,620 --> 00:12:48,579
frames at all. So e.g. if the
client is using 802.1x authentication, we

144
00:12:48,579 --> 00:12:52,800
simply forward all the frames between
these two different channels and we do the

145
00:12:52,800 --> 00:12:56,600
same thing with the first three messages
of the 4-way handshake, we simply

146
00:12:56,600 --> 00:13:03,970
forward them unmodified. Where the attack
starts, is if the client sends Msg4

147
00:13:03,970 --> 00:13:08,990
of the 4-way handshake. Instead of
forwarding this message to the access

148
00:13:08,990 --> 00:13:14,329
point, we don't forward it, which in our
situation is equivalent to blocking the

149
00:13:14,329 --> 00:13:20,860
message from arriving at the access point.
Now what's interesting in this situation,

150
00:13:20,860 --> 00:13:26,670
is that from the perspective of the client,
the handshake now successfully completed.

151
00:13:26,670 --> 00:13:32,040
After all, it received Msg3, it
replied using Msg4 and it thinks that

152
00:13:32,040 --> 00:13:35,860
the handshake is done, meaning it now
installs the encryption key and installs

153
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

154
00:13:44,439 --> 00:13:48,660
was completed, it has installed the key,
but the access point hasn't received

155
00:13:48,660 --> 00:13:55,339
Msg4 yet and the access point will
try to recover from this situation and it

156
00:13:55,339 --> 00:14:02,269
will do that by retransmitting a new
Msg3. And as the - as we, as the

157
00:14:02,269 --> 00:14:06,620
attacker, will forward this message to the
client, the client will accept this

158
00:14:06,620 --> 00:14:11,579
retransmitted Msg3 and then the Wi-Fi
standard says, that if you receive a

159
00:14:11,579 --> 00:14:16,940
retransmitted Msg3, you will reply
using a new Msg4. After that you will

160
00:14:16,940 --> 00:14:23,449
also install the encryption key again. Now,
one remark that I want to make here, is

161
00:14:23,449 --> 00:14:30,519
that, when we receive the retransmitted
Msg3, we reply using a new Msg4,

162
00:14:30,519 --> 00:14:36,149
however, this Msg4 will be already
encrypted at the link layer and the reason

163
00:14:36,149 --> 00:14:40,980
it's already encrypted, is because these
handshake messages are normal data frames

164
00:14:40,980 --> 00:14:45,879
and well, we already installed the
encryption key to encrypt data frames. So

165
00:14:45,879 --> 00:14:51,610
nearly all implementations we tested, will
send Msg4, the retransmitted Msg4,

166
00:14:51,610 --> 00:14:56,709
in an encrypted fashion. Now, I want to
remark here, that the Wi-Fi standard

167
00:14:56,709 --> 00:15:02,649
actually demands that Msg4, if it is
retransmitted, should be sent in plain text,

168
00:15:02,649 --> 00:15:07,020
so according to the specification, this
shouldn't happen. But nearly all

169
00:15:07,020 --> 00:15:12,999
implementations we tested, sent a
retransmitted Msg3 using encryption,

170
00:15:12,999 --> 00:15:17,730
and we will abuse this observation later.
So as I mentioned, after the client

171
00:15:17,730 --> 00:15:22,339
receives a retransmitted Msg3, it'll
reply using Msg4, it will again

172
00:15:22,339 --> 00:15:27,499
install the encryption key, and as a
result of that, this transmit nonce will be

173
00:15:27,499 --> 00:15:34,160
reset, which means, that if the client now
sends another data frame, it will again

174
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

175
00:15:41,569 --> 00:15:46,220
have key stream reuse, meaning we can now
try to abuse this to decrypt the data

176
00:15:46,220 --> 00:15:51,879
frame.
Now, how are we precisely going to abuse

177
00:15:51,879 --> 00:15:57,740
this, because we do somehow need to
recover the key stream that was used? And

178
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

179
00:16:03,309 --> 00:16:08,180
plain text, and a retransmission of
Msg4 is later sent in an encrypted

180
00:16:08,180 --> 00:16:12,161
fashion. Now, there is a small difference
between these two messages, but

181
00:16:12,161 --> 00:16:15,600
essentially we have a message sent in
plaintext, and we have a message sent

182
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

183
00:16:20,820 --> 00:16:24,350
the key stream corresponding to the nonce
value of 1.

184
00:16:24,350 --> 00:16:28,680
This data frame here at the bottom, it
also uses nonce value of 1, meaning it

185
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

186
00:16:33,130 --> 00:16:41,659
you go: We decrypted the packets and we
have now defeated WPA2. So...

187
00:16:41,659 --> 00:16:50,530
<i>Applause</i>
Thank you. So, that describes the attack

188
00:16:50,530 --> 00:16:56,129
against the 4-way handshake. And the
4-way handshake is not the only Wi-Fi

189
00:16:56,129 --> 00:17:00,310
handshake that is vulnerable. There are
also other handshakes which can be

190
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

191
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.

192
00:17:09,650 --> 00:17:14,260
Here, I'm just going to discuss more the
high-level concepts and the ideas behind

193
00:17:14,260 --> 00:17:18,880
the attack. So, e.g., one handshake
that is also vulnerable, is the group key

194
00:17:18,880 --> 00:17:23,260
handshake, and that handshake is used to
transport the group key from the access

195
00:17:23,260 --> 00:17:27,398
point to the client. And that key is used
to encrypt broadcast and multicast

196
00:17:27,398 --> 00:17:33,570
traffic. Then we also have the FT
handshake. The FT handshake is used, when

197
00:17:33,570 --> 00:17:38,460
you roam from one access point to another
access point of the same Wi-Fi network.

198
00:17:38,460 --> 00:17:42,730
It's used so you can quickly switch
from one access point to another without

199
00:17:42,730 --> 00:17:47,450
a long timeout. And finally, another
handshake that's also vulnerable is the

200
00:17:47,450 --> 00:17:51,990
PeerKey handshake, and that's used when
two clients want to communicate directly

201
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

202
00:17:59,510 --> 00:18:05,500
practical impact of our attacks are. And
I'm first going to start with the general

203
00:18:05,500 --> 00:18:11,770
impact that a key reinstallation attack
has. So, let's assume we have a device

204
00:18:11,770 --> 00:18:15,690
that's vulnerable. This device can either
be a client device, e.g. it can be

205
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

206
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

207
00:18:26,970 --> 00:18:32,520
vulnerable to our key reinstallation
attack, the first thing that generally

208
00:18:32,520 --> 00:18:38,930
always happens, if this device ever sends
encrypted data frames, we can force it to

209
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

210
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

211
00:18:50,529 --> 00:18:57,530
encrypted frames sent towards this device.
Now, why is that the case? That's because

212
00:18:57,530 --> 00:19:02,500
if a key is reinstalled, not only is this
transmit nonce reset to 0, but another

213
00:19:02,500 --> 00:19:08,380
parameter, which is called the replay
counter, it is also reset to 0. And this

214
00:19:08,380 --> 00:19:12,490
replay counter, as the name implies,
it's used to detect retransmissions, or

215
00:19:12,490 --> 00:19:18,690
it's used to detect malicious replays. If
this counter is reset, we can also replay

216
00:19:18,690 --> 00:19:24,510
frames towards a vulnerable device. So,
that's the general impact of a key

217
00:19:24,510 --> 00:19:33,110
reinstallation attack, but there are a lot
of other factors which also influence the

218
00:19:33,110 --> 00:19:41,250
exact impact of the attack, and one of the
things that probably has the biggest

219
00:19:41,250 --> 00:19:48,100
influence, is the encryptions cipher that
is being used. So, e.g., these days

220
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

221
00:19:52,350 --> 00:19:58,659
encryption algorithm in Wi-Fi networks.
Against this algorithm, the impact in a

222
00:19:58,659 --> 00:20:04,070
sense stays limited to only decrypting and
replaying frames. It's not possible to

223
00:20:04,070 --> 00:20:10,230
abuse our key reinstallation attack to now
forge frames. And really, we got lucky

224
00:20:10,230 --> 00:20:16,690
here, because this is the most widely used
cipher, and against this cipher we cannot

225
00:20:16,690 --> 00:20:22,260
start to forge frames. Because, if we
would have been using the older encryption

226
00:20:22,260 --> 00:20:28,130
algorithm, which is WPA TKIP, against that
algorithm, we would be able to recover the

227
00:20:28,130 --> 00:20:32,200
Message Integrity Check key, which is
basically just a fancy word for the

228
00:20:32,200 --> 00:20:37,179
authentication key. And once we have that
authentication key, we would be able to

229
00:20:37,179 --> 00:20:44,880
forge frames that appear to be sent by the
device under attack. Interestingly, lately

230
00:20:44,880 --> 00:20:50,100
there's also been a new encryption
algorithm that is being introduced, and

231
00:20:50,100 --> 00:20:53,850
that algorithm is
called GCMP. It's fairly new, so only a

232
00:20:53,850 --> 00:20:59,169
few devices currently support it, and
currently it is being rolled out under the

233
00:20:59,169 --> 00:21:06,190
name of WiGig. Against this algorithm, the
impact of a key reinstallation attack is

234
00:21:06,190 --> 00:21:14,000
really the worst, because here we can
again recover the authentication key, but

235
00:21:14,000 --> 00:21:18,520
when we use GCMP, the same authentication
key is used in both communication

236
00:21:18,520 --> 00:21:23,490
directions. So against GCMP, we would be
able to forge frames that are sent from

237
00:21:23,490 --> 00:21:27,580
the client to the access point and also
forge frames that appear to be sent

238
00:21:27,580 --> 00:21:32,630
from the access point to the client, while
for the WPA-TKIP algorithm, we would only

239
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.

240
00:21:37,509 --> 00:21:42,630
So, my opinion - this is a bit surprising,
because GCMP is the latest encryption

241
00:21:42,630 --> 00:21:46,880
algorithm that is defined in the Wi-Fi
standard, yet the impact against it would

242
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

243
00:21:51,950 --> 00:21:55,490
would have found the attack, say maybe
five or ten years later, and everyone

244
00:21:55,490 --> 00:22:01,710
would be using this algorithm, the impact
would have been a lot worse. Another thing

245
00:22:01,710 --> 00:22:06,280
that influences the impact of the attack
is, which specific handshake we are

246
00:22:06,280 --> 00:22:11,169
attacking. For example, if we attack the
group key handshake, then the only thing

247
00:22:11,169 --> 00:22:14,159
we can do is, we can 
only replay, broadcast or

248
00:22:14,159 --> 00:22:20,390
multicast frames. Now, why is that the
case? Why can't we decrypt broadcast or

249
00:22:20,390 --> 00:22:26,390
multicast frames, if a key reinstallation
occurs? And the reason is, that if we

250
00:22:26,390 --> 00:22:30,150
attack the group key handshake, we are
attacking the client, and the client is

251
00:22:30,150 --> 00:22:35,380
never sending actual encrypted broadcast
frames, so will never reuse the transmit

252
00:22:35,380 --> 00:22:40,050
nonce when it encrypts frames, because
it's never encrypting frames. Now, why is

253
00:22:40,050 --> 00:22:44,519
it, that the client never sends real
encrypted broadcast frames? Well, the

254
00:22:44,519 --> 00:22:49,100
reason is quite simple. Let's say, we have
the network layout shown here and the

255
00:22:49,100 --> 00:22:54,229
client on the left wants to send a
broadcast frames to all the other clients.

256
00:22:54,229 --> 00:22:58,419
Now, what happens here, is that this client
will send the data frame it wants to

257
00:22:58,419 --> 00:23:03,690
broadcast as a Unicast frame to the access
point only, meaning it won't encrypt it

258
00:23:03,690 --> 00:23:09,980
yet under the group key. It's the access
points that will broadcast this frame to

259
00:23:09,980 --> 00:23:14,149
all connected clients, and only the access
point will then encrypt it using the group

260
00:23:14,149 --> 00:23:16,350
key, and this is to assure that all
clients

261
00:23:16,350 --> 00:23:20,690
within range of the access point will
receive this broadcast message. Now, for

262
00:23:20,690 --> 00:23:24,659
us, this means that only the access point
is transmitting real encrypted broadcast

263
00:23:24,659 --> 00:23:28,940
frames, and in the group key handshake we
cannot attack the access point. We are

264
00:23:28,940 --> 00:23:33,059
only attacking the client, meaning in
practice, we can only replay broadcast

265
00:23:33,059 --> 00:23:37,560
frames to the client, at least if we are
targeting the group key handshake. So,

266
00:23:37,560 --> 00:23:42,980
really, the impact is limited in practice
if we attack this handshake, because

267
00:23:42,980 --> 00:23:47,769
generally, replaying broadcast data doesn't
have a high impact. Though, I do want to

268
00:23:47,769 --> 00:23:53,250
note, that some home automation systems use
broadcast traffic to, e.g., send

269
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

270
00:23:59,250 --> 00:24:03,970
lights on or off, so although the
impact of replaying broadcast frame is

271
00:24:03,970 --> 00:24:08,120
low, there are situations in practice,
where it does have some impact, but it

272
00:24:08,120 --> 00:24:13,090
really depends on your network setup and
the devices that you use. So, the other

273
00:24:13,090 --> 00:24:17,129
handshake that is vulnerable, is the 4-
way handshake, but we already discussed

274
00:24:17,129 --> 00:24:21,809
that. Against a 4-way handshake we can
attack the clients and the impact, is that

275
00:24:21,809 --> 00:24:25,610
we can replay and decrypt frames, and
depending on the encryption algorithm

276
00:24:25,610 --> 00:24:31,690
being used, we can possibly forge frames
as well. The situation is a lot more

277
00:24:31,690 --> 00:24:36,080
interesting for the FT handshake, though.
And remember, this handshake is used, when

278
00:24:36,080 --> 00:24:40,959
you roam from one access point to another
of the same network. Against the FT

279
00:24:40,959 --> 00:24:45,669
handshake, it's not the clients that we
can attack, but here we can attack the

280
00:24:45,669 --> 00:24:51,450
access point. And on top of that, when
attacking the FT handshake, we no longer

281
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

282
00:24:56,679 --> 00:25:01,370
explain this using our common example,
where a client wants to connect and where

283
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

284
00:25:08,330 --> 00:25:11,520
as the 4-way handshake, meaning you
also have four frames that are

285
00:25:11,520 --> 00:25:16,730
transmitted, but the big difference here
is, that with the FT handshake it's the

286
00:25:16,730 --> 00:25:21,220
client that sends the first message
in the handshake, while for the 4-way

287
00:25:21,220 --> 00:25:26,250
handshake it was the access point that
sends the first message. So, the handshake

288
00:25:26,250 --> 00:25:29,860
is practically the same as the 4-way
handshake, meaning, initially we have two

289
00:25:29,860 --> 00:25:34,190
messages that transport these random
numbers, these nonces, between both

290
00:25:34,190 --> 00:25:40,770
devices. Then, both these endpoints can
generate the fresh encryption key. Then

291
00:25:40,770 --> 00:25:46,090
the last two frames, they are again used
to confirm that both parties negotiated

292
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

293
00:25:51,210 --> 00:25:56,600
phase, and what happens here, is that the
third frame of the handshake is now sent

294
00:25:56,600 --> 00:26:01,970
from the client to the access point and
that is a reassociation request. And after

295
00:26:01,970 --> 00:26:06,779
the access point receives this frame, it
will reply using a reassociation response

296
00:26:06,779 --> 00:26:12,799
frame and it will install the encryption
key. Once it has installed the encryption

297
00:26:12,799 --> 00:26:18,590
key, it can of course start sending
encrypted data frames. So, let's again

298
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

299
00:26:23,820 --> 00:26:28,840
reassociation request that the client
previously transmitted, and we can simply

300
00:26:28,840 --> 00:26:36,450
replay it. That's because in the FT
handshake, there is no replay protection

301
00:26:36,450 --> 00:26:41,730
against messages of the handshake. So we
can just take that frame, we can send it

302
00:26:41,730 --> 00:26:45,380
again to the access point. The access
point will receive it, it will accept it,

303
00:26:45,380 --> 00:26:51,490
and it will reply using a reassociation
response. Now, so far this is not a

304
00:26:51,490 --> 00:26:57,440
problem. The problem here is, that again
the access point will reinstall the

305
00:26:57,440 --> 00:27:01,269
encryption key, and here it goes wrong
because we are reinstalling this

306
00:27:01,269 --> 00:27:05,889
encryption key. The transmit nonce is
again reset to 0, meaning if we now send

307
00:27:05,889 --> 00:27:11,930
the data frame again, the nonce value of 1
is used to encrypt these data frames,

308
00:27:11,930 --> 00:27:14,950
meaning the same key stream is used,
meaning we can start applying the same

309
00:27:14,950 --> 00:27:19,029
tricks to first derive some known key
stream and to then abuse that to attack

310
00:27:19,029 --> 00:27:24,250
the handshake. So, I want to highlight
here a few things. And the first is, the

311
00:27:24,250 --> 00:27:27,740
reason why we don't need a man-in-the-
middle position, is because handshake

312
00:27:27,740 --> 00:27:30,170
messages in
the FT handshake, they are not protected

313
00:27:30,170 --> 00:27:34,720
against replays, while in the 4-way
handshake, every handshake messages

314
00:27:34,720 --> 00:27:40,330
contains a sequence counter, where the
receiver uses the sequence counter to

315
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

316
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

317
00:27:48,090 --> 00:27:55,351
block packets and to trigger
retransmissions. Ok, so that's the

318
00:27:55,351 --> 00:28:01,630
explanation for the FT handshake. Another
factor that can influence the impacts of

319
00:28:01,630 --> 00:28:06,660
our attack in practice, is which operating
system and which device precisely we are

320
00:28:06,660 --> 00:28:12,120
attacking. And in particular, we see that
iOS and Windows, they are not vulnerable

321
00:28:12,120 --> 00:28:17,970
against attacks against a 4-way
handshake. And why is that the case? Well,

322
00:28:17,970 --> 00:28:22,360
that's because these two devices don't
really follow the standard, and they don't

323
00:28:22,360 --> 00:28:26,659
accept retransmissions of Msg3,
meaning we cannot abuse these

324
00:28:26,659 --> 00:28:33,180
retransmissions of Msg3 to trigger
these key reinstallations.

325
00:28:33,180 --> 00:28:36,380
Now, I want to make two remarks 
here. And the first one is, that

326
00:28:36,380 --> 00:28:41,550
against these devices we can still attack
the group key handshake. And particularly

327
00:28:41,550 --> 00:28:46,860
when looking at iOS, if we look at iOS
version 11, it does implement the standard

328
00:28:46,860 --> 00:28:50,679
properly and it does accept
retransmissions of Msg3, meaning that

329
00:28:50,679 --> 00:28:58,580
one is vulnerable to attacks against the
4-way handshake. Now, Linux is not much

330
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

331
00:29:04,460 --> 00:29:11,750
Android, it's called wpa_supplicant, and
against wpa_supplicant 2.4 and higher, we

332
00:29:11,750 --> 00:29:17,919
notice that, if we try to perform a key
reinstallation attack, it won't reinstall

333
00:29:17,919 --> 00:29:22,990
the secret key that was negotiated, but
no, instead it will suddenly install an

334
00:29:22,990 --> 00:29:27,870
all-zero encryption key, and then it of
course becomes very trivial to start

335
00:29:27,870 --> 00:29:36,919
decrypting data that this device is
transmitting. Now, why does this happen?

336
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

337
00:29:42,659 --> 00:29:48,990
the implementation does wrong, to... why it
installs this all-zero key. And to explain

338
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

339
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.

340
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,

341
00:30:01,080 --> 00:30:05,330
which is represented by the
handshake icon here, and we're also going

342
00:30:05,330 --> 00:30:10,429
to look at another entity, namely the
Linux kernel. It's the Linux kernel that

343
00:30:10,429 --> 00:30:15,239
will be responsible for encrypting data
frames, and wpa_ supplicant will be

344
00:30:15,239 --> 00:30:20,889
responsible for executing the 4-way handshake.
And of course we assume, that we as an

345
00:30:20,889 --> 00:30:27,410
attacker are nearby, and we again have
this man-in-the-middle position. So, what

346
00:30:27,410 --> 00:30:31,149
does an attacker have to do to cause this
installation of an all-zero encryption

347
00:30:31,149 --> 00:30:36,780
key? Well, again, we simply let the first
phase of the 4-way handshake execute

348
00:30:36,780 --> 00:30:42,460
normally, and when the access point sends
Msg3 of the 4-way handshake, we

349
00:30:42,460 --> 00:30:48,679
forward that to the Android. Android will
reply using Msg4. And we will

350
00:30:48,679 --> 00:30:53,510
again block Msg4 from arriving at the
access point.

351
00:30:53,510 --> 00:30:58,090
Now, completely similar to the case with
the 4-way handshake, the client thinks that

352
00:30:58,090 --> 00:31:02,019
the handshake now successfully completed,
meaning it will install the encryption

353
00:31:02,019 --> 00:31:07,600
key. How it will install the encryption
key is as follows: It commands the Linux

354
00:31:07,600 --> 00:31:15,059
kernel into installing the encryption key
in the driver. And the driver itself will

355
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

356
00:31:19,080 --> 00:31:24,280
then encrypt frames. Now this means that
wpa_supplicant, which is just a user land

357
00:31:24,280 --> 00:31:28,139
program, no longer needs to store the
encryption key, meaning it will clear it

358
00:31:28,139 --> 00:31:34,270
from memory. What will happen now, if we
continue with the attack, is that the

359
00:31:34,270 --> 00:31:38,969
access point will retransmit Msg3,
because it did not receive Msg4. The

360
00:31:38,969 --> 00:31:42,790
client will again happily accept this
retransmitted Msg3 and reply using

361
00:31:42,790 --> 00:31:48,289
Msg4. And again it will instruct the
Linux kernel saying "Hey, please install

362
00:31:48,289 --> 00:31:52,389
this encryption key that is located at
this address in the memory." But of

363
00:31:52,389 --> 00:31:56,789
course, that memory is now all zeros,
because that key has just been cleared

364
00:31:56,789 --> 00:31:59,720
from memory. So,
now it's basically commanding the Linux

365
00:31:59,720 --> 00:32:04,139
kernel into installing an all-zero
encryption key. And the Linux kernel and

366
00:32:04,139 --> 00:32:09,080
driver will happily obey this command and
they will install an all-zero encryption

367
00:32:09,080 --> 00:32:13,690
key, meaning at this point, all the data
that the client is sending, is encrypted

368
00:32:13,690 --> 00:32:18,370
using a known key, so we can easily
decrypt all the traffic, and of course we

369
00:32:18,370 --> 00:32:23,470
can also send any traffic we want to the
client. Basically, we are now a rogue

370
00:32:23,470 --> 00:32:28,529
access point and we can manipulate the
traffic of the client as we wish.

371
00:32:28,529 --> 00:32:37,699
<i>Applause</i>
MV: Thank you. So, after this you might be

372
00:32:37,699 --> 00:32:42,940
wondering, "Well, gee, is my device
vulnerable?" And you can test your own

373
00:32:42,940 --> 00:32:50,039
device using the following script. It's on
github. I have tested the script on Kali

374
00:32:50,039 --> 00:32:54,870
Linux, on Arch Linux, and also on Ubuntu,
so I could recommend using one of these

375
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

376
00:33:00,270 --> 00:33:05,409
tested ourselves, because we noticed that
if you use our testing scripts with some

377
00:33:05,409 --> 00:33:08,960
older
Wi-Fi devices, then there are some bugs in

378
00:33:08,960 --> 00:33:16,279
these Wi-Fi devices which cause our
scripts to fail. And one way to also

379
00:33:16,279 --> 00:33:20,010
prevent our scripts to fail, is to disable
hardware encryption. Now, how you should do

380
00:33:20,010 --> 00:33:25,409
that is also explained on this page. Using
these scripts, you can test both your

381
00:33:25,409 --> 00:33:29,140
client devices, you can test against
attacks against the 4-way handshake,

382
00:33:29,140 --> 00:33:33,799
the group key handshake, and there's also
a script to test the access point, whether

383
00:33:33,799 --> 00:33:40,519
it's vulnerable against attacks against
the FT handshake. Now, if you're going to

384
00:33:40,519 --> 00:33:45,500
try to see which devices are vulnerable,
you are most likely going to see that

385
00:33:45,500 --> 00:33:52,559
quite some clients are still vulnerable to
our attacks. Luckily, we can modify the

386
00:33:52,559 --> 00:33:58,129
access point to prevent attacks against
the client. In particular, we can make

387
00:33:58,129 --> 00:34:02,620
additional modifications to the access
point, such that the access points never

388
00:34:02,620 --> 00:34:07,149
retransmits Msg3 of the 4-way
handshake, and that it also never

389
00:34:07,149 --> 00:34:11,640
retransmits the first message of the group
key handshake. And if we do that, then

390
00:34:11,640 --> 00:34:17,060
clients that are connected to such a
modified access points, they are no longer

391
00:34:17,060 --> 00:34:19,130
vulnerable against most attacks. There are

392
00:34:19,130 --> 00:34:24,660
still some edge cases where the device is
vulnerable, but these have a very low

393
00:34:24,660 --> 00:34:29,909
impact. So, if we modify an access point
in this way, then connected clients are no

394
00:34:29,909 --> 00:34:34,719
longer vulnerable. One downside here is,
that because we are no longer

395
00:34:34,719 --> 00:34:40,530
retransmitting certain messages, it could
be that especially in a noisy environment,

396
00:34:40,530 --> 00:34:44,520
because we don't retransmit these messages
anymore, that the handshake may fail

397
00:34:44,520 --> 00:34:50,500
because the reliability is now less. Now,
one thing I also want to remark here,

398
00:34:50,500 --> 00:34:57,310
that... if you have a router, which is
vulnerable against our attack and a

399
00:34:57,310 --> 00:35:02,090
vendor says "Hey, we patched our router,
so we patched our access point to defend

400
00:35:02,090 --> 00:35:07,400
against attacks," then this does not mean
that this access point implements these

401
00:35:07,400 --> 00:35:10,780
countermeasures. Because these
countermeasures, they are additional

402
00:35:10,780 --> 00:35:15,920
modifications on top of the normal
patches to defend against the attack. So,

403
00:35:15,920 --> 00:35:21,130
only if a vendor explicitly says that "Our
patches of the access point also prevent

404
00:35:21,130 --> 00:35:26,320
attacks against clients," then, only if
they explicitly say that, are attacks

405
00:35:26,320 --> 00:35:32,640
against the client also prevented. Ok,
so now I want to cover some misconceptions

406
00:35:32,640 --> 00:35:39,810
that have been floating around the
internet. And the first one is, that some

407
00:35:39,810 --> 00:35:43,490
people claim, if you only patch the
clients, or if you only patch the access

408
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

409
00:35:46,980 --> 00:35:51,420
client and the access point is vulnerable,
then we can still attack the access point.

410
00:35:51,420 --> 00:35:54,810
If the access point only contains these
normal patches, the normal patches to

411
00:35:54,810 --> 00:36:00,021
defend against attacks, then connected
clients are also still vulnerable. So, as

412
00:36:00,021 --> 00:36:05,660
I mentioned, connected clients are only
defended, if the access point contains

413
00:36:05,660 --> 00:36:11,530
really extra modifications on top of the
default patches. Now, another common

414
00:36:11,530 --> 00:36:17,081
misconception is, that some people might
say "But, yeah, it's a cool attack, but

415
00:36:17,081 --> 00:36:22,490
you have to be close to the network in
order to pull off these attacks."

416
00:36:22,490 --> 00:36:26,920
Unfortunately, that's not the case because
we can use special antenna. And this

417
00:36:26,920 --> 00:36:30,171
special antenna, they can be made
really cheap out of, e.g. just a

418
00:36:30,171 --> 00:36:36,040
tin can, and with this special antenna, we
can manipulate Wi-Fi traffic from up to,

419
00:36:36,040 --> 00:36:41,450
say, 2 miles. And there are even leaked
NSA documents, where the NSA is able to

420
00:36:41,450 --> 00:36:47,440
exploit a Wi-Fi network using other
attacks from up to 8 miles away. Now,

421
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

422
00:36:51,010 --> 00:36:54,620
have to be physically close to the
network. You can still be relatively far

423
00:36:54,620 --> 00:37:02,370
away. Another strange remark that I
sometimes hear, is that you need to be

424
00:37:02,370 --> 00:37:06,630
connected to the network in order to pull
off these attacks, which would basically

425
00:37:06,630 --> 00:37:10,440
mean, you need to know the password of the
network to carry out the attacks. But

426
00:37:10,440 --> 00:37:14,540
that's not the case. As I mentioned,
during the attacks, you only need to be

427
00:37:14,540 --> 00:37:19,740
close enough. You need to be able to
manipulate some encrypted packets. But you

428
00:37:19,740 --> 00:37:23,740
don't need to know anything about the
network. You simply need to know the

429
00:37:23,740 --> 00:37:27,210
network is there and there's a vulnerable
client and access point and then you can

430
00:37:27,210 --> 00:37:34,450
start attacking them. One remark that I
can understand, is that some people

431
00:37:34,450 --> 00:37:39,430
say that "Yeah, Ok, you can attack these
handshakes, and you can decrypt data that

432
00:37:39,430 --> 00:37:43,630
is sent right after these handshakes, but
generally right after you connect to an

433
00:37:43,630 --> 00:37:48,690
Wi-Fi network, you're not really sending
interesting data, because at that point

434
00:37:48,690 --> 00:37:53,520
your device is sending e.g. ARP
requests, or it's sending DHCP requests,

435
00:37:53,520 --> 00:37:59,770
or is just creating TCP connections. But
no useful information is transmitted at

436
00:37:59,770 --> 00:38:06,260
this time." Unfortunately, at least for a
defender, this is again not true. Because,

437
00:38:06,260 --> 00:38:10,090
what we can do as an attacker is, we can
first let the client connect <i>blackout</i> out

438
00:38:10,090 --> 00:38:14,041
manipulating any traffic. The client, the
victim, will then, e.g. start

439
00:38:14,041 --> 00:38:20,120
browsing the internet, start
opening TCP connections, and in the middle

440
00:38:20,120 --> 00:38:24,070
of that, while the victim is e.g.
surfing the internet, we can

441
00:38:24,070 --> 00:38:28,090
deauthenticate the client from the
network, and all operating system will

442
00:38:28,090 --> 00:38:32,020
then immediately execute a new 4-way
handshake. And once that 4-way

443
00:38:32,020 --> 00:38:37,500
handshake is then completed, it will 
send all the buffered TCP packets again

444
00:38:37,500 --> 00:38:41,280
to the access point and also in a reverse
direction. So, basically, what we as an

445
00:38:41,280 --> 00:38:45,170
attacker can do, we can wait until we
expect the victim to send interesting

446
00:38:45,170 --> 00:38:49,190
information. Then we deauthenticate the
victim. It will execute a new handshake.

447
00:38:49,190 --> 00:38:56,010
And then we can decrypt the data that will
be transmitted right after that handshake.

448
00:38:56,010 --> 00:38:59,520
Another thing that makes the attack
possibly hard, is that obtaining this

449
00:38:59,520 --> 00:39:03,500
channel based man-in-the-middle is
difficult. For example, you might be

450
00:39:03,500 --> 00:39:07,760
thinking that in order to force the
clients to connect to the rogue access

451
00:39:07,760 --> 00:39:13,150
point, you need a stronger signal strength
than a real access point. But again,

452
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

453
00:39:17,870 --> 00:39:23,350
special Wi-Fi packets and so-called
channel switch announcements, which

454
00:39:23,350 --> 00:39:28,680
command the client into switching to a
different Wi-Fi channel, and effectively

455
00:39:28,680 --> 00:39:32,400
<i>blackout</i> to a rogue access point. So we don't
need a high signal strength, we can simply

456
00:39:32,400 --> 00:39:36,520
command a victim into saying "Hey, switch
to this channel and connect to our access

457
00:39:36,520 --> 00:39:40,820
point." And these frames are not
authenticated, so we can just forge them

458
00:39:40,820 --> 00:39:47,780
as an attacker. Another thing you might
say, that the complexity of the attack is

459
00:39:47,780 --> 00:39:52,871
hard, meaning it requires some expertise
to implement this. And this is true. You

460
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

461
00:39:59,110 --> 00:40:03,480
as usual you only need to write this
attack once, and then people can use your

462
00:40:03,480 --> 00:40:07,880
script in order to attack others. And this
is similar to, e.g., memory

463
00:40:07,880 --> 00:40:13,350
corruption attacks, such as buffer
overflows or stack overflows. Writing the

464
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

465
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

466
00:40:22,000 --> 00:40:29,270
the script, and you can start attacking
people. One other misconception that I

467
00:40:29,270 --> 00:40:35,630
sometimes encounter, is that people say "If
you use AES-CCMP, this mitigates the

468
00:40:35,630 --> 00:40:41,840
attack." Again, unfortunately, this is not
true, because the only advantage of using

469
00:40:41,840 --> 00:40:47,260
AES-CCMP is that
the attacker can no longer forge frames.

470
00:40:47,260 --> 00:40:52,680
The attacker is still able to decrypt and
replay frames. And finally, the last

471
00:40:52,680 --> 00:40:57,800
misconception is, that some people say that
enterprise networks aren't vulnerable,

472
00:40:57,800 --> 00:41:02,830
because they e.g. don't execute
the 4-way handshake. But again,

473
00:41:02,830 --> 00:41:07,450
unfortunately, that's wrong, because even
these networks use the 4-way handshake

474
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

475
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

476
00:41:19,880 --> 00:41:25,530
carried away, though. We can patch these
vulnerabilities in a backwards compatible

477
00:41:25,530 --> 00:41:30,190
way. And as I illustrated here in my talk,
the impact also really depends on the

478
00:41:30,190 --> 00:41:34,530
devices that you are using and your own
network setup. So, sometimes the impact is

479
00:41:34,530 --> 00:41:38,150
actually really low, but of course
sometimes the impact can be very high,

480
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,

481
00:41:43,250 --> 00:41:49,660
essentially. Now, for the last part of the
talk, I'm going to discuss some lessons

482
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

483
00:41:56,150 --> 00:42:01,320
important and interesting observations -
it's also the reason why I really like

484
00:42:01,320 --> 00:42:06,500
this attack myself - is that the 4-way
handshake was proven to be secure. The

485
00:42:06,500 --> 00:42:11,270
encryption protocol, and in particular
AES, has also been proven as secure.

486
00:42:11,270 --> 00:42:18,560
However, if we combine these two things,
then suddenly we lose all security. And

487
00:42:18,560 --> 00:42:27,400
this is quite unfortunate. And what this
teaches us, is that even though individual

488
00:42:27,400 --> 00:42:33,080
parts of a system were really investigated
and perhaps formally analyzed, we also

489
00:42:33,080 --> 00:42:37,560
need to analyze the combination of these
different entities and models, and we also

490
00:42:37,560 --> 00:42:43,540
need to prove that these combinations are
secure as well. And another way to look at

491
00:42:43,540 --> 00:42:50,830
this, is that in the proof of the 4-way
handshake, the authors, they modeled the

492
00:42:50,830 --> 00:42:56,780
handshake in a rather abstract way. And
their proofs, specifically, they did not

493
00:42:56,780 --> 00:43:00,780
model retransmissions of handshake
messages. And that's one of the things we

494
00:43:00,780 --> 00:43:06,310
abuse. So, on one hand we need to assure
that we also look

495
00:43:06,310 --> 00:43:11,140
at the combinations of these different
entities, but we also need to assure that

496
00:43:11,140 --> 00:43:17,080
the abstract models that we use reflect
reality. Another thing that we can learn,

497
00:43:17,080 --> 00:43:21,690
is that we should keep the protocols and
also the implementations simple.

498
00:43:21,690 --> 00:43:28,490
E.g., if we look at wpa_supplicant 2.6,
when we were studying this version

499
00:43:28,490 --> 00:43:34,600
ourself, we thought it wasn't vulnerable
to key reinstallation attacks. However,

500
00:43:34,600 --> 00:43:40,550
when we were notifying companies of the
vulnerabilities, another researcher found

501
00:43:40,550 --> 00:43:46,800
an attack against this version which did
work. The reason we missed this attack

502
00:43:46,800 --> 00:43:52,780
against version 2.6, is because
wpa_supplicant uses a fairly complex

503
00:43:52,780 --> 00:43:57,600
implementation of the 4-way handshake
and the state machine is fairly complex to

504
00:43:57,600 --> 00:44:02,690
reason about. And there are two ways to
combat this. The first is to keep the

505
00:44:02,690 --> 00:44:07,210
protocol simple. The second way to combat
this, is to formally verify

506
00:44:07,210 --> 00:44:12,630
implementations. Now of course, we cannot
formally verify all the code, but what we

507
00:44:12,630 --> 00:44:17,410
can do is, really, these cryptographic
protocols which play a very important

508
00:44:17,410 --> 00:44:23,950
role, at least we should pay enough
attention to that. What's also

509
00:44:23,950 --> 00:44:29,330
interesting, is that I encountered a
document of the CIA which also agrees, that

510
00:44:29,330 --> 00:44:34,220
complex implementations or protocols are
bad. Specifically, they have a document,

511
00:44:34,220 --> 00:44:39,770
where the CIA advises people how to
properly implement backdoors, essentially,

512
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

513
00:44:44,760 --> 00:44:48,970
encryption, but in that encryption
algorithm, don't enable re-key

514
00:44:48,970 --> 00:44:53,451
functionality, because that enables
additional features of the encryption

515
00:44:53,451 --> 00:44:58,860
algorithm. And these additional features,
they cause unnecessary complexity and that

516
00:44:58,860 --> 00:45:05,031
generally leads to bugs." Another thing
that we can learn, is that the standard

517
00:45:05,031 --> 00:45:10,560
needs to be specified rigorously and as
precisely as possible. Because the

518
00:45:10,560 --> 00:45:17,500
original WPA2 standard, it was a bit fake.
It didn't really define a state machine.

519
00:45:17,500 --> 00:45:23,720
Well, the state machine that it defined
says, what an implementation - sorry -

520
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

521
00:45:30,360 --> 00:45:35,270
doesn't define what an implementation
should do when it receives an unexpected

522
00:45:35,270 --> 00:45:41,550
message. So, it doesn't define the order,
in which messages should be accepted. Now,

523
00:45:41,550 --> 00:45:46,760
there is an amendment of the Wi-Fi
standard which better defines how and when

524
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

525
00:45:52,820 --> 00:45:58,430
that because the original WPA2 standard
was a bit fake, I can forgive iOS and

526
00:45:58,430 --> 00:46:02,250
Windows for deviating a bit from the
standard. Because the standard was

527
00:46:02,250 --> 00:46:08,750
difficult to interpret correctly. Now, on
a bit of a related note, I want to briefly

528
00:46:08,750 --> 00:46:13,760
mention a workshop that we are organizing,
which is exactly about how to implement

529
00:46:13,760 --> 00:46:18,951
these security protocols properly, how to
e.g. fuzz security protocols, how

530
00:46:18,951 --> 00:46:23,620
to prove that they are correct, how to
make sure that we specify them rigorously.

531
00:46:23,620 --> 00:46:30,070
So, if you are working in this field, do
consider submitting to this. Now, the last

532
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

533
00:46:35,500 --> 00:46:42,520
can coordinate the disclosure of a
vulnerability like this. Because this is

534
00:46:42,520 --> 00:46:45,730
not an ordinary vulnerability,
that is, just affects one

535
00:46:45,730 --> 00:46:52,450
vendor, it really affects possibly every
Wi-Fi device that is around. So, how on

536
00:46:52,450 --> 00:46:56,880
earth are you going to start notifying
companies? Who are you going to notify?

537
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

538
00:47:02,360 --> 00:47:07,750
strategy that we used, and what we used
first is... we first wanted to determine,

539
00:47:07,750 --> 00:47:12,470
you know, is this really a widespread
issue? We wanted to be sure of that before

540
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

541
00:47:18,620 --> 00:47:25,040
first contacted a few selected vendors and
we told them that "Hey, we possibly found

542
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

543
00:47:30,630 --> 00:47:36,210
should check this out." And quite quickly
we got a few responses from vendors, saying

544
00:47:36,210 --> 00:47:41,960
that "Yes, we looked at your attack and
indeed, some of our devices are

545
00:47:41,960 --> 00:47:45,270
vulnerable," and this really confirmed to
us, that a device

546
00:47:45,270 --> 00:47:49,500
that we didn't test ourself was
vulnerable to the attack that we found.

547
00:47:49,500 --> 00:47:52,870
So, it confirmed that the issue is
widespread, and we also got a bit of

548
00:47:52,870 --> 00:47:57,160
feedback on the report that we sent
towards them on the description of our

549
00:47:57,160 --> 00:48:02,550
attack. So, at this point we were
convinced ourselves, that this really was a

550
00:48:02,550 --> 00:48:07,870
flaw in the standard and that a lot of
companies will be affected. Then the next

551
00:48:07,870 --> 00:48:12,620
question we had is, "Okay, who are we now
all going to notify?" We of course

552
00:48:12,620 --> 00:48:16,240
notified the big names and the big
companies, but who else do we have to

553
00:48:16,240 --> 00:48:22,810
notify? And at this point, our tactic was
to rely on a CERT team, specifically a

554
00:48:22,810 --> 00:48:28,680
CERT from the US and they did all the
coordination for us.

555
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

556
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

557
00:48:38,690 --> 00:48:42,760
contacted already for other
vendors, that also might be affected

558
00:48:42,760 --> 00:48:48,790
by the bug that you found, e.g.
Now one thing that is more difficult here,

559
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

560
00:48:55,580 --> 00:49:01,260
you also can't notify everyone because if
you are going to notify everyone, then the

561
00:49:01,260 --> 00:49:10,450
chance of the details leaking, they become
close to one. Another difficult thing to

562
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,

563
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

564
00:49:23,110 --> 00:49:27,950
period to patch everything, but then again,
the risk of this details leasing... err,

565
00:49:27,950 --> 00:49:33,300
leaking increase. On the other hand, if the
embargo period is too short, people won't

566
00:49:33,300 --> 00:49:36,950
have time to patch it. So this is quite a
hard decision. In the end,

567
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

568
00:49:42,310 --> 00:49:47,490
pick a deadline, but still do pick a
deadline to avoid any uncertainty and so

569
00:49:47,490 --> 00:49:54,300
that people know, what to expect. And
finally, I want to thank CERT and ICASI

570
00:49:54,300 --> 00:49:59,960
for helping with the coordination and you
also want to thank Cisco for some of the

571
00:49:59,960 --> 00:50:05,700
advice that they give.
So, with that I can conclude the talk, so

572
00:50:05,700 --> 00:50:11,980
what we discussed, is a flaw and the WPA2
standard itself and the most surprising

573
00:50:11,980 --> 00:50:17,770
thing about this research is, that WPA2 was
proven to be correct, yet we still found

574
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

575
00:50:23,041 --> 00:50:27,880
theoretical attack, the attack has actual
impact and practice.

576
00:50:27,880 --> 00:50:32,740
And finally, in order to defend against
this, you should update all your clients

577
00:50:32,740 --> 00:50:38,220
and also check if your access points are
affected. So with that, thank you for your

578
00:50:38,220 --> 00:50:41,360
attention and if there are any questions,
feel free to ask.

579
00:50:41,360 --> 00:50:50,510
<i>applause</i>


580
00:50:50,510 --> 00:50:52,650
Herald: So, do we have any questions?

581
00:50:52,650 --> 00:50:57,760
There is mics everywhere, so please come
in front. And I think, we already have the

582
00:50:57,760 --> 00:51:01,770
first question directly here in front on
mic number 1.

583
00:51:01,770 --> 00:51:11,540
Mic1: You mentioned, that GCMP is most
vulnerable. Do you know if there's any

584
00:51:11,540 --> 00:51:18,300
standardization going on, about switching
to nonce misuse resistant scheme like

585
00:51:18,300 --> 00:51:28,100
AES-GCM, Synthetic Initialization Vector?
MV: Yes, so there have been

586
00:51:28,100 --> 00:51:33,710
some proposals in order to make the
encryption algorithm defend against nonce

587
00:51:33,710 --> 00:51:40,020
reuse. Now the impression I have, that this
is still a bit of ongoing research. So

588
00:51:40,020 --> 00:51:45,450
there are proposals, where you have an
algorithm that you can use, but I'm not

589
00:51:45,450 --> 00:51:50,640
aware of actual encryption protocols, e.g.
TLS or Wi-Fi, that are using them.

590
00:51:50,640 --> 00:51:54,790
But they exist, but I... they're not yet being
really used.

591
00:51:54,790 --> 00:52:02,920
Mic1: It is standardisation going on in
CFRG, so Crypto Forum Research Group in

592
00:52:02,920 --> 00:52:10,600
IETF standardization, but I was asking about
Wi-Fi standardization, if they are planning

593
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

594
00:52:20,230 --> 00:52:30,500
the deterministic initialization vector,
there's a random IV possible, if you use

595
00:52:30,500 --> 00:52:38,850
96 bit, then the impact wouldn't be
bounded.

596
00:52:38,850 --> 00:52:45,030
MV: So to answer the first question: I'm
not aware of the Wi-Fi standard

597
00:52:45,030 --> 00:52:51,730
from really modifying the standard to use
a nonce misuse resistant encryption

598
00:52:51,730 --> 00:52:57,340
cipher. They are modifying the standard to
defend against key reinstallation attacks,

599
00:52:57,340 --> 00:53:00,820
but I think they're not yet going to
incorporate a nonce misuse resistant

600
00:53:00,820 --> 00:53:05,430
encryption cipher, because they still have
the impression that they're going to wait

601
00:53:05,430 --> 00:53:11,760
probably a while and once that technology
is more mature they're going to use that.

602
00:53:11,760 --> 00:53:15,900
If I understood your second question, you
also have encryption algorithms, where you

603
00:53:15,900 --> 00:53:20,550
don't have deterministic nonce, but you
have a nonce, which for every encryption

604
00:53:20,550 --> 00:53:27,560
operation e.g. is random.
Mic1: Actually in the GCM standard there

605
00:53:27,560 --> 00:53:32,470
are two possibilities: one deterministic,
MV: Yeah.

606
00:53:32,470 --> 00:53:38,270
Mic1: and the second random.
MV: So the risk of using a random

607
00:53:38,270 --> 00:53:43,130
initialization vector is, that you may
have a bad random generator,

608
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

609
00:53:52,010 --> 00:53:56,680
randomly generated nonce it can
also go bad, but then there are different

610
00:53:56,680 --> 00:54:02,050
attacks. And I think, there has been a
paper that analyzes a certain TLS

611
00:54:02,050 --> 00:54:07,210
libraries, where they do find attacks, where
in that case the GCM algorithm can still

612
00:54:07,210 --> 00:54:11,930
be attacked, not through key reinstallation
attacks, but because there is, because

613
00:54:11,930 --> 00:54:15,780
basically the nonce isn't really random,
e.g. sometimes a bad implementation

614
00:54:15,780 --> 00:54:21,070
always uses the same random nonce.
Person X: Um, direct answer...

615
00:54:21,070 --> 00:54:22,610
Herald: Err, sorry,...
X: Direct answer to his question number

616
00:54:22,610 --> 00:54:30,590
one: because he asked, whether there's
right now an approach to modify the

617
00:54:30,590 --> 00:54:38,340
standard towards being resistant against
this attack, right now there is no IEEE

618
00:54:38,340 --> 00:54:46,170
task group working on an amendment which
will fix this.

619
00:54:46,170 --> 00:54:50,910
MV: Well, there is... they are working to 
prevent the key reinstallation attack.

620
00:54:50,910 --> 00:54:54,320
X: Well, there is no official
active task group right now.

621
00:54:54,320 --> 00:54:57,030
MV: Okay that could be, but there are still
people working on that.

622
00:54:57,030 --> 00:54:58,980
X: Yeah, they're working on that,
but no

623
00:54:58,980 --> 00:55:00,600
task group, right?
MV: Ok. Thank you.

624
00:55:00,600 --> 00:55:03,400
Herald: Okay thank you.
Here in number 3.

625
00:55:03,400 --> 00:55:07,510
Mic3: Yes, thanks for your
amazing talk.

626
00:55:07,510 --> 00:55:11,320
Just for my personal understanding:
could you briefly go back to

627
00:55:11,320 --> 00:55:17,370
the slide with the 4-way
handshake, like, right in the beginning?

628
00:55:17,370 --> 00:55:21,010
MV: Yup, so the attack or the handshake
itself?

629
00:55:21,010 --> 00:55:28,770
Mic3: Yeah, yeah the attack.
MV: So let's go to this slide.

630
00:55:28,770 --> 00:55:37,270
Mic3: Yeah so all you get from this, is the
keystream that is used to encrypt

631
00:55:37,270 --> 00:55:41,880
the the Msg4, right,
that's all you get?

632
00:55:41,880 --> 00:55:45,550
MV: Yes, but you can already use that to
start decrypting frames and what you can

633
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

634
00:55:51,480 --> 00:55:54,960
triggering new handshakes by
deauthenticating the client, so you can

635
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

636
00:56:02,940 --> 00:56:09,090
sending this retransmitted Msg3
to the clients, because sometimes you know

637
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

638
00:56:12,090 --> 00:56:16,650
know that the HTTP requests. You can capture
quite some packets where you know the

639
00:56:16,650 --> 00:56:22,370
content, to derive some known key stream
and once you have that, you can forward

640
00:56:22,370 --> 00:56:27,780
Msg3 to trigger a key
reinstallation and then you have collected

641
00:56:27,780 --> 00:56:33,830
quite some key stream to be able to
decrypt several packets at a time. So you

642
00:56:33,830 --> 00:56:38,910
can use tactics like that, you can rely on
the packet length to basically determine,

643
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

644
00:56:43,770 --> 00:56:47,780
derive new key stream and there are a lot
of ways to play around with that.

645
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

646
00:56:51,680 --> 00:56:59,630
already being used immediately, because
it's being used to encrypt Msg4.

647
00:56:59,630 --> 00:57:02,940
MV: Well, we know the content of Msg4

648
00:57:02,940 --> 00:57:08,550
and we abuse, that Msg4 is
encrypted to derive known key stream and

649
00:57:08,550 --> 00:57:14,130
we can then use that to encrypt data
frames, which we do not know and... we

650
00:57:14,130 --> 00:57:15,740
should discuss this offline.
Mic3: Yeah.

651
00:57:15,740 --> 00:57:19,850
Herald: Perhaps this is for later
discussion with more in detail. Now we

652
00:57:19,850 --> 00:57:24,750
switch to number two... number four, I
think it is. Yeah, thanks.

653
00:57:24,750 --> 00:57:30,940
Mic4: Yes. Great find really and an
awesome talk. Could you maybe elaborate a

654
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

655
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

656
00:57:44,330 --> 00:57:48,990
can you still benefit from formal
verification?

657
00:57:48,990 --> 00:57:55,540
MV: Well, I think the attitude we should
adopt is, that formal verification of code

658
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

659
00:58:01,670 --> 00:58:07,450
protocol, but it's not just because it's
formally verified that it's secure.

660
00:58:07,450 --> 00:58:12,270
Perhaps one of the attitudes that people
had was: 'oh it's firmly verified, it must

661
00:58:12,270 --> 00:58:17,840
be fine'. We should abandon that attitude
and instead we should say: "Ok, it's

662
00:58:17,840 --> 00:58:21,750
formally verified but, you know, let's
check if the model they used reflects

663
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

664
00:58:28,480 --> 00:58:33,470
formal verification but we should just
treat it as additional evidence, that

665
00:58:33,470 --> 00:58:41,540
something looks secure.
Herald: Ok, there's another question on mic 2

666
00:58:41,540 --> 00:58:47,250
Mic2: The first part is on the slide
you're currently on. As far as I

667
00:58:47,250 --> 00:58:52,880
understood it in the talk, the
retransmission of Msg4 is not

668
00:58:52,880 --> 00:58:56,860
supposed to be encrypted by the standard.
MV: Correct.

669
00:58:56,860 --> 00:59:02,240
Mic2: So if you follow the standards, you
shouldn't have a problem here.

670
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

671
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

672
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

673
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

674
00:59:22,101 --> 00:59:28,770
has been work to fingerprint the length of
HTTP requests, to be able to determine

675
00:59:28,770 --> 00:59:32,440
which page you are visiting, so purely
based on the length, we can determine the

676
00:59:32,440 --> 00:59:37,260
contents of the website you are looking
for. We can then derive known plaintext

677
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

678
00:59:44,020 --> 00:59:51,750
derive known keystream and to then trigger
a key reinstallation attack to then abuse this.

679
00:59:51,750 --> 00:59:55,190
Herald: Ok we have time for one last
question. Mic number 1?

680
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

681
01:00:04,730 --> 01:00:11,240
deployed in the network, we are still
vulnerable to the attack, because as 11W

682
01:00:11,240 --> 01:00:19,590
specifies the encryption, I'm supposed by
this amendment, is also done by the

683
01:00:19,590 --> 01:00:28,020
encryption use on the network like before,
so 11W is not really a way to secure

684
01:00:28,020 --> 01:00:33,690
the network?
MV: Well, if I got it right, 11W is, one of

685
01:00:33,690 --> 01:00:36,380
the things it does, is protect the
management's frames, if I'm correct?

686
01:00:36,380 --> 01:00:39,122
Mic1: Yes.
MV: Yes.

687
01:00:39,122 --> 01:00:44,620
MV: So using that does not defend against
these attacks.

688
01:00:44,620 --> 01:00:50,710
Herald: Ok, I think there's still quite
details, where people are curious about,

689
01:00:50,710 --> 01:00:55,160
because it's everybody starting this
question "as far as I understood". So I think,

690
01:00:55,160 --> 01:00:58,840
this was a really nice comprehensive talk
and I want to thank you. And everybody who

691
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

692
01:01:03,660 --> 01:01:06,990
the paper, perhaps read everything in
detail there.

693
01:01:06,990 --> 01:01:11,540
So, please another big round of applause
for Mathy and his amazing talk!

694
01:01:11,540 --> 01:01:13,276
Thank you very much.
MV: Thank you!

695
01:01:13,276 --> 01:01:20,510
<i>applause</i>

696
01:01:20,510 --> 01:01:26,095
<i>34c3 outro</i>

697
01:01:26,095 --> 01:01:41,861
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!