Brevet FR3064857A1 — publié le 20181005

COMMUNICATION SÉCURISÉE DE BOUT EN BOUT POUR CAPTEUR MOBILE DANS UN RÉSEAU loT DESCRIPTION DOMAINE TECHNIQUE L'objet de la présente invention concerne la sécurité dans le domaine de l'Internet des objets ou loT (Internet of Things). ÉTAT DE LA TECHNIQUE ANTÉRIEURE L'apparition de technologies radio pervasives et à faible débit, adaptées à des objets autonomes et à faible consommation d'énergie, a permis récemment le développement de l'Internet des objets (loT). L'IoT permet à un utilisateur d'accéder à des informations, 15 encore dénommées ressources, issues de capteurs ou d'actionneurs, souvent distants et à faible autonomie. Le schéma retenu actuellement consiste à virtualiser ces ressources dans une passerelle (gateway) ou un serveur, connecté(e) à Internet ou à l'infrastructure. La sécurité de bout en bout (end-to-end), c'est-à-dire de l'utilisateur à la ressource, est assurée en fait entre l'utilisateur et l'élément virtualisant la ressource d'une part et, 20 d'autre part, entre l'élément virtualisant la ressource et la ressource elle-même. La passerelle permet la continuité des communications entre le domaine du sous-réseau de capteurs et le domaine de l'Internet, en assurant l'interopérabilité des protocoles de communication. En revanche, elle ne garantit pas l'interopérabilité des protocoles de sécurité, d'où une discontinuité de sécurité au niveau de la passerelle. 25 En pratique, la passerelle héberge des clés de sécurité différentes qui assurent la confidentialité et l'intégrité d'une part avec l'utilisateur final côté Internet, et d'autre part avec le réseau de capteurs. Ces clés de sécurité sont fournies par un serveur situé dans le « Cloud », pouvant disposer en outre d'une liste des dispositifs autorisés à communiquer sur le réseau (white list). 10 3064857 2 La fourniture de clés de sécurité à la passerelle est bien adaptée aux cas où les capteurs sont des dispositifs fixes, autrement dit appartiennent à un seul et même sous-réseau au cours du temps. En revanche, lorsque ces capteurs sont mobiles et passent d'un sous-réseau à l'autre, en se connectant successivement à différentes passerelles lors de 5 leur déplacement, la gestion de la sécurité des communications devient sensiblement plus complexe. La situation d'un capteur se déplaçant dans un réseau WSN a été illustrée en Fig.1. On a représenté sur cette figure un capteur mobile, 110, se déplaçant d'un sous-réseau 120 à un autre sous-réseau 130. Le sous-réseau 120 (resp. 130) est relié à Internet via la passerelle 125 (resp. 135). La passerelle 125 (resp. 135) est elle-même en communication avec un serveur, 140, dit serveur « cloud » par une connexion IP sécurisée. L'accès d'un utilisateur, 150, à la ressource du capteur mobile 110 se fait via le serveur 140 et la passerelle, 125. Le WSN peut être un réseau ZigBee ou encore un réseau LPWAN (Low Power Wide-Area Network), par exemple un réseau LoRaWAN (Long Range LPWAN). Le standard ZigBee offre la possibilité de gérer la sécurité des communications au niveau de la couche réseau, encore dénommée NTW (ZigBee Network Layer) ou de la couche application, encore dénommée APS (ZigBee Application Sub-Layer). En revanche, le standard est silencieux sur la gestion de la sécurité au niveau de la couche liaison (IEEE 802.15.4 Physical Layer), a fortiori en situation de mobilité et sur la distribution des clés secrètes de sécurité. Le protocole LoRaWAN ne prévoit pas davantage de gestion de la sécurité au niveau de la couche liaison (Lora MAC), ni de gestion des clés secrètes. Il a cependant été proposé dans l'article de R. Miller intitulé « LoRa Security Building a secure LoRa solution » publié dans MWR Labs Whitepaper, une procédure pour distribuer les clés secrètes dans un réseau LoRa. En particulier, lorsqu'un capteur (noeud) souhaite rejoindre un tel réseau, il initie une procédure dite d'activation ou OTAA (OverThe-Air-Activation). On suppose que chaque noeud est équipé d'une clé secrète unique symétrique (AppKey). Cette procédure consiste en un échange de messages entre le noeud 3064857 3 et le serveur via la passerelle. Elle débute par l'envoi d'une demande d'accès (foin request) comprenant un entête MAC (MHDR), un identifiant du propriétaire du capteur (AppEUI), un identifiant du capteur (DevEUI) ainsi qu'un nonce (DevNonce) généré par le capteur. La demande d'accès est signée en hachant la demande d'accès au moyen de la clé secrète 5 AppKey, cette signature servant de code d'authentification de message ou MIC (Message I ntegrity Code) La demande d'accès ainsi signée est transmise au serveur du réseau LoRa qui vérifie l'authenticité du message au moyen de la clé AppKey. En cas de succès, le serveur cloud répond au capteur par un message d'acceptation (join-accept). Pour ce faire, le 10 serveur génère un nouveau nonce (AppNonce) ainsi que deux clés secrètes NwkSKey (Network Session Key) et AppSKey (Application Session Key) correspondant respectivement à la couche réseau et à la couche application. Ces clés sont générées en chiffrant au moyen de la clé AppKey, une séquence de données obtenue par concaténation d'une valeur prédéterminée, du nonce généré par le serveur AppNonce, d'un identifiant du réseau LoRa, 15 NetID, et du nonce généré par le capteur, DevNonce. Les clés ainsi générées sont transmises au capteur. Le message d'acceptation comporte le nonce AppNonce, l'adresse du dispositif destinataire, DevAddr, ainsi que certains paramètres physiques. Le message est également signé au moyen de la clé AppKey. A la réception, le capteur déchiffre le message 20 d'acceptation et vérifie le code MIC au moyen de la clé AppKey. En cas de succès, le capteur génère de son côté les clés NwkSKey et AppSKey à partir de la valeur AppNonce contenue dans le message d'acceptation. Toutefois, la solution préconisée dans l'article de R. Miller précité n'est pas entièrement satisfaisante. En effet, l'entête d'une trame MAC (MHDR) du côté du réseau 25 LoRa n'a pas à être connu au-delà de la passerelle, en particulier par le serveur cloud. Le serveur n'a donc pas la possibilité en pratique de vérifier l'authenticité de la requête d'accès. En outre, n'importe quel capteur peut se connecter au serveur cloud en empruntant n'importe quelle passerelle. Il n'y a donc pas de sécurité assurée au niveau liaison dans le sous-réseau, en aval de la passerelle LoRa. 3064857 4 Le but de la présente invention est par conséquent de proposer une méthode permettant de sécuriser efficacement la communication entre le capteur du réseau WSN et l'utilisateur, de bout en bout au niveau liaison, y compris lorsque le capteur est en situation de mobilité. 5 EXPOSÉ DE L'INVENTION La présente invention est définie par une méthode de communication sécurisée de bout en bout entre un capteur mobile et un utilisateur, le capteur mobile se déplaçant au sein d'un réseau WSN, ledit réseau WSN comprenant au moins un sous-réseau relié à 10 Internet au moyen d'une passerelle, ladite passerelle étant connectée via Internet à un serveur gestionnaire dudit réseau WSN, dans laquelle, lorsque ledit capteur mobile transmet une requête d'association à la passerelle, celle-ci la relaie au serveur et : - le serveur génère une clé de chiffrement temporaire et la communique sous forme chiffrée à la passerelle ainsi qu'au capteur; 15 - la passerelle transmet au capteur mobile, une clé de sécurité de sous-réseau destinée à sécuriser, au niveau liaison, les transmissions au sein du sous-réseau, ladite clé de sécurité de sous-réseau étant transmise au capteur mobile sous forme chiffrée par la clé de chiffrement temporaire ; - ledit capteur mobile transmet à la passerelle un message d'acquittement, chiffré 20 au moyen de ladite clé de sécurité de sous-réseau. Le serveur dispose avantageusement d'une liste blanche contenant les identifiants des capteurs autorisés à se connecter via ladite passerelle, associés à leurs clés de sécurité respectives, ainsi que l'identifiant de ladite passerelle associé à sa clé de sécurité. Le capteur mobile peut disposer d'un identifiant et de sa propre clé de sécurité, et 25 pour former ladite requête d'association, il génère un nonce, ladite requête d'association étant obtenue en concaténant l'identifiant du capteur mobile, le nonce ainsi généré et d'une signature de l'identifiant et du nonce ainsi concaténés par la clé de sécurité du capteur mobile. 3064857 5 De préférence, sur réception de la requête d'association, le serveur, après avoir vérifié l'intégrité de la requête, chiffre la clé de chiffrement temporaire au moyen de la clé de sécurité de la passerelle pour générer un premier message et au moyen de la clé de sécurité du capteur mobile pour générer un second message, les premier et second 5 messages étant respectivement transmis à la passerelle et au capteur mobile au niveau de la couche application. Le premier message est obtenu de préférence en concaténant l'identifiant de la passerelle, l'identifiant du capteur mobile, le nonce et ladite clé de chiffrement temporaire pour former un premier ensemble d'informations concaténées, ledit premier ensemble 10 d'informations concaténées étant chiffré au moyen de la clé de sécurité de la passerelle. Avantageusement, le premier ensemble d'informations concaténées est signé au moyen d'une clé de signature de la passerelle et la signature est concaténée au premier ensemble d'informations concaténées précédemment chiffré au moyen de la clé de sécurité de la passerelle. 15 La clé de signature de la passerelle peut être choisie identique à la clé de sécurité de la passerelle. Le second message est obtenu de préférence en concaténant l'identifiant de la passerelle, l'identifiant du capteur mobile, le nonce et ladite clé de chiffrement temporaire pour former un second ensemble d'informations concaténées, ledit second ensemble 20 d'informations concaténées étant chiffré au moyen de la clé de sécurité du capteur mobile. Avantageusement, le second ensemble d'informations concaténées est signé au moyen d'une clé de signature du capteur mobile et la signature ainsi obtenue est concaténée au second ensemble d'informations concaténées précédemment chiffré au moyen de la clé de sécurité du capteur mobile. 25 La clé de signature du capteur mobile peut être choisie identique à la clé de sécurité du capteur mobile. La passerelle peut en outre transmettre au capteur un troisième message contenant la clé de sous-réseau chiffrée par la clé de chiffrement temporaire, le troisième message étant transmis au niveau application ou au niveau réseau. 3064857 6 Le troisième message contient alors une concaténation de l'identifiant de la passerelle, de l'identifiant du capteur mobile, du nonce et de la clé de sous-réseau. Lorsque le serveur détecte qu'un capteur du sous-réseau ne répond plus aux requêtes du serveur, ou bien à intervalles de temps réguliers, le serveur peut générer une 5 nouvelle clé de chiffrement temporaire, et la transmettre à chaque capteur appartenant au sous-réseau sous forme chiffrée par la clé de sécurité de ce capteur ou d'une clé de session précédemment échangée entre la passerelle et ce capteur. Le serveur peut en outre transmettre à la passerelle une requête de renouvellement de la clé de sous-réseau à la passerelle ladite requête de renouvellement 10 contenant la nouvelle clé de chiffrement temporaire, sous forme chiffrée par la clé de sécurité de la passerelle. Enfin, lorsque la passerelle a reçu la requête de renouvellement du serveur, celle-ci peut générer une nouvelle clé de sous-réseau et la diffuser au capteur de sous-réseau sous la forme d'un message chiffré par la nouvelle clé de chiffrement temporaire. 15 BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention, en faisant référence aux figures jointes parmi lesquelles : 20 La Fig. 1, déjà décrite, représente schématiquement la situation d'un capteur se déplaçant au sein d'un réseau WSN ; La Fig. 2 représente schématiquement les différentes couches de protocole intervenant dans une communication entre un utilisateur et un capteur dans la situation de la Fig. 1; 25 La Fig. 3 représente schématiquement la distribution de clés secrètes dans une méthode de communication sécurisée de bout en bout selon un mode de réalisation de l'invention ; 3064857 7 La Fig. 4 représente schématiquement un processus d'association sécurisé d'un capteur dans une méthode de communication sécurisée de bout en bout selon un mode de réalisation de l'invention ; La Fig. 5 représente schématiquement un processus de renouvellement/ révocation 5 de la clé de liaison dans une méthode de communication sécurisée de bout en bout selon un mode de réalisation de l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS Nous considérons à nouveau un réseau WSN, c'est-à-dire un réseau de capteurs 10 sans fil à sauts multiples (multi-hop) comme représenté en Fig. 1. Ce réseau obéit à un standard de l'Internet des objets ou loT, il peut être par exemple un réseau ZigBee, un réseau 6LoWPAN ou encore un réseau LoRaWAN. Ce réseau comprend une pluralité de sous-réseaux, chaque sous-réseau étant relié à Internet au moyen d'une passerelle, chaque passerelle étant connectée au serveur (serveur cloud) gestionnaire du réseau. 15 Les capteurs du réseau WSN embarquent un système d'exploitation, tel que Contiki (version 3.x), permettant de gérer des clés de sécurité au niveau de la couche liaison (couche MAC) du modèle OSI. Chaque passerelle assure l'interopérabilité des protocoles de communication entre le réseau WSN et Internet. Elle héberge également un système d'exploitation permettant de gérer les clés de sécurité au niveau liaison, tel que par 20 exemple un noyau Linux (version 4.4) pour communiquer de manière sécurisée avec le réseau de capteurs. L'utilisateur final accède aux ressources fournies par les capteurs via Internet. On suppose que chaque capteur du réseau WSN est équipé d'une clé de sécurité (par exemple une clé symétrique de 128 bits) stockée dans une mémoire « morte » de type 25 FLASH, ROM ou EPROM, si possible sécurisée. Dans la suite, nous noterons AppKu la clé de sécurité appartenant au capteur ayant pour identifiant Devu . La clé de sécurité est une clé secrète au sens où elle n'est connue que du capteur Devu et du serveur gestionnaire du réseau WSN. Elle est utilisée au niveau application dans les communications entre le capteur Devu et le serveur, voire l'utilisateur final. 3064857 8 De même, chaque passerelle est identifiée par un identifiant et est équipée d'une clé de sécurité au niveau liaison. Cette clé de sécurité est une clé secrète dans la mesure où elle est connue seulement de la passerelle et des capteurs du sous-réseau qui y sont reliés. Dans la suite, on notera LinSK A, la clé de sécurité de la passerelle ayant pour 5 identifiant Gat A. Autrement dit, la clé de sécurité LinSK A assure la sécurité des communications (confidentialité, intégrité et authentification) au niveau liaison à l'intérieur du sous-réseau A . La Fig. 2 représente schématiquement les différentes couches de protocole 10 intervenant dans une communication entre un utilisateur et un capteur dans la situation de la Fig. 1. On a désigné en 210 la pile de protocole intervenant dans le domaine Internet (par exemple au niveau du serveur), en 220 la pile de protocole intervenant au niveau de la passerelle et en 230 la pile de protocole intervenant au niveau du réseau WSN (par exemple 15 au niveau du capteur mobile). On a supposé ici que la transmission dans le domaine Internet entre le serveur et la passerelle était réalisée par une liaison Ethernet (couche PHY et MAC) et que la transmission dans le réseau WSN était réalisée selon le protocole IEEE 802.15.4 (couches PHY et MAC). La transmission au niveau réseau se fait selon le protocole IPv4 ou IPv6 dans 20 le domaine Internet et selon le protocole IPv6/ 6LoWPAN du côté du réseau WSN. La passerelle assure la conversion de protocole jusqu'au niveau réseau et est transparente pour les couches protocolaires supérieures. On a représenté sur la Fig. 3 la distribution de clés secrètes dans une méthode de 25 communication sécurisée de bout en bout selon un mode de réalisation de l'invention. Le capteur Devv du sous-réseau A est équipé de la clé secrète AppKv. De même, le capteur Devu cherchant à rejoindre le sous-réseau A est équipé de la clé secrète AppKu. 3064857 9 Les capteurs Devw et Devz du sous-réseau B sont respectivement équipés des clés secrètes AppKw et AppKz . Les passerelles GatA et GatB (ou de manière équivalente les sous-réseaux A et B ) sont respectivement équipées de clés de sécurité LinSKA et LinSKB. 5 Le serveur cloud, gestionnaire du réseau WSN, possède une liste blanche (white list) de couples d'identifiants des dispositifs autorisés et de leurs clés secrètes correspondantes. Dans le cas illustré, cette liste blanche comprend les identifiants des passerelles (GatA, GatB) respectivement associés à leurs clés de sécurité respectives (LinSKA,LinSKB) et, pour chaque passerelle (ou de manière équivalente pour chaque sous-réseau ( A ,B)), les 10 identifiants des capteurs du sous-réseau en question associés à leurs clés de sécurité respectives. On notera en fait que l'entrée de la liste blanche relative à un capteur (par exemple Devv) d'un sous-réseau correspond à un triplet constitué de l'identifiant de ce capteur, de sa clé de sécurité (AppKv) et de l'identifiant de la passerelle ( GatA ) du sous-réseau auquel il appartient. Autrement dit, une communication entre le capteur Devv et 15 le serveur ne sera autorisée et sécurisée avec la clé AppKv que dans la mesure où elle sera établie via la passerelle du sous-réseau dans lequel le capteur est enregistré. Dans le cas où le capteur est un capteur mobile, seul le couple de l'identifiant (Devu) et de sa clé de sécurité (AppKu ) est stocké dans la liste blanche du serveur. 20 La Fig. 4 représente schématiquement un processus d'association sécurisé d'un capteur à un sous-réseau, dans le cadre d'un mode de réalisation de l'invention. On suppose qu'un capteur mobile (par exemple Devu dans la Fig. 3) souhaite rejoindre un sous-réseau sécurisé. Le détail du processus d'association a été représenté en Fig. 4 dans le cas où le 25 réseau WSN est conforme au standard ZigBee. Il est cependant clair à l'homme du métier que ce processus d'association s'applique de manière équivalente à un réseau 6LoWPAN ou un réseau LoRaWAN. 3064857 10 Dans une première phase, le capteur mobile Devu se procure auprès du serveur une clé temporaire lui permettant de communiquer de manière sécurisée avec la passerelle du sous-réseau qu'il souhaite rejoindre. Plus précisément, le capteur mobile Devu transmet en 411 une requête 5 d'association (message « Hello ») à la passerelle du sous-réseau, via un canal non sécurisé. Ce message, transmis au niveau de la couche application (APS dans le cas du protocole ZigBee), comprend une charge utile contenant au moins l'identificateur du capteur mobile, un nonce généré par ce dernier et une signature au moyen de sa clé de sécurité (AppKu ). La signature peut être par exemple un code d'authentification d'une empreinte 10 cryptographique HMAC (keyed-Hash Message Authentification Code). Ainsi, la charge utile de la requête d'association est donnée par : request =DevuDevNonceIHMAC(AppKu,DevulDevNonce) (1) 15 où HMAC(AppKu,DevulDevNonce) représente la signature de DevulDevNonce au moyen de clé de sécurité, AppKu . A l'étape 412, la passerelle relaie la requête d'association au serveur gestionnaire du réseau en lui ajoutant son identifiant de passerelle, Gat A. La charge utile requestAps_. est en revanche relayée de manière transparente par la passerelle étant donné qu'elle se 20 situe au niveau applicatif. Le message relayé par la passerelle au serveur peut être protégé par un chiffrement TLS. A la réception du message ainsi relayé, l'intégrité et l'authenticité du message sont vérifiées par le serveur au moyen de la signature (HMAC). Plus précisément, le serveur calcule la signature de DevulDevNonce à partir de la clé de sécurité AppKu stockée dans 25 sa liste et la compare avec la signature contenue dans la requête requestAps_pm. Le serveur vérifie en outre que le capteur Devu demande bien à rejoindre le sous-réseau A , à partir de l'identifiant de la passerelle Gat A, adjoint au message relayé. 3064857 11 Le serveur génère alors une clé de chiffrement temporaire, notée EncK tem , destinée à sécuriser la communication entre le capteur et la passerelle. Cette clé temporaire est transmise d'une part à la passerelle GatA et, d'autre part, au capteur Devu . Plus précisément, le serveur chiffre la clé temporaire EncKtemp au moyen de la clé 5 de sécurité de la passerelle, AppK A (contenue dans la liste blanche du serveur), et la transmet en 421 à la passerelle dans un premier message, key -tempGatA . De même, le serveur chiffre la clé temporaire EncK tem au moyen de la clé de sécurité du capteur, AppKu , (également contenue dans la liste blanche du serveur) et la transmet en 422 au evu G capteur Devu , dans un second message key -tempp . Les messages key -tempatA et 10 key -teMPDevu sont transmis au niveau de la couche application (couche APS dans le cas de ZigBee). De préférence, le serveur adjoint à la clé temporaire EncK tem contenue dans les messages key -temp la requête d'association du capteur, pour éviter les attaques par rejeu (replay attack), ainsi 15 que les identifiants de la passerelle GatA et du capteur Devu . Dans ce cas, la charge utile des premier et second messages peut s'exprimer comme suit : key -teMP AG patsA pu) = Encrypt(AppK A,Gat AIDevuDevNoncelEncKtemp) (2-1) et 20 key -teMP Appevsu ND = Encrypt(AppKu ,Gat AIDevuDevNoncelEncKtemp) (2-2) où Encrypt(AppK A, X) et Encrypt(AppKu ,X) représentent respectivement le chiffrement de X par la clé de sécurité de la passerelle, AppK A, et la clé de sécurité du capteur, AppKu et X = GatAIDev/DevNoncelEncK tem désigne la concaténation des 25 données GatA, Dev, DevNonce et EncKtemp " U GatA et key -teMPDevu , le nonce DevNonce précédemment reçu dans 3064857 12 Le cas échéant, le serveur peut adjoindre à la charge utile (key -temp AG pat,4_pu,, , key - temp AD p"su pm) une signature permettant d'assurer son intégrité, si le protocole de communication ne l'assure pas lui-même de manière intrinsèque. Par exemple, cette signature pourra être obtenue sous la forme d'un code HMAC, d'un code MAC (Message 5 Authentification Code) ou d'un code MIC (Message Integrity Code). Dans le cas d'un code HMAC, les charges utiles des premier et second messages peuvent s'exprimer comme suit : key -temp AGpatsA_pu) = Encrypt (AppK A, X)1HMAC (AppK A, X) (3-1) 10 key -temp AD p'su_pLE, = Encrypt (AppKu ,X)IHMAC (AppKulX) (3-2) A la réception, la passerelle Gat A et le capteur Devu déchiffrent le contenu du premier et du second message au moyen de leurs clés de sécurité respectives, puis vérifient, le cas échéant, l'intégrité de la charge utile au moyen de la signature. 15 A ce stade, la passerelle Gat A et le capteur Devu disposent d'une clé secrète commune partagée, EncK tem (typiquement de 128 bits), leur permettant d'établir un canal sécurisé entre eux, au niveau liaison. Dans une seconde phase, la passerelle transmet au capteur mobile la clé de sécurité 20 du sous réseau, cette transmission étant sécurisée par la clé de chiffrement temporaire, EncKtemp, préalablement fournie par le serveur à la passerelle et au capteur en question. Plus précisément, à l'étape 431, la passerelle Gat A utilise la clé temporaire EncKtemp pour transmettre au capteur Devu , la clé de sécurité du sous-réseau, LinSK A . 25 Comme indiqué précédemment, cette clé est destinée à protéger les transmissions au sein du sous-réseau A, au niveau de la couche liaison. 3064857 13 Plus précisément, la passerelle Gat A transmet l'information chiffrée Encrypt(EncKtemp,LinSK A) au capteur Devu , soit dans la charge utile d'un message au niveau application, soit dans la charge utile d'un message au niveau réseau, de manière à ce qu'elle puisse être routée dans le sous-réseau (le cas échéant en plusieurs « hops ») 5 jusqu'au capteur. Le message au niveau application est par exemple sous la forme d'un message de contrôle DIO (DODAG Information Object où DODAG signifie Destination Oriented Direct Acyclic Graph) du protocole de routage RPL. On rappelle que RPL spécifie un protocole de routage adapté aux besoins des communications IPv6 au-dessus des réseaux de faible puissance et avec perte. 10 Comme précédemment, la passerelle peut adjoindre à l'information chiffrée, Encrypt(EncKtemp,LinSK A), le nonce DevNonce ainsi que les identifiants de la passerelle Gat A et du capteur Devu . Par exemple, si la transmission est effectuée au niveau applicatif, la charge utile peut s'exprimer sous la forme : 15 keyAGpat = Encrypt(EncKte,,Gat AIDevulDevNoncelLinSK A) (4) avec les mêmes conventions de notation que précédemment. L'inclusion de Devu et DevNonce dans la charge utile permet de tracer le processus, autrement dit d'indiquer 20 que la clé de sous-réseau transmise à l'étape 431 fait bien suite à la requête d'association lancée par le capteur, évitant ainsi toute ambiguïté dans le cas où plusieurs capteurs rejoindraient simultanément le sous-réseau. Le cas échéant, la passerelle Gat A peut adjoindre à la charge utile une signature (HMAC, MAC, MIC). Ainsi, lorsque la signature est une signature HMAC, la charge utile 25 devient : key AG pat = Encrypt(EncKtemp,Y)IHMAC(EncKtemp,Y) (5) 3064857 14 avec Y =Gat AIDevulDevNoncelLinSK A . Selon une variante, au lieu de transmettre une seule clé de sous-réseau LinSK A, la passerelle pourra transmettre deux clés distinctes LinSK Al et LinSK A2 , l'une pour chiffrer les messages (au niveau liaison) et l'autre pour les signer. 5 Dans tous les cas, le capteur Devu déchiffre la charge utile keyAGpat pLD du message au moyen de la clé temporaire EncK tem précédemment reçue, puis vérifie le cas échéant l'intégrité de la charge utile au moyen de la signature. Si le message est intègre, la clé de sécurité du sous réseau, LinSK A, est stockée dans la mémoire vive du capteur. Le capteur Devu transmet ensuite en 432 un message d'acquittement à la 10 passerelle, par exemple sous la forme d'un message de contrôle DAO (Destination Advertisement Object). Ce message d'acquittement est chiffré au moyen de la clé de sécurité du sous-réseau LinSK A. Lorsque le capteur se déplace d'un sous-réseau à l'autre, l'ancienne clé de sous- réseau stockée dans la mémoire vive du capteur est remplacée par la clé nouvelle transmise 15 par la passerelle du sous-réseau qu'il vient de rejoindre. Le processus décrit ci-dessus se répète pour chaque nouveau capteur qui rejoint le sous-réseau. Si le capteur ne dispose pas encore de clé de session pour communiquer des données au niveau applicatif, le serveur cloud lui en envoie une en 440 qu'il conservera en 20 mobilité. Cette clé, notée AppSKu en Fig. 4, est transmise au capteur de la même façon que la clé temporaire, EncK tem. Le capteur la stocke alors dans sa mémoire vive et le serveur cloud la conserve dans sa liste blanche pour les échanges futurs. La Fig. 5 représente schématiquement un processus de renouvellement/ révocation 25 de clé de sécurité de sous-réseau dans une méthode de communication sécurisée de bout en bout selon un mode de réalisation de l'invention. Ce processus de renouvellement de la clé de sécurité de sous-réseau est lancé à intervalles réguliers ou bien sur survenance d'un évènement selon le degré de sécurité 3064857 15 requis. Par exemple, il pourra être lancé à chaque fois qu'un capteur ne répond plus aux requêtes du serveur, soit que ce dernier ait quitté le sous-réseau, soit que sa batterie soit épuisée. Le renouvellement de la clé de sécurité de sous-réseau a pour objet de parer une 5 attaque qui consisterait à aller lire cette clé de sécurité dans la mémoire de l'un des capteurs. Dans l'exemple illustré, on suppose que le serveur a détecté que le capteur mobile Devu ne répond plus à ses requêtes. Il décide alors de renouveler la clé du sous-réseau B auquel il était associé. Après renouvellement de cette clé, le capteur Devu sera de facto 10 écarté du sous-réseau dans la mesure où il ne possèdera pas la nouvelle clé. A l'étape 511, le serveur transmet à chaque capteur du sous-réseau B (seuls deux capteurs Devz et Devw de ce sous-réseau ont été représentés à titre d'exemple), une nouvelle clé temporaire EncK tem' . 15 Cette nouvelle clé temporaire est transmise sous forme chiffrée à l'aide de la clé de sécurité du capteur ( AppKw , AppK z) ou de sa clé de session (AppSKw,AppSKz ). Par exemple, le serveur transmet au capteur Devw un message au niveau applicatif, temp keyB , contenant la charge utile suivante : 20 temp keYABps 'D= Encrypt (AppKw ,Gat BIDevwAppNoncelEncK te, ') (6-1) ou bien, lorsque la clé de session est utilisée : 25 temp keYABps 'D= Encrypt (AppSKw ,Gat BIDevwAppNoncelEncK te, ') (6-2) 3064857 16 avec les mêmes conventions de notation que précédemment. En particulier, X '= Gat BIDevwAppNoncelEncK'mp' représente la concaténation de l'identifiant de la passerelle Gat B, de l'identifiant du capteur destinataire, Devw , d'un nonce généré par le serveur, AppNonce, et de la clé temporaire EncK tem' . Le nonce permet de tracer 5 l'échange en étant repris ultérieurement dans le message d'acquittement du capteur Devw . De préférence, le serveur adjoint à la charge utile une signature (HMAC, MAC, MIC). Ainsi, lorsque la signature est une signature HMAC, la charge utile devient : 10 temp keyABps_pu) = Encrypt (AppKw , X ')1HMAC(AppKw , X') (7-1) ou bien, lorsque la clé de session est utilisée : 15 temp key AB ps_pm = Encrypt (AppSKw , X ')1HMAC(AppSKw , X') (7-2) A la réception du message, le capteur déchiffre la charge utile au moyen de sa clé de sécurité AppK w ou de sa clé de session AppSKw et en vérifie l'intégrité au moyen de la signature. Il extrait de la charge utile la clé temporaire EncK tem' et le nonce AppNonce . 20 A l'étape 512, chaque capteur du sous-réseau B ayant reçu la clé temporaire EncK tem' transmet un message d'acquittement au serveur en y incorporant son identifiant et le nonce AppNonce précédemment reçu. Ainsi, le message d'acquittement ack new keyw renvoyé par le capteur contient la charge utile : 25 ack temp keyAWps_pu) = Encrypt (AppKw , ACK1Gat BIDevwlAppNonce) (8-1) ou bien, lorsque la clé de session est utilisée : 3064857 17 ack temp key AwBB_BLD = Encrypt (AppSKw , ACKIGatBIDevw1AppNonce) (8-2) Là encore, le capteur peut adjoindre à la charge utile une signature (HMAC, MAC, MIC) pour 5 permettre une vérification de l'intégrité du message d'acquittement par le serveur. Une fois que le serveur a reçu tous les messages d'acquittement, il envoie en 520 à la passerelle Gat B une requête de renouvellement de la clé de sécurité du sous-réseau B, renew keyB . Cette requête contient la clé temporaire EncKtemp' et peut être 10 transmise via le protocole sécurisé https voire en chiffrant la charge utile avec la clé AppK B . La passerelle Gat B génère alors une nouvelle clé de sécurité de sous-réseau, LinSK B' et la diffuse en 530 aux capteurs du sous-réseau sous la forme d'un message chiffré par la clé temporaire EncKtemp' , broadcast keyB .Le message peut être transmis au 15 niveau liaison, réseau ou application. La charge utile du message diffusé par la passerelle GatB, broadcast keyB , peut s'exprimer sous la forme : broadcast keyB = Encrypt (EncK 'mp',Gat BILinSK B') (9) 20 Le cas échéant, un nonce peut être généré par la passerelle et ajouté à l'argument du chiffrement pour les besoins de l'acquittement. En outre, la charge utile peut encore être signée, de manière à pouvoir vérifier son intégrité au niveau des capteurs, et notamment que la nouvelle clé LinSK B' est correcte. 25 La propagation du message broadcast keyB dans le sous-réseau se fait par saut d'un capteur à l'autre. 3064857 18 Une fois que chaque capteur a reçu le message broadcast keyB , lien déchiffre le contenu et note la valeur de la nouvelle clé. Il renvoie alors en 540 un message d'acquittement à la passerelle GatB, puis procède au remplacement de sa clé de sécurité de sous-réseau stockée dans sa mémoire vive. 5 Une fois que la passerelle GatB a reçu tous les acquittements, les communications entre les capteurs du sous-réseau B et le serveur (ou l'utilisateur final) peuvent reprendre. En pratique, il y aura toujours des capteurs qui ne répondront pas. Il peut être envisagé de diffuser à nouveau le message broadcast keyB au cas où ce message ou bien l'acquittement correspondant se serait perdu. Toutefois, si le capteur ne répond toujours 10 pas au bout d'un nombre fixé de sollicitations, la clé de sécurité du sous-réseau est mise à jour pour tous les capteurs du sous-réseau ayant répondu par acquittement. Pour les autres, un processus sécurisé d'association pourra être initié lorsqu'ils seront prêts à rejoindre un sous-réseau. Dans la description tant du processus d'association que du renouvellement de la 15 clé de sécurité du sous-réseau, on a supposé que la clé de sécurité de la passerelle et la clé de sécurité du capteur mobile pouvaient servir non seulement au chiffrement des messages mais également à leur signature. Alternativement, la passerelle et/ou le capteur mobile pourront disposer chacun d'une clé de sécurité (pour le chiffrement) et d'une clé pour la signature. Les clés de sécurité et les clés de signature sont alors stockées dans la 20 liste blanche du serveur en relation avec les identifiants des dispositifs (passerelle, capteur mobile) correspondants. REVENDICATIONS1. Méthode de communication sécurisée de bout en bout entre un capteur mobile et un utilisateur, le capteur mobile se déplaçant au sein d'un réseau WSN, ledit réseau WSN comprenant au moins un sous-réseau relié à Internet au moyen d'une passerelle, ladite passerelle étant connectée via Internet à un serveur gestionnaire dudit réseau WSN, caractérisée en ce que lorsque ledit capteur mobile transmet une requête d'association à la passerelle (411), celle-ci la relaie au serveur (412) et : le serveur génère une clé de chiffrement temporaire ( EncKtemp) et la communique sous forme chiffrée à la passerelle (421) ainsi qu'au capteur (422); la passerelle transmet (431) au capteur mobile, une clé de sécurité de sous- réseau destinée à sécuriser, au niveau liaison, les transmissions au sein du sous-réseau, ladite clé de sécurité de sous-réseau étant transmise au capteur mobile sous forme chiffrée par la clé de chiffrement temporaire ; - ledit capteur mobile transmet à la passerelle un message d'acquittement (432), chiffré au moyen de ladite clé de sécurité de sous-réseau. 2. Méthode de communication de bout en bout selon la revendication 1, caractérisée en ce que le serveur dispose d'une liste blanche contenant les identifiants des capteurs autorisés à se connecter via ladite passerelle, associés à leurs clés de sécurité respectives, ainsi que l'identifiant de ladite passerelle (GatA) associé à sa clé de sécurité. 3. Méthode de communication sécurisée de bout en bout selon la revendication 2, caractérisée en ce que le capteur mobile dispose d'un identifiant (Devu ) et de sa propre clé de sécurité (AppKu ), et que, pour former ladite requête d'association, il génère un nonce (DevNonce ), ladite requête d'association étant obtenue en concaténant l'identifiant du capteur mobile, le nonce ainsi généré et d'une signature de l'identifiant et du nonce ainsi concaténés par la clé de sécurité du capteur mobile. 3064857 20 4. Méthode de communication sécurisée de bout en bout selon la revendication 3, caractérisée en ce que, sur réception de la requête d'association, le serveur, après avoir vérifié l'intégrité de la requête, chiffre la clé de chiffrement temporaire 5 (EncK tem) au moyen de la clé de sécurité de la passerelle ( AppK A) pour générer un premier message (key -tempGatA ) et au moyen de la clé de sécurité du capteur mobile pour générer un second message (key -terne' ), les premier et second messages étant respectivement transmis (421,422) à la passerelle et au capteur mobile au niveau de la couche application. 10 5. Méthode de communication sécurisée de bout en bout selon la revendication 4, caractérisée en ce que le premier message (key -tempGatA ) est obtenu en concaténant l'identifiant de la passerelle (GatA), l'identifiant du capteur mobile (Devu ), le nonce (DevNonce) et ladite clé de chiffrement temporaire ( EncK tem) pour former un 15 premier ensemble d'informations concaténées, ledit premier ensemble d'informations concaténées étant chiffré au moyen de la clé de sécurité de la passerelle (AppKA ). 6. Méthode de communication sécurisée de bout en bout selon la revendication 5, caractérisée en ce que le premier ensemble d'informations concaténées 20 est signé au moyen d'une clé de signature de la passerelle et que la signature est concaténée au premier ensemble d'informations concaténées précédemment chiffré au moyen de la clé de sécurité de la passerelle (AppKA). 7. Méthode de communication sécurisée de bout en bout selon la 25 revendication 6, caractérisée en ce que la clé de signature de la passerelle est identique à la clé de sécurité de la passerelle. 8. Méthode de communication sécurisée de bout en bout selon la revendication 4, caractérisée en ce que le second message (key -terne ) est obtenu en 3064857 21 concaténant l'identifiant de la passerelle (GatA), l'identifiant du capteur mobile (Devu ), le nonce (DevNonce) et ladite clé de chiffrement temporaire (EncKtemp ) pour former un second ensemble d'informations concaténées, ledit second ensemble d'informations concaténées étant chiffré au moyen de la clé de sécurité du capteur mobile (AppKu ). 5 9. Méthode de communication sécurisée de bout en bout selon la revendication 8, caractérisée en ce que le second ensemble d'informations concaténées est signé au moyen d'une clé de signature du capteur mobile et que la signature ainsi obtenue est concaténée au second ensemble d'informations concaténées précédemment 10 chiffré au moyen de la clé de sécurité du capteur mobile (AppKu ). 10. Méthode de communication sécurisée de bout en bout selon la revendication 9, caractérisée en ce que la clé de signature du capteur mobile est identique à la clé de sécurité du capteur mobile. 15 11. Méthode de communication sécurisée de bout en bout selon l'une des revendications 4 à 10, caractérisée en ce que la passerelle transmet au capteur un troisième message contenant la clé de sous-réseau (LinSK A) chiffrée par la clé de chiffrement temporaire, le troisième message étant transmis au niveau application ou au niveau 20 réseau. 12. Méthode de communication sécurisée de bout en bout selon la revendication 11, caractérisée en ce que le troisième message contient une concaténation de l'identifiant de la passerelle ( GatA ), de l'identifiant du capteur mobile (Devu ), du nonce 25 et de la clé de sous-réseau. 13. Méthode de communication sécurisée de bout en bout selon l'une des revendications précédentes, caractérisée en ce que, lorsque le serveur détecte qu'un capteur du sous-réseau ne répond plus aux requêtes du serveur, ou bien à intervalles de 30 temps réguliers, le serveur génère une nouvelle clé de chiffrement temporaire (EncKtemp ' ), 3064857 22 et la transmet (511) à chaque capteur (Devz , Devw ) appartenant au sous-réseau sous forme chiffrée par la clé de sécurité de ce capteur (AppKw,AppKz ) ou d'une clé de session (AppSKw , AppSK z) précédemment échangée entre la passerelle et ce capteur. 5 14. Méthode de communication sécurisée de bout en bout selon la revendication 13, caractérisée en ce que le serveur transmet à la passerelle une requête de renouvellement de la clé de sous-réseau à la passerelle ( renew keyB) ladite requête de renouvellement contenant la nouvelle clé de chiffrement temporaire (EncKtemp '), sous forme chiffrée par la clé de sécurité de la passerelle ( GatB). 10 15. Méthode de communication sécurisée de bout en bout selon la revendication 14, caractérisée en ce que, lorsque la passerelle a reçu la requête de renouvellement du serveur, celle-ci génère une nouvelle clé de sous-réseau (LinSKB ') et la diffuse au capteur de sous-réseau sous la forme d'un message chiffré (broadcast keyB ) 15 par la nouvelle clé de chiffrement temporaire (EncKtemp 'L