Brevet FR3120154A1 — publié le 20220826

Procédé (100) de communication sécurisé entre un lecteur (B) et un contrôleur (A) configurés pour communiquer entre eux, le procédé comprenant les phases suivantes mises en œuvre par le lecteur (B): - une phase (101) de lecture d’une information par le lecteur (B); - une phase (102) d’échange d’une clé publique (B SpubK ) du lecteur (B) et d’une clé publique (A SpubK ) du contrôleur (A) ; - une phase (103) de génération d’une suite de clés de session; - une phase (104) de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session (k 0 ) de la suite de clés de session, - une phase (105) protocolaire de communication sécurisée entre le lecteur (B) et le contrôleur (A). Figure 1 Procédé d’échanges sécurisés entre un lecteur de contrôle d’accès, concentrateur IOT et une unité de traitement de données. La présente invention concerne le domaine de la cryptographie et des protocoles de sécurisation des communications numériques. Il est connu de sécuriser les communications numériques entre un serveur et un client. Les protocoles de sécurisation existants nécessitent une puissance de calcul importante, qui n’est pas disponible sur un lecteur de contrôle d’accès ou sur concentrateur d’objets connectés, que nous désignerons également par concentrateur IOT (Internet of Things), et sur l’unité de traitement de données correspondantes, lorsque ledit lecteur de contrôle d’accès/concentrateur IOT est destiné à contrôler l’accès à une zone donnée, en lisant les données d’identifications d’un utilisateur sur un badge, de technologie RFID par exemple, et en transmettant les données lues à l’unité de traitement de données pour contrôle par l’unité de traitement de données. L’utilisation de protocoles connus pour authentifier l’unité de traitement de données et le lecteur de contrôle d’accès/concentrateur IOT, et pour assurer la sécurité des échanges d’informations entre l’unité de traitement de données et le lecteur de contrôle d’accès/concentrateur IOT avec un niveau de sécurité satisfaisant nécessite une puissance de calcul dont ne disposent pas l’unité de traitement de données et le lecteur de contrôle d’accès d’un dispositif de contrôle d’accès/concentrateur IOT. L’invention a donc pour but de proposer une solution à tout ou partie de ces problèmes. A cet effet, la présente invention concerne un procédé d’échanges sécurisés entre un lecteur et un contrôleur configurés pour communiquer entre eux, le procédé comprenant les phases suivantes mises en œuvre par le lecteur: - une phase de lecture d’une information par le lecteur; - une phase d’échange d’une clé publique du lecteur et d’une clé publique du contrôleur; - une phase de génération d’une suite de clés de session; - une phase de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session de la suite de clés de session, - une phase protocolaire de communication sécurisée entre le lecteur et le contrôleur. Selon un mode de mise en œuvre, l’invention comprend une ou plusieurs des caractéristiques suivantes, seules ou en combinaison techniquement acceptable. Selon un mode de mise œuvre, le lecteur et le contrôleur sont configurés pour assurer un contrôle d’accès à une zone protégée. Selon un mode de mise en œuvre, le lecteur est un lecteur de contrôle d’accès, par exemple un lecteur de badge RFID, ou un concentrateur IOT, configuré pour lire l’information numérique contenue dans le badge. Dans la suite du texte, le lecteur de contrôle d’accès désignera aussi bien le lecteur de badge pour le contrôle d’accès à une zone donnée que le concentrateur IOT. Selon un mode de mise en œuvre, la phase d’échange d’une clé publique du contrôleur comprend l’échange d’une pluralité de clés publiques du contrôleur. Selon un mode de mise en œuvre, la phase d’échange de clés comprend : - une étape de réception de la clé publique du contrôleur, et de réception d’une liste de mécanismes de sécurité proposés par le contrôleur, et de réception d’un paramètre de sécurité généré par le contrôleur ; - une étape d’émission vers le contrôleur, de la clé publique du lecteur, et d’un numéro de série du lecteur, et d’un mécanisme de sécurité accepté par le lecteur, ledit mécanisme de sécurité étant choisi par le parmi la liste de mécanismes de sécurité, et d’un paramètre de sécurité généré par le lecteur; Selon ces dispositions, le choix du mécanisme de sécurité parmi la liste de mécanismes de sécurité permet d’ajuster le besoin en puissance de calcul aux ressources disponibles sur le lecteur et sur le contrôleur. Selon un mode de mise en œuvre, l’étape de réception de la clé publique du contrôleur comprend la réception d’une pluralité de clés publiques du contrôleur. Selon un mode de mise en œuvre, le paramètre de sécurité généré par le contrôleur est généré aléatoirement, par exemple selon un procédé cryptographique. Selon un mode de mise en œuvre, le paramètre de sécurité généré par le lecteur est généré aléatoirement, par exemple selon un procédé cryptographique. Selon un mode de mise en œuvre, la phase de génération d’une suite de clés de session comprend les étapes suivantes : - un étape de calcul d’un secret, partagé par le lecteur et par le contrôleur, le secret étant calculé à partir d’une clé privée du lecteur et de la clé publique du contrôleur; - une étape de calcul de la suite de clés de session à partir du secret partagé, et du numéro de série du lecteur, et du paramètre de sécurité généré par le lecteur, et du paramètre de sécurité généré par le contrôleur; Selon un mode de mise en œuvre, le calcul du secret partagé utilise l’échange de clés Diffie-Hellman basé sur des courbes elliptiques. Selon un mode de mise en œuvre, la phase de confirmation de la suite de clés comprend : - une étape de réception d’un premier code d’authentification calculé par le contrôleur en fonction de la première clé de session de la suite de clés de session, et en fonction d’un identifiant du contrôleur, et d’un identifiant du lecteur, et du paramètre de sécurité généré par le lecteur, et du paramètre de sécurité généré par le contrôleur; - une étape d’émission d’un deuxième code d’authentification calculé par le lecteur en fonction de la première clé de session de la suite de clés de session, et en fonction de l’identifiant du contrôleur, et de l’identifiant du lecteur, et du paramètre de sécurité généré par le lecteur, et du paramètre de sécurité généré par le contrôleur; - une étape de vérification du premier code d’authentification reçu ; Selon un mode de mise en œuvre, le premier code d’authentification est calculé en fonction d’une première valeur alphanumérique prédéterminée. Selon un mode de mise en œuvre, le deuxième code d’authentification est calculé en fonction d’une deuxième valeur alphanumérique prédéterminée. Selon un mode de mise en œuvre, le paramètre de sécurité généré par le lecteur est une autre clé publique générée par le lecteur, à laquelle correspond une autre clé privée générée par le lecteur, et dans lequel le secret est concaténé avec un autre secret partagé calculé à partir de l’autre clé privée générée par le lecteur et de la clé publique du contrôleur, et le secret partagé concaténé devenant le secret partagé utilisé pour l’étape de calcul de la suite de clés de session. Selon un mode de mise en œuvre, le paramètre de sécurité généré par le contrôleur est une autre clé publique générée par le contrôleur, à laquelle correspond une autre clé privée générée par le contrôleur, et dans lequel l’autre secret partagé est calculé à partir de l’autre clé privée générée par lecteur et de la clé publique du contrôleur. Selon un mode de mise en œuvre, la phase protocolaire comprend une étape de réception par le lecteur d’une requête sécurisée en provenance du contrôleur, une étape de calcul d’une signature à partir de l’information lue et d’une clé de la suite de clé de sessions et une étape de création d’une trame comprenant la signature concaténée avec les informations lues et avec un compteur anti-rejeu, et une étape de chiffrement de la trame en utilisant une autre clé de la suite de clés de session, et une étape de transmission de la trame chiffrée. Selon ces dispositions, après les premières phases d’authentification, la communication entre le lecteur et le lecteur est sécurisée. L’invention concerne également un procédé communication sécurisé entre un lecteur et un contrôleur, le procédé comprenant les phases suivantes mises en œuvre par le contrôleur : - une phase d’échange d’une clé publique du lecteur et d’une clé publique du contrôleur; - une phase de génération d’une suite de clés de session ; - une phase de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session de la suite de clés de session. - une phase protocolaire de communication sécurisée entre le lecteuret le contrôleur. Selon un mode de mise en œuvre, le contrôleur est configuré pour contrôler l’identité, et l’accès à une zone donnée, d’un utilisateur du badge à partir de l’information lue par le lecteur sur le badge et reçue par le contrôleur, le procédé comprenant une phase finale de contrôle d’une identité d’un utilisateur du badge. Selon un mode de mise en œuvre, la phase d’échange d’une clé publique du lecteur et d’une clé publique du contrôleur, comprend : - une étape d’émission vers le lecteur, de la clé publique du contrôleur et d’une liste de mécanismes de sécurité proposés par le contrôleur, et d’un paramètre de sécurité généré par le contrôleur; - une étape de réception de la clé publique du lecteur, et d’un numéro de série du lecteur, et d’un mécanisme de sécurité accepté par le lecteur, ledit mécanisme de sécurité étant choisi par le parmi la liste, et d’un paramètre de sécurité généré par le lecteur. Selon un mode de mise en œuvre, l’étape d’émission de la clé publique du contrôleur comprend l’émission d’une pluralité de clés publiques du contrôleur. Selon un mode de mise en œuvre, la phase de génération d’une suite de clés de session comprend les étapes suivantes : - un étape de calcul d’un secret, partagé par le lecteur et par le contrôleur, le secret étant calculé à partir d’une clé privée du contrôleur et de la clé publique du lecteur; - une étape de calcul de la suite de clés de session à partir du secret partagé, et du numéro de série du lecteur, et du paramètre de sécurité généré par le lecteur, et du paramètre de sécurité généré par le contrôleur; Selon un mode de mise en œuvre le calcul du secret partagé utilise l’échange de clés Diffie-Hellman basé sur des courbes elliptiques. Selon un mode de mise en œuvre, la phase de confirmation de la suite de clés comprend : - une étape d’émission d’un premier code d’authentification calculé par le contrôleur en fonction de la première clé de session de la suite de clés de session, et en fonction d’un identifiant du contrôleur, et d’un identifiant du lecteur, et du paramètre de sécurité généré par le lecteur, et du paramètre de sécurité généré par le contrôleur ; - une étape de réception d’un deuxième code d’authentification calculé par le lecteur en fonction de la première clé de session de la suite de clés de session, et en fonction d’un identifiant du contrôleur, et d’un identifiant du lecteur, et du paramètre de sécurité généré par le lecteur, et du paramètre de sécurité généré par le contrôleur; - une étape de vérification du deuxième code d’authentification reçu. Selon un mode de mise en œuvre, le premier code d’authentification est calculé en fonction d’une première valeur alphanumérique prédéterminée. Selon un mode de mise en œuvre, le deuxième code d’authentification est calculé en fonction d’une deuxième valeur alphanumérique prédéterminée. Selon un mode de mise en œuvre, le paramètre de sécurité généré par le lecteur est une autre clé publique générée par le lecteur, et dans lequel le secret partagé est concaténé avec un autre secret partagé calculé à partir de la clé privée du contrôleur et de l’autre clé publique générée par le lecteur, le secret partagé concaténé devenant le secret partagé utilisé pour l’étape de calcul de la suite de clés de session. Selon un mode de mise en œuvre, le paramètre de sécurité généré par le contrôleur est une autre clé publique générée par le contrôleur, à laquelle correspond une autre clé privée générée par le contrôleur, et dans lequel l’autre secret partagé est calculé à partir de l’autre clé privée générée par contrôleur et de l’autre clé publique générée par le lecteur. Selon un mode de mise en œuvre, la phase protocolaire comprend une étape d’émission par le contrôleur vers le lecteur d’une requête sécurisée, une étape de réception d’une trame chiffrée, une étape de déchiffrement de la trame en utilisant une clé de la suite de clés de session, la trame déchiffrée comprenant une signature concaténée avec l’information lue et avec un compteur anti-rejeu, et une étape de vérification de la signature avec une autre clé de la suite de clés de session et du compteur anti-rejeu. Selon un aspect de l’invention, l’invention concerne également un lecteur de contrôle d’accès pour le contrôle d’accès à une zone, configuré pour communiquer une information, lue sur un badge, à un contrôleur, selon l’un des exemples de mise en œuvre du procédé décrit ci-avant. Selon un autre aspect de l’invention, l’invention concerne également un contrôleur d’un lecteur de contrôle d’accès configuré pour communiquer avec le lecteur de contrôle d’accès selon l’un des exemples de mise en œuvre du procédé 200 décrit ci-avant. Pour sa bonne compréhension, un mode de réalisation et/ou de mise en oeuvre de l’invention est décrit en référence aux dessins ci-annexés représentant, à titre d’exemple non limitatif, une forme de réalisation ou de mise en œuvre respectivement d’un dispositif et/ou d’un procédé selon l’invention. Les mêmes références sur les dessins désignent des éléments similaires ou des éléments dont les fonctions sont similaires. est une représentation schématique des étapes du procédé selon l’invention, du point de vue du contrôleur d’une part, et du point de vue d’un lecteur de contrôle d’accès d’autre part. Le protocole ou procédé 100, 200 d’échanges sécurisés selon l’invention est destiné à un dispositif de contrôle d’accès à une zone protégée ou à un concentrateur IOT. Le dispositif de contrôle d’accès comprend typiquement un lecteur B de badge et une unité de traitement logique (UTL), appelée également contrôleur A. Le lecteur de contrôle d’accès B met par exemple en œuvre la technologie de type RFId configurée pour la lecture des informations contenues dans un badge de type RFId; le lecteur de contrôle d’accès B est configuré pour mettre en œuvre un micro-logiciel embarqué, et communiquer avec le contrôleur A, par exemple via une liaison série de type RS485, selon un procédé 100, 200 de communication sécurisé selon l’invention. Le procédé 100, 200 de communication sécurisé selon l’invention comprend une partie du procédé 100 de communication sécurisé mis en œuvre plus particulièrement par le lecteur de contrôle d’accès B et une autre partie du procédé 200 de communication sécurisé mis en œuvre plus particulièrement par le contrôleur A. Ce procédé permet d’effectuer dans un premier temps une authentification entre le contrôleur A et le lecteur B, et dans un deuxième temps d’assurer la sécurité des communications entre le lecteur B et le contrôleur A. Pour s’adapter à la puissance de calcul limitée du lecteur B et du contrôleur A du dispositif de contrôle d’accès, le procédé 100 de communication sécurisé mis en œuvre plus particulièrement par le lecteur de contrôle d’accès B comprend les phases suivantes : - une phase 101 de lecture d’une information par le lecteur (B); - une phase 102 d’échange d’une clé publique B SpubK du lecteur B, et d’une ou plusieurs clé(s) publique(s) A SpubK du contrôleur A ; - une phase 103 de génération d’une suite de clés de session; - une phase 104 de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session k 0 de la suite de clés de session, - une phase 105 protocolaire de communication sécurisée entre le lecteur (B) et le contrôleur A. Symétriquement, et en correspondance avec les phases du procédé 100 mises en œuvre par le lecteur B, le procédé 200 de communication sécurisé mis en œuvre plus particulièrement par le contrôleur A, comprend les phases suivantes : - une phase 202 d’échange d’une clé publique BSpubK du lecteur B et d’une clé publique ASpubK du contrôleur A ; - une phase 203 de génération d’une suite de clés de session ; - une phase 204 de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session k0 de la suite de clés de session. - une phase 205 protocolaire de communication sécurisée entre le lecteur B et le contrôleur A. Selon ces dispositions, après les premières phases 102, 202, 103, 203, 104, 204, du procédé 100, 200, qui sont des phases d’authentification et de confirmation des clés de la suite de clés, la communication entre le lecteur B et le lecteur A pendant la phase protocolaire 105, 205 est sécurisée. Selon un exemple, la phase protocolaire 105 du procédé 100 mis en œuvre par le lecteur B, comprend une étape 1050 de réception par le lecteur B d’une requête sécurisée RS en provenance du contrôleur A, une étape de calcul d’une signature 1051 à partir de l’information lue et d’une clé de la suite de clé de sessions et une étape 105 de création d’une trame comprenant la signature concaténée avec les informations lues et avec un compteur anti-rejeu, et une étape 1053 de chiffrement de la trame en utilisant une autre clé de la suite de clés de session, et une étape 1054 de transmission de la trame chiffrée TC. De manière correspondante, la phase protocolaire 205 du procédé 200 mis en œuvre par le contrôleur A, comprend une étape 2050 d’émission par le contrôleur A vers le lecteur B d’une requête sécurisée RS, une étape 2051 de réception d’une trame chiffrée TC, une étape 2052 de déchiffrement de la trame en utilisant une clé de la suite de clés de session, la trame déchiffrée comprenant une signature concaténée avec l’information lue et avec un compteur anti-rejeu, et une étape 2053 de vérification de la signature avec une autre clé de la suite de clés de session et du compteur anti-rejeu. En particulier, pour s’adapter à la puissance de calcul limitée du lecteur B et du contrôleur A du dispositif de contrôle d’accès, la phase 102 d’échange de clés des phases d’authentification du procédé 100 mis en œuvre par le lecteur B comprend : - une étape 1021 de réception de la ou des clé(s) publique(s) A SpubK du contrôleur A, et de réception d’une liste de mécanismes de sécurité CcipherSuite proposés par le contrôleur A, et de réception d’un paramètre de sécurité PA généré par le contrôleur A; - une étape 1022 d’émission vers le contrôleur A, de la clé publique B SpubK du lecteur B, et d’un numéro de série SN du lecteur B, et d’un mécanisme Ccipher de sécurité accepté par le lecteur B, ledit mécanisme de sécurité Ccipher étant choisi par le parmi la liste de mécanismes de sécurité CcipherSuite, et d’un paramètre de sécurité PB généré par le lecteur B. Selon ces dispositions, le choix du mécanisme de sécurité parmi la liste de mécanismes de sécurité permet d’ajuster le besoin en puissance de calcul aux ressources disponibles sur le lecteur et sur le contrôleur. Plus particulièrement, l’étape de réception de la clé publique du contrôleur comprend la réception d’une pluralité de clés publiques du contrôleur. Par exemple, le paramètre de sécurité généré par le contrôleur et/ou le lecteur est généré aléatoirement, selon un procédé cryptographique. Symétriquement, et en correspondance avec les étapes de la phase 102 d’échange de clés du procédé 100 mis en œuvre par le lecteur B, la phase 202 d’échange d’une clé publique BSpubK du lecteur B et d’une clé publique ASpubK du contrôleur A, comprend : - une étape 2021 d’émission vers le lecteur B, de la ou des clé(s) publique(s) A SpubK du contrôleur A, et d’une liste de mécanismes de sécurité CcipherSuite proposés par le contrôleur A, et d’un paramètre de sécurité PA généré par le contrôleur A; - une étape 2022 de réception de la clé publique B SpubK du lecteur B, et d’un numéro de série SN du lecteur B, et d’un mécanisme Ccipher de sécurité accepté par le lecteur B, ledit mécanisme de sécurité Ccipher étant choisi par le parmi la liste CcipherSuite, et d’un paramètre de sécurité PB généré par le lecteur B. En particulier encore, la phase 103 de génération d’une suite de clés de session du procédé 100 mis en œuvre par le lecteur B comprend : - un étape 1031 de calcul d’un secret S, partagé par le lecteur B et par le contrôleur A, le secret S étant calculé à partir d’une clé privée B SprivK du lecteur B et de la clé publique A SpubK du contrôleur A ; - une étape 1032 de calcul de la suite de clés de session à partir du secret partagé S, et du numéro de série SN du lecteur B, et du paramètre de sécurité PB généré par le lecteur B, et du paramètre de sécurité PA généré par le contrôleur A. Symétriquement, et en correspondance avec les étapes de la phase 103 de génération d’une suite de clés de session du procédé 100 mis en œuvre par le lecteur B, la phase 203 de génération d’une suite de clés de session du procédé 200 mis en œuvre par le contrôleur A, comprend les étapes suivantes : - un étape 2031 de calcul d’un secret S, partagé par le lecteur B et par le contrôleur A, le secret S étant calculé à partir d’une clé privée A SprivK du contrôleur A et de la clé publique B SpubK du lecteur B ; - une étape 2032 de calcul de la suite de clés de session à partir du secret partagé S, et du numéro de série SN du lecteur B, et du paramètre de sécurité PB généré par le lecteur B, et du paramètre de sécurité PA généré par le contrôleur A. Plus particulièrement, le calcul du secret partagé utilise l’échange de clés Diffie-Hellman basé sur des courbes elliptiques. En particulier, la phase 104 de confirmation de la suite de clés du procédé 100 mis en œuvre par le lecteur B comprend : - une étape 1041 de réception d’un premier code d’authentification MAC1 calculé par le contrôleur A en fonction de la première clé de session k 0 de la suite de clés de session, et en fonction d’un identifiant IDA du contrôleur A, et d’un identifiant IDB du lecteur B, et du paramètre de sécurité PB généré par le lecteur B, et du paramètre de sécurité PA généré par le contrôleur A; - une étape 1042 d’émission d’un deuxième code d’authentification MAC2 calculé par le lecteur B en fonction de la première clé de session k 0 de la suite de clés de session, et en fonction de l’identifiant IDA du contrôleur A, et de l’identifiant IDB du lecteur B, et du paramètre de sécurité PB généré par le lecteur B, et du paramètre de sécurité PA généré par le contrôleur A. - une étape 1043 de vérification du premier code d’authentification MAC1 reçu. Symétriquement, et en correspondance avec les étapes de la phase 104 de confirmation de la suite de clés du procédé 100 mis en œuvre par le lecteur B, la phase 204 de confirmation de la suite de clés du procédé 200 mis en œuvre par le contrôleur A, comprend les étapes suivantes : - une étape 2041 d’émission d’un premier code d’authentification MAC1 calculé par le contrôleur A en fonction de la première clé de session k 0 de la suite de clés de session, et en fonction d’un identifiant IDA du contrôleur A, et d’un identifiant IDB du lecteur B, et du paramètre de sécurité PB généré par le lecteur B, et du paramètre de sécurité PA généré par le contrôleur A; - une étape 2042 de réception d’un deuxième code d’authentification MAC2 calculé par le lecteur B en fonction de la première clé de session k 0 de la suite de clés de session, et en fonction d’un identifiant IDA du contrôleur A, et d’un identifiant IDB du lecteur B, et du paramètre de sécurité PB généré par le lecteur B, et du paramètre de sécurité PA généré par le contrôleur A; - une étape 2043 de vérification du deuxième code d’authentification MAC2 reçu. Selon un exemple particulier, le premier code d’authentification est calculé en fonction d’une première valeur alphanumérique prédéterminée infoAB0, et le deuxième code d’authentification est calculé en fonction d’une deuxième valeur alphanumérique prédéterminée infoBA0. Plus particulièrement, le paramètre de sécurité PB généré par le lecteur B est une autre clé publique B EpubK générée par le lecteur B, à laquelle correspond une autre clé privée B EprivK générée par le lecteur B, et dans lequel le secret S est concaténé avec un autre secret partagé S E calculé à partir de l’autre clé privée B EprivK générée par le lecteur B et de la clé publique A SpubK du contrôleur A, et le secret partagé concaténé devenant le secret partagé S utilisé pour l’étape 1032 de calcul de la suite de clés de session. Symétriquement, de manière correspondante, le paramètre de sécurité PB généré par le lecteur B est une autre clé publique B EpubK générée par le lecteur B, et dans lequel le secret partagé S est concaténé avec un autre secret partagé S E calculé à partir de la clé privée A SprivK du contrôleur A et de l’autre clé publique B EpubK générée par le lecteur B, le secret partagé concaténé devenant le secret partagé S utilisé pour l’étape 2032 de calcul de la suite de clés de session. Plus particulièrement encore, le paramètre de sécurité PA généré par le contrôleur A est une autre clé publique A EpubK générée par le contrôleur A, à laquelle correspond une autre clé privée A EprivK générée par le contrôleur A, et dans lequel l’autre secret partagé S E est calculé à partir de l’autre clé privée B EprivK générée par lecteur B et de la clé publique A EpubK du contrôleur A. Symétriquement, de manière correspondante, le paramètre de sécurité PA généré par le contrôleur A est une autre clé publique A EpubK générée par le contrôleur A, à laquelle correspond une autre clé privée A EprivK générée par le contrôleur A, et dans lequel l’autre secret partagé S E est calculé à partir de l’autre clé privée A EprivK générée par contrôleur A et de l’autre clé publique B EpubK générée par le lecteur B. Selon un aspect de l’invention, l’invention concerne également un lecteur B de contrôle d’accès pour le contrôle d’accès à une zone ou un concentrateur IOT, configuré pour communiquer une information, lue sur un badge, à un contrôleur A, selon l’un des exemples de mise en œuvre du procédé 100 décrit ci-avant. Selon un autre aspect de l’invention, l’invention concerne également un contrôleur A d’un lecteur de contrôle d’accès configuré pour communiquer avec le lecteur de contrôle d’accès selon l’un des exemples de mise en œuvre du procédé 200 décrit ci-avant. Procédé (100) d’échanges sécurisés entre un lecteur (B) et un contrôleur (A) configurés pour communiquer entre eux, le procédé comprenant les phases suivantes mises en œuvre par le lecteur (B): - une phase (101) de lecture d’une information par le lecteur (B); - une phase (102) d’échange d’une clé publique (B SpubK ) du lecteur (B) et d’une clé publique (A SpubK ) du contrôleur (A) ; - une phase (103) de génération d’une suite de clés de session; - une phase (104) de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session (k 0 ) de la suite de clés de session, - une phase (105) protocolaire de communication sécurisée entre le lecteur (B) et le contrôleur (A). Procédé (100) selon la revendication 1, dans lequel la phase (102) d’échange de clés comprend : - une étape (1021) de réception de la clé publique (A SpubK ) du contrôleur (A), et de réception d’une liste de mécanismes de sécurité (CcipherSuite) proposés par le contrôleur (A), et de réception d’un paramètre de sécurité (PA) généré par le contrôleur (A) ; - une étape (1022) d’émission vers le contrôleur (A), de la clé publique (B SpubK ) du lecteur (B), et d’un numéro de série (SN) du lecteur (B), et d’un mécanisme (Ccipher) de sécurité accepté par le lecteur (B), ledit mécanisme de sécurité (Ccipher) étant choisi par le parmi la liste de mécanismes de sécurité (CcipherSuite), et d’un paramètre de sécurité (PB) généré par le lecteur (B) ; Procédé (100) selon la revendication 2, dans lequel la phase (103) de génération d’une suite de clés de session comprend les étapes suivantes : - un étape (1031) de calcul d’un secret (S), partagé par le lecteur (B) et par le contrôleur (A), le secret (S) étant calculé à partir d’une clé privée (B SprivK ) du lecteur (B) et de la clé publique (A SpubK ) du contrôleur (A) ; - une étape (1032) de calcul de la suite de clés de session à partir du secret partagé (S), et du numéro de série (SN) du lecteur (B), et du paramètre de sécurité (PB) généré par le lecteur (B), et du paramètre de sécurité (PA) généré par le contrôleur (A) ; Procédé (100) selon l’une des revendications 2 ou 3, dans lequel la phase (104) de confirmation de la suite de clés comprend : - une étape (1041) de réception d’un premier code d’authentification (MAC1) calculé par le contrôleur (A) en fonction de la première clé de session (k 0 ) de la suite de clés de session, et en fonction d’un identifiant (IDA) du contrôleur (A), et d’un identifiant (IDB) du lecteur (B), et du paramètre de sécurité (PB) généré par le lecteur (B), et du paramètre de sécurité (PA) généré par le contrôleur (A); - une étape (1042) d’émission d’un deuxième code d’authentification (MAC2) calculé par le lecteur (B) en fonction de la première clé de session (k 0 ) de la suite de clés de session, et en fonction de l’identifiant (IDA) du contrôleur (A), et de l’identifiant (IDB) du lecteur (B), et du paramètre de sécurité (PB) généré par le lecteur (B), et du paramètre de sécurité (PA) généré par le contrôleur (A); - une étape (1043) de vérification du premier code d’authentification (MAC1) reçu ; Procédé (100) selon la revendication 4, dans lequel le paramètre de sécurité (PB) généré par le lecteur (B) est une autre clé publique (B EpubK ) générée par le lecteur (B), à laquelle correspond une autre clé privée (B EprivK ) générée par le lecteur (B), et dans lequel le secret (S) est concaténé avec un autre secret partagé (S E ) calculé à partir de l’autre clé privée (B EprivK ) générée par le lecteur (B) et de la clé publique (A SpubK ) du contrôleur (A), et le secret partagé concaténé devenant le secret partagé (S) utilisé pour l’étape (1032) de calcul de la suite de clés de session. Procédé (100) selon la revendication 5, dans lequel le paramètre de sécurité (PA) généré par le contrôleur (A) est une autre clé publique (A EpubK ) générée par le contrôleur (A), à laquelle correspond une autre clé privée (A EprivK ) générée par le contrôleur (A), et dans lequel l’autre secret partagé (S E ) est calculé à partir de l’autre clé privée (B EprivK ) générée par lecteur (B) et de la clé publique (A EpubK ) du contrôleur (A). Procédé (100) selon l’une quelconque des revendications 1 à 6, dans lequel la phase (105) protocolaire comprend une étape (1050) de réception par le lecteur (B) d’une requête sécurisée (RS) en provenance du contrôleur (A), une étape de calcul d’une signature (1051) à partir de l’information lue et d’une clé de la suite de clé de sessions et une étape (1052) de création d’une trame comprenant la signature concaténée avec les informations lues et avec un compteur anti-rejeu, et une étape (1053) de chiffrement de la trame en utilisant une autre clé de la suite de clés de session, et une étape (1054) de transmission de la trame chiffrée (TC). Procédé (200) de communication sécurisée entre un lecteur (B) et un contrôleur (A) configurés pour communiquer entre eux, le procédé (200) comprenant les phases suivantes mises en œuvre par le contrôleur (A) : - une phase (202) d’échange d’une clé publique (BSpubK) du lecteur (B) et d’une clé publique (ASpubK) du contrôleur (A) ; - une phase (203) de génération d’une suite de clés de session ; - une phase (204) de confirmation de la suite de clés basée sur l’utilisation d’une première clé de session (k0) de la suite de clés de session. - une phase (205) protocolaire de communication sécurisée entre le lecteur (B) et le contrôleur (A). Procédé (200) selon la revendication précédente, dans lequel la phase (202) d’échange d’une clé publique (BSpubK) du lecteur (B) et d’une clé publique (ASpubK) du contrôleur (A), comprend : - une étape (2021) d’émission vers le lecteur (B), de la clé publique (A SpubK ) du contrôleur (A), et d’une liste de mécanismes de sécurité (CcipherSuite) proposés par le contrôleur (A), et d’un paramètre de sécurité (PA) généré par le contrôleur (A) ; - une étape (2022) de réception de la clé publique (B SpubK ) du lecteur (B), et d’un numéro de série (SN) du lecteur (B), et d’un mécanisme (Ccipher) de sécurité accepté par le lecteur (B), ledit mécanisme de sécurité (Ccipher) étant choisi par le parmi la liste (CcipherSuite), et d’un paramètre de sécurité (PB) généré par le lecteur (B) ; Procédé (200) selon la revendication 8 ou 9, dans lequel la phase (203) de génération d’une suite de clés de session comprend les étapes suivantes : - un étape (2031) de calcul d’un secret (S), partagé par le lecteur (B) et par le contrôleur (A), le secret (S) étant calculé à partir d’une clé privée (A SprivK ) du contrôleur (A) et de la clé publique (B SpubK ) du lecteur (B); - une étape (2032) de calcul de la suite de clés de session à partir du secret partagé (S), et du numéro de série (SN) du lecteur (B), et du paramètre de sécurité (PB) généré par le lecteur (B), et du paramètre de sécurité (PA) généré par le contrôleur (A) ; Procédé (200) selon l’une des revendications 9 ou 10, dans lequel la phase (204) de confirmation de la suite de clés comprend : - une étape (2041) d’émission d’un premier code d’authentification (MAC1) calculé par le contrôleur (A) en fonction de la première clé de session (k 0 ) de la suite de clés de session, et en fonction d’un identifiant (IDA) du contrôleur (A), et d’un identifiant (IDB) du lecteur (B), et du paramètre de sécurité (PB) généré par le lecteur (B), et du paramètre de sécurité (PA) généré par le contrôleur (A); - une étape (2042) de réception d’un deuxième code d’authentification (MAC2) calculé par le lecteur (B) en fonction de la première clé de session (k 0 ) de la suite de clés de session, et en fonction d’un identifiant (IDA) du contrôleur (A), et d’un identifiant (IDB) du lecteur (B), et du paramètre de sécurité (PB) généré par le lecteur (B), et du paramètre de sécurité (PA) généré par le contrôleur (A); - une étape (2043) de vérification du deuxième code d’authentification (MAC2) reçu. Procédé (200) selon la revendication 11, dans lequel le paramètre de sécurité (PB) généré par le lecteur (B) est une autre clé publique (B EpubK ) générée par le lecteur (B), et dans lequel le secret partagé (S) est concaténé avec un autre secret partagé (S E ) calculé à partir de la clé privée (A SprivK ) du contrôleur (A) et de l’autre clé publique (B EpubK ) générée par le lecteur (B), le secret partagé concaténé devenant le secret partagé (S) utilisé pour l’étape (2032) de calcul de la suite de clés de session. Procédé (200) selon la revendication 12, dans lequel le paramètre de sécurité (PA) généré par le contrôleur (A) est une autre clé publique (A EpubK ) générée par le contrôleur (A), à laquelle correspond une autre clé privée (A EprivK ) générée par le contrôleur (A), et dans lequel l’autre secret partagé (S E ) est calculé à partir de l’autre clé privée (A EprivK ) générée par contrôleur (A) et de l’autre clé publique (B EpubK ) générée par le lecteur (B). Lecteur (B) de contrôle d’accès pour le contrôle d’accès à une zone ou concentrateur IOT, configuré pour communiquer une information, lue sur un badge, à un contrôleur (A), selon un procédé (100) selon l’une des revendications 1 à 7. Contrôleur (A) d’un lecteur de contrôle d’accès ou d’un concentrateur IOT configuré pour communiquer avec le lecteur de contrôle d’accès ou un concentrateur IOT selon un procédé (200) selon l’une des revendications 8 à 13.