This application is a National Stage Entry of International Application No. PCT/IB2017/000924, filed Mar. 2, 2017, which is hereby incorporated by reference in its entirety for all purposes as if fully set forth herein.

The present invention relates to wireless communication, and more specifically to secure communication between a wireless device and a server over a Low Power Wide Area Network (LPWAN).

BACKGROUND OF THE INVENTION

Low Power Wide Area Networks (LPWANs) are low-power wireless networks which allow long range communications at a low bit rate. These networks are particularly suitable for Machine-To-Machine (M2M) and Internet of Things (IoT) applications, which are limited in terms of memory capacity, computing power and energy. Sigfox, LTE-NB1 (“Long Term Evolution—Machine to Machine, Narrow Band”) or LoRaWAN (“Long Range Radio Wide Area Network”) are examples of such networks.

FIG. 1describes the architecture of an LPWAN which, by way of illustration, may be of the LoRaWAN type. A LoRaWAN network follows a star topology, in which messages between devices, called end-devices,101,102,103and a central network server121are transmitted and received through gateways111,112. The end-devices101,102,103and the gateways111,112communicate according the low bit rate LoRa radio technology, while the gateways and the network server121usually communicate using higher bit rate backhauling technologies, such as Ethernet or 4G for example. The network server then communicates with a plurality of application servers131,132from which the application providers exploit data from the end-devices101,102,103, and may instruct the network server to send downlink packets to the end-devices.

For some applications, for example in industrial IoT and commercial applications, a huge number of connected devices equipped with sensors have to be deployed: there could potentially be tens of billions of communicating sensors to connect to networks in the coming years. These sensors operate on batteries and daily transmit very small amounts of data at a low bit rate to servers. LPWANs are thus a good solution for these applications, which do not need a high bit rate, and for these devices with limited resources, for which an autonomy of several years is needed.

In LPWAN, IoT communication between a device (also designated here by “end-device”) and its data processing platform typically takes place over a Radio Frequency (RF) interface, open to eavesdropping. This communication needs to be secured to ensure confidentiality as well as integrity of the data from and to the device.

The current state of the art in IoT secure communications relies on a (or several) shared secret(s) that is (are) used, directly or by means of key derivation techniques, to encrypt and/or authenticate communications between an end-device and a network server.

In some advanced implementations, the shared secrets are used over the air and computed from a cryptographic key, hereinafter referred to as “application key”, known by both of the end-device and the network server, which is never communicated over the air.

For example, in the LoRaWAN standard, activating an end-device on the network can be done by the “Over-The-Air Activation” (OTAA) method. To achieve OTAA, the end-device sends a message and a cryptogram computed with its application key (AppKey). The server checks if the end-device is authorized to join the network, on the basis of this AppKey, which has been communicated beforehand to the server (during the device commissioning process). If the end-device is authorized, the server sends a downlink message including some cryptographic data. Then, two session keys (one for network related functions such as integrity protection, the other for user payload encryption) are derived at the end-device, based on the received data.

The limitation of the current security architecture is linked to the possibility of physical attacks to the end-device or to the server. Some high security applications may rely on information generated by an IoT sensor, and the possibility to spoof data triggers from a legitimate sensor may lead to important consequences. If a server is accessed by an attacker, the application keys of potentially millions of devices are exposed.

If the sensor can be physically accessed by an attacker, the attacker will be able to physically access the device flash and RAM memory, and therefore access the application key that is used to bootstrap the communication security. An implementer may choose to encrypt this secret, but such encryption will rely on code, or additional secrets that are also present in memory, and the attacker therefore always has enough information to reverse the obfuscation strategy and reach the bootstrap secret.

The limitations highlighted in the previous sections relate to the physical accessibility of the memory used to store the application key. In the last 20 years, technologies have been developed to provide physical protection to an application key, inside a module that implements multiple strategies to make it “impossible” to retrieve a secret key. “Impossible” is to be understood in the sense of “not achievable with means that are proportional to the potential profit that may be obtained by accessing the secret key”.

Such security modules have to implement standard cryptographic methods that rely on the secret key, such as RSA public key and private key operations. The physical module implementing physically protected secret and cryptographic code and providing a secure Application Programming Interface (API) to an external processor is called a “Secure Element” (SE).

