DPKI: Beseitigung der Mängel zentralisierter PKI mithilfe von Blockchain

Es ist kein Geheimnis, dass eines der am häufigsten verwendeten Hilfsmittel, ohne die der Datenschutz in offenen Netzwerken nicht möglich ist, die Technologie digitaler Zertifikate ist. Es ist jedoch kein Geheimnis, dass der Hauptnachteil der Technologie das bedingungslose Vertrauen in die Zentren ist, die digitale Zertifikate ausstellen. Andrey Chmora, Direktor für Technologie und Innovation bei ENCRY, schlug einen neuen Ansatz für die Organisation vor Public-Key-Infrastruktur (Public-Key-Infrastruktur, PKI), das zur Beseitigung aktueller Mängel beitragen wird und die Distributed-Ledger-Technologie (Blockchain) nutzt. Aber das Wichtigste zuerst.

Wenn Sie mit der Funktionsweise Ihrer aktuellen Public-Key-Infrastruktur vertraut sind und deren Hauptmängel kennen, können Sie mit den unten aufgeführten Änderungsvorschlägen fortfahren.

Was sind digitale Signaturen und Zertifikate?Bei der Interaktion im Internet geht es immer um die Übermittlung von Daten. Wir alle haben ein Interesse daran, dass die Daten sicher übertragen werden. Aber was ist Sicherheit? Die gefragtesten Sicherheitsdienste sind Vertraulichkeit, Integrität und Authentizität. Zu diesem Zweck werden derzeit Verfahren der asymmetrischen Kryptographie bzw. Kryptographie mit öffentlichem Schlüssel eingesetzt.

Beginnen wir mit der Tatsache, dass die Interaktionssubjekte für die Verwendung dieser Methoden über zwei einzelne Schlüsselpaare verfügen müssen – einen öffentlichen und einen geheimen. Mit ihrer Hilfe werden die oben genannten Sicherheitsdienste bereitgestellt.

Wie wird die Vertraulichkeit der Informationsübermittlung erreicht? Vor dem Senden von Daten verschlüsselt (kryptografisch) der sendende Teilnehmer die offenen Daten mit dem öffentlichen Schlüssel des Empfängers, und der Empfänger entschlüsselt den empfangenen Chiffretext mit dem gepaarten geheimen Schlüssel.

Wie wird die Integrität und Authentizität der übermittelten Informationen erreicht? Um dieses Problem zu lösen, wurde ein anderer Mechanismus geschaffen. Die offenen Daten werden nicht verschlüsselt, aber das Ergebnis der Anwendung der kryptografischen Hash-Funktion – ein „komprimiertes“ Abbild der Eingabedatensequenz – wird in verschlüsselter Form übertragen. Das Ergebnis eines solchen Hashings wird als „Digest“ bezeichnet und mit dem geheimen Schlüssel des sendenden Abonnenten („dem Zeugen“) verschlüsselt. Als Ergebnis der Verschlüsselung des Digests wird eine digitale Signatur erhalten. Es wird zusammen mit dem Klartext an den Empfänger-Abonnenten („Verifizierer“) übermittelt. Er entschlüsselt die digitale Signatur auf dem öffentlichen Schlüssel des Zeugen und vergleicht sie mit dem Ergebnis der Anwendung einer kryptografischen Hash-Funktion, die der Prüfer anhand der empfangenen offenen Daten selbstständig berechnet. Wenn sie übereinstimmen, bedeutet dies, dass die Daten vom sendenden Teilnehmer authentisch und vollständig übermittelt und nicht von einem Angreifer verändert wurden.

Die meisten Ressourcen, die mit personenbezogenen Daten und Zahlungsinformationen arbeiten (Banken, Versicherungen, Fluggesellschaften, Zahlungssysteme sowie Regierungsportale wie das Steueramt), nutzen aktiv asymmetrische Kryptografiemethoden.

Was hat ein digitales Zertifikat damit zu tun? Es ist einfach. Sowohl beim ersten als auch beim zweiten Verfahren handelt es sich um öffentliche Schlüssel, und da diese eine zentrale Rolle spielen, ist es sehr wichtig sicherzustellen, dass die Schlüssel tatsächlich dem Absender (dem Zeugen im Fall der Signaturprüfung) oder dem Empfänger gehören und nicht durch die Schlüssel der Angreifer ersetzt. Aus diesem Grund gibt es digitale Zertifikate, um die Authentizität und Integrität des öffentlichen Schlüssels sicherzustellen.

