DE112021006165T5 - Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf - Google Patents

Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf Download PDF

Info

Publication number
DE112021006165T5
DE112021006165T5 DE112021006165.8T DE112021006165T DE112021006165T5 DE 112021006165 T5 DE112021006165 T5 DE 112021006165T5 DE 112021006165 T DE112021006165 T DE 112021006165T DE 112021006165 T5 DE112021006165 T5 DE 112021006165T5
Authority
DE
Germany
Prior art keywords
blockchain
key
keys
transaction
peers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112021006165.8T
Other languages
English (en)
Inventor
Yacov Manevich
Nitin Gaur
Dulce B. Ponceleon
Petr Novotny
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112021006165T5 publication Critical patent/DE112021006165T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Eine beispielhafte Operation kann Verschlüsseln eines privaten Schlüssels mit einem Verschlüsselungsschlüssel und/oder Erzeugen einer Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels und/oder Umwandeln der Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes und/oder Speichern des verschlüsselten privaten Schlüssels in einer Blockchain und/oder Verteilen der Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain umfassen, wobei das Verteilen Übertragen eines anderen Schlüsselanteils von der Mehrzahl von Schlüsselanteilen an jeden Blockchain-Peer von der Mehrzahl von Blockchain-Peers aufweist.

Description

  • HINTERGRUND
  • Eine zentrale Plattform speichert und pflegt Daten an einem einzigen Ort. Bei diesem Ort handelt es sich häufig um einen zentralen Computer, z.B. eine Cloud-Computing-Umgebung, einen Webserver, einen Großrechner oder Ähnliches. Auf Informationen, die auf einer zentralen Plattform gespeichert sind, kann in der Regel von mehreren verschiedenen Orten aus zugegriffen werden. Auf der zentralen Plattform können gleichzeitig mehrere Benutzer oder Client-Workstations arbeiten, z.B. auf der Grundlage einer Client/Server-Konfiguration. Eine zentrale Plattform ist insbesondere hinsichtlich ihrer Sicherheit einfach zu verwalten, zu pflegen und zu überwachen, da sie sich an einem einzigen Ort befindet. Auf einer zentralen Plattform wird die Datenredundanz minimiert, da ein einzelner Speicherplatz für alle Daten auch bedeutet, dass ein gegebener Datensatz nur einen primären Datensatz hat.
  • KURZDARSTELLUNG
  • Eine beispielhafte Ausführungsform stellt eine Vorrichtung bereit, die einen Prozessor umfasst, der so konfiguriert ist, dass er einen privaten Schlüssel mit einem Verschlüsselungsschlüssel verschlüsselt und/oder eine Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels erzeugt und/oder die Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes umwandelt und/oder den verschlüsselten privaten Schlüssel in einer Blockchain speichert, und/oder eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie die Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain verteilt, wobei der Prozessor einen anderen Schlüsselanteil von der Mehrzahl von Schlüsselanteilen an jeden Blockchain-Peer der Mehrzahl von Blockchain-Peers überträgt.
  • Eine weitere beispielhafte Ausführungsform stellt ein Verfahren bereit, das Verschlüsseln eines privaten Schlüssels mit einem Verschlüsselungsschlüssel und/oder Erzeugen einer Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels und/oder Umwandeln der Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes und/oder Speichern des verschlüsselten privaten Schlüssels in einer Blockchain und/oder Verteilen der Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain umfasst, wobei das Verteilen Übertragen eines anderen Schlüsselanteils von der Mehrzahl von Schlüsselanteilen an jeden Blockchain-Peer von der Mehrzahl von Blockchain-Peers aufweist.
  • Eine weitere beispielhafte Ausführungsform stellt ein nichtflüchtiges, durch einen Computer lesbares Medium mit Anweisungen bereit, die, wenn sie von einem Prozessor gelesen werden, den Prozessor veranlassen, Verschlüsseln eines privaten Schlüssels mit einem Verschlüsselungsschlüssel und/oder Erzeugen einer Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels und/oder Umwandeln der Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes und/oder Speichern des verschlüsselten privaten Schlüssels in einer Blockchain und/oder Verteilen der Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain durchzuführen, wobei das Verteilen Übertragen eines anderen Schlüsselanteils der Mehrzahl von Schlüsselanteilen an jeden Blockchain-Peer der Mehrzahl von Blockchain-Peers aufweist.
  • Kurzbeschreibung der Zeichnungen
    • 1A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Speichern eines verschlüsselten privaten Schlüssels in einem Blockchain-Netzwerk veranschaulicht.
    • 1B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Umwandeln eines Verschlüsselungsschlüssels in Schlüsselanteile mit einer vergesslichen Pseudozufallsfunktion (oblivious pseudorandum function - OPRF) veranschaulicht.
    • 1C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Wiederherstellen des Verschlüsselungsschlüssels veranschaulicht.
    • 1D ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess zum Entschlüsseln einer Gebührentransaktion und Abrufen des verschlüsselten privaten Schlüssels veranschaulicht.
    • 2A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine beispielhafte Konfiguration einer Blockchain-Architektur veranschaulicht.
    • 2B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Blockchain-Transaktionsablauf zwischen Knoten veranschaulicht.
    • 3A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein genehmigungspflichtiges (permissioned) Netzwerk veranschaulicht.
    • 3B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein weiteres genehmigungspflichtiges Netzwerk veranschaulicht.
    • 3C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein genehmigungsfreies (permissionless) Netzwerk veranschaulicht.
    • 4A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Datenübertragungsprozess zum Erzeugen und Verteilen von OPRF-Schlüsseln veranschaulicht.
    • 4B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Datenübertragungsprozess zum Wiederherstellen eines Verschlüsselungsschlüssels auf der Grundlage der verteilten OPRF-Schlüssel veranschaulicht.
    • 5 ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein Verfahren zum Verteilen eines Verschlüsselungsschlüssels unter Peers eines Blockchain-Netzwerks veranschaulicht.
    • 6A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein beispielhaftes System veranschaulicht, dass so konfiguriert ist, dass es eine oder mehrere hier beschriebene Operationen durchführt.
    • 6B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein weiteres beispielhaftes System veranschaulicht, das so konfiguriert ist, dass es eine oder mehrere hier beschriebene Operationen durchführt.
    • 6C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein weiteres beispielhaftes System veranschaulicht, das so konfiguriert ist, dass es einen Smart Contract (intelligenter Vertrag) verwendet.
    • 6D ist eine Darstellung, die gemäß beispielhaften Ausführungsformen ein weiteres beispielhaftes System veranschaulicht, das so konfiguriert ist, dass es eine Blockchain verwendet.
    • 7A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen einen Prozess veranschaulicht, bei dem ein neuer Block zu einem Distributed Ledger (verteiltes Kontenbuch) hinzugefügt wird.
    • 7B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen den Dateninhalt eines neuen Datenblocks veranschaulicht.
    • 7C ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine Blockchain für digitalen Inhalt veranschaulicht.
    • 7D ist eine Darstellung, die einen Block veranschaulicht, der gemäß beispielhaften Ausführungsformen die Struktur von Blöcken in der Blockchain darstellen kann.
    • 8A ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine beispielhafte Blockchain veranschaulicht, die Daten zum maschinellen Lernen (künstliche Intelligenz) speichert.
    • 8B ist eine Darstellung, die gemäß beispielhaften Ausführungsformen eine beispielhafte quantensichere Blockchain veranschaulicht.
    • 9 ist eine Darstellung, die ein beispielhaftes System veranschaulicht, das eine oder mehrere der beispielhaften Ausführungsformen unterstützt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Es versteht sich, dass die unmittelbaren Komponenten, die in den Figuren hier allgemein beschrieben und veranschaulicht sind, in vielen verschiedenen Konfigurationen angeordnet und ausgeführt sein können. Die folgende ausführliche Beschreibung der Ausführungsformen mindestens eines Verfahrens, einer Vorrichtung, eines nichtflüchtigen, durch einen Computer lesbaren Mediums und eines Systems, wie in den beigefügten Figuren dargestellt, soll daher den Anwendungsbereich der beanspruchten Anmeldung nicht einschränken, sondern stellt lediglich ausgewählte Ausführungsformen dar.
  • Die in dieser Beschreibung dargelegten unmittelbaren Merkmale, Strukturen oder Eigenschaften können in jeder geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert oder entfernt werden. Die Ausdrücke „beispielhafte Ausführungsformen“, „einige Ausführungsformen“ oder andere ähnliche Begriffe in dieser Beschreibung beziehen sich darauf, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform enthalten sein kann. Daher beziehen sich die Ausdrücke „beispielhafte Ausführungsformen“, „in einigen Ausführungsformen“, „in anderen Ausführungsformen“ oder ähnliche Begriffe in dieser Beschreibung nicht unbedingt alle auf dieselbe Gruppe von Ausführungsformen, und die beschriebenen Merkmale, Strukturen oder Eigenschaften können in geeigneter Weise in einer oder mehreren Ausführungsformen kombiniert oder entfernt werden. Weiterhin kann in den Darstellungen jede Verbindung zwischen Elementen eine einseitige und/oder zweiseitige Datenübertragung ermöglichen, auch wenn die dargestellte Verbindung ein einseitiger oder zweiseitiger Pfeil ist. Ferner kann jede in den Zeichnungen dargestellte Einheit eine andere Einheit sein. Wenn zum Beispiel eine mobile Einheit gezeigt wird, die Informationen sendet, könnte auch eine drahtgebundene Einheit verwendet werden, um die Informationen zu senden.
  • Auch wenn in der Beschreibung der Ausführungsformen der Begriff „Nachricht“ verwendet wird, kann die Anwendung auf viele Arten von Netzwerken und Daten angewendet werden. Bestimmte Arten von Verbindungen, Nachrichten und Signalübertragungen können darüber hinaus zwar in beispielhaften Ausführungsformen dargestellt werden, die Anwendung ist jedoch nicht auf eine bestimmte Art von Verbindung, Nachricht und Signalübertragung beschränkt.
  • Beispielhafte Ausführungsformen stellen Verfahren, Systeme, Komponenten, nichtflüchtige, durch einen Computer lesbare Medien, Einheiten und/oder Netzwerke bereit, die sich auf einen Schlüsselwiederherstellungsprozess auf der Grundlage einer vergesslichen Pseudozufallsfunktion (OPRF) beziehen.
  • In einer Ausführungsform verwendet diese Anwendung eine dezentrale Datenbank (z.B. eine Blockchain), bei der es sich um ein verteiltes Speichersystem handelt, das mehrere Knoten umfasst, die untereinander Daten austauschen. Die dezentrale Datenbank umfasst eine unveränderliche „Append-only“-Datenstruktur (append-only = nur hinzufügen), die einem Distributed Ledger ähnelt und in der Lage ist, Datensätze zwischen gegenseitig nichtvertrauenswürdigen Parteien zu verwalten. Die nichtvertrauenswürdigen Parteien werden hier als Peers oder Peer-Knoten bezeichnet. Jeder Peer verwaltet eine Kopie der Datenbanksätze, und kein Peer alleine kann die Datenbanksätze ändern, ohne dass darüber ein Konsens zwischen den verteilten Peers erzielt wird. Die Peers können beispielsweise ein Konsensprotokoll ausführen, um Blockchain-Speichertransaktionen zu validieren, die Speichertransaktionen in Blöcke zu gruppieren und eine Hash-Kette über die Blöcke zu erzeugen. Dieser Prozess führt zur Bildung des Ledger, indem die Speichertransaktionen so in eine Reihenfolge gebracht werden, wie es für die Konsistenz erforderlich ist. In verschiedenen Ausführungsformen kann eine genehmigungspflichtige und/oder eine genehmigungsfreie Blockchain verwendet werden. Bei einer öffentlichen oder genehmigungsfreien Blockchain kann jeder teilnehmen, ohne dass eine bestimmte Identität erforderlich ist. Öffentliche Blockchains können native Kryptowährungen umfassen und verwenden einen Konsens auf der Grundlage verschiedener Protokolle wie z.B. Proof-of-Work (PoW). Andererseits stellt eine genehmigungspflichtige Blockchain-Datenbank sichere Interaktionen zwischen einer Gruppe von Entitäten bereit, die ein gemeinsames Ziel verfolgen, sich jedoch gegenseitig nicht vollständig vertrauen, z.B. Unternehmen, die Geldmittel, Waren, Informationen und Ähnliches austauschen.
  • Die vorliegende Anwendung kann eine Blockchain verwenden, die eine beliebige, programmierbare Logik ausführt, die auf ein dezentrales Schema zur Datenspeicherung zugeschnitten ist und als „Smart Contracts“ der „Chaincodes“ bezeichnet wird. In einigen Fällen können spezielle Chaincodes für Verwaltungsfunktionen und Parameter zur Verfügung stehen, die als System-Chaincode bezeichnet werden. Die Anwendung kann weiterhin Smart Contracts verwenden, bei denen es sich um vertrauenswürdige verteilte Anwendungen handelt, die fälschungssichere Eigenschaften der Blockchain-Datenbank und eine zugrunde liegende Vereinbarung zwischen den Knoten nutzen, die als Endorsement (Bestätigung) oder Endorsement Policy (Bestätigungsrichtlinie) bezeichnet wird. Blockchain-Transaktionen, die dieser Anwendung zugehörig sind, können „bestätigt“ werden, bevor sie in der Blockchain festgeschrieben (committed) werden, während nichtbestätigte Transaktionen ignoriert werden. Eine Endorsement Policy ermöglicht einem Chaincode, Endorser (Bestätiger) für eine Transaktion in Form eines Satzes von Peer-Knoten anzugeben, die für die Bestätigung notwendig sind. Wenn ein Client die Transaktion an die in der Endorsement Policy angegebenen Peers sendet, wird die Transaktion ausgeführt, um die Transaktion zu validieren. Nach dem Validieren beginnt eine Sortierphase für die Transaktionen, in der ein Konsensprotokoll verwendet wird, um eine geordnete Folge von bestätigten Transaktionen zu erstellen, die in Blöcken gruppiert sind.
  • Die vorliegende Anwendung kann Knoten verwenden, bei denen es sich um die Datenübertragungsentitäten des Blockchain-Systems handelt. Ein „Knoten“ kann eine logische Funktion in dem Sinne durchführen, dass mehrere Knoten unterschiedlichen Typs auf demselben physischen Server laufen können. Knoten werden in Vertrauensbereichen gruppiert und sind logischen Entitäten zugehörig, die sie auf verschiedene Weise steuern. Die Knoten können verschiedene Typen umfassen, z.B. einen Client- oder sendenden Client-Knoten, der einen Transaktionsaufruf an einen Endorser (z.B. einen Peer) sendet und Transaktionsvorschläge an einen Sortierdienst (ordering service) (z.B. einen Sortierknoten (ordering node)) übermittelt. Ein anderer Typ von Knoten ist ein Peer-Knoten, der vom Client gesendete Transaktionen empfangen, die Transaktionen festschreiben und einen Zustand und eine Kopie des Ledger der Blockchain-Transaktionen verwalten kann. Peers können auch die Rolle eines Endorser übernehmen, was jedoch nicht zwingend erforderlich ist. Ein Sortierdienstknoten oder Sortierer (orderer) ist ein Knoten, der den Datenübertragungsdienst für alle Knoten durchführt und eine Zustellungsgarantie implementiert, z.B. eine Übertragung an alle Peer-Knoten im System, wenn Transaktionen festgeschrieben werden und ein aktueller Zustand (World State) der Blockchain geändert wird, was ein anderer Name für die anfängliche Blockchain-Transaktion ist, die normalerweise Steuerungs- und Einrichtungsinformationen umfasst.
  • Die vorliegende Anwendung kann ein Ledger verwenden, bei dem es sich um eine sequenzierte, fälschungssichere Aufzeichnung aller Zustandswechsel einer Blockchain handelt. Zustandswechsel können sich aus Chaincode-Aufrufen (d.h. Transaktionen) ergeben, die von beteiligten Parteien (z.B. Client-Knoten, Sortierknoten, Endorser-Knoten, Peer-Knoten usw.) gesendet werden. Jede teilnehmende Partei (z.B. ein Peer-Knoten) kann eine Kopie des Ledger unterhalten. Eine Transaktion kann dazu führen, dass ein Satz von Asset-Schlüssel-Wert-Paaren als ein oder mehrere Operanden im Ledger festgeschrieben werden, z.B. Erzeugen, Aktualisieren, Löschen und Ähnliches. Das Ledger umfasst eine Blockchain (auch als Chain bezeichnet), in der ein unveränderlicher, sequenzierter Datensatz in Blöcken gespeichert wird. Das Ledger umfasst auch eine Zustandsdatenbank, in der ein aktueller Zustand der Blockchain festgehalten wird.
  • Die vorliegende Anwendung kann eine Chain verwenden, bei der es sich um ein Transaktionsprotokoll handelt, das als Hash-verknüpfte Blöcke strukturiert ist, wobei jeder Block eine Sequenz von N Transaktionen enthält, wobei N gleich oder größer als eins ist. Der Blockkopf umfasst einen Hash der Transaktionen des Blocks sowie einen Hash des Kopfes des vorherigen Blocks. Auf diese Weise können alle Transaktionen im Ledger sequenziert und kryptografisch miteinander verknüpft werden. Es ist daher nicht möglich, die Ledger-Daten zu manipulieren, ohne die Hash-Verknüpfungen zu beschädigen. Ein Hash eines zuletzt hinzugefügten Blockchain-Blocks stellt jede Transaktion in der Chain dar, die vor ihm stattgefunden hat, wodurch sichergestellt werden kann, dass sich alle Peer-Knoten in einem einheitlichen und vertrauenswürdigen Zustand befinden. Die Chain kann in einem Peer-Knoten-Dateisystem gespeichert werden (d.h. lokal, in einem angeschlossenen Speicher, in der Cloud usw.), wodurch der Append-only-Charakter der Arbeitslast der Blockchain wirksam unterstützt wird.
  • Der aktuelle Zustand des unveränderlichen Ledger stellt die neuesten Werte für alle Schlüssel dar, die im Transaktionsprotokoll der Chain enthalten sind. Da der aktuelle Zustand die neuesten Schlüsselwerte darstellt, die einem Kanal bekannt sind, wird er manchmal auch als „World State“ bezeichnet. Chaincode-Aufrufe führen mit den Daten des aktuellen Zustands des Ledger Transaktionen aus. Damit diese Chaincode-Interaktionen effizient sind, können die aktuellen Werte der Schlüssel in einer Zustandsdatenbank gespeichert werden. Die Zustandsdatenbank kann einfach eine indizierte Ansicht des Transaktionsprotokolls der Chain sein, daher kann sie jederzeit anhand der Chain neu erzeugt werden. Die Zustandsdatenbank kann automatisch wiederhergestellt (oder bei Bedarf erzeugt) werden, wenn der Peer-Knoten gestartet wird und bevor Transaktionen angenommen werden.
  • Asymmetrische Schlüsselpaare (private und öffentliche digitale Schlüsselpaare) werden häufig zum Sichern von Informationen verwendet. Blockchain-Clients können einen privaten Schlüssel verwenden, um Daten zu ver- und entschlüsseln, die an andere Teilnehmer der Blockchain gesendet werden. In diesem Beispiel kennt nur der Client den privaten Schlüssel. In der Zwischenzeit kann ein entsprechender öffentlicher Schlüssel des privaten Schlüssels unter den anderen Teilnehmern der Blockchain geteilt und zum Entschlüsseln/Verschlüsseln von Daten verwendet werden. Wenn der private Schlüssel jedoch verloren geht (z.B. eine Einheit, auf der der private Schlüssel gespeichert ist, zerstört wird, verloren geht, nicht mehr funktionsfähig ist, usw.), gehen auch die Daten verloren, die mit diesem privaten Schlüssel verschlüsselt sind. Ein Client kann daher den privaten Schlüssel bei einem Dritten (z.B. einem entfernt angeordneten Server usw.) speichern, sollte der private Schlüssel jemals verloren gehen.
  • Um den privaten Schlüssel zum Beispiel vom Server abzurufen, kann der Client ein Kennwort für die Anmeldung bereitstellen. Die auf Kennwort beruhende Authentifizierung ermöglicht es dem Client (mit Kenntnis des Kennworts), den privaten Schlüssel zu erhalten. Entitäten, die nicht über das Kennwort verfügen, können dagegen den privaten Schlüssel nicht erhalten. Die auf Kennwort beruhende Authentifizierung ist jedoch anfällig für böswillige Angriffe. Wenn der Client den privaten Schlüssel zum Beispiel an den entfernt angeordneten Server sendet, kann der Client einen Authentifizierungsprozess mit dem Server einrichten, der auch ein Kennwort umfasst. Der Server kann eine mit Salt versehene und gehashte Form des Kennworts speichern. Wenn der Client den privaten Schlüssel erhalten möchte, stellt er das entsprechende Kennwort wie bei einem Anmeldeprozess bereit. Wenn der Server böswillig ist, kann er in diesem Fall das Kennwort durch einen Brute-Force-Wörterverzeichnisangriff auf das Kennwort oder durch einfaches Abfangen der Anmeldung herausfinden.
  • Die beispielhaften Ausführungsformen stellen einen neuen Mechanismus bereit, mit dem eine auf Kennwort beruhende Authentifizierung durchgeführt werden kann, ohne dass der private Schlüssel für Brute-Force-Angriffe anfällig ist. Ein privater Schlüssel kann insbesondere mit einem Verschlüsselungsschlüssel verschlüsselt werden. Der verschlüsselte private Schlüssel kann in diesem Fall einem oder mehreren Blockchain-Peers bereitgestellt und sogar in der Blockchain gespeichert werden. Der private Schlüssel kann weiterhin in eine Mehrzahl von Schlüsselwerten (z.B. Zufallswerte) umgewandelt werden, und eine vergessliche Pseudozufallsfunktion (OPRF) kann verwendet werden, um die Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen umzuwandeln. In diesem Beispiel kann die OPRF ein Kennwort (geheime Eingabe) vom Client erhalten und die Mehrzahl von Schlüsselanteilen auf der Grundlage des Kennworts erzeugen. Die Schlüsselanteile können unter einer Mehrzahl von Blockchain-Peers verteilt werden.
  • Wenn der Client den privaten Schlüssel wiederherstellen möchte, fordert der Client die Schlüsselanteile von der Mehrzahl von Blockchain-Peers an. In diesem Fall benötigt der Client eine zuvor festgelegte Anzahl von Schlüsselanteilen, um den Verschlüsselungsschlüssel wiederherzustellen. Um die Schlüsselanteile zurück in die Mehrzahl von Schlüsseln umzuwandeln, gibt der Client die Schlüsselanteile und das Kennwort in das OPRF-Programm ein, das die Mehrzahl von Schlüsseln ausgibt. Der Client kann dann den Verschlüsselungsschlüssel von der Mehrzahl von Schlüsseln wiederherstellen. Der Client kann anschließend den verschlüsselten privaten Schlüssel von einem Blockchain-Peer anfordern und den verschlüsselten privaten Schlüssel auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels entschlüsseln.
  • Zu einigen der Vorteile des hier beschriebenen OPRF-Prozesses gehört der Schutz des Kennworts vor böswilligen Clients und böswilligen Peers (Servern). Böswillige Clients, die versuchen, Brute-Force-Anmeldeversuche durchzuführen und/oder an Informationen zu gelangen, die auf dem Server gespeichert sind, werden davon abgehalten, das Kennwort in Erfahrung zu bringen, da das Kennwort nicht auf dem Server gespeichert ist oder nicht für ihn zugänglich ist. Das Kennwort bleibt stattdessen während des gesamten Prozesses beim Client. Darüber hinaus wird verhindert, dass Server, die versuchen, Wörterverzeichnisangriffe oder Abfangangriffe offline durchzuführen, das Kennwort erhalten, da die Server das Kennwort nicht speichern. Jeder Schlüsselanteil sieht ferner zufällig aus.
  • 1A veranschaulicht einen Prozess 100A zum Speichern eines verschlüsselten privaten Schlüssels 101' in einem Blockchain-Netzwerk gemäß beispielhaften Ausführungsformen. Mit Bezug auf 1A kann eine Client-Anwendung (z.B. ein Blockchain-Client usw.) einen privaten Schlüssel 101 von einer Blockchain-Brieftasche (wallet) (nicht dargestellt) empfangen. In diesem Fall kann der private Schlüssel 101 Teil eines asymmetrischen Schlüsselpaares sein, das einen entsprechenden öffentlichen Schlüssel enthält, der der Blockchain-Brieftasche zugehörig ist. In diesem Beispiel kann die Client-Anwendung 110 den privaten Schlüssel 101 auf der Grundlage eines Verschlüsselungsschlüssels 102 verschlüsseln, um einen verschlüsselten privaten Schlüssel 101' zu erzeugen.
  • Gemäß verschiedenen Ausführungsformen kann die Client-Anwendung 110 den verschlüsselten privaten Schlüssel 101' und eine Gebühr in einem oder mehreren Blockchain-Peers 131, 132, 133 und 134 eines Blockchain-Netzwerks speichern, die eine Blockchain 130 verwalten. Zusätzlich zum Verschlüsseln des privaten Schlüssels 101 kann auch die Gebühr, die den Blockchain-Peers 131, 132, 133 und 134 zugewiesen werden soll, verschlüsselt werden, um zu verhindern, dass die Blockchain-Peers die Gebühr ausgeben. In diesem Beispiel kann es sich bei den Blockchain-Peers 131 bis 134 um Server handeln, die ein Blockchain-Ledger ausführen, das unter allen Blockchain-Peers 131 bis 134 verteilt/repliziert wird. Bei der Gebühr kann es sich um eine Vergütung handeln, die in einer Transaktion enthalten ist, die in der Blockchain 130 gespeichert wird. Wenn die Client-Anwendung 110 anschließend den verschlüsselten privaten Schlüssel 101' von den Blockchain-Peers 131 bis 134 anfordert, kann die Client-Anwendung 110 die Gebührentransaktion entschlüsseln und die entschlüsselte Gebühr einem der Blockchain-Peers 131 bis 134 bereitstellen. Als Reaktion darauf können die Blockchain-Peers 131 bis 134 die entsprechende Transaktion ausführen, die Gebühr einziehen und den verschlüsselten privaten Schlüssel zurücksenden (wie in 1D dargestellt).
  • 1B veranschaulicht einen Prozess 100B zum Umwandeln des Verschlüsselungsschlüssels 102 in Schlüsselanteile 122A bis 122D mit einem Dienst einer vergesslichen Pseudozufallsfunktion (OPRF) 120 gemäß beispielhaften Ausführungsformen. Mit Bezug auf 1B kann die Client-Anwendung 110 eine Mehrzahl von Schlüsseln 112A, 112B, 112C und 112D auf der Grundlage des Verschlüsselungsschlüssels 102 erzeugen. In diesem Fall kann es sich bei den Schlüsseln 112A bis 112D um Pseudozufallswerte handeln, die aus dem Verschlüsselungsschlüssel 102 extrahiert werden usw. Die Anzahl der Schlüssel 112A bis 112D kann in diesem Fall auf der Anzahl von Blockchain-Peers des Netzwerks oder der von der Client-Anwendung 110 verwendeten beruhen. Bei den Schlüsseln 11A bis 112D kann es sich zum Beispiel um Zufallswerte handeln, die gleichmäßig aus einer größeren Primzahl entnommen werden. Die Schlüssel 112A bis 112D werden so erzeugt, dass sie zum Wiederherstellen des Verschlüsselungsschlüssels 102 mit einem OPRF-Protokoll verwendet werden können.
  • In den beispielhaften Ausführungsformen verfügt ein Benutzer 111 (z.B. der Client-Anwendung 110 zugehörig) über ein Kennwort 114 oder einen anderen geheimen Wert. Bei dem Kennwort 114 kann es sich in diesem Fall um einen Textwert oder einen alphanumerischen Wert handeln, den nur der Benutzer 111 kennt. Die Schlüssel 112A bis 112D können von der Client-Anwendung 110 ausgegeben und in einen OPRF-Dienst 120 eingegeben werden. Das Kennwort 114 kann auch über eine Benutzerschnittstelle (nicht dargestellt) der Benutzereinheit ausgegeben und in den OPRF-Dienst 120 eingegeben werden. In diesem Beispiel kann der OPRF-Dienst 120 in die Client-Anwendung 110 (in einer Client-Einheit) integriert sein, oder es kann sich um einen eigenständigen Dienst handeln, der auf der Client-Einheit ausgeführt wird. Der OPRF-Dienst 120 kann die Mehrzahl von Schlüsseln 112A bis 112D in eine Mehrzahl von OPRF-Schlüsseln 122A bis 122D über ein OPRF-Protokoll umwandeln, das das Kennwort 114 verwendet, um die OPRF-Schlüssel 122A bis 122D mit dem Kennwort 114 zu verknüpfen, sodass nur der Benutzer 111 (der das Kennwort 114 kennt) die Schlüssel 112A bis 112D wiederherstellen kann.
  • Um jeden OPRF-Schlüssel 122A, 122B, 122C und 122D zu erzeugen, kann der OPRF-Dienst 120 eine zuvor festgelegte Funktion fK(x) ausführen.
  • In diesem Beispiel ist f der OPRF-Algorithmus, K ist der Eingabewert, der einem Blockchain-Peer (z.B. einer der Schlüssel 112A bis 112D) zugehörig ist, und x ist ein geheimer Wert (z.B. das Kennwort 114) von der Client-Anwendung 110. Die Funktion fK ist ein Zwei-Parteien-Protokoll, das als Eingabe einen Schlüssel (einen der Schlüssel 112A bis 112D) und einen geheimen Wert (Kennwort 114) nimmt und einen OPRF-Schlüssel 122A bis 122D zurücksendet, der mit dem bestimmten Kennwort 114 des Benutzers 111 verknüpft ist. Der OPRF-Dienst 120 kann zum Beispiel den Schlüssel 112A und das Kennwort 114 als Eingaben erhalten und den OPRF-Schlüssel 112A ausgeben, der dem Blockchain-Peer 131 zugewiesen ist. Dieser Prozess kann für jeden der Blockchain-Peers 131 bis 134 durchgeführt werden. Der OPRF-Dienst 120 kann die OPRF-Schlüssel 122A bis 122D parallel (gleichzeitig), sequenziell (z.B. einen nach dem anderen), teilweise zeitlich überlappend usw. erzeugen. Zu Beispielen für die OPRF-Funktion (f) gehören unter anderem DH-OPRF und Naor-Reingold, ohne auf diese beschränkt zu sein. Darüber hinaus werden die OPRF-Schlüssel 122A bis 122D jeweils an die Mehrzahl von Blockchain-Peers 131 bis 134 verteilt. Die Blockchain-Peers 131 bis 134 erfahren daher nichts über das Kennwort 114.
  • Bei der Funktion fK handelt es sich um eine Pseudozufallsfunktion, wenn sie wirksam berechenbar ist, wobei K zufällig ausgewählt wird und kein leistungsfähiger Algorithmus fK von einer Zufallsfunktion unterscheiden kann. Die Client-Anwendung 110 kann ferner jeden der Schlüssel 112A bis 112D jeweils einem der Blockchain-Peers 131 bis 134 zuordnen. In diesem System handelt es sich bei dem OPRF-Protokoll im Wesentlichen um ein Zwei-Parteien-Protokoll zwischen der Client-Anwendung 110 und einem entsprechenden Blockchain-Peer 131 bis 134, wobei der Client eine Eingabe x bereitstellt und der Blockchain-Peer mit der Eingabe K registriert wird, und nach dem Protokoll berechnet der Client fK(x) so, dass die Blockchain-Peers nichts über das Kennwort 114 erfahren.
  • 1C veranschaulicht einen Prozess 100C zum Wiederherstellen des Verschlüsselungsschlüssels 102 gemäß beispielhaften Ausführungsformen. In diesem Beispiel kann der OPRF-Dienst 120 den Verschlüsselungsschlüssel 102 auf der Grundlage der OPRF-Schlüssel 122A bis 122D, die in den Blockchain-Peers 131 bis 134 im Prozess 100B von 1B gespeichert werden, und dem vom Benutzer 111 bereitgestellten Kennwort 114 wiederherstellen. Mit Bezug auf 1C empfängt der OPRF-Dienst 120 die Mehrzahl von OPRF-Schlüsseln 122A bis 122D, die jeweils von der Mehrzahl von Peers 131 bis 134 gespeichert werden, und empfängt das Kennwort 114 vom Benutzer 111. Es ist nicht notwendig, dass der OPRF-Dienst 10 alle OPRF-Schlüssel 122A bis 122D empfängt, wenn das verwendete Schema für die geheime gemeinsame Nutzung nur einen zuvor festgelegten Schwellenwert (z.B. ein Quorum usw.) von Schlüsseln erfordert, um den Verschlüsselungsschlüssel 102 wiederherzustellen. In diesem Fall kann der OPRF-Dienst 120 die OPRF-Schlüssel 122A bis 122D bewerten, wenn der Benutzer 111 das Kennwort 114 bereitstellt. Der OPRF-Dienst 120 kann die OPRF-Funktion fK(x) ausführen, um die Mehrzahl von Schlüsseln 112A bis 112D wiederherzustellen. Als Nächstes kann der OPRF-Dienst 120 oder die Client-Anwendung 110 den Verschlüsselungsschlüssel 102 von der Mehrzahl von Schlüsseln 112A bis 112D wiederherstellen, der zum Entschlüsseln des verschlüsselten privaten Schlüssels 101' verwendet werden kann, um den privaten Schlüssel 101 offenzulegen.
  • 1D veranschaulicht einen Prozess 100D zum Entschlüsseln einer Gebührentransaktion und Abrufen des verschlüsselten privaten Schlüssels 101' von den Blockchain-Peers 131 bis 134 gemäß beispielhaften Ausführungsformen. Mit Bezug auf 1D hat die Client-Anwendung 110 den Verschlüsselungsschlüssel 102 auf der Grundlage der Mehrzahl von Schlüsseln 112A bis 112D wie im Beispiel von 1C beschrieben wiederhergestellt. In diesem Beispiel kann die Client-Anwendung 110 die Gebührentransaktion, die in den Blockchain-Peers 131 bis 134 gespeichert ist, auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels 102 entschlüsseln und die entschlüsselte Transaktion gegen den verschlüsselten privaten Schlüssel 101' austauschen. In diesem Beispiel leitet die Client-Anwendung 110 die entschlüsselte Transaktion an jeden der Blockchain-Peers 131 bis 134 weiter, damit diese die Zahlung erhalten können. Als Nächstes können einer oder mehrere der Blockchain-Peers 131 bis 134 den verschlüsselten privaten Schlüssel 101' zurücksenden. Als Reaktion darauf kann die Client-Anwendung 110 den verschlüsselten privaten Schlüssel 101' entschlüsseln, um den ursprünglichen privaten Schlüssel 101 wiederherzustellen.
  • 2A veranschaulicht eine Konfiguration 200 einer Blockchain-Architektur gemäß beispielhaften Ausführungsformen. Mit Bezug auf 2A kann die Blockchain-Architektur 200 bestimmte Blockchain-Elemente enthalten, so beispielsweise eine Gruppe von Blockchain-Knoten 202. Die Blockchain-Knoten 202 können einen oder mehrere Knoten 204 bis 210 umfassen (diese vier Knoten sind nur beispielhaft dargestellt). Diese Knoten sind an einer Reihe von Aktivitäten beteiligt, z.B. am Hinzufügen von Blockchain-Transaktionen und am Validierungsprozess (Konsens). Ein oder mehrere Blockchain-Knoten 204 bis 210 können Transaktionen auf der Grundlage einer Endorsement Policy bestätigen und einen Sortierdienst für alle Blockchain-Knoten in der Architektur 200 bereitstellen. Ein Blockchain-Knoten kann eine Blockchain-Authentifizierung initiieren und versuchen, in ein unveränderliches Blockchain-Ledger zu schreiben, das in der Blockchain-Schicht 216 gespeichert ist, von der eine Kopie auch in der zugrunde liegenden physischen Infrastruktur 214 gespeichert sein kann. Die Blockchain-Konfiguration kann eine oder mehrere Anwendungen 224 umfassen, die mit Anwendungsprogrammierschnittstellen (APIs) 222 verbunden sind, um auf gespeicherten Programm-/Anwendungscode 220 (z.B. Chaincode, Smart Contracts usw.) zuzugreifen und diesen auszuführen, der entsprechend einer von den Teilnehmern gewünschten individuellen Konfiguration erzeugt werden kann und der seinen eigenen Zustand aufrechterhalten, seine eigenen Assets kontrollieren und externe Informationen empfangen kann. Dies kann als Transaktion implementiert und durch Anhängen an das Distributed Ledger auf allen Blockchain-Knoten 204 bis 210 implementiert werden.
  • Die Blockchain-Basis oder -Plattform 212 kann verschiedene Schichten von Blockchain-Daten, Diensten (z.B. kryptographische Vertrauensdienste, virtuelle Ausführungsumgebung usw.) und die zugrunde liegende physische Computerinfrastruktur umfassen, die dazu verwendet werden kann, neue Transaktionen zu empfangen und zu speichern und Prüfern, die auf Dateneinträge zugreifen wollen, den Zugriff bereitzustellen. Die Blockchain-Schicht 216 kann eine Schnittstelle zur Verfügung stellen, die den Zugriff auf die virtuelle Ausführungsumgebung bereitstellt, die erforderlich ist, um den Programmcode zu verarbeiten und die physische Infrastruktur 214 zu nutzen. Die kryptografischen Vertrauensdienste 218 können verwendet werden, um Transaktionen wie den Austausch von Assets zu überprüfen und Informationen vertraulich zu halten.
  • Die Konfiguration der Blockchain-Architektur von 2A kann Programm-/ Anwendungscode 220 über eine oder mehrere von der Blockchain-Plattform 212 zur Verfügung gestellte Schnittstellen und bereitgestellte Dienste verarbeiten und ausführen. Der Code 220 kann Assets in der Blockchain kontrollieren. Der Code 220 kann beispielsweise Daten speichern und übertragen und von den Knoten 204 bis 210 in Form eines Smart Contract und eines zugehörigen Chaincodes mit Bedingungen oder anderen Codeelementen ausgeführt werden, die seiner Ausführung unterliegen. In einem nichteinschränkenden Beispiel können Smart Contracts erzeugt werden, um Erinnerungen, Aktualisierungen und/oder Mitteilungen aufgrund von Änderungen, Aktualisierungen usw. auszuführen. Die Smart Contracts können ihrerseits dazu verwendet werden, Regeln zu identifizieren, die den Autorisierungs- und Zugriffsanforderungen und der Nutzung des Ledger zugehörig sind. Der Smart Contract (oder der Chaincode, der die Logik des Smart Contract ausführt) kann zum Beispiel die Blockchain-Daten 226 lesen, die von einer oder mehreren Verarbeitungsentitäten (z.B. virtuelle Maschinen) verarbeitet werden können, die in der Blockchain-Schicht 216 enthalten sind, um im Rahmen eines komplexen Dienstszenarios die Ergebnisse 228 einschließlich Warnungen zu erzeugen, die Haftung festzulegen und Ähnliches. Die physische Infrastruktur 214 kann zum Abrufen der hier beschriebenen Daten oder Informationen verwendet werden.
  • Ein Smart Contract kann über eine hochentwickelte Anwendung und Programmiersprache erzeugt und dann in einen Block in der Blockchain geschrieben werden. Der Smart Contract kann einen ausführbaren Code enthalten, der in einer Blockchain (z.B. einem verteilten Netzwerk von Blockchain-Peers) registriert, gespeichert und/oder repliziert wird. Eine Transaktion ist eine Ausführung der Logik des Smart Contract, die als Reaktion auf Bedingungen, die dem Smart Contract zugehörig sind, durchgeführt werden kann. Das Ausführen des Smart Contract kann (eine) vertrauenswürdige Änderung(en) eines Zustands eines digitalen Blockchain-Ledger auslösen. Die durch das Ausführen des Smart Contract verursachte(n) Änderung(en) des Blockchain-Ledger kann (können) automatisch im gesamten verteilten Netzwerk von Blockchain-Peers durch ein oder mehrere Konsensprotokolle repliziert werden.
  • Der Smart Contract kann Daten im Format von Schlüssel-Wert-Paaren in die Blockchain schreiben. Darüber hinaus kann der Code des Smart Contract die in einer Blockchain gespeicherten Werte lesen und in Operationen der Anwendung verwenden. Der Code des Smart Contract kann die Ausgabe verschiedener logischer Operationen in einen oder mehrere Blöcke in der Blockchain schreiben. Der Code kann dazu verwendet werden, eine temporäre Datenstruktur in einer virtuellen Maschine oder einer anderen Datenverarbeitungsplattform zu erzeugen. Daten, die in die Blockchain geschriebenen werden, können öffentlich sein und/oder verschlüsselt und als vertraulich behandelt werden. Die temporären Daten, die vom Smart Contract verwendet/erzeugt werden, werden von der bereitgestellten Ausführungsumgebung im Speicher gespeichert und dann gelöscht, sobald die für die Blockchain benötigten Daten identifiziert sind.
  • Ein Chaincode kann die Code-Interpretation (z.B. die Logik) eines Smart Contract enthalten. Der Chaincode kann zum Beispiel eine standardmäßige und implementierbare Version der Logik im Smart Contract enthalten. Wie hier beschrieben, kann es sich bei dem Chaincode um einen Programmcode handeln, der in einem Datenverarbeitungsnetzwerk implementiert wird, wo er von den Chain-Validierern im Rahmen eines Konsensverfahrens ausgeführt und validiert wird. Der Chaincode kann einen Hash empfangen und aus der Blockchain einen Hash abrufen, der der Datenvorlage zugehörig ist, die durch die Verwendung eines zuvor gespeicherten Merkmalsextraktors erzeugt wurde. Stimmen die Hashes der Hash-Kennung und der aus den gespeicherten Kennungsvorlagedaten erzeugte Hash überein, sendet der Chaincode einen Autorisierungsschlüssel an den angeforderten Dienst. Der Chaincode kann Daten in die Blockchain schreiben, die den kryptografischen Einzelheiten zugehörig sind.
  • 2B veranschaulicht ein Beispiel für einen Blockchain-Transaktionsablauf 250 zwischen Knoten der Blockchain gemäß einer beispielhaften Ausführungsform. Mit Bezug auf 2B kann der Transaktionsablauf einen Client-Knoten 260 umfassen, der einen Transaktionsvorschlag 291 an einen bestätigenden Peer-Knoten 281 übermittelt. Der bestätigende Peer 281 kann die Client-Signatur prüfen und eine Chaincode-Funktion ausführen, um die Transaktion zu initiieren. Die Ausgabe kann die Chaincode-Ergebnisse, einen Satz von Schlüssel/Wert-Versionen, die im Chaincode gelesen wurden (Lesesatz), und den Satz von Schlüsseln/Werten, die in den Chaincode geschrieben wurden (Schreibsatz), umfassen. In diesem Fall kann der bestätigende Peer 281 ermitteln, ob der Transaktionsvorschlag bestätigt wird. Die Antwort 292 auf den Vorschlag wird zusammen mit einer Bestätigungssignatur (falls genehmigt) an den Client 260 zurückgesendet. Der Client 260 stellt die Bestätigungen in den Transaktionsnutzdaten 293 zusammen und übertragt diese an einen Sortierdienstknoten 284. Der Sortierdienstknoten 284 gibt dann die sortierten Transaktionen als Blöcke an alle Peers 281 bis 283 in einem Kanal aus. Vor dem Festschreiben in der Blockchain kann jeder Peer 281 bis 283 die Transaktion validieren. So können die Peers beispielsweise die Endorsement Policy überprüfen, um sicherzustellen, dass die richtige Anzahl der angegebenen Peers die Ergebnisse signiert und die Signaturen anhand der Transaktionsnutzdaten 293 authentifiziert hat.
  • Mit erneutem Bezug auf 2B initiiert der Client-Knoten die Transaktion 291, indem er eine Anforderung an den Peer-Knoten 281 erzeugt und sendet, bei dem es sich um einen Endorser handelt. Der Client 260 kann eine Anwendung umfassen, die ein unterstütztes Software-Entwicklungskit (software development kit - SDK) nutzt, das eine verfügbare API verwendet, um einen Transaktionsvorschlag zu erzeugen. Bei dem Vorschlag handelt es sich um eine Anforderung, eine Chaincode-Funktion aufzurufen, damit Daten gelesen und/oder in das Ledger geschrieben werden können (d.h., neue Schlüssel-Wert-Paare für die Assets schreiben). Das SDK kann als Shim dienen, um den Transaktionsvorschlag in ein geeignetes Architekturformat zu packen (z.B. Protokollpuffer über einen Fernprozeduraufruf (remote procedure call - RPC)) und die kryptografischen Berechtigungsnachweise des Clients zu verwenden, um eine eindeutige Signatur für den Transaktionsvorschlag zu erzeugen.
  • Als Reaktion darauf kann der bestätigende Peer-Knoten 281 prüfen, ob (a) der Transaktionsvorschlag korrekt formatiert ist, (b) die Transaktion nicht bereits in der Vergangenheit gesendet wurde (Schutz vor Wiederholungsangriffen), (c) die Signatur gültig ist und (d) dass der Sender (im Beispiel der Client 260) ordnungsgemäß berechtigt ist, die vorgeschlagene Operation auf diesem Kanal durchzuführen. Der bestätigende Peer-Knoten 281 kann die Eingaben des Transaktionsvorschlags als Argumente für die aufgerufene Chaincode-Funktion verwenden. Der Chaincode wird dann auf der Grundlage einer Datenbank mit dem aktuellen Zustand ausgeführt, um Transaktionsergebnisse zu erzeugen, darunter ein Antwortwert, ein Lesesatz und ein Schreibsatz. Das Ledger wird zu diesem Zeitpunkt jedoch nicht aktualisiert. In Schritt 292 werden der Satz von Werten zusammen mit der Signatur des bestätigenden Peer-Knotens 281 als Antwort 292 auf den Vorschlag an das SDK des Clients 260 zurückgesendet, der die Nutzdaten für die Anwendung zur Nutzung parst.
  • Als Reaktion darauf überprüft/verifiziert die Anwendung des Clients 260 die Signaturen der bestätigenden Peers und vergleicht die Vorschlagsantworten, um zu ermitteln, ob die Vorschlagsantwort dieselbe ist. Würde der Chaincode nur das Ledger abfragen, würde die Anwendung die Antwort auf die Abfrage überprüfen und die Transaktion in der Regel nicht an den Sortierdienstknoten 284 senden. Beabsichtigt die Client-Anwendung, die Transaktion zum Aktualisieren des Ledger an den Sortierknotendienst 284 zu senden, entscheidet die Anwendung vor dem Senden, ob die angegebene Endorsement Policy erfüllt ist (d.h., haben alle für die Transaktion erforderlichen Peer-Knoten die Transaktion bestätigt). In diesem Fall kann der Client nur eine von mehreren an der Transaktion beteiligten Parteien aufnehmen. In diesem Fall kann jeder Client seinen eigenen bestätigenden Knoten haben, und jeder bestätigende Knoten muss die Transaktion bestätigen. Die Architektur ist so angelegt, dass die Endorsement Policy auch dann von den Peers bestätigt und in der Phase des Festschreibens und Validierens aufrechterhalten wird, wenn eine Anwendung sich dafür entscheidet, Antworten nicht zu überprüfen oder ansonsten eine nichtbestätigte Transaktion weiterzuleiten.
  • Nach erfolgreichem Überprüfen stellt der Client 260 in Schritt 293 Bestätigungen zu einem Transaktionsvorschlag zusammen und sendet den Transaktionsvorschlag und die Antwort in einer Transaktionsnachricht an den Sortierknoten 284. Die Transaktion kann die Lese-/Schreibsätze, die Signaturen der bestätigenden Peers und eine Kanal-ID enthalten. Der Sortierknoten 284 muss nicht den gesamten Inhalt einer Transaktion überprüfen, um seine Operation durchzuführen; stattdessen kann der Sortierknoten 284 einfach Transaktionen von allen Kanälen im Netzwerk empfangen, sie chronologisch nach Kanal sortieren und Blöcke von Transaktionen pro Kanal erzeugen.
  • Die Blöcke werden vom Sortierknoten 284 an alle Peer-Knoten 281 bis 283 im Kanal übermittelt. Der Datenabschnitt im Block kann validiert werden, um sicherzustellen, dass eine Endorsement Policy erfüllt wird und dass keine Änderungen am Zustand des Ledger für die Variablen des Lesesatzes vorgenommen wurden, seit der Lesesatz durch das Ausführen der Transaktion erzeugt wurde. Darüber hinaus fügt jeder Peer-Knoten 281 bis 283 in Schritt 295 den Block an die Chain des Kanals an, und für jede gültige Transaktion werden die Schreibsätze in der aktuellen Zustandsdatenbank festgeschrieben. Ein Ereignis kann ausgelöst werden, um die Client-Anwendung darüber zu informieren, dass die Transaktion (der Aufruf) unveränderlich an die Chain angehängt wurde, und um mitzuteilen, ob die Transaktion für gültig oder ungültig erklärt wurde.
  • 3A veranschaulicht ein Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk 300, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 302 eine Transaktion in der genehmigungspflichtigen Blockchain 304 beginnen. In diesem Beispiel kann es sich bei der Transaktion um Implementieren, Aufrufen oder Abfragen handeln, und sie kann über eine clientseitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können den Zugriff auf einen Regulierer 306, z.B. einen Prüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 308 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 306 als „Auditor“ und des Blockchain-Benutzers 302 als „Client“. Ein Prüfer könnte darauf beschränkt sein, nur das Ledger abzufragen, während ein Client berechtigt sein könnte, bestimmte Arten von Chaincode zu implementieren, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 310 kann Chaincode und clientseitige Anwendungen schreiben. Der Blockchain-Entwickler 310 kann Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 312 in Chaincode zu integrieren, kann der Entwickler 310 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel verbindet sich der Blockchain-Benutzer 302 über einen Peer-Knoten 314 mit der genehmigungspflichtigen Blockchain 304. Bevor der Peer-Knoten 314 mit den Transaktionen fortfährt, ruft er die Anmelde- und Transaktionszertifikate des Benutzers von einer Zertifizierungsstelle 316 ab, die Benutzerrollen und -genehmigungen verwaltet. In einigen Fällen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 304 Transaktionen durchführen zu können. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 312 überprüfen. Um die Berechtigung des Benutzers zu bestätigen, kann der Chaincode eine Out-of-Band-Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 318 nutzen.
  • 3B veranschaulicht ein weiteres Beispiel für ein genehmigungspflichtiges Blockchain-Netzwerk 320, das eine verteilte, dezentrale Peer-to-Peer-Architektur aufweist. In diesem Beispiel kann ein Blockchain-Benutzer 322 eine Transaktion an die genehmigungspflichtige Blockchain 324 senden. In diesem Beispiel kann es sich bei der Transaktion um Implementieren, Aufrufen oder Abfragen handeln, und sie kann über eine clientseitige Anwendung, die ein SDK nutzt, direkt über eine API usw. ausgegeben werden. Netzwerke können den Zugriff auf einen Regulierer 326, z.B. einen Prüfer, bereitstellen. Ein Blockchain-Netzwerkbetreiber 328 verwaltet die Genehmigungen der Mitglieder, z.B. Anmelden des Regulierers 326 als „Auditor“ und des Blockchain-Benutzers 322 als „Client“. Ein Prüfer könnte darauf beschränkt sein, nur das Ledger abzufragen, während ein Client berechtigt sein könnte, bestimmte Arten von Chaincode zu implementieren, aufzurufen und abzufragen.
  • Ein Blockchain-Entwickler 330 schreibt Chaincode und clientseitige Anwendungen. Der Blockchain-Entwickler 330 kann Chaincode über eine Schnittstelle direkt in dem Netzwerk implementieren. Um Berechtigungsnachweise aus einer herkömmlichen Datenquelle 332 in Chaincode zu integrieren, kann der Entwickler 330 eine Out-of-Band-Verbindung verwenden, um auf die Daten zuzugreifen. In diesem Beispiel verbindet sich der Blockchain-Benutzer 322 über einen Peer-Knoten 334 mit dem Netzwerk. Bevor der Peer-Knoten 334 mit den Transaktionen fortfährt, ruft er die Anmelde- und Transaktionszertifikate des Benutzers von der Zertifizierungsstelle 336 ab, die die Rollen und Genehmigungen der Benutzer verwaltet. In einigen Fällen müssen die Benutzer der Blockchain diese digitalen Zertifikate besitzen, um in der genehmigungspflichtigen Blockchain 324 Transaktionen durchführen zu können. In der Zwischenzeit muss ein Benutzer, der Chaincode verwenden möchte, unter Umständen seine Berechtigungsnachweise in der herkömmlichen Datenquelle 332 überprüfen. Um die Berechtigung des Benutzers zu bestätigen, kann der Chaincode eine Out-of-Band-Verbindung zu diesen Daten über eine herkömmliche Verarbeitungsplattform 338 nutzen.
  • In einigen Ausführungsformen kann es sich bei der vorliegenden Blockchain um eine genehmigungsfreie Blockchain handeln. Im Gegensatz zu genehmigungspflichtigen Blockchains, für die eine Genehmigung zum Beitritt erforderlich ist, kann einer genehmigungsfreien Blockchain jeder beitreten. Um einer genehmigungsfreien Blockchain beizutreten, kann ein Benutzer beispielsweise eine persönliche Adresse erzeugen und beginnen, mit dem Netzwerk zu interagieren, indem er Transaktionen sendet und damit Einträge in das Ledger hinzufügt. Darüber hinaus haben alle Parteien die Möglichkeit, einen Knoten im System auszuführen und die Mining-Protokolle zum Überprüfen von Transaktionen zu verwenden.
  • 3C veranschaulicht einen Prozess 350 einer Transaktion, die von einer genehmigungsfreien Blockchain 352 verarbeitet wird und eine Mehrzahl von Knoten 354 umfasst. Ein Sender 356 möchte eine Zahlung oder ein beliebiges anderes werthaltiges Gut (z.B. eine Urkunde, medizinische Dokumente, einen Vertrag, eine Ware, eine Dienstleistung oder beliebige andere Assets, die in einen digitalen Datensatz eingebunden werden können) über die genehmigungsfreie Blockchain 352 an einen Empfänger 358 senden. In einer Ausführungsform können sowohl die Sendeeinheit 356 als auch die Empfängereinheit 358 über digitale Brieftaschen (die der Blockchain 352 zugehörig sind) verfügen, die Steuerungen der Benutzerschnittstelle und eine Anzeige der Transaktionsparameter bereitstellen. Daraufhin wird die Transaktion über die Blockchain 352 an die Knoten 354 übertragen. Je nach den Netzwerkparametern der Blockchain 352 überprüfen die Knoten 360 die Transaktion auf der Grundlage von Regeln (die vordefiniert oder dynamisch zugeordnet werden können), die von den Erzeugern der genehmigungsfreien Blockchain 352 aufgestellt wurden. Dies kann z.B. Überprüfen der Identität der beteiligten Parteien umfassen usw. Die Transaktion kann sofort überprüft werden oder in eine Warteschlange mit anderen Transaktionen gestellt werden, und die Knoten 354 ermitteln auf der Grundlage eines Satzes von Netzwerkregeln, ob die Transaktionen gültig sind.
  • In der Struktur 362 werden gültige Transaktionen zu einem Block zusammengefasst und mit einer Sperre (Hash) gesichert. Dieser Prozess kann durch Mining-Knoten unter den Knoten 354 durchgeführt werden. Mining-Knoten können zusätzliche Software speziell für das Mining und Erzeugen von Blöcken für die genehmigungsfreie Blockchain 352 verwenden. Jeder Block kann durch einen Hash (z.B. Bitzahl 256 usw.) identifiziert werden, der mit einem vom Netzwerk vereinbarten Algorithmus erzeugt wird. Jeder Block kann einen Kopf, einen Zeiger oder einen Verweis auf einen Hash des Kopfes des vorherigen Blocks in der Chain und eine Gruppe gültiger Transaktionen umfassen. Der Verweis auf den Hash des vorherigen Blocks ist dem Erzeugen der sicheren, unabhängigen Chain von Blöcken zugehörig.
  • Bevor Blöcke zur Blockchain hinzugefügt werden können, müssen die Blöcke validiert werden. Das Validieren der genehmigungsfreien Blockchain 352 kann ein Proof-of-Work (PoW) umfassen, bei der es sich um eine Lösung eines Rätsels handelt, das aus dem Kopf des Blocks abgeleitet wird. Zwar ist dies im Beispiel von 3C nicht dargestellt, doch ist ein weiterer Prozess zum Überprüfen eines Blocks der Proof-of-Stake. Im Gegensatz zum Proof-of-Work, bei dem der Algorithmus Miner belohnt, die mathematische Probleme lösen, wird beim Proof-of-Stake der Erzeuger eines neuen Blocks auf deterministische Weise ausgewählt, abhängig von seinem Vermögen, das auch als „Stake“ definiert ist. Anschließend wird ein ähnlicher Nachweis von dem ausgewählten Knoten durchgeführt.
  • Beim Mining 364 versuchen Knoten, den Block zu lösen, indem sie schrittweise Änderungen an einer Variablen vornehmen, bis die Lösung ein netzwerkweites Ziel erfüllt. Auf diese Weise wird der PoW erzeugt und stellt auf diese Weise richtige Antworten sicher. Mit anderen Worten: eine potenzielle Lösung muss nachweisen, dass zum Lösen des Problems Datenverarbeitungsressourcen eingesetzt wurden. Bei einigen Arten von genehmigungsfreien Blockchains können Miner für ein korrektes Mining eines Blocks mit etwas von Wert (z.B. Münzen usw.) belohnt werden.
  • In diesem Fall macht der PoW-Prozess zusammen mit dem Chaining von Blöcken Änderungen an der Blockchain extrem schwierig, da ein Angreifer alle nachfolgenden Blöcke ändern muss, damit die Änderungen an einem Block akzeptiert werden. Außerdem nimmt mit dem Mining neuer Blöcke die Schwierigkeit zu, einen Block zu verändern, und die Zahl der nachfolgenden Blöcke steigt. Bei der Verteilung 366 wird der erfolgreich validierte Block über die genehmigungsfreie Blockchain 352 verteilt, und alle Knoten 354 fügen den Block zu einer Mehrheits-Chain hinzu, bei der es sich um das auditierbare Ledger der genehmigungsfreien Blockchain 352 handelt. Außerdem wird der Wert in der vom Sender 356 gesendeten Transaktion in der digitalen Brieftasche der Empfängereinheit 358 hinterlegt oder in anderer Weise an sie übertragen.
  • 4A veranschaulicht gemäß beispielhaften Ausführungsformen einen Datenübertragungsprozess 400A zum Erzeugen und Verteilen von OPRF-Schlüsseln. Mit Bezug auf 4A verfügt ein Client 410 über ein öffentliches und privates Schlüsselpaar (pk, sk). In diesem Beispiel verschlüsselt der Client den privaten Schlüssel (sk) mit einem Verschlüsselungsschlüssel und sendet eine Mehrzahl von Transaktionen an eine Mehrzahl von Blockchain-Peers 421, 422, 423 und 424 in 430, 431, 432 bzw. 433, um ein Backup des verschlüsselten privaten Schlüssels (sk) zu speichern. Jede Transaktion kann den verschlüsselten privaten Schlüssel und eine Gebühr/Vergütung enthalten, wenn der Client 410 den verschlüsselten privaten Schlüssel wiederherstellen muss. In diesem Fall ist die Anzahl der Blockchain-Peers nicht auf vier beschränkt, sondern kann jede vom Protokoll gewünschte Schwellenwertzahl sein.
  • In Schritt 434 erzeugt der Client 410 einen OPRF-Schlüssel für jeden der Blockchain-Peers 421 bis 424. Zunächst kann der Client 410 eine Mehrzahl von Schlüsseln erzeugen, die zum Wiederherstellen der Verschlüsselungsschlüssel verwendet werden können. Als Nächstes wandelt der Client 410 die Mehrzahl von Schlüsseln in eine Mehrzahl von OPRF-Schlüsseln auf der Grundlage eines Benutzerkennworts um. Für jede Organisation (Peer) kann der Client 410 einen OPRF-Schlüssel nach dem Zufallsprinzip auf der Grundlage einer zuvor festgelegten Funktion fK(x) erzeugen, die den Schlüssel und das Kennwort als Eingabe empfängt und einen OPRF-Schlüssel ausgibt. Der genannte Schritt 434 wird iterativ oder gleichzeitig durchgeführt, um eine Mehrzahl von OPRF-Schlüsseln für die Blockchain-Peers 421 bis 424 zu erzeugen. Der Client 410 verteilt die Mehrzahl von OPRF-Schlüsseln an die Mehrzahl von Blockchain-Peers 421 bis 424 in den Schritten 435, 436, 437 bzw. 438.
  • Die Schritte 430 bis 433 werden zwar als durchgeführte Schritte 434 bis 438 in 4A dargestellt, es sei jedoch darauf hingewiesen, dass die Schritte 430 bis 433 nach den Schritten 434 bis 438 und/oder gleichzeitig mit den Schritten 430 bis 433 durchgeführt werden können. Mit anderen Worten: die Reihenfolge der Schritte 430 bis 438 ist nicht auf das in 4A dargestellte und beschriebene Beispiel beschränkt.
  • 4B veranschaulicht einen Datenübertragungsprozess 400B zum Wiederherstellen eines Verschlüsselungsschlüssels auf der Grundlage der verteilten OPRF-Schlüssel gemäß beispielhaften Ausführungsformen. Mit Bezug auf 4B überträgt der Client-Dienst 410 in Schritt 440 eine Anforderung an die Blockchain-Peers 421 bis 424 für die OPRF-Schlüssel. Die Anforderung kann an alle Peers 421 bis 424 gesendet werden. Als Reaktion darauf können die Blockchain-Peers 421 bis 424 in den Schritten 441, 442, 443 und 444 die für den Client-Dienst 410 gespeicherten jeweiligen OPRF-Schlüssel übertragen. In Schritt 445 kann der Client 410 die Ausführung der OPRF-Funktion (Dienst) auslösen, um die empfangenen OPRF-Schlüssel in die entsprechenden Schlüssel umzuwandeln, die zum Wiederherstellen des Verschlüsselungsschlüssels verwendet werden können. In diesem Fall kann ein Benutzer ein Kennwort eingeben, das zusammen mit den OPRF-Schlüsseln in die OPRF-Funktion eingegeben wird. Die OPRF-Funktion gibt die Originalschlüssel aus. Der Client 410 kann den Verschlüsselungsschlüssel auf der Grundlage der Schlüssel in Schritt 445 wiederherstellen. In Schritt 446 kann der Client 410 einen verschlüsselten privaten Schlüssel von einem der Blockchain-Peers anfordern. In diesem Fall empfängt der Client den verschlüsselten privaten Schlüssel in Schritt 447 von dem Blockchain-Peer 421. Der Client 410 entschlüsselt den privaten Schlüssel anschließend in Schritt 448 und verwendet den privaten Schlüssel, um eine Blockchain-Transaktion, eine Blockchain-Nachricht, eine Blockchain-Anforderung usw. zu signieren.
  • 5 veranschaulicht ein Verfahren 500 zum Verteilen eines Verschlüsselungsschlüssels unter Peers eines Blockchain-Netzwerks gemäß beispielhaften Ausführungsformen. Als nichteinschränkendes Beispiel kann das Verfahren 500 von einer Client-Anwendung durchgeführt werden, die in einer Datenverarbeitungseinheit wie einem Smartphone, einem Tablet, einem Laptop, einem Desktop, einem Server, einer Cloud-Plattform usw. ausgeführt wird. Mit Bezug auf 5 kann das Verfahren in Schritt 510 Verschlüsseln eines privaten Schlüssels mit einem Verschlüsselungsschlüssel umfassen. Der Verschlüsselungsschlüssel kann in diesem Fall vom Client erzeugt werden.
  • In Schritt 520 kann das Verfahren Erzeugen einer Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels und Umwandeln der Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes umfassen. Bei der geheimen Eingabe kann es sich um ein Kennwort handeln, das nur der Client kennt. In Schritt 530 kann das Verfahren Speichern des verschlüsselten privaten Schlüssels in einer Blockchain umfassen. Der Client kann den verschlüsselten privaten Schlüssel zum Beispiel an eine Mehrzahl von Blockchain-Peers der Blockchain übertragen. In Schritt 540 kann das Verfahren Verteilen der Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain umfassen, wobei das Verteilen Übertragen eines anderen Schlüsselanteils von der Mehrzahl der Schlüsselanteile an jeden Blockchain-Peer der Mehrzahl von Blockchain-Peers umfasst.
  • In einigen Ausführungsformen kann die Mehrzahl von Schlüsseln eine Mehrzahl von Pseudozufallswerten umfassen, und das Verfahren kann weiterhin jeweils Registrieren der Mehrzahl von Pseudozufallswerten in der Mehrzahl von Blockchain-Peers umfassen. In einigen Ausführungsformen kann das Umwandeln Ausführen einer vergesslichen Pseudozufallsfunktion (OPRF) umfassen, die einen Schlüssel von der Mehrzahl von Schlüsseln und den geheimen Eingabewert empfängt und einen Schlüsselanteil für den entsprechenden Schlüssel ausgibt. In einigen Ausführungsformen kann das Umwandeln weiterhin iteratives Ausführen der OPRF für jeden Schlüssel der Mehrzahl von Schlüsseln auf der Grundlage des geheimen Eingabewertes umfassen, um jeden Schlüsselanteil der Mehrzahl von Schlüsselanteilen auszugeben.
  • In einigen Ausführungsformen kann das Speichern Verteilen einer Blockchain-Transaktion an die Mehrzahl von Blockchain-Peers umfassen, wobei die Blockchain-Transaktion den verschlüsselten privaten Schlüssel und einen Zahlungswert aufweist. In einigen Ausführungsformen kann das Verfahren weiterhin Abrufen der Mehrzahl von Schlüsselanteilen von der Mehrzahl von Blockchain-Peers und Zurückumwandeln der Mehrzahl von Schlüsselanteilen in die Mehrzahl von Schlüsseln auf der Grundlage des geheimen Eingabewertes umfassen. In einigen Ausführungsformen kann das Verfahren weiterhin Wiederherstellen des Verschlüsselungsschlüssels von der Mehrzahl von Schlüsseln und Entschlüsseln des verschlüsselten privaten Schlüssels auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels umfassen.
  • In einigen Ausführungsformen kann das Verfahren weiterhin Wiederherstellen des Verschlüsselungsschlüssels von der Mehrzahl von Schlüsseln und Entschlüsseln einer Gebührentransaktion, die von der Mehrzahl von Blockchain-Peers gespeichert werden, auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels umfassen. In diesem Beispiel kann das Verfahren weiterhin Übertragen der entschlüsselten Gebührentransaktion an einen Blockchain-Peer der Mehrzahl, Empfangen des verschlüsselten privaten Schlüssels von dem Blockchain-Peer im Austausch für die entschlüsselte Gebührentransaktion und Entschlüsseln des verschlüsselten privaten Schlüssels auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels umfassen.
  • 6A veranschaulicht ein beispielhaftes System 600, das eine physische Infrastruktur 610 umfasst, die so konfiguriert ist, dass sie verschiedene Operationen gemäß beispielhaften Ausführungsformen durchführt. Mit Bezug auf 6A umfasst die physische Infrastruktur 610 ein Modul 612 und ein Modul 614. Das Modul 614 umfasst eine Blockchain 620 und einen Smart Contract 630 (der sich in der Blockchain 620 befinden kann), der jeden der in einer der beispielhaften Ausführungsformen enthaltenen operativen Schritte 608 (in Modul 612) ausführen kann. Die Schritte/Operationen 608 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen umfassen und können ausgegebene oder geschriebene Informationen darstellen, die in einen oder mehrere Smart Contracts 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Die physische Infrastruktur 610, das Modul 612 und das Modul 614 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 612 und das Modul 614 ein und dasselbe Modul sein.
  • 6B veranschaulicht ein weiteres beispielhaftes System 640, das so konfiguriert ist, dass es verschiedene Operationen gemäß beispielhaften Ausführungsformen durchführt. Mit Bezug auf 6B umfasst das System 640 ein Modul 612 und ein Modul 614. Das Modul 614 umfasst eine Blockchain 620 und einen Smart Contract 630 (der sich in der Blockchain 620 befinden kann), der jeden der in einer der beispielhaften Ausführungsformen enthaltenen operativen Schritte 608 (in Modul 612) ausführen kann. Die Schritte/Operationen 608 können eine oder mehrere der beschriebenen oder dargestellten Ausführungsformen umfassen und können ausgegebene oder geschriebene Informationen darstellen, die in einen oder mehrere Smart Contracts 630 und/oder Blockchains 620 geschrieben oder daraus gelesen werden. Die physische Infrastruktur 610, das Modul 612 und das Modul 614 können einen oder mehrere Computer, Server, Prozessoren, Speicher und/oder drahtlose Datenübertragungseinheiten umfassen. Weiterhin können das Modul 612 und das Modul 614 ein und dasselbe Modul sein.
  • 6C veranschaulicht ein beispielhaftes System, das so konfiguriert ist, dass es eine Konfiguration eines Smart Contract zwischen Vertragsparteien und einem vermittelnden Server verwendet, der so konfiguriert ist, dass er die Bedingungen des Smart Contract in der Blockchain gemäß beispielhaften Ausführungsformen umsetzt. Mit Bezug auf 6C kann die Konfiguration 650 eine Datenübertragungssitzung, eine Asset-Übertragungssitzung oder einen Prozess oder eine Prozedur darstellen, die durch einen Smart Contract 630 gesteuert wird, der ausdrücklich eine oder mehrere Benutzereinheiten 652 und/oder 656 identifiziert. Die Ausführung, die Operationen und die Ergebnisse der Ausführung des Smart Contract können von einem Server 654 verwaltet werden. Der Inhalt des Smart Contract 630 kann digitale Signaturen von einer oder mehreren der Entitäten 652 und 656 erfordern, die an der Transaktion des Smart Contract beteiligt sind. Die Ergebnisse der Ausführung des Smart Contract können als Blockchain-Transaktion in eine Blockchain 620 geschrieben werden. Der Smart Contract 630 befindet sich in der Blockchain 620, die sich in einem oder mehreren Computern, Servern, Prozessoren, Speichern und/oder drahtlosen Datenübertragungseinheiten befinden kann.
  • 6D veranschaulicht ein System 660, das eine Blockchain gemäß beispielhaften Ausführungsformen umfasst. Mit Bezug auf das Beispiel von 6D stellt ein Anwendungsprogrammierschnittstellen(API)-Gateway 662 eine gemeinsame Schnittstelle für den Zugriff auf eine Blockchain-Logik (z.B. Smart Contract 630 oder anderer Chaincode) und Daten (z.B. Distributed Ledger usw.) bereit. In diesem Beispiel ist das API-Gateway 662 eine gemeinsame Schnittstelle zum Durchführen von Transaktionen (Aufrufe, Abfragen usw.) in der Blockchain, indem eine oder mehrere Entitäten 652 und 656 mit einem Blockchain-Peer (d.h. einem Server 654) verbunden werden. In diesem Fall ist der Server 654 eine Peer-Komponente des Blockchain-Netzwerks, die eine Kopie des World State (allgemeiner Zustand) und ein Distributed Ledger enthält, das es den Clients 652 und 656 ermöglicht, Daten über den World State abzufragen und Transaktionen an das Blockchain-Netzwerk zu senden, wo die bestätigenden Peers die Smart Contracts 630 je nach Smart Contract 630 und Endorsement Policy ausführen werden.
  • Die vorstehenden Ausführungsformen können in Hardware, in einem von einem Prozessor ausgeführten Computerprogramm, in Firmware oder in einer Kombination der vorstehend Genannten implementiert werden. Ein Computerprogramm kann auf einem durch einen Computer lesbaren Medium wie beispielsweise einem Speichermedium ausgeführt werden. Ein Computerprogramm kann sich beispielsweise in einem Direktzugriffsspeicher („RAM“), einem Flash-Speicher, einem Nur-Lese-Speicher („ROM“), einem löschbaren programmierbaren Nur-Lese-Speicher („EPROM“), einem elektrisch löschbaren programmierbaren Nur-Lese-Speicher („EEPROM“), in Registern, auf einer Festplatte, auf einer Wechselplatte, in einem Compact-Disc-Nur-Lese-Speicher („CD-ROM“) oder auf jeder anderen in der Technik bekannten Form von Speichermedium befinden.
  • Ein beispielhaftes Speichermedium kann mit dem Prozessor verbunden werden, sodass der Prozessor Informationen aus dem Speichermedium lesen und in das Speichermedium schreiben kann. Alternativ kann das Speichermedium in den Prozessor integriert sein. Der Prozessor und das Speichermedium können sich in einer anwendungsspezifischen integrierten Schaltung („ASIC“) befinden. Alternativ können der Prozessor und das Speichermedium als einzelne Komponenten vorliegen.
  • 7A veranschaulicht einen Prozess 700, bei dem gemäß beispielhaften Ausführungsformen ein neuer Block zu einem Distributed Ledger 720 hinzugefügt wird, und 7B veranschaulicht gemäß beispielhaften Ausführungsformen den Inhalt einer neuen Datenblockstruktur 730 für eine Blockchain. Mit Bezug auf 7A können Clients (nicht dargestellt) Transaktionen an die Blockchain-Knoten 711, 712 und/oder 713 senden. Clients können Anweisungen sein, die von einer beliebigen Quelle empfangen werden, um eine Aktivität in der Blockchain 720 auszuführen. Bei den Clients kann es sich beispielsweise um Anwendungen handeln, die im Namen eines Anforderers, z.B. einer Einheit, einer Person oder einer Entität, handeln, um Transaktionen für die Blockchain vorzuschlagen. Die Mehrzahl von Blockchain-Peers (z.B. die Blockchain-Knoten 711, 712 und 713) können einen Zustand des Blockchain-Netzwerks und eine Kopie des Distributed Ledger 720 speichern. Im Blockchain-Netzwerk können verschiedene Arten von Blockchain-Knoten/Peers vorhanden sein, z.B. bestätigende Peers, die von Clients vorgeschlagene Transaktionen simulieren und bestätigen, und festschreibende Peers, die Bestätigungen überprüfen, Transaktionen validieren und diese im Distributed Leder 720 festschreiben. In diesem Beispiel können die Blockchain-Knoten 711, 712 und 713 die Rolle eines Endorser-Knotens, eines festschreibenden Knotens oder beider durchführen.
  • Das Distributed Ledger 720 umfasst eine Blockchain, die unveränderliche, sequenzierte Datensätze in Blöcken speichert, und eine Zustandsdatenbank 724 (aktueller World State), in der ein aktueller Zustand der Blockchain 722 gespeichert ist. Pro Kanal kann ein Distributed Ledger 720 vorhanden sein, und jeder Peer unterhält seine eigene Kopie des Distributed Ledger 720 für jeden Kanal, dessen Mitglied er ist. Die Blockchain 722 ist ein Transaktionsprotokoll, das in Form von Hash-verknüpften Blöcken aufgebaut ist, wobei jeder Block eine Folge von N Transaktionen enthält. Blöcke können verschiedene Komponenten umfassen, wie z.B. in 7B dargestellt. Die Verknüpfung der Blöcke (in 7A durch Pfeile dargestellt) kann durch Hinzufügen eines Hash des Kopfes eines früheren Blocks in einen Blockkopf eines aktuellen Blocks erzeugt werden. Auf diese Weise werden alle Transaktionen in der Blockchain 722 sequenziert und kryptografisch miteinander verknüpft, um eine Manipulation der Blockchain-Daten zu verhindern, ohne die Hash-Verknüpfungen zu unterbrechen. Aufgrund der Verknüpfungen stellt der letzte Block in der Blockchain 722 außerdem jede Transaktion, die vor ihm stattgefunden hat, dar. Die Blockchain 722 kann in einem Peer-Dateisystem (lokaler oder angeschlossener Speicher) gespeichert werden, das eine Append-only-Blockchain-Arbeitslast unterstützt.
  • Der aktuelle Zustand der Blockchain 722 und des Distributed Ledger 722 kann in der Zustandsdatenbank 724 gespeichert werden. In diesem Fall stellen die Daten des aktuellen Zustands die neuesten Werte für alle jemals im Chain-Transaktionsprotokoll der Blockchain 722 enthaltenen Schlüssel dar. Chaincode-Aufrufe führen Transaktionen auf der Grundlage des aktuellen Zustands in der Zustandsdatenbank 724 aus. Damit diese Chaincode-Interaktionen höchst effizient sind, werden die aktuellen Werte aller Schlüssel in der Zustandsdatenbank 724 gespeichert. Die Zustandsdatenbank 724 kann eine indizierte Ansicht des Transaktionsprotokolls der Blockchain 722 enthalten und kann daher jederzeit aus der Chain neu erzeugt werden. Die Zustandsdatenbank 724 kann automatisch wiederhergestellt (oder bei Bedarf erzeugt) werden, wenn der Peer-Knoten gestartet wird und bevor Transaktionen angenommen werden.
  • Bestätigende Knoten empfangen Transaktionen von Clients und bestätigen die Transaktion auf der Grundlage simulierter Ergebnisse. Bestätigende Knoten enthalten Smart Contracts, die die Transaktionsvorschläge simulieren. Wenn ein bestätigender Knoten eine Transaktion bestätigt, erzeugen die bestätigenden Knoten eine Transaktionsbestätigung, bei der es sich um eine signierte Antwort des bestätigenden Knotens an die Client-Anwendung handelt, die die Bestätigung der simulierten Transaktion anzeigt. Das Verfahren zum Bestätigen einer Transaktion hängt von einer Endorsement Policy ab, die im Chaincode festgelegt werden kann. Ein Beispiel für eine Endorsement Policy ist „die Mehrheit der bestätigenden Peers muss die Transaktion bestätigen“. Verschiedene Kanäle können unterschiedliche Endorsement Policies aufweisen. Bestätigte Transaktionen werden von der Client-Anwendung an den Sortierdienst 710 weitergeleitet.
  • Der Sortierdienst 710 lässt bestätigte Transaktionen zu, ordnet sie in einem Block an und übermittelt die Blöcke an die festschreibenden Peers. Beispielsweise kann der Sortierdienst 710 einen neuen Block initiieren, wenn ein Schwellenwert an Transaktionen erreicht wurde, ein Zeitgeber abgelaufen ist oder eine andere Bedingung vorliegt. In dem Beispiel von 7A handelt es sich bei dem Blockchain-Knoten 712 um einen festschreibenden Peer, der einen neuen Datenblock 730 zum Speichern in der Blockchain 720 empfangen hat. Der erste Block in der Blockchain kann als Genesis-Block bezeichnet werden, der Informationen über die Blockchain, ihre Mitglieder, die darin gespeicherten Daten usw. enthält.
  • Der Sortierdienst 710 kann aus einer Gruppe von Sortierern zusammengesetzt sein. Der Sortierdienst 710 verarbeitet keine Transaktionen und Smart Contracts und führt auch nicht das gemeinsam genutzte Ledger. Vielmehr kann der Sortierdienst 710 die bestätigten Transaktionen annehmen, und er legt die Reihenfolge fest, in der diese Transaktionen im Distributed Ledger 720 festgeschrieben werden. Die Architektur des Blockchain-Netzwerks kann so ausgelegt werden, dass die spezifische Implementierung des „Sortierens“ (z.B. Solo, Kafka, BFT usw.) zu einer integrierbaren Komponente wird.
  • Transaktionen werden in einer konsistenten Reihenfolge in das Distributed Ledger 720 geschrieben. Die Reihenfolge der Transaktionen wird festgelegt, um sicherzustellen, dass die Aktualisierungen der Zustandsdatenbank 724 gültig sind, wenn sie im Netzwerk festgeschrieben werden. Im Gegensatz zu einem Blockchain-System für Kryptowährungen (z.B. Bitcoin usw.), bei dem das Sortieren durch das Lösen eines kryptografischen Rätsels oder durch Mining erfolgt, können die Parteien des Distributed Ledger 720 in diesem Beispiel den Sortiermechanismus wählen, der am besten zu diesem Netzwerk passt.
  • Wenn der Sortierdienst 710 einen neuen Datenblock 730 initialisiert, kann der neue Datenblock 730 an die festschreibenden Peers (z.B. die Blockchain-Knoten 711, 712 und 713) übertragen werden. Daraufhin überprüft jeder festschreibende Peer die Transaktion im neuen Datenblock 730, indem er sicherstellt, dass der Lese- und der Schreibsatz immer noch mit dem aktuellen World State in der Zustandsdatenbank 724 übereinstimmen. Konkret heißt dies, dass der festschreibende Peer ermitteln kann, ob die gelesenen Daten, die vorhanden waren, als die Endorser die Transaktion simulierten, mit dem aktuellen World State in der Zustandsdatenbank 724 identisch sind. Wenn der festschreibende Peer die Transaktion validiert, wird die Transaktion in die Blockchain 722 im Distributed Ledger 720 geschrieben, und die Zustandsdatenbank 724 wird mit den Schreibdaten aus dem Lese-/Schreibsatz aktualisiert. Wenn eine Transaktion nicht erfolgreich ist, d.h., wenn der festschreibende Peer feststellt, dass der Lese-/Schreibsatz nicht mit dem aktuellen World State in der Zustandsdatenbank 724 übereinstimmt, ist die in einem Block zusammengefasste Transaktion zwar immer noch in diesem Block enthalten, aber sie ist als ungültig gekennzeichnet, und die Zustandsdatenbank 724 wird nicht aktualisiert.
  • Mit Bezug auf 7B kann ein neuer Datenblock 730 (auch als Datenblock bezeichnet), der in der Blockchain 722 des Distributed Ledger 720 gespeichert wird, mehrere Datensegmente enthalten, z.B. einen Blockkopf 740, Blockdaten 750 (Blockdatenabschnitt) und Block-Metadaten 760. Es sei darauf hingewiesen, dass die verschiedenen dargestellten Blöcke und ihr Inhalt, z.B. der neue Datenblock 730 und sein Inhalt, die in 7B gezeigt werden, lediglich Beispiele sind und den Anwendungsbereich der beispielhaften Ausführungsformen nicht einschränken sollen. In einem herkömmlichen Block kann der Datenabschnitt Transaktionsinformationen von N Transaktionen (z.B. 1, 10, 100, 500, 1000, 2000, 3000 usw.) in den Blockdaten 750 speichern.
  • Der neue Datenblock 730 kann eine Verknüpfung zu einem früheren Block (z.B. in der Blockchain 722 in 7A) im Blockkopf 740 enthalten. Der Blockkopf 740 kann insbesondere einen Hash des Kopfes eines früheren Blocks enthalten. Der Blockkopf 740 kann auch eine eindeutige Blocknummer, einen Hash der Blockdaten 750 des neuen Datenblocks 730 und Ähnliches umfassen. Die Blocknummer des neuen Datenblocks 730 kann eindeutig sein und in verschiedenen Reihenfolgen zugewiesen werden, z.B. in einer inkrementellen/sequenziellen Reihenfolge, die bei null beginnt.
  • In den Block-Metadaten 760 können mehrere Felder mit Metadaten gespeichert werden (z.B. als Byte-Anordnung usw.). Die Metadatenfelder können eine Signatur beim Erzeugen eines Blocks, einen Verweis auf einen letzten Konfigurationsblock, ein Transaktionsfilter, das gültige und ungültige Transaktionen im Block identifiziert, den letzten verbliebenen Offset eines Sortierdienstes, der den Block sortiert hat, und Ähnliches umfassen. Die Signatur, der letzte Konfigurationsblock und die Metadaten des Sortierers können vom Sortierdienst 710 hinzugefügt werden. In der Zwischenzeit kann ein festschreibender Knoten des Blocks (z.B. der Blockchain-Knoten 712) auf der Grundlage einer Endorsement Policy, der Überprüfung von Lese-/Schreibsätzen usw. Angaben zur Gültigkeit/Ungültigkeit hinzufügen. Das Transaktionsfilter kann eine Byte-Anordnung mit einer Größe umfassen, die der Anzahl von Transaktionen in den Blockdaten 750 entspricht, sowie einen Validierungscode, der angibt, ob eine Transaktion gültig oder ungültig war.
  • 7C veranschaulicht eine Ausführungsform einer Blockchain 770 für digitalen Inhalt gemäß den hier beschriebenen Ausführungsformen. Der digitale Inhalt kann eine oder mehrere Dateien und zugehörige Informationen enthalten. Die Dateien können Medien, Bilder, Video, Audio, Text, Links, Grafiken, Animationen, Webseiten, Dokumente oder andere Formen mit digitalem Inhalt umfassen. Die unveränderlichen Append-only-Aspekte der Blockchain dienen als Schutz für die Integrität, Gültigkeit und Echtheit des digitalen Inhalts, sodass sie sich für Gerichtsverfahren eignen, in denen Zulässigkeitsregeln angewandt werden, oder für andere Situationen, in denen Beweise in Betracht gezogen werden oder in denen die Darstellung und Verwendung digitaler Informationen anderweitig von Interesse sind. In diesem Fall kann der digitale Inhalt als digitaler Nachweis bezeichnet werden.
  • Die Blockchain kann auf verschiedene Weise gebildet werden. In einer Ausführungsform kann der digitale Inhalt in der Blockchain enthalten sein, und die Blockchain selbst kann darauf zugreifen. Beispielsweise kann jeder Block der Blockchain einen Hash-Wert von Verweisinformationen (z.B. Kopf, Wert usw.) zusammen mit dem zugehörigen digitalen Inhalt speichern. Der Hash-Wert und der zugehörige digitale Inhalt können dann gemeinsam verschlüsselt werden. Auf den digitalen Inhalt jedes Blocks kann somit zugegriffen werden, indem jeder Block in der Blockchain entschlüsselt wird, und der Hash-Wert jedes Blocks kann als Grundlage für einen Verweis auf einen vorherigen Block verwendet werden. Dies lässt sich wie folgt darstellen:
    Block 1 Block 2 . . . . . . . Block N
    Hash-Wert 1 Hash-Wert 2 Hash-Wert N
    Digitaler Inhalt 1 Digitaler Inhalt2 Digitaler Inhalt N
  • In einer Ausführungsform kann der digitale Inhalt nicht in der Blockchain enthalten sein. So kann die Blockchain beispielsweise die verschlüsselten Hashes des Inhalts jedes Blocks ohne den digitalen Inhalt speichern. Der digitale Inhalt kann in Verbindung mit dem Hash-Wert der Originaldatei in einem anderen Speicherbereich oder an einer anderen Speicheradresse gespeichert werden. Bei dem anderen Speicherbereich kann es sich um dieselbe Speichereinheit handeln, die auch zum Speichern der Blockchain verwendet wird, oder um einen anderen Speicherbereich oder auch um eine gesonderte relationale Datenbank. Auf den digitalen Inhalt jedes Blocks kann durch Abrufen oder Abfragen des Hash-Wertes eines relevanten Blocks und anschließendes Suchen dieses Hash-Wertes im Speicherbereich, der in Übereinstimmung mit den tatsächlichen digitalen Inhalt gespeichert ist, verwiesen oder zugegriffen werden. Diese Operation kann z.B. von einem Datenbank-Gatekeeper durchgeführt werden. Dies lässt sich wie folgt darstellen:
    Blockchain Speicherbereich
    Block 1 Hash-Wert Block 1 Hash-Wert ... Inhalt
    · ·
    · ·
    · ·
    Block N Hash-Wert Block N Hash-Wert ... Inhalt
  • In der beispielhaften Ausführungsform von 7C umfasst die Blockchain 770 eine Anzahl von Blöcken 7781, 7782, ... 778N, die in einer geordneten Folge kryptografisch verknüpft sind, wobei N ≥ 1 ist. Bei der Verschlüsselung, die verwendet wird, um die Blöcke 7781, 7782, ... 778N zu verknüpfen, kann es sich um eine beliebige Anzahl von verschlüsselten oder unverschlüsselten Hash-Funktionen handeln. In einer Ausführungsform werden die Blöcke 7781, 7782, ... 778N einer Hash-Funktion unterzogen, die aus Eingaben, die auf den Informationen in den Blöcken beruhen, n-bit alphanumerische Ausgaben erzeugt (wobei n 256 oder eine andere Zahl ist). Zu Beispielen für eine solche Hash-Funktion gehören, ohne auf diese beschränkt zu sein, ein Algorithmus vom Typ SHA (SHA steht für Secured Hash Algorithm, sicherer Hash-Algorithmus), ein Merkle-Damgard-Algorithmus, ein HAIFA-Algorithmus, ein Merkle-Baum-Algorithmus, ein Nonce-gestützter Algorithmus und ein nichtkollisionsresistenter PRF-Algorithmus. In einer anderen Ausführungsform können die Blöcke 7781, 7782, ..., 778N durch eine andere Funktion als eine Hash-Funktion kryptografisch verknüpft werden. Zur Veranschaulichung folgt eine Beschreibung mit Verweis auf eine Hash-Funktion, z.B. SHA-2.
  • Jeder der Blöcke 7781, 7782, ..., 778N in der Blockchain umfasst einen Kopf, eine Version der Datei und einen Wert. Der Kopf und der Wert sind für jeden Block unterschiedlich, was auf das Hashing in der Blockchain zurückzuführen ist. In einer Ausführungsform kann der Wert im Kopf enthalten sein. Wie im Folgenden ausführlicher beschrieben, kann die Version der Datei die Originaldatei oder eine andere Version der Originaldatei sein.
  • Der erste Block 7781 in der Blockchain wird als Genesis-Block bezeichnet und umfasst den Kopf 7721, die Originaldatei 7741 und einen Anfangswert 7761. Das Hashing-Schema, das für den Genesis-Block und auch für alle folgenden Blöcke verwendet wird, kann unterschiedlich sein. Zum Beispiel können alle Informationen im ersten Block 7781 zusammen und auf einmal gehasht werden, oder jede Information oder ein Teil der Informationen im ersten Block 7781 kann separat gehasht werden, und dann kann ein Hash der separat gehashten Teile durchgeführt werden.
  • Der Kopf 7721 kann einen oder mehrere Anfangsparameter umfassen, die beispielsweise eine Versionsnummer, einen Zeitstempel, eine Nonce, Stamminformationen, einen Schwierigkeitsgrad, ein Konsensprotokoll, eine Dauer, ein Medienformat, eine Quelle, beschreibende Schlüsselwörter und/oder andere Informationen umfassen können, die der Originaldatei 7741 und/oder der Blockchain zugehörig sind. Der Kopf 7721 kann automatisch (z.B. durch eine Software zur Blockchain-Netzwerkverwaltung) oder manuell durch einen Blockchain-Teilnehmer erzeugt werden. Im Gegensatz zum Kopf in den anderen Blöcken 7782 bis 778N in der Blockchain verweist der Kopf 7721 im Genesis-Block nicht auf einen vorherigen Block, da es keinen vorherigen Block gibt.
  • Bei der Originaldatei 7741 im Genesis-Block kann es sich beispielsweise um Daten handeln, die von einer Einheit mit oder ohne Verarbeitung vor ihrer Aufnahme in die Blockchain erfasst wurden. Die Originaldatei 7741 wird über die Schnittstelle des Systems von der Einheit, der Medienquelle oder dem Knoten empfangen. Der Originaldatei 7741 sind Metadaten zugehörig, die z.B. von einem Benutzer, der Einheit und/oder dem Systemprozessor entweder manuell oder automatisch erzeugt werden können. Die Metadaten können im ersten Block 7781 enthalten sein, der der Originaldatei 7741 zugehörig ist.
  • Der Wert 7761 im Genesis-Block ist ein Anfangswert, der auf der Grundlage eines oder mehrerer eindeutiger Attribute der Originaldatei 7741 erzeugt wird. In einer Ausführungsform können das eine oder die mehreren eindeutigen Attribute den Hash-Wert für die Originaldatei 7741, Metadaten für die Originaldatei 7741 und andere der Datei zugehörige Informationen umfassen. In einer Implementierung kann der Anfangswert 7761 auf den folgenden eindeutigen Attributen beruhen:
    • 1) SHA-2 berechneter Hash-Wert für die Originaldatei
    • 2) ID der ursprünglichen Einheit
    • 3) Anfangszeitstempel für die Originaldatei
    • 4) Anfänglicher Speicherort der Originaldatei
    • 5) Blockchain-Netzwerk-Mitglieder-ID für Software zur aktuellen Kontrolle der Originaldatei und der zugehörigen Metadaten
  • Die anderen Blöcke 7782 bis 778N in der Blockchain verfügen ebenfalls über Köpfe, Dateien und Werte. Im Gegensatz zum ersten Block 7721 umfasst jedoch jeder der Köpfe 7722 bis 772N in den anderen Blöcken den Hash-Wert eines unmittelbar vorhergehenden Blocks. Der Hash-Wert des unmittelbar vorhergehenden Blocks kann lediglich der Hash des Kopfes des vorherigen Blocks oder der Hash-Wert des gesamten vorherigen Blocks sein. Indem der Hash-Wert eines vorhergehenden Blocks in jeden der verbleibenden Blöcke integriert wird, kann eine Rückverfolgung vom N-ten Block zurück zum Genesis-Block (und der zugehörigen Originaldatei) Block für Block durchgeführt werden, wie durch die Pfeile 780 angezeigt, um eine überprüfbare und unveränderliche Chain-of-Custody herzustellen.
  • Jeder der Köpfe 7722 bis 772N in den anderen Blöcken kann auch andere Informationen enthalten, z.B. Versionsnummer, Zeitstempel, Nonce, Stamminformationen, Schwierigkeitsgrad, Konsensprotokoll und/oder andere Parameter oder Informationen, die den entsprechenden Dateien und/oder der Blockchain im Allgemeinen zugehörig sind.
  • Die Dateien 7742 bis 774N in den anderen Blöcken können der Originaldatei entsprechen, oder es kann sich um eine geänderte Version der Originaldatei im Genesis-Block handeln, beispielsweise je nach Art der durchgeführten Verarbeitung. Die Art der durchgeführten Verarbeitung kann sich von Block zu Block unterscheiden. Das Verarbeiten kann z.B. jede Änderung einer Datei in einem vorhergehenden Block umfassen, unter anderem Redigieren von Informationen oder sonstiges Ändern des Inhalts, Entfernen von Informationen oder Hinzufügen oder Anhängen von Informationen in den Dateien.
  • Zusätzlich oder alternativ kann das Verarbeiten lediglich ein Kopieren der Datei aus einem vorhergehenden Block, Ändern eines Speicherortes der Datei, Analysieren der Datei aus einem oder mehreren vorhergehenden Blöcken, Verlagern der Datei von einem Speicherort zu einem anderen oder Durchführen von Maßnahmen in Bezug auf die Datei der Blockchain und/oder ihrer zugehörigen Metadaten umfassen. Ein Verarbeiten, das Analysieren einer Datei umfasst, kann zum Beispiel Anhängen, Einbeziehen oder anderweitiges Zuordnen verschiedener analytischer, statistischer oder anderer Informationen umfassen, die der Datei zugehörig sind.
  • Die Werte in jedem der anderen Blöcke 7762 bis 776N sind eindeutige Werte, und aufgrund der durchgeführten Verarbeitung unterscheiden sie sich alle. So entspricht beispielsweise der Wert in einem beliebigen Block einer aktualisierten Version des Wertes im vorherigen Block. Die Aktualisierung spiegelt sich im Hash des Blocks wider, dem der Wert zugewiesen ist. Die Werte der Blöcke stellen somit einen Hinweis darauf bereit, welche Verarbeitung in den Blöcken durchgeführt wurde, und ermöglichen auch eine Rückverfolgung durch die Blockchain bis zur Originaldatei. Dieses Verfolgen bestätigt die Chain-of-Custody der Datei über die gesamte Blockchain.
  • Nehmen wir zum Beispiel den Fall, dass Teile der Datei in einem vorherigen Block redigiert, ausgeblendet oder verpixelt werden, um die Identität einer in der Datei gezeigten Person zu schützen. In diesem Fall umfasst der Block mit der redigierten Datei zugehörige Metadaten, z.B. wie das Redigieren durchgeführt wurde, wer das Redigieren durchgeführt hat, Zeitstempel, die angeben, wann die Redigierung(en) vorgenommen wurde(n), usw. Die Metadaten können gehasht werden, um den Wert zu bilden. Da sich die Metadaten des Blocks von den Informationen unterscheiden, die zum Bilden des Wertes im vorherigen Block gehasht wurden, unterscheiden sich die Werte voneinander und können beim Entschlüsseln wiederhergestellt werden.
  • In einer Ausführungsform kann der Wert eines vorherigen Blocks aktualisiert werden (z.B. kann ein neuer Hash-Wert berechnet werden), um den Wert eines aktuellen Blocks zu bilden, wenn einer oder mehrere der folgenden Fälle eintreten. In dieser beispielhaften Ausführungsform kann der neue Hash-Wert durch Hashing aller oder eines Teils der unten aufgeführten Informationen berechnet werden.
    1. a) Neuer SHA-2 berechneter Hash-Wert, wenn die Datei in irgendeiner Weise verarbeitet wurde (z.B. wenn die Datei redigiert, kopiert, geändert oder auf sie zugegriffen wurde oder eine andere Maßnahme durchgeführt wurde)
    2. b) Neuer Speicherort für die Datei
    3. c) Neue Metadaten identifiziert, die der Datei zugehörig sind
    4. d) Übertragung des Zugriffs auf oder der Kontrolle über die Datei von einem Blockchain-Teilnehmer auf einen anderen Blockchain-Teilnehmer
  • 7D zeigt eine Ausführungsform eines Blocks, die gemäß einer Ausführungsform die Struktur der Blöcke in der Blockchain 790 darstellen kann. Der Block Blocki umfasst einen Kopf 772i, eine Datei 774i und einen Wert 776i.
  • Der Kopf 772i umfasst einen Hash-Wert eines vorherigen Blocks Blocki-1 und zusätzliche Verweisinformationen, bei denen es sich z.B. um beliebige hier beschriebene Arten von Informationen (z.B. Kopf-Informationen mit Verweisen, Merkmalen, Parametern usw.) handeln kann. Alle Blöcke verweisen auf den Hash eines vorherigen Blocks, außer natürlich des Genesis-Blocks. Der Hash-Wert des vorherigen Blocks kann nur ein Hash des Kopfes im vorherigen Block sein oder ein Hash aller oder eines Teils der Informationen im vorherigen Block, einschließlich der Datei und der Metadaten.
  • Die Datei 774i umfasst eine Mehrzahl von Daten, z.B. Daten 1, Daten 2, ..., Daten N in Folge. Die Daten sind mit den Metadaten 1, Metadaten 2, ..., Metadaten N versehen, die den Inhalt und/oder die den Daten zugehörigen Merkmale beschreiben. Die Metadaten für die einzelnen Daten können beispielsweise Informationen zur Angabe eines Zeitstempels für die Daten, zur Verarbeitung der Daten, Schlüsselwörter zur Angabe der in den Daten abgebildeten Personen oder anderer Inhalte und/oder andere Merkmale umfassen, die hilfreich sein können, um die Gültigkeit und den Inhalt der Datei insgesamt und insbesondere ihre Verwendung als digitalen Nachweis festzustellen, wie beispielsweise im Zusammenhang mit einer unten beschriebenen Ausführungsform beschrieben. Zusätzlich zu den Metadaten können alle Daten mit einem Verweis REF1, REF2, ..., REFN auf frühere Daten versehen werden, um Manipulationen, Lücken in der Datei und sequenzielle Verweise in der Datei zu vermeiden.
  • Sobald die Metadaten den Daten zugewiesen sind (z.B. durch einen Smart Contract), können die Metadaten nicht mehr geändert werden, ohne dass sich der Hash ändert, der zum Ungültigmachen leicht identifiziert werden kann. Die Metadaten erzeugen somit ein Datenprotokoll mit Informationen, auf die Teilnehmer der Blockchain zur Verwendung zugreifen können.
  • Der Wert 776i ist ein Hash-Wert oder ein anderer Wert, der auf der Grundlage einer der zuvor beschriebenen Arten von Informationen berechnet wird. Beispielsweise kann für jeden gegebenen Block Blocki der Wert für diesen Block aktualisiert werden, um das für diesen Block durchgeführte Verarbeiten widerzuspiegeln, z.B. neuer Hash-Wert, neuer Speicherort, neue Metadaten für die zugehörige Datei, Übertragen der Kontrolle oder des Zugriffs, Kennung oder andere hinzuzufügende Maßnahme oder Informationen. Zwar ist der Wert in jedem Block getrennt von den Metadaten für die Daten der Datei und des Kopfes dargestellt, doch kann der Wert in einer anderen Ausführungsform ganz oder teilweise auf diesen Metadaten beruhen.
  • Sobald die Blockchain 770 gebildet ist, kann die unveränderliche Chain-of-Custody zu jedem beliebigen Zeitpunkt für die Datei abgerufen werden, indem die Blockchain nach der Transaktionshistorie der Werte in den Blöcken abgefragt wird. Diese Abfrage- oder Verfolgungsprozedur kann mit einem Entschlüsseln des Wertes des Blocks beginnen, der am aktuellsten erfasst ist (z.B. der letzte (N-te) Block), und dann mit dem Entschlüsseln des Wertes der anderen Blöcke fortfahren, bis der Genesis-Block erreicht und die Originaldatei wiederhergestellt ist. Das Entschlüsseln kann auch Entschlüsseln der Köpfe und Dateien und zugehöriger Metadaten in jedem Block umfassen.
  • Das Entschlüsseln wird auf der Grundlage der Art des Verschlüsselns, die in jedem Block verwendet wurde, durchgeführt. Dies kann Verwenden von privaten Schlüsseln, öffentlichen Schlüsseln oder von Paaren aus öffentlichen und privaten Schlüsseln umfassen. Bei der asymmetrischen Verschlüsselung können Blockchain-Teilnehmer oder ein Prozessor im Netzwerk beispielsweise ein Paar aus öffentlichem und privatem Schlüssel mithilfe eines vorgegebenen Algorithmus erzeugen. Der öffentliche und der private Schlüssel sind miteinander durch eine mathematische Beziehung verbunden. Der öffentliche Schlüssel kann öffentlich verteilt werden und als Adresse dienen, um Nachrichten von anderen Benutzern zu empfangen, z.B. eine IP-Adresse oder eine Privatadresse. Der private Schlüssel wird geheim gehalten und zum digitalen Signieren von Nachrichten verwendet, die an andere Blockchain-Teilnehmer gesendet werden. Die Signatur ist in der Nachricht enthalten, damit der Empfänger sie mit dem öffentlichen Schlüssel des Senders überprüfen kann. Auf diese Weise kann der Empfänger sicher sein, dass nur der Sender diese Nachricht gesendet haben kann.
  • Das Erzeugen eines Schlüsselpaares ist vergleichbar mit dem Erzeugen eines Kontos in der Blockchain, ohne dass man sich jedoch irgendwo registrieren muss. Außerdem wird jede Transaktion, die in der Blockchain ausgeführt wird, vom Sender mit seinem privaten Schlüssel digital signiert. Diese Signatur stellt sicher, dass nur der Inhaber des Kontos die Datei der Blockchain verfolgen und bearbeiten kann (sofern dies im Rahmen einer durch einen Smart Contract festgelegten Genehmigung liegt).
  • Die 8A und 8B veranschaulichen weitere Beispiele für Anwendungsfälle einer Blockchain, die hier einbezogen und verwendet werden können. 8A veranschaulicht insbesondere ein Beispiel 800 für eine Blockchain 810, in der Daten zum maschinellen Lernen (künstliche Intelligenz) gespeichert werden. Maschinelles Lernen stützt sich auf beträchtliche Mengen historischer Daten (oder Trainingsdaten), um Prognosemodelle für genaue Vorhersagen zu neuen Daten zu erstellen. Software für maschinelles Lernen (z.B. neuronale Netzwerke usw.) kann oft Millionen von Datensätzen durchforsten, um nichtintuitive Muster zu erkennen.
  • In dem Beispiel von 8A erstellt und implementiert eine Host-Plattform 820 ein Modell für maschinelles Lernen zum vorausschauenden Überwachen von Assets 830. Bei der Host-Plattform 820 kann es sich in diesem Fall um eine Cloud-Plattform, einen Industrieserver, einen Webserver, einen Personal Computer, eine Benutzereinheit oder Ähnliches handeln. Bei den Assets 830 kann es sich um jede Art von Asset (z.B. Maschine oder Ausrüstung) handeln, beispielsweise Flugzeuge, Lokomotiven, Turbinen, medizinische Anlagen und Geräte, Öl- und Gasanlagen, Boote, Schiffe, Fahrzeuge und Ähnliches. Ein weiteres Beispiel für die Assets 830 sind immaterielle Assets wie z.B. Aktien, Währungen, digitale Zahlungsmittel, Versicherungen oder Ähnliches.
  • Die Blockchain 810 kann verwendet werden, um sowohl einen Trainingsprozess 802 des Modells für maschinelles Lernen als auch einen Vorhersageprozess 804 auf der Grundlage eines trainierten Modells für maschinelles Lernen erheblich zu verbessern. Anstatt dass ein Datenwissenschaftler/-ingenieur oder ein anderer Benutzer die Daten sammeln muss, können die historischen Daten in Schritt 802 beispielsweise von den Assets 830 selbst (oder einer zwischengeschalteten Einheit, nicht dargestellt) in der Blockchain 810 gespeichert werden. Dies kann die Zeit, die die Host-Plattform 820 für das Sammeln von Daten beim Trainieren von Vorhersagemodellen benötigt, erheblich verringern. Mit Smart Contracts können Daten beispielsweise direkt und zuverlässig von ihrem Ursprungsort in die Blockchain 810 übertragen werden. Durch Verwenden der Blockchain 810, um die Sicherheit von und das Eigentum an den gesammelten Daten zu gewährleisten, können Smart Contracts die Daten von den Assets direkt an die Personen senden, die die Daten für den Aufbau eines Modells für maschinelles Lernen verwenden. Dadurch ist es möglich, dass die Assets 830 gemeinsam Daten nutzen.
  • Die gesammelten Daten können auf der Grundlage eines Konsensmechanismus in der Blockchain 810 gespeichert werden. Der Konsensmechanismus bezieht (genehmigungspflichtige Knoten) ein, um sicherzustellen, dass die aufgezeichneten Daten überprüft und korrekt sind. Die aufgezeichneten Daten werden mit einem Zeitstempel versehen, kryptografisch signiert und sind unveränderbar. Somit sind sie überprüfbar, transparent und sicher. Durch das Hinzufügen von loT-Einheiten, die direkt in die Blockchain schreiben, können in bestimmten Fällen (z.B. Lieferkette, Gesundheitswesen, Logistik usw.) sowohl die Häufigkeit als auch die Genauigkeit der aufgezeichneten Daten erhöht werden.
  • Darüber hinaus kann das Training des Modells für maschinelles Lernen mit den gesammelten Daten mehrere Durchgänge des Verfeinerns und Testens durch die Host-Plattform 820 erfordern. Jeder Durchgang kann auf zusätzlichen Daten oder Daten beruhen, bei denen man bisher nicht davon ausging, dass sie das Wissen des Modells für maschinelles Lernen erweitern könnten. In Schritt 802 können die verschiedenen Trainings- und Testschritte (und die zugehörigen Daten) von der Host-Plattform 820 in der Blockchain 810 gespeichert werden. Jede Verfeinerung des Modells für maschinelles Lernen (z.B. Änderungen bei den Variablen, Gewichten usw.) kann in der Blockchain 810 gespeichert werden. Dies stellt einen überprüfbaren Nachweis dafür bereit, wie das Modell trainiert wurde und welche Daten zum Trainieren des Modells verwendet wurden. Wenn die Host-Plattform 820 ein fertig trainiertes Modell erreicht hat, kann das resultierende Modell in der Blockchain 810 gespeichert werden.
  • Nachdem das Modell trainiert wurde, kann es in einer Live-Umgebung implementiert werden, wo es auf der Grundlage der Ausführung des fertig trainierten Modells für maschinelles Lernen Vorhersagen/Entscheidungen treffen kann. In Schritt 804 kann das Modell für maschinelles Lernen beispielsweise für die zustandsorientierte Instandhaltung (condition-based maintenance - CBM) eines Assets, z.B. eines Flugzeugs, einer Windturbine, einem Gerät im Gesundheitswesen und Ähnliches, verwendet werden. In diesem Beispiel können die vom Asset 830 zurückgemeldeten Daten in das Modell für maschinelles Lernen eingegeben und für die Vorhersage von Ereignissen wie z.B. Ausfällen, Fehlercodes usw. verwendet werden. Festlegungen, die durch das Ausführen des Modells für maschinelles Lernen in der Host-Plattform 820 getroffen werden, können in der Blockchain 810 gespeichert werden, um einen prüfbaren/überprüfbaren Nachweis bereitzustellen. Bei einem nichteinschränkenden Beispiel kann das Modell für maschinelles Lernen einen zukünftigen Ausfall/Fehler eines Teils des Assets 830 vorhersagen und eine Warnung oder eine Benachrichtigung zum Austauschen des Teils erzeugen. Die Daten, die dieser Entscheidung zugrunde liegen, können von der Host-Plattform 820 in der Blockchain 810 gespeichert werden. In einer Ausführungsform können die hier beschriebenen und/oder abgebildeten Funktionen und/oder Maßnahmen in der Blockchain 810 oder in Bezug auf diese durchgeführt werden.
  • Neue Transaktionen für eine Blockchain können in einem neuen Block zusammengefasst und zu einem bestehenden Hash-Wert hinzugefügt werden. Dieser wird dann verschlüsselt, um einen neuen Hash für den neuen Block zu erzeugen. Dieser wird der nächsten Liste von Transaktionen hinzugefügt, wenn diese verschlüsselt sind, usw. Das Ergebnis ist eine Kette von Blöcken, von denen jeder die Hash-Werte aller vorhergehenden Blöcke enthält. Computer, die diese Blöcke speichern, vergleichen regelmäßig ihre Hash-Werte, um sicherzustellen, dass sie alle übereinstimmen. Stellt einer der Computer einen Fehler fest, verwirft er die Datensätze, die das Problem verursachen. Dieser Ansatz ist gut geeignet, um die Manipulationssicherheit der Blockchain zu gewährleisten, aber er ist nicht perfekt.
  • Eine Möglichkeit, wie ein unehrlicher Benutzer dieses System umgehen kann, besteht darin, dass dieser die Liste der Transaktionen zu seinen Gunsten verändert, jedoch so, dass der Hash unverändert bleibt. Dies kann durch eine Brute-Force-Methode geschehen, d.h. durch Ändern eines Datensatzes, Verschlüsseln des Ergebnisses und Prüfen, ob der Hash-Wert derselbe ist. Und wenn dies nicht der Fall ist, wird dies wieder und wieder versucht, bis ein übereinstimmender Hash gefunden wird. Die Sicherheit von Blockchains beruht auf der Überzeugung, dass gewöhnliche Computer diese Art von Brute-Force-Angriffen nur in Zeiträumen durchführen können, die völlig utopisch sind, wie etwa das Alter des Universums. Im Gegensatz dazu sind Quantencomputer viel schneller (tausende Male schneller) und stellen daher eine viel größere Gefahr dar.
  • 8B zeigt ein Beispiel 850 für eine quantensichere Blockchain 852, die eine Quantenschlüsselverteilung (quantum key distribution - QKD) zum Schutz vor einem Quantencomputerangriff implementiert. In diesem Beispiel können die Benutzer der Blockchain die Identität der anderen Benutzer mit QKD überprüfen. Dabei werden Informationen mithilfe von Quantenteilchen wie Photonen übertragen, die von einem Abhörer nicht kopiert werden können, ohne sie zu zerstören. Auf diese Weise können sich ein Sender und ein Empfänger in der Blockchain der Identität des jeweils anderen sicher sein.
  • In dem Beispiel von 8B gibt es die vier Benutzer 854, 856, 858 und 860. Jedes Benutzerpaar kann einen geheimen Schlüssel 862 (d.h. eine QKD) untereinander nutzen. Da es in diesem Beispiel vier Knoten gibt, sind sechs Knotenpaare vorhanden, und daher werden sechs verschiedene geheime Schlüssel 862 verwendet, darunter QKDAB, QKDAC, QKDAD, QKDBC, QKDBD und QKDCD. Jedes Paar kann eine QKD erzeugen, indem es Informationen mithilfe von Quantenteilchen wie Photonen überträgt, die von einem Abhörer nicht kopiert werden können, ohne sie zu zerstören. Auf diese Weise kann sich ein Benutzerpaar der Identität des jeweils anderen sicher sein.
  • Die Funktion der Blockchain 852 beruht auf den beiden Verfahren (i) Erzeugen von Transaktionen und (ii) Bilden von Blöcken, die die neuen Transaktionen zusammenfassen. Neue Transaktionen können ähnlich wie in einem herkömmlichen Blockchain-Netzwerk erzeugt werden. Jede Transaktion kann Informationen über einen Sender, einen Empfänger, einen Erzeugungszeitpunkt, einen zu überweisenden Betrag (oder Wert), eine Liste von Verweistransaktionen, die belegen, dass der Absender über die nötigen Mittel für die Operation verfügt, und Ähnliches enthalten. Dieser Transaktionsdatensatz wird dann an alle anderen Knoten gesendet, wo er in einen Pool von unbestätigten Transaktionen aufgenommen wird. Hier authentifizieren zwei Parteien (d.h. ein Paar der Benutzer 854 bis 860) die Transaktion durch Bereitstellen ihres gemeinsam genutzten geheimen Schlüssels 862 (QKD). Diese Quantensignatur kann an jede Transaktion angehängt werden, wodurch sie äußerst schwer zu fälschen ist. Jeder Knoten prüft seine Einträge anhand einer lokalen Kopie der Blockchain 852, um zu überprüfen, ob jede Transaktion über ausreichende Mittel verfügt. Die Transaktionen sind jedoch noch nicht bestätigt.
  • Anstatt einen herkömmlichen Mining-Prozess bei den Blöcken durchzuführen, können die Blöcke dezentral mithilfe eines Übertragungsprotokolls erzeugt werden. Nach einer vorher festgelegten Zeitspanne (z.B. Sekunden, Minuten, Stunden usw.) kann das Netzwerk das Übertragungsprotokoll auf jede unbestätigte Transaktion anwenden, um so eine byzantinische Einigung (Konsens) über eine korrekte Version der Transaktion zu erzielen. So kann jeder Knoten beispielsweise einen privaten Wert (Transaktionsdaten des jeweiligen Knotens) besitzen. In einem ersten Durchgang übermitteln die Knoten sich gegenseitig ihre privaten Werte. In den folgenden Durchgängen übertragen die Knoten die Informationen, die sie im vorherigen Durchgang von anderen Knoten empfangen haben. In diesem Fall sind ehrliche Knoten in der Lage, einen kompletten Satz von Transaktionen in einem neuen Block zu erzeugen. Dieser neue Block kann der Blockchain 852 hinzugefügt werden. In einer Ausführungsform können die hier beschriebenen und/oder abgebildeten Funktionen und/oder Maßnahmen in der Blockchain 852 oder in Bezug auf diese durchgeführt werden.
  • 9 veranschaulicht ein beispielhaftes System 900, das eine oder mehrere der hier beschriebenen und/oder abgebildeten Ausführungsformen unterstützt. Das System 900 weist ein Computersystem/einen Server 902 auf, das/der mit zahlreichen anderen universellen oder speziellen Datenverarbeitungssystem-Umgebungen oder Konfigurationen funktionsfähig ist. Beispiele für bekannte Datenverarbeitungssysteme, Umgebungen und/oder Konfigurationen, die für die Nutzung mit dem Computersystem/Server 902 geeignet sein können, sind unter anderem, ohne auf diese beschränkt zu sein, PersonalComputer-Systeme, Server-Computer-Systeme, schlanke Clients, leistungsintensive Clients, Hand- oder Laptop-Einheiten, Mehrprozessorsysteme, Systeme auf der Grundlage von Mikroprozessoren, Beistellgeräte, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Großrechnersysteme und verteilte Cloud-Computing-Umgebungen, die jedes beliebige der vorstehend genannten Systeme oder Einheiten und Ähnliches enthalten.
  • Das Computersystem/der Server 902 kann im allgemeinen Kontext von durch ein Computersystem ausführbaren Anweisungen beschrieben werden, z.B. Programmmodule, die von einem Computersystem ausgeführt werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. enthalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server 902 kann in verteilten Cloud-Computing-Umgebungen eingesetzt werden, wo die Aufgaben von entfernt angeordneten Verarbeitungseinheiten durchgeführt werden, die über ein Datenübertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernt angeordneten Computersystem-Speichermedien befinden, darunter Speichereinheiten mit Arbeitsspeichern.
  • Wie in 9 gezeigt, wird das Computersystem 902 im Cloud-Computing-Knoten 900 in Form einer universellen Datenverarbeitungseinheit dargestellt. Bei den Komponenten des Computersystems/Servers 902 kann es sich - ohne auf diese beschränkt zu sein - um einen oder mehrere Prozessoren oder Verarbeitungseinheiten 904, einen Systemspeicher 906 und einen Bus handeln, der verschiedene Systemkomponenten, darunter den Systemspeicher 906, mit dem Prozessor 904 verbindet.
  • Der Bus stellt eine oder mehrere von beliebigen mehreren Arten von Busstrukturen dar, darunter einen Speicherbus oder eine Speichersteuereinheit, einen Peripheriebus, eine AGP-Schnittstelle (Accelerated Graphics Port) und einen Prozessor oder lokalen Bus, der eine beliebige aus einer Vielfalt von Busarchitekturen nutzt. Beispielsweise und nicht einschränkend enthalten solche Architekturen einen Industry-Standard-Architecture(ISA)-Bus, einen Micro-Channel-Architecture(MCA)-Bus, einen Enhanced-ISA(EISA)-Bus, einen lokalen Video-Electronics-Standards-Association(VESA)-Bus und einen Peripheral-Component-Interconnects(PCI)-Bus.
  • Das Computersystem/der Server 902 umfasst in der Regel eine Vielfalt von durch einen Computer lesbaren Medien. Bei diesen Medien kann es sich um beliebige verfügbare Medien handeln, auf die das Computersystem/der Server 902 zugreifen kann, darunter flüchtige und nichtflüchtige Medien, wechselbare und nichtwechselbare Medien. In einer Ausführungsform implementiert der Systemspeicher 906 die Ablaufpläne der anderen Figuren. Der Systemspeicher 906 kann vom Computersystem lesbare Medien in Form von flüchtigen Speichern, z.B. Direktzugriffsspeicher (RAM) 910 und/oder Cache 912, enthalten. Das Computersystem/der Server 902 kann ferner weitere wechselbare/nichtwechselbare, flüchtige/nichtflüchtige Computersystem-Speichermedien enthalten. Nur beispielhaft kann das Speichersystem 914 bereitgestellt werden, um ein nichtwechselbares, nichtflüchtiges magnetisches Medium auszulesen und zu beschreiben (nicht dargestellt und üblicherweise als „Festplatte“ bezeichnet). Obwohl nicht dargestellt, können ein Laufwerk für magnetische Speicherplatten zum Auslesen und Beschreiben einer wechselbaren, nichtflüchtigen magnetischen Speicherplatte (z.B. „Diskette“) und ein Laufwerk für optische Speicherplatten zum Auslesen oder Beschreiben einer wechselbaren, nichtflüchtigen optischen Speicherplatte wie einem CD-ROM, DVD-ROM und andere optische Medien bereitgestellt werden. In solchen Fällen kann jedes über eine oder mehrere Datenmedien-Schnittstellen mit dem Bus verbunden sein. Wie nachstehend weiter dargestellt und beschrieben, kann der Speicher 906 mindestens ein Programmprodukt mit einem (z.B. mindestens einem) Satz von Programmmodulen enthalten, die so konfiguriert sind, dass sie die Funktionen verschiedener Ausführungsformen der Anwendung ausführen.
  • Das Programm/Dienstprogramm 916 mit (mindestens) einem Satz von Programmmodulen 918 kann beispielsweise und nicht einschränkend im Speicher 906 gespeichert sein, ebenso ein Betriebssystem, ein oder mehrere Anwendungsprogramme, weitere Programmmodule und Programmdaten. Das Betriebssystem, ein oder mehrere Anwendungsprogramme, weitere Programmmodule und Programmdaten oder eine Kombination daraus können jeweils eine Implementierung einer Netzwerkumgebung enthalten. Die Programmmodule 918 führen im Allgemeinen die Funktionen und/oder Methodiken verschiedener Ausführungsformen der hier beschriebenen Anwendung aus.
  • Für den Fachmann ist ersichtlich, dass Aspekte der vorliegenden Anwendung als System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Aspekte der vorliegenden Anwendung können daher die Form einer kompletten Hardware-Ausführung, einer kompletten Software-Ausführung (darunter Firmware, residente Software, Mikrocode usw.) oder eine Ausführungsform haben, bei der Hardware- und Software-Aspekte kombiniert sind, die allgemein hier als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Aspekte der vorliegenden Anwendung können des Weiteren die Form eines Computerprogrammprodukts haben, das in einem oder mehreren durch einen Computer lesbaren Medien ausgeführt ist, die über einen darin enthaltenen, durch einen Computer lesbaren Programmcode verfügen.
  • Das Computersystem/der Server 902 kann auch mit einer oder mehreren externen Einheiten 920, z.B. einer Tastatur, einer Zeigeeinheit, einer Anzeige 922 usw., Daten austauschen; sowie mit einer oder mehreren Einheiten, die einen Benutzer in die Lage versetzen, mit dem Computersystem/Server 902 zu interagieren; und/oder beliebigen Einheiten (z.B. Netzwerkkarte, Modem usw.), die das Computersystem/den Server 902 in die Lage versetzen, mit einer oder mehreren Datenverarbeitungseinheiten Daten auszutauschen. Eine solche Datenübertragung kann über die E/A-Schnittstellen 924 erfolgen. Überdies kann das Computersystem/der Server 902 mit einem oder mehreren Netzwerken, z.B. einem lokalen Netzwerk (LAN), einem allgemeinen Weitverkehrsnetzwerk (WAN) und/oder einem öffentlichen Netzwerk (z.B. das Internet), über den Netzwerkadapter 926 Daten austauschen. Wie dargestellt, tauscht der Netzwerkadapter 926 mit den anderen Komponenten des Computersystems/Servers 902 über einen Bus Daten aus. Es versteht sich, dass sonstige Hardware- und/oder Softwarekomponenten in Verbindung mit dem Computersystem/Server 902 verwendet werden können, auch wenn sie nicht dargestellt sind. Zu Beispielen zählen, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, Anordnungen externer Festplattenlaufwerke, RAID-Systeme, Bandlaufwerke und Speichersysteme für die Datenarchivierung usw.
  • Obwohl eine beispielhafte Ausführungsform mindestens eines Systems, Verfahrens und nichtflüchtigen, durch einen Computer lesbaren Mediums in den beiliegenden Zeichnungen veranschaulicht und in der vorstehenden ausführlichen Beschreibung beschrieben wurde, versteht sich, dass die Anmeldung nicht auf die offenbarten Ausführungsformen beschränkt ist, sondern dass zahlreichen neue Anordnungen, Änderungen und Ersetzungen möglich sind, wie sie in den folgenden Ansprüchen dargelegt und definiert sind. Die Fähigkeiten des Systems der verschiedenen Figuren können beispielsweise durch ein(e) oder mehrere der hierin beschriebenen Module oder Komponenten oder in einer verteilten Architektur ausgeführt werden und können einen Sender, einen Empfänger oder ein Paar von beiden enthalten. Die von den einzelnen Modulen ausgeführte Funktionalität kann beispielsweise ganz oder teilweise von einem oder mehreren dieser Module ausgeführt werden. Darüber hinaus kann die hierin beschriebene Funktionalität zu verschiedenen Zeiten und in Bezug auf verschiedene Ereignisse innerhalb oder außerhalb der Module oder Komponenten ausgeführt werden. Die zwischen verschiedenen Modulen gesendeten Informationen können ferner zwischen den Modulen übertragen werden durch: ein Datennetzwerk und/oder das Internet und/oder ein Sprachnetzwerk und/oder ein Internet-Protokoll-Netzwerk und/oder eine drahtlose Einheit und/oder eine drahtgebundene Einheit und/oder über eine Mehrzahl von Protokollen. Die von einem der Module gesendeten oder empfangenen Nachrichten können des Weiteren direkt und/oder über eines oder mehrere der anderen Module gesendet oder empfangen werden.
  • Für einen Fachmann ist offensichtlich, dass ein „System“ als Personal Computer, Server, Konsole, persönlicher digitaler Assistent (PDA), Mobiltelefon, Tablet-Datenverarbeitungseinheit, Smartphone oder eine andere geeignete Datenverarbeitungseinheit oder eine Kombination von Einheiten ausgeführt werden kann. Die Darstellung der oben beschriebenen Funktionen als von einem „System“ ausgeführt soll den Umfang der vorliegenden Anwendung in keiner Weise einschränken, sondern ein Beispiel für viele Ausführungsformen darstellen. Tatsächlich können die hierin offenbarten Verfahren, Systeme und Vorrichtungen in lokalisierter und verteilter Form im Einklang mit der Datenverarbeitungstechnologie implementiert werden.
  • Es ist zu beachten, dass einige der in dieser Beschreibung vorgestellten Systemeigenschaften als Module vorgestellt wurden, um ihre Implementierungsunabhängigkeit besonders hervorzuheben. Ein Modul kann beispielsweise als Hardware-Schaltung implementiert werden, die kundenspezifische VLSI-Schaltungen (VLSI = Very Large Scale Integration) oder Gate-Anordnungen, handelsübliche Halbleiter wie Logikchips, Transistoren oder andere einzelne Komponenten aufweist. Ein Modul kann auch in programmierbaren Hardware-Einheiten wie vor Ort programmierbaren Gatteranordnungen, programmierbaren Logikanordnungen, programmierbaren Logikeinheiten, Grafikverarbeitungseinheiten oder Ähnlichem implementiert werden.
  • Ein Modul kann auch zumindest teilweise in Software implementiert werden, um von verschiedenen Arten von Prozessoren ausgeführt zu werden. Eine identifizierte Einheit von ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen aufweisen, die beispielsweise als Objekt, Verfahren oder Funktion aufgebaut sein können. Die ausführbaren Dateien eines identifizierten Moduls müssen sich jedoch nicht physisch an dergleichen Stelle befinden, sondern können unterschiedliche Anweisungen aufweisen, die an verschiedenen Stellen gespeichert sind, die, nachdem sie logisch verbunden werden, das Modul aufweisen und den angegebenen Zweck für das Modul erfüllen. Darüber hinaus können Module auf einem durch einen Computer lesbaren Medium gespeichert werden, bei dem es sich beispielsweise um eine Festplatte, eine Flash-Einheit, ein Direktzugriffsspeicher (RAM), ein Band oder ein anderes solches Medium zum Speichern von Daten handeln kann.
  • Tatsächlich kann ein Modul aus ausführbarem Code eine einzelne Anweisung oder viele Anweisungen enthalten und sogar über mehrere verschiedene Code-Segmente, zwischen verschiedenen Programmen und über mehrere Speichereinheiten verteilt sein. Ebenso können Betriebsdaten identifiziert und hier in Modulen dargestellt werden und in jeder geeigneten Form ausgeführt und in jeder geeigneten Art von Datenstruktur aufgebaut sein. Die Betriebsdaten können als ein einzelner Datensatz erfasst oder über verschiedene Orte verteilt sein, darunter verschiedene Speichereinheiten, und zumindest teilweise nur als elektronische Signale in einem System oder Netzwerk vorliegen.
  • Es versteht sich, dass die Komponenten der Anmeldung, wie sie in den Figuren hier allgemein beschrieben und veranschaulicht sind, in vielen verschiedenen Konfigurationen angeordnet und ausgelegt sein können. Die ausführliche Beschreibung der Ausführungsformen soll daher den Umfang der beanspruchten Anwendung nicht einschränken, sondern stellt lediglich ausgewählte Ausführungsformen der Anwendung dar.
  • Für einen Fachmann ist leicht verständlich, dass das vorstehend Genannte mit Schritten in einer anderen Reihenfolge und/oder mit Hardware-Elementen in Konfigurationen durchgeführt werden kann, die sich von den offenbarten Schritten unterscheiden. Obwohl die Anmeldung auf Grundlage dieser bevorzugten Ausführungsformen beschrieben wurde, ist es für Fachleute offensichtlich, dass bestimmte Änderungen, Variationen und andere Ausbildungen möglich sind.
  • Zwar wurden bevorzugte Ausführungsformen der vorliegenden Anwendung beschrieben, jedoch ist zu verstehen, dass die beschriebenen Ausführungsformen nur veranschaulichend sind und der Anwendungsbereich der Anwendung ausschließlich durch die beigefügten Ansprüche zu definieren ist, wenn dabei eine umfassende Bandbreite von Äquivalenten und Änderungen (z.B. Protokolle, Hardware-Einheiten, Software-Plattformen usw.) berücksichtigt werden.

Claims (20)

  1. Vorrichtung, die aufweist: einen Prozessor, der so konfiguriert ist, dass er einen privaten Schlüssel mit einem Verschlüsselungsschlüssel verschlüsselt, eine Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels erzeugt und die Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf Grundlage eines geheimen Eingabewertes umwandelt, und den verschlüsselten privaten Schlüssel in einer Blockchain speichert; und eine Netzwerkschnittstelle, die so konfiguriert ist, dass sie die Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain verteilt, wobei der Prozessor einen anderen Schlüsselanteil von der Mehrzahl der Schlüsselanteile an jeden Blockchain-Peer der Mehrzahl von Blockchain-Peers überträgt.
  2. Vorrichtung nach Anspruch 1, wobei die Mehrzahl von Schlüsseln eine Mehrzahl von Pseudozufallswerten aufweist, und der Prozessor so konfiguriert ist, dass er die Mehrzahl von Pseudozufallswerten jeweils in der Mehrzahl von Blockchain-Peers registriert.
  3. Vorrichtung nach Anspruch 1, wobei der Prozessor so konfiguriert ist, dass er eine vergessliche Pseudozufallsfunktion (OPRF) ausführt, die einen Schlüssel von der Mehrzahl von Schlüsseln und den geheimen Eingabewert empfängt und einen Schlüsselanteil für den entsprechenden Schlüssel ausgibt.
  4. Vorrichtung nach Anspruch 3, wobei der Prozessor so konfiguriert ist, dass er die OPRF für jeden Schlüssel der Mehrzahl von Schlüsseln auf der Grundlage des geheimen Eingabewertes iterativ ausführt, um jeden Schlüsselanteil der Mehrzahl von Schlüsselanteilen auszugeben.
  5. Vorrichtung nach Anspruch 3, wobei der geheime Eingabewert ein Kennwort aufweist.
  6. Vorrichtung nach Anspruch 1, wobei der Prozessor so konfiguriert ist, dass er die Netzwerkschnittstelle steuert, um eine Blockchain-Transaktion an die Mehrzahl von Blockchain-Peers zu verteilen, wobei die Blockchain-Transaktion den verschlüsselten privaten Schlüssel und einen Zahlungswert aufweist.
  7. Vorrichtung nach Anspruch 1, wobei der Prozessor so konfiguriert ist, dass er die Mehrzahl von Schlüsselanteilen von der Mehrzahl von Blockchain-Peers abruft und die Mehrzahl von Schlüsselanteilen in die Mehrzahl von Schlüsseln auf der Grundlage des geheimen Eingabewertes zurückumwandelt.
  8. Vorrichtung nach Anspruch 7, wobei der Prozessor weiterhin so konfiguriert ist, dass er den Verschlüsselungsschlüssel von der Mehrzahl von Schlüsseln wiederherstellt und auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels eine Gebührentransaktion entschlüsselt, die von der Mehrzahl von Blockchain-Peers gespeichert wird.
  9. Vorrichtung nach Anspruch 8, wobei der Prozessor weiterhin so konfiguriert ist, dass er die entschlüsselte Gebührentransaktion an einen Blockchain-Peer der Mehrzahl überträgt, den verschlüsselten privaten Schlüssel von dem Blockchain-Peer im Austausch für die entschlüsselte Gebührentransaktion empfängt und den verschlüsselten privaten Schlüssel auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels entschlüsselt.
  10. Verfahren, das aufweist: Verschlüsseln eines privaten Schlüssels mit einem Verschlüsselungsschlüssel; Erzeugen einer Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels und Umwandeln der Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes; Speichern des verschlüsselten privaten Schlüssels in einer Blockchain; und Verteilen der Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain, wobei das Verteilen Übertragen eines anderen Schlüsselanteils von der Mehrzahl der Schlüsselanteile an jeden Blockchain-Peer der Mehrzahl von Blockchain-Peers umfasst.
  11. Verfahren nach Anspruch 9, wobei die Mehrzahl von Schlüsseln eine Mehrzahl von Pseudozufallswerten aufweist, und das Verfahren weiterhin Registrieren der Mehrzahl von Pseudozufallswerten jeweils in der Mehrzahl von Blockchain-Peers umfasst.
  12. Verfahren nach Anspruch 9, wobei das Umwandeln Ausführen einer vergesslichen Pseudozufallsfunktion (OPRF) umfasst, die einen Schlüssel von der Mehrzahl von Schlüsseln und den geheimen Eingabewert empfängt und einen Schlüsselanteil für den entsprechenden Schlüssel ausgibt.
  13. Verfahren nach Anspruch 12, wobei das Umwandeln weiterhin iteratives Ausführen der OPRF für jeden Schlüssel der Mehrzahl von Schlüsseln auf der Grundlage des geheimen Eingabewertes umfasst, um jeden Schlüsselanteil der Mehrzahl von Schlüsselanteilen auszugeben.
  14. Verfahren nach Anspruch 12, wobei der geheime Eingabewert ein Kennwort aufweist.
  15. Verfahren nach Anspruch 9, wobei das Speichern Verteilen einer Blockchain-Transaktion an die Mehrzahl von Blockchain-Peers umfasst, wobei die Blockchain-Transaktion den verschlüsselten privaten Schlüssel und einen Zahlungswert aufweist.
  16. Verfahren nach Anspruch 9, wobei das Verfahren weiterhin Abrufen der Mehrzahl von Schlüsselanteilen von der Mehrzahl von Blockchain-Peers und Zurückumwandeln der Mehrzahl von Schlüsselanteilen in die Mehrzahl von Schlüsseln auf der Grundlage des geheimen Eingabewertes umfasst.
  17. Verfahren nach Anspruch 16, wobei das Verfahren weiterhin Wiederherstellen des Verschlüsselungsschlüssels von der Mehrzahl von Schlüsseln und auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels Entschlüsseln einer Gebührentransaktion umfasst, die von der Mehrzahl von Blockchain-Peers gespeichert wird.
  18. Verfahren nach Anspruch 17, wobei das Verfahren weiterhin Übertragen der entschlüsselten Gebührentransaktion an einen Blockchain-Peer der Mehrzahl, Empfangen des verschlüsselten privaten Schlüssels von dem Blockchain-Peer im Austausch für die entschlüsselte Gebührentransaktion und Entschlüsseln des verschlüsselten privaten Schlüssels auf der Grundlage des wiederhergestellten Verschlüsselungsschlüssels umfasst.
  19. Computerprogrammprodukt, das Anweisungen aufweist, die, wenn sie von einem Prozessor gelesen werden, den Prozessor veranlassen, ein Verfahren durchzuführen, das aufweist: Verschlüsseln eines privaten Schlüssels mit einem Verschlüsselungsschlüssel; Erzeugen einer Mehrzahl von Schlüsseln auf der Grundlage des Verschlüsselungsschlüssels und Umwandeln der Mehrzahl von Schlüsseln in eine Mehrzahl von Schlüsselanteilen auf der Grundlage eines geheimen Eingabewertes; Speichern des verschlüsselten privaten Schlüssels in einer Blockchain; und Verteilen der Mehrzahl von Schlüsselanteilen an eine Mehrzahl von Blockchain-Peers der Blockchain, wobei das Verteilen Übertragen eines anderen Schlüsselanteils von der Mehrzahl der Schlüsselanteile an jeden Blockchain-Peer der Mehrzahl von Blockchain-Peers aufweist.
  20. Computerprogrammprodukt nach Anspruch 17, wobei das Umwandeln Ausführen einer vergesslichen Pseudozufallsfunktion (OPRF) umfasst, die einen Schlüssel von der Mehrzahl von Schlüsseln und den geheimen Eingabewert empfängt und einen Schlüsselanteil für den entsprechenden Schlüssel ausgibt.
DE112021006165.8T 2020-11-24 2021-10-25 Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf Pending DE112021006165T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/103,475 US20220166616A1 (en) 2020-11-24 2020-11-24 Key reclamation in blockchain network via oprf
US17/103,475 2020-11-24
PCT/CN2021/125947 WO2022111175A1 (en) 2020-11-24 2021-10-25 Key reclamation in blockchain network via oprf

Publications (1)

Publication Number Publication Date
DE112021006165T5 true DE112021006165T5 (de) 2023-10-05

Family

ID=81658686

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021006165.8T Pending DE112021006165T5 (de) 2020-11-24 2021-10-25 Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf

Country Status (6)

Country Link
US (1) US20220166616A1 (de)
JP (1) JP2023551458A (de)
CN (1) CN116438776A (de)
DE (1) DE112021006165T5 (de)
GB (1) GB2615710A (de)
WO (1) WO2022111175A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115114082A (zh) * 2021-03-23 2022-09-27 伊姆西Ip控股有限责任公司 用于在物联网中备份数据的方法、设备和程序产品
TWI806724B (zh) * 2022-08-02 2023-06-21 中華電信股份有限公司 用於決定金鑰的系統及方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8015211B2 (en) * 2004-04-21 2011-09-06 Architecture Technology Corporation Secure peer-to-peer object storage system
US9413735B1 (en) * 2015-01-20 2016-08-09 Ca, Inc. Managing distribution and retrieval of security key fragments among proxy storage devices
US11107071B2 (en) * 2016-02-01 2021-08-31 Apple Inc. Validating online access to secure device functionality
US11720890B2 (en) * 2016-04-22 2023-08-08 Micro Focus Llc Authorization of use of cryptographic keys
US10762564B2 (en) * 2016-11-10 2020-09-01 International Business Machines Corporation Autonomous peer-to-peer energy networks operating on a blockchain
LU93377B1 (en) * 2016-12-15 2018-07-03 Luxembourg Inst Science & Tech List P2p network data distribution and retrieval using blockchain log
US10601585B1 (en) * 2016-12-16 2020-03-24 EMC IP Holding Company LLC Methods and apparatus for blockchain encryption
US11190344B2 (en) * 2017-01-25 2021-11-30 Salesforce.Com, Inc. Secure user authentication based on multiple asymmetric cryptography key pairs
WO2018213419A1 (en) * 2017-05-16 2018-11-22 Apple Inc. Facilitating a fund transfer between user accounts
GB201709367D0 (en) * 2017-06-13 2017-07-26 Nchain Holdings Ltd Computer-implemented system and method
CN107623569A (zh) * 2017-09-30 2018-01-23 矩阵元技术（深圳）有限公司 基于秘密共享技术的区块链密钥托管和恢复方法、装置
US10439812B2 (en) * 2018-02-02 2019-10-08 SquareLink, Inc. Technologies for private key recovery in distributed ledger systems
US10841080B2 (en) * 2018-03-20 2020-11-17 International Business Machines Corporation Oblivious pseudorandom function in a key management system
US10917234B2 (en) * 2018-05-03 2021-02-09 International Business Machines Corporation Blockchain for on-chain management of off-chain storage
CN109379397B (zh) * 2018-08-31 2019-12-06 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
US20210135855A1 (en) * 2019-10-30 2021-05-06 EMC IP Holding Company LLC Threshold-Based Override of Data Privacy Using Distributed Ledgers and Key Shares
CN110929290B (zh) * 2019-12-04 2022-03-18 南京如般量子科技有限公司 基于联盟链的私钥门限备份、挂失及恢复系统及其方法
CN111507710A (zh) * 2020-03-25 2020-08-07 农业农村部农药检定所(国际食品法典农药残留委员会秘书处) 一种数据查询与共享系统
US11736456B2 (en) * 2020-09-29 2023-08-22 International Business Machines Corporation Consensus service for blockchain networks

Also Published As

Publication number Publication date
GB2615710A (en) 2023-08-16
WO2022111175A1 (en) 2022-06-02
US20220166616A1 (en) 2022-05-26
CN116438776A (zh) 2023-07-14
GB202307404D0 (en) 2023-07-05
JP2023551458A (ja) 2023-12-08

Similar Documents

Publication Publication Date Title
DE112020005289B4 (de) Teilweise sortierte blockchain
DE112020005075B4 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
DE112021000688T5 (de) Indexstruktur für blockchain-ledger
US20200382283A1 (en) Blockchain verification using non-consecutive blocks
US11838400B2 (en) Image encoding for blockchain
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
US11455403B2 (en) Privacy-preserving document sharing
US11379472B2 (en) Schema-based pruning of blockchain data
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
US20210256145A1 (en) Preservation of privacy in large datasets
US11646900B2 (en) Subscription service for networks
US11354425B2 (en) Privacy-preserving document sharing
DE112021006165T5 (de) Schlüsselwiederherstellung in einem blockchain-netzwerk mit oprf
DE112022000906T5 (de) Trennen von blockchain-daten
DE112021000219T5 (de) Konfliktfreie versionssteuerung
US11310311B2 (en) Media obfuscation
US20210174292A1 (en) Anonymization of partners
DE112021005625T5 (de) Automatisiertes zusammenführen von dlt-netzwerken
DE112021004120T5 (de) Schwellenwertverschlüsselung für sendeinhalt
US11526467B2 (en) Document storage and verification
US11876890B2 (en) Anonymization of partners
US20210232539A1 (en) Document storage and verification
US11379594B2 (en) Media obfuscation

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence