LU507229B1 - Procédé asymétrique d'inscription de codes cryptographiques - Google Patents

Abstract

L'invention concerne un procédé d'inscription et de stockage sécurisé de clés cryptographiques sur une pluralité de supports physiques indépendants (100 ; 200 ; 100, 200 300, 400, 500, 600) via au moins une entité centrale (33 ; 33a, 33b). Ce procédé implique des entités de gestion (31 ; 32), chaque support physique étant associé à une entité de gestion respective. Le procédé comprend la génération de paires de clés cryptographiques asymétriques (pub1, priv1 ; pub2, priv2) par chaque entité de gestion (31 ; 32), incluant une clé publique et une clé privée. Il comprend également la sauvegarde du résultat du calcul d'une clé centrale publique (pub3) sur l'entité centrale (33 ; 33a, 33b), et l'inscription de cette clé centrale publique (pub3) sur chaque support physique respectif par les entités de gestion (31 ; 32).

Description

Titre : Procédé asymétrique d'inscription de codes cryptographiques

La présente invention concerne une méthode et un système d'inscription sécurisé et de stockage sécurisé de clés cryptographiques sur plusieurs supports physiques. La présente invention se rapport aussi à une pluralité de supports physiques configurés pour mettre en en œuvre ce procédé. La présente invention concerne en outre une méthode et des supports physiques configurés pour conserver des clés cryptographiques de manière sécurisée en utilisant des contrôles d'accès qui renforcent leur sécurité.

Domaine technique

La présente invention concerne la sécurité des données, et plus particulièrement la manipulation sécurisée d'éléments de données hautement sensibles tels que les clés cryptographiques. L'invention fournit une méthode d'inscription et de stockage avec contrôle d'accès sécurisé. L'invention est particulièrement adaptée pour, mais sans s'y limiter, l'utilisation de portefeuilles numériques (logiciels). Cela peut inclure, par exemple, des portefeuilles utilisés en relation avec des crypto-monnaies telles que

Bitcoin, Ethereum, Litecoin, etc.

État de la technique antérieure

Concernant l’état de la technique antérieure, il existe des procédés et systèmes de génération de clés cryptographiques pour permettre la reconstruction d'une clé d'accès spécifique à un compte sécurisé.

La publication WO-2017145018 révèle un exemple de procédé et de système sécurisé pour échanger des entités via une chaîne de blocs en intégrant des techniques de tokenisation, ainsi que des techniques pour intégrer des métadonnées dans un script d'échange d'une transaction blockchain, le script comprenant une première clé publique d'utilisateur (P1A) associée à une première clé privée utilisateur (V1A) formant une paire cryptographique asymétrique, et une première clé publique tierce

(P1T) associée à une première clé privée tierce (V1T) formant une paire LU507229 cryptographique asymétrique. Cette méthode consiste en un hachage du premier script pour générer un premier script hash et à publier le premier script et le premier script hash sur une table hash distribuée.

La publication US 2017237561 révèle un autre exemple de méthode et système pour prendre en charge des communications sécurisées à l'aide d'un module communiquant avec un serveur en accédant à Internet, et d'une application, le module pouvant dériver des paires de clés privées / publiques à l'aide d'algorithmes cryptographiques et d’ensembles de paramètres pour envoyer les données du module à l'application et recevoir les instructions du module à partir de l'application.

La publication US2015164192 révèle un support ou objet collectable avec une cavité scellée qui contient une clé privée qui accorde à l'utilisateur l'accès à une crypto- monnaie enregistrée sur un compte lorsque la cavité de l'objet scellé est visiblement cassée afin d'accéder à la cavité, l'objet comportant un enregistrement de la date de dépôt, et du montant de la crypto-monnaie dans le compte, des instructions pour l'utilisation d’une clé privée et/ ou publique, etune clé publique qui permet à l'utilisateur de voir le montant de crypto-monnaie déposé dans le compte.

La publication US2020295935 révèle une méthode et un système d’inscription sécurisé et de stockage sécurisé de clés cryptographiques, mais uniquement pour un support physique unique. Il est divulgué dans cette publication comment inscrire et stocker des clés cryptographiques sur un seul support physique incluant des clés cryptographiques, ces clés étant par exemple utilisées pour permettre l’accès a des portefeuilles en relation avec des crypto-monnaies.

Définitions

Cryptographie asymétrique : La cryptographie asymétrique se base sur l'existence de fonctions mathématiques à sens unique. Ces fonctions mathématiques utilisent 2 paramètres appelés clé privée et clé publique. La clé publique est utilisée pour chiffrer ou vérifier une signature, cette clé publique a pour but d’être diffusée et utilisée par LU507229 tout le monde. La clé privée correspondante permet de déchiffrer ou de signer un message.

Paire de clés asymétriques : une paire de clés asymétriques est composée d’une clé publique et de la clé privée correspondante. Une paire de clé est soit utilisé pour le chiffrement/déchiffrement soit pour la signature/vérification. Connaissant la clé publique il est impossible, dans un temps raisonnable, de trouver la clé privée correspondante. La clé privée est confidentielle et doit être gardée secrète.

Signature électronique : une signature électronique utilise la cryptographie asymétrique. La clé privée est utilisée pour signer et la clé publique pour vérifier la signature.

Autocollant holographique témoin : L'autocollant holographique témoin est un autocollant contenant un hologramme 3d qui, lorsqu'il est décollé, se détruit. Après avoir retiré un autocollant holographique témoin, il est impossible de le repositionner sans que son retrait ne puisse être détecté visuellement. Dès lors il peut être utilisé pour voir si un secret caché sous cet autocollant a été révélé.

