DPKI: remédier aux inconvénients de l'ICP centralisée au moyen de la chaîne de blocs

Les certificats numériques sont l'un des outils auxiliaires les plus connus qui aident à protéger les données sur les réseaux publics. Cependant, le principal inconvénient de cette technologie est également connu: les utilisateurs sont obligés de faire implicitement confiance aux autorités de certification qui émettent des certificats numériques. Andrey Chmora, directeur des technologies et des innovations chez ENCRY, a suggéré une nouvelle approche pour la construction d'une infrastructure à clé publique (PKI) afin d'éliminer les inconvénients existants en utilisant la technologie du registre distribué (blockchain).
Commençons par les bases.

Si vous connaissez déjà les bases de l'infrastructure à clé publique existante et ses principaux inconvénients, n'hésitez pas à faire défiler la description de ce que nous proposons de modifier.





Alors, comment fonctionnera une infrastructure à clé publique décentralisée dans la pratique? Plongeons-nous dans la technologie que nous avons brevetée en 2018 et considérons notre meilleur savoir-faire.

Supposons qu'un individu possède un ensemble de clés publiques, où chaque clé est une sorte de transaction stockée dans un registre. Comment vérifier que toutes ces clés appartiennent réellement à un propriétaire donné sans CA? Pour résoudre cette tâche, nous pouvons créer une transaction nulle pour stocker les informations sur le propriétaire et son portefeuille électronique (à partir desquels des frais de commission pour l'ajout d'une transaction au grand livre sont débités). Une transaction nulle est une sorte d '"ancre" pour connecter les prochaines transactions avec les données sur les clés publiques. Chaque transaction de ce type contient une structure de données spécialisée appelée "notification".

La notification est un ensemble de données structurées de champs fonctionnels qui stocke des informations sur la clé publique du propriétaire et garantit la persistance de cette clé en l'ajoutant à l'un des enregistrements associés dans le grand livre distribué.

La prochaine question évidente est de savoir comment former une transaction nulle? Une transaction nulle, comme toutes les transactions ultérieures, est une agrégation de six champs de données. Pour former une transaction nulle, nous utilisons la paire de clés publique / privée pour le portefeuille électronique. Cette paire de clés publique / privée est créée lorsque l'utilisateur crée son portefeuille à partir duquel les frais de commission pour l'ajout d'une transaction nulle au grand livre et pour les opérations ultérieures avec notifications seront débités.


Figure 3. Création d'une transaction nulle

La figure 3 montre comment un résumé de la clé publique du portefeuille électronique est formé à l'aide de la fonction de hachage SHA256, puis de la fonction de hachage RIPEMD160. Ici, RIPEMD160 est responsable de la représentation des données avec la taille de résumé jusqu'à 160 bits. C'est très important, car les registres sont des bases de données coûteuses. La clé publique elle-même est incluse dans le cinquième champ. Le premier champ contient des données qui lient une transaction donnée à la précédente. Dans la transaction nulle, contrairement à toutes les autres transactions, ce champ est vide. Le deuxième champ contient des données pour la vérification de la connectivité des transactions. Par souci de concision, nous désignerons respectivement les données des premier et deuxième champs par "liaison" et "vérification".


Figure 4. Liaison et vérification des transactions

Les données dans ces champs peuvent être formées à l'aide du hachage itératif comme illustré dans la figure 4 ci-dessus pour lier les deuxième et troisième transactions.
Les données des cinq premiers champs sont authentifiées avec le DS généré à l'aide de la clé privée du portefeuille électronique. Et c'est tout - la transaction peut maintenant être ajoutée au pool puis, après une vérification réussie (comme le montre la figure 5 ), au grand livre.


Figure 5. Vérification de la transaction nulle

Cette transaction peut maintenant être utilisée pour "connecter" les prochaines transactions. Jetons un coup d'œil à la figure 6 pour voir comment toutes les transactions non nulles sont formées.


Figure 6. Création d'une transaction non nulle

La première chose que vous remarquerez peut-être est une multitude de paires de clés publiques / privées. En plus de la paire de clés publique / privée de portefeuille électronique déjà familière, nous utilisons également des paires de clés ordinaires et de service.

Une clé publique ordinaire est la partie la plus importante ici. Cette clé est utilisée dans diverses procédures et processus du monde environnant (comme les transactions bancaires et autres, le flux de documents, etc.). Par exemple, une clé privée à partir d'une paire de clés publique / privée ordinaire peut être utilisée pour la création d'un DS pour divers documents, tels que les ordres de paiement, tandis que la clé publique peut être utilisée pour la vérification du DS avec exécution ultérieure de ceux-ci. commandes.

