Patent Application
20180288013
The subject matter of the present invention relates to the security in the field of the Internet of things (IoT).
The advance of pervasive low rate radio technologies, adapted to autonomous low-energy consumption objects, has recently allowed the development of the Internet of things (IoT). The IoT enables a user to access information, also called resources, from sensors or actuators, being often remote and with low autonomy. The scheme currently retained consists in virtualising these resources in a gateway or server, connected to the Internet or infrastructure.
The end-to-end security, that is from the user to the resource, is actually ensured between the user and the element virtualising the resource on the one hand and, between the element virtualising the resource and the resource itself on the other hand.
The gateway allows continuous communications between the field of the sensor sub-network and the Internet field, by ensuring interoperability of communication protocols. On the other hand, it does not ensure interoperability of the security protocols, hence there is a discontinuous security at the gateway.
In practice, the gateway harbours different security keys which ensure confidentiality and integrity on the one hand with the final user on the Internet side, and with the sensor network on the other hand. These security keys are provided by a server located in the “Cloud”, that can further have a list of the devices permitted to communicate on the network (white list).
Providing security keys to the gateway is well adapted to cases where the sensors are fixed devices, in other words belong to one and a single sub-network over time. On the other hand, when these sensors are mobile and switch from one sub-network to the other, by successively connecting to different gateways when moving, managing communication securities becomes substantially more complex.
The situation of a sensor moving in a WSN network has been illustrated in
The WSN can be a ZigBee network or even an LPWAN network (Low Power Wide-Area Network), for example a LoRaWAN network (Long Range LPWAN).
The ZigBee standard offers the possibility to manage communication security at the network layer, also called NTW (ZigBee Network Layer) or the application layer, also called APS (ZigBee Application Sub-Layer). On the other hand, the standard is silent about the management of security at the link layer (IEEE 802.15.4 Physical Layer), a fortiori in a situation of mobility and about the distribution of the secrete security keys.
The LoRaWAN protocol does not further provide for management of security at the link layer (Lora MAC), nor management of the secrete keys.
However, it has been proposed in the paper by R. Miller entitled “LoRa Security Building a secure LoRa solution published in MWR Labs Whitepaper, a procedure for distributing the secrete keys on a LoRa network. In particular, when a sensor (node) wishes to join such a network, it initiates a procedure called an activation procedure or OTAA (Over-The-Air-Activation). It is assumed that each node is equipped with a symmetric single secrete key (AppKey). This procedure consists in exchanging messages between the node and the server via the gateway. It starts with sending a join request comprising a MAC header (MHDR), an identifier of the owner of the sensor (AppEUI), a sensor identifier (DevEUI) as well as a nonce (DevNonce) generated by the sensor. The join request is signed by hashing the join request by means of the secrete key AppKey, this signature acting as a message authentication code or message integrity code (MIC).
The join request thus signed is transmitted to the network server LoRa which verifies the authenticity of the message by means of the AppKey. In case of success, the cloud server replies to the sensor by an accept message (join-accept). To do this, the server generates a new nonce (AppNonce) as well as two secrete keys NwkSKey (Network Session Key) and AppSKey (Application Session Key) corresponding to the network layer and to the application layer respectively. These keys are generated by encrypting, by means of the AppKey key, a data sequence obtained by concatenating a predetermined value, of the nonce generated by the AppNonce server, an identifier of the LoRa network, NetID, and the nonce generated by the sensor, DevNonce. The keys thus generated are transmitted to the sensor.
The accept message includes the AppNonce, the address of the destination device, DevAddr, as well as some physical parameters. The message is also signed by means of the AppKey key. Upon receipt, the sensor decrypts the accept message and verifies the MIC code by means of the AppKey. In case of success, the sensor generates on its own the NwkSKey and AppSKey from the AppNonce value contained in the accept message.
However, the solution recommended in the aforementioned paper by R. Miller is not fully satisfactory. Indeed, the header of a MAC frame (MH DR) on the side of the LoRa network has not to be known beyond the gateway, in particular by the cloud server. The server thus has no possibility in practice to verify the authenticity of the join request. Further, any sensor can be connected to the cloud server through any gateway. Therefore, there is no security ensured at the link level in the sub-network, downstream of the LoRa gateway.
The purpose of the present invention is consequently to provide a method enabling the communication between the sensor of the WSN network and the user to be efficiently secured, in an end-to-end fashion at the link level, including when the sensor is in a mobility situation.
The present invention is defined by an end-to-end secured communication method between a mobile sensor and a user, the mobile sensor moving within a WSN network, said WSN network comprising at least one sub-network connected to the Internet by means of a gateway, said gateway being connected via the Internet to a server managing said WSN network, in which, when the mobile sensor transmits an association request to the gateway, this relays it to the server and:
The server advantageously has a white list containing the identifiers of the sensors permitted to be connected via said gateway, associated with their respective security keys, as well as the identifier of said gateway associated with its security key.
The mobile sensor can have an identifier and its own security key, and to form said association request, it generates a nonce, said association request being obtained by concatenating the identifier of the mobile sensor, the nonce thus generated and a signature of the identifier and of the nonce thus concatenated by the security key of the mobile sensor.
Preferably, upon receipt of the association request, the server, after it has verified the request integrity, encrypts the temporary encryption key by means of the security key of the gateway to generate a first message and by means of the security key of the mobile sensor to generate a second message, the first and second messages being respectively transmitted to the gateway and to the mobile sensor at the application layer.
The first message is preferably obtained by concatenating the identifier of the gateway, the identifier of the mobile sensor, the nonce and said temporary encryption key to form a first set of concatenated information, said first set of concatenated information being encrypted by means of the security key of the gateway.
Advantageously, the first set of concatenated information is signed by means of a signature key of the gateway and the signature is concatenated to the first set of concatenated information previously encrypted by means of the security key of the gateway.
The signature key of the gateway can be chosen identical to the security key of the gateway.
The second message is preferably obtained by concatenating the identifier of the gateway, the identifier of the mobile sensor, the nonce and said temporary encryption key to form a second set of concatenated information, said second set of concatenated information being encrypted by means of the security key of the mobile sensor.
Advantageously, the second set of information concatenated is signed by means of a signature key of the mobile sensor and the signature thus obtained is concatenated to the second set of concatenated information previously encrypted by means of the security key of the mobile sensor.
The signature key of the mobile sensor can be chosen identical to the security key of the mobile sensor.
The gateway can further transmit to the sensor a third message containing the sub-network key encrypted by the temporary encryption key, the third message being transmitted at the application level or at the network level.
The third message thereby contains a concatenation of the identifier of the gateway, of the identifier of the mobile sensor, of the nonce and of the sub-network key.
When the server detects that a sensor of the sub-network does not reply any longer to the requests of the server, or at regular time intervals, the server can generate a new temporary encryption key, and transmit it to each sensor belonging to the sub-network in an encrypted form by the security key of this sensor or a session key previously exchanged between the gateway and this sensor.
The server can further transmit to the gateway a renew request for the sub-network key to the gateway, said renew request containing the new temporary encryption key, in an encrypted form by the security key of the gateway.
Finally, when the gateway has received the renew request from the server, this can generate a new sub-network key and broadcast it to the sub-network sensor in the form of an encrypted message by the new temporary encryption key.
Further characteristics and advantages of the invention will appear upon reading a preferential embodiment of the invention, making reference to the appended figures in which:
A WSN network is again considered, that is a network of multi-hop wireless sensors as represented in
The sensors of the WSN network accommodate an operating system, such as Contiki (version 3.x), enabling security keys to be managed at the link layer (MAC layer) of the OSI model. Each gateway ensures interoperability of the communication protocols between the WSN network and the Internet. It also accommodates an operating system enabling security keys to be managed at the link level, such as for example a Linux kernel (version 4.4) to securely communicate with the sensor network. The final user accesses the resources provided by the sensors via the Internet.
It is assumed that each sensor of the WSN network is equipped with a security key (for example a 128-bit symmetric key) stored in a read only memory of the FLASH, ROM or EPROM, secured if possible. In the following, AppKU will designate the security key belonging to the sensor having DevU as an identifier. The security key is a secrete key in that it is only known from the sensor DevU and from the server managing the WSN network. It is used at the application level in the communications between the DevU sensor and the server, or even the final user.
Further, each gateway is identified by an identifier and is equipped with a security key at the link level. This security key is a secrete key insofar as it is only known from the gateway and the sensors of the sub-network connected thereto. In the following, LinSKA will designate the security key of the gateway having GatA as an identifier. In other words, the security key LinSKA ensures the security of the communications (confidentiality, integrity and authentication) at the link level inside the sub-network A.
210 designates the protocol stack intervening in the Internet domain (for example at the server), 220 designates the protocol stack intervening at the gateway and 230 designates the protocol stack intervening at the WSN network (for example at the mobile sensor).
It has been assumed here that the transmission in the Internet domain between the server and the gateway was made by an Ethernet link (PHY and MAC layer) and that the transmission in the WSN network was made according to the protocol IEEE 802.15.4 (PHY and MAC layers). The transmission at the network level is made according to the protocol IPv4 or IPv6 in the Internet field and according to the protocol IPv6/6LoWPAN on the side of the WSN network. The gateway ensures protocol conversion up to the network level and is transparent to the upper protocol layers.
In
The sensor DevV of the sub-network A is equipped with the secrete key AppKV. Further, the sensor DevU attempting to join the sub-network A is equipped with the secrete key AppKU.
The sensors DevW and DevZ of the sub-network B are respectively equipped with the secrete keys AppKW and AppKZ.
The gateways GatA and GatB (or equivalently the sub-networks A and B) are respectively equipped with the security keys LinSKA and LinSKB.
The cloud server, managing the WSN network, has a white list of couples of identifiers of permitted devices and their corresponding secrete keys. In the case illustrated, this white list comprises the identifiers of the gateways (GatA,GatB) respectively associated with their respective security keys (LinSKA,LinSKB) and, for each gateway (or equivalently for each sub-network (A, B)), the identifiers of the sensors of the sub-network in question associated with their respective security keys. It will be actually noted that the input of the white list related to a sensor (for example DevV) of a sub-network corresponds to a triplet consisting of the identifier of this sensor, its security key (AppKV) and the identifier of the gateway (GatA) of the sub-network to which it belongs. In other words, a communication between the sensor DevV and the server will be permitted and secured with the AppKV key only insofar as it will be established via the gateway of the sub-network in which the sensor is recorded. In the case where the sensor is a mobile sensor, only the couple of the identifier (DevU) and its security key AppKU) is stored in the white list of the server.
It is assumed that a mobile sensor (for example DevU in
The detail of the association process has been represented in
In a first phase, the mobile sensor DevU takes from the server a temporary key enabling it to securely communicate with the gateway of the sub-network it wishes to join.
More precisely, the mobile sensor DevU transmits in 411 an association request (“Hello” message) to the gateway of the sub-network, via an unsecured channel.
This message, transmitted at the application layer (APS in the case of the ZigBee protocol), comprises a payload containing at least the identifier of the mobile sensor, a nonce generated by the latter and a signature by means of its security key (AppKU). The signature can for example be an authentication code of a cryptographic footprint HMAC (keyed-Hash Message Authentication Code). Thus, the payload of the association request is given by:
requestAPS-PLD=DevU|DevNonce|HMAC(AppKU,DevU|DevNonce) (1)
where HMAC(AppKU,DevU|DevNonce) represents the signature of DevU|DevNonce by means of the security key, AppKU. In a simplified embodiment, the nonce can be omitted and therefore the association request boils down to requestAPS-PLD=DevU|HMAC (AppKU,DevU).
In step 412, the gateway relays the association request to the server managing the network by adding its gateway identifier, GatA. The payload requestAPS-PLD is on the other hand transparently relayed by the gateway given that it is located at the applicative level. The message relayed by the gateway to the server can be protected by a TLS encryption.
Upon receiving the message thus relayed, the integrity and authenticity of the message are verified by the server by means of the signature (H MAC). More precisely, the server calculates the signature of DevU|DevNonce from the security key AppKU stored in the list and compares it with the signature contained in the requestAps pa). The server further verifies that the sensor DevU does request to join the sub-network A, from the identifier of the gateway GatA, appended to the message relayed.
Then, the server generates a temporary encryption key, marked EncKtemp, for securing the communication between the sensor and the gateway. This temporary key is transmitted to the gateway GatA on the one hand and, to the sensor DevU on the other hand. More precisely, the server encrypts the temporary key EncKtemp by means of the security key of the gateway, AppKA (contained in the white list of the server), and transmits it in 421 to the gateway in a first message, key tempGat
Preferably, the server adds to the temporary key EncKtemp contained in the messages key tempGat
key-tempAPS-PLDGat
and
key-tempAPS-PLDGat
where Encrypt (AppKA, X) and Encrypt (AppKU, X) respectively represent the X encryption by the security key of the gateway, AppKA, and the security key of the sensor, AppKU and X=GatA|DevU|DevNonce|EncKtemp designates the concatenation of data GatA, DevU, DevNonce and EncKtemp.
Optionally, the server can add to the payload (key-tempAPS-PLDGat
key-tempAPS-PLDGat
key-tempAPS-PLDDev
Upon receptions, the gateway GatA and the sensor DevU decrypt the content of the first and of the second message by means of their respective security keys, and then verify optionally the integrity of the payload by means of the signature.
In this stage, the gateway GatA and the sensor DevU have a shared common secrete key, EncKtemp (typically of 128 bits), enabling them to establish a secured channel between them, at the link level.
In a second phase, the gateway transmits to the mobile sensor the security key of the sub-network, this transmission being secured by the temporary encryption key, EncKtemp, provided beforehand by the server to the gateway and to the sensor in question.
More precisely, in step 431, the gateway GatA uses the temporary key EncKtemp to transmit to the sensor DevU, the security key of the sub-network, LinSKA. As previously indicated, this key is for protecting the transmissions within the sub-network A, at the link level.
More precisely, the gateway GatA transmits the encrypted information Encrypt(EncKtemp,LinSKA) to the sensor DevU, either in the payload of a message at the application level, or in the payload of a message at the network level, such that it can be routed in the sub-network (optionally in several “hops”) to the sensor. The message at the application level is for example in the form of a DIO (DODAG Information Object where DODAG means Destination Oriented Direct Acyclic Graph) control message of the RPL routing protocol. It is reminded that RPL specifies a routing protocol suitable for IPv6 communication needs above the low power lossy networks.
As above, the gateway can add to the encrypted information, Encrypt(EncKtemp,LinSKA), the DevNonce nonce as well as the identifiers of the gateway GatA and the sensor DevU.
For example, if the transmission is performed at the applicative level, the payload can be expressed as:
keyAPS-PLDGat
with the same notation conventions as previously. The inclusion of DevU and DevNonce in the payload enables the process to be traced, in other words makes it possible to indicate that the sub-network key transmitted in step 431 actually follows the association request initiated by the sensor, thus avoiding any ambiguity in the case where several sensors would simultaneously join the sub-network.
Optionally, the gateway GatA can add to the payload a signature (H MAC, MAC, MIC). Thus, when the signature is an HMAC signature, the payload becomes:
keyAPS-PLDGat
with Y=GatA|DevU|DevNonce|LinSKA.
According to one alternative, instead of transmitting a single sub-network key LinSKA, the gateway could transmit two distinct keys LinSKA1 and LinSKA2, one to encrypt messages (at the link level) and the other to sign them.
In any cases, the sensor DevU decrypts the payload keyAPS-PLDGat
The sensor DevU then transmits in 432 an acknowledgment message to the gateway, for example in the form of a DAO (Destination Advertisement Object) control message. This acknowledgment message is encrypted by means of the security key of the sub-network LinSKA.
When the sensor moves from one sub-network to the other, the old sub-network key stored in the random access memory of the sensor is replaced by the new key transmitted by the gateway of the sub-network it has just joined.
The process described above is repeated for each new sensor which joins the sub-network.
If the sensor has not yet a session key to communicate data at the applicative level, the cloud server sends it one in 440 that it will maintain in mobility. This key, noted AppSKU in
This process of renewing the security key of the sub-network is initiated at regular intervals or upon the occurrence of an event depending on the security degree required. For example, it could be initiated each time a sensor does not reply to the server request any longer, regardless of whether this has left the sub-network, or its battery is exhausted.
The purpose of renewing the security key of the sub-network is to cope with an attack which would consist in reading this security key in the memory of one of the sensors.
In the example illustrated, it is assumed that the server has detected that the mobile sensor DevU does not reply to its requests any longer. Therefore, it decides to renew the key of the sub-network B with which it was associated. After renewing this key, the sensor DevU will be de facto excluded from the sub-network insofar as it will not have the new key.
In step 511, the server transmits to each sensor of the sub-network B (only two sensors DevZ and DevW of this sub-network have been represented by way of example), a new temporary key EncKtemp′.
This new temporary key is transmitted in an encrypted form using the security key of the sensor (AppKW, AppKZ) or its session key (AppSKW,AppSKZ).
For example, the server transmits to the sensor DevW a message at the applicative level, temp_keyB, containing the following payload:
temp_keyAPS-PLDB=Encrypt(AppKW,GatB|DevW|AppNonce|EncKtemp′) (6-1)
or, when the session key is used:
temp_keyAPS-PLDB=Encrypt(AppSKW,GatB|DevW|AppNonce|EncKtemp′) (6-2)
with the same notation conventions as previously. In particular, X′=GatB|DevW|AppNonce|EncKtemp′ represents the concatenation of the identifier of the gateway GatB, of the identifier of the destination sensor, DevW, of a nonce generated by the server, AppNonce, and of the temporary key EncKtemp′. The nonce enables the exchange to be traced by being subsequently resumed in the acknowledgment message of the DevW sensor.
Preferably, the server adds to the payload a signature (HMAC, MAC, MIC). Thus, when the signature is an HMAC signature, the payload becomes:
temp_keyAPS-PLDB=Encrypt(AppKW,X′)|HMAC(AppKW,X′) (7-1)
or, when the session key is used:
temp_keyAPS-PLDB=Encrypt(AppSKW,X′)|HMAC(AppSKW,X′) (7-2).
Upon receiving the message, the sensor decrypts the payload by means of its security key AppKW or its session key AppSKW and verifies it for the integrity by means of the signature. It extracts the temporary key EncKtemp′ and the nonce AppNonce from the payload.
In step 512, each sensor of the sub-network B having received the temporary key EncKtemp′ transmits an acknowledgment message to the server by incorporating its identifier and the previously received nonce AppNonce therein. Thus, the acknowledgment message ack_new_keyW sent back by the sensor contains the payload:
ack_temp_keyAPS-PLDW=Encrypt(AppKW,ACK|GatB|DevW|AppNonce) (8-1)
or, when the session key is used:
ack_temp_keyAPS-PLDW=Encrypt(AppSKW,ACK|GatB|DevW|AppNonce) (8-2).
Once again, the sensor can add to the payload a signature (HMAC, MAC, MIC) to allow a verification for the integrity of the acknowledgment message by the server.
Once the server has received all the acknowledgment messages, it sends in 520 to the gateway GatB a request for renewing the security key of the sub-network B, renew_keyB. This request contains the temporary key EncKtemp′ and can be transmitted via the secured protocol https or even by encrypting the payload with the key AppKB.
The gateway GatB gateway thereby generates a new security key of the sub-network, LinSKB′ and broadcasts it in 530 to the sub-network sensors as a message encrypted by the temporary key EncKtemp′, broadcast_keyB. The message can be transmitted at the link, network or application level.
The payload of the message broadcast by the gateway GatB, broadcast_keyB, can be expressed as:
broadcast_keyB=Encrypt(EncKtemp′,GatB|LinSKB′) (9)
Optionally, a nonce can be generated by the gateway and added to the encryption argument for acknowledgment needs. Further, the payload can still be signed, so as to be capable of verifying its integrity at the sensors, and in particular that the new key LinSKB′ is proper.
Propagating the message broadcast_keyB in the sub-network is made by hops from one sensor to the other.
Once each sensor has received the broadcast_keyB message, it decrypts the content thereof and marks of the value of the new key. Then, it sends back in 540 an acknowledgment message to the gateway GatB, and then replaces its sub-network security key stored in a random access memory.
Once the gateway GatB has received all the acknowledgments, the communications between the sensors of the sub-network B and the server (or the final user) can resume.
In practice, there will be always sensors which will not reply. It can be considered to broadcast again the message broadcast_keyB in case where this message or the corresponding acknowledgment would be lost. However, if the sensor still does not reply after a fixed number of demands, the sub-network security key is updated by all the sub-network sensors that have replied by acknowledgment. For the other ones, a secured association process could be initiated when they are ready to join a sub-network.
In the description both of the association process and renewing the sub-network security key, it has been assumed that the security key of the gateway and the security key of the mobile sensor could be used not only for encryption of messages but also to their signature. Alternatively, the gateway and/or the mobile sensor could each have a security key (for encryption) and a key for signature. The security keys and signature keys are thereby stored in the white list of the server in connection with the identifiers of the corresponding devices (gateway, mobile sensor).
| Number | Date | Country | Kind |
|---|---|---|---|
| 17 52881 | Apr 2017 | FR | national |
