A recent publication analyzed the Sigfox protocol security, This is the most advanced work I’ve seen on this so it is interesting to go to some details about it. The author is Loïc Ferreira working for Orange Labs, Applied Cryptography Group at Caen,France. This report has been shared with Sigfox by the Author on August 2020.

In this post, I’ll not challenge any of the outcomes from Loïc as it is a serious researcher. What I want to do is to highlight this with the ability for someone to use this to make a successful attack against a device and in what conditions.

I love to say, in the security domain, that sometime, IoT attacks are like explaining how to destroy earth and humanity by changing the course of the moon to make that one crashing on its target: Theoretically it is possible, technically we could find ways to make is possible for an extraordinary cost. Practically speaking, the one doing it will also kills itself, so there is no big gain to expect.

So, let’s take a look to the different breaches reported on the publication…

Frame replay

This, as indicated in the document, is a well known attack. It consists in capturing a Sigfox Frame (valid) and replay it later to be accepted by the backend. The frame is not modified. This type of attack already have multiple counter measures:

• The frame counter, prohibit a immediate reusing to the captured frame as the backend will trash the numbers in the past. So you need to wait for 4000+ transmissions to be able to use it. Usually Sigfox devices are transmitting about a message per hour, so half a year. This will be shorter with devices speaking more.
• The ability to capture a Sigfox frame is currently null with existing published code and technics over 50-100 meters (for real I never been able over 10 meters). On this point a solution can be published tomorrow or is already available on black market. So it is not a counter measure but just something interesting to know. There is no protection against capturing raw frames.
• The use of Sigfox encryption push the frame counter to 20bits (not really but it is like). As I did written two years ago when disclosing the sigfox encryption mechanisms anyone should implement Sigfox encryption and eventually use an end-to-end encryption on top of it.

The publication highlight short periods (1 month) for executing a successful attack. Theoretically it is possible due to the 140 messages a day authorized by the legal context. (It could be written 1 hours in an FCC environment as Sigfox do not practically limits to 140 message and FCC have no duty cycle + higher speed). So the reality of a such attack depends on the real number of messages sent per day per device ; your ability to capture the messages to determine the correct timing to send your attack ; the immobility of the device ; your ability to identify your target in the different messages you could receive… So it makes sense if you are in a lab or if you have a big money interest in doing it.

The Frame replay also concerns downlink frames ; in my point of view the functional impact is higher as the downlinks are mostly used for configuration and action taking. Replay is replay, so it means you can send a previous order (so applying a configuration already applied… re-execute an action). To make it working, you need to send your downlink in the right time, so previously capturing a frame with a downlink request, then transmitting it. You are in competition with the network potentially (not mandatory) so you need to be really near the targeted device. (The uplink attack can be performed far away from the device, not the downlink one).

There is another problem to solve: even if capturing a downlink is easy (the encoding is GFSK), decoders are easy to find and the signal is pushed by the base-station with high power. You can capture it some kilometers away from the device. You need to link captured downlink messages with the device you target. But the downlink does not contain the device identity neither the sequence ID to replay it at the right time… As a consequence, to find this, you need to analyses all the uplink communications, find the one happen in the previous 30 seconds, on the right frequency, decode it and check for the targeted ID you may have obtained from the field .. how ? is a good question if not printed on it (security basics.. do not print IDs on the devices…)

More over, even if downlink authorized per contract is a maximum of 4 per day, the implementation is totally different:

• 4 downlinks is the maximum number of backend to device communications contractually promised by the network. But practically you can do much more.
• Most of the devices are not implementing downlink… they are not concerned
• Most of the devices implementing downlink are using it once every 6 months, so it is really hard to capture one for replaying it.
• Usually devices are limiting downlinks because they are highly energy consuming.
• In another hand, some devices are using downlink intensively to receive on-request operations to do. Such device can request downlink on every 10 minutes. But usually only get a response on daily, weekly, monthly basis.

