DPKI : éliminer les défauts de la PKI centralisée grâce à la blockchain

Ce n'est un secret pour personne : l'un des outils auxiliaires couramment utilisés, sans lesquels la protection des données dans les réseaux ouverts est impossible, est la technologie des certificats numériques. Cependant, ce n’est un secret pour personne que le principal inconvénient de la technologie est la confiance inconditionnelle dans les centres qui délivrent les certificats numériques. Le directeur de la technologie et de l'innovation d'ENCRY Andrey Chmora a proposé une nouvelle approche d'organisation infrastructure à clé publique (Infrastructure à clé publique, PKI), qui contribuera à éliminer les lacunes actuelles et qui utilise la technologie du grand livre distribué (blockchain). Mais tout d’abord.

Si vous connaissez le fonctionnement de votre infrastructure à clé publique actuelle et connaissez ses principales lacunes, vous pouvez passer directement à ce que nous proposons de modifier ci-dessous.

Que sont les signatures numériques et les certificats ?L'interaction sur Internet implique toujours le transfert de données. Nous avons tous intérêt à garantir que les données sont transmises en toute sécurité. Mais qu’est-ce que la sécurité ? Les services de sécurité les plus recherchés sont la confidentialité, l’intégrité et l’authenticité. A cet effet, on utilise actuellement des méthodes de cryptographie asymétrique, ou cryptographie à clé publique.

Commençons par le fait que pour utiliser ces méthodes, les sujets d'interaction doivent disposer de deux clés individuelles appariées - publique et secrète. Avec leur aide, les services de sécurité que nous avons mentionnés ci-dessus sont fournis.

Comment la confidentialité du transfert d’informations est-elle assurée ? Avant d'envoyer des données, l'abonné expéditeur crypte (transforme cryptographiquement) les données ouvertes à l'aide de la clé publique du destinataire, et le destinataire déchiffre le texte chiffré reçu à l'aide de la clé secrète appariée.

Comment l’intégrité et l’authenticité des informations transmises sont-elles assurées ? Pour résoudre ce problème, un autre mécanisme a été créé. Les données ouvertes ne sont pas cryptées, mais le résultat de l'application de la fonction de hachage cryptographique - une image « compressée » de la séquence de données d'entrée - est transmis sous forme cryptée. Le résultat d'un tel hachage est appelé « résumé », et il est crypté à l'aide de la clé secrète de l'abonné expéditeur (« le témoin »). Suite au cryptage du résumé, une signature numérique est obtenue. Celui-ci, accompagné du texte en clair, est transmis à l'abonné destinataire (« vérificateur »). Il déchiffre la signature numérique de la clé publique du témoin et la compare avec le résultat de l’application d’une fonction de hachage cryptographique, que le vérificateur calcule indépendamment sur la base des données ouvertes reçues. S'ils correspondent, cela indique que les données ont été transmises sous une forme authentique et complète par l'abonné expéditeur, et non modifiées par un attaquant.

