35c3 preroll music Angel: I'm very happy to be allowed to announce the following talk. Hunting the Sigfox: Wireless IoT network security by Florian. Some of you have might heard of the work of Florian already, because sometime ago there was an article on a popular German website called "Furby from hell" and somebody there hacked the Furby and there was also a video where you could see the debug output on the displays which are the eyes of the Furby. It was a really disturbing video and the guy who did this is exactly Florian. applause Today he's gonna talk about Sigfox which is not another toy but a network technology for IoT devices. And like it's always we see IoT word the security issues. So let's hear a talk about the Internet of shit by Florian and welcome him with a big round of applause. applause Thank you for that introduction. So this talk will be targeted at the technical audience which is the case here but you don't have to be RF experts on the trip in order to understand this. So I will start by covering some basics of RF technology and some basics about Sigfox. And just after that I'll start talking about an analysis of the Sigfox protocol and its security. I'll mention the most important thing first , which is that I didn't find any serious vulnerabilities in the Sigfox protocol. But there are substantial weak spots and you should be aware of these if you want to use Sigfox 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'd 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 collar - her collar 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 collar here for Alice. So this collar does a couple of thing - couple of things. First of all, it determines Alice's position based on GPS satellites. It also measures measures her body temperature and then it transmits all of this information to Bob. So that's what he wants 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 country site with Wi-Fi there's just not enough range. Mobile networks, they would theoretically work but they are just really expensive and they need a lot of power. So you have to change the battery relatively often. Luckily, these days there's a third option and it's called the LPWan. And this is short for Low Power Wide Area Network. And the LPWan is great because it solves all of these problems. Now, how is this possible? Why might we just - might have we just discovered the LPWan so recently, why hasn't this been done before. What kind of compromises do they make. And to understand the compromises that LP 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 wide 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 MHz, that's the bandwidth of Wi-Fi, and this red rectangle on 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 single power. And this root 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 signal 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 narrowband technology and Sigfox is one of these ultra narrowband 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 narrow frequency range. And the answer's kind of obvious. You can see it already. It's that bandwidth is proportional to data rate. When I'm saying that is obvious, that's because it's sort of ingrained in our language. So when I tell you that I have broadband 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 narrowband technology, you have to think Sigfox is slow. And when I'm slow - things slow here - it's not just a bit slow but extremely slow. So here on the right you can see a comparison between Sigfox and its very fastest configuration and the 56k dial up modem. Now this means that we can only transmit 140 uplinks per day and then 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 downings per day and they are not big either they are just 8 bytes. So what I'm saying here is that you can forget everything you happen to know about Internet protocol 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's just - it's just transmittes it's just broadcasting. So Sigfox device just sleeps all day long until some interrupt occurs like some 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 Sigfox cloud. So we just have to look at one uplink transmission and there's no, 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 you don't just have one device but like ten devices or 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 - the sort of frequency multiplex our uplink. So this this is frequency and time division multiple access. 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 band signals colliding is just extremely slim. Now all of these peaks you can see in this diagram, are not all cows. There are also a bunch of other Sigfox devices. And for instance Sigfox is also used in areas like smart homes, MARK metering, smart city, the agriculture industry 4.0. So essentially we have the full range of buzzwords and this probably helps Sigfox raise 250 million euros during the last couple of years. And 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 the unlicensed spectrum in Europe. That's at 868 MHz. 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 if it's any good. I'll say Sigfox is not the only LP of 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. 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. 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 if phase is changed and stays the same. That's zero. So this is a special kind of phase modulation that Sigfox uses. So you can see these knees 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 then that's the one. And when the frequency is a bit lower that's a zero. Like your car radio uses the analog version of this but this just frequency shift keying which is a very similar technique. Let's actually get started with the Sigfox uplink. At this point I want to thank Paul Pino. He did some really amazing reverse engineering work of 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 pycom SiPy and the other one is a development kit by FC micro electronics. And I also had a software defined radio so for those of you who don't know a software defined radio or as 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. And 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 these different Sigfox uplinks and to find this out I had to demodulate it, so demodulation means that I know that Fox uplink uses D-BPSK, thats differential binary phase shift keying, which is a special kind of the phase modulation I've been talking about and using this information I can write a demodulator software and 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 close 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 convolution or 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 and 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 out comes the encoded data. That's that's all there is to have (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 is just a fancy way of saying that this helps us correct bit errors or transmissions 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 were 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 dumps 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 unique 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 documented 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 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. First one 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 of 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 the checksum 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 this here, 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 Ethernet 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 e-mails and so on. But it doesn't use ... like PGP e-mails use something like RSA so they have an asymmetric scheme, 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. I already have 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 Sigfoxes YouTube video on security, they say that the secret key is stored in non accessible memory. So this sounds secure right? But it turns out that when I first got the pycom SiPy, 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 SiPys 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. applause So the secret key is in plain text in flash memory. applause continues You might say that's not really a problem because you need physical access to this device in order to 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 this secure element chip. 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 CBC-MAC which is just a AES in chiper block chaining mode, so can 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 that's how it should be. So let's look at the security of the uplink. It looks pretty good at this first glance. So they use well-established algorithms like CBC- MAC. So CBC-MAC is also used in Wi-Fi, so it's tried and true. I didn't find any obvious implementation flaws in the uplink so I tried to fuzz 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 their response was that they do offer an encrypted solution, but of course it takes some energy to calculate 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 Sigfox uplink are these two here. I think the MAC is just way too short and the sequence number is extremely short and 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... laughter ...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 four 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 at four frequencies like it's shown here but at 300 frequencies. And then we're 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 Sigfox about this and their 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 Sigfox. 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. This just means that I capture an uplink frame from Alice and at some later point in time I just replay it to the Sigfox base station and hope it gets accepted. But usually it doesn't get accepted because the sequence number is a replay protection. But again in the case of Sigfox the sequence number is very short just 12 bits long. So it's going to overflow eventually. And again looking at the worst case scenario this is after less than 30 days. I had to ask Sigfox 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 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 Sigfox 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 money transporter or a security system where you need confidentiality or authenticity, then you should probably think about using Sigfox or implement your own checks or use Sigfoxs encrypted solution. So that's all for the uplink. Now, 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 Sigfox device sleeps all day. This means that the Sigfox base station cannot just transmit a downlink, but the Sigfox device has to request it first. So it sends an uplink that contains a downlink request and the Sigfox base station, uhm Sigfox cloud then decides which base station is going to answer with a downlink. Now, of course I want 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 Grafenberg. And it turns out that this antenna was actually a Sigfox base station. Now if you want to find your own Sigfox 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 Bundesnetzagentur. And I figured out that whenever there is something called a 'sonstige Funkanlage' and it has these specific security clearances, then that's Sigfox. laughter So here's another one. applause So let's just listen to one of these downlinks. short signal noise 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 Shifting Keying. Again I demodulated this uplink er 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 some 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, 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 BCH(15, 11, 1) code and this is cool because this can correct 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 Pinault 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, and 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 this modems and not the old ones. Now if you don't buy a modem with the encryption solution these are your options: So you have to implement encryption yourself if you need it. There is 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 Marc and 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 Pinault 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 side. So none of that was Sigfox's fault. He reacted 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, these substantial weak spots but we didn't find any major issues, and what he said then was that Sigfox is planning to open source their device 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 more, if you want to find out more about Sigfox and you don't want to wait for Sigfox to release their device 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 and the reference implantation is for software defined radio. If you have any questions you can contact me by email. You can also call me on my DECT phone here during conference and of course here's my Sigfox device ID and my Sigfox secret key, so just send me a Sigfox uplink. Thank you. applause Herald: Thank you Florian for this amazing talk, and now we have time for some questions. There's I think a lot of microhones 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 we have somebody on the mic there in the back. Yes that's mic, number I can't read that from here, I'm too old for that shit. Eight. Okay thanks. Number eight you start. Q: So Hi, is this on, yeah, so you said scrambling didn't provide any confidentiality, so what is it for? A: It might be for, just for receiver synchronization because it facilitates receiver synchronization. I'm not sure what 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 tell you. Herald: OK now we shift over there to the mic, yes you exactly in the white shirt. This was the mic. Okay, then I was then I want to go to 7 sorry, the numbers are too far away. It's just such such a big room, number seven please. Q: Hi. Thanks for the talk. My question is what is the reason you cannot disclose the scrambling algoritm? A: I could disclose thie scrambling algorithm but I have decided not to. So there is 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. Herald: OK, now we take a question from the Internet. Q: Yes, so one of the IRC users asks: Do you think that it is possible to run your own base stations in the future or will they always be run by Sigfox? A: Absolutely. It's just a matter of intellectual property and whether that's legal or not, I think they do have some patents 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 your own secret keys, you you cannot get the secret, well you could extract them from the devices but you cannot get the secret keys of all devices from Sigfox but of course you could run your own parallel Sigfox network. H: OK. Mike. Number eight again. Thanks for the talk. I have a student who wants to fuzz LoRaWAN. You mentioned a few times you fuzzed the uplink. Did you use the ACR implementation for sending as well or did you figure out how to manipulate one of the existing radio transceivers. A: I did manipulate the PI comp sci pi but I didn't use that to fuzz the uplink so I used the SDR implementation to fuzz the uplink. Herald: Okay. Sing a number 7. There's another question. Q: Hi. Can you tell us what an agency is like on these networks. A: Didn't get that. Sorry. Q: Can you tell us what's the latency is like on those networks. A: The latency on these networks. (Q: Yes.) Well it's like you have to go to a website to to retrieve all of the information from that the Sigfox base Station has received. And I didn't really test this because theoretically you could also have some some API calls and have Sigfax automaticly transmit this 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. Herald: Okay now I have to ask is there somebody on mic eight. One more. Yes yes. One more. Okay. Please. It's you. Q: Yeah. So is the sigfox algorithms all of these things are running on the companies provided chips or is there some software involved which could be potentially reverse engineered? A: 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. Also 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, they're probably not giving one to you. Herald: Okay. Yeah we have time for one more question. We take one from the Internet. Q: What are the advantages of Sigfox verses LoRaWAN. A: I think that sigFox is even more low power than LoRaWAN. There are also a couple of other advantage, but in general I think that it's good if we have two competing providers in the LP events space just to have some diversity. And yeah there are advantages to both of them. So but in general I think that that's greate too to have both of them around. But as I told you it's more low power. 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 that you just have to take care of the devices you don't have to take care of the network. So that's another advantage. Herald: Okay. So as time's up thank you very much. And please another round of applause for this amazing talk Florian. applause 35c3 postroll music subtitles created by c3subtitles.de in the year 2019. Join, and help us!