The downlink MAC is calculated including the uplink corresponding SeqID. It means the device will only accept a downlink with the corresponding uplink sequence ID. As downlinks are rare, statistically you have not a big chance to find the right conditions to execute your replay attack.

The paper also indicate that the replayed Uplink frame can count on the device subscription limits when valid. Ok, if you have a lot you can always repeat the coming one. But this assumption is wrong:

• If a future valid frame is sent, the next legit one will be rejected (so not counted)
• If you exceed the 140 frames, there is no impact on Sigfox subscription. (this is different for lower subscription … but previous point applies)
• This will have other impact that this one in the reality later detailed.

What about encrypted frames

Honestly this chapter is really how to find a way to success the attack …(remind the moon …) So imagine you can hack the system to continuously transmitting … Imagine it is 600bps … ok lets also imagine it is repeat 1 … Now, we also need to expect this device to have enough battery to transmit all these messages … Now, let’s imagine after sending continuous data we can assume as invalid because this is not the normal behavior .. in that case you could be able to transmit a replayed frame… Hummm … but doing that, you are in competition with the device also sending a legit new frame with that seq id… your timing need to be really thin to make it real..

This is a perfect example of the difference theory and reality. In theory nothing wrong in that paper.

What can device maker do to protect against such attacks

• Using Sigfox encryption (should be your default)
• Add a frame counter in your downlink communications with a size depending on you donwlink frequency. in most of the case 4 bits will be enough.
• Add a Frame counter (can be incremented every 4096) in the uplink payload to detect the replay in the application backend

Denial of Service

This attack is much more interesting. In fact I’ve been demonstrated and reported to Sigfox this attack scenario two years ago.

The principle is to replay a legit frame when the legit device did not yet reached the sequence ID captured. This is activating the security feature of the backend and block the next legit frame coming from the legit device until the seqID is becoming higher than the replayed one. During this period of time, the device transmission are not reported to the backend.

Imagine if you have an alarm system, the alarm will never been reported, it is discarded, later the device data reception will normally continue and you could never see what has been happened.

If an attacker has captured many frames all along a long period, it can replay them on regular basis to continuously. Using a SeqId always higher than the legit device. In that situation, the backend will consider the replayed SeqIds as legit and always reject the device’s one.

This attacks needs to be in proximity of the device to capture the frames (currently 10 meters) then you can replay from any place covered by Sigfox network.

In term of what you can do, this attack is more interesting than the replay one previously described.

Practically, to execute this attack, you need to capture a legit frame, wait for the next valid transmission frame (so this is basically after 3900+ if not encrypted) and then you can execute it. As most of the device are under 24-50 messages a day … that’s long.

On top of this, there are different counter-measures that can be used. The back-end is generating an event in such a situation and this event can be used to unlock the security mechanism blocking the reception ; or it can be use to create a functional alert indicating the device is under attack…

What can device maker do to protect against such attacks

• Using Sigfox encryption drastically reduce this attack risk
• Processing the backend security event to re-engage device or generate a functional alarm

What can Sigfox do to protect against such attacks

• Rewriting the sequence security system. It has been made to protect against replay attack but it has side effects with a larger impact. I think it’s not to Sigfox to take a decision on blocking or not the messages. It should be a trust indicator in the reported payload. Free to the application backend to decide what to do with it. This could also backend application to add security mechanism inside the payload to validate the fame (like adding bytes to the seqId)

MAC Tag Forgery

Here the idea is to generate frames with a valid MAC security mechanism. This is a brute force attack. One or more devices will try all the possible combinations until finding one. At the end the attacker will have sent one valid frame over 65536 in the best situation for him. But he will be impossible to the attacker to know what has been the right one.

Even if he knows it, he will never be able to force a second one in a shorter time. It means a continuous emission and a quick detection on the Sigfox Backend.

I don’t know what are the security mechanisms in a such situation in the Sigfox infrastructure But I know you have events generated when a message is received with an invalid key. So it means the application backend can be alerted by an average of 32768 events… Something you can detect.