La plupart des ressources qui travaillent avec des données personnelles et des informations de paiement (banques, compagnies d'assurance, compagnies aériennes, systèmes de paiement, ainsi que portails gouvernementaux tels que le service des impôts) utilisent activement des méthodes de cryptographie asymétrique.

Qu’est-ce qu’un certificat numérique a à voir là-dedans ? C'est simple. Tant le premier que le deuxième processus impliquent des clés publiques, et comme elles jouent un rôle central, il est très important de s'assurer que les clés appartiennent effectivement à l'expéditeur (le témoin, dans le cas de la vérification de signature) ou au destinataire, et ne sont pas remplacé par les clés des attaquants. C'est pourquoi des certificats numériques existent pour garantir l'authenticité et l'intégrité de la clé publique.

Remarque : l'authenticité et l'intégrité de la clé publique sont confirmées exactement de la même manière que l'authenticité et l'intégrité des données publiques, c'est-à-dire à l'aide d'une signature numérique électronique (EDS).
D'où viennent les certificats numériques ?Les autorités de certification de confiance, ou autorités de certification (CA), sont responsables de la délivrance et de la maintenance des certificats numériques. Le demandeur demande la délivrance d'un certificat à l'AC, se soumet à une identification au Centre d'Enregistrement (CR) et reçoit un certificat de l'AC. L'AC garantit que la clé publique du certificat appartient exactement à l'entité pour laquelle elle a été émise.

Si vous ne confirmez pas l'authenticité de la clé publique, alors un attaquant lors du transfert/stockage de cette clé peut la remplacer par la sienne. Si la substitution a eu lieu, l'attaquant pourra décrypter tout ce que l'abonné expéditeur transmet à l'abonné destinataire, ou modifier les données ouvertes à sa propre discrétion.

Les certificats numériques sont utilisés partout où la cryptographie asymétrique est disponible. L'un des certificats numériques les plus courants est le certificat SSL pour une communication sécurisée via le protocole HTTPS. Des centaines d'entreprises enregistrées dans diverses juridictions sont impliquées dans la délivrance de certificats SSL. La part principale revient à cinq à dix grands centres de confiance : IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA et CR sont des composants de PKI, qui comprennent également :

• Ouvrir le répertoire – une base de données publique qui permet un stockage sécurisé des certificats numériques.
• Liste des certificats révoqués – une base de données publique qui assure le stockage sécurisé des certificats numériques des clés publiques révoquées (par exemple, en raison de la compromission d'une clé privée appariée). Les sujets d'infrastructure peuvent accéder indépendamment à cette base de données ou utiliser le protocole spécialisé OCSP (Online Certification Status Protocol), qui simplifie le processus de vérification.
• Utilisateurs de certificats – les sujets PKI desservis qui ont conclu un accord d'utilisation avec l'AC et vérifient la signature numérique et/ou chiffrent les données sur la base de la clé publique du certificat.
• Suiveurs – servis aux sujets PKI qui possèdent une clé secrète couplée à la clé publique du certificat, et qui ont conclu un contrat d'abonnement avec l'AC. L'abonné peut être simultanément utilisateur du certificat.

Ainsi, les entités de confiance de l'infrastructure à clé publique, qui comprennent les AC, les CR et les annuaires ouverts, sont responsables de :

1. Vérification de l’authenticité de l’identité du demandeur.
2. Profilage du certificat de clé publique.
3. Délivrance d'un certificat de clé publique pour un demandeur dont l'identité a été confirmée de manière fiable.
4. Modifiez le statut du certificat de clé publique.
5. Fournir des informations sur l'état actuel du certificat de clé publique.

Inconvénients de la PKI, quels sont-ils ?Le défaut fondamental de la PKI est la présence d’entités de confiance.
Les utilisateurs doivent faire confiance inconditionnellement au CA et au CR. Mais, comme le montre la pratique, la confiance inconditionnelle est lourde de conséquences.

Au cours des dix dernières années, plusieurs scandales majeurs ont eu lieu dans ce domaine liés à la vulnérabilité des infrastructures.

— en 2010, le malware Stuxnet a commencé à se propager en ligne, signé à l'aide de certificats numériques volés à RealTek et JMicron.

- En 2017, Google accusait Symantec d'émettre un grand nombre de certificats falsifiés. À cette époque, Symantec était l'une des plus grandes AC en termes de volumes de production. Dans le navigateur Google Chrome 70, la prise en charge des certificats émis par cette société et ses centres affiliés GeoTrust et Thawte a été arrêtée avant le 1er décembre 2017.

Les autorités de certification ont été compromises et, par conséquent, tout le monde a souffert : les autorités de certification elles-mêmes, ainsi que les utilisateurs et les abonnés. La confiance dans les infrastructures a été ébranlée. De plus, les certificats numériques peuvent être bloqués dans le cadre de conflits politiques, ce qui affectera également le fonctionnement de nombreuses ressources. C'est précisément ce qui était redouté il y a plusieurs années au sein de l'administration présidentielle russe, où l'on a discuté en 2016 de la possibilité de créer un centre de certification d'État qui délivrerait des certificats SSL aux sites de RuNet. La situation actuelle est telle que même les portails d'État en Russie utiliser certificats numériques émis par les sociétés américaines Comodo ou Thawte (filiale de Symantec).

Il y a un autre problème - la question authentification primaire (authentification) des utilisateurs. Comment identifier un utilisateur qui a contacté l'AC pour une demande d'émission d'un certificat numérique sans contact personnel direct ? Désormais, ce problème est résolu de manière situationnelle, en fonction des capacités de l'infrastructure. Quelque chose est extrait des registres ouverts (par exemple, des informations sur les personnes morales demandant des certificats) ; dans les cas où les demandeurs sont des particuliers, on peut utiliser des bureaux de banque ou de poste, où leur identité est confirmée à l'aide de documents d'identification, par exemple un passeport.

Le problème de la falsification des informations d’identification à des fins d’usurpation d’identité est fondamental. Notons qu'il n'existe pas de solution complète à ce problème pour des raisons de théorie de l'information : sans disposer d'informations fiables a priori, il est impossible de confirmer ou d'infirmer l'authenticité d'un sujet particulier. En règle générale, pour vérification, il est nécessaire de présenter un ensemble de documents prouvant l'identité du demandeur. Il existe de nombreuses méthodes de vérification différentes, mais aucune d’entre elles ne garantit pleinement l’authenticité des documents. Par conséquent, l’authenticité de l’identité du demandeur ne peut pas non plus être garantie.

Comment remédier à ces lacunes ?Si les problèmes de l'ICP dans son état actuel peuvent s'expliquer par la centralisation, alors il est logique de supposer que la décentralisation contribuerait à éliminer partiellement les lacunes identifiées.

La décentralisation n'implique pas la présence d'entités de confiance - si vous créez infrastructure à clé publique décentralisée (Infrastructure à clé publique décentralisée, DPKI), alors ni CA ni CR ne sont nécessaires. Abandonnons le concept de certificat numérique et utilisons un registre distribué pour stocker des informations sur les clés publiques. Dans notre cas, nous appelons registre une base de données linéaire composée d’enregistrements individuels (blocs) liés à l’aide de la technologie blockchain. Au lieu d'un certificat numérique, nous introduirons la notion de « notification ».

À quoi ressemblera le processus de réception, de vérification et d'annulation des notifications dans le DPKI proposé :

1. Chaque demandeur soumet indépendamment une demande de notification en remplissant un formulaire lors de l'inscription, après quoi il crée une transaction qui est stockée dans un pool spécialisé.

2. Les informations sur la clé publique, ainsi que les détails du propriétaire et d'autres métadonnées, sont stockées dans un registre distribué, et non dans un certificat numérique, dont l'émission dans une PKI centralisée relève de l'autorité de certification.

3. La vérification de l'authenticité de l'identité du demandeur est effectuée après coup grâce aux efforts conjoints de la communauté des utilisateurs de la DPKI, et non par le CR.

4. Seul le propriétaire d'une telle notification peut modifier le statut d'une clé publique.

5. N'importe qui peut accéder au grand livre distribué et vérifier l'état actuel de la clé publique.

Remarque : La vérification communautaire de l'identité d'un demandeur peut sembler peu fiable à première vue. Mais nous ne devons pas oublier qu’aujourd’hui, tous les utilisateurs de services numériques laissent inévitablement une empreinte numérique, et ce processus ne fera que s’accentuer. Registres électroniques ouverts des personnes morales, cartes, numérisation d'images de terrain, réseaux sociaux, autant d'outils accessibles au public. Ils sont déjà utilisés avec succès lors d’enquêtes menées aussi bien par des journalistes que par les forces de l’ordre. Par exemple, il suffit de rappeler les enquêtes de Bellingcat ou de l'équipe d'enquête commune JIT, qui étudie les circonstances du crash du Boeing malaisien.

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

Imaginez qu'un propriétaire possède de nombreuses clés publiques, où chaque clé correspond à une certaine transaction stockée dans le registre. En l’absence d’AC, comment 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 desquels est débitée la commission de placement de la transaction dans le registre). La transaction nulle 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 en d'autres termes, une notification.

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

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

Comme le montre la figure, un résumé de clé publique de portefeuille est généré en appliquant séquentiellement les fonctions de hachage SHA256 et RIPEMD160. Ici, RIPEMD160 est responsable de la représentation compacte des données dont la largeur ne dépasse pas 160 bits. Ceci est important car le registre n’est pas une base de données bon marché. La clé publique elle-même est saisie dans le cinquième champ. Le premier champ contient des données qui établissent une connexion à la transaction précédente. Pour une transaction nulle, ce champ ne contient rien, ce qui le distingue des transactions ultérieures. Le deuxième champ concerne les 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 « lien » et « chèque ». Le contenu de ces champs est généré par hachage itératif, comme le démontre la 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 électronique générée à l’aide de la clé secrète du portefeuille.

Voilà, la transaction nulle est envoyée au pool et après vérification réussie, elle est inscrite dans le registre. Vous pouvez désormais y « lier » les transactions suivantes. Considérons comment se forment les transactions autres que zéro.

La première chose qui a probablement attiré votre attention est l’abondance des paires de clés. En plus de la paire de clés de portefeuille déjà familière, des paires de clés ordinaires et de service sont utilisées.

Une clé publique ordinaire est la raison pour laquelle tout a commencé. Cette clé est impliquée dans diverses procédures et processus se déroulant dans le monde extérieur (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 pour divers documents - ordres de paiement, etc., et une clé publique peut être utilisée pour vérifier cette signature numérique avec l'exécution ultérieure de ces instructions, à condition qu'elle est valable.

La paire de services est délivrée au sujet DPKI enregistré. Le nom de cette paire correspond à son objectif. Notez que lors de la formation/vérification d’une transaction nulle, les clés de service ne sont pas utilisées.

Clarifions à nouveau le but des clés :

1. Les clés de portefeuille sont utilisées pour générer/vérifier à la fois une transaction nulle et toute autre transaction non nulle. La clé privée d’un portefeuille n’est connue que du propriétaire du portefeuille, qui est également propriétaire de nombreuses clés publiques ordinaires.
2. Une clé publique ordinaire a un objectif similaire à une clé publique pour laquelle un certificat est émis dans une PKI 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 lors de la génération de signatures numériques pour les transactions (sauf pour zéro transaction). Public est utilisé pour vérifier la signature numérique électronique d'une transaction avant qu'elle ne soit publiée dans le registre.

Il existe donc 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 du DPKI. Le deuxième groupe comprend les clés ordinaires - leur portée peut varier et est déterminée par les tâches d'application 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 : La paire de clés de service peut être connue de différentes entités DPKI. Par exemple, cela peut être pareil pour tout le monde. C'est pour cette raison que 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 propriétaire de nombreux clés publiques. Toutes les clés ont leur propre signification. Par exemple, il est toujours possible de prouver que la transaction a été inscrite dans le registre par un sujet DPKI enregistré, puisque la signature a également été générée sur une clé des services secrets. Et il ne peut y avoir d'abus, comme les attaques DOS, car le propriétaire paie pour chaque transaction.

Toutes les transactions qui suivent le zéro sont formées de la même manière : la clé publique (pas le portefeuille, comme dans le cas de la transaction zéro, mais à partir d'une paire de clés ordinaire) est exécutée via deux fonctions de hachage SHA256 et RIPEMD160. C'est ainsi que sont formées les données du troisième champ. Le quatrième champ contient des informations d'accompagnement (par exemple, des informations sur l'état actuel, les dates d'expiration, l'horodatage, les identifiants des crypto-algorithmes utilisés, etc.). Le cinquième champ contient la clé publique de la paire de clés de service. Avec son aide, la signature numérique sera ensuite vérifiée et donc répliquée. Justifions la nécessité d'une telle approche.

Rappelons qu'une transaction est saisie dans un pool et y est stockée jusqu'à son traitement. Le stockage dans un pool est associé à un certain risque : les données de transaction peuvent être falsifiées. Le propriétaire certifie les données de la transaction avec une signature numérique électronique. La clé publique permettant de vérifier cette signature numérique est indiquée explicitement dans l'un des champs de transaction et est ensuite inscrite dans le registre. Les particularités du traitement des transactions sont telles qu'un attaquant est capable de modifier les données à sa discrétion, puis de les vérifier à l'aide de sa clé secrète, et d'indiquer une clé publique couplée pour vérifier la signature numérique dans la transaction. Si l’authenticité et l’intégrité sont assurées exclusivement par la signature numérique, alors une telle contrefaçon passera inaperçue. Cependant, si, en plus de la signature numérique, il existe un mécanisme supplémentaire qui assure à la fois l'archivage et la persistance des informations stockées, alors la contrefaçon peut être détectée. Pour ce faire, il suffit de saisir dans le registre la véritable clé publique du propriétaire. Expliquons comment cela fonctionne.

Laissez l’attaquant falsifier les données de transaction. Du point de vue des clés et des signatures numériques, les options suivantes sont possibles :

1. L’attaquant place sa clé publique dans la transaction tandis que la signature numérique du propriétaire reste inchangée.
2. L’attaquant crée une signature numérique sur sa clé privée, mais laisse inchangée la clé publique du propriétaire.
3. L'attaquant crée une signature numérique sur sa clé privée et place une clé publique couplée dans la transaction.

Évidemment, les options 1 et 2 n’ont aucun sens, puisqu’elles seront toujours détectées lors de la vérification de la signature numérique. Seule l'option 3 a du sens, et si un attaquant forme une signature numérique sur sa propre clé secrète, il est alors obligé de sauvegarder dans la transaction une clé publique appariée, différente de la clé publique du propriétaire. C'est le seul moyen pour un attaquant d'imposer des données falsifiées.

Supposons que le propriétaire dispose d’une paire de clés fixe – privée et publique. Que les données soient certifiées par signature numérique à l'aide de la clé secrète de cette paire, et la clé publique est indiquée dans la transaction. Supposons également que cette clé publique ait déjà été inscrite dans le registre et que son authenticité ait été vérifiée de manière fiable. Une contrefaçon sera alors indiquée par le fait que la clé publique de la transaction ne correspond pas à la clé publique du registre.

Pour résumer. Lors du traitement des toutes premières données de transaction du propriétaire, il est nécessaire de vérifier l'authenticité de la clé publique inscrite dans le registre. Pour ce faire, lisez la clé dans le registre et comparez-la avec la véritable clé publique du propriétaire dans le périmètre de sécurité (zone d'invulnérabilité relative). Si l'authenticité de la clé est confirmée et que sa persistance est garantie lors du placement, alors l'authenticité de la clé de la transaction ultérieure peut être facilement confirmée/réfutée en la comparant avec la clé du registre. En d’autres termes, la clé du registre est utilisée comme échantillon de référence. Toutes les autres transactions du propriétaire sont traitées de la même manière.

La transaction est certifiée par une signature numérique électronique - c'est là que des clés secrètes sont nécessaires, et non pas une, mais deux à la fois - une clé de service et une clé de portefeuille. Grâce à l'utilisation de deux clés secrètes, le niveau de sécurité nécessaire est assuré - après tout, la clé secrète du service peut être connue des autres utilisateurs, tandis que la clé secrète du portefeuille n'est connue que du propriétaire de la paire de clés ordinaire. Nous avons appelé une telle signature à deux clés une signature numérique « consolidée ».

La vérification des transactions non nulles s'effectue à l'aide de deux clés publiques : le wallet et la clé de service. Le processus de vérification peut être divisé en deux étapes principales : la première consiste à vérifier le résumé de la clé publique du portefeuille, et la seconde consiste à vérifier la signature numérique électronique de la transaction, la même consolidée qui a été formée à l'aide de deux clés secrètes ( portefeuille et service). Si la validité de la signature numérique est confirmée, après vérification supplémentaire, la transaction est inscrite au registre.

Une question logique peut se poser : comment vérifier si une transaction appartient à une chaîne spécifique avec la « racine » sous la forme d'une transaction nulle ? À cette fin, le processus de vérification est complété par une étape supplémentaire : la vérification de la connectivité. C’est là que nous aurons besoin des données des deux premiers champs, que nous avons jusqu’à présent ignorées.

Imaginons que nous devions vérifier si la transaction n°3 intervient réellement après la transaction n°2. Pour ce faire, en utilisant la méthode de hachage combinée, la valeur de la fonction de hachage est calculée pour les données des troisième, quatrième et cinquième champs de la transaction n°2. Ensuite, la concaténation des données du premier champ de la transaction n° 3 et la valeur de fonction de hachage combinée précédemment obtenue pour les données des troisième, quatrième et cinquième champs de la transaction n° 2 sont effectuées. Tout cela s'exécute également via deux fonctions de hachage SHA256 et RIPEMD160. Si la valeur reçue correspond aux données du deuxième champ de la transaction n°2, alors le contrôle est réussi et la connexion est confirmée. Cela apparaît plus clairement dans les figures ci-dessous.

D'une manière générale, la technologie permettant de générer et de saisir une notification dans le registre ressemble exactement à ceci. Une illustration visuelle du processus de formation d'une chaîne de notifications est présentée dans la figure suivante :

Dans ce texte, nous ne nous attarderons pas sur les détails, qui existent sans aucun doute, et reviendrons sur l’idée même d’une infrastructure à clé publique décentralisée.

Ainsi, puisque le demandeur soumet lui-même une demande d'enregistrement des notifications, qui ne sont pas stockées dans la base de données de l'AC, mais dans le registre, les principaux composants architecturaux du DPKI doivent être pris en compte :

1. Registre des notifications valides (RDN).
2. Registre des notifications révoquées (RON).
3. Registre des notifications suspendues (RPN).

Les informations sur les clés publiques sont stockées dans RDN/RON/RPN sous la forme de valeurs de fonction de hachage. Il convient également de noter qu'il peut s'agir soit de registres différents, soit de chaînes différentes, voire d'une seule chaîne faisant partie d'un registre unique, lorsque des informations sur l'état d'une clé publique ordinaire (révocation, suspension, etc.) sont saisies dans le quatrième champ de la structure de données sous la forme de la valeur de code correspondante. Il existe de nombreuses options différentes pour la mise en œuvre architecturale du DPKI, et le choix de l'une ou l'autre dépend d'un certain nombre de facteurs, par exemple des critères d'optimisation tels que le coût de la mémoire à long terme pour le stockage des clés publiques, etc.

Ainsi, DPKI peut s'avérer, sinon plus simple, du moins comparable à une solution centralisée en termes de complexité architecturale.

La question principale demeure - Quel registre est adapté à la mise en œuvre de la technologie ?

La principale exigence du registre est la capacité de générer des transactions de tout type. L’exemple le plus célèbre de registre est le réseau Bitcoin. Mais lors de la mise en œuvre de la technologie décrite ci-dessus, certaines difficultés surviennent : les limites du langage de script existant, le manque de mécanismes nécessaires pour traiter des ensembles de données arbitraires, des méthodes pour générer des transactions de type arbitraire, et bien plus encore.

Chez ENCRY, nous avons essayé de résoudre les problèmes formulés ci-dessus et avons développé un registre qui, à notre avis, présente un certain nombre d'avantages, à savoir :

• prend en charge plusieurs types de transactions : il peut à la fois échanger des actifs (c'est-à-dire effectuer des transactions financières) et créer des transactions avec une structure arbitraire,
• les développeurs ont accès au langage de programmation propriétaire PrismLang, qui offre la flexibilité nécessaire pour résoudre divers problèmes technologiques,
• un mécanisme de traitement d'ensembles de données arbitraires est fourni.

Si nous adoptons une approche simplifiée, alors la séquence d'actions suivante a lieu :

1. Le demandeur s'inscrit auprès du DPKI et reçoit un portefeuille numérique. L'adresse du portefeuille est la valeur de hachage de la clé publique du portefeuille. La clé privée du portefeuille n'est connue que du demandeur.
2. Le sujet enregistré a accès à la clé secrète du service.
3. Le sujet génère une transaction nulle et la vérifie avec une signature numérique en utilisant la clé secrète du portefeuille.
4. Si une transaction autre que zéro est formée, elle est certifiée par une signature numérique électronique utilisant deux clés secrètes : une portefeuille et une de service.
5. Le sujet soumet une transaction au pool.
6. Le nœud du réseau ENCRY lit la transaction dans le pool et vérifie la signature numérique, ainsi que la connectivité de la transaction.
7. Si la signature numérique est valide et la connexion est confirmée, alors il prépare la transaction pour l'inscription au registre.

Ici, le registre agit comme une base de données distribuée qui stocke des informations sur les notifications valides, annulées et suspendues.

Bien entendu, la décentralisation n’est pas une panacée. Le problème fondamental de l'authentification de l'utilisateur principal ne disparaît nulle part : si actuellement la vérification du demandeur est effectuée par le CR, alors au DPKI il est proposé de déléguer la vérification aux membres de la communauté, et d'utiliser la motivation financière pour stimuler l'activité. La technologie de vérification open source est bien connue. L'efficacité d'une telle vérification a été confirmée dans la pratique. Rappelons encore une fois un certain nombre d'enquêtes très médiatisées menées par la publication en ligne Bellingcat.

Mais d’une manière générale, le tableau suivant se dégage : la DPKI est l’occasion de corriger, sinon la totalité, de nombreuses lacunes de la PKI centralisée.

Abonnez-vous à notre Habrablog, nous prévoyons de continuer à couvrir activement notre recherche et développement, et de suivre Twitter, si vous ne voulez pas manquer d'autres actualités sur les projets ENCRY.

Source: habr.com