🌱 📥 🐓 DPKI: Beseitigung der Nachteile einer zentralisierten PKI durch Blockchain 💩 🍰 🗄️

Digitale Zertifikate sind eines der bekanntesten Hilfstools zum Schutz von Daten in öffentlichen Netzwerken. Der Hauptnachteil dieser Technologie ist jedoch auch allgemein bekannt: Benutzer sind gezwungen, Zertifizierungsstellen, die digitale Zertifikate ausstellen, implizit zu vertrauen. Andrey Chmora, Direktor für Technologie und Innovationen bei ENCRY, schlug einen neuen Ansatz für den Aufbau einer Public-Key-Infrastruktur (PKI) vor , um die bestehenden Nachteile mithilfe der Blockchain-Technologie (Distributed Ledger ) zu beseitigen.
Beginnen wir mit den Grundlagen.

Wenn Sie die Grundlagen der vorhandenen Public-Key-Infrastruktur und ihre Hauptnachteile bereits kennen, können Sie zur Beschreibung der von uns vorgeschlagenen Änderungen scrollen.

Was sind digitale Signaturen und digitale Zertifikate?

Interaktionen über das Internet beinhalten immer den Datenaustausch. Und deshalb sind wir alle daran interessiert, die Daten während eines solchen Austauschs sicher zu halten. Aber was ist Sicherheit? Die beliebtesten Sicherheitsdienste sind Vertraulichkeit, Integrität und Authentizität. Heute basieren sie auf asymmetrischer Kryptographie, die auch als Public-Key-Kryptographie bezeichnet wird.

Zuallererst erfordern diese Methoden, dass die Interaktionsentitäten zwei dedizierte Schlüsselpaare haben müssen: öffentlich und privat. Diese Schlüsselpaare bieten die oben genannten Sicherheitsmerkmale.

Aber wie erreicht man einen privaten Informationsaustausch?

Abbildung 1. Verschlüsselte Datenübertragung mithilfe einer Kryptografie mit öffentlichem Schlüssel

Vor dem Senden von Daten verschlüsselt (konvertiert der Absender die öffentlichen Daten kryptografisch) die öffentlichen Daten mit dem öffentlichen Schlüssel des Empfängers, und der Empfänger entschlüsselt die verschlüsselten Daten mit dem privaten Schlüsselpaar.

Wie kann die Integrität und Authentizität der gesendeten Informationen erreicht werden? Dieses Problem kann mit einem anderen Mechanismus gelöst werden.

Abbildung 2. Digitale Signatur / Überprüfung

Obwohl öffentliche Daten nicht verschlüsselt sind, enthalten sie einen kryptografischen Hash-Funktionswert, dh ein verschlüsseltes "komprimiertes" Bild der Eingabedatensequenz. Das Ergebnis eines solchen Hashings wird als "Digest" bezeichnet und mit dem privaten Schlüssel des Absenders ("Authentifikator") verschlüsselt. Das Ergebnis der Digest-Verschlüsselung ist eine digitale Signatur, die zusammen mit dem unverschlüsselten Text an den Empfänger ("Verifizierer") gesendet wird. Der Empfänger entschlüsselt die digitale Signatur mit dem öffentlichen Schlüssel des Authentifikators und vergleicht sie dann mit dem Wert der kryptografischen Hash-Funktion, der vom Prüfer auf der Grundlage der erhaltenen öffentlichen Daten berechnet wird. Wenn sie übereinstimmen, sind die empfangenen Daten vollständig authentisch, ganzheitlich und frei von Änderungen, die möglicherweise von Angreifern vorgenommen werden könnten.

Die meisten Ressourcen, die personenbezogene Daten und Zahlungsinformationen verarbeiten (z. B. Banken, Versicherungsunternehmen, Luftfahrtunternehmen und Zahlungssysteme sowie der Steuerdienst und andere Regierungsportale), verwenden weitgehend asymmetrische Kryptografie.

Wie können digitale Zertifikate hier helfen? Es ist ganz einfach. Beide Prozesse umfassen öffentliche Schlüssel, die eine sehr wichtige Rolle spielen. Daher müssen wir immer überprüfen, ob sie dem Absender (oder dem Authentifikator, wenn wir eine Signatur überprüfen müssen) oder dem Empfänger und nicht Angreifern gehören. Und hier können digitale Zertifikate dazu beitragen, die Authentizität und Integrität des öffentlichen Schlüssels sicherzustellen.

