0:00:00.000,0:00:19.920
35c3 preroll music
0:00:19.920,0:00:25.900
Angel: I'm very happy to be allowed to[br]announce the following talk. Hunting the
0:00:25.900,0:00:34.730
Sigfox: Wireless IoT network security by[br]Florian. Some of you have might heard of
0:00:34.730,0:00:39.780
the work of Florian already, because[br]sometime ago there was an article on a
0:00:39.780,0:00:46.699
popular German website called "Furby from[br]hell" and somebody there hacked the Furby
0:00:46.699,0:00:51.030
and there was also a video where you could[br]see the debug output on the displays which
0:00:51.030,0:00:56.969
are the eyes of the Furby. It was a really[br]disturbing video and the guy who did this
0:00:56.969,0:01:08.360
is exactly Florian. applause Today he's[br]gonna talk about Sigfox which is not
0:01:08.360,0:01:15.110
another toy but a network technology for[br]IoT devices. And like it's always we see
0:01:15.110,0:01:22.030
IoT word the security issues. So let's[br]hear a talk about the Internet of shit by
0:01:22.030,0:01:26.160
Florian and welcome him with a big round[br]of applause.
0:01:26.160,0:01:33.720
applause[br]Thank you for that introduction. So this
0:01:33.720,0:01:37.990
talk will be targeted at the technical[br]audience which is the case here but you
0:01:37.990,0:01:42.790
don't have to be RF experts on the trip in[br]order to understand this. So I will start
0:01:42.790,0:01:48.000
by covering some basics of RF technology[br]and some basics about Sigfox. And just
0:01:48.000,0:01:52.540
after that I'll start talking about an[br]analysis of the Sigfox protocol and its
0:01:52.540,0:01:57.700
security. I'll mention the most important[br]thing first , which is that I didn't find
0:01:57.700,0:02:02.680
any serious vulnerabilities in the Sigfox[br]protocol. But there are substantial weak
0:02:02.680,0:02:06.500
spots and you should be aware of these if[br]you want to use Sigfox in your own
0:02:06.500,0:02:12.140
application. But let me introduce myself[br]first. I don't think there's a lot of
0:02:12.140,0:02:16.450
information you need to know about me, so[br]I figured I'd just show you this picture
0:02:16.450,0:02:20.659
here of me instead. I'm not showing you[br]this picture because I think I look so
0:02:20.659,0:02:27.379
fabulous but because I think that this cow[br]here in the background is amazing and this
0:02:27.379,0:02:32.459
is not just any cow. This is Alice. Alice[br]the cow. And as you can see she has a
0:02:32.459,0:02:38.359
great life, so she lives somewhere in the[br]mountains. And there's just one problem
0:02:38.359,0:02:45.950
with her. She likes to break out of her[br]collar - her collar now her farmer which
0:02:45.950,0:02:50.599
is called Bob doesn't like this very[br]much but he recently heard about something
0:02:50.599,0:02:57.739
called the IoT. And he thinks that the IoT[br]is going to solve all of his problems. So
0:02:57.739,0:03:02.889
he purchased this collar here for Alice.[br]So this collar does a couple of thing -
0:03:02.889,0:03:08.720
couple of things. First of all, it[br]determines Alice's position based on GPS
0:03:08.720,0:03:13.569
satellites. It also measures measures her[br]body temperature and then it transmits all
0:03:13.569,0:03:18.599
of this information to Bob. So that's what[br]he wants to do. There's just one obvious
0:03:18.599,0:03:25.140
problem: How do we even get this data from[br]Alice to Bob? Well, traditionally in the
0:03:25.140,0:03:30.390
IoT there have been two solutions that[br]have often been employed. One of them is
0:03:30.390,0:03:34.890
Wi-Fi and the other one is mobile[br]networks. Now Wi-Fi is not going to work
0:03:34.890,0:03:41.180
in this application. Here we cannot cover[br]the whole country site with Wi-Fi there's
0:03:41.180,0:03:46.549
just not enough range. Mobile networks,[br]they would theoretically work but they are
0:03:46.549,0:03:51.200
just really expensive and they need a lot[br]of power. So you have to change the
0:03:51.200,0:03:56.739
battery relatively often. Luckily, these[br]days there's a third option and it's
0:03:56.739,0:04:02.399
called the LPWan. And this is short for[br]Low Power Wide Area Network. And the
0:04:02.399,0:04:07.650
LPWan is great because it solves[br]all of these problems. Now, how is this
0:04:07.650,0:04:12.180
possible? Why might we just - might have[br]we just discovered the LPWan so recently,
0:04:12.180,0:04:17.249
why hasn't this been done before. What[br]kind of compromises do they make. And to
0:04:17.249,0:04:20.899
understand the compromises that LP[br]networks make we have to look at the
0:04:20.899,0:04:26.250
electromagnetic spectrum. So that's what[br]the electromagnetic spectrum of a Wi-Fi
0:04:26.250,0:04:31.480
signal looks like. You can see that Wi-Fi[br]is fairly wide band and you have these
0:04:31.480,0:04:36.690
tiny ripples on top of the signal that is[br]noise and we don't like this noise. In
0:04:36.690,0:04:41.411
order to find the power that's contained[br]in one of these Wi-Fi transmissions, we
0:04:41.411,0:04:45.820
have to look at the area underneath a[br]curve. So that's the power of the Wi-Fi
0:04:45.820,0:04:54.690
signal. It's typically 20 MHz, that's the[br]bandwidth of Wi-Fi, and this red rectangle
0:04:54.690,0:04:59.580
on on top of the signal, this is the noise[br]and we don't want this. Now what
0:04:59.580,0:05:03.850
determines the range is not the absolute[br]value of the noise but the relative value
0:05:03.850,0:05:08.950
of the noise compared to the single power.[br]And this root ratio is called the signal
0:05:08.950,0:05:14.500
to noise ratio or SNR for short. Now if[br]you look at the blue and the red square
0:05:14.500,0:05:18.750
you can see that the red square is very[br]big compared to the blue square, which
0:05:18.750,0:05:24.560
means that our signal to noise ratio is[br]really bad. Now the solution to this is
0:05:24.560,0:05:28.950
kind of obvious once you know it: You just[br]concentrate this whole signal power in a
0:05:28.950,0:05:35.260
very narrow frequency range. Now this way,[br]you just have this tiny little ripple on
0:05:35.260,0:05:39.710
top of the signal and that's all your[br]noise. So now your signal to noise ratio
0:05:39.710,0:05:44.060
is a lot better. And this focusing of the[br]complete signal power in a very near
0:05:44.060,0:05:48.960
frequency range that's called ultra[br]narrowband technology and Sigfox is one of
0:05:48.960,0:05:55.620
these ultra narrowband technologies. Now[br]you might wonder why don't we do this with
0:05:55.620,0:06:00.060
Wi-Fi as well. If the solution is so[br]simple why don't we always concentrate the
0:06:00.060,0:06:04.050
complete signal power in a very narrow[br]frequency range. And the answer's kind of
0:06:04.050,0:06:08.460
obvious. You can see it already. It's that[br]bandwidth is proportional to data rate.
0:06:08.460,0:06:11.770
When I'm saying that is obvious, that's[br]because it's sort of ingrained in our
0:06:11.770,0:06:16.420
language. So when I tell you that I have[br]broadband internet you think that my
0:06:16.420,0:06:20.770
internet is fast. You don't think that my[br]internet uses a lot of frequency real
0:06:20.770,0:06:25.870
estate. On the other hand if I tell you[br]that Sigfox is an ultra narrowband
0:06:25.870,0:06:30.930
technology, you have to think Sigfox is[br]slow. And when I'm slow - things slow here
0:06:30.930,0:06:35.720
- it's not just a bit slow but extremely[br]slow. So here on the right you can see a
0:06:35.720,0:06:40.610
comparison between Sigfox and its very[br]fastest configuration and the 56k dial
0:06:40.610,0:06:49.440
up modem. Now this means that we can only[br]transmit 140 uplinks per day and then
0:06:49.440,0:06:53.640
uplink can contain up to 12 bytes so[br]uplink would be from Alice's collar to the
0:06:53.640,0:06:59.680
Sigfox base station to Bob and we can only[br]receive four downings per day and they are
0:06:59.680,0:07:04.280
not big either they are just 8 bytes. So[br]what I'm saying here is that you can
0:07:04.280,0:07:09.380
forget everything you happen to know about[br]Internet protocol so there's no IP,
0:07:09.380,0:07:13.020
there's no DNS, there's no HDTV or[br]anything like that. Sigfox is a completely
0:07:13.020,0:07:18.750
separate protocol. Now even more than[br]that, there's not even any signaling or
0:07:18.750,0:07:24.031
connection establishment. So when a Sigfox[br]device wants to transmit something, it's
0:07:24.031,0:07:28.610
just - it's just transmittes it's just[br]broadcasting. So Sigfox device just sleeps
0:07:28.610,0:07:34.520
all day long until some interrupt occurs[br]like some some timer overflows or some
0:07:34.520,0:07:40.280
button is pressed and then it broadcasts[br]the information it has gathered. Sigfox
0:07:40.280,0:07:43.990
base stations may pick it up or not, and[br]if they do, they just forward this
0:07:43.990,0:07:47.880
information to Sigfox cloud. So we just[br]have to look at one uplink transmission
0:07:47.880,0:07:54.240
and there's no, no long protocol on top of[br]that. Now that's cool and this only works
0:07:54.240,0:07:57.200
if there's one device you may think. So[br]how is this possible if you don't just
0:07:57.200,0:08:03.090
have one device but like ten devices or or[br]hundreds or thousands of devices. How can
0:08:03.090,0:08:06.980
we make sure that these uplink[br]transmissions don't collide. And the
0:08:06.980,0:08:11.210
reality is that these uplink transmissions[br]may actually collide. Again we have to
0:08:11.210,0:08:16.450
look at the radio spectrum to understand[br]this - the sort of frequency multiplex our
0:08:16.450,0:08:22.090
uplink. So this this is frequency and[br]time division multiple access. So you have
0:08:22.090,0:08:26.480
Sigfox uplink at different frequencies at[br]the same time and whenever a Sigfox device
0:08:26.480,0:08:30.320
wants to transmit an uplink, it first[br]chooses a frequency to transmit at
0:08:30.320,0:08:35.010
randomly. And the likelihood of two of[br]these very narrow band signals colliding
0:08:35.010,0:08:41.570
is just extremely slim. Now all of these[br]peaks you can see in this diagram, are not
0:08:41.570,0:08:46.770
all cows. There are also a bunch[br]of other Sigfox devices. And for instance
0:08:46.770,0:08:52.210
Sigfox is also used in areas like smart[br]homes, MARK metering, smart city, the
0:08:52.210,0:08:58.110
agriculture industry 4.0. So essentially[br]we have the full range of buzzwords and
0:08:58.110,0:09:02.940
this probably helps Sigfox raise 250[br]million euros during the last couple of
0:09:02.940,0:09:07.240
years. And with all of that money they[br]already got pretty decent coverage, as you
0:09:07.240,0:09:12.400
can see in the coverage map on the left.[br]Now one thing that's cool about Sigfox is
0:09:12.400,0:09:17.970
that they use the unlicensed spectrum in[br]Europe. That's at 868 MHz. This is cool
0:09:17.970,0:09:24.240
because it's free to use so Sigfox is[br]extremely cheap. Now just the downside of
0:09:24.240,0:09:29.210
Sigfox is that Sigfox is completely[br]proprietary so we cannot verify whether
0:09:29.210,0:09:32.180
it's secure or not. And this is the part[br]I'm trying to change with this
0:09:32.180,0:09:36.990
presentation here. And look at a security[br]of the Sigfox protocol and see if it's if
0:09:36.990,0:09:42.110
it's any good. I'll say Sigfox is not the[br]only LP of technology. There are a bunch
0:09:42.110,0:09:48.120
of others. So here are a couple of names[br]but to be honest I'd say that these three
0:09:48.120,0:09:55.260
here are the ones you should remember. So[br]that's all I have to say about the Sigfox.
0:09:55.260,0:10:00.400
Sigfox technology and Sigfox basics. Let's[br]just do a quick refresher of RF basics
0:10:00.400,0:10:04.070
first. So this is going to be extremely[br]short and many of you are going to know
0:10:04.070,0:10:08.940
this already. So the basic idea is that I[br]want to transmit some information
0:10:08.940,0:10:15.550
wirelessly and to do this I have to emit[br]an electromagnetic wave. So this is what
0:10:15.550,0:10:20.080
an EM wave looks like. As you can see[br]there's no information on there. We have
0:10:20.080,0:10:24.890
to put some information on there somehow[br]and this process is called modulation.
0:10:24.890,0:10:28.820
There are different ways to modulate a[br]radio wave. And one of them is phase
0:10:28.820,0:10:35.050
modulation. This means that in this case[br]here whenever the phase changes by 180
0:10:35.050,0:10:40.460
degrees that's the one when if phase is[br]changed and stays the same. That's zero.
0:10:40.460,0:10:44.330
So this is a special kind of phase[br]modulation that Sigfox uses. So you can
0:10:44.330,0:10:49.760
see these knees in the sine wave. Now this[br]is not the only modulation technique.
0:10:49.760,0:10:55.240
There's also frequency modulation. You[br]probably know this from your car radio for
0:10:55.240,0:11:01.510
instance. So this is frequency modulation[br]- frequency modulation just means that
0:11:01.510,0:11:05.210
whenever the frequency is a bit higher[br]then that's the one. And when the
0:11:05.210,0:11:08.910
frequency is a bit lower that's a zero.[br]Like your car radio uses the analog
0:11:08.910,0:11:12.170
version of this but this just frequency[br]shift keying which is a very similar
0:11:12.170,0:11:18.240
technique. Let's actually get started with[br]the Sigfox uplink. At this point I want to
0:11:18.240,0:11:23.830
thank Paul Pino. He did some really[br]amazing reverse engineering work of some
0:11:23.830,0:11:27.570
basic reverse engineering work of the[br]Sigfox protocol and published it on his
0:11:27.570,0:11:33.200
blog. And this really helped me get[br]started with my own analysis. So to
0:11:33.200,0:11:37.980
analyze the Sigfox protocol myself, I[br]first wanted to record one of these uplink
0:11:37.980,0:11:44.260
frames. So I got two Sigfox devices, one[br]of them is the pycom SiPy and the other
0:11:44.260,0:11:49.250
one is a development kit by FC micro[br]electronics. And I also had a software
0:11:49.250,0:11:53.930
defined radio so for those of you who[br]don't know a software defined radio or as
0:11:53.930,0:11:59.319
SDR for short is just a device that's[br]pretty much a microphone but not for
0:11:59.319,0:12:03.810
sound, for sound waves, but for[br]electromagnetic waves. So we can use this
0:12:03.810,0:12:09.280
to record electromagnetic waves into[br]something that's very similar to a sound
0:12:09.280,0:12:14.560
file. And I just want you to listen to one[br]of these sound files first and I want you
0:12:14.560,0:12:19.029
to know that this is going to be in real[br]time. And it's also just one piece of
0:12:19.029,0:12:22.730
information that I'm transmitting, so this[br]is not a couple of transmissions but just
0:12:22.730,0:12:34.649
one transmission. The interesting part[br]here is that even though I was just
0:12:34.649,0:12:39.920
transmitting one piece of information, we[br]have three uplinks at different
0:12:39.920,0:12:45.240
frequencies apparently. Now I wanted to[br]find out what's the relationship between
0:12:45.240,0:12:50.440
these these different Sigfox uplinks and[br]to find this out I had to demodulate it,
0:12:50.440,0:12:56.920
so demodulation means that I know that Fox[br]uplink uses D-BPSK, thats differential
0:12:56.920,0:13:00.230
binary phase shift keying, which is a[br]special kind of the phase modulation I've
0:13:00.230,0:13:05.670
been talking about and using this[br]information I can write a demodulator
0:13:05.670,0:13:11.190
software and this outputs a hexadecimal[br]representation of the Sigfox uplink; so
0:13:11.190,0:13:15.420
just binary representation. And that's[br]what it looks like. So I've colored these
0:13:15.420,0:13:20.759
three uplink frames in different colors so[br]that you can distinguish them. Now let's
0:13:20.759,0:13:26.310
have a close look at these and see what[br]they have in common. So the one thing they
0:13:26.310,0:13:31.440
have in common is this preamble here but[br]everything else appears to be completely
0:13:31.440,0:13:37.700
uncorrelated. That's what I thought at[br]first, but eventually it turned out that
0:13:37.700,0:13:42.300
this is convolution or coding. I guess if[br]you're a coding person it's enough for me
0:13:42.300,0:13:46.950
to tell you that this is a (5,7)[br]convolutional code and if not you probably
0:13:46.950,0:13:51.480
don't know what these words even mean. So[br]this is a convolutional code. It just
0:13:51.480,0:13:56.000
means that I take this unencoded input,[br]which is the red frame, and feed it into
0:13:56.000,0:14:01.380
these schematic diagrams here which are[br]made up of shift registers and XOR
0:14:01.380,0:14:06.210
operations and out comes the encoded data.[br]That's that's all there is to have (5,7)
0:14:06.210,0:14:14.060
convolutional code. Now this means that[br]the first, second and third transmission
0:14:14.060,0:14:18.720
all contain the exact same information. So[br]why am I transmitting this information
0:14:18.720,0:14:26.990
three times? The technical term for this[br]is coding gain. So coding gain is just a
0:14:26.990,0:14:31.209
fancy way of saying that this helps us[br]correct bit errors or transmissions errors
0:14:31.209,0:14:36.839
if they happen to occur in the uplink[br]transmission. But to continue I just have
0:14:36.839,0:14:42.650
to focus on this initial transmission here[br]which is the one that's unencoded, and I
0:14:42.650,0:14:46.080
can just ignore the other ones because[br]they are just the same information anyway,
0:14:46.080,0:14:50.420
just encoded differently. So of course I[br]captured a couple of these first
0:14:50.420,0:14:55.560
transmissions just ignored the rest and[br]they were all with the same payload so
0:14:55.560,0:15:01.179
that I can find some similarities. Now[br]let's look at a bunch of these. So the
0:15:01.179,0:15:06.350
whole trick to analyzing these wireless[br]protocols is just to keep staring at these
0:15:06.350,0:15:12.089
hex dumps for a very long time until you[br]see some patterns. And I think you can
0:15:12.089,0:15:16.430
already spot some of them. So that's the[br]preamble, we already talked about that.
0:15:16.430,0:15:21.020
Then here we have some header. Then this[br]is a sequence number. This is especially
0:15:21.020,0:15:26.050
easy to spot because the number is[br]incremented after every transmission. Then
0:15:26.050,0:15:31.180
here that's the device ID. So this is a[br]unique identifier for every Sigfox device
0:15:31.180,0:15:35.029
which tells us that this uplink[br]transmission was from Alice and not from
0:15:35.029,0:15:40.580
some other cow or some other device, and[br]that is the payload. And as you can see
0:15:40.580,0:15:46.650
it's completely unencoded and unencrypted.[br]Now this may seem bad but it's not really
0:15:46.650,0:15:51.410
a problem in terms of security issues[br]because this is documented behavior. So
0:15:51.410,0:15:55.790
when you look at Sigfox security white[br]paper they say that data is conveyed over
0:15:55.790,0:16:00.491
the air without any encryption. So that's[br]strange, but it's not really really a
0:16:00.491,0:16:05.560
problem as long as it's documented. But[br]eventually after staring at these frames
0:16:05.560,0:16:10.940
for some more time I figured out this[br]frame structure here. So you don't have to
0:16:10.940,0:16:16.050
remember all of this. I'm going to publish[br]an 80 page document that contains all of
0:16:16.050,0:16:21.210
the boring protocol details and you can[br]read up what every flag bit means later
0:16:21.210,0:16:25.990
on. But for now I just want to focus on a[br]couple of things. First one to wrap this
0:16:25.990,0:16:31.200
up a bit. So whenever we receive an uplink[br]frame from Alice the cow this is
0:16:31.200,0:16:35.260
essentially what she's telling us. So most[br]importantly that's the payload. What she's
0:16:35.260,0:16:40.180
doing right now for instance. And then[br]there's also the device ID which tells us
0:16:40.180,0:16:46.810
that this is Alice. And there's also a[br]bunch of more information in there. Now
0:16:46.810,0:16:51.070
again I want to focus on two fields here[br]that are a bit more interesting. One of
0:16:51.070,0:16:57.769
them is the CRC and the other one is the[br]MAC. Now, CRC, if you're a coding person
0:16:57.769,0:17:03.220
again you probably know what to do with[br]this information here for everyone else
0:17:03.220,0:17:07.970
you might know this already, but this is[br]just the checksum so this helps us detect
0:17:07.970,0:17:12.420
bit errors in the uplink frame and correct[br]... not correct them, but to discard the
0:17:12.420,0:17:17.650
uplink frame in case these bit errors[br]occur. Now this here, the MAC is a bit
0:17:17.650,0:17:22.979
more interesting. So in this case MAC does[br]not stand for an Apple computer. It also
0:17:22.979,0:17:27.349
doesn't stand for a MAC address so it has[br]nothing to do with medium access control
0:17:27.349,0:17:33.230
or Ethernet or anything. It stands for[br]message authentication code. Now as the
0:17:33.230,0:17:38.070
name says a message authentication code is[br]for authenticity protection. So this is
0:17:38.070,0:17:42.460
something that's very similar to digital[br]signatures. So you might know digital
0:17:42.460,0:17:48.400
signatures just from PGP e-mails and so[br]on. But it doesn't use ... like PGP
0:17:48.400,0:17:54.950
e-mails use something like RSA so they[br]have an asymmetric scheme, whereas message
0:17:54.950,0:18:00.189
authentication codes they use a symmetric[br]encryption scheme like for instance AES.
0:18:00.189,0:18:04.179
Now this slide is not that important. The[br]only important part is that I wanted this
0:18:04.179,0:18:08.510
algorithm here. So I wanted the algorithm[br]that I can use to generate one of these
0:18:08.510,0:18:14.510
MACs. I already have the payload and all[br]of the message I'm transmitting. I didn't
0:18:14.510,0:18:21.360
have the key yet so I wanted the key. Now[br]at first I thought it was impossible to
0:18:21.360,0:18:26.340
get the key from a Sigfox device because[br]if you watch Sigfoxes YouTube video on
0:18:26.340,0:18:32.400
security, they say that the secret key is[br]stored in non accessible memory. So this
0:18:32.400,0:18:38.300
sounds secure right? But it turns out that[br]when I first got the pycom SiPy, this
0:18:38.300,0:18:42.740
development kit here, it wanted to update[br]the firmware and it didn't just update the
0:18:42.740,0:18:47.590
firmware, but this is a section of the[br]SiPys flash memory before the so-called
0:18:47.590,0:18:51.610
firmware update, and this is the same[br]section after the firmware update and it
0:18:51.610,0:18:55.230
totally provisioned the device ID, some[br]other code and that's the secret key.
0:18:55.230,0:18:59.150
applause[br]So the secret key is in plain text in
0:18:59.150,0:19:03.850
flash memory.[br]applause continues
0:19:03.850,0:19:09.170
You might say that's not really a problem[br]because you need physical access to this
0:19:09.170,0:19:15.350
device in order to to get the secret key.[br]But still I confronted Sigfox about this
0:19:15.350,0:19:21.740
issue and their response was that yeah[br]they do offer solutions where the secret
0:19:21.740,0:19:27.220
key is not stored in plain text but it[br]costs some money and many manufacturers
0:19:27.220,0:19:32.090
don't choose to use it. So pycom for[br]instance didn't have this secure element
0:19:32.090,0:19:38.790
chip. But at this point I had the key, So[br]just based on some educated guessing I was
0:19:38.790,0:19:44.089
able to find the algorithm that's used for[br]calculating the MAC, and many of you
0:19:44.089,0:19:48.410
probably know this already, so this is[br]CBC-MAC which is just a AES in chiper block
0:19:48.410,0:19:52.850
chaining mode, so can we can use the[br]structure to generate a MAC. The input to
0:19:52.850,0:19:57.990
this algorithm is not just the payload but[br]also some other information like the flag
0:19:57.990,0:20:02.740
bits, the sequence number, the device ID[br]and the payload of course. So yeah that's
0:20:02.740,0:20:07.980
that's how it should be. So let's look at[br]the security of the uplink. It looks
0:20:07.980,0:20:12.830
pretty good at this first glance. So they[br]use well-established algorithms like CBC-
0:20:12.830,0:20:18.419
MAC. So CBC-MAC is also used in Wi-Fi, so[br]it's tried and true. I didn't find any
0:20:18.419,0:20:22.640
obvious implementation flaws in the uplink[br]so I tried to fuzz the uplink but it
0:20:22.640,0:20:27.380
didn't get accepted. Now one problem is[br]that we don't have any payload
0:20:27.380,0:20:32.740
confidentiality, so this is documented but[br]still I wondered why would you design a
0:20:32.740,0:20:38.400
protocol in 2018 or a couple of years ago[br]without any encryption? And their response
0:20:38.400,0:20:44.250
was that they do offer an encrypted[br]solution, but of course it takes some
0:20:44.250,0:20:49.880
energy to calculate encryption and it[br]really matters if you're talking about
0:20:49.880,0:20:54.290
devices with tens of years of battery[br]life, than just performing this one
0:20:54.290,0:21:00.499
encryption can make a difference. Now this[br]is not a real problem in my opinion. I
0:21:00.499,0:21:04.790
think the real problem with the Sigfox[br]uplink are these two here. I think the MAC
0:21:04.790,0:21:09.440
is just way too short and the sequence[br]number is extremely short and this makes
0:21:09.440,0:21:14.470
brute force and replay attacks possible.[br]So let's look at the brute force attack
0:21:14.470,0:21:21.090
first and let's just look at the ideal[br]scenario. So this is an ideal world - just
0:21:21.090,0:21:25.490
Alice transmitting her uplink frame to the[br]Sigfox cloud. That's what we want. No
0:21:25.490,0:21:30.900
attacker here. Now when she's transmitting[br]this uplink frame she's also transmitting
0:21:30.900,0:21:36.530
a MAC and in a worst case scenario this[br]Mac is just 16 bits long. So if you do the
0:21:36.530,0:21:42.509
math, the number of possible values for[br]the MAC is very limited. So the idea would
0:21:42.509,0:21:47.260
be to just try one Mac after the other...[br]laughter
0:21:47.260,0:21:52.500
...that's brute-forcing, right. Now with[br]most protocols this is not very practical
0:21:52.500,0:21:57.799
because this takes a lot of time. Again[br]looking at the worst case scenario if we
0:21:57.799,0:22:03.330
do the math it's possible in just less[br]than four hours. So that's not great. And
0:22:03.330,0:22:08.260
remember in the beginning I told you[br]something about frequency Multiplexing and
0:22:08.260,0:22:13.600
these multiple uplinks that can coexist at[br]the same time, we can even do this for the
0:22:13.600,0:22:18.820
attack. We can just frequency multiplex[br]our attack and we can do this at not just
0:22:18.820,0:22:23.560
at four frequencies like it's shown here[br]but at 300 frequencies. And then we're not
0:22:23.560,0:22:27.460
talking about a couple of hours to try all[br]possible MACs, but it's a matter of
0:22:27.460,0:22:34.690
minutes so that sounds bad. So I[br]confronted Sigfox about this and their
0:22:34.690,0:22:39.220
response was that yes they are aware of[br]this issue but they have implemented some
0:22:39.220,0:22:43.880
kind of blacklist. Now I wasn't able to[br]confirm this information because I only
0:22:43.880,0:22:48.100
had development kits and they say that[br]development kits are exempt from this
0:22:48.100,0:22:53.850
regulation. Now, this is great if they[br]have implemented this blacklist, but on
0:22:53.850,0:22:57.130
the other hand this also means that now we[br]have a conflict between two security
0:22:57.130,0:23:00.960
goals. One of them is authenticity[br]protection and the other one is
0:23:00.960,0:23:04.809
availability. So you're not going to have[br]perfect availability if you're using
0:23:04.809,0:23:10.940
Sigfox. But on the other hand maybe if you[br]want perfect availability maybe you just
0:23:10.940,0:23:15.470
shouldn't use a wireless system in the[br]first place. Now, the other attack is the
0:23:15.470,0:23:20.549
replay attack. This just means that I[br]capture an uplink frame from Alice and at
0:23:20.549,0:23:25.720
some later point in time I just replay it[br]to the Sigfox base station and hope it
0:23:25.720,0:23:31.070
gets accepted. But usually it doesn't get[br]accepted because the sequence number is a
0:23:31.070,0:23:36.090
replay protection. But again in the case[br]of Sigfox the sequence number is very
0:23:36.090,0:23:41.010
short just 12 bits long. So it's going to[br]overflow eventually. And again looking at
0:23:41.010,0:23:46.590
the worst case scenario this is after less[br]than 30 days. I had to ask Sigfox about
0:23:46.590,0:23:50.750
this as well, and their response was that[br]if you choose their so-called encrypted
0:23:50.750,0:23:55.870
solution. So that was the one that also[br]does the payload encryption, then you're
0:23:55.870,0:24:01.179
going to have a 20 bit sequence number. So[br]you should probably use that if you if you
0:24:01.179,0:24:08.190
don't want to have replay attacks. So in[br]summary if all you want to do is create a
0:24:08.190,0:24:13.750
device that tracks cows you're probably[br]going to be fine with just normal Sigfox
0:24:13.750,0:24:17.890
without the encrypted solution and you[br]don't need perfect authenticity and no
0:24:17.890,0:24:22.940
perfect confidentiality protection. But on[br]the other hand if you have a money
0:24:22.940,0:24:28.550
transporter or a security system where you[br]need confidentiality or authenticity, then
0:24:28.550,0:24:33.299
you should probably think about using[br]Sigfox or implement your own checks or use
0:24:33.299,0:24:38.950
Sigfoxs encrypted solution. So that's all[br]for the uplink. Now, I'm just going to
0:24:38.950,0:24:43.150
quickly talk about the downlink. This is[br]going to be extremely short because the
0:24:43.150,0:24:49.550
downlink protocol is so much simpler. So I told[br]you that a Sigfox device sleeps all day. This
0:24:49.550,0:24:54.039
means that the Sigfox base station cannot[br]just transmit a downlink, but the Sigfox
0:24:54.039,0:24:58.200
device has to request it first. So it[br]sends an uplink that contains a downlink
0:24:58.200,0:25:04.150
request and the Sigfox base station, uhm[br]Sigfox cloud then decides which base
0:25:04.150,0:25:11.059
station is going to answer with a[br]downlink. Now, of course I want to record
0:25:11.059,0:25:16.470
one of these downlink transmissions so I[br]had to find a base station at some point a
0:25:16.470,0:25:20.040
friend of mine hinted me that there was[br]this omnidirectional antenna here on a
0:25:20.040,0:25:26.380
cell tower in Grafenberg. And it turns out[br]that this antenna was actually a Sigfox
0:25:26.380,0:25:31.580
base station. Now if you want to find your[br]own Sigfox base station you don't have to
0:25:31.580,0:25:35.309
go around hunting for omnidirectional[br]antennas on cell towers. You can just go
0:25:35.309,0:25:39.340
to the website of the Bundesnetzagentur.[br]And I figured out that whenever there is
0:25:39.340,0:25:43.429
something called a 'sonstige Funkanlage'[br]and it has these specific security
0:25:43.429,0:25:47.370
clearances, then that's Sigfox.[br]laughter
0:25:47.370,0:25:50.420
So here's another one.[br]applause
0:25:50.420,0:25:57.240
So let's just listen to one of these[br]downlinks.
0:25:57.240,0:26:01.720
short signal noise[br]Again that was in real time and it was
0:26:01.720,0:26:06.890
really short and it sounded differently.[br]This is because this is not phase
0:26:06.890,0:26:12.400
modulation but frequency modulation or in[br]this particular case GFSK that's Gaussian
0:26:12.400,0:26:15.970
Frequency Shifting Keying. Again I[br]demodulated this uplink er this downlink
0:26:15.970,0:26:20.720
frame that's what it looks like. I[br]captured a couple of these I looked at
0:26:20.720,0:26:27.510
them that's the preamble, that's a garbled[br]mess. So what could that be? I thought
0:26:27.510,0:26:32.250
that maybe suddenly they're using[br]encryption, or maybe some very smart error
0:26:32.250,0:26:36.490
correction code scheme, but it turns out[br]that it's something much simpler called
0:26:36.490,0:26:41.700
scrambling. So unfortunately I'm not going[br]to tell you the algorithm that's used for
0:26:41.700,0:26:45.760
scrambling here, but I can tell you that[br]the inputs to the scrambling algorithm is
0:26:45.760,0:26:52.059
just the sequence number and the device ID[br]of the corresponding uplink. So you can
0:26:52.059,0:26:55.750
totally reverse the scrambling or you can[br]even brute force it because these two
0:26:55.750,0:27:01.820
numbers are very finite. So scrambling[br]does not provide any confidentiality. I
0:27:01.820,0:27:05.299
can tell you what I figured out in the[br]end. So this is the complete frame
0:27:05.299,0:27:11.990
structure of the downlink it's static so[br]very simple, think that two fields here
0:27:11.990,0:27:16.900
are particularly interesting. One of them[br]is this one here so if you're a coding
0:27:16.900,0:27:22.070
person this is a BCH(15, 11, 1) code and[br]this is cool because this can correct
0:27:22.070,0:27:27.450
correct up to 8 bit errors in the downlink[br]frame and the other interesting thing of
0:27:27.450,0:27:31.490
course is this message authentication[br]code, so we also have authenticity
0:27:31.490,0:27:38.500
protection for the downlink. So in[br]summary, for the Sigfox downlink it looks
0:27:38.500,0:27:44.299
pretty secure, again, the only real[br]problem I found is that there's scrambling
0:27:44.299,0:27:49.780
but this scrambling doesn't provide any[br]confidentiality. But last week I figured
0:27:49.780,0:27:55.250
out that if you use, or, Paul Pinault[br]hinted me that if you use Sigfox's
0:27:55.250,0:27:59.750
encrypted solution he figured this out,[br]then you're also going to have an
0:27:59.750,0:28:03.909
encrypted downlink, so you should probably[br]use that. And this is also pretty much my
0:28:03.909,0:28:09.780
summary for you: If you are a device maker[br]and you want to build a Sigfox device and
0:28:09.780,0:28:15.410
add Sigfox connectivity to your device,[br]it's fine to use Sigfox but you should be
0:28:15.410,0:28:19.820
aware of the level of security it[br]provides, and most importantly this means
0:28:19.820,0:28:24.059
that if you need confidentiality and if[br]you need good authenticity protection you
0:28:24.059,0:28:29.030
should probably use Sigfox's encrypted[br]solution, and this means that you have to
0:28:29.030,0:28:34.039
buy one of the very few modems still that[br]support this encryption. This also kind of
0:28:34.039,0:28:41.030
puts some pressure on the manufacturers to[br]just start providing this modems and not
0:28:41.030,0:28:46.570
the old ones. Now if you don't buy a modem[br]with the encryption solution these are
0:28:46.570,0:28:51.549
your options: So you have to implement[br]encryption yourself if you need it. There is
0:28:51.549,0:28:56.870
some things you can do to improve the[br]authenticity protection that the Sigfox
0:28:56.870,0:29:02.700
uplink and downlink already provide, and[br]if you don't do that you're just going to
0:29:02.700,0:29:08.660
have to implement your own authenticity[br]checks. Now I want to thank a couple of
0:29:08.660,0:29:13.920
people most importantly that is Felix and[br]Marc and they didn't just help me with the
0:29:13.920,0:29:18.270
whole technical aspect of this[br]presentation here, but they also helped me
0:29:18.270,0:29:23.270
proofread the documentation I'm going to[br]publish soon and this presentation here. I
0:29:23.270,0:29:27.679
also want to thank Paul Pinault for[br]providing quite a lot of information and
0:29:27.679,0:29:31.919
you will see a link to his blog on the[br]website I'm going to show you in a second.
0:29:31.919,0:29:36.650
I also want to thank Mr. Lehmann from[br]Sigfox Germany. Even though there were
0:29:36.650,0:29:40.550
some screw ups in the communication with[br]Sigfox on our side. So none of that was
0:29:40.550,0:29:45.880
Sigfox's fault. He reacted really nicely[br]and handled it very nicely and responded
0:29:45.880,0:29:50.490
to all of our questions, And I also want[br]to thank Linus Neumann for organizing that
0:29:50.490,0:29:59.790
communication with Sigfox. Now when I[br]talked to Mr. Lehmann from Sigfox Germany
0:29:59.790,0:30:04.240
essentially I told him that there were[br]these weak spots, these substantial weak
0:30:04.240,0:30:09.309
spots but we didn't find any major issues,[br]and what he said then was that Sigfox is
0:30:09.309,0:30:13.640
planning to open source their device[br]library and I really hope that they carry
0:30:13.640,0:30:18.260
through with this, because if they do[br]that, that to me would signal that Sigfox
0:30:18.260,0:30:24.330
is a company that really cares about[br]security. Now if you want to find more, if
0:30:24.330,0:30:29.520
you want to find out more about Sigfox and[br]you don't want to wait for Sigfox to
0:30:29.520,0:30:34.960
release their device library you can just[br]go to this website here and download my
0:30:34.960,0:30:39.210
open source library instead. I'm also[br]going to publish these protocol
0:30:39.210,0:30:42.960
specifications and the reference[br]implantation is for software defined
0:30:42.960,0:30:48.070
radio. If you have any questions you can[br]contact me by email. You can also call me
0:30:48.070,0:30:53.530
on my DECT phone here during conference[br]and of course here's my Sigfox device ID
0:30:53.530,0:30:58.340
and my Sigfox secret key, so just send me[br]a Sigfox uplink. Thank you.
0:30:58.340,0:31:11.040
applause[br]Herald: Thank you Florian for this amazing
0:31:11.040,0:31:18.810
talk, and now we have time for some[br]questions. There's I think a lot of
0:31:18.810,0:31:24.300
microhones all around, so please line up[br]on the microphones if you want to ask a
0:31:24.300,0:31:31.409
question, and especially two tips for[br]that: First a question is in general just
0:31:31.409,0:31:38.540
one sentence long. Second if you want us[br]to hear you you have to speak into the mic
0:31:38.540,0:31:48.070
so get close to the mic, it doesn't bite[br]back. So I think we have somebody on the
0:31:48.070,0:31:54.300
mic there in the back. Yes that's mic, number[br]I can't read that from here, I'm too old
0:31:54.300,0:31:59.220
for that shit. Eight. Okay thanks. Number[br]eight you start.
0:31:59.220,0:32:08.120
Q: So Hi, is this on, yeah, so you said[br]scrambling didn't provide any
0:32:08.120,0:32:14.330
confidentiality, so what is it for?[br]A: It might be for, just for receiver
0:32:14.330,0:32:19.310
synchronization because it facilitates[br]receiver synchronization. I'm not sure
0:32:19.310,0:32:22.710
what what it's for. Now the scrambling[br]algorithm, it's not a very standard
0:32:22.710,0:32:28.280
algorithm. So this is why I'm not really[br]sure what it's good for. If it was a very
0:32:28.280,0:32:32.529
standard algorithm I would think that it's[br]just for receiver synchronization but
0:32:32.529,0:32:38.650
that's not the case. So maybe it's some[br]kind of security by obscurity but I'm not
0:32:38.650,0:32:45.529
sure I can tell you.[br]Herald: OK now we shift over there to the
0:32:45.529,0:32:55.649
mic, yes you exactly in the white shirt.[br]This was the mic. Okay, then I was then I
0:32:55.649,0:32:59.929
want to go to 7 sorry, the numbers are too[br]far away. It's just such such a big room,
0:32:59.929,0:33:06.159
number seven please.[br]Q: Hi. Thanks for the talk. My question is
0:33:06.159,0:33:12.840
what is the reason you cannot disclose the[br]scrambling algoritm?
0:33:12.840,0:33:17.460
A: I could disclose thie scrambling[br]algorithm but I have decided not to. So
0:33:17.460,0:33:21.919
there is no one forcing me to do this,[br]it's just based on the legal advice that I
0:33:21.919,0:33:27.230
have received, but I am going to publish[br]scrambled and unscrambled versions of
0:33:27.230,0:33:31.559
Sigfox downlinks so I cannot stop you from[br]reverse engineering this algorithm
0:33:31.559,0:33:36.050
yourself. Thank you.[br]Herald: OK, now we take a question from
0:33:36.050,0:33:41.789
the Internet.[br]Q: Yes, so one of the IRC users asks: Do
0:33:41.789,0:33:46.720
you think that it is possible to run your[br]own base stations in the future or will
0:33:46.720,0:33:52.179
they always be run by Sigfox?[br]A: Absolutely. It's just a matter of
0:33:52.179,0:33:56.201
intellectual property and whether that's[br]legal or not, I think they do have some
0:33:56.201,0:34:01.290
patents on their technology, but there's[br]nothing stopping you from running your own
0:34:01.290,0:34:05.760
base station. So you will have to have a[br]separate network from Sigfox with your own
0:34:05.760,0:34:09.269
secret keys, you you cannot get the[br]secret, well you could extract them from
0:34:09.269,0:34:13.550
the devices but you cannot get the secret[br]keys of all devices from Sigfox but of
0:34:13.550,0:34:19.759
course you could run your own parallel[br]Sigfox network.
0:34:19.759,0:34:26.250
H: OK. Mike. Number eight again. Thanks[br]for the talk. I have a student who wants
0:34:26.250,0:34:32.899
to fuzz LoRaWAN. You mentioned a few[br]times you fuzzed the uplink. Did you use
0:34:32.899,0:34:40.540
the ACR implementation for sending as well[br]or did you figure out how to manipulate
0:34:40.540,0:34:47.790
one of the existing radio transceivers.[br]A: I did manipulate the PI comp sci pi but
0:34:47.790,0:34:52.399
I didn't use that to fuzz the uplink so I[br]used the SDR implementation to fuzz the
0:34:52.399,0:34:57.830
uplink.[br]Herald: Okay. Sing a number 7. There's
0:34:57.830,0:35:00.830
another question.[br]Q: Hi. Can you tell us what an agency is
0:35:00.830,0:35:05.640
like on these networks.[br]A: Didn't get that. Sorry.
0:35:05.640,0:35:09.500
Q: Can you tell us what's the latency is[br]like on those networks.
0:35:09.500,0:35:15.600
A: The latency on these networks. (Q:[br]Yes.) Well it's like you have to go to a
0:35:15.600,0:35:19.880
website to to retrieve all of the[br]information from that the Sigfox base
0:35:19.880,0:35:25.720
Station has received. And I didn't really[br]test this because theoretically you could
0:35:25.720,0:35:33.910
also have some some API calls and have[br]Sigfax automaticly transmit this API calls
0:35:33.910,0:35:37.220
but I'd say it's in a matter of a couple[br]of seconds.
0:35:37.220,0:35:42.269
Like three seconds or so. I haven't tested[br]it.
0:35:42.269,0:35:47.470
Herald: Okay now I have to ask is there[br]somebody on mic eight. One more. Yes yes.
0:35:47.470,0:35:54.300
One more. Okay. Please. It's you.[br]Q: Yeah. So is the sigfox algorithms all
0:35:54.300,0:36:02.650
of these things are running on the companies[br]provided chips or is there some software
0:36:02.650,0:36:06.870
involved which could be potentially[br]reverse engineered?
0:36:06.870,0:36:11.270
A: So the software that is involved that[br]could be reverse engineered is the client
0:36:11.270,0:36:17.010
library. But this is already the part I am[br]publishing now. Also there's a couple of
0:36:17.010,0:36:23.250
more things that you can reverse engineer[br]about this. I don't think you're going to
0:36:23.250,0:36:30.360
be able to get a sigfox base station,[br]they're probably not giving one to you.
0:36:30.360,0:36:34.520
Herald: Okay. Yeah we have time for one[br]more question. We take one from the
0:36:34.520,0:36:40.380
Internet.[br]Q: What are the advantages of Sigfox
0:36:40.380,0:36:49.020
verses LoRaWAN.[br]A: I think that sigFox is even more low
0:36:49.020,0:36:55.480
power than LoRaWAN. There are also a[br]couple of other advantage, but in general
0:36:55.480,0:37:00.640
I think that it's good if we have two[br]competing providers in the LP events space
0:37:00.640,0:37:06.540
just to have some diversity. And yeah[br]there are advantages to both of them. So
0:37:06.540,0:37:10.770
but in general I think that that's greate[br]too to have both of them around. But as I
0:37:10.770,0:37:16.350
told you it's more low power. I also think[br]that it's a bit more scalable and also
0:37:16.350,0:37:22.630
from the perspective of someone that's[br]trying to deploy a sigfox device fleet
0:37:22.630,0:37:26.410
that you just have to take care of the[br]devices you don't have to take care of the
0:37:26.410,0:37:32.080
network. So that's another advantage.[br]Herald: Okay. So as time's up thank you
0:37:32.080,0:37:37.981
very much. And please another round of[br]applause for this amazing talk Florian.
0:37:37.981,0:37:40.855
applause
0:37:40.855,0:37:46.457
35c3 postroll music
0:37:46.457,0:38:03.000
subtitles created by c3subtitles.de[br]in the year 2019. Join, and help us!