 Hello, everyone, and thank you for coming. What we are about to speak today is Bluetooth security and actually we are focusing on Android smartphone and some kind of interesting stuff. So the talk will be divided in two parts. The first part we are giving you a little overview about what is Bluetooth and how does it work. And the second part we will focus on the new stuff. Okay? So little introduction. I'm Matteo Becaro. I'm security consultant at Secure Network in Italy and theoretically I am also a student. And let me give the word to my friend, the other Matteo. Hi, all. I am Matteo Collura. So same first name. You can make some confusion maybe sometimes. I am a student at Politecnico di Torino. This is the logo. And I'm an electronic engineer researching different fields such as Bluetooth and NFC. And okay, here you find some info about my contacts. Okay, so let's start this talk from the name of Bluetooth because it is nice to spot this nice Scandinavian humor thing. Because the name Bluetooth actually comes from the name of a king of Denmark, I think, of the 12th century. And his name was Harald and the surname Bluetooth. And as you can see, those runic tractor stands for H and B. They met together. And this is in the name of Bluetooth, the logo of Bluetooth. Okay, this was a nice thing about that. And it is a cable replacement protocol actually. And it works at the same frequency as Wi-Fi, more or less. You try high frequency. 2.4 GHz. 79 channels usually. And so it is a multi-path and adaptive frequency hopping transmission. Okay, this is some info regarding the architecture. Well, actually it is not so useful from the point of view of the user. Maybe it is useful for the designer. Because we can see there are a lot of protocols we may use in order to build our stack and our architecture. And first you start from a physical layer in which you select your proper radio. And then on the top you put your baseband. And here there comes some very, let's say, important and mandatory protocol. This one is required in order to establish and manage the links with our devices. And it comes along with this, the logical link control and adaptation protocol. And they're used in order to, let's say, link the devices together. And then the service discovery protocol is another mandatory one. And so you can build so many different stacks here. But it is not so useful from the user point of view. Okay, there has been so many updates as regards to Bluetooth. And from version 1 to 9 to version 4, 3.2. First of all, they started, well, they introduced the physical address for the Bluetooth and the first version. Because obviously you cannot target a Bluetooth device without knowing its address. So then it became a IEEE standard in 2002 with version 1.1. Then introduced the adaptive frequency hopping spread spectrum. That was in order to make it robust and resistant to interferences and is dropping, well, theoretically. After that they know how it was made. And it was, well, not so simple, but it was possible to drop our Bluetooth communication. And after that, from version 2, was introduced the enhanced data rate for faster data transfer. So two devices actually were, it was easily to transfer a big amount of data between two devices. And two new modulations, the Gaussian frequency shift king and the phase shift king, were introduced. So this is just for telecom people. I don't know if there are telecom engineers here and they are glad to hear about it. Then from version 2.1, a very big update regarding the secure simple pairing. Because before this update, well, the pairing mechanism was not so secure, well, it was not so secure. Let's say we are speaking about security, but we will see later. And from version 3, some updates regarding data transfer. Because when you have very high data to be transferred, you use the Bluetooth connection in order to make the pairing and exchange some keys while you are transferring data using a wireless, well, 802.11 protocol. And Unicast Connectionless data was an update for the use of Bluetooth, for example, in museums and places where you need to send little pieces of information of data to some devices. And this was done by passing, well, not considering the whole procedure of connection between two devices, just sending little pieces of information. From version 4, Bluetooth low energy was introduced. And it is called Bluetooth low energy or smart Bluetooth, it depends. And from version 4.1, they lowered the consumptions. Well, maybe you heard about the low energy Bluetooth as the protocol which is consuming the few power. Because the duty cycle has been improved. And so the discovery time has been limited so that the transceiver is not on so long. And you are lowering the consumptions. From version 4.2, the data packet of low energy has been extended to, from 22 to 27 bytes to be transferred. And we will speak about secure connections of low energy. So some, I will quote some of the past vulnerabilities and regarding Bluetooth. And let's start with the Blue Snarf. It was published in the late 2003 by Holtman and Lowry. And it was a talk given, well, some papers you will find online. And actually it is exploiting some insecurity of the OBEX protocol. The goal of this, well, this exploit, by this exploit, you can make some easy decisions and get requests to common files. At the time, you applied this vulnerability on mobile phones and pocket palms. Because there was the most common devices with Bluetooth enabled. And there were the devices where you can get some information exploiting this, well, using this exploit. And so if you make some get requests targeted to common files such as calendar or contacts, you know the name and the part. And you actually were bypassing the security manager, Charles and just going through this protocol of exchanging files. So the user was not seeing any prompt on its device. And there was no authentication needed. And then I will quote a blue bug which was a nice exploit by Adam Lowry and Martin Hurford. And we are lucky because he is sitting here right now. And he will be glad, he will be glad, I think, to explain if you have more questions, because of course better than me because he discovered this. So it was presented at DEF CON 12 in 2004. And it was regarding the Bluetooth implementation on mobile phones, especially Symbian OS. So I want to know how many of you did actually pawn a Symbian OS phone? So raise your hand. How many of you? So many? So few of you? No one of you pawned actually a Symbian OS phone? It was so fun. Martin, you don't count. Sorry? Really? Bad thing because I remember when I was, I think, 13 years old, it was the time, I'm young, maybe, I'm just 21. At the time I was 13 years old, 14 years old. And I remember it was so funny to play with those nice vulnerabilities because they collect them all in a proof of concept application called the Bluver. And it was so funny to hug your friend, phone, when they leave their Bluetooth on and you just connect them to them. And it was possible to control the device, well, send some controls like send an SMS to another number without making them see that you were doing that or calling other people. So when we were at school, for example, you were also able to make them ring their phone and they say, oh, fuck, what's happening right now? And the teacher, oh, what are you doing with your phone? It was so funny, man. So fun. And, okay, and so you were able also to download items via Obex protocol. It was maybe the first time smartphones had some cameras on it. So sometimes you were getting some pictures, let's say, well, some very hot pictures from, well, at the time we were chill, well, boys, guys, so it was not legal. But for just our fun, you find some pictures of people, I don't know, playing at home, so you rest very badly. And you say, oh, hi, what were you doing with your mom, maybe doing something in the kitchen? I don't know. So you were like, hey, I got this from you. Oh, how come? And it was so funny. And so thank Adam, Laurie, and Martin for this. And then another one I want to quote, blue chop. And it was useful to break the connection between some devices. And this was possible, provided the master device was supporting multiple connections. So the only thing you had to do was spoofing a random slave out of the pico net. And so spoofed his address and contacted the master. At the time, the master was saying, oh, I have two devices the same, what the hell? And the pico net was this update. Then I will quote other known exploits like blue dump in order to get the link is blue bump in order to push and the link is, but there are a lot of things I will leave the references to if you want to, let's say, know more about them. And so a little explanation about the pairing. And then I will leave for the new stuff. This is more, maybe more interesting and funny to hear. Okay, this is how the legacy pairing procedure work before version 2.0. So there are two devices, device A as initiator, device B as a responder. And the initiator was saying something like, hey, I want to connect you, this is my random number I created right now. And device B said, okay, thank you for giving me. And it's just computing by an algorithm, the E22 algorithm. And it takes as inputs the address of device B, a pin number inserted, and the length of the pin, and random previously created. The device A make the same exact thing, and there is no check between the two devices if that the link he created is the same. Actually, this check happens later when there is the authentication procedure. And at that time, it works in this way. The verifier just sends a random number to the claimant and say, oh, this is my random number. The claimant computes by another algorithm, an hash as res called here. And transmits back to device A, which computes the same exact, which applies the same exact encryption algorithm and checks if the two are equals. This time, if they are equal, the authentication happens. But this link he is the link he previously generated. So no check if it was the same at the time. So here, there are a lot of exploits, but we're not speaking about them now. And after version 2.1, it comes the secure simple pairing. So the device A, the initiating one, generates a random number, an A. And the device B, the non-initiating, makes the same. But another random number. Then the previous, then, this favoring mechanism, the two devices have already exchanged their public keys, named the PKB and PKA. So the device B will send the result of this computation, of this algorithm, to device A. And they will exchange their random numbers. Then device A will check if the algorithm worked well. And compute some results and check. Each one computes a number. And the users, at the last step on their display, they visualize the final number and they have to say, okay, it is the same on the two sides, in order to confirm the pairing. Just the last thing about Bluetooth Low Energy encryption bypass, there are three different keys needed to establish a connection in Bluetooth Low Energy. And the nice thing about this is that after the temporary key, TK, named TK, is generated, the way in which it is generated is actually transmitted in plain text over the air. So the problem is that if I'm able to decrypt the TK, actually I'm able to get the short-term key and the long-term key from this procedure. So it is a problem. And there are just three ways in which the TK can be established. Well, if the pairing mode is just works, is a name for the pairing mode, the TK is set to zero. So simple. If it is a six-digit pin, the TK is, well, it is just a six-digit, six-digit pin. It is a six-digit number padded to 120-bit number. And it can be easily brute-forced using a PC and it can be easily brute-forced even offline. Less than one second. If it is out of band, well, it means that that passage is transmitted in another spectrum band. And so it is not so easily to be detected. So temporary key, okay, I just wrote fuck yourself because it would be actually kind of impossible to find that if it is well-chosen. But never say never. And if we get the temporary key, so we get the short-term key and the long-term key and then answer all the questions for T2. And so that's it for this part. Just I will leave one sentence my professor used to say in his lectures about this passage, the out-of-band. Because if you are sure you are fucking someone saying, okay, you will never find it, well, look at your back, look behind you because sometimes there is someone else who is gonna fuck you before. So be careful during this. Okay, so I will leave the back to my friend. Okay, so, okay, let's go on some new stuff. So a little overview about what smart lock, smart unlock is. It's a feature introduced in Android 5.0, lollipop. And it enables the user to unlock the smartphone by passing its lock screen if some condition are met. And this condition can be location unlock in which the user can set like a geofence. And if within this geofence the Android smartphone is automatically unlocked. Then we have the NFC unlock in which, you know, the device must be near NFC tag, previously saved. And if so then the device automatically unlock. Then we have the face unlock, which is just a geometric face scanner, something like that. Of course, the face must be saved before, you know. And then we have the body unlock, which I actually have no idea what it is. I mean the problem is that the smartphone is in contact with a body, not your body. So if I store your smartphone, it will be unlocked also with my hand. So I put up a lock screen. Anyway. And then we have the Bluetooth unlock, which is what we are interested in now. So the Bluetooth unlock maybe is the most used feature. I actually use it in my car when I'm driving and I should not text. So I can bypass my lock screen and text quickly to not be sold by the police and stuff like that. Practically the user must say, okay, I have this pair device and I can mark one of them or more than one of them as trusted. And then from this moment every time I'm connected to this device the lock screen is bypassed. I don't have to put my pin code. I don't have to do my swipe thing. And you know, what's the problem? Actually the problem is that in Android version, Android 5.1, the link is not checked to verify the device. What does it mean? It means that if I have a previous save connection, I mean the link is not necessary for the connection. So basically how the Bluetooth unlock works. I have to initialize a connection. This can be done by the smartphone or the device itself. And we have two possibilities. If the Mac address of the Bluetooth device is known, then we don't have to check the link in and just give some details, get some details from the device, like what kind of device it is, some headset or, you know, car Bluetooth, enable or something like that. Otherwise if the Mac address is not known, then we have to start the authentication process we saw before. Then we can do all the other stuff and then the connection. So from this picture you can see there is only one thing we need to know to create a connection to the Android device, which is the Mac address of the target device. And to get the Mac address, actually we don't require all the Mac address. In Bluetooth you just need to know four bytes, the least significant four bytes of the Mac address in order to establish a connection. And actually we have two possible solutions, the brute force solution and the sniffing solution. In brute force the problem are that it's low, it's expensive and after all it's not a good idea. The sniffing solution has some cons too, which is it requires vicinity of the victim, the target can become aware of you, which are trying to do heavy things with your computer and you need to sniff the authentication process in order to get the four bytes of the Mac address. So we said that brute force is low because the Mac address cannot be brute force offline, we need to create each time a new connection with a new Mac address and it takes time, a lot of time. It is expensive because we can try to speed up the process, paralyzing, creating, having more Bluetooth dongle or stuff like that and create new connection with each dongle. And so we have to buy a lot of dongle and it can be expensive. And as I said before it's not a good idea because we need to brute force like 42 bits of data, it's not possible after all. So the other idea is sniffing. As I said before, sniffing has also three problems. You have to be near the victim and in order for your Ubertoot or whatever you are using to sniff the connection to intercept the packets, you need to intercept an authentication process to get the whole Mac address bytes you need. So it's not that easy and the target can become aware because we are not like normal people. They saw us strange way. I mean, if you are your Starbucks and see someone like this one playing around, this can be a problem. I think this guy is awesome. I saw the picture when I was in high school, wow, I won't become this guy. If anyone knows who he is, please tell me. Anyway, let's go on. So our solution is like an hybrid approach. We know another thing about in the Android devices. Actually this thing is true also for other kind of devices like in my car, up on the same thing. Android automatically sends out like beacons, maybe you are familiar with beacons in wireless Wi-Fi solution. And Android do almost the same thing. It tries to connect to previous save the device, sending out part of their Mac address. So since the trusted device must be already been paired with Android device, the beacons contain also part of the Mac address of the target device. So we can intercept those beacons which are in clear text, retrieve three bytes of the Mac address and brute force the remaining byte, which means 256 possible Mac address, which is way less than 32 bits of entropy. Moreover, the last byte we need is also part of the manufacturer byte, the manufacturer part of the Mac address. So the real possibilities are much way less. Okay, now I have like a little demo showing you how does it work. I'm sorry that the video is a little messed up. Sorry. We like recorded it in the night with beacons, parties. So there is some, I try to explain it if I remember. Okay. So how does it start? Okay. Wait. I had this Windows solution. Just a second. Okay. Okay. So basically what we are doing now, okay, go on and back. Sorry. So basically we have our totally legit Mac address for our computer. And what you are doing now is like scanning if there is some device. Actually, we are looking for a specific device, which is our My Headphone. Oh, come on. Okay. Okay. So the highlight Mac address is the My Headphone Mac address. Please don't fuck with my headset. Please. Okay. So we need to spoof this address in order to create a connection. So we use the BD address utility in order to do that. And after some glitch of the video, we should see that the Mac address is now changing. Just reset the interface, the Bluetooth interface, to apply the changes. And we need to just to make the device, the computer, Bluetooth visible. So the Android phone can scan us and try to connect. So we do that. We start a HCI dump, which just intercept all the HCI packets in order to see what's going on. And then from the, this is my tablet with Android 5.0.1. And we are in the lock screen, actually. And we start Bluetooth. It automatically tries to connect. We see the MyTablet Mac address. Wait, just a second, please. Okay. Here, this is MyTablet Mac address. It's not randomized. Again, please don't fuck with my tablet. And after the connection starts, we can see from the tablet view that, okay, you see the little lock here at the bottom. It's open. So the lock screen is actually bypassed. I can unlock the device and, you know, browse it and do stuff, whatever I want. And this works for a fixed amount of time. After that, the Android device tries to send data to the Bluetooth device. And since the link key is not the same, because we actually don't have the correct link key, it recognizes these things and drops the connection. So we will see in a moment that from HCI dump, the connection is dropped. Okay, just, I got a notification and here we are. Remote user preliminary connection. So that's the way it works. Actually, we didn't brute force anything. We didn't do that because we had no time to create like proof of concept thing. And we will try to do that in the future, release it on GitHub or anywhere open source, you know. Okay, so that's nice. We have only one problem that our Android device sends out Bicons for all the previous connected device. So how to fix that? Well, actually enjoy the 5.1 add the nice feature from the lock screen. I can choose which device I want to connect to. And so I can send the Bicons only for that device. So if I see a computer, it's probably not a trusted device. If I see a smart watch or something that has more possibilities. So I have another little demo for you which actually just show these things. Let's hope it works. Okay, so this is my computer with the Ubertoot scanning. Intercepting the clear text packets, the so called Bicons. And from my smartphone, I just enable Bluetooth. And we will see that, okay. We will see that it's automatically try to connect to my headset. And in the Ubertoot screen, we see LAP which is the part of three bytes of the MAC address we need to establish the connection. So just clear text data. Pretty easy to intercept. And now we just boot force one byte. Actually, this is done without the handset near the smartphone. So there is no need to have both of the device together. Okay, so this is fixed actually in Android 5.1, I think. The Android security team fixed it. So the link now is checked. But there is still a problem because the API is not fixed yet. So if you have an Android device with the version prior 5.1, you have the smart unlock feature still vulnerable. So don't enable it, I think. And otherwise, only the API are vulnerable. And what does it mean? It means that, sorry, there is no method to check if the connection between a Bluetooth device and your Android smartphone is on an encrypted channel. So there is no way to check if the link key is correct or not. And we said that to the Android security team and they told us, wait, there is the feature is in the source code of Android. Check it, this link, and this is the method actually. But it's not present in the SDK yet. And this was true in April and it's true also now. So actually I think they probably implemented it in Android M or whatever. I don't know. So, okay. But Android smart lock is fixed. So we are pretty safe now, right? No because we have a third-part application. Actually, there is some application which uses this feature, some application which implements the smart unlock for Android device prior version 5. So if you don't have a lollipop, you want the smart unlock feature, you can download the application and set all the things. So then what I, okay, this video is really messed up. I think we were drunk, completely drunk. Probably you won't see anything. Sorry for that. There is also my big face. I don't know if you can see that. But there is, we should not tell them what time we recorded that video. We should not. No. Okay, so it was in the morning. We were totally fine. Okay, let's start the video. I repeat, sorry for that. I try to explain what you should see. Okay, actually, we have our, again, we are completely legit MAC address which is Coca-Cola. Okay. There is almost visible. And we are trying to change it again to the My Headset MAC address. Then we start with the interface and start, sorry. And we will see that the MAC address is actually spoofed. So we just need to make the computer visible to other devices. Oh, that's what I'm talking about. Well, actually, it was what we were seeing, maybe. Don't say that. He was recording. Okay, so, wow. Okay, we put the device in visible mode and then we start the HCI dump again to see what's going on. And then we move to my tablet with Android 4.4.4.4. Something. Okay. And just turn on the Bluetooth. It automatically tries to connect to the computer. You see? Okay. And it's a very shitty video. You can see device unlock. I don't know if you can read, but it's written device unlock. Trust me, please. We see in the computer view that we have the connection. The connection is terminated right after that. But we actually had time to unlock the tablet and, you know, browse the video, browse the photo, get some porn picture, whatever. No. It's not your device. So after that, after the connection is dropped, the lock screen is enabled again. But if you already unlocked the device, you can just don't lock it again and browse it, bring it home and reset it, you know. Whatever. So, okay. Thanks, God. The video is over. And let's go to FutureWorks. So just a few things about our FutureWorks. Oh, okay. Thank you. Thanks. Yeah, okay. Just something about our FutureWorks. As you can, as you know, probably, the IFC world is growing up very fast and quick. So IOT devices are going to be more, more, more, more, maybe they're following something like more slow and getting small, but spread over the world. And so we are focusing our next researches on those devices. And by the time, at the time, right now, we have some concepts about smart locks, which are those kind of locks. Smart locks. Yeah. So please, choose those locks for your door. They are completely secure. Send us where you live. And we will make a check if it is working. Very Italian. You can prepare dinner, some food. You can have a dinner together. Bring a coffee. Yeah. So smart locks. We have one and we just bought. So we are going to spend some time on it. And then some other devices like FitBand and like Jobon, FitBit, those kind of bands that are working on low energy Bluetooth. And this is our future work. So maybe you will see us again in the next month with new things. I hope so. And so I just want to thank you for your patience and your willing to come here and look at our talk. Really thank you. And now it's Q&A time. Q&A time. You have to ask questions, you know? It's not to go away time, but turn off your Bluetooth. Question over there? Yeah. The white paper of that, all the slides and I think I won't put the videos, but everything else will be online. I think I put on my Github and probably on the Defconn website. Other questions? Don't be shy. We have time for a couple of questions, but if you are leaving, please leave through the back or the right hand side. Do not go this way because that poor guy with the red shirt over there will just push you somewhere else. What's that? Yeah, the right side. Oh, so can we have a microphone for that guy over there? Oh, I can hear you. I can hear you. Sorry. Oh, a Windows phone. It's a new brand, you know? Smart Lock. Oh, sorry. I heard smart phones. Sorry. Be something. Oh, it's called Danalock. Danalock. You know that? It's European, made in Danish, Danalock. We both, it's quite expensive. I think I paid that like $300 or something like that. But we actually try to get us some money to buy other locks as well. I think the one is called, oh, I don't remember the names, but we want to try three, four locks and test some things we have in mind. So if you have some bit comes to share or to donate, we are. No, no, we don't accept Bitcoin after empty gox. Anything else? Oh, yes. What? Smart card? Oh, I never saw a smart card with Bluetooth. Sorry. Do you have one? Not smart card. Oh, smart card. Oh, machine. Sorry, sorry. No. No. Because I'm poor, I don't have a car. No, I'm joking. Actually, I don't have a car with the possibility to unlock it with Bluetooth. Yeah? Can we have a microphone, please? Because I'm, I can't hear, sorry. Thank you. Have you guys worked with the Apple home kit yet to understand Apple is requiring 30, 72 bits of security for Bluetooth to connect or for the IoT stuff to be, to qualify for home kit? No. No, we actually don't. Sorry. I recently ran across the new target for you guys, Bluetooth vending machine payment system. There are no Bluetooth vending machines in Italy. Sorry. There's actually one, if you want to go play with it at the atomic museum. I think that's illegal. Just give me the address, please. No, okay, joking. Thanks. What is it? Anyone else? I need the address. Bueller? Bueller? No? All right. Well, in any case, I want to thank these guys. We will bring it out all the way. If there are any other questions, feel free to go. I'm not done talking yet. Okay, now you can clap. Thank you once again.