Hinweis: Die Authentizität und Integrität des öffentlichen Schlüssels wird genauso überprüft wie bei öffentlichen Daten, dh unter Verwendung der digitalen Signatur (DS).

Wer stellt digitale Zertifikate aus?

Digitale Zertifikate werden von vertrauenswürdigen Zertifizierungsstellen ausgestellt und verwaltet. Die Entität, die die Anforderung stellt, fordert eine Zertifizierungsstelle auf, ein Zertifikat auszustellen, registriert sich im Registration Center (RC) und erhält dann ihr Zertifikat in der Zertifizierungsstelle. Die Zertifizierungsstelle garantiert, dass der öffentliche Schlüssel aus dem Zertifikat der Entität gehört, für die er ausgestellt wurde.

Wenn Sie die Authentizität des öffentlichen Schlüssels nicht überprüfen, können Angreifer den übertragenen / gespeicherten Schlüssel durch ihren eigenen ersetzen. Sobald der Schlüssel ersetzt wurde, können Angreifer alles entschlüsseln, was der Absender an den Empfänger überträgt, oder die öffentlichen Daten nach eigenem Ermessen ändern.

Digitale Zertifikate werden immer zusammen mit asymmetrischer Kryptographie verwendet. Eines der beliebtesten digitalen Zertifikate sind SSL-Zertifikate für die sichere Kommunikation über HTTPS. SSL-Zertifikate werden von Hunderten von Unternehmen in verschiedenen Ländern ausgestellt. Der Kernmarktanteil verteilt sich auf die fünf bis zehn größten vertrauenswürdigen Zertifizierungsstellen: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom und Trustwave.

CAs und RCs sind die PKI-Komponenten, zu denen auch gehören:

Öffentliches Wörterbuch: Eine öffentliche Datenbank, die zuverlässige Speicherung für digitale Zertifikate bietet
Liste der gesperrten Zertifikate: Eine öffentliche Datenbank, die zuverlässige Speicherung für digitale Zertifikate gesperrter öffentlicher Schlüssel bietet (z. B. aufgrund kompromittierter privater Schlüssel).
Infrastrukturentitäten können selbstständig auf diese Datenbank zugreifen oder das spezielle Online Certification Status Protocol (OCSP) verwenden, das den Überprüfungsprozess vereinfacht.
Zertifikatbenutzer: PKI-Entitäten, die gemäß der Benutzervereinbarung mit der Zertifizierungsstelle bedient werden und digitale Signaturen überprüfen und / oder Daten basierend auf dem öffentlichen Schlüssel aus dem Zertifikat verschlüsseln
Abonnenten: PKI-Entitäten, die von einer Zertifizierungsstelle bedient werden, den privaten Schlüssel und den gepaarten öffentlichen Schlüssel aus dem Zertifikat besitzen und eine Abonnentenvereinbarung mit der Zertifizierungsstelle geschlossen haben. Ein Abonnent kann auch ein Benutzer des Zertifikats sein.

Daher sind vertrauenswürdige Entitäten der Public-Key-Infrastruktur, einschließlich Zertifizierungsstellen, RCs und Public Dictionaries, verantwortlich für:

Überprüfung der Entität, die die Anfrage stellt
Profilerstellung des Public-Key-Zertifikats
Ausstellung eines Public-Key-Zertifikats für eine authentifizierte Entität, die die Anforderung stellt
Änderung des Status eines Public-Key-Zertifikats
Bereitstellung der Informationen zum aktuellen Status eines Public-Key-Zertifikats.

Was sind die Nachteile von PKI?

Der grundlegende Nachteil von PKI ist die Abhängigkeit von vertrauenswürdigen Entitäten. Benutzer sind gezwungen, CAs und RCs blind zu vertrauen. Ein solches blindes Vertrauen ist jedoch gefährlich.

In den letzten zehn Jahren verursachte die Sicherheitslücke in der Infrastruktur mehrere große Skandale.

Im Jahr 2010 verbreitete sich die Malware Stuxnet, die mit gestohlenen digitalen Zertifikaten von RealTek und JMicron signiert wurde, im Internet.

Im Jahr 2017 beschuldigte Google Symantec, eine große Anzahl gefälschter Zertifikate ausgestellt zu haben. Zu diesem Zeitpunkt war Symantec nach Anzahl der ausgestellten Zertifikate eine der größten Zertifizierungsstellen. Seit der Version 70 von Google Chrome hat Google die Unterstützung für alle von diesem Unternehmen und seinen verbundenen Unternehmen GeoTrust und Thawte ausgestellten Zertifikate vor dem 1. Dezember 2017 eingestellt.