Monnaie cryptographique : les monnaies cryptographiques sont des monnaies basées sur la technologie dite de « blockchain » ou chaine de blocks où toutes les transactions sont stockées dans une base de données distribuée entre tous les participants. Chaque transaction de monnaie cryptographique doit être signée électroniquement en utilisant une clé privée asymétrique.

Jeton de monnaie cryptographique : Unité de valeur utilisé dans les monnaies cryptographique. Ces jetons sont associés à une clé publique et sont transférables d’une clé publique à une autre en signant (a l’aide de la clé privé) une transaction électronique.

Adresse de Monnaie cryptographique : Dans le cadre des monnaies cryptographiques, les jetons peuvent être associés non pas à une clé publique mais à une adresse. Cette adresse est le plus souvent calculée en fonction de la clé publique.

Adresse Multi-signature s sur n : les jetons utilisés comme crypto-monnaie peuvent être envoyé à une adresse multi-signature, ce qui signifie que pour être utilisés les jetons doivent être dépensés dans une transaction qui doit être signée par plusieurs clés privées asymétrique. De plus, il est possible d'indiquer le nombre de signatures s nécessaires parmi les n clés paires de clés sélectionnées. Par exemple, pour dépenser un jeton envoyé à une adresse multi-signature 3 sur 4, la signature de 3 clés privées parmi un set de 4 paires de clés asymétriques peut être nécessaire. Toutes les informations (set de clés asymétrique, nombre de signature nécessaires, etc...) concernant les exigences pour utiliser les jetons envoyés à une adresse multi- signature de monnaie cryptographique sont connues de l’état de la technique.

Certificat Racine : les certificats racine sont des certificats électroniques générés par une autorité de certification. Ces certificats racine se trouve par exemple dans les navigateurs web et permette de vérifier la validité du certificat d’un site web et dès lors de commencer une communication chiffrer.

Portefeuille numérique : Un portefeuille numérique est un logiciel ou un service qui permet à son utilisateur d'effectuer des opérations de paiement en utilisant des monnaies cryptographiques. Le rôle du portefeuille numérique est à la fois de créer, de signer et de publier une transaction de monnaies cryptographiques.

Problème : Stockage sécurisé long terme des clés privées cryptographiques

La cryptographie à clé publique est souvent utilisée pour protéger des informations nécessaires a des transactions. L'utilisation de clés asymétriques, comportant une cryptographie à clé publique, déplace la question de la sécurité dans une certaine mesure. Bien que la clé privée soit gardée secrète, sa clé publique correspondante peut être rendue publique. Son interception par un tiers n'est pas problématique.

Comme toutes autres données informatiques, les clés privées cryptographiques sont soumises au problème du stockage qui requiert un haut niveau de sécurité. Il doit être résistant aux attaques de personnes malveillantes, à l'épreuve du temps et des désastres naturels.

5 LU507229

Résister aux attaques de personnes malveillantes signifie que le support ne doit pas être accessible facilement. Cela peut être fait en stockant la clé sur un support non connecté dans un endroit où les contrôles d'accès sont importants, par exemple dans un coffre de banque. Cela veut dire que la clé cryptographique n’est pas utilisée régulièrement, ce qui est le cas pour les clés privées des certificats racine ou les clés utilisées pour les investissements longs termes de monnaies cryptographiques.

Suivant l’art antérieur, on peut reprocher à ces méthodes et systèmes de génération de clés cryptographiques connus sur un support qu’ils ne sont pas prévus pour résoudre le problème de l’inscription et du stockage à long terme des clés privées avec un haut niveau de sécurité et que ces clés cryptographiques sont vulnérables à l'interception par des tiers non autorisés. Avec ces méthodes et systèmes de génération de clés cryptographiques connus, rien n’est prévu pour résister aux attaques de personnes malveillantes lors de la création du support, ou pour éviter que le support soit détruit par l'épreuve du temps et des désastres naturels.

En outre, les problèmes résultent également dans leur mise en œuvre car ces supports de stockage de clés cryptographiques sont peu fiables et ne résistent pas aux intempéries, et autres désastres naturels.

Le stockage de la clé privée soulève des problèmes de sécurité importants. Les supports digitaux sont fragiles et peuvent se dégrader au fur et à mesure du temps. A titre d'exemple, dans le cas d’un portefeuille de crypto-monnaie numérique tel qu'un portefeuille Bitcoin, le portefeuille comprend un logiciel qui permet à un utilisateur de se connecter. La clé privée est stockée soit par le portefeuille installé sur le périphérique de l'utilisateur, soit par un fournisseur de services de portefeuille.

Cependant, la clé privée stockée peut être volée ou perdue, la perte pouvant être due à des dommages causés au matériel de l'utilisateur, par exemple ordinateur. De même, si l'utilisateur meurt ou devient incapable, l'accès à la clé privée peut être perdu et donc les fonds associés au portefeuille deviennent inaccessibles. Bien que le stockage côté fournisseur de services de la clé privée puisse surmonter ces problèmes, l'utilisateur doit être prêt à faire confiance au fournisseur de services pour garder sa clé privée en toute sécurité. LU507229

Les violations de sécurité du côté du fournisseur de services sont alors un risque réel et important.

En particulier, il existe aujourd’hui un problème réel de sécurité lié au transport des supports contenant partiellement les secrets cryptographiques. En effet, bien que le scellement et le cryptage des supports avant leur expédition offrent une certaine protection, ils ne suppriment pas entièrement le risque de compromission durant le transport. La manipulation physique de ces supports par des transporteurs peut exposer les secrets à des risques d'interception ou de manipulation malveillante, surtout si le transporteur n'est pas entièrement fiable ou si le processus de vérification à l'arrivée est défaillant. Cette vulnérabilité pourrait permettre à des acteurs malintentionnés d'accéder à des informations sensibles malgré les mesures de sécurité en place.

De plus, la méthode des "brain wallets", c'est-à-dire de stocker un portefeuille sous la forme d'une clé privée mémorisée ou d'une phrase d'amorçage, présente ses propres défis en termes de sécurité et de praticabilité. Se rappeler avec précision une suite complexe de caractères peut être difficile et sujet à erreur. Cela peut conduire à une perte irréversible des accès cryptographiques si l'utilisateur oublie la séquence ou si elle est mal reconstituée. De plus, malgré leur nature apparemment sécurisée, ces "brain wallets" sont vulnérables aux attaques de force brute, surtout si les phrases de passe ne sont pas suffisamment complexes ou si elles suivent des modèles linguistiques prévisibles.

Résumé de l’invention

Il existe donc un besoin de pouvoir disposer d’une méthode, de supports physiques et plus généralement d’un système qui, permet de remédier aux inconvénients précités.

Pour pallier les inconvénients précités, un objet de la présente divulgation propose un procédé d'inscription et de stockage sécurisé de clés cryptographiques sur une pluralité de supports physiques indépendants via au moins une entité centrale, chaque LU507229 support physique étant respectif d’une entité de gestion correspondante parmi une pluralité d’entités de gestion, ledit procédé comprenant les étapes suivantes : a) au moyen de chacune desdites entités de gestion, générer une paire de clés cryptographiques asymétriques respective de ladite chacune entité de gestion, chacune des paires générée(s) de clés cryptographiques asymétriques comprenant une clé publique de ladite entité de gestion respective et une clé privée de l'entité de gestion respective, b) au moyen desdites entités de gestion, et de l'au moins une entité centrale, sauvegarder, sur au moins une entité centrale, le résultat d’un calcul d’une clé centrale publique, et c) au moyen de chacune desdites entités de gestion, inscrire, sur chaque support physique respectif de ladite chaque entité de gestion, la clé centrale publique sauvegardée.

Diverses caractéristiques supplémentaires peuvent être prévues seules ou en combinaison : - l'étape de sauvegarde comprend au moins la sous-étape de b2) inscrire, sur chaque support physique de ladite pluralité de supports physiques indépendants, au moyen de l’entité de gestion respective de chaque support physique, la clé privée respective générée par ladite entité de gestion respective, - l’étape de sauvegarde comprend au moins la sous-étape de b5) transmettre, depuis chaque entité de gestion, vers 'au moins une entité centrale, la clé publique respective générée par ladite entité de gestion, - l'étape de sauvegarde comprend au moins la sous-étape de calculer, au moyen de

Tau moins une entité centrale, ladite clé centrale publique à partir de chacune des clés publiques transmises par les entités de gestion, - le procédé comprend en outre, suite à la mise en œuvre de l'étape c) d'inscription, une mise en œuvre d’une étape de livrer au moins l’un des supports physiques parmi la pluralité de supports physiques indépendants, à une entité de contrôle respective de l'entité de gestion et dudit support physique, - l'étape a) de génération comprend enregistrer, par chacune desdites entités de gestion, dans une mémoire de l'entité de gestion mettant en œuvre ladite génération, la clé publique générée,

-l’étape a) de génération comprend associer, par chacune desdites entités de gestion, LU507229 la paire de clés cryptographiques asymétriques respective de ladite entité de gestion à un numéro de série du support physique respectif de ladite entité de gestion, - le procédé comprend en outre, suivant ou suite à la mise en œuvre de l'étape d'association, une étape d'écriture, par chaque entité de gestion, sur le support physique respectif de ladite entité de gestion, de la clé privée de l’entité de gestion respective, - le procédé comprend en outre, suivant ou suite à la mise en œuvre de l'étape d'écriture, une étape de vérification, par chaque support physique respectif de l’entité de gestion ayant mis en œuvre l'étape d'association et l'étape d’écriture, de la clé privée de l’entité de gestion respective, - le procédé comprend en outre, suivant ou suite à la mise en œuvre de l'étape de vérification, une étape d'obfuscation de la clé privée vérifiée de l’entité de gestion respective, - l'étape c) d'inscription comprend une mise en œuvre d'une sous-étape c1) de transmettre, depuis l’au moins une entité centrale, à chaque entité de gestion, la clé centrale publique calculée.

Un des objets de l'invention est de fournir une méthode et un système d'inscription sécurisé de clés cryptographiques sur plusieurs supports physiques, supports physiques avec lesquels il est assuré que lesdites clés cryptographiques n’auront jamais été utilisées par un même utilisateur.

Un autre but de la présente invention est de proposer une méthode et un système qui dans le cas des clés cryptographiques correspondant à plusieurs supports physiques, assure un stockage avec un haut niveau de sécurité, et qui est résistant aux attaques de personnes malveillantes à l'encontre de l’un quelconque de cette pluralité de supports physiques, ainsi qu’à l’épreuve du temps et des désastres naturels.

Résister aux attaques de personnes malveillantes signifie que le support ne doit pas être accessible facilement.

Par conséquent, un but de la présente invention est de fournir une méthode et un système d'inscription et de stockage discret de clés cryptographiques sur plusieurs supports physiques qui soit aussi fiable que possible.

En d'autres mots, la présente invention permet d'améliorer la sécurité et la fiabilité de LU507229 la création de clés cryptographiques sur plusieurs supports physiques, avec pour avantage de pouvoir garantir qu'aucun de ces supports physiques n’a été compromis au cours des phases de création et/ou d'inscription des codes et clés cryptographiques correspondantes.

L’utilisation d’un seul support physique présente plusieurs failles car ceci facilite un accès malveillant aux clés cryptographiques stockées sur le seul support physique. Un utilisateur malveillant pourrait reconstruire une clé spécifique, par exemple une clé d'accès à un compte sécurisé en association avec un système de gestion de portefeuille. À l'inverse, l'emploi de plusieurs supports physiques fournit une solution qui permet une manipulation plus sécurisée d'un secret, par exemple une clé cryptographique et/ou une adresse calculée à partir d’une clé cryptographique pour donner accès à cette clé.

Plusieurs supports physiques permettent de réduire de manière significative les risques de compromettre des informations sensibles, particulièrement en matière de clés cryptographiques. On résout ainsi l’une des craintes majeures associées à l'utilisation d'un support unique, qui réside dans le fait que toutes les données, qu'elles soient publiques ou secrètes, sont centralisées en un seul point, augmentant ainsi le risque de compromission avant même que l'utilisateur final n'entre en possession du support. Entre le moment où les codes secrets sont inscrits sur le support et le moment où l'utilisateur reçoit ce dernier, la chaîne logistique présente de multiples opportunités pour que ces informations soient exposées ou altérées. Avantageusement, la présente solution permet de répartir les secrets sur deux supports distincts suivant des canaux de livraison différents, minimisant le risque de compromission.

Dans le cadre de la présente invention, les objectifs sont atteints, en ce que clés cryptographiques peuvent être stockées sur un support non connecté dans un endroit où les contrôles d'accès sont importants, par exemple dans un coffre de banque. Cela veut dire que la clé cryptographique n’est pas utilisée régulièrement, ce qui est le cas pour les clés privées des certificats racine ou les clés utilisées pour les investissements longs termes de monnaies cryptographiques.

Les supports digitaux sont fragiles et peuvent se dégrader au fur et à mesure du temps.

Cependant, les clés cryptographiques sont de petites tailles comparées aux autres fichiers informatiques, ce qui rend possible leurs stockages sur des supports physiques, donc non-digitaux.

Certain métaux ou alliages sont des supports très résistant qui peuvent subir des contraintes physiques importantes. Ces supports sont donc de très bons candidats pour un stockage long terme des clés cryptographiques.

Selon l’invention, les clés cryptographiques peuvent être gravées sur une barre en métal ou en alliage de métaux, telle qu’une barre en or, platine, argent ou acier.

Le stockage d’information sur des métaux nécessite une expertise et des machines spécialisées. Des individus privés doivent donc déléguer ce processus à une partie de confiance. La confiance est donc le point critique de cette méthode car l’entité qui inscrit l'information confidentielle sur le métal aura temporairement accès à l'information. Le processus de invention développé permet de diminuer le risque lié à la confiance en une seule entité en divisant cette confiance entre plusieurs entités distinctes.

La Cryptographie implique des techniques de stockage sécurisé de données sensibles ainsi que sa communication entre deux ou plusieurs entités de gestion distinctes. Une entité de gestion peut inclure un dispositif de communication mobile, une tablette, un ordinateur portable, un ordinateur de bureau, d'autres formes de dispositifs informatiques et des dispositifs de communication, un dispositif serveur dans un réseau, un périphérique client, etc. Les entités de gestion peuvent être associées, par exemple, à une personne physique, à un groupe de personnes, comme les employés d'une entreprise, ou à un système tel qu'un système bancaire. Pour des raisons de sécurité, deux ou plusieurs entités de gestion ne peuvent être liées par un réseau de communication car il ne serait pas sûr et vulnérable à l'interception par des tiers non autorisés. Par conséquent, plusieurs informations secrètes différentes générées aléatoirement, avec suffisamment d’entropie, sont inscrites sur un support l’une après l’autres par deux personnes différentes à partir d’entités de gestion distinctes. De préférence, chacune des deux personnes recouvre le secret au moyen d’un cache de LU507229 sécurité immédiatement après l'inscription, par exemple avec un hologramme de sécurité.

Brève description des figures

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit. Aussi, afin de permettre une compréhension plus claire de l'invention on décrira ci-après, plusieurs formes de réalisation préférées, à titre d'exemple, en se référant en particulier aux figures en annexe, parmi lesquelles : - la figure 1 illustre un schéma d’un mode de réalisation de l'invention utilisant deux supports physiques et trois entités de gestion, dont une entité de gestion centrale, pour fournir, à deux entités séparées, une clé publique centrale, et - la figure 2 illustre un schéma d’un autre mode de réalisation de l'invention utilisant deux supports physiques et trois entités de gestion, dont deux entités de gestion centrales, pour fournir, à deux entités séparées, une clé publique centrale.

La présente invention est décrite avec des réalisations particulières et des références a des figures mais l'invention n’est pas limitée par celles-ci. Les dessins ou figures … décrits ne sont que schématiques et ne sont pas limitants.

