DPKI: remédier aux inconvénients de l'ICP centralisée avec la blockchain

Ce n'est un secret pour personne que l'un des outils auxiliaires courants, sans lequel la protection des données dans les réseaux ouverts est impossible, est la technologie des certificats numériques. Cependant, ce n'est pas un secret que le principal inconvénient de cette technologie est la confiance inconditionnelle dans les centres délivrant des certificats numériques. Andrey Chmora, directeur de la technologie et de l'innovation chez ENCRY, a proposé une nouvelle approche pour organiser l'infrastructure à clé publique ( PKI ), qui aidera à éliminer les lacunes actuelles et qui utilise la technologie de registre distribué (blockchain). Mais tout d'abord.

Si vous connaissez les principes de fonctionnement de l'infrastructure existante des clés publiques et que vous connaissez ses principales lacunes, vous pouvez immédiatement passer à la description de ce que nous proposons de changer.





Alors, comment fonctionnera une infrastructure à clé publique décentralisée dans la pratique? Arrêtons-nous sur la description de la technologie elle-même, que nous avons brevetée en 2018 et considérons à juste titre notre savoir-faire.

Imaginez qu'il y ait un propriétaire qui possède beaucoup de clés publiques, où chaque clé est une certaine transaction qui est stockée dans le registre. Comment en l'absence d'une autorité de certification comprendre que toutes les clés appartiennent à ce propriétaire particulier? Pour résoudre ce problème, une transaction zéro est créée, qui contient des informations sur le propriétaire et son portefeuille (à partir desquelles la commission pour placer la transaction dans le registre est débitée). Une transaction zéro est une sorte d '«ancre» à laquelle seront attachées les transactions suivantes avec des données sur les clés publiques. Chacune de ces transactions contient une structure de données spécialisée, ou d'une autre manière - une notification.

La notification est un ensemble de données structuré composé de champs fonctionnels et comprenant des informations sur la clé publique du propriétaire, dont la persistance est garantie par le placement dans l'une des entrées associées du registre distribué.

La prochaine question logique est de savoir comment se forme une transaction zéro? Une transaction nulle - comme les suivantes - est une agrégation de six champs de données. Lors de la formation d'une transaction nulle, une paire de clés du portefeuille (clés publiques et clés secrètes) est impliquée. Cette paire de clés apparaît au moment où l'utilisateur enregistre son portefeuille, à partir duquel la commission de publication d'une transaction nulle dans le registre et - par la suite - les opérations avec notifications seront débitées.



Comme le montre la figure, le résumé de la clé du portefeuille public est généré en appliquant successivement les fonctions de hachage SHA256 et RIPEMD160. Ici, RIPEMD160 est responsable de la présentation compacte des données dont la capacité en bits ne dépasse pas 160 bits. C'est important - car le registre n'est pas une base de données bon marché. La clé publique elle-même est entrée dans le cinquième champ. Le premier champ contient des données qui établissent une connexion avec la transaction précédente. Pour une transaction zéro, ce champ ne contient rien, ce qui le distingue des transactions suivantes. Le deuxième champ correspond aux données permettant de vérifier la connectivité des transactions. Par souci de concision, nous appellerons respectivement les données des premier et deuxième champs «bundle» et «check». Le contenu de ces champs est généré par la méthode de hachage itérative comme le montre l'exemple de liaison des deuxième et troisième transactions dans la figure ci-dessous.



Les données des cinq premiers champs sont certifiées par une signature numérique électronique, qui est générée à l'aide de la clé secrète du portefeuille.

Tout, la transaction zéro est envoyée au pool et après une vérification réussie (comme illustré dans la figure ci-dessous) est entrée dans le registre.



Vous pouvez désormais y «lier» les transactions suivantes. Considérez comment la formation de transactions autres que zéro se produit.



La première chose qui vous a probablement frappé a été l'abondance de paires de clés. En plus de la paire de clés du portefeuille déjà familière, des paires de clés ordinaires et officielles sont utilisées.

Une clé publique ordinaire est celle pour laquelle tout, en fait, a été démarré. Cette clé est impliquée dans diverses procédures et processus se déroulant dans le monde environnant (transactions bancaires et autres, flux de documents, etc.). Par exemple, une clé secrète d'une paire ordinaire peut être utilisée pour générer des signatures numériques de divers documents - ordres de paiement, etc., et une publique - pour vérifier cette signature numérique avec l'exécution ultérieure de ces ordres, sous réserve de sa validité.