Diese Zertifizierungsstellen wurden kompromittiert, und infolgedessen waren die Zertifizierungsstellen selbst sowie Benutzer und Abonnenten betroffen. Darüber hinaus wurde das Vertrauen in die Infrastruktur beeinträchtigt. Darüber hinaus können digitale Zertifikate aufgrund politischer Konflikte verboten werden und somit viele Ressourcen beeinträchtigen. Aus diesem Grund haben die russischen Behörden 2016 die Einrichtung eines nationalen Zertifizierungszentrums für die Ausstellung von SSL-Zertifikaten für Runet-Websites in Betracht gezogen. In der gegenwärtigen Situation verwenden russische Regierungsportale digitale Zertifikate, die von den US-amerikanischen Unternehmen Comodo oder Thawte (Symantecs Tochtergesellschaft) ausgestellt wurden.

Es gibt noch ein weiteres Problem: Wie werden Benutzer zunächst authentifiziert? Wie identifiziere ich einen anonymen Benutzer, der ein digitales Zertifikat von einer Zertifizierungsstelle angefordert hat? Heutzutage wird es oft willkürlich gemacht, abhängig von den Infrastrukturfähigkeiten. Einige Informationen stammen aus öffentlichen Datenbanken (z. B. über juristische Personen, die Zertifikate anfordern) oder von Banken und Postämtern, bei denen Personen anhand ihres Personalausweises und anderer Dokumente identifiziert werden können.

Der Identitätswechsel aufgrund falscher Anmeldeinformationen ist eines der grundlegenden Probleme. Und leider kann es aufgrund informativer und theoretischer Aspekte nicht einmal eine vollständige Lösung dieses Problems geben: Ohne zuverlässige Informationen ist es unmöglich, die Authentizität einer Entität zu überprüfen. In der Regel erfordert der Überprüfungsprozess eine Reihe von Dokumenten, die die Identität der Entität belegen, die die Anforderung stellt. Obwohl es viele Überprüfungsmethoden gibt, kann keine von ihnen die Echtheit der Dokumente garantieren. Daher kann auch die Authentizität der Entität, die die Anforderung stellt, nicht sicher identifiziert werden.

Wie können diese Nachteile beseitigt werden?

Da aktuelle PKI-Probleme hauptsächlich durch Zentralisierung verursacht werden, ist es offensichtlich, dass durch Dezentralisierung zumindest einige davon beseitigt werden können.

Die Dezentralisierung ist nicht auf vertrauenswürdige Entitäten angewiesen, da durch die Erstellung der dezentralen Infrastruktur für öffentliche Schlüssel (DPKI) sowohl Zertifizierungsstellen als auch RCs unnötig werden. Lassen Sie uns das Konzept des digitalen Zertifikats ablehnen und stattdessen ein verteiltes Hauptbuch verwenden, um Informationen über öffentliche Schlüssel zu speichern. In unserem Fall ist ein Ledger eine lineare Datenbank, die aus einzelnen Datensätzen (Blöcken) besteht und mithilfe der Blockchain-Technologie verbunden ist. Ersetzen wir den Begriff "digitales Zertifikat" durch den Begriff "Benachrichtigung".

So sieht der Empfang, die Überprüfung und das Widerrufen von Benachrichtigungen im vorgeschlagenen DPKI aus:

Jedes Unternehmen, das die Anfrage stellt, beantragt eine Benachrichtigung für sich, indem es ein Registrierungsformular ausfüllt, und erstellt dann eine Transaktion, die in einem speziellen Pool gespeichert wird.
Informationen über den öffentlichen Schlüssel sowie die Details des Besitzers und andere Metadaten werden in einem verteilten Hauptbuch und nicht in einem digitalen Zertifikat gespeichert, das von der Zertifizierungsstelle in der zentralisierten PKI ausgestellt wird.
Die Entität, die die Anfrage stellt, wird dann durch die gemeinsamen Bemühungen der DPKI-Benutzergemeinschaft und nicht durch RC authentifiziert.
Nur der Eigentümer einer solchen Benachrichtigung darf den Status eines öffentlichen Schlüssels ändern.
Jeder kann auf das verteilte Hauptbuch zugreifen und den aktuellen Status des öffentlichen Schlüssels überprüfen.

