Return to Video

34C3 - KRACKing WPA2 by Forcing Nonce Reuse

  • 0:00 - 0:17
    34c3 intro
  • 0:17 - 0:24
    Herald: I'm really happy to be able to
    introduce our next speaker. Mathy is a
  • 0:24 - 0:30
    postdoc in Network Security and Applied
    Crypto. He took part in discovering and
  • 0:30 - 0:36
    implementing quite some attacks in this
    field and especially in the wireless
  • 0:36 - 0:43
    sector. And today he will show us, that all
    our Wi-Fi devices are vulnerable.
  • 0:43 - 0:49
    Especially the ones with Linux and
    Android. So, I don't want to go into the
  • 0:49 - 0:53
    technical details, because he would do
    this and I think if you're interested in
  • 0:53 - 0:58
    even learning more about it, he even linked
    the research paper as well as the scripts
  • 0:58 - 1:04
    and a website for this attack in the
    Fahrplan. So for now, give a big round of
  • 1:04 - 1:07
    applause for Mathy Vanhoef!
  • 1:07 - 1:12
    applause
  • 1:12 - 1:16
    Mathy Vanhoef: Ok, thank you for the
    introduction and thank you all for
  • 1:16 - 1:20
    attending the talk, even though it's
    already a bit late in the evening. Thank
  • 1:20 - 1:25
    you CCC for allowing me to speak here. So
    today I'm going to talk about my research
  • 1:25 - 1:31
    on WPA2 and you probably have already
    heard about this under the name of KRACK
  • 1:31 - 1:38
    attacks. Now, the history of this research
    is quite interesting, because during my PhD,
  • 1:38 - 1:44
    I was already researching the security of
    wireless networks and during my PhD
  • 1:44 - 1:51
    defense last year, when I was finishing up
    on writing my thesis, one of the jury
  • 1:51 - 1:57
    members in my PhD asked: "Hey, you're
    recommending WPA2 with AES in your thesis,
  • 1:57 - 2:03
    but are you sure that's really a secure
    solution?" And last year my answer was:
  • 2:03 - 2:08
    "Yeah, I mean it seems secure. It has been
    around for more than a decade and if we
  • 2:08 - 2:12
    ignore some brute-force attacks against
    the password, if you select a secure
  • 2:12 - 2:17
    password, then there are no real weaknesses
    that are known. On top of that, there are
  • 2:17 - 2:21
    also mathematical proofs that state that
    if you have the 4-way handshake on the
  • 2:21 - 2:27
    encryption algorithm, that it's supposed to
    be secure. Unfortunately, a year later I
  • 2:27 - 2:33
    was staring at some OpenBSD code. In
    particular, I was looking at this function
  • 2:33 - 2:39
    called ic_set_key. The details aren't
    important here yet, but this key installs
  • 2:39 - 2:44
    the encryption key for use by the driver,
    so frames get encrypted and I was
  • 2:44 - 2:48
    wondering, what
    would happen if this function is called
  • 2:48 - 2:53
    twice. And I was thinking, like, will it
    reinstall the key and what will happen
  • 2:53 - 2:58
    when you reinstall the key? And it turns
    out that answering this question led to
  • 2:58 - 3:07
    the attack I found and as you know by now,
    this uncovered the flaw in WPA2. So in a
  • 3:07 - 3:14
    sense, this talk is all about how I gave
    the wrong answer during my PhD defense. To
  • 3:14 - 3:20
    explain the attack, I will illustrate it
    against the 4-way handshake. After that I
  • 3:20 - 3:24
    will discuss the impact of the attack in
    practice, then I will go over some
  • 3:24 - 3:29
    common misconceptions that have been
    floating around the internet and finally I
  • 3:29 - 3:32
    will discuss some lessons that we can
    learn from this
  • 3:32 - 3:38
    research and from our findings. Let's get
    started with explaining the attack against
  • 3:38 - 3:42
    the 4-way handshake and the first
    question I have to answer here is: what
  • 3:42 - 3:49
    exactly is this 4-way handshake? And the
    4-way handshake is executed whenever
  • 3:49 - 3:53
    you connect to a protected Wi-Fi network.
    It's used when you connect to your home
  • 3:53 - 3:57
    Wi-Fi network where you just have a pre-
    shared password, but it's also used in
  • 3:57 - 4:02
    enterprise network-networks where you for
    example have a username and a password to
  • 4:02 - 4:06
    log in.
    The purpose of this handshake is to verify
  • 4:06 - 4:11
    that you possess the correct credentials
    in order to connect to the network and at
  • 4:11 - 4:15
    the same time, this 4-way handshake
    negotiates a fresh session key that will
  • 4:15 - 4:20
    be used to encrypt data frames.
    This session key is called the PTK, the
  • 4:20 - 4:28
    pairwise temporal key. And as I mentioned,
    this handshake seemed to be really secure
  • 4:28 - 4:34
    because for over a decade, no attacks have
    been found against it, assuming that a
  • 4:34 - 4:40
    secure password is being used, and on top
    of that, the 4-way handshake was
  • 4:40 - 4:44
    formally proven to be secure and the
    encryption algorithm that is used after
  • 4:44 - 4:49
    the 4-way handshake, which generally
    is AES CCMP, that was also formally
  • 4:49 - 4:54
    proven to be secure.
    Yet somehow we did find an attack even
  • 4:54 - 4:57
    though we have all these formal proofs,
    even though this protocol has been around
  • 4:57 - 5:01
    for that long. So what went
    wrong?
  • 5:01 - 5:08
    To explain this, I'm going to explain how
    the 4-way handshake works, using this
  • 5:08 - 5:13
    specific example. So let's say, we have the
    client on the right here that wants to
  • 5:13 - 5:18
    connect to the access point on the left.
    Now, in order to start the 4-way
  • 5:18 - 5:22
    handshake, there first needs to be some
    preshared secrets between the client on
  • 5:22 - 5:27
    the access point and if you have a network
    at home, this preshared secret is basically
  • 5:27 - 5:31
    the password of the network. But if you
    have an enterprise or a more professional
  • 5:31 - 5:36
    network, then - where you for example have
    to log in using a username and a password -
  • 5:36 - 5:42
    then first 802.1x authentication algorithm
    is executed, which in practice is commonly
  • 5:42 - 5:47
    some form of RADIUS authentication.
    The details of that are not important.
  • 5:47 - 5:51
    What's important here is the result.
    Namely, after this authentication phase
  • 5:51 - 5:56
    there is a shared secret between the
    client and the access point.
  • 5:56 - 6:01
    And once we have this shared secret, we
    can execute the 4-way handshake. What
  • 6:01 - 6:07
    the first two messages in the 4-way
    handshake do, is they transport a random
  • 6:07 - 6:11
    number between both devices.
    So in particular, the access point will
  • 6:11 - 6:16
    generate a random number called the access
    point nonce, the ANonce, and it will
  • 6:16 - 6:20
    transport that to the client.
    Then in reaction to that, the client will
  • 6:20 - 6:24
    generate its own random number called the
    supplicant nonce - and supplicant is
  • 6:24 - 6:29
    basically a synonym for client - and it
    will send that random number, the SNonce,
  • 6:29 - 6:37
    to the access point in the second message
    of the handshake. Once both devices have
  • 6:37 - 6:42
    each other's random number, then we can
    derive this unique per session key.
  • 6:42 - 6:47
    How that key is derived, is fairly simple: we
    take the preshared key, that is known
  • 6:47 - 6:52
    between these two devices, we combine that
    with both of these random numbers and the
  • 6:52 - 6:57
    result is the PTK, this fresh encryption
    key, that will later be used to encrypt
  • 6:57 - 7:03
    data frames.
    Now, I want to clarify one thing, and you
  • 7:03 - 7:08
    might have heard about this research under
    the name 'key reinstallation attacks:
  • 7:08 - 7:14
    forcing nonce reuse in WPA2'.
    I want to highlight here that the nonce
  • 7:14 - 7:18
    reuse does not refer to the nonce reuse
    about the ANonce or SNonce during the
  • 7:18 - 7:22
    4-way handshake. So here we're going [to]
    assume, that these ANonce and SNonce, that
  • 7:22 - 7:27
    they are random and not predictable. The
    nonce reuse refers to nonce reuse that
  • 7:27 - 7:34
    will happen during the encryption
    algorithm, which I will explain in a bit.
  • 7:34 - 7:40
    That's it for the first stage of the 4-way
    handshake. The second stage of the 4-way
  • 7:40 - 7:47
    handshake, a bit simplified, it basically
    confirms that both parties negotiate at
  • 7:47 - 7:52
    the same PTK, the same encryption key. And
    in particular, the access point will send
  • 7:52 - 7:57
    Message 3 to the client. The client will
    verify the authenticity of that frame and
  • 7:57 - 8:04
    if everything looks ok, the client will
    reply using Msg4 to the access point.
  • 8:04 - 8:09
    Once these four messages have been
    exchanged, both the client on the access
  • 8:09 - 8:16
    point will install the PTK for use by the
    driver, so now data frames can be exchanged
  • 8:16 - 8:22
    and these data frames will be encrypted.
    Ok, so now we covered the 4-way
  • 8:22 - 8:29
    handshake, we know the highlight of how it
    works. Now the final thing I need to
  • 8:29 - 8:35
    explain, before we can get to the details
    of the attack, is: How does encryption work
  • 8:35 - 8:40
    in a Wi-Fi network? And to explain this,
    let's take the example here, where we want
  • 8:40 - 8:45
    to send some plain text data from, e.g.,
    from the client to the access
  • 8:45 - 8:49
    point. Then the first thing that will
    happen, is that we will take the PTK and
  • 8:49 - 8:53
    the fresh session key, that the 4-way
    handshake just negotiated and we will
  • 8:53 - 9:00
    combine that with a packet number. And here,
    this packet number is called a nonce.
  • 9:00 - 9:05
    The packet number is incremented by 1 for
    every frame, that is transmitted and the ID
  • 9:05 - 9:10
    here is, that by combining the session key
    with the packet number we get a unique per
  • 9:10 - 9:16
    packet key for every packet that we want
    to transmit.
  • 9:16 - 9:20
    The way the encryption now works is fairly
    simple, we feed this per packet key as
  • 9:20 - 9:26
    input to a stream cipher. We get us output
    some key stream, we simply XOR that key
  • 9:26 - 9:32
    stream with the plaintext and the result
    is the encrypted data, the ciphertext.
  • 9:32 - 9:37
    Now we prepense a plaintext header with
    some metadata and also the packet number,
  • 9:37 - 9:40
    the nonce value, that we used, so the
    receiver will be able to decrypt the
  • 9:40 - 9:46
    packet. Essentially, this is just a stream
    cipher, where a nonce is used to always
  • 9:46 - 9:53
    derive a unique per packet key. Now there's
    one essential requirements in this
  • 9:53 - 9:58
    encryption key.
    That is, that under a particular session
  • 9:58 - 10:04
    key, a nonce value should only be used once,
    because if you ever reuse a nonce value,
  • 10:04 - 10:08
    you will generate the same per packet key.
    You will generate the same key stream and
  • 10:08 - 10:12
    this will allow you to decrypt packets,
    that are sent and depending on the
  • 10:12 - 10:19
    specific stream cipher that is being used,
    it will also allow you to forge frames.
  • 10:19 - 10:21
    clears his throat
  • 10:21 - 10:28
    Now the question here is: Is this nonce
    value indeed only used once? And we already
  • 10:28 - 10:32
    know, that it is incremented by one for
    every packet that is transmitted, so the
  • 10:32 - 10:37
    only question that remains is: To what
    value is this packet number initialized?
  • 10:37 - 10:44
    And the answer is quite simple: when the
    PTK is installed, this transmit nonce is
  • 10:44 - 10:49
    initialized to 0.
    At first sight, this makes a lot of sense.
  • 10:49 - 10:54
    I mean, you initiate that number to 0,
    you increment it by one for every packet,
  • 10:54 - 11:01
    so surely this nonce is a specific nonce
    value, is only used once.
  • 11:01 - 11:07
    Unfortunately, this is not the case. And the
    reason this nonce value or a particular
  • 11:07 - 11:12
    nonce value is sometimes used more than
    once, is because we can force
  • 11:12 - 11:18
    reinstallations of the PTK and those
    reinstallations will again reset the nonce
  • 11:18 - 11:24
    to 0 and then nonce value will be reused.
    So, how can we force these key
  • 11:24 - 11:29
    reinstallations as an attacker?
    Let's again take the example where we have
  • 11:29 - 11:35
    a client on the left, that wants to connect
    to the access point on the right and in
  • 11:35 - 11:39
    this case, we also have an attacker that
    sits in the middle and this attacker will
  • 11:39 - 11:45
    assume a so-called channel-based man-in-
    the-middle position and in this-man-in-the-
  • 11:45 - 11:51
    middle position, the adversary isn't yet
    able to decrypt any packets. This man-in-
  • 11:51 - 11:56
    the-middle position is purely there, so we
    can reliably block packets from arriving
  • 11:56 - 12:02
    and we can reorder the packet and so on. We
    are not breaking encryption yet. And the
  • 12:02 - 12:07
    way we obtain this man-in-the-middle
    position is, we simply take all the frames
  • 12:07 - 12:11
    that the access point which, e.g.,
    is on Channel 6, we take all the frames
  • 12:11 - 12:16
    that it is broadcasting and as an attacker,
    we capture them and we rebroadcast them, we
  • 12:16 - 12:21
    retransmit them on a different channel,
    e.g. Channel 1. So we are effectively
  • 12:21 - 12:27
    cloning the real access point on a rogue
    channel and then we force the victim into
  • 12:27 - 12:31
    connecting to this rogue access point on
    this different channel.
  • 12:31 - 12:36
    So let's assume now that the attacker
    obtains this position, this man-in-the-
  • 12:36 - 12:43
    middle position and the first stage of the
    4-way handshake, we don't modify any
  • 12:43 - 12:49
    frames at all. So e.g. if the
    client is using 802.1x authentication, we
  • 12:49 - 12:53
    simply forward all the frames between
    these two different channels and we do the
  • 12:53 - 12:57
    same thing with the first three messages
    of the 4-way handshake, we simply
  • 12:57 - 13:04
    forward them unmodified. Where the attack
    starts, is if the client sends Msg4
  • 13:04 - 13:09
    of the 4-way handshake. Instead of
    forwarding this message to the access
  • 13:09 - 13:14
    point, we don't forward it, which in our
    situation is equivalent to blocking the
  • 13:14 - 13:21
    message from arriving at the access point.
    Now what's interesting in this situation,
  • 13:21 - 13:27
    is that from the perspective of the client,
    the handshake now successfully completed.
  • 13:27 - 13:32
    After all, it received Msg3, it
    replied using Msg4 and it thinks that
  • 13:32 - 13:36
    the handshake is done, meaning it now
    installs the encryption key and installs
  • 13:36 - 13:44
    the PTK for use. So, let's make some space
    here - the client thinks, that the handshake
  • 13:44 - 13:49
    was completed, it has installed the key,
    but the access point hasn't received
  • 13:49 - 13:55
    Msg4 yet and the access point will
    try to recover from this situation and it
  • 13:55 - 14:02
    will do that by retransmitting a new
    Msg3. And as the - as we, as the
  • 14:02 - 14:07
    attacker, will forward this message to the
    client, the client will accept this
  • 14:07 - 14:12
    retransmitted Msg3 and then the Wi-Fi
    standard says, that if you receive a
  • 14:12 - 14:17
    retransmitted Msg3, you will reply
    using a new Msg4. After that you will
  • 14:17 - 14:23
    also install the encryption key again. Now,
    one remark that I want to make here, is
  • 14:23 - 14:31
    that, when we receive the retransmitted
    Msg3, we reply using a new Msg4,
  • 14:31 - 14:36
    however, this Msg4 will be already
    encrypted at the link layer and the reason
  • 14:36 - 14:41
    it's already encrypted, is because these
    handshake messages are normal data frames
  • 14:41 - 14:46
    and well, we already installed the
    encryption key to encrypt data frames. So
  • 14:46 - 14:52
    nearly all implementations we tested, will
    send Msg4, the retransmitted Msg4,
  • 14:52 - 14:57
    in an encrypted fashion. Now, I want to
    remark here, that the Wi-Fi standard
  • 14:57 - 15:03
    actually demands that Msg4, if it is
    retransmitted, should be sent in plain text,
  • 15:03 - 15:07
    so according to the specification, this
    shouldn't happen. But nearly all
  • 15:07 - 15:13
    implementations we tested, sent a
    retransmitted Msg3 using encryption,
  • 15:13 - 15:18
    and we will abuse this observation later.
    So as I mentioned, after the client
  • 15:18 - 15:22
    receives a retransmitted Msg3, it'll
    reply using Msg4, it will again
  • 15:22 - 15:27
    install the encryption key, and as a
    result of that, this transmit nonce will be
  • 15:27 - 15:34
    reset, which means, that if the client now
    sends another data frame, it will again
  • 15:34 - 15:42
    use this nonce value of 1 to encrypt the
    frame, meaning we have nonce reuse, and we
  • 15:42 - 15:46
    have key stream reuse, meaning we can now
    try to abuse this to decrypt the data
  • 15:46 - 15:52
    frame.
    Now, how are we precisely going to abuse
  • 15:52 - 15:58
    this, because we do somehow need to
    recover the key stream that was used? And
  • 15:58 - 16:03
    we go back to our observation, that we have
    a Msg4 here, that is initially sent in
  • 16:03 - 16:08
    plain text, and a retransmission of
    Msg4 is later sent in an encrypted
  • 16:08 - 16:12
    fashion. Now, there is a small difference
    between these two messages, but
  • 16:12 - 16:16
    essentially we have a message sent in
    plaintext, and we have a message sent
  • 16:16 - 16:21
    encrypted, and all we need to do, is we
    need to XOR these two messages and we have
  • 16:21 - 16:24
    the key stream corresponding to the nonce
    value of 1.
  • 16:24 - 16:29
    This data frame here at the bottom, it
    also uses nonce value of 1, meaning it
  • 16:29 - 16:33
    uses the exact same key stream, so we XOR
    this packet with the key stream and there
  • 16:33 - 16:42
    you go: We decrypted the packets and we
    have now defeated WPA2. So...
  • 16:42 - 16:51
    Applause
    Thank you. So, that describes the attack
  • 16:51 - 16:56
    against the 4-way handshake. And the
    4-way handshake is not the only Wi-Fi
  • 16:56 - 17:00
    handshake that is vulnerable. There are
    also other handshakes which can be
  • 17:00 - 17:05
    attacked in a similar manner, but I'm not
    going to explain all of them in detail. If
  • 17:05 - 17:10
    you want all the nitty-gritty details, I'm
    going to refer you to our academic paper.
  • 17:10 - 17:14
    Here, I'm just going to discuss more the
    high-level concepts and the ideas behind
  • 17:14 - 17:19
    the attack. So, e.g., one handshake
    that is also vulnerable, is the group key
  • 17:19 - 17:23
    handshake, and that handshake is used to
    transport the group key from the access
  • 17:23 - 17:27
    point to the client. And that key is used
    to encrypt broadcast and multicast
  • 17:27 - 17:34
    traffic. Then we also have the FT
    handshake. The FT handshake is used, when
  • 17:34 - 17:38
    you roam from one access point to another
    access point of the same Wi-Fi network.
  • 17:38 - 17:43
    It's used so you can quickly switch
    from one access point to another without
  • 17:43 - 17:47
    a long timeout. And finally, another
    handshake that's also vulnerable is the
  • 17:47 - 17:52
    PeerKey handshake, and that's used when
    two clients want to communicate directly
  • 17:52 - 18:00
    with one another. Okay, so I'm now going
    to discuss in a bit more detail, what the
  • 18:00 - 18:06
    practical impact of our attacks are. And
    I'm first going to start with the general
  • 18:06 - 18:12
    impact that a key reinstallation attack
    has. So, let's assume we have a device
  • 18:12 - 18:16
    that's vulnerable. This device can either
    be a client device, e.g. it can be
  • 18:16 - 18:20
    a smartphone, or a laptop, or these days
    it can even be a toaster. They have Wi-Fi
  • 18:20 - 18:27
    as well. Or it can also be an access
    point. So if a client or access point is
  • 18:27 - 18:33
    vulnerable to our key reinstallation
    attack, the first thing that generally
  • 18:33 - 18:39
    always happens, if this device ever sends
    encrypted data frames, we can force it to
  • 18:39 - 18:45
    reuse the nonce, which in turn we can use
    to decrypt frames. But that's not the only
  • 18:45 - 18:51
    thing we can do when a device is vulnerable.
    Another thing we can do, is we can replay
  • 18:51 - 18:58
    encrypted frames sent towards this device.
    Now, why is that the case? That's because
  • 18:58 - 19:02
    if a key is reinstalled, not only is this
    transmit nonce reset to 0, but another
  • 19:02 - 19:08
    parameter, which is called the replay
    counter, it is also reset to 0. And this
  • 19:08 - 19:12
    replay counter, as the name implies,
    it's used to detect retransmissions, or
  • 19:12 - 19:19
    it's used to detect malicious replays. If
    this counter is reset, we can also replay
  • 19:19 - 19:25
    frames towards a vulnerable device. So,
    that's the general impact of a key
  • 19:25 - 19:33
    reinstallation attack, but there are a lot
    of other factors which also influence the
  • 19:33 - 19:41
    exact impact of the attack, and one of the
    things that probably has the biggest
  • 19:41 - 19:48
    influence, is the encryptions cipher that
    is being used. So, e.g., these days
  • 19:48 - 19:52
    it is quite common that Wi-Fi networks use
    AES CCMP. It's the most widely used
  • 19:52 - 19:59
    encryption algorithm in Wi-Fi networks.
    Against this algorithm, the impact in a
  • 19:59 - 20:04
    sense stays limited to only decrypting and
    replaying frames. It's not possible to
  • 20:04 - 20:10
    abuse our key reinstallation attack to now
    forge frames. And really, we got lucky
  • 20:10 - 20:17
    here, because this is the most widely used
    cipher, and against this cipher we cannot
  • 20:17 - 20:22
    start to forge frames. Because, if we
    would have been using the older encryption
  • 20:22 - 20:28
    algorithm, which is WPA TKIP, against that
    algorithm, we would be able to recover the
  • 20:28 - 20:32
    Message Integrity Check key, which is
    basically just a fancy word for the
  • 20:32 - 20:37
    authentication key. And once we have that
    authentication key, we would be able to
  • 20:37 - 20:45
    forge frames that appear to be sent by the
    device under attack. Interestingly, lately
  • 20:45 - 20:50
    there's also been a new encryption
    algorithm that is being introduced, and
  • 20:50 - 20:54
    that algorithm is
    called GCMP. It's fairly new, so only a
  • 20:54 - 20:59
    few devices currently support it, and
    currently it is being rolled out under the
  • 20:59 - 21:06
    name of WiGig. Against this algorithm, the
    impact of a key reinstallation attack is
  • 21:06 - 21:14
    really the worst, because here we can
    again recover the authentication key, but
  • 21:14 - 21:19
    when we use GCMP, the same authentication
    key is used in both communication
  • 21:19 - 21:23
    directions. So against GCMP, we would be
    able to forge frames that are sent from
  • 21:23 - 21:28
    the client to the access point and also
    forge frames that appear to be sent
  • 21:28 - 21:33
    from the access point to the client, while
    for the WPA-TKIP algorithm, we would only
  • 21:33 - 21:38
    be able to forge frames, that appear to be
    sent by the device that is under attack.
  • 21:38 - 21:43
    So, my opinion - this is a bit surprising,
    because GCMP is the latest encryption
  • 21:43 - 21:47
    algorithm that is defined in the Wi-Fi
    standard, yet the impact against it would
  • 21:47 - 21:52
    be the highest. So, this is also why I
    think we got lucky here, because if we
  • 21:52 - 21:55
    would have found the attack, say maybe
    five or ten years later, and everyone
  • 21:55 - 22:02
    would be using this algorithm, the impact
    would have been a lot worse. Another thing
  • 22:02 - 22:06
    that influences the impact of the attack
    is, which specific handshake we are
  • 22:06 - 22:11
    attacking. For example, if we attack the
    group key handshake, then the only thing
  • 22:11 - 22:14
    we can do is, we can
    only replay, broadcast or
  • 22:14 - 22:20
    multicast frames. Now, why is that the
    case? Why can't we decrypt broadcast or
  • 22:20 - 22:26
    multicast frames, if a key reinstallation
    occurs? And the reason is, that if we
  • 22:26 - 22:30
    attack the group key handshake, we are
    attacking the client, and the client is
  • 22:30 - 22:35
    never sending actual encrypted broadcast
    frames, so will never reuse the transmit
  • 22:35 - 22:40
    nonce when it encrypts frames, because
    it's never encrypting frames. Now, why is
  • 22:40 - 22:45
    it, that the client never sends real
    encrypted broadcast frames? Well, the
  • 22:45 - 22:49
    reason is quite simple. Let's say, we have
    the network layout shown here and the
  • 22:49 - 22:54
    client on the left wants to send a
    broadcast frames to all the other clients.
  • 22:54 - 22:58
    Now, what happens here, is that this client
    will send the data frame it wants to
  • 22:58 - 23:04
    broadcast as a Unicast frame to the access
    point only, meaning it won't encrypt it
  • 23:04 - 23:10
    yet under the group key. It's the access
    points that will broadcast this frame to
  • 23:10 - 23:14
    all connected clients, and only the access
    point will then encrypt it using the group
  • 23:14 - 23:16
    key, and this is to assure that all
    clients
  • 23:16 - 23:21
    within range of the access point will
    receive this broadcast message. Now, for
  • 23:21 - 23:25
    us, this means that only the access point
    is transmitting real encrypted broadcast
  • 23:25 - 23:29
    frames, and in the group key handshake we
    cannot attack the access point. We are
  • 23:29 - 23:33
    only attacking the client, meaning in
    practice, we can only replay broadcast
  • 23:33 - 23:38
    frames to the client, at least if we are
    targeting the group key handshake. So,
  • 23:38 - 23:43
    really, the impact is limited in practice
    if we attack this handshake, because
  • 23:43 - 23:48
    generally, replaying broadcast data doesn't
    have a high impact. Though, I do want to
  • 23:48 - 23:53
    note, that some home automation systems use
    broadcast traffic to, e.g., send
  • 23:53 - 23:59
    commands to turn the device on or off,
    e.g. to turn your fridge on, or to turn
  • 23:59 - 24:04
    lights on or off, so although the
    impact of replaying broadcast frame is
  • 24:04 - 24:08
    low, there are situations in practice,
    where it does have some impact, but it
  • 24:08 - 24:13
    really depends on your network setup and
    the devices that you use. So, the other
  • 24:13 - 24:17
    handshake that is vulnerable, is the 4-
    way handshake, but we already discussed
  • 24:17 - 24:22
    that. Against a 4-way handshake we can
    attack the clients and the impact, is that
  • 24:22 - 24:26
    we can replay and decrypt frames, and
    depending on the encryption algorithm
  • 24:26 - 24:32
    being used, we can possibly forge frames
    as well. The situation is a lot more
  • 24:32 - 24:36
    interesting for the FT handshake, though.
    And remember, this handshake is used, when
  • 24:36 - 24:41
    you roam from one access point to another
    of the same network. Against the FT
  • 24:41 - 24:46
    handshake, it's not the clients that we
    can attack, but here we can attack the
  • 24:46 - 24:51
    access point. And on top of that, when
    attacking the FT handshake, we no longer
  • 24:51 - 24:57
    need this man-in-the-middle position. Now,
    why is that the case? Well, let's again
  • 24:57 - 25:01
    explain this using our common example,
    where a client wants to connect and where
  • 25:01 - 25:08
    it is executing the FT handshake. And at a
    high level, the FT handshake is the same
  • 25:08 - 25:12
    as the 4-way handshake, meaning you
    also have four frames that are
  • 25:12 - 25:17
    transmitted, but the big difference here
    is, that with the FT handshake it's the
  • 25:17 - 25:21
    client that sends the first message
    in the handshake, while for the 4-way
  • 25:21 - 25:26
    handshake it was the access point that
    sends the first message. So, the handshake
  • 25:26 - 25:30
    is practically the same as the 4-way
    handshake, meaning, initially we have two
  • 25:30 - 25:34
    messages that transport these random
    numbers, these nonces, between both
  • 25:34 - 25:41
    devices. Then, both these endpoints can
    generate the fresh encryption key. Then
  • 25:41 - 25:46
    the last two frames, they are again used
    to confirm that both parties negotiated
  • 25:46 - 25:51
    the same encryption key. Now, I want to go
    in a bit more detail here on this last
  • 25:51 - 25:57
    phase, and what happens here, is that the
    third frame of the handshake is now sent
  • 25:57 - 26:02
    from the client to the access point and
    that is a reassociation request. And after
  • 26:02 - 26:07
    the access point receives this frame, it
    will reply using a reassociation response
  • 26:07 - 26:13
    frame and it will install the encryption
    key. Once it has installed the encryption
  • 26:13 - 26:19
    key, it can of course start sending
    encrypted data frames. So, let's again
  • 26:19 - 26:24
    make some room here. What we can now do
    as an attacker, is we can take this
  • 26:24 - 26:29
    reassociation request that the client
    previously transmitted, and we can simply
  • 26:29 - 26:36
    replay it. That's because in the FT
    handshake, there is no replay protection
  • 26:36 - 26:42
    against messages of the handshake. So we
    can just take that frame, we can send it
  • 26:42 - 26:45
    again to the access point. The access
    point will receive it, it will accept it,
  • 26:45 - 26:51
    and it will reply using a reassociation
    response. Now, so far this is not a
  • 26:51 - 26:57
    problem. The problem here is, that again
    the access point will reinstall the
  • 26:57 - 27:01
    encryption key, and here it goes wrong
    because we are reinstalling this
  • 27:01 - 27:06
    encryption key. The transmit nonce is
    again reset to 0, meaning if we now send
  • 27:06 - 27:12
    the data frame again, the nonce value of 1
    is used to encrypt these data frames,
  • 27:12 - 27:15
    meaning the same key stream is used,
    meaning we can start applying the same
  • 27:15 - 27:19
    tricks to first derive some known key
    stream and to then abuse that to attack
  • 27:19 - 27:24
    the handshake. So, I want to highlight
    here a few things. And the first is, the
  • 27:24 - 27:28
    reason why we don't need a man-in-the-
    middle position, is because handshake
  • 27:28 - 27:30
    messages in
    the FT handshake, they are not protected
  • 27:30 - 27:35
    against replays, while in the 4-way
    handshake, every handshake messages
  • 27:35 - 27:40
    contains a sequence counter, where the
    receiver uses the sequence counter to
  • 27:40 - 27:44
    detect replays, but for the FT handshake
    that's not the case, so we can just take
  • 27:44 - 27:48
    these messages, we can replay them, and we
    don't need a man-in-the-middle position to
  • 27:48 - 27:55
    block packets and to trigger
    retransmissions. Ok, so that's the
  • 27:55 - 28:02
    explanation for the FT handshake. Another
    factor that can influence the impacts of
  • 28:02 - 28:07
    our attack in practice, is which operating
    system and which device precisely we are
  • 28:07 - 28:12
    attacking. And in particular, we see that
    iOS and Windows, they are not vulnerable
  • 28:12 - 28:18
    against attacks against a 4-way
    handshake. And why is that the case? Well,
  • 28:18 - 28:22
    that's because these two devices don't
    really follow the standard, and they don't
  • 28:22 - 28:27
    accept retransmissions of Msg3,
    meaning we cannot abuse these
  • 28:27 - 28:33
    retransmissions of Msg3 to trigger
    these key reinstallations.
  • 28:33 - 28:36
    Now, I want to make two remarks
    here. And the first one is, that
  • 28:36 - 28:42
    against these devices we can still attack
    the group key handshake. And particularly
  • 28:42 - 28:47
    when looking at iOS, if we look at iOS
    version 11, it does implement the standard
  • 28:47 - 28:51
    properly and it does accept
    retransmissions of Msg3, meaning that
  • 28:51 - 28:59
    one is vulnerable to attacks against the
    4-way handshake. Now, Linux is not much
  • 28:59 - 29:04
    better, because if we look at the Wi-Fi client
    that is used on Linux, and for example on
  • 29:04 - 29:12
    Android, it's called wpa_supplicant, and
    against wpa_supplicant 2.4 and higher, we
  • 29:12 - 29:18
    notice that, if we try to perform a key
    reinstallation attack, it won't reinstall
  • 29:18 - 29:23
    the secret key that was negotiated, but
    no, instead it will suddenly install an
  • 29:23 - 29:28
    all-zero encryption key, and then it of
    course becomes very trivial to start
  • 29:28 - 29:37
    decrypting data that this device is
    transmitting. Now, why does this happen?
  • 29:37 - 29:43
    I can actually sort of understand why this
    went wrong. So, I'm going to explain what
  • 29:43 - 29:49
    the implementation does wrong, to... why it
    installs this all-zero key. And to explain
  • 29:49 - 29:52
    this, I'm going to assume that we have an
    Android device that is connecting to an
  • 29:52 - 29:57
    access point. And we're going to zoom in a
    bit on the implementation of the Android.
  • 29:57 - 30:01
    And we're going to look at two entities.
    We're first going to look at wpa_supplicant,
  • 30:01 - 30:05
    which is represented by the
    handshake icon here, and we're also going
  • 30:05 - 30:10
    to look at another entity, namely the
    Linux kernel. It's the Linux kernel that
  • 30:10 - 30:15
    will be responsible for encrypting data
    frames, and wpa_ supplicant will be
  • 30:15 - 30:21
    responsible for executing the 4-way handshake.
    And of course we assume, that we as an
  • 30:21 - 30:27
    attacker are nearby, and we again have
    this man-in-the-middle position. So, what
  • 30:27 - 30:31
    does an attacker have to do to cause this
    installation of an all-zero encryption
  • 30:31 - 30:37
    key? Well, again, we simply let the first
    phase of the 4-way handshake execute
  • 30:37 - 30:42
    normally, and when the access point sends
    Msg3 of the 4-way handshake, we
  • 30:42 - 30:49
    forward that to the Android. Android will
    reply using Msg4. And we will
  • 30:49 - 30:54
    again block Msg4 from arriving at the
    access point.
  • 30:54 - 30:58
    Now, completely similar to the case with
    the 4-way handshake, the client thinks that
  • 30:58 - 31:02
    the handshake now successfully completed,
    meaning it will install the encryption
  • 31:02 - 31:08
    key. How it will install the encryption
    key is as follows: It commands the Linux
  • 31:08 - 31:15
    kernel into installing the encryption key
    in the driver. And the driver itself will
  • 31:15 - 31:19
    make a copy of the encryption key. And it
    will store it locally. And the driver can
  • 31:19 - 31:24
    then encrypt frames. Now this means that
    wpa_supplicant, which is just a user land
  • 31:24 - 31:28
    program, no longer needs to store the
    encryption key, meaning it will clear it
  • 31:28 - 31:34
    from memory. What will happen now, if we
    continue with the attack, is that the
  • 31:34 - 31:39
    access point will retransmit Msg3,
    because it did not receive Msg4. The
  • 31:39 - 31:43
    client will again happily accept this
    retransmitted Msg3 and reply using
  • 31:43 - 31:48
    Msg4. And again it will instruct the
    Linux kernel saying "Hey, please install
  • 31:48 - 31:52
    this encryption key that is located at
    this address in the memory." But of
  • 31:52 - 31:57
    course, that memory is now all zeros,
    because that key has just been cleared
  • 31:57 - 32:00
    from memory. So,
    now it's basically commanding the Linux
  • 32:00 - 32:04
    kernel into installing an all-zero
    encryption key. And the Linux kernel and
  • 32:04 - 32:09
    driver will happily obey this command and
    they will install an all-zero encryption
  • 32:09 - 32:14
    key, meaning at this point, all the data
    that the client is sending, is encrypted
  • 32:14 - 32:18
    using a known key, so we can easily
    decrypt all the traffic, and of course we
  • 32:18 - 32:23
    can also send any traffic we want to the
    client. Basically, we are now a rogue
  • 32:23 - 32:29
    access point and we can manipulate the
    traffic of the client as we wish.
  • 32:29 - 32:38
    Applause
    MV: Thank you. So, after this you might be
  • 32:38 - 32:43
    wondering, "Well, gee, is my device
    vulnerable?" And you can test your own
  • 32:43 - 32:50
    device using the following script. It's on
    github. I have tested the script on Kali
  • 32:50 - 32:55
    Linux, on Arch Linux, and also on Ubuntu,
    so I could recommend using one of these
  • 32:55 - 33:00
    distributions, and I also recommend to use
    a Wi-Fi dongle that we or someone else has
  • 33:00 - 33:05
    tested ourselves, because we noticed that
    if you use our testing scripts with some
  • 33:05 - 33:09
    older
    Wi-Fi devices, then there are some bugs in
  • 33:09 - 33:16
    these Wi-Fi devices which cause our
    scripts to fail. And one way to also
  • 33:16 - 33:20
    prevent our scripts to fail, is to disable
    hardware encryption. Now, how you should do
  • 33:20 - 33:25
    that is also explained on this page. Using
    these scripts, you can test both your
  • 33:25 - 33:29
    client devices, you can test against
    attacks against the 4-way handshake,
  • 33:29 - 33:34
    the group key handshake, and there's also
    a script to test the access point, whether
  • 33:34 - 33:41
    it's vulnerable against attacks against
    the FT handshake. Now, if you're going to
  • 33:41 - 33:46
    try to see which devices are vulnerable,
    you are most likely going to see that
  • 33:46 - 33:53
    quite some clients are still vulnerable to
    our attacks. Luckily, we can modify the
  • 33:53 - 33:58
    access point to prevent attacks against
    the client. In particular, we can make
  • 33:58 - 34:03
    additional modifications to the access
    point, such that the access points never
  • 34:03 - 34:07
    retransmits Msg3 of the 4-way
    handshake, and that it also never
  • 34:07 - 34:12
    retransmits the first message of the group
    key handshake. And if we do that, then
  • 34:12 - 34:17
    clients that are connected to such a
    modified access points, they are no longer
  • 34:17 - 34:19
    vulnerable against most attacks. There are
  • 34:19 - 34:25
    still some edge cases where the device is
    vulnerable, but these have a very low
  • 34:25 - 34:30
    impact. So, if we modify an access point
    in this way, then connected clients are no
  • 34:30 - 34:35
    longer vulnerable. One downside here is,
    that because we are no longer
  • 34:35 - 34:41
    retransmitting certain messages, it could
    be that especially in a noisy environment,
  • 34:41 - 34:45
    because we don't retransmit these messages
    anymore, that the handshake may fail
  • 34:45 - 34:50
    because the reliability is now less. Now,
    one thing I also want to remark here,
  • 34:50 - 34:57
    that... if you have a router, which is
    vulnerable against our attack and a
  • 34:57 - 35:02
    vendor says "Hey, we patched our router,
    so we patched our access point to defend
  • 35:02 - 35:07
    against attacks," then this does not mean
    that this access point implements these
  • 35:07 - 35:11
    countermeasures. Because these
    countermeasures, they are additional
  • 35:11 - 35:16
    modifications on top of the normal
    patches to defend against the attack. So,
  • 35:16 - 35:21
    only if a vendor explicitly says that "Our
    patches of the access point also prevent
  • 35:21 - 35:26
    attacks against clients," then, only if
    they explicitly say that, are attacks
  • 35:26 - 35:33
    against the client also prevented. Ok,
    so now I want to cover some misconceptions
  • 35:33 - 35:40
    that have been floating around the
    internet. And the first one is, that some
  • 35:40 - 35:43
    people claim, if you only patch the
    clients, or if you only patch the access
  • 35:43 - 35:47
    point, then you're fine. But that's not
    the case. Because if you only patch the
  • 35:47 - 35:51
    client and the access point is vulnerable,
    then we can still attack the access point.
  • 35:51 - 35:55
    If the access point only contains these
    normal patches, the normal patches to
  • 35:55 - 36:00
    defend against attacks, then connected
    clients are also still vulnerable. So, as
  • 36:00 - 36:06
    I mentioned, connected clients are only
    defended, if the access point contains
  • 36:06 - 36:12
    really extra modifications on top of the
    default patches. Now, another common
  • 36:12 - 36:17
    misconception is, that some people might
    say "But, yeah, it's a cool attack, but
  • 36:17 - 36:22
    you have to be close to the network in
    order to pull off these attacks."
  • 36:22 - 36:27
    Unfortunately, that's not the case because
    we can use special antenna. And this
  • 36:27 - 36:30
    special antenna, they can be made
    really cheap out of, e.g. just a
  • 36:30 - 36:36
    tin can, and with this special antenna, we
    can manipulate Wi-Fi traffic from up to,
  • 36:36 - 36:41
    say, 2 miles. And there are even leaked
    NSA documents, where the NSA is able to
  • 36:41 - 36:47
    exploit a Wi-Fi network using other
    attacks from up to 8 miles away. Now,
  • 36:47 - 36:51
    that's of course with a clear line of
    sight, but still this shows that you don't
  • 36:51 - 36:55
    have to be physically close to the
    network. You can still be relatively far
  • 36:55 - 37:02
    away. Another strange remark that I
    sometimes hear, is that you need to be
  • 37:02 - 37:07
    connected to the network in order to pull
    off these attacks, which would basically
  • 37:07 - 37:10
    mean, you need to know the password of the
    network to carry out the attacks. But
  • 37:10 - 37:15
    that's not the case. As I mentioned,
    during the attacks, you only need to be
  • 37:15 - 37:20
    close enough. You need to be able to
    manipulate some encrypted packets. But you
  • 37:20 - 37:24
    don't need to know anything about the
    network. You simply need to know the
  • 37:24 - 37:27
    network is there and there's a vulnerable
    client and access point and then you can
  • 37:27 - 37:34
    start attacking them. One remark that I
    can understand, is that some people
  • 37:34 - 37:39
    say that "Yeah, Ok, you can attack these
    handshakes, and you can decrypt data that
  • 37:39 - 37:44
    is sent right after these handshakes, but
    generally right after you connect to an
  • 37:44 - 37:49
    Wi-Fi network, you're not really sending
    interesting data, because at that point
  • 37:49 - 37:54
    your device is sending e.g. ARP
    requests, or it's sending DHCP requests,
  • 37:54 - 38:00
    or is just creating TCP connections. But
    no useful information is transmitted at
  • 38:00 - 38:06
    this time." Unfortunately, at least for a
    defender, this is again not true. Because,
  • 38:06 - 38:10
    what we can do as an attacker is, we can
    first let the client connect blackout out
  • 38:10 - 38:14
    manipulating any traffic. The client, the
    victim, will then, e.g. start
  • 38:14 - 38:20
    browsing the internet, start
    opening TCP connections, and in the middle
  • 38:20 - 38:24
    of that, while the victim is e.g.
    surfing the internet, we can
  • 38:24 - 38:28
    deauthenticate the client from the
    network, and all operating system will
  • 38:28 - 38:32
    then immediately execute a new 4-way
    handshake. And once that 4-way
  • 38:32 - 38:38
    handshake is then completed, it will
    send all the buffered TCP packets again
  • 38:38 - 38:41
    to the access point and also in a reverse
    direction. So, basically, what we as an
  • 38:41 - 38:45
    attacker can do, we can wait until we
    expect the victim to send interesting
  • 38:45 - 38:49
    information. Then we deauthenticate the
    victim. It will execute a new handshake.
  • 38:49 - 38:56
    And then we can decrypt the data that will
    be transmitted right after that handshake.
  • 38:56 - 39:00
    Another thing that makes the attack
    possibly hard, is that obtaining this
  • 39:00 - 39:04
    channel based man-in-the-middle is
    difficult. For example, you might be
  • 39:04 - 39:08
    thinking that in order to force the
    clients to connect to the rogue access
  • 39:08 - 39:13
    point, you need a stronger signal strength
    than a real access point. But again,
  • 39:13 - 39:18
    that's not the case. And the reason this
    is not the case, is because we can use
  • 39:18 - 39:23
    special Wi-Fi packets and so-called
    channel switch announcements, which
  • 39:23 - 39:29
    command the client into switching to a
    different Wi-Fi channel, and effectively
  • 39:29 - 39:32
    blackout to a rogue access point. So we don't
    need a high signal strength, we can simply
  • 39:32 - 39:37
    command a victim into saying "Hey, switch
    to this channel and connect to our access
  • 39:37 - 39:41
    point." And these frames are not
    authenticated, so we can just forge them
  • 39:41 - 39:48
    as an attacker. Another thing you might
    say, that the complexity of the attack is
  • 39:48 - 39:53
    hard, meaning it requires some expertise
    to implement this. And this is true. You
  • 39:53 - 39:59
    do need to know a bit about Wi-Fi in order
    to make a proof of concept reliable, but
  • 39:59 - 40:03
    as usual you only need to write this
    attack once, and then people can use your
  • 40:03 - 40:08
    script in order to attack others. And this
    is similar to, e.g., memory
  • 40:08 - 40:13
    corruption attacks, such as buffer
    overflows or stack overflows. Writing the
  • 40:13 - 40:17
    proof of concept may be hard, but if you
    then give it to someone else, or if you
  • 40:17 - 40:22
    put it in Metasploit or some other tool,
    all the user has to do, is basically start
  • 40:22 - 40:29
    the script, and you can start attacking
    people. One other misconception that I
  • 40:29 - 40:36
    sometimes encounter, is that people say "If
    you use AES-CCMP, this mitigates the
  • 40:36 - 40:42
    attack." Again, unfortunately, this is not
    true, because the only advantage of using
  • 40:42 - 40:47
    AES-CCMP is that
    the attacker can no longer forge frames.
  • 40:47 - 40:53
    The attacker is still able to decrypt and
    replay frames. And finally, the last
  • 40:53 - 40:58
    misconception is, that some people say that
    enterprise networks aren't vulnerable,
  • 40:58 - 41:03
    because they e.g. don't execute
    the 4-way handshake. But again,
  • 41:03 - 41:07
    unfortunately, that's wrong, because even
    these networks use the 4-way handshake
  • 41:07 - 41:14
    and they can be attacked as well. So, then
    you have some people that say "OK, WPA2 is
  • 41:14 - 41:20
    now completely broken. It's the end of the
    world and we're all doomed." Let's not get
  • 41:20 - 41:26
    carried away, though. We can patch these
    vulnerabilities in a backwards compatible
  • 41:26 - 41:30
    way. And as I illustrated here in my talk,
    the impact also really depends on the
  • 41:30 - 41:35
    devices that you are using and your own
    network setup. So, sometimes the impact is
  • 41:35 - 41:38
    actually really low, but of course
    sometimes the impact can be very high,
  • 41:38 - 41:43
    e.g. if you have a Linux device, then
    attacker can do what he or she wishes,
  • 41:43 - 41:50
    essentially. Now, for the last part of the
    talk, I'm going to discuss some lessons
  • 41:50 - 41:56
    that we can learn from this attack and
    also the research. I think one of the most
  • 41:56 - 42:01
    important and interesting observations -
    it's also the reason why I really like
  • 42:01 - 42:06
    this attack myself - is that the 4-way
    handshake was proven to be secure. The
  • 42:06 - 42:11
    encryption protocol, and in particular
    AES, has also been proven as secure.
  • 42:11 - 42:19
    However, if we combine these two things,
    then suddenly we lose all security. And
  • 42:19 - 42:27
    this is quite unfortunate. And what this
    teaches us, is that even though individual
  • 42:27 - 42:33
    parts of a system were really investigated
    and perhaps formally analyzed, we also
  • 42:33 - 42:38
    need to analyze the combination of these
    different entities and models, and we also
  • 42:38 - 42:44
    need to prove that these combinations are
    secure as well. And another way to look at
  • 42:44 - 42:51
    this, is that in the proof of the 4-way
    handshake, the authors, they modeled the
  • 42:51 - 42:57
    handshake in a rather abstract way. And
    their proofs, specifically, they did not
  • 42:57 - 43:01
    model retransmissions of handshake
    messages. And that's one of the things we
  • 43:01 - 43:06
    abuse. So, on one hand we need to assure
    that we also look
  • 43:06 - 43:11
    at the combinations of these different
    entities, but we also need to assure that
  • 43:11 - 43:17
    the abstract models that we use reflect
    reality. Another thing that we can learn,
  • 43:17 - 43:22
    is that we should keep the protocols and
    also the implementations simple.
  • 43:22 - 43:28
    E.g., if we look at wpa_supplicant 2.6,
    when we were studying this version
  • 43:28 - 43:35
    ourself, we thought it wasn't vulnerable
    to key reinstallation attacks. However,
  • 43:35 - 43:41
    when we were notifying companies of the
    vulnerabilities, another researcher found
  • 43:41 - 43:47
    an attack against this version which did
    work. The reason we missed this attack
  • 43:47 - 43:53
    against version 2.6, is because
    wpa_supplicant uses a fairly complex
  • 43:53 - 43:58
    implementation of the 4-way handshake
    and the state machine is fairly complex to
  • 43:58 - 44:03
    reason about. And there are two ways to
    combat this. The first is to keep the
  • 44:03 - 44:07
    protocol simple. The second way to combat
    this, is to formally verify
  • 44:07 - 44:13
    implementations. Now of course, we cannot
    formally verify all the code, but what we
  • 44:13 - 44:17
    can do is, really, these cryptographic
    protocols which play a very important
  • 44:17 - 44:24
    role, at least we should pay enough
    attention to that. What's also
  • 44:24 - 44:29
    interesting, is that I encountered a
    document of the CIA which also agrees, that
  • 44:29 - 44:34
    complex implementations or protocols are
    bad. Specifically, they have a document,
  • 44:34 - 44:40
    where the CIA advises people how to
    properly implement backdoors, essentially,
  • 44:40 - 44:45
    and they're saying that "Yeah, if you want
    to send data back to us, of course, use
  • 44:45 - 44:49
    encryption, but in that encryption
    algorithm, don't enable re-key
  • 44:49 - 44:53
    functionality, because that enables
    additional features of the encryption
  • 44:53 - 44:59
    algorithm. And these additional features,
    they cause unnecessary complexity and that
  • 44:59 - 45:05
    generally leads to bugs." Another thing
    that we can learn, is that the standard
  • 45:05 - 45:11
    needs to be specified rigorously and as
    precisely as possible. Because the
  • 45:11 - 45:18
    original WPA2 standard, it was a bit fake.
    It didn't really define a state machine.
  • 45:18 - 45:24
    Well, the state machine that it defined
    says, what an implementation - sorry -
  • 45:24 - 45:30
    should do if it receives a message, but -
    let's go back to the slides - but it
  • 45:30 - 45:35
    doesn't define what an implementation
    should do when it receives an unexpected
  • 45:35 - 45:42
    message. So, it doesn't define the order,
    in which messages should be accepted. Now,
  • 45:42 - 45:47
    there is an amendment of the Wi-Fi
    standard which better defines how and when
  • 45:47 - 45:53
    to handle messages, but even that standard
    is a bit fake. And I want to remark here
  • 45:53 - 45:58
    that because the original WPA2 standard
    was a bit fake, I can forgive iOS and
  • 45:58 - 46:02
    Windows for deviating a bit from the
    standard. Because the standard was
  • 46:02 - 46:09
    difficult to interpret correctly. Now, on
    a bit of a related note, I want to briefly
  • 46:09 - 46:14
    mention a workshop that we are organizing,
    which is exactly about how to implement
  • 46:14 - 46:19
    these security protocols properly, how to
    e.g. fuzz security protocols, how
  • 46:19 - 46:24
    to prove that they are correct, how to
    make sure that we specify them rigorously.
  • 46:24 - 46:30
    So, if you are working in this field, do
    consider submitting to this. Now, the last
  • 46:30 - 46:36
    thing that I want to mention on what we
    can learn from this research, is how we
  • 46:36 - 46:43
    can coordinate the disclosure of a
    vulnerability like this. Because this is
  • 46:43 - 46:46
    not an ordinary vulnerability,
    that is, just affects one
  • 46:46 - 46:52
    vendor, it really affects possibly every
    Wi-Fi device that is around. So, how on
  • 46:52 - 46:57
    earth are you going to start notifying
    companies? Who are you going to notify?
  • 46:57 - 47:02
    What would be the deadlines, and so on?
    Well, I'm going to discuss a bit about the
  • 47:02 - 47:08
    strategy that we used, and what we used
    first is... we first wanted to determine,
  • 47:08 - 47:12
    you know, is this really a widespread
    issue? We wanted to be sure of that before
  • 47:12 - 47:19
    we started to notify a lot of companies.
    And the way we tackled that problem is, we
  • 47:19 - 47:25
    first contacted a few selected vendors and
    we told them that "Hey, we possibly found
  • 47:25 - 47:31
    this flaw in the WPA2 protocol, but we
    weren't able to test your devices, but you
  • 47:31 - 47:36
    should check this out." And quite quickly
    we got a few responses from vendors, saying
  • 47:36 - 47:42
    that "Yes, we looked at your attack and
    indeed, some of our devices are
  • 47:42 - 47:45
    vulnerable," and this really confirmed to
    us, that a device
  • 47:45 - 47:50
    that we didn't test ourself was
    vulnerable to the attack that we found.
  • 47:50 - 47:53
    So, it confirmed that the issue is
    widespread, and we also got a bit of
  • 47:53 - 47:57
    feedback on the report that we sent
    towards them on the description of our
  • 47:57 - 48:03
    attack. So, at this point we were
    convinced ourselves, that this really was a
  • 48:03 - 48:08
    flaw in the standard and that a lot of
    companies will be affected. Then the next
  • 48:08 - 48:13
    question we had is, "Okay, who are we now
    all going to notify?" We of course
  • 48:13 - 48:16
    notified the big names and the big
    companies, but who else do we have to
  • 48:16 - 48:23
    notify? And at this point, our tactic was
    to rely on a CERT team, specifically a
  • 48:23 - 48:29
    CERT from the US and they did all the
    coordination for us.
  • 48:29 - 48:34
    But one other thing that you can do is,
    that if you're not sure who all is
  • 48:34 - 48:39
    affected or what, who all the vendors are,
    then you can just ask a vendor that you
  • 48:39 - 48:43
    contacted already for other
    vendors, that also might be affected
  • 48:43 - 48:49
    by the bug that you found, e.g.
    Now one thing that is more difficult here,
  • 48:49 - 48:56
    is that on one hand you want to notify as
    much vendors as possibly, on the other hand
  • 48:56 - 49:01
    you also can't notify everyone because if
    you are going to notify everyone, then the
  • 49:01 - 49:10
    chance of the details leaking, they become
    close to one. Another difficult thing to
  • 49:10 - 49:16
    decide is, how long should you give time to
    companies in order to patch this. And again,
  • 49:16 - 49:23
    here you're mixed between two decisions:
    on one hand you can give give them a long
  • 49:23 - 49:28
    period to patch everything, but then again,
    the risk of this details leasing... err,
  • 49:28 - 49:33
    leaking increase. On the other hand, if the
    embargo period is too short, people won't
  • 49:33 - 49:37
    have time to patch it. So this is quite a
    hard decision. In the end,
  • 49:37 - 49:42
    what we did is - and which I would
    again do in the future - is, it's hard to
  • 49:42 - 49:47
    pick a deadline, but still do pick a
    deadline to avoid any uncertainty and so
  • 49:47 - 49:54
    that people know, what to expect. And
    finally, I want to thank CERT and ICASI
  • 49:54 - 50:00
    for helping with the coordination and you
    also want to thank Cisco for some of the
  • 50:00 - 50:06
    advice that they give.
    So, with that I can conclude the talk, so
  • 50:06 - 50:12
    what we discussed, is a flaw and the WPA2
    standard itself and the most surprising
  • 50:12 - 50:18
    thing about this research is, that WPA2 was
    proven to be correct, yet we still found
  • 50:18 - 50:23
    his attack after more than a decade.
    And more than that, not only is this just a
  • 50:23 - 50:28
    theoretical attack, the attack has actual
    impact and practice.
  • 50:28 - 50:33
    And finally, in order to defend against
    this, you should update all your clients
  • 50:33 - 50:38
    and also check if your access points are
    affected. So with that, thank you for your
  • 50:38 - 50:41
    attention and if there are any questions,
    feel free to ask.
  • 50:41 - 50:51
    applause
  • 50:51 - 50:53
    Herald: So, do we have any questions?
  • 50:53 - 50:58
    There is mics everywhere, so please come
    in front. And I think, we already have the
  • 50:58 - 51:02
    first question directly here in front on
    mic number 1.
  • 51:02 - 51:12
    Mic1: You mentioned, that GCMP is most
    vulnerable. Do you know if there's any
  • 51:12 - 51:18
    standardization going on, about switching
    to nonce misuse resistant scheme like
  • 51:18 - 51:28
    AES-GCM, Synthetic Initialization Vector?
    MV: Yes, so there have been
  • 51:28 - 51:34
    some proposals in order to make the
    encryption algorithm defend against nonce
  • 51:34 - 51:40
    reuse. Now the impression I have, that this
    is still a bit of ongoing research. So
  • 51:40 - 51:45
    there are proposals, where you have an
    algorithm that you can use, but I'm not
  • 51:45 - 51:51
    aware of actual encryption protocols, e.g.
    TLS or Wi-Fi, that are using them.
  • 51:51 - 51:55
    But they exist, but I... they're not yet being
    really used.
  • 51:55 - 52:03
    Mic1: It is standardisation going on in
    CFRG, so Crypto Forum Research Group in
  • 52:03 - 52:11
    IETF standardization, but I was asking about
    Wi-Fi standardization, if they are planning
  • 52:11 - 52:20
    to use this? And [a] related question would be,
    if you would use in AES-GCM instead of
  • 52:20 - 52:30
    the deterministic initialization vector,
    there's a random IV possible, if you use
  • 52:30 - 52:39
    96 bit, then the impact wouldn't be
    bounded.
  • 52:39 - 52:45
    MV: So to answer the first question: I'm
    not aware of the Wi-Fi standard
  • 52:45 - 52:52
    from really modifying the standard to use
    a nonce misuse resistant encryption
  • 52:52 - 52:57
    cipher. They are modifying the standard to
    defend against key reinstallation attacks,
  • 52:57 - 53:01
    but I think they're not yet going to
    incorporate a nonce misuse resistant
  • 53:01 - 53:05
    encryption cipher, because they still have
    the impression that they're going to wait
  • 53:05 - 53:12
    probably a while and once that technology
    is more mature they're going to use that.
  • 53:12 - 53:16
    If I understood your second question, you
    also have encryption algorithms, where you
  • 53:16 - 53:21
    don't have deterministic nonce, but you
    have a nonce, which for every encryption
  • 53:21 - 53:28
    operation e.g. is random.
    Mic1: Actually in the GCM standard there
  • 53:28 - 53:32
    are two possibilities: one deterministic,
    MV: Yeah.
  • 53:32 - 53:38
    Mic1: and the second random.
    MV: So the risk of using a random
  • 53:38 - 53:43
    initialization vector is, that you may
    have a bad random generator,
  • 53:43 - 53:52
    that it can go wrong there. On that, that
    you still have nonce reuse, so even with a
  • 53:52 - 53:57
    randomly generated nonce it can
    also go bad, but then there are different
  • 53:57 - 54:02
    attacks. And I think, there has been a
    paper that analyzes a certain TLS
  • 54:02 - 54:07
    libraries, where they do find attacks, where
    in that case the GCM algorithm can still
  • 54:07 - 54:12
    be attacked, not through key reinstallation
    attacks, but because there is, because
  • 54:12 - 54:16
    basically the nonce isn't really random,
    e.g. sometimes a bad implementation
  • 54:16 - 54:21
    always uses the same random nonce.
    Person X: Um, direct answer...
  • 54:21 - 54:23
    Herald: Err, sorry,...
    X: Direct answer to his question number
  • 54:23 - 54:31
    one: because he asked, whether there's
    right now an approach to modify the
  • 54:31 - 54:38
    standard towards being resistant against
    this attack, right now there is no IEEE
  • 54:38 - 54:46
    task group working on an amendment which
    will fix this.
  • 54:46 - 54:51
    MV: Well, there is... they are working to
    prevent the key reinstallation attack.
  • 54:51 - 54:54
    X: Well, there is no official
    active task group right now.
  • 54:54 - 54:57
    MV: Okay that could be, but there are still
    people working on that.
  • 54:57 - 54:59
    X: Yeah, they're working on that,
    but no
  • 54:59 - 55:01
    task group, right?
    MV: Ok. Thank you.
  • 55:01 - 55:03
    Herald: Okay thank you.
    Here in number 3.
  • 55:03 - 55:08
    Mic3: Yes, thanks for your
    amazing talk.
  • 55:08 - 55:11
    Just for my personal understanding:
    could you briefly go back to
  • 55:11 - 55:17
    the slide with the 4-way
    handshake, like, right in the beginning?
  • 55:17 - 55:21
    MV: Yup, so the attack or the handshake
    itself?
  • 55:21 - 55:29
    Mic3: Yeah, yeah the attack.
    MV: So let's go to this slide.
  • 55:29 - 55:37
    Mic3: Yeah so all you get from this, is the
    keystream that is used to encrypt
  • 55:37 - 55:42
    the the Msg4, right,
    that's all you get?
  • 55:42 - 55:46
    MV: Yes, but you can already use that to
    start decrypting frames and what you can
  • 55:46 - 55:51
    do as an attacker, you have several options.
    The first thing you can do is, you can keep
  • 55:51 - 55:55
    triggering new handshakes by
    deauthenticating the client, so you can
  • 55:55 - 56:03
    always decrypt one packet at a time.
    What you can also do is, you can wait with
  • 56:03 - 56:09
    sending this retransmitted Msg3
    to the clients, because sometimes you know
  • 56:09 - 56:12
    the encrypted data that is sent. So you
    know that a packet is an ARP request, you
  • 56:12 - 56:17
    know that the HTTP requests. You can capture
    quite some packets where you know the
  • 56:17 - 56:22
    content, to derive some known key stream
    and once you have that, you can forward
  • 56:22 - 56:28
    Msg3 to trigger a key
    reinstallation and then you have collected
  • 56:28 - 56:34
    quite some key stream to be able to
    decrypt several packets at a time. So you
  • 56:34 - 56:39
    can use tactics like that, you can rely on
    the packet length to basically determine,
  • 56:39 - 56:44
    what the type of packet is, where you have
    known plaintext and you can use that to
  • 56:44 - 56:48
    derive new key stream and there are a lot
    of ways to play around with that.
  • 56:48 - 56:52
    Mic3: Yeah but, all you get here is the -
    because the key stream that you get is
  • 56:52 - 57:00
    already being used immediately, because
    it's being used to encrypt Msg4.
  • 57:00 - 57:03
    MV: Well, we know the content of Msg4
  • 57:03 - 57:09
    and we abuse, that Msg4 is
    encrypted to derive known key stream and
  • 57:09 - 57:14
    we can then use that to encrypt data
    frames, which we do not know and... we
  • 57:14 - 57:16
    should discuss this offline.
    Mic3: Yeah.
  • 57:16 - 57:20
    Herald: Perhaps this is for later
    discussion with more in detail. Now we
  • 57:20 - 57:25
    switch to number two... number four, I
    think it is. Yeah, thanks.
  • 57:25 - 57:31
    Mic4: Yes. Great find really and an
    awesome talk. Could you maybe elaborate a
  • 57:31 - 57:38
    bit on how to still use the advantage of
    formal verification in the sense of, let's
  • 57:38 - 57:44
    say, the flaws that it has, it gives a very
    false sense of security in your sense, how
  • 57:44 - 57:49
    can you still benefit from formal
    verification?
  • 57:49 - 57:56
    MV: Well, I think the attitude we should
    adopt is, that formal verification of code
  • 57:56 - 58:02
    or of algorithms increases the amount of
    trust we can put into a program or into a
  • 58:02 - 58:07
    protocol, but it's not just because it's
    formally verified that it's secure.
  • 58:07 - 58:12
    Perhaps one of the attitudes that people
    had was: 'oh it's firmly verified, it must
  • 58:12 - 58:18
    be fine'. We should abandon that attitude
    and instead we should say: "Ok, it's
  • 58:18 - 58:22
    formally verified but, you know, let's
    check if the model they used reflects
  • 58:22 - 58:28
    reality. Let's see if the proof is correct"
    and so on. So, we should still employ a
  • 58:28 - 58:33
    formal verification but we should just
    treat it as additional evidence, that
  • 58:33 - 58:42
    something looks secure.
    Herald: Ok, there's another question on mic 2
  • 58:42 - 58:47
    Mic2: The first part is on the slide
    you're currently on. As far as I
  • 58:47 - 58:53
    understood it in the talk, the
    retransmission of Msg4 is not
  • 58:53 - 58:57
    supposed to be encrypted by the standard.
    MV: Correct.
  • 58:57 - 59:02
    Mic2: So if you follow the standards, you
    shouldn't have a problem here.
  • 59:02 - 59:06
    MV: No, then you still have a problem,
    because what you can then you do, is just
  • 59:06 - 59:10
    wait for a data packet where you know that
    contents of, e.g.it can be an ARP
  • 59:10 - 59:15
    request, you can derive most fields of
    that, it can be a DHCP request, it can be
  • 59:15 - 59:22
    be a TCP SYN packet, or it can be some
    plain text HTML frames. E.g. there
  • 59:22 - 59:29
    has been work to fingerprint the length of
    HTTP requests, to be able to determine
  • 59:29 - 59:32
    which page you are visiting, so purely
    based on the length, we can determine the
  • 59:32 - 59:37
    contents of the website you are looking
    for. We can then derive known plaintext
  • 59:37 - 59:44
    and basically there are a lot of ways to
    predict the content of a frame, to then
  • 59:44 - 59:52
    derive known keystream and to then trigger
    a key reinstallation attack to then abuse this.
  • 59:52 - 59:55
    Herald: Ok we have time for one last
    question. Mic number 1?
  • 59:55 - 60:05
    Mic1: Um, so as far as I understood your
    research, and so we, if we have like 11W
  • 60:05 - 60:11
    deployed in the network, we are still
    vulnerable to the attack, because as 11W
  • 60:11 - 60:20
    specifies the encryption, I'm supposed by
    this amendment, is also done by the
  • 60:20 - 60:28
    encryption use on the network like before,
    so 11W is not really a way to secure
  • 60:28 - 60:34
    the network?
    MV: Well, if I got it right, 11W is, one of
  • 60:34 - 60:36
    the things it does, is protect the
    management's frames, if I'm correct?
  • 60:36 - 60:39
    Mic1: Yes.
    MV: Yes.
  • 60:39 - 60:45
    MV: So using that does not defend against
    these attacks.
  • 60:45 - 60:51
    Herald: Ok, I think there's still quite
    details, where people are curious about,
  • 60:51 - 60:55
    because it's everybody starting this
    question "as far as I understood". So I think,
  • 60:55 - 60:59
    this was a really nice comprehensive talk
    and I want to thank you. And everybody who
  • 60:59 - 61:04
    has more questions, perhaps can find you
    here and ask you more or have a look into
  • 61:04 - 61:07
    the paper, perhaps read everything in
    detail there.
  • 61:07 - 61:12
    So, please another big round of applause
    for Mathy and his amazing talk!
  • 61:12 - 61:13
    Thank you very much.
    MV: Thank you!
  • 61:13 - 61:21
    applause
  • 61:21 - 61:26
    34c3 outro
  • 61:26 - 61:42
    subtitles created by c3subtitles.de
    in the year 2018. Join, and help us!
Title:
34C3 - KRACKing WPA2 by Forcing Nonce Reuse
Description:

more » « less
Video Language:
English
Duration:
01:01:42

English subtitles

Revisions Compare revisions