Return to Video

35C3 - Hunting the Sigfox: Wireless IoT Network Security

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

more » « less
Video Language:
English
Duration:
38:03

English subtitles

Revisions Compare revisions