[ARTICLE] Sigfox security

Introduction

   Sigfox is a proprietary wireless technology developed by the French start-up of the same name. The technology operates on free radio bands, dedicated to civil use, called ISM bands (for “Industrial, Scientific and Medical” bands). In Europe, this band is around 868 MHz, and around 915 MHz in the United States. Sigfox is a protocol that operates in the narrow band UNB (“Ultra Narrow Band”) to allow the coexistence of many simultaneous communications. It is low-power, long-range (from a few kilometres in the city to a few tens of kilometres in the countryside) and low-rate (100 bits per second, making it a good candidate for IoT uses.

Sigfox covers the vast majority of France, with approximately 1500 antennas deployed. Other European countries such as Ireland, Luxembourg, Portugal, Spain and the Netherlands are also fully covered. Some countries are currently being covered by the operator: Australia, Belgium, Brazil, United Kingdom, Czech Republic, Denmark, Finland, Italy, Mauritius, New Zealand, and the United States. Sigfox does not cover most of the countries abroad on its own. To do this, it relies on partner operators in each country covered, called SNO (“Sigfox Network Operators”). A map of Sigfox’s coverage is available at http://www.sigfox.com/coverage .

Mainly designed to be unidirectional, it can however be used in bidirectional mode on demand, in an opportunistic way, by sending specific frames requiring network acknowledgement. After a short transmission, the device then listens for a short time to retrieve a message downloading from the network (8 bytes are available).

Messages sent by peripherals are retrieved centrally, either via Sigfox’s dedicated interface, called “backend” (https://backend.sigfox.com), or via the dedicated backoffice of a Sigfox intermediary. It is possible on these interfaces to define business callbacks, for example to make automated Web Services requests based on messages received by a fleet of Sigfox devices.

The ISM band is free to use but is subject to legal restrictions on use. In Europe, for example, a device in the 868 MHz band cannot transmit more than 1% of the time. This legal constraint allows, on average, only one message to be sent every 10 minutes. For this use, and for a single Sigfox device, the annual subscription is about 10€ per year.

Context of the study

   As the protocol is proprietary, there are no public specifications for Sigfox, with the exception of three documents published at ETSI in September 2014, after the technology was released, on LTN (“Low Throughput Networks”) low bandwidth networks. These specifications, which are less technical than functional, are not entirely in line with the Sigfox protocol itself and are more a working basis for future standardization of low speed IoT protocols (documents ETSI GS LTN 001-003 V1.1.1.1 2014/09).

In this context, and following numerous requests from our customers and prospects regarding Sigfox security, we have decided to conduct an independent study on the subject to establish the exact security features of the technology. We used two different approaches for its realization: a reverse engineering study of the radio protocol and another on the firmware of a Sigfox component.

Radio protocol analysis

   When a Sigfox message is sent, 3 different frames are actually sent (see Figure 1) using 3 slightly different frequencies and also following 3 different codings.

Waterfall view of a Sigfox message being sent

The modulation used is a phase change modulation (BPSK), and 100 bits are transmitted per second (see Figure 2).

Waveform in real time representation

Firmware analysis

   For our study, we used an Arduino Sigfox development board, including a SOC (“System On Chip”) with a Si4461 radio module and an ARM Cortex-M3 processor. This card has been physically interfaced with 2 USB dungles, a UART series dongle for the operational control of the Sigfox module (sending frames), and a SWD dongle for debugging this module (pausing and recovering flash and RAM memories). The hardware package is shown in Figure 3.

Extraction of the memory from a Sigfox card

We chose to control the debugging of the module using Open Source OpenOCD software. The development headers provided in the development kit were used to identify interesting ranges and memory structures in the captures. Memory extraction recovered 128 KB of flash memory and 16 KB of RAM memory, most of which we analyzed with the IDA Pro software. The combined radio and firmware analysis determined the exact format of a Sigfox uplink frame. This structure is shown in Figure 4.

Structure of a Sigfox uplink frame

Sigfox security features

Redundancy / interference resistance

To resist voluntary or involuntary environmental interference, Sigfox therefore sends each message as 3 frames on 3 different frequencies, with 3 different binary encodings, to minimize the chances that the 3 frames will be altered upon reception. In addition, the Sigfox approved equipment has a good level of sensitivity, for example -125 dbM on our test device. However, we noted significant differences in reception inside and outside the buildings. Indoors, it is preferable to transmit near windows to ensure that messages are received properly. For critical applications, care should be taken to select devices with a high level of sensitivity.

Integrity

To check the integrity of received messages, in addition to their redundancy by multiple transmission, Sigfox uses a 16-bit error detector code (FCS: “Frame Check Sequence”). We were able to determine in our study that it was a CRC CCITT / XMODEM with zero initialization and output values. Thus, a corrupted message is very likely to be detected invalid. In addition, a MAC authentication code is used to authenticate the frame, and also acts as an integrity detector.

Anti-rejection mechanism

Each time a Sigfox frame is sent, a frame counter is incremented in the flash memory of the device, and the network keeps track of the received frame numbers. The same reissued message is ignored by the network. Sigfox therefore has an anti-replay mechanism. Thanks to this traceability, the network is even able to give the number of messages sent but not received, for example in areas where there is no coverage.

Authentication

Each Sigfox device has its own unique 32-bit identifier, which it writes into all the frames it sends. This way, it is possible to identify the specific device that transmitted a particular frame. We can wonder why an IoT identifier on only 32 bits (4.3 billion objects maximum), when we are talking about several tens of billions of connected objects in a few years. It is likely that the protocol will evolve by increasing the size of this field if Sigfox is deployed massively.

For authentication, a 128-bit symmetric key is embedded in each device during its manufacture and used to authenticate each message transmitted. Message authentication is done by a 16-bit MAC code, which is the result of calculating a part of the encrypted frame in AES-128-CBC, in which only the first 2 bytes of the last block are kept. This number includes the frame counter, so messages are not immediately replayable.

Encryption

The Sigfox protocol is not encrypted, all data sent over the network is sent in clear and potentially interceptible within the transmission range of the device (a few kilometers). Interception can be done with very little equipment, we will discuss this again in the section “Residual vulnerabilities and risks”. It is a pity that the Sigfox modules do not integrate native and transparent encryption for the user because they already integrate an implementation of the AES-128 encryption algorithm and a 128-bit embedded key, both used for frame authentication.

Portability between Sigfox intermediaries

Sigfox has several partners for the marketing of subscriptions to its network, and does not generally invoice individuals and small SMEs directly. Invoicing therefore sometimes goes through invoicing intermediaries, and it is even possible to switch from one intermediary to another. For this transition, it is necessary, as with traditional mobile networks, to provide a portability code requested from the old intermediary, and given to the new one, on the same principle as the mobile RIO code. In the case of Sigfox, this 16-digit hexadecimal code (8 bytes) is called the PAC (“Porting Authorisation Code”), and is renewed with each portability.

In principle, it is absolutely necessary to have the PAC to migrate from one Sigfox intermediary to another. In practice, it has been possible for us to ask Sigfox for its own invoicing connection without a PAC, which shows that this PAC code is not cryptographically necessary and that it is renewable by Sigfox if necessary.

Residual vulnerabilities and risks

We identified four main vulnerabilities:

As we have seen, the frames are sent in clear and are therefore receivable with adequate radio equipment, such as USB keys for DVB-T TV reception based on the Realtek RTL2832U chipset (see http://hakshop.myshopify.com/products/software-defined-radio-kit-rtl-sdr), devices that are currently experiencing some success. Very accessible, around 15 euros, they actually make it possible to receive frequencies from 50 MHz to about 2200 MHz, which makes them already very accessible and powerful audit tools. Listening to the Sigfox protocol is therefore not expensive for the attacker.

An important vulnerability for remotely controlled systems is the fact that the frames are partially replayable. Indeed, although an anti-replay system is present, it actually includes a frame counter on only 12 bits, so that messages and their signatures can be replayed every 212 bits = 4096 messages. With one message sent every 10 minutes, the frame counter loops in just over 28 days, so messages and their signatures sent during one month become valid again the following month, then again the following month and so on.

None of the Sigfox devices currently on the market have a “Secure Element”, which means that their authentication key is not properly protected. Indeed, a key is provisioned at the factory during the manufacture of the Sigfox devices, and it is stored in a part of the flash memory of the device, part of the memory not addressable by the user but accessible by the firmware. When used, the authentication key is copied into the device’s RAM, leaving it exposed by an attacker who would have punctual physical access to the device through a debugging or reflash interface on the device. A punctual physical access to a Sigfox device allows to extract this 128-bit key then to usurp ad vitam æternam the device by sending arbitrary messages in its place.

Finally, since the devices transmit their 32-bit identifier in clear, all Sigfox messages sent are identifiable and can be attached to the device that sent them. This makes it easy to know all the messages sent by a particular device during a listening session.

Development and integration recommendations

In all areas of IoT, due to technological constraints related to the capabilities of communicating objects, compromises in terms of security are necessary. It is therefore particularly important to analyse Sigfox’s operating environment on a case-by-case basis to adapt the level of security according to the use made of it, through a careful risk analysis.

If sensitive data is manipulated (from a confidentiality or availability point of view), it is desirable to redundant Sigfox, either at the wireless protocol level or at the application level. For confidentiality, we recommend encrypting the data. The difficulty lies in the fact that the data are small (12 characters at most), and therefore smaller than the block size of symmetric encryption algorithms that are state-of-the-art. It is therefore not possible to use a robust block encryption system, which would increase the frame size. One possibility is to use a flow encryption system before sending the data, while introducing a new key into the system (because the existing buried key is not easily accessible to the developer) and ensuring its security, which is not easy. Regarding non-usurpation, we recommend adding one or two bytes to the existing frame counter, consuming them on the useful 12-byte content, in order to make it difficult to reuse signed messages. Digital Security experts are at your disposal to assist you in studying your IoT security needs.