However, the utilization of Secure Elements in the context of IoT security has many drawbacks. For instance:they represent a significant cost, which, related to the cost of RF and microcontroller subsystem typically used in an IoT device, may add 50% or more to the cost of the device;they use additional energy, in a context where devices are sometimes optimized for battery life of 10 years or more;they use additional printed circuit board space, whereas compactness is important;conventionally, they can only operate specific standard cryptographic primitives, defined during the design stage. As a result “non standard” operations or intermediate computations based on secret information still need to be implemented in a non-secure space, and thus may expose the secret information over the communication bus and RAM;they typically implement only the standard mainstream cryptographic primitives which are adapted for the computer or secure storage world, but do not take into account the extreme limitations of an IoT communication link: LPWAN technologies, such as LoRaWAN for example, are limited to 50 bytes per uplink or so in the downlink, and accept only very few uplink or downlink messages per day. Certificate-based cryptography, or hash methods, are therefore not usable in their standard form. Therefore, dedicated SEs for each IoT technology would need to be developed, making it impossible to design multiprotocol devices and adding to the cost of design;they do not allow upgrades without significantly adding to the overall SE cost. Upgradability is important in the IoT context, where millions of devices may be deployed over the next few decades, and stay operational for over 10 years. End devise must be adaptable to the advances in security technology in this time frame.

There is thus a need for alternative solutions to ensure the security of LPWAN IoT communication.

SUMMARY OF THE INVENTION

The invention relates to a communication interface for supporting communication between a wireless device and a server over an LPWAN. The communication interface comprises:an untrusted execution part configured to operate in accordance with an LPWAN communication protocol stack including at least one secured LPWAN protocol using cryptographic primitives;a memory for storing computer code and at least one cryptographic key in an encrypted form;a trusted execution part incorporating a root secret for decrypting the at least one cryptographic key from the memory, wherein the trusted execution part is configured to execute the cryptographic primitives of the at least one secured LPWAN protocol using the decrypted cryptographic key and computer code from the memory.

This communication interface can be used in a device or a server (network server or application server).

The trusted execution part can implement all the operations that have to be secured (encryption, decryption, execution of cryptographic primitives . . . ) while the untrusted execution part can communicate with a device or server via an unsecured link. For instance, the trusted execution part encrypts a message and the untrusted execution part sends the encrypted message via a standard (unsecure) communication link.

Advantageously, the communication interface comprises a microcontroller chip which includes both the untrusted execution part and the trusted execution part

Hence, a single semiconductor chip can carry out all security and communication functions, which is particularly desirable in the case of end-devices which are potentially very numerous and therefore must have a low hardware cost.

In one embodiment, the memory has a reprogrammable memory section for storing computer code and a cryptographic application key in an encrypted form, and a RAM or flash section for storing, in an encrypted form, at least one cryptographic session key computed by the trusted execution part as a function of the cryptographic application key.

The use of a reprogrammable memory section advantageously makes it possible to update/upgrade an application key or a portion of the code stored in the memory. Hence, the communication interface of the present invention ensures the security of LPWAN IoT communication while ensuring lower costs and better evolutivity. For instance, the engineer/administrator in charge of the manufacture of a connected object may change the application key of a device both in the server and in the device. This administrator also can change a code portion in the communication interface of the server, so that this change can then be sent to a multicast group of devices.

To implement this multicast transmission, the reprogrammable memory section can be further provided for storing a cryptographic group key written in an encrypted form by the trusted execution part in response to a command for joining a multicast group of wireless devices.

In the context of an LPWAN including communication protocols based on application and session keys (such as LoRaWAN for instance), the execution of one of the cryptographic primitives by the trusted execution part can comprise encrypting concatenated information elements of a first set of information elements with an application key decrypted from the memory to derive a first session key, wherein the first set of information elements includes at least one nonce.

More specifically, the concatenated information elements of the first set may include a first nonce generated by the server, an identifier of the LPWAN and a second nonce generated by the wireless device.

In this context, the trusted execution part can be configured to compute the key derivation material sent over the air during the key derivation handshake, and then encrypt the first session key with the root secret and write the encrypted first session key in a RAM or flash section of the memory.

The execution of one of the cryptographic primitives by the trusted execution part can comprise encrypting a message provided by the untrusted execution part using the first session key. The encryption procedure is specific to the LPWAN protocol, typically not available in a standard Secure Element: it is executed by the secure part of the communication interface from encrypted code implementing the specific encryption procedure, said encrypted code being integrity checked and decrypted using the secure subsystem root secret.

The execution of one of the cryptographic primitives by the trusted execution part also can comprise encrypting concatenated information elements of a second set of information elements with the application key decrypted from the memory to derive a second session key, wherein the second set of information elements includes at least one nonce.

The concatenated information elements of this second set can include a first nonce generated by the wireless device, an identifier of the LPWAN and a second nonce generated by the server.

