• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    An end-to-end communication method between a mobile sensor and a user, wherein the mobile sensor moves within a WSN network, the WSN comprising a plurality of subnets connected to the Internet by means of gateways. When the mobile sensor wishes to join a subnet, it transmits an association request to the gateway of the subnet which relays it to the server via the Internet. The latter communicates to the mobile sensor and to the gateway a temporary encryption key in encrypted form. The gateway can then communicate to the mobile sensor the security key of the subnet, by a message encrypted using the temporary encryption key. The mobile sensor can then communicate with the gateway securely, at the link level, by means of the security key of the subnet.
    公开号:FR3064857A1
    申请号:FR1752881
    申请日:2017-04-04
    公开日:2018-10-05
    发明作者:Christine Hennebert；Alexandre MACABIES
    申请人:Commissariat a lEnergie Atomique CEA；Commissariat a lEnergie Atomique et aux Energies Alternatives CEA；
    IPC主号:
    专利说明:

    Holder (s): ATOMIC AND ALTERNATIVE ENERGY COMMISSIONER Public establishment.
    Extension request (s)
    Agent (s): BREVALEX.
    (04) SECURE END-TO-END COMMUNICATION FOR MOBILE SENSOR IN AN IOT NETWORK.
    FR 3 064 857 - A1 _ The invention relates to an end-to-end communication method between a mobile sensor and a user, the mobile sensor moving within a WSN network, the WSN network comprising a plurality of connected subnets to the Internet through gateways. When the mobile sensor wishes to join a subnetwork, it transmits an association request to the gateway of the subnetwork which relays it to the server via the Internet. The latter communicates to the mobile sensor and to the gateway a temporary encryption key in encrypted form. The gateway can then communicate the security key of the subnet to the mobile sensor, by an encrypted message using the temporary encryption key. The mobile sensor can then communicate with the gateway in a secure manner, at the link level, by means of the subnet security key.
    AppK ,,
    412s
    Heiio / OIS iReiay Hello Dev u | ' HMÀC ^, cU ; Gaç k Ap Denver cncienet, .. j wtn Appn., DIQ Rnc (LinSK A ! With entK, BmpCAD, sing LinSK. deliver RîiC'AppSK ,,) wi: h ΑρρΚ υr l
    Vssijfv pev, (iû $ [Vç, uelnijiunic ^ Vd GaÇ Venf / ÎJMA ^^ iScerrecf,
    Wls-ri Thai Dev T .._ X ~ 421 ^ _ / ~ 422
    White List DeVu-AppKu Dev v - AppK v -vis G; Dev w - AppK w —vis Gst s Dsv z - AppK z -via Gsl B Gai A - LinSK ,, - LinSK „Gat B -L, nSK B UnSK P
    SECURE END-TO-END COMMUNICATION FOR MOBILE SENSOR IN A LOOT NETWORK
    DESCRIPTION
    TECHNICAL AREA
    The object of the present invention relates to security in the field of Internet of Things or loT (Internet ofThings).
    STATE OF THE PRIOR ART
    The appearance of pervasive and low-speed radio technologies, adapted to autonomous objects and with low energy consumption, has recently enabled the development of the Internet of Things (loT). The IoT allows a user to access information, also called resources, from sensors or actuators, often distant and with low autonomy. The current scheme consists of virtualizing these resources in a gateway (gotewoy) or a server, connected to the Internet or to the infrastructure.
    End-to-end security, that is to say from user to resource, is in fact ensured between the user and the element virtualizing the resource on the one hand, and, on the other hand, between the element virtualizing the resource and the resource itself.
    The gateway allows the continuity of communications between the domain of the sensor subnet and the domain of the Internet, ensuring the interoperability of communication protocols. However, it does not guarantee the interoperability of security protocols, resulting in a security discontinuity at the gateway level.
    In practice, the gateway hosts different security keys which ensure confidentiality and integrity on the one hand with the end user on the Internet side, and on the other hand with the sensor network. These security keys are provided by a server located in the "Cloud", which may also have a list of devices authorized to communicate on the network (white list).
    The provision of security keys to the gateway is well suited to cases where the sensors are fixed devices, in other words belong to one and the same sub-network over time. On the other hand, when these sensors are mobile and pass from one sub-network to another, by successively connecting to different gateways during their movement, the management of communications security becomes significantly more complex.
    The situation of a sensor moving in a WSN network has been illustrated in Fig. 1. This figure shows a mobile sensor, 110, moving from one subnet 120 to another subnet 130. The subnet 120 (resp. 130) is connected to the Internet via the gateway 125 (resp. 135). The gateway 125 (resp. 135) is itself in communication with a server, 140, called the "cloud" server by a secure IP connection. The access of a user, 150, to the resource of the mobile sensor 110 is done via the server 140 and the gateway, 125.
    The WSN can be a ZigBee network or an LPWAN (Low Power Wide-Area Network), for example a LoRaWAN (Long Range LPWAN) network.
    The ZigBee standard offers the possibility of managing communications security at the network layer, also known as NTW (ZigBee Network Layer) or at the application layer, also called APS (ZigBee Application Sub-Layer). However, the standard is silent on security management at the link layer level (IEEE
    802.15.4 Physical Layer), a fortiori in a situation of mobility and on the distribution of secret security keys.
    The LoRaWAN protocol does not provide for more security management at the link layer (Lora MAC) level, nor for management of secret keys.
    However, it was proposed in the article by R. Miller entitled “LoRa Security Building a secure LoRa solution” published in MWR Labs Whitepaper, a procedure for distributing secret keys in a LoRa network. In particular, when a sensor (node) wishes to join such a network, it initiates a procedure called activation or OTAA (OverThe-Air-Activation). It is assumed that each node is equipped with a unique symmetric secret key (AppKey). This procedure consists of an exchange of messages between the node and the server via the gateway. It begins with the sending of a join request comprising a MAC header (MHDR), a sensor owner identifier (AppEUI), a sensor identifier (DevEUI) and a nonce (DevNonce) generated by the sensor. The access request is signed by hashing the access request using the AppKey secret key, this signature serving as message authentication code or MIC (Message Integrity Code)
    The access request thus signed is transmitted to the LoRa network server, which verifies the authenticity of the message using the AppKey. If successful, the cloud server responds to the sensor with an accept-accept message. To do this, the server generates a new nonce (AppNonce) as well as two secret keys NwkSKey (Network Session Key) and AppSKey (Application Session Key) corresponding respectively to the network layer and to the application layer. These keys are generated by encrypting using the AppKey, a data sequence obtained by concatenating a predetermined value, the nonce generated by the AppNonce server, an identifier of the LoRa network, NetlD, and the nonce generated by the sensor, DevNonce. The keys thus generated are transmitted to the sensor.
    The acceptance message includes the nonce AppNonce, the address of the recipient device, DevAddr, as well as certain physical parameters. The message is also signed using the AppKey. Upon receipt, the sensor decrypts the acceptance message and verifies the MIC code using the AppKey. If successful, the sensor generates the NwkSKey and AppSKey keys from the AppNonce value contained in the acceptance message.
    However, the solution recommended in the article by R. Miller cited above is not entirely satisfactory. Indeed, the header of a MAC frame (MHDR) on the side of the LoRa network does not have to be known beyond the gateway, in particular by the cloud server. The server therefore does not have the possibility in practice of verifying the authenticity of the access request. In addition, any sensor can connect to the cloud server using any gateway. There is therefore no security ensured at the link level in the subnetwork, downstream of the LoRa gateway.
    The aim of the present invention is therefore to propose a method making it possible to effectively secure the communication between the sensor of the WSN network and the user, from end to end at the link level, including when the sensor is in a mobility situation.
    STATEMENT OF THE INVENTION
    The present invention is defined by a method of secure end-to-end communication between a mobile sensor and a user, the mobile sensor moving within a WSN network, said WSN network comprising at least one subnet connected to the Internet at by means of a gateway, said gateway being connected via the Internet to a server managing said WSN network, in which, when said mobile sensor transmits an association request to the gateway, the latter relays it to the server and:
    - the server generates a temporary encryption key and communicates it in encrypted form to the gateway as well as to the sensor;
    - the gateway transmits to the mobile sensor, a subnetwork security key intended to secure, at the link level, the transmissions within the subnetwork, said subnetwork security key being transmitted to the mobile sensor in encrypted form the temporary encryption key;
    - Said mobile sensor transmits to the gateway an acknowledgment message, encrypted by means of said subnet security key.
    The server advantageously has a white list containing the identifiers of the sensors authorized to connect 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 the nonce thus concatenated by the security key of the mobile sensor.
    Preferably, on receipt of the association request, the server, after verifying the integrity of the request, encrypts the temporary encryption key using the gateway security key to generate a first message and using 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 using the gateway security key.
    Advantageously, the first set of concatenated information is signed by means of a signature key of the gateway and the signature is concatenated with the first set of concatenated information previously encrypted by means of the security key of the gateway.
    The gateway signature key can be chosen identical to the gateway security key.
    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 using the mobile sensor security key.
    Advantageously, the second set of concatenated information is signed by means of a signature key of the mobile sensor and the signature thus obtained is concatenated with the second set of concatenated information previously encrypted by means of the security key of the mobile sensor.
    The mobile sensor signature key can be chosen identical to the mobile sensor security key.
    The gateway can also transmit to the sensor a third message containing the subnet key encrypted by the temporary encryption key, the third message being transmitted at the application level or at the network level.
    The third message then contains a concatenation of the gateway identifier, the identifier of the mobile sensor, the nonce and the subnet key.
    When the server detects that a sensor in the subnet no longer responds to requests from 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 subnet. in encrypted form with the security key of this sensor or a session key previously exchanged between the gateway and this sensor.
    The server can also transmit to the gateway a request for renewal of the subnet key to the gateway, said request for renewal containing the new temporary encryption key, in encrypted form with the gateway security key.
    Finally, when the gateway has received the server renewal request, it can generate a new subnet key and broadcast it to the subnet sensor in the form of a message encrypted by the new temporary encryption key. .
    BRIEF DESCRIPTION OF THE DRAWINGS
    Other characteristics and advantages of the invention will appear on reading a preferred embodiment of the invention, with reference to the attached figures among which:
    Fig. 1, already described, schematically represents the situation of a sensor moving within a WSN network;
    Fig. 2 schematically represents the different protocol layers involved in communication between a user and a sensor in the situation in FIG. 1;
    Fig. 3 schematically represents the distribution of secret keys in a secure end-to-end communication method according to an embodiment of the invention;
    Fig. 4 schematically represents a secure association process of a sensor in a secure end-to-end communication method according to an embodiment of the invention;
    Fig. 5 schematically represents a process for renewing / revoking the link key in a secure end-to-end communication method according to an embodiment of the invention.
    DETAILED PRESENTATION OF PARTICULAR EMBODIMENTS
    We again consider a WSN network, i.e. a multi-hop (multi-hop) wireless sensor network as shown in Fig. 1. This network obeys a standard of the Internet of Things or loT, it can be for example a ZigBee network, a 6L0WPAN network or even a LoRaWAN network. This network comprises a plurality of subnets, each subnetwork being connected to the Internet by means of a gateway, each gateway being connected to the server (cloud server) managing the network.
    The WSN network sensors have an operating system, such as Contiki (version 3.x), used to manage security keys at the link layer (MAC layer) of the OSI model. Each gateway ensures the interoperability of the communication protocols between the WSN network and the Internet. It also hosts an operating system for managing security keys at the link level, such as for example a Linux kernel (version 4.4) to communicate securely with the sensor network. The end user accesses the resources provided by the sensors via the Internet.
    It is assumed that each sensor in the WSN network is equipped with a security key (for example a symmetric 128-bit key) stored in a “read only” memory of the FLASH, ROM or EPROM type, if possible secure. In the following, we will note ΑρρΚ υ the security key belonging to the sensor having the identifier Dev v . The security key is a secret key in the sense that it is known only to the Dev v sensor and to the server managing the WSN network. It is used at the application level in communications between the Dev v sensor and the server, or even the end user.
    Likewise, each gateway is identified by an identifier and is equipped with a security key at link level. This security key is a secret key insofar as it is known only to the gateway and to the sensors of the subnet connected to it. In the following, we will note LinSK A , the gateway security key having the identifier Gat A. In other words, the LinSK security key A ensures the security of communications (confidentiality, integrity and authentication) at the link level inside subnet A.
    Fig. 2 schematically represents the different protocol layers involved in communication between a user and a sensor in the situation in FIG. 1.
    In 210, the protocol stack operating in the Internet domain (for example at the server level) has been designated, in 220 the protocol stack operating at the gateway level and in 230 the protocol stack operating at the WSN network level (for example, example at the mobile sensor).
    It was assumed here that the transmission in the Internet domain between the server and the gateway was carried out by an Ethernet link (PHY and MAC layer) and that the transmission in the WSN network was carried out according to the IEEE 802.15.4 protocol (PHY and MAC). Transmission at the network level is done using the IPv4 or IPv6 protocol in the Internet domain and according to the IPv6 / 6L0WPAN protocol on the WSN network side. The gateway provides protocol conversion up to the network level and is transparent to the upper protocol layers.
    There is shown in FIG. 3 the distribution of secret keys in a secure end-to-end communication method according to an embodiment of the invention.
    The Dev v sensor of subnet A is equipped with the AppK v secret key. Similarly, the Dev v sensor seeking to join the subnetwork A is equipped with the secret key ^ ρρκ υ
    The Dev w and Dev z sensors of subnet B are respectively equipped with the secret keys AppK w and AppK z .
    The Gat, and Gat B gateways (or equivalent subnets A and B) are equipped with LinSK A and LinSK B security keys respectively.
    The cloud server, manager of the WSN network, has a white list of pairs of identifiers for authorized devices and their corresponding secret keys. In the illustrated case, this white list includes the identifiers of the gateways (Gat ,, Gat B ) respectively associated with their respective security keys (LinSK A , LinSK B ) and, for each gateway (or equivalently for each subnet (A, B)), the identifiers of the sensors of the subnetwork in question associated with their respective security keys. It will in fact be noted that the entry in the white list relating to a sensor (for example Dev v ) of a subnetwork corresponds to a triplet consisting of the identifier of this sensor, its security key (AppK v ) and the gateway identifier (Gat A ) of the subnetwork to which it belongs. In other words, a communication between the Dev v sensor and the server will only be authorized and secured with the AppK v key insofar as it will be established via the gateway of the subnetwork in which the sensor is registered. In the case where the sensor is a mobile sensor, only the pair of the identifier (Dev v ) and its security key (ΑρρΚ υ ) is stored in the server's white list.
    Fig. 4 schematically represents a process for the secure association of a sensor with a sub-network, in the context of an embodiment of the invention.
    It is assumed that a mobile sensor (for example Dev v in Fig. 3) wishes to join a secure subnetwork.
    The detail of the association process has been shown in Fig. 4 if the WSN network complies with the ZigBee standard. It is however clear to a person skilled in the art that this association process applies in an equivalent manner to a 6L0WPAN network or a LoRaWAN network.
    ίο
    In a first phase, the Dev v mobile sensor obtains from the server a temporary key allowing it to communicate in a secure manner with the gateway of the subnetwork it wishes to join.
    More specifically, the mobile sensor Dev, transmits in 411 an association request (“Hello” message) to the gateway of the subnetwork, via an insecure channel. This message, transmitted at the application layer level (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 using its security key (ΑρρΚ υ ). The signature can for example be an authentication code of a keyed-Hosh Message Authentication Code (HMAC). Thus, the payload of the association request is given by:
    request APS _ PLD = Dev v DevNonce HMAC [ΑρρΚ υ , Dev v DevNonce} (1) where HMAC (AppK P , De p DevNonce} represents the signature of Dev v DevNonce by means of security key, ΑρρΚ υ .
    In step 412, the gateway relays the association request to the network management server by adding its gateway identifier, Gat A. The APS _ PLD request payload, on the other hand, is relayed transparently by the gateway since it is located at the application level. The message relayed by the gateway to the server can be protected by TLS encryption.
    Upon receipt of the message thus relayed, the integrity and authenticity of the message are verified by the server by means of the signature (HMAC). More precisely, the server calculates the signature of Dev v DevNonce from the security key ΑρρΚ υ stored in its list and compares it with the signature contained in the request request APS _ PLD .
    The server also verifies that the Dev v sensor requests to join the subnetwork A, from the identifier of the gateway Gat A , attached to the relayed message.
    The server then generates a temporary encryption key, noted EncK temp , intended to secure the communication between the sensor and the gateway. This temporary key is transmitted on the one hand to the Gat gateway, and, on the other hand, to the Dev v sensor. More specifically, the server encrypts the temporary EncK temp key using the gateway security key, AppK A (contained in the server's whitelist), and transmits it in 421 to the gateway in a first message, key - temp Ga ' A. Similarly, the server encrypts the temporary EncK temp key using the sensor security key, AppK v , (also contained in the server's white list) and transmits it in 422 to the Dev v sensor, in a second message key- temp DeVu . The key-temp Ga ' A and key-temp DeVu messages are transmitted at the application layer (APS layer in the case of ZigBee).
    Preferably, the server attached to the temporary key EncK temp contained in the key -temp Ga ' A and key-temp DeVu messages , the DevNonce nonce previously received in the sensor association request, to avoid replay attacks (replay attack), as well as the identifiers of the Gat gateway, and of the Dev sensor. In this case, the payload of the first and second messages can be expressed as follows:
    key -temp G Ap A _ PLD = Encrypt ^ AppK A , Gat A Dev i: DevNonce EncK temp j (2-1) and key -temp A pg- PLD = Encrypt ^ AppK v , Gat A Dev i : ^ DevNonce ^ EncK temp j (2-2) where Encrypt (AppK A , X) and Encrypt (AppK v , X) represent respectively the encryption of X by the gateway security key, AppK A , and the key of sensor security, AppK v and X = Gat A Dev u ^ DevNonce ^ EncK temp indicates the concatenation of the data Gat ,, Dev ,,, DevNonce and EncK,
    At 'U' temp
    If necessary, the server can add to the payload (key -temp G A a / * _ PLD , key ~ temp ^ _ PLD ) a signature ensuring its integrity, if the communication protocol does not ensure it itself intrinsically. For example, this signature can be obtained in the form of an HMAC code, a MAC code (Message Authentication Code) or a MIC code (Message Integrity Code). In the case of an HMAC code, the payloads of the first and second messages can be expressed as follows:
    key -temp ^ _ PLD = Encrypt (AppK A , X) HMAC (AppK A , X) (3-1) key - temp A p S u _ PLD = Encrypt (AppK f ,, X) ^ HMAC (AppK f , | X) (3-2)
    On reception, the gateway Gat A and the sensor De g decrypt the content of the first and second messages using their respective security keys, then check, if necessary, the integrity of the payload using the signature.
    At this stage, the gateway Gat A and the sensor De g have a shared common secret key, EncK temp (typically of 128 bits), allowing them to establish a secure channel between them, at the link level.
    In a second phase, the gateway transmits the security key of the subnetwork to the mobile sensor, this transmission being secured by the temporary encryption key, EncK temp , previously supplied by the server to the gateway and to the sensor in question.
    More precisely, in step 431, the gateway Gat, uses the temporary key EncK temp to transmit to the sensor Dev v , the security key of the subnetwork, LinSK A.
    As indicated previously, this key is intended to protect the transmissions within the subnetwork A, at the level of the link layer.
    More specifically, the Gat A gateway transmits encrypted information
    Encrypt [EncK temp , LinSK A } to the sensor De p, either in the payload of a message at application level, or in the payload of a message at network level, so that it can be routed in the sub-network (if necessary in several "hops") to the sensor. The application level message is for example in the form of a DIO control message (DODAG Information Object where DODAG stands for Destination Oriented Direct Acyclic Graph) of the RPL routing protocol. Recall that RPL specifies a routing protocol adapted to the needs of IPv6 communications over low power and lossy networks.
    As before, the gateway can add to the encrypted information, EncryptiEncK temp , LinSK A X the nonce DevNonce as well as the identifiers of the gateway Gat A and the sensor De p.
    For example, if the transmission is carried out at the application level, the payload can be expressed in the form:
    key A ps-pLD = Encrypt (EncK temp , Gat A | Dev v | DevNonce | LinSK A ) (4) with the same notation conventions as above. The inclusion of Dev v and DevNonce in the payload makes it possible to trace the process, in other words to indicate that the subnetwork key transmitted in step 431 does indeed follow the association request launched by the sensor, thus avoiding any ambiguity in the case where several sensors join the sub-network simultaneously.
    If necessary, the Gat A gateway can add a signature (HMAC, MAC, MIC) to the payload. So when the signature is an HMAC signature, the payload becomes:
    key aps-PLD Encrypt (EncK, mr , K) | HM4 C (, F) (5) with Y = Gat A Dev v DevNonce LinSK A.
    Alternatively, instead of transmitting a single LinSK A subnet key, the gateway may transmit two separate keys LinSK and LinSK 1 ,, one for encrypting messages (at link level) and the other for sign.
    In all cases, the sensor Dev v deciphers the payload key ^ _ PLD of the message by means of the temporary key EncK temp previously received, then verifies if necessary the integrity of the payload by means of the signature. If the message is intact, the subnet security key, LinSK A , is stored in the RAM of the sensor.
    The sensor De p then transmits at 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 using the LinSK A subnet security key.
    When the sensor moves from one sub-network to another, the old sub-network key stored in the RAM 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 that joins the subnet.
    If the sensor does not yet have a session key to communicate data at the application level, the cloud server sends one in 440 which it will keep on the move. This key, noted AppSK v in FIG. 4, is transmitted to the sensor in the same way as the temporary key, EncK temp . The sensor then stores it in its RAM and the cloud server keeps it in its white list for future exchanges.
    Fig. 5 schematically represents a process for renewing / revoking a subnet security key in a secure end-to-end communication method according to an embodiment of the invention.
    This subnet security key renewal process is launched at regular intervals or when an event occurs depending on the degree of security required. For example, it could be launched each time a sensor no longer responds to requests from the server, either that the latter has left the subnet, or that its battery is exhausted.
    The purpose of renewing the subnet security key is to counter 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 De y no longer responds to its requests. He then decides to renew the key of the subnetwork B with which he was associated. After renewal of this key, the Dev v sensor will de facto be removed from the sub-network insofar as it does not have the new key.
    In step 511, the server transmits to each sensor of the sub-network B (only two sensors Dev z and Dev w of this sub-network have been shown by way of example), a new temporary key EncK temp '·
    This new temporary key is transmitted in encrypted form using the sensor security key (AppK w , AppK z ) or its session key (AppSK w , AppSK z }.
    For example, the server transmits to the Dev w sensor an application level message, temp _key B , containing the following payload:
    temp _ key B APS_ PLD = Encrypt (AppK w , Gat B Dev w | AppNonce EncK temp 'j (6-D or, when the session key is used:
    temp _ key APS _ PLD = Encrypt (AppSK w , Gat B Dev w | AppNonce EncK temp 'j (6-2) with the same notation conventions as before. In particular, X' = Gat B Dev w AppNonce EncK temp 'represents the concatenation of the identifier of the Gat B gateway, the identifier of the recipient sensor, Dev w , a server-generated nonce, AppNonce, and the temporary key EncK temp '. nonce allows you to trace the exchange by being included later in the acknowledgment message from the sensor £) < ν ψ .
    Preferably, the server attached to the payload has a signature (HMAC, MAC, MIC). So when the signature is an HMAC signature, the payload becomes:
    temp _key B APS_ PLD = Encrypt (AppK w , X ') ElMAC (AppK w , X'} (7-1) or, when the session key is used:
    temp _key B APS_ PLD = Encrypt (AppSK w , X '} HMAC {AppSK w , X') (7-2)
    Upon receipt of the message, the sensor decrypts the payload using its security key AppK w or its session key AppSK w and verifies its integrity by means of the signature. It extracts from the payload the temporary key EncK temp 'and the nonce AppNonce.
    In step 512, each sensor of the subnetwork B having received the temporary key EncK temp 'transmits an acknowledgment message to the server by incorporating therein its identifier and the previously received AppNonce nonce. Thus, the acknowledgment message ack _new _key w returned by the sensor contains the payload:
    ack _temp _ key APS _ PLD = Encrypt (AppK w , ACK Gat B E) ev w | AppNonce} (8-1) or, when the session key is used:
    ack _temp _key ^ PS _ PLD = Encrypt [AppSK w , ACK Gat B E) ev w | AppNonce} (8-2)
    Again, the sensor can add a signature (HMAC, MAC, MIC) to the payload to allow verification of the integrity of the acknowledgment message by the server.
    Once the server has received all the acknowledgment messages, it sends at 520 to the gateway Gat B a request to renew the security key of subnet B, renew _key B. This request contains the temporary EncK temp 'key and can be transmitted via the secure https protocol or even by encrypting the payload with the key
    AppK B.
    The Gat B gateway then generates a new subnet security key, LinSK B 'and broadcasts it in 530 to the sensors of the subnet in the form of a message encrypted by the temporary key EncK temp ', broadcast _key B. The message can be transmitted at the link, network or application level.
    The payload of the message broadcast by the Gat B gateway, broadcast_key B , can be expressed in the form:
    broadcast _ key B = Encrypt {EncK Gat B LinSK B ') (9)
    If necessary, a nonce can be generated by the gateway and added to the encryption argument for the purposes of acknowledgment. In addition, the payload can still be signed, so that its integrity can be checked at the level of the sensors, and in particular that the new LinSK key B 'is correct.
    The broadcast_key B message is propagated in the subnet by hopping from one sensor to another.
    Once each sensor has received the broadcast message _key B , it decrypts the content and writes down the value of the new key. It then returns at 540 an acknowledgment message to the gateway Gat B , then proceeds to replace its subnet security key stored in its RAM.
    Once the Gat B gateway has received all the acknowledgments, communications between the sensors of subnet B and the server (or the end user) can resume.
    In practice, there will always be sensors that will not respond. It can be envisaged to broadcast the broadcast message _key B again if this message or the corresponding acknowledgment is lost. However, if the sensor still does not respond after a fixed number of requests, the security key of the subnetwork is updated for all the sensors of the subnetwork having responded by acknowledgment. For others, a secure association process can be initiated when they are ready to join a subnet.
    In the description of both the association process and the renewal of the subnet security key, it was assumed that the gateway security key and the mobile sensor security key could be used not only for message encryption but also at their signing. Alternatively, the gateway and / or the mobile sensor may each have a security key (for encryption) and a key for signing. The security keys and the signature keys are then stored in the
    0 white list of the server in relation to the identifiers of the corresponding devices (gateway, mobile sensor).
    权利要求:
    Claims (15)
    [1" id="c-fr-0001]
    1. Method for secure end-to-end communication between a mobile sensor and a user, the mobile sensor moving within a WSN network, said WSN network comprising at least one subnet connected to the Internet by means of a gateway , said gateway being connected via the Internet to a server managing said WSN network, characterized in that when said mobile sensor transmits an association request to the gateway (411), the latter relays it to the server (412) and:
    the server generates a temporary encryption key (EncK temp ) and communicates it in encrypted form to the gateway (421) as well as to the sensor (422);
    the gateway transmits (431) to the mobile sensor, a subnetwork security key intended to secure, at the link level, the transmissions within the subnetwork, said subnetwork security key being transmitted to the mobile sensor in encrypted form by the temporary encryption key;
    said mobile sensor transmits to the gateway an acknowledgment message (432), encrypted by means of said subnet security key.
    [2" id="c-fr-0002]
    2. End-to-end communication method according to claim 1, characterized in that the server has a white list containing the identifiers of the sensors authorized to connect via said gateway, associated with their respective security keys, as well as the identifier of said gateway [Gat A ) associated with its security key.
    [3" id="c-fr-0003]
    3. A secure end-to-end communication method according to claim 2, characterized in that the mobile sensor has an identifier [Dev v ) and its own security key [AppK v ), and that, to form said request association, it generates a nonce (DevNonce), 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 key of mobile sensor security.
    [4" id="c-fr-0004]
    4. A secure end-to-end communication method according to claim 3, characterized in that, on receipt of the association request, the server, after verifying the integrity of the request, encrypts the temporary encryption key (EncK temp ) using the gateway security key (AppK A ) to generate a first message (key-temp Ga ' A ) and using the mobile sensor security key to generate a second message (key-temp DeVu ), the first and second messages being respectively transmitted (421,422) to the gateway and to the mobile sensor at the application layer.
    [5" id="c-fr-0005]
    5. A secure end-to-end communication method according to claim 4, characterized in that the first message (key -temp Ga ' A ) is obtained by concatenating the identifier of the gateway (Gat.), The identifier of the sensor mobile (Dev u ), nonce (DevNonce) and said temporary encryption key (EncK temp ) to form a first set of concatenated information, said first set of concatenated information being encrypted using the gateway security key (AppK A ).
    [6" id="c-fr-0006]
    6. A secure end-to-end communication method according to claim 5, characterized in that the first set of concatenated information is signed by means of a gateway signature key and that the signature is concatenated to the first set of concatenated information previously encrypted using the gateway security key (AppK A ).
    [7" id="c-fr-0007]
    7. A secure end-to-end communication method according to claim 6, characterized in that the gateway signature key is identical to the gateway security key.
    [8" id="c-fr-0008]
    8. A secure end-to-end communication method according to claim 4, characterized in that the second message (key -temp DeVu ) is obtained by concatenating the identifier of the gateway (Gat.), The identifier of the mobile sensor ( Dev u ), the nonce {DevNonce} and said temporary encryption key {EncK temp } to form a second set of concatenated information, said second set of concatenated information being encrypted using the security key of the mobile sensor (ΑρρΚ ν ).
    [9" id="c-fr-0009]
    9. A secure end-to-end communication method according to claim 8, characterized in that the second set of concatenated information is signed by means of a signature key of the mobile sensor and that the signature thus obtained is concatenated to the second set concatenated information previously encrypted using the mobile sensor security key (ΑρρΚ ν ).
    [10" id="c-fr-0010]
    10. A secure end-to-end communication method according to claim 9, characterized in that the signature key of the mobile sensor is identical to the security key of the mobile sensor.
    [11" id="c-fr-0011]
    11. A secure end-to-end communication method according to one of claims 4 to 10, characterized in that the gateway transmits to the sensor a third message containing the subnet key {LinSK A } encrypted by the temporary encryption key , the third message being transmitted at the application level or at the network level.
    [12" id="c-fr-0012]
    12. A secure end-to-end communication method according to claim 11, characterized in that the third message contains a concatenation of the identifier of the gateway (Gat.), Of the identifier of the mobile sensor (Dev u ), of the nonce and the subnet key.
    [13" id="c-fr-0013]
    13. A secure end-to-end communication method according to one of the preceding claims, characterized in that, when the server detects that a sensor of the subnetwork no longer responds to requests from the server, or else at regular time intervals , the server generates a new temporary encryption key (EncK temp '), and transmits it (511) to each sensor (Dev z , Dev w ) belonging to the subnet in encrypted form with the security key of this sensor (AppK w , AppK z ) or a session key (AppSK w , AppSK z ) previously exchanged between the gateway and this sensor.
    5
    [14" id="c-fr-0014]
    14. A secure end-to-end communication method according to claim 13, characterized in that the server transmits to the gateway a request for renewal of the subnet key to the gateway (renew _key B ) said renewal request containing the new temporary encryption key (EncK temp '), in encrypted form with the gateway security key (Gat B ).
    [15" id="c-fr-0015]
    15. A secure end-to-end communication method according to claim 14, characterized in that, when the gateway has received the renewal request from the server, this generates a new subnet key (LinSKf) and broadcasts it to the subnet sensor in the form of an encrypted message (broadcast _key B )
    15 by the new temporary encryption key (EncK temp ').
    1/5
    S.61339 ο
    CM
    Ο co
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3386162A1|2018-10-10|Secure end-to-end communication for mobile sensor in an iot network
    US10123257B2|2018-11-06|Wireless extender secure discovery and provisioning
    JP2013520070A|2013-05-30|Discovery of credibility in communication networks
    Kumar et al.2019|Implementation and analysis of QUIC for MQTT
    WO2013143888A1|2013-10-03|Method and system for establishing a session key
    EP2235890B1|2017-06-21|Ip communication system between the ground and a vehicle
    WO2013160140A1|2013-10-31|Method and system for authenticating the nodes of a network
    EP1753173A1|2007-02-14|Access control for a mobile equipment to a communication network based on dynamic modification of access policies
    Tournier et al.2021|A survey of IoT protocols and their security issues through the lens of a generic IoT stack
    EP2156600B1|2019-12-04|Method of distributing an authentication key, corresponding terminal, mobility server and computer programs
    Han et al.2015|Practical security analysis for the constrained node networks: Focusing on the dtls protocol
    EP2186252A2|2010-05-19|Method for distributing cryptographic keys in a communication network
    FR3028369A1|2016-05-13|METHOD AND SYSTEM FOR MANAGING USER IDENTITY TO BE IMPLEMENTED DURING COMMUNICATION BETWEEN TWO WEB BROWSERS
    FR2980938A1|2013-04-05|METHOD FOR FIABILIZING THE CONTINUITY OF COMMUNICATIONS OPERATED FROM A 4G MOBILE TERMINAL CONNECTED TO AN IP INTERCONNECTION NETWORK
    EP3613186B1|2021-01-06|Communication system and method
    FR3069992A1|2019-02-08|SLEEP DENI ATTENDANCE RADIO RECEIVING / RECEIVING DEVICE RESISTANT TO SLEEP DENI ATTACKS
    EP2665224B1|2014-12-24|Method of distributing a digital encryption key to telecommunication terminals
    US20210204114A1|2021-07-01|Systems and methods to support data privacy over a multi-hop network
    KR101594897B1|2016-02-29|Secure Communication System and Method for Building a Secure Communication Session between Lightweight Things
    EP3718372A1|2020-10-07|Method for manufacturing a device comprising a membrane extending over a cavity
    WO2021074412A1|2021-04-22|Method for connecting a communication node, and corresponding communication node
    EP1858224A1|2007-11-21|Method of setting up virtual private networks and remote access control
    FR2901084A1|2007-11-16|User`s identity protecting method for e.g. mobile telephone, involves ensuring protection of identity of client device user, and deriving encryption key from less weightage bits of key generated from premaster secret and random values
    FR2924294A1|2009-05-29|Authentication identifier e.g. medium access control address, and random sequence transmitting method for e.g. portable computer, involves sending authentication request nearer to communicating device by terminal
    FR2900776A1|2007-11-09|METHOD OF SECURING DATA
    同族专利:
    公开号 | 公开日
    US20180288013A1|2018-10-04|
    FR3064857B1|2020-07-03|
    EP3386162A1|2018-10-10|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20080263647A1|2006-07-21|2008-10-23|General Electric Company|System and Method For Providing Network Device Authentication|
    EP2890083A2|2013-12-24|2015-07-01|Samsung Electro-Mechanics Co., Ltd.|Key distribution system and method|
    KR101866977B1|2017-12-27|2018-06-14|부산대학교 산학협력단|System and Method for Interactive Managing Remote Device based on LoRa Communication|
    FR3087311B1|2018-10-16|2020-09-18|Idemia Identity & Security France|PROCESS FOR COMMUNICATING AN OBJECT WITH A NETWORK OF CONNECTED OBJECTS TO SIGNAL THAT A CLONE POTENTIALLY PASSED FOR THE OBJECT IN THE NETWORK|
    WO2020089565A1|2018-10-30|2020-05-07|Airbus Defence And Space Sas|System for improved monitoring of connected sensors|
    FR3087983B1|2018-10-30|2020-11-20|Airbus Defence & Space Sas|IMPROVED SUPERVISION SYSTEM OF CONNECTED SENSORS|
    DE102019120015A1|2019-07-24|2021-01-28|Minol Messtechnik W. Lehmann Gmbh & Co. Kg|Device for home and / or building automation and processes that can be installed on the building side|
    法律状态:
    2018-04-26| PLFP| Fee payment|Year of fee payment: 2 |
    2018-10-05| PLSC| Search report ready|Effective date: 20181005 |
    2019-04-29| PLFP| Fee payment|Year of fee payment: 3 |
    2020-04-30| PLFP| Fee payment|Year of fee payment: 4 |
    2021-04-29| PLFP| Fee payment|Year of fee payment: 5 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1752881A|FR3064857B1|2017-04-04|2017-04-04|SECURE END-TO-END COMMUNICATION FOR MOBILE SENSOR IN AN IOT NETWORK|
    FR1752881|2017-04-04|FR1752881A| FR3064857B1|2017-04-04|2017-04-04|SECURE END-TO-END COMMUNICATION FOR MOBILE SENSOR IN AN IOT NETWORK|
    US15/944,103| US20180288013A1|2017-04-04|2018-04-03|End-to-end secured communication for mobile sensor in an iot network|
    EP18165700.8A| EP3386162A1|2017-04-04|2018-04-04|Secure end-to-end communication for mobile sensor in an iot network|
    [返回顶部]