Hinweis: Auf den ersten Blick kann die Authentifizierung der Entität, die die Anforderung stellt, unzuverlässig erscheinen. Es ist jedoch wichtig zu bedenken, dass heutzutage alle Benutzer digitaler Dienste einen ständig wachsenden digitalen Fußabdruck hinterlassen. Zu den öffentlich verfügbaren Tools gehören digitale Datenbanken von juristischen Personen, Karten, digitalisierte Geländebilder, soziale Medien und mehr. Sie werden bereits erfolgreich bei Ermittlungen von Journalisten und Strafverfolgungsbehörden eingesetzt. Eines der typischen Beispiele sind Bellingcat-Untersuchungen und die gemeinsame Gruppe JIT, die den Absturz des malaysischen Boeing-Flugzeugs untersucht.

Wie funktioniert eine dezentrale Infrastruktur mit öffentlichen Schlüsseln in der Praxis? Lassen Sie uns tief in die Technologie eintauchen, die wir 2018 patentiert haben, und unser bestes Know-how berücksichtigen.

Angenommen, es gibt eine Person, die einen Satz öffentlicher Schlüssel besitzt, wobei jeder Schlüssel eine Art Transaktion ist, die in einem Hauptbuch gespeichert ist. Wie kann ich überprüfen, ob alle diese Schlüssel wirklich einem bestimmten Eigentümer ohne Zertifizierungsstelle gehören? Um diese Aufgabe zu lösen, können wir eine Nulltransaktion erstellen, um die Informationen über den Eigentümer und dessen E-Wallet zu speichern (von der eine Provisionsgebühr für das Hinzufügen einer Transaktion zum Hauptbuch abgebucht wird). Eine Nulltransaktion ist eine Art "Anker" zum Anschließen der nächsten Transaktionen zusammen mit den Daten über öffentliche Schlüssel. Jede Transaktion dieses Typs enthält eine spezielle Datenstruktur, die als "Benachrichtigung" bezeichnet wird.

Die Benachrichtigung ist ein strukturierter Datensatz von Funktionsfeldern, in dem Informationen zum öffentlichen Schlüssel des Eigentümers gespeichert und die Persistenz dieses Schlüssels garantiert werden, indem er einem der zugehörigen Datensätze im verteilten Hauptbuch hinzugefügt wird.

Die nächste naheliegende Frage ist, wie man eine Nulltransaktion bildet. Eine Nulltransaktion ist wie alle nachfolgenden Transaktionen eine Aggregation von sechs Datenfeldern. Um eine Nulltransaktion zu bilden, verwenden wir das öffentliche / private Schlüsselpaar für die E-Wallet. Dieses öffentliche / private Schlüsselpaar wird erstellt, wenn der Benutzer seine Brieftasche erstellt, aus der die Provisionsgebühr für das Hinzufügen einer Nulltransaktion zum Hauptbuch und für nachfolgende Vorgänge mit Benachrichtigungen belastet wird.

Abbildung 3. Erstellen einer Nulltransaktion

Abbildung 3 zeigt, wie ein Digest des öffentlichen Schlüssels der E-Wallet mithilfe der SHA256-Hash-Funktion und anschließend der RIPEMD160-Hash-Funktion erstellt wird. Hier ist RIPEMD160 für die Darstellung von Daten mit einer Digest-Größe von bis zu 160 Bit verantwortlich. Dies ist sehr wichtig, da Ledger teure Datenbanken sind. Der öffentliche Schlüssel selbst ist im fünften Feld enthalten. Das erste Feld enthält Daten, die eine bestimmte Transaktion mit der vorherigen verknüpfen. In der Nulltransaktion ist dieses Feld im Gegensatz zu allen anderen Transaktionen leer. Das zweite Feld enthält Daten zur Überprüfung der Transaktionskonnektivität. Der Kürze halber werden wir Daten im ersten und zweiten Feld als "binden" bzw. "verifizieren" bezeichnen.

Abbildung 4. Bindung und Überprüfung von Transaktionen

Daten in diesen Feldern können durch iteratives Hashing gebildet werden, wie in Abbildung 4 oben gezeigt, um die zweite und dritte Transaktion zu binden.
Die Daten in den ersten fünf Feldern werden mit dem DS authentifiziert, der mit dem privaten Schlüssel der E-Wallet generiert wurde. Und das ist alles - die Transaktion kann jetzt zum Pool und nach erfolgreicher Überprüfung (wie in Abbildung 5 dargestellt ) zum Hauptbuch hinzugefügt werden.

Abbildung 5. Überprüfung der Nulltransaktion