The trusted execution part may be configured to encrypt the second session key with the root secret and write the encrypted second session key in a RAM or flash section of the memory.

When a second session key is derived, the execution of one of the cryptographic primitives by the trusted execution part may comprise computing a Message Integrity Check (MIC) value based on an encrypted message using the second session key. The MIC can be further computed based on concatenated elements, including an address of the wireless device.

This MIC value may be included in a payload for an uplink or downlink message sent via the LPWAN.

A MIC value may also be computed:based on concatenated elements, including a nonce generated by the wireless device, an identifier of the device, and an identifier of an application provider, using an application key decrypted from the memory; and/orbased on concatenated elements, including an identifier of the LPWAN and an address of the wireless device, using an application key decrypted from the memory.

Such MIC values may be included in a payload for a “join request” message (from the end-device to the network server) and for a “join accept” message (from the network server to the end-device), respectively, in the case of an OTAA in the LPWAN.

Another aspect of the invention relates to a wireless device having a communication interface as described above for communicating with a server over an LPWAN.

The trusted execution part of the communication interface of the device can be configured to change at least one cryptographic key stored in an encrypted form in the memory of the communication interface in response to a key update command received over the LPWAN. The change of the cryptographic key can be performed by the trusted execution part using an update key stored in an encrypted form.

Thus, if one cryptographic key has been compromised, it can be changed easily and in a secure way.

The trusted execution part of the communication interface can be configured to change a portion of the computer code stored in the memory in response to a code upgrade command received over the LPWAN. The code upgrade command can be received on a multicast address of the LPWAN in at least one encrypted message which is decrypted by the trusted execution part using a cryptographic group key stored in an encrypted form in the memory.

Hence, it is possible to securely and easily upgrade a code stored in memory (for instance, bootstrapping cryptographic primitives, or multicast group short term key derivation algorithms) of all the devices of a group.

In this context of code upgrade, the communication interface can be configured to apply redundancy decoding to the at least one encrypted message to obtain an upgraded code portion for changing the portion of the computer code stored in the memory.

When an upgrade message is sent from a server to a device, packet loss may happen. Adding redundancy in the transmitted information (by applying redundancy encoding/decoding at the server/device side, respectively) allows the device to compensate a loss of information.

For instance, the redundancy decoding can comprise a low-density parity check (LDPC) decoding.

Furthermore, the trusted execution part can be configured to compute a hash code based on a cryptographic key stored in an encrypted form in the memory and an upgraded code portion received as part of the code upgrade command, and the communication interface can be configured to transmit the hash code to a verification server and to receive a response from the verification server to validate whether the portion of the computer code is to be changed.

This advantageously enables to check the authenticity of the received message in the context of a code upgrade.

Yet another aspect of the invention relates to a server having a communication interface as described above for communicating with a plurality of wireless devices over an LPWAN.

The memory of the communication interface may store a plurality of cryptographic application keys in an encrypted form, each cryptographic application key being for a respective wireless device of the LPWAN.

For changing the cryptographic application key for one of the plurality of wireless devices, the communication interface can be configured to transmit a key update command to the one of the wireless devices over the LPWAN, through a unicast address of the one of the plurality of wireless devices, and the trusted execution part of the communication interface can be configured to change the cryptographic key stored in an encrypted form in the memory of the communication interface for the one of the plurality of wireless devices.

For changing a computer code portion used by a group of wireless devices, the communication interface can be configured to transmit a code upgrade command over the LPWAN, through a multicast address of the LPWAN. The trusted execution part of the communication interface can be configured to encrypt the code upgrade command with a cryptographic group key associated with the multicast address of the LPWAN prior to transmission through the multicast address.

As mentioned above, the encrypted code upgrade command can be redundancy encoded and then split into a plurality of fragments transmitted in respective messages to the multicast address of the LPWAN. In a particular embodiment, the encrypted code upgrade command can be redundancy encoded using LDPC encoding.

Finally, an authenticity check of the message can be performed as follows:the communication interface receives a first hash code from one of the group of wireless devices,the trusted execution part computes a second hash code based on a cryptographic key stored in an encrypted form in the memory for the one of the group of wireless devices and an upgraded code portion to be substituted for the computer code portion used by the group of wireless devices,the communication interface compares the first and second hash codes and to send a response to the one of the group of wireless devices depending on whether or not the first and second hash codes are identical.

Other features and advantages of the method and apparatus disclosed herein will become apparent from the following description of non-limiting embodiments, with reference to the appended drawings.

