 Let's get started then. So we really do love our conveniences. Today, nowadays, inserting a physical key into a lock is just too much work. Our lights have to kind of regulate themselves. It's way too much effort to hit the switch all the time. But we forget that this automation comes with a price. And that prices our security and our privacy. Our speakers today, Marcus Milner and Marcus Kamashteta, are going to talk about a device that actually had a lot of promise and was basically brought down by a very simple and implementational problem. And there's actually going to be a demo if you see the hardware over here. This is awesome. We're going to have a demo here. Everybody else who's not made it to this talk is going to totally regret it. So give it up for Marcus and Marcus. Yeah, thank you, everybody, for coming. I'm still waiting for the slides. Okay, that's awesome. So my name is Marcus Kamashteta, with me on stage is my colleague, Marcus Milner. And two other colleagues who have been involved with the project are also here, sitting over there, Christian Kudera and Daniel Burian. And all together, we are from the security consulting company, Drustvex KG. So I would first start out by giving you an idea who we actually are. So as I mentioned, we are a security consulting company. So we focus on security consulting, engineering and security research. The company was founded in 2012, but the security consulting work actually reaches back to 2005. And so today, what we do is we do security audits. We do security audits of web applications, software applications. So this is pretty much what everybody else is doing as well. But we have a strong focus also on embedded devices. And with our hardware security lab, we can even go down to the microchip level. So just to give you an idea of what we do, in addition to that, we do embedded in security engineering and high-speed cryptography. Second slide, this is the lab that we have. So we can really go down deep, even to the chip level. We have a focused ion beam workstation, a scanning electron microscope to do this kind of work. And typical work we do in the lab is like evaluation of, again, side channel attacks or fault injection attacks. And then we can even go to the microchip level by doing fully invasive attacks. And our general idea here is that we have more sophisticated equipment in the lab. And so we can make up analysis time. So we can do an analysis in a shorter amount of time, whereas a normal attacker who wouldn't have all these tools has typically more time to conduct attack. Okay, so now the big question, how in the hell did we get to garage doors, right? So as you might know, many of the garage door systems that are out in the field that are really known to be insecure, insecure because they mostly use static or very simple rolling code schemes. There is often no encryption at all. And for this reason, you can mount very easy replay attacks or cloning attacks. So this is pretty much known. And in contrast to that, there is the Herman B-secure system. So it uses the well-known AES encryption algorithm. It is a high security established system in the field. And if you compare that to the classical systems that are really easy to break, it is a big security improvement. And yeah, to answer the question, how we actually got to this system is the two of our security analysis, both sitting here, they have the system at home. And so they were asking the question, is the system really secure? So is the system implementation secure in practice? Does the system really use the AES algorithm? And is the algorithm used in a secure way? How is the key material generated? How is it used? Is the key material individual? Or is there maybe shared key material among different systems? What do the messages look like on the RF interface? Last but not least, the question, does the system adhere to the Kerkhoff's principle? So if an attacker really knows exactly how the system operates and the only thing he doesn't have is the key material, then the system should still be secure. And this was the point where we decided to conduct a security audit. So how do you start a security audit on a system like this, on a wireless system with all these hand transmitters and the receiver that's typically in the garage? And so we started off with the hand transmitters. So we already had a few of them. We also obtained new ones. And so what we had is we had different models. We had different manufacturing dates. So some of the older hand transmitters that we had were already bought in 2015, whereas the newer ones were bought in 2017. And so in general, we can say that our analysis then will also cover a broader range in terms of the different models and the manufacturing dates. So to start out, what we did is we conducted an RF signal analysis from the system manual we already knew that the system operates somewhere in the 868 megahertz range. So we used a software-defined radio, a blade RF in this case. And our goals at this point were just to find out what is the exact frequency the system operates. Then what is the modulation scheme that the system uses to transfer the data? What is the channel coding? And after we have answered all these questions, hopefully decode RF frames. So if you have one of those systems, what can you do to find the frequency? It's actually pretty easy. So you can just use the GNU radio tool suite. We also did that. We performed a spectral analysis. So we tuned our software-defined radio to this 868 megahertz with enough bandwidth so that you can really see the signal and then you just do a waterfall plot. And what you will see there is if you press on the hand transmitter, you will see something like this. This is just a normal waterfall diagram. It shows the spectrum over time. And here we can see that there is a signal with a center frequency of 868.330 megahertz. So we have now already identified the frequency. That's good. But what we also see is on the left and on the right side, you can see those peaks. So when the signal is transmitted, it uses actually two frequencies and it switches between them. And this is a very strong indication that frequency shift keying is used. So the idea of that is that if you have a zero bit, you transmit a bit of a lower frequency. And if you have a one bit, you transmit a bit of a higher frequency. Pretty simple. So we already know that FSK modulation was used. Now the next step is we want to know the channel coding. So if we demodulate the signal and we have the data bits, the data bits are still in a channel coding scheme. And we need to find out which scheme is used. And so what we did is we had a look at the signal. And in the first step, it was necessary to get to the right symbol rate. And the typical signal starts with a synchronizing block. So this is just a very simple waveform with an alternating high and low signal all the time. And it allows the receiver to synchronize its symbol to the transmitter. And we did just the same. So it allowed us to synchronize on the signal. This is a picture where you can see that. So on the left side here, you can see the synchronization block. And after that, there's the data block. And once again, here we are in the time domain. And here you can also easily see that FSK modulation is used. So we have these long periods and we have signals with the short periods. So this is FSK modulation. And if you do a Google search for KnewRadio, FSK demodulation, there's a lot of examples of demodulating blocks. And so we had a look there how the typical demodulation scheme looks like. And then we added a few more blocks that are specific to our system and we tuned the blocks to our system. So after all, we wanted to analyze the B-secure system. So also the blocks have to be B-secure specific. Yeah, so we came up with this block. We already cut away this initial synchronization block so that we just end up with the demodulated data bits. And once we have those, we can hopefully analyze them and find out what the channel coding is. Yeah, we just did that. We analyzed the captured dump file. And interestingly, what we could find in there is there were always sequences of symbols, but it was always a zero followed by one, or a one followed by zero. And this indicates that Manchester coding is used. I have here a very simple picture from Wikipedia. So it actually takes two symbols to transmit one data bit. And if you have, for instance, first a symbol of one and then a symbol of zero, the data bit is one. And vice versa, if you first have a symbol of zero and then a symbol of one, the data bit is a zero. So pretty easy. And at that point, it allowed us already to try decoding the RF frames that are used in the system. So we wrote the Python script. We used the GNU radio framework once again. Our assumption was also that, typically at the end of an RF frame, there has to be some kind of checksum. After all, the receiver has to know whether the transmission was correct, so whether there were any errors or not. And it can determine that by computing a checksum and then comparing it to the checksum in the packet. Yeah, what we came up with can be seen in this table. So we noticed we had like nine different hand transmitters at the end. And we pressed the different hand transmitters and we just had a look how the RF frames look like. And so at this point, we could see that the frames always started with either an 0x70 or an 0x50. After that, there was the serial number. So it was a four byte value that was individual per hand transmitter and it didn't change at all per hand transmitter. After that, there was the encrypted data field. So we knew that the system uses AES encryption. And there was this very large blob that changed each time. So obviously, that has to be the encrypted data. And we also assumed, but really weren't sure at that point of time that the last byte is probably the checksum value. OK, now, so we have managed to decode the RF frame. We have a pretty good assumption of what the signal looks like. But still, our main question is, how does the system operate? How does the encryption scheme work? And so our next step was to hardware analysis. So we just opened up a transmitter. And here you can see this on a picture. So it's just, I think it's from one of those transmitter, very pretty small. And if you open that up, you have this PCB. You can find different chips on there. And you can also see that there are a lot of test pads. And in fact, the chip with the little sticker on it is a microcontroller. So in general, really, we had a look at the chips, at the chip markings. We could find out that there is a transmitter I see on the PCB, the SX-20 or 1230 radio chip. So there's a public data sheet for that. So we knew what kind of chip it is. However, more interestingly was the microcontroller. After all, the microcontroller contains the actual system implementation. So if we are able to analyze the firmware, we will also find out precisely how the system works and whether it contains security vulnerabilities. And in our case, we had a look at the microcontroller. And what we could see there is the microchip logo. So the logo of the manufacturer microchip. And so we assumed that it is probably a PIC microcontroller. But unfortunately, the model type of the chip, so the exact microcontroller type, was not written on the chip package. Instead, there was a very long manufacturer code. So you might notice that if you buy microcontrollers in large quantities, sometimes you get your own chip markings. And obviously, we had something like this. So we really didn't know what kind of microcontroller we have. We only knew that probably it is a PIC microcontroller. But what else did we know? We knew that the chip has 28 pins. We knew that the chip is in a QFN package. We also knew that the chip is probably older than three years since the system, the BCQ system, has been on the market for a very long time. And only recently microchip acquired at metal. So it could be possible that in the future, there might be at metal chips that now have a microchip logo on it on them. But in our case, this cannot be the case. And from the PCB, we knew that ground is on pins 5 and 16. And as you saw in the picture before, we saw all these test pins. And so we also assumed that the test points on the PCB probably also go to the programming pins of the microcontroller. So to identify the controller, the first thing we came up with is just doing a simple search at a component distributor. So we searched for the manufacturer microchip. We searched for chips with 28 pins and chips that are available in the QFN package. And the results were only four different models. So the PIC 16F, 18F, 24F, and 32F. And so at that point, from those four candidate series, we started to look into the data sheets. And as it turns out, the PIC 24 and PIC 32 is not only a pretty large microcontroller, but it would also need ground on pin 24. And this is something that was not on our PCB. So we assumed that the PIC microcontroller must in fact be either a PIC 16 or PIC 18F series. So what we did next is to identify the programming pins. So if you want to program a PIC microcontroller, you need the programming pins, not MCLR, PGD, PGC, and then a supply voltage, so VDD and ground. And both of the PIC 16F series and the PIC 18F series in this 28 pin package, they have the programming pins at the same location. So it's easy. And at that point, you can just connect the PIC 3 programmer to the device. So that's like a very low cost programming tool that everybody is using to program PIC microcontrollers. So this is the picture of the PCB. And now you can also see in red, marked in red, the test points on the PCB. And in the table on the right, we can see that in fact, the programming pins have been connected to those test pads. So we did a little breakout board to connect the PIC ID programmer. And we wanted to know what microcontroller we are dealing with. And the program tool reported to us that in fact, it is a PIC 18F 26K 20 microcontroller. OK, so much for that. But what it also told us that we already assumed it, that all the flash blocks are locked. So there are code protection bits. And we cannot just read the firmware. The firmware is locked down. It cannot be read out. What we also saw is that the e-prom at this point is not locked. So we could just dump the e-prom at this point. But unfortunately, it doesn't contain the firmware. Yeah, so we want to do a firmware analysis. Because in the firmware, there's the entire system implementation. And only by conducting a firmware analysis, we will know how the system operates and whether the system is secure. And the firmware is locked. The locking pits on the PIC microcontroller are typically implemented in a form of a security fuse. But yeah, since we were in a situation that we could not dump the firmware, the issue would be more or less that we cannot get the firmware out. And so we would have to go back to security by obscurity. We would have to trust the manufacturer that the system is really secure because we cannot dump the firmware. Yeah, so what we did is we have hardware security lab. So we have a lot of methods that we can apply to even conduct a security audit in this case. Our first question was, how is the security fuse logic implemented on the PIC 18F microcontroller? How does it look like? What are we up against? What do we need to get around to be able to extract the firmware? And our approach in this case was to do an IC decapsulation, so to open up the chip, and then do a rough microscopic analysis. So here are some pictures. It's a rather easy process. So you just desolder the chip. And then we follow a wet chemical decapsulation process. And in the last picture, you can see that the chip has been opened up. It would still be functional at that point, but we can visibly see the dyno. So in the next step, we used the chip, and we had a look at it in our microscope. And this is what we could see. This is a PIC 18F microcontroller. It has a very large flash area. It has an S-RAM. It has an E-PREM. And on the right side is the area where we suspect that the security fuses are. Big question. Why do we suspect that there are the security fuses? Yeah, on today's microcontrollers, it's often very easy to spot them because of those little metal shields. So in the old days, there was an attack where you could just reset the security fuses by using UV light. So you could erase the security fuses with UV light, and after that, you could just dump the chip. And as a countermeasure, manufacturers came up with those little shields. So now you can use those little shields to spot the potential areas of the security fuses. Okay, so we knew at this point what we are up against, what we need to do. And we were sitting in the lab and exploring different options that we could do. And yeah, so the first method that came to our mind is the chip is already... We could do an invasive FIP circuit edit. So we have a FIP already, and the approach would work in the following that we would have to identify the security fuse logic. So we already know where the security fuses are. We would have to look a bit deeper into that to find out how the logic works. And then we could bypass the security fuse by applying a FIP circuit edit. Okay, so that's a method. And the big question was, what would be the advantage of it and what would be the disadvantage? The advantage is, yeah, if you can do that, you have a high success rate. Disadvantages, we didn't do an analysis of the PIC 18F before. So we didn't have a recipe attend, and so it would have taken us a long time to figure out how the security fuse logic works. Yeah, so to give you an idea how that method would have worked, this is our FIP machine, and this is what you can do with it. So it's like a soldering iron for a chip. On this picture, you see an example of another chip where we did a FIP circuit edit. In general, the machine allows you to cut traces and also to deposit new traces. So in the case of the PIC 18F controller, we could have just cut the output rail of the security fuse and then connect it either to VDD or ground, and so we would have a fixed output and bypassed the fuse. Yeah, next option we explored. So we did a bit of more research, and there is the well-known bunny attack. So I told you before that now there is this countermeasure where the manufacturer puts those little metal shields in order to avoid UV light getting down to the fuse. And bunny Huang, he wanted to do this on a different type of PIC controller, and what he found out is that if you use the UV light at a very steep angle, it can actually go below the shield, bounce up again, bounce down again at the field and so on and so forth, and there will be enough UV light in order to erase the fuse. Okay, that's nice. So the advantage of that would be our chip is already open and it's rather easy to conduct so we could just ride. This advantage is that bunny did the attack on a different chip model. So we were at this point really not sure whether we had the same fuse type. So there's another fuse type, it's called anti-fuse, and instead of getting cleared by UV light, it's getting set by UV light. And what you also have to do is you have to cover the flash memory, for instance with a permanent marker or with a little electrical tape, otherwise you will also erase the flash memory. And so at that point we were a bit worried that we could damage the chip and it was still unclear to us whether the brooch worked. Next thing is also covered today in a few talks is voltage glitching. So we have a voltage glitch amplifier where we can conduct glitch attacks with very short pulses and high current. So we could try to glitch the chip in order to extract the firmware. Advantage would be it's easy to conduct. Disadvantages, we have really no idea if this approach works on the PIC ADNF and we would have to find the glitch parameters first. Yeah, so these are the methods so far that we explored and after doing more research, we also found the easy way. So the easy way that really everybody with the technical knowledge can conduct at home without all these fancy tools. So there is a really a trivial design issue in the PIC ADNF security fuse logic. And the design issue is that the PIC ADNF controller, it has five memory blocks and each of those memory blocks has a separate security bit. So a separate locking bit. And what you can do is you can erase a locking bit of one block, therefore you will also erase the content of the block, but the remaining blocks, the programming will stay intact. So you can just like upload a dump code to this block and then by using this dump code, the dump code will extract the remaining blocks that are still locked. And this has in fact even been presented at the CCC at the 27 C3 in 2010 already by Milo Schmeriak in his talk, Heart of Darkness, exploring the uncharted backwaters of heat eyeglass security. Yeah, so in order to do this, we implemented a very simple PIC firmware extraction tool. So it was just a little breadboard setup. We used an FTDI board. So one of those USB to serial converters and we wrote a bit of a software tools. It was just a small software script. So our setup then allowed us to directly talk with the PIC microcontroller programming pins. So this is what it looks like on this PIC ADNF when you start out. You have five memory blocks. So the first block is the boot block. After that, you have the first code block. It's a bit smaller because of the size of the boot block. And after that, you have the additional code blocks. And all of them are locked right now. And so what you do is you remove the lock bit. For instance, in this case here of the book block and therefore you also erase the boot block. As I mentioned, the other blocks remain intact. Then we create a little dump code. We program it to the boot block. And once the chip is powered on, our dump block will execute and it will just happily dump the remaining four code blocks. And after that, we will have a partial dump of the microcontroller even so it is locked. However, the only thing we don't have is the boot block because we overwrote it and the content obviously is irrevocably lost. Okay, so what do we do at that point? How do we even get that? Yeah, it's easy. Just take another PIC microcontroller with the same programming. So start out again, repeat the process. So this is what we did. But this time, of course, we have to erase another code block. You use the dump code again. And now the dump code can be used to also dump the boot block. However, keep in mind that the execution starts at the boot block. So we don't know exactly where, at what point in our block there is the destination for a jump instruction. So we don't know exactly where execution jumps into our block. And so what you can do there is you just use a knob slide, like from buffer overflows, they are very well known there. And at the end of the knob slide, you have your dump code. So that's the only difference. And after that, you have two partial dumps of the PICs. You combine those dumps, then you have the full firmware dump. And then you can refresh those two PIC microcontrollers again, and they will have the original programming. So at this point, we had extracted the firmware and we could start doing a firmware analysis. So for this, we used the well-known Ida Pro tool. It supports the PIC architecture. And yeah, and this way we analyzed the firmware to find out how the system operates. So the firmware analysis provided us with a very deep implementation insight. So we could confirm how the checksum is computed and that in fact the last byte is a checksum. We knew how the RF protocol works and we could also obtain how the encryption methodology in the system works. So to give you an idea, this is the result of our analysis. This is the cryptographic scheme and key generation that's used in the Hermann BCQ system. So on the left, you start out with the serial number. The serial number is individual per hand transmitter. And at the heart of the encryption algorithm, you have AES128 algorithm. And around that, there's a bit of magic happening which we believe is a countermeasure, a whitening approach against side channel attacks. And on the left, you have a random seed and the entire block just generates a new random seed. However, on the right, there is a static value that is shared among all the hand transmitters. The random seed is used as a key and it outputs the long-term communication key. And subsequently, this key is always used to encrypt and decrypt wireless frames. So if we combine that with what we discovered by doing the RF signal analysis, is, yeah, this is what we receive. And we know the serial number. The serial number is transmitted in the clear, so we have the input to this scheme, the serial number input. Next thing is, we also know the static value. Static value is contained in the firmware and it is shared among all the hand transmitters. What we also know is, of course, how the encryption with the AES algorithm edits how it works, because it's implemented in the firmware. And what we found out is, yeah, we have the initial random seed. And of course, the initial random seed has to be in a hand transmitter. Unfortunately, what we found out is that the very same initial random seed is used on all the hand transmitters that we analyzed. So in other words, we had all necessary data to compute a communication key from a serial number. Now, how can we attack this vulnerability? Yeah, to do an attack, you can, for instance, use low-cost software-defined radio, such as the CCC radio. We will demo that in a few minutes. Or the HEC-RF, and in our case, yeah, like I mentioned, we used the CCC radio. We were visiting the CCC camp 2015 and it was available for free there as a conference batch. So what you do to perform the attack is you record the RF transmission from a B-secure hand transmitter one time. You only need to do it one time. And so you receive a wireless frame. So by now, you should know how the frame looks like. And in the next step, you use the information that you have obtained from the firmware analysis and from the RF frame. It looks like this. So we really know everything that we need to compute the communication key. This is what we do in the next step. We compute the communication key candidate. The candidate is correct if we decrypt the encrypted packet and it has the known plaintext structure. Otherwise, we repeat that process. Why do we have to repeat the process at all? Yeah, repeating the process is necessary if the user has manually generated a new key. So the system offers this functionality and if a user has done that, maybe we have to repeat the process for one or two types. And after that, we know the long-term communication key. We can decrypt the encrypted message from the wireless frame. We can increase the contained count up to just by one and then encrypt the message again with the long-term communication key. And in the last step, we use the CCC radio, for instance, to transmit the frame. Yeah, and for that, we have prepared a live demo. It will hopefully work. And I would ask the video guys to switch over to Markus. So, thank you. For today's demonstration, we built a little setup. This is actually the rail of a garage door opener. So this would be mounted on the ceiling of your garage and it moves up and down the flag over there. Down here is the operator, which has the built-in receiver for the radio. And we can actually operate it with a remote. So to, if you like. Okay, to start with the attack, we have a sniffer, which listens for any radio packets in the air. So I have a remote that's not synced to the door, so it won't open, but we can see packets coming in. So if any one of you has a receiver, he could press it now and we would see the packets. Yeah, there are some. So thanks for sharing your keys. Very nice. So the sniffer is configurated for today to stop when we get the signal from the hand transmitter with the correct serial number. So if Markus presses the button again, the door will open and we get the packet we need for our calculations. So this would be the packet. And now we have a script that calculates everything we need. So up here is the packet. We get that as input for our script. It shows us the serial number and it calculates the communication key. It decrypts the package, which we do not show because we agreed to not disclose the structure of a clear text packet. So we just show the counter value, the current counter value. We increase it by one. Then we can encrypt the packet again with the key and we put it into a frame so it's ready to be transmitted. So with another script, we can transmit the packet with our radio. So if I press the button, the door should open without Markus doing anything. So let's see if that works. And now we can again start up the sniffer and see what happens if Markus presses the button off his remote again. So we actually get the packet and it's exactly the same as we calculated. And in addition to that, the door didn't move because it just got the packet and it doesn't work to replay the attack. So the counter has to be counted up one more time. So if he presses the button again, the door will move again. Yeah, it works again. Okay, that's for our live demo and Markus will continue with our impact assessment. Thanks. Can you switch over once again? Yeah, thank you. Okay, so after we found out the vulnerability, we wanted to do an impact assessment as well. So what we did is we did an observation and we saw that the serial numbers of the same model hand transmitters that were bought at the same time were close to each other. So we made the assumption that there are sequential serial numbers. And by having a look at those serial numbers, our assumption is that there are probably millions of devices in the fields. But of course, this is only our assumption, how this serial number scheme works and we are really not sure if our guess is correct. Next big question is, how can we fix the vulnerability? Yeah, it's actually rather easy. As I mentioned right now, all the hand transmitters that share the very same initial random seed. And the solution, the security fix, is just that each hand transmitter would need to have its own individual random seed value. And since this random seed value is in this case no longer than shared between all hand transmitters an attacker would also no longer know the initial random seed and he would need to start like something like a brute force attack on this random seed. Yeah, what did we do when we found out the vulnerability? As it says here, in case of vulnerability, disclose responsibly. So we did this. We followed a responsible disclosure process. At the beginning of October, we involved the Austrian national search team as a coordinator and we reported the security vulnerability to them, including our security advisory and including the suggested security fix so that the manufacturer can fix the issue. And at the end of October, we actually received the confirmation from the national search team that the manufacturer has received the information and in fact he has also understood the security problem. Yeah, after that we had various email and phone call exchanges with the manufacturer. And at the end of the November, they also visited us in our lab and we presented the vulnerability once again and also the suggested security fix. And in December, we also received information from them that they have now implemented a security fix and they are currently in the testing phase. Yeah, to conclude the talk, we presented the viable methodology that can be used if you want to analyze a wireless RF system, something like similar to this one that for instance also uses microcontrollers. Of course, we believe that if you are a manufacturer and you create something like this, so you really want to have a secure system, we believe that it's important to do independent security audits. So it can be really an essential tool to achieve a high level security because then you have this external viewpoint and if vulnerabilities can be found, you can then fix them at an early point. Yeah, besides if it comes to hardware and hardware security, it's also pretty good if you have a hardware security lab at hand. So as you saw, you have a lot of methods that can be used. So it's not that you have a system in front of you and you want to do a security audit and then you say, okay, now I'm stuck, I cannot read the firmware, I cannot do a firmware security audit. And so if you have more options, it's just easier. Yeah. Yeah, you also saw that we followed a responsible disclosure process. So in addition to following the process, we also tried to support the manufacturer in understanding and also in fixing the vulnerability. Yeah, and last but not least, we will also publish the security advisory today after this talk. We already have a CVE ID and the CVSS score. And in this case, the CVSS score is pretty high and we believe it is also a significant vulnerability. Okay, so that was it for our talk. I hope you enjoyed it. And if you have any questions. Yeah, so if you have any questions, we have four microphones as one, two, three and four, line up behind those questions just to define what a question actually is. It is like one or two sentences that actually end with a question mark. It is not your life story. And with that, I'm gonna go to microphone one, please. Yeah, thanks for sharing this insight. You said that the manufacturer has announced a fix for that. Does that mean customers are supposed to buy new devices or will they be able to update them or have them exchanged? We really don't know what they have planned, but we just received the feedback that there is a security fix now. So I think it will be really up to the manufacturer how he will interact with the customers. So the internet has a question for us? Yes, the first question is one that occurred pretty early during your talk regarding your reverse engineering work because CBM user noted that it looked pretty expensive from a monetary and timely point of view and he wants to know who paid for it. Yeah, this work was actually done as a fund project. So most of the work that we do is paid work and typically it's under non-disclosure agreements. So in this case, I couldn't stand here and do a talk on that. So this was just a fun work and it was not paid for. So microphone one. Great talk. How many of these garage door openers actually use some form of encryption? Is this something exceptional or is this a standard? I think it is that the Herman system, since it uses AES, it's really an exception. So the typical systems that we saw, so a few other guys, I know they also have garage doors at home and of course we looked at them with a soft to defined radio and yeah, really, typically you can find like static messages there. There's a static code. You just do a replay attack and then it's nothing, the door goes up and so this is something that we really don't have here. So I would really say that in general, the majority of the systems is probably rather weak. Thanks. Microphone two. So my question is after you broke into the systems, maybe you play out with the counter so that you can lock the door forever maybe or is it the counter to the lower value or much higher? Yeah, yeah, in fact, you can do that. So there's this accepted counter value and of course the receiver in order to avoid replay attacks, it has to move this counter window forwards and if you do that by performing an attack, you can move it forward way too much and then you can press for like hundreds of times on the hand transmitter, nothing will happen. We had that right before when we did the stage demo, I pressed the hand transmitter and since the frame had been used already and the counter value had been used already, it didn't work. So microphone one. Thank you for your work. Sorry if I misunderstand, but so the fix principally is to change the globally static initialization vector or random seed, the first one, from a static value to a per device and thus the kind of per purchasing affair. How does that stop a targeted attack where the attacker just listens for a specific individual and just waits for that particular initialization vector? Yeah, the attacker wouldn't know this initialization vector. Where would he get the initial random seed? So, I mean, if the manufacturer would know the initial random seed, in case the seed would be stored there, then yeah, maybe you can get the seed there, but if the seed is stored only in the hand transmitter, then nobody would know the initial random seed. So you would have to do a firmware extraction on it and then you need it, but since you then would have physical access, yeah. So if I was to purchase the product and maybe it had a backup key, so two transmitters and one of them went missing, that sort of thing. No, they would have individual random seed and not the same one. Okay, thank you. The internet had a question? Yes, TNT wants to know that if the seed is random, does that mean that you can't register new key fobs into an existing systems since the receiver would know the random seed? No, you could register them, that would work just fine. We didn't have a look at how the actual pairing process works because it is only done one time, but yeah, in general, regardless of the seed in there, there has to be some kind of exchange where the key is paired to the receiver. So that wouldn't be a problem. Microphone one. The problem was the not random seed. If you get random seeds, you pointed out the only thing that would be left to crack the system was to brute force this 80-bit key. Can you give us a hint how much time it would take to do so? Yeah, 80-bit is pretty long. So even, for instance, we have an FPGA cluster to explore some of these questions and we did some similar algorithms on it. And yeah, so 80-bits would still take at least a few months or so. So yeah, at least. Microphone one again. Hi, thank you for your work, actually. The thing is, when you jam the garage door with an SDR transmitter and just record the code, the FSK code from the transmitter, from the hand transmitter, and you just do replay attack. Will it work or just in the form of the rolling code, it doesn't work? If you would press the button, you send out a valid frame. And if this frame never reaches the receiver, you could use this frame at a later point of time and open up the door. Yeah. Okay, thanks. But the thing is, when the frame isn't used, but a new frame was sent, will the old frame still be active? No, in this case, the frame would become invalid because you have a newer counter value then and all counter values before that are invalid. Okay, thanks. So the internet? Yes, a rather popular question. You noted that there will be fixes and that the devices will be updated and do the other devices update it automatically or does the company have to go to the garage doors and if they're updated automatically, are the garage doors connected to the internet? No, so neither the doors nor the transmitters are connected to the internet. So we really don't know what the manufacturer has in mind here, but they cannot be updated automatically online. Microphone one. Are there any other findings in the code that you have dumped? For example, synchronization code or something like that, updating firmware or something like that? No, we just had a look at the scheme that is used and since we already found this vulnerability in the scheme, how it is found on the systems in the field, we stopped at this point. Okay, thank you. And I think we don't have any more questions unless somebody's really, really quick. So I'm really glad that my garage does not have an automated system and but with that I would like you to help me in thanking Marcus and Marcus for this fantastic talk and make this really count. Thank you.