Jetzt kann diese Transaktion zum "Anschließen" der nächsten Transaktionen verwendet werden. Schauen wir uns Abbildung 6 an, um zu sehen, wie alle Nicht-Null-Transaktionen gebildet werden.

Abbildung 6. Erstellen einer Nicht-Null-Transaktion

Das erste, was Sie möglicherweise bemerken, ist eine Vielzahl von öffentlichen / privaten Schlüsselpaaren. Neben dem bereits bekannten öffentlichen / privaten E-Wallet-Schlüsselpaar verwenden wir auch normale und Service-Schlüsselpaare.

Ein gewöhnlicher öffentlicher Schlüssel ist hier der wichtigste Teil. Dieser Schlüssel wird in verschiedenen Verfahren und Prozessen der Umgebung verwendet (z. B. Bankgeschäfte und andere Transaktionen, Dokumentenfluss usw.). Beispielsweise kann ein privater Schlüssel aus einem normalen öffentlichen / privaten Schlüsselpaar zum Erstellen eines DS für verschiedene Dokumente, wie z. B. Zahlungsaufträge, verwendet werden, während der öffentliche Schlüssel zur Überprüfung des DS mit anschließender Ausführung dieser verwendet werden kann Bestellungen.

Ein öffentliches / privates Dienstschlüsselpaar wird an eine registrierte DPKI-Entität ausgegeben. Der Name dieses öffentlichen / privaten Schlüsselpaars spiegelt eindeutig seinen Zweck wider. Beachten Sie, dass Dienstschlüssel nicht zur Generierung / Überprüfung einer Nulltransaktion verwendet werden.

Um es klar zu machen, lassen Sie uns die Zwecke dieser Schlüssel verfeinern:

E-Wallet-Schlüssel werden zur Generierung und / oder Überprüfung von Null- und Nicht-Null-Transaktionen verwendet. Der private Schlüssel der E-Wallet ist nur dem Besitzer der E-Wallet bekannt, der auch über die normalen öffentlichen Schlüssel verfügt.
Der Zweck eines normalen öffentlichen Schlüssels ist der gleiche wie der des öffentlichen Schlüssels, für den ein Zertifikat in der zentralisierten PKI ausgestellt wird.
Das öffentliche / private Schlüsselpaar des Dienstes gehört zum DPKI. Für die registrierten Entitäten wird ein privater Schlüssel ausgegeben, mit dem ein DS aller Nicht-Null-Transaktionen erstellt wird. Ein öffentlicher Schlüssel wird zur Überprüfung eines DS für Transaktionen verwendet, bevor diese dem Hauptbuch hinzugefügt werden.

Wir haben also zwei Schlüsselgruppen. Die erste Gruppe umfasst Serviceschlüssel und E-Wallet-Schlüssel, die nur innerhalb des DPKI zulässig sind. Die zweite Gruppe umfasst normale Schlüssel, die je nach Anwendungsbereich für verschiedene Zwecke verwendet werden können. Gleichzeitig stellt das DPKI die Integrität und Authentizität normaler öffentlicher Schlüssel sicher.

Hinweis: Das öffentliche / private Schlüsselpaar des Dienstes kann verschiedenen DPKI-Entitäten offengelegt werden. In bestimmten Fällen kann das Paar für alle Entitäten gleich sein. Aus diesem Grund erfordert das Erstellen einer Signatur für jede Nicht-Null-Transaktion zwei private Schlüssel, von denen einer der E-Wallet-Schlüssel ist: Dieser Schlüssel ist nur dem Eigentümer der E-Wallet bekannt, der auch über die normalen öffentlichen Schlüssel verfügt. Alle diese Schlüssel haben bestimmte Zwecke. Zum Beispiel können wir immer nachweisen, dass eine bestimmte Transaktion von einer registrierten DPKI-Entität in das Hauptbuch aufgenommen wurde, da die Signatur auch mit einem privaten Serviceschlüssel erstellt wurde. Darüber hinaus werden DOS-Angriffe und andere betrügerische Aktivitäten verhindert, da der Eigentümer für jede Transaktion bezahlt.