Hinweis: Die Authentizität und Integrität des öffentlichen Schlüssels wird auf genau die gleiche Weise bestätigt wie die Authentizität und Integrität öffentlicher Daten, nämlich mithilfe einer elektronischen digitalen Signatur (EDS).
Woher kommen digitale Zertifikate?Vertrauenswürdige Zertifizierungsstellen oder Certification Authorities (CAs) sind für die Ausstellung und Verwaltung digitaler Zertifikate verantwortlich. Der Antragsteller beantragt die Ausstellung eines Zertifikats bei der CA, unterzieht sich einer Identifizierung im Registration Center (CR) und erhält ein Zertifikat von der CA. Die CA garantiert, dass der öffentliche Schlüssel aus dem Zertifikat genau der Entität gehört, für die er ausgestellt wurde.

Wenn Sie die Authentizität des öffentlichen Schlüssels nicht bestätigen, kann ein Angreifer diesen bei der Übertragung/Speicherung dieses Schlüssels durch seinen eigenen ersetzen. Wenn die Ersetzung stattgefunden hat, kann der Angreifer alles entschlüsseln, was der sendende Teilnehmer an den empfangenden Teilnehmer übermittelt, oder die offenen Daten nach eigenem Ermessen ändern.

Digitale Zertifikate werden überall dort eingesetzt, wo asymmetrische Kryptographie verfügbar ist. Eines der gebräuchlichsten digitalen Zertifikate sind SSL-Zertifikate für die sichere Kommunikation über das HTTPS-Protokoll. Hunderte von in verschiedenen Jurisdiktionen registrierten Unternehmen sind an der Ausstellung von SSL-Zertifikaten beteiligt. Der Hauptanteil entfällt auf fünf bis zehn große vertrauenswürdige Zentren: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA und CR sind Bestandteile der PKI, zu der auch Folgendes gehört:

• Verzeichnis öffnen – eine öffentliche Datenbank, die eine sichere Speicherung digitaler Zertifikate ermöglicht.
• Liste der widerrufenen Zertifikate – eine öffentliche Datenbank, die eine sichere Speicherung digitaler Zertifikate widerrufener öffentlicher Schlüssel ermöglicht (z. B. aufgrund der Kompromittierung eines gepaarten privaten Schlüssels). Infrastruktursubjekte können selbstständig auf diese Datenbank zugreifen oder das spezielle Online Certification Status Protocol (OCSP) nutzen, das den Verifizierungsprozess vereinfacht.
• Zertifikatsbenutzer – betreute PKI-Subjekte, die einen Nutzungsvertrag mit der Zertifizierungsstelle abgeschlossen haben und die digitale Signatur verifizieren und/oder Daten auf der Grundlage des öffentlichen Schlüssels aus dem Zertifikat verschlüsseln.
• Verfolger – bediente PKI-Subjekte, die einen geheimen Schlüssel besitzen, der mit dem öffentlichen Schlüssel aus dem Zertifikat gepaart ist, und die einen Abonnentenvertrag mit der CA abgeschlossen haben. Der Abonnent kann gleichzeitig Nutzer des Zertifikats sein.

Daher sind vertrauenswürdige Einheiten der Public-Key-Infrastruktur, zu denen CAs, CRs und offene Verzeichnisse gehören, verantwortlich für:

1. Überprüfung der Echtheit der Identität des Antragstellers.
2. Profilierung des Public-Key-Zertifikats.
3. Ausstellung eines Public-Key-Zertifikats für einen Antragsteller, dessen Identität zuverlässig bestätigt wurde.
4. Ändern Sie den Status des Public-Key-Zertifikats.
5. Bereitstellung von Informationen über den aktuellen Status des Public-Key-Zertifikats.

Was sind die Nachteile von PKI?Der grundlegende Fehler von PKI ist das Vorhandensein vertrauenswürdiger Instanzen.
Benutzer müssen der CA und CR bedingungslos vertrauen. Doch wie die Praxis zeigt, ist bedingungsloses Vertrauen mit schwerwiegenden Folgen verbunden.

In den letzten zehn Jahren kam es in diesem Bereich zu mehreren großen Skandalen im Zusammenhang mit der Schwachstelle der Infrastruktur.

– Im Jahr 2010 begann sich die Stuxnet-Malware online zu verbreiten, signiert mit gestohlenen digitalen Zertifikaten von RealTek und JMicron.