Une paire de clés publique / privée de service est délivrée à une entité DPKI enregistrée. Le nom de cette paire de clés publique / privée reflète clairement son objectif. Notez que les clés de service ne sont pas utilisées pour la génération / vérification d'une transaction nulle.

Juste pour être clair, affinons les objectifs de ces clés:

1. Les clés de portefeuille électronique sont utilisées pour la génération et / ou la vérification des transactions nulles et non nulles. La clé privée du portefeuille électronique n'est connue que du propriétaire du portefeuille électronique qui possède également l'ensemble des clés publiques ordinaires.
2. Le but d'une clé publique ordinaire est le même que celui de la clé publique pour laquelle un certificat est émis dans l'ICP centralisée.
3. La paire de clés publique / privée de service appartient au DPKI. Une clé privée est émise pour les entités enregistrées et est utilisée pour créer un DS de toutes les transactions non nulles. Une clé publique est utilisée pour la vérification d'un DS pour les transactions avant de les ajouter au grand livre.

Ainsi, nous avons deux groupes de clés. Le premier groupe comprend les clés de service et les clés de portefeuille électronique qui ne sont éligibles que dans le DPKI. Le deuxième groupe comprend des clés ordinaires qui peuvent être utilisées à diverses fins en fonction d'un domaine d'application donné. Dans le même temps, le DPKI garantit l'intégrité et l'authenticité des clés publiques ordinaires.

Remarque: La paire de clés publique / privée de service peut être divulguée à diverses entités DPKI. Dans certains cas, la paire peut être la même pour toutes les entités. C'est pourquoi la formation d'une signature pour chaque transaction non nulle nécessite deux clés privées, dont l'une est la clé du portefeuille électronique: cette clé n'est connue que du propriétaire du portefeuille électronique qui possède également l'ensemble des clés publiques ordinaires. Toutes ces clés ont certaines fonctions. Par exemple, nous pouvons toujours prouver qu'une transaction donnée a été incluse dans le grand livre par une entité DPKI enregistrée, car la signature a également été formée à l'aide d'une clé privée de service. De plus, cela empêche toute attaque DOS et autres activités frauduleuses, car le propriétaire paie pour chaque transaction.