Alle Transaktionen, die auf eine Nulltransaktion folgen, werden auf ähnliche Weise gebildet: Ein öffentlicher Schlüssel (aus einem normalen Schlüsselpaar, nicht der Schlüssel der E-Wallet wie bei Nulltransaktionen) wird mit zwei Hash-Funktionen verarbeitet: SHA256 und RIPEMD160. So entstehen Daten im dritten Feld. Das vierte Feld enthält zusätzliche Informationen (z. B. Informationen zum aktuellen Status, Gültigkeitszeitraum, Zeitstempel, IDs der kryptografischen Algorithmen usw.). Das fünfte Feld enthält einen öffentlichen Schlüssel aus dem öffentlichen / privaten Schlüsselpaar des Dienstes. Dieser Schlüssel wird repliziert, da er zur Überprüfung eines DS verwendet wird. Lassen Sie uns beweisen, dass ein solcher Ansatz notwendig ist.

Jede Transaktion wird in den Pool aufgenommen und dort bis zur Verarbeitung gespeichert. Das Halten von Transaktionen im Pool ist jedoch riskant, da Transaktionsdaten gefälscht werden können. Der Eigentümer authentifiziert Transaktionsdaten mit einem DS. Der öffentliche Schlüssel für die Überprüfung dieses DS wird explizit in einem der Transaktionsfelder angegeben und dann in das Ledger aufgenommen. Transaktionen werden so verarbeitet, dass ein Angreifer die Daten möglicherweise nach eigenem Ermessen ändern, mit einem eigenen privaten Schlüssel überprüfen und dann den entsprechenden öffentlichen Schlüssel für die Überprüfung von DS direkt in der Transaktion angeben kann. Wenn Authentizität und Integrität nur mit einem DS sichergestellt werden, kann eine solche Fälschung unbemerkt bleiben. Die Erweiterung eines DS um einen zusätzlichen Mechanismus, der sowohl die Archivierung als auch die Persistenz der gespeicherten Informationen ermöglicht, hilft jedoch dabei, solche Fälschungen zu erkennen. Alles, was wir tun müssen, ist, den authentischen öffentlichen Schlüssel des Eigentümers in das Hauptbuch aufzunehmen. Mal sehen, wie es funktioniert.

Angenommen, ein Angreifer versucht, die Transaktionsdaten zu fälschen. In Bezug auf die Schlüssel und DS sind folgende Optionen möglich:

Der Angreifer platziert seinen eigenen öffentlichen Schlüssel in der Transaktion, während der DS des Besitzers unverändert bleibt.
Der Angreifer bildet mit seinem eigenen privaten Schlüssel einen neuen DS, während der öffentliche Schlüssel des Besitzers unverändert bleibt.
Der Angreifer bildet mit seinem eigenen privaten Schlüssel einen neuen DS und platziert den entsprechenden öffentlichen Schlüssel in der Transaktion.

Es ist offensichtlich, dass die Optionen 1 und 2 nutzlos sind, da bei der Überprüfung des DS eine solche Fälschung immer erkannt wird. Die einzige Option, die Sinn macht, ist Option 3: Wenn der Angreifer einen DS mit seinem eigenen privaten Schlüssel erstellt, muss er den entsprechenden öffentlichen Schlüssel in der Transaktion speichern. Dieser Schlüssel unterscheidet sich vom öffentlichen Schlüssel des Besitzers. Nur so kann der Angreifer seine gefälschten Daten durchsetzen.

Angenommen, der Eigentümer hat ein festes öffentliches / privates Schlüsselpaar. Angenommen, die Daten werden mit einem DS unter Verwendung eines privaten Schlüssels aus diesem Paar authentifiziert, während der öffentliche Schlüssel in der Transaktion angegeben wird. Angenommen, dieser öffentliche Schlüssel wurde zuvor in das Hauptbuch aufgenommen und vollständig authentifiziert. Die Fälschung kann dann dadurch aufgedeckt werden, dass der öffentliche Schlüssel in der Transaktion nicht mit dem öffentlichen Schlüssel im Hauptbuch übereinstimmt.

Fassen wir es zusammen. Bei der Verarbeitung von Daten aus der ersten Transaktion des Eigentümers müssen wir den im Hauptbuch enthaltenen öffentlichen Schlüssel authentifizieren. Dazu können wir den Schlüssel aus dem Hauptbuch lesen und diesen Schlüssel dann mit dem authentischen öffentlichen Schlüssel des Besitzers innerhalb des Sicherheitsbereichs (relativ unverwundbarer Bereich) abgleichen. Wenn der platzierte Schlüssel authentifiziert und vollständig persistent ist, kann der Schlüssel aus der nächsten Transaktion auch einfach authentifiziert werden, indem er mit dem Schlüssel aus dem Hauptbuch abgeglichen wird. Mit anderen Worten wird der Schlüssel aus dem Hauptbuch als Referenz verwendet. Alle anderen Transaktionen des Eigentümers werden ähnlich verarbeitet.

