FR 3044499 A1 20170602 FR 1561408 A 20151126 1 MÉTHODE D'ÉTABLISSEMENT D'UNE COMMUNICATION SÉCURISÉE DE BOUT EN BOUT ENTRE LE TERMINAL D'UN UTILISATEUR ET UN OBJET CONNECTÉ DESCRIPTION DOMAINE TECHNIQUE L'objet de la présente invention concerne la sécurité des réseaux et plus particulièrement celle de l'Internet des objets ou loT (Internet of Things). ÉTAT DE LA TECHNIQUE ANTÉRIEURE L'apparition de technologies radio pervasives et à faible débit, adaptées à des objets autonomes et à faible consommation d'énergie, a permis récemment le développement de Internet des objets (loT). L'IoT permet à un utilisateur d'accéder à des informations, encore dénommées ressources, issues de capteurs ou d'actionneurs, souvent distants et à faible autonomie. Le schéma retenu actuellement consiste à virtualiser ces ressources dans une passerelle (gateway) ou un serveur, connecté(e) à Internet ou à l'infrastructure. La sécurité de bout en bout (end-to-end), c'est-à-dire de l'utilisateur à la ressource, est assurée en fait entre l'utilisateur et l'élément virtualisant la ressource. Cela implique que l'élément qui stocke les ressources virtuelles soit un élément de confiance (trusted). La Fig. 1 représente un scénario classique d'accès d'un utilisateur à une ressource associée à un objet. L'utilisateur dispose d'une « machine », 110, (au sens de M2M), généralement un smartphone, une tablette ou un ordinateur et se connecte à Internet, 150. Par l'intermédiaire d'une application, située sur un serveur d'applications, 120, dans le Cloud, il peut accéder à des ressources distantes fournies par des objets connectés, 190, contraints en mémoire, en puissance de calcul et en énergie. Ces objets peuvent communiquer avec des passerelles 180 via des liaisons radio à faible énergie aux moyens de standards de communication tels que IEEE 802.15.4, Bluetooth, Zigbee, etc. 3044499 2 Les passerelles 180 assurent l'interopérabilité entre les standards de communication précités et ceux utilisés par les passerelles pour leur liaison à Internet (par exemple Wifi, Ethernet, GPRS). En revanche, les passerelles 180 ne sont pas capables d'assurer l'interopérabilité des protocoles de sécurité entre les objets connectés et 5 Internet. Pour cette raison, elles stockent les informations issues des différents objets connectés, ce qui implique qu'elles soient de confiance. Il est connu dans une telle architecture de garantir la sécurité de la communication entre l'utilisateur et la passerelle de virtualisation au moyen d'un chiffrement. Les principes de sécurité par la conception (security by design) imposent de faire transiter le matériel de 10 chiffrement (clés de chiffrement, jetons, graines de générateurs pseudo-aléatoires) par un chemin distinct de celui emprunté par les données. Dans ce cas, l'utilisateur s'identifie d'abord au moyen d'un login/mot de passe auprès d'un serveur de sécurité 130. En cas de succès, le serveur de sécurité distribue un même jeton d'accès à l'utilisateur et à la passerelle de virtualisation 180. Ce jeton d'accès indique que l'utilisateur possède un droit 15 d'accès à la ressource via une application donnée (du serveur d'applications). Le matériel de chiffrement, notamment des clés de chiffrement symétriques, sont également distribuées à l'utilisateur et à la passerelle via un canal sécurisé (SSL/TLS ou IPsec). L'utilisateur et l'élément stockant la ressource virtuelle peuvent ensuite communiquer de façon confidentielle. 20 Diverses solutions existent pour assurer une sécurité de communication de bout en bout entre la machine de l'utilisateur et l'objet connecté. Une première solution est d'équiper l'objet connecté d'un élément de sécurité (secure element) tel qu'une carte SIM par exemple. Toutefois dans le contexte d'objets 25 connectés à très faible autonomie, cette solution est exclue en pratique. Une seconde solution, consiste à pousser le jeton de d'accès ainsi que le matériel de chiffrement depuis le serveur de sécurité jusqu'à l'objet connecté. Le jeton d'accès et éventuellement le matériel cryptographique associé transitent alors par une passerelle qui doit être de confiance (trusted) car elle a accès en clair à ces informations lors de la 3 0 conversion de protocole. La notion de sécurité end-to-end est alors interrompue au niveau 3044499 3 de la passerelle. Une troisième solution consiste à générer ou à insérer le matériel cryptographique dans l'objet connecté avant son déploiement et à utiliser un canal hors bande pour le transmettre vers le serveur d'autorisation. Par exemple, l'utilisateur peut, dans un premier 5 temps, approcher son smartphone de l'objet connecté et récupérer par voie optique (signal lumineux, scan d'un QR code sur l'objet) une information décrivant numériquement la valeur secrète de la clé symétrique stockée dans l'objet lors de son déploiement. Le smartphone se connecte ensuite à l'infrastructure et transmet l'information de clé symétrique au serveur de sécurité via un canal sécurisé. Dans ce cas, le smartphone se 10 comporte comme une passerelle de confiance (trusted). La clé symétrique est alors stockée dans le profil de l'utilisateur au niveau du serveur de sécurité pour l'établissement d'une communication sécurisée avec l'objet connecté. Le serveur de sécurité peut ensuite pousser le matériel de chiffrement (une clé secrète) ainsi qu'un jeton d'accès jusqu'à l'objet connecté. L'utilisateur dispose des mêmes informations via sa liaison sécurisée avec le 15 serveur de sécurité et peut donc établir une communication sécurisée avec l'objet connecté. Cette troisième solution n'est toutefois pas satisfaisante dans la mesure où elle nécessite, d'une part, d'utiliser un canal hors bande et, d'autre part, d'utiliser une passerelle de confiance, le smartphone dans ce cas. 20 L'objet de la présente invention est par conséquent de proposer une méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur et un objet connecté, notamment un objet connecté contraint en termes d'énergie, de mémoire et de capacité de calcul, qui ne présente pas les inconvénients de l'état de l'art. En particulier, la méthode d'établissement de la communication sécurisée 25 avec l'objet connecté devra permettre de se dispenser d'un élément de sécurité intégré dans cet objet connecté ainsi que d'un canal de communication auxiliaire pour faire transiter le matériel cryptographique. Enfin et surtout, elle devra permettre d'avoir accès directement à la ressource fournie par l'objet connecté sans requérir de virtualisation ni de passerelle de confiance. 3044499 4 EXPOSÉ DE L'INVENTION La présente invention est définie par une méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur/ un serveur d'intermédiateur de contexte et un objet connecté, ladite méthode mettant en oeuvre un 5 premier serveur, dit serveur d'autorisation d'accès et un second serveur, dit serveur de production, le terminal de l'utilisateur communiquant avec le serveur d'autorisation d'accès par une première communication sécurisée et le serveur de production communiquant avec le serveur d'autorisation d'accès par une seconde communication sécurisée, le serveur d'autorisation d'accès hébergeant une première base de données 10 contenant des informations permettant d'authentifier les différents utilisateurs et de gérer leurs droits d'accès aux différents objets connectés, le serveur de production hébergeant une seconde base de données contenant des identifiants d'objets connectés et possédant un couple de clés privée et publique initiales (Kunt,Q.,), ladite méthode comprenant les étapes suivantes : 15 (a) sur une requête de l'utilisateur contenant l'identifiant de l'objet connecté ( SN ), demande de vérification du serveur d'autorisation d'accès auprès du serveur de production que cet identifiant est bien valide ; (b) sur initialisation de l'objet connecté, identification et authentification de l'objet connecté auprès du serveur de production, au moyen d'un premier message (M1) 20 contenant l'identifiant de l'objet connecté ainsi que ce même identifiant, chiffré par la clé publique initiale (Q. ); (c) en cas de succès d'authentification de l'objet connecté, génération par le serveur d'autorisation d'accès d'un second message (M2) contenant les paramètres d'un cryptosystème, le second message étant préalablement signé par le serveur de production, 25 le message ainsi que sa signature ( sgn (M2) ) étant transmis à l'objet connecté; (d) génération par l'objet connecté d'un couple de clés privée et publique d'accès (KF,QF), à partir des paramètres du cryptosystème, permettant d'établir une troisième communication sécurisée (225) entre le serveur d'autorisation d'accès et l'objet connecté; (e) établissement d'une communication sécurisée entre le terminal de 3044499 5 l'utilisateur, resp. le serveur d'intermédiation de contexte, et l'objet connecté au moyen d'une clé symétrique, distribuée par le serveur d'autorisation d'accès, d'une part au terminal d'utilisateur via la première communication sécurisée, resp. au serveur d'intermédiation via une quatrième communication sécurisée, et, d'autre part, à l'objet 5 connecté via la troisième communication sécurisée. A l'étape (a), le serveur de production effectue avantageusement un horodatage de l'identifiant de l'objet connecté et stocke l'estampille d'horodatage dans la seconde base de données en relation avec ledit identifiant. Lors de ou suite à son initialisation à l'étape (b), l'objet connecté génère un jeton 10 de session (TK) sous la forme d'un premier nombre aléatoire (RAU, ainsi qu'un second nombre aléatoire (RN2). Le premier message (M1) comprend avantageusement une première partie en clair comprenant l'identifiant de l'objet connecté (SN), et une second partie chiffrée au moyen de la clé publique initiale ( ent ), la seconde partie comprenant ce même identifiant, 15 la clé de session, ainsi que, le cas échéant, un certificat ( Cent ) de la clé publique initiale. A l'étape (b), le serveur de production identifie l'objet connecté si son identifiant est présent dans la seconde base de données. En outre, à l'étape (b), le serveur de production authentifie l'objet connecté en 20 déchiffrant la seconde partie du premier message à l'aide de la clé privée initiale et en comparant le résultat du déchiffrage avec la première partie. Préférentiellement, à l'étape (b), le serveur de production ne déclare l'objet connecté que si, à la date de l'authentification, l'estampille d'horodatage n'est pas périmée. 25 Le serveur de production peut alors transmettre au serveur d'autorisation d'accès le résultat de l'authentification (ACK ,NACK ) accompagné du numéro d'identifiant de l'objet connecté et, le cas échéant, du certificat de la clé publique initiale (Ce, ). En cas de succès d'authentification à l'étape (b), le serveur d'autorisation d'accès stocke dans la première base de données le jeton de session en relation avec l'identifiant 3044499 6 d'objet connecté. Avantageusement, à l'étape (c), le second message (M2 ) comprend l'identifiant d'objet connecté (SN), le jeton de session (TK ), la clé publique du serveur d'autorisation d'accès (0 1 - ----auth - 5 De préférence, le cryptosystème est un cryptosystème sur une courbe elliptique. Le serveur de production signe le second message au moyen de la clé privée initiale et renvoie la signature ainsi obtenue ( sgn(M2) au serveur d'autorisation d'accès. Le serveur d'autorisation d'accès transmet ensuite le second message (M2 ) ainsi que sa signature (sgn(M2) à l'objet connecté. 10 Selon une première variante, à l'étape (d), l'objet connecté génère une clé publique temporaire à partir du second nombre aléatoire et d'un point générateur (G ) sur la courbe elliptique. L'objet connecté peut alors générer un troisième message (M3) contenant, dans une première partie en clair, son identifiant et, dans une seconde partie chiffrée au moyen 15 de la clé publique du serveur d'autorisation d'accès 0auth - ( 1 - ---- certificat de la clé publique initiale (Cent), le jeton d'accès ainsi que la clé publique temporaire (Qteint, ). Le serveur d'autorisation d'accès génère avantageusement un certificat implicite d'une clé publique d'accès (CertF) ) ainsi qu'une signature de ce certificat (SignF) à partir 20 de la clé publique temporaire (Q'mp), d'un troisième nombre aléatoire (k), du jeton de session (TK ), de la clé privée du serveur d'autorisation (Kanth) et des paramètres du cryptosystème sur courbe elliptique. Le serveur d'autorisation d'accès génère ensuite un quatrième message (M4 ) comprenant le certificat implicite de la clé publique d'accès (CertF) ainsi que sa signature 25 ( SignF ), ce message ainsi que sa signature (Sgn(M4) au moyen de la clé privée du serveur d'autorisation d'accès étant transmis à l'objet connecté. et les paramètres d'un cryptosystème. ce même identifiant, le 3044499 7 L'objet connecté, après avoir vérifié l'intégrité du quatrième message au moyen de la clé publique du serveur d'autorisation d'accès, génère avantageusement ledit couple de clés privée et publique d'accès (KF,QF ) à partir du certificat implicite de la clé publique d'accès (CertF) et de sa signature (CertF), du jeton de session (TK ), de la clé publique 5 d'autorisation d'accès (0auth -l et des paramètres du cryptosystème sur courbe elliptique. - ---- Selon une seconde variante, l'objet connecté génère la clé privée d'accès (KF ) à partir du second nombre aléatoire (RAT2) et la clé publique d'accès (QF ) à partir de cette dernière et des paramètres du cryptosytème sur courbe elliptique. Dans ce cas, l'objet connecté génère avantageusement un troisième 10 message ( M3 ) contenant, dans une première partie en clair, son identifiant et, dans une seconde partie chiffrée au moyen de la clé publique du serveur d'autorisation d'accès Qauth), ce même identifiant, le certificat de clé initiale, CQ,,, , le jeton d'accès, ainsi que la clé publique d'accès (QF ). Le serveur d'autorisation d'accès génère alors un certificat X.509 (Certx 509) de la 15 clé publique d'accès (QF ), à partir de l'identifiant de l'objet connecté et de la clé publique d'accès, au moyen de sa clé privée d'autorisation d'accès (Kauth). Le serveur d'autorisation d'accès peut également générer un quatrième message (M4) comprenant le certificat de la clé publique d'accès (Certx 509) ainsi que sa signature ( Sign.th(M 4)) au moyen de la clé privée du serveur d'autorisation d'accès, ce message 2 0 ainsi que sa signature ( Signaua,(M 4)) étant transmis à l'objet connecté. Après avoir vérifié l'intégrité du quatrième message au moyen de la clé publique du serveur d'autorisation d'accès, l'objet connecté stocke avantageusement dans sa mémoire le certificat de la clé publique d'accès (Certx 509 ). 2 5 BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention, en faisant référence aux figures jointes 3044499 8 parmi lesquelles : La Fig. 1 représente schématiquement un scenario d'accès par un utilisateur à une ressource associée à un objet connecté tel que connu de l'état de la technique ; La Fig. 2 représente schématiquement l'architecture d'un système permettant 5 d'établir une communication sécurisée entre le terminal d'un utilisateur et un objet connecté ; La Fig. 3 représente schématiquement un ordinogramme d'une méthode d'établissement d'une communication sécurisée entre le terminal d'un utilisateur et un objet connecté, selon un mode de réalisation de l'invention ; 10 Les Figs. 4A et 4B représentent une première partie des échanges entre les éléments du système de la Fig. 2 lors de la mise en oeuvre de la méthode d'établissement d'une communication sécurisée selon le mode de réalisation de l'invention représenté en Fig. 3; La Fig. 5A représente une seconde partie des échanges entre les éléments du 15 système de la Fig. 2 lors de la mise en oeuvre de la méthode d'établissement d'une communication sécurisée selon une première variante du mode de réalisation de l'invention représenté en Fig. 3 ; La Fig. 5B représente une seconde partie des échanges entre les éléments du système de la Fig. 2 lors de la mise en oeuvre de la méthode d'établissement d'une 20 communication sécurisée selon une seconde variante du mode de réalisation de l'invention représenté en Fig. 3. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS Nous entendrons dans la suite par objets connectés des objets ayant une capacité de 25 communication, généralement au moyen d'un seul standard de communication sans fil (IEEE 802.15.4, Bluetooth, Zigbee, etc.) mais ne disposant que de ressources très limitées (CPU, RAM, taille de mémoire flash, énergie). Par exemple, les objets ne posséderont que quelques dizaines d'octets de RAM et quelques centaines voire quelques dizaine de kilooctets de mémoire flash. Ces objets connectés pourront être notamment des capteurs 3044499 9 organisés sous la forme de réseau sans fil ou WSN (Wireless Sensor Network). La Fig. 2 représente de manière schématique l'architecture d'un système permettant l'établissement d'une communication sécurisée entre le terminal d'un utilisateur et un 5 objet connecté. Le système, 200, comprend le terminal d'un utilisateur, encore dénommé plus simplement utilisateur, 210, un premier serveur, dit serveur d'autorisation d'accès, 220, et un second serveur, dit serveur de production, 230. Le terminal de l'utilisateur peut être un smartphone, une tablette ou un ordinateur. L'utilisateur peut se connecter au serveur 10 d'autorisation d'accès via Internet au moyen d'une communication sécurisée par un protocole tel que HTTPS (HyperText Transfer Protocol Secured) ou SSH (Secure SHell). Le serveur d'autorisation d'accès 220 héberge une première base de données, 221, contenant des informations permettant d'authentifier les différents utilisateurs, de gérer leurs droits d'accès aux différents objets connectés et ainsi d'autoriser l'accès des 15 utilisateurs à ces derniers. Pour ce faire, il gère les profils des différents utilisateurs ou groupes d'utilisateurs. Par exemple, à chaque utilisateur (ou groupe d'utilisateurs) est associée une liste d'objets connectés, déterminés par leurs identifiants respectifs. Ainsi, le serveur d'autorisation peut déterminer si un utilisateur donné peut accéder à telle ou telle ressource d'un objet connecté, le cas échéant en distinguant s'il peut y accéder via une 20 passerelle de virtualisation ou bien par une communication sécurisée de bout-en-bout. Le serveur de production, 230, est connecté au serveur d'autorisation au moyen d'une communication sécurisée 235, par exemple grâce à un protocole tel que HTTPS (HyperText Transfer Protocol Secured) ou SSH (Secure SHell). Le serveur de production héberge une seconde base de données, 231, contenant 25 notamment les identifiants (par exemple les numéros de série) des différents objets connectés ainsi que le matériel cryptographique initial qui a été utilisé lors du flash de leurs EEPROM (ou stocké dans une mémoire interne). Le matériel cryptographique initial peut comprendre un couple de clés publique et privée initiales (K. ,Q.) d'un système de chiffrement asymétrique ainsi le certificat Cent associé à la clé publique, par exemple un 30 certificat X.509. De préférence, toutefois, le chiffrement utilisé est un chiffrement sur 3044499 10 courbes elliptiques utilisant des certificats implicites dont le principe est rappelé ci-après. Dans ce cas, le certificat Cent de la clé publique initiale est constitué du certificat implicite Certin et de la signature du certificat, Sign. , par le serveur de production. Comme indiqué plus haut, le serveur de production peut utiliser un chiffrement 5 sur courbes elliptiques avec certificats implicites. On suppose que le serveur de production dispose d'un identifiant /Dp'd et d'un couple de clés privée et publique ( K p'd 0 prod ) d'un système asymétrique. Le certificat implicite Cellini, est d'abord construit à partir de deux nombres aléatoires 2 et 1u : 10 Certin = 2G+ duG mod. n (1) où G est un point générateur d'ordre n du cryptosystème elliptique. Le certificat implicite est donc un point de la courbe elliptique (multiple de G). La signature initiale est quant à 15 elle obtenue au moyen de : Signinit =hinit2+ K prod mod. n (2) où hinit = H (Cert.,1Dprod , 1 ^ H est une fonction de hash telle que SHA et 0 est le symbole 2 0 de concaténation. La clé publique initiale Qinit se déduit directement du certificat implicite : it =ntCertinit 0 prod (3) et la clé privée initiale associée est obtenue par : 25 Kinit =(hinitÀ+Signinit) mod. n (4) Les objets connectés 261, éventuellement organisés sous forme de réseau 260, ne 3044499 11 possèdent pas les ressources de communication leur permettant de se connecter directement à Internet. Ils utilisent pour ce faire une passerelle 250 qui réalise l'interface entre le standard de communication sans fil utilisé par les objets connectés (IEEE 802.15.4, Bluetooth, Zigbee, etc.) et l'infrastructure IP d'Internet. 5 Chaque objet connecté dispose d'un numéro de série (SN) qui lui est physiquement associé (par exemple inscrit sur l'objet en question). En outre, chaque objet connecté contient dans son EEPROM : - l'URL du serveur de production, URLprod qui a servi à flasher l'EEPROM ; - les éléments publics du matériel cryptographique initial, à savoir la clé publique 10 initiale, Qu, , ainsi que son certificat CQ,,, . L'URL du serveur de production, URLprod, ainsi que les éléments publics du matériel cryptographique initial sont avantageusement stockés dans une partie sécurisée (chiffrée) de la mémoire (EEPROM) de l'objet connecté. Les différents objets connectés produits pendant un intervalle donné de 15 production peuvent tous contenir les mêmes éléments de matériel cryptographique eut, Cent . Toutefois, le serveur de production peut disposer de plusieurs images précompilées du logiciel à installer dans les EEPROM des objets connectés, ces images précompilées correspondant à des matériels cryptographiques distincts (différents couples de clés ( Ktnt'nt) et différents certificats Cent). Lors de la production, les images précompilées 2 0 servent ensuite à flasher les EEPROM des objets connectés de manière aléatoire. Une fois que la communication sécurisée est établie de bout-en-bout, autrement dit du terminal de l'utilisateur à l'objet connecté, par le serveur d'autorisation d'accès, 220, l'utilisateur peut ensuite communiquer directement de manière sécurisée avec l'objet connecté. 25 Alternativement, le serveur d'autorisation d'accès, 220, peut permettre d'établir une communication sécurisée, 245, entre un serveur intermédiateur de contexte (context broker), 240, et l'objet connecté. On rappelle qu'un intermédiateur de contexte a pour fonction de contextualiser les données fournies par différents objets connectés, par exemple des mesures effectuées par différents capteurs, par exemple en les géolocalisant 3044499 12 et/ou en les horodatant. L'utilisateur peut alors consulter les données contextualisées au moyen d'une communication sécurisée. La Fig. 3 représente schématiquement un ordinogramme d'une méthode 5 d'établissement d'une communication sécurisée entre le terminal d'un utilisateur et un objet connecté, selon un mode de réalisation de l'invention. A une étape préalable 310, l'utilisateur 210 enregistre un objet connecté 261 auprès du serveur d'autorisation d'accès. Plus précisément, l'utilisateur transmet au 10 serveur d'autorisation d'accès une requête d'enregistrement ayant pour argument le numéro de série SN de l'objet connecté en question et l'URL URLp'd du serveur de production. Le serveur d'autorisation d'accès enregistre le numéro de série SN sous le profil de l'utilisateur ainsi que l'adresse URLprod associée à l'objet connecté. 15 Dans une première étape, 320, sur requête de l'utilisateur contenant l'identifiant de l'objet connecté (SN ), le serveur d'autorisation d'accès demande auprès du serveur de production si cet identifiant est bien valide. Sur réception de cette demande de vérification, le serveur de production peut effectuer un horodatage du numéro de série SN et enregistrer l'estampille d'horodatage 20 (ou valeur d'horodatage) obtenue, TS(SN) , dans la seconde base de données 231, en relation avec le numéro de série. Dans une seconde étape, 330, indépendante de la première, l'objet connecté est initialisé. Suite à cette initialisation, le serveur de production authentifie l'objet connecté. 25 Pour ce faire, l'objet connecté transmet au moyen d'un premier message (M1) contenant l'identifiant de l'objet connecté ainsi que ce même identifiant, chiffré par la clé publique initiale (Qin ) Plus précisément, lors de son initialisation, l'objet connecté génère un premier nombre aléatoire (RAU qui servira de jeton de session TK (TK = RNi) et un second 3044499 13 nombre aléatoire (RN2) qui servira à générer ultérieurement la clé privée de l'objet connecté. Les nombres aléatoires sont générés par exemple à partir d'une série de mesures physiques. L'objet connecté transmet ensuite au serveur de production 230 une demande 5 d'ouverture de session. A cette fin, l'objet connecté transmet au serveur de production un premier message, MI, comprenant dans une partie en clair le numéro de série de l'objet connecté et dans une partie chiffrée par la clé publique initiale, Q.,, le jeton de session, le numéro de série, SN, ainsi que le certificat de la clé publique initiale, CQ,,, 10 Le serveur de production 230 vérifie si le numéro de série est valide, c'est-à-dire s'il est bien répertorié dans la base de données 231. Il authentifie également l'objet connecté. Pour ce faire, le serveur de production déchiffre la partie chiffrée du premier message à l'aide de la clé privée initiale Kin et détermine si le numéro de série contenu dans la partie chiffrée est bien celui le numéro de série SN contenu dans la partie en clair 15 du premier message. Optionnellement, le serveur de production, vérifie que la valeur d'horodatage TS(SN) du numéro de série SN est récente, autrement dit qu'elle n'est pas antérieure à t -A où t est la date de contrôle et A est la durée de péremption. Dans le cas où le contrôle de péremption est mis en place, l'authentification n'est considérée comme réussie 20 que dans la mesure où l'horodatage n'est pas périmé. Lors d'une troisième étape, 340, en cas de succès d'authentification, le serveur d'autorisation d'accès génère un second message (M2) contenant les paramètres d'un cryptosystème, ce second message étant préalablement signé par le serveur de production, 25 le message ainsi que sa signature étant transmis à l'objet connecté. Plus précisément, en cas de succès de l'authentification, le serveur de production enregistre dans sa base de données 231 le jeton de session, TK, en relation avec le numéro de série SN . Il transmet également au serveur d'autorisation d'accès le résultat de l'authentification ( ACK ), accompagné du jeton de session, TK, et du certificat, CQ,,,, , 3044499 14 de la clé publique initiale. En cas d'échec de l'authentification, la procédure d'établissement de communication sécurisée de bout-en-bout est avortée. Le serveur d'autorisation est ainsi averti de l'identification et de l'authentification 5 de l'objet connecté par le serveur de production. Le serveur d'autorisation d'accès transmet alors à l'objet connecté un second message, M2, contenant toutes les informations nécessaires à la création d'un canal sécurisé entre le serveur d'autorisation d'accès et l'objet connecté. Toutefois, étant donné que le serveur d'autorisation d'accès est inconnu de l'objet connecté à ce stade, celui-ci 10 fait préalablement signer le message M2 par le serveur de production au moyen de la clé, K.,. Le serveur d'autorisation d'accès envoie le message M2, accompagné de la signature Sgnp'd (M2) ainsi obtenue, à l'objet connecté. Il faut noter que les informations contenues dans le message M2 sont publiques. De préférence, le message M2 contiendra (en clair) le numéro de série SN , le jeton de session TK , la clé publique du serveur 15 d'autorisation d'accès , Qauth ainsi que les paramètres d'un cryptosystème pour générer un couple de clés privée et publique. Par exemple, si le cryptosystème choisi est basé sur des courbes elliptiques, c'est-à-dire un cryptosystème ECC (Elliptic Curve Cryptography), les paramètres transmis sont les paramètres standards décrivant la courbe elliptique (taille du domaine, paramètres de la courbe, point générateur, ordre de la courbe et cofacteur). 20 A l'étape 350, l'objet connecté et le serveur d'autorisation d'accès peuvent établir une communication sécurisée au moyen du couple de clés privée et publique (Kauth ) ---auth - L'objet connecté et le serveur d'autorisation d'accès échangent au moyen de cette communication sécurisée les informations nécessaires pour générer un couple de clés 25 privée et publique (KF,QF ) ainsi qu'un certificat CertF de la clé publique QF. Plus précisément, au cours de cet échange l'objet connecté génère le couple de clés (KF,QF ) et le serveur d'autorisation d'accès génère le certificat CertF. On notera que l'opération la plus gourmande en ressources de calcul, à savoir la génération du certificat, est effectuée 3044499 15 par le serveur d'autorisation d'accès. Au terme de l'étape 350, le serveur d'autorisation d'accès dispose d'une part d'un premier canal sécurisé, 215, avec l'utilisateur et d'un second canal sécurisé, 225, (au moyen du couple de clés (KF,QF ) avec l'objet connecté). On notera qu'à la différence de l'état de 5 la technique la clé secrète KF a été générée par l'objet connecté lui-même. A l'étape 360, le serveur d'autorisation d'accès peut ensuite distribuer aux deux parties (utilisateur et objet connecté) une clé symétrique via les canaux sécurisés 215 et 225, pour établir une communication sécurisée de bout en bout entre elles. Alternativement, le serveur d'autorisation d'accès peut distribuer à l'objet 10 connecté et au serveur intermédiateur de contexte, 240, une clé symétrique via les canaux sécurisés 215 et 245 pour établir une communication sécurisée entre eux. En outre, le serveur d'autorisation d'accès peut transmettre via ces mêmes canaux sécurisés un jeton d'accès aux deux parties (l'objet connecté, d'une part, et le terminal d'utilisateur d'autre part ou bien l'objet connecté d'une part et le serveur intermédiateur 15 de contexte, d'autre part). Le jeton d'accès permet notamment d'accéder à des ressources ou des services particuliers fournis par le serveur intermédiateur. Les Figs. 4A et 4B représentent une première partie des échanges entre les différents éléments du système de la Fig. 2 lors de la mise en oeuvre de la méthode 2 0 d'établissement d'une communication sécurisée selon le mode de réalisation de l'invention précédemment décrit. Cette première partie est commune à une première et une seconde variantes de ce mode de réalisation. Les différents éléments du système ont été représentés dans le diagramme temporel, à savoir le terminal d'utilisateur 210, le serveur de production 230, le serveur 25 d'autorisation d'accès, 220, la passerelle 250 et l'objet connecté, 261. A l'étape 410, l'utilisateur transmet au serveur d'autorisation d'accès une requête d'enregistrement ayant pour argument l'identifiant (par exemple le numéro de série SN ) de l'objet connecté en question et l'URL URLprod du serveur de production. Cette requête est transmise sur le canal sécurisé 215 (HTTPS ou SSH). 3044499 16 Le serveur d'autorisation d'accès transmet ensuite en 420, via le canal sécurisé 235, une requête de vérification au serveur de production ayant pour argument l'identifiant de l'objet connecté. Le serveur de production détermine alors si l'identifiant est bien dans la seconde base de données 231. Dans l'affirmative, il procède en 421 à un 5 horodatage de la requête et stocke l'estampille d'horodatage TS(SN) dans la seconde base de données 231, en relation avec l'identifiant. Il confirme ensuite en 422 au serveur d'autorisation que l'objet connecté est bien identifié. A l'étape 430, l'utilisateur initialise l'objet connecté. Lors de son initialisation ou suite à celle-ci, l'objet connecté génère un premier nombre aléatoire (RAU qui servira de 10 jeton de session TK (TK = RNi) et un second nombre aléatoire ( RN2) qui servira à générer ultérieurement la clé privée de l'objet connecté. Il transmet ensuite en 431 au serveur de production un premier message M1 comprenant une partie en clair et une seconde partie chiffrée par la clé publique initiale, en,. La première partie contient l'identifiant (SN ) et la seconde partie contient le jeton de session, l'identifiant ainsi que le 15 certificat de la clé publique initiale, Ce, . Lorsque le chiffrement est un chiffrement sur courbes elliptiques utilisant des certificats implicites, le certificat Cent est constitué du certificat implicite Cert. et de sa signature, Sign. , par le serveur de production. Le serveur de production récupère l'estampille d'horodatage dans la seconde base de données, à partir de l'identifiant de l'objet connecté. En 432, si la valeur d'horodatage 20 est antérieure à t -A où t est la date de contrôle et A une durée de péremption, la déclaration de l'objet connecté est considérée comme périmée (ce qui nécessite un renouvellement de sa déclaration par l'utilisateur) et l'authentification échoue. Le serveur de production déchiffre ensuite la seconde partie du message et compare en 433 la valeur de l'identifiant dans la seconde partie déchiffrée avec celle dans la première part. Lorsque 25 ces deux valeurs coïncident, le serveur de production considère que l'objet connecté est authentifié. A défaut, l'authentification échoue. En tout état de cause, en 434, le serveur de production transmet au serveur d'autorisation d'accès, via le canal sécurisé 215, un message d'authentification. Celui-ci comprend l'identifiant de l'objet connecté (SN ), le jeton de session, TK , le certificat de la clé publique initiale Cent, ainsi que le résultat 3044499 17 d'authentification (ACK ou NACK ). Le serveur d'autorisation d'accès est ainsi averti que l'objet connecté a bien été identifié et authentifié. Il enregistre alors en 435, dans la première base de données, le jeton de session en relation avec l'identifiant de l'objet en question. 5 Le serveur d'autorisation d'accès construit un second message, M2, contenant toutes les informations nécessaires à la création d'un canal sécurisé entre le serveur d'autorisation d'accès et l'objet connecté, et l'envoie en 440 au serveur de production. Le message M2 contient (en clair) l'identifiant SN , le jeton de session TK , la clé publique du serveur d'autorisation d'accès, Qauth ainsi que les paramètres d'un cryptosystème 10 ( Cryptosystem ) pour générer un couple de clés privée et publique. Le serveur de production signe en 441 le message M2 au moyen de la clé privée initiale, Kint, et renvoie, en 442, la signature ainsi obtenue, Signprod (M2), au serveur d'autorisation d'accès. Ce dernier transmet en 443 le message M2, accompagné de la signature Signprod (M2) ainsi obtenue, à l'objet connecté. 15 En 444, l'objet connecté vérifie à l'aide de la clé publique initiale, en,, que le message M2 est bien intègre et, dans l'affirmative, stocke dans sa mémoire la clé publique, Qauth ainsi que les paramètres du cryptosystème (Cryptosystem -ryptosystem ). La suite des échanges entre les éléments du système dépend de la variante 20 considérée. La Fig. 5A représente une seconde partie des échanges entre les éléments du système de la Fig. 2 lors de la mise en oeuvre de la méthode d'établissement d'une communication sécurisée selon une première variante du mode de réalisation. Cette 25 seconde partie fait suite à la première partie précédemment décrite en relation avec les Figs. 4A et 4B. Cette première variante fait appel à un cryptosystème sur courbes elliptiques avec certificats implicites. Dans ce cas, les paramètres du cryptosystème (Cryptosystem) ) dans 3044499 18 le message M2 sont p la caractéristique du corps, a,b les paramètres de la courbe elliptique, G , une point générateur appartenant à la courbe elliptique et n l'ordre de G . A l'étape 450, l'objet connecté génère une clé publique temporaire Qtemp à partir d'une clé privée Ktemp prise égale au second nombre aléatoire RN2. En 451, l'objet 5 connecté transmet un troisième message, M3, comprenant une première partie en clair et une seconde partie chiffrée à l'aide de la clé publique, 0 ----auth , qu'il a obtenue à l'étape précédente. La première partie contient l'identifiant de l'objet connecté. La seconde partie contient également cet identifiant, le certificat de la clé initiale, CQini, , le jeton de session et la clé publique temporaire, Qtemp. La présence dans le message M3 du certificat de clé 10 initiale, CQini, , permet d'authentifier l'objet connecté auprès du serveur d'autorisation d'accès et par conséquent d'éviter des attaques de type « man-in-the-middle ». En 452, le serveur d'autorisation d'accès authentifie l'objet connecté au moyen du certificat de clé initiale,CQinit. Après avoir authentifié l'objet connecté, il génère un troisième nombre aléatoire RN3 et calcule un certificat implicite : 15 CertF = Qtemp + kG (5) Il obtient ensuite une valeur de hachage à partir du certificat et du jeton de session, soit : 20 hF =h(CertFMTK) (6) où h est une fonction de hachage et CertF TK représente le certificat implicite concaténé au jeton de session. 25 Le serveur d'autorisation d'accès signe alors le certificat au moyen de sa clé privée Kauth (jouant ici le rôle de clé maître), pour fournir la signature du certificat : 3044499 SignF = hFk + Kauth Enfin, le serveur d'autorisation d'accès forme en 460 un quatrième message, M4 , comprenant le certificat (CertF,SignF) et le transmet à l'objet connecté. Il transmet 5 également la signature du message M 4 , Signauth(M 4) , au moyen de la clé privée, K auth . En 461, l'objet vérifie que le quatrième message est intègre au moyen de la clé publique 0 ---auth QF par: 10 KF = h(CertFlITK)RN2+ SignF mod. n QF = h(CertF,TK)CertF +Qauth Au terme de l'étape 461, l'objet connecté et le serveur d'autorisation d'accès 15 disposent chacun d'un jeu de clés asymétriques, respectivement (KF,QF ) et ( Kauthauth - ) , ---, ce qui leur permet d'établir une communication sécurisée, 225, entre eux. Le serveur d'autorisation d'accès peut alors transmettre une clé symétrique à la fois au terminal de l'utilisateur et à l'objet connecté, ou bien au serveur intermédiateur de contexte et à l'objet connecté. Ces deux éléments peuvent ensuite établir directement 20 entre eux une liaison sécurisée sans qu'il soit besoin de qualifier la passerelle comme passerelle de confiance. La Fig. 5B représente une seconde partie des échanges entre les éléments du système de la Fig. 2 lors de la mise en oeuvre de la méthode d'établissement d'une 25 communication sécurisée selon une seconde variante du mode de réalisation. Cette seconde partie fait ainsi suite à la première partie précédemment décrite en relation avec les Figs. 4A et 4B. A la différence de la première variante, à l'étape 450, on ne génère pas de clé 19 (7) Si c'est bien le cas, il calcule un couple de clé privée KF et de clé publique 3044499 20 temporaire mais directement les clés privée, KF, et publique, QF, à partir du second nombre aléatoire RN2 et des paramètres du cryptosystème reçus à l'étape précédente. Dans le cas où l'on utilise un cryptosystème sur courbes elliptiques de paramètres (p,a,b,G,n), la clé privée KF n'est autre que KF =RN2 et la clé publique QF est obtenue 5 par : QF=KF.G (10) 10 L'objet connecté demande ensuite une certification de sa clé publique auprès du serveur d'autorisation d'accès. A cette fin, l'objet connecté transmet en 451 un troisième message, M3, comprenant une première partie en clair et une seconde partie chiffrée à l'aide de la clé publique, 0 ----auth contient l'identifiant de l'objet connecté. La seconde partie contient également 15 l'identifiant, le certificat de clé initiale, Cen , et la clé publique, QF, générée en 450. Comme dans la première variante, le certificat de clé initiale, Cent, permet d'authentifier l'objet connecté auprès du serveur d'autorisation d'accès et par conséquent d'éviter des attaques de type « man-in-the-middle ». En 452, le serveur d'autorisation d'accès vérifie l'intégrité du message M3 au 20 moyen de sa clé privée Kauth et authentifie l'objet connecté au moyen du certificat de clé initiale, Ce, . Il génère ensuite un certificat de clé publique, Certx509 au format X.509 à partir de l'identifiant SN et de la clé publique QF. La signature du certificat est effectuée au moyen de sa clé privée Kauth. On notera que le certificat est ici auto-signé dans la mesure où le serveur d'autorisation d'accès joue également le rôle d'autorité de certification. 2 5 En 461, le serveur d'autorisation d'accès transmet à l'objet connecté un quatrième message M4 ainsi que sa signature Signauth(M4) au moyen de la clé privée Kauth. L'objet connecté vérifie l'intégrité du message M4, au moyen de la clé publique Qauth. Lorsque le , qu'il a obtenue à l'étape précédente. La première partie 3044499 21 message est intègre, l'objet connecté stocke dans sa mémoire le certificat X.509, Certx509 Cette seconde variante nécessite cependant une capacité mémoire plus importante que dans la première variante en raison de la taille du certificat X.509. Comme dans la première variante, le serveur d'autorisation d'accès peut 5 transmettre une clé symétrique à la fois au terminal de l'utilisateur et à l'objet connecté, (voire alternativement au serveur intermédiateur de contexte et à l'objet connecté) pour établir une communication sécurisée entre ces deux éléments. Dans les deux cas, la passerelle 250 réalisant l'interface entre le standard de communication sans fil utilisé par l'objet connecté et l'infrastructure IP d'Internet n'a pas besoin d'être de confiance. REVENDICATIONS1. Méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur (210)/ un serveur d'intermédiateur de contexte (240) et un objet connecté (261), caractérisée en ce qu'elle met en oeuvre un premier serveur, dit serveur d'autorisation d'accès (220) et un second serveur, dit serveur de production (230), le terminal de l'utilisateur communiquant avec le serveur d'autorisation d'accès par une première communication sécurisée (215) et le serveur de production communiquant avec le serveur d'autorisation d'accès par une seconde communication sécurisée (235), le serveur d'autorisation d'accès hébergeant une première base de données (221) contenant des informations permettant d'authentifier les différents utilisateurs et de gérer leurs droits d'accès aux différents objets connectés, le serveur de production hébergeant une seconde base de données (231) contenant des identifiants d'objets connectés et possédant un couple de clés privée et publique initiales (Kunt,Q.,), caractérisée en ce qu'elle comprend les étapes suivantes : (a) sur une requête de l'utilisateur contenant l'identifiant de l'objet connecté ( SN ), demande de vérification du serveur d'autorisation d'accès auprès du serveur de production que cet identifiant est bien valide ; (b) sur initialisation de l'objet connecté, identification et authentification de l'objet connecté auprès du serveur de production, au moyen d'un premier message (M1) contenant l'identifiant de l'objet connecté ainsi que ce même identifiant, chiffré par la clé publique initiale (en, ); (c) en cas de succès d'authentification de l'objet connecté, génération par le serveur d'autorisation d'accès d'un second message (M2) contenant les paramètres d'un cryptosystème, le second message étant préalablement signé par le serveur de production, le message ainsi que sa signature ( sgn (M2) ) étant transmis à l'objet connecté; (d) génération par l'objet connecté d'un couple de clés privée et publique d'accès (KF,QF), à partir des paramètres du cryptosystème, permettant d'établir une troisième 3044499 23 communication sécurisée (225) entre le serveur d'autorisation d'accès et l'objet connecté ; (e) établissement d'une communication sécurisée entre le terminal de l'utilisateur, resp. le serveur d'intermédiation de contexte, et l'objet connecté au moyen d'une clé symétrique, distribuée par le serveur d'autorisation d'accès, d'une part au 5 terminal d'utilisateur via la première communication sécurisée, resp. au serveur d'intermédiation via une quatrième communication sécurisée, et, d'autre part, à l'objet connecté via la troisième communication sécurisée. 2. Méthode d'établissement d'une communication sécurisée de bout en bout 10 selon la revendication 1, caractérisée en ce qu'à l'étape (a), le serveur de production effectue un horodatage de l'identifiant de l'objet connecté et stocke l'estampille d'horodatage dans la seconde base de données en relation avec ledit identifiant. 3. Méthode d'établissement d'une communication sécurisée de bout en bout 15 selon la revendication 1 ou 2, caractérisée en ce que lors de ou suite à son initialisation à l'étape (b), l'objet connecté génère un jeton de session (TK ) sous la forme d'un premier nombre aléatoire (RNI), ainsi qu'un second nombre aléatoire (RN2). 4. Méthode d'établissement d'une communication sécurisée de bout en bout 20 selon la revendication 3, caractérisée en ce que le premier message (M1) comprend une première partie en clair comprenant l'identifiant de l'objet connecté (SN), et une second partie chiffrée au moyen de la clé publique initiale (en, ), la seconde partie comprenant ce même identifiant, la clé de session, ainsi que, le cas échéant, un certificat ( Cent ) de la clé publique initiale. 25 5. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 4, caractérisée en ce qu'à l'étape (b), le serveur de production identifie l'objet connecté si son identifiant est présent dans la seconde base de données. 3044499 24 6. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 5, caractérisée en ce qu'à l'étape (b), le serveur de production authentifie l'objet connecté en déchiffrant la seconde partie du premier message à l'aide de la clé privée initiale et en comparant le résultat du déchiffrage avec la première partie. 5 7. Méthode d'établissement d'une communication sécurisée de bout en bout selon les revendications 2 et 6, caractérisée en ce qu'à l'étape (b), le serveur de production ne déclare l'objet connecté que si, à la date de l'authentification, l'estampille d'horodatage n'est pas périmée. 10 8. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 6 ou 7, caractérisée en ce qu'au terme de l'étape (b), le serveur de production transmet au serveur d'autorisation d'accès le résultat de l'authentification ( ACK,NACK) accompagné du numéro d'identifiant de l'objet connecté et, le cas 15 échéant, du certificat de la clé publique initiale (Cen ). 9. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 8, caractérisée en ce qu'en cas de succès d'authentification à l'étape (b), le serveur d'autorisation d'accès stocke dans la première base de données le 20 jeton de session en relation avec l'identifiant d'objet connecté. 10. Méthode d'établissement d'une communication sécurisée de bout en bout selon l'une des revendications précédentes, caractérisée en ce qu'à l'étape (c), le second message (M2 ) comprend l'identifiant d'objet connecté ( SN ), le jeton de session (TK ), la 25 clé publique du serveur d'autorisation d'accès (auth - 1 et les paramètres d'un --- cryptosystème. 11. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 10, caractérisée en ce que le cryptosystème est un cryptosystème 3044499 25 sur une courbe elliptique. 12. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 11, caractérisée en ce qu'à l'étape (c) le serveur de production signe 5 le second message au moyen de la clé privée initiale et renvoie la signature ainsi obtenue ( sgn(M2) au serveur d'autorisation d'accès. 13. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 12, caractérisée en ce que le serveur d'autorisation d'accès transmet 10 le second message (M2) ainsi que sa signature ( sgn(M2) à l'objet connecté. 14. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 13, caractérisée en ce qu'à l'étape (d), l'objet connecté génère une clé publique temporaire à partir du second nombre aléatoire et d'un point générateur ( G ) 15 sur la courbe elliptique. 15. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 14, caractérisée en ce que l'objet connecté génère un troisième message (M3) contenant, dans une première partie en clair, son identifiant et, dans une 20 seconde partie chiffrée au moyen de la clé publique du serveur d'autorisation d'accès (Qaurh ), ce même identifiant, le certificat de la clé publique initiale (CQini,), le jeton d'accès ainsi que la clé publique temporaire (Qtemp ). 16. Méthode d'établissement d'une communication sécurisée de bout en bout 25 selon la revendication 15, caractérisée en ce que le serveur d'autorisation d'accès génère un certificat implicite d'une clé publique d'accès (CertF) ainsi qu'une signature de ce certificat (SignF) à partir de la clé publique temporaire (Qtemp ), d'un troisième nombre aléatoire (k), du jeton de session (TK ), de la clé privée du serveur d'autorisation ( Kauth ) et des paramètres du cryptosystème sur courbe elliptique. 3044499 26 17. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 16, caractérisée en ce que le serveur d'autorisation d'accès génère un quatrième message (M4) comprenant le certificat implicite de la clé publique d'accès 5 ( CertF) ainsi que sa signature ( SignF ), ce message ainsi que sa signature (Sgn(M4) au moyen de la clé privée du serveur d'autorisation d'accès étant transmis à l'objet connecté. 18. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 17, caractérisée en ce que l'objet connecté, après avoir vérifié 10 l'intégrité du quatrième message au moyen de la clé publique du serveur d'autorisation d'accès, génère ledit couple de clés privée et publique d'accès (KF,QF ) à partir du certificat implicite de la clé publique d'accès (CertF) et de sa signature (CertF ), du jeton de session (TK ), de la clé publique d'autorisation d'accès (Qauth - 1 - ---- et des paramètres du cryptosystème sur courbe elliptique. 19. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 13, caractérisée en ce que l'objet connecté génère la clé privée d'accès (KF ) à partir du second nombre aléatoire (RAT2) et la clé publique d'accès (QF ) à partir de cette dernière et des paramètres du cryptosytème sur courbe elliptique. 20. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 19, caractérisée en ce que l'objet connecté génère un troisième message (M3) contenant, dans une première partie en clair, son identifiant et, dans une seconde partie chiffrée au moyen de la clé publique du serveur d'autorisation d'accès Qauth ), ce même identifiant, le certificat de clé initiale, CQinit, le jeton d'accès, ainsi que la clé publique d'accès (QF ). 21. Méthode d'établissement d'une communication sécurisée de bout en bout 15 20 25 3044499 27 selon la revendication 20, caractérisée en ce que le serveur d'autorisation d'accès génère un certificat X.509 (Certx 509) de la clé publique d'accès (QF), à partir de l'identifiant de l'objet connecté et de la clé publique d'accès, au moyen de sa clé privée d'autorisation d'accès (Kauth). 5 22. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 21, caractérisée en ce que le serveur d'autorisation d'accès génère un quatrième message (M4) comprenant le certificat de la clé publique d'accès (Certx 509 ) ainsi que sa signature ( Sign.th(M4) ) au moyen de la clé privée du serveur d'autorisation 10 d'accès, ce message ainsi que sa signature ( Sign.th(M 4)) étant transmis à l'objet connecté. 23. Méthode d'établissement d'une communication sécurisée de bout en bout selon la revendication 21, caractérisée en ce que, après avoir vérifié l'intégrité du quatrième message au moyen de la clé publique du serveur d'autorisation d'accès, l'objet 15 connecté stocke dans sa mémoire le certificat de la clé publique d'accès (Certx 509 )-