Verfahren und Vorrichtung zum Erzeugen, Bereitstellen und Weitergeben eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektronischen Dokument
Beschreibung
Gegenstand
Hier Ist ein Erzeugen, Bereitstellen und Weltergeben eines vertrauenswürdigen elektroni- schen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektro- nischen Dokument offenbart. Dies ist als Vorrichtung und als Verfahren zu realisieren. Merk- male und Eigenschaften der Vorrichtung und des Verfahrens sind In den Ansprüchen defi- niert; aber auch die Beschreibung und die Figuren offenbaren Charakteristika der Vorrich- tung und des Verfahrens sowie deren unterschiedliche Aspekte und Zusammenhänge. Hintergrund und Stand der Technik
Herkömmliche offiziell ausgestellte Dokumente (Pass, Personalausweis, Führerschein, Ge- burts-, Heiratsurkunde, Schul- Universitätsabschluss, oder dergl.) enthalten eine Sammlung vordefinierter zertifizierter Datensätze (Name, Adresse, Geburtsdatum, Blutgruppe, Impfsta- tus, Familienstand, Fingerabdruck, Irisblld, etc.). Das Verlegen eines solchen Dokuments durch dessen Inhaber gegenüber einem Dritten (Behörde, Geschäftspartner, etc.) etwa zum Nachweis des Alters oder der Staatsangehörigkeit ist üblich und erfüllt seinen Zweck. Aller- dings gibt der Inhaber durch die Vorlage des Dokuments als Ganzes dem Dritten meist mehr Informationen (Nebeninformationen) über sich preis als In der momentanen Situation erfor- derlich.
Wird etwa beim Kauf einer altersbeschränkten Ware (zum Beispiel Genussmittel) ein solches Dokument seitens des Käufers zum Nachweis seiner Volljährigkeit verwendet, kann der Ver- käufer über den Käufer viel mehr Informationen (Vor- und Nachname, Tag, Monat; Jahr der Geburt, Wohnort; Staatsangehörigkeit, etc.) erlangen, als für den konkreten Nachweis (Käu- fer Ist volljährig) erforderlich. Ein Bonitätsnachweis, etwa eines Käufers für einen Abschluss eines Kaufvertrags einer Wohnung, oder ein Einkommensnachwels eines Mieters für einen Abschluss eines Mietvertrags, erfordern derzeit ein Schreiben einer Bank bzw. eines Arbeit- gebers. Aus einem solchen Schreiben lassen sich neben dem aktuell geforderten Umfang der Bonität diverse weitere Informationen entnehmen.
Eine mobile ID-Lösung, z.B. MB TECURE ID (https://www.muehlbauer.de/solutions/id-card- solution), verarbeitet digitale Darstellungen amtlich ausgestellter und beglaubigter Dokumen- te, wie Identitätsnachweise, Führerscheine, etc. Diese Dokumente umfassen oft ein Foto des
Inhabers, Name, Adresse, Nationalität, Geschlecht, Geburtsdatum, Führerscheinklassen, Aus- stellung- und Gültigkeitsdatum, und Weiteres. Aus den Angaben des jeweiligen Dokuments wird eine mobile ID erzeugt, die auf einem Mobilgerät eines Reisenden eingespeichert und gehalten wird. Diese mobile ID ersetzt eine Vielzahl inhomogener Reisedokumente; sie er- laubt eine bequeme, berührungslose und datenschutzkonforme Vorgehensweise bei sicherer Identifikation des Reisenden.
Zur Identitätsprüfung einer Person und/oder einem Einräumen von Rechten an eine Person werden folgende Schritte unterschieden: Bei einer Authentisierung legt ein Nutzer einen Nachweis seiner vom System zu überprüfenden Identität vor. Eine Authentifizierung stellt die eigentliche Prüfung der vom Nutzer behaupteten Identität dar. Die Authentifizierung nimmt eine vertrauenswürdige Instanz vor. Diese vertrauenswürdige Instanz verifiziert oder falsifi- ziert die Identität des Nutzers anhand der im Nachweis enthaltenen Merkmale. Nach erfolg- reich abgeschlossener (verifizierter) Authentifizierung werden bei der Autorisierung dem Nut- zer die von ihm nachgefragten Rechte eingeräumt. Ein Reisender kann sich am Bahnhof mit Reisepass und Fahrkarte - aktiv - authentisieren. Durch das Bahnhofs-/Zugpersonal wird der Reisende - passiv - anhand der von ihm vorgelegten Dokumente authentifiziert. So ist der Reisende durch seine Fahrkarte zur Reise autorisiert.
In bekannten elektronischen Lösungen kann für derartige Szenarien die das Dokument aus- stellende Behörde / der Arbeitgeber kontaktiert und gebeten werden, zu diesem Dokument ein dediziertes Zertifikat mit einer dedizierten Signatur auszustellen. Dies erfordert eine zen- trale Infrastruktur und ist nicht datenschutzfreundlich, da die Verbindungsdaten (Metadaten) in der konkreten Situation nicht erforderliche Information (zum Beispiel Geo-Standort, Datum und Uhrzeit, Art des Zertifikats) preisgeben. Selbstsignierte Zertifikate sind eine weitere Mög- lichkeit. Diese Zertifikate bieten jedoch nur eine geringe Sicherheit, da die Authentizität des Inhalts des Zertifikats nicht nachgewiesen ist.
Public Key Infrastruktur PKI bezeichnet ein System, das digitale Zertifikate zu erzeugen, zu verteilen und zu prüfen in der Lage ist. Diese Zertifikate dienen als digitale Identität für Per- sonen. Eines asymmetrisches Kryptosystem kann elektronisch zu versendende Nachrichten signieren und verschlüsseln. Eine signierte Nachricht stammt in dieser Form tatsächlich vom angegebenen Absender. Um dies zu verifizieren, ist der öffentliche, zum Beispiel per E-Mail versendbare öffentliche Schlüssel (Public-Key) des Absenders erforderlich. Um zu gewährlei- sten, dass es sich tatsächlich um den Schlüssel des Absenders handelt, kann der zu verschi- ckende Schlüssel selbst wieder mit einem vertrauenswürdigen Schlüssel signiert sein. So ist eine Hierarchie aus vertrauenswürdigen Institutionen aufzubauen, wobei die Echtheit der Schlüssel der obersten Institution dieser Hierarchie zu akzeptieren ist. Digitale Zertifikate
sind digital signierte elektronische Daten zum Nachweis der Echtheit von Objekten. Eine Zer- tifizierungsstelle - Certificate Authority, CA - ist eine das Zertifikat bereitstellende und die Si- gnatur von Zertifikatsanträgen übernehmende Entität. Eine PKI bietet ein hierarchisches Gül- tigkeitsmodell an. Wird einer Zertifizierungsstelle vertraut, wird allen von ihr signierten Zerti- fikaten auch vertraut. Da eine CA untergeordnete CAs haben kann, wird auch allen unterge- ordneten CAs vertraut.
Zugrundeliegendes Problem
Persönliche Daten sollen bei Wahrung oder nur geringfügiger Schwächung der Vollständig- keit und Korrektheit (Unversehrtheit) der Daten, der Authentizität der beteiligten Person oder IT-Komponente oder -Anwendung, des Schutzes vor unbefugter Preisgabe der Daten, und/ oder der Anonymität des Herausgebenden an einen Dritten ausgegeben werden können. Da- bei ist auch die Herausgabe von Meta-Daten im Zusammenhang mit der Datenausgabe an den Dritten zu vermeiden.
Lösung
Als Ausprägung einer Lösung wird ein Verfahren angegeben, das zumindest teilweise als Lo- gik (in Hard- und/oder Software) in einem portablen Gerät eines Nutzers implementiert ist. Der in dem portablen Gerät implementierte Teil der Logik ist dazu eingerichtet, mit weiteren, in entfernten portablen oder stationären Geräten / in cloud computing implementierten Tei- len der Logik über eine Netzwerk-/Daten-Verbindung zu kommunizieren.
Das portable Gerät ist in einer Variante ein Mobilgerät (Smartphone), das dazu eingerichtet ist, eine sog. App auszuführen, also eine Anwendungssoftware für das portable Gerät mit ei- nem dafür ausgerichteten mobilen Betriebssystem. In dieser App ist der vom Nutzer auszu- lösende / auszuführende Teil des Verfahrens, um in nutzerfreundlicher, Privatsphäre wahren- der, vertrauenswürdiger und situationsangemessener Weise den Nutzer, seine Daten oder deren Teile zu authentifizieren, zu verifizieren und einem Dritten zu präsentieren. Die dafür erforderlichen Verfahrensschritte werden dezentral ausgeführt. In einer Variante bietet cloud computing für die dezentrale Ausführung über ein Netz bei Bedarf, jederzeit und überall ei- nen einfachen und schnellen Zugriff auf einen geteilten Pool in erforderlicher Weise konfigu- rierbarer Rechnerressourcen (Netze, Server, Speichersysteme, Anwendungen und Dienste).
Anstelle des portablen Geräts kann für den Nutzer auch eine stationäre Rechnerresouce vor- gesehen sein, die dem Nutzer die für diese Lösung erforderliche Funktionalität bereitstellt.
Für die innerhalb und/oder außerhalb der App des portablen Geräts auszuführenden Schritte der Logik sind die folgende Ressourcen einzusetzen.
In einem sogenannten distributed ledger (verteiltes digitales Analogon zu einem Buchfüh- rungsjournal) werden Datensätze in einem Peer-to-Peer-Netzwerk (P2P-Netzwerk) verteilt. Dabei entscheiden Knoten des Netzwerks durch eine Übereinkunft (Konsens) gemeinsam über die Aktualisierung der Daten. Bei den Daten kann es sich beispielsweise um Konto- stände einer Kryptowährung, Herkunftsnachweise für Waren, die Inhalte oben genannter offiziell ausgestellter Dokumente oder abstrakter um Vertragszustände von sogenannten smart contracts handeln.
In der hier vorgestellten Lösung wird in dem distributed ledger eine Rechenvorschrift, als Programm oder Skript (siehe unten) gespeichert. Dieses Programm oder Skript dient in einer Variante dazu, einen Eingangswert zu authentifizieren, und/oder zu verifizieren. Der distribu- ted ledger enthält also keinen statischen Wert oder Datum. Vielmehr wird in einem smart contract (siehe unten) hinterlegt, wie zum Beispiel basierend auf einem offiziell zertifizierten Geburts-Datum eines Nutzers eine Abfrage in Bezug auf dessen Volljährigkeit, (mit Ja oder Nein) zu beantworten ist, ohne später das Geburts-Datum des Nutzers selbst preiszugeben.
Diese klar definierte, binäre Antwort auf eine - ggf. auch komplexe - Frage, wird ermittelt durch eine von miner im Netzwerk überprüfte (siehe unten) Rechenvorschrift in dem smart contract. Diese Antwort wird übermittelt als eine zertifizierte / verschlüsselte Nachricht, um- fassend die Antwort (ist volljährig, hat einen Führerschein der Klasse B, etc.) in Bezug auf ein Dokument und/oder einen Identitätshinweis (Name). Diese Antwort dient zur Vorlage bei einem Dritten und bietet eine einfache und zuverlässige Handhabung im digitalen Verkehr.
Bei einem distributed ledger gibt es keine zentrale Kommunikationssteuerung und keine zen- trale Speicherung von Datensätzen. Die Knoten des Netzwerks verwalten jeweils eine lokale Kopie des vollständigen Datenbestands und können selbst neue Datensätze hinzufügen. Ein geeigneter Konsensmechanismus sorgt dafür, dass die verteilten Datensätze in allen Knoten aktuell sind und übereinstimmen und das distributed iedger als verteilte Datenstruktur damit stets in einem konsistenten Zustand gehalten wird. In dem distributed iedger sind smart con- tracts als verteilt durch die miner geprüfte Programme / Skripte abgelegt, die nicht mehr ge- ändert werden können und konsistent gehalten werden.
Zur Absicherung des Zugangs zu dem Netzwerk, der Datenstruktur, der Datensätze und der Konsensbildung werden für die erforderliche Sicherheit (insbesondere Integrität und Authen- tizität) kryptografische Verfahren eingesetzt. Regeln für die Validierung, Speicherung und Nutzung der Daten sind in diversen Ausprägungen in den Datensätzen selbst codiert und werden bei der Verarbeitung automatisiert vom Netzwerk ausgeführt und durchgesetzt.
In der sogenannten biockchain-Technologie werden Datensätze als sogenannte transactions in einem blockchain-Netzwerk validiert und zu Blöcken zusammengefasst. Durch kryptografi- sche Verkettung werden neue Datenblöcke (transactions) manipulationssicher mit ihrem Vor- gänger in der Kette verbunden. Diese Verkettung legt auch eine chronologische Reihenfolge der transactions fest. So entsteht als Spezialfall eines distributed iedger eine länger werden- de Kette von Datenblöcken, eine sogenannte blockchain. Typischerweise enthält jeder Block der biockchain einen kryptografischen hash des vorherigen Blocks in der Kette, einen Zeit- stempel und einen oder mehrere Datensätze. Zur Verwendung als distributed ledger wird ei- ne biockchain in dem blockchain-Netzwerk verwaltet, in dem alle Knoten gemeinsam ein Pro- tokoll zur Validierung neuer Blöcke befolgen. Eine biockchain ist inhärent resistent gegen Mo- difikation der Datensätze, da diese nach ihrer Aufnahme in die biockchain nicht rückwirkend geändert werden können, ohne dass alle nachfolgenden Blöcke geändert werden. Dies wür- de einen Konsens zwischen der Mehrheit der Knoten im Netzwerk erfordern.
Eine transaction bezeichnet dabei auch eine in dem distributed ledger / der biockchain ver- waltete oder zu verarbeitende Information. Der Begriff wallet beschreibt zum einen eine digi- tale Brieftasche zum Beispiel in dem Mobilgerät für Zugangsdaten und Geheimnisse eines Nutzers, und zum anderen eine generelle Benutzerschnittstelle zum blockchain-Netzwerk, über die der Nutzer seine Zugangsdaten und Geheimnisse verwalten und am System teil ha- ben kann. Ein Netzwerkknoten oder Akteur im Netzwerk, der einer biockchain neue Blöcke hinzufügen darf, wird auch als miner bezeichnet.
In einem distributed iedger können ein oder mehrere smart contracts gespeichert sein. Als smart contract sind nicht Verträge im rechtlichem Sinne, sondern rechnergestützte, ausführ- bare Anweisungen verstanden. Ein smart contract enthält also ein oder mehrere ausführbare Programme. Ein smart contract soll Handlungen oder Geschäfte zwischen einander unbe- kannten oder misstrauenden Personen manipulationssicher ermöglichen. Ein solcher smart contract exhält eine eigene Adresse zur Interaktion mit dem smart contract.
Der Programmcode des smart contract wird in einer transaction an die biockchain gesendet und von den Netzwerkknoten im Rahmen der Validierung ausgeführt. Der smart contract wird durch eine transaction aufgerufen. Ein Datensatz wird in einen smart contract ebenfalls durch eine transaction eingegeben. In hier vorgestellten Varianten des smart contract kann dessen Aufrufen registriert und überwacht werden. Aber auch völlig anonymes Aufrufen des smart contract kann vorgesehen sein, um ein Offenlegen der Daten zu vermeiden. Ein Auf- ruf-Zähler zur Darstellung der Reputation des smart contract kann zusätzlich implementiert
sein. Da eine blockchain unveränderlich ist, sind nachträgliche Änderungen am Programm- code unmöglich.
Eine unabhängige Instanz, die ausgebende Stelle eines Dokuments (Personalausweis, Reise- pass), der Nutzer oder der prüfende Dritte kann einen smart contract erstellen, von dem Netzwerk der miner prüfen, zertifizieren und anschließend nutzen lassen.
Ein smart contract kann als Skript in einer z.B. stackbasierten Skriptsprache, oder als Anwei- sungsabfolge in einer compilierbaren Programmiersprache, zum Beispiel Solidity, Go, Java, Node.js oder dergl. programmiert sein. Der Compiler erzeugt einen Bytecode. Dieser Byte- code oder das Skript wird als eigenständige transaction ohne Angabe einer Empfängeradres- se an das Netzwerk gesendet. Ein miner ordnet dem smart contract eine neu erzeugte Ad- resse zu und veröffentlicht den Programmcode in der blockchain. Eine transaction an die Ad- resse des smart contract hat dessen Ausführung durch den miner bei Aufnahme der trans- action in einen Block und anschließend von jedem anderen Knoten bei dessen Verifikation zur Folge.
Alterativ beauftragt ein Auftraggeber eines smart contract nur einige der Netzwerkknoten / miner mit der Ausführung des smart contract Diese Netzwerkknoten simulieren unabhängig voneinander zunächst lokal die Ausführung des smart contract und meldet das Ergebnis an den Auftraggeber zurück, ohne es in der blockchain zu verankern. Bei ausreichender Anzahl übereinstimmender Rückmeldungen wird eine transaction aufgesetzt und an eine andere Gruppe von Netzwerkknoten geschickt. Diese Gruppe entscheidet ohne eine Validierung oder inhaltliche Bewertung über die Reihenfolge, in der eingegangene transactions in die block- chain aufgenommen werden. Diese Validierung erfolgt final durch alle Netzwerkknoten, wenn sie ihre lokale Kopie der blockchain aktualisieren.
In dem smart contract enthaltene Regelungen können auch außerhalb der blockchain auf ei- ner API (application programming interface, Schnittstelle zur Programmierung von Anwen- dungen, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird), ausgeführt werden; lediglich die Befehle, die spezifische block- chain-Operationen betreffen, etwa ein Transfer von Werten, werden als transaction an die blockchain weitergeleitet und dort eingetragen. So ist der Programmcode nachträglich verän- derbar, da dieser nicht selbst auf der blockchain liegt. Dabei ist das Prinzip der Unveränder- lichkeit zugunsten einer möglichen Fehlerkorrektur aufgegeben.
Noch detaillierter ergibt sich basierend auf der vorstehend erläuterten Infrastruktur folgen- des Zusammenwirken der einzelnen Funktionen:
Eine einzelne b/ockchain hat wenigstens zwei Blöcke. Jeder Block enthält den hash-Wert des vorhergehenden Blocks. So wird eine Kettenabhängigkeit hergestellt, die vor unrechtmäßiger Änderung einer transaction in einem Block schützt, indem sie eine Neuberechnung jedes Blocks erfordert, der nach dem geänderten Block erzeugt wird. Transactions, die zwischen den Knoten des Netzwerks ausgetauscht werden, werden in den Blöcken der biockchain ge- speichert. Dabei kann jede transaction Benutzerdaten und eine digitale Signatur, z. B. den verschlüsselten Hash-Wert der Benutzerdaten enthalten. Eine transaction kann als Msg = D + h(D) definiert werden, wobei Msg die Nachricht bezeichnet, D für den in der transaction enthaltenen Datensatz steht, und h() eine hash-Funktion bezeichnet.
Neue Blöcke werden durch ein Konsensverfahren unter den Knoten des Netzwerks erzeugt und, sobald sie erzeugt sind, werden neue Blöcke an die biockchain angehängt. Ein typisches Konsensverfahren ist das sogenannte proof-of-work-Verfahren, das der Suche nach einem hash-Wert mit einer bestimmten Anforderung entspricht, d.h. der Suche nach einem be- stimmten hash-Wert, der sich nach Anwendung einer hash -Funktion auf den gesamten In- halt eines Blocks ergibt. Die Schwierigkeit, diesen hash -Wert zu berechnen, wird durch die Anzahl der Nullbits bestimmt, die am Anfang des hash -Wertes vorhanden sein müssen. Die- se Anzahl der Nullbits wird auch als Schwierigkeitsgrad bezeichnet. Durch eine höhere/niedri- gere Anzahl von Nullen am Anfang des hash -Wertes kann der Rechenaufwand erhöht/ver- ringert werden. Zur Berechnung des hash -Wertes kann eine sogenannte "nonce", d. h. ein Zufallswert verwendet werden, der Teil eines Blocks ist. Die nonce wird im proof-of-work- Verfahren zufällig modifiziert, um den gewünschten Ziel-hash -Wert für den gesamten Block zu finden. Unterschiedliche hash -Werte können also durch Modifikation der nonce und/ oder Hinzufügen neuer eingehender transactions erreicht werden. Das Finden der Lösung im proof-of-work-Verfahren ist in der Regel mit einem hohen Rechenaufwand verbunden. Das proof-of-work-Verfahren ist nicht das einzige verwendete Konsensverfahren; vielmehr wer- den auch andere, z. B. proof-of-stake, proof-of-capacity, proof-of-burn und proof-of-activity verwendet.
In dem blockchain-Netzwerk sind miner solche Knoten, die Blöcke berechnen, also auch an der Durchführung des proof-of-work teilnehmen . Um einen neuen Block zu berechnen, kön- nen miner alle aktuellen transactions sammeln, die noch nicht in der biockchain enthalten sind, und die aus den transactions gewonnenen Hash-Werte mit dem Hash-Wert des vorheri- gen Blocks, dem Zeitstempel und der nonce kombinieren. Als Nächstes wird auf diese kombi- nierten Datensätze eine hash-Funktion angewendet, die einen hash-Wert des neuen Blocks ergibt. Miner führen diese Berechnung wiederholt durch (indem sie die nonce ändern und/
oder neue eingehende transactions hinzufügen), bis eine Lösung für den Proof-of-Work ge- funden ist. Der erste miner, der eine Lösung findet, sendet den berechneten Block an die an- deren Knoten im Netzwerk. Wenn die anderen Knoten den Block validieren, wird die trans- action zur blockchain hinzugefügt.
Um eine neue transaction der blockchain hinzuzufügen, werden typischerweise die folgenden Schritte im blockchain-Netzwerk ausgeführt: (1) Die neue transaction wird vom Ursprungs- knoten in das Netzwerk gesendet und von allen Knoten empfangen. (2) Die transaction wird von allen Knoten validiert und jeder Knoten sendet das Ergebnis der Validierung, d.h., er gibt an, ob die transaction als gültig / validiert angesehen wird oder nicht. (3) Wenn die trans- action akzeptiert wird, d.h., die Mehrheit der Knoten bestimmt die transaction als gültig / va- lidiert, beginnen die miner die Berechnung des Blocks z.B., (4) der erste miner, der eine Lö- sung (z. B. für den proof-of-work) findet, sendet den berechneten Block in das Netzwerk. (5) Die anderen Knoten validieren die Lösung und senden das Validierungsergebnis in das Netz- werk, d. h., sie geben an, ob die Lösung akzeptiert oder abgelehnt wird. (6) Wenn die Lö- sung akzeptiert wird, d. h., die Mehrheit der Knoten akzeptiert die Lösung, wird der Block der blockchain hinzugefügt und die Knoten aktualisieren ihr distributed iedger entsprechend. Die Validierung der transaction in Schritt (2) oben kann unter Verwendung bekannter digita- ler Signaturen durchgeführt werden. Z.B. kann jede transaction vom Ursprungsknoten der transaction digital signiert werden, indem eine hash - Funktion auf den Datensatz der Trans- aktion angewendet und der erhaltene hash-Wert mit dem private key des Ursprungsknotens verschlüsselt wird. Die empfangenden Knoten können dann die transaction validieren, indem sie die digitale Signatur mit dem öffentlichen Schlüssel des Ursprungsknotens entschlüsseln, den hash-Wert des Datensatzes berechnen und den empfangenen hash -Wert mit dem berechneten hash-Wert vergleichen.
Aus technischer Sicht werden bei der hier vorgestellten Lösung Zertifikate-Speicher mit ei- nem distributed iedger, insbesondere einer blockchain kombiniert. In dem distributed iedger / der blockchain ist zumindest ein smart contract hinterlegt. Mit dem in diesem smart con- tract enthaltenen Programm oder Skript oder der Anweisungsabfolge werden Zertifikate mit verteiltem Vertrauen ausgegeben. Der smart contract legt insbesondere fest, wie und unter welchen Bedingungen der Datensatz zu berechnen ist, der sich in dem auszugebenden Zertifikat befindet.
Die hier vorgestellte Lösung betrifft ein Verfahren zum Erzeugen, Bereitstellen und Austau- schen eines vertrauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer betreffenden elektronischen Dokument, mit den Schritten:
Bereitstellen des Dokuments, das eine den Nutzer betreffende Information in einem elektro- nischen Format umfasst;
Kontaktieren einer in einem Netzwerk gehaltenen blockchain durch den Nutzer, wobei die blockchain einen smart contract enthält, der eingerichtet und dazu programmiert ist (i) zur Prüfung, ob das Dokument die Erfüllung einer Einschränkung durch den Nutzer belegt; (ii) zur Prüfung der Erfüllung / Nicht-Erfüllung der Einschränkung mittels des smart contract, (iii) zum Berechnen eines proof mittels des smart contract, und Erzeugen eines Zertifikates des proof mittels des smart contract unter Verwendung einer kryptografischen Funktion; und (iv) zum Versenden des Zertifikates des proof durch den smart contract an den Nutzer.
Die hier vorgestellte Lösung umfasst, dass die in dem Netzwerk / den Rechner- und/oder Netzwerkressourcen gehaltene blockchain Teil eines distributed ledger ist.
Zusätzlich wird in einer Variante der hier vorgestellten Lösung ein durch den smart contract berechneter hash-Wert in einer weiteren blockchain abgelegt, um unabhängig vom krypto- graphisch erzeugten proof ein weiteres Merkmal der Authentizität zu erzeugen.
Die hier vorgestellte Lösung nutzt den smart contract in der blockchain zur Berechnung des Zertifikates.
Anstelle des zu versendenden Zertifikates des proof durch den smart contract an den Nutzer wird in einer Variante der hier vorgestellten Lösung ein hash verwendet als Beleg verwendet, dass (i) die Berechnung des proof mittels des smart contract stattgefunden hat, und (ii) dass nichts verändert wurde.
Die hier vorgestellte Lösung umfasst in einer Variante vor dem Kontaktieren der in dem Netzwerk gehaltenen blockchain, ein Einleiten einer Interaktion mit einer weiteren Person durch den Nutzer; und/oder ein Mitteilen der Einschränkung der Interaktion durch die wie- tere Person an den Nutzer, wobei die Erfüllung / Nicht-Erfüllung der Einschränkung durch den Nutzer anhand des Dokuments zu belegen ist.
Die hier vorgestellte Lösung umfasst in einer weiteren Variante, nach dem Versenden des hash-Wertes des proof durch den smart contract an den Nutzer, (i) ein Versenden des er- haltenen hash-Wertes des proof durch den Nutzer an die weitere Person; (ii) ein Prüfen des hash-Wertes des proof durch die weitere Person; und/oder (iii) ein Bewirken, abhängig vom Ergebnis des Prüfens, einer Ausführung oder Verweigerung der durch den Nutzer eingeleite- ten Interaktion durch die weitere Person.
Die hier vorgestellte Lösung umfasst in einer weiteren Variante, dass der smart contract eingerichtet und dazu programmiert ist, ein abgeleitetes, vertrauenswürdiges Zertifikat zu dem berechneten proof und dem erzeugten hash-Wertes des proof zu erstellen.
Der distributed ledger ist in Bezug auf den smart contract für jede Partei transparent und ermöglicht die Validierung sowohl seiner selbst als auch der Berechnungsanweisungen. Da- bei bleiben Sicherheit und privacy der Daten bei Zugriff auf Dokumente des Nutzers im vom Nutzer geforderten oder definierten Umfang erhalten, ohne dass das zugrunde liegende Do- kument oder ein darin enthaltenes Datenelement offenzulegen ist. So ist zum Beispiel bei Al- tersabfragen (Nutzer ist älter als x Jahre) nicht das Geburtsdatum als ganzes (Tag/ Monat/ Jahr) preiszugeben. Vielmehr wird mit der hier vorgestellten Lösung aus dem zertifizierten Geburtsdatum des Nutzers eine sichere Ja/Nein-Aussage erzeugt. Ähnlich liefert bei einer Bo- nitätsabfrage für einen Wohnungskauf die Bank statt des Kontoauszugs eine den konkreten Abfragewert bestätigende/verneinende Aussage (Nutzer hat eine Bonität > €150000). Die smart contracts können unter Verwendung der blockchain-Funktionalität auf weitere Eigen- schaften des Nutzer (ist sozialversichert, ist Staatsbürger des Landes XX, hat Fahrerlaubnis der Klasse YY, hat zum Datum ZZ einen Aufenthaltstitel im Land XX, etc.) erweitert werden.
Das Maß an Vertrauenwürdigkeit - level ofassurance - ergibt sich aus dem Vertrauen, das die verteilte Berechnung bzw. das Netzwerk aus minern bietet. Das hashing des smart con- tract und dessen Speicherung im distributed ledger garantiert einen level ofassurance, der sich aus dem Anteil der miner bezogen auf alle Knoten im Netzwerk ergibt. So wird garan- tiert, dass der berechnete Wert genau zu der Berechnungsanweisung des smart contract ge- hört und die Validierung des smart contracts und des Berechnungsergebnisses zuverlässig ist.
Als Ergebnis der Berechnung wird ein neuer Berechtigungsnachweis bereitgestellt, mit einer Zertifizierung aus dem blockchain-Netzwerk. Das Zertifikat kann in der wallet des Nutzers ge- speichert und später verwendet werden, wenn diese Art der Zertifizierung erforderlich ist.
Das einmal generierte Zertifikat kann später mehrfach gezeigt werden. Das Zertifikat selbst kann auch mit einem Zeitstempel versehen sein, so dass eine dritte Partei das Zertifikat ent- sprechend bewerten kann. In der blockchain kann eine Zählung der Aufrufe des smart con- tract hinterlegt werden, die zur Dokumentation der Reputation dienen kann. Das Zertifikat enthält immer die Adresse des smart contract zur späteren Verifikation durch den Überprü- fenden.
Bei einer Variante der hier vorgestellten Lösung umfasst das Bereitstellen des Dokuments ein solches Dokument, bei dem zumindest den Nutzer betreffende Information in dem elektroni- schen Format zertifiziert, signiert, und/oder authentifiziert sind.
Bei einer Variante der hier vorgestellten Lösung umfasst das Kontaktieren der blockchain ein Übermitteln von Angaben durch den Nutzer mittels einer elektronischen Datenkommunika- tion (i) zur Identifizierung des Nutzers; (ii) zu dem Dokument; (iii) zu dem zur Prüfung der Einschränkung zu verwendenden smart contract; und/oder (iv) zu der Einschränkung; über ein Netzwerk an die blockchain umfasst.
Bei einer Variante der hier vorgestellten Lösung sendet der Nutzer zum Prüfen der Erfüllung der Einschränkung mittels des smart contract, (i) dem smart contract zumindest teilweise das Dokument; und/oder dem smart contract Zugangsdaten zu zumindest einem Teil des Dokuments; über das Netzwerk an die blockchain.
Eine Variante der hier vorgestellten Lösung umfasst zum Prüfen der Erfüllung der Einschrän- kung der smart contract einen Programmcode oder ein Skript mit Anweisungen zum (i) Prü- fen wenigstens eines Zertifikats, einer Signatur und/oder einer Authentifizierung des Doku- ments; (ii) Berechnen des proof basierend auf dem Ergebnis der Prüfung des wenigstens ei- nen Zertifikats, der wenigstens einen Signatur und/oder der wenigstens einer Authentifizie- rung des Dokuments; und/oder (iii) Signieren des proof mittels einer vorzugsweise verteilten kryptografischen Funktion durch Erzeugen einer Signatur des proof. Eine Signatur hat den Vorzug, dass mit ihr zu beweisen ist, wer den hash berechnet hat. Der smart contract SC ist in der in der blockchain BC abgelegt. Die Signatur kann dabei zentral oder verteilt erstellt werden, das ist beides möglich.
Bei einer Variante der hier vorgestellten Lösung umfasst das Versenden des Zertifikates des proof durch die blockchain an den Nutzer ein Übermitteln des Zertifikates des proof mittels elektronischer Datenkommunikation über das Netzwerk, um (i) das Zertifikat des proof in einer in einem Mobilgerät oder einer stationären Rechnerresouce des Nutzers gehaltenen wallet abzuspeichern, so dass dieses Zertifikat des proof für den Nutzer zur weiteren Bear- beitung zugänglich ist; und/oder (ii) das Zertifikat des proof mit oder ohne vorheriges Ab- speichern in der wallet von dem Mobilgerät oder der stationären Rechnerresouce des Nutzers ohne eine Aktion des Nutzers über das Netzwerk an die weitere Person zu versenden.
Bei einer Variante der hier vorgestellten Lösung umfasst das Bereitstellen des Dokuments ein solches Dokument, bei dem (i) zumindest den Nutzer betreffende Information unter Verwen-
düng eines vorzugsweise biometrischen ID-Dokuments von einer offiziellen Behörde oder ei- nes trusted partner in dem elektronischen Format zertifiziert, signiert, und/oder authentifi- ziert sind; und/oder (ii) zumindest den Nutzer betreffende Information in einem elektroni- schen Identitätsnachweis und/oder einem elD-Server mit funktionaler elD-Schnittstelle für externe Zugriffe gespeichert sind.
Bei einer Variante der hier vorgestellten Lösung ist der (i) smart contractm der bbckchain dazu programmiert und eingerichtet, auf die den Nutzer betreffende Information in dem elektronischen Identitätsnachweis und/oder dem elD-Server zur Prüfung der Einschränkung zuzugreifen, und/oder (ii) die den Nutzer betreffende Information als mobile ID in seiner wallet durch den Nutzer bereitgehalten zur Versendung über das Netzwerk an den smart contractm der blockchain.
Bei einer Variante der hier vorgestellten Lösung wird als smart contract ein durch miner in Knoten des Netzwerks validierter smart contract eingesetzt, der programmiert und dazu ein- gerichtet ist, in dem Dokument den Nutzer betreffende Information mit der an den smart contract übermittelten Einschränkung auf deren Erfüllung hin zu vergleichen. Dabei kann der smart contract programmiert und dazu eingerichtet sein, ein Vorliegen / Nicht-Vorliegen der Erfüllung der Einschränkung nach dem Berechnen des proof durch den smart contract, und dem Erzeugen des Zertifikates des proof durch den smart contract mithilfe der kryptogra- fischen Funktion an den Nutzer zu versenden. Zusaätzlich oder stattdessen kann der smart contract programmiert und dazu eingerichtet sein, mittels an den smart contract gesendeter Angaben hinsichtlich des Umfangs festlegbare weitere Informationen aus dem Dokument übertragen.
Bei einer Variante der hier vorgestellten Lösung ist der smart contract programmiert und dazu eingerichtet, (i) für die den Nutzer betreffende Information, und soweit hinsichtlich des Umfangs festgelegt, weitere Informationen aus dem Dokument, zu zertifizieren, signieren, und/oder authentifizieren, und/oder neue zertifizierte, signierte, und/oder authentifizierte Datenelemente zu erzeugen, die durch Dritte durch unabhängigen Zugriff auf den smart contract in der bbckchain vollständig verifizierbar und hinsichtlich der Authentizität der Da- tenelemente überprüfbar sind.
Bei einer Variante der hier vorgestellten Lösung ist der smart contract programmiert und dazu eingerichtet, das Vorliegen / Nicht-Vorliegen der Erfüllung / Nicht-Erfüllung der Ein- schränkung durch den Nutzer in einer Form an den Nutzer zu senden, die das gleiche Maß an Vertrauenwürdigkeit - level of assurance - aufweisen wie das zum Prüfen der Einschrän- kung mittels des smart contract verwendete Dokument; und/oder wobei der smart contract
programmiert und dazu eingerichtet ist, dass der Nutzer (i) das Berechnen des proof durch den smart contract, (ii) das Erzeugen des Zertifikates des proof durch den smart contract mithilfe einer, vorzugsweise verteilten, kryptografischen Funktion, und/oder (iii) das Versen- den des Zertifikates des proof durch den smart contract an den Nutzer selbst initiiert.
Bei einer Variante der hier vorgestellten Lösung werden als kryptografische Funktion eine public-key -Kryptographie / digitale Signaturen und/oder kryptographische hash-Funktionen eingesetzt. In einer Variante wird in der public-key -Kryptographie ein durch eine Rechenvor- schrift mathematisch miteinander verbundenes Schlüsselpaar mit einem private key und ei- nem public key erzeugt. In einer Variante smart contract, und das Erzeugen eines hasb-\Ner- tes des proof durch den smart contract m ith i Ife des Schlüsselpaars. In einer Variante wird das Schlüsselpaar zur Erstellung einer digitalen Signatur verwendet, indem der Nutzer die transaction mit seinem private key signiert, über den nur er verfügt, und die so entstandene signierte Nachricht an den smart contract sendet. In einer anderen Variante ist der smart contract eingerichtet und dazu programmiert, von der transaction ein hash-Wert erzeugt, der dann mit dem private key verschlüsselt wird. Mit dem public key kann anschließend ein Drit- ter den hash-Wert entschlüsseln und prüfen, ob er zur transaction paßt. In einer weiteren Variante ist der smart contract eingerichtet und dazu programmiert, vor dem Versenden des hash-Wertes des proof diesen mit der digitalen Signatur zu signieren. In einer Variante ist der smart contract eingerichtet und programmiert, die transaction mit dem public key des Nutzers zu prüfen und die Authentizität der transaction, sofern die beiden Schlüssel korre- spondieren, zu verifizieren. In einer Variante ist nach dem Signieren der transaction durch den smart contract die transaction auf inhaltliche Integrität durch den Nutzer und/oder die dritte Person zu prüfen.
In einer Variante ist der smart contract eingerichtet und dazu programmiert, das Erzeugen des hash-Wertes und/oder des Zertifikats des proof mit einer kryptographischen hash-Funk- tion auszuführen, wobei aus dem proof, der eine Zeichenfolge beliebiger Länge ist, eine Re- chenvorschrift der hash-Funktion eine Zeichenfolge mit fixer Länge ( = hash-Wert ) erzeugt. Dabei ist die hash-Funktion deterministisch. Ausgehend von dem erzeugten hash-Wert ist der ursprüngliche proof nicht, insbesondere nicht mit vertretbarem Aufwand, zu bestimmen. Es ist nicht, insbesondere nicht mit vertretbarem Aufwand, möglich, einen zweiten, anderen proof zu finden, der denselben hash-Wert des proof ergibt. Es ist nicht, insbesondere nicht mit vertretbarem Aufwand, möglich, zwei unterschiedliche proofs zu finden, die denselben hash-Wert des proof ergeben. In einer Variante implementiert die hash-Funktion einen z.B. auf SHA-2, oder SHA-3 basierenden Algorithmus.
In einer Variante ist die den smart contract enthaltende, in einem distributed ledger imple- mentierte blockchain als erlaubnisbasierte öffentliche blockchain, als eine erlaubnisbasierte private blockchain oder als eine erlaubnisfreie öffentliche blockchain implementierte.
Hier ist auch ein portables Gerät offenbart, das dazu eingerichtet ist, eine Logik in Hard- und /oder Software auszuführen, in der das Verfahren nach einer der vorstehenden Varianten im- plementiert ist. Die Logik ist dazu eingerichtet, einen oder mehrere der Verfahrensschritte nach einer der vorstehenden Varianten entweder mit Ressourcen des portablen Geräts aus- zuführen, oder über ein Netzwerk mit entfernten Ressourcen zur Ausführung eines oder mehrerer der Verfahrensschritte zu kommunizieren. Insbesondere in dem portablen Gerät können vom Nutzer auszulösende oder auszuführende Verfahrensschritte der Logik dazu die- nen, den Nutzer, seine Daten oder deren Teile zu authentifizieren, zu verifizieren und einem Dritten zu präsentieren, und weitere Verfahrensschritte der Logik dezentral als cbud Compu- ting und/oder in Knoten des Netzwerks, insbesondere auch in als miner wirkenden Knoten implementiert sein.
Hier ist auch ein wallet offenbart, implementiert als Datenbank in einem portablen Gerät, das dazu eingerichtet ist, eine Logik in Hard- und/oder Software auszuführen, in der das Verfah- ren nach einer der vorstehenden Varianten implementiert ist, und wobei die Logik dazu ein- gerichtet ist, einen oder mehrere der Verfahrensschritte nach einer der vorstehenden Varian- ten entweder mit Ressourcen des portablen Geräts auszuführen, oder über ein Netzwerk mit entfernten Ressourcen zur Ausführung eines oder mehrerer der Verfahrensschritte zu kom- munizieren. Insbesondere kann in dem portablen Gerät ein Speicher zur Speicherung des di- gitalen Zertifikates des proof vorgesehen sein, der durch die blockchain an die wallet des Nutzers mittels elektronischen Datenkommunikation über das Netzwerk übermittelt wurde.
Das portable Gerät kann programmiert und dazu eingerichtet sein, in der wallet die Speiche- rung und/oder die Weiterversendung des digitalen Zertifikates des proof mittels über eine Nutzeroberfläche einzugebender Befehle zu bewirken, und/oder das digitale Zertifikat des proof mit vorherigem Abspeichern in der wallet von dem portablen Gerät des Nutzers ohne eine Aktion des Nutzers über das Netzwerk an die weitere Person zu versenden. Die den Nutzer betreffende Information kann als mobile ID in seiner wallet für den Nutzer bereitge- halten werden zur Versendung über das Netzwerk an den smart contract in der blockchain.
Kurzbeschreibuno der Figuren
Weitere Merkmale, Eigenschaften, Vorteile, Zweckmäßigkeiten der Vorrichtungen und der Verfahrensweisen sind der nachfolgenden Beschreibung in Verbindung mit der Zeichnung zu
entnehmen. Auch mögliche Abwandlungen werden für einen Fachmann anhand der nachste- henden Beschreibung deutlich, die auf die beigefügten Zeichnungen Bezug nimmt. Dabei veranschaulichen die Fig. Ausführungsformen hier erörterter Lösungen. Hierbei zeigt Fig. 1 einen Ablauf der Schritte einer Variante des hier offenbarten Verfahrens.
Detaillierte Beschreibung von Varianten
Die hier vorgestellte Lösung dient zum Erzeugen, Bereitstellen und Weitergeben eines ver- trauenswürdigen elektronischen Datensatzes oder Zertifikates basierend auf einem einen Nutzer N betreffenden elektronischen Dokument D. Dazu sind einzelne Entitäten und deren Interaktion miteinander als einzelne Schritte in der Fig. 1 veranschaulicht.
Ein validierter smart contract, der in einem distributed n ledger abgelegt ist, dient dazu, in datenschutzfreundlicher Weise Attribute des Berechtigungsinhabers / Nutzers abzuleiten, ohne Nebeninformationen preiszugeben. Der validierte smart contract verifiziert die offiziel- len Signaturen der Datenelemente / Informationen INFO des Dokuments D und berechnet und generiert neue zertifizierte Datenelemente (Über-/ Unterschreitung einer Altersgrenze, Nationalität, Staatsangehörigkeit, ...), die von einem Dritten durch eine elektronische Anfra- ge bei dem distributed ledger verifiziert werden können. Der smart contract und die Ergeb- nisse seiner Berechnungen sind durch starke Kryptographie geschützt. Damit ist für die ab- geleiteten Daten das gleiche Maß an Sicherheit wie bei den Quelldaten erreichbar. Jeder Dritte, dem Zugriff auf den distributed ledger gewährt wird, kann die Authentizität dieser Berechtigungsnachweise überprüfen.
So kann der Nutzer N Berechtigungsnachweise auf der Grundlage offiziell zertifizierter Be- rechtigungsnachweise generieren. Dabei bleibt die Privatsphäre des Nutzers N so weit wie möglich gewahrt. Die abgeleiteten Berechtigungsnachweise haben bei der hier vorgestellten Lösung das gleiche oder ein ähnliches level ofassurance (loa) wie der zur Generierung ver- wendete Quellberechtigungsnachweis, obwohl sie nicht von einer Behörde oder dergl. er- zeugt wurden. Vielmehr bewirkt der Nutzer N selbst die Generierung der abgeleiteten Be- rechtigungsnachweise durch den smart contract
Die vorliegende Lösung versetzt den Nutzer N in die Lage, sich ein selbstsigniertes Zertifikat ausstellen zu lassen, das den Grad der Sicherheit der ursprünglichen Daten beibehält oder demgegenüber nicht wesentlich schwächer ist. Dabei wird die Erzeugung und Anhäufung von Metadaten vermieden. So ist auch nicht nachvollziehbar, wer wann welche Daten ange- fordert hat, etc.
Hierzu dient auch eine hier vorgestellte digitale wallet mit offiziell signierten Zertifikaten. Die Lösung berechnet und leitet signierte Zertifikate als Ergebnis der Berechnungen eines smart contract ab, die in einem distributed ledger gespeichert und (auch öffentlich) verfügbar sind. Der distributed ledger ist in hier vorgestellten Varianten eine erlaubnisbasierte öffent- liche blockchain. Andere Varianten, mit denen die hier vorgestellte Lösung ebenfalls zu reali- sieren ist, sind eine erlaubnisbasierte private blockchain oder eine erlaubnislose öffentliche blockchain.
Der distributed ledger macht den smart contract SC für jede vertrauende Partei transparent und erlaubt die Validierung des smart contract SC und der in ihm enthaltenen Berechnungs- anweisungen selbst. Mit Hilfe von Validierungsschemata kann die Herkunft der zugrunde lie- genden Zertifikate nachgewiesen werden. Damit bleibt der loa erhalten, ohne dass das zu- grundeliegende Datenelement aus zum Beispiel einem E-Pass des Nutzers N offengelegt wird. Zur Beantwortung einer gestellten Anfrage (z.B.: ist der Nutzer volljährig? "istVolljäh- rig()") wird einer Berechnung mit dem smart contract SC ein zertifiziertes Datenelement, in diesem Beispiel das Geburtsdatum des Nutzers N verwendet. Die Fig. 1 veranschaulicht die- sen Ablauf. Der smart contract SC kann von vertrauenden Parteien unter Verwendung der Blockchain-Funktionalität auf weitere Eigenschaften wie "istVerheiratet()", "istÜber24()", "istEuropäer()", "istKrankenversichert()" usw. erweitert werden.
Aus dem Vertrauen, das die distributed Berechnung (und die (starke) Verschlüsselung) bie- ten, ergibt sich die loa. Das hashing des smart contract und dessen Speicherung im distribu- ted n ledger garantiert, den loa, solange mehr als die Hälfte der miner unabhängig ist. Der smart contract garantiert, dass der berechnete Wert genau zu der Berechnungsanweisung des smart contract gehört, und dass die Validierung des smart contract und des proof zu- verlässig sind.
Das Ergebnis der Berechnung wird zu einem neuem proof mit einer Zertifizierung aus dem blockchain-Netzwerk. Das Zertifikat kann der Nutzer N in der wallet speichern und später bei Anforderung verwenden. Der einmal generierte proof kann mehrfach gezeigt werden. Der proof selbst enthält eine mit einem Zeitstempel versehene Zertifizierung. So kann die In- stanz, der der proof vorgelegt wird, den Berechtigungsnachweis entsprechend bewerten.
Ausgangspunkt ist, dass der Nutzer N von einer Vertrauen genießenden Instanz Certificate Authority zum Beispiel einer offiziellen Behörde (Regierung) identifiziert (i) mit einem ID- Dokument, (ii) einem Ausweis/einer Urkunde (Reisepass, Personalausweis), oder (iii) mit biometrischen Daten. Alternativ oder kumulativ verfügt der Nutzer N über ein digital signier-
tes Zertifikat der Instanz Certificate Authority in einem elD-Dokument oder in einer autori- sierten Datenbank. Alternativ oder kumulativ verfügt der Nutzer N über ein digital signiertes Zertifikat in einer digitalen wallet als mobile ID in seinem smart phone oder als Software- wallet in einem Rechner. Das digital signierte Zertifikat ist für den Benutzer zur Weiterverar- beitung zugänglich.
Als Beispiel sei vorgesehen, dass der Nutzer N ein Objekt Obj mieten möchte. Dazu stellt der Nutzer N eine Anfrage an den Inhaber des Objekts Obj auf elektronischem Weg, z.B. mit seinem smart phone oder drahtlos oder drahtgebunden. (Fig. 1, Schritt 1)
Als Antwort erhält der Nutzer N auf elektronischem Weg, dass er zum Mieten des Objekt Obj belegen muss, die Beschränkung RE zu erfüllen, 24 oder älter zu sein. (Fig. 1, Schritt 2)
Um diesen Beleg zu erbringen, verbindet sich der Nutzer N auf elektronischem Weg mit ei- ner biockchain BC und liefert der biockchain BC sein Geburtsdatum und seine Pass-ID inklu- sive offizieller Unterschriften ein. (Fig. 1, Schritt 3)
Die biockchain BC umfasst einen smart contract SC. Dieser smart contract SC prüft die Si- gnaturen und berechnet den proof. Der proof wird von der biockchain BC mithilfe einer ver- teilten kryptografischen Funktion signiert. (Fig. 1, Schritte 4 - 8)
Der signierte proof wird an den Nutzer N zurückgeschickt. Der Nutzer N legt den proof zur weiteren Verwendung in seine wallet. Die wallet kann so konfiguriert sein, dass der proof automatisch an die Instanz weitergeleitet wird, die den Nachweis angefordert hat, hier das Objekt Obj. (Fig. 1, Schritt 9)
Der proof wird entweder automatisch oder manuell von dem Nutzer N an die Instanz wei- tergeleitet, die den Nachweis angefordert hat. Die Instanz kann nun die Signatur des proof prüfen und über die Zugangsentscheidung befinden. (Fig. 1, Schritte 10 - 16)
Der Ablauf im Einzelnen ist wie folgt:
Im Schritt 1 erfolgt durch den Nutzer N auf elektronischem Weg ein Zugriff auf ein Objekt Obj, das durche eine Einschränkung RE geschützt ist. Das Objekt Obj kann ein Mietvertrag für eine Wohnung sein. Die Einschränkung RE besteht darin, dass der Mieter 24 Jahre alt oder älter sein muss.
Im Schritt 2 teilt das Objekt Obj dem Nutzer N auf elektronischem Weg dass er einen Nach- weis zu erbringen hat, dass der Mieter 24 der Wohnung Jahre alt oder älter sein muss.
Im Schritt 3 kontaktiert der Nutzer N einen distributed ledger DL. Dieser distributed ledger DL umfasst eine blockchain BC. Diese biockchain BC enthält einen smart contract "Over23 proof". So kann der Nutzer N einen Beleg dafür erzeugen (lassen), dass er die Einschrän- kung RE erfüllt, 24 Jahre alt oder älter zu sein, ohne dabei sein Geburtdatum (Tag, Monat, Jahr) gegenüber dem Vermieter offenlegen zu müssen.
Im Schritt 4 fordert der smart contract SC den öffentlichen Schlüssel public key des Unter- zeichners des Dokuments D (der Zertifizierungsstelle CA) an, um die Authentizität zu prüfen. Der smart contract SC erhält den öffentlichen Schlüssel public key in der Regel aus einer Austauschplattform PKD public key directory der der Zertifizierungsstelle CA Teilnehmer le- gen ihre öffentlichen Schlüssel public keys dort ab, damit mit diesen öffentlichen Schlüsseln public key Nachrichten an sie verschlüsselt werden können. Das Entschlüsseln ist nur beim Empfänger mit dessen privatem Schlüssel private key möglich. Mit diesem Mechanismus las- sen sich auch so genannte digitale Signaturen erzeugen, wobei hier eine Signatur mit sei- nem private key erzeugt und mit dem zugehörigen öffentlichen Schlüssel überprüft wird.
Diese Signaturen belegen, ob eine Nachricht vom angegebenen Absender stammt oder ob sie von einer unbefugten Person verändert wurde: ob also beispielsweise Daten von der je- weiligen Behörde auf einen elektronischen Pass geschrieben wurden oder ob sie manipuliert sind.
Eine digitale Signatur basiert auf einer asymmetrischen Verschlüsselung, bei der ein Sender mit Hilfe seines private key zw einer digitalen Nachricht einen Wert errechnet, der digitale Signatur genannt wird. Mit diesem Wert und dem public key können Dritte die nicht abstreit- bare Urheberschaft und Integrität der Nachricht prüfen. Um eine mit einem Signaturschlüs- sel erstellte Signatur einer Person zuordnen zu können, muss der public key dieser Person zweifelsfrei zugeordnet sein. Aus der zu signierenden digitalen Nachricht und dem private key wird durch eine eindeutige Rechenvorschrift die Signatur berechnet. Unterschiedliche digitale Nachrichten müssen dabei mit an Sicherheit grenzender Wahrscheinlichkeit zu einer anderen Signatur führen, und die Signatur muss für jeden Schlüssel einen anderen Wert ergeben. Bei einer digitalen Signatur wird der private key in der Regel nicht direkt auf die Nachricht angewendet, sondern auf deren Hash-Wert, der mittels einer Hashfunktion (wie z. B. SHA-2, SHA-3 oder dergl.) aus der Nachricht berechnet wird. Soweit der public key mit- tels eines digitalen Zertifikats einer Person zugeordnet wurde, kann, da es nur einen zum public key korrespondierenden private key gibt, über das öffentliche Verzeichnis des Zertifi- zierungsdiensteanbieters die Identität des Signaturerstellers ermittelt und überprüft werden. Die Gesamtheit der technischen Infrastruktur, mit der die Zertifikate und Informationen zu
ihrer Gültigkeit erzeugt und öffentlich bereitgestellt werden, wird als PKI (Public Key Infra- structure) bezeichnet.
Dabei ist die Authentizität des Absenders wesentlich - also der Nachweis, dass ein Heraus- geber eines öffentlichen Schlüssels auch tatsächlich der ist, der er vorgibt zu sein. Die Pub- lic-Key-Infrastruktur PKI ermöglicht, die Vertrauenswürdigkeit eines öffentlichen Schlüssels sicherzustellen, indem dieser aus einem vertrauenswürdigen Schlüsselverzeichnis bezogen wird. In der Austauschplattform public key directory können Aussteller von Dokumenten ihre öffentlichen Schlüssel publizieren, die zur Verifikation notwendig sind. Von der Plattform kann der smart contract SC dann den öffentlichen Schlüssel public key beziehen.
Im Schritt 5 wird der öffentliche Schlüssel public key dem smart contract SC übermittelt.
Im Schritt 6 prüft der smart contract SC die Unterschrift der Zertifizierungsstelle CA unter dem Dokument D. Falls die Signatur gültig ist, werden die nächsten Schritte ausgeführt. Wenn nicht, bricht die Ausführung hier ab.
Im Schritt 7 erfolgt die Altersprüfung basierend auf der Berechnungsvorschrift in dem smart contract SC und der Angabe des Geburtsdatums in dem Dokument D, dessen Richtigkeit und Vertrauenswürdigkeit durch die Verschlüsselung mit dem öffentlichen Schlüssel public key und die Authentizität des Dokuments aus der Zertifizierungsstelle CA belegt ist. Die Informa- tion INFO gelangt aus dem Dokument D von der Zertifizierungsstelle CA zu dem smart con- tract SC in der nachstehend dargestellten Weise. Hierbei werden die erforderlichen Daten dem smart contract SC direkt zur Verfügung gestellt. Das zuständige public key directory PKD ist vorher in dem smart contract SC eingetragen. In einer weiteren Variante hat das Dokument D bereits die notwendigen Zertifikate. Dies erübrigt weitere Dienste. Dem smart contract SC vorangeschaltet kann eine Dictionary-Funktionalität sitzen, die dem Nutzer Aus- kunft gibt, welcher smart contract SC für seine Anfrage am geeignetsten sein könnte.
Pseudo Code zum Erzeugen eines neuen Zertifikates
// Das Datum wird signiert, das Zertifikat dazu wird mitgegeben
// Im Zertifikat sind der Herausgeber und die Gültigkeitsdauer des Zertifikats angegeben.
// Das Datum im Zertifikat entspricht den Angaben in der machine readable zone, MRZ, eines Passes // oder ID Karte, deren hash in dem document security object, SOD des Passes oder ID-Karte signiert // abgelegt ist. let DG1 = ["IDD< < 1234567897< < <<<<<<<<<<<<<",
"9701218F2026031D<<<<<<<<<< <<<()",
"MARTINA< <<SPECIMEN<< <<<<<<<<<<"];
let SOD = [ hashDGl = "596BAE8E7BA9F4D6FC9A468251B3B08A", // MD5 hash als Bsp.
... // weitere hashes weiterer Datengruppen sodSignatur = "SidcJvN0zGHGaTtmcmuUVIS6BGlLf2o9hbFT9ND08T8=", sodCertificat = "The Certificate to prove the signature, optional... "]; let personalData = [DG1, SOD];
// Diese Adresse wird von der BC vergeben und ist unveränderlich const SC_ADDRESS = "ID_OF_THE_SMARTCONTRACT";
// die staatliche CA, falls kein Zertifikat vorhanden ist const govCA = RESPONSIBLE_COUNTRY_CA; var certificate = undefined;
// Hilfskonstante zum Altersvergleich const ticks24years = dockTicksfor24Years();
// Struktur zur Aufnahme des zertifizierten Ergebnisses (analog zu SOD) dass SignedResult = {result, scAddr, signature, certificate};
// Hilfsfunktion zum Prüfen des Zertifikates function boolean checkSignatureOfData(signedData){ if (hasCertificate(signedData) ){ certificate = getCertificateFromData(signedData);
}else( certificate = getCertificateFromPKD(govCA);
) return isValid(signedData, certificate);
} function SignedResult generateSignedResult( result, addr ) {
// es wird im SC ein externer, vertrauenswürdiger Dienst gerufen der das Ergebnis des SC signiert var signature = callTrustedSignatureService(result, addr ); return new SignedResult( result, addr, signature, certificate );
} function SignedResult over23( personalData ) {
// Prüfen der Validität der Signatur if (checkSignatureOfData( personalData ) )
{ var DateOfBirth = extractDoB(personalData); boolean res = ( (now() - DateOfBirth) > ticks24Years );
// optional kann der Zeitstempel mit in das Ergebnis einfließen result = [res, timestamp ]; return generateSignedResult( result, SC_ADDRESS );
}
}
Pseudo-Code zum Validieren des Zertifikates
// Funktion zur Prüfung der Signatur function boolean isSCCertificateVaIid ( scCredential ){ result = scCredential. result;
address = scCredential.scAddr;
Signatare = scCredential.signature; cert = scCredential.certificate; return (callTrustedSignatureService(result, address ) == signature);
}
Damit errechnet der smart contract SC auf Basis eines von der Zertifizierungsstelle CA be- reitgestellten Dokuments D, zum Beispiel einem E-Pass-Dokument, genauer gesagt einer in dem Dokument D den Nutzer N betreffenden Information INFO in einem elektronischen For- mat, die Erfüllung der Einschränkung RE durch den Nutzer N. Das Ergebnis dieser Berech- nung ist eine Wahr/Falsch-Angabe. Im vorliegenden Beispiel wird von dem aktuellen Tages- datum (Jahr - Monat - Tag) das Geburtsdatum (Jahr - Monat - Tag) des Nutzers N, wie es aus seinem E-Pass-Dokument D entnehmbar ist, subtrahiert und das Ergebnis mit 23 Jahren verglichen. Wenn das Ergebnis größer ist als 23, wird der smart contract SC ein „Wahr" aus- geben; wenn das Ergebnis kleiner ist als 23, wird der smart contract SC ein „Falsch" ausge- ben. Anstelle dieses Beispiels könnte auch ein smart contract SC mit beliebiger anderer Funktionalität / Prüffähigkeit ausgeführt werden.
Im Schritt 8 erfolgt die Signierung des Ergebnisses. Die Vertrauensbasis dieses Ansatzes ist der distributed ledger DL. Jeder Teilnehmer kann den smart contract SC einsehen und vali- dieren. Ein dedizierter distributed hash zur Erkennung von Manipulationen schützt jeden smart contract SC. Das Ergebnis der Berechnung wird mit einer ID des Nutzers gebündelt. Hierdurch werden die ID des Nutzers N und der Beweis proof mit der ID des smart contract SC, genauer gesagt der Adresse des smart contract SC verknüpft, um die Herkunft des Er- gebnisses der Berechnung zu dokumentieren. Für dieses Tripel <ID, SC-result, SC-hash> er- mittelt dann der distributed ledger DL einen hash-Wert, um die Authentizität des Tripels zu dokumentieren. Das Tripel kann nicht verändert werden, ohne den hash des distributed ledger DL zu zerstören. Der distributed ledger DL -Konsens ist in einer Variante ein "proof- of-work" und in einer anderen Variante ein "proof-of-stake".
Im Schritt 9 wird das Triple <ID, SC-result, SC-hash> als Ergebnis der Berechnung durch den smart contract SC an den Nutzer N auf elektronsichem Weg zurückgesendet. Der Nutzer N kann nun das Ergebnis in seiner wallet speichern.
Im Schritt 10 wird das Ergebnis der Berechnung durch den Nutzer N an das Objekt Obj auf elektronischem Weg gesandt. Dies kann durch den Nutzer manuell ausgelöst erfolgen, oder automatisch, indem das Weiterleiten aufgrund gespeicherter bevorzugter Einstellungen er- folgt, sobald das Ergebnis der Berechnung den Nutzer N auf elektronischem Weg erreicht hat und in seiner wallet gespeichert ist.
Im Schritt 11 wird in einer Anfrage zur Verifizierung die Gültigkeit des proof vom Objekt Obj überprüft. Alternativ dazu kann der proof vom Objekt Obj an eine dedizierte Verifizie- rungsinstanz VI zur Verifizierung weitergeleitet werden.
Im Schritt 12 prüft die dedizierte Verifizierungsinstanz VI die Gültigkeit der hashes und der Signatur mittels einer Anfrage an den distributed ledger DL.
Im Schritt 13 erfolgt eine Validierung, indem die Echtheit des Triple <ID, SC-result, SC- hash> und der Triple-Signatur einer Überprüfung unterzogen werden. Dazu vergleicht der distributed ledger DL das übermittelte Tripel und dessen hash-Wert mit den ursprünglich mittels des smart contract SC erzeugten Tripels, und anschließend mittels des distributed ledger DL erzeugten Werten.
Im Schritt 14 kommt das Verifizierungsergebnis aus dem distributed ledger DL. Der distribu- ted ledger DL ist als unabhängige Instanz ausgestaltet, die das Ergebnis liefert. Eine Eigen- schaft des distributed iedger DL ist, dass er online oder offline verfügbar ist, da er auf ver- schiedene Knoten im Netzwerk verteilt ist. So kann die Verifizierung online oder offline mit einer lokalen, gesicherten und zertifizierten Kopie des distributed iedger DL erfolgen. Der di- stributed iedger DL muss jedoch von Zeit zu Zeit online sein, um auf neueste Änderungen des distributed iedger DL aktualisiert zu werden. Der distributed iedger DL ist in der hier ein- gesetzten Variante bevorzugt erlaubnisbasiert.
Im Schritt 15 erfolgt die Entscheidung der Verifizierungsinstanz VI basierend auf dem Veri- fizierungsergebnis. Hierzu generiert die Verifizierungsinstanz VI eine Entscheidung zu den ursprünglich angeforderten Anfrage. Im vorliegenden Beispiel bestätigt oder nicht bestätigt die Verifizierungsinstanz VI die Anfrage, hat der Nutzer ein "Alter-über-23"?
Im Schritt 16 kann der angeforderte Zugriff aus Schritt 1 in Abhängigkeit von der Entschei- dung aus Schritt 15 gewährt werden oder nicht. Beim nächsten Zugriff auf eine Ressource mit derselben Anfrage können die Schritte ab Schritt 9 durchgeführt werden. Voraussetzung ist, dass die ID des Nutzers N nicht geändert wird.
Die einzelnen Schritte sind auch wie folgt in Java-Programmnotation zu beschreiben:
1. Zugriff.beschränktes.Objekt(ID, ObjID)
2. ObjID. nachweis(Alter >23)
3. BerechneAltersnachweisAlter >23(ID, signiertes Dokument)
4. HolePublicKey ()
5. SendePublicKey ()
6. Beweisesignatur (PublicKey)
7. BerechneAltersnachweis(Grenze = 23, Geburtsdatum)
8. ErzeugeCryptoSigniertenProof (blockchain Netzwerk)
9. SendeSigniertenAgeproof (signed(wahr/falsch)
10. Weiterleiten (ID, CryptoSignedProof23)
11. Nachfrageverifizierung (ID2, CryptoSignedProof23)
12. Verifizierung (CryptoSignedProof23): wahr/falsch
13. BelegeGültigkeitQ: wahr/falsch
14. VerifizierungsErgebnisQ : wahr/falsch
15. Entscheidung (ID2, ObjID): wahr/falsch
16. ZugangGewährt(ID2, ObjID): wahr/falsch
Ein weiterer Anwendungsfall ist der Nachweis der allgemeinen Hochschulreife, bei der als Nutzer der Inhaber eines Abiturzeugnisses die Qualifikation nachweisen kann, ohne Details der Prüfung, wie Datum, Ort, Note oder sonstige Inhalte des Abiturzeugnisses preiszugeben. Es wird lediglich nachgewiesen, dass der Nutzer über die allgemeine Hochschulreife verfügt, zu der er ein gültiges Zertifikat von dem smart contract SC erhalten hat.
Ein weiterer Anwendungsfall ist die Teilnahme an einem Sozialhilfeprogramm. Der Nutzer N beantragt eine staatliche Leistung und weist nach, dass er dazu berechtigt ist. Dazu lässt der Nutzer N seine inländische Adresse gegen seinen Wohnort in seinem Personalausweis als Wahl-/Fasch -Aussage abprüfen.
Ein weiterer Anwendungsfall ist eine KFZ-Zulassung, bei der der Nutzer N ein Auto anmel- den möchte. Dazu muss er bei der KFZ-Zulassungsstelle seine Anschrift und Steuerinforma- tionen angeben. Die Anschrift wird bei der KFZ-Zulassungsstelle vollständig angegeben. Ein Nachweis über ausstehende Steuern des Nutzers N wird von KFZ-Zulassungsstelle verlangt. Der Nutzer N gibt seine Steueridentifikationsnummer an. Der Nutzer N selbst kontaktiert auf elektronischem Wege einen entsprechend programmierten smart contract SC. Der smart contract SC verbindet sich unter Bezug auf die Steueridentifikationsnummer des Nutzers N mit den Steuerbehörden und erhält die Aussage, dass keine offenen Steuerzahlungen des Nutzers N bestehen. Daraufhin bescheinigt der smart contract SC das Ergebnis, wonach der Nutzer N keine Steuerschulden hat. Der Nutzer N nutzt diesen Nachweis, ohne seine Steuer- identifikationsnummer bei der KFZ-Zulassung preiszugeben.
Ein weiterer Anwendungsfall ist ein Einlagenzertifikat, bei dem der Nutzer N aufgefordert wird, die Verfügbarkeit eines bestimmten Geldbetrags zur Vorbereitung einer Transaktion
(Miete/Kauf eines Hauses, Kauf eines Autos usw.) zu beweisen. Der Nutzer N verwendet einen entsprechend programmierten smart contract SC zusammen mit Details seiner Bank- verbindung (Kontoverbindung, Kreditlinie des Girokontos, Bakguthaben) um den erforderli- chen Betrag als verfügbar zu beweisen, ohne die Kontonummer, das Finanzinstitut und an- dere Details preiszugeben.
Ein weiterer Anwendungsfall ist ein Führerscheinnachweis, zu dem der Nutzer N nachweisen muss, dass er zum Fahren berechtigt ist und mindestens 24 Jahre alt ist. Die hier vorgestell- te Verfahrensweise liefert einen Nachweis ohne Offenlegung der sonstigen Details der Fah- rerlaubnis des Nutzers N. Analog kann auch die Berechtigung zum Fahren bestimmter Fahr- zeuge, festgelegt in den Führerscheinklassen ( B, B17, B96, B196, BE, A1, A2, A, AM, C1, C1E, C, CE, D1, D1E, D, DE, L, T) oder Gruppen davon ohne Offenlegung der sonstigen De- tails der Fahrerlaubnis des Nutzers N nachgewiesen werden.
Die vorangehend beschriebenen Varianten der Vorrichtung, deren Aufbau- und Betriebsas- pekte, sowie die Varianten der Verfahrensweise dienen lediglich dem besseren Verständnis der Struktur, der Funktionsweise und der Eigenschaften; sie schränken die Offenbarung nicht etwa auf die Ausführungsbeispiele ein. Die Fig. sind teilweise schematisch. Dabei sind wesentliche Eigenschaften und Effekte zum Teil deutlich vergrößert dargestellt, um die Funktionen, Wirkprinzipien, technischen Ausgestaltungen und Merkmale zu verdeutlichen.
Dabei kann jede Funktionsweise, jedes Prinzip, jede technische Ausgestaltung und jedes Merkmal, welches/welche in den Fig. oder im Text offenbart ist/sind, mit allen Ansprüchen, jedem Merkmal im Text und in den anderen Fig., anderen Funktionsweisen, Prinzipien, tech- nischen Ausgestaltungen und Merkmalen, die in dieser Offenbarung enthalten sind oder sich daraus ergeben, frei und beliebig kombiniert werden, so dass alle denkbaren Kombinationen der beschriebenen Vorgehensweise zuzuordnen sind. Dabei sind auch Kombinationen zwi- schen allen einzelnen Ausführungen im Text, das heißt in jedem Abschnitt der Beschreibung, in den Ansprüchen und auch Kombinationen zwischen verschiedenen Varianten im Text, in den Ansprüchen und in den Fig. umfasst. Auch die Ansprüche limitieren nicht die Offenba- rung und damit die Kombinationsmöglichkeiten aller aufgezeigten Merkmale untereinander. Alle offenbarten Merkmale sind explizit auch einzeln und in Kombination mit allen anderen Merkmalen hier offenbart.