There is another thing not considered here: the MAC size is variable and depends on the payload size. For a 12 bits payload it is 2 bytes. For a 11 bits payload it is 3 bytes ; for 10 it is 4 bytes. So basically the attack time is valid for 4,8,12 bytes payload and will be 256,65536… longer for the others.

The attack will conduct in injecting an undesired uplink frame for a given device, in condition you have a valid sequence ID, so you need to firstly listen to device uplinks and know the transmission period of the device to predict a potentially good sequence ID. Then you can eventually conduct a DoS attack.

This attack can be conducted from anywhere in the Sigfox network ( but more easy to block if you are not in the device coverage area), once you obtained the current Sigfox SeqID and also know the SigfoxID of your target.

What about the Donwlink attack

The document describes how to perform the same attack on a downlink communication. As basically a device is deciding when it accepts a downlink messages there is no way to accelerate the processes. So you have a short time-frame during the reception windows of 25 seconds where you can make some trial.

According to the paper a downlink frame is 370ms so you could have about 68 trials per downlink. The sequence ID of the downlink changes on every downlink opportunity so you need to restart you try on every downlinks. So on each try you have 1 chance over 969 to succeed in your attack. Downlinks are really rare, so good luck !

The downlink attack also needs to be conducted at proximity of the device.

What can device maker do to protect against such attacks

• Use payload size 1,2,3,5,6,7,9,10,11 only and reject frames with other size. Apply the DoS counter-measures
• Monitor frame rejection for invalid key, this will give the context.
• Add an extra (secret) validation mechanism in the downlink
• Enable encryption (the attacker won’t be able to forge a specific payload)

What can Sigfox do to protect against such attacks

• Detect high speed communication, block it if not coming from the previous known device area

Key extraction

The cream pie security point a security analysis won’t be complete if you not mention it… So yes, if you let your car with door open, and key inside, it’s possible someone access it and still the car…

By the way, a device, like car is usually in a garage, the door of the garage is locked and attacker needs to expose itself to access the keys.

If he is able to do it, it means he can physically access the device. In a such situation there are many other interesting and easier things to do than putting a JTAG reader on the device to extract the key…

By-the-way, protecting keys inside the device is basic development requirement and unfortunately I agree lots of device makers and modem developers are not managing it properly, so it has to be reported.

We could also add a chapter “printed keys on device boxes” but Sigfox keys are not manipulated by the end-user.

What can device maker do to protect against such attacks

• Protect the keys in eeprom and memory. Eventually use secure-elements but in my point of view there are many other ways to do it with a non military grade security level but good enough by software.
• Protect device from firmware / eeprom dump
• Don’t be too much stupid

WHAT CAN Sigfox do to protect against such attacks

• Nothing, it is not network related
• Eventually during certification they could refuse modem provider to have a such lack of security as this is “exposing” a large number of customer after

Lack of Encryption – Single bit case

Sigfox 1bit communication are not using the payload part of the message (it is like a 0 message but one of the bit of the headers are used to carry the single bit information). So basically this single bit is not encrypted… ok good to know.

What can device maker do to protect against such attacks

• Use a 1 byte frame to transfer your 1bit payload if you want to be protected against a 1bit decryption…
• Do your own 1 bit encryption in your firmware

What can SIGFOX do to protect against such attacks

• Reject 1 bit payload when encryption is activated (this is a bit stupid for real)

Replay of Downlink Encrypted Frame

If I understand well, it is indicating that cnt (the sequenceId extension) is not taken into account in the downlink MAC generation, so basically a downlink captured could be replayed later. The document says “even if encryption is later deactivated”. Ok, but a device is Encrypted or Not Encrypted forever so, I understand the mathematical principles, but it is a non sense.

So this means, that if you captured a downlink corresponding to a given sequence ID, then if a new downlink request appears with the same sequence ID, you could replay the response you previously received. As the downlink response are really rare, you may need to wait for a multiple sequence ID rotations before reaching your goal. May be never.