- Im Jahr 2017 warf Google Symantec vor, eine große Anzahl gefälschter Zertifikate ausgestellt zu haben. Gemessen am Produktionsvolumen war Symantec damals eine der größten CAs. Im Google Chrome 70-Browser wurde die Unterstützung für Zertifikate dieses Unternehmens und seiner angeschlossenen Zentren GeoTrust und Thawte vor dem 1. Dezember 2017 eingestellt.

Die CAs wurden kompromittiert, und alle litten darunter: die CAs selbst sowie Benutzer und Abonnenten. Das Vertrauen in die Infrastruktur wurde untergraben. Darüber hinaus können digitale Zertifikate im Rahmen politischer Konflikte gesperrt werden, was sich auch auf den Betrieb vieler Ressourcen auswirken wird. Genau das wurde vor einigen Jahren in der russischen Präsidialverwaltung befürchtet, als sie 2016 die Möglichkeit diskutierte, ein staatliches Zertifizierungszentrum einzurichten, das SSL-Zertifikate für Websites im RuNet ausstellen würde. Der aktuelle Stand der Dinge ist so, dass sogar staatliche Portale in Russland verwenden digitale Zertifikate der amerikanischen Unternehmen Comodo oder Thawte (eine Tochtergesellschaft von Symantec).

Es gibt noch ein anderes Problem – die Frage primäre Authentifizierung (Authentifizierung) von Benutzern. Wie kann ein Benutzer identifiziert werden, der sich ohne direkten persönlichen Kontakt an die Zertifizierungsstelle gewandt hat, um ein digitales Zertifikat auszustellen? Dies wird nun je nach Leistungsfähigkeit der Infrastruktur situativ gelöst. Es wird etwas aus offenen Registern entnommen (z. B. Informationen über juristische Personen, die Zertifikate beantragen); in Fällen, in denen es sich bei den Antragstellern um natürliche Personen handelt, können Bankfilialen oder Postämter genutzt werden, deren Identität anhand von Ausweisdokumenten, beispielsweise einem Reisepass, bestätigt wird.

Das Problem der Fälschung von Ausweisen zum Zweck der Identitätsfälschung ist ein grundsätzliches Problem. Beachten wir, dass es aus informationstheoretischen Gründen keine vollständige Lösung für dieses Problem gibt: Ohne a priori verlässliche Informationen ist es unmöglich, die Authentizität eines bestimmten Themas zu bestätigen oder zu leugnen. Zur Überprüfung ist in der Regel die Vorlage von Dokumenten erforderlich, die die Identität des Antragstellers belegen. Es gibt viele verschiedene Überprüfungsmethoden, aber keine davon bietet eine vollständige Garantie für die Echtheit von Dokumenten. Dementsprechend kann auch die Echtheit der Identität des Antragstellers nicht gewährleistet werden.

Wie können diese Mängel behoben werden?Wenn die Probleme der PKI in ihrem gegenwärtigen Zustand durch die Zentralisierung erklärt werden können, ist es logisch anzunehmen, dass die Dezentralisierung dazu beitragen würde, die festgestellten Mängel teilweise zu beseitigen.

Dezentralisierung bedeutet nicht die Anwesenheit vertrauenswürdiger Einheiten – sofern Sie sie erstellen dezentrale Public-Key-Infrastruktur (Dezentrale Public-Key-Infrastruktur, DPKI), dann werden weder CA noch CR benötigt. Lassen Sie uns das Konzept eines digitalen Zertifikats aufgeben und eine verteilte Registrierung verwenden, um Informationen über öffentliche Schlüssel zu speichern. In unserem Fall nennen wir ein Register eine lineare Datenbank, die aus einzelnen Datensätzen (Blöcken) besteht, die mithilfe der Blockchain-Technologie verknüpft sind. Anstelle eines digitalen Zertifikats werden wir das Konzept der „Benachrichtigung“ einführen.

Wie der Prozess des Empfangens, Überprüfens und Stornierens von Meldungen im vorgeschlagenen DPKI aussehen wird:

1. Jeder Antragsteller stellt selbstständig einen Antrag auf Benachrichtigung, indem er bei der Registrierung ein Formular ausfüllt und anschließend eine Transaktion erstellt, die in einem spezialisierten Pool gespeichert wird.

2. Informationen über den öffentlichen Schlüssel werden zusammen mit den Angaben zum Eigentümer und anderen Metadaten in einem verteilten Register gespeichert und nicht in einem digitalen Zertifikat, für dessen Ausstellung in einer zentralen PKI die Zertifizierungsstelle verantwortlich ist.