Toutes les transactions qui suivent une transaction nulle sont formées de la même manière: une clé publique (à partir d'une paire de clés ordinaire, pas la clé du portefeuille électronique comme pour les transactions nulles) est traitée à l'aide de deux fonctions de hachage: SHA256 et RIPEMD160. C'est ainsi que les données du troisième champ sont formées. Le quatrième champ contient des informations supplémentaires (par exemple des informations sur l'état actuel, la période de validité, l'horodatage, les identifiants des algorithmes cryptographiques, etc.). Le cinquième champ contient une clé publique de la paire de clés publique / privée de service. Cette clé est répliquée, car elle sera utilisée pour la vérification d'un DS. Prouvons qu'une telle approche est nécessaire.

Chaque transaction est incluse dans le pool et y est stockée jusqu'à son traitement. Cependant, conserver les transactions dans le pool est risqué, car les données de transaction peuvent être falsifiées. Le propriétaire authentifie les données de transaction à l'aide d'un DS. La clé publique pour la vérification de ce DS est explicitement spécifiée dans l'un des champs de transaction, puis incluse dans le grand livre. Les transactions sont traitées d'une manière qui permet éventuellement à un attaquant de modifier les données à sa discrétion, de les vérifier avec sa propre clé privée, puis de spécifier la clé publique correspondante pour la vérification de DS directement dans la transaction. Si l'authenticité et l'intégrité ne sont garanties qu'avec un DS, une telle contrefaçon peut rester inaperçue. Cependant, l'extension d'une DS avec un mécanisme supplémentaire qui assure à la fois l'archivage et la persistance des informations stockées aidera à détecter une telle contrefaçon. Tout ce que nous devons faire est d'inclure la clé publique authentique du propriétaire dans le grand livre. Voyons comment cela fonctionne.

Supposons qu'un attaquant tente de falsifier les données de transaction. En termes de clés et de DS, les options suivantes sont possibles:

1. L'attaquant place sa propre clé publique dans la transaction tout en conservant la DS du propriétaire inchangée.
2. L'attaquant forme un nouveau DS en utilisant sa propre clé privée tout en gardant inchangée la clé publique du propriétaire.
3. L'attaquant forme un nouveau DS à l'aide de sa propre clé privée et place la clé publique correspondante dans la transaction.

Il est évident que les options 1 et 2 sont inutiles, car la vérification de la DS détectera toujours une telle contrefaçon. La seule option qui a du sens est l'option 3: si l'attaquant crée un DS à l'aide de sa propre clé privée, il est alors obligé d'enregistrer la clé publique correspondante dans la transaction, et cette clé sera différente de la clé publique du propriétaire. C'est le seul moyen pour l'attaquant d'appliquer ses données falsifiées.

Supposons que le propriétaire possède une paire de clés publique / privée fixe. Supposons que les données soient authentifiées avec un DS à l'aide d'une clé privée de cette paire tandis que la clé publique est spécifiée dans la transaction. Supposons également que cette clé publique ait été incluse précédemment dans le grand livre et qu'elle ait été entièrement authentifiée. Ensuite, la contrefaçon peut être révélée par le fait que la clé publique de la transaction ne correspond pas à la clé publique du grand livre.

Résumons-le. Lors du traitement des données de la toute première transaction du propriétaire, nous devons authentifier la clé publique incluse dans le grand livre. Pour ce faire, nous pouvons lire la clé dans le registre, puis faire correspondre cette clé avec la clé publique authentique du propriétaire dans le périmètre de sécurité (zone relativement invulnérable). Si la clé placée est authentifiée et entièrement persistante, la clé de la transaction suivante peut également être facilement authentifiée en la faisant correspondre avec la clé du grand livre. En d'autres termes, la clé du grand livre est utilisée comme référence. Toutes les autres transactions du propriétaire seront traitées de la même manière.

Chaque transaction est authentifiée avec un DS, et ici nous avons besoin des deux clés privées: la clé privée du service et la clé privée du portefeuille électronique. Sur la base des deux clés privées, nous pouvons garantir le niveau de sécurité cible, car la clé privée du service peut être connue des autres utilisateurs, tandis que la clé privée du portefeuille électronique n'est connue que du propriétaire de la paire de clés ordinaire. Nous avons appelé une telle signature à deux clés une DS "consolidée".

Les transactions non nulles sont vérifiées à l'aide des deux clés publiques: la clé du portefeuille électronique et la clé de service. (Figure 7)


Figure 7. Vérification d'une transaction non nulle

Le processus de vérification comprend les deux étapes de base: la première étape comprend la vérification du résumé de la clé publique du portefeuille électronique tandis que la deuxième étape met en œuvre la vérification de la DS «consolidée» de la transaction formée à l'aide des deux clés privées (c.-à-d. la clé du portefeuille et la clé de service). Lorsque le DS est authentifié, la transaction correspondante, lors de la vérification supplémentaire, est incluse dans le grand livre.

Cependant, la question suivante se pose: comment vérifier si une transaction donnée appartient à une chaîne de transaction particulière qui commence à partir d'une transaction nulle? Pour ce faire, nous avons mis à jour le processus de vérification avec une autre étape encore: la vérification de la connectivité. Cette étape nécessitera des données des deux premiers champs que nous n'avons pas utilisés jusqu'à présent.

Supposons que nous devons vérifier si la transaction # 2 est vraiment suivie de la transaction # 3 . Pour ce faire, nous pouvons utiliser la méthode de hachage combinée pour calculer les valeurs de la fonction de hachage pour les données des troisième, quatrième et cinquième champs. Nous pouvons concaténer les données du premier champ de la transaction # 3 et la valeur de la fonction de hachage combinée précédemment calculée pour les données des troisième, quatrième et cinquième champs de la transaction # 2 . Toutes ces valeurs sont ensuite traitées à l'aide des deux fonctions de hachage: SHA256 et RIPEMD160. Si la valeur résultante correspond aux données du deuxième champ de la transaction # 2 , la vérification est réussie et la connectivité est prouvée. Ceci est illustré plus en détail dans les figures ci-dessous.




Figure 8, Figure 9. Vérification de la liaison, deuxième et troisième transactions

En général, la formation et l'inclusion d'une notification dans le grand livre ressemblent à ceci. Le workflow de formation d'une chaîne de notifications est clairement illustré dans la figure suivante:


Figure 10. Structure et traitement des transactions

Dans cet article, nous n'allons pas plonger dans les détails et revenir à la discussion du concept de l'infrastructure décentralisée pour les clés publiques.

Ainsi, puisque l'entité effectuant la demande envoie une demande d'enregistrement des notifications qui sont stockées dans le grand livre plutôt que dans une base de données CA, les principaux composants architecturaux du DPKI sont les suivants:

1. Grand livre des notifications valides (LVN)
2. Grand livre des notifications retirées (LWN)
3. Grand livre des notifications suspendues (LSN).

Les informations sur les clés publiques sont stockées dans le LVN / LWN / LSN en tant que valeurs de fonction de hachage. Notez également qu'il peut s'agir de différents livres ou de chaînes différentes ou même d'une seule chaîne dans le cadre d'un seul livre, lorsque des informations sur le statut d'une clé publique ordinaire (retrait, suspension, etc.) sont ajoutées au quatrième champ du structure de données comme valeur de code correspondante. Il existe de nombreuses options pour la mise en œuvre architecturale du DPKI en fonction de divers critères d'optimisation, tels que les coûts de stockage à long terme des clés publiques en mémoire, etc.

Ainsi, le DPKI peut devenir d'une complexité architecturale identique ou même inférieure par rapport à une solution centralisée.

Donc, la question principale ici est de savoir quel livre est le plus approprié pour mettre en œuvre cette technologie?

La principale exigence du grand livre est de pouvoir conclure des transactions de tout type. L'exemple le plus connu d'un vrai grand livre est le Bitcoin. Cependant, la mise en œuvre de la technologie ci-dessus pour Bitcoin peut rencontrer certaines difficultés: limitations du langage de script existant, manque de mécanismes nécessaires pour traiter des ensembles de données arbitraires et des méthodes pour générer des transactions de types arbitraires, etc.

Chez ENCRY, nous avons essayé de résoudre les problèmes ci-dessus et développé un registre qui, à notre avis, présente plusieurs avantages importants:

• Prise en charge de plusieurs types de transactions: dans ce registre, vous pouvez à la fois échanger des actifs (c'est-à-dire effectuer des transactions financières) et former des transactions d'une structure arbitraire
• Les développeurs sont invités à utiliser le langage de programmation propriétaire PrismLang qui est très flexible pour résoudre divers problèmes technologiques
• Le mécanisme mis en œuvre pour le traitement d'ensembles de données arbitraires.

Autrement dit, les étapes suivantes doivent être suivies:

1. Une entité effectuant la demande s'inscrit dans le DPKI et obtient un portefeuille électronique. L'adresse du portefeuille électronique est une valeur de la fonction de hachage appliquée à la clé publique du portefeuille électronique. La clé privée du portefeuille électronique n'est connue que de l'entité qui fait la demande
2. Lors de l'inscription, l'entité obtient l'accès à la clé privée du service
3. L'entité forme une transaction nulle puis authentifie son DS à l'aide de la clé privée du portefeuille électronique
4. Lors de la formation d'une transaction non nulle, l'entité doit authentifier son DS à l'aide de deux clés privées: la clé du portefeuille électronique et la clé de service
5. L'entité envoie la transaction au pool
6. Le nœud du réseau ENCRY lit la transaction dans le pool, puis vérifie le DS et la connectivité de la transaction
7. Si le DS est valide et que la connectivité est prouvée, le nœud préparera la transaction pour l'ajouter au grand livre.

Ici, le registre sert de base de données distribuée qui stocke des informations sur les notifications valides, retirées et suspendues.

Certes, la décentralisation n'est pas une solution universelle. Le problème principal avec l'authentification de l'utilisateur principal persiste: alors que l'entité qui fait la demande est actuellement vérifiée par l'AC, le DPKI propose de déléguer cette vérification aux membres de la communauté et de les motiver financièrement. La technologie de vérification basée sur des sources publiques est connue. L'efficacité d'une telle vérification a également été prouvée dans la pratique: plusieurs enquêtes de haut niveau menées par Bellingcat en sont de bons exemples.

Mais en général, nous sommes tout à fait sûrs que le DPKI est capable d'éliminer de nombreux, sinon tous, les inconvénients d'une PKI centralisée.

N'hésitez pas à vous abonner à notre blog sur Habr , où nous allons discuter de nos recherches et développements ultérieurs, et suivez notre Twitter pour rester à l'écoute pour plus de nouvelles sur les projets ENCRY.