35c3 preroll music
Angel: I'm very happy to be allowed to
announce the following talk. Hunting the
Sigfox: Wireless IoT network security by
Florian. Some of you have might heard of
the work of Florian already, because
sometime ago there was an article on a
popular German website called "Furby from
hell" and somebody there hacked the Furby
and there was also a video where you could
see the debug output on the displays which
are the eyes of the Furby. It was a really
disturbing video and the guy who did this
is exactly Florian. applause Today he's
gonna talk about Sigfox which is not
another toy but a network technology for
IoT devices. And like it's always we see
IoT word the security issues. So let's
hear a talk about the Internet of shit by
Florian and welcome him with a big round
of applause.
applause
Thank you for that introduction. So this
talk will be targeted at the technical
audience which is the case here but you
don't have to be RF experts on the trip in
order to understand this. So I will start
by covering some basics of RF technology
and some basics about Sigfox. And just
after that I'll start talking about an
analysis of the Sigfox protocol and its
security. I'll mention the most important
thing first , which is that I didn't find
any serious vulnerabilities in the Sigfox
protocol. But there are substantial weak
spots and you should be aware of these if
you want to use Sigfox in your own
application. But let me introduce myself
first. I don't think there's a lot of
information you need to know about me, so
I figured I'd just show you this picture
here of me instead. I'm not showing you
this picture because I think I look so
fabulous but because I think that this cow
here in the background is amazing and this
is not just any cow. This is Alice. Alice
the cow. And as you can see she has a
great life, so she lives somewhere in the
mountains. And there's just one problem
with her. She likes to break out of her
collar - her collar now her farmer which
is called Bob doesn't like this very
much but he recently heard about something
called the IoT. And he thinks that the IoT
is going to solve all of his problems. So
he purchased this collar here for Alice.
So this collar does a couple of thing -
couple of things. First of all, it
determines Alice's position based on GPS
satellites. It also measures measures her
body temperature and then it transmits all
of this information to Bob. So that's what
he wants to do. There's just one obvious
problem: How do we even get this data from
Alice to Bob? Well, traditionally in the
IoT there have been two solutions that
have often been employed. One of them is
Wi-Fi and the other one is mobile
networks. Now Wi-Fi is not going to work
in this application. Here we cannot cover
the whole country site with Wi-Fi there's
just not enough range. Mobile networks,
they would theoretically work but they are
just really expensive and they need a lot
of power. So you have to change the
battery relatively often. Luckily, these
days there's a third option and it's
called the LPWan. And this is short for
Low Power Wide Area Network. And the
LPWan is great because it solves
all of these problems. Now, how is this
possible? Why might we just - might have
we just discovered the LPWan so recently,
why hasn't this been done before. What
kind of compromises do they make. And to
understand the compromises that LP
networks make we have to look at the
electromagnetic spectrum. So that's what
the electromagnetic spectrum of a Wi-Fi
signal looks like. You can see that Wi-Fi
is fairly wide band and you have these
tiny ripples on top of the signal that is
noise and we don't like this noise. In
order to find the power that's contained
in one of these Wi-Fi transmissions, we
have to look at the area underneath a
curve. So that's the power of the Wi-Fi
signal. It's typically 20 MHz, that's the
bandwidth of Wi-Fi, and this red rectangle
on on top of the signal, this is the noise
and we don't want this. Now what
determines the range is not the absolute
value of the noise but the relative value
of the noise compared to the single power.
And this root ratio is called the signal
to noise ratio or SNR for short. Now if
you look at the blue and the red square
you can see that the red square is very
big compared to the blue square, which
means that our signal to noise ratio is
really bad. Now the solution to this is
kind of obvious once you know it: You just
concentrate this whole signal power in a
very narrow frequency range. Now this way,
you just have this tiny little ripple on
top of the signal and that's all your
noise. So now your signal to noise ratio
is a lot better. And this focusing of the
complete signal power in a very near
frequency range that's called ultra
narrowband technology and Sigfox is one of
these ultra narrowband technologies. Now
you might wonder why don't we do this with
Wi-Fi as well. If the solution is so
simple why don't we always concentrate the
complete signal power in a very narrow
frequency range. And the answer's kind of
obvious. You can see it already. It's that
bandwidth is proportional to data rate.
When I'm saying that is obvious, that's
because it's sort of ingrained in our
language. So when I tell you that I have
broadband internet you think that my
internet is fast. You don't think that my
internet uses a lot of frequency real
estate. On the other hand if I tell you
that Sigfox is an ultra narrowband
technology, you have to think Sigfox is
slow. And when I'm slow - things slow here
- it's not just a bit slow but extremely
slow. So here on the right you can see a
comparison between Sigfox and its very
fastest configuration and the 56k dial
up modem. Now this means that we can only
transmit 140 uplinks per day and then
uplink can contain up to 12 bytes so
uplink would be from Alice's collar to the
Sigfox base station to Bob and we can only
receive four downings per day and they are
not big either they are just 8 bytes. So
what I'm saying here is that you can
forget everything you happen to know about
Internet protocol so there's no IP,
there's no DNS, there's no HDTV or
anything like that. Sigfox is a completely
separate protocol. Now even more than
that, there's not even any signaling or
connection establishment. So when a Sigfox
device wants to transmit something, it's
just - it's just transmittes it's just
broadcasting. So Sigfox device just sleeps
all day long until some interrupt occurs
like some some timer overflows or some
button is pressed and then it broadcasts
the information it has gathered. Sigfox
base stations may pick it up or not, and
if they do, they just forward this
information to Sigfox cloud. So we just
have to look at one uplink transmission
and there's no, no long protocol on top of
that. Now that's cool and this only works
if there's one device you may think. So
how is this possible if you don't just
have one device but like ten devices or or
hundreds or thousands of devices. How can
we make sure that these uplink
transmissions don't collide. And the
reality is that these uplink transmissions
may actually collide. Again we have to
look at the radio spectrum to understand
this - the sort of frequency multiplex our
uplink. So this this is frequency and
time division multiple access. So you have
Sigfox uplink at different frequencies at
the same time and whenever a Sigfox device
wants to transmit an uplink, it first
chooses a frequency to transmit at
randomly. And the likelihood of two of
these very narrow band signals colliding
is just extremely slim. Now all of these
peaks you can see in this diagram, are not
all cows. There are also a bunch
of other Sigfox devices. And for instance
Sigfox is also used in areas like smart
homes, MARK metering, smart city, the
agriculture industry 4.0. So essentially
we have the full range of buzzwords and
this probably helps Sigfox raise 250
million euros during the last couple of
years. And with all of that money they
already got pretty decent coverage, as you
can see in the coverage map on the left.
Now one thing that's cool about Sigfox is
that they use the unlicensed spectrum in
Europe. That's at 868 MHz. This is cool
because it's free to use so Sigfox is
extremely cheap. Now just the downside of
Sigfox is that Sigfox is completely
proprietary so we cannot verify whether
it's secure or not. And this is the part
I'm trying to change with this
presentation here. And look at a security
of the Sigfox protocol and see if it's if
it's any good. I'll say Sigfox is not the
only LP of technology. There are a bunch
of others. So here are a couple of names
but to be honest I'd say that these three
here are the ones you should remember. So
that's all I have to say about the Sigfox.
Sigfox technology and Sigfox basics. Let's
just do a quick refresher of RF basics
first. So this is going to be extremely
short and many of you are going to know
this already. So the basic idea is that I
want to transmit some information
wirelessly and to do this I have to emit
an electromagnetic wave. So this is what
an EM wave looks like. As you can see
there's no information on there. We have
to put some information on there somehow
and this process is called modulation.
There are different ways to modulate a
radio wave. And one of them is phase
modulation. This means that in this case
here whenever the phase changes by 180
degrees that's the one when if phase is
changed and stays the same. That's zero.
So this is a special kind of phase
modulation that Sigfox uses. So you can
see these knees in the sine wave. Now this
is not the only modulation technique.
There's also frequency modulation. You
probably know this from your car radio for
instance. So this is frequency modulation
- frequency modulation just means that
whenever the frequency is a bit higher
then that's the one. And when the
frequency is a bit lower that's a zero.
Like your car radio uses the analog
version of this but this just frequency
shift keying which is a very similar
technique. Let's actually get started with
the Sigfox uplink. At this point I want to
thank Paul Pino. He did some really
amazing reverse engineering work of some
basic reverse engineering work of the
Sigfox protocol and published it on his
blog. And this really helped me get
started with my own analysis. So to
analyze the Sigfox protocol myself, I
first wanted to record one of these uplink
frames. So I got two Sigfox devices, one
of them is the pycom SiPy and the other
one is a development kit by FC micro
electronics. And I also had a software
defined radio so for those of you who
don't know a software defined radio or as
SDR for short is just a device that's
pretty much a microphone but not for
sound, for sound waves, but for
electromagnetic waves. So we can use this
to record electromagnetic waves into
something that's very similar to a sound
file. And I just want you to listen to one
of these sound files first and I want you
to know that this is going to be in real
time. And it's also just one piece of
information that I'm transmitting, so this
is not a couple of transmissions but just
one transmission. The interesting part
here is that even though I was just
transmitting one piece of information, we
have three uplinks at different
frequencies apparently. Now I wanted to
find out what's the relationship between
these these different Sigfox uplinks and
to find this out I had to demodulate it,
so demodulation means that I know that Fox
uplink uses D-BPSK, thats differential
binary phase shift keying, which is a
special kind of the phase modulation I've
been talking about and using this
information I can write a demodulator
software and this outputs a hexadecimal
representation of the Sigfox uplink; so
just binary representation. And that's
what it looks like. So I've colored these
three uplink frames in different colors so
that you can distinguish them. Now let's
have a close look at these and see what
they have in common. So the one thing they
have in common is this preamble here but
everything else appears to be completely
uncorrelated. That's what I thought at
first, but eventually it turned out that
this is convolution or coding. I guess if
you're a coding person it's enough for me
to tell you that this is a (5,7)
convolutional code and if not you probably
don't know what these words even mean. So
this is a convolutional code. It just
means that I take this unencoded input,
which is the red frame, and feed it into
these schematic diagrams here which are
made up of shift registers and XOR
operations and out comes the encoded data.
That's that's all there is to have (5,7)
convolutional code. Now this means that
the first, second and third transmission
all contain the exact same information. So
why am I transmitting this information
three times? The technical term for this
is coding gain. So coding gain is just a
fancy way of saying that this helps us
correct bit errors or transmissions errors
if they happen to occur in the uplink
transmission. But to continue I just have
to focus on this initial transmission here
which is the one that's unencoded, and I
can just ignore the other ones because
they are just the same information anyway,
just encoded differently. So of course I
captured a couple of these first
transmissions just ignored the rest and
they were all with the same payload so
that I can find some similarities. Now
let's look at a bunch of these. So the
whole trick to analyzing these wireless
protocols is just to keep staring at these
hex dumps for a very long time until you
see some patterns. And I think you can
already spot some of them. So that's the
preamble, we already talked about that.
Then here we have some header. Then this
is a sequence number. This is especially
easy to spot because the number is
incremented after every transmission. Then
here that's the device ID. So this is a
unique identifier for every Sigfox device
which tells us that this uplink
transmission was from Alice and not from
some other cow or some other device, and
that is the payload. And as you can see
it's completely unencoded and unencrypted.
Now this may seem bad but it's not really
a problem in terms of security issues
because this is documented behavior. So
when you look at Sigfox security white
paper they say that data is conveyed over
the air without any encryption. So that's
strange, but it's not really really a
problem as long as it's documented. But
eventually after staring at these frames
for some more time I figured out this
frame structure here. So you don't have to
remember all of this. I'm going to publish
an 80 page document that contains all of
the boring protocol details and you can
read up what every flag bit means later
on. But for now I just want to focus on a
couple of things. First one to wrap this
up a bit. So whenever we receive an uplink
frame from Alice the cow this is
essentially what she's telling us. So most
importantly that's the payload. What she's
doing right now for instance. And then
there's also the device ID which tells us
that this is Alice. And there's also a
bunch of more information in there. Now
again I want to focus on two fields here
that are a bit more interesting. One of
them is the CRC and the other one is the
MAC. Now, CRC, if you're a coding person
again you probably know what to do with
this information here for everyone else
you might know this already, but this is
just the checksum so this helps us detect
bit errors in the uplink frame and correct
... not correct them, but to discard the
uplink frame in case these bit errors
occur. Now this here, the MAC is a bit
more interesting. So in this case MAC does
not stand for an Apple computer. It also
doesn't stand for a MAC address so it has
nothing to do with medium access control
or Ethernet or anything. It stands for
message authentication code. Now as the
name says a message authentication code is
for authenticity protection. So this is
something that's very similar to digital
signatures. So you might know digital
signatures just from PGP e-mails and so
on. But it doesn't use ... like PGP
e-mails use something like RSA so they
have an asymmetric scheme, whereas message
authentication codes they use a symmetric
encryption scheme like for instance AES.
Now this slide is not that important. The
only important part is that I wanted this
algorithm here. So I wanted the algorithm
that I can use to generate one of these
MACs. I already have the payload and all
of the message I'm transmitting. I didn't
have the key yet so I wanted the key. Now
at first I thought it was impossible to
get the key from a Sigfox device because
if you watch Sigfoxes YouTube video on
security, they say that the secret key is
stored in non accessible memory. So this
sounds secure right? But it turns out that
when I first got the pycom SiPy, this
development kit here, it wanted to update
the firmware and it didn't just update the
firmware, but this is a section of the
SiPys flash memory before the so-called
firmware update, and this is the same
section after the firmware update and it
totally provisioned the device ID, some
other code and that's the secret key.
applause
So the secret key is in plain text in
flash memory.
applause continues
You might say that's not really a problem
because you need physical access to this
device in order to to get the secret key.
But still I confronted Sigfox about this
issue and their response was that yeah
they do offer solutions where the secret
key is not stored in plain text but it
costs some money and many manufacturers
don't choose to use it. So pycom for
instance didn't have this secure element
chip. But at this point I had the key, So
just based on some educated guessing I was
able to find the algorithm that's used for
calculating the MAC, and many of you
probably know this already, so this is
CBC-MAC which is just a AES in chiper block
chaining mode, so can we can use the
structure to generate a MAC. The input to
this algorithm is not just the payload but
also some other information like the flag
bits, the sequence number, the device ID
and the payload of course. So yeah that's
that's how it should be. So let's look at
the security of the uplink. It looks
pretty good at this first glance. So they
use well-established algorithms like CBC-
MAC. So CBC-MAC is also used in Wi-Fi, so
it's tried and true. I didn't find any
obvious implementation flaws in the uplink
so I tried to fuzz the uplink but it
didn't get accepted. Now one problem is
that we don't have any payload
confidentiality, so this is documented but
still I wondered why would you design a
protocol in 2018 or a couple of years ago
without any encryption? And their response
was that they do offer an encrypted
solution, but of course it takes some
energy to calculate encryption and it
really matters if you're talking about
devices with tens of years of battery
life, than just performing this one
encryption can make a difference. Now this
is not a real problem in my opinion. I
think the real problem with the Sigfox
uplink are these two here. I think the MAC
is just way too short and the sequence
number is extremely short and this makes
brute force and replay attacks possible.
So let's look at the brute force attack
first and let's just look at the ideal
scenario. So this is an ideal world - just
Alice transmitting her uplink frame to the
Sigfox cloud. That's what we want. No
attacker here. Now when she's transmitting
this uplink frame she's also transmitting
a MAC and in a worst case scenario this
Mac is just 16 bits long. So if you do the
math, the number of possible values for
the MAC is very limited. So the idea would
be to just try one Mac after the other...
laughter
...that's brute-forcing, right. Now with
most protocols this is not very practical
because this takes a lot of time. Again
looking at the worst case scenario if we
do the math it's possible in just less
than four hours. So that's not great. And
remember in the beginning I told you
something about frequency Multiplexing and
these multiple uplinks that can coexist at
the same time, we can even do this for the
attack. We can just frequency multiplex
our attack and we can do this at not just
at four frequencies like it's shown here
but at 300 frequencies. And then we're not
talking about a couple of hours to try all
possible MACs, but it's a matter of
minutes so that sounds bad. So I
confronted Sigfox about this and their
response was that yes they are aware of
this issue but they have implemented some
kind of blacklist. Now I wasn't able to
confirm this information because I only
had development kits and they say that
development kits are exempt from this
regulation. Now, this is great if they
have implemented this blacklist, but on
the other hand this also means that now we
have a conflict between two security
goals. One of them is authenticity
protection and the other one is
availability. So you're not going to have
perfect availability if you're using
Sigfox. But on the other hand maybe if you
want perfect availability maybe you just
shouldn't use a wireless system in the
first place. Now, the other attack is the
replay attack. This just means that I
capture an uplink frame from Alice and at
some later point in time I just replay it
to the Sigfox base station and hope it
gets accepted. But usually it doesn't get
accepted because the sequence number is a
replay protection. But again in the case
of Sigfox the sequence number is very
short just 12 bits long. So it's going to
overflow eventually. And again looking at
the worst case scenario this is after less
than 30 days. I had to ask Sigfox about
this as well, and their response was that
if you choose their so-called encrypted
solution. So that was the one that also
does the payload encryption, then you're
going to have a 20 bit sequence number. So
you should probably use that if you if you
don't want to have replay attacks. So in
summary if all you want to do is create a
device that tracks cows you're probably
going to be fine with just normal Sigfox
without the encrypted solution and you
don't need perfect authenticity and no
perfect confidentiality protection. But on
the other hand if you have a money
transporter or a security system where you
need confidentiality or authenticity, then
you should probably think about using
Sigfox or implement your own checks or use
Sigfoxs encrypted solution. So that's all
for the uplink. Now, I'm just going to
quickly talk about the downlink. This is
going to be extremely short because the
downlink protocol is so much simpler. So I told
you that a Sigfox device sleeps all day. This
means that the Sigfox base station cannot
just transmit a downlink, but the Sigfox
device has to request it first. So it
sends an uplink that contains a downlink
request and the Sigfox base station, uhm
Sigfox cloud then decides which base
station is going to answer with a
downlink. Now, of course I want to record
one of these downlink transmissions so I
had to find a base station at some point a
friend of mine hinted me that there was
this omnidirectional antenna here on a
cell tower in Grafenberg. And it turns out
that this antenna was actually a Sigfox
base station. Now if you want to find your
own Sigfox base station you don't have to
go around hunting for omnidirectional
antennas on cell towers. You can just go
to the website of the Bundesnetzagentur.
And I figured out that whenever there is
something called a 'sonstige Funkanlage'
and it has these specific security
clearances, then that's Sigfox.
laughter
So here's another one.
applause
So let's just listen to one of these
downlinks.
short signal noise
Again that was in real time and it was
really short and it sounded differently.
This is because this is not phase
modulation but frequency modulation or in
this particular case GFSK that's Gaussian
Frequency Shifting Keying. Again I
demodulated this uplink er this downlink
frame that's what it looks like. I
captured a couple of these I looked at
them that's the preamble, that's a garbled
mess. So what could that be? I thought
that maybe suddenly they're using
encryption, or maybe some very smart error
correction code scheme, but it turns out
that it's something much simpler called
scrambling. So unfortunately I'm not going
to tell you the algorithm that's used for
scrambling here, but I can tell you that
the inputs to the scrambling algorithm is
just the sequence number and the device ID
of the corresponding uplink. So you can
totally reverse the scrambling or you can
even brute force it because these two
numbers are very finite. So scrambling
does not provide any confidentiality. I
can tell you what I figured out in the
end. So this is the complete frame
structure of the downlink it's static so
very simple, think that two fields here
are particularly interesting. One of them
is this one here so if you're a coding
person this is a BCH(15, 11, 1) code and
this is cool because this can correct
correct up to 8 bit errors in the downlink
frame and the other interesting thing of
course is this message authentication
code, so we also have authenticity
protection for the downlink. So in
summary, for the Sigfox downlink it looks
pretty secure, again, the only real
problem I found is that there's scrambling
but this scrambling doesn't provide any
confidentiality. But last week I figured
out that if you use, or, Paul Pinault
hinted me that if you use Sigfox's
encrypted solution he figured this out,
then you're also going to have an
encrypted downlink, so you should probably
use that. And this is also pretty much my
summary for you: If you are a device maker
and you want to build a Sigfox device and
add Sigfox connectivity to your device,
it's fine to use Sigfox but you should be
aware of the level of security it
provides, and most importantly this means
that if you need confidentiality and if
you need good authenticity protection you
should probably use Sigfox's encrypted
solution, and this means that you have to
buy one of the very few modems still that
support this encryption. This also kind of
puts some pressure on the manufacturers to
just start providing this modems and not
the old ones. Now if you don't buy a modem
with the encryption solution these are
your options: So you have to implement
encryption yourself if you need it. There is
some things you can do to improve the
authenticity protection that the Sigfox
uplink and downlink already provide, and
if you don't do that you're just going to
have to implement your own authenticity
checks. Now I want to thank a couple of
people most importantly that is Felix and
Marc and they didn't just help me with the
whole technical aspect of this
presentation here, but they also helped me
proofread the documentation I'm going to
publish soon and this presentation here. I
also want to thank Paul Pinault for
providing quite a lot of information and
you will see a link to his blog on the
website I'm going to show you in a second.
I also want to thank Mr. Lehmann from
Sigfox Germany. Even though there were
some screw ups in the communication with
Sigfox on our side. So none of that was
Sigfox's fault. He reacted really nicely
and handled it very nicely and responded
to all of our questions, And I also want
to thank Linus Neumann for organizing that
communication with Sigfox. Now when I
talked to Mr. Lehmann from Sigfox Germany
essentially I told him that there were
these weak spots, these substantial weak
spots but we didn't find any major issues,
and what he said then was that Sigfox is
planning to open source their device
library and I really hope that they carry
through with this, because if they do
that, that to me would signal that Sigfox
is a company that really cares about
security. Now if you want to find more, if
you want to find out more about Sigfox and
you don't want to wait for Sigfox to
release their device library you can just
go to this website here and download my
open source library instead. I'm also
going to publish these protocol
specifications and the reference
implantation is for software defined
radio. If you have any questions you can
contact me by email. You can also call me
on my DECT phone here during conference
and of course here's my Sigfox device ID
and my Sigfox secret key, so just send me
a Sigfox uplink. Thank you.
applause
Herald: Thank you Florian for this amazing
talk, and now we have time for some
questions. There's I think a lot of
microhones all around, so please line up
on the microphones if you want to ask a
question, and especially two tips for
that: First a question is in general just
one sentence long. Second if you want us
to hear you you have to speak into the mic
so get close to the mic, it doesn't bite
back. So I think we have somebody on the
mic there in the back. Yes that's mic, number
I can't read that from here, I'm too old
for that shit. Eight. Okay thanks. Number
eight you start.
Q: So Hi, is this on, yeah, so you said
scrambling didn't provide any
confidentiality, so what is it for?
A: It might be for, just for receiver
synchronization because it facilitates
receiver synchronization. I'm not sure
what what it's for. Now the scrambling
algorithm, it's not a very standard
algorithm. So this is why I'm not really
sure what it's good for. If it was a very
standard algorithm I would think that it's
just for receiver synchronization but
that's not the case. So maybe it's some
kind of security by obscurity but I'm not
sure I can tell you.
Herald: OK now we shift over there to the
mic, yes you exactly in the white shirt.
This was the mic. Okay, then I was then I
want to go to 7 sorry, the numbers are too
far away. It's just such such a big room,
number seven please.
Q: Hi. Thanks for the talk. My question is
what is the reason you cannot disclose the
scrambling algoritm?
A: I could disclose thie scrambling
algorithm but I have decided not to. So
there is no one forcing me to do this,
it's just based on the legal advice that I
have received, but I am going to publish
scrambled and unscrambled versions of
Sigfox downlinks so I cannot stop you from
reverse engineering this algorithm
yourself. Thank you.
Herald: OK, now we take a question from
the Internet.
Q: Yes, so one of the IRC users asks: Do
you think that it is possible to run your
own base stations in the future or will
they always be run by Sigfox?
A: Absolutely. It's just a matter of
intellectual property and whether that's
legal or not, I think they do have some
patents on their technology, but there's
nothing stopping you from running your own
base station. So you will have to have a
separate network from Sigfox with your own
secret keys, you you cannot get the
secret, well you could extract them from
the devices but you cannot get the secret
keys of all devices from Sigfox but of
course you could run your own parallel
Sigfox network.
H: OK. Mike. Number eight again. Thanks
for the talk. I have a student who wants
to fuzz LoRaWAN. You mentioned a few
times you fuzzed the uplink. Did you use
the ACR implementation for sending as well
or did you figure out how to manipulate
one of the existing radio transceivers.
A: I did manipulate the PI comp sci pi but
I didn't use that to fuzz the uplink so I
used the SDR implementation to fuzz the
uplink.
Herald: Okay. Sing a number 7. There's
another question.
Q: Hi. Can you tell us what an agency is
like on these networks.
A: Didn't get that. Sorry.
Q: Can you tell us what's the latency is
like on those networks.
A: The latency on these networks. (Q:
Yes.) Well it's like you have to go to a
website to to retrieve all of the
information from that the Sigfox base
Station has received. And I didn't really
test this because theoretically you could
also have some some API calls and have
Sigfax automaticly transmit this API calls
but I'd say it's in a matter of a couple
of seconds.
Like three seconds or so. I haven't tested
it.
Herald: Okay now I have to ask is there
somebody on mic eight. One more. Yes yes.
One more. Okay. Please. It's you.
Q: Yeah. So is the sigfox algorithms all
of these things are running on the companies
provided chips or is there some software
involved which could be potentially
reverse engineered?
A: So the software that is involved that
could be reverse engineered is the client
library. But this is already the part I am
publishing now. Also there's a couple of
more things that you can reverse engineer
about this. I don't think you're going to
be able to get a sigfox base station,
they're probably not giving one to you.
Herald: Okay. Yeah we have time for one
more question. We take one from the
Internet.
Q: What are the advantages of Sigfox
verses LoRaWAN.
A: I think that sigFox is even more low
power than LoRaWAN. There are also a
couple of other advantage, but in general
I think that it's good if we have two
competing providers in the LP events space
just to have some diversity. And yeah
there are advantages to both of them. So
but in general I think that that's greate
too to have both of them around. But as I
told you it's more low power. I also think
that it's a bit more scalable and also
from the perspective of someone that's
trying to deploy a sigfox device fleet
that you just have to take care of the
devices you don't have to take care of the
network. So that's another advantage.
Herald: Okay. So as time's up thank you
very much. And please another round of
applause for this amazing talk Florian.
applause
35c3 postroll music
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!