Defeating Bluetooth Low Energy 5 PRNG for Fun and Jamming
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 335 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/48360 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 27106 / 335
8
9
12
14
32
38
41
58
60
61
72
75
83
87
92
96
108
115
128
132
143
152
158
159
191
193
218
230
268
271
273
276
278
295
310
320
321
335
00:00
Food energyPlastikkarteCore dumpRevision controlCommunications protocolTelecommunicationCodePersonal identification numberAlgorithmMechanism designInformation securityComputer hardwarePhysicsRange (statistics)Order (biology)Connected spaceRevision controlPoint (geometry)2 (number)Communications protocolEvoluteInformation securityFood energyMechanism designDigitizingKey (cryptography)Multiplication signSelectivity (electronic)Complete metric spaceAlgorithmGame controllerTouchscreenComputer hardwareSpywareSequenceRight angleBitBinary fileStudent's t-testHydraulic jumpRange (statistics)PhysicsLatent heatAddress spaceCartesian coordinate systemSoftware developerPlastikkarteEncryptionPersonal identification numberAuthenticationElliptic curveInternet der DingeDifferent (Kate Ryan album)Core dumpComputer virusCurveDifferential (mechanical device)CollisionBroadcasting (networking)WhiteboardComputer animation
07:26
AlgorithmEmailSpywarePattern languagePhysicsComputer hardwareSequenceComputer hardwarePoint (geometry)Communications protocolAlgorithmConnected spaceSelectivity (electronic)Cellular automatonSequencePattern languageBitInformation securityRandom number generationSoftwareLoop (music)Computer fileTask (computing)SpywareOrder (biology)Different (Kate Ryan album)NeuroinformatikPhysicsRandomizationComputer animation
10:16
Operations researchPermutationoutputAddress spaceExclusive orRandom numberNumberAlgorithmFunction (mathematics)Order (biology)Random number generationMultiplication signCase moddingNeuroinformatikConnected spaceAlgorithmLatent heatSequenceMultiplicationFunction (mathematics)IdentifiabilityLoop (music)Link (knot theory)NumberAddress spacePermutationExclusive orBitSelectivity (electronic)Asynchronous Transfer ModeOperator (mathematics)Binary multiplierRevision controlRow (database)Computer animationMeeting/Interview
12:27
Digital signalWeb pageAddress spaceIntegrated development environmentoutputExclusive orSequenceTwitterRandom number generationLatent heatAddress spaceParallel portSequenceBitFunctional (mathematics)IdentifiabilityConnected spaceState of matterRandomizationElectric generatorSinc functionType theoryComputer animation
14:12
SequenceInformationRoundingSieve of EratosthenesVector potentialSubject indexingDigital signalConnected spaceRoundness (object)CASE <Informatik>Event horizonMultiplication signNumberAddress spaceIdentifiabilityMultiplicationNeuroinformatikMathematical optimizationOperator (mathematics)Nichtlineares GleichungssystemSubject indexingSequencePattern languageAlgorithmSelectivity (electronic)Sieve of EratosthenesBitHypothesisInstance (computer science)MeasurementCountingMechanism design1 (number)Computer programmingGame controllerFunctional (mathematics)Computer animation
18:54
Physical systemInformationResultantSimulationScripting languageRoundness (object)NumberPlanningComputer animation
19:35
InformationVideoconferencingWindowProbability density functionSimulationIntegrated development environmentDirac delta functionPhysical systemBit rateTheoryRevision controlSoftware testingVideoconferencingTime zoneCommunications protocolMeasurementChronometrySimulationMultiplicationDivisor (algebraic geometry)NeuroinformatikMultiplication signBit rateMathematicsApproximationGreatest common divisorComputer animationSource code
21:58
Texture mappingData recoveryRevision controlFunction (mathematics)Parameter (computer programming)Stack (abstract data type)Process (computing)WebsiteConnected spaceBeta functionPhysical system2 (number)WhiteboardNumberComputer fileSequenceCodeMappingMultiplication signCommunications protocolGoodness of fitSoftware developerData recoveryCASE <Informatik>Selectivity (electronic)InternetworkingAlgorithmRandom number generationBitFunction (mathematics)Metropolitan area networkComputer animation
24:57
AlgorithmSieve of EratosthenesRoundingDigital filterMultiplication signAlgorithmLatent heatConnected spaceBitSieve of EratosthenesMereologyImplementationRoundness (object)1 (number)Computer animation
25:52
MeasurementPattern languageSieve of EratosthenesAlgorithmSequenceBitComplex (psychology)Multiplication signMeasurementMereologyPattern languageVirtual machineDifferent (Kate Ryan album)Sieve of EratosthenesSequenceAlgorithmForm (programming)Time zoneComputer animationMeeting/Interview
26:47
Digital signalConnected spaceGame controllerOrder (biology)FirmwareGoodness of fitComputer animation
27:19
CodeBitMereologyCoroutineRevision controlMultiplication signComputer animation
28:07
Pattern matchingMotion captureRevision controlParameter (computer programming)Connected spaceData recoveryMoment (mathematics)VideoconferencingLevel (video gaming)FirmwareVideo gameReal numberBitComputer animation
29:25
HypermediaDigital signalMotion captureRevision controlConnected spaceComputer fileComputer animation
30:04
Parameter (computer programming)Revision controlTouchscreenConnected spaceRight angleSlide ruleGreatest elementComputer animation
31:02
HypermediaInclusion mapRevision controlParameter (computer programming)Food energyInformation securityPhysicsComputing platformCloningSlide ruleRevision controlSoftwareCodeComputer fileSoftware developerSoftware-defined radioVulnerability (computing)NumberConnected spaceCloningRepository (publishing)Table (information)FirmwareRandom number generationPhysicsSelectivity (electronic)2 (number)Scripting languageDifferent (Kate Ryan album)Type theorySoftware testingPhysical systemComputing platformSpacetimeSemiconductor memoryAlgorithmCommunications protocolBitHacker (term)SpywareEmailForm (programming)Installation artComputer animation
Transcript: English(auto-generated)
00:00
So, I'm going to talk about Bluetooth Low Energy 5 P-O-N-G 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, digital security, a French IT security company specialized in the
00:22
um IoT. And I'm also the main developer of B-T-E-D-J-A-C or B-T-E-D-J-A-C which is Swiss Army Knife. So, we are going to talk about uh B-E-D-5 and uh especially what's new in B-E-D-5 specifications. And I will go through some specific features and also some uh some
00:44
interesting stuff in this uh in this protocol. So, first of all I'm going to recap what B-E-D is for those who are not familiar with this protocol. So, this protocol has been introduced in 20- in 2010 as uh Bluetooth Smart. So, this is the first name of this
01:00
protocol in Bluetooth core specification version 4.0. And it has evolved since then. Uh version 4.1 in 2013, 4.2 in 2014, version 5 in 2016 and last version 5.1 this year, uh in at the beginning of this year. So, it's um evolving very quickly uh as a
01:23
protocol and uh it's um it's designed to to to be very effective. So, people behind this protocol produces a lot of produce a lot of different versions. But the uh industry um it's difficult for the industry to to keep up with this uh evolution. This protocol provides
01:45
some security mechanisms uh such as pairing. So, you can exchange keys between two devices before to to be able to encrypt communications. And this uh pairing mechanism uh can be done with a pin code. So, this is uh something uh very easy. You just exchange a six
02:02
digit pin code between two devices and you derive some keys from this. Also from uh from out of one data. And also uh it's um it's a curve differentiation. So, this is uh something provided by this protocol and it's cool. Some version of this pairing uh are not very secure uh as it was demonstrated before uh years before uh before. But uh some of
02:25
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 uh very interesting because this uh secure connections, BLE secure connection is uh uh
02:41
pretty strong when it's correctly implemented uh in the uh 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 uh in uh in uh specific connections. And last but not least, there is also what we call the channel
03:03
selection algorithm. So, to make things clear uh this Bluetooth low energy protocol uses channel hopping to ensure to to to make these connections uh reliable. And this channel hopping mechanism is very simple. When two devices create a connection, they are going to
03:22
jump from one channel to another uh in order to avoid packet collisions. So, this uh allows the connection to be uh 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 when it mmm but when it comes to sniffing, when you are trying to sniff uh uh a BLE
03:42
connection, this can make this can be an issue because you for you need to know what this uh algorithm is and how to recover this uh hopping sequence in order to follow an existing connection. So, this makes sniffing complicated. There are also well known attacks uh
04:02
especially on BLE 4 which is the first one sniffing. You can easily sniff BLE connections. So, this is pretty straightforward. Even secure BLE connection when the pairing is not so secure. You can also jam an existing connection. This is what uh I showed last year at Defcon with BLE jack. So, it's possible to disconnect two devices
04:24
and once uh uh the uh device is disconnected then it advertise 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 uh one device to another and then exploit this uh
04:42
connection without the other device noticing the disconnection. So, it's uh possible to take complete control over uh a device this way. So, again, uh you can do this with a lot of different virus hardware. So, um on the left of the screen there is the UberTooth which is a well known device used to to sniff BLE connections. In the
05:04
middle, the Adafruit Bluefriend LA Sniffer which is the one of the one of the first alien bluetooth known as a sniffer available in the market. Uh it costs around uh 40 bucks. And uh on the right of the screen there is the uh the Microbit which is a uh British broadcasting company uh sponsored board developed to or designed to to teach UK
05:27
students how to code. And BTLE jack uses this last board, this Microbit to uh allow attackers to to sniff, jam, and hijack some connections. Let's go back to the
05:46
new features introduced in BLE 5. BLE 5 introduces uh uh a better throughput up to 2 megabits per second, a better range, up to 800 feet or 240 meters, and an improved coexistence. I will go very shortly uh for this uh the first two, better throughput
06:05
a better range. Basically it had it adds two new phis uh to the uh bluetooth low energy protocol. The 2 megabits per second uh uncoded phi that doubles the speed of uh the any BLE connection so you can send more data in the same amount of time. And uh also the
06:24
AD coded phi which uh improves the range uh times uh 4 times the actual range for BLE 4 but at 125 kilobytes per second speed and 2 times the same range at 500 kilobytes per second. So this this is some kind of trade off your your redo between range and speed.
06:47
If you have a look at the packets sent over this uh two new phis uh there is the AD coded phi which is uh a new phi introduced in BLE 5 and there is another phi, the AD uncoded phi which is the actual uh the BLE 4 phi. And in these packets you will find uh an
07:06
access address which is a 32 bit value um identifying a connection between two devices. But the problem is that the hardware we are using, see um such as the micro bit or even the Adafruit blue friend AD sniffer, this hardware cannot cope with these new phis. And
07:26
that's pretty much the issue, the issue here. So our hardware may be useful but for these new phis this can be a problem. So we're going to cover this later. The main point here is
07:41
that the BLE 5 protocol introduces a new channel selection algorithm. So the old one is mentioned here, this is uh a very simple uh sequence generator based on some module O. And the new channel selection algorithm introduces a PRNG based random generator, a PRNG based
08:02
channel selection algorithm. So this is based on the random number generator. This is uh a problem for us because uh as Mike Ryan showed uh in 2013 it was very easy to recover uh a very key value of the first channel selection algorithm which is the uh op-inc value mentioned
08:22
in this slide. But with the PRNG the the task is uh much harder because you you need to break uh this uh random number generator to to be able to to sniff uh hijack and jam an existing connection. Luckily the device is implementing this channel selection algorithm uh
08:44
advertise the uh 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 BLE 5? First of all there is a completely different new
09:02
hopping pattern used uh so basically the old version, the first channel selection algorithm generates a 37 channel sequence and this new channel selection algorithm generates a 65,536 channel sequence. And basically the device will loop over the
09:21
sequence. So this is uh uh more complicated and our first approach we we got when we were developing the uh BLE 4 tools uh couldn't work here. So sniffing new connection is still possible because you only need some software able to to follow the this uh new channel
09:40
secure channel selection algorithm. Because at the beginning of a connection you get everything you need to synchronize with this connection and and follow packets. But as an attacker we won't be able to jam or hijack BLE 5 devices because the connection is always the already established and we don't have these values used to to to compute the uh
10:03
sequence of channels. The we need to go to synchronize and follow the connection. So we also need a new hardware that supports supports BLE 5 new files but that uh another question. It's uh just like some guys at BTCIG decided to introduce this PRNG uh in order
10:24
to mess up with the the actual tools. Well this is what I believed when I started this uh 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
10:43
value. Uh this uh random number generator relies on basic operations. Some uh add, multiply, XOR, bit permutation and so on. And it also uh uses some uh channel remapping but this was the same with BLE 4. This channel identifier value is computed
11:00
from access address. So uh this uh this is the 32 bit value identifying your link between 2 devices. So basically identifying your connection. And the the the the computation is the following. You take the um access address bit 0 to 15 and you XOR this value 16 bit value with the uh access of it bit 16 to 31. So you got a 60
11:23
16 bit value. And then we are going to use uh a lot of uh uh computation and uh a specific version called MAM for multiply add mode. And basically this what in the perform some computations. And takes 2 values A and B, 16 bit values and produces a 16 bit
11:42
output. And this is just 3 times in a row uh with 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 uh when this
12:07
channel selection algorithm generates a sequence, it goes from uh a counter from 0 to 4K. And then generates every possible channel. And this this creates uh uh uh a sequence of of
12:21
channels and the devices will go over a loop over this sequence. So when I saw this uh I was like uh wow what's this stuff? What what the fuck? And I wasn't alone. I I found some people on Twitter also complaining about this uh specification and especially this PRNG. Well, maybe there's something to do. Uh if you have a look at this uh generator then
12:49
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 known value. And also the next value uh is generated from a
13:05
counter, next random value generated from a counter. So not from some kind of internal state that usually PRNG is used to to to create uh another random value. So since
13:20
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 if we look at the uh specification then we know that the channel identifier is constant since it is derived from the
13:40
access address. And what this uh function does it that it generates a fixed sequence of 65000 values indexed by a counter. Normally this counter bears random number generators are used to parallel- parallelize sorry in French. Uh this is a very easy excuse but
14:02
anyway. Um yeah. So this uh 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 randomize some kind of channels and that's it. So what do we need to break
14:22
it? If we consider the channel uh no just consider the channel identifier as known you know since it is derived from the access address. We are left with a 16 bit uh unknown value which is a counter and if we can figure out where we are in the sequence of uh this uh 65000 and 566 values then we will find out what this counter value is. And
14:47
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 uh and these events are the
15:07
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 something from uh some measures we can
15:26
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 or simple computation to to derive the channel for a specific counter. Uh but if not if this uh if these channels are
15:46
not all used then this is a more complex. But in fact this uh it doesn't make things more compli- more complicated uh in the in this way. But I will focus on the first case. The first case is that we are going to use all the 37 data channels to make s- things
16:03
simpler. My first approach was to uh use a sieve. Uh I'm quite sure you'll you'll know that it was the same 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
16:23
number of rounds to be more precise. The prerequisites 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 or the
16:41
count of 0. So just say that it's 0. It's uh hypothetical. It's not the real value we are looking for. And we compute uh channel C0 from this uh pure energy function with this candidate counter and uh based on the uh channel identifier of course. And we wait for a valid packet. So we get a packet at time T0 on channel 0. On channel C0. And we do the
17:05
same on the next channel. So we increase the the counter with a counter of 1. We compute the next channel and then we wait for a valid packet. And we got a packet at time T1. So we then we measure the the time spent in between. So data T equals T1 minus T0.
17:24
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 are just uh going through the
17:44
sequence and looking for uh a specific pattern composed of two channels. Channel C0 at uh uh say index uh 200 for instance. And at index 200 plus N, channel C1. By doing this, you will get uh between 200 and 400 candidate values for this counter. So remember
18:06
we are looking for the uh counter used at T0. And we do it uh uh we repeat the operations. We take the first candidate out of the uh the remaining candidates and we compute C0, C1. We wait a packet on channel C0, then C1. We deduce the number of hops. And
18:27
then we apply our sieve again. We are going to filter all these uh all these candidates 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 T0. So since I had no BLE5 devices
18:48
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 wrote my uh everything in Python, Python 3
19:04
and I create this script CSA to simulate pi. So basically, at the start, there is a uh a counter randomly generated which is a 13600. And I will go through every candidate uh each round reducing the number of candidates. So it's here 21, 11, 6, 3, 2
19:25
until we get uh a single candidate. And this candidate is 13600 which is in fact the value we are looking for for T0. So that's good. Yeah, I I I I love when a plan comes
19:46
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
20:05
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 measures, these times are normally
20:21
multiples of the value we are looking for, we will get this value. So again, I simulated this uh this computation. Well it's uh very quick so I have no video for this one. But uh by doing only 10 measures I was able to recover the open data. And I performed a
20:41
lot of tests and this test showed that uh if you perform only 5 measures, if you compute 5 measures then you get uh this approximated success rate of 95% of success. So this is pretty good. If you're gonna if you get 10 measures then you are quite
21:02
sure to get the correct value. But that's cool. So basically what I got here is that a way to recover the open total 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.
21:24
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 uh in the market. So I wasn't able to find something to buy that implements this uh this this protocol. So I'm
21:44
sorry there is there is no video of a sex toy hack this time or a drone hack uh but anyway. So uh based on my first research uh I decided to to try to to apply this uh this attacks on uh some BLE 5 devices. So since there are no BLE 5 devices I'm going to
22:06
make some. Uh I ordered on uh on the site on the website on the internet 2 development boards from Nordic uh which support this new protocol with uh the correct SDK and the correct stack. And uh I just programmed this uh this uh board with a very basic examples.
22:27
Um one making a LED blink and providing a BLE 5 compatible device and another uh able to connect to the first one. So basically 2 devices that can create a connection in
22:40
between and transfer data. And I also decided to improve my beta jack tool by uh implementing some uh some features, new features for BLE 5. So um beta beta jack can do the job but only for the legacy 5 which is the one gigabit per second uncoded file. But doesn't matter
23:00
my different boards uh are compatible with this file so it's ok. And I modified beta jack to compute this op interval while uh this uh this tool was mapping channels because usually when you're uh attacking uh an existing BLE connection you need to know what channels are in use. You remember I suppose that all 37 channels are used
23:25
but this is not always the case. So by doing this uh I modified the code to to be able to to get this uh this op this uh hop interval while mapping. But I faced a first problem um this problem is that normally when you are using CSA number 1 the first channel selection
23:44
algorithm this is a 37 channel sequence and you look 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 op interval value and you measure the uh time spent between 2 packets
24:02
received on the same channel and then you divide it by 47 and it gives you the the value you want. But this is not the case with this random number generator since uh uh a channel can appears twice or maybe more during the sequence. So I had to compute automatically the uh a timeout to be sure that uh uh a channel is correctly used. Anyway,
24:27
and I tested this uh GCD based technique for recovering the op interval and it works pretty well. In fact once you smash uh when when once you solve all the other issues but on timeout. So this is an example of what I gave what uh what I get uh when I uh
24:47
try this op interval recovery system on this uh this connection. So I got a op interval of 160 which is uh uh pretty much it. So that's good. Great success for first time. But the
25:00
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 one uh went pretty well. Uh I I went from 65,000 uh candidates to about 250 candidates which is which is what I showed you uh a few minutes ago. So
25:25
that was pretty cool. But the next one's 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
25:40
hell of a time to execute. And it induces a delay and I I get lost in the connection. So uh this is a uh 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 move from a sieve to a pattern
26:01
machine algorithm which is basically what I was also using. So normally during my sieve attack uh perform a measure a measure and then uh 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
26:26
fact uh I'm quite sure to get the correct value. And by doing this you end up with 10 delta t values. So sometimes difference between packets received in various channels. And based on this we look for this hopping pattern in our sequence and we did use a counter
26:44
exactly as we did before. And yeah that worked. I was able to guess the counter value. Uh so uh we will show I will show you uh an example of this uh later. So that was pretty cool. So from this uh uh I told myself yeah that's good. You get the open interval you get uh the
27:06
counter value. Now this is easy peasy. Uh everything you need to to do is just to synchronize with the existing connection. Well good. So I developed my uh the firmware in order to to synchronize with the connection and um yeah that was some kind of issue here.
27:23
Um didn't work at all. So I got the uh correct open 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
27:43
of the code. So this is the filtering routine. What this code does is just going through all the candidates and filter this uh this candidate. So uh this is the second version of the approach. So I need to to go through the 65000 and uh and 536 candidates
28:03
and it takes a hell of 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
28:24
that's pretty much it for this 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 you can see uh this uh
28:47
this uh tool is trying to recover the PRNG internal counter which is the unknown value 16 bit. It takes sometimes um 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 real life device you have
29:05
to be next near to the device to to to attack it. So uh if it takes uh less than a minute it's ok. 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
29:23
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 BLE 5 connection. But remember it's only on the 1 megabit per second uh uncoded file. And you
29:42
can also try to jam a connection. So basically once you uh you are synchronized with this uh this connection you can you can inject packets as well. And this is what I do uh I did last year uh for you know when I was attacking some devices. And this can also be done
30:01
with uh my BLE 5 devices. Well it's uh how to say. This is yeah uh something very special because um I got my device on the 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
30:23
bottom uh bottom right of the screen. Uh this LED which when it's 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
30:45
telling the telling us that the connection has been uh lost and disconnected. So here uh uh I successfully jammed an existing connection BLE 5 connection by using BLE Jack. Yep
31:07
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 BLE Jack version 2 including this uh
31:26
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 a very few devices I only got 2 of them so uh I don't know what's uh if this tool will work with with any type of devices BLE 5 compatible
31:43
devices. So um I give you the code I give you the 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 uh this version may uh alter the you know the behavior of uh the
32:06
actual BTL BTL Jack version. So just to make things clear you can uh clone this uh repository and then uh install the device by using uh some uh Python auto magic installer uh Python set up by and that's it. So uh all the code is available open
32:24
source as usual. So to to conclude uh not so quickly but uh anyway um what this talk to demonstrate is that the BLE 5 CSA number 2 so the second channel selection algorithm
32:41
PRNG is weak. Um but there is a reason for that. I remember at uh at the beginning of this research I was uh just thinking thinking that uh this PRNG has been introduced in this version of BLE to piss hackers uh trying to attack uh BLE devices. But in fact uh
33:02
after uh after the um uh I I I 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 easily guessed. And the last 16 bit is a counter so this is very easy
33:22
to to recover. But in fact this PRNG has been designed to improve coexistence. Not security. The goal of uh the uh guys who designed this protocol or this protocol this channel selection algorithm and this PRNG uh in particular was to improve the
33:40
coexistence of devices in the same say the same space. By doing this yeah it works. You can get a lot of BLE 5 devices and with this system you can get a lot more devices that we are used to to have in uh with the BLE 4 version. And also the counter based random number generators are easier to implement and consumes form less uh power and
34:06
memory. Uh so in uh in the IOT world this is something that makes sense. So is it 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
34:31
include uh some uh a lot of development for BTLJAC. Uh as I said there are 2 new files introduced in this BLE 5 version. BLE 5 protocol. And this uh new files are supported by a
34:46
new Nordic system and chip called the uh NRF52840. 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
35:06
chip to be able to decode and uncode the data packet over the year. So this is quite interesting. But the fact is that it uh demands a lot of work to put BTLJAC to this new platform. Because uh uh both of them uh are made by Nordic but there are some some
35:24
differences in the way these chips handle the BLE protocol. But luckily someone called Marcus Mengs made some research recently on uh logitech unifying devices. And this this
35:41
guy this dude made a lot of 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 have uh some piece of code ready to use to implement this. So uh I I think uh I'm if he if he's kind enough to
36:00
share with me some uh some tricks he did on this uh on this chip. I will be able to port BTLJAC to this new platform and get rid of the micro bit uh stuff. So this is uh this is it. Um I think uh I said every almost everything I wanted to say. Um the resource
36:24
materials, the 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 BLE 5 dash research on github. So you can get everything uh I developed and try it.
36:43
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
37:01
attending this talk and uh I hope it was uh yeah cool.