1 00:00:00,000 --> 00:00:19,920 *35c3 preroll music* 2 00:00:19,920 --> 00:00:25,900 Angel: I'm very happy to be allowed to announce the following talk. Hunting the 3 00:00:25,900 --> 00:00:34,730 Sigfox: Wireless IoT network security by Florian. Some of you have might heard of 4 00:00:34,730 --> 00:00:39,780 the work of Florian already, because sometime ago there was an article on a 5 00:00:39,780 --> 00:00:46,699 popular German website called "Furby from hell" and somebody there hacked the Furby 6 00:00:46,699 --> 00:00:51,030 and there was also a video where you could see the debug output on the displays which 7 00:00:51,030 --> 00:00:56,969 are the eyes of the Furby. It was a really disturbing video and the guy who did this 8 00:00:56,969 --> 00:01:08,360 is exactly Florian. *applause* Today he's gonna talk about Sigfox which is not 9 00:01:08,360 --> 00:01:15,110 another toy but a network technology for IoT devices. And like it's always we see 10 00:01:15,110 --> 00:01:22,030 IoT word the security issues. So let's hear a talk about the Internet of shit by 11 00:01:22,030 --> 00:01:26,160 Florian and welcome him with a big round of applause. 12 00:01:26,160 --> 00:01:33,720 *applause* Thank you for that introduction. So this 13 00:01:33,720 --> 00:01:37,990 talk will be targeted at the technical audience which is the case here but you 14 00:01:37,990 --> 00:01:42,790 don't have to be RF experts on the trip in order to understand this. So I will start 15 00:01:42,790 --> 00:01:48,000 by covering some basics of RF technology and some basics about Sigfox. And just 16 00:01:48,000 --> 00:01:52,540 after that I'll start talking about an analysis of the Sigfox protocol and its 17 00:01:52,540 --> 00:01:57,700 security. I'll mention the most important thing first , which is that I didn't find 18 00:01:57,700 --> 00:02:02,680 any serious vulnerabilities in the Sigfox protocol. But there are substantial weak 19 00:02:02,680 --> 00:02:06,500 spots and you should be aware of these if you want to use Sigfox in your own 20 00:02:06,500 --> 00:02:12,140 application. But let me introduce myself first. I don't think there's a lot of 21 00:02:12,140 --> 00:02:16,450 information you need to know about me, so I figured I'd just show you this picture 22 00:02:16,450 --> 00:02:20,659 here of me instead. I'm not showing you this picture because I think I look so 23 00:02:20,659 --> 00:02:27,379 fabulous but because I think that this cow here in the background is amazing and this 24 00:02:27,379 --> 00:02:32,459 is not just any cow. This is Alice. Alice the cow. And as you can see she has a 25 00:02:32,459 --> 00:02:38,359 great life, so she lives somewhere in the mountains. And there's just one problem 26 00:02:38,359 --> 00:02:45,950 with her. She likes to break out of her collar - her collar now her farmer which 27 00:02:45,950 --> 00:02:50,599 is called Bob doesn't like this very much but he recently heard about something 28 00:02:50,599 --> 00:02:57,739 called the IoT. And he thinks that the IoT is going to solve all of his problems. So 29 00:02:57,739 --> 00:03:02,889 he purchased this collar here for Alice. So this collar does a couple of thing - 30 00:03:02,889 --> 00:03:08,720 couple of things. First of all, it determines Alice's position based on GPS 31 00:03:08,720 --> 00:03:13,569 satellites. It also measures measures her body temperature and then it transmits all 32 00:03:13,569 --> 00:03:18,599 of this information to Bob. So that's what he wants to do. There's just one obvious 33 00:03:18,599 --> 00:03:25,140 problem: How do we even get this data from Alice to Bob? Well, traditionally in the 34 00:03:25,140 --> 00:03:30,390 IoT there have been two solutions that have often been employed. One of them is 35 00:03:30,390 --> 00:03:34,890 Wi-Fi and the other one is mobile networks. Now Wi-Fi is not going to work 36 00:03:34,890 --> 00:03:41,180 in this application. Here we cannot cover the whole country site with Wi-Fi there's 37 00:03:41,180 --> 00:03:46,549 just not enough range. Mobile networks, they would theoretically work but they are 38 00:03:46,549 --> 00:03:51,200 just really expensive and they need a lot of power. So you have to change the 39 00:03:51,200 --> 00:03:56,739 battery relatively often. Luckily, these days there's a third option and it's 40 00:03:56,739 --> 00:04:02,399 called the LPWan. And this is short for Low Power Wide Area Network. And the 41 00:04:02,399 --> 00:04:07,650 LPWan is great because it solves all of these problems. Now, how is this 42 00:04:07,650 --> 00:04:12,180 possible? Why might we just - might have we just discovered the LPWan so recently, 43 00:04:12,180 --> 00:04:17,249 why hasn't this been done before. What kind of compromises do they make. And to 44 00:04:17,249 --> 00:04:20,899 understand the compromises that LP networks make we have to look at the 45 00:04:20,899 --> 00:04:26,250 electromagnetic spectrum. So that's what the electromagnetic spectrum of a Wi-Fi 46 00:04:26,250 --> 00:04:31,480 signal looks like. You can see that Wi-Fi is fairly wide band and you have these 47 00:04:31,480 --> 00:04:36,690 tiny ripples on top of the signal that is noise and we don't like this noise. In 48 00:04:36,690 --> 00:04:41,411 order to find the power that's contained in one of these Wi-Fi transmissions, we 49 00:04:41,411 --> 00:04:45,820 have to look at the area underneath a curve. So that's the power of the Wi-Fi 50 00:04:45,820 --> 00:04:54,690 signal. It's typically 20 MHz, that's the bandwidth of Wi-Fi, and this red rectangle 51 00:04:54,690 --> 00:04:59,580 on on top of the signal, this is the noise and we don't want this. Now what 52 00:04:59,580 --> 00:05:03,850 determines the range is not the absolute value of the noise but the relative value 53 00:05:03,850 --> 00:05:08,950 of the noise compared to the single power. And this root ratio is called the signal 54 00:05:08,950 --> 00:05:14,500 to noise ratio or SNR for short. Now if you look at the blue and the red square 55 00:05:14,500 --> 00:05:18,750 you can see that the red square is very big compared to the blue square, which 56 00:05:18,750 --> 00:05:24,560 means that our signal to noise ratio is really bad. Now the solution to this is 57 00:05:24,560 --> 00:05:28,950 kind of obvious once you know it: You just concentrate this whole signal power in a 58 00:05:28,950 --> 00:05:35,260 very narrow frequency range. Now this way, you just have this tiny little ripple on 59 00:05:35,260 --> 00:05:39,710 top of the signal and that's all your noise. So now your signal to noise ratio 60 00:05:39,710 --> 00:05:44,060 is a lot better. And this focusing of the complete signal power in a very near 61 00:05:44,060 --> 00:05:48,960 frequency range that's called ultra narrowband technology and Sigfox is one of 62 00:05:48,960 --> 00:05:55,620 these ultra narrowband technologies. Now you might wonder why don't we do this with 63 00:05:55,620 --> 00:06:00,060 Wi-Fi as well. If the solution is so simple why don't we always concentrate the 64 00:06:00,060 --> 00:06:04,050 complete signal power in a very narrow frequency range. And the answer's kind of 65 00:06:04,050 --> 00:06:08,460 obvious. You can see it already. It's that bandwidth is proportional to data rate. 66 00:06:08,460 --> 00:06:11,770 When I'm saying that is obvious, that's because it's sort of ingrained in our 67 00:06:11,770 --> 00:06:16,420 language. So when I tell you that I have broadband internet you think that my 68 00:06:16,420 --> 00:06:20,770 internet is fast. You don't think that my internet uses a lot of frequency real 69 00:06:20,770 --> 00:06:25,870 estate. On the other hand if I tell you that Sigfox is an ultra narrowband 70 00:06:25,870 --> 00:06:30,930 technology, you have to think Sigfox is slow. And when I'm slow - things slow here 71 00:06:30,930 --> 00:06:35,720 - it's not just a bit slow but extremely slow. So here on the right you can see a 72 00:06:35,720 --> 00:06:40,610 comparison between Sigfox and its very fastest configuration and the 56k dial 73 00:06:40,610 --> 00:06:49,440 up modem. Now this means that we can only transmit 140 uplinks per day and then 74 00:06:49,440 --> 00:06:53,640 uplink can contain up to 12 bytes so uplink would be from Alice's collar to the 75 00:06:53,640 --> 00:06:59,680 Sigfox base station to Bob and we can only receive four downings per day and they are 76 00:06:59,680 --> 00:07:04,280 not big either they are just 8 bytes. So what I'm saying here is that you can 77 00:07:04,280 --> 00:07:09,380 forget everything you happen to know about Internet protocol so there's no IP, 78 00:07:09,380 --> 00:07:13,020 there's no DNS, there's no HDTV or anything like that. Sigfox is a completely 79 00:07:13,020 --> 00:07:18,750 separate protocol. Now even more than that, there's not even any signaling or 80 00:07:18,750 --> 00:07:24,031 connection establishment. So when a Sigfox device wants to transmit something, it's 81 00:07:24,031 --> 00:07:28,610 just - it's just transmittes it's just broadcasting. So Sigfox device just sleeps 82 00:07:28,610 --> 00:07:34,520 all day long until some interrupt occurs like some some timer overflows or some 83 00:07:34,520 --> 00:07:40,280 button is pressed and then it broadcasts the information it has gathered. Sigfox 84 00:07:40,280 --> 00:07:43,990 base stations may pick it up or not, and if they do, they just forward this 85 00:07:43,990 --> 00:07:47,880 information to Sigfox cloud. So we just have to look at one uplink transmission 86 00:07:47,880 --> 00:07:54,240 and there's no, no long protocol on top of that. Now that's cool and this only works 87 00:07:54,240 --> 00:07:57,200 if there's one device you may think. So how is this possible if you don't just 88 00:07:57,200 --> 00:08:03,090 have one device but like ten devices or or hundreds or thousands of devices. How can 89 00:08:03,090 --> 00:08:06,980 we make sure that these uplink transmissions don't collide. And the 90 00:08:06,980 --> 00:08:11,210 reality is that these uplink transmissions may actually collide. Again we have to 91 00:08:11,210 --> 00:08:16,450 look at the radio spectrum to understand this - the sort of frequency multiplex our 92 00:08:16,450 --> 00:08:22,090 uplink. So this this is frequency and time division multiple access. So you have 93 00:08:22,090 --> 00:08:26,480 Sigfox uplink at different frequencies at the same time and whenever a Sigfox device 94 00:08:26,480 --> 00:08:30,320 wants to transmit an uplink, it first chooses a frequency to transmit at 95 00:08:30,320 --> 00:08:35,010 randomly. And the likelihood of two of these very narrow band signals colliding 96 00:08:35,010 --> 00:08:41,570 is just extremely slim. Now all of these peaks you can see in this diagram, are not 97 00:08:41,570 --> 00:08:46,770 all cows. There are also a bunch of other Sigfox devices. And for instance 98 00:08:46,770 --> 00:08:52,210 Sigfox is also used in areas like smart homes, MARK metering, smart city, the 99 00:08:52,210 --> 00:08:58,110 agriculture industry 4.0. So essentially we have the full range of buzzwords and 100 00:08:58,110 --> 00:09:02,940 this probably helps Sigfox raise 250 million euros during the last couple of 101 00:09:02,940 --> 00:09:07,240 years. And with all of that money they already got pretty decent coverage, as you 102 00:09:07,240 --> 00:09:12,400 can see in the coverage map on the left. Now one thing that's cool about Sigfox is 103 00:09:12,400 --> 00:09:17,970 that they use the unlicensed spectrum in Europe. That's at 868 MHz. This is cool 104 00:09:17,970 --> 00:09:24,240 because it's free to use so Sigfox is extremely cheap. Now just the downside of 105 00:09:24,240 --> 00:09:29,210 Sigfox is that Sigfox is completely proprietary so we cannot verify whether 106 00:09:29,210 --> 00:09:32,180 it's secure or not. And this is the part I'm trying to change with this 107 00:09:32,180 --> 00:09:36,990 presentation here. And look at a security of the Sigfox protocol and see if it's if 108 00:09:36,990 --> 00:09:42,110 it's any good. I'll say Sigfox is not the only LP of technology. There are a bunch 109 00:09:42,110 --> 00:09:48,120 of others. So here are a couple of names but to be honest I'd say that these three 110 00:09:48,120 --> 00:09:55,260 here are the ones you should remember. So that's all I have to say about the Sigfox. 111 00:09:55,260 --> 00:10:00,400 Sigfox technology and Sigfox basics. Let's just do a quick refresher of RF basics 112 00:10:00,400 --> 00:10:04,070 first. So this is going to be extremely short and many of you are going to know 113 00:10:04,070 --> 00:10:08,940 this already. So the basic idea is that I want to transmit some information 114 00:10:08,940 --> 00:10:15,550 wirelessly and to do this I have to emit an electromagnetic wave. So this is what 115 00:10:15,550 --> 00:10:20,080 an EM wave looks like. As you can see there's no information on there. We have 116 00:10:20,080 --> 00:10:24,890 to put some information on there somehow and this process is called modulation. 117 00:10:24,890 --> 00:10:28,820 There are different ways to modulate a radio wave. And one of them is phase 118 00:10:28,820 --> 00:10:35,050 modulation. This means that in this case here whenever the phase changes by 180 119 00:10:35,050 --> 00:10:40,460 degrees that's the one when if phase is changed and stays the same. That's zero. 120 00:10:40,460 --> 00:10:44,330 So this is a special kind of phase modulation that Sigfox uses. So you can 121 00:10:44,330 --> 00:10:49,760 see these knees in the sine wave. Now this is not the only modulation technique. 122 00:10:49,760 --> 00:10:55,240 There's also frequency modulation. You probably know this from your car radio for 123 00:10:55,240 --> 00:11:01,510 instance. So this is frequency modulation - frequency modulation just means that 124 00:11:01,510 --> 00:11:05,210 whenever the frequency is a bit higher then that's the one. And when the 125 00:11:05,210 --> 00:11:08,910 frequency is a bit lower that's a zero. Like your car radio uses the analog 126 00:11:08,910 --> 00:11:12,170 version of this but this just frequency shift keying which is a very similar 127 00:11:12,170 --> 00:11:18,240 technique. Let's actually get started with the Sigfox uplink. At this point I want to 128 00:11:18,240 --> 00:11:23,830 thank Paul Pino. He did some really amazing reverse engineering work of some 129 00:11:23,830 --> 00:11:27,570 basic reverse engineering work of the Sigfox protocol and published it on his 130 00:11:27,570 --> 00:11:33,200 blog. And this really helped me get started with my own analysis. So to 131 00:11:33,200 --> 00:11:37,980 analyze the Sigfox protocol myself, I first wanted to record one of these uplink 132 00:11:37,980 --> 00:11:44,260 frames. So I got two Sigfox devices, one of them is the pycom SiPy and the other 133 00:11:44,260 --> 00:11:49,250 one is a development kit by FC micro electronics. And I also had a software 134 00:11:49,250 --> 00:11:53,930 defined radio so for those of you who don't know a software defined radio or as 135 00:11:53,930 --> 00:11:59,319 SDR for short is just a device that's pretty much a microphone but not for 136 00:11:59,319 --> 00:12:03,810 sound, for sound waves, but for electromagnetic waves. So we can use this 137 00:12:03,810 --> 00:12:09,280 to record electromagnetic waves into something that's very similar to a sound 138 00:12:09,280 --> 00:12:14,560 file. And I just want you to listen to one of these sound files first and I want you 139 00:12:14,560 --> 00:12:19,029 to know that this is going to be in real time. And it's also just one piece of 140 00:12:19,029 --> 00:12:22,730 information that I'm transmitting, so this is not a couple of transmissions but just 141 00:12:22,730 --> 00:12:34,649 one transmission. The interesting part here is that even though I was just 142 00:12:34,649 --> 00:12:39,920 transmitting one piece of information, we have three uplinks at different 143 00:12:39,920 --> 00:12:45,240 frequencies apparently. Now I wanted to find out what's the relationship between 144 00:12:45,240 --> 00:12:50,440 these these different Sigfox uplinks and to find this out I had to demodulate it, 145 00:12:50,440 --> 00:12:56,920 so demodulation means that I know that Fox uplink uses D-BPSK, thats differential 146 00:12:56,920 --> 00:13:00,230 binary phase shift keying, which is a special kind of the phase modulation I've 147 00:13:00,230 --> 00:13:05,670 been talking about and using this information I can write a demodulator 148 00:13:05,670 --> 00:13:11,190 software and this outputs a hexadecimal representation of the Sigfox uplink; so 149 00:13:11,190 --> 00:13:15,420 just binary representation. And that's what it looks like. So I've colored these 150 00:13:15,420 --> 00:13:20,759 three uplink frames in different colors so that you can distinguish them. Now let's 151 00:13:20,759 --> 00:13:26,310 have a close look at these and see what they have in common. So the one thing they 152 00:13:26,310 --> 00:13:31,440 have in common is this preamble here but everything else appears to be completely 153 00:13:31,440 --> 00:13:37,700 uncorrelated. That's what I thought at first, but eventually it turned out that 154 00:13:37,700 --> 00:13:42,300 this is convolution or coding. I guess if you're a coding person it's enough for me 155 00:13:42,300 --> 00:13:46,950 to tell you that this is a (5,7) convolutional code and if not you probably 156 00:13:46,950 --> 00:13:51,480 don't know what these words even mean. So this is a convolutional code. It just 157 00:13:51,480 --> 00:13:56,000 means that I take this unencoded input, which is the red frame, and feed it into 158 00:13:56,000 --> 00:14:01,380 these schematic diagrams here which are made up of shift registers and XOR 159 00:14:01,380 --> 00:14:06,210 operations and out comes the encoded data. That's that's all there is to have (5,7) 160 00:14:06,210 --> 00:14:14,060 convolutional code. Now this means that the first, second and third transmission 161 00:14:14,060 --> 00:14:18,720 all contain the exact same information. So why am I transmitting this information 162 00:14:18,720 --> 00:14:26,990 three times? The technical term for this is coding gain. So coding gain is just a 163 00:14:26,990 --> 00:14:31,209 fancy way of saying that this helps us correct bit errors or transmissions errors 164 00:14:31,209 --> 00:14:36,839 if they happen to occur in the uplink transmission. But to continue I just have 165 00:14:36,839 --> 00:14:42,650 to focus on this initial transmission here which is the one that's unencoded, and I 166 00:14:42,650 --> 00:14:46,080 can just ignore the other ones because they are just the same information anyway, 167 00:14:46,080 --> 00:14:50,420 just encoded differently. So of course I captured a couple of these first 168 00:14:50,420 --> 00:14:55,560 transmissions just ignored the rest and they were all with the same payload so 169 00:14:55,560 --> 00:15:01,179 that I can find some similarities. Now let's look at a bunch of these. So the 170 00:15:01,179 --> 00:15:06,350 whole trick to analyzing these wireless protocols is just to keep staring at these 171 00:15:06,350 --> 00:15:12,089 hex dumps for a very long time until you see some patterns. And I think you can 172 00:15:12,089 --> 00:15:16,430 already spot some of them. So that's the preamble, we already talked about that. 173 00:15:16,430 --> 00:15:21,020 Then here we have some header. Then this is a sequence number. This is especially 174 00:15:21,020 --> 00:15:26,050 easy to spot because the number is incremented after every transmission. Then 175 00:15:26,050 --> 00:15:31,180 here that's the device ID. So this is a unique identifier for every Sigfox device 176 00:15:31,180 --> 00:15:35,029 which tells us that this uplink transmission was from Alice and not from 177 00:15:35,029 --> 00:15:40,580 some other cow or some other device, and that is the payload. And as you can see 178 00:15:40,580 --> 00:15:46,650 it's completely unencoded and unencrypted. Now this may seem bad but it's not really 179 00:15:46,650 --> 00:15:51,410 a problem in terms of security issues because this is documented behavior. So 180 00:15:51,410 --> 00:15:55,790 when you look at Sigfox security white paper they say that data is conveyed over 181 00:15:55,790 --> 00:16:00,491 the air without any encryption. So that's strange, but it's not really really a 182 00:16:00,491 --> 00:16:05,560 problem as long as it's documented. But eventually after staring at these frames 183 00:16:05,560 --> 00:16:10,940 for some more time I figured out this frame structure here. So you don't have to 184 00:16:10,940 --> 00:16:16,050 remember all of this. I'm going to publish an 80 page document that contains all of 185 00:16:16,050 --> 00:16:21,210 the boring protocol details and you can read up what every flag bit means later 186 00:16:21,210 --> 00:16:25,990 on. But for now I just want to focus on a couple of things. First one to wrap this 187 00:16:25,990 --> 00:16:31,200 up a bit. So whenever we receive an uplink frame from Alice the cow this is 188 00:16:31,200 --> 00:16:35,260 essentially what she's telling us. So most importantly that's the payload. What she's 189 00:16:35,260 --> 00:16:40,180 doing right now for instance. And then there's also the device ID which tells us 190 00:16:40,180 --> 00:16:46,810 that this is Alice. And there's also a bunch of more information in there. Now 191 00:16:46,810 --> 00:16:51,070 again I want to focus on two fields here that are a bit more interesting. One of 192 00:16:51,070 --> 00:16:57,769 them is the CRC and the other one is the MAC. Now, CRC, if you're a coding person 193 00:16:57,769 --> 00:17:03,220 again you probably know what to do with this information here for everyone else 194 00:17:03,220 --> 00:17:07,970 you might know this already, but this is just the checksum so this helps us detect 195 00:17:07,970 --> 00:17:12,420 bit errors in the uplink frame and correct ... not correct them, but to discard the 196 00:17:12,420 --> 00:17:17,650 uplink frame in case these bit errors occur. Now this here, the MAC is a bit 197 00:17:17,650 --> 00:17:22,979 more interesting. So in this case MAC does not stand for an Apple computer. It also 198 00:17:22,979 --> 00:17:27,349 doesn't stand for a MAC address so it has nothing to do with medium access control 199 00:17:27,349 --> 00:17:33,230 or Ethernet or anything. It stands for message authentication code. Now as the 200 00:17:33,230 --> 00:17:38,070 name says a message authentication code is for authenticity protection. So this is 201 00:17:38,070 --> 00:17:42,460 something that's very similar to digital signatures. So you might know digital 202 00:17:42,460 --> 00:17:48,400 signatures just from PGP e-mails and so on. But it doesn't use ... like PGP 203 00:17:48,400 --> 00:17:54,950 e-mails use something like RSA so they have an asymmetric scheme, whereas message 204 00:17:54,950 --> 00:18:00,189 authentication codes they use a symmetric encryption scheme like for instance AES. 205 00:18:00,189 --> 00:18:04,179 Now this slide is not that important. The only important part is that I wanted this 206 00:18:04,179 --> 00:18:08,510 algorithm here. So I wanted the algorithm that I can use to generate one of these 207 00:18:08,510 --> 00:18:14,510 MACs. I already have the payload and all of the message I'm transmitting. I didn't 208 00:18:14,510 --> 00:18:21,360 have the key yet so I wanted the key. Now at first I thought it was impossible to 209 00:18:21,360 --> 00:18:26,340 get the key from a Sigfox device because if you watch Sigfoxes YouTube video on 210 00:18:26,340 --> 00:18:32,400 security, they say that the secret key is stored in non accessible memory. So this 211 00:18:32,400 --> 00:18:38,300 sounds secure right? But it turns out that when I first got the pycom SiPy, this 212 00:18:38,300 --> 00:18:42,740 development kit here, it wanted to update the firmware and it didn't just update the 213 00:18:42,740 --> 00:18:47,590 firmware, but this is a section of the SiPys flash memory before the so-called 214 00:18:47,590 --> 00:18:51,610 firmware update, and this is the same section after the firmware update and it 215 00:18:51,610 --> 00:18:55,230 totally provisioned the device ID, some other code and that's the secret key. 216 00:18:55,230 --> 00:18:59,150 *applause* So the secret key is in plain text in 217 00:18:59,150 --> 00:19:03,850 flash memory. *applause continues* 218 00:19:03,850 --> 00:19:09,170 You might say that's not really a problem because you need physical access to this 219 00:19:09,170 --> 00:19:15,350 device in order to to get the secret key. But still I confronted Sigfox about this 220 00:19:15,350 --> 00:19:21,740 issue and their response was that yeah they do offer solutions where the secret 221 00:19:21,740 --> 00:19:27,220 key is not stored in plain text but it costs some money and many manufacturers 222 00:19:27,220 --> 00:19:32,090 don't choose to use it. So pycom for instance didn't have this secure element 223 00:19:32,090 --> 00:19:38,790 chip. But at this point I had the key, So just based on some educated guessing I was 224 00:19:38,790 --> 00:19:44,089 able to find the algorithm that's used for calculating the MAC, and many of you 225 00:19:44,089 --> 00:19:48,410 probably know this already, so this is CBC-MAC which is just a AES in chiper block 226 00:19:48,410 --> 00:19:52,850 chaining mode, so can we can use the structure to generate a MAC. The input to 227 00:19:52,850 --> 00:19:57,990 this algorithm is not just the payload but also some other information like the flag 228 00:19:57,990 --> 00:20:02,740 bits, the sequence number, the device ID and the payload of course. So yeah that's 229 00:20:02,740 --> 00:20:07,980 that's how it should be. So let's look at the security of the uplink. It looks 230 00:20:07,980 --> 00:20:12,830 pretty good at this first glance. So they use well-established algorithms like CBC- 231 00:20:12,830 --> 00:20:18,419 MAC. So CBC-MAC is also used in Wi-Fi, so it's tried and true. I didn't find any 232 00:20:18,419 --> 00:20:22,640 obvious implementation flaws in the uplink so I tried to fuzz the uplink but it 233 00:20:22,640 --> 00:20:27,380 didn't get accepted. Now one problem is that we don't have any payload 234 00:20:27,380 --> 00:20:32,740 confidentiality, so this is documented but still I wondered why would you design a 235 00:20:32,740 --> 00:20:38,400 protocol in 2018 or a couple of years ago without any encryption? And their response 236 00:20:38,400 --> 00:20:44,250 was that they do offer an encrypted solution, but of course it takes some 237 00:20:44,250 --> 00:20:49,880 energy to calculate encryption and it really matters if you're talking about 238 00:20:49,880 --> 00:20:54,290 devices with tens of years of battery life, than just performing this one 239 00:20:54,290 --> 00:21:00,499 encryption can make a difference. Now this is not a real problem in my opinion. I 240 00:21:00,499 --> 00:21:04,790 think the real problem with the Sigfox uplink are these two here. I think the MAC 241 00:21:04,790 --> 00:21:09,440 is just way too short and the sequence number is extremely short and this makes 242 00:21:09,440 --> 00:21:14,470 brute force and replay attacks possible. So let's look at the brute force attack 243 00:21:14,470 --> 00:21:21,090 first and let's just look at the ideal scenario. So this is an ideal world - just 244 00:21:21,090 --> 00:21:25,490 Alice transmitting her uplink frame to the Sigfox cloud. That's what we want. No 245 00:21:25,490 --> 00:21:30,900 attacker here. Now when she's transmitting this uplink frame she's also transmitting 246 00:21:30,900 --> 00:21:36,530 a MAC and in a worst case scenario this Mac is just 16 bits long. So if you do the 247 00:21:36,530 --> 00:21:42,509 math, the number of possible values for the MAC is very limited. So the idea would 248 00:21:42,509 --> 00:21:47,260 be to just try one Mac after the other... *laughter* 249 00:21:47,260 --> 00:21:52,500 ...that's brute-forcing, right. Now with most protocols this is not very practical 250 00:21:52,500 --> 00:21:57,799 because this takes a lot of time. Again looking at the worst case scenario if we 251 00:21:57,799 --> 00:22:03,330 do the math it's possible in just less than four hours. So that's not great. And 252 00:22:03,330 --> 00:22:08,260 remember in the beginning I told you something about frequency Multiplexing and 253 00:22:08,260 --> 00:22:13,600 these multiple uplinks that can coexist at the same time, we can even do this for the 254 00:22:13,600 --> 00:22:18,820 attack. We can just frequency multiplex our attack and we can do this at not just 255 00:22:18,820 --> 00:22:23,560 at four frequencies like it's shown here but at 300 frequencies. And then we're not 256 00:22:23,560 --> 00:22:27,460 talking about a couple of hours to try all possible MACs, but it's a matter of 257 00:22:27,460 --> 00:22:34,690 minutes so that sounds bad. So I confronted Sigfox about this and their 258 00:22:34,690 --> 00:22:39,220 response was that yes they are aware of this issue but they have implemented some 259 00:22:39,220 --> 00:22:43,880 kind of blacklist. Now I wasn't able to confirm this information because I only 260 00:22:43,880 --> 00:22:48,100 had development kits and they say that development kits are exempt from this 261 00:22:48,100 --> 00:22:53,850 regulation. Now, this is great if they have implemented this blacklist, but on 262 00:22:53,850 --> 00:22:57,130 the other hand this also means that now we have a conflict between two security 263 00:22:57,130 --> 00:23:00,960 goals. One of them is authenticity protection and the other one is 264 00:23:00,960 --> 00:23:04,809 availability. So you're not going to have perfect availability if you're using 265 00:23:04,809 --> 00:23:10,940 Sigfox. But on the other hand maybe if you want perfect availability maybe you just 266 00:23:10,940 --> 00:23:15,470 shouldn't use a wireless system in the first place. Now, the other attack is the 267 00:23:15,470 --> 00:23:20,549 replay attack. This just means that I capture an uplink frame from Alice and at 268 00:23:20,549 --> 00:23:25,720 some later point in time I just replay it to the Sigfox base station and hope it 269 00:23:25,720 --> 00:23:31,070 gets accepted. But usually it doesn't get accepted because the sequence number is a 270 00:23:31,070 --> 00:23:36,090 replay protection. But again in the case of Sigfox the sequence number is very 271 00:23:36,090 --> 00:23:41,010 short just 12 bits long. So it's going to overflow eventually. And again looking at 272 00:23:41,010 --> 00:23:46,590 the worst case scenario this is after less than 30 days. I had to ask Sigfox about 273 00:23:46,590 --> 00:23:50,750 this as well, and their response was that if you choose their so-called encrypted 274 00:23:50,750 --> 00:23:55,870 solution. So that was the one that also does the payload encryption, then you're 275 00:23:55,870 --> 00:24:01,179 going to have a 20 bit sequence number. So you should probably use that if you if you 276 00:24:01,179 --> 00:24:08,190 don't want to have replay attacks. So in summary if all you want to do is create a 277 00:24:08,190 --> 00:24:13,750 device that tracks cows you're probably going to be fine with just normal Sigfox 278 00:24:13,750 --> 00:24:17,890 without the encrypted solution and you don't need perfect authenticity and no 279 00:24:17,890 --> 00:24:22,940 perfect confidentiality protection. But on the other hand if you have a money 280 00:24:22,940 --> 00:24:28,550 transporter or a security system where you need confidentiality or authenticity, then 281 00:24:28,550 --> 00:24:33,299 you should probably think about using Sigfox or implement your own checks or use 282 00:24:33,299 --> 00:24:38,950 Sigfoxs encrypted solution. So that's all for the uplink. Now, I'm just going to 283 00:24:38,950 --> 00:24:43,150 quickly talk about the downlink. This is going to be extremely short because the 284 00:24:43,150 --> 00:24:49,550 downlink protocol is so much simpler. So I told you that a Sigfox device sleeps all day. This 285 00:24:49,550 --> 00:24:54,039 means that the Sigfox base station cannot just transmit a downlink, but the Sigfox 286 00:24:54,039 --> 00:24:58,200 device has to request it first. So it sends an uplink that contains a downlink 287 00:24:58,200 --> 00:25:04,150 request and the Sigfox base station, uhm Sigfox cloud then decides which base 288 00:25:04,150 --> 00:25:11,059 station is going to answer with a downlink. Now, of course I want to record 289 00:25:11,059 --> 00:25:16,470 one of these downlink transmissions so I had to find a base station at some point a 290 00:25:16,470 --> 00:25:20,040 friend of mine hinted me that there was this omnidirectional antenna here on a 291 00:25:20,040 --> 00:25:26,380 cell tower in Grafenberg. And it turns out that this antenna was actually a Sigfox 292 00:25:26,380 --> 00:25:31,580 base station. Now if you want to find your own Sigfox base station you don't have to 293 00:25:31,580 --> 00:25:35,309 go around hunting for omnidirectional antennas on cell towers. You can just go 294 00:25:35,309 --> 00:25:39,340 to the website of the Bundesnetzagentur. And I figured out that whenever there is 295 00:25:39,340 --> 00:25:43,429 something called a 'sonstige Funkanlage' and it has these specific security 296 00:25:43,429 --> 00:25:47,370 clearances, then that's Sigfox. *laughter* 297 00:25:47,370 --> 00:25:50,420 So here's another one. *applause* 298 00:25:50,420 --> 00:25:57,240 So let's just listen to one of these downlinks. 299 00:25:57,240 --> 00:26:01,720 * short signal noise* Again that was in real time and it was 300 00:26:01,720 --> 00:26:06,890 really short and it sounded differently. This is because this is not phase 301 00:26:06,890 --> 00:26:12,400 modulation but frequency modulation or in this particular case GFSK that's Gaussian 302 00:26:12,400 --> 00:26:15,970 Frequency Shifting Keying. Again I demodulated this uplink er this downlink 303 00:26:15,970 --> 00:26:20,720 frame that's what it looks like. I captured a couple of these I looked at 304 00:26:20,720 --> 00:26:27,510 them that's the preamble, that's a garbled mess. So what could that be? I thought 305 00:26:27,510 --> 00:26:32,250 that maybe suddenly they're using encryption, or maybe some very smart error 306 00:26:32,250 --> 00:26:36,490 correction code scheme, but it turns out that it's something much simpler called 307 00:26:36,490 --> 00:26:41,700 scrambling. So unfortunately I'm not going to tell you the algorithm that's used for 308 00:26:41,700 --> 00:26:45,760 scrambling here, but I can tell you that the inputs to the scrambling algorithm is 309 00:26:45,760 --> 00:26:52,059 just the sequence number and the device ID of the corresponding uplink. So you can 310 00:26:52,059 --> 00:26:55,750 totally reverse the scrambling or you can even brute force it because these two 311 00:26:55,750 --> 00:27:01,820 numbers are very finite. So scrambling does not provide any confidentiality. I 312 00:27:01,820 --> 00:27:05,299 can tell you what I figured out in the end. So this is the complete frame 313 00:27:05,299 --> 00:27:11,990 structure of the downlink it's static so very simple, think that two fields here 314 00:27:11,990 --> 00:27:16,900 are particularly interesting. One of them is this one here so if you're a coding 315 00:27:16,900 --> 00:27:22,070 person this is a BCH(15, 11, 1) code and this is cool because this can correct 316 00:27:22,070 --> 00:27:27,450 correct up to 8 bit errors in the downlink frame and the other interesting thing of 317 00:27:27,450 --> 00:27:31,490 course is this message authentication code, so we also have authenticity 318 00:27:31,490 --> 00:27:38,500 protection for the downlink. So in summary, for the Sigfox downlink it looks 319 00:27:38,500 --> 00:27:44,299 pretty secure, again, the only real problem I found is that there's scrambling 320 00:27:44,299 --> 00:27:49,780 but this scrambling doesn't provide any confidentiality. But last week I figured 321 00:27:49,780 --> 00:27:55,250 out that if you use, or, Paul Pinault hinted me that if you use Sigfox's 322 00:27:55,250 --> 00:27:59,750 encrypted solution he figured this out, then you're also going to have an 323 00:27:59,750 --> 00:28:03,909 encrypted downlink, so you should probably use that. And this is also pretty much my 324 00:28:03,909 --> 00:28:09,780 summary for you: If you are a device maker and you want to build a Sigfox device and 325 00:28:09,780 --> 00:28:15,410 add Sigfox connectivity to your device, it's fine to use Sigfox but you should be 326 00:28:15,410 --> 00:28:19,820 aware of the level of security it provides, and most importantly this means 327 00:28:19,820 --> 00:28:24,059 that if you need confidentiality and if you need good authenticity protection you 328 00:28:24,059 --> 00:28:29,030 should probably use Sigfox's encrypted solution, and this means that you have to 329 00:28:29,030 --> 00:28:34,039 buy one of the very few modems still that support this encryption. This also kind of 330 00:28:34,039 --> 00:28:41,030 puts some pressure on the manufacturers to just start providing this modems and not 331 00:28:41,030 --> 00:28:46,570 the old ones. Now if you don't buy a modem with the encryption solution these are 332 00:28:46,570 --> 00:28:51,549 your options: So you have to implement encryption yourself if you need it. There is 333 00:28:51,549 --> 00:28:56,870 some things you can do to improve the authenticity protection that the Sigfox 334 00:28:56,870 --> 00:29:02,700 uplink and downlink already provide, and if you don't do that you're just going to 335 00:29:02,700 --> 00:29:08,660 have to implement your own authenticity checks. Now I want to thank a couple of 336 00:29:08,660 --> 00:29:13,920 people most importantly that is Felix and Marc and they didn't just help me with the 337 00:29:13,920 --> 00:29:18,270 whole technical aspect of this presentation here, but they also helped me 338 00:29:18,270 --> 00:29:23,270 proofread the documentation I'm going to publish soon and this presentation here. I 339 00:29:23,270 --> 00:29:27,679 also want to thank Paul Pinault for providing quite a lot of information and 340 00:29:27,679 --> 00:29:31,919 you will see a link to his blog on the website I'm going to show you in a second. 341 00:29:31,919 --> 00:29:36,650 I also want to thank Mr. Lehmann from Sigfox Germany. Even though there were 342 00:29:36,650 --> 00:29:40,550 some screw ups in the communication with Sigfox on our side. So none of that was 343 00:29:40,550 --> 00:29:45,880 Sigfox's fault. He reacted really nicely and handled it very nicely and responded 344 00:29:45,880 --> 00:29:50,490 to all of our questions, And I also want to thank Linus Neumann for organizing that 345 00:29:50,490 --> 00:29:59,790 communication with Sigfox. Now when I talked to Mr. Lehmann from Sigfox Germany 346 00:29:59,790 --> 00:30:04,240 essentially I told him that there were these weak spots, these substantial weak 347 00:30:04,240 --> 00:30:09,309 spots but we didn't find any major issues, and what he said then was that Sigfox is 348 00:30:09,309 --> 00:30:13,640 planning to open source their device library and I really hope that they carry 349 00:30:13,640 --> 00:30:18,260 through with this, because if they do that, that to me would signal that Sigfox 350 00:30:18,260 --> 00:30:24,330 is a company that really cares about security. Now if you want to find more, if 351 00:30:24,330 --> 00:30:29,520 you want to find out more about Sigfox and you don't want to wait for Sigfox to 352 00:30:29,520 --> 00:30:34,960 release their device library you can just go to this website here and download my 353 00:30:34,960 --> 00:30:39,210 open source library instead. I'm also going to publish these protocol 354 00:30:39,210 --> 00:30:42,960 specifications and the reference implantation is for software defined 355 00:30:42,960 --> 00:30:48,070 radio. If you have any questions you can contact me by email. You can also call me 356 00:30:48,070 --> 00:30:53,530 on my DECT phone here during conference and of course here's my Sigfox device ID 357 00:30:53,530 --> 00:30:58,340 and my Sigfox secret key, so just send me a Sigfox uplink. Thank you. 358 00:30:58,340 --> 00:31:11,040 *applause* Herald: Thank you Florian for this amazing 359 00:31:11,040 --> 00:31:18,810 talk, and now we have time for some questions. There's I think a lot of 360 00:31:18,810 --> 00:31:24,300 microhones all around, so please line up on the microphones if you want to ask a 361 00:31:24,300 --> 00:31:31,409 question, and especially two tips for that: First a question is in general just 362 00:31:31,409 --> 00:31:38,540 one sentence long. Second if you want us to hear you you have to speak into the mic 363 00:31:38,540 --> 00:31:48,070 so get close to the mic, it doesn't bite back. So I think we have somebody on the 364 00:31:48,070 --> 00:31:54,300 mic there in the back. Yes that's mic, number I can't read that from here, I'm too old 365 00:31:54,300 --> 00:31:59,220 for that shit. Eight. Okay thanks. Number eight you start. 366 00:31:59,220 --> 00:32:08,120 Q: So Hi, is this on, yeah, so you said scrambling didn't provide any 367 00:32:08,120 --> 00:32:14,330 confidentiality, so what is it for? A: It might be for, just for receiver 368 00:32:14,330 --> 00:32:19,310 synchronization because it facilitates receiver synchronization. I'm not sure 369 00:32:19,310 --> 00:32:22,710 what what it's for. Now the scrambling algorithm, it's not a very standard 370 00:32:22,710 --> 00:32:28,280 algorithm. So this is why I'm not really sure what it's good for. If it was a very 371 00:32:28,280 --> 00:32:32,529 standard algorithm I would think that it's just for receiver synchronization but 372 00:32:32,529 --> 00:32:38,650 that's not the case. So maybe it's some kind of security by obscurity but I'm not 373 00:32:38,650 --> 00:32:45,529 sure I can tell you. Herald: OK now we shift over there to the 374 00:32:45,529 --> 00:32:55,649 mic, yes you exactly in the white shirt. This was the mic. Okay, then I was then I 375 00:32:55,649 --> 00:32:59,929 want to go to 7 sorry, the numbers are too far away. It's just such such a big room, 376 00:32:59,929 --> 00:33:06,159 number seven please. Q: Hi. Thanks for the talk. My question is 377 00:33:06,159 --> 00:33:12,840 what is the reason you cannot disclose the scrambling algoritm? 378 00:33:12,840 --> 00:33:17,460 A: I could disclose thie scrambling algorithm but I have decided not to. So 379 00:33:17,460 --> 00:33:21,919 there is no one forcing me to do this, it's just based on the legal advice that I 380 00:33:21,919 --> 00:33:27,230 have received, but I am going to publish scrambled and unscrambled versions of 381 00:33:27,230 --> 00:33:31,559 Sigfox downlinks so I cannot stop you from reverse engineering this algorithm 382 00:33:31,559 --> 00:33:36,050 yourself. Thank you. Herald: OK, now we take a question from 383 00:33:36,050 --> 00:33:41,789 the Internet. Q: Yes, so one of the IRC users asks: Do 384 00:33:41,789 --> 00:33:46,720 you think that it is possible to run your own base stations in the future or will 385 00:33:46,720 --> 00:33:52,179 they always be run by Sigfox? A: Absolutely. It's just a matter of 386 00:33:52,179 --> 00:33:56,201 intellectual property and whether that's legal or not, I think they do have some 387 00:33:56,201 --> 00:34:01,290 patents on their technology, but there's nothing stopping you from running your own 388 00:34:01,290 --> 00:34:05,760 base station. So you will have to have a separate network from Sigfox with your own 389 00:34:05,760 --> 00:34:09,269 secret keys, you you cannot get the secret, well you could extract them from 390 00:34:09,269 --> 00:34:13,550 the devices but you cannot get the secret keys of all devices from Sigfox but of 391 00:34:13,550 --> 00:34:19,759 course you could run your own parallel Sigfox network. 392 00:34:19,759 --> 00:34:26,250 H: OK. Mike. Number eight again. Thanks for the talk. I have a student who wants 393 00:34:26,250 --> 00:34:32,899 to fuzz LoRaWAN. You mentioned a few times you fuzzed the uplink. Did you use 394 00:34:32,899 --> 00:34:40,540 the ACR implementation for sending as well or did you figure out how to manipulate 395 00:34:40,540 --> 00:34:47,790 one of the existing radio transceivers. A: I did manipulate the PI comp sci pi but 396 00:34:47,790 --> 00:34:52,399 I didn't use that to fuzz the uplink so I used the SDR implementation to fuzz the 397 00:34:52,399 --> 00:34:57,830 uplink. Herald: Okay. Sing a number 7. There's 398 00:34:57,830 --> 00:35:00,830 another question. Q: Hi. Can you tell us what an agency is 399 00:35:00,830 --> 00:35:05,640 like on these networks. A: Didn't get that. Sorry. 400 00:35:05,640 --> 00:35:09,500 Q: Can you tell us what's the latency is like on those networks. 401 00:35:09,500 --> 00:35:15,600 A: The latency on these networks. (Q: Yes.) Well it's like you have to go to a 402 00:35:15,600 --> 00:35:19,880 website to to retrieve all of the information from that the Sigfox base 403 00:35:19,880 --> 00:35:25,720 Station has received. And I didn't really test this because theoretically you could 404 00:35:25,720 --> 00:35:33,910 also have some some API calls and have Sigfax automaticly transmit this API calls 405 00:35:33,910 --> 00:35:37,220 but I'd say it's in a matter of a couple of seconds. 406 00:35:37,220 --> 00:35:42,269 Like three seconds or so. I haven't tested it. 407 00:35:42,269 --> 00:35:47,470 Herald: Okay now I have to ask is there somebody on mic eight. One more. Yes yes. 408 00:35:47,470 --> 00:35:54,300 One more. Okay. Please. It's you. Q: Yeah. So is the sigfox algorithms all 409 00:35:54,300 --> 00:36:02,650 of these things are running on the companies provided chips or is there some software 410 00:36:02,650 --> 00:36:06,870 involved which could be potentially reverse engineered? 411 00:36:06,870 --> 00:36:11,270 A: So the software that is involved that could be reverse engineered is the client 412 00:36:11,270 --> 00:36:17,010 library. But this is already the part I am publishing now. Also there's a couple of 413 00:36:17,010 --> 00:36:23,250 more things that you can reverse engineer about this. I don't think you're going to 414 00:36:23,250 --> 00:36:30,360 be able to get a sigfox base station, they're probably not giving one to you. 415 00:36:30,360 --> 00:36:34,520 Herald: Okay. Yeah we have time for one more question. We take one from the 416 00:36:34,520 --> 00:36:40,380 Internet. Q: What are the advantages of Sigfox 417 00:36:40,380 --> 00:36:49,020 verses LoRaWAN. A: I think that sigFox is even more low 418 00:36:49,020 --> 00:36:55,480 power than LoRaWAN. There are also a couple of other advantage, but in general 419 00:36:55,480 --> 00:37:00,640 I think that it's good if we have two competing providers in the LP events space 420 00:37:00,640 --> 00:37:06,540 just to have some diversity. And yeah there are advantages to both of them. So 421 00:37:06,540 --> 00:37:10,770 but in general I think that that's greate too to have both of them around. But as I 422 00:37:10,770 --> 00:37:16,350 told you it's more low power. I also think that it's a bit more scalable and also 423 00:37:16,350 --> 00:37:22,630 from the perspective of someone that's trying to deploy a sigfox device fleet 424 00:37:22,630 --> 00:37:26,410 that you just have to take care of the devices you don't have to take care of the 425 00:37:26,410 --> 00:37:32,080 network. So that's another advantage. Herald: Okay. So as time's up thank you 426 00:37:32,080 --> 00:37:37,981 very much. And please another round of applause for this amazing talk Florian. 427 00:37:37,981 --> 00:37:40,855 *applause* 428 00:37:40,855 --> 00:37:46,457 *35c3 postroll music* 429 00:37:46,457 --> 00:38:03,000 subtitles created by c3subtitles.de in the year 2019. Join, and help us!