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!