Un couple d'entreprises est délivré à une entité DPKI enregistrée. Le nom de cette paire correspond à son objectif. Notez que lors de la génération / vérification d'une transaction nulle, les clés de service ne sont pas utilisées.

Encore une fois, nous clarifierons le but des clés:

1. Les clés de portefeuille sont utilisées pour générer / vérifier à la fois un zéro et toute autre transaction non nulle. La clé secrète du portefeuille n'est connue que du propriétaire du portefeuille, qui est en même temps propriétaire de nombreuses clés publiques ordinaires.
2. Une clé publique unique a un objectif similaire à une clé publique pour laquelle un certificat est émis dans une infrastructure à clé publique centralisée.
3. La paire de clés de service appartient à DPKI. La clé secrète est délivrée aux entités enregistrées et est utilisée dans la formation de transactions électroniques numériques (à l'exception de zéro). Public est utilisé pour vérifier la signature numérique d'une transaction avant qu'elle ne soit placée dans le registre.

Ainsi, il existe deux groupes de clés. Le premier comprend les clés de service et les clés de portefeuille - elles n'ont de sens que dans le contexte de DPKI. Le deuxième groupe comprend les clés ordinaires - leur portée peut varier et est due aux applications dans lesquelles elles sont utilisées. Dans le même temps, DPKI garantit l'intégrité et l'authenticité des clés publiques ordinaires.

Remarque: Une paire de clés de service peut être connue de diverses entités DPKI. Par exemple, cela peut être le même pour tout le monde. Pour cette raison, lors de la génération de la signature de chaque transaction non nulle, deux clés secrètes sont utilisées, dont l'une est la clé du portefeuille - elle n'est connue que du propriétaire du portefeuille, qui est également le propriétaire de nombreuses clés publiques ordinaires. Toutes les clés ont leur propre signification. Par exemple, vous pouvez toujours prouver qu'une transaction a été entrée dans le registre par une entité DPKI enregistrée, car la signature a été générée, y compris à l'aide d'une clé de service secrète. Et il ne peut y avoir d'abus, comme une attaque DOS, car le propriétaire paie pour chaque transaction.

Toutes les transactions qui suivent le zéro sont générées de la même manière: une clé publique (mais pas un portefeuille, comme dans le cas d'une transaction zéro, mais à partir d'une paire de clés ordinaire) est exécutée via deux fonctions de hachage SHA256 et RIPEMD160. Ainsi, les données du troisième champ sont formées. Les informations d'accompagnement sont saisies dans le quatrième champ (par exemple, des informations sur l'état actuel, la période de validité, l'horodatage, les identifiants des algorithmes cryptographiques utilisés, etc.). Dans le cinquième champ, la clé publique de la paire de clés de service. Avec son aide, l'EDS sera vérifié, il est donc répliqué. Nous justifions la nécessité d'une telle approche.

Rappelez-vous qu'une transaction est entrée dans le pool et y est stockée jusqu'à ce qu'elle soit traitée. Le stockage dans le pool est associé à un certain risque - ces transactions peuvent être falsifiées. Le propriétaire certifie les données de la transaction de signature numérique. La clé publique de vérification de cette signature numérique est indiquée dans l'un des champs de transaction sous une forme explicite et est ensuite entrée dans le registre. , , . , . , , , . . , .

. :

1. .
2. , .
3. .

, 1 2 , . 3, , , . .

, — . , . , . , .

. . ( ). , / . , . .

— - , , — . — , . “” .

, , : . : — , — , , , ( ). , .



: “” ? — . - , .

, , №3 №2. - , №2. №3 - , №2. - SHA256 RIPEMD160. №2, . .




. :



, , , , .

, , , , DPKI :

1. ().
2. ().
3. ().

// -. , , , (, .) . DPKI , , , .

, DPKI , .

— ?

— . — . : , , , .

ENCRY , , , , :

• : ( ), ,
• PrismLang, ,
• .

, :

1. DPKI . — - . .
2. .
3. .
4. , : .
5. .
6. ENCRY , .
7. , .

, , .

, . : , DPKI , . . . - Bellingcat.

: DPKI — , , PKI.

, , , ENCRY.