Brevet FR3074592A1 — publié le 20190607

DOMAINE DE L'INVENTION La presente invention se rapporte au domaine des objets connectes. L'invention concerne tout particulierement un procede de partage d'une cle servant a deriver des cies de session pour crypter et authentifier des communications entre un objet et un serveur. L'invention trouve avantageusement application dans des reseaux d'objets connectes conformes a la specification LoRaWAN®. ETAT DE LA TECHNIQUE La specification LoRaWAN definit un protocole de communication pour un reseau d'objets connectes. Dans un tel reseau, un objet (parfois appele terminal ou - end-device - en anglais) est amene a communiquer avec un serveur faisant partie d'un tel reseau. La specification LoRaWAN version 1 propose d'utiliser deux cies de session NwkSKey, AppSKey pour crypter et authentifier des communications entre l'objet et le serveur. Par ailleurs, les cies de session NwkSKey, AppSKey doivent etre derivees d'une cle d'application AppKey, lorsque cet objet envoie au serveur une requete d'adhesion a un reseau d'objets connectes. Chaque objet dispose de sa propre cle d'application AppKey. Cette cle d'application AppKey est fournie par un fournisseur d'application. Une contrainte importante est que la cle d'application AppKey doit etre un secret outage entre l'objet et le serveur. Pour que cette contrainte soit respectee, la specification LoRaWAN propose de precharger une valeur de cle d'application AppKey dans une memoire de l'objet, au cours d'une etape de configuration de l'objet realisee avant sa mise en service. Un tel pre-chargement est toutefois contraignant. En effet, on ne connait pas forcement, au moment ou cette etape de configuration est mise en oeuvre, avec quel serveur l'objet sera amene a communiquer une fois mis en service. EXPOSE DE L'INVENTION Un but de l'invention est de partager une cle entre un objet connecte et un serveur d'un reseau d'objets connectes d'une maniere moins contraignante tout en etant securisee, la cle servant a deriver des cies de session pour crypter et authentifier des communications entre l'objet et le serveur. II est ainsi propose, selon un premier aspect de l'invention, un procede de partage d'une cle de reference entre un objet susceptible d'être connecte a un reseau d'objets connectes et au moins un serveur, le procede comprenant des &apes de : 2 - application, par l'objet, d'une premiere fonction predeterminee a au moins une premiere donnee et a une cle propre a un element securise de l'objet, de sorte a generer la cle de reference, - transmission au serveur d'une requete d'adhesion de l'objet a un reseau d'objets 5 connectes, la requete d'adhesion comprenant la premiere donnee, la cle propre a ['element securise n'etant en revanche pas transmise par l'objet au serveur, - obtention, par le serveur, de la cle propre a ['element securise sur la base de la requete d'adhesion, - application, par le serveur, de la premiere fonction predeterminee a la premiere 10 donnee et a la cle obtenue par le serveur, de sorte a obtenir la cle de reference. Le procede selon le premier aspect de ['invention, peut comprendre les caracteristiques optionnelles suivantes, prises seules ou en combinaison lorsque cela est techniquement possible. Le procede peut comprendre par ailleurs des &apes d'application, par l'objet, d'une 15 deuxieme fonction predeterminee a une deuxieme donnee et a la cle de reference, de sorte a generer un code d'integrite, et de transmission au serveur du code d'integrite genere. Dans ce cas, ['obtention par le serveur de la cle propre a ['element securise comprend les &apes suivantes : - pour au moins une cle d'element securise candidate memorisee par le serveur : 20 a) application de la premiere fonction predeterminee a la premiere donnee transmise dans la requete d'adhesion et a une cle d'element securise candidate memorisee par le serveur, de sorte a generer une cle de reference candidate), b) application de la deuxieme fonction predeterminee a la deuxieme donnee 25 transmise dans la requete d'adhesion et a la cle de reference candidate generee), de sorte a generer un code d'integrite candidat), - selection d'une cle de reference candidate ayant servi a generer un code d'integrite candidat egal au code d'integrite relatif a la requete d'adhesion. Le procede peut comprendre par ailleurs : ['application, par l'objet, d'une troisieme 30 fonction predeterminee a un identifiant unique de ['element securise de l'objet et a une donnee d'alea ayant une valeur comprise dans un ensemble fini predetermine, de sorte a generer un nonce ; la transmission du nonce au serveur ; pour au moins un identifiant unique d'element securise candidat et pour au moins une valeur candidate de ['ensemble fini predetermine, ['application de la troisieme fonction predeterminee a l'identifiant candidat 35 et a la valeur candidate, de sorte a generer un nonce candidat ; et la selection d'au moins 3 une cle d'element securise candidate associee, dans une table de correspondance, a un identifiant candidat ayant servi a generer un nonce candidat egal au nonce transmis dans la requete d'adhesion, dans lequel l'etape a) est mise en ceuvre uniquement pour chaque cle d'element securise candidate selectionnee. 5 La donnee d'alea peut etre un compteur increments par l'objet pour chaque nouvelle requete d'adhesion. La troisieme fonction peut comprendre une fonction de hachage prenant en entrée l'identifiant de ['element securise de l'objet et la donnee d'alea, suivie d'une troncature. Le nonce peut etre une donnee DevNonce conforme a la specification LoRaWAN et/ou 10 etre incluse dans la requete d'adhesion. L'obtention de la cle propre a ['element securise par le serveur peut comprend des stapes de : identification, dans une premiere table de correspondance, d'un identifiant d'element securise associe a la premiere donnee transmise dans la requete d'adhesion, et identification, dans une deuxieme table de correspondance distincte de la premiere table de 15 correspondance, d'une cle associee a l'identifiant unique d'element securise identifie dans la premiere table de correspondance. La requete d'adhesion peut etre un message conforme a la specification LoRaWAN. La premiere donnee peut etre ou dependre d'au moins une des donnees suivantes : un identifiant unique propre a l'objet, un identifiant d'application unique propre a un 20 fournisseur d'application de l'objet, un nonce. La cle de reference peut servir a deriver des cies de session pour crypter et authentifier des communications entre l'objet et le serveur ou sert a partager une autre cle entre l'objet et le serveur. II est egalement propose, selon un deuxieme aspect de ['invention, un systeme 25 comprenant un objet susceptible d'être connects a un reseau d'objets connectes, et au moins un serveur, dans lequel l'objet est configure pour : - appliquer une premiere fonction predeterminee a au moins une premiere donnee et a une cle propre a un element securise de l'objet, de sorte a generer la cle de reference, 30 - transmettre au serveur une requete d'adhesion de l'objet au reseau d'objets connectes, la requete d'adhesion comprenant la premiere donnee, la cle propre a ['element securise n'etant en revanche pas transmise par l'objet au serveur, et dans lequel le serveur est configure pour : - obtenir la cle propre a ['element securise sur la base de la requete d'adhesion, 4 - appliquer la premiere fonction predeterminee a la premiere donnee et a la cle obtenue par le serveur, de sorte a obtenir la cle de reference. DESCRIPTION DES FIGURES 5 D'autres caracteristiques, buts et avantages de l'invention ressortiront de la description qui suit, qui est purement illustrative et non [imitative, et qui doit etre lue en regard des dessins annexes sur lesquels : - La figure 1 illustre de facon schernatique un systeme comprenant un objet et un serveur pour reseau d'objets connectes, selon un mode de realisation ; 10 - Les figures 2 et 3 illustrent des stapes d'un procede de partage d'une cle entre l'objet et le serveur illustres sur la figure 1, selon un mode de realisation de l'invention. Sur ['ensemble des figures, les elements similaires portent des references identiques. DESCRIPTION DETAILLEE DE L'INVENTION 15 On a schernatiquement represents en figure 1 un objet 1 susceptible d'être connects a un reseau d'objets connectes via un serveur 2. L'objet 1 comprend un element securise 4, au moins un processeur 6, au moins une memoire 8 et une interface de communication 10 avec le serveur 2. Le processeur 6 est configure pour executer des programmes d'ordinateur, et en 20 particulier une premiere fonction f, voire une deuxieme fonction g et une troisieme fonction h qui seront detainees dans la suite. L'element securise 4 peut etre un circuit physique dedie. Ce circuit dedie peut etre amovible, par exemple au format UICC. Alternativement, ['element securise 4 est virtuel, dans le sens ou it est forme par un programme d'ordinateur specifique susceptible d'être 25 execute par le processeur 6 de l'objet 1. L'interface de communication 10 est par exemple du type radio sans fit. Dans ce qui suit, on prendra l'exemple d'une interface de communication 10 destinee a emettre ou recevoir des messages conformes a la specification LoRaWAN®, auquel cas le reseau d'objets connects est un reseau egalement conforme a cette specification LoRaWAN. 30 L'element securise 4 memorise une cle KSE qui lui est propre. L'element securise 4 dispose par ailleurs d'un identifiant unique IDSE qui lui est propre. Par ailleurs, la memoire 8 de l'objet 1 comprend au moins une memoire non volatile est destine a stocker des donnees de calcul de maniere persistante (HDD, SSD, Flash, etc.), en particulier les donnees suivantes definies par la specification LoRaWAN version 1 : 35 - DevEUI : un identifiant unique propre a l'objet 1, assimilable a un numero de serie. 5 - AppEUI : un identifiant d'application unique propre a un fournisseur d'application de l'objet 1. Il permet de classer differents objets tels que l'objet 1 par application. Le serveur 2 comprend au moins un processeur 12, au moins une memoire 14 et une interface de communication 16 avec au moins un objet 1 tel que l'objet 1 represents en 5 figure 1 Le processeur 12 du serveur 2 est egalement configure pour executer des programmes d'ordinateur, et en particulier la premiere fonction f, voire la deuxieme fonction g et la troisieme fonction h precitees. La memoire 14 du serveur 2 comprend au moins une memoire non volatile est destine 10 a stocker des donnees de calcul de maniere persistante (HDD, SSD, Flash, etc.), en particulier des tables de correspondances dont le contenu sera &tante dans la suite. L'interface de communication 16 est configuree pour interagir avec ['interface de communication 10 de l'objet 1 ; elle est par consequent du meme type. Pour que l'objet 1 et le serveur 2 puisse communiquer l'un avec l'autre de maniere 15 securisee, au moins une cle de reference doit etre partagee entre le client et le serveur. La cle de reference sert par exemple a deriver des cies de session pour crypter et authentifier des communications entre l'objet 1 et le serveur. Lorsque le reseau d'objets connectes est le reseau LoRaWAN version 1, cas non limitatif que l'on prendra en exemple dans la suite, cette cle de reference est la cle d'application 20 AppKey, laquelle permet de deriver les cies de session NwkSKey, AppSKey lesquelles permettent de crypter et authentifier des communications entre l'objet 1 et le serveur 2. En reference a la figure 2, un procede de partage d'une cle de reference AppKey entre l'objet 1 et le serveur 2 selon un premier mode de realisation comprend les stapes suivantes. 25 Le processeur 6 de l'objet 1 genere un nonce (etape 100). Ce nonce est destine a etre passé en parametre d'une requete d'adhesion a un reseau d'objets connects, transmise par l'objet 1 au serveur 2. Le serveur 2 garde trace de certaines valeurs de ce nonce utilisees par l'objet 1 par le passé, et ignore toute requete d'adhesion qui reutiliserait l'une de ces valeurs, de maniere a assurer une protection contre des attaques par rejeu. 30 Ce nonce est la donnee DevNonce definie dans la specification LoRaWAN. Il est code sur deux octets. Par ailleurs, l'objet 1 applique la premiere fonction f a au moins une premiere donnee, et a la cle KSE propre a ['element securise 4 de l'objet 1, de sorte a generer une cle de reference AppKey (etape 102). 6 Cette etape 102 peut etre mise en ceuvre par le processeur 6 de ['objet 1, mais est de preference mis en ceuvre par ['element securise 4 de fawn a eviter que la cle KSE n'ait pas a etre extraite hors de cet element securise 4. La premiere donnee peut etre ['une des donnees suivantes definies par la specification 5 LoRaWAN : DevEUI ou AppEUI (prealablement memorisees dans la memoire de ['objet 1) bien ou DevNonce (nonce calcule au cours de l'etape 100). Au cours de sa duree de vie, ['objet 1 peut etre amene a contenir differents elements securises. Par exemple, lorsque ['element securise 4 se presente sous la forme d'un circuit physique amovible, ce circuit peut etre remplace. La generation 102 de la cle AppKey par 10 ['objet 1 connecte peut ainsi etre mise en ceuvre a chaque fois qu'un nouvel element securise est inclus dans ['objet 1 connecte, c'est-a-dire a chaque fois que la cle passee en entrée de la premiere fonction change au sein de ['objet 1. En particulier, l'identifiant AppEUI peut etre amene a evoluer au cours du cycle de vie de ['objet, par exemple si ['objet 1 change de proprietaire et/ou de serveur associe. 15 Le processeur 6 de ['objet 1 genere par ailleurs une requete d'adhesion a un reseau d'objets connectes (etape 106). La requete d'adhesion est un message join-request conforme a la specification LoRaWAN. Le message join-request comprend alors, de maniere conventionnelle, les donnees suivantes : DevEUI, AppEUI et DevNonce. Par consequent, la premiere donnee, ayant servi a 20 calculer la cle de reference AppKey et etant susceptible d'être ['une des trois donnees qui precedent, est incluse dans la requete d'adhesion. L'objet 1 genere par ailleurs un code d'integrite MIC relatif a la requete d'adhesion (etape 102). Ce code d'integrite MIC a pour but d'authentifier la requete d'adhesion aupres d'un destinataire, autrement dit, de permettre a un tel destinataire de verifier si la requete 25 d'adhesion a ete ernis par un objet 1 agree et si les donnees contenues dans la requete d'adhesion sont coherentes. Le code d'integrite MIC est genere par application de la deuxieme fonction g a a ['une des donnees comprises dans la requete d'adhesion generee et a la cle de reference AppKey (etape 104). 30 Cette donnee, dite dans la suite deuxieme donnee, peut en particulier "etre la premiere donnee, ou bien distincte de la premiere donnee. La deuxieme fonction g est par exemple une fonction de chiffrement AES. La requete d'adhesion est transmise par ['interface de communication au serveur 2 (etape 108). Le code d'integrite MIC est egalement transmis au serveur 2. 7 Dans le cas du reseau LoRaWAN, le message join-request est encapsule par le processeur 6 dans un message MAC, de meme que le code d'integrite MIC, avant leur envoi au serveur. Le message MAC est typiquement relaye au serveur 2 par un operateur (LoRa Network Operator). 5 En reference a la figure 3, la requete d'adhesion est recue par ['interface de communication 16 du serveur 2, qui le transmet au processeur 12 pour etre traitee. Le processeur 12 du serveur 2 obtient la cle KSE propre a ['element securise 4, en s'aidant de la requete d'adhesion recue. Toutefois, cette obtention est mise en ceuvre autrement que par une transmission de la cle KSE propre a ['element securise 4 par ['objet 10 1 au serveur. Cette obtention est mise en ceuvre au moyen des &apes suivantes. Ont ete prealablement memorisees dans la memoire 14 du serveur 2 une pluralite de cies d'element securise candidates KSE(1), ..., KSE(n). L'une d'entre elles est susceptible d'être egale a la cle KSE de ['element securise 4 de ['objet 1. Le processeur 12 met en ceuvre une boucle comprenant au moins une iteration, chaque 15 iteration utilisant une des cies d'element securise candidates KSE(1), ..., KSE(n). Une iteration d'indice i comprend les &apes 208, 210, 212 suivantes. Le processeur 12 applique la premiere fonction predeterminee f a la premiere donnee (DevEUI, AppEUI ou DevNonce) contenue dans la requete d'adhesion recue, et a la cle d'element securise candidate KSE(i) memorisee par le serveur 2, de sorte a generer une cle 20 de reference candidate AppKey(i) (etape 208). Ensuite, le processeur 12 applique la deuxieme fonction predeterminee g a la deuxieme donnee (DevEUI, AppEUI, ou DevNonce) qui a ete recue par le serveur dans la requete d'adhesion, et a la cle de reference candidate AppKey(i), de sorte a generer un code d'integrite candidat MIC(i) associe a la cle de reference candidate AppKey(i) (etape 210). 25 Le processeur 12 compare ensuite le code d'integrite candidat MIC(i) au code d'integrite MIC contenu dans la requete d'adhesion recue par le serveur 2 (etape 212). Si les deux codes ne sont pas egaux, une nouvelle iteration est mise en ceuvre pour une cle d'element securise candidate suivante KSE(i+1). Les &apes 208, 210, 212 sont alors repetees sur la base de la cle KSE(i+1). 30 Si le processeur 12 met en ceuvre n iterations et qu'il est constate qu'aucun des codes d'integrite candidats MIC(1), ..., MIC(n) n'est egal au code d'integrite MIC recu, alors la requete d'adhesion est rejetee par le serveur. En revanche, si deux codes compares MIC(i) et MIC sont egaux, alors cela signifie que la requete d'adhesion recue par le serveur 2 provient bien d'un objet 1 agree. Mais cela 35 signifie egalement que la cle de reference candidate AppKey(i), ayant permis de generer le 8 code d'integrite candidat MIC(i), est egal a la cle AppKey detenue par ['objet 1, puisque ['objet 1 et le serveur ont chacun utilise la meme deuxieme fonction predeterminee g pour generer les deux codes d'integrite compares. Le processeur 12 du serveur 2 considere donc que la cle propre a ['element securise 4 est la cle AppKey(i). 5 En definitive, le processeur 12 selectionne en tant que cle AppKey la cle de reference candidate ayant permis de generer un code d'integrite candidat egal au code d'integrite (MIC) relatif a la requete d'adhesion (etape 214). De facon conventionnelle, le serveur 2 transmet a ['objet 1 un message de reponse join-accept -, lui indiquant que la requete d'adhesion a ete acceptee par le serveur 2. 10 La cle de reference AppKey devient a ce stade une cle partagee entre ['objet 1 et le serveur 2. Par la suite, la cle de reference AppKey partagee peut etre utilisee conventionnellement pour deriver les cies de session NwkSKey, AppSKey pour crypter et authentifier des communications entre ['objet 1 et le serveur. 15 Bien entendu, le nombre maximal de calculs effectues par le serveur 2 pour recuperer la cle de reference AppKey au cours du procede de partage qui precede est proportionnel au nombre n de cies candidates KSE(i) memorisees par le serveur 2. Par consequent, i[ est avantageusement mis les &apes additionnelles suivantes au cours du procede, afin de reduire le nombre de calculs effectues en pratique par le serveur 2 pour recuperer cette cle de 20 reference AppKey. De retour a la figure 2, au cours de l'etape 100, le processeur 6 de ['objet 1 ou ['element securise 4 applique la troisieme fonction predeterminee h a l'identifiant unique (IDSE) de ['element securise 4 de ['objet 1 et a une donnee d'alea ayant une valeur comprise dans un ensemble fini predetermine de m valeurs, de sorte a generer le DevNonce qui sera ensuite 25 inclus dans la requete d'adhesion a transmettre au serveur. La troisieme fonction est par exemple la suivante : DevNonce = trunc(hash(IDSE, counter)) ou - counter est la donnee d'alea, 30 - hash designe une fonction de hachage, - trunc est une troncature qui ne conserve que 2 octets du resultat de la fonction de hachage. De retour a la figure 3, une table de correspondance entre des identifiants uniques d'elements securise IDSE(1), ..., IDSE(n) et les cies d'elements securise KSE(1), ..., KSE(n) 35 discutees precedemment a ete prealablement memorisee dans la memoire 14 du serveur 2. 9 Autrement dit, pour tout i allant de 1 a n, l'identifiant unique IDSE(i) et la cle KSE(i) se rapportent a un meme element skull* et sont donc mis en correspondance dans la table de correspondance memorisee dans la memoire 14 du serveur 2. Bien entendu, l'un des identifiants candidats IDSE(1), ..., IDSE(n) est susceptible d'être 5 egal a l'identifiant unique IDSE memorise par ['element securise 4 de l'objet 1. On suppose par ailleurs que le serveur connait l'ensemble fini auquel appartient la donnee d'alea. Le processeur 12 du serveur 2 met en ceuvre les &apes suivantes pour au moins un identifiant unique d'element securise candidat IDSE(i) d'indice i et pour au moins une valeur 10 candidate de l'ensemble fini predetermine d'indice j. Le processeur applique la troisieme fonction predeterminee h a l'identifiant candidat IDSE(i) et a la valeur candidate d'indice j, de sorte a generer un nonce candidat, que l'on nomme par convention DevNonce(i,j) (etape 200). Le processeur compare le DevNonce recu dans la requete d'adhesion avec chaque nonce 15 candidat genere (202). Si un nonce candidat genere DevNonce(i,j) est egal au DevNonce, alors le processeur 12 selectionne la cle d'element securise KSE(i) associee, dans la table de correspondance, a l'identifiant unique d'element securise candidat IDSE(i) ayant servi a generer le nonce candidat DevNonce(i,j) (etape 204). 20 Si un nonce candidat genere DevNonce(i,j) est different du DevNonce, alors le processeur 12 ne selectionne pas, au cours de l'etape 204, la cle d'element securise KSE(i) associee, dans la table de correspondance, a l'identifiant unique d'element securise candidat IDSE(i) ayant servi a generer le nonce candidat DevNonce(i,j). Le processeur repete par exemple les &apes 200, 202, 204 pour tout i allant de 1 a n, 25 et pour tout element de l'ensemble fini (de cardinal m). Il est a noter que le nombre de cies d'elements securises candidats IDSE(i) selectionne par le serveur peut "etre egal a 1, mais peut egalement "etre superieur a 1. En effet, la troncature trunc de la troisieme fonction h est susceptible de generer des collisions, c'esta-dire produire des DevNonces(i,j) de meme valeur a partir de donnees d'entrees de la 30 troisieme fonction pourtant differentes. Les &apes 208, 210 et 212 sont ensuite mises en ceuvre uniquement pour chaque cle d'element securise candidate selectionnee au cours de l'etape 204. Le calcul prealable 200 des nonces candidats permet ainsi de realiser un pre-filtrage de cies d'elements securises KSE(i) candidates memorisees dans la memoire 14 du serveur 2, 35 dont le nombre peut "etre extremement grand. Certes, les &apes additionnelles 200, 202, 10 204 de ce pre-filtrage induisent une charge de calcul supplementaire ; toutefois, cette charge supplementaire, relativement petite, est largement compensee par le fait que le nombre d'iterations faisant appel a la premiere fonction (dans l'etape 208) et a la deuxieme fonction (dans l'etape 210) est fortement reduit. La charge de calcul globale consommee par 5 le serveur pour obtenir la cle KSE de ['element securise 4 est donc en definitive fortement reduite grace aux &apes 208, 210, 212. Cette economie de charge de calcul est particulierement avantageuse lorsque les calculs sont confies a un module materiel de securite ( REVENDICATIONS1. Procede de partage d'une cle de reference (AppKey) entre un objet (1) susceptible d'être connecte a un reseau d'objets connectes et au moins un serveur (2), le procede comprenant des &apes de : - application (102), par l'objet (1), d'une premiere fonction predeterminee (f) a au moins une premiere donnee (DevEUI, AppEUI, DevNonce) et a une cle (KSE) propre a un element securise de l'objet (1), de sorte a generer la cle de reference (AppKey), - transmission (108) au serveur (2) d'une requete d'adhesion (join-request) de l'objet (1) au reseau d'objets connectes, la requete d'adhesion (join-request) comprenant la premiere donnee (DevEUI, AppEUI, DevNonce), la cle (KSE) propre a ['element securise (4) n'etant en revanche pas transmise par l'objet (1) au serveur (2), - obtention, par le serveur (2), de la cle (KSE) propre a ['element securise (4) sur la base de la requete d'adhesion (join-request), - application (208), par le serveur (2), de la premiere fonction predeterminee (f) a la premiere donnee (DevEUI, AppEUI, DevNonce) et a la cle (KSE) obtenue par le serveur (2), de sorte a obtenir la cle de reference (AppKey). 2. Procede selon la revendication 1, comprenant par ailleurs des &apes de : - application (104), par l'objet (1), d'une deuxieme fonction predeterminee (g) a une deuxieme donnee (DevEUI, AppEUI, DevNonce) et a la cle de reference (AppKey), de sorte a generer un code d'integrite (MIC), - transmission (108) au serveur (2) du code d'integrite (MIC) genere, et dans lequel ['obtention par le serveur (2) de la cle propre a ['element securise (4) 25 comprend des &apes de : - pour au moins une cle d'element securise candidate memorisee par le serveur (2) : c) application (208) de la premiere fonction predeterminee (f) a la premiere donnee (DevEUI, AppEUI, DevNonce) transmise dans la requete d'adhesion (join-request) et a une cle d'element securise candidate memorisee par le 30 serveur (2), de sorte a generer une cle de reference candidate (AppKey(i)), d) application (210) de la deuxieme fonction predeterminee (g) a la deuxieme donnee (DevEUI, AppEUI, DevNonce) transmise dans la requete d'adhesion (join-request) et a la cle de reference candidate generee (AppKey(i)), de sorte a generer un code d'integrite candidat (MIC(i)), 14 - selection d'une cle de reference candidate ayant servi a generer un code d'integrite candidat egal au code d'integrite (MIC) relatif a la requete d'adhesion (join-request). 3. Procede selon la revendication 2, comprenant en outre des &apes de 5 - application (100), par l'objet (1), d'une troisieme fonction predeterminee (h) a un identifiant unique (IDSE) de ['element securise (4) de l'objet (1) et a une donnee d'alea (counter) ayant une valeur comprise dans un ensemble fini predetermine, de sorte a generer un nonce (DevNonce), - transmission (108) du nonce (DevNonce) au serveur (2), 10 - pour au moins un identifiant unique d'element securise candidat et pour au moins une valeur candidate de ['ensemble fini predetermine, application (200) de la troisieme fonction predeterminee (h) a l'identifiant candidat et a la valeur candidate, de sorte a generer un nonce candidat, - selection (204) d'au moins une cle d'element securise candidate associee, dans une 15 table de correspondance, a un identifiant candidat ayant servi a generer un nonce candidat egal au nonce transmis dans la requete d'adhesion (join-request), dans lequel l'etape a) est mise en oeuvre uniquement pour chaque cle d'element securise candidate selectionnee. 20 4. Procede selon la revendication 3, dans lequel la donnee d'alea est un compteur increments par l'objet (1) pour chaque nouvelle requete d'adhesion. 5. Procede selon l'une des revendications 3 et 4, dans lequel la troisieme fonction (h) comprend une fonction de hachage prenant en entrée l'identifiant (IDSE) de ['element securise (4) de l'objet (1) et la donnee d'alea (counter), suivie d'une troncature. 6. Procede selon l'une des revendications 3 a 5, dans lequel le nonce est une donnee DevNonce conforme a la specification LoRaWAN et/ou est incluse dans la requete d'adhesion. 7. Procede selon la revendication 1, dans lequel l'obtention de la cle propre a ['element securise (4) par le serveur (2) comprend des &apes de : - identification, dans une premiere table de correspondance, d'un identifiant d'element securise associe a la premiere donnee (DevEUI, AppEUI, DevNonce) transmise dans la requete d'adhesion (join-request), 15 - identification, dans une deuxieme table de correspondance distincte de la premiere table de correspondance, d'une cle associee a l'identifiant unique d'element securise identifie dans la premiere table de correspondance. 5 8. Procede selon l'une des revendications 1 a 7, dans lequel : - la requete d'adhesion (join-request) est un message conforme a la specification LoRaWAN, et/ou - lequel la premiere donnee est ou depend d'au moins une des donnees suivantes : o un identifiant unique propre a ['objet (DevEUI), 10 o un identifiant d'application unique propre a un fournisseur d'application de ['objet (AppEUI), o un nonce (DevNonce), et/ou - la cle de reference sert a deriver des cies de session (NwkSKey, AppSKey) pour crypter et authentifier des communications entre ['objet (1) et le serveur (2) ou sert a 15 partager une autre cle entre ['objet (1) et le serveur (2). 9. Systeme comprenant un objet (1) susceptible d'être connecte a un reseau d'objets connectes, et au moins un serveur (2), dans lequel ['objet (1) est configure pour : - appliquer une premiere fonction predeterminee (f) a au moins une premiere donnee 20 (DevEUI, AppEUI, DevNonce) et a une cle (KSE) propre a un element securise de ['objet (1), de sorte a generer la cle de reference (AppKey), - transmettre au serveur (2) une requete d'adhesion (join-request) de ['objet (1) au reseau d'objets connectes, la requete d'adhesion (join-request) comprenant la premiere donnee (DevEUI, AppEUI, DevNonce), la cle (KSE) propre a ['element 25 securise (4) n'etant en revanche pas transmise par ['objet (1) au serveur (2), et dans lequel le serveur (2) est configure pour : - obtenir la cle (KSE) propre a ['element securise (4) sur la base de la requete d'adhesion (join-request), - appliquer la premiere fonction predeterminee (f) a la premiere donnee (DevEUI, 30 AppEUI, DevNonce) et a la cle (KSE) obtenue par le serveur (2), de sorte a obtenir la cle de reference (AppKey).