Jede Transaktion wird mit einem DS authentifiziert, und hier benötigen wir beide privaten Schlüssel: den privaten Dienstschlüssel und den privaten Schlüssel der E-Wallet. Basierend auf den beiden privaten Schlüsseln können wir die Zielsicherheitsstufe sicherstellen, da der private Dienstschlüssel anderen Benutzern bekannt sein kann, während der private Schlüssel der E-Wallet nur dem Besitzer des normalen Schlüsselpaars bekannt ist. Wir haben eine solche Zwei-Schlüssel-Signatur als "konsolidierten" DS bezeichnet.

Nicht-Null-Transaktionen werden mit den beiden öffentlichen Schlüsseln überprüft: dem Schlüssel der E-Wallet und dem Serviceschlüssel. (Abbildung 7)

Abbildung 7. Überprüfung einer Nicht-Null-Transaktion

Der Überprüfungsprozess besteht aus zwei grundlegenden Schritten: Der erste Schritt umfasst die Überprüfung des Digests des öffentlichen Schlüssels der E-Wallet, während der zweite Schritt die Überprüfung des "konsolidierten" DS der Transaktion implementiert, der unter Verwendung der beiden privaten Schlüssel (d. H. Des E-Walls) gebildet wurde. Brieftaschenschlüssel und Serviceschlüssel). Wenn der DS authentifiziert ist, wird die entsprechende Transaktion nach der zusätzlichen Überprüfung in das Hauptbuch aufgenommen.

Es stellt sich jedoch die folgende Frage: Wie kann überprüft werden, ob eine bestimmte Transaktion zu einer bestimmten Transaktionskette gehört, die von einer Nulltransaktion ausgeht? Zu diesem Zweck haben wir den Überprüfungsprozess mit einem weiteren Schritt aktualisiert - der Konnektivitätsüberprüfung. Für diesen Schritt sind Daten aus den ersten beiden Feldern erforderlich, die wir bisher noch nicht verwendet haben.

Angenommen, wir müssen überprüfen, ob auf Transaktion 2 wirklich Transaktion 3 folgt. Dazu können wir die kombinierte Hashing-Methode verwenden, um die Hash-Funktionswerte für die Daten im dritten, vierten und fünften Feld zu berechnen. Wir können die Daten aus dem ersten Feld von Transaktion Nr. 3 und dem zuvor berechneten kombinierten Hash-Funktionswert für die Daten im dritten, vierten und fünften Feld von Transaktion Nr. 2 verketten. Alle diese Werte werden dann mit den beiden Hash-Funktionen SHA256 und RIPEMD160 verarbeitet. Wenn der resultierende Wert mit den Daten im zweiten Feld von Transaktion 2 übereinstimmt, wird die Überprüfung erfolgreich bestanden und die Konnektivität nachgewiesen. Dies ist in den folgenden Abbildungen detaillierter dargestellt.

Abbildung 8, Abbildung 9. Beispiel für die Überprüfung der Bindung, zweite und dritte Transaktion

Im Allgemeinen sieht das Bilden und Einfügen einer Benachrichtigung in das Hauptbuch so aus. Der Arbeitsablauf beim Bilden einer Benachrichtigungskette ist in der folgenden Abbildung deutlich dargestellt:

Abbildung 10. Transaktionsstruktur und -verarbeitung

In diesem Artikel werden wir nicht tief in die Details eintauchen und auf die Diskussion des Konzepts der dezentralen Infrastruktur für öffentliche Schlüssel zurückkommen.

Da die Entität, die die Anforderung stellt, eine Anforderung zur Registrierung von Benachrichtigungen sendet, die im Hauptbuch und nicht in einer CA-Datenbank gespeichert sind, lauten die zentralen Architekturkomponenten des DPKI wie folgt:

Hauptbuch gültiger Benachrichtigungen (LVN)
Hauptbuch der zurückgezogenen Benachrichtigungen (LWN)
Hauptbuch der angehaltenen Benachrichtigungen (LSN).

Die Informationen zu öffentlichen Schlüsseln werden in der LVN / LWN / LSN als Hash-Funktionswerte gespeichert. Beachten Sie auch, dass es sich entweder um verschiedene Ledger oder verschiedene Ketten oder sogar um eine einzelne Kette als Teil eines einzelnen Ledgers handeln kann, wenn Informationen zum Status eines normalen öffentlichen Schlüssels (Entnahme, Aussetzung usw.) zum vierten Feld des hinzugefügt werden Datenstruktur als entsprechender Codewert. Abhängig von verschiedenen Optimierungskriterien gibt es viele Optionen für die architektonische Implementierung des DPKI, z. B. Kosten für die Langzeitspeicherung öffentlicher Schlüssel im Speicher usw.

