 I'm very happy to be allowed to announce the following talk, Hunting the Sick Fox, wireless IoT network security by Florian. Some of you have might heard of the work of Florian already because some time ago there was an article on a popular German website called Furby from Hell and somebody hacked the Furby and there was also a video where you could see the debug output on the displace which are the eyes of the Furby. It was a really disturbing video and the guy who did this is exactly Florian. Today he's gonna talk about Sick Fox which is not another toy but a network technology for IoT devices and like it's always with the IoT world, there's security issues. So let's hear a talk about the Internet of Shit by Florian and welcome him with a big round of applause. Thank you for the introduction. So this talk will be targeted at a technical audience which is the case here but you don't have to be RF experts in order to understand this. So I will start by covering some basics of RF technology and some basics about Sick Fox and just after that I'll start talking about analysis of the Sick Fox protocol and its security. I'll mention the most important thing first which is that I didn't find any serious vulnerabilities in the Sick Fox protocol but there are substantial weak spots and you should be aware of these if you want to use Sick Fox in your own application. But let me introduce myself first. I don't think there's a lot of information you need to know about me so I figured I just show you this picture here of me instead. I'm not showing you this picture because I think I look so fabulous but because I think that this cow here in the background is amazing and this is not just any cow this is Alice, Alice the cow and as you can see she has a great life so she lives somewhere in the mountains and there's just one problem with her. She likes to break out of her coral. Now her farmer which is called Bob doesn't like this very much but he recently heard about something called the IOT and he thinks that the IOT is going to solve all of his problems so he purchased this color here for Alice. So this color does a couple of things. First of all it determines Alice's position based on GPS satellites. It also measures her body temperature and then it transmits all of this information to Bob. So that's what we want to do. There's just one obvious problem. How do we even get this data from Alice to Bob? Well traditionally in the IOT there have been two solutions that have often been employed. One of them is Wi-Fi and the other one is mobile networks. Now Wi-Fi is not going to work in this application here. We cannot cover the whole countryside with Wi-Fi. It's just not enough for us to cover the whole country. So we have to change the battery relatively often. Luckily these days there's a third option and it's called the LPVAN and this is short for low power white area network. And the LPVAN is great because it solves all of these problems. Now how is this possible? Why do we just have to just discover the LPVAN so recently? Why hasn't this been done before? What kind of compromises do they make? And to understand the compromises that LPVAN networks make we have to look at the electromagnetic spectrum. So that's what the electromagnetic spectrum of a Wi-Fi signal looks like. You can see that Wi-Fi is fairly white band and you have these tiny ripples on top of the signal. That is noise and we don't like this noise. In order to find the power that's contained in one of these Wi-Fi transmissions, we have to look at the area underneath a curve. So that's the power of the Wi-Fi signal. It's typically 20 megahertz at the bandwidth of Wi-Fi. And this red rectangle on top of the signal, this is the noise. And we don't want this. Now what determines the range is not the absolute value of the noise but the relative value of the noise compared to the signal power. And this ratio is called the signal-to-noise ratio or SNR for short. Now if you look at the blue and the red square, you can see that the red square is very big compared to the blue square, which means that our signal-to-noise ratio is really bad. Now the solution to this is kind of obvious once you know it. You just concentrate this whole spectrum power in a very narrow frequency range. Now this way, you just have this tiny little ripple on top of the signal and that's all your noise. So now your signal-to-noise ratio is a lot better. And this focusing of the complete signal power in a very near frequency range, that's called ultra-narrow band technology. And SIGFOX is one of these ultra-narrow band technologies. Now you might wonder why don't we do this with Wi-Fi as well if the solution is so simple, why don't we always concentrate the complete signal power in a very near frequency range. And the answer is kind of obvious, you can see it already, it's that bandwidth is proportional to data rate. When I'm saying that it's obvious, that's because it's sort of ingrained in our language. So when I tell you that I have drawband internet, you think that my internet is fast. You don't think that my internet uses a lot of frequency real estate. On the other hand, if I tell you that SIGFOX is an ultra-narrow band technology, you have to think SIGFOX is slow. And when I'm saying slow here, it's not just a bit slow, but extremely slow. So here on the right you can see a comparison between SIGFOX in its very fastest configuration and a 56K dial-up modem. Now this means that we can only transmit 140 uplinks per day. And an uplink can contain up to 12 bytes, so uplink would be from Alice's collar to the SIGFOX base station to Bob. And we can only receive four downlinks per day, and they are not big either, it's just eight bytes. So what I'm saying here is that you can forget everything you happen to know about internet protocols. So there's no IP, there's no DNS, there's no HDTV or anything like that. SIGFOX is a completely separate protocol. Now, even more than that, there's not even any signaling or connection establishment. So when a SIGFOX device wants to transmit something, it just broadcasts it. So SIGFOX device just sleeps all day long until some interrupt occurs, like some timer overflows or some button is pressed, and then it broadcasts the information it has gathered. SIGFOX base stations may pick it up or not, and if they do, they just forward this information to the SIGFOX cloud. So we just have to look at one uplink transmission and there's no long protocol on top of that. Now, that's cool, and this only works if there's one device you may think. So how is this possible if we don't just have one device but like 10 devices or hundreds or thousands of devices? How can we make sure that these uplink transmissions don't collide? And the reality is that these uplink transmissions may actually collide. Again, we have to look at the radio spectrum to understand this. We sort of frequency multiplex our uplink. So this is frequency and time division multiple axis. So you have SIGFOX uplink at different frequencies at the same time, and whenever a SIGFOX device wants to transmit an uplink, it first chooses a frequency to transmit at randomly. And the likelihood of two of these very narrow bands signals colliding is just extremely slim. Now, all of these peaks you can see in this diagram are not all cows, they're also a bunch of other SIGFOX devices. And for instance, SIGFOX is also used in areas like smart homes, smart metering, smart city, e-agriculture, industry 4.0. So essentially we have the full range of buzzwords. And this probably helped SIGFOX raise 250 million euros during the last couple of years. With all of that money, they already got pretty decent coverage, as you can see in the coverage map on the left. Now, one thing that's cool about SIGFOX is that they use an unlicensed spectrum in Europe that's at 860 megahertz. This is cool because it's free to use. So SIGFOX is extremely cheap. Now, just the downside of SIGFOX is that SIGFOX is completely proprietary. So we cannot verify whether it's secure or not. And this is the part I'm trying to change with this presentation here and look at a security of the SIGFOX protocol and see if it's any good. Now, SIGFOX is not the only LP van technology. There are a bunch of others. So here are a couple of names. But to be honest, I'd say that these three here are the ones you should remember. So that's all I have to say about the SIGFOX technology and SIGFOX basics. Let's just do a quick refresher of RF basics first. So this is going to be extremely short and many of you are going to know this already. So the basic idea is that I want to transmit some information wirelessly. And to do this, I have to emit an electromagnetic wave. So this is what an EM wave looks like. Now, as you can see, there's no information on there. We have to put some information on there somehow. And this process is called modulation. There are different ways to modulate a radio wave. And one of them is phase modulation. This means that in this case here, whenever the phase changes by 180 degrees, that's the one. When the phase stays the same, that's zero. So this is a special kind of phase modulation that SIGFOX uses. So you can see these mes in the sine wave. Now, this is not the only modulation technique. There's also frequency modulation. You probably know this from your car radio, for instance. So this is frequency modulation. Frequency modulation just means that whenever the frequency is a bit higher than that's one, and when the frequency is a bit lower, that's zero. Your car radio uses the analog version of this, but this is just frequency shift key, which is a very similar technique. Let's actually get started with the SIGFOX uplink. At this point, I want to thank Paul Pinot. He did some really amazing reverse engineering work, some basic reverse engineering work of the SIGFOX protocol and published it on his blog. And this really helped me get started with my own analysis. So to analyze the SIGFOX protocol myself, I first wanted to record one of these uplink frames. So I got two SIGFOX devices. One of them is the PICOM side pi, and the other one is a development kit by ST micro electronics. And I also had a software defined radio. So for those of you who don't know, a software defined radio or SDR for short is just a device that's pretty much a microphone, but not for sound, for sound waves, but for electromagnetic waves. So we can use this to record electromagnetic waves into something that's very similar to a sound file. I just want you to listen to one of these sound files first, and I want you to know that this is going to be in real time, and it's also just one piece of information that I'm transmitting. So this is not a couple of transmissions, but just one transmission. The interesting part here is that even though I was just transmitting one piece of information, we have three uplinks at different frequencies, apparently. Now, I wanted to find out what's the relationship between these different SIGFOX uplinks. And to find this out, I had to demodulate it. So demodulation means that I know that SIGFOX uplink uses dbpsk, that's differential binary phase shift key, which is a special kind of the phase modulation I've been talking about. And using this information, I can write a demodulator software. This outputs a hexadecimal representation of the SIGFOX uplink, so just binary representation, and that's what it looks like. So I've colored these three uplink frames in different colors so that you can distinguish them. Now, let's have a closer look at these and see what they have in common. So the one thing they have in common is this preamble here, but everything else appears to be completely uncorrelated. That's what I thought at first, but eventually it turned out that this is convolutional coding. I guess if you're a coding person, it's enough for me to tell you that this is a 5.7 convolutional code. If not, you probably don't know what these words even mean, so this is a convolutional code. It just means that I take this unencoded input, which is the red frame, and feed it into these schematic diagrams here, which are made up of shift registers and XOR operations and outcomes that are encoded. That's all there is to 5.7 convolutional code. Now, this means that the first, second, and third transmission all contain the exact same information. So why am I transmitting this information three times? The technical term for this is coding gain. So coding gain just means it's just a fancy way of saying that this helps us correct bit errors or transmission errors if they happen to occur in the uplink transmission. But to continue, I just have to focus on this initial transmission here, which is the one that's unencoded and I can just ignore the other ones because they are just the same information anyway just encoded differently. So, of course, I captured a couple of these first transmissions, just ignored the rest, and they are all with the same payload so that I can find some similarities. Now, let's look at a bunch of these. So the whole trick to analyzing these wireless protocols is just to keep staring at these hex stems for a very long time until you see some patterns. And I think you can already spot some of them. So that's the preamble. We already talked about that. Then here we have some header. Then this is a sequence number. This is especially easy to spot because the number is incremented after every transmission. Then here, that's the device ID. So this is a big identifier for every SIGFOX device, which tells us that this uplink transmission was from Alice and not from some other cow or some other device. And that is the payload. And as you can see, it's completely unencoded and unencrypted. Now, this may seem bad, but it's not really a problem in terms of security issues because this is document behavior. So when you look at SIGFOX security white paper, they say that data is conveyed over the air without any encryption. So that's strange, but it's not really a problem as long as it's documented. But eventually, after staring at these frames for some more time, I figured out this frame structure here. So you don't have to remember all of this. I'm going to publish an 80-page document that contains all of the boring protocol details. And you can read up what every flag bit means later on. But for now, I just want to focus on a couple of things. I first want to wrap this up a bit. So whenever we receive an uplink frame from Alice the cow, this is essentially what she's telling us. So most importantly, that's the payload, what she's doing right now, for instance. And then there's also the device ID, which tells us that this is Alice. And there's also a bunch more information in there. Now, again, I want to focus on two fields here that are a bit more interesting. One of them is the CRC and the other one is the Mac. Now, CRC, if you're a coding person again, you probably know what to do with this information here. For everyone else, you might know this already, but this is just to check some. So this helps us detect bit errors in the uplink frame and correct, not correct them, but to discard the uplink frame in case these bit errors occur. Now, the CRC at the Mac is a bit more interesting. So in this case, Mac does not stand for an Apple computer. It also doesn't stand for a Mac address, so it has nothing to do with medium access control or either that or anything. It stands for message authentication code. Now, as the name says, a message authentication code is for authenticity protection. So this is something that's very similar to digital signatures. So you might know digital signatures just from PGP emails and so on. But it doesn't use something like RSA, so they have an asymmetric scheme, whereas digital signatures, whereas message authentication codes, they use a symmetric encryption scheme, like for instance, AES. Now, this slide is not that important. The only important part is that I wanted this algorithm here. So I wanted the algorithm that I can use to generate one of these Macs. And I already had the payload and all of the message I'm transmitting. I didn't have the key yet, so I wanted the key. Now, at first, I thought it was impossible to get the key from a SIGFOX device, because if you watch SIGFOX's YouTube video on security, they say that the secret key is stored in non-accessible memory. So this sounds secure, right? Well, it turns out that when I first got the PyCom SciPy, this development kit here, it wanted to update the firmware. And it didn't just update the firmware, but this is a section of the SciPy flash memory before the so-called firmware update. And this is the same section after the firmware update. And it totally provisioned the device ID, some other code, and that's the secret key. So the secret key is in plain text and flash memory. Now, you might say that's not really a problem, because you need physical access to this device in order to get the secret key. But still, I confronted SIGFOX about this issue, and their response was that yeah, they do offer solutions where the secret key is not stored in plain text, but it costs some money, and many manufacturers don't choose to use it. So PyCom, for instance, didn't have the secure element shift. But at this point, I had the key, so just based on some educated guessing, I was able to find the algorithm that's used for calculating the MAC. And many of you probably know this already, so this is CBCMAC, which is just AES in Cypher block chaining mode, and we can use the structure to generate a MAC. The input to this algorithm is not just the payload, but also some other information, like the flag bits, the sequence number, the device ID, and the payload, of course. So yeah, that's how it should be. So let's look at the security of the uplink. It looks pretty good at its first glance, so they use well-established algorithms, like CBCMAC. So CBCMAC is also used in Wi-Fi, so it's trying through. I didn't find any obvious implementation flaws in the uplink, so I tried to fust the uplink, but it didn't get accepted. Now, one problem is that we don't have any payload confidentiality. So this is documented, but still I wondered why would you design a protocol in 2018 or a couple of years ago without any encryption? And the response was that it's not a real problem, but they do offer an encrypted solution, but of course it takes some energy to calculate an encryption, and it really matters if you're talking about devices with tens of years of battery life, than just performing this one encryption can make a difference. Now, this is not a real problem, in my opinion. I think the real problem with the CBCMAC uplink are these two here. I think the MAC is just way too short, and the sequence number is extremely short. This makes brute force and replay attacks possible. So let's look at the brute force attack first, and let's just look at the ideal scenario. So this is an ideal world, just Alice transmitting her uplink frame to the Sigfox cloud. That's what we want, no attacker here. Now, when she's transmitting this uplink frame, she's also transmitting a MAC, and in a worst case scenario, this MAC is just 16 bits long. So if you do the math, the number of possible values for the MAC is very limited. So the idea would be to just try one MAC after the other. That's brute forcing, right? Now, with most protocols, this is not very practical because this takes a lot of time. Again, looking at the worst case scenario, if we do the math, it's possible in just less than 4 hours. So that's not great. And remember, in the beginning I told you something about frequency multiplexing and these multiple uplinks that can coexist at the same time. We can even do this for the attack. We can just frequency multiplex our attack. And we can do this at not just 4 frequencies, like it's shown here, but at 300 frequencies. And then we are not talking about a couple of hours to try all possible MACs, but it's a matter of minutes. So that sounds bad. So I confronted some folks about this. And the response was that, yes, they are aware of this issue, but they have implemented some kind of blacklist. Now, I wasn't able to confirm this information because I only had development kits, and they say that development kits are exempt from this regulation. Now, this is great if they have implemented this blacklist, but on the other hand, this also means that now we have a conflict between two security goals. One of them is authenticity protection, and the other one is availability. So you're not going to have perfect availability if you're using SIFOX. But on the other hand, maybe if you want perfect availability, maybe you just shouldn't use a wireless system in the first place. Now, the other attack is the replay attack. It just means that I capture an uplink frame from Alice, and at some later point in time, I just replay it to the SIFOX base station, and hope it gets accepted. Well, usually it doesn't get accepted because the sequence number is a replay protection. But again, in the case of SIFOX, the sequence number is very short, just 12 bits long, so it's going to overflow eventually. Again, looking at the worst-case scenario, this is after less than 30 days. I had to ask SIFOX about this as well, and their response was that if you choose their so-called encrypted solution, so that was the one that also does the payload encryption, then you're going to have a 20-bit sequence number. So you should probably use that if you don't want to have replay attacks. So in summary, if all you want to do is create a device that tracks cows, you're probably going to be fine with just normal SIFOX without the encrypted solution, and you don't need perfect authenticity and no perfect confidentiality protection. But on the other hand, if you have a managed transporter or a security system where you need confidentiality or authenticity, then you should probably think about using SIFOX or implement your own checks or use SIFOX's encrypted solution. So that's all for the uplink. I'm just going to quickly talk about the downlink. This is going to be extremely short because the downlink protocol is so much simpler. So I told you that a SIFOX device just leaps all day. This means that the SIFOX base station cannot just transmit a downlink, but the SIFOX device has to request it first. So it sends an uplink that contains a downlink request, and the SIFOX base station decides which base station is going to answer with a downlink. Now, of course, I wanted to record one of these downlink transmissions, so I had to find a base station. At some point, a friend of mine hinted me that there was this omnidirectional antenna here on a cell tower in Kaffenberg, and it turned out that this antenna was actually a SIFOX base station. Now, if you want to find your own SIFOX base station, you don't have to go around hunting for omnidirectional antennas on cell towers. You can just go to the website of the Bundesnetz-agentur, and I figured out that whenever there is something called a sonstige Funkanlage, and it has these specific security clearances, then that's SIFOX. So here's another one. So let's just listen to one of these downlinks. Again, that was in real time, and it was really short, and it sounded differently. This is because this is not phase modulation, but frequency modulation, or in this particular case, GFSK, that's Gaussian Frequency Shift King. Again, I demodulated this uplink, add this downlink frame. That's what it looks like. I captured a couple of these. I looked at them. That's the preamble. That's a garbled mess. So what could that be? I thought that maybe suddenly they're using encryption, or maybe it's a very smart error correction code scheme, but it turns out that it's something much simpler called scrambling. So unfortunately, I'm not going to tell you the algorithm that's used for scrambling here, but I can tell you that the inputs to the scrambling algorithm is just the sequence number and the device ID of the corresponding uplink. So you can totally reverse the scrambling, or you can even brute force it, because these two numbers are very finite. So scrambling does not provide any confidentiality. I can tell you what I figured out in the end. So this is the complete frame structure of the downlink. It's static, so very simple. I think that two fields here are particularly interesting. One of them is this one here. So if you're a coding person, this is a BCH15111 code, and this is cool because this can correct up to 8-bit errors in the downlink frame. And the other interesting thing, of course, is this message authentication code. So we also have authenticity protection for the downlink. So in summary, for the SIGFOX downlink, it looks pretty secure. Again, the only real problem I found is that there's scrambling, but this scrambling doesn't provide any confidentiality. But last week I figured out that if you use, or Paul Pinot, he hinted me that if you use SIGFOX's encrypted solution, he figured this out, then you're also going to have an encrypted downlink. So you should probably use that. And this is also pretty much my summary for you. If you are a device maker and you want to build a SIGFOX device and add SIGFOX connectivity to your device, it's fine to use SIGFOX, but you should be aware of the level of security it provides. And most importantly, this means that if you need confidentiality and if you need good authenticity protection, you should probably use SIGFOX's encrypted solution. This means that you have to buy one of the very few modems still that support this encryption. This also kind of puts some pressure on the manufacturers to just start providing these modems and not the old ones. Now if you don't buy a modem with the encrypted solution, these are your options. So you have to implement encryption yourself if you need it. There are some things you can do to improve the authenticity protection that the SIGFOX uplink and downlink already provide. And if you don't do that, you're just going to have to implement your own authenticity checks. Now I want to thank a couple of people. Most importantly, that is Felix and Mark. They didn't just help me with the whole technical aspect of this presentation here, but they also helped me proofread the documentation I'm going to publish soon and this presentation here. I also want to thank Paul Pinot for providing quite a lot of information and you will see a link to his blog on the website I'm going to show you in a second. I also want to thank Mr. Lehmann from SIGFOX Germany. Even though there were some screw ups in the communication with SIGFOX on our site, so none of that was SIGFOX's fault, he did it really nicely and handled it very nicely and responded to all of our questions. And I also want to thank Linus Neumann for organizing that communication with SIGFOX. Now when I talked to Mr. Lehmann from SIGFOX Germany, essentially I told him that there were these weak spots, the substantial weak spots, but we didn't find any major issues and what he said then was that SIGFOX is planning to open source a device at Library and I really hope that they carry through with this because if they do that, that to me would signal that SIGFOX is a company that really cares about security. Now if you want to find out more about SIGFOX and you don't want to wait for SIGFOX to release their device at Library, you can just go to this website here and download my open source library instead. I'm also going to publish these protocol specifications. The reference implementation is for software defined radio. If you have any questions, you can contact me via email. You can also call me on my deck phone to your conference. And of course here's my SIGFOX device ID and my SIGFOX secret key so just send me a SIGFOX uplink. Thank you. Thank you. I think a lot of microphones all around. So please line up on the microphones if you want to ask a question and especially two tips for that. First, a question is in general just one sentence long. Second, if you want us to hear you, you have to speak into the mic so get close to the mic. It doesn't bite back. So I think you have somebody on the mic there in the back. Yes, that's mic number. I can't read that from here. I'm told for that shit. Eight. Okay, thanks. Number eight. You start. So, hi. Yeah. So you said scrambling didn't provide any confidentiality. So what is it for? It might be for just for receiving synchronization because it facilitates receiver synchronization. I'm not sure what it's for. Now, the scrambling algorithm, it's not a very standard algorithm so this is why I'm not really sure what it's good for. If it was a very standard algorithm I would think that it's just for receiver synchronization but that's not the case. So maybe it's some kind of security by obscurity but I'm not sure. I can't tell you. Okay, now we shift over there to the mic. Yes, exactly, in the right shirt. This was the mic. This was the mic. Okay, then I want to go to seven. Sorry, the numbers are too far away. It's just such a big room. Number seven, please. Hi. Thanks for the talk. My question is what is the reason you cannot disclose the scrambling algorithm? I could disclose the scrambling algorithm but I have decided not to so there's no one forcing me to do this. It's just based on the legal advice that I have received but I am going to publish scrambled and unscrambled versions of Sigfox downlinks so I cannot stop you from reverse engineering this algorithm yourself. Thank you. Okay, now we take a question from the Internet. Yes, so one of the users asks, do you think it is possible to run your own base stations in the future or will they always be run by Sigfox? Absolutely. It's just a matter of intellectual property and whether that's legal or not. I think they do have some patterns on their technology but there's nothing stopping you from running your own base station. So you will have to have a separate network from Sigfox with their own secret keys. You cannot get the secret but you could track them from devices but you cannot get the secret keys of all devices from Sigfox but of course you could run your own parallel Sigfox network. Okay, mic number eight again. Thanks for the talk. I have a student who wants to fuzz Laura one. You mentioned a few times you fuzz the uplink. Did you use the SER implementation for sending as well or did you figure out how to manipulate one of the existing radio transceivers? I did manipulate the pycom sci-pi but I didn't use that to fuzz the uplink so I used the SER implementation to fuzz the uplink. Thanks. Okay, I think on number seven there's another question. Hi, can you tell us what the latency is like on these networks? Didn't get that, sorry. Can you tell us what the latency is like on those networks? The latency on these networks? Yes. Well, it's like you have to go to a website to retrieve all of the information that the Sigfox base station has received and I didn't really test this because theoretically you could also have some API calls and have Sigfox automatically transmit these API calls but I'd say it's in a matter of a couple of seconds, like three seconds or so. I haven't tested it. Okay, now I have to ask, is there somebody on mic eight? One more? Yes, there's one more. Okay, please. Yeah, so is the Sigfox algorithms, all the things running on the companies provided chips or is there some software involved which could be potentially reverse engineered? So the software that is involved that could be reverse engineered is the client library but this is already the part I am publishing now so there's a couple of more things that you can reverse engineer about this. I don't think you're going to be able to get a Sigfox base station there, probably not giving one to you. Okay, we have time for one more question. We take one from the Internet. What are the advantages that you see of Sigfox versus Lorawan? I think that Sigfox has even more low power than Lorawan. There are also a couple of other advantages but in general I think that it's good if we have two competing providers in the LP van space just to have some diversity. Yeah, there are advantages to both of them. I think that's great to have both of them around. As I told you, it's more low power and I also think that it's a bit more scalable and also from the perspective of someone that's trying to deploy a Sigfox device fleet you just have to take care of the devices. You don't have to take care of the network so that's another advantage. Okay, there is time up. Thank you very much and please give a round of applause for this amazing talk for Lorawan.