 Okay, so our next speaker for the day has just finished his PhD on security of yeah, I think that deserves a round of applause on the topic of security of a WPA, TLS and RC4. He's now doing his postdoc and focusing on wireless security, so and the next talk the title is predicting and abusing WPA2 80211 group keys. Please give a big round of applause to Mati van Hof. Okay, thank you for the nice introduction. So I am indeed Mati van Hoef and I'm going to present predicting and abusing WPA2 group keys or more officially 802.11 group keys. So first a quick introduction to Wi-Fi security. What was the state of Wi-Fi security before I did this research? Well, essentially Wi-Fi security has been thoroughly investigated. There have been a lot of results. For example, we know with the very first security algorithm of Wi-Fi wired encrypted privacy, in other words, web. It was horribly flawed. You probably all noticed that you can crack a web network within mere minutes. In fact, if you download the latest tool suite of Air Quack NG and there is enough traffic on the network, you can really obtain the pre-shared key of the network within only a few minutes and sometimes if you're lucky, even seconds. So the first attempt by the 802.11 group to introduce a security protocol, it didn't really went that well. We also have other attacks recently against wireless networks on in particular against WPA2. One example, which is quite recent, is that some vendors or some ISPs, when they hand out their router, they initialize it with a default password with a default passphrase and it turns out that these are rather predictable. In particular, this default password, which should be shown somewhere here on the back of your router or on the car to receive with it, it was derived from the MAC address. So if you want to attack one of these networks, you simply have to sniff the network, determine the MAC address and from that, you could derive the shared key, the pre-shared key of the network. And similar to this, you also have dictionary attacks against the WPA2 handshake. So these are all known attacks and the way that this dictionary attack works is essentially, you can force a client to disconnect from the network and then it will reconnect with the network. And if it reconnects, it of course performs a fresh handshake with the access point to negotiate session keys. Now, the bad part about this handshake is that as an attacker, you can capture the four messages that are exchanged in this handshake and then you can perform offline guessing attacks at the password of your network. And if the handshake would have been better designed, these kind of dictionary attacks would not have been possible. Unfortunately, the way the handshake was designed, you can make a capture of the handshake, you can process this offline on these kind of dictionary attacks are unfortunately possible. I think a few years ago, there was also a attack which shows that using a bit of social engineering as well, you can even attack WPA2 enterprise networks. And these are networks where you have to type in your username on the password. So think of Iterom or your company network, or also here in the CCC network, you also have one of these enterprise networks as well. And the idea behind this attack, I'm not going to go in detail here because these are known, but one of the parts that they use is they broadcast a network with the same SSID name as the target network, but they include a small space bar behind the name. And if you then look at the network name in your operating system, you won't notice that the network is, for example, Iterom and then a space bar after it. So it's essentially a completely new network. And if you connect to a completely new network, your operating system won't really complain because otherwise it would say, okay, previously you connected to Iterom, now it certainly uses a different certificate, this is bad. But because the space was after the SSID, your operating system will think, oh, it's a new network, everything is fine. But as I mentioned, I'm not going into detail, I'm just mentioning it as related work in a sense. Lately there have also been a few more theoretic attacks against WPA T-CIP. They are similar in spirit to the text on the web, except cracking WPA T-CIP is much, much more difficult, even though there are also other weaknesses in WPA T-CIP, so you should not use it. But there are theoretical attacks that allow you to recover the session keys as well. Though they are very hard to execute in practice. So why am I telling you all this? Well, if you look at all this previous research about the security of wireless networks, we can see that a lot of this work is focused on the security of the pre-shared keys or of the negotiated session keys. So that has received a very large amount of attention from the research community and also from hackers. However, the keys that are used to protect broadcast traffic, so the group keys, they are not widely used. So here is something strange with the slides. For some reason, one slide is missing. But anyway, so these group keys, they are used to encrypt broadcast on multicast traffic. And that is in contrast with session keys. So for example, if you see here, your access point, it has a group key. And it also has a session key for every client that is connected to the network. So what we noticed is that the security of these negotiated session keys is properly studied, but the security of the group key is not studied. So what I did during my research is that I investigated how these group keys are managed during their full lifetime. So what do I mean with the lifetime of a group key? Well, we have our access point here. When you start your access point, so when you start your router, the first thing that happens is that it generates a fresh and random group key. And here we notice that the random number generator, so the RNG that is used to generate this group key is flawed. So the standard suggests a bad random number generator as a reference implementation. And we will see in practice that certain vendors also implement a random number generator that is predictable. And this will allow us to predict the group key. So that's essentially the first stage of the lifetime of the group key when it is generated. The second part is when a client connects to the network. When it connects to the network, it performs this four-way handshake. It negotiates the session keys. These are sometimes also called the pairwise keys. During this handshake, the group key is also transported to the client because of course it needs to know the group key to be able to decrypt broadcast on multicast traffic. And what we found here is that we can manipulate this handshake as a man and a middle attacker. And we can then use, we can then force uships of RC4. Meaning the group key when it is being transmitted from the access point to the client is encrypted using RC4. RC4 is an insecure cipher. You should not use it. In this context, we will see that we also, currently it's a theoretical attack, but we do have an attack against the way RC4 is used in this situation. Now, also one of the more interesting parts is also, let's say that we now as an attacker have the group key, what can we do with the group key? Because of course, if we know that key, we can decrypt broadcast on multicast frames, we can inject broadcast on multicast frames, but can we do even more? And here we're going to show that using some clever tricks, we can use the group key to inject unicast IP traffic. So not just broadcast traffic, but also unicast traffic. And we will even show how we can decrypt nearly all internet traffic of the network. And then at the last part of the presentation, I'm going to propose a new idea on how to better generate random numbers if you have a Wi-Fi device. But the main part of the presentation will be these first three steps on in particular predicting the RNG and then abusing it to decrypt traffic on inject traffic. So before I get to the main content of the presentation, I'm going to give a little bit more background on how these group keys are used. So let's say we are in the following situation. We have our access point here, which has the group key of the network on which has the two session keys of the two connected clients here. Let's assume that in this situation, Client A wants to send a broadcast network over the complete network. Now, if Client A would send this broadcast frame itself, then there is a problem because there are certain situations where clients are out of reach of each other. So that's the hidden terminal problem. If Client A would broadcast the message, Client B would not receive it. So this was of course anticipated by the designers of the Wi-Fi protocol. So instead, what happens if this client wants to send a broadcast frame, at first sends it to the access point. And it will essentially send this frame with as the immediate receiver the access point. However, the final destination is the broadcast MAC address. Because the immediate receiver is the access point, it will be encrypted using the session keys. And when the access point receives this frame, it will also use the session keys to decrypt this frame, but then it will see, oh, okay, the final destination is actually the broadcast MAC address, meaning I will have to forward this to all clients. And of course, all clients are in range of the access point. So in this case, all stations will receive it. And when the access point sends the broadcast frame, the immediate receiver on the final destinations are both the broadcast MAC address, meaning in this case, the group key is used to encrypt on sent as frame. So the important takeaway message here is that only the access point normally will send real group frames because the client will first forward it to the access point as a unicast frame. So that's for the quick introduction. So as I mentioned, the talk will mainly be about predicting the RNG and then decrypting all traffic. So let's start with predicting the RNG. So the first question is, okay, does the Wi-Fi standard specify some methods on how to best generate these group keys? And it turns out that yes, they do specify a method. And in particular, they have a certain procedure for generating the group key that will be used. On the crypto people call this the key hierarchy that is being used. So it's actually fairly straightforward. When your access point starts up, it will generate a public counter value. So a random counter, it does not start at zero. It can start at any value you want. But it's public. So an attacker or outsiders are allowed to know this variable. Apart from that, it also generates a private master key on this has to stay secret. Otherwise, all your security guarantees are gone. So once you have generated these two fields, we simply take a hash of both of them. On the output of that hash is the current group key. And the current group key is also called group temporal key. On the reason they call it temporal is because you can refresh it every hour or every day or every 10 minutes. And that's also the advantage of this construction. Because if you want to generate a group key, it's very simple. You simply increase the public counter by one. You recalculate this hash value. And then you get a new group key. So this design seems very nice. Because if you want to generate a new group key, you simply increase this public counter by one. And you calculate a new hash. Unfortunately, this design is actually quite bad. Why is that? That is because these two values are only randomly sampled when your device boots onto new entropy is never introduced into the system. So if for some reason an attacker either compromises this key and knows it, he can predict all future keys. Or in our case, if the random number generator is bad, we can probably predict all future keys that are generated. So this is a bad design and should be avoided. Unfortunately, it is officially specified this way in the standard. So in principle, the standard recommends everyone to use this key hierarchy, this procedure. So okay, now we know that if we can predict these two values, we can derive our group key. So the next question is, how are these random numbers generated? Again, the Wi-Fi standard provides us with an answer because it suggests an example random number generator. If you read the standard, it actually sounds quite promising because it says the RNG that we use should generate cryptographic quality randomness. To show you the quote in detail, a station must be able to generate cryptographic quality random numbers. Once you can look in the appendix at section M5 to see how you can achieve this. So this sounds very promising. Until you actually go to the appendix, on there it says, whoa, wait a minute, what we're going to show is just an example solution. Ideally, you should extend it yourself. And of course, that's not really, this is a strange situation because in the standard itself, it says this RNG in the appendix is secure. But if you actually read the appendix, it says this is just an example solution. It may not be that secure after all. So we have an inconsistency in the standard here. And just to come back to the text that is shown in the appendix, it says that, okay, you probably should combine it with other recommendations on how to generate random numbers. This is expository only. Again, you should probably improve this, which is very strange to see this kind of language in a standard. So we basically have an inconsistent description here. It says that it should be secure, then it says it's not really secure. So the question is, how secure really is this random number generator? And the next question is, how many platforms implemented? So let's look in detail at how the random number generator is implemented. And here we see that the standard basically defines a function, which is the RNG. And first and for all, it's a stateless function. I'll come back in a minute, why that it's a bad idea. But first and for all, it has a very vague description, even if they only meant this to be like an example solution to get people on the way. Because if you look at the code, there is a main Y loop here, a main loop, and it simply says, repeat this algorithm until it's random enough. They don't specify what this means. So that's very strange and suspicious. A bit suspicious as well as also at the end of the algorithm, at the end of the loop. So during certain parts of the loop they say, if the time is not available, you can simply set it to zero. So this line might not be that bad. If they include something like, if you set the time to zero, maybe you should include, should do more iterations of the main loop. But they simply say, oh well, if it's not available, you know, just skip it. So like I mentioned, the standard is a bit hard to interpret because they say it's an example solution. But in other parts they say it's supposed to be good. But even if they only meant it as an example for the vendors, this description is still just too vague. Now to come back to this stateless part here, the random number generator is executed on demand. And only when this function is being called is randomness collected. And again, this is a very strange design, because if you have a proper RNG, for example, the one in OpenBSD or the one in Linux, or the one in any decent design, basically, their entropy is constantly collected in the background. For example, you have your timing of interrupts, timing of packets, you have clock skew, and so on. Normally, all this randomness is collected in a so-called entropy pool. And then if you need randomness, you can extract a random number from this entropy pool, for example, using a hash or any other construct. But the fact that this function is executed on demand is also a very bad sign. So all that is not that promising. And if we then look at the actual events where it extracts randomness from, we can see that it's mainly based on the time stamp of that frames are arrived and also on clock jitter. So let's look at these two sources in detail. We have our frame arrival times. So if your router would be connected to an internet cable and there would be a sufficient amount of traffic, then you could simply collect this based on internet traffic. However, you don't always have the guarantee that there is sufficient traffic available. The standardization committee, the people realize this, like there may not be that much traffic available. So what they said is, no, if there is not that much traffic, simply wait until a client wants to connect and then send a few messages of the handshake, then abort the handshake, restart the handshake, then abort the handshake, restart the handshake until you captured enough frames. So this first one for all would be very time consuming. The second bigger problem is, if you are a client and you are constantly trying to connect with a network but it fails a few times, then your device will simply blacklist the access point and this will not work. So the fact that they even simply suggested using this is my opinion absurd. So the second source is the clock jitter on drift. So if you have a clock in an implementation and it's never completely accurate, there is also a small amount that you can't predict as an attacker. The problem here is that they don't specify a minimum resolution that the clock should have. So a vendor can use any clock at once, even one with a very low resolution, meaning only a very low amount of entropy is collected. And of course that's quite bad. So after I saw this, I thought to myself, okay, this is just basically a big mistake of the standardization people. Surely everyone realized that this was bad, aren't they implemented something better? But when I actually looked at codes, so yeah, this is really like, what the hell are you doing? So if you look at vendors, we have, for example, media tech. It used to be called also rallying. And they implement this random number generator almost as specified with a few changes. And those changes actually weaken it a bit more. They also did one good part, by the way. I'll come back to that in a minute. Then there's also Broadcom. The random number generator they use depends on the operating system that is being used. Then there is also Open Firmware, which is a good example of an embedded system on Terras host APD, which is the open source implementation of Linux. As you can see, they do it properly. So we did a very rough estimate of how many networks are run using this media tech or Broadcom implementation. So this was just using a very quick war drive around my city. And I determined whether the device is using media tech or Broadcom based on the fingerprint of the beacon. How that works is explained in a different paper. But essentially, I did a very, very rough estimate. At most, let's say 25% of networks could be vulnerable to this. I would say maybe 5% or 10% could be attacked using a text similar to the one we're going to present. Just to show that these are a bit popular and you might be able to use this in practice. But anyway, let's look at the first implementation, the one of media tech. So what did they do? Well, first and for all, they implemented the key hierarchy, so the procedure on how to generate these group keys as proposed by the standard. So just to recap, this is this construction where you generate two variables, one which is secret, the other which can be public, then a hash is taken onto the output as shown. They do improve this slightly, actually. So they do one thing that is good, namely instead of when they want to generate a new group key, instead of simply increasing the counter by one, they actually constantly generate a completely new random value for the counter. That's actually a very good decision, because then you are introducing new entropy every time you generate a group key. However, this group master key, that one is only sampled at boot time. Okay. So we now know how their construction works. Now the question is, how do they implement this random number generator on Can we then try to attack it? Well, this is the bad part of their design. They only use clock jitter to extract randomness on to collect entropy. In particular, it uses the so-called Jiffy's counter of the Linux kernel. So the Jiffy's counter is something that is increased every tick, but not every processor tick, but every logical tick. And I'll come back to that in a minute. So this RNG is likely quite bad. And this is good for us, because at least for us as attackers, because we simply have to predict the group master key on this public counter, which is also called the genomes, the group nones. And if we can predict both of them, we can derive the group key. So let's try to attack this RNG. As I mentioned, it uses this Jiffy's as the counter. The problem is, these Jiffy's have the best millisecond accuracy, which is rather low. In fact, it's really low. So this means in practice that the GMK, so this secret key, which is generated at boot, generally it always uses the same Jiffy's value, so the same clock values. So that means in practice, for the GMK, there are say around 200 to 300 possible values. At least if you have a, I tested this on my device, on for a specific device, on specific firmware version, then you have a limited set of possibilities. Of course, if you run a different firmware version, then some other things might happen during the boot process, influencing the time when these Jiffy's values are collected. But if you know the implementation, you are attacking, you have a very limited set of values. Then the second part is we have to predict this genomes value. On most routers, the group key is regenerated every hour, meaning this genomes value is also sampled every hour. So in order to predict this value, we need to know the uptime of the router to predict the range of possible Jiffy's values that were used. How do we determine the uptime of the router? Well, it's quite simple. The uptime is leaked in the beacons of most routers. So we simply have to sniff beacons, then we can estimate the uptime of the router, and then we can estimate the time of when this genomes was generated. So basically, what do we have to do for a successful attack? We need to capture one encrypted broadcast or multicast message. We have to capture also a few beacons to estimate the uptime, and then we can do a search through the whole key space. We tried this against our own router, so that's this one. Here we noticed, well, we implemented a program on the GPU, in particular on OpenCL to make sure we can do this in a timely matter. We found that using the GPU in my laptop, which is just standard GPU, you can even get better GPUs or even multiple ones, but even just on my normal laptop, I can crack the keys within three to four minutes. Thank you. So this is assuming the router also has an uptime of one year, and if the uptime is around one year, then there's also a lot of clock skew, meaning predicting the genomes is harder. So if I'm going to demo the attack in a few minutes, then I know that the uptime was very low, meaning I can reduce this number even further, because there hasn't been that much clock skew, meaning predicting it will be easier. So this, in a sense, is also a worst-case estimate. However, I do have to note that this is only if you are attacking one specific device. If you know which device you are attacking, let's say you don't know the exact firmware that is running, then you have to perform a bigger search. So the end result here is that you get both the master key and the current group key. So I planned a demo here. Now, Wi-Fi demos are always very risky, especially in a situation like this. So fingers crossed. So let me first try to mirror the screen. Let's hope we don't already fail here. Okay. So here I have a Wi-Fi device that is running in the monitor mode. And I have a script that will capture the frames sent by my router. So I already put it in monitor mode, so that is simply this script. Just execute some commands to put it in monitor mode. And I'm now going to capture packets that are sent by my router. And I made a Python script for that. So let's execute that on capture packets from my router. As you can see, it's now trying to capture packets, but nothing is received yet. And that is normal because the router is not yet started. So let's put it on. This was planned by the way to show you it's real. So now the router is booting. And in a few seconds, it should be receiving beacons from which it can derive the uptime of the router. You can see, there we go. We got a beacon. Now it's waiting for an encrypted broadcast packet. Now, this is one small limitation of the attack. As you can see, it was waiting until my laptop connected to this network. Because if no one is connected to the network, then there is, of course, no traffic. So there must be at least one client, or for some reason, your router has to send one broadcast frame that is encrypted using the broadcast scheme because otherwise there is nothing to crack. We don't have any data. So in this case, we captured this frame. So let's try to open this capture file. So you can see here we captured a lot of beacon frames. This beacon frame has a field here, which is called the time stamp. On from this we can determine the uptime. So here you can see it. Here it's very close to zero. And every time it increases, on from this we can determine the uptime of the router. There you go. On at the very end of this capture, we have this broadcast packet, which we want to decrypt. So let's try that. So as I mentioned, this works on the GPU. So first I have to type opti run to enable my GPU while executing the next command. So I simply have a script here. I'm attacking the MediaTek implementation, and I'm using the capture I just made. So now it parses this file here. It lists all the networks that we captured. In this case, because we are in a crowded room, I made sure that I only captured frames from my network to try to make sure that the demo indeed works. And you can see now it's trying to predict the group master key. And it has estimated that the Jiffy's values that were used there were around this number. And the Jiffy's values that were used for the genomes it has estimated around this value. Now you may be wondering why is this Jiffy's values so high? Doesn't it start at zero? This is actually very interesting, in my opinion. The Linux kernel starts at the Jiffy's value of minus five minutes. Why do they do that? Well, that's because if you are a developer, on there somehow is a bug in your driver that after five minutes when your Jiffy values overflows there is a problem that developers would very quickly detect issues if your Jiffy's value would overflow. This is just to explain why this number is so high, even though we just booted the router. And anyway, you can see that we successfully found the group key here. And it even decrypted the packet for us. So that worked. And it wrote the single decrypted packet to a file as well. So let's open that as well so you can see that it indeed works. Here, that's the wrong file. On here you can see the decrypted broadcast packet was an ARP packet. On here you can see the decrypted packet. So we indeed correctly predicted the group key until we were able to decrypt this packet. So let's now try to switch back to the presentation. Okay, I will have to go through these slides again probably. Okay, so that was the demo. The demo gods have praised us. Thank god it worked. So now let's come back to the other vendor, the Broadcom vendor. So as I mentioned, this depends on the operating system that they are using. In particular, if they are using Linux, then they implement the group key hierarchy as specified in the standard, but they simply read randomness from def uRandom. So that is much better than the random number generator proposed in the standard. However, a few years ago, there was a paper called Mining Your Peace and Queues by Henninger et al. They showed that specifically on embedded devices and on older Linux kernels, def uRandom might be predictable. So this means that on certain devices, def uRandom is predictable, and in turn all the group keys might be predictable as well. Now if you run a newer Linux kernel, this should no longer be an issue. However, because a lot of routers use an old kernel, this might be an issue. I haven't tested this. This is simply based on their paper that def uRandom is not ideal for older kernels essentially. So that's for Linux. This Broadcom implementation also runs on VxWorks on the ECOS. So for those of you who don't know what these operating systems are, VxWorks on the ECOS, they are both essentially real-time operating systems. VxWorks is proprietary. It's used a lot in aerospace, so it's used in the Mars lander. It's used by SpaceX. It's also used in drones. And of course it's also used on certain routers and access points. Then there's also ECOS, which is essentially similar. It's also a real-time operating system except it's open source and it is again used in aerospace and it's also used by the military in certain situations. But of course we focus on when it's used in the router and when it's used as an access point. So we see that in this case Broadcom again implements the 802.11 group key and for random numbers it has simply takes the md5 hash of the current time in microseconds. So again that's not ideal at all. There is also another disadvantage of their implementation. They use this public counter in the handshake, in the four-way handshake that you use when you connect to the network. Now this is perfectly allowed. There is nothing wrong with that. But it does make it easy for us as attackers because we can collect the value that was used here in the handshake onto the one that was used while generating the group key will be only a few numbers away from this value that was leaked. So really the only thing we have to predict here is the group master key. And if we have the group master key we can then again predict the group key. So one popular router which is vulnerable to this is the WRT54. At least if you have one that uses version 5 or higher then it uses VxWorks kernel. So if you have a router which is version 4 or lower it runs on the next. And of course if you run DDWRT on this you're also fine. But if you have version 5 of this device or higher then you might be vulnerable. Unfortunately I only had older versions of this router at home. So I simply simulated this attack. Again using OpenCL code. And even with just simply quite modest assumptions. I predict that you need around four to five minutes on my GPU to crack it. Let's say that for some reason my simulation is not perfect. Then you can use a more powerful GPU to still predict it. But again taking the MD5 of the current time in microseconds it's simply not sufficient to collect enough randomness. So that concludes both these implementations. Then we also have two other examples. The first is called OpenFirmware. On the second is hostapd. So OpenFirmware essentially it's a simple open source BIOS system. What was really surprising to me is that during the BIOS these people have very basic support for Wi-Fi functionality. At least as a client. You can even connect to a WPA2 secured network. Now for me that was very surprising to see that BIOS supports Wi-Fi. But they do. Now I do have to say here that they only implement client functionality. So they don't implement access point functionality. So they don't actually generate a group key. However they do use a random number generator to generate other values that are used during the Wi-Fi handshake. Ante use a very very simple methodology. They simply take the amount of ticks that have occurred since boot. They run that to a linear congerential generator which is simply a deterministic function and that's used as the random number generator. The output of this is hashed to get a sufficiently long output. But still this is very easy to predict. And we included this because this is a very good example of an implementation that is running on an embedded system where there is no kernel available to provide you with random numbers. So in this case we are in the BIOS. There is no kernel. There is no libraries we can use to generate random numbers. But we see that in that situation very bad solutions are used. At the end of the presentation I will show a way where even in these scenarios in embedded system we can still try to come up with good ways to generate random numbers. So as last example we have host APD which is essentially the most used access point on Linux for example it is used by Android if you set up a hotspot. And they have a very good implementation. They implement the 802.11 group key. They extended it to include entropy every time a new group key is generated. So that's very good. Even better than that they read from def random on boot and for some reason there is not enough entropy available. It will simply wait until the first client connects and then it will try to read again from def random. If there still isn't enough entropy available it will simply reject connections. So in other words if you use host APD everything should be fine. Of course if the kernel and everything works properly. So that concludes how we can generate and predict this group key. We will now explain how we can, so this is the second main part of the presentation, how we can exploit this group key to inject on decrypt traffic. So let's start with a simple case. We want to inject a unicost IP packet and we want to send it towards a client. So your initial ID maybe okay you have your IP packet right here. You simply put that into a broadcast Wi-Fi frame. So here we have the Wi-Fi header of course very simplified. Basically we have flags in the header which says that this broadcast frame is sent towards the client of our network and the receiver is the broadcast MAC address. Because the receiver is the broadcast MAC address this IP packet and everything with it is encrypted and protected using the group key. However this will not work and why is that? Well the client notices that this unicost IP packet is received on a grouped address Wi-Fi frame and this is the so called whole 196 check and basically says you should reject packets that are sent on a group addressed link layer but are sent to a unicost IP address. In other words this technique will not work. So how can we try to bypass this technique? Well the realization we have to make is that this check occurs when a link layer packet is being passed on to the network layer where we have these unicost IP addresses and an access point only works at the link layer. So if we can somehow abuse the access point then we might be able to bypass this check. So let me simply explain the technique that we're going to use. So we have our network here with the victim with the attacker which wants to send a packet to the client but what the attacker will do it will first send this IP packet towards the access point. So again we have our IP packet here. Now we add a bit more complicated Wi-Fi header which says this group frame, this broadcast frame is sent to the access point. The immediate receiver is in this case the broadcast MAC address. However the final destination of the frame is the victim. So what will happen if the access point receives this frame? Well it will notice okay the frame is indeed destined for me. I will use the group key to decrypt it because I did receive it on the broadcast MAC address. Everything is fine. And then it will notice while it's still operating at the link layer. Oh but the final destination is actually the victim. So I have to forward this packet to the victim. The access point of course has the session keys, the pairwise keys of the client. So it will simply take this IP packet. It will encrypt it using the session keys for us. And then it will simply send it to the victim for us. And now when the victim receives this packet everything seems okay. We have our unicast receiver addresses, a unicast IP address. It is properly encrypted. So everything is okay and the attack works. The second part is that we want to also decrypt packets. The idea behind this is very simple. It's also very simple to explain. We simply are poison the router on the client so that the IP address of the gateway on the IP address of the client are the broadcast MAC address. And then both the router on the client will send unicast IP traffic through a broadcast MAC address. And it will encrypt it using the group 3 group key which we have so we can decrypt this packet and then forward them to ensure that connectivity stays on that the client doesn't notice anything. So that's actually quite simple. How we can we prevent this? Well the first thing is that if the access point receives a broadcast frame but with a unicast final destination it should not forward these. On an even better counter measure is that in an infrastructure network, so not necessarily in a mesh network but in an infrastructure network where you have an access point, the access point should simply ignore frames that are received on a broadcast MAC address. And then these issues would be avoided. So I would say that Ata was the most fun part of the research. We're now going to look at a theoretical attack against the handshake that is being used where we can force usage of RCE4. So okay, let's first quickly explain how the handshake works. So we have our client here which sometimes is also called the supplicant during the handshake and we have our access point. So the beginning is very simple. Your access point is constantly transmitting beacons. Those beacons contains the features of the access point. For example whether it supports 802.11 or whether it supports AC and it also includes the supported ciphers of the network. In practice this basically means whether it supports WPA T-CIP or AES CCMP. Then the client will select either T-CIP or AES. Anna will send an association request to the network. On this packet here basically tells the network I want to join. On this is the cipher I want to use. And reply to that the access point generates random nonce. The client will also generate a random nonce. So these random nonsense are used to prevent replay attacks and they are used to assure that fresh session keys are negotiated. So here we have the access point nonce, so the A nonce and we have the supplicant nonce also the client nonce. So it's the same as the client nonce which is the S nonce. Once they both have received these S nonces they can receive they can derive the session keys. After this first stage of the handshake we are essentially going to confirm that everything was okay that there was no attacker. And the access point is going to send the group key the group temporal key in message tree of the handshake. On the message tree it also includes an authenticated cipher list of the ciphers that the access point supports. So this is to prevent downgrade attacks. Let's say that we have a man in the middle attacker which here says okay I only support the old T-CIP cipher then the client would connect using T-CIP. However at this stage the real access point which send message tree which includes the real cipher list which is authenticated using the password of the network essentially. Meaning an attacker cannot modify the packet on the client would notice after receiving message tree if there was a possible downgrade attack because this authenticated cipher list might not match the ones that was received in unprotected beacons. So the problem with this design is that the group key here is transmitted unencrypted before the client can prevent undetected downgrade attacks. So what can an attacker do here? An attacker can put up a rogue access point it can modify the beacon messages and say hey I only include I only support WPAT CIP which means that the client will connect using WPAT CIP. And in case that the session cipher is WPAT CIP then this group key here when it is transmitted to the client is encrypted unprotected using RC4. If AES would have been used then we also would use AES to protect the group key and everything would be fine. However in this case we are using RC4 if we can if you are performing this attack. And RC4 is of course quite bad. So for the crypto people around here I'm very quickly going to explain how RC4 is used. You basically have a 16 byte initialization vector which is public. You have a 16 byte secret key on the first 250 key stream bytes are dropped. This is actually a very strange construction if you're a bit used to RC4. I'm simply going to intuitively explain the problem with RC4 in this case and also the problem with RC4 in general. Here you see a graph which kind of illustrates the behavior of RC4 in this case. So normally if you would make these kinds of graphs for a secure cipher for example for AES this would be completely white. So what does this graph illustrate? Well say for example here you are at key stream position say 300. If we then go look at key stream value let's say around 90 we can see that there's a blue dot here. What does that mean? That means that the key stream byte at position 300 is slightly less likely than uniform to contain the value 90. Normally this should be uniformly random. Normally if you have a proper cipher every key stream byte should occur as often as all the others. However you can see here in the colors that these blue key stream bytes at certain values occur less often on these red ones occur more often than others. On this graph depends on the specific analyzation vector that is being used. So the only thing I would take away from this slide is that if you use RC4 some key stream values occur more often than others and we can abuse that in an attack. So if we were to perform similar attacks against the ones that were executed against SSL on HTTPS in a few recent years then we can see it's still a theoretical attack because it would take around 50 years to execute. The reason is because we need to collect a lot of encrypted traffic to perform our crypt analysis. In the case of Wi-Fi this is very time consuming to do. However attacks only can better. In fact a few weeks ago I found a trick to execute these handshakes more frequently meaning this time would be I think at least divided by two or three. So let's say that someone would put more time in this we could probably lower this value more and more every year. So the takeaway messages from a cryptographic standpoint RC4 is broken and you should simply not use it anymore. So the counter measure is if you have a network at home simply disable WPA2 T-CIP. So if you have a network not only should you select that it has to use WPA2 you have to explicitly configure it to only use AES. In that case you are safe against this specific attack. So finally the last part of the presentation is just a very short short suggestion on how we can improve the random number generator. We want to make sure that the improvement that we suggest even works on embedded systems where there is no kernel available and where there is very little chance of collecting randomness. Well our observation is essentially well okay we have a Wi-Fi chip on this Wi-Fi chip can monitor all the Wi-Fi signals around. So why not simply extract randomness from all the Wi-Fi frames that we receive. In other words why not collect randomness from background noise. And we actually found one device it is this one. This has a so-called spectral scan feature and this means that this chip is able to collect a lot of samples of the current Wi-Fi background noise even if there is no traffic or nothing is going on. And we can generate a very large amount of samples every second. The current downside is that this is a bit energy. This takes a lot of energy so you can't run this very long. But we did implement this idea to extract randomness from the background noise of the Wi-Fi channel and we did a few statistical tests on this and our results were promising. It shows that we can indeed extract randomness from background noise. Now this is just a proposal. Some more research here is needed but I did think that Wi-Fi vendors should provide a feature that common Wi-Fi chips exports some of this randomness which can then directly be used or it can be used by the kernel to strengthen the current pool of randomness. So that concludes my talk. There are a few important lessons to take away here. The first is if you have a random number generator always check the quality of the output and especially if you put this in the standard don't put very bad example algorithms which are really bad. If you design a specification what you put in there should be good and it should work. Otherwise just reference an external source where this is explained better. And to protect, to defend against the attack where we decrypt all traffic of a network like I mentioned the access point should ignore any frames that are received on broadcast MAC address or which should simply not forward unicast frames that are sent on a broadcast MAC address. Finally regarding the protocol that is used in the handshake you should try to avoid sending sensitive data before trying to protect downgrade attacks. So that concludes my presentations. If there are any questions feel free to ask. Thank you Mati. We have a few minutes left for questions so if you have any questions please line up next to the microphones and ask your questions make good use of our time. If we have any questions from the internet yes please. Yes two questions from the internet. The first one would you consider WPA2 with a pre-shared key still safe? If the pre-shared key is good unpredictable then these type of dictionary attacks they are no longer possible however you still have the issue of the group key and in fact this group key which is badly generated this applies to both enterprise networks on networks that use a pre-shared key. Currently I believe that the handshake that is used in Wi-Fi can be improved so if you use a pre-shared key I don't consider it as strong as an enterprise network where you have proper credentials so I would say that an enterprise network is more secure in most cases however as a general user if you have a complex pre-shared key then you're still good. Okay question from here. For the art proofing did you consider a gratuitous ARP offer on the networks? Because you already have access to the broadcast so Well I think that's what we used to poison the entries of the client so we send a broadcast ARP packet to poison the client on the router if that explains your question Yeah but you can explain all the clients in the network should you send a gratuitous ARP so you basically broadcast the ARP entry to anybody on the network just not one single client with the Unicast? Well you can send it to any client you want you can say I want to inject traffic of this client or you can maybe try to send it to all clients I haven't looked at that much in detail I just tested if you want to attack one client that works if you want to attack another client you can just do the same attack Okay thanks Yes Um have you for regarding your problem I have a very access point sends the broadcast packets further as a Unicast packet Is it demanded in the standard to do it this way or have you checked with all implementation do it this way or only some? That's a good question I don't know exactly what the standard says what I do know is that not even all implementations implement this whole 100 and 196 attack so there you can even directly send frames to the client without needing to abuse the access point so I don't think that this idea of forwarding packets is explicitly mentioned in the standard I think they just haven't thought about that but I would guess that most implementations would be vulnerable to this forwarding trick through the access point I mean I would be surprised if certain vendors thought about protecting against that it could be but I think the chance is low Okay, last talk last question sorry no no okay then I think we're done again big round of applause for a great talk to you