What can device maker do to protect against such attacks

• Same as previously seen fro downlink replay: add a counter in the downlink message to reject replayed messages.
• Don’t stress too much with this attack if you have downlinks on weekly-monthly basis

MAC Tag Forgery : Completion Attack

This attack is in my point of view the most interesting as it is something new. The others have already been known, with different scenario extension, but there was nothing really surprising.

This one is more interesting in this point of view ; also more complex to understand. Basically the idea is the following:

When Sigfox lib is computing a MAC signature of the frame, it uses a 16 bytes array. As the payload vary, the 16 bytes array is completed by reusing the headers and payload inside this array.

It will be possible to forge a new valid frame from a previously captured one in certain conditions:

• The original payload size must be 1, 2 or 6 bytes long if clear payload. It will be 1,4,5 long for encrypted payload.
• The Forged frame content will be : original payload | Frame-type | F | Seq Number | DeviceID | Payload ; for the 1 byte forgery and will have less new bytes for the others. You can’t choose your forged payload content.
• The new frame sequence number will be the same as the initial sequence number. So you can send it only when this one is legit like in a replay attack.
• The encrypted forged payload will generate unpredictable results on the added bytes once decrypted.

What is it really ?

So basically as in a replay attack, you need to capture a frame, then compared to a classical replay attack, here you can modify the frame before replay it. By doing this you can create a new behavior on the application backend. But you can’t select the content of the frame you have forged. So, it is basically difficult to choose the backend behavior.

Then, you need to replay the frame, with the same consequences, difficulties and counter-measures seen before.

What are the consequences ?

The frame will be valid on backend with a different content. The first bytes will be the same as original frame. Next bytes will be different. So this new frame can be interpreted as a valid frame for a different feature and register invalid data in your application with eventually bad decision taken.

What can Device maker do to protect against such attacks

• Usually we use header in our frame format when designing device firmware communication protocol. So avoid reusing the same first bits in header for different frame size (particularly for size 1,2,6)
• Do not use size 1,2,6 but 3,3,7 ; there is no differences in terms of communication as Sigfox only have 4,8,12 frames size. Using 3 /7 instead of 4/8 allows to extends MAC to 1 byte more as previously seen.
• Eventually detects such attack by searching the device ID in the received frame when clear payload.
• Apply previously seen replay counter-measures.

What can Sigfox do to protect against such attacks

• Basically nothing without changing the whole protocol, but regarding the risk level, no interest of doing it
• Detecting this kind of forged frame as they are repeating the frame so they have no big chance to be legit. This can be made prior to decryption for the encrypted frame. Then report an alert on it.

Conclusion

The paper quality is really good and ask some good questions. My regrets is that these questions are mainly pushed to Sigfox and the counter-measures proposal are mostly affecting Sigfox protocol.

The problem of a such approach is that LPWAn protocol evolution is a problem (let take as an example: LoRaWan protocol is evolving but not a lot of devices and network servers are adopting it. Most of the evolution are incompatible with the previous versions or can’t be dissociated – see my blog post about LoRaWan 1.0.4 evolution).

So basically, you can blame Sigfox about not doing anything about published security paper and if ever one of the attack occurred you can say “I’ve told them” but industrial migration is a problem.

I agree on the fact Sigfox is not communicating on counter measures and evolution against the different reported attack, but I had serious discussions with them on attack I’ve been demonstrated and never yet published publicly. So they are reactive when there is a real risk for the consumers.

My point of view, is to give to the developers the best understanding of the real risk and to give them the simple counter-measures they can add during device design to protect against the know potential attack.

All the reported attacks needs a real effort for the attacker to be successfully conducted, lots of time and important investment/energy spent on it.

This is what I’ve done in this post. Do not consider it as an attack against Loïc Ferreira, it has done an excellent job, as a researcher, and the paper quality is really good. I recommend you to read it and take a look to the proposed counter-measures I did not comment much as I have written my own all along the paper reading.