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