3. Die Überprüfung der Authentizität der Identität des Antragstellers erfolgt nachträglich durch gemeinsame Anstrengungen der DPKI-Benutzergemeinschaft und nicht durch den CR.

4. Nur der Besitzer einer solchen Benachrichtigung kann den Status eines öffentlichen Schlüssels ändern.

5. Jeder kann auf das Distributed Ledger zugreifen und den aktuellen Status des öffentlichen Schlüssels überprüfen.

Hinweis: Die Community-Überprüfung der Identität eines Antragstellers kann auf den ersten Blick unzuverlässig erscheinen. Wir müssen jedoch bedenken, dass heutzutage alle Nutzer digitaler Dienste unweigerlich einen digitalen Fußabdruck hinterlassen und dieser Prozess nur noch an Dynamik gewinnen wird. Offene elektronische Register juristischer Personen, Karten, Digitalisierung von Geländebildern, soziale Netzwerke – all das sind öffentlich zugängliche Werkzeuge. Sie werden bereits erfolgreich bei Ermittlungen sowohl von Journalisten als auch von Strafverfolgungsbehörden eingesetzt. Es genügt beispielsweise, an die Ermittlungen von Bellingcat oder des gemeinsamen Ermittlungsteams JIT zu erinnern, das die Umstände des Absturzes der malaysischen Boeing untersucht.

Wie würde also eine dezentrale Public-Key-Infrastruktur in der Praxis funktionieren? Bleiben wir bei der Beschreibung der Technologie selbst, die wir haben 2018 patentiert und wir betrachten es zu Recht als unser Know-how.

Stellen Sie sich vor, es gibt einen Besitzer, der viele öffentliche Schlüssel besitzt, wobei jeder Schlüssel eine bestimmte Transaktion darstellt, die in der Registrierung gespeichert ist. Wie können Sie ohne Zertifizierungsstelle verstehen, dass alle Schlüssel diesem bestimmten Eigentümer gehören? Um dieses Problem zu lösen, wird eine Nulltransaktion erstellt, die Informationen über den Eigentümer und sein Wallet enthält (von dem die Provision für die Eintragung der Transaktion in das Register abgebucht wird). Die Nulltransaktion ist eine Art „Anker“, an den die folgenden Transaktionen mit Daten zu öffentlichen Schlüsseln angehängt werden. Jede dieser Transaktionen enthält eine spezielle Datenstruktur, oder anders ausgedrückt, eine Benachrichtigung.

Bei der Benachrichtigung handelt es sich um einen strukturierten Datensatz, der aus Funktionsfeldern besteht und Informationen über den öffentlichen Schlüssel des Eigentümers enthält, dessen Beständigkeit durch die Platzierung in einem der zugehörigen Datensätze des verteilten Registers gewährleistet ist.

Die nächste logische Frage ist, wie entsteht eine Nulltransaktion? Die Nulltransaktion ist – wie auch die nachfolgenden – eine Aggregation von sechs Datenfeldern. Bei der Bildung einer Nulltransaktion ist das Schlüsselpaar des Wallets beteiligt (öffentlicher und gepaarter geheimer Schlüssel). Dieses Schlüsselpaar erscheint in dem Moment, in dem der Benutzer sein Wallet registriert, von dem die Provision für die Eintragung einer Nulltransaktion in das Register und anschließend für Vorgänge mit Benachrichtigungen abgebucht wird.

Wie in der Abbildung dargestellt, wird ein Wallet-Public-Key-Digest durch sequentielles Anwenden der Hash-Funktionen SHA256 und RIPEMD160 generiert. Hier ist RIPEMD160 für die kompakte Darstellung von Daten verantwortlich, deren Breite 160 Bit nicht überschreitet. Dies ist wichtig, da es sich bei der Registry nicht um eine billige Datenbank handelt. Im fünften Feld wird der öffentliche Schlüssel selbst eingetragen. Das erste Feld enthält Daten, die eine Verbindung zur vorherigen Transaktion herstellen. Bei einer Null-Transaktion enthält dieses Feld nichts, was es von nachfolgenden Transaktionen unterscheidet. Das zweite Feld enthält Daten zur Überprüfung der Konnektivität von Transaktionen. Der Kürze halber nennen wir die Daten im ersten und zweiten Feld „Link“ bzw. „Check“. Der Inhalt dieser Felder wird durch iteratives Hashing generiert, wie die Verknüpfung der zweiten und dritten Transaktion in der folgenden Abbildung zeigt.

