[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:16.62,Default,,0000,0000,0000,,{\i1}34c3 intro{\i0}
Dialogue: 0,0:00:16.62,0:00:23.72,Default,,0000,0000,0000,,Herald: I'm really happy to be able to\Nintroduce our next speaker. Mathy is a
Dialogue: 0,0:00:23.72,0:00:30.18,Default,,0000,0000,0000,,postdoc in Network Security and Applied\NCrypto. He took part in discovering and
Dialogue: 0,0:00:30.18,0:00:35.86,Default,,0000,0000,0000,,implementing quite some attacks in this\Nfield and especially in the wireless
Dialogue: 0,0:00:35.86,0:00:43.49,Default,,0000,0000,0000,,sector. And today he will show us, that all\Nour Wi-Fi devices are vulnerable.
Dialogue: 0,0:00:43.49,0:00:49.12,Default,,0000,0000,0000,,Especially the ones with Linux and\NAndroid. So, I don't want to go into the
Dialogue: 0,0:00:49.12,0:00:53.14,Default,,0000,0000,0000,,technical details, because he would do\Nthis and I think if you're interested in
Dialogue: 0,0:00:53.14,0:00:57.96,Default,,0000,0000,0000,,even learning more about it, he even linked\Nthe research paper as well as the scripts
Dialogue: 0,0:00:57.96,0:01:04.19,Default,,0000,0000,0000,,and a website for this attack in the\NFahrplan. So for now, give a big round of
Dialogue: 0,0:01:04.19,0:01:06.70,Default,,0000,0000,0000,,applause for Mathy Vanhoef!
Dialogue: 0,0:01:06.70,0:01:11.51,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:01:11.51,0:01:15.96,Default,,0000,0000,0000,,Mathy Vanhoef: Ok, thank you for the\Nintroduction and thank you all for
Dialogue: 0,0:01:15.96,0:01:19.92,Default,,0000,0000,0000,,attending the talk, even though it's\Nalready a bit late in the evening. Thank
Dialogue: 0,0:01:19.92,0:01:25.48,Default,,0000,0000,0000,,you CCC for allowing me to speak here. So\Ntoday I'm going to talk about my research
Dialogue: 0,0:01:25.48,0:01:30.75,Default,,0000,0000,0000,,on WPA2 and you probably have already\Nheard about this under the name of KRACK
Dialogue: 0,0:01:30.75,0:01:37.77,Default,,0000,0000,0000,,attacks. Now, the history of this research\Nis quite interesting, because during my PhD,
Dialogue: 0,0:01:37.77,0:01:44.49,Default,,0000,0000,0000,,I was already researching the security of\Nwireless networks and during my PhD
Dialogue: 0,0:01:44.49,0:01:50.84,Default,,0000,0000,0000,,defense last year, when I was finishing up\Non writing my thesis, one of the jury
Dialogue: 0,0:01:50.84,0:01:57.23,Default,,0000,0000,0000,,members in my PhD asked: "Hey, you're\Nrecommending WPA2 with AES in your thesis,
Dialogue: 0,0:01:57.23,0:02:03.39,Default,,0000,0000,0000,,but are you sure that's really a secure\Nsolution?" And last year my answer was:
Dialogue: 0,0:02:03.39,0:02:08.23,Default,,0000,0000,0000,,"Yeah, I mean it seems secure. It has been\Naround for more than a decade and if we
Dialogue: 0,0:02:08.23,0:02:11.92,Default,,0000,0000,0000,,ignore some brute-force attacks against\Nthe password, if you select a secure
Dialogue: 0,0:02:11.92,0:02:16.91,Default,,0000,0000,0000,,password, then there are no real weaknesses\Nthat are known. On top of that, there are
Dialogue: 0,0:02:16.91,0:02:21.19,Default,,0000,0000,0000,,also mathematical proofs that state that\Nif you have the 4-way handshake on the
Dialogue: 0,0:02:21.19,0:02:27.49,Default,,0000,0000,0000,,encryption algorithm, that it's supposed to\Nbe secure. Unfortunately, a year later I
Dialogue: 0,0:02:27.49,0:02:32.80,Default,,0000,0000,0000,,was staring at some OpenBSD code. In\Nparticular, I was looking at this function
Dialogue: 0,0:02:32.80,0:02:39.44,Default,,0000,0000,0000,,called ic_set_key. The details aren't\Nimportant here yet, but this key installs
Dialogue: 0,0:02:39.44,0:02:44.47,Default,,0000,0000,0000,,the encryption key for use by the driver,\Nso frames get encrypted and I was
Dialogue: 0,0:02:44.47,0:02:48.24,Default,,0000,0000,0000,,wondering, what\Nwould happen if this function is called
Dialogue: 0,0:02:48.24,0:02:53.46,Default,,0000,0000,0000,,twice. And I was thinking, like, will it\Nreinstall the key and what will happen
Dialogue: 0,0:02:53.46,0:02:58.38,Default,,0000,0000,0000,,when you reinstall the key? And it turns\Nout that answering this question led to
Dialogue: 0,0:02:58.38,0:03:06.54,Default,,0000,0000,0000,,the attack I found and as you know by now,\Nthis uncovered the flaw in WPA2. So in a
Dialogue: 0,0:03:06.54,0:03:13.59,Default,,0000,0000,0000,,sense, this talk is all about how I gave\Nthe wrong answer during my PhD defense. To
Dialogue: 0,0:03:13.59,0:03:19.59,Default,,0000,0000,0000,,explain the attack, I will illustrate it\Nagainst the 4-way handshake. After that I
Dialogue: 0,0:03:19.59,0:03:24.47,Default,,0000,0000,0000,,will discuss the impact of the attack in\Npractice, then I will go over some
Dialogue: 0,0:03:24.47,0:03:28.72,Default,,0000,0000,0000,,common misconceptions that have been\Nfloating around the internet and finally I
Dialogue: 0,0:03:28.72,0:03:31.94,Default,,0000,0000,0000,,will discuss some lessons that we can\Nlearn from this
Dialogue: 0,0:03:31.94,0:03:37.82,Default,,0000,0000,0000,,research and from our findings. Let's get\Nstarted with explaining the attack against
Dialogue: 0,0:03:37.82,0:03:42.29,Default,,0000,0000,0000,,the 4-way handshake and the first\Nquestion I have to answer here is: what
Dialogue: 0,0:03:42.29,0:03:48.74,Default,,0000,0000,0000,,exactly is this 4-way handshake? And the\N4-way handshake is executed whenever
Dialogue: 0,0:03:48.74,0:03:53.35,Default,,0000,0000,0000,,you connect to a protected Wi-Fi network.\NIt's used when you connect to your home
Dialogue: 0,0:03:53.35,0:03:57.29,Default,,0000,0000,0000,,Wi-Fi network where you just have a pre-\Nshared password, but it's also used in
Dialogue: 0,0:03:57.29,0:04:02.49,Default,,0000,0000,0000,,enterprise network-networks where you for\Nexample have a username and a password to
Dialogue: 0,0:04:02.49,0:04:06.24,Default,,0000,0000,0000,,log in.\NThe purpose of this handshake is to verify
Dialogue: 0,0:04:06.24,0:04:10.80,Default,,0000,0000,0000,,that you possess the correct credentials\Nin order to connect to the network and at
Dialogue: 0,0:04:10.80,0:04:15.25,Default,,0000,0000,0000,,the same time, this 4-way handshake\Nnegotiates a fresh session key that will
Dialogue: 0,0:04:15.25,0:04:19.98,Default,,0000,0000,0000,,be used to encrypt data frames.\NThis session key is called the PTK, the
Dialogue: 0,0:04:19.98,0:04:27.61,Default,,0000,0000,0000,,pairwise temporal key. And as I mentioned,\Nthis handshake seemed to be really secure
Dialogue: 0,0:04:27.61,0:04:33.77,Default,,0000,0000,0000,,because for over a decade, no attacks have\Nbeen found against it, assuming that a
Dialogue: 0,0:04:33.77,0:04:40.02,Default,,0000,0000,0000,,secure password is being used, and on top\Nof that, the 4-way handshake was
Dialogue: 0,0:04:40.02,0:04:43.73,Default,,0000,0000,0000,,formally proven to be secure and the\Nencryption algorithm that is used after
Dialogue: 0,0:04:43.73,0:04:48.66,Default,,0000,0000,0000,,the 4-way handshake, which generally\Nis AES CCMP, that was also formally
Dialogue: 0,0:04:48.66,0:04:53.55,Default,,0000,0000,0000,,proven to be secure.\NYet somehow we did find an attack even
Dialogue: 0,0:04:53.55,0:04:57.20,Default,,0000,0000,0000,,though we have all these formal proofs,\Neven though this protocol has been around
Dialogue: 0,0:04:57.20,0:05:01.23,Default,,0000,0000,0000,,for that long. So what went\Nwrong?
Dialogue: 0,0:05:01.23,0:05:08.05,Default,,0000,0000,0000,,To explain this, I'm going to explain how\Nthe 4-way handshake works, using this
Dialogue: 0,0:05:08.05,0:05:12.55,Default,,0000,0000,0000,,specific example. So let's say, we have the\Nclient on the right here that wants to
Dialogue: 0,0:05:12.55,0:05:17.71,Default,,0000,0000,0000,,connect to the access point on the left.\NNow, in order to start the 4-way
Dialogue: 0,0:05:17.71,0:05:22.02,Default,,0000,0000,0000,,handshake, there first needs to be some\Npreshared secrets between the client on
Dialogue: 0,0:05:22.02,0:05:26.75,Default,,0000,0000,0000,,the access point and if you have a network\Nat home, this preshared secret is basically
Dialogue: 0,0:05:26.75,0:05:30.75,Default,,0000,0000,0000,,the password of the network. But if you\Nhave an enterprise or a more professional
Dialogue: 0,0:05:30.75,0:05:35.65,Default,,0000,0000,0000,,network, then - where you for example have\Nto log in using a username and a password -
Dialogue: 0,0:05:35.65,0:05:41.79,Default,,0000,0000,0000,,then first 802.1x authentication algorithm\Nis executed, which in practice is commonly
Dialogue: 0,0:05:41.79,0:05:47.08,Default,,0000,0000,0000,,some form of RADIUS authentication.\NThe details of that are not important.
Dialogue: 0,0:05:47.08,0:05:51.18,Default,,0000,0000,0000,,What's important here is the result.\NNamely, after this authentication phase
Dialogue: 0,0:05:51.18,0:05:55.51,Default,,0000,0000,0000,,there is a shared secret between the\Nclient and the access point.
Dialogue: 0,0:05:55.51,0:06:01.46,Default,,0000,0000,0000,,And once we have this shared secret, we\Ncan execute the 4-way handshake. What
Dialogue: 0,0:06:01.46,0:06:06.88,Default,,0000,0000,0000,,the first two messages in the 4-way\Nhandshake do, is they transport a random
Dialogue: 0,0:06:06.88,0:06:11.10,Default,,0000,0000,0000,,number between both devices.\NSo in particular, the access point will
Dialogue: 0,0:06:11.10,0:06:15.57,Default,,0000,0000,0000,,generate a random number called the access\Npoint nonce, the ANonce, and it will
Dialogue: 0,0:06:15.57,0:06:20.38,Default,,0000,0000,0000,,transport that to the client.\NThen in reaction to that, the client will
Dialogue: 0,0:06:20.38,0:06:24.15,Default,,0000,0000,0000,,generate its own random number called the\Nsupplicant nonce - and supplicant is
Dialogue: 0,0:06:24.15,0:06:29.12,Default,,0000,0000,0000,,basically a synonym for client - and it\Nwill send that random number, the SNonce,
Dialogue: 0,0:06:29.12,0:06:36.55,Default,,0000,0000,0000,,to the access point in the second message\Nof the handshake. Once both devices have
Dialogue: 0,0:06:36.55,0:06:41.69,Default,,0000,0000,0000,,each other's random number, then we can\Nderive this unique per session key.
Dialogue: 0,0:06:41.69,0:06:46.86,Default,,0000,0000,0000,,How that key is derived, is fairly simple: we\Ntake the preshared key, that is known
Dialogue: 0,0:06:46.86,0:06:51.67,Default,,0000,0000,0000,,between these two devices, we combine that\Nwith both of these random numbers and the
Dialogue: 0,0:06:51.67,0:06:56.85,Default,,0000,0000,0000,,result is the PTK, this fresh encryption\Nkey, that will later be used to encrypt
Dialogue: 0,0:06:56.85,0:07:02.93,Default,,0000,0000,0000,,data frames.\NNow, I want to clarify one thing, and you
Dialogue: 0,0:07:02.93,0:07:07.85,Default,,0000,0000,0000,,might have heard about this research under\Nthe name 'key reinstallation attacks:
Dialogue: 0,0:07:07.85,0:07:13.61,Default,,0000,0000,0000,,forcing nonce reuse in WPA2'.\NI want to highlight here that the nonce
Dialogue: 0,0:07:13.61,0:07:17.99,Default,,0000,0000,0000,,reuse does not refer to the nonce reuse\Nabout the ANonce or SNonce during the
Dialogue: 0,0:07:17.99,0:07:22.48,Default,,0000,0000,0000,,4-way handshake. So here we're going [to]\Nassume, that these ANonce and SNonce, that
Dialogue: 0,0:07:22.48,0:07:27.25,Default,,0000,0000,0000,,they are random and not predictable. The\Nnonce reuse refers to nonce reuse that
Dialogue: 0,0:07:27.25,0:07:34.00,Default,,0000,0000,0000,,will happen during the encryption\Nalgorithm, which I will explain in a bit.
Dialogue: 0,0:07:34.00,0:07:40.25,Default,,0000,0000,0000,,That's it for the first stage of the 4-way\Nhandshake. The second stage of the 4-way
Dialogue: 0,0:07:40.25,0:07:47.43,Default,,0000,0000,0000,,handshake, a bit simplified, it basically\Nconfirms that both parties negotiate at
Dialogue: 0,0:07:47.43,0:07:51.100,Default,,0000,0000,0000,,the same PTK, the same encryption key. And\Nin particular, the access point will send
Dialogue: 0,0:07:51.100,0:07:56.91,Default,,0000,0000,0000,,Message 3 to the client. The client will\Nverify the authenticity of that frame and
Dialogue: 0,0:07:56.91,0:08:04.31,Default,,0000,0000,0000,,if everything looks ok, the client will\Nreply using Msg4 to the access point.
Dialogue: 0,0:08:04.31,0:08:08.74,Default,,0000,0000,0000,,Once these four messages have been\Nexchanged, both the client on the access
Dialogue: 0,0:08:08.74,0:08:15.57,Default,,0000,0000,0000,,point will install the PTK for use by the\Ndriver, so now data frames can be exchanged
Dialogue: 0,0:08:15.57,0:08:22.14,Default,,0000,0000,0000,,and these data frames will be encrypted.\NOk, so now we covered the 4-way
Dialogue: 0,0:08:22.14,0:08:29.01,Default,,0000,0000,0000,,handshake, we know the highlight of how it\Nworks. Now the final thing I need to
Dialogue: 0,0:08:29.01,0:08:34.64,Default,,0000,0000,0000,,explain, before we can get to the details\Nof the attack, is: How does encryption work
Dialogue: 0,0:08:34.64,0:08:40.06,Default,,0000,0000,0000,,in a Wi-Fi network? And to explain this,\Nlet's take the example here, where we want
Dialogue: 0,0:08:40.06,0:08:44.51,Default,,0000,0000,0000,,to send some plain text data from, e.g.,\Nfrom the client to the access
Dialogue: 0,0:08:44.51,0:08:49.40,Default,,0000,0000,0000,,point. Then the first thing that will\Nhappen, is that we will take the PTK and
Dialogue: 0,0:08:49.40,0:08:53.31,Default,,0000,0000,0000,,the fresh session key, that the 4-way\Nhandshake just negotiated and we will
Dialogue: 0,0:08:53.31,0:08:59.94,Default,,0000,0000,0000,,combine that with a packet number. And here,\Nthis packet number is called a nonce.
Dialogue: 0,0:08:59.94,0:09:04.75,Default,,0000,0000,0000,,The packet number is incremented by 1 for\Nevery frame, that is transmitted and the ID
Dialogue: 0,0:09:04.75,0:09:09.58,Default,,0000,0000,0000,,here is, that by combining the session key\Nwith the packet number we get a unique per
Dialogue: 0,0:09:09.58,0:09:15.93,Default,,0000,0000,0000,,packet key for every packet that we want\Nto transmit.
Dialogue: 0,0:09:15.93,0:09:20.33,Default,,0000,0000,0000,,The way the encryption now works is fairly\Nsimple, we feed this per packet key as
Dialogue: 0,0:09:20.33,0:09:25.91,Default,,0000,0000,0000,,input to a stream cipher. We get us output\Nsome key stream, we simply XOR that key
Dialogue: 0,0:09:25.91,0:09:31.61,Default,,0000,0000,0000,,stream with the plaintext and the result\Nis the encrypted data, the ciphertext.
Dialogue: 0,0:09:31.61,0:09:36.62,Default,,0000,0000,0000,,Now we prepense a plaintext header with\Nsome metadata and also the packet number,
Dialogue: 0,0:09:36.62,0:09:40.48,Default,,0000,0000,0000,,the nonce value, that we used, so the\Nreceiver will be able to decrypt the
Dialogue: 0,0:09:40.48,0:09:46.12,Default,,0000,0000,0000,,packet. Essentially, this is just a stream\Ncipher, where a nonce is used to always
Dialogue: 0,0:09:46.12,0:09:52.90,Default,,0000,0000,0000,,derive a unique per packet key. Now there's\None essential requirements in this
Dialogue: 0,0:09:52.90,0:09:58.00,Default,,0000,0000,0000,,encryption key.\NThat is, that under a particular session
Dialogue: 0,0:09:58.00,0:10:04.30,Default,,0000,0000,0000,,key, a nonce value should only be used once,\Nbecause if you ever reuse a nonce value,
Dialogue: 0,0:10:04.30,0:10:08.30,Default,,0000,0000,0000,,you will generate the same per packet key.\NYou will generate the same key stream and
Dialogue: 0,0:10:08.30,0:10:12.08,Default,,0000,0000,0000,,this will allow you to decrypt packets,\Nthat are sent and depending on the
Dialogue: 0,0:10:12.08,0:10:19.36,Default,,0000,0000,0000,,specific stream cipher that is being used,\Nit will also allow you to forge frames.
Dialogue: 0,0:10:19.36,0:10:20.55,Default,,0000,0000,0000,,{\i1}clears his throat{\i0}
Dialogue: 0,0:10:20.55,0:10:28.04,Default,,0000,0000,0000,,Now the question here is: Is this nonce\Nvalue indeed only used once? And we already
Dialogue: 0,0:10:28.04,0:10:32.35,Default,,0000,0000,0000,,know, that it is incremented by one for\Nevery packet that is transmitted, so the
Dialogue: 0,0:10:32.35,0:10:37.07,Default,,0000,0000,0000,,only question that remains is: To what\Nvalue is this packet number initialized?
Dialogue: 0,0:10:37.07,0:10:44.05,Default,,0000,0000,0000,,And the answer is quite simple: when the\NPTK is installed, this transmit nonce is
Dialogue: 0,0:10:44.05,0:10:49.28,Default,,0000,0000,0000,,initialized to 0.\NAt first sight, this makes a lot of sense.
Dialogue: 0,0:10:49.28,0:10:53.55,Default,,0000,0000,0000,,I mean, you initiate that number to 0,\Nyou increment it by one for every packet,
Dialogue: 0,0:10:53.55,0:11:00.70,Default,,0000,0000,0000,,so surely this nonce is a specific nonce\Nvalue, is only used once.
Dialogue: 0,0:11:00.70,0:11:06.96,Default,,0000,0000,0000,,Unfortunately, this is not the case. And the\Nreason this nonce value or a particular
Dialogue: 0,0:11:06.96,0:11:11.93,Default,,0000,0000,0000,,nonce value is sometimes used more than\Nonce, is because we can force
Dialogue: 0,0:11:11.93,0:11:17.54,Default,,0000,0000,0000,,reinstallations of the PTK and those\Nreinstallations will again reset the nonce
Dialogue: 0,0:11:17.54,0:11:23.98,Default,,0000,0000,0000,,to 0 and then nonce value will be reused.\NSo, how can we force these key
Dialogue: 0,0:11:23.98,0:11:29.34,Default,,0000,0000,0000,,reinstallations as an attacker?\NLet's again take the example where we have
Dialogue: 0,0:11:29.34,0:11:34.66,Default,,0000,0000,0000,,a client on the left, that wants to connect\Nto the access point on the right and in
Dialogue: 0,0:11:34.66,0:11:38.97,Default,,0000,0000,0000,,this case, we also have an attacker that\Nsits in the middle and this attacker will
Dialogue: 0,0:11:38.97,0:11:45.41,Default,,0000,0000,0000,,assume a so-called channel-based man-in-\Nthe-middle position and in this-man-in-the-
Dialogue: 0,0:11:45.41,0:11:50.80,Default,,0000,0000,0000,,middle position, the adversary isn't yet\Nable to decrypt any packets. This man-in-
Dialogue: 0,0:11:50.80,0:11:56.02,Default,,0000,0000,0000,,the-middle position is purely there, so we\Ncan reliably block packets from arriving
Dialogue: 0,0:11:56.02,0:12:01.91,Default,,0000,0000,0000,,and we can reorder the packet and so on. We\Nare not breaking encryption yet. And the
Dialogue: 0,0:12:01.91,0:12:06.69,Default,,0000,0000,0000,,way we obtain this man-in-the-middle\Nposition is, we simply take all the frames
Dialogue: 0,0:12:06.69,0:12:11.25,Default,,0000,0000,0000,,that the access point which, e.g.,\Nis on Channel 6, we take all the frames
Dialogue: 0,0:12:11.25,0:12:16.25,Default,,0000,0000,0000,,that it is broadcasting and as an attacker,\Nwe capture them and we rebroadcast them, we
Dialogue: 0,0:12:16.25,0:12:21.22,Default,,0000,0000,0000,,retransmit them on a different channel, \Ne.g. Channel 1. So we are effectively
Dialogue: 0,0:12:21.22,0:12:26.83,Default,,0000,0000,0000,,cloning the real access point on a rogue\Nchannel and then we force the victim into
Dialogue: 0,0:12:26.83,0:12:31.07,Default,,0000,0000,0000,,connecting to this rogue access point on\Nthis different channel.
Dialogue: 0,0:12:31.07,0:12:36.02,Default,,0000,0000,0000,,So let's assume now that the attacker\Nobtains this position, this man-in-the-
Dialogue: 0,0:12:36.02,0:12:42.62,Default,,0000,0000,0000,,middle position and the first stage of the\N4-way handshake, we don't modify any
Dialogue: 0,0:12:42.62,0:12:48.58,Default,,0000,0000,0000,,frames at all. So e.g. if the\Nclient is using 802.1x authentication, we
Dialogue: 0,0:12:48.58,0:12:52.80,Default,,0000,0000,0000,,simply forward all the frames between\Nthese two different channels and we do the
Dialogue: 0,0:12:52.80,0:12:56.60,Default,,0000,0000,0000,,same thing with the first three messages\Nof the 4-way handshake, we simply
Dialogue: 0,0:12:56.60,0:13:03.97,Default,,0000,0000,0000,,forward them unmodified. Where the attack\Nstarts, is if the client sends Msg4
Dialogue: 0,0:13:03.97,0:13:08.99,Default,,0000,0000,0000,,of the 4-way handshake. Instead of\Nforwarding this message to the access
Dialogue: 0,0:13:08.99,0:13:14.33,Default,,0000,0000,0000,,point, we don't forward it, which in our\Nsituation is equivalent to blocking the
Dialogue: 0,0:13:14.33,0:13:20.86,Default,,0000,0000,0000,,message from arriving at the access point.\NNow what's interesting in this situation,
Dialogue: 0,0:13:20.86,0:13:26.67,Default,,0000,0000,0000,,is that from the perspective of the client,\Nthe handshake now successfully completed.
Dialogue: 0,0:13:26.67,0:13:32.04,Default,,0000,0000,0000,,After all, it received Msg3, it\Nreplied using Msg4 and it thinks that
Dialogue: 0,0:13:32.04,0:13:35.86,Default,,0000,0000,0000,,the handshake is done, meaning it now\Ninstalls the encryption key and installs
Dialogue: 0,0:13:35.86,0:13:44.44,Default,,0000,0000,0000,,the PTK for use. So, let's make some space\Nhere - the client thinks, that the handshake
Dialogue: 0,0:13:44.44,0:13:48.66,Default,,0000,0000,0000,,was completed, it has installed the key,\Nbut the access point hasn't received
Dialogue: 0,0:13:48.66,0:13:55.34,Default,,0000,0000,0000,,Msg4 yet and the access point will\Ntry to recover from this situation and it
Dialogue: 0,0:13:55.34,0:14:02.27,Default,,0000,0000,0000,,will do that by retransmitting a new\NMsg3. And as the - as we, as the
Dialogue: 0,0:14:02.27,0:14:06.62,Default,,0000,0000,0000,,attacker, will forward this message to the\Nclient, the client will accept this
Dialogue: 0,0:14:06.62,0:14:11.58,Default,,0000,0000,0000,,retransmitted Msg3 and then the Wi-Fi\Nstandard says, that if you receive a
Dialogue: 0,0:14:11.58,0:14:16.94,Default,,0000,0000,0000,,retransmitted Msg3, you will reply\Nusing a new Msg4. After that you will
Dialogue: 0,0:14:16.94,0:14:23.45,Default,,0000,0000,0000,,also install the encryption key again. Now,\None remark that I want to make here, is
Dialogue: 0,0:14:23.45,0:14:30.52,Default,,0000,0000,0000,,that, when we receive the retransmitted\NMsg3, we reply using a new Msg4,
Dialogue: 0,0:14:30.52,0:14:36.15,Default,,0000,0000,0000,,however, this Msg4 will be already\Nencrypted at the link layer and the reason
Dialogue: 0,0:14:36.15,0:14:40.98,Default,,0000,0000,0000,,it's already encrypted, is because these\Nhandshake messages are normal data frames
Dialogue: 0,0:14:40.98,0:14:45.88,Default,,0000,0000,0000,,and well, we already installed the\Nencryption key to encrypt data frames. So
Dialogue: 0,0:14:45.88,0:14:51.61,Default,,0000,0000,0000,,nearly all implementations we tested, will\Nsend Msg4, the retransmitted Msg4,
Dialogue: 0,0:14:51.61,0:14:56.71,Default,,0000,0000,0000,,in an encrypted fashion. Now, I want to\Nremark here, that the Wi-Fi standard
Dialogue: 0,0:14:56.71,0:15:02.65,Default,,0000,0000,0000,,actually demands that Msg4, if it is\Nretransmitted, should be sent in plain text,
Dialogue: 0,0:15:02.65,0:15:07.02,Default,,0000,0000,0000,,so according to the specification, this\Nshouldn't happen. But nearly all
Dialogue: 0,0:15:07.02,0:15:12.100,Default,,0000,0000,0000,,implementations we tested, sent a\Nretransmitted Msg3 using encryption,
Dialogue: 0,0:15:12.100,0:15:17.73,Default,,0000,0000,0000,,and we will abuse this observation later.\NSo as I mentioned, after the client
Dialogue: 0,0:15:17.73,0:15:22.34,Default,,0000,0000,0000,,receives a retransmitted Msg3, it'll\Nreply using Msg4, it will again
Dialogue: 0,0:15:22.34,0:15:27.50,Default,,0000,0000,0000,,install the encryption key, and as a\Nresult of that, this transmit nonce will be
Dialogue: 0,0:15:27.50,0:15:34.16,Default,,0000,0000,0000,,reset, which means, that if the client now\Nsends another data frame, it will again
Dialogue: 0,0:15:34.16,0:15:41.57,Default,,0000,0000,0000,,use this nonce value of 1 to encrypt the\Nframe, meaning we have nonce reuse, and we
Dialogue: 0,0:15:41.57,0:15:46.22,Default,,0000,0000,0000,,have key stream reuse, meaning we can now\Ntry to abuse this to decrypt the data
Dialogue: 0,0:15:46.22,0:15:51.88,Default,,0000,0000,0000,,frame.\NNow, how are we precisely going to abuse
Dialogue: 0,0:15:51.88,0:15:57.74,Default,,0000,0000,0000,,this, because we do somehow need to\Nrecover the key stream that was used? And
Dialogue: 0,0:15:57.74,0:16:03.31,Default,,0000,0000,0000,,we go back to our observation, that we have\Na Msg4 here, that is initially sent in
Dialogue: 0,0:16:03.31,0:16:08.18,Default,,0000,0000,0000,,plain text, and a retransmission of\NMsg4 is later sent in an encrypted
Dialogue: 0,0:16:08.18,0:16:12.16,Default,,0000,0000,0000,,fashion. Now, there is a small difference\Nbetween these two messages, but
Dialogue: 0,0:16:12.16,0:16:15.60,Default,,0000,0000,0000,,essentially we have a message sent in\Nplaintext, and we have a message sent
Dialogue: 0,0:16:15.60,0:16:20.82,Default,,0000,0000,0000,,encrypted, and all we need to do, is we\Nneed to XOR these two messages and we have
Dialogue: 0,0:16:20.82,0:16:24.35,Default,,0000,0000,0000,,the key stream corresponding to the nonce\Nvalue of 1.
Dialogue: 0,0:16:24.35,0:16:28.68,Default,,0000,0000,0000,,This data frame here at the bottom, it\Nalso uses nonce value of 1, meaning it
Dialogue: 0,0:16:28.68,0:16:33.13,Default,,0000,0000,0000,,uses the exact same key stream, so we XOR\Nthis packet with the key stream and there
Dialogue: 0,0:16:33.13,0:16:41.66,Default,,0000,0000,0000,,you go: We decrypted the packets and we\Nhave now defeated WPA2. So...
Dialogue: 0,0:16:41.66,0:16:50.53,Default,,0000,0000,0000,,{\i1}Applause{\i0}\NThank you. So, that describes the attack
Dialogue: 0,0:16:50.53,0:16:56.13,Default,,0000,0000,0000,,against the 4-way handshake. And the\N4-way handshake is not the only Wi-Fi
Dialogue: 0,0:16:56.13,0:17:00.31,Default,,0000,0000,0000,,handshake that is vulnerable. There are\Nalso other handshakes which can be
Dialogue: 0,0:17:00.31,0:17:05.14,Default,,0000,0000,0000,,attacked in a similar manner, but I'm not\Ngoing to explain all of them in detail. If
Dialogue: 0,0:17:05.14,0:17:09.65,Default,,0000,0000,0000,,you want all the nitty-gritty details, I'm\Ngoing to refer you to our academic paper.
Dialogue: 0,0:17:09.65,0:17:14.26,Default,,0000,0000,0000,,Here, I'm just going to discuss more the\Nhigh-level concepts and the ideas behind
Dialogue: 0,0:17:14.26,0:17:18.88,Default,,0000,0000,0000,,the attack. So, e.g., one handshake\Nthat is also vulnerable, is the group key
Dialogue: 0,0:17:18.88,0:17:23.26,Default,,0000,0000,0000,,handshake, and that handshake is used to\Ntransport the group key from the access
Dialogue: 0,0:17:23.26,0:17:27.40,Default,,0000,0000,0000,,point to the client. And that key is used\Nto encrypt broadcast and multicast
Dialogue: 0,0:17:27.40,0:17:33.57,Default,,0000,0000,0000,,traffic. Then we also have the FT\Nhandshake. The FT handshake is used, when
Dialogue: 0,0:17:33.57,0:17:38.46,Default,,0000,0000,0000,,you roam from one access point to another\Naccess point of the same Wi-Fi network.
Dialogue: 0,0:17:38.46,0:17:42.73,Default,,0000,0000,0000,,It's used so you can quickly switch\Nfrom one access point to another without
Dialogue: 0,0:17:42.73,0:17:47.45,Default,,0000,0000,0000,,a long timeout. And finally, another\Nhandshake that's also vulnerable is the
Dialogue: 0,0:17:47.45,0:17:51.99,Default,,0000,0000,0000,,PeerKey handshake, and that's used when\Ntwo clients want to communicate directly
Dialogue: 0,0:17:51.99,0:17:59.51,Default,,0000,0000,0000,,with one another. Okay, so I'm now going\Nto discuss in a bit more detail, what the
Dialogue: 0,0:17:59.51,0:18:05.50,Default,,0000,0000,0000,,practical impact of our attacks are. And\NI'm first going to start with the general
Dialogue: 0,0:18:05.50,0:18:11.77,Default,,0000,0000,0000,,impact that a key reinstallation attack\Nhas. So, let's assume we have a device
Dialogue: 0,0:18:11.77,0:18:15.69,Default,,0000,0000,0000,,that's vulnerable. This device can either\Nbe a client device, e.g. it can be
Dialogue: 0,0:18:15.69,0:18:20.37,Default,,0000,0000,0000,,a smartphone, or a laptop, or these days\Nit can even be a toaster. They have Wi-Fi
Dialogue: 0,0:18:20.37,0:18:26.97,Default,,0000,0000,0000,,as well. Or it can also be an access\Npoint. So if a client or access point is
Dialogue: 0,0:18:26.97,0:18:32.52,Default,,0000,0000,0000,,vulnerable to our key reinstallation\Nattack, the first thing that generally
Dialogue: 0,0:18:32.52,0:18:38.93,Default,,0000,0000,0000,,always happens, if this device ever sends\Nencrypted data frames, we can force it to
Dialogue: 0,0:18:38.93,0:18:44.93,Default,,0000,0000,0000,,reuse the nonce, which in turn we can use\Nto decrypt frames. But that's not the only
Dialogue: 0,0:18:44.93,0:18:50.53,Default,,0000,0000,0000,,thing we can do when a device is vulnerable.\NAnother thing we can do, is we can replay
Dialogue: 0,0:18:50.53,0:18:57.53,Default,,0000,0000,0000,,encrypted frames sent towards this device.\NNow, why is that the case? That's because
Dialogue: 0,0:18:57.53,0:19:02.50,Default,,0000,0000,0000,,if a key is reinstalled, not only is this\Ntransmit nonce reset to 0, but another
Dialogue: 0,0:19:02.50,0:19:08.38,Default,,0000,0000,0000,,parameter, which is called the replay\Ncounter, it is also reset to 0. And this
Dialogue: 0,0:19:08.38,0:19:12.49,Default,,0000,0000,0000,,replay counter, as the name implies,\Nit's used to detect retransmissions, or
Dialogue: 0,0:19:12.49,0:19:18.69,Default,,0000,0000,0000,,it's used to detect malicious replays. If\Nthis counter is reset, we can also replay
Dialogue: 0,0:19:18.69,0:19:24.51,Default,,0000,0000,0000,,frames towards a vulnerable device. So,\Nthat's the general impact of a key
Dialogue: 0,0:19:24.51,0:19:33.11,Default,,0000,0000,0000,,reinstallation attack, but there are a lot\Nof other factors which also influence the
Dialogue: 0,0:19:33.11,0:19:41.25,Default,,0000,0000,0000,,exact impact of the attack, and one of the\Nthings that probably has the biggest
Dialogue: 0,0:19:41.25,0:19:48.10,Default,,0000,0000,0000,,influence, is the encryptions cipher that\Nis being used. So, e.g., these days
Dialogue: 0,0:19:48.10,0:19:52.35,Default,,0000,0000,0000,,it is quite common that Wi-Fi networks use\NAES CCMP. It's the most widely used
Dialogue: 0,0:19:52.35,0:19:58.66,Default,,0000,0000,0000,,encryption algorithm in Wi-Fi networks.\NAgainst this algorithm, the impact in a
Dialogue: 0,0:19:58.66,0:20:04.07,Default,,0000,0000,0000,,sense stays limited to only decrypting and\Nreplaying frames. It's not possible to
Dialogue: 0,0:20:04.07,0:20:10.23,Default,,0000,0000,0000,,abuse our key reinstallation attack to now\Nforge frames. And really, we got lucky
Dialogue: 0,0:20:10.23,0:20:16.69,Default,,0000,0000,0000,,here, because this is the most widely used\Ncipher, and against this cipher we cannot
Dialogue: 0,0:20:16.69,0:20:22.26,Default,,0000,0000,0000,,start to forge frames. Because, if we\Nwould have been using the older encryption
Dialogue: 0,0:20:22.26,0:20:28.13,Default,,0000,0000,0000,,algorithm, which is WPA TKIP, against that\Nalgorithm, we would be able to recover the
Dialogue: 0,0:20:28.13,0:20:32.20,Default,,0000,0000,0000,,Message Integrity Check key, which is\Nbasically just a fancy word for the
Dialogue: 0,0:20:32.20,0:20:37.18,Default,,0000,0000,0000,,authentication key. And once we have that\Nauthentication key, we would be able to
Dialogue: 0,0:20:37.18,0:20:44.88,Default,,0000,0000,0000,,forge frames that appear to be sent by the\Ndevice under attack. Interestingly, lately
Dialogue: 0,0:20:44.88,0:20:50.10,Default,,0000,0000,0000,,there's also been a new encryption\Nalgorithm that is being introduced, and
Dialogue: 0,0:20:50.10,0:20:53.85,Default,,0000,0000,0000,,that algorithm is\Ncalled GCMP. It's fairly new, so only a
Dialogue: 0,0:20:53.85,0:20:59.17,Default,,0000,0000,0000,,few devices currently support it, and\Ncurrently it is being rolled out under the
Dialogue: 0,0:20:59.17,0:21:06.19,Default,,0000,0000,0000,,name of WiGig. Against this algorithm, the\Nimpact of a key reinstallation attack is
Dialogue: 0,0:21:06.19,0:21:14.00,Default,,0000,0000,0000,,really the worst, because here we can\Nagain recover the authentication key, but
Dialogue: 0,0:21:14.00,0:21:18.52,Default,,0000,0000,0000,,when we use GCMP, the same authentication\Nkey is used in both communication
Dialogue: 0,0:21:18.52,0:21:23.49,Default,,0000,0000,0000,,directions. So against GCMP, we would be\Nable to forge frames that are sent from
Dialogue: 0,0:21:23.49,0:21:27.58,Default,,0000,0000,0000,,the client to the access point and also\Nforge frames that appear to be sent
Dialogue: 0,0:21:27.58,0:21:32.63,Default,,0000,0000,0000,,from the access point to the client, while\Nfor the WPA-TKIP algorithm, we would only
Dialogue: 0,0:21:32.63,0:21:37.51,Default,,0000,0000,0000,,be able to forge frames, that appear to be\Nsent by the device that is under attack.
Dialogue: 0,0:21:37.51,0:21:42.63,Default,,0000,0000,0000,,So, my opinion - this is a bit surprising,\Nbecause GCMP is the latest encryption
Dialogue: 0,0:21:42.63,0:21:46.88,Default,,0000,0000,0000,,algorithm that is defined in the Wi-Fi\Nstandard, yet the impact against it would
Dialogue: 0,0:21:46.88,0:21:51.95,Default,,0000,0000,0000,,be the highest. So, this is also why I\Nthink we got lucky here, because if we
Dialogue: 0,0:21:51.95,0:21:55.49,Default,,0000,0000,0000,,would have found the attack, say maybe\Nfive or ten years later, and everyone
Dialogue: 0,0:21:55.49,0:22:01.71,Default,,0000,0000,0000,,would be using this algorithm, the impact\Nwould have been a lot worse. Another thing
Dialogue: 0,0:22:01.71,0:22:06.28,Default,,0000,0000,0000,,that influences the impact of the attack\Nis, which specific handshake we are
Dialogue: 0,0:22:06.28,0:22:11.17,Default,,0000,0000,0000,,attacking. For example, if we attack the\Ngroup key handshake, then the only thing
Dialogue: 0,0:22:11.17,0:22:14.16,Default,,0000,0000,0000,,we can do is, we can \Nonly replay, broadcast or
Dialogue: 0,0:22:14.16,0:22:20.39,Default,,0000,0000,0000,,multicast frames. Now, why is that the\Ncase? Why can't we decrypt broadcast or
Dialogue: 0,0:22:20.39,0:22:26.39,Default,,0000,0000,0000,,multicast frames, if a key reinstallation\Noccurs? And the reason is, that if we
Dialogue: 0,0:22:26.39,0:22:30.15,Default,,0000,0000,0000,,attack the group key handshake, we are\Nattacking the client, and the client is
Dialogue: 0,0:22:30.15,0:22:35.38,Default,,0000,0000,0000,,never sending actual encrypted broadcast\Nframes, so will never reuse the transmit
Dialogue: 0,0:22:35.38,0:22:40.05,Default,,0000,0000,0000,,nonce when it encrypts frames, because\Nit's never encrypting frames. Now, why is
Dialogue: 0,0:22:40.05,0:22:44.52,Default,,0000,0000,0000,,it, that the client never sends real\Nencrypted broadcast frames? Well, the
Dialogue: 0,0:22:44.52,0:22:49.10,Default,,0000,0000,0000,,reason is quite simple. Let's say, we have\Nthe network layout shown here and the
Dialogue: 0,0:22:49.10,0:22:54.23,Default,,0000,0000,0000,,client on the left wants to send a\Nbroadcast frames to all the other clients.
Dialogue: 0,0:22:54.23,0:22:58.42,Default,,0000,0000,0000,,Now, what happens here, is that this client\Nwill send the data frame it wants to
Dialogue: 0,0:22:58.42,0:23:03.69,Default,,0000,0000,0000,,broadcast as a Unicast frame to the access\Npoint only, meaning it won't encrypt it
Dialogue: 0,0:23:03.69,0:23:09.98,Default,,0000,0000,0000,,yet under the group key. It's the access\Npoints that will broadcast this frame to
Dialogue: 0,0:23:09.98,0:23:14.15,Default,,0000,0000,0000,,all connected clients, and only the access\Npoint will then encrypt it using the group
Dialogue: 0,0:23:14.15,0:23:16.35,Default,,0000,0000,0000,,key, and this is to assure that all\Nclients
Dialogue: 0,0:23:16.35,0:23:20.69,Default,,0000,0000,0000,,within range of the access point will\Nreceive this broadcast message. Now, for
Dialogue: 0,0:23:20.69,0:23:24.66,Default,,0000,0000,0000,,us, this means that only the access point\Nis transmitting real encrypted broadcast
Dialogue: 0,0:23:24.66,0:23:28.94,Default,,0000,0000,0000,,frames, and in the group key handshake we\Ncannot attack the access point. We are
Dialogue: 0,0:23:28.94,0:23:33.06,Default,,0000,0000,0000,,only attacking the client, meaning in\Npractice, we can only replay broadcast
Dialogue: 0,0:23:33.06,0:23:37.56,Default,,0000,0000,0000,,frames to the client, at least if we are\Ntargeting the group key handshake. So,
Dialogue: 0,0:23:37.56,0:23:42.98,Default,,0000,0000,0000,,really, the impact is limited in practice\Nif we attack this handshake, because
Dialogue: 0,0:23:42.98,0:23:47.77,Default,,0000,0000,0000,,generally, replaying broadcast data doesn't\Nhave a high impact. Though, I do want to
Dialogue: 0,0:23:47.77,0:23:53.25,Default,,0000,0000,0000,,note, that some home automation systems use\Nbroadcast traffic to, e.g., send
Dialogue: 0,0:23:53.25,0:23:59.25,Default,,0000,0000,0000,,commands to turn the device on or off,\Ne.g. to turn your fridge on, or to turn
Dialogue: 0,0:23:59.25,0:24:03.97,Default,,0000,0000,0000,,lights on or off, so although the\Nimpact of replaying broadcast frame is
Dialogue: 0,0:24:03.97,0:24:08.12,Default,,0000,0000,0000,,low, there are situations in practice,\Nwhere it does have some impact, but it
Dialogue: 0,0:24:08.12,0:24:13.09,Default,,0000,0000,0000,,really depends on your network setup and\Nthe devices that you use. So, the other
Dialogue: 0,0:24:13.09,0:24:17.13,Default,,0000,0000,0000,,handshake that is vulnerable, is the 4-\Nway handshake, but we already discussed
Dialogue: 0,0:24:17.13,0:24:21.81,Default,,0000,0000,0000,,that. Against a 4-way handshake we can\Nattack the clients and the impact, is that
Dialogue: 0,0:24:21.81,0:24:25.61,Default,,0000,0000,0000,,we can replay and decrypt frames, and\Ndepending on the encryption algorithm
Dialogue: 0,0:24:25.61,0:24:31.69,Default,,0000,0000,0000,,being used, we can possibly forge frames\Nas well. The situation is a lot more
Dialogue: 0,0:24:31.69,0:24:36.08,Default,,0000,0000,0000,,interesting for the FT handshake, though.\NAnd remember, this handshake is used, when
Dialogue: 0,0:24:36.08,0:24:40.96,Default,,0000,0000,0000,,you roam from one access point to another\Nof the same network. Against the FT
Dialogue: 0,0:24:40.96,0:24:45.67,Default,,0000,0000,0000,,handshake, it's not the clients that we\Ncan attack, but here we can attack the
Dialogue: 0,0:24:45.67,0:24:51.45,Default,,0000,0000,0000,,access point. And on top of that, when\Nattacking the FT handshake, we no longer
Dialogue: 0,0:24:51.45,0:24:56.68,Default,,0000,0000,0000,,need this man-in-the-middle position. Now,\Nwhy is that the case? Well, let's again
Dialogue: 0,0:24:56.68,0:25:01.37,Default,,0000,0000,0000,,explain this using our common example,\Nwhere a client wants to connect and where
Dialogue: 0,0:25:01.37,0:25:08.33,Default,,0000,0000,0000,,it is executing the FT handshake. And at a\Nhigh level, the FT handshake is the same
Dialogue: 0,0:25:08.33,0:25:11.52,Default,,0000,0000,0000,,as the 4-way handshake, meaning you\Nalso have four frames that are
Dialogue: 0,0:25:11.52,0:25:16.73,Default,,0000,0000,0000,,transmitted, but the big difference here\Nis, that with the FT handshake it's the
Dialogue: 0,0:25:16.73,0:25:21.22,Default,,0000,0000,0000,,client that sends the first message\Nin the handshake, while for the 4-way
Dialogue: 0,0:25:21.22,0:25:26.25,Default,,0000,0000,0000,,handshake it was the access point that\Nsends the first message. So, the handshake
Dialogue: 0,0:25:26.25,0:25:29.86,Default,,0000,0000,0000,,is practically the same as the 4-way\Nhandshake, meaning, initially we have two
Dialogue: 0,0:25:29.86,0:25:34.19,Default,,0000,0000,0000,,messages that transport these random\Nnumbers, these nonces, between both
Dialogue: 0,0:25:34.19,0:25:40.77,Default,,0000,0000,0000,,devices. Then, both these endpoints can\Ngenerate the fresh encryption key. Then
Dialogue: 0,0:25:40.77,0:25:46.09,Default,,0000,0000,0000,,the last two frames, they are again used\Nto confirm that both parties negotiated
Dialogue: 0,0:25:46.09,0:25:51.21,Default,,0000,0000,0000,,the same encryption key. Now, I want to go\Nin a bit more detail here on this last
Dialogue: 0,0:25:51.21,0:25:56.60,Default,,0000,0000,0000,,phase, and what happens here, is that the\Nthird frame of the handshake is now sent
Dialogue: 0,0:25:56.60,0:26:01.97,Default,,0000,0000,0000,,from the client to the access point and\Nthat is a reassociation request. And after
Dialogue: 0,0:26:01.97,0:26:06.78,Default,,0000,0000,0000,,the access point receives this frame, it\Nwill reply using a reassociation response
Dialogue: 0,0:26:06.78,0:26:12.80,Default,,0000,0000,0000,,frame and it will install the encryption\Nkey. Once it has installed the encryption
Dialogue: 0,0:26:12.80,0:26:18.59,Default,,0000,0000,0000,,key, it can of course start sending\Nencrypted data frames. So, let's again
Dialogue: 0,0:26:18.59,0:26:23.82,Default,,0000,0000,0000,,make some room here. What we can now do\Nas an attacker, is we can take this
Dialogue: 0,0:26:23.82,0:26:28.84,Default,,0000,0000,0000,,reassociation request that the client\Npreviously transmitted, and we can simply
Dialogue: 0,0:26:28.84,0:26:36.45,Default,,0000,0000,0000,,replay it. That's because in the FT\Nhandshake, there is no replay protection
Dialogue: 0,0:26:36.45,0:26:41.73,Default,,0000,0000,0000,,against messages of the handshake. So we\Ncan just take that frame, we can send it
Dialogue: 0,0:26:41.73,0:26:45.38,Default,,0000,0000,0000,,again to the access point. The access\Npoint will receive it, it will accept it,
Dialogue: 0,0:26:45.38,0:26:51.49,Default,,0000,0000,0000,,and it will reply using a reassociation\Nresponse. Now, so far this is not a
Dialogue: 0,0:26:51.49,0:26:57.44,Default,,0000,0000,0000,,problem. The problem here is, that again\Nthe access point will reinstall the
Dialogue: 0,0:26:57.44,0:27:01.27,Default,,0000,0000,0000,,encryption key, and here it goes wrong\Nbecause we are reinstalling this
Dialogue: 0,0:27:01.27,0:27:05.89,Default,,0000,0000,0000,,encryption key. The transmit nonce is\Nagain reset to 0, meaning if we now send
Dialogue: 0,0:27:05.89,0:27:11.93,Default,,0000,0000,0000,,the data frame again, the nonce value of 1\Nis used to encrypt these data frames,
Dialogue: 0,0:27:11.93,0:27:14.95,Default,,0000,0000,0000,,meaning the same key stream is used,\Nmeaning we can start applying the same
Dialogue: 0,0:27:14.95,0:27:19.03,Default,,0000,0000,0000,,tricks to first derive some known key\Nstream and to then abuse that to attack
Dialogue: 0,0:27:19.03,0:27:24.25,Default,,0000,0000,0000,,the handshake. So, I want to highlight\Nhere a few things. And the first is, the
Dialogue: 0,0:27:24.25,0:27:27.74,Default,,0000,0000,0000,,reason why we don't need a man-in-the-\Nmiddle position, is because handshake
Dialogue: 0,0:27:27.74,0:27:30.17,Default,,0000,0000,0000,,messages in\Nthe FT handshake, they are not protected
Dialogue: 0,0:27:30.17,0:27:34.72,Default,,0000,0000,0000,,against replays, while in the 4-way\Nhandshake, every handshake messages
Dialogue: 0,0:27:34.72,0:27:40.33,Default,,0000,0000,0000,,contains a sequence counter, where the\Nreceiver uses the sequence counter to
Dialogue: 0,0:27:40.33,0:27:44.45,Default,,0000,0000,0000,,detect replays, but for the FT handshake\Nthat's not the case, so we can just take
Dialogue: 0,0:27:44.45,0:27:48.09,Default,,0000,0000,0000,,these messages, we can replay them, and we\Ndon't need a man-in-the-middle position to
Dialogue: 0,0:27:48.09,0:27:55.35,Default,,0000,0000,0000,,block packets and to trigger\Nretransmissions. Ok, so that's the
Dialogue: 0,0:27:55.35,0:28:01.63,Default,,0000,0000,0000,,explanation for the FT handshake. Another\Nfactor that can influence the impacts of
Dialogue: 0,0:28:01.63,0:28:06.66,Default,,0000,0000,0000,,our attack in practice, is which operating\Nsystem and which device precisely we are
Dialogue: 0,0:28:06.66,0:28:12.12,Default,,0000,0000,0000,,attacking. And in particular, we see that\NiOS and Windows, they are not vulnerable
Dialogue: 0,0:28:12.12,0:28:17.97,Default,,0000,0000,0000,,against attacks against a 4-way\Nhandshake. And why is that the case? Well,
Dialogue: 0,0:28:17.97,0:28:22.36,Default,,0000,0000,0000,,that's because these two devices don't\Nreally follow the standard, and they don't
Dialogue: 0,0:28:22.36,0:28:26.66,Default,,0000,0000,0000,,accept retransmissions of Msg3,\Nmeaning we cannot abuse these
Dialogue: 0,0:28:26.66,0:28:33.18,Default,,0000,0000,0000,,retransmissions of Msg3 to trigger\Nthese key reinstallations.
Dialogue: 0,0:28:33.18,0:28:36.38,Default,,0000,0000,0000,,Now, I want to make two remarks \Nhere. And the first one is, that
Dialogue: 0,0:28:36.38,0:28:41.55,Default,,0000,0000,0000,,against these devices we can still attack\Nthe group key handshake. And particularly
Dialogue: 0,0:28:41.55,0:28:46.86,Default,,0000,0000,0000,,when looking at iOS, if we look at iOS\Nversion 11, it does implement the standard
Dialogue: 0,0:28:46.86,0:28:50.68,Default,,0000,0000,0000,,properly and it does accept\Nretransmissions of Msg3, meaning that
Dialogue: 0,0:28:50.68,0:28:58.58,Default,,0000,0000,0000,,one is vulnerable to attacks against the\N4-way handshake. Now, Linux is not much
Dialogue: 0,0:28:58.58,0:29:04.46,Default,,0000,0000,0000,,better, because if we look at the Wi-Fi client\Nthat is used on Linux, and for example on
Dialogue: 0,0:29:04.46,0:29:11.75,Default,,0000,0000,0000,,Android, it's called wpa_supplicant, and\Nagainst wpa_supplicant 2.4 and higher, we
Dialogue: 0,0:29:11.75,0:29:17.92,Default,,0000,0000,0000,,notice that, if we try to perform a key\Nreinstallation attack, it won't reinstall
Dialogue: 0,0:29:17.92,0:29:22.99,Default,,0000,0000,0000,,the secret key that was negotiated, but\Nno, instead it will suddenly install an
Dialogue: 0,0:29:22.99,0:29:27.87,Default,,0000,0000,0000,,all-zero encryption key, and then it of\Ncourse becomes very trivial to start
Dialogue: 0,0:29:27.87,0:29:36.92,Default,,0000,0000,0000,,decrypting data that this device is\Ntransmitting. Now, why does this happen?
Dialogue: 0,0:29:36.92,0:29:42.66,Default,,0000,0000,0000,,I can actually sort of understand why this\Nwent wrong. So, I'm going to explain what
Dialogue: 0,0:29:42.66,0:29:48.99,Default,,0000,0000,0000,,the implementation does wrong, to... why it\Ninstalls this all-zero key. And to explain
Dialogue: 0,0:29:48.99,0:29:52.46,Default,,0000,0000,0000,,this, I'm going to assume that we have an\NAndroid device that is connecting to an
Dialogue: 0,0:29:52.46,0:29:56.66,Default,,0000,0000,0000,,access point. And we're going to zoom in a\Nbit on the implementation of the Android.
Dialogue: 0,0:29:56.66,0:30:01.08,Default,,0000,0000,0000,,And we're going to look at two entities.\NWe're first going to look at wpa_supplicant,
Dialogue: 0,0:30:01.08,0:30:05.33,Default,,0000,0000,0000,,which is represented by the\Nhandshake icon here, and we're also going
Dialogue: 0,0:30:05.33,0:30:10.43,Default,,0000,0000,0000,,to look at another entity, namely the\NLinux kernel. It's the Linux kernel that
Dialogue: 0,0:30:10.43,0:30:15.24,Default,,0000,0000,0000,,will be responsible for encrypting data\Nframes, and wpa_ supplicant will be
Dialogue: 0,0:30:15.24,0:30:20.89,Default,,0000,0000,0000,,responsible for executing the 4-way handshake.\NAnd of course we assume, that we as an
Dialogue: 0,0:30:20.89,0:30:27.41,Default,,0000,0000,0000,,attacker are nearby, and we again have\Nthis man-in-the-middle position. So, what
Dialogue: 0,0:30:27.41,0:30:31.15,Default,,0000,0000,0000,,does an attacker have to do to cause this\Ninstallation of an all-zero encryption
Dialogue: 0,0:30:31.15,0:30:36.78,Default,,0000,0000,0000,,key? Well, again, we simply let the first\Nphase of the 4-way handshake execute
Dialogue: 0,0:30:36.78,0:30:42.46,Default,,0000,0000,0000,,normally, and when the access point sends\NMsg3 of the 4-way handshake, we
Dialogue: 0,0:30:42.46,0:30:48.68,Default,,0000,0000,0000,,forward that to the Android. Android will\Nreply using Msg4. And we will
Dialogue: 0,0:30:48.68,0:30:53.51,Default,,0000,0000,0000,,again block Msg4 from arriving at the\Naccess point.
Dialogue: 0,0:30:53.51,0:30:58.09,Default,,0000,0000,0000,,Now, completely similar to the case with\Nthe 4-way handshake, the client thinks that
Dialogue: 0,0:30:58.09,0:31:02.02,Default,,0000,0000,0000,,the handshake now successfully completed,\Nmeaning it will install the encryption
Dialogue: 0,0:31:02.02,0:31:07.60,Default,,0000,0000,0000,,key. How it will install the encryption\Nkey is as follows: It commands the Linux
Dialogue: 0,0:31:07.60,0:31:15.06,Default,,0000,0000,0000,,kernel into installing the encryption key\Nin the driver. And the driver itself will
Dialogue: 0,0:31:15.06,0:31:19.08,Default,,0000,0000,0000,,make a copy of the encryption key. And it\Nwill store it locally. And the driver can
Dialogue: 0,0:31:19.08,0:31:24.28,Default,,0000,0000,0000,,then encrypt frames. Now this means that\Nwpa_supplicant, which is just a user land
Dialogue: 0,0:31:24.28,0:31:28.14,Default,,0000,0000,0000,,program, no longer needs to store the\Nencryption key, meaning it will clear it
Dialogue: 0,0:31:28.14,0:31:34.27,Default,,0000,0000,0000,,from memory. What will happen now, if we\Ncontinue with the attack, is that the
Dialogue: 0,0:31:34.27,0:31:38.97,Default,,0000,0000,0000,,access point will retransmit Msg3,\Nbecause it did not receive Msg4. The
Dialogue: 0,0:31:38.97,0:31:42.79,Default,,0000,0000,0000,,client will again happily accept this\Nretransmitted Msg3 and reply using
Dialogue: 0,0:31:42.79,0:31:48.29,Default,,0000,0000,0000,,Msg4. And again it will instruct the\NLinux kernel saying "Hey, please install
Dialogue: 0,0:31:48.29,0:31:52.39,Default,,0000,0000,0000,,this encryption key that is located at\Nthis address in the memory." But of
Dialogue: 0,0:31:52.39,0:31:56.79,Default,,0000,0000,0000,,course, that memory is now all zeros,\Nbecause that key has just been cleared
Dialogue: 0,0:31:56.79,0:31:59.72,Default,,0000,0000,0000,,from memory. So,\Nnow it's basically commanding the Linux
Dialogue: 0,0:31:59.72,0:32:04.14,Default,,0000,0000,0000,,kernel into installing an all-zero\Nencryption key. And the Linux kernel and
Dialogue: 0,0:32:04.14,0:32:09.08,Default,,0000,0000,0000,,driver will happily obey this command and\Nthey will install an all-zero encryption
Dialogue: 0,0:32:09.08,0:32:13.69,Default,,0000,0000,0000,,key, meaning at this point, all the data\Nthat the client is sending, is encrypted
Dialogue: 0,0:32:13.69,0:32:18.37,Default,,0000,0000,0000,,using a known key, so we can easily\Ndecrypt all the traffic, and of course we
Dialogue: 0,0:32:18.37,0:32:23.47,Default,,0000,0000,0000,,can also send any traffic we want to the\Nclient. Basically, we are now a rogue
Dialogue: 0,0:32:23.47,0:32:28.53,Default,,0000,0000,0000,,access point and we can manipulate the\Ntraffic of the client as we wish.
Dialogue: 0,0:32:28.53,0:32:37.70,Default,,0000,0000,0000,,{\i1}Applause{\i0}\NMV: Thank you. So, after this you might be
Dialogue: 0,0:32:37.70,0:32:42.94,Default,,0000,0000,0000,,wondering, "Well, gee, is my device\Nvulnerable?" And you can test your own
Dialogue: 0,0:32:42.94,0:32:50.04,Default,,0000,0000,0000,,device using the following script. It's on\Ngithub. I have tested the script on Kali
Dialogue: 0,0:32:50.04,0:32:54.87,Default,,0000,0000,0000,,Linux, on Arch Linux, and also on Ubuntu,\Nso I could recommend using one of these
Dialogue: 0,0:32:54.87,0:33:00.27,Default,,0000,0000,0000,,distributions, and I also recommend to use\Na Wi-Fi dongle that we or someone else has
Dialogue: 0,0:33:00.27,0:33:05.41,Default,,0000,0000,0000,,tested ourselves, because we noticed that\Nif you use our testing scripts with some
Dialogue: 0,0:33:05.41,0:33:08.96,Default,,0000,0000,0000,,older\NWi-Fi devices, then there are some bugs in
Dialogue: 0,0:33:08.96,0:33:16.28,Default,,0000,0000,0000,,these Wi-Fi devices which cause our\Nscripts to fail. And one way to also
Dialogue: 0,0:33:16.28,0:33:20.01,Default,,0000,0000,0000,,prevent our scripts to fail, is to disable\Nhardware encryption. Now, how you should do
Dialogue: 0,0:33:20.01,0:33:25.41,Default,,0000,0000,0000,,that is also explained on this page. Using\Nthese scripts, you can test both your
Dialogue: 0,0:33:25.41,0:33:29.14,Default,,0000,0000,0000,,client devices, you can test against\Nattacks against the 4-way handshake,
Dialogue: 0,0:33:29.14,0:33:33.80,Default,,0000,0000,0000,,the group key handshake, and there's also\Na script to test the access point, whether
Dialogue: 0,0:33:33.80,0:33:40.52,Default,,0000,0000,0000,,it's vulnerable against attacks against\Nthe FT handshake. Now, if you're going to
Dialogue: 0,0:33:40.52,0:33:45.50,Default,,0000,0000,0000,,try to see which devices are vulnerable,\Nyou are most likely going to see that
Dialogue: 0,0:33:45.50,0:33:52.56,Default,,0000,0000,0000,,quite some clients are still vulnerable to\Nour attacks. Luckily, we can modify the
Dialogue: 0,0:33:52.56,0:33:58.13,Default,,0000,0000,0000,,access point to prevent attacks against\Nthe client. In particular, we can make
Dialogue: 0,0:33:58.13,0:34:02.62,Default,,0000,0000,0000,,additional modifications to the access\Npoint, such that the access points never
Dialogue: 0,0:34:02.62,0:34:07.15,Default,,0000,0000,0000,,retransmits Msg3 of the 4-way\Nhandshake, and that it also never
Dialogue: 0,0:34:07.15,0:34:11.64,Default,,0000,0000,0000,,retransmits the first message of the group\Nkey handshake. And if we do that, then
Dialogue: 0,0:34:11.64,0:34:17.06,Default,,0000,0000,0000,,clients that are connected to such a\Nmodified access points, they are no longer
Dialogue: 0,0:34:17.06,0:34:19.13,Default,,0000,0000,0000,,vulnerable against most attacks. There are
Dialogue: 0,0:34:19.13,0:34:24.66,Default,,0000,0000,0000,,still some edge cases where the device is\Nvulnerable, but these have a very low
Dialogue: 0,0:34:24.66,0:34:29.91,Default,,0000,0000,0000,,impact. So, if we modify an access point\Nin this way, then connected clients are no
Dialogue: 0,0:34:29.91,0:34:34.72,Default,,0000,0000,0000,,longer vulnerable. One downside here is,\Nthat because we are no longer
Dialogue: 0,0:34:34.72,0:34:40.53,Default,,0000,0000,0000,,retransmitting certain messages, it could\Nbe that especially in a noisy environment,
Dialogue: 0,0:34:40.53,0:34:44.52,Default,,0000,0000,0000,,because we don't retransmit these messages\Nanymore, that the handshake may fail
Dialogue: 0,0:34:44.52,0:34:50.50,Default,,0000,0000,0000,,because the reliability is now less. Now,\None thing I also want to remark here,
Dialogue: 0,0:34:50.50,0:34:57.31,Default,,0000,0000,0000,,that... if you have a router, which is\Nvulnerable against our attack and a
Dialogue: 0,0:34:57.31,0:35:02.09,Default,,0000,0000,0000,,vendor says "Hey, we patched our router,\Nso we patched our access point to defend
Dialogue: 0,0:35:02.09,0:35:07.40,Default,,0000,0000,0000,,against attacks," then this does not mean\Nthat this access point implements these
Dialogue: 0,0:35:07.40,0:35:10.78,Default,,0000,0000,0000,,countermeasures. Because these\Ncountermeasures, they are additional
Dialogue: 0,0:35:10.78,0:35:15.92,Default,,0000,0000,0000,,modifications on top of the normal\Npatches to defend against the attack. So,
Dialogue: 0,0:35:15.92,0:35:21.13,Default,,0000,0000,0000,,only if a vendor explicitly says that "Our\Npatches of the access point also prevent
Dialogue: 0,0:35:21.13,0:35:26.32,Default,,0000,0000,0000,,attacks against clients," then, only if\Nthey explicitly say that, are attacks
Dialogue: 0,0:35:26.32,0:35:32.64,Default,,0000,0000,0000,,against the client also prevented. Ok,\Nso now I want to cover some misconceptions
Dialogue: 0,0:35:32.64,0:35:39.81,Default,,0000,0000,0000,,that have been floating around the\Ninternet. And the first one is, that some
Dialogue: 0,0:35:39.81,0:35:43.49,Default,,0000,0000,0000,,people claim, if you only patch the\Nclients, or if you only patch the access
Dialogue: 0,0:35:43.49,0:35:46.98,Default,,0000,0000,0000,,point, then you're fine. But that's not\Nthe case. Because if you only patch the
Dialogue: 0,0:35:46.98,0:35:51.42,Default,,0000,0000,0000,,client and the access point is vulnerable,\Nthen we can still attack the access point.
Dialogue: 0,0:35:51.42,0:35:54.81,Default,,0000,0000,0000,,If the access point only contains these\Nnormal patches, the normal patches to
Dialogue: 0,0:35:54.81,0:36:00.02,Default,,0000,0000,0000,,defend against attacks, then connected\Nclients are also still vulnerable. So, as
Dialogue: 0,0:36:00.02,0:36:05.66,Default,,0000,0000,0000,,I mentioned, connected clients are only\Ndefended, if the access point contains
Dialogue: 0,0:36:05.66,0:36:11.53,Default,,0000,0000,0000,,really extra modifications on top of the\Ndefault patches. Now, another common
Dialogue: 0,0:36:11.53,0:36:17.08,Default,,0000,0000,0000,,misconception is, that some people might\Nsay "But, yeah, it's a cool attack, but
Dialogue: 0,0:36:17.08,0:36:22.49,Default,,0000,0000,0000,,you have to be close to the network in\Norder to pull off these attacks."
Dialogue: 0,0:36:22.49,0:36:26.92,Default,,0000,0000,0000,,Unfortunately, that's not the case because\Nwe can use special antenna. And this
Dialogue: 0,0:36:26.92,0:36:30.17,Default,,0000,0000,0000,,special antenna, they can be made\Nreally cheap out of, e.g. just a
Dialogue: 0,0:36:30.17,0:36:36.04,Default,,0000,0000,0000,,tin can, and with this special antenna, we\Ncan manipulate Wi-Fi traffic from up to,
Dialogue: 0,0:36:36.04,0:36:41.45,Default,,0000,0000,0000,,say, 2 miles. And there are even leaked\NNSA documents, where the NSA is able to
Dialogue: 0,0:36:41.45,0:36:47.44,Default,,0000,0000,0000,,exploit a Wi-Fi network using other\Nattacks from up to 8 miles away. Now,
Dialogue: 0,0:36:47.44,0:36:51.01,Default,,0000,0000,0000,,that's of course with a clear line of\Nsight, but still this shows that you don't
Dialogue: 0,0:36:51.01,0:36:54.62,Default,,0000,0000,0000,,have to be physically close to the\Nnetwork. You can still be relatively far
Dialogue: 0,0:36:54.62,0:37:02.37,Default,,0000,0000,0000,,away. Another strange remark that I\Nsometimes hear, is that you need to be
Dialogue: 0,0:37:02.37,0:37:06.63,Default,,0000,0000,0000,,connected to the network in order to pull\Noff these attacks, which would basically
Dialogue: 0,0:37:06.63,0:37:10.44,Default,,0000,0000,0000,,mean, you need to know the password of the\Nnetwork to carry out the attacks. But
Dialogue: 0,0:37:10.44,0:37:14.54,Default,,0000,0000,0000,,that's not the case. As I mentioned,\Nduring the attacks, you only need to be
Dialogue: 0,0:37:14.54,0:37:19.74,Default,,0000,0000,0000,,close enough. You need to be able to\Nmanipulate some encrypted packets. But you
Dialogue: 0,0:37:19.74,0:37:23.74,Default,,0000,0000,0000,,don't need to know anything about the\Nnetwork. You simply need to know the
Dialogue: 0,0:37:23.74,0:37:27.21,Default,,0000,0000,0000,,network is there and there's a vulnerable\Nclient and access point and then you can
Dialogue: 0,0:37:27.21,0:37:34.45,Default,,0000,0000,0000,,start attacking them. One remark that I\Ncan understand, is that some people
Dialogue: 0,0:37:34.45,0:37:39.43,Default,,0000,0000,0000,,say that "Yeah, Ok, you can attack these\Nhandshakes, and you can decrypt data that
Dialogue: 0,0:37:39.43,0:37:43.63,Default,,0000,0000,0000,,is sent right after these handshakes, but\Ngenerally right after you connect to an
Dialogue: 0,0:37:43.63,0:37:48.69,Default,,0000,0000,0000,,Wi-Fi network, you're not really sending\Ninteresting data, because at that point
Dialogue: 0,0:37:48.69,0:37:53.52,Default,,0000,0000,0000,,your device is sending e.g. ARP\Nrequests, or it's sending DHCP requests,
Dialogue: 0,0:37:53.52,0:37:59.77,Default,,0000,0000,0000,,or is just creating TCP connections. But\Nno useful information is transmitted at
Dialogue: 0,0:37:59.77,0:38:06.26,Default,,0000,0000,0000,,this time." Unfortunately, at least for a\Ndefender, this is again not true. Because,
Dialogue: 0,0:38:06.26,0:38:10.09,Default,,0000,0000,0000,,what we can do as an attacker is, we can\Nfirst let the client connect {\i1}blackout{\i0} out
Dialogue: 0,0:38:10.09,0:38:14.04,Default,,0000,0000,0000,,manipulating any traffic. The client, the\Nvictim, will then, e.g. start
Dialogue: 0,0:38:14.04,0:38:20.12,Default,,0000,0000,0000,,browsing the internet, start\Nopening TCP connections, and in the middle
Dialogue: 0,0:38:20.12,0:38:24.07,Default,,0000,0000,0000,,of that, while the victim is e.g.\Nsurfing the internet, we can
Dialogue: 0,0:38:24.07,0:38:28.09,Default,,0000,0000,0000,,deauthenticate the client from the\Nnetwork, and all operating system will
Dialogue: 0,0:38:28.09,0:38:32.02,Default,,0000,0000,0000,,then immediately execute a new 4-way\Nhandshake. And once that 4-way
Dialogue: 0,0:38:32.02,0:38:37.50,Default,,0000,0000,0000,,handshake is then completed, it will \Nsend all the buffered TCP packets again
Dialogue: 0,0:38:37.50,0:38:41.28,Default,,0000,0000,0000,,to the access point and also in a reverse\Ndirection. So, basically, what we as an
Dialogue: 0,0:38:41.28,0:38:45.17,Default,,0000,0000,0000,,attacker can do, we can wait until we\Nexpect the victim to send interesting
Dialogue: 0,0:38:45.17,0:38:49.19,Default,,0000,0000,0000,,information. Then we deauthenticate the\Nvictim. It will execute a new handshake.
Dialogue: 0,0:38:49.19,0:38:56.01,Default,,0000,0000,0000,,And then we can decrypt the data that will\Nbe transmitted right after that handshake.
Dialogue: 0,0:38:56.01,0:38:59.52,Default,,0000,0000,0000,,Another thing that makes the attack\Npossibly hard, is that obtaining this
Dialogue: 0,0:38:59.52,0:39:03.50,Default,,0000,0000,0000,,channel based man-in-the-middle is\Ndifficult. For example, you might be
Dialogue: 0,0:39:03.50,0:39:07.76,Default,,0000,0000,0000,,thinking that in order to force the\Nclients to connect to the rogue access
Dialogue: 0,0:39:07.76,0:39:13.15,Default,,0000,0000,0000,,point, you need a stronger signal strength\Nthan a real access point. But again,
Dialogue: 0,0:39:13.15,0:39:17.87,Default,,0000,0000,0000,,that's not the case. And the reason this\Nis not the case, is because we can use
Dialogue: 0,0:39:17.87,0:39:23.35,Default,,0000,0000,0000,,special Wi-Fi packets and so-called\Nchannel switch announcements, which
Dialogue: 0,0:39:23.35,0:39:28.68,Default,,0000,0000,0000,,command the client into switching to a\Ndifferent Wi-Fi channel, and effectively
Dialogue: 0,0:39:28.68,0:39:32.40,Default,,0000,0000,0000,,{\i1}blackout{\i0} to a rogue access point. So we don't\Nneed a high signal strength, we can simply
Dialogue: 0,0:39:32.40,0:39:36.52,Default,,0000,0000,0000,,command a victim into saying "Hey, switch\Nto this channel and connect to our access
Dialogue: 0,0:39:36.52,0:39:40.82,Default,,0000,0000,0000,,point." And these frames are not\Nauthenticated, so we can just forge them
Dialogue: 0,0:39:40.82,0:39:47.78,Default,,0000,0000,0000,,as an attacker. Another thing you might\Nsay, that the complexity of the attack is
Dialogue: 0,0:39:47.78,0:39:52.87,Default,,0000,0000,0000,,hard, meaning it requires some expertise\Nto implement this. And this is true. You
Dialogue: 0,0:39:52.87,0:39:59.11,Default,,0000,0000,0000,,do need to know a bit about Wi-Fi in order\Nto make a proof of concept reliable, but
Dialogue: 0,0:39:59.11,0:40:03.48,Default,,0000,0000,0000,,as usual you only need to write this\Nattack once, and then people can use your
Dialogue: 0,0:40:03.48,0:40:07.88,Default,,0000,0000,0000,,script in order to attack others. And this\Nis similar to, e.g., memory
Dialogue: 0,0:40:07.88,0:40:13.35,Default,,0000,0000,0000,,corruption attacks, such as buffer\Noverflows or stack overflows. Writing the
Dialogue: 0,0:40:13.35,0:40:17.04,Default,,0000,0000,0000,,proof of concept may be hard, but if you\Nthen give it to someone else, or if you
Dialogue: 0,0:40:17.04,0:40:22.00,Default,,0000,0000,0000,,put it in Metasploit or some other tool,\Nall the user has to do, is basically start
Dialogue: 0,0:40:22.00,0:40:29.27,Default,,0000,0000,0000,,the script, and you can start attacking\Npeople. One other misconception that I
Dialogue: 0,0:40:29.27,0:40:35.63,Default,,0000,0000,0000,,sometimes encounter, is that people say "If\Nyou use AES-CCMP, this mitigates the
Dialogue: 0,0:40:35.63,0:40:41.84,Default,,0000,0000,0000,,attack." Again, unfortunately, this is not\Ntrue, because the only advantage of using
Dialogue: 0,0:40:41.84,0:40:47.26,Default,,0000,0000,0000,,AES-CCMP is that\Nthe attacker can no longer forge frames.
Dialogue: 0,0:40:47.26,0:40:52.68,Default,,0000,0000,0000,,The attacker is still able to decrypt and\Nreplay frames. And finally, the last
Dialogue: 0,0:40:52.68,0:40:57.80,Default,,0000,0000,0000,,misconception is, that some people say that\Nenterprise networks aren't vulnerable,
Dialogue: 0,0:40:57.80,0:41:02.83,Default,,0000,0000,0000,,because they e.g. don't execute\Nthe 4-way handshake. But again,
Dialogue: 0,0:41:02.83,0:41:07.45,Default,,0000,0000,0000,,unfortunately, that's wrong, because even\Nthese networks use the 4-way handshake
Dialogue: 0,0:41:07.45,0:41:13.61,Default,,0000,0000,0000,,and they can be attacked as well. So, then\Nyou have some people that say "OK, WPA2 is
Dialogue: 0,0:41:13.61,0:41:19.88,Default,,0000,0000,0000,,now completely broken. It's the end of the\Nworld and we're all doomed." Let's not get
Dialogue: 0,0:41:19.88,0:41:25.53,Default,,0000,0000,0000,,carried away, though. We can patch these\Nvulnerabilities in a backwards compatible
Dialogue: 0,0:41:25.53,0:41:30.19,Default,,0000,0000,0000,,way. And as I illustrated here in my talk,\Nthe impact also really depends on the
Dialogue: 0,0:41:30.19,0:41:34.53,Default,,0000,0000,0000,,devices that you are using and your own\Nnetwork setup. So, sometimes the impact is
Dialogue: 0,0:41:34.53,0:41:38.15,Default,,0000,0000,0000,,actually really low, but of course\Nsometimes the impact can be very high,
Dialogue: 0,0:41:38.15,0:41:43.25,Default,,0000,0000,0000,,e.g. if you have a Linux device, then\Nattacker can do what he or she wishes,
Dialogue: 0,0:41:43.25,0:41:49.66,Default,,0000,0000,0000,,essentially. Now, for the last part of the\Ntalk, I'm going to discuss some lessons
Dialogue: 0,0:41:49.66,0:41:56.15,Default,,0000,0000,0000,,that we can learn from this attack and\Nalso the research. I think one of the most
Dialogue: 0,0:41:56.15,0:42:01.32,Default,,0000,0000,0000,,important and interesting observations -\Nit's also the reason why I really like
Dialogue: 0,0:42:01.32,0:42:06.50,Default,,0000,0000,0000,,this attack myself - is that the 4-way\Nhandshake was proven to be secure. The
Dialogue: 0,0:42:06.50,0:42:11.27,Default,,0000,0000,0000,,encryption protocol, and in particular\NAES, has also been proven as secure.
Dialogue: 0,0:42:11.27,0:42:18.56,Default,,0000,0000,0000,,However, if we combine these two things,\Nthen suddenly we lose all security. And
Dialogue: 0,0:42:18.56,0:42:27.40,Default,,0000,0000,0000,,this is quite unfortunate. And what this\Nteaches us, is that even though individual
Dialogue: 0,0:42:27.40,0:42:33.08,Default,,0000,0000,0000,,parts of a system were really investigated\Nand perhaps formally analyzed, we also
Dialogue: 0,0:42:33.08,0:42:37.56,Default,,0000,0000,0000,,need to analyze the combination of these\Ndifferent entities and models, and we also
Dialogue: 0,0:42:37.56,0:42:43.54,Default,,0000,0000,0000,,need to prove that these combinations are\Nsecure as well. And another way to look at
Dialogue: 0,0:42:43.54,0:42:50.83,Default,,0000,0000,0000,,this, is that in the proof of the 4-way\Nhandshake, the authors, they modeled the
Dialogue: 0,0:42:50.83,0:42:56.78,Default,,0000,0000,0000,,handshake in a rather abstract way. And\Ntheir proofs, specifically, they did not
Dialogue: 0,0:42:56.78,0:43:00.78,Default,,0000,0000,0000,,model retransmissions of handshake\Nmessages. And that's one of the things we
Dialogue: 0,0:43:00.78,0:43:06.31,Default,,0000,0000,0000,,abuse. So, on one hand we need to assure\Nthat we also look
Dialogue: 0,0:43:06.31,0:43:11.14,Default,,0000,0000,0000,,at the combinations of these different\Nentities, but we also need to assure that
Dialogue: 0,0:43:11.14,0:43:17.08,Default,,0000,0000,0000,,the abstract models that we use reflect\Nreality. Another thing that we can learn,
Dialogue: 0,0:43:17.08,0:43:21.69,Default,,0000,0000,0000,,is that we should keep the protocols and\Nalso the implementations simple.
Dialogue: 0,0:43:21.69,0:43:28.49,Default,,0000,0000,0000,,E.g., if we look at wpa_supplicant 2.6,\Nwhen we were studying this version
Dialogue: 0,0:43:28.49,0:43:34.60,Default,,0000,0000,0000,,ourself, we thought it wasn't vulnerable\Nto key reinstallation attacks. However,
Dialogue: 0,0:43:34.60,0:43:40.55,Default,,0000,0000,0000,,when we were notifying companies of the\Nvulnerabilities, another researcher found
Dialogue: 0,0:43:40.55,0:43:46.80,Default,,0000,0000,0000,,an attack against this version which did\Nwork. The reason we missed this attack
Dialogue: 0,0:43:46.80,0:43:52.78,Default,,0000,0000,0000,,against version 2.6, is because\Nwpa_supplicant uses a fairly complex
Dialogue: 0,0:43:52.78,0:43:57.60,Default,,0000,0000,0000,,implementation of the 4-way handshake\Nand the state machine is fairly complex to
Dialogue: 0,0:43:57.60,0:44:02.69,Default,,0000,0000,0000,,reason about. And there are two ways to\Ncombat this. The first is to keep the
Dialogue: 0,0:44:02.69,0:44:07.21,Default,,0000,0000,0000,,protocol simple. The second way to combat\Nthis, is to formally verify
Dialogue: 0,0:44:07.21,0:44:12.63,Default,,0000,0000,0000,,implementations. Now of course, we cannot\Nformally verify all the code, but what we
Dialogue: 0,0:44:12.63,0:44:17.41,Default,,0000,0000,0000,,can do is, really, these cryptographic\Nprotocols which play a very important
Dialogue: 0,0:44:17.41,0:44:23.95,Default,,0000,0000,0000,,role, at least we should pay enough\Nattention to that. What's also
Dialogue: 0,0:44:23.95,0:44:29.33,Default,,0000,0000,0000,,interesting, is that I encountered a\Ndocument of the CIA which also agrees, that
Dialogue: 0,0:44:29.33,0:44:34.22,Default,,0000,0000,0000,,complex implementations or protocols are\Nbad. Specifically, they have a document,
Dialogue: 0,0:44:34.22,0:44:39.77,Default,,0000,0000,0000,,where the CIA advises people how to\Nproperly implement backdoors, essentially,
Dialogue: 0,0:44:39.77,0:44:44.76,Default,,0000,0000,0000,,and they're saying that "Yeah, if you want\Nto send data back to us, of course, use
Dialogue: 0,0:44:44.76,0:44:48.97,Default,,0000,0000,0000,,encryption, but in that encryption\Nalgorithm, don't enable re-key
Dialogue: 0,0:44:48.97,0:44:53.45,Default,,0000,0000,0000,,functionality, because that enables\Nadditional features of the encryption
Dialogue: 0,0:44:53.45,0:44:58.86,Default,,0000,0000,0000,,algorithm. And these additional features,\Nthey cause unnecessary complexity and that
Dialogue: 0,0:44:58.86,0:45:05.03,Default,,0000,0000,0000,,generally leads to bugs." Another thing\Nthat we can learn, is that the standard
Dialogue: 0,0:45:05.03,0:45:10.56,Default,,0000,0000,0000,,needs to be specified rigorously and as\Nprecisely as possible. Because the
Dialogue: 0,0:45:10.56,0:45:17.50,Default,,0000,0000,0000,,original WPA2 standard, it was a bit fake.\NIt didn't really define a state machine.
Dialogue: 0,0:45:17.50,0:45:23.72,Default,,0000,0000,0000,,Well, the state machine that it defined\Nsays, what an implementation - sorry -
Dialogue: 0,0:45:23.72,0:45:30.36,Default,,0000,0000,0000,,should do if it receives a message, but -\Nlet's go back to the slides - but it
Dialogue: 0,0:45:30.36,0:45:35.27,Default,,0000,0000,0000,,doesn't define what an implementation\Nshould do when it receives an unexpected
Dialogue: 0,0:45:35.27,0:45:41.55,Default,,0000,0000,0000,,message. So, it doesn't define the order,\Nin which messages should be accepted. Now,
Dialogue: 0,0:45:41.55,0:45:46.76,Default,,0000,0000,0000,,there is an amendment of the Wi-Fi\Nstandard which better defines how and when
Dialogue: 0,0:45:46.76,0:45:52.82,Default,,0000,0000,0000,,to handle messages, but even that standard\Nis a bit fake. And I want to remark here
Dialogue: 0,0:45:52.82,0:45:58.43,Default,,0000,0000,0000,,that because the original WPA2 standard\Nwas a bit fake, I can forgive iOS and
Dialogue: 0,0:45:58.43,0:46:02.25,Default,,0000,0000,0000,,Windows for deviating a bit from the\Nstandard. Because the standard was
Dialogue: 0,0:46:02.25,0:46:08.75,Default,,0000,0000,0000,,difficult to interpret correctly. Now, on\Na bit of a related note, I want to briefly
Dialogue: 0,0:46:08.75,0:46:13.76,Default,,0000,0000,0000,,mention a workshop that we are organizing,\Nwhich is exactly about how to implement
Dialogue: 0,0:46:13.76,0:46:18.95,Default,,0000,0000,0000,,these security protocols properly, how to\Ne.g. fuzz security protocols, how
Dialogue: 0,0:46:18.95,0:46:23.62,Default,,0000,0000,0000,,to prove that they are correct, how to\Nmake sure that we specify them rigorously.
Dialogue: 0,0:46:23.62,0:46:30.07,Default,,0000,0000,0000,,So, if you are working in this field, do\Nconsider submitting to this. Now, the last
Dialogue: 0,0:46:30.07,0:46:35.50,Default,,0000,0000,0000,,thing that I want to mention on what we\Ncan learn from this research, is how we
Dialogue: 0,0:46:35.50,0:46:42.52,Default,,0000,0000,0000,,can coordinate the disclosure of a\Nvulnerability like this. Because this is
Dialogue: 0,0:46:42.52,0:46:45.73,Default,,0000,0000,0000,,not an ordinary vulnerability,\Nthat is, just affects one
Dialogue: 0,0:46:45.73,0:46:52.45,Default,,0000,0000,0000,,vendor, it really affects possibly every\NWi-Fi device that is around. So, how on
Dialogue: 0,0:46:52.45,0:46:56.88,Default,,0000,0000,0000,,earth are you going to start notifying\Ncompanies? Who are you going to notify?
Dialogue: 0,0:46:56.88,0:47:02.36,Default,,0000,0000,0000,,What would be the deadlines, and so on?\NWell, I'm going to discuss a bit about the
Dialogue: 0,0:47:02.36,0:47:07.75,Default,,0000,0000,0000,,strategy that we used, and what we used\Nfirst is... we first wanted to determine,
Dialogue: 0,0:47:07.75,0:47:12.47,Default,,0000,0000,0000,,you know, is this really a widespread\Nissue? We wanted to be sure of that before
Dialogue: 0,0:47:12.47,0:47:18.62,Default,,0000,0000,0000,,we started to notify a lot of companies.\NAnd the way we tackled that problem is, we
Dialogue: 0,0:47:18.62,0:47:25.04,Default,,0000,0000,0000,,first contacted a few selected vendors and\Nwe told them that "Hey, we possibly found
Dialogue: 0,0:47:25.04,0:47:30.63,Default,,0000,0000,0000,,this flaw in the WPA2 protocol, but we\Nweren't able to test your devices, but you
Dialogue: 0,0:47:30.63,0:47:36.21,Default,,0000,0000,0000,,should check this out." And quite quickly\Nwe got a few responses from vendors, saying
Dialogue: 0,0:47:36.21,0:47:41.96,Default,,0000,0000,0000,,that "Yes, we looked at your attack and\Nindeed, some of our devices are
Dialogue: 0,0:47:41.96,0:47:45.27,Default,,0000,0000,0000,,vulnerable," and this really confirmed to\Nus, that a device
Dialogue: 0,0:47:45.27,0:47:49.50,Default,,0000,0000,0000,,that we didn't test ourself was\Nvulnerable to the attack that we found.
Dialogue: 0,0:47:49.50,0:47:52.87,Default,,0000,0000,0000,,So, it confirmed that the issue is\Nwidespread, and we also got a bit of
Dialogue: 0,0:47:52.87,0:47:57.16,Default,,0000,0000,0000,,feedback on the report that we sent\Ntowards them on the description of our
Dialogue: 0,0:47:57.16,0:48:02.55,Default,,0000,0000,0000,,attack. So, at this point we were\Nconvinced ourselves, that this really was a
Dialogue: 0,0:48:02.55,0:48:07.87,Default,,0000,0000,0000,,flaw in the standard and that a lot of\Ncompanies will be affected. Then the next
Dialogue: 0,0:48:07.87,0:48:12.62,Default,,0000,0000,0000,,question we had is, "Okay, who are we now\Nall going to notify?" We of course
Dialogue: 0,0:48:12.62,0:48:16.24,Default,,0000,0000,0000,,notified the big names and the big\Ncompanies, but who else do we have to
Dialogue: 0,0:48:16.24,0:48:22.81,Default,,0000,0000,0000,,notify? And at this point, our tactic was\Nto rely on a CERT team, specifically a
Dialogue: 0,0:48:22.81,0:48:28.68,Default,,0000,0000,0000,,CERT from the US and they did all the\Ncoordination for us.
Dialogue: 0,0:48:28.68,0:48:33.76,Default,,0000,0000,0000,,But one other thing that you can do is,\Nthat if you're not sure who all is
Dialogue: 0,0:48:33.76,0:48:38.69,Default,,0000,0000,0000,,affected or what, who all the vendors are,\Nthen you can just ask a vendor that you
Dialogue: 0,0:48:38.69,0:48:42.76,Default,,0000,0000,0000,,contacted already for other\Nvendors, that also might be affected
Dialogue: 0,0:48:42.76,0:48:48.79,Default,,0000,0000,0000,,by the bug that you found, e.g.\NNow one thing that is more difficult here,
Dialogue: 0,0:48:48.79,0:48:55.58,Default,,0000,0000,0000,,is that on one hand you want to notify as\Nmuch vendors as possibly, on the other hand
Dialogue: 0,0:48:55.58,0:49:01.26,Default,,0000,0000,0000,,you also can't notify everyone because if\Nyou are going to notify everyone, then the
Dialogue: 0,0:49:01.26,0:49:10.45,Default,,0000,0000,0000,,chance of the details leaking, they become\Nclose to one. Another difficult thing to
Dialogue: 0,0:49:10.45,0:49:15.58,Default,,0000,0000,0000,,decide is, how long should you give time to\Ncompanies in order to patch this. And again,
Dialogue: 0,0:49:15.58,0:49:23.11,Default,,0000,0000,0000,,here you're mixed between two decisions:\Non one hand you can give give them a long
Dialogue: 0,0:49:23.11,0:49:27.95,Default,,0000,0000,0000,,period to patch everything, but then again,\Nthe risk of this details leasing... err,
Dialogue: 0,0:49:27.95,0:49:33.30,Default,,0000,0000,0000,,leaking increase. On the other hand, if the\Nembargo period is too short, people won't
Dialogue: 0,0:49:33.30,0:49:36.95,Default,,0000,0000,0000,,have time to patch it. So this is quite a\Nhard decision. In the end,
Dialogue: 0,0:49:36.95,0:49:42.31,Default,,0000,0000,0000,,what we did is - and which I would\Nagain do in the future - is, it's hard to
Dialogue: 0,0:49:42.31,0:49:47.49,Default,,0000,0000,0000,,pick a deadline, but still do pick a\Ndeadline to avoid any uncertainty and so
Dialogue: 0,0:49:47.49,0:49:54.30,Default,,0000,0000,0000,,that people know, what to expect. And\Nfinally, I want to thank CERT and ICASI
Dialogue: 0,0:49:54.30,0:49:59.96,Default,,0000,0000,0000,,for helping with the coordination and you\Nalso want to thank Cisco for some of the
Dialogue: 0,0:49:59.96,0:50:05.70,Default,,0000,0000,0000,,advice that they give.\NSo, with that I can conclude the talk, so
Dialogue: 0,0:50:05.70,0:50:11.98,Default,,0000,0000,0000,,what we discussed, is a flaw and the WPA2\Nstandard itself and the most surprising
Dialogue: 0,0:50:11.98,0:50:17.77,Default,,0000,0000,0000,,thing about this research is, that WPA2 was\Nproven to be correct, yet we still found
Dialogue: 0,0:50:17.77,0:50:23.04,Default,,0000,0000,0000,,his attack after more than a decade.\NAnd more than that, not only is this just a
Dialogue: 0,0:50:23.04,0:50:27.88,Default,,0000,0000,0000,,theoretical attack, the attack has actual\Nimpact and practice.
Dialogue: 0,0:50:27.88,0:50:32.74,Default,,0000,0000,0000,,And finally, in order to defend against\Nthis, you should update all your clients
Dialogue: 0,0:50:32.74,0:50:38.22,Default,,0000,0000,0000,,and also check if your access points are\Naffected. So with that, thank you for your
Dialogue: 0,0:50:38.22,0:50:41.36,Default,,0000,0000,0000,,attention and if there are any questions,\Nfeel free to ask.
Dialogue: 0,0:50:41.36,0:50:50.51,Default,,0000,0000,0000,,{\i1}applause{\i0}\N
Dialogue: 0,0:50:50.51,0:50:52.65,Default,,0000,0000,0000,,Herald: So, do we have any questions?
Dialogue: 0,0:50:52.65,0:50:57.76,Default,,0000,0000,0000,,There is mics everywhere, so please come\Nin front. And I think, we already have the
Dialogue: 0,0:50:57.76,0:51:01.77,Default,,0000,0000,0000,,first question directly here in front on\Nmic number 1.
Dialogue: 0,0:51:01.77,0:51:11.54,Default,,0000,0000,0000,,Mic1: You mentioned, that GCMP is most\Nvulnerable. Do you know if there's any
Dialogue: 0,0:51:11.54,0:51:18.30,Default,,0000,0000,0000,,standardization going on, about switching\Nto nonce misuse resistant scheme like
Dialogue: 0,0:51:18.30,0:51:28.10,Default,,0000,0000,0000,,AES-GCM, Synthetic Initialization Vector?\NMV: Yes, so there have been
Dialogue: 0,0:51:28.10,0:51:33.71,Default,,0000,0000,0000,,some proposals in order to make the\Nencryption algorithm defend against nonce
Dialogue: 0,0:51:33.71,0:51:40.02,Default,,0000,0000,0000,,reuse. Now the impression I have, that this\Nis still a bit of ongoing research. So
Dialogue: 0,0:51:40.02,0:51:45.45,Default,,0000,0000,0000,,there are proposals, where you have an\Nalgorithm that you can use, but I'm not
Dialogue: 0,0:51:45.45,0:51:50.64,Default,,0000,0000,0000,,aware of actual encryption protocols, e.g.\NTLS or Wi-Fi, that are using them.
Dialogue: 0,0:51:50.64,0:51:54.79,Default,,0000,0000,0000,,But they exist, but I... they're not yet being\Nreally used.
Dialogue: 0,0:51:54.79,0:52:02.92,Default,,0000,0000,0000,,Mic1: It is standardisation going on in\NCFRG, so Crypto Forum Research Group in
Dialogue: 0,0:52:02.92,0:52:10.60,Default,,0000,0000,0000,,IETF standardization, but I was asking about\NWi-Fi standardization, if they are planning
Dialogue: 0,0:52:10.60,0:52:20.23,Default,,0000,0000,0000,,to use this? And [a] related question would be,\Nif you would use in AES-GCM instead of
Dialogue: 0,0:52:20.23,0:52:30.50,Default,,0000,0000,0000,,the deterministic initialization vector,\Nthere's a random IV possible, if you use
Dialogue: 0,0:52:30.50,0:52:38.85,Default,,0000,0000,0000,,96 bit, then the impact wouldn't be\Nbounded.
Dialogue: 0,0:52:38.85,0:52:45.03,Default,,0000,0000,0000,,MV: So to answer the first question: I'm\Nnot aware of the Wi-Fi standard
Dialogue: 0,0:52:45.03,0:52:51.73,Default,,0000,0000,0000,,from really modifying the standard to use\Na nonce misuse resistant encryption
Dialogue: 0,0:52:51.73,0:52:57.34,Default,,0000,0000,0000,,cipher. They are modifying the standard to\Ndefend against key reinstallation attacks,
Dialogue: 0,0:52:57.34,0:53:00.82,Default,,0000,0000,0000,,but I think they're not yet going to\Nincorporate a nonce misuse resistant
Dialogue: 0,0:53:00.82,0:53:05.43,Default,,0000,0000,0000,,encryption cipher, because they still have\Nthe impression that they're going to wait
Dialogue: 0,0:53:05.43,0:53:11.76,Default,,0000,0000,0000,,probably a while and once that technology\Nis more mature they're going to use that.
Dialogue: 0,0:53:11.76,0:53:15.90,Default,,0000,0000,0000,,If I understood your second question, you\Nalso have encryption algorithms, where you
Dialogue: 0,0:53:15.90,0:53:20.55,Default,,0000,0000,0000,,don't have deterministic nonce, but you\Nhave a nonce, which for every encryption
Dialogue: 0,0:53:20.55,0:53:27.56,Default,,0000,0000,0000,,operation e.g. is random.\NMic1: Actually in the GCM standard there
Dialogue: 0,0:53:27.56,0:53:32.47,Default,,0000,0000,0000,,are two possibilities: one deterministic,\NMV: Yeah.
Dialogue: 0,0:53:32.47,0:53:38.27,Default,,0000,0000,0000,,Mic1: and the second random.\NMV: So the risk of using a random
Dialogue: 0,0:53:38.27,0:53:43.13,Default,,0000,0000,0000,,initialization vector is, that you may\Nhave a bad random generator,
Dialogue: 0,0:53:43.13,0:53:52.01,Default,,0000,0000,0000,,that it can go wrong there. On that, that\Nyou still have nonce reuse, so even with a
Dialogue: 0,0:53:52.01,0:53:56.68,Default,,0000,0000,0000,,randomly generated nonce it can\Nalso go bad, but then there are different
Dialogue: 0,0:53:56.68,0:54:02.05,Default,,0000,0000,0000,,attacks. And I think, there has been a\Npaper that analyzes a certain TLS
Dialogue: 0,0:54:02.05,0:54:07.21,Default,,0000,0000,0000,,libraries, where they do find attacks, where\Nin that case the GCM algorithm can still
Dialogue: 0,0:54:07.21,0:54:11.93,Default,,0000,0000,0000,,be attacked, not through key reinstallation\Nattacks, but because there is, because
Dialogue: 0,0:54:11.93,0:54:15.78,Default,,0000,0000,0000,,basically the nonce isn't really random,\Ne.g. sometimes a bad implementation
Dialogue: 0,0:54:15.78,0:54:21.07,Default,,0000,0000,0000,,always uses the same random nonce.\NPerson X: Um, direct answer...
Dialogue: 0,0:54:21.07,0:54:22.61,Default,,0000,0000,0000,,Herald: Err, sorry,...\NX: Direct answer to his question number
Dialogue: 0,0:54:22.61,0:54:30.59,Default,,0000,0000,0000,,one: because he asked, whether there's\Nright now an approach to modify the
Dialogue: 0,0:54:30.59,0:54:38.34,Default,,0000,0000,0000,,standard towards being resistant against\Nthis attack, right now there is no IEEE
Dialogue: 0,0:54:38.34,0:54:46.17,Default,,0000,0000,0000,,task group working on an amendment which\Nwill fix this.
Dialogue: 0,0:54:46.17,0:54:50.91,Default,,0000,0000,0000,,MV: Well, there is... they are working to \Nprevent the key reinstallation attack.
Dialogue: 0,0:54:50.91,0:54:54.32,Default,,0000,0000,0000,,X: Well, there is no official\Nactive task group right now.
Dialogue: 0,0:54:54.32,0:54:57.03,Default,,0000,0000,0000,,MV: Okay that could be, but there are still\Npeople working on that.
Dialogue: 0,0:54:57.03,0:54:58.98,Default,,0000,0000,0000,,X: Yeah, they're working on that,\Nbut no
Dialogue: 0,0:54:58.98,0:55:00.60,Default,,0000,0000,0000,,task group, right?\NMV: Ok. Thank you.
Dialogue: 0,0:55:00.60,0:55:03.40,Default,,0000,0000,0000,,Herald: Okay thank you.\NHere in number 3.
Dialogue: 0,0:55:03.40,0:55:07.51,Default,,0000,0000,0000,,Mic3: Yes, thanks for your\Namazing talk.
Dialogue: 0,0:55:07.51,0:55:11.32,Default,,0000,0000,0000,,Just for my personal understanding:\Ncould you briefly go back to
Dialogue: 0,0:55:11.32,0:55:17.37,Default,,0000,0000,0000,,the slide with the 4-way\Nhandshake, like, right in the beginning?
Dialogue: 0,0:55:17.37,0:55:21.01,Default,,0000,0000,0000,,MV: Yup, so the attack or the handshake\Nitself?
Dialogue: 0,0:55:21.01,0:55:28.77,Default,,0000,0000,0000,,Mic3: Yeah, yeah the attack.\NMV: So let's go to this slide.
Dialogue: 0,0:55:28.77,0:55:37.27,Default,,0000,0000,0000,,Mic3: Yeah so all you get from this, is the\Nkeystream that is used to encrypt
Dialogue: 0,0:55:37.27,0:55:41.88,Default,,0000,0000,0000,,the the Msg4, right,\Nthat's all you get?
Dialogue: 0,0:55:41.88,0:55:45.55,Default,,0000,0000,0000,,MV: Yes, but you can already use that to\Nstart decrypting frames and what you can
Dialogue: 0,0:55:45.55,0:55:51.48,Default,,0000,0000,0000,,do as an attacker, you have several options.\NThe first thing you can do is, you can keep
Dialogue: 0,0:55:51.48,0:55:54.96,Default,,0000,0000,0000,,triggering new handshakes by\Ndeauthenticating the client, so you can
Dialogue: 0,0:55:54.96,0:56:02.94,Default,,0000,0000,0000,,always decrypt one packet at a time.\NWhat you can also do is, you can wait with
Dialogue: 0,0:56:02.94,0:56:09.09,Default,,0000,0000,0000,,sending this retransmitted Msg3\Nto the clients, because sometimes you know
Dialogue: 0,0:56:09.09,0:56:12.09,Default,,0000,0000,0000,,the encrypted data that is sent. So you\Nknow that a packet is an ARP request, you
Dialogue: 0,0:56:12.09,0:56:16.65,Default,,0000,0000,0000,,know that the HTTP requests. You can capture\Nquite some packets where you know the
Dialogue: 0,0:56:16.65,0:56:22.37,Default,,0000,0000,0000,,content, to derive some known key stream\Nand once you have that, you can forward
Dialogue: 0,0:56:22.37,0:56:27.78,Default,,0000,0000,0000,,Msg3 to trigger a key\Nreinstallation and then you have collected
Dialogue: 0,0:56:27.78,0:56:33.83,Default,,0000,0000,0000,,quite some key stream to be able to\Ndecrypt several packets at a time. So you
Dialogue: 0,0:56:33.83,0:56:38.91,Default,,0000,0000,0000,,can use tactics like that, you can rely on\Nthe packet length to basically determine,
Dialogue: 0,0:56:38.91,0:56:43.77,Default,,0000,0000,0000,,what the type of packet is, where you have\Nknown plaintext and you can use that to
Dialogue: 0,0:56:43.77,0:56:47.78,Default,,0000,0000,0000,,derive new key stream and there are a lot\Nof ways to play around with that.
Dialogue: 0,0:56:47.78,0:56:51.68,Default,,0000,0000,0000,,Mic3: Yeah but, all you get here is the -\Nbecause the key stream that you get is
Dialogue: 0,0:56:51.68,0:56:59.63,Default,,0000,0000,0000,,already being used immediately, because\Nit's being used to encrypt Msg4.
Dialogue: 0,0:56:59.63,0:57:02.94,Default,,0000,0000,0000,,MV: Well, we know the content of Msg4
Dialogue: 0,0:57:02.94,0:57:08.55,Default,,0000,0000,0000,,and we abuse, that Msg4 is\Nencrypted to derive known key stream and
Dialogue: 0,0:57:08.55,0:57:14.13,Default,,0000,0000,0000,,we can then use that to encrypt data\Nframes, which we do not know and... we
Dialogue: 0,0:57:14.13,0:57:15.74,Default,,0000,0000,0000,,should discuss this offline.\NMic3: Yeah.
Dialogue: 0,0:57:15.74,0:57:19.85,Default,,0000,0000,0000,,Herald: Perhaps this is for later\Ndiscussion with more in detail. Now we
Dialogue: 0,0:57:19.85,0:57:24.75,Default,,0000,0000,0000,,switch to number two... number four, I\Nthink it is. Yeah, thanks.
Dialogue: 0,0:57:24.75,0:57:30.94,Default,,0000,0000,0000,,Mic4: Yes. Great find really and an\Nawesome talk. Could you maybe elaborate a
Dialogue: 0,0:57:30.94,0:57:38.10,Default,,0000,0000,0000,,bit on how to still use the advantage of\Nformal verification in the sense of, let's
Dialogue: 0,0:57:38.10,0:57:44.33,Default,,0000,0000,0000,,say, the flaws that it has, it gives a very\Nfalse sense of security in your sense, how
Dialogue: 0,0:57:44.33,0:57:48.99,Default,,0000,0000,0000,,can you still benefit from formal\Nverification?
Dialogue: 0,0:57:48.99,0:57:55.54,Default,,0000,0000,0000,,MV: Well, I think the attitude we should\Nadopt is, that formal verification of code
Dialogue: 0,0:57:55.54,0:58:01.67,Default,,0000,0000,0000,,or of algorithms increases the amount of\Ntrust we can put into a program or into a
Dialogue: 0,0:58:01.67,0:58:07.45,Default,,0000,0000,0000,,protocol, but it's not just because it's\Nformally verified that it's secure.
Dialogue: 0,0:58:07.45,0:58:12.27,Default,,0000,0000,0000,,Perhaps one of the attitudes that people\Nhad was: 'oh it's firmly verified, it must
Dialogue: 0,0:58:12.27,0:58:17.84,Default,,0000,0000,0000,,be fine'. We should abandon that attitude\Nand instead we should say: "Ok, it's
Dialogue: 0,0:58:17.84,0:58:21.75,Default,,0000,0000,0000,,formally verified but, you know, let's\Ncheck if the model they used reflects
Dialogue: 0,0:58:21.75,0:58:28.48,Default,,0000,0000,0000,,reality. Let's see if the proof is correct"\Nand so on. So, we should still employ a
Dialogue: 0,0:58:28.48,0:58:33.47,Default,,0000,0000,0000,,formal verification but we should just\Ntreat it as additional evidence, that
Dialogue: 0,0:58:33.47,0:58:41.54,Default,,0000,0000,0000,,something looks secure.\NHerald: Ok, there's another question on mic 2
Dialogue: 0,0:58:41.54,0:58:47.25,Default,,0000,0000,0000,,Mic2: The first part is on the slide\Nyou're currently on. As far as I
Dialogue: 0,0:58:47.25,0:58:52.88,Default,,0000,0000,0000,,understood it in the talk, the\Nretransmission of Msg4 is not
Dialogue: 0,0:58:52.88,0:58:56.86,Default,,0000,0000,0000,,supposed to be encrypted by the standard.\NMV: Correct.
Dialogue: 0,0:58:56.86,0:59:02.24,Default,,0000,0000,0000,,Mic2: So if you follow the standards, you\Nshouldn't have a problem here.
Dialogue: 0,0:59:02.24,0:59:05.63,Default,,0000,0000,0000,,MV: No, then you still have a problem,\Nbecause what you can then you do, is just
Dialogue: 0,0:59:05.63,0:59:10.00,Default,,0000,0000,0000,,wait for a data packet where you know that\Ncontents of, e.g.it can be an ARP
Dialogue: 0,0:59:10.00,0:59:14.66,Default,,0000,0000,0000,,request, you can derive most fields of\Nthat, it can be a DHCP request, it can be
Dialogue: 0,0:59:14.66,0:59:22.10,Default,,0000,0000,0000,,be a TCP SYN packet, or it can be some\Nplain text HTML frames. E.g. there
Dialogue: 0,0:59:22.10,0:59:28.77,Default,,0000,0000,0000,,has been work to fingerprint the length of\NHTTP requests, to be able to determine
Dialogue: 0,0:59:28.77,0:59:32.44,Default,,0000,0000,0000,,which page you are visiting, so purely\Nbased on the length, we can determine the
Dialogue: 0,0:59:32.44,0:59:37.26,Default,,0000,0000,0000,,contents of the website you are looking\Nfor. We can then derive known plaintext
Dialogue: 0,0:59:37.26,0:59:44.02,Default,,0000,0000,0000,,and basically there are a lot of ways to\Npredict the content of a frame, to then
Dialogue: 0,0:59:44.02,0:59:51.75,Default,,0000,0000,0000,,derive known keystream and to then trigger\Na key reinstallation attack to then abuse this.
Dialogue: 0,0:59:51.75,0:59:55.19,Default,,0000,0000,0000,,Herald: Ok we have time for one last\Nquestion. Mic number 1?
Dialogue: 0,0:59:55.19,1:00:04.73,Default,,0000,0000,0000,,Mic1: Um, so as far as I understood your\Nresearch, and so we, if we have like 11W
Dialogue: 0,1:00:04.73,1:00:11.24,Default,,0000,0000,0000,,deployed in the network, we are still\Nvulnerable to the attack, because as 11W
Dialogue: 0,1:00:11.24,1:00:19.59,Default,,0000,0000,0000,,specifies the encryption, I'm supposed by\Nthis amendment, is also done by the
Dialogue: 0,1:00:19.59,1:00:28.02,Default,,0000,0000,0000,,encryption use on the network like before,\Nso 11W is not really a way to secure
Dialogue: 0,1:00:28.02,1:00:33.69,Default,,0000,0000,0000,,the network?\NMV: Well, if I got it right, 11W is, one of
Dialogue: 0,1:00:33.69,1:00:36.38,Default,,0000,0000,0000,,the things it does, is protect the\Nmanagement's frames, if I'm correct?
Dialogue: 0,1:00:36.38,1:00:39.12,Default,,0000,0000,0000,,Mic1: Yes.\NMV: Yes.
Dialogue: 0,1:00:39.12,1:00:44.62,Default,,0000,0000,0000,,MV: So using that does not defend against\Nthese attacks.
Dialogue: 0,1:00:44.62,1:00:50.71,Default,,0000,0000,0000,,Herald: Ok, I think there's still quite\Ndetails, where people are curious about,
Dialogue: 0,1:00:50.71,1:00:55.16,Default,,0000,0000,0000,,because it's everybody starting this\Nquestion "as far as I understood". So I think,
Dialogue: 0,1:00:55.16,1:00:58.84,Default,,0000,0000,0000,,this was a really nice comprehensive talk\Nand I want to thank you. And everybody who
Dialogue: 0,1:00:58.84,1:01:03.66,Default,,0000,0000,0000,,has more questions, perhaps can find you\Nhere and ask you more or have a look into
Dialogue: 0,1:01:03.66,1:01:06.99,Default,,0000,0000,0000,,the paper, perhaps read everything in\Ndetail there.
Dialogue: 0,1:01:06.99,1:01:11.54,Default,,0000,0000,0000,,So, please another big round of applause\Nfor Mathy and his amazing talk!
Dialogue: 0,1:01:11.54,1:01:13.28,Default,,0000,0000,0000,,Thank you very much.\NMV: Thank you!
Dialogue: 0,1:01:13.28,1:01:20.51,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,1:01:20.51,1:01:26.10,Default,,0000,0000,0000,,{\i1}34c3 outro{\i0}
Dialogue: 0,1:01:26.10,1:01:41.86,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2018. Join, and help us!