 Yay, hi there. So it's a pleasure to to speak here Yeah, so I'm still waiting for the confirmation that I'm being streamed right now Does it work? Everything is Delight Okay, I seem to be live great. Um, so it's a pleasure to be here Um and talking at the devogs or the digital see three walk Um and so I will be talking about Bluetooth random number generator Which is a topic I was working on together with Marta dealer and he did it as a master thesis and afterwards I continued it So the question is always How do things work like in terms of What does randomness look like and I found this nice rabbit on the internet and it might give you some randomness But yeah, that's the big question. Is it really random what you get there or it's not random and Then Marta dealer asked me if he can do a master thesis with me and back then when he started I had something like 10 students and I was like, oh, you know I have tons of students already working on Bluetooth And I don't really know what to give you because someone is like putting it to Linux another person to Mac OS and so on I don't really can paralyze more there And then he was like, but I really want to do a master thesis with you and then I was like, huh Yeah, so I still I still have this random number generator thing that someone really should look into and so Yeah, he started doing a master thesis with me Now the big question is like why is it even interesting to look in the random number generator, so if you look into the specification the specification says that The random number generator really needs to be FIPS compliant because it is used for authentication encryption and everything else that's somewhat Related to security So That means that security breaks Sorry, I'm I'm still confused with the mumble. I'm sorry. Okay, so The the random number generator is very important for security for encryption on but also for Authentication and everything that does security and so it needs to be FIPS compliant Which means that it needs to pass certain statistical tests and the specification also says like that you should replace the shall one function by Shall 256 and so on and Proposes some tests that should be done with the random number generator Now the big thing is even if a random number generator is passing statistical tests, it might still Be broken. So just if it doesn't pass the test then it's obviously broken But even if it passes the test, there might still be something going on So it might still not be cryptographically strong just because it's passing some tests And now the big question is in a Bluetooth chip. How can you acquire randomness? So there's multiple possibilities. I don't know. So I I asked my unicorn so and of course my unicorn is here as always So and now the big question to the unicorn is how do you acquire randomness? So there might be first of all the answer to everything which is a 42 or Then there is another thing that you might have heard about which is the random access memory and Probably nobody heard about the Random only memory and then there is another option which sounds safe Which is the hardware random number generator. So that's a few options And still so I didn't have the answer my unicorn didn't have the answer So I asked the internet joker, which is Twitter and I made a poll so that everyone who knows info sec can Check it out. And then I was looking for the answers. So what was the top answer? Yeah 42 is the top answer but then some people also heard about hardware random number generators and Some said random access memory and probably nobody ever heard about the random only memory So let's see Yeah, so how is it implemented actually? so what what? Marta did I looked into is the following four devices the first one is the Google Nexus 5 Which is just like our let's say hacking device in those terms that is the first one where we got next one and everything else working and Then we have three more Devices listed here because we have symbols for them So it's only partial symbols just some functional names and global variable names But that's way more than just nothing because the blue to firmware really doesn't have any strings and Within those four devices. He was already able to differentiate between two variants the first one has an inline to the random number generator, but also hardware number generator and no cache and the second variant somehow has a cache and Some little rewrite in the library so that the random number generator the children number generators somehow outlined In a in another function So and how does it look like so the variant number two is just the code That's also in the variant number three for their hardware number generator It just checks if the hardware random number generator is ready and if it's ready Then it's basically just checking If it has a new numbers so it also pets the watchdog in between because just waiting for a new random number might take a moment So that the chip doesn't crash from this and then returns four byte value With the with the data. So that's it very simple. Just wait for the next random number And it has also some constant just to check like if there is really a hardware random number generator present And if it has a new number and so on but that's just magic numbers Yeah, so That's that's the basic setup and then the pseudo random number generator is way more interesting because It's taking a few values So the values basically are the blue to clock the blue to clock is value that is shared for communication to all parties then there is the Locker clock of the device and then there is a few more values which have to do with signal processing and it's taking all those values and Putting them into the not so secure C or C 32 functions Just to compress it back to four bytes so that somehow the combined entropy of everything of this is combined back to the four bytes that we need for the random number Functions, so it looks just the same no matter if the one or the other is called and So another input is the previous pseudo random number, but if it's initialized then Instead it's taking some memory, but that's that's basically the the only difference here So this this one looks a bit strange. So really not the thing that you want to see Because like signal inputs might be predictable and clocks especially are predictable and CSC 32 also does not look too good So what he did there was doing a few more measurements and so the measurements We didn't look good the the plots here are Histograms and each histogram has just the values 0 to 255 which means so the Bluetooth clock for example It's actually four bytes and then of course one of the values is more frequent Because that's like one of the digits of the clock and so on so it's not really a time plot here or something Here was just looking at the byte frequency and the only thing that looks random is this plot age the last one which is the last Random value. So if it would only use The pseudo random number generator then this would be the entropy that the pseudo random number generator gets And then it was already the end of his thesis and we reported this and what I currently do is I first Request a CVE at Mitra. They just take one or two days and then I send it to Broadcom and Cyprus and their customers because This takes so until Broadcom replies it usually takes a week or longer. So And they also don't issue any CVE. They don't issue any issue idea or something So if I don't request a CVE in advance myself, then I cannot really track the issue So that's that's why we do it this way it also confuses then the the customers of Broadcom because they think Broadcom would assign those CVs, but they don't Yeah, so then we did responsible disclosure and We said so yeah, so why would you introduce this pseudo random number generator, which really doesn't look good If you had a proper hardware random number generator and then Broadcom said like why should we ever go to the pseudo random? fallback if we have the hardware in the device So it was just like everyone claims like yeah, you did you did a mistake, but Nobody really said like and this is this is the mistake So it was just going forward and back and Broadcom said yeah, we we never ever go to the fallback so it's safe and Yeah, so this is then probably the end because Marta de los teases was finished So he handed it in so no peering we used in any of the device he looked into Nothing to see there and then we just say goodbye and This is the end so to say The end in terms of Yeah Everything everything is great and Everything is secure and nothing is bad and now the cool thing here is that now My other student former student Jan will have a lot of time to explain all the weird machines and remote God execution to you right because we are just like Ten minutes or something in my talk But this is this is only half the truth. So this is not really the end Because then of course, I looked into a few more devices Because some device if they if they have a fallback and even the code changed over time then There should be a reason why they changed the code over time and of course you should also measure the hardware random generator itself So if it's really secure and the basic test don't need so much data But if you take the die-harder test suite It means that you need to get one gigabyte of random data out of this chip over you are it with Some patches and it should be as fast as possible and so on and so forth. So this this was really pain So what did I do first of all you need to try to find a large free memory area in the chip While it's idle and I found some on most ships. So it depends a bit. So different ships different measurements Some of them had smaller regions And then I also wanted to be sure that no other process is writing into the memory area because actually the area is not really free it's just currently not being used by another process and Hopefully not used by another process So I was just using the fifth byte to write some tests by because the process usually writes like in a sequence and so on So that's what I did a sanity check and I also deactivated the original RBG run function so that they are that this is not called in the background And falsifies my results and Then the next thing is that I did some asynchronous call back so that I don't pull for data all the time But I wait until the measurement is finished Which makes it a bit faster but so for this you need to fix the land from and some HCI call back and stuff and These were broken on a few devices So it's somehow broken on the Nexus 6p and iPhone 7 and it's in another way broken on the Cypress evolution boards and Yeah, well they removed lounge rum on the iPhone 11, but so except from that so on most devices It is work some devices need like certain patches Yeah, so and then finally I had like some data from those chips and really like a gigabyte or more And then I was like, okay, it's just random data. I really don't care about it So I just upload it to the Google Cloud because who cares And then it just locked me out and so on as well But I could log in again, but it's like not what I usually do like putting a lot of data to Google And then Felix just said like next time when I do this I should maybe not call it random data dot bin But maybe encrypted backup dot bin would be a funnier name So the reason the reason why there is so much data for the Nexus 5 is probably because I put my backup in there Yeah, so this is the data You see 2.7 gigabytes for the Nexus 5 That's where my encrypted backup is contained and all the others are the random numbers and all of them pass the die-harder test And then there is still some chips that are too much pain. So first of all I have this I make late 2009 which basically has 2007 firmware or something and it's so slow and it has so little free memory that you really can forget to get data out of this chip and And then there is the Samsung Galaxy S10 and there they introduce Deccanaries and stuff so like it just gets more pain to write patches and the iPhone 11 Currently is not supported by internal blue. So I need to write everything with Bluetooth by hand So really like entered the hex numbers each and every one after the other But what I did for those devices is that I at least confirmed That there is a hardware random number generator and that when I do actions that triggered like pairing and stuff That the number in the hardware random number generator is changing So at least there is one present, but I didn't collect like one gigabyte or more of data Yeah, so now the issue is so there's tons of variants and the firmware itself it's just a raw binary and That really makes it a lot of a lot of pain because every mistake that you that you get when you try to find assembly and Just find the wrong arm instruction beginnings and so on and so forth every mistake will make an error in the call graph and then You will get wrong matches. So for Ida 68 the disassembler is a bit more aggressive And I think it's linear and then there is an Ida 72 and you're once it's doing it a bit different And then you have less false positives, but it's also finding less and then there's amnesia, which is also way too aggressive So if you have too many Like false positives you get problems if you don't find all of the functions You also have problems. So it's it's really it's really pain And so I have a student who developed another tool That's not looking for disassembly, but just for our binary stuff and that's going to be released soon but I also couldn't use this one there because if you have different Compiler options and stuff. So if you go over a lot of year years in firmware versions Then this one also doesn't work that well It works well for patches within the same chip and so on but it doesn't work well for going over 10 years of firmware Yeah, so the variants the oldest variant is the one in the iMac and also the ASUS USB dongle and the pseudo random number generator fallback Looks very funny because it really just depends on the clock and the clock is incremented each 0.005 seconds by one and that's it so The pseudo random number generator there is really really really bad But also at least on the iMac Lake 2009 it's not being used I currently didn't have an ASUS speed dongle tool to confirm. So I just looked into the firmware image Yeah, so then there is tons of more tips of the variant 2 and 3 which I The pseudo random number generator that I just showed to you Still what you can see here is that the location of the the mapping of where this hardware register is changed And so it changed a bit over the years, but then forth and back so The the chip data compiled it is not always necessarily exactly what the memory mapping is and so on and so forth Yeah, then there is variant number 5 and variant number 5 is the one that you can find in the current iPhone 11, but also the iPhone 8 xxr I don't have a favorite dump of the chip of the iPhone XS. It's a different one And then also the Samsung Galaxy S10 S20 They all have this new variant and the new variant is a rewrite of this complete random byte generator library. So it's Everything is different inside and it has some kind of asynchronous cache and so on but It's still using this Library in the same way. So it's still using the same cause that I will show you later in a call graph And what they did is they removed the pseudo random number rate generator at least from what I could see I mean, it's always hard to say because There's also like patches and a lot of other stuff So I could still be missing something in a firmware without any simple sense on and so forth But it looks like they they skip the pseudo random number generator Which means if in one of those firmware versions The hardware random number generator would be wrong in some way, then there wouldn't be any fallback Which might also not be good Yeah, and then there is the variant number 4 because I can count I just skip variant number 4 and the variant number 4 Yeah, somehow they forgot the hardware random number generator So one of all those devices that I looked into was actually missing it And it's obviously the number 4 because yeah, it's probably a bit like the different random number generator Which is also returning for all the time So and now if you look into that device that is missing The hardware random number generator. We have the same pattern as in the variant number 2 So we have the previous random value. We have two clocks and we have some signal based inputs So now the first one the clock you can see so this is a measurement really over 50 minutes just looking into the Bluetooth clock and the heartbeat clock and the heartbeat clock starts at FFFFFF and then the Bluetooth clock increases the Bluetooth clock itself is shared over the air But it might be reset. So they might not so they correlate but they might not have like a corresponding value So you still as an attacker would need to figure out what the current local hardware clock of the device is But you might also be able as an attacker to set this. So if you crash the the Bluetooth chip Then it starts again at FFFFFF Which means that now crash only attacks which Broadcom is usually not patching become relevant again And this is this is really sad. So it means a very simple Crash-only attack in whatever state machine entering some weird state or whatever that is no memory bug But crashes the chip can already be relevant to reset this Yeah, and now there is signal processing inputs. So there is a resistor quality C FH out and on the left hand side you can see it's Getting just values between 1 and 80 something around this and on the right hand side you can see that also Over time it's not really random, but you can see a pattern So it stays a bit of the time the same and then it's the numbers that follow each other are somewhat similar so it's also not really the best random input there and Then there is two more that are a bit random the first one is the RX in at angle Which only takes a few values if you measure over time and the second one Is the HCC status? I think it's somewhat like RSSI but So in the first measurement it was really zero all the time in the second measurement It was sometimes zero sometimes getting values, but also just values in the same range So it's again not really random Which all together means that if those inputs are not random and an attacker Gets the current value of the RNG The attacker might be able to predict the next values of the RNG Now the question is so why did we even stop after like looking into 17 chips? So 17 is the most random number between 1 and 20 you can you can look that up on the internet There's multiple studies that confirm 17 is the most random number So I didn't measure more devices than 17 and also that was one of the mottos for the Easter hack Some years ago in Frankfurt, so just send 17 is the most random one as far as and then something funny happened because Broadcom's customer who who had this issue with the missing Hardware random that drama generator got a bit nervous And so they asked like can we take wall com because like maybe somewhere else. There's also randomness missing and Then I said well, I mean you can tell them, but at least we don't have any NDA or something So they wouldn't tell us and why should they tell you if they are insecure? So it really doesn't make that much sense But of course you can ask like if this black box of magic of random number generator for Qualcomm chips is It's like broken and then they asked and then they gave us some answer and this answer I'm not allowed to show you here and then I they gave me another answer And that's the answer that I'm allowed to show you here, which is yeah, they didn't found any indicators that that they have the same issue in To the random number generator or something so they say we think our random numbers are secure But that's again a thing so you you would never ever know for a bit of chip until you do this whole Reverse engineering and all those measurements if it is really secure Now the impact so I said in all versions so or variant so variant one two five The function IBG run is called the same way And that means that there is one variant where it's put into a wrapper So this char get one two eight byte run a bit run. So this one is a 16 byte Output and it's just taking 16 times the IBG run function and putting it into the char function But it's just in in a loop. So that means that there is not that much randomness. So for the timers and so on You can predict how they change and then also those those values That come from the signals they very similar over time. So probably it's just the same value over the whole round And then there's the other Variant so the red one above which is your P run This is ultra low power and is used for everything that's Bluetooth L E and for those they are just copying those four bytes as they are Without any show on top And you get the direct state of the previous random value and this is for example used in the Secure manager ULP function to To send an initialization vector and this one is to send in plain text over the air before encryption starts for example, so this date definitely leaks Yeah, so random numbers are needed for example in the numeral comparison protocol That's a protocol when you pair two devices and get six digit number shown on those devices And this protocol prevents active man in the middle attacks by making a commitment on a random number And then later opening this commitment so on a commitment is just something I give you a key for a safe and I tell you in the safe is something and Later, I give you The other way around I give you the safe whatever but it's basically I'm committing to something without telling you the what and then later I open it and This property breaks as soon as you can predict the random number So the numeric comparison for the man in the middle attack Is now viable in that sense Yeah, and there is also a few other things that break, but this is just an example so you can no longer do the pairing with the six digit number without being secure against men in the middle attacks and Then I looked into Android and Android Well, they had a good idea. So overall so if the boot of chip is Fibs compliant it means Sorry, so if the if the Chip is so if the RNG is Fibs compliant It means that the Bluetooth chip on an Android device is a safe source of randomness in that sense So it's really good to take this one because it's certified and Android runs on very many many many devices And you never know if in a cheap whatsoever China phone you would have a good RNG and it's a good idea to take the Bluetooth random Yeah, so that's why they do this I think and what you can see in this fire shark trace Is that the le run function which directly calls the ui p run which directly calls the RBG run is? Called multiple times in a row and the first four calls are actually used to create An elliptic curve if you have an private key and then later compute a public key and the second one is then sent over the air and You can also look this up in the in the current Android code and this of course means that well if you if you have RNG that is broken then the the private keys directly initialize with this one and so it's Just leaking the key without even any active manual middle So just a passive man in the middle that somehow can infer from the other numbers that are sent over the air What what was the previous state of the RNG is now able to know the key just passive Now the question is so when will there be a patch? So the device with the missing had a random number generator. I skipped the name of the device on purpose because this one didn't past the 90-day deadline yet because we found this one a bit later but The problem is that also Broadcom and their customer they cannot provide us with Depatch and advance so they don't even give us the binary or something and they also don't tell us when exactly it will be patched So all I do is I go like to to vendor websites and check like is there any update announced and once there is the CVE that I initially Got from from Mitra if this one is listed there, then I can hope for like Yeah, I don't know reverse engineering that patch And if it's not mentioned then usually it means that there is no patch So I don't know for the for the first issue that that was really serious that we found I started like Reverse engineering each monthly patch one then like so I did it for three months and it didn't happen Until in the fourth month it was happening and then it was already officially officially announced And as there is currently no patch announced They will definitely not make the 90-day deadline and I also think like even if giving them two more weeks It really will not make the deadline. So Yeah, let's let's see how that develops, but I think there will not be any good patch in time so The lessons learned don't trust any embedded random number generator It might just be a bad to the random number generator that still was passing some statistical tests But once you know the the inputs of such a pseudo random number generator You might see that it's insecure. So, yeah, you never you never know And then also during all this patching I really saw like how do you feel we evolved over more than ten years and how each of them has like their Individual bugs that you need to fix to interact with it and to get like one gigabyte out of data out of that chip and so on and so forth So that was definitely interesting for this project And now I need to give some credits first of all to Marta dealer for surviving a thesis with me and Also Felix who helps me with everything that's crypto and that I don't understand Then there is Matthew as my boss who makes it possible to buy like one smart phone and another smart phone And I don't know and another smart phone and still another smartphone And then there is Jacob who made it possible for me to access one of the devices that I needed Remote in a setup. So he's also in the next month team and then I had To proof readers for the paper that I wrote in parallel Who also helped me a lot like last minute? That's that's always the thing because papers always get done last minute So that's it for my talk and now you can ask questions There's also a pet where you can put in your questions And then I will answer them So, let's see Our full screen from my Nakama. Wait a second. Yep So, do you see me full screen on my camera now, I hope so I hope so, okay So the questions First the first what yeah, yeah, yeah, yeah, you can only hear me in the live stream. That's okay I'm I'm already in the question pet. So I just answer the question from the pet I can yeah, so I can hear everyone speaking the mumble. It's just that people cannot hear me speaking the mumble, but I can hear you So, yeah Yeah, okay Yeah, it doesn't matter. So I just I just read the questions myself and answer the questions myself Yeah, yeah, it's easier. But if I just do it on my own, I'm sorry So the first question is if we are able to access the main CPU from an exploit in the Bluetooth chip so that that depends so it's It's a complicated question, which I which I cannot fully answer yet, but so Okay, so I'm going on on my own so anyway, so there is so people are asking if there's an exploit to escalate into the operating system And so the first thing is that there is like a lot of drivers and I would say the most interesting one is Since the iPhone XS and iPhone 11 they are attaching the Bluetooth chip via PCI express, but except from that I'm not Commenting anymore Yeah, so then people are asking entropy. Yeah, so I mean, it's not really random there's the timer which is not random and then there is like Two more inputs that are like one byte or something but not even the full byte being used So I don't know there might be Like one byte or something that you need to put force Yeah, so next question, how did we access the Bluetooth chip on the iPhones? Yeah J breaks so Internal blue is working well on everything like I don't know. I also have this this cute iPhone 6 here so on iPhone 6 on iOS 12, but also iOS 13 everything that's an UI chip It's working with internal blue, but you need to check break, but yeah checkmate does a great job and then you can just install it Yeah, so and No, no, no internal blue internal blue someone is Can I I cannot edit the pad but internal blue and then It doesn't have anything to do with the RKA up for the COVID-19 tracking. No, no, no, it's nothing We don't have any working exploit right now. I mean that that would be cool Like I don't know building something to calculate it back. Yeah, but then again Currently publishing exploit is so so because it's not being fixed in time. So yeah, I mean we probably should build it Shouldn't be too high based on the measurements Yeah, so then there is the next question so how much Money would vendor safe by not including a good hardware engine I mean they just need to include a good pseudo random number generator actually So that's everything that the Bluetooth specification requires and I'm I'm not even sure like So for me for me the firmware, but I don't know it might just be that for the smartphone Where it's missing that they already put it in there, but didn't really wire it or something or for example that The chip already went into production, but I don't think that they initially leave it out to save some money Yeah, so next question So how can we make more accurate statistical tests? I mean die-harder And so on they already have accurate statistical tests The problem is just that if you have like some pseudo random number generator and don't know the inputs then it will look very Random despite the input itself was not random Yeah, so the paper we just submitted it to a conference We might so the conference doesn't prevent us from from Publishing on archive or something But it includes the model of the vulnerable smartphone so we can earliest we can do it would be I think first of May or something so Yeah Then next comment is a great brick and what does my unicorn think about all the stuff. I don't know so yeah Unicorn on the stream again saying hello Um Yeah, next question if So how they how they could fix the pseudo random number generator using the other sources than they had I Really, I really don't know and that's the thing So that's why I asked them like how are you going to fix this and they just said like we are going to fix it in time And this is this is really an issue the whole the whole patching policy there So it's really annoying because I Don't know how it how it will be fixed and when it will be fixed. So I have no idea And now yeah, can I quickly explain what random only memory is so this is basically just a joke that Yan Is going to to make in a So he's going to make the next talk so and so I was like, you know They don't have a hard random number generator What do you think where they will like get the randomness from when they patch it and then I was like, I don't know Yeah So maybe random access memory and then just for fun. We said like oh, maybe there is there's also Random only memory like rom but rom obviously is not random only memory But it's just like where the hell should they get the sources from to make a good Patch for this Yeah, so why is they know SPF record for bluetooth.lo? This this the bluetooth.lo domain. I don't know. So for some legacy reasons. I I Still have some website Hosted at one and one or I don't know. It's now United Internet or Ionos I don't know what I just I just clicked it there and there's nothing properly configured on it. I'm sorry And Last question why does unicorn wear an antenna on its head? Yeah, so that's that's a controversial thing Like if tinfoil heads actually help you to get less radiation or if they increase radiation Yeah, so I don't know but I mean it looks at this stylish. I guess so Enjoy it. Enjoy the the hat Yeah, so I Don't know so now you can probably see it better. That's that's the awesome tinfoil head that my friend Made for my unicorn when it graduated Okay, so I think that's the questions already Yeah Cool no more questions. I guess except from if I hear something in the mumble but Looks all right So we can probably hand over to Jan