Brevet FR3061618A1 — publié le 20180706

DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne les procédés mis en oeuvre par des dispositifs pour rejoindre un réseau. Elle concerne plus particulièrement des procédés mis en oeuvre par un dispositif et dans un réseau, ainsi qu'une entité électronique associée. L'invention s'applique particulièrement avantageusement en vue de produire des clés (telles que des clés de session) utilisables par la suite pour 10 échanger de manière sécurisée des données dans le réseau. ARRIERE-PLAN TECHNOLOGIQUE Il est connu (par exemple dans la technologie L0RaWAN®) qu'un dispositif électronique puisse rejoindre un réseau afin de pouvoir ultérieurement échanger des données avec un serveur applicatif connecté à ce réseau. 15 Après une phase permettant au dispositif électronique de rejoindre le réseau, le dispositif électronique et le serveur applicatif sont en mesure de produire (chacun de leur côté) une clé de session utilisée par la suite notamment pour chiffrer les échanges de données entre ces deux entités. On prévoit pour ce faire que le dispositif électronique et le serveur 20 applicatif connaissent tous deux un secret partagé, par exemple la clé cryptographique applicative AppKey (pour "Application Key") dans la technologie LoRaWAN®. Lorsque le processus permettant au dispositif électronique de rejoindre le réseau est géré par un serveur de réseau distinct du serveur applicatif, ce 25 processus ne peut aboutir que si le serveur applicatif (qui détient le secret partagé) est disponible, sauf à communiquer le secret partagé au serveur de réseau (ce qui n'est généralement pas souhaitable). OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un procédé mis en 30 oeuvre par un dispositif pour rejoindre un réseau, le dispositif comprenant une mémoire et mémorisant une clé cryptographique applicative dans ladite mémoire, le procédé comprenant les étapes suivantes : - test de l'absence ou de la présence dans la mémoire d'une clé cryptographique associée au réseau ; 3061618 2 - en cas d'absence de la clé cryptographique associée au réseau, émission d'une requête pour rejoindre le réseau et réception en retour de données de dérivation produites par un serveur applicatif et chiffrées au moyen de la clé cryptographique applicative ; 5 - en cas de présence de la clé cryptographique associée au réseau, émission d'une requête pour rejoindre le réseau et réception en retour de données de dérivation produites par un serveur associé au réseau et chiffrées au moyen d'une clé cryptographique de réseau égale à, ou dérivée de, la clé cryptographique associée au réseau. Le dispositif s'adapte ainsi en fonction des données mémorisées dans la mémoire susmentionnée : le processus lui permettant de rejoindre le réseau peut à défaut être mis en oeuvre au moyen de la clé cryptographique applicative ; par contre, si une clé cryptographique associée au réseau est présente, le processus lui permettant de rejoindre le réseau utilise une autre clé cryptographique et peut ainsi aboutir sans nécessiter un accès au serveur applicatif, comme expliqué dans la suite. Le procédé peut comprendre une étape de dérivation d'une clé de session applicative sur la base de la clé cryptographique applicative et des données de dérivation reçues ; cette clé de session applicative pourra être utilisée ultérieurement dans le cadre d'échanges entre le dispositif et le serveur applicatif, par exemple pour chiffrer les données échangées. En cas de présence de la clé cryptographique associée au réseau, le procédé peut par ailleurs comprendre une étape de dérivation d'une clé de session de réseau sur la base de la clé cryptographique de réseau et des données de dérivation reçues ; cette clé de session de réseau pourra être utilisée ultérieurement dans le cadre d'échanges entre le dispositif et le serveur de réseau, par exemple pour chiffrer les données échangées. Le procédé peut par ailleurs comprendre, en cas de présence de la clé cryptographique associée au réseau, une étape de dérivation de la clé cryptographique de réseau sur la base de la clé cryptographique associée au réseau (qui peut alors être une clé maîtresse, comme expliqué dans la suite) et d'un identifiant du réseau. On peut prévoir en outre dans ce cas une étape (préalable à l'étape de dérivation de la clé cryptographique de réseau) de réception de l'identifiant du 3061618 3 réseau en provenance du serveur associé au réseau. Selon une autre possibilité de réalisation, la clé cryptographique de réseau peut être la clé cryptographique associée au réseau (auquel cas cette clé est mémorisée au préalable, par exemple pendant une phase de personnalisation 5 du dispositif, dans la mémoire susmentionnée). On peut prévoir en pratique que le dispositif comprenne une entité électronique sécurisée incluant ladite mémoire. L'invention propose également un procédé mis en oeuvre dans un réseau comprenant un serveur applicatif, un serveur de réseau et un dispositif 10 comprenant une mémoire mémorisant une clé cryptographique applicative, le procédé comprenant les étapes suivantes : - test par le dispositif de l'absence ou de la présence dans la mémoire d'une clé cryptographique associée au réseau ; - en cas d'absence de la clé cryptographique associée au réseau, 15 émission par le dispositif d'une requête pour rejoindre le réseau, production de données de dérivation par le serveur applicatif, chiffrement des données de dérivation par le serveur applicatif au moyen de la clé cryptographique applicative, et réception par le dispositif des données de dérivation chiffrées ; - en cas de présence de la clé cryptographique associée au réseau, 20 émission par le dispositif d'une requête pour rejoindre le réseau, production de données de dérivation par le serveur de réseau, chiffrement des données de dérivation par le serveur de réseau au moyen d'une clé cryptographique de réseau égale à, ou dérivée de, la clé cryptographique associée au réseau, et réception par le dispositif des données de dérivation chiffrées. 25 L'invention propose enfin une entité électronique (par exemple une entité électronique sécurisée) comprenant une mémoire mémorisant une clé cryptographique applicative, un module d'émission d'une requête pour rejoindre un réseau, un mécanisme de test de l'absence ou de la présence dans la mémoire d'une clé cryptographique associée au réseau, et un module de réception conçu 30 pour recevoir, en cas d'absence de la clé cryptographique associée au réseau, des données de dérivation produites par un serveur applicatif et chiffrées au moyen de la clé cryptographique applicative et, en cas de présence de la clé cryptographique associée au réseau, des données de dérivation produites par un serveur associé au réseau et chiffrées au moyen d'une clé cryptographique de 3061618 4 réseau égale à, ou dérivée de, la clé cryptographique associée au réseau. Une telle entité électronique peut également comprendre un module de dérivation d'une clé de session applicative sur la base de la clé cryptographique applicative et des données de dérivation reçues. 5 L'entité électronique peut par ailleurs comprendre un module apte à dériver, en cas de présence de la clé cryptographique associée au réseau, une clé de session de réseau sur la base de la clé cryptographique de réseau et des données de dérivation reçues. L'entité électronique peut aussi comprendre un module apte à dériver, en 10 cas de présence de la clé cryptographique associée au réseau, la clé cryptographique de réseau sur la base de la clé cryptographique associée au réseau et d'un identifiant du réseau. Lorsque l'entité électronique comprend un processeur (par exemple un microprocesseur), le mécanisme et/ou les modules précités peuvent au moins en 15 partie être mis en oeuvre par des instructions exécutables par le processeur et mémorisées dans une mémoire de l'entité électronique. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et 20 comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente schématiquement les éléments principaux d'un système dans lequel peut être mise en oeuvre l'invention ; - la figure 2 présente les données initialement mémorisées dans divers 25 dispositifs du système de la figure 1 ; - la figure 3 représente une première possibilité envisageable pour les étapes d'initiation d'un procédé conforme à l'invention ; - la figure 4 représente une seconde possibilité envisageable pour les étapes d'initiation d'un procédé conforme à l'invention ; 30 - la figure 5 représente des étapes d'un procédé mis en oeuvre dans un premier cas ; et - la figure 6 représente des étapes d'un procédé mis en oeuvre dans un second cas. La figure 1 représente schématiquement les éléments principaux d'un 3061618 5 système dans lequel peut être mise en oeuvre l'invention. Ce système comprend un dispositif électronique 10, une passerelle 5 (ou "gateway selon l'appellation anglo-saxonne), un serveur de réseau 20 et un serveur applicatif 30. 5 Le dispositif électronique 10 comprend un processeur 12 (par exemple un microcontrôleur), une entité électronique 2 et un circuit de communication 14, ici un circuit de communication conçu pour établir une liaison sans fil (i.e. par ondes radio) avec la passerelle 5. Le dispositif électronique 10 est typiquement un objet connecté, tel qu'un 10 dispositif de mesure (par exemple un dispositif de mesure de fourniture d'énergie ou d'eau), un détecteur (tel qu'un détecteur de fumée), un identifiant, ou un terminal monétique. Dans l'exemple décrit, l'entité électronique 2 est une entité électronique sécurisée, en l'occurrence un élément sécurisé (ou SE pour "Secure Element"), 15 réalisé ici sous la forme d'un microcontrôleur. Un tel élément sécurisé peut éventuellement être intégré au dispositif électronique 10, par exemple en étant soudé au sein du dispositif électronique 10 : l'entité électronique 2 est alors de type eSE (pour "embedded Secure Element"). En variante, l'entité électronique 2 pourrait être une carte à microcircuit 20 (par exemple une carte à microcircuit universelle ou UICC pour "Universal Integrated Circuit Card", telle que visée dans la spécification technique ETSI TS 102 221), ou une carte à microcircuit universelle soudée ou eUICC pour "embedded Universal Circuit Card" (telle que décrite dans la norme ETSI TS 103 383). 25 L'entité électronique 2 comprend un processeur (par exemple un microprocesseur) et au moins une mémoire, notamment ici une mémoire non-volatile réinscriptible. Cette mémoire mémorise en particulier des instructions conçues de telle sorte que l'entité électronique 2 puisse mettre en oeuvre certaines étapes au moins des procédés décrits ci-dessous en références aux figures 3 à 6 30 lorsque ces instructions sont exécutées par le processeur de l'entité électronique 2. La mémoire de l'entité électronique 2 mémorise également des données utilisées au cours de son fonctionnement, en particulier certaines au moins des données indiquées en figure 2 (décrite ci-dessous) comme mémorisées au sein du 3061618 6 dispositif électronique 10. Comme déjà indiqué, l'entité électronique 2 est ici sécurisée, c'est-à-dire que cette entité électronique 2 est conçue, du fait de sa construction physique et de la conception des programmes d'ordinateur qu'elle mémorise, de façon à 5 rendre très difficile, voire impossible, pour un attaquant l'accès (par lecture et/ou modification) aux données confidentielles qu'elle mémorise. Ainsi, l'entité électronique 2 présente un niveau de sécurité conforme aux critères communs EAL (pour "Evaluation Assurance Level"), correspondant à la norme ISO 15408, avec un niveau supérieur ou égal à 4, ou à la norme FIPS (pour "Federal 10 Information Processing Standard") 140-2. Comme déjà indiqué, le dispositif électronique 10 peut établir une liaison (ici sans fil) avec la passerelle 5, laquelle est reliée au serveur de réseau 20 (par exemple au moyen d'un réseau local tel qu'un réseau Ethernet ou un réseau local sans fil, parfois dénommé WLAN pour "Wireless Local Area Network") de sorte 15 que le dispositif électronique 10 peut échanger des données avec le serveur de réseau 20. Le dispositif électronique 10, la passerelle 5 et le serveur de réseau 20 sont par exemple agencés selon la technologie LoRaWAN®. Le serveur de réseau 20 est également connecté à un réseau de 20 communication, ici un réseau de communication public I tel que le réseau Internet, auquel est également connecté un serveur applicatif 30. Le serveur applicatif 30 et le dispositif électronique 10 doivent pouvoir échanger des données de manière sécurisée dans le cadre du fonctionnement du dispositif électronique 10, typiquement dans le cadre de l'exécution d'une 25 application par le processeur 12 du dispositif électronique 10. Comme cela ressort de ce qui précède, le dispositif électronique 10 et le serveur applicatif 30 peuvent échanger des données via la passerelle 5, le serveur de réseau 20 et le réseau de communication I. On décrit dans la suite la phase (généralement mise en oeuvre lors de la 30 première connexion du dispositif électronique 10 au serveur de réseau 20) qui permet au dispositif électronique 10 de rejoindre le réseau comprenant le serveur de réseau 20 et de mettre en place des clés cryptographiques (dénommées clés de session dans la suite) utilisées lors des échanges de données entre le dispositif électronique 10 et le serveur de réseau 20, ainsi qu'entre le dispositif électronique 3061618 7 10 et le serveur applicatif 30, en particulier pour chiffrer les données échangées. La figure 2 présente ainsi les données initialement mémorisées dans le dispositif électronique 10, le serveur de réseau 20 et le serveur applicatif 30, avant cette phase permettant au dispositif électronique 10 de rejoindre le réseau. 5 Le dispositif électronique 10 mémorise ainsi : - un identifiant DevEUI du dispositif électronique 10 ; - un identifiant AppEUI de l'application concernée ; - une clé cryptographique applicative AppKey ; et - éventuellement une clé cryptographique associée au réseau, qui peut 10 être soit une clé maîtresse NwkMKey, soit une clé cryptographique de réseau NwkKey. Comme déjà indiqué, certaines au moins de ces données (en particulier les clés cryptographiques susmentionnées) peuvent être mémorisées au sein de l'entité électronique sécurisée 2 qui équipe le dispositif électronique 10 comme 15 déjà indiqué (ce qui permet d'empêcher tout accès à ces données par une personne malintentionnée). Les données (telles que les clés cryptographiques susmentionnées) mémorisées dans l'entité électronique sécurisée 2 ont par exemple été mémorisées dans une mémoire de l'entité électronique sécurisé 2 au cours d'une 20 étape de préparation de l'entité électronique 2 en vue de son fonctionnement ultérieur (étape couramment dénommée "étape de personnalisation"). Comme cela ressortira des explications données ci-dessous, notamment en référence aux figures 3 et 4, le dispositif électronique 10 (et plus précisément ici l'entité électronique 2) mémorise l'une des clés cryptographiques associées au 25 réseau lorsque l'on souhaite que le procédé mis en oeuvre par le dispositif électronique 10 pour rejoindre le réseau soit conforme au procédé décrit ci-dessous en référence à la figure 5. Le serveur de réseau 20 mémorise quant à lui un identifiant de réseau NetID et, éventuellement (lorsque l'on souhaite que le procédé mis en oeuvre par 30 le dispositif électronique 10 pour rejoindre le réseau puisse être conforme au procédé décrit ci-dessous en référence à la figure 5), une clé cryptographique fournie au réseau, qui peut être soit la clé cryptographique de réseau NwkKey susmentionnée, soit une clé générique de réseau NwkDevKey. On prévoit ici en effet que la clé générique de réseau NwkDevKey est 3061618 8 une clé dérivée sur la base de la clé maîtresse NwkMKey susmentionnée (qui n'est quant à elle pas distribuée au réseau par mesure de confidentialité) et de l'identifiant de réseau NetID : NwkDevKey = dl (NwkMKey, NetID), où dl est une fonction de dérivation. 5 La clé cryptographique de réseau NwkKey est quant à elle dérivée sur la base de la clé générique de réseau NwkDevKey et de l'identifiant DevEUI du dispositif électronique 10 : NwkKey = d2(NwkDevKey, DevEUI), où d2 est une fonction de dérivation. La clé cryptographique de réseau NwkKey est donc liée à un couple dispositif électronique 10 - réseau. 10 Selon les modes de réalisation, lorsque l'on souhaite que le procédé mis en oeuvre par le dispositif électronique 10 pour rejoindre le réseau puisse être conforme au procédé décrit ci-dessous en référence à la figure 5, le serveur de réseau 20 peut ainsi mémoriser soit la clé générique de réseau NwkDevKey (et dériver ensuite la clé cryptographique de réseau NwkKey sur la base de 15 l'identifiant DevEUI), soit une clé cryptographique de réseau NwkKey pour chaque dispositif électronique avec lequel le serveur de réseau 20 est susceptible d'interagir. Le serveur applicatif 30 mémorise l'identifiant AppEUI de l'application et la clé cryptographique applicative AppKey (laquelle est associée au dispositif 20 électronique 10 et à lui seul). En variante, le serveur applicatif 30 pourrait mémoriser une clé applicative générique AppDevKey (en lieu et place de la clé cryptographique applicative AppKey) afin de pouvoir dériver la clé cryptographique applicative AppKey sur la base de la clé applicative générique AppDevKey et de l'identifiant 25 DevEUI du dispositif électronique 10: AppKey = d3(AppDevKey, DevEUI) où d3 est une fonction de dérivation. On prévoit ici que la clé applicative générique AppDevKey et la clé maîtresse NwkMKey soit dérivée à partir d'une même clé racine AppRootKey (connue seulement de l'organisme gérant l'application concernée). Ceci peut 30 simplifier la gestion des clés au sein de cet organisme. La figure 3 représente une première possibilité envisageable pour les étapes d'initiation d'un procédé mis en oeuvre par le dispositif électronique 10 pour rejoindre le réseau. On se place ici dans le cas où la clé cryptographique associée au réseau 3061618 9 éventuellement mémorisée au sein du dispositif électronique 10 (ici dans la mémoire de l'entité électronique 2) est la clé maîtresse NwkMKey. Le procédé de la figure 3 débute par une étape E0 à laquelle le dispositif électronique 10 consulte la mémoire concernée (ici la mémoire de l'entité 5 électronique 2) afin de déterminer (étape El) si cette mémoire contient (Le. mémorise) une clé cryptographique associée au réseau, ici la clé maîtresse NwkMKey. Cette étape peut être réalisée en pratique par exemple en consultant un indicateur dédié mémorisé dans la mémoire concernée. En variante, cette étape peut être réalisée en recherchant dans la mémoire concernée un champ 10 identifié par un en-tête spécifique. Dans l'affirmative, le procédé se poursuit à partir de l'étape E2 décrite plus bas en référence à la figure 5. Dans la négative, le procédé se poursuit à partir de l'étape E50 décrite plus bas en référence à la figure 6. 15 La figure 4 représente une seconde possibilité envisageable pour les étapes d'initiation d'un procédé mis en oeuvre par le dispositif électronique 10 pour rejoindre le réseau. On se place ici dans le cas où la clé cryptographique associée au réseau éventuellement mémorisée au sein du dispositif électronique 10 (ici dans la 20 mémoire de l'entité électronique 2) est la clé cryptographique de réseau NwkKey. Le procédé de la figure 4 débute par une étape E0' à laquelle le dispositif électronique 10 consulte la mémoire concernée (ici la mémoire de l'entité électronique 2) afin de déterminer (étape El') si cette mémoire contient (i.e. mémorise) une clé cryptographique associée au réseau, ici la clé cryptographique 25 de réseau NwkKey. Cette étape peut être réalisée en pratique par exemple en consultant un indicateur dédié mémorisé dans la mémoire concernée. En variante, cette étape peut être réalisée en recherchant dans la mémoire concernée un champ identifié par un en-tête spécifique. Dans l'affirmative, le procédé se poursuit à partir de l'étape E8 décrite 30 plus bas en référence à la figure 5. Dans la négative, le procédé se poursuit à partir de l'étape E50 décrite plus bas en référence à la figure 6. La figure 5 représente les étapes mises en oeuvre dans le cas où une clé cryptographique associée au réseau (en pratique ici le clé maîtresse NwkMKey ou 3061618 10 la clé cryptographique de réseau NwkKey) est présente dans la mémoire concernée au sein du dispositif électronique 10 (ici la mémoire de l'entité électronique 2). Comme cela ressort des explications données ci-dessus en référence aux figures 3 et 4, le procédé décrit ci-dessous débute à l'étape E2 si la 5 clé maîtresse NwkMKey est présente dans la mémoire du dispositif électronique 10 et à l'étape E8 si la clé cryptographique de réseau NwkKey est présente dans la mémoire du dispositif électronique 10. À l'étape E2, l'entité électronique 2 équipant le dispositif électronique 10 émet une demande d'identifiant DMD à destination du serveur de réseau 20 (via la 10 passerelle 5 et au moyen du circuit de communication 14). Le serveur de réseau 20 reçoit cette demande d'identifiant DMD et émet en réponse son identifiant de réseau NetID (étape E4). L'entité électronique 2 reçoit l'identifiant NetID et peut ainsi déterminer à l'étape E6 la clé cryptographique de réseau NwkKey sur la base de la clé 15 maîtresse NwkMKey et de l'identifiant de réseau NetID. Précisément, comme expliqué plus haut, l'entité électronique 2 détermine tout d'abord (ici par dérivation) la clé générique de réseau NwkDevKey sur la base de la clé maîtresse NwkMKey et de l'identifiant de réseau NetID : NwkDevKey = dl (NwkMKey, NetID). 20 L'entité électronique 2 peut alors déterminer la clé cryptographique de réseau NwkKey (ici par dérivation) sur la base de la clé générique de réseau NwkDevKey et de l'identifiant du dispositif électronique DevEUI : NwkKey = d2(NwkDevKey, DevEUI). L'entité électronique 2 procède à l'étape E8 à la détermination de 25 premières données de dérivation DevNonce, ici par tirage aléatoire. L'entité électronique 2 prépare ensuite à l'étape El 0 un message REQ comprenant l'identifiant AppEUI de l'application, l'identifiant DevEUI du dispositif électronique 10 et les premières données de dérivation DevNonce. Ce message REQ forme une requête pour rejoindre le réseau et peut également inclure un en- 30 tête spécifique correspondant. L'entité électronique 2 détermine par ailleurs à l'étape El 0 une valeur d'intégrité MIC1 du message REQ ainsi préparé, par exemple en appliquant au message préparé une fonction cryptographique (ici de type CMAC) utilisant la clé cryptographique de réseau NwkKey. 3 0 6 1 6 1 8 11 On remarque qu'on utilise dans l'exemple décrit ici la même clé cryptographique NwkKey pour le calcul de la valeur d'intégrité MIC1 et pour le chiffrement des données incluant les secondes données de dérivation NwkNonce (ci-dessous à l'étape E20). On pourrait toutefois en variante utiliser deux clés 5 distinctes : une clé spécifique pour le calcul de la valeur d'intégrité MIC1 (utilisée à l'étape E10 qui vient d'être décrite et à l'étape de vérification E14 ci-dessous) et une clé spécifique pour le chiffrement (utilisée à l'étape E20 pour le chiffrement et à l'étape E28 pour le déchiffrement). Ces deux clés distinctes et spécifiques pourraient en pratique être dérivées sur la base d'une même clé racine (et de 10 données de dérivation respectives différentes). L'entité électronique 2 peut également déterminer lors de cette étape E10 une valeur d'intégrité MIC2 du message préparé REQ, par exemple en appliquant au message préparé une fonction cryptographique (ici de type CMAC) utilisant la clé cryptographique applicative AppKey. 15 De même, on utilise ici la même clé cryptographique pour le calcul de la valeur d'intégrité MIC2 et pour la dérivation de la clé de session applicative (voir ci-dessous les étapes E26 et E32). On pourrait toutefois en variante utiliser une clé spécifique (différente de la clé cryptographique applicative AppKey) pour le calcul de la valeur d'intégrité MIC2. 20 Le dispositif électronique 10 peut alors émettre à l'étape E12 le message REQ préparé à l'étape E10 (message de requête pour rejoindre le réseau) et la (ou les) valeur(s) d'intégrité MIC1, MIC2, à destination du serveur de réseau 20. Le serveur de réseau 20 reçoit ces données et procède à des vérifications à l'étape E14. 25 Le serveur de réseau 20 peut ainsi vérifier que les premières données de dérivation DevNonce n'ont pas été préalablement reçues en provenance de ce dispositif électronique 10 (i.e. avec l'identifiant DevEUI également reçu). Le serveur de réseau 20 peut mémoriser pour se faire l'ensemble des données de dérivation reçues lors de précédents échanges. 30 Si les premières données de dérivation DevNonce ont déjà été reçues, il est mis fin au procédé afin d'éviter tout risque d'attaque par rejeu. Si les premières données de dérivation DevNonce n'ont jamais été reçues au préalable, le procédé se poursuit par la vérification de la valeur d'intégrité MIC1 : le serveur de réseau 20 applique au message reçu REQ 3061618 12 (comprenant l'identifiant AppEUI de l'application, l'identifiant DevEUI du dispositif électronique 10 et les premières données de dérivation DevNonce) la fonction cryptographique utilisant la clé cryptographique de réseau NwkKey et vérifie que le résultat obtenu est bien égal à la valeur d'intégrité MIC1 reçue. 5 Dans la négative, il est mis fin au procédé sans que le dispositif électronique 10 n'ait pu rejoindre le réseau. Dans l'affirmative, le procédé se poursuit à l'étape E16. On remarque que, dans le cas où le serveur de réseau 20 mémorise la clé générique de réseau NwkDevKey, il peut obtenir la clé cryptographique de 10 réseau NwkKey par dérivation sur la base de cette clé générique de réseau NwkDevKey et de l'identifiant DevEUI du dispositif électronique 10 (qu'il vient de recevoir). Comme déjà indiqué, on a en effet : NwkKey = d2(NwkDevKey, DevEUI). Le serveur de réseau 20 produit ensuite, ici par tirage aléatoire, des 15 secondes données de dérivation NwkNonce (étape E16). Le serveur de réseau 20 peut également générer à cette étape une adresse DevAddr du dispositif électronique 10 dans le réseau. Le serveur de réseau 20 peut ainsi préparer à l'étape E18 un message ACC d'acceptation du dispositif électronique 10 dans le réseau, ce message ACC 20 comprenant les secondes données de dérivation NwkNonce ainsi qu'éventuellement l'identifiant de réseau NetID et/ou l'adresse DevAddr et/ou un en-tête spécifique. Le serveur de réseau 20 détermine par ailleurs à l'étape E18 une valeur d'intégrité MIC du message d'acceptation ACC ainsi préparé, par exemple en 25 appliquant au message préparé une fonction cryptographique (ici de type CMAC) utilisant la clé cryptographique de réseau NwkKey. Comme déjà indiqué plus haut, on pourrait utiliser en variante une clé spécifique pour le calcul des valeurs d'intégrité, distincte de la clé cryptographique de réseau utilisée ci-dessous pour le chiffrement (étape E20). 30 Le serveur de réseau 20 procède alors à l'étape E20 au chiffrement du message d'acceptation ACC (comprenant les secondes données de dérivation NwkNonce, l'identifiant de réseau NetID et l'adresse DevAddr) préparé à l'étape E18, ici par exemple au moyen d'un algorithme cryptographique de chiffrement utilisant la clé cryptographique de réseau NwkKey. Ce chiffrement peut également 3061618 13 couvrir la valeur d'intégrité MIC susmentionnée. Le serveur de réseau 20 peut ainsi émettre à l'étape E22 ce message chiffré à destination du dispositif électronique 10 (et précisément de l'entité électronique 2 qui équipe ce dispositif électronique 10). Le traitement effectué 5 alors au sein du dispositif électronique 10 est décrit plus bas (à partir de l'étape E28). Le serveur de réseau 20 détermine par ailleurs à l'étape E24 une clé de session de réseau NwkSKey sur la base de la clé cryptographique de réseau NwkKey, des premières données de dérivation DevNonce et des secondes 10 données de dérivation NwkNonce. On applique par exemple pour ce faire un algorithme cryptographique de dérivation F (éventuellement de type CMAC), utilisant la clé cryptographique de réseau NwkKey, à des données comprenant les premières données de dérivation DevNonce et les secondes données de dérivation NwkNonce (ainsi 15 qu'éventuellement d'autres données telles que l'identifiant de réseau NetID) : NwkSKey = FNwkKey(NwkNoncellNetIDIIDevNonce), où II est l'opérateur de concaténation. Comme déjà indiqué, la clé de session de réseau NwkSKey pourra ultérieurement être utilisée dans le cadre d'échange de données entre le dispositif 20 électronique 10 et le serveur de réseau 20, par exemple notamment pour le chiffrement des données échangées. Le serveur de réseau 20 peut ensuite transmettre à destination du serveur applicatif 30 le message REQ initialement émis par le dispositif électronique 10 à l'étape E12 (comprenant notamment l'identifiant DevEUI du 25 dispositif électronique 10 et les premières données de dérivation DevNonce) et les secondes données de dérivation NwkNonce (étape E25). On remarque que cette transmission peut être reportée si le serveur applicatif 30 n'est pas disponible, sans que cela ne bloque le processus permettant au dispositif électronique 10 de rejoindre le réseau (ce processus se 30 poursuivant de toute façon comme déjà indiqué à l'étape E28). Lorsque le serveur applicatif 30 reçoit les données émises à l'étape E25, il peut vérifier la valeur d'intégrité MIC2 (dans les cas où la valeur d'intégrité MIC2 est utilisée), ici au moyen de la clé cryptographique applicative AppKey (ou en variante au moyen d'une clé spécifique). 3061618 14 En cas de vérification positive, le serveur applicatif 30 peut déterminer à l'étape E26 une clé de session applicative AppSKey sur la base de la clé cryptographique applicative AppKey, des premières données de dérivation DevNonce et des secondes données de dérivation NwkNonce. (En cas de 5 vérification négative, il est mis fin au procédé sans générer la clé de session applicative AppSKey.) Dans le cas où le serveur applicatif 30 mémorise la clé applicative générique AppDevKey, il peut obtenir la clé cryptographique applicative AppKey par dérivation sur la base de la clé applicative générique AppDevKey et de 10 l'identifiant DevEUI (que ce serveur applicatif 30 vient de recevoir) : AppKey = d3(AppDevKey, DevEUI). La clé de session applicative AppSKey est par exemple déterminée par application d'un algorithme cryptographique de dérivation G (éventuellement de type CMAC), utilisant la clé cryptographique applicative AppKey, à des données 15 comprenant les premières données de dérivation DevNonce et les secondes données de dérivation NwkNonce (ainsi qu'éventuellement d'autres données telles que l'identifiant de réseau NetID) : AppSKey = GAppKey(NwkNoncellNetIDIIDevNonce), où II est l'opérateur de concaténation. 20 Comme déjà indiqué, la clé de session applicative AppSKey pourra ultérieurement être utilisée dans le cadre d'échange de données entre le dispositif électronique 10 et le serveur applicatif 30, par exemple notamment pour le chiffrement des données échangées. De son côté, l'équipement électronique 10 (et précisément l'entité 25 électronique 2) reçoit le message chiffré émis par le serveur de réseau 20 à l'étape E22 (message d'acceptation ACC dans le réseau, chiffré au moyen de la clé cryptographique de réseau NwkKey). L'entité électronique 2 peut alors déchiffrer ce message à l'aide de la clé cryptographique de réseau NwkKey et vérifier la valeur d'intégrité MIC (étape 30 E28). Précisément, l'entité électronique 2 applique un algorithme cryptographique de déchiffrement utilisant la clé cryptographique de réseau NwkKey au message chiffré reçu et peut ainsi avoir accès aux secondes données de dérivation NwkNonce, à l'identifiant de réseau NetID et à l'adresse DevAddr 3061618 15 (ces données étant contenues dans le message déchiffré), ainsi qu'à la valeur d'intégrité MIC. L'entité électronique 2 vérifie par ailleurs l'intégrité du message reçu en comparant la valeur d'intégrité reçu MIC et le résultat de l'application au message 5 déchiffré de la fonction cryptographique ayant permis de déterminer la valeur d'intégrité MIC à l'étape E18 (et utilisant la clé cryptographique de réseau NwkKey). L'entité électronique 2 (et/ou le processeur 12) peut alors mémoriser l'adresse DevAddr en tant qu'adresse du dispositif électronique 10 dans le réseau 10 (étape E30). L'entité électronique 2 détermine enfin à l'étape E32 les deux clés de session précitées : - la clé de session applicative AppSKey à utiliser ultérieurement dans les échanges de données avec le serveur applicatif 30 (notamment en tant que clé 15 d'un algorithme cryptographique de chiffrement appliqué aux données échangées) ; - la clé de session de réseau NwkSKey à utiliser ultérieurement dans les échanges de données avec le serveur de réseau 20 (notamment en tant que clé d'un algorithme cryptographique de chiffrement appliqué aux données 20 échangées). On rappelle que la clé de session applicative AppSKey est ici déterminée par application d'un algorithme cryptographique de dérivation G, utilisant la clé cryptographique applicative AppKey, à des données comprenant les premières données de dérivation DevNonce (produites à l'étape E8), les secondes données 25 de dérivation NwkNonce (reçues et déchiffrées à l'étape 28) et, ici, l'identifiant de réseau NetID. De même, la clé de session de réseau NwkSKey est ici déterminée par application d'un algorithme cryptographique de dérivation F, utilisant la clé cryptographique de réseau NwkKey, à des données comprenant les premières 30 données de dérivation DevNonce, les secondes données de dérivation NwkNonce et, ici, l'identifiant de réseau NetID. Le procédé qui vient d'être décrit a ainsi permis au dispositif électronique 10 de rejoindre le réseau (et notamment de mémoriser son adresse DevAddr à l'étape E30) et de produire les clés de sessions AppSKey, NwkSKey 3061618 16 susmentionnés. On remarque en particulier que la clé de session applicative AppSKey a pu être produite sans nécessiter un accès au serveur applicatif 30 (qui pourrait donc éventuellement être hors-ligne lorsque le dispositif électronique 10 rejoint le réseau) et sans que le serveur de réseau 20 ne puisse quant à lui obtenir 5 cette clé de session applicative AppSKey (ce qui permet d'assurer la confidentialité des échanges ultérieurs entre le dispositif électronique 10 et le serveur applicatif 30 vis-à-vis du serveur de réseau 20). On décrit à présent en référence à la figure 6 les étapes mises en oeuvre dans le cas où aucune clé cryptographique associée au réseau NwkMKey, 10 NwkKey n'est présente dans la mémoire concernée au sein du dispositif électronique 10 (ici la mémoire de l'entité électronique 2). À l'étape E50, l'entité électronique 2 procède à la détermination de premières données de dérivation DevNonce, ici par tirage aléatoire. L'entité électronique 2 prépare ensuite à l'étape E51 un message REQ' 15 comprenant l'identifiant AppEUI de l'application, l'identifiant DevEUI du dispositif électronique 10 et les premières données de dérivation DevNonce. Ce message REQ' forme une requête pour rejoindre le réseau et peut également inclure un entête spécifique correspondant. L'entité électronique 2 détermine par ailleurs à l'étape E51 une valeur 20 d'intégrité MIC' du message REQ ainsi préparé, par exemple en appliquant au message préparé une fonction cryptographique (ici de type CMAC) utilisant ici la clé cryptographique applicative AppKey. On utilise effet ici la même clé cryptographique AppKey pour le calcul de la valeur d'intégrité MIC' et pour le chiffrement des données incluant les secondes 25 données de dérivation AppNonce (ci-dessous à l'étape E64). On pourrait toutefois en variante utiliser deux clés distinctes : une clé spécifique pour le calcul de la valeur d'intégrité MIC' (utilisée à l'étape E51 qui vient d'être décrite et à l'étape de vérification E58 ci-dessous) et une clé spécifique pour le chiffrement (utilisée à l'étape E64 pour le chiffrement et à l'étape E72 pour le déchiffrement). Ces deux 30 clés distinctes et spécifiques pourraient en pratique être dérivées sur la base d'une même clé racine (et de données de dérivation respectives différentes). Le dispositif électronique 10 peut ensuite émettre à l'étape E52 le message REQ' préparé à l'étape E51 (message de requête pour rejoindre le réseau) et la valeur d'intégrité MIC' à destination du serveur de réseau 20. 3061618 17 Le serveur de réseau 20 reçoit ces données et vérifie à l'étape E54 que les premières données de dérivation DevNonce n'ont pas été préalablement reçues en provenance de ce dispositif électronique 10 (i.e. avec l'identifiant DevEUI également reçu). Le serveur de réseau 20 peut mémoriser pour se faire 5 l'ensemble des données de dérivation reçues lors de précédents échanges. Si les premières données de dérivation DevNonce ont déjà été reçues, il est mis fin au procédé afin d'éviter tout risque d'attaque par rejeu. Si les premières données de dérivation DevNonce n'ont jamais été reçues au préalable, le procédé se poursuit par la transmission du message REQ', 10 de la valeur d'intégrité MIC' et d'une adresse DevAddr à destination du serveur applicatif 30 (étape E56). Cette adresse DevAddr (générée par exemple à cette occasion) est allouée au dispositif électronique 10 et correspond ainsi à l'adresse du dispositif électronique 10 dans le réseau. L'adresse DevAddr est éventuellement transmise sous forme chiffrée (par exemple par établissement 15 d'un canal de communication sécurisé entre le serveur de réseau 20 et le serveur applicatif 30). Le serveur applicatif 30 reçoit l'adresse DevAddr, le message REQ' et la valeur d'intégrité MIC' et peut alors vérifier l'intégrité du message REQ' (étape E58) : le serveur applicatif 30 applique au message reçu REQ' (comprenant 20 l'identifiant AppEUI de l'application, l'identifiant DevEUI du dispositif électronique 10 et les premières données de dérivation DevNonce) la fonction cryptographique utilisant ici la clé cryptographique applicative AppKey et vérifie que le résultat obtenu est bien égal à la valeur d'intégrité MIC' reçue. En cas de vérification négative, il est mis fin au procédé sans que le 25 dispositif électronique 10 n'ait pu rejoindre le réseau. Dans l'affirmative, le procédé se poursuit à l'étape E60 où le serveur applicatif 30 produit, ici par tirage aléatoire, des secondes données de dérivation AppNonce. Le serveur applicatif 30 peut ainsi préparer à l'étape E62 un message 30 ACC' d'acceptation du dispositif électronique 10 dans le réseau, ce message ACC' comprenant les secondes données de dérivation AppNonce ainsi qu'éventuellement l'identifiant de réseau NetID et/ou l'adresse DevAddr et/ou un en-tête spécifique. Le serveur applicatif 30 détermine par ailleurs à l'étape E62 une valeur 3061618 18 d'intégrité MIC" du message d'acceptation ACC' ainsi préparé, par exemple en appliquant au message préparé ACC' une fonction cryptographique (ici de type CMAC) utilisant la clé cryptographique applicative AppKey (ou, en variante, une clé spécifique de calcul des valeurs d'intégrité différente de la clé cryptographique 5 applicative AppKey, comme déjà indiqué). Le serveur applicatif 30 procède ensuite à l'étape E64 au chiffrement du message d'acceptation ACC' (comprenant les secondes données de dérivation AppNonce, l'identifiant de réseau NetID et l'adresse DevAddr) préparé à l'étape E62, ici par exemple au moyen d'un algorithme cryptographique de chiffrement 10 utilisant la clé cryptographique applicative AppKey. Ce chiffrement peut également couvrir la valeur d'intégrité MIC" susmentionnée. Le serveur applicatif 30 détermine par ailleurs une clé de session de réseau NwkSKey et une clé de session applicative AppSKey (étape E65). Ces clés de session NwkSKey, AppSkey sont chacune déterminées sur 15 la base de la clé cryptographique applicative AppKey, des premières données de dérivation DevNonce et des secondes données de dérivation AppNonce (et, ici, de l'identifiant de réseau NetID). On peut utiliser par exemple pour ce faire un algorithme cryptographique de dérivation H utilisant la clé cryptographique applicative AppKey et appliqué à 20 des données légèrement différentes dans le cas de la clé de session applicative AppSKey et dans le cas de la clé de session de réseau NwkSKey : NwkSKey = HAppKey(0x0111AppNoncel I NetIDI I DevNonce), AppSKey = HAppKey(0x0211AppNoncellNetIDIIDevNonce) où 0x01 est la valeur 1 en hexadécimal, où 0x02 est la valeur 2 en 25 hexadécimal et où II est l'opérateur de concaténation. Comme déjà indiqué, la clé de session de réseau NwkSKey pourra ultérieurement être utilisée dans le cadre d'échange de données entre le dispositif électronique 10 et le serveur de réseau 20, par exemple notamment pour le chiffrement des données échangées ; la clé de session applicative AppSKey 30 pourra quant à elle être ultérieurement utilisée dans le cadre d'échange de données entre le dispositif électronique 10 et le serveur applicatif 30, par exemple notamment pour le chiffrement des données échangées. Le serveur applicatif 30 émet à l'étape E66 le message ACC' chiffré et la clé de session de réseau NwkSKey à destination du serveur de réseau 20. La clé 3061618 19 de session de réseau NwkSKey est éventuellement transmise sous forme chiffrée (par exemple par établissement d'un canal de communication sécurisé entre le serveur de réseau 20 et le serveur applicatif 30). Le serveur de réseau 20 reçoit la clé de session de réseau NwkSKey et 5 mémorise cette clé de session de réseau NwkSKey à l'étape E68 pour utilisation ultérieure. Le serveur de réseau 20 transmet par ailleurs à l'étape E70 le message ACC' chiffré à destination du dispositif électronique 10 (et précisément de l'entité électronique 2 qui équipe ce dispositif électronique 10). 10 L'équipement électronique 10 (et précisément l'entité électronique 2) reçoit le message chiffré émis par le serveur de réseau 20 à l'étape E70 (message d'acceptation ACC' dans le réseau, chiffré au moyen de la clé cryptographique applicative AppKey). L'entité électronique 2 peut alors déchiffrer ce message à l'aide de la clé 15 cryptographique applicative AppKey et vérifier la valeur d'intégrité MIC" (étape E72). Précisément, l'entité électronique 2 applique un algorithme cryptographique de déchiffrement utilisant la clé cryptographique applicative AppKey au message chiffré reçu et peut ainsi avoir accès aux secondes données 20 de dérivation AppNonce, à l'identifiant de réseau NetID et à l'adresse DevAddr (ces données étant contenues dans le message déchiffré), ainsi qu'à la valeur d'intégrité MIC". L'entité électronique 2 vérifie par ailleurs l'intégrité du message reçu en comparant la valeur d'intégrité reçu MIC" et le résultat de l'application au message 25 déchiffré de la fonction cryptographique ayant permis de déterminer la valeur d'intégrité MIC" à l'étape E62 (et utilisant ici la clé cryptographique applicative AppKey, ou, en variante, une clé spécifique). L'entité électronique 2 (et/ou le processeur 12) peut alors mémoriser l'adresse DevAddr en tant qu'adresse du dispositif électronique 10 dans le réseau 30 (étape E74). L'entité électronique 2 détermine enfin à l'étape E76 les deux clés de session AppSKey, NwkSkey précitées (selon le même processus qu'indiqué ci-dessus à l'étape E65). REVENDICATIONS1. Procédé mis en oeuvre par un dispositif (10) pour rejoindre un réseau, le dispositif (10) comprenant une mémoire et mémorisant une clé cryptographique applicative (AppKey) dans ladite mémoire, le procédé comprenant les étapes suivantes : - test (El ; El ') de l'absence ou de la présence dans la mémoire d'une clé cryptographique (NwkMKey ; NwkKey) associée au réseau ; - en cas d'absence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), émission (E52) d'une requête (REQ') pour rejoindre le réseau et réception (E72) en retour de données de dérivation (AppNonce) produites par un serveur applicatif (30) et chiffrées au moyen de la clé cryptographique applicative (AppKey) ; - en cas de présence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), émission (E12) d'une requête (REQ) pour rejoindre le réseau et réception (E28) en retour de données de dérivation (NwkNonce) produites par un serveur associé au réseau (20) et chiffrées au moyen d'une clé cryptographique de réseau (NwkKey) égale à, ou dérivée de, la clé cryptographique associée au réseau (NwkMKey ; NwkKey). 2. Procédé selon la revendication 1, comprenant une étape de dérivation (E32 ; E76) d'une clé de session applicative (AppSKey) sur la base de la clé cryptographique applicative (AppKey) et des données de dérivation reçues (AppNonce ; NwkNonce). 3. Procédé selon la revendication 1 ou 2, comprenant, en cas de présence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), une étape de dérivation (E32) d'une clé de session de réseau (NwkSKey) sur la base de la clé cryptographique de réseau (NwkKey) et des données de dérivation reçues (NwkNonce). 4. Procédé selon l'une des revendications 1 à 3, comprenant, en cas de présence de la clé cryptographique associée au réseau (NwkMKey), une étape de dérivation (E6) de la clé cryptographique de réseau (NwkKey) sur la base de la clé 3061618 21 cryptographique associée au réseau (NwkMKey) et d'un identifiant (NetID) du réseau. 5. Procédé selon la revendication 4, comprenant une étape de réception 5 de l'identifiant (NetID) du réseau en provenance du serveur associé au réseau. 6. Procédé selon l'une des revendications 1 à 3, dans lequel la clé cryptographique de réseau est la clé cryptographique associée au réseau (NwkKey). 10 7. Procédé selon l'une des revendications 1 à 6, dans lequel le dispositif (10) comprend une entité électronique sécurisée (2) incluant ladite mémoire. 8. Procédé mis en oeuvre dans un réseau comprenant un serveur 15 applicatif (30), un serveur de réseau (20) et un dispositif (10) comprenant une mémoire mémorisant une clé cryptographique applicative (AppKey), le procédé comprenant les étapes suivantes : - test (El ; El') par le dispositif de l'absence ou de la présence dans la mémoire d'une clé cryptographique (NwkMKey ; NwkKey) associée au réseau ; 20 - en cas d'absence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), émission (E52) par le dispositif (10) d'une requête (REQ') pour rejoindre le réseau, production (E60) de données de dérivation (AppNonce) par le serveur applicatif (30), chiffrement (E64) des données de dérivation (AppNonce) par le serveur applicatif (30) au moyen de la clé cryptographique 25 applicative (AppKey), et réception (E72) par le dispositif (10) des données de dérivation chiffrées ; - en cas de présence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), émission (E12) par le dispositif (10) d'une requête (REQ) pour rejoindre le réseau, production (E16) de données de dérivation (NwkNonce) 30 par le serveur de réseau (20), chiffrement (E20) des données de dérivation (NwkNonce) par le serveur de réseau (20) au moyen d'une clé cryptographique de réseau (NwkKey) égale à, ou dérivée de, la clé cryptographique associée au réseau (NwkMKey ; NwkKey), et réception (E28) par le dispositif (10) des données de dérivation chiffrées. 3061618 22 9. Entité électronique (2) comprenant : - une mémoire mémorisant une clé cryptographique applicative (AppKey), 5 - un module d'émission d'une requête (REQ ; REQ') pour rejoindre un réseau ; - un mécanisme de test de l'absence ou de la présence dans la mémoire d'une clé cryptographique (NwkMKey ; NwkKey) associée au réseau ; - un module de réception conçu pour recevoir, en cas d'absence de la clé 10 cryptographique associée au réseau (NwkMKey ; NwkKey), des données de dérivation (AppNonce) produites par un serveur applicatif (30) et chiffrées au moyen de la clé cryptographique applicative (AppKey) et, en cas de présence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), des données de dérivation (NwkNonce) produites par un serveur associé au réseau (20) et 15 chiffrées au moyen d'une clé cryptographique de réseau (NwkKey) égale à, ou dérivée de, la clé cryptographique associée au réseau (NwkMKey ; NwkKey). 10. Entité électronique selon la revendication 9, comprenant un module de dérivation d'une clé de session applicative (AppSKey) sur la base de la clé 20 cryptographique applicative (AppKey) et des données de dérivation reçues (AppNonce ; NwkNonce). 11. Entité électronique selon la revendication 10 ou 11, comprenant un module apte à dériver, en cas de présence de la clé cryptographique associée au 25 réseau (NwkMKey ; NwkKey), une clé de session de réseau (NwkSKey) sur la base de la clé cryptographique de réseau (NwkKey) et des données de dérivation reçues (NwkNonce). 12. Entité électronique selon l'une des revendications 9 à 11, 30 comprenant un module apte à dériver, en cas de présence de la clé cryptographique associée au réseau (NwkMKey ; NwkKey), la clé cryptographique de réseau (NwkKey) sur la base de la clé cryptographique associée au réseau (NwkMKey) et d'un identifiant (NetID) du réseau.