FR 3087311 A1 20200417 FR 1871190 A 20181016 DESCRIPTION TITRE : Procédé de communication d'un objet avec un réseau d'objets connectés pour signaler qu'un clone se fait potentiellement passer pour l'objet dans le réseau DOMAINE DE L'INVENTION La présente invention se rapporte au domaine des objets connectés. L'invention concerne tout particulièrement un procédé de communication d'un objet avec un réseau d'objets connectés pour signaler qu'un clone se fait potentiellement passer pour l'objet dans le réseau. 10 L'invention trouve avantageusement application dans des réseaux d'objets connectés conformes à ta spécification LoRaWAN®. ETAT DE LA TECHNIQUE La spécification LoRaWAN définit un protocole de communication pour un réseau 15 d'objets connectés. Dans un tel réseau, un objet (parfois appelé terminal ou - end-device - en anglais) est amené à communiquer avec un serveur faisant partie d'un tel réseau. Conventionnellement, un objet conforme à la spécification LoRaWAN émet une requête d'adhésion « join-request » vers un serveur du réseau de sorte à rejoindre te réseau. C'est une fois que le serveur a accepté cette requête que l'objet peut ensuite transmettre des 20 données utiles au réseau. Pour éviter que l'objet ne soit confondu avec un autre noeud du réseau, l'objet dispose d'un identifiant unique DevUID et d'au moins une cté secrète (une clé AppKey dans ta version 1.0 de ta spécification LoRaWAN, une paire de clés AppKey et NwKkey dans ta version 1.1). L'identifiant est envoyé en clair dans ta requête d'adhésion. Par ailleurs, chaque clé secrète 25 est utilisée pour sécuriser le contenu requête d'adhésion, sans toutefois être divulguée. Bien entendu, un tiers malveillant parvenant à découvrir ta cté secrète pourrait constituer un clone de l'objet, afin que ce clone émette de son côté des requêtes d'adhésion de même contenu que celles émises par t'objet, se faisant ainsi passer pour ce dernier auprès du réseau. Ce type d'attaque est appelé attaque par clonage. 30 Pour éviter de telles attaques par clonage, il est généralement prévu dans l'objet un élément sécurisé (Secure Element) faisant office de coffre-fort inviolable pour stocker et garder secrète garder ta cté. Toutefois, l'incorporation d'un tel élément sécurisé représente un surcoût de fabrication d'un objet connecté ; il existe donc de nombreux objets connectés ne disposant 35 pas d'un tel élément sécurisé pour se prémunir d'attaques par clonage. 2 On connaît par ailleurs de l'état de ta technique plusieurs procédés pour détecter un clone dans un réseau d'objets connectés. Un premier procédé connu pour détecter un clone consiste à envoyer à un objet qui souhaite rejoindre le réseau une requête d'authentification. Pour ne pas être considéré comme un clone, l'objet doit alors répondre à la requête avec un message de réponse contenant une clé d'anti-clonage. Selon un deuxième procédé, un cloné est détecté au moyen d'un nombre aléatoire transmis dans le réseau. Les procédés proposés présentent toutefois l'inconvénient de nécessiter des modifications substantielles au niveau des objets à protéger contre du clonage (opérations cryptographiques additionnelles, stockage de données supplémentaires au niveau des objets, communications additionnelles entre objets). EXPOSE DE L'INVENTION Un but de l'invention est de signaler l'existence potentielle d'un clone se faisant potentiellement un objet dans un réseau connecté, d'une manière très simple et peu coûteuse à implémenter. Il est donc proposé un procédé de communication d'un objet avec un serveur d'un réseau d'objets connectés pour signaler qu'un clone se fait potentiellement passer pour l'objet dans le réseau, te procédé comprenant les étapes suivantes mises en oeuvre par l'objet : - transmission au serveur d'une requête d'adhésion de l'objet au réseau d'objets connectés, - après la transmission de la requête d'adhésion, détection d'un rejet ou d'une non- prise en compte d'un message de référence transmis par l'objet au serveur, - en réponse à ta détection, transmission au serveur d'un message d'alerte indiquant te rejet ou ta non prise en compte. Le procédé de communication selon l'invention peut également comprendre tes caractéristiques suivantes, prises seules ou en combinaison lorsque cela est techniquement 30 possible. De préférence, te message d'alerte est une nouvelle requête d'adhésion au réseau d'objets connectés. De préférence, ta requête d'adhésion transmise avant la détection comprend une première valeur n'indiquant pas de rejet ou de non prise en compte d'un quelconque message 3 transmis par l'objet au serveur, et ta nouvelle requête d'adhésion comprend, en lieu et place de ta première valeur, une deuxième valeur indiquant le rejet ou ta non prise en compte. De préférence, la première valeur est un nonce destiné à être utilisé par te serveur pour détecter des attaques par rejeu. 5 De préférence, la première valeur occupe un emplacement prédéterminé de N bits dans la requête d'adhésion transmise avant ta détection, ta deuxième valeur occupe te même emplacement prédéterminé de N bits dans la nouvelle requête d'adhésion, et ta deuxième valeur est égale à zéro ou 2N-1. De préférence, ta première valeur et ta deuxième valeur occupent te champ DevNonce 10 défini par une spécification LoRaWAN. De préférence, te message de référence est transmis par l'objet au serveur après la requête d'adhésion, et transporte par exemple des données utiles. De préférence, il est détecté une non prise en compte du message de référence lorsqu'aucun accusé de réception du message de référence n'est reçu par l'objet dans un 15 délai prédéterminé à compter de la transmission du message de référence. De préférence, te procédé de communication comprend en outre un rejet ou une non prise en compte par te serveur d'une requête d'adhésion qui est transmise au serveur après le message d'alerte et qui comprend un identifiant unique propre à l'objet. De préférence, la requête d'adhésion ou te message de référence comprend un code 20 d'intégrité généré à partir d'une première clé secrète propre à l'objet, et dans lequel te message d'alerte comprend un code d'intégrité généré à partir d'une deuxième cté secrète propre à l'objet différente de la première clé secrète. De préférence, le code d'intégrité de la requête d'adhésion ou du message de référence est généré par application d'une fonction prédéterminée à la première clé secrète propre à 25 l'objet, et dans lequel te code d'intégrité du message d'alerte est généré par application de La même fonction prédéterminée à ta deuxième cté secrète propre à l'objet. Il est également proposé un objet comprenant une interface de communication avec un serveur d'un réseau d'objets connectés, l'objet comprenant par ailleurs un processeur configuré pour : - commander une transmission au serveur d'une requête d'adhésion de l'objet au réseau d'objets connectés, - après la transmission de ta requête d'adhésion, détecter un rejet ou d'une non-prise en compte d'un message de référence transmis par l'objet au serveur, - en réponse à la détection, commander une transmission au serveur d'un message d'alerte indiquant le rejet ou la non prise en compte. 4 DESCRIPTION DES FIGURES D'autres caractéristiques, buts et avantages de l'invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : [Fig. 1] - La figure 1 illustre de façon schématique un système de navigation selon un premier mode de réalisation de l'invention ; [Fig. 2] 10 - La figure 2 est un organigramme d'étapes d'un procédé de communication selon un mode de réalisation de l'invention ; [Fig. 3] - La figure 3 illustre schématiquement des messages échangés par un objet, un serveur de réseau d'objets connectés et un clone cherchant à se faire passer pour l'objet dans 15 le réseau, au cours d'une mise en oeuvre du procédé de ta figure 2. Sur l'ensemble des figures, tes éléments similaires portent des références identiques. DESCRIPTION DETAILLEE DE L'INVENTION On a schématiquement représenté en figure 1 un objet 1 susceptible d'être connecté 20 à un réseau d'objets connectés via un serveur 2. L'objet 1 comprend au moins un processeur 10, au moins une mémoire 12 et une interface de communication 14 avec le serveur 2. Le processeur 10 est configuré pour exécuter des programmes d'ordinateur. L'interface de communication 14 est par exemple du type radio sans fit. 25 Dans ce qui suit, on prendra l'exemple d'une interface de communication 14 destinée à émettre ou recevoir des messages conformes à la spécification LoRaWAN®, auquel cas te réseau d'objets connecté est un réseau également conforme à cette spécification LoRaWAN. La mémoire 12 de l'objet 1 comprend au moins une mémoire non volatile est destiné à stocker des données de calcul de manière persistante (HDD, SSD, Flash, etc.), en particulier 30 les données suivantes, lorsque ta spécification LoRaWAN version 1 est utilisée : - DevEUI : un identifiant unique propre à l'objet 1, assimilable à un numéro de série. - AppEUI : un identifiant d'application unique propre à un fournisseur d'application de l'objet 1. Il permet de classer différents objets tels que l'objet 1 par application. Dans la spécification LoRaWAN version 1.1, pouvant également être utilisée, AppEUI et 35 remplacée par une donnée JoinEUI. 5 Similairement, le serveur 2 comprend au moins un processeur 20, au moins une mémoire 22 et une interface de communication 24 avec au moins un objet tel que l'objet 1. Le processeur 20 du serveur 2 est également configuré pour exécuter des programmes d'ordinateur. 5 La mémoire 22 du serveur 2 comprend au moins une mémoire non volatile est destiné à stocker des données de calcul de manière persistante (HDD, SSD, Flash, etc.). L'interface de communication 24 est configurée pour interagir avec l'interface de communication 14 de l'objet 1 ; elle est par conséquent du même type. En référence à l'organigramme de la figure 2, un procédé pour signal l'existence 10 potentielle d'un clone de l'objet 1 dans te réseau d'objets connectés comprend les étapes suivantes. Le processeur 10 de l'objet 1 génère un nonce (étape 100). Comme il sera détaillé ci-après, ce nonce est destiné à être passé en paramètre d'une requête d'adhésion à un réseau d'objets connectés, transmise par l'objet 1 au serveur 2. Le serveur 2 garde trace de 15 certaines valeurs de ce nonce utilisées par l'objet 1 par le passé, et ignore toute requête d'adhésion qui réutiliserait l'une de ces valeurs, de manière à assurer une protection contre des attaques par rejeu. Le nonce est une valeur comprise dans une plage de valeurs prédéterminées codables sur N bits. 20 La plage de valeurs ne comprend pas toutes les valeurs prédéterminées qui sont codables sur N bits. Autrement dit, cette plage comprend un nombre de valeurs entières strictement inférieur à 2N. La plage de valeurs comprend par exemple 2N-1 valeurs ; il existe alors une seule valeur codable sur N bits que ne peut pas prendre te nonce. 25 Le nonce est par exemple la donnée DevNonce définie dans ta spécification LoRaWAN. Cette donnée est codée sur deux octets (N=16). Le nonce peut alors avoir 65535 valeurs différentes (et non 653536 comme proposé dans les spécifications LoRaWAN). Le processeur 10 de l'objet 1 génère une requête d'adhésion à un réseau d'objets connectés (étape 104). 30 La requête d'adhésion est un message - join-request » conforme à la spécification LoRaWAN. Le message join-request comprend alors, de manière conventionnelle, les données suivantes : DevEUI, AppEUI (ou JoinEUl) et DevNonce. L'objet 1 génère par ailleurs un code d'intégrité MIC relatif à ta requête d'adhésion (étape 102). Ce code d'intégrité MIC a pour but d'authentifier ta requête d'adhésion auprès 35 d'un destinataire, autrement dit, de permettre à un tel destinataire de vérifier si ta requête 6 d'adhésion a été émis par un objet 1 agréé et si les données contenues dans la requête d'adhésion sont cohérentes. Le code d'intégrité MIC est généré de manière classique via un chiffrement AES utilisant au moins une clé secrète propre à l'objet 1 : par exemple, la clé AppKey dans ta version 1.0 5 de ta spécification LoRaWAN, une paire de clés AppKey et NwKkey dans la version 1.1 de ta spécification LoRaWAN. La requête d'adhésion est transmise par l'interface de communication au serveur 2 (étape 106). Le code d'intégrité MIC est également transmis au serveur 2 dans la requête d'adhésion. 10 La requête d'adhésion est reçue par l'interface de communication 24 du serveur 2, qui le transmet au processeur 20 pour être traitée. Le processeur 20 met en oeuvre de manière classique un contrôle d'intégrité de ta requête d'adhésion en s'aidant du code d'intégrité candidat MIC. Si ce contrôle se solde par un échec, alors la requête d'adhésion est rejetée ou ignorée par te serveur 2. 15 Par ailleurs, le processeur 20 compare la valeur DevNonce de la requête d'adhésion reçue avec un historique de valeurs de DevNonce préalablement reçues et mémorisées dans la mémoire 22. Si la valeur de DevNonce reçue et égale à l'une des valeurs de l'historique, le serveur 2 rejette ou ta toute requête d'adhésion, de manière à assurer une protection contre des attaques par rejeu. 20 De façon conventionnelle, le serveur 2 transmet à l'objet 1 un message de réponse - join-accept -, lui indiquant que la requête d'adhésion a été acceptée par te serveur 2. Sinon, le serveur 2 ne transmet par exemple aucun message de réponse « join-accept L'objet 1, désormais adhérent au réseau d'objets connectés, peut transmettre au serveur 2 d'autres types de messages, notamment des messages formellement appelés dans 25 la suite - messages de référence » (étape 108). Pour être acceptés par le serveur 2, ces messages sont censés être cohérents avec la dernière requête d'adhésion reçue est acceptée par le serveur 2. Dans le cas de LoRaWAN (spécification 1), cette cohérence est assurée par deux clés de session NwkSKey, AppSKey servant pour crypter et authentifier tes messages échangés par 30 l'objet 1 et le serveur 2. Côté objet 1, ces clés de session NwkSKey, AppSKey sont dérivées de la clé secrète AppKey, et sont renouvelées pour chaque nouvelle requête d'adhésion (à t'aide de compteurs). Ces clés de session sont par ailleurs déterminées par te serveur 2 sur la base des informations fournies dans ta requête d'adhésion, sans pour autant que ces clés de session soit transmises en clair dans la requête d'adhésion, selon un procédé connu. Tous 35 les messages de référence émis ultérieurement par l'objet 1 comprenant un code d'intégrité 7 (champ MIC) qui est calculé sur la base des dés de session NwkSKey, AppSKey négociées avec le serveur 2. Un exemple de message de référence est un message contenant des données utiles. On entend par données « utiles des données différentes de métadonnées ayant pour fonction 5 de contrôler ta communication des données utiles. Le message de liaison montante « uptink » défini dans ta spécification LoRaWAN est un message transportant des données utiles et constitue par conséquent un exemple de message de référence. Lorsque te serveur 2 reçoit un message de référence, il peut en accuser réception à 10 L'objet 1 via un message d'accusé de réception qui est retourné à l'objet 1. En particulier, un message d'accusé de réception de type ACK » peut être émis par le serveur 2 en réponse à la réception d'un message de liaison montante « uptink » demandant un tel accusé réception (- confirmed uptink -), dans le cas d'un réseau LoRaWAN. Il est toutefois à noter qu'un message de liaison montante - uptink » d'un type ne 15 nécessitant pas d'accusé de réception peut être émis par l'objet 1. Lorsque te serveur 2 recoit ce type de message, il n'envoie donc pas d'accusé de réception « ACK » à l'objet 1. Toutefois, il se peut que te serveur 2 ne transmette pas un tel message d'accusé de réception à l'objet 1 en réponse à un message de référence, et rejette ce message de référence. 20 Un tel phénomène survient typiquement lorsqu'un clone cherchant à se faire passer pour l'objet 1, transmet une requête d'adhésion au serveur 2 comprenant te DevUID permettant d'identifier en propre l'objet 1, et que cette requête d'adhésion est acceptée par le serveur 2, juste avant que l'objet 1 envoie un message de liaison montante. En effet, l'acceptation par le serveur 2 de ta requête d'adhésion émise par te clone 25 entraîne une mise à jour par le serveur 2 des clés de sessions NwkSKey, AppSKey associés à L'identifiant DevUID, sans que L'objet 1 n'en soit informé. Ainsi, tout message de référence émis par l'objet 1 après acceptation par te serveur 2 de cette requête d'adhésion - pirate sera rejeté, leurs codes d'intégrité MIC n'ayant pas été calculés sur les dernières clés de session NwkSKey, AppSKey acceptées par te serveur 2. 30 Un tel scénario est illustré en figure 3, laquelle montre des échanges de message entre l'objet 1 mettant en oeuvre le procédé de la figure 2, te serveur 2 et un clone C cherchant à se faire passer pour l'objet 1 dans un réseau LoRaWAN. Sur ta figure 3, te clone C est illustré par une icône sombre et l'objet 1 est illustré par une icône comparativement plus claire. L'objet 1 met en oeuvre une étape de détection d'un rejet ou d'une non-prise en 35 compte d'un message de référence transmis par l'objet 1 au serveur 2 (étape 110). 8 Par exemple, l'objet 1 détecte une non prise en compte ou un rejet du message de référence lorsqu'aucun accusé de réception du message de référence n'est reçu par l'objet 1 dans un délai prédéterminé à compter de la transmission du message de référence. Pour cela, l'objet 1 peut utiliser un compteur de temps qui est réinitialisé à chaque fois que te 5 délai expire ou qu'un accusé réception est reçu. En réponse à la détection 110, l'objet 1 transmet au serveur 2 génère un message d'alerte indiquant te rejet ou la non prise en compte du message de référence (étape 112), et le transmet au serveur 2 (étape 114). Il est à noter que t'étape 114 de transmission du message d'alerte peut être déclenchée 10 après une seule tentative infructueuse de transmissions d'un message de référence, ou bien seulement après N tentatives infructueuses de transmissions d'un message de référence, N étant strictement supérieur à 1, par exempte égal à 3. Le message d'alerte est de préférence une nouvelle requête d'adhésion au réseau d'objets connectés. Ceci présente plusieurs avantages. Premièrement, le fait de réutiliser 15 une requête déjà existante dans te protocole de communication utilisé a pour effet de ne pas complexifier de manière importante ce protocole de communication. Autrement dit, cette fonction complémentaire d'alerte est par conséquent plus facile à déployer via mise à jour dans un objet 1 déjà utilisé. Deuxièmement, le fait d'utiliser spécifiquement une requête d'adhésion pour assurer cette fonction d'alerte présente l'avantage de limiter tes 20 échanges de communication pour permettre à l'objet 1 de non seulement remonter une alerte mais également de reprendre la main sans délai sur ta communication préalablement interrompue tacitement par le clone C. Dans ta suite, on établit une distinction entre des requêtes d'adhésion avec fonction d'alerte, et requêtes d'adhésion classiques n'assurant pas cette fonction additionnelle 25 d'alerte. De manière générale, une requête d'adhésion avec fonction d'alerte se distingue d'une requête d'adhésion classique de la manière suivante : - Une requête d'adhésion classique comprend, en un emplacement prédéfini, une première valeur n'indiquant pas de rejet ou de non prise en compte d'un quelconque 30 message de référence transmis par l'objet 1. - Une requête d'adhésion avec fonction d'alerte comprend, en lieu et place de ta première valeur au même emplacement prédéfini, une deuxième valeur indiquant te rejet ou ta non prise en compte d'un message de référence transmis par l'objet 1. 9 Comme indiqué précédemment, te champ DevNonce d'une requête « join-request - est occupé par un nonce ayant une première valeur choisie dans une plage de valeurs prédéterminée. Par conséquent, une requête d'adhésion de type « join-request » avec fonction d'alerte 5 diffère de préférence d'une requête d'adhésion de type - join-request- sans fonction d'alerte par Le remplacement, dans te champ DevNonce, de ta première valeur par une deuxième valeur exclue de cette plage de valeurs prédéterminée, cette deuxième valeur étant elle-même prédéterminée. De préférence, ta deuxième valeur est égale à 0 ou égal à 2N-1 (c'est-à-dire te nombre 10 dont la représentation comprend N bits tous égaux à 1). Ces deux valeurs particulières sont les valeurs minimale et maximales codabtes sur N bits. En particulier, le champ DevNonce comprend 2 octets (N=6). La deuxième valeur peut dans ce cas être égale à 0x0000 ou OxFFFF. Choisir l'une ou l'autre des valeurs extrémales 0 et 2H-1 présente l'avantage de très 15 peu perturber le fonctionnement du serveur 2 se servant du contenu du champ DevNonce pour détecter des attaques par rejeu, puisque toutes tes valeurs que peuvent prendre te nonce transmis dans te champ DevNonce d'une requête d'adhésion classique sont choisies dans un unique intervalle. Ceci est particulièrement vrai dans certains modes de réalisation où le nonce que t'objet 1 insère dans le champ DevNonce n'est pas choisi de manière 20 totalement aléatoire, mais plutôt par incrémentation d'un compteur. Parmi ces deux valeurs, choisir 211-1 comme deuxième valeur (d'alerte) présente l'avantage de perturber au minimum de telles implémentations à base de compteur, puisqu'un compteur est conventionnellement réinitialisé à la valeur O. A l'opposé, choisir 0 comme deuxième valeur (d'alerte) présente l'avantage d'être clairement identifiable car 25 indépendante de N. En variante, un bit parmi tes N du champ DevNonce peut être réserver pour l'alerte de clonage potentiel (par exemple, 1 peut signifier l'alerte, tandis que 0 peut signifier l'absence d'alerte). Cette variante présente toutefois l'inconvénient de diviser sensiblement par deux la taille de ta plage de valeurs dans laquelle te nonce est choisi, ce qui réduit par conséquent 30 l'efficacité du mécanisme de protection contre des attaques par rejeu auquel ce nonce est destiné. En recevant te message d'alerte par son interface de communication 16, te serveur 2 est mis au courant d'une potentielle existence d'un clone dans le réseau se faisant passer pour l'objet 1, et peut y remédier par un traitement approprié. 10 En réponse à ta réception d'un tel message d'alerte, une solution radicale que te processeur 20 peut mettre en oeuvre pour empêcher le clone C d'accéder au réseau d'objets connectés est tout simplement de refuser toute requête d'adhésion ultérieure qui comprendrait te même DevEUI que celui remonté dans la requête d'adhésion avec alerte. Pour renforcer ta confiance du message d'alerte émis, il peut être prévu d'inclure dans le message d'alerte un code d'intégrité (MIC dans le cas LoRaWAN) généré par l'objet 1 sur la base d'une clé secrète différente de celle utilisée pour générer un code d'intégrité inclus dans une requête d'adhésion classique. Les fonctions prenant en entrée ces deux clés différentes pour générer tes codes d'intégrités dans te message d'alarme et dans une requête 10 d'adhésion classique sont identiques. Ce mécanisme présente l'avantage d'être facile à déployer dans des réseaux existants, notamment dans le cas où te message d'alerte est en fait une requête d'adhésion contenant une information d'alerte. REVENDICATIONS1. Procédé de communication d'un objet (1) avec un serveur (2) d'un réseau d'objets connectés pour signaler qu'un clone se fait potentiellement passer pour l'objet dans te réseau, te procédé comprenant les étapes suivantes mises en oeuvre par l'objet (1) : - transmission (106) au serveur (2) d'une requête d'adhésion (join-request) de l'objet (1) au réseau d'objets connectés, - après ta transmission de ta requête d'adhésion, détection (110) d'un rejet ou d'une non-prise en compte d'un message de référence (uplink) transmis par l'objet (1) au serveur (2), - en réponse à La détection, transmission (114) au serveur (2) d'un message d'alerte indiquant le rejet ou la non prise en compte. 2. Procédé selon l'une des revendications précédentes, dans lequel te message d'alerte est une nouvelle requête d'adhésion au réseau d'objets connectés. 15 3. Procédé selon l'une des revendications précédentes, dans lequel la requête d'adhésion transmise avant la détection comprend une première valeur n'indiquant pas de rejet ou de non prise en compte d'un quelconque message transmis par l'objet (1) au serveur (2), et la nouvelle requête d'adhésion comprend, en lieu et place de la première valeur, une deuxième 20 valeur indiquant le rejet ou la non prise en compte. 4. Procédé selon la revendication 3, dans lequel la première valeur est un nonce destiné à être utilisé par le serveur pour détecter des attaques par rejeu. 25 5. Procédé selon l'une des revendications 3 à 4, dans lequel ta première valeur occupe un emplacement prédéterminé de N bits dans ta requête d'adhésion transmise avant la détection, la deuxième valeur occupe te même emplacement prédéterminé de N bits dans ta nouvelle requête d'adhésion, et la deuxième valeur est égale à zéro ou 2N-1. 30 6. Procédé selon l'une des revendications 3 à 5, dans lequel la première valeur et la deuxième valeur occupent te champ DevNonce défini par une spécification LoRaWAN. 7. Procédé selon l'une des revendications précédentes, dans lequel te message de référence est transmis par l'objet (1) au serveur après la requête d'adhésion, et transporte par exemple 35 des données utiles. 12 8. Procédé selon l'une des revendications précédentes, dans lequel il est détecté une non prise en compte du message de référence lorsqu'aucun accusé de réception du message de référence n'est reçu par l'objet dans un délai prédéterminé à compter de ta transmission du 5 message de référence. 9. Procédé selon l'une des revendications précédentes, comprenant en outre un rejet ou une non prise en compte par te serveur d'une requête d'adhésion qui est transmise au serveur après te message d'alerte et qui comprend un identifiant unique propre à l'objet. 10 10. Procédé selon t'une des revendications précédentes, dans lequel la requête d'adhésion ou le message de référence comprend un code d'intégrité généré à partir d'une première cté secrète propre à l'objet (1), et dans lequel te message d'alerte comprend un code d'intégrité généré à partir d'une deuxième clé secrète propre à l'objet (1) différente de ta première cté secrète. 11. Procédé selon la revendication précédente, dans lequel le code d'intégrité de ta requête d'adhésion ou du message de référence est généré par application d'une fonction prédéterminée à ta première clé secrète propre à l'objet (1), et dans lequel le code d'intégrité du message d'alerte est généré par application de la même fonction prédéterminée à ta deuxième cté secrète propre à ('objet (1). 12. Objet (1) comprenant une interface de communication (14) avec un serveur (2) d'un réseau d'objets connectés, l'objet (1) comprenant par ailleurs un processeur (10) configuré pour : - commander une transmission au serveur (2) d'une requête d'adhésion (join-request) de l'objet (1) au réseau d'objets connectés, - après ta transmission de la requête d'adhésion, détecter un rejet ou d'une non-prise en compte d'un message de référence transmis par l'objet (1) au serveur (2), - en réponse à la détection, commander une transmission au serveur (2) d'un message d'alerte indiquant le rejet ou la non prise en compte.