35C3 - Hunting the Sigfox: Wireless IoT Network Security

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!