 They both are from Munich, from Munich TCC, Hackerspace, and they have yet another talk about lockpicking, I guess. And this time it's about Bluetooth lockpicking of hotels, which I find very interesting. So give a big round of applause for Ray and Emha. This is not Hackagepity, but thank you. Okay, so welcome to our presentation about Bluetooth lockpicking. Who of you did a short race of hands did already lockpicking? So who did Bluetooth lockpicking? Oh yeah, you're perfectly right here. We'll show you how to get into this, and it's a lot of fun. Okay, so first, who are we? For the people who don't know us, Ray. I'm a security researcher, lockpicker, interested in technology and of the Moussi Sisi. And for some reason, I spent many, too many nights in hotels which led to this research. Yeah, hi, I'm Michael. I'm basically a lock nerd. I have been collecting locks since I was a little child, and I never stopped doing that. When I was young, of course, they were mechanical, so I started lockpicking. I joined Sportsfeuner Spertechnik. We also have a tent here in the village, so you can improve your lockpicking skills there. But then all the new locks basically became electronics. So I became an electronic engineer and continued to do that. And yeah, this led to Bluetooth, finally. Yeah, we already had this presentation in an earlier format, a small conference in Vegas, but we were a little worried about their bandwidth capabilities, so hopefully now with MediaCCC we got a good provider to get this content out to the open world. So what is it about? We're talking about smart devices or so-called smart devices using Bluetooth low energy, and we'll show you how to analyze them, how to hack them, and probably if you're building such things, how to build them in a better way. And of course, we'll tell you about vulnerabilities. We found that way, starting from cheap padlocks, some prior research, and then go to hotel systems, which is the newest thing we discovered here. So we give a short introduction about Bluetooth low energy, how these systems work, how to analyze them, and at the end also tell you a little bit about the responsible disclosure process we had with the hotel vendor affected by this vulnerability. Okay, so how does such an ecosystem look like? You basically have a lock, and this is communicating to your smartphone using BLE. But of course, the smartphone is also communicating to some backend in the internet where it gets key data or permissions or stuff like that. So what are the attack vectors and such a system? There are various. For one, you can attack the hardware itself. So on the lock hardware you have electronics, you can read out firmware, you can do side channel attacks, probably power analysis to get out AS keys and stuff like that. You can insert wires sometimes to get to the contact points for flashing or reading out the flash without opening the device. And there's mechanical attacks like vibration, shocking hammering onto it, magnets and stuff like that, attacking the mechanics itself. On a smartphone, I think this is something many people here are familiar with. There might be malware, and there might be distance frauds. That means you have your smartphone somewhere and someone is relaying your data somewhere else to attack your lock. And of course, on the internet API, there is a web server. So web servers have weaknesses, API implementations have weaknesses. There might be wrong authentication or no authentication at all. So this is also a big part. Lots of research has been done there, but this presentation is not covering a lot of this end of the ecosystem. What we will be starting looking at is the connections here. So we have a BLE connection between the lock and your device, and we have an internet connection between your smartphone and the backend API. And both of those can of course be sniffed. You can machine the middle attacks them, and you can do impersonation of one of the two sides of the communication. So taking this all together, there's quite a few attack vectors in such a system, and surprisingly, those systems often fail in some way. So BLE in a very short introduction, as I said, is Bluetooth Low Energy, and it was designed as a cheap alternative to classical Bluetooth. So it consumes less power with devices running on battery and stuff like that. It is part of BT 4.0, so it's out there for quite a while. And for people familiar with classical Bluetooth, it's quite different. So the use cases are mainly devices connected, so-called IoT, but usually they don't have an own IP address. They communicate with the smartphone or other device having an IP address. So the various things like locks, light bulbs, we heard about sex toys, I think at Congress, heart rate sensors, stuff like that is using BLE. But what's about the security of BLE? I think there's also a lot of prior research on this. One of the first papers on the Woot 2013 conference was called with low energy comes low security, and that's basically true. So there are secure options like an out-of-band or BT 4.2 elliptic curve pairing, but they are very uncommon. So usually you can just sniff these connections with easy measures. And so the application has to provide the security for the system, which often fails. So how to find out these vulnerabilities? So we're looking at the BLE layer now. First, if you have such a device yourself, you install the app on your phone and you can yourself analyze your device speaking to your lock or whatever. So on Android, there's a very easy option. You just enable the debug mode and activate in the debug menu the HCI snoop lock. So then it writes a BLE pickup file to your file system. On iOS, there's a similar possibility. You can download a Bluetooth debug certificate from Apple. This is for a few days valid. You install it and your device starts to lock the BLE traffic. So what you then do is you use your app like you normally do. You open your lock, you activate your light bulb, stuff like that. And I would recommend writing down time stamps of various actions. So like at two minutes, whatever, I opened the locks and I closed it so you can later correlate that to your Bluetooth event. And then you get your lock file from the phone and you can just load it into tools like Wireshark. Wireshark, I think many people here know, has support for BLE. So it will help you decoding it. You can see here the sender in the receiver side and it decodes the Bluetooth protocol stack. So it shows you what kind of request is it where in the layer is the packet and also shows you which is most the interesting part, which data is written to which Bluetooth handle. So here you find the data of the Bluetooth communication. So that's what you do with your own device. But if you want to attack a system or if you want to see if it's a real possible attack, you have to sniff the BLE from the air. So it's relatively easy because there's only three advertising channels where you have to listen to to get the connection and just cheap sniffers out just starting at like $25 like the Adda Bluefruit, which I'm pretty sure many people here have, or the Ubuntu's one, which has a few more capabilities. Both of those support a Wireshark live view. So if you have the plugin installed, you just get a live data stream in Wireshark. The drawback of these devices is you only have one advertising channel and if the device you're sniffing doesn't use a standard hopping sequence, you probably miss the start of the connection. So these tools are perfectly fine for proof of concept. If you want to see, okay, I really can sniff this data. But if you want a more reliable attack, our favorite tool is Beetlejack. Beetlejack by Damian Cockwell was released, I think, at Blackhead and it provides firmware for cheap BLE USB devices like the BBC Microbit. So those can be bought for like 15 euros or something and it flashes in firmware on it or the BLE 400 boot or 400 board or even the Addafruit tool. So it supports three devices connected to USB, setting each one to different channels so you now monitor all advertising channels and basically get every connection every time quite reliably. And these tools can do much more than just sniffing. They can, for example, hijack attacks or relay data but we focused on sniffing here. So if you set this up, or I set it up like a very creative way that works basically, Microsoft that looks ugly and builds a quite nice setup using Raspberry Pi. So this is an autonomous sniffing setup running on a battery. You could fit it into a smoke detector, put it somewhere, have it running for a few hours and collect data. There's also a new tool out there called Mirage. It is the author that he looked at the other tools and tried to build something better. It has probably some more capabilities, especially in the part of mandible attacks or something like that. But with powerful tools, there comes complexity. So for starting, we still recommend using the Beetlejack tool. But if you hit a point server, it doesn't help you. Have a look in Mirage. It might be a tool of choice. So now we know how to look at the Bluetooth layer. What's about the backend link? So it usually is TLS encrypted with modern apps. There's very, very few apps still using plain HTTP to talk to the backend. But if you're analyzing it on your own device, of course, you can just install a fake root CA and there's machines and middle tools which create certificates on the fly. So you direct your internet traffic through your tool, have the fake CI installed, and then all your TLS traffic is readable for you. To make it clear, this is not an attack you do on other users. This is something you do to get your own traffic of your own app analyzed. And I really can recommend you doing that just to look what all your apps are doing in your system. So using such a fake CA is quite easy on iOS. You just install it and say, I trust this CA. It was the same in Android. But starting with version 7, Android apps don't trust the system certificate store anymore. So you have to, or the difference shape between two certificate store. So you either have to root your device and just replace the original CA store. Or you can, if you for some reason can't root your device, modify the app. So you have to unpack the app, add a network security config to it telling you, telling it, I want to use the user certificate store, rebuild the app, sign it, install it, and then you can also manage the middle traffic on a non-rooted phone. So usually that works, but there are a few apps trying to prevent this by measures like key pinning. And Mike will tell you about that. Yeah, this is an example we found at the conference hotel in Vegas. We didn't hack the system. Of course, we just wanted to see what it's doing. And this is a very nice example because the app actually tells you what went wrong. It says code certificate pinning failure. So basically this app was like, okay, I cannot trust this Android device anyway. I have to check the certificate myself. And that usually doesn't mean the end of this analysis because there's other ways. The first one is really basic and simple, but we think it's a good advice. It often turned out app vendors usually do at least two apps, one for iOS, one for Android. And really often one of the apps doesn't do the certificate pinning, so just try the other one. Or for Android, you can easily get an older version of the app from the internet and try that. But if that doesn't help, then you could modify the application and re-sign it and we'll come to how to look into what to modify. We'll come to that later. You could also use a tool called Frida and potentially the Objection Framework. And that's a really powerful tool for mobile application. It's kind of scary if you're an app developer because this tool allows you to basically change everything. Just a quick example in this 45 minutes, we can't do this in detail, but there's good tutorials. What you would do is, in the example of an Android device, you have a rooted Android device, you run a server component there. Then you could try this Objection, as I said. Here's an example. I think it was the Master Lock BE app, where you just use Objection and type in Android SSL pinning disable and you would get that. If not, I mean if Objection doesn't help, you would have to analyze the app. You would have to write a small JavaScript file, like shown here. This basically overloads the check method of the OK HTTP framework, and it always just returns and does not throw an exception, and it locks out something. In the end, you will basically, at the bottom, you see one of the tools showing the traffic. In this case, you see the non-encrypted traffic. Our opinion is, it may be nice to protect the user from ROGCA that somehow got installed on the device, but if you want to do a secure protocol, that's much better than trying to hide it through this method. Don't rely on SSL pinning. People will be able to analyze it. Okay, now when it works, there's two second use. For example, on the Unix command line, you can use the Mitten proxy. On Mac, I like Charles proxy, but there's many more available, like Burp and Fiddler. The example of the Mitten proxy on the command line is shown here. You can see a flow of the messages, and you can scroll up and down. When you zoom in, it will nicely decode the message for you, show it. This is actually an example we will also come to later. Our advice for you would be to use all these tools when you unbox the system, because you will probably otherwise lose important events, like the first firmware update and maybe the last firmware update was easier to analyze. It is really advisable to have an old Android device, and they are not that expensive. Root it and use it for that. Okay, so now that we know how to get to the data, let's have a look how to analyze it. Basically, you get a lot of bytes, right? What to do with that? We brought an example here. This is a very small, very cheap padlock. It's not really mechanically sound. You can probably just bite on it and it will break something like that, but it's a very nice puzzle. It's cheap. You get it for not much more than $10 from Amazon, or from Alibaba or something like this, and it's a nice puzzle. Basically, you can spend a weekend analyzing it. Interestingly enough, we found that this company sells other locks, for example, bike locks, and there is our friends from Radforschung. They do the bike sharing system here at the camp. They also encountered this, because basically this also comes as a bike lock or a scooter lock. It's also integrated into some, you know, these e-scooters that now pop up on the streets. It's interesting to look at the protocol, and we have to be careful here. This was last year, and the company did improve this in the meantime. For example, in 2018, they did not use HTTPS, so all the Mitten stuff was not really that difficult. You could just listen to the transmission. You would see the password and plain text. And yeah, if you look closely, oops, sorry, if you look closely, you would also see in the transmission from the backend server to the application, you would see 16 bytes that are called lock key. Yeah, so 16 bytes is 128 bits, and it's a very easy assumption to think, well, maybe this is AES128, because that's used in many systems today. So when we looked at the Bluetooth traffic on the left side of the image between the lock and the smartphone, initially it was all random. You just saw randomly looking bits, so you couldn't find out anything. But then we just had a lucky shot on this and used AES decryption. You find even online tools to do that. And yeah, now it doesn't look random anymore. If you look at this closely, you see many zeros, and this is obviously not encrypted, so we got the right way to decrypt it with a lock key from the backend. And then what do you do? How do you find out more about this? Basically to analyze that, you open this lock several times and record several sessions, compare them, and here we underlined bytes that are of interest. And if you do this for a few sessions, you will find some obvious pattern, like, okay, now it's requesting something at a response. There is a session ID, in this case four bytes, sometimes only three bytes. That is always the same. And basically, yeah, this is an example where you can deduce a protocol from just looking at it for, let's say, two hours. And in this case, what we can see, there is a replay protection, there is a random, or nonce, basically, a random value that is created by the lock and changes every session. But as you can see, it does not change within the session, so there's no counter or something like this. And with tools that can actually hijack a connection or that do man in the middle and you can replace and replay things. This may be an interesting attack vector. What would be the next step after you have analyzed this? You could write a software that mimics the application. We use Python for that on a Raspberry Pi. And there's BluePi, for example, as a library. And then you can basically emulate the application and try it yourself, and then you can modify small things and see what happens if I modify the session ID. Will it still work? Will the lock reject it? What happens? And use fuzzing. Doing this, we didn't find any obvious weakness, except for things like, yeah, if you share this secret key with somebody else, then you cannot revoke it because you cannot change it. Well, yeah, but you also want to look at the whole system, of course, yeah? Maybe if somebody integrates this into scooters, do they use a different key for every scooter? Or does this backend really work as you would expect it? Does it not give you other users' keys? Of course, in this case, you have to respect the laws. Oh, yeah. That was a protocol that is not too difficult to understand. What do we do if the protocol really doesn't make sense at all? Next step could be to reverse the application. This also has legal implications. You may have to check the laws. There are certain reasons why you can do this legally protected, but check that. When you recompile an application, you get source code, and you can analyze the source code for Android. That is not too difficult because it's Java, and Java can be recompiled rather easily. In some Android applications, there is native code, that's C++ code, and then you need tools that recompile this. There's, for example, the Ghidor tool by NSA that does that, or Eda, many of you know. For iOS, it's very similar, but you have to get the application first decrypted way. And then you could also use Hopper, for example, to decompile ARM code. When you have that, what do you do? You will start searching for anchors like Android or Bluetooth. If you find something that's Android or Bluetooth.Bluetooth get characteristic, that's where the data is sent or received from the device. You probably also search for things like AES or key. And the second example, that's the real example, if you find a key like this, 0, 1, 2, 3, 4, 5. You may want to look closer, because there may other things be hidden, and Ray will come to that soon. Yeah, the other thing, the one thing that often happens also is that the app is obfuscated, and even though there are symbols in the application, they are just like C0001. And that's extremely hard to read. So it is not really difficult if you use a tool that's made for that, like Android Studio for Android. In this example down there, you see there is an array. On the array, if this is null, then key data is null. It's presented, and this wasn't obfuscated. So then you just replace key data everywhere, and then you go back from this anchor to getting something readable. So on obfuscation, we have a very strong opinion. It doesn't make sense to do that. It makes review harder, but it makes review harder for people that are friendly and will do responsible disclosure. Terminals will still do that, and they will not inform the vendor, so don't do that. Do a proper secure protocol, and then you don't need to hide it. Okay, so what did you find so far using these techniques? Yeah, so a short recap of things probably already published in the past. One very easy example, also something you can try out for getting started is a cheap padlock by the company Anboud. It has a shim proof mechanic, so unlike very cheap locker locks from the US, you can't shim it, but the passcode is transmitted in plain text, and to our knowledge is still the way today, so consider it a zero day, but we assume the vendor knows he is not using encryption, so we didn't have to notify him about that. So if you just look at the transmission here, you'll find a hex string. This hex string translates to decimal. Decimal is the key you have entered for your lock in the app. You sniff it on the air, you enter this code in the app, and you can open someone's airless lock. So this is the quality of these Chinese locks, but I'm pretty sure this is one singular example, right? Who thinks this is a singular example? Yeah, one hand. Okay, so there was a presentation at DEF CON two years ago, or three years into the meantime, by Rosa Ramsey and they tested 16 locks, and 12 had vulnerabilities like that one. So as you could fust them, you could simply read the passcode, you could replay data, something like that. Then of those 16 locks, 14 were padlocks, and two of those padlocks remained unbroken in this very broad approach. So these two padlocks were something by random, we looked into closer. The first one was by the company Master Lock, and we played around with it a little. So we had a similar attack on an older Master Lock, but for sure, like building a new modern Bluetooth lock, they fixed it. So we use an attack tool which is called a so-called magnet. You might have heard about it, and it manipulates the motor from the outside. So by this movement and changing the polarity, we rotate the motor inside the lock without using the electronics at all, and your $80 padlock opens. So that was easy, but not wireless lock picking. So let's look at the other one. The other one I have talked about already at the 33C3, so this is just a short recap for people who didn't see that. If you're more interested in this, just look up lock picking in the IoT and you'll find the old presentation. So the Nokia padlock was one of the first Bluetooth padlocks ever created. It was a Kickstarter project, and what I'm showing you is, of course, for the old version. They did a firmware update after our disclosure, so now this is fixed. We haven't looked into the new one more closely, so... So this lock padlock actually used 128-bit AS back then, and it also used different keys for yourself and for the friends you shared it to. Not different AS keys, but different secrets inside the lock, but the time restrictions were only enforced in the app, which was the first weakness, but that's more like a minor weakness compared to the rest. The main problem was that they used individual session keys for each opening operation, but the session keys were created in an unsecure manner. The only security relied in the secrecy by obscurity of this mechanism. So if you know how to use the disassembler and you'll find operations like XOR and look a little around it, we found out it's a very simple protocol. It sends a nonce encrypted with this pre-shared 1, 2, 3, 4, 5 key. The lock sends you a nonce. Those are added together. They are added to the center of this 0, 1, 2, 3, 4, 5 key. Don't ask me why. So 32-bits in a 128-bit key get changed with data you can reconstruct, and you've got the new session key which is used to open the lock. So when following this, you could just break the whole encryption and read out the data. So this was a more complex lock, but still in the cheap product, so now for the interesting part, hotel keys. So before that, we always had sims like padlocks, vibrators, other cheap toys. Now we encounter this in the real life. Why do they actually do that? This is really a smart idea. Of course, the main purpose of that is to get rid of personal. No making the experience for the customer more pleasant, I mean. So you can do self-check-in. You don't need a key card anymore. Your mobile phone is your key to your hotel room. So it might be that it's less personal interaction, but of course, in a hotel with big queues, it might actually be an advantage for you if you just check in your app and don't have to go to the front desk. Just walk to your room. So what are the challenges of these systems? This is not your lock. You don't have to compare to this lock getting a code from the packaging or something. There's no big chance to do a big pre-shared, secure pairing or something. Then of course, those hotels are there for quite a while. The locks are probably old and they have to retrofit the Bluetooth stuff, so they probably don't have the most modern crypto chips in there. And then of course, it's a complex ecosystem of the booking companies, of the hotel operators, of the application writing companies, of the lock manufacturers, which have to interact somehow to get a good system out. But so how does it work? So you have normal booking. You link this booking somehow to your account. What we found there is often not very secure mechanisms of authenticating. For example, you need to know a name, a date, and the booking number, which is a sequentially increasing number. And then you can create your mobile key if you know this data. In social engineering, this actually might be a way to get a key easier than walking up to a front desk. But in the normal way, you do an online check-in, and the mobile key is transferred to your app, and then you use the app to open your hotel room. So this actually was not taken at the Black Hat Hotel. We just used the Mitten Proxy to replace the logo. So this is something you can also do with these TLS tools, but you open your door and the door opens, so that's the normal use case. We actually looked into this in two different hotels. The first hotel, we call it the Hotel H, we found a system that we did not break. We looked into it, analyzed it, and found out it was quite using cryptography. So from our perspective, it looks like the vendor has a secret key KS, which is never getting known to us as a user. The back end sends us a key for our Stay K, and then encrypted version of this key K we call K Star. So now our app sends to the log K Star, and the log uses this vendor key KS to decrypt K Star to K. So now as well the app as the log knows the key K, and they can do securely AES encrypted communications. This is a protocol at least somehow working. We didn't find the direct attack vector except for probably extracting the secret key from the physical log. There's lots of talks about getting firmware dumped and stuff like that, that would be possible, but we do this in a hotel where a stay is a normal guest. So we didn't also not really experiment more into this because the system for some reason went down after our first stay. So we have no implications here. We switched to another hotel having logs by the manufacturer M. So this we found early 2019 in the quite upper-class hotel, so talking about four stars, not really five stars, which uses the mobile key basically everywhere but also can use your normal key. And we analyzed the TLS traffic and the BLE traffic. So when I do a link by booking to my app, I get some data and in this I find something called mobile key having a DT array of lots of bytes. We see only the first five bytes here, but it's more like 40 or something. When looking at the BLE traffic, I figured out I see all the bytes I get as a mobile key also on the air. So that doesn't really look good. Is it really just a replay attack? I looked at the data and found out there's quite some handshake happening before this transmission, but after some four-byte signature or something, the whole key gets transferred. So that didn't really look like it will withhold our analysis, but we first had to understand the other bytes happening before that, so Michael will tell you about that. Exactly, so we did the same thing again as we did with the small padlock. We looked at several sessions. You just open the door multiple times, record all this. We found there is something at the end that changes. 32 bits. We made the assumption that half of this may be something like a nonce. The other half would be a CSE. And for the first three messages, we were right with that assumption, so you can see underlined at the end the CSE value. You will find tools to reverse engineer CSEs, for example, CSE Refang. We, however, just used the custom Python script to try out many CSEs. There's always a seed value that can change. There's an XOR value that can change. Direction can change back and forth and so on, but there's not so many and basically brute forces isn't the right word, I think. We just tried them and then we found the right polynomial. And it turned out that the seed, the initial value, was something that's constant within a hotel. It's called SC, probably system code or something, and that's also sent from the back end. We've seen that in a message that was sent from the back end to the application. So we knew how to create the first three messages. You always need, as a seed, the last CSE. But then in the middle, the last of these CSE or whatever, we didn't know at that time, and that was more complicated. There were like six bytes, always zero, and then two bytes had changed. And we had to play with that. There were some values to play and try and play around, but essentially it's like this. There is the values from the previous calculations I used together with the data behind that, and then this used the CSE value that was transmitted by the real application. And now we knew how to create that ourselves. So that was a major breakthrough in this project. We prepared a Python script again. We're using BluePy that calculates these CSEs. Of course, you need a key somewhere. We tried that as well again. So you can see our sniffing attack here. In this case, we did it from inside of the room not to confuse the roommates and so on, but you can see the three little recorders there, and one of them was linking because it actually triggered the, it actually found the transmission. And on the laptop screen, you can see the key data. Insert this into our Python script, and well then... Yeah, then I thought let's try this out for real. I went with my laptop and a classical hacker outfit outside of one of the rooms we had, and let's try it out. So there's the Python script running on my laptop using the data we sniffed on the actual hotel door. You see the light is turning to green, and we enter a room, and suddenly it turned into a quite nice hotel suite because actually in the 37th floor of a luxury hotel. So much for Chinese padlocks. Okay, so after we had that running, we thought let's play around with it a little more, and Michael created a Python script emulating the lock. So we had the other target, the other side of the system, and we could use the real app to play with our simulated target. And we were wondering how big is this problem. We found this in one hotel, but we found out the names of these locks are base 64 encoded binary data that we can understand. So we could just by looking at advertisements from BE locks find out if they belong to the system we analyzed or not. We found another hotel chain and the third hotel chain using the system. After booking a room in one of these chains, we found an even more simple variation of this protocol. So this basically tells us, okay, this is a bigger problem, and from that we also could deduce that the vendor of these locks called Messerschmitt Systems, a German company, is the origin of this protocol. And even so they have like 2,000 hotels altogether. The system is only deployed in like, I'm not sure, but a smaller three digit number or something of them, because they're very, we talked to them and they're very early in adopting this and also they don't put this into their 5-star houses because they don't want mobile keys basically. But in other houses it's getting popular. So we thought, okay, this might be something real and we have to find out can it really be used in a real attack. So we know we can reliably sniff it, but where could you sniff it? Doing it at the door might be a problem because you have to know which lock you're sniffing. So our first way was, oh, probably there's a way to get this out much security considerations. In such a fitness center there might be options like plastic containers that aren't especially hidden somewhere. Having this nicely set up and letting our test guests enter the fitness center, we found out mobile key was down for the fitness center. I'm not sure if they wanted to spoil us or whatever, but there's a second place where everybody uses his key and this actually seemed better for sniffing because if you want to enter your floor you have to activate the elevator using your mobile phone app. So this is a place where you can very unsuspecially work with your backpack, have a sniffing set up or even place it somewhere and everybody has to use his keyser. And if you have the simulator script we built you don't even need special hardware. You just emulate the elevator lock, advertise more heavily and the app of somebody will connect to your laptop and you can complete hardware less attack except for your laptop to get the key. And of course our tool dumps the key for your convenience use. So figuring out this is a real issue which can really be exploited. We thought it would be a good way to disclose this to the vendor and we started this in April. We told them, we told them, yeah, this is the problem and nicely we got an immediate response probably because we did some research in who to write to. We sent him technical detail. First reaction was that it looks very interesting but it can't really work like that. So we sent a very specific mail telling, believe me, we did this in a real hotel. We didn't send the video so but we sent proof of concept codes, they acknowledged it and all the communication went very well. They never tried to prevent publication or anything and they started to work on the update. The challenges of course in such an update is you have to update a whole hotel system, a whole ecosystem. So we found out that the lock the first hotel where we saw the nice video this is a modern hotel being completely online. They can actually remotely update the whole system from their office. In other hotels they will have to walk from door to door to door with what I understand is an infrared update device. So this will be some work and of course the different app vendors will have to integrate the fixed system into their APKs independently of the update of the lock system. So actually this state of now still is a zero day exploit and we had some discussions also already at Black Hat if we should really publish it but figuring out that you can still use your normal key card if you figure you're in such an affected hotel and giving the fact that actually not very many people actually use it so far because it's quite coming up now. We thought it's okay. But one important lesson we learned is you have to really identify all the parties because we informed the vendor very early but the app vendors and the hotels and actually a second vendor which we only heard about two weeks ago were notified a little bit late about that. But still this was quite interesting to see contact to the vendor side and they told us they are in the process of rolling it out starting end of August. Probably this is a little bit delayed now because we haven't really heard of the new protocol yet but they're working on it and we hope this turns out quite well. So what are the takeaways you should take from this presentation? One of course is particularly as sure everybody should know by now the BLE link layer usually can be sniffed reliable with simple tools unless special measures like out of band pairing are taken. And whoever should build this I'm not addressing this to you but to the vendors looking into this talk please don't hide your secrets in apps build secure protocols. This whole things we analyzed are all obviously built on the assumptions that you can do things like that and it works out no it doesn't. And the thing we learned in this is BLE is not just used in toys anymore it's getting to the real world. Now it's in hotels probably it's always getting to really important things like your martyr refrigerator so these things are worth looking into and worth analyzing and I hope that with these entry points here and I can really recommend downloading the slides because all the blue words you saw in several links to more information help you to get into this research field and you can help us make this a safer world by hacking all these things. So thanks for attention and now we have like two minutes 50 seconds for questions. We do have time for some questions so raise your hand if you have one no, the microphone is wired so you need to come to this lovely angel in the center here and ask your question in his microphone. Yes, there is a question over there. Am I supposed to ask is it okay? Hi Ray, I'm Michael I have a question about other transports like is NFC or RFID ever used in hotel door locks? RFID is the standard way today most hotels you have an RFID card today NFC I have not seen but we have for example seen Bluetooth locking systems where you have to near your phone to the lock before the lock activates the Bluetooth but this is not what we looked into and as I said RFID is very standard and of course these cards can clone and everything but it's a different field of research. Bluetooth became popular and popular smartphones so that's the technology they all go for now but of course all the cards you get in the hotels previously some years ago they used magnet stripes but now they are RFID Thanks a lot for this answer do we have another question, yes up there go ahead. Are there some Bluetooth locks that perform some sort of pairing? We have not seen it and it's really inconvenient because you would have to spend too much time to do that so basically all the locked systems except for very few that you put in your front door all of them use just unencrypted link layer and then do the encryption or whatever they think that's appropriate they do on the application layer. The only high security device where I found pairing so far was a luggage bag showing a digital bag tag that used pairing. Thank you for your answer. Do we have any more questions? I don't think that is the case if I'm not mistaken, scream now. No questions on the internet? Okay. Or on the internet of things? No, okay. Then thank you again and please get into hacking these things.