 So, I'm going to talk about Bluetooth Blue Energy 5 PRNG today for fun and jamming and maybe more. So for those who don't know me, I am a security evangelist and also a senior security researcher, a digital security, a French IT security company specialized in the IOT. And I'm also the main developer of BTAD Jack, or BTAD Jack, which is a BLE Swiss Army knife. So, we are going to talk about BLE 5 and especially what's new in BLE 5 specifications and I will go through some specific features and also some interesting stuff in this protocol. So first of all, I'm going to recap what BLE is for those who are not familiar with this protocol. So this protocol has been introduced in 2010 as a Bluetooth smart, so this is the first name of this protocol in Bluetooth code specification, version 4.0. And it has evolved since then, version 4.1 in 2013, 4.2 in 2014, version 5 in 2016, and last version 5.1 this year, at the beginning of this year. So it's evolving very quickly as a protocol and it's designed to be very effective. So I'm going to go through some of the things that are very effective. So people behind this protocol produces a lot of, produce a lot of different versions, but the industry, it's difficult for the industry to keep up with this evolution. This protocol provides some security mechanisms such as pairing, so you can exchange keys between two devices before to be able to encrypt communications. And this pairing mechanism can be done with the PIN code, so this is something very easy. You just exchange a six digit PIN code between two devices and you derive some keys from this. Also from out of the data, and also edit some, edit the curve, defend the negotiation. So this is something provided by this protocol and it's cool. Some version of this pairing are not very secure as it was demonstrated before, years before, but some of them are pretty strong such as the elliptic curves. This protocol also provides secure connections, so that means you can secure connection between two devices. And this is very interesting because this secure connection, BAD secure connection is pretty strong when it's correctly implemented in the, in the applications. And this secure connection provides encryption and authentication. That means nobody can tap into an existing connection or even inject some malicious packets in this, in a specific connections. And last but not least, there is also what we call the channel selection algorithm. So to make things clear, clear this Bluetooth low-energy protocol uses channel hopping to ensure, to make these connections reliable. And this channel hopping mechanism is very simple. When two devices create a connection, they're going to jump from one channel to another in order to avoid packet collisions. So this allows the connection to be steady, you know, even if there are a lot of devices in the same room. And this channel selection algorithm is not a security mechanism, but when it comes to sniffing, when you are trying to sniff a BAD connection, this can make, this can be an issue because you need to know what this algorithm is and how to recover these hopping sequence in order to follow an existing connection. So this makes sniffing complicated. There are also well-known attacks, especially on BAD4, which is the first one, sniffing. You can easily sniff BAD connections. So this is pretty straightforward. Even secure BAD connection when the pairing is not so secure. You can also jam an existing connection. This is what I showed last year at DefCon with BTLE Jack. So it's possible to disconnect two devices and once the device is disconnected, then it advertises again and you can connect to it and take control of it. But you can also hijack a connection. That means you can force a disconnection from one device to another and then exploit this connection without the other device notising the disconnection. So it's possible to take complete control over a device this way. So again, you can do this with a lot of different virus hardware. So on the left of the screen, there is the Ubertooth, which is a well-known device used to sniff BAD connections. In the middle, the other fruit, blue friend, LA sniffer, which is the one of the first alien Bluetooth known as a sniffer available on the market. It costs around 40 bucks. And on the right of the screen, there is the micro bit, which is a British broadcasting company sponsored board developed or designed to teach UK students how to code. And BTLE Jack uses this last board, this micro bit to allow attackers to sniff, jam and hijack some connections. Let's go back to the new features introduced in BAD 5. BAD 5 introduces a better throughput up to 2 megabits per second, a better range, up to 800 feet or 240 meters, and an improved coexistence. I'll go very shortly for these first two, better throughput, a better range. Basically, it adds two new files to the Bluetooth low-energy protocol. The 2 megabit per second uncoded file that doubles the speed of the any BAD connection, so you can send more data in the same amount of time. And also the AD coded file, which here improved the range, four times the actual run for BAD 4, but at 125 kilobit per second speed and two times the same range at 500 kilobit per second. So this is some kind of trade-off you're going to do between range and speed. If you have a look at the packets sent over these two new files, there is the AD coded file, which is a new file introduced in BAD 5, and there is another file, the AD uncoded file, which is the actual, the BAD 4 file. And in these packets, you will find an access address, which is a 32-bit value, identifying a connection between two devices. But the problem is that the hardware we're using, such as the micro-bit or even the Adafruit booth and Elie Sniper, this hardware cannot cope with these new files. And that's pretty much the issue here. So our hardware may be useful, but for these new files, this can be a problem. So we're going to cover this later. The main point here is that the BAD 5 protocol introduces a new channel selection algorithm. So the old one is mentioned here. This is a very simple sequence generator based on some modulo. And the new channel selection algorithm introduces a PRNG based random generator, PRNG based channel selection algorithm. So this is based on the random number generator. This is a problem for us because as Mike Ryan showed in 2013, it was very easy to recover a key value of the first channel selection algorithm, which is the up-ink value mentioned in this slide. But with the PRNG, the task is much harder because you need to break this random number generator to be able to sniff, hijack and jam an existing connection. Luckily, the device is implementing this channel selection algorithm, advertise a very specific bit. And if this bit is set, the CH cell bit, then this device supports this new channel selection algorithm. So, basically, what are the consequences regarding known attacks on BAD 5? First of all, there is a completely different new hopping pattern used. So, basically, the old version, the first channel selection algorithm generates a 37 channel sequence. And this new channel selection algorithm generates a 65,500 and 36 channel sequence. And basically, the device will loop over the sequence. So this is more complicated. And our first approach we got when we were developing the BAD 4 tools couldn't work here. So sniffing new connection is still possible because you only need some software able to follow this new channel selection algorithm. Because at the beginning of the connection, you get everything you need to synchronize with this connection and follow packets. But as an attacker, we won't be able to jam or hijack BAD 5 devices because the connection is always already established. And we don't have these values used to compute the sequence of channels. We need to go to synchronize and follow the connection. So, we also need a new hardware that supports BAD 5 new files, but that's another question. It's just like some guys at BTC decided to introduce this PRNG in order to mess up with the actual tools. Well, this is what I believed when I started this research. So, let's see. Let's have a look at the random number generator. First of all, it uses a channel identifier value, some kind of value as a seed, which is a 16 bit value. This random number generator relies on basic operations, some add, multiply, XOR, bit permutation and so on. And it also uses some channel remapping, but this is what's the same with BLE4. This channel identifier value is computed from access address. So, this is the 32 bit value identifying your link between two devices. So, basically identifying your connection. And the computation is the following. You take the access address, bit 0 to 15, and your XOR, this value, 16 bit value with the access address, bit 16 to 31. So, you get a 16 bit value. And then we are going to use a lot of computation and a specific wording called MAM for multiply, add, mod. And basically, this is what performs some computations. And takes two values, A and B, 16 bit values, and produces a 16 bit output. And this is just three times in a row. These are some other computations in between to create a random number. Based on this random number, then we compute the actual channel for a given counter, a given value of the counter used here. So, when this, when this channel selection algorithm generates a sequence, it goes from a counter from 0 to 4K. And then generates every possible channel. And this, this creates a sequence of channels and the devices will go over, loop over this sequence. So, when I saw this, I was like, whoa, what's this stuff? What, what the fuck? And I wasn't alone. I found some people on Twitter also complaining about this specification and especially this PRNG. Well, maybe there's something to do. If you have a look at this generator, then you may have noticed that the channel identifier, which is a 16 bit value, is computed from the access address, which is basically public. So, we need this to sniff in connection. So, this is a non-value. And also, the next value is generated from a counter, next random value generated from a counter. So, not from some kind of internal state that usually PRNG is used to, to create another random value. So, since access address is public, then we can go from 32 unknown bits to 16 unknown bits. So, this is quite easy. And this PRNG, well, is it really a PRNG? If you, if you look at the specific specification, then we know that the channel identifier is constant since it's derived from the access address. And what this function does, it generates a fixed sequence of 65,000 values indexed by a counter. Normally, this counter bears random number generators are used to parallelize, sorry, in French. This is a very easy excuse, but anyway. Yeah. So, this, this generates a fixed sequence of values. And then, um, this is very interesting for us for, you know, leading the attack. But what this function does, in fact, just monomize some kind of channels and that's it. So, what do we need to break it? If we consider the channel, just consider the channel identifier as known, you know, since this is derived from the access address, we are left with a 16-bit unknown value, which is a counter. And if we can figure out where we are in the sequence of this 65,000 and 566 values, then we would find out what this counter value is. And once we get this value, it's done, you can synchronize with a connection and then follow a connection and then jam, hijack, and do whatever you want. So, how to get the counter value? As an attacker, we can only monitor, uh, some events. Um, and these events are the following. We can determine when the packet is received on a specific channel. And based on this, you can also determine when, uh, the time between two packets received on two different channels. So, basically, we can deduce some thing from, uh, some measures we can do on this, uh, on a specific connection. If all 37 data channels are used, then the, uh, channel selection algorithm uses a very simple equation, a simple computation to, to derive the channel for a specific counter. Uh, but if not, if this, uh, if these channels are not all used, then this is more complex. But in fact, this, uh, it doesn't make things more complicated, uh, in the, in this way. But I, I will focus on the first case. Uh, the first case is that we are going to use all the 37 data channels to make things simpler. My first approach was to, uh, use a sieve. Uh, I'm quite sure you'll, you know, but it was a sense to, sieve used to find prime numbers. We are basically doing the same. Our goal is to eliminate every possible candidate in multiple rounds and in the smallest number of rounds to be more precise. The prerequisite here to do this is to be able to, uh, to, is to know the hop interval value, which is basically the time between two hops in the, uh, hopping mechanism. So, how it works, we are going to consider a counter of zero. So, just say that it's, it's zero, it's uh, hypothetical. It's not the real value we are looking for. And we compute, uh, channel C zero from this, uh, period function with this candidate counter and, uh, based on the, uh, channel identifier of course. And we wait for a valid packet. So we got a packet at time T zero on channel zero, on channel C zero. And we do the same on the next channel. So we increase the counter with the counter of one. We compute the next channel and then we wait for a valid packet and we got a packet at time T one. So, we, then we measure the, the time spent in between. So data T equals T one minus T zero. And since we know the hop interval, the time between two hops, then we can deduce the number of hops between these two packets. So, by doing this, we can create a pattern that, uh, will be very useful to, to sieve the sequence. So basically we're just, uh, going through the sequence and looking for a specific pattern composed of two channels. Channel C zero at, uh, uh, say index 200 for instance and at index 200 plus N channel C one. By doing this, you will get between 200 and 400 candidate values for this counter. So remember we are, we are looking for the, uh, counter used at T zero. And we do it, uh, we repeat the operations. We take the first candidate out of the, the remaining candidates and we compute C zero C one. We wait a packet on channel C zero, then C one. We deduce the number of hops and then we apply or sieve again. We are going to filter these, the, all these candidate, and keep only the matching ones. And you do this until one candidate left. And this candidate is the, your, the value of the counter at T zero. So, since I had no BLE5 devices at this time, I decided to implement, uh, to simulate this, uh, this attack. So, I will show you the result of this, uh, simulation. So, I, uh, I wrote my, everything in Python, Python 3, and I create this script, CSA 2 simulated by. So basically, at the start, there is a, a, a counter randomly generated, which is a 13,600. And I will go through every candidate, uh, each round reducing the number of candidates. So it's here 21, 11, 6, 3, 2, until we get, uh, a single candidate. And this candidate is 3,600, which is in fact the value we are looking for for T zero. So that's good. Yeah, I, I love when a plan comes together. The problem here is that we need to know the, what this hop interval value is. Uh, I suppose this, uh, value was known during my first simulation, but in fact I don't know this value. So how to guess this value? Well, it's, uh, some basic math you have to do. Since we are going to measure, uh, time differences between packets received on various channels, then we can, uh, do so. We can compute the GCD, the greatest common divisor of all these measures. And since these, these times are normally multiples of the value we are looking for, we will get this value. So again, I simulated this, uh, this computation. Well, it's very quick, so I have no video for this one. But, uh, by doing only 10 measures, I was able to recover the hop interval. And I performed a lot of tests, and this test showed that, um, if you perform only 5 measures, if you compute 5 measures, then you get an approximate success rate of 95% of success. So this is pretty good. If you, you should get 10 measures, then you are quite sure to get the correct value. But that's cool. So, basically what I got here is that a way to recover the hop interval value and another way to get the, uh, counter value, uh, the value of the counter, sorry, uh, at, uh, a specific time. So, let's do it in practice with a real device. Uh, there is a problem in fact, is that this, uh, version of the protocol has been released, uh, in 2016. And still, there is no compatible devices, uh, in the market. So, I wasn't about to find something to buy that implements this, uh, this, this protocol. So, uh, I'm sorry, there is, there is, uh, there is no video of a sex toy hack this time or a drone hack, um, but anyway. So, um, based on my first research, uh, I decided to, to try to, to apply this, uh, this attacks on, uh, some BLD5 devices. So, since there are no BLD5 devices, I'm going to make some. Uh, I ordered on, uh, uh, on a site, on a website on the internet, the two development boards from Nordic, uh, which support this new protocol with, uh, the correct SDK and the correct stack. And, uh, uh, just program this, uh, this, uh, boards with very basic examples. Uh, one making a, a LED blink and providing a BLD5 compatible device and another, uh, able to connect to the first one. So, basically, two devices that can create a connection in between and transfer data. And I also decided to improve my beta jack tool by, um, implementing some, some features, new features for BLD5. So, um, beta, beta jack can do the job, but only for the legacy file, which is the one megabit password uncoded file. But doesn't matter, my development boards, uh, are compatible with this file. So, it's okay. And I modified beta jack to compute this open interval while, uh, this, uh, this tool was mapping channels because usually when you're, uh, attacking, uh, an existing BLD connection, you need to know what channels are unused. You remember, I suppose that all 37 channels are used, but this is not always the case. So, by doing this, uh, I modified the other code to, to be able to, to get this, uh, this open, this, uh, open interval while mapping. But I first, uh, first problem, um, this problem is that normally when you are using CSA number one, the first channel selection algorithm, this is a 37 channel sequence and you loop over this, this sequence. But there is no doubles, you know, the, uh, each channel only appears once in this sequence. So, it's very easy to determine this open interval value and you measure, uh, time span between two packets received on the same channel and then you divide it by 37 and it gives you the, the value you want. But this is not the case with this random number generator, since, uh, um, a channel can appear twice or maybe more during the sequence. So, I had to compute automatically the, uh, time out to be sure that, uh, uh, a channel is correctly used. Anyway. And I, I tested this, uh, GCD based technique for recovering the open interval and it works pretty well. In fact, once you, uh, smash, uh, when, when, once you solved all the, all the issues but on time out. So, this is an example output of what I gave, what I get, uh, when I, uh, tried this open interval recovery system on this, uh, this connection. So, I got a open interval of 160 which is, uh, uh, pretty much it. So, that's good. Great success for the first time. But the main part is to be able to recover the counter used, uh, at a specific time during the connection. So, I implemented this algorithm, the sieve algorithm and I started trying this, uh, this algorithm. So, the first round, uh, went pretty well. I, I went from 65,000, uh, candidates to about 250 candidates, which is what I showed you, uh, a few minutes ago. So, that was pretty cool. But the next round is completely messed up. Uh, I wasn't able to get any data. So, I was a bit puzzled. And it turns out that my filter routine took a hell of a time to execute. And it induces a delay and I, I get lost in the connection. So, uh, this is a, um, simple algorithm problem. So, yeah, I was a bit pissed at this time. Uh, so, I decided to redesign my attack and to solve this problem I moved from a sieve to a pattern machine algorithm which is basically what I was also using. So, normally during my sieve attack, um, perform a measure, um, a measure and then, um, I filter all the candidates. This time, I'm going to do all the measures in, uh, during the first part of the attack and then filter all the candidates just at the end. And by doing this, I get, uh, a more complex pattern but in fact, uh, I'm quite sure to get the correct value. And by doing this, you end up with ten delta t values. So, some times difference between packets received in various channels. And based on this, we look for this hopping pattern in our sequence and we deduce the counter exactly as we did before. And, yeah, that worked. I was able to guess the counter value. Uh, so, uh, we'll show, I will show you, uh, an example of this later. So, that was pretty cool. So, from this, uh, uh, I told myself, yeah, that's good. You get the up interval, you get, uh, the counter value. Now, this is easy peasy. Uh, everything you need to do is just to synchronize with the existing connection. Well, good. So, I developed my, uh, the firmware in order to synchronize with the connection and, um, yeah. There was some kind of issue here. Um, didn't work at all. So, I got the, uh, correct up interval value. I got the correct, uh, counter, but I wasn't able to synchronize. And, uh, I looked at my code a bit, once more, you know, just to be sure that I didn't fuck it up. And I stumbled upon this part of the code. So, this is the filtering routine. What this code does is just going through all the candidates and filter these, uh, these candidates. So, uh, this is the second version of the approach. So, I need to, to go through the 65,000, uh, and, uh, and 536 candidates and it takes a hell of a time again. And by doing this, I was just, uh, 13 hops away of the correct value at the moment I was trying to synchronize. So, by doing this, just adding 13 to the, uh, counter value, I was able to synchronize to an existing connection. And that's pretty much it for the, this, uh, recovery. I will show you, uh, now a video of, uh, everything working with this, uh, this firmware. So, uh, for the video purpose of the video, I just provide the channel map and the hop interval value. So, as we can see, uh, this, uh, this, uh, tool is trying to recover the PRNG internal counter which is the, an unknown value, 16 bit. It takes sometimes, uh, generally less than a minute to, to deduce this, uh, this value. So it's pretty cool because, uh, if you are trying to attack a, a real life device, you have to be next, near to the device to, to, to attack it. So, uh, if it takes a less than a minute, it's okay. Should be very short. And once the, uh, counter has been recovered, then we capture data sent over these devices. So, by doing this, we got the correct value for the hop interval and then we get the correct value for the counter. So, that's pretty much it. You, you get a way to sniff, sorry, you get a way to sniff, uh, data over a BLE5 connection. But remember, it's only on the 1 megabit per second, uh, uncoded file. And you can also try to jam a connection. So, basically, once you, you are synchronized with this, uh, this connection, you can, you can inject packets as well. And this is what I do, I, I did last year, uh, for, you know, when I was attacking some devices. And this can also be done with my BLE5 devices. Well, it's sort of, hard to say. This is, yeah, uh, something very special because, um, I got my device on, on the screen here. So, I'm going to, to recover the, the pure engine on the counter. And you can see some LEDs, uh, normally at the, uh, bottom, uh, bottom right of the screen. Uh, this LED, which when it's the LED 2 that is, uh, uh, lit, then it means the connection is still active. I'm going to jam this, uh, this connection and be, be, pay attention. This is, this will be very quick. There is, uh, uh, some LED blinking, uh, telling, uh, telling us that the connection has been lost and disconnected. So here, uh, uh, I successfully jammed an existing connection, BLE5 connection, by using BTL Jack. Back to the slides. So, um, since, uh, everything went smooth with this, uh, this attack, I decided to, to release a new version of this tool, of BTL Jack, version 2, including this, uh, all this research I made on this, uh, channel selection algorithm number 2. So, it's, uh, it's working, uh, but I tested it on very few devices. I only got two of them. So, uh, I don't know what, uh, if this tool will work with, with any type of devices, BTL 5 compatible devices. So, um, I give you the code, I give you all the, the tools. Uh, this, uh, version of the software has not been published on PIP, uh, just not to mess with, uh, the actual version, because I, I'm not sure, uh, since I made a lot of modifications in the firmware, I'm not sure that the, uh, this version may, uh, alter the, you know, the behavior of, uh, the actual BTL, BTL Jack version. So, just to make things, things clear, you can, uh, clone this, uh, repository and then, uh, install the device by using some, uh, Python auto magic installer, uh, Python setup by, and that's it. So, uh, all the code is available, open source as usual. So, to, to conclude, uh, not so quickly, but, uh, anyway, um, what this talk demonstrated is that the BTL 5 CSA number 2, so the second channel, second algorithm, PRNG is weak. Um, but there was a reason for that. Remember, at the, uh, at the beginning of this research, I was, uh, just thinking, thinking that, uh, this PRNG has been introduced in this version of BAD to PIS hackers, uh, trying to attack, uh, BAD devices. But in fact, uh, after, I thought, um, uh, I, uh, I had some other thought about this, uh, this, uh, this PRNG, but, um, well, it, it's not really a PRNG, uh, as it's used here. And, of course, 16 bits out of 32 can be easy to guess. And the last 16 bit is a counter, so this is very easy to, to recover. But in fact, this PRNG has been designed to improve coexistence, not security. The goal of the, uh, guys who designed this protocol, or this protocol, this, uh, channel solution algorithm and this PRNG, uh, in particular, was to improve the coexistence of devices in the same, say, same space. By doing this, yeah, it works. You can get a lot of BAD 5 devices and with this system, you can get a lot more devices that we, uh, used to, to have in, uh, with the BAD 4 version. And also, the counter based random number generators are easier to implement and consumes formless, uh, power and memory. Uh, so, in, uh, in the IoT world, this is something that makes sense. So, is it a, a vulnerability? Well, I, I don't think so. I, I don't think it's a vulnerability, but in fact, it doesn't stop, uh, hackers, uh, to jam or hijack, uh, existing connections. Future work will include, uh, some, uh, a lot of development for BTAD Jack. Uh, as I said, there are, there are two new files introduced in this BAD 5 version, BAD 5, uh, protocol. And this, uh, new files are supported by a new Nordic system on chip called the, uh, NRF 52840. And this, uh, this chip is, uh, very interesting because it, uh, implements all the, uh, files natively. So we don't have to do some, uh, some, uh, SDR stuff or anything. We can just use the features of this, uh, of this chip to be able to decode and anchor the data packet over there. So this is, uh, quite interesting. But the fact is that it, uh, demands a lot of work to put BTAD Jack to this new platform because, uh, um, both of them, uh, are made by Nordic, but there are some, um, some differences in the way this chip handles the BAD protocol. But luckily someone called Marcus Mengs made some research, uh, recently on, uh, logitech unifying devices. And this, this guy, this dude made a lot of, uh, uh, of code compatible with this chip. And I talked with the, with him, uh, we exchanged a lot of mails. And this, uh, this guy had, uh, uh, some piece of code we need to use to implement this. So, uh, I think, uh, I'm, if he, if he's kind enough to share with me some, uh, some tricks he did on this, uh, on this chip, I will be able to port BTAD Jack to this new platform and get rid of the microbit stuff. So, this is, uh, this is it. Um, I think I, I said every, almost everything I wanted to say. Um, the resource materials, all the notes, scripts, I wrote, everything I showed you with the Python scripts is also, uh, also available on the, on the GitHub repository, which, uh, which is the following, BAD5 dash with the research on GitHub. So, you can get everything, uh, I developed and try it, insert me if the code is, uh, you know, dirty and, uh, and not that clear. But in fact, you can, uh, simulate, uh, everything the way I did and test it against, uh, some, uh, I don't know, maybe some new attacks you're, uh, looking for. So, thank you very much for attending this talk. And, uh, I hope it was, uh, yeah, cool.