Premier mode de réalisation de l’invention :

La figure 1 illustre une réalisation représentative de l'invention utilisant trois entités de gestion 31, 32 et 33, dont l'entité centrale 33, pour fournir une clé publique centrale pub3. Deux autres entités 131 et 232 sont également illustrées pour recevoir les supports physiques finaux à l'issue du procédé.

La figure 2 illustre une réalisation représentative de l'invention utilisant quatre entités de gestion 31, 32, 33a et 33b, dont deux entité centrales 33a et 33b, pour fournir une clé publique centrale pub3.

Le système d'inscription et de stockage sécurisé de clés cryptographiques sur un LU507229 support physique comprend : - une première entité de gestion 31 configurée pour générer une première paire de clés cryptographiques asymétriques comprenant une première clé publique utilisateur pub1 et une première clé privée utilisateur priv1, la première entité de gestion 31 comportant : - un premier ordinateur 41 dans lequel des instructions de programme sont mémorisées, lesquelles instructions, lorsqu'elles sont lues par un premier processeur de données, font que le premier ordinateur génère la première clé privée utilisateur priv1 et mémorise la première clé publique utilisateur pub1 dans une première mémoire d'enregistrement, - Un premier dispositif 51 associé au premier ordinateur configuré pour inscrire la première clé privée utilisateur priv1 sur un support physique, et - un premier moyen pour vérifier la première clé privée utilisateur priv1 inscrite et apposer un premier élément occultant témoin hol1 sur le support physique pour occulter la première clé privée utilisateur priv1 et la rendre non-visible, une deuxième entité de gestion 32 configurée pour générer une deuxième paire de clés cryptographiques asymétriques comprenant une deuxième clé publique utilisateur pub2 et une deuxième clé privée utilisateur priv2, la deuxième entité de gestion 32 comportant : - un deuxième ordinateur 42 dans lequel des instructions de programme sont mémorisées, lesquelles instructions, lorsqu'elles sont lues par un deuxième processeur de données, font que le deuxième ordinateur 42 est configuré pour mémoriser la deuxième clé publique utilisateur pub2 dans une deuxième mémoire d'enregistrement ; - un deuxième dispositif 52 associé au deuxième ordinateur pour inscrire la deuxième clé privée utilisateur priv2 sur le support physique, et - un deuxième moyen pour vérifier la deuxième clé privée utilisateur priv2 inscrite et apposer un deuxième élément occultant témoin hol2 sur le support physique pour occulter la deuxième clé privée utilisateur priv2 et la rendre non-visible.

La troisième entité de gestion 33 est configurée pour générer uniquement la clé publique centrale pub3, et comporte un troisième ordinateur 43 dans lequel des instructions de programme sont mémorisées, lesquelles instructions, lorsqu'elles sont lues par un troisième processeur de données, font que le troisième ordinateur génère LU507229 la clé publique centrale pub3 dans une troisième mémoire d'enregistrement.

En outre, le troisième ordinateur 43 est configuré pour générer une clé publique centrale pub3 à partir de la première clé publique utilisateur pub1 transmise par l’entité de gestion 31 et de la deuxième clé publique utilisateur pub2 et permettre la transmission de cette clé publique centrale pub3 à l’entité de gestion 31 pour être inscrite sur le premier support physique 100 et à l'entité de gestion 32 pour être inscrite sur le deuxième support physique 200.

Exemple de mise en œuvre via internet

Comme représenté aux figures 1 et 2, invention vise à fournir un exemple de système sécurisé d'inscription et de stockage de clés cryptographiques sur des supports physiques indépendants via plusieurs entités de gestion et une entité centrale. Dans ce contexte, l'entité 31 est désignée comme l'entité 1 et l'entité 32 comme l'entité 2, les deux étant associées à l'entité centrale 33 qui est par exemple un éditeur de programme informatique ou de logiciel pour la gestion des clés.

On décrit ci-dessous le cas d’une mise en œuvre via internet.

Au préalable, l’entité 32 télécharge un logiciel ou progiciel émis par l’entité 33. Ce logiciel permet à l’entité 32 de gérer la création et le stockage de ses paires de clés cryptographiques de manière sécurisée. L'entité 33, bien qu’elle édite ce logiciel, ne voit pas les informations envoyées par l’entité 32, garantissant ainsi la confidentialité des données.

Lors de l'ouverture d'une session par l'entité 32, celle-ci demande la création d'une paire de clés cryptographiques pub2/priv2. Cette demande est enregistrée par l’entité 33, qui envoie ensuite une requête à l’entité de gestion 31 pour la création d’une autre paire de clés pub1/priv1. L'entité 33 enregistre également l'appairage des supports

NOO1 de l’entité 31 avec NOO2 de l’entité 32. Cette session de création de paires de clés est donc liée à cet appairage précis de supports.

En parallèle, l'entité de gestion 31 démarre sa propre session de création de clés. LU507229

L’entité 32 ouvre une session spécifique pour la création de sa paire de clés priv2/pub2 associée au numéro de série NO02. Cette procédure suit plusieurs étapes détaillées, décrites ci-dessous.

Au cours de l'étape S21, l’entité 32, grâce au logiciel, génère une paire de clés priv2/pub2 associée au numéro de série NO02. Seule l'entité 32 peut visualiser cette information, assurant ainsi la sécurité et la confidentialité. Ensuite, à l'étape S220, l'entité 32 mémorise la clé publique pub2. Lors de l’étape S221, l’entité 32 associe cette paire de clés à son numéro de série NO02 dans un champ spécifique. À l’étape

S222, l’entité 32 inscrit sa clé privée priv2 sur un support physique 200. Ensuite, au cours de l'étape S223, l’entité 32 vérifie l’inscription de la clé priv2 sur le support 200.

Une fois cette vérification effectuée, l'entité 32 obscurcit la clé priv2 pour la rendre non visible lors de l'étape S224. Enfin, à l'étape S225, l’entité 32 transmet sa clé publique pub2 à l’entité 33, en précisant le numéro de série NO02.

L’entité centrale 33, utilisant les clés publiques pub1 et pub2, calcule alors la clé publique centrale pub3. Ce calcul se déroule pendant l’étape S326. Ensuite, à l'étape

S231, l’entité 33 communique la clé publique centrale pub3 à l’entité 32. L’entité 32 inscrit ensuite la clé publique centrale sur son support 200 au cours de l’étape S232.

On note que lorsque deux entités centrales sont présentes, par exemple l’entité 3a dénotée par la référence 33a et l’entité 3b dénotée par la référence 33b sur la figure2, l'étape S326 de calcul de la clé centrale publique pub3 peut être mise en œuvre par l'entité 33a ou par l'entité 33b.

En parallèle, l'entité 31 démarre une session propre de création de clés. Elle reçoit la demande de l'entité 33 pour la création d'une paire de clés priv1/pub1 et ouvre une session d'appairage de clés avec le support NOO1. Cette procédure suit les étapes suivantes :

Lors de I'étape S11, l’entité 31 génère une paire de clés priv1/pub1. Ensuite, au cours de l’étape S110, l’entité 31 mémorise la clé publique pub1. À l’étape S121, l’entité 31 associe cette paire de clés à son numéro de série NOO1 dans un champ spécifique. La clé privée priv1 est ensuite inscrite sur un support physique 100 lors de l'étape S122.

Ensuite, au cours de l'étape S123, l’entité 31 vérifie l'inscription de la clé priv1 sur le LU507229 support 100. Une fois cette vérification effectuée, l’entité 31 obscurcit la clé priv1 pour la rendre non visible lors de l’étape S124. Finalement, à l'étape S125, l’entité 31 transmet sa clé publique pub1 à l’entité 33, en précisant le numéro de série NOO1.

Suite au calcul de la clé publique centrale pub3, l’entité 33 communique cette clé publique centrale à l’entité 31 au cours de l’étape S131. L’entité 31 inscrit ensuite la clé publique centrale sur son support 100 lors de l’étape S132.

Une fois ces étapes réalisées, le support 100 est livré à l'entité 31 ou envoyé à l'entité 32. Au cours de l'étape S151, le support 100 est reçu par l’entité 31. Lors de l’étape

S151prime, le support 100 peut être retiré par l’entité 32 ou envoyé à celle-ci.

Ainsi, l'entité 32 se retrouve en possession des supports 100 et 200. À partir de ces supports, l'entité 32 peut calculer la clé privée finale en utilisant un logiciel en open source, complétant ainsi le processus sécurisé d'inscription et de stockage des clés cryptographiques.

On obtient ainsi un procédé et un système qui permettent d’assurer une gestion sécurisée des clés cryptographiques sur des supports physiques indépendants via une architecture impliquant plusieurs entités de gestion et une entité centrale. Chaque étape du processus, de la génération à l'inscription et a 'obscurcissement des clés, garantit la confidentialité et la sécurité des données, tout en permettant une flexibilité et une adaptabilité dans l'utilisation des supports physiques et des clés générées.

Matériel et logiciel

Le processus d'inscription des clés cryptographiques utilise au moins trois entités de gestion 31, 32 et 33 différentes, dont au moins une entité de gestion 33 dite « centrale ».

Les entités de gestion 31, 32 et 33 peuvent être associées, par exemple, à une LU507229 personne physique, à un groupe de personnes, comme les employés d'une entreprise, ou à un système tel qu'un fournisseur de services.

Chacune des entités 31, 32 ou 33 a une machine à graver correspondante 51, 52 ou 53, reliée à un ordinateur 41, 42 ou 43, pour réaliser inscription sur leurs supports physiques. Ces trois ordinateurs 41, 42 et 43 ne sont connectés à aucun réseau pour éviter les risques de cyberattaque. Il est également conseillé d’avoir un ordinateur 41,42 avec une protection électromagnétique pour éviter les attaques utilisant les ondes électromagnétiques pour endommager ou espionner l'équipement. Sur ces ordinateurs sont installés le logiciel de génération des clés privés et des clés publiques.

Chacune des entités 31 et 32 est en possession d’un ou de plusieurs dispositif(s) obscurcissant(s) qu’elle appliquera sur les supports physiques. Sur ces ordinateurs sont installés le logiciel de génération des clés privées et des clés publiques. Chacune des entités 31 et 32 est en possession d'un ou de plusieurs dispositif(s) obscurcissant(s) qu’elle appliquera sur les supports physiques.

L’entité de gestion 33 comprend un ordinateur 43 qui n’est pas connecté à aucun réseau. Ceci permet d’éviter les risques de cyberattaque et/ou de fournir une protection électromagnétique pour éviter les attaques éventuelles se servant d'ondes électromagnétiques.

Le logiciel permet d’effectuer des calculs cryptographiques pour la génération, vérification, signature des paires de clés asymétriques. Il permet aussi de générer une adresse de monnaies cryptographiques à partir dune clé ou de plusieurs clés publiques. De plus, la méthode de calcul utilisée pour générer les clés privées et les clés publiques est mise en œuvre, en particulier, pour générer la clé publique centrale pub3.

Dans le cas de 3 entités, il peut y avoir 6 employés impliqués, soit à titre d'exemple : — Alice et Albert employés de la première entité 31.

— Bob et Brian employés de la seconde entité 32 LU507229 — John et Jane employés de la troisième entité 33.

Inscription des clés cryptographiques

Les étapes de la génération et de l'inscription des clés publiques et privées sont présentées dans de schéma de la Figure 1. (1) Alice génère une paire de clés publique/privée sur l'ordinateur 41 à l’aide du logiciel. (2) Alice prend une barre ou un support en métal 100 et inscrit la clé privée (priv1). (3) Albert rentre cette clé privée dans le logiciel. Celui-ci va régénérer la clé publique (pub1). Albert vérifie que la clé publique générée à partir de la clé privée et la clé publique (pub1) générée par Alice sont les mêmes. (4) Une fois cette vérification effectuée, Alice et Albert appliquent le dispositif obscurcissant (Obf1) de leur entité 31 sur la clé privée (priv1), et/ou par exemple collent l’autocollant holographique témoin (hol1) de leur entité 31 sur la clé privée (priv1). (5) Alice et Albert transmettent la première clé publique (pub1) a la troisième entité 33

La seconde entité 32 effectue ensuite un processus similaire. (6) Brian génère une paire de clés publique/privée, (7) Brian inscrit la clé privée (priv2), puis (8) Bob vérifie à l’aide du logiciel que la clé gravée à bien la même clé publique (pub2) que celle de Brian. (9) Bob et Brian appliquent le dispositif obscurcissant (Obf2) de leur entité 32 sur la clé privée (priv2) et/ou par exemple collent l’autocollant holographique témoin (hol2) de leur entité 32 sur la clé privée (priv2).

Bob et Brian transmettent la deuxième clé publique (pub2) à la troisième entité 33.

John calcule la troisième clé publique centrale (pub3) à partir de l'ordinateur 43

Jane vérifie à l’aide du logiciel que la clé publique centrale (pub3) est bien correcte

John et Jane transmettent cette clé publique centrale aux entités 31 et 32 pour qu’elle soit inscrite pour l’entité 31 par Alice sur le support en métal 100 et ensuite vérifiée par

Albert et qu’elle soit inscrite pour l'entité 32 par John sur le support en métal 200 et LU507229 ensuite vérifiée par Jane.

Dans l'exemple ici présenté, le processus permet de créer deux supports en métal 100 et 200, sur lesquels sont inscrits par deux entités différentes 31 et 32, deux clés privées (priv1) et (priv2), qui sont obscurcies par deux dispositifs (Obf1, Obf2) ainsi qu’une clé publique centrale (pub3). A aucun moment, les entités 31 et 32 ne communiquent l’une l’autre grâce à l'entité 33, qui joue ainsi le rôle de créer un sas de sécurité empêchant une compromission des clés.

De plus, les entités 31 et 32 n’entrent pas en contact avec l'utilisateur final. En effet, l'entité 31 transmet son support physique 100 à l’entité 131 et l’entité 32 transmet son support physique 200 à l'entité 232. Ainsi les entités 31 et 32, non seulement ne communiquent pas l’une avec l’autre, mais elles ne communiquent pas non plus avec l’utilisateur final.

Récupération de la clé privée _ L'utilisateur final des supports physiques 100 et 200 peut vérifier que le ou les dispositif(s) obscurcissant(s) Obf1 sur le support 100 et Obf2 sur le support 200 n’ont subi aucun dommage, et donc que les clés privées priv1 et priv2 sont pas été dévoilées.

Afin de récupérer sa clé privée finale priv3, l’utilisateur final doit révéler les clés privées priv1 sur le support physique 100 et priv2 sur le support physique 200.

L'utilisateur final renseigne les clés priv1 et priv2 dans le logiciel, ainsi que la clé publique centrale pub3. Le logiciel effectue la rédemption de la clé privée finale priv3 qui va de pair avec la clé publique centrale pub3.

Cette clé privée finale priv3 n’a jamais été calculée auparavant car personne n’avait accès aux informations nécessaires, c'est à dire, à la clé publique centrale et les deux clés privés priv1 et priv2. Aucun employé de l’entité 31, 32 ou 33 n'a eu accès aux informations suffisantes pour récupérer la clé privée finale excepté l'utilisateur final.

L’entité 33 permet de créer un mur au travers duquel les entités 31 et 32 ne communiquent pas car elles ne se connaissent pas et n'ont pas besoin de se transmettre une quelconque information, clé ou autre élément.

L’entité 33, elle-même LU507229 ne connaît aucune des clés privées priv1 ou priv2.

Claims (10)

REVENDICATIONS

1. Procédé d'inscription et de stockage sécurisé de clés cryptographiques sur une pluralité de supports physiques indépendants (100 ; 200 ; 100, 200 300, 400, 500, 600) via au moins une entité centrale (33 ; 33a, 33b), chaque support physique (100 ; 200 ; 100, 200 300, 400, 500, 600) étant respectif d’une entité de gestion (31 ; 32) correspondante parmi une pluralité d’entités de gestion (31 ; 32), ledit procédé comprenant les étapes suivantes : a) au moyen de chacune desdites entités de gestion (31 ; 32), générer (S11 ; S21) une paire de clés cryptographiques asymétriques (pub1, priv1 ; pub2, priv2) respective de ladite chacune entité de gestion (31 ; 32), chacune des paires générée de clés cryptographiques asymétriques (pub1, priv1 ; pub2, priv2) comprenant une clé publique (pub1 ; pub2) de ladite entité de gestion respective (31 ; 32) et une clé privée (priv1 ; priv2) de l’entité de gestion respective (31 ; 32), b) au moyen desdites entités de gestion (31 ; 32), et de 'au moins une entité centrale (33 ; 33a, 33b), sauvegarder (S121, S221, S122, S222, S123, S223, S124, S224, S125, S225, S326), sur l’au moins une entité centrale (33 ; 33a, 33b), le résultat d’un calcul d’une clé centrale publique (pub3), et c) au moyen de chacune desdites entités de gestion (31 ; 32), inscrire (S131, S132 ; S231, S232), sur chaque support physique (100 ; 200) respectif de ladite chaque entité de gestion (31 ; 32), la clé centrale publique (pub3) sauvegardée.

2. Procédé selon la revendication 1, dans lequel l’étape de sauvegarde (S121, S221, S122, S222, S123, S223, S124, S224, S125, S225, S326) comprend au moins les sous-étapes de - b2) inscrire (S122, S222), sur chaque support physique de ladite pluralité de supports physiques indépendants (100 ; 200 ; 100, 200 300, 400, 500, 600), au moyen de l’entité de gestion respective (31 ; 32) dudit chaque support physique (100 ; 200 ; 100, 200 300, 400, 500, 600), la clé privée (priv1 ; priv2) respective générée par ladite entité de gestion (31 ; 32) respective, - b5) transmettre (S125, S225), depuis chaque entité de gestion (31 ; 32), vers l’au moins une entité centrale (33 ; 33a, 33b), la clé publique (pub1 ; pub2) respective générée par ladite entité de gestion (31 ; 32), et b6) calculer (S326), au moyen de l’au moins une entité centrale (33 ; 33a, 33b), LU507229 ladite clé centrale publique (pub3) à partir de chacune des clés publiques (pub1 ; pub2) transmises par les entités de gestion (31 ; 32).

3. Procédé selon l’une quelconque des revendications précédentes, comprenant en outre, suite à la mise en œuvre de l’étape c) d’inscription (S131, S132, S231, S232), une mise en œuvre d’une étape d1) de livrer (S141 ; S242) au moins l’un des supports physiques (100 ; 200) parmi la pluralité de supports physiques indépendants (100, 200), a une entité de contrôle (131 ; 232) respective de l'entité de gestion (31 ; 32) et dudit support physique (100 ; 200).

4. Procédé selon l’une quelconque des revendications précédentes, dans lequel l'étape a) de génération (S11 ; S21) comprend enregistrer (S110 ; S220), par chacune desdites entités de gestion (31 ; 32), dans une mémoire de l’entité de gestion (31 ; 32) mettant en œuvre ladite génération, la clé publique (pub1 ; pub2) générée.

5. Procédé selon l’une quelconque des revendications précédentes, dans lequel l'étape a) de génération (S11 ; S21) comprend associer (S121 ; S221), par chacune desdites entités de gestion (31 ; 32), la paire de clés cryptographiques asymétriques (pub1, priv1 ; pub2, priv2) respective de ladite entité de gestion (31 ; 32) à un numéro de série (N001 ; NO02) du support physique (100 ; 200 ; 100, 200 300, 400, 500, 600) respectif de ladite entité de gestion (31 ; 32).

6. Procédé selon la revendication 5, comprenant en outre, suivant la mise en œuvre de l'étape d'association (S121; S221), une étape d’écriture (S122 ; S222), par chaque entité de gestion (31 ; 32), sur le support physique (100 ; 200) respectif de ladite entité de gestion (31 ; 32), de la clé privée (priv1 ; priv2) de l’entité de gestion respective (31 ; 32).

7. Procédé selon la revendication 6, comprenant en outre, suivant la mise en œuvre de l’étape d’écriture (S122 ; S222), une étape de vérification (S123 ; S223), par chaque support physique (100 ; 200) respectif de l’entité de gestion (31 ; 32) ayant mis en œuvre l’étape d'association (S121 ; S221) et l’étape d’écriture (S122 ;

8222), de la clé privée (priv1 ; priv 2) de l’entité de gestion respective (31 ; 32). LU507229

8. Procédé selon la revendication 7, comprenant en outre, suivant à la mise en œuvre de l’étape de vérification (S123 ; S223), une étape d’obfuscation (S124 ; S224) de la clé privée (priv1 ; priv2) vérifiée de l’entité de gestion respective (31 ; 32).

9. Procédé selon l’une quelconque des revendications précédentes, dans lequel l'étape c) d'inscription (S131, S132; S231, S232) comprend une mise en œuvre d’une sous-étape c1) de transmettre (S131 ; S231), depuis l’au moins une entité centrale (33 ; 33a, 33b), à chaque entité de gestion (31 ; 32), la clé centrale publique (pub3) calculée.

10. Procédé selon la revendication 9, dans lequel I'étape c) d'inscription (S131, S132 ; S231, S232) comprend une mise en œuvre d’une sous-étape c1) de transmettre (S131 ; S231), depuis l’au moins une entité centrale (33 ; 33a, 33b), a chaque entité de gestion (31 ; 32), la clé centrale publique (pub3) calculée.