Somit kann das DPKI im Vergleich zu einer zentralisierten Lösung dieselbe oder sogar eine geringere architektonische Komplexität aufweisen.

Die Hauptfrage hier ist also, welches Hauptbuch für die Implementierung dieser Technologie besser geeignet ist.

Die Grundvoraussetzung für das Ledger ist es, Transaktionen jeglicher Art bilden zu können. Das bekannteste Beispiel für ein echtes Hauptbuch ist Bitcoin. Die Implementierung der oben genannten Technologie für Bitcoin kann jedoch mit bestimmten Schwierigkeiten verbunden sein: Einschränkungen der vorhandenen Skriptsprache, das Fehlen der erforderlichen Mechanismen zur Verarbeitung beliebiger Datensätze und Methoden zum Generieren von Transaktionen beliebigen Typs usw.

Wir bei ENCRY haben versucht, die oben genannten Probleme zu lösen, und ein Hauptbuch entwickelt, das unserer Meinung nach mehrere wichtige Vorteile bietet:

Unterstützung verschiedener Arten von Transaktionen: In diesem Hauptbuch können Sie sowohl Vermögenswerte austauschen (d. H. Finanztransaktionen ausführen) als auch Transaktionen mit einer beliebigen Struktur bilden
Entwickler können gerne die proprietäre Programmiersprache PrismLang verwenden, die sehr flexibel bei der Lösung verschiedener technologischer Probleme ist
Der implementierte Mechanismus zur Verarbeitung beliebiger Datensätze.

Einfach ausgedrückt sollten die folgenden Schritte ausgeführt werden:

Eine Entität, die die Anforderung erstellt, registriert sich im DPKI und erhält eine E-Wallet. Die Adresse der E-Wallet ist ein Wert der Hash-Funktion, die auf den öffentlichen Schlüssel der E-Wallet angewendet wird. Der private Schlüssel der E-Wallet ist nur der Entität bekannt, die die Anfrage stellt
Bei der Registrierung erhält die Entität Zugriff auf den privaten Dienstschlüssel
Die Entität bildet eine Nulltransaktion und authentifiziert dann ihren DS mithilfe des privaten Schlüssels der E-Wallet
Beim Bilden einer Nicht-Null-Transaktion muss die Entität ihren DS mit zwei privaten Schlüsseln authentifizieren: dem Schlüssel der E-Wallet und dem Serviceschlüssel
Die Entität sendet die Transaktion an den Pool
Der ENCRY-Netzwerkknoten liest die Transaktion aus dem Pool und überprüft dann den DS und die Konnektivität der Transaktion
Wenn der DS gültig ist und die Konnektivität nachgewiesen wurde, bereitet der Knoten die Transaktion für das Hinzufügen zum Hauptbuch vor.

Hier dient das Hauptbuch als verteilte Datenbank, in der Informationen zu gültigen, zurückgezogenen und angehaltenen Benachrichtigungen gespeichert werden.

Dezentralisierung ist sicherlich keine Einheitslösung. Das Kernproblem bei der primären Benutzerauthentifizierung besteht weiterhin: Während die Entität, die die Anforderung stellt, derzeit von der Zertifizierungsstelle überprüft wird, schlägt die DPKI vor, diese Überprüfung an die Community-Mitglieder zu delegieren und sie finanziell zu motivieren. Die auf öffentlichen Quellen basierende Verifikationstechnologie ist allgemein bekannt. Die Effizienz einer solchen Überprüfung wurde auch in der Praxis nachgewiesen: Mehrere hochkarätige Untersuchungen von Bellingcat sind gute Beispiele dafür.

Im Allgemeinen sind wir jedoch ziemlich sicher, dass die DPKI in der Lage ist, viele, wenn nicht alle Nachteile einer zentralisierten PKI zu beseitigen.

Abonnieren Sie unseren Blog auf Habr , in dem wir unsere weiteren Forschungen und Entwicklungen diskutieren, und folgen Sie unserem Twitter , um weitere Neuigkeiten zu ENCRY-Projekten zu erhalten.

DPKI: Beseitigung der Nachteile einer zentralisierten PKI durch Blockchain

More articles: