*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!