Die Daten aus den ersten fünf Feldern werden durch eine elektronische Signatur zertifiziert, die mithilfe des geheimen Schlüssels des Wallets generiert wird.

Die Nulltransaktion wird an den Pool gesendet und nach erfolgreicher Überprüfung in die Registrierung eingetragen. Nun können Sie die folgenden Transaktionen damit „verknüpfen“. Betrachten wir, wie Transaktionen ungleich Null gebildet werden.

Das erste, was Ihnen wahrscheinlich ins Auge fällt, ist die Fülle an Schlüsselpaaren. Neben dem bereits bekannten Wallet-Schlüsselpaar werden auch normale und Service-Schlüsselpaare verwendet.

Für einen gewöhnlichen öffentlichen Schlüssel wurde alles gestartet. Dieser Schlüssel ist an verschiedenen Vorgängen und Prozessen in der Außenwelt beteiligt (Bank- und andere Transaktionen, Dokumentenfluss usw.). Beispielsweise kann ein geheimer Schlüssel aus einem gewöhnlichen Paar verwendet werden, um digitale Signaturen für verschiedene Dokumente – Zahlungsaufträge usw. – zu generieren, und ein öffentlicher Schlüssel kann verwendet werden, um diese digitale Signatur bei der anschließenden Ausführung dieser Anweisungen zu überprüfen, sofern dies der Fall ist ist gültig.

Das Leistungspaar wird an den registrierten DPKI-Betreff ausgestellt. Der Name dieses Paares entspricht seinem Zweck. Beachten Sie, dass bei der Bildung/Prüfung einer Nulltransaktion keine Serviceschlüssel verwendet werden.

Lassen Sie uns noch einmal den Zweck der Schlüssel klären:

1. Wallet-Schlüssel werden verwendet, um sowohl eine Null-Transaktion als auch jede andere Nicht-Null-Transaktion zu generieren/zu überprüfen. Der private Schlüssel einer Wallet ist nur dem Besitzer der Wallet bekannt, der auch der Besitzer vieler gewöhnlicher öffentlicher Schlüssel ist.
2. Ein gewöhnlicher öffentlicher Schlüssel hat einen ähnlichen Zweck wie ein öffentlicher Schlüssel, für den in einer zentralen PKI ein Zertifikat ausgestellt wird.
3. Das Dienstschlüsselpaar gehört DPKI. Der geheime Schlüssel wird an registrierte Unternehmen ausgegeben und bei der Erstellung digitaler Signaturen für Transaktionen (mit Ausnahme von Nulltransaktionen) verwendet. Public wird verwendet, um die elektronische digitale Signatur einer Transaktion zu überprüfen, bevor sie im Register veröffentlicht wird.

Somit gibt es zwei Gruppen von Schlüsseln. Die erste umfasst Dienstschlüssel und Wallet-Schlüssel – sie machen nur im Kontext von DPKI Sinn. Die zweite Gruppe umfasst gewöhnliche Schlüssel – ihr Umfang kann variieren und wird durch die Anwendungsaufgaben bestimmt, in denen sie verwendet werden. Gleichzeitig stellt DPKI die Integrität und Authentizität gewöhnlicher öffentlicher Schlüssel sicher.

Hinweis: Das Dienstschlüsselpaar ist möglicherweise verschiedenen DPKI-Entitäten bekannt. Es kann zum Beispiel für alle gleich sein. Aus diesem Grund werden beim Generieren der Signatur jeder Nicht-Null-Transaktion zwei geheime Schlüssel verwendet, von denen einer der Wallet-Schlüssel ist – er ist nur dem Besitzer des Wallets bekannt, der auch der Besitzer vieler gewöhnlicher Transaktionen ist öffentliche Schlüssel. Alle Tasten haben ihre eigene Bedeutung. Beispielsweise ist es jederzeit möglich nachzuweisen, dass die Transaktion von einem registrierten DPKI-Subjekt in das Register eingetragen wurde, da die Signatur auch auf einem Geheimdienstschlüssel generiert wurde. Und es kann keinen Missbrauch wie etwa DOS-Angriffe geben, da der Eigentümer für jede Transaktion bezahlt.

Alle Transaktionen, die auf die Null-Eins folgen, werden auf ähnliche Weise gebildet: Der öffentliche Schlüssel (nicht das Wallet, wie im Fall der Null-Transaktion, sondern aus einem gewöhnlichen Schlüsselpaar) wird durch zwei Hash-Funktionen SHA256 und RIPEMD160 geführt. So entstehen die Daten des dritten Feldes. Das vierte Feld enthält Begleitinformationen (z. B. Informationen zum aktuellen Status, Ablaufdaten, Zeitstempel, Kennungen verwendeter Kryptoalgorithmen usw.). Das fünfte Feld enthält den öffentlichen Schlüssel aus dem Dienstschlüsselpaar. Mit seiner Hilfe wird dann die digitale Signatur überprüft und somit repliziert. Lassen Sie uns die Notwendigkeit eines solchen Ansatzes begründen.

Denken Sie daran, dass eine Transaktion in einen Pool eingegeben und dort gespeichert wird, bis sie verarbeitet wird. Die Speicherung in einem Pool ist mit einem gewissen Risiko verbunden – Transaktionsdaten können verfälscht werden. Der Eigentümer beglaubigt die Transaktionsdaten mit einer elektronischen digitalen Signatur. Der öffentliche Schlüssel zur Überprüfung dieser digitalen Signatur wird in einem der Transaktionsfelder explizit angegeben und anschließend in die Registrierung eingetragen. Die Besonderheiten der Transaktionsverarbeitung bestehen darin, dass ein Angreifer die Daten nach eigenem Ermessen ändern und anschließend mit seinem geheimen Schlüssel überprüfen und einen gepaarten öffentlichen Schlüssel zur Überprüfung der digitalen Signatur in der Transaktion angeben kann. Werden Authentizität und Integrität ausschließlich durch die digitale Signatur sichergestellt, bleibt eine solche Fälschung unbemerkt. Wenn jedoch zusätzlich zur digitalen Signatur ein zusätzlicher Mechanismus vorhanden ist, der sowohl die Archivierung als auch die Persistenz der gespeicherten Informationen gewährleistet, kann die Fälschung erkannt werden. Dazu reicht es aus, den echten öffentlichen Schlüssel des Besitzers in die Registry einzutragen. Lassen Sie uns erklären, wie das funktioniert.

Lassen Sie den Angreifer Transaktionsdaten fälschen. Aus Sicht der Schlüssel und digitalen Signaturen sind folgende Optionen möglich:

1. Der Angreifer fügt seinen öffentlichen Schlüssel in die Transaktion ein, während die digitale Signatur des Eigentümers unverändert bleibt.
2. Der Angreifer erstellt eine digitale Signatur auf seinem privaten Schlüssel, lässt den öffentlichen Schlüssel des Eigentümers jedoch unverändert.
3. Der Angreifer erstellt eine digitale Signatur auf seinem privaten Schlüssel und fügt einen gepaarten öffentlichen Schlüssel in die Transaktion ein.

Offensichtlich sind die Optionen 1 und 2 bedeutungslos, da sie bei der Überprüfung der digitalen Signatur immer erkannt werden. Nur Option 3 ist sinnvoll, und wenn ein Angreifer eine digitale Signatur auf seinem eigenen geheimen Schlüssel erstellt, ist er gezwungen, bei der Transaktion einen gepaarten öffentlichen Schlüssel zu speichern, der sich vom öffentlichen Schlüssel des Besitzers unterscheidet. Nur so kann ein Angreifer gefälschte Daten einschleusen.

Nehmen wir an, dass der Eigentümer über ein festes Schlüsselpaar verfügt – privat und öffentlich. Lassen Sie die Daten mit dem geheimen Schlüssel dieses Paares durch digitale Signatur zertifizieren und der öffentliche Schlüssel wird in der Transaktion angegeben. Nehmen wir außerdem an, dass dieser öffentliche Schlüssel zuvor in die Registry eingetragen und seine Authentizität zuverlässig überprüft wurde. Eine Fälschung wird dann dadurch angezeigt, dass der öffentliche Schlüssel aus der Transaktion nicht mit dem öffentlichen Schlüssel aus der Registry übereinstimmt.

Fassen wir zusammen. Bei der Verarbeitung der allerersten Transaktionsdaten des Eigentümers ist es notwendig, die Authentizität des in die Registrierung eingetragenen öffentlichen Schlüssels zu überprüfen. Lesen Sie dazu den Schlüssel aus der Registry aus und vergleichen Sie ihn mit dem wahren öffentlichen Schlüssel des Besitzers innerhalb des Sicherheitsperimeters (Bereich relativer Unverwundbarkeit). Wenn die Authentizität des Schlüssels bestätigt ist und seine Persistenz bei der Platzierung gewährleistet ist, kann die Authentizität des Schlüssels aus der nachfolgenden Transaktion leicht bestätigt/widerlegt werden, indem er mit dem Schlüssel aus der Registrierung verglichen wird. Mit anderen Worten: Der Schlüssel aus der Registry wird als Referenzmuster verwendet. Alle anderen Eigentümertransaktionen werden auf ähnliche Weise verarbeitet.

Die Transaktion wird durch eine elektronische digitale Signatur zertifiziert – hier werden geheime Schlüssel benötigt, und zwar nicht einer, sondern gleich zwei – ein Serviceschlüssel und ein Wallet-Schlüssel. Durch die Verwendung von zwei geheimen Schlüsseln wird das nötige Maß an Sicherheit gewährleistet – schließlich kann der geheime Schlüssel des Dienstes anderen Benutzern bekannt sein, während der geheime Schlüssel des Wallets nur dem Besitzer des gewöhnlichen Schlüsselpaares bekannt ist. Wir haben eine solche Zwei-Schlüssel-Signatur als „konsolidierte“ digitale Signatur bezeichnet.

Die Überprüfung von Nicht-Null-Transaktionen erfolgt mithilfe von zwei öffentlichen Schlüsseln: dem Wallet und dem Serviceschlüssel. Der Verifizierungsprozess kann in zwei Hauptphasen unterteilt werden: In der ersten Phase wird der Auszug des öffentlichen Schlüssels der Brieftasche überprüft, in der zweiten wird die elektronische digitale Signatur der Transaktion überprüft, dieselbe konsolidierte Signatur, die mithilfe zweier geheimer Schlüssel erstellt wurde ( Geldbeutel und Service). Wird die Gültigkeit der digitalen Signatur bestätigt, wird die Transaktion nach zusätzlicher Prüfung in das Register eingetragen.

Es kann sich eine logische Frage stellen: Wie kann überprüft werden, ob eine Transaktion zu einer bestimmten Kette mit der „Wurzel“ in Form einer Nulltransaktion gehört? Zu diesem Zweck wird der Verifizierungsprozess um eine weitere Stufe ergänzt – die Konnektivitätsprüfung. Hier benötigen wir die Daten aus den ersten beiden Feldern, die wir bisher ignoriert haben.

Stellen wir uns vor, wir müssten prüfen, ob die Transaktion Nr. 3 tatsächlich nach der Transaktion Nr. 2 erfolgt. Dazu wird mit dem kombinierten Hashing-Verfahren der Hash-Funktionswert für die Daten aus dem dritten, vierten und fünften Feld der Transaktion Nr. 2 berechnet. Dann wird die Verkettung der Daten aus dem ersten Feld der Transaktion Nr. 3 und des zuvor erhaltenen kombinierten Hash-Funktionswerts für Daten aus dem dritten, vierten und fünften Feld der Transaktion Nr. 2 durchgeführt. All dies wird auch über zwei Hash-Funktionen SHA256 und RIPEMD160 ausgeführt. Wenn der empfangene Wert mit den Daten im zweiten Feld der Transaktion Nr. 2 übereinstimmt, ist die Prüfung bestanden und die Verbindung bestätigt. Dies wird in den folgenden Abbildungen deutlicher dargestellt.

Im Allgemeinen sieht die Technologie zur Erstellung und Eintragung einer Meldung in das Register genau so aus. Eine visuelle Darstellung des Prozesses der Bildung einer Benachrichtigungskette ist in der folgenden Abbildung dargestellt:

In diesem Text werden wir uns nicht mit den Details befassen, die zweifellos existieren, und uns wieder der eigentlichen Idee einer dezentralen Public-Key-Infrastruktur zuwenden.

Da der Antragsteller selbst einen Antrag auf Registrierung von Meldungen stellt, die nicht in der CA-Datenbank, sondern im Register gespeichert sind, sollten die wichtigsten Architekturkomponenten von DPKI berücksichtigt werden:

1. Register gültiger Meldungen (RDN).
2. Register der widerrufenen Mitteilungen (RON).
3. Register der ausgesetzten Meldungen (RPN).

Informationen über öffentliche Schlüssel werden in RDN/RON/RPN in Form von Hash-Funktionswerten gespeichert. Es ist auch erwähnenswert, dass es sich dabei entweder um unterschiedliche Register oder unterschiedliche Ketten oder sogar um eine Kette als Teil eines einzigen Registers handeln kann, wenn Informationen über den Status eines gewöhnlichen öffentlichen Schlüssels (Widerruf, Suspendierung usw.) in das eingegeben werden viertes Feld der Datenstruktur in Form des entsprechenden Codewerts. Es gibt viele verschiedene Optionen für die architektonische Implementierung von DPKI, und die Wahl der einen oder anderen hängt von einer Reihe von Faktoren ab, beispielsweise Optimierungskriterien wie den Kosten des Langzeitspeichers für die Speicherung öffentlicher Schlüssel usw.

Daher könnte sich DPKI hinsichtlich der architektonischen Komplexität als wenn nicht einfacher, so doch zumindest vergleichbar mit einer zentralisierten Lösung erweisen.

Die Hauptfrage bleibt: Welche Registry ist für die Implementierung der Technologie geeignet?

Die Hauptanforderung an die Registrierung ist die Fähigkeit, Transaktionen jeglicher Art zu generieren. Das bekannteste Beispiel für ein Ledger ist das Bitcoin-Netzwerk. Bei der Implementierung der oben beschriebenen Technologie treten jedoch bestimmte Schwierigkeiten auf: die Einschränkungen der vorhandenen Skriptsprache, das Fehlen notwendiger Mechanismen zur Verarbeitung beliebiger Datensätze, Methoden zur Generierung von Transaktionen beliebiger Art und vieles mehr.

Wir von ENCRY haben versucht, die oben formulierten Probleme zu lösen und haben ein Register entwickelt, das unserer Meinung nach eine Reihe von Vorteilen mit sich bringt, nämlich:

• unterstützt mehrere Arten von Transaktionen: Es kann sowohl Vermögenswerte austauschen (d. h. Finanztransaktionen durchführen) als auch Transaktionen mit einer beliebigen Struktur erstellen.
• Entwickler haben Zugriff auf die proprietäre Programmiersprache PrismLang, die die nötige Flexibilität bei der Lösung verschiedener technologischer Probleme bietet,
• Es wird ein Mechanismus zur Verarbeitung beliebiger Datensätze bereitgestellt.

Wenn wir vereinfacht vorgehen, findet folgende Abfolge von Aktionen statt:

1. Der Antragsteller registriert sich bei DPKI und erhält eine digitale Geldbörse. Die Wallet-Adresse ist der Hash-Wert des öffentlichen Schlüssels des Wallets. Der private Schlüssel des Wallets ist nur dem Antragsteller bekannt.
2. Dem registrierten Subjekt wird Zugriff auf den geheimen Dienstschlüssel gewährt.
3. Das Subjekt generiert eine Nulltransaktion und verifiziert diese mit einer digitalen Signatur unter Verwendung des geheimen Schlüssels der Brieftasche.
4. Kommt es zu einer anderen Transaktion als Null, wird diese durch eine elektronische digitale Signatur mit zwei geheimen Schlüsseln zertifiziert: einem Wallet- und einem Service-Schlüssel.
5. Das Subjekt übermittelt eine Transaktion an den Pool.
6. Der ENCRY-Netzwerkknoten liest die Transaktion aus dem Pool und überprüft die digitale Signatur sowie die Konnektivität der Transaktion.
7. Ist die digitale Signatur gültig und die Verbindung bestätigt, bereitet es die Transaktion für die Eintragung in das Register vor.

Dabei fungiert die Registry als verteilte Datenbank, die Informationen über gültige, stornierte und ausgesetzte Benachrichtigungen speichert.

Natürlich ist Dezentralisierung kein Allheilmittel. Das grundlegende Problem der primären Benutzerauthentifizierung verschwindet nirgendwo: Wenn die Überprüfung des Antragstellers derzeit von der CR durchgeführt wird, wird in DPKI vorgeschlagen, die Überprüfung an Community-Mitglieder zu delegieren und finanzielle Motivation zur Anregung der Aktivität zu nutzen. Open-Source-Verifizierungstechnologie ist allgemein bekannt. Die Wirksamkeit einer solchen Überprüfung wurde in der Praxis bestätigt. Erinnern wir uns noch einmal an eine Reihe hochkarätiger Untersuchungen der Online-Publikation Bellingcat.

Aber im Allgemeinen ergibt sich das folgende Bild: DPKI ist eine Gelegenheit, wenn nicht alle, dann viele der Mängel der zentralisierten PKI zu beheben.

Abonnieren Sie unseren Habrablog, wir planen, weiterhin aktiv über unsere Forschung und Entwicklung zu berichten und diese zu verfolgen Twitter, wenn Sie keine weiteren Neuigkeiten zu ENCRY-Projekten verpassen möchten.

Source: habr.com