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