DE102017217342B4

DE102017217342B4 - Verfahren zum Verwalten eines elektronischen Transaktionsdokuments

Info

Publication number: DE102017217342B4
Application number: DE102017217342.4A
Authority: DE
Inventors: Patentinhaber gleich
Original assignee: Individual
Current assignee: Catena De GmbH
Priority date: 2017-09-28
Filing date: 2017-09-28
Publication date: 2019-08-14
Anticipated expiration: 2037-09-29
Also published as: WO2019063512A1; DE102017217342A1

Abstract

Verfahren zum Verwalten eines elektronischen Transaktionsdokuments (T) zwischen einem Benutzer (U) und einem Empfänger (V) in einer Transaktionskette (TC) in einer Datenbank (TDB), wobei sowohl der Benutzer (U) als auch der Empfänger (V) jeweils ein kryptographisches Schlüsselpaar besitzen, das einen öffentlichen Schlüssel (nu; nv) und einen privaten Schlüssel (σ_U; σ_V) umfasst, wobei das elektronische Transaktionsdokument (T) aus einem Transaktionsinhalt (d) vom Benutzer (U) zum Empfänger (V) und einem Transaktionsinhalt-Hash-Wert (h(d)), der mit dem privaten Schlüssel (σ_U) des Benutzers (U) signiert ist, besteht, und wobei das Verfahren die folgenden Schritte umfasst:
- Empfangen eines zu archivierenden elektronischen Transaktionsdokuments (T) durch die Datenbank (TDB),
- Überprüfen einer Zertifizierung des elektronischen Transaktionsdokuments (T),
- Zertifizieren des elektronischen Transaktionsdokuments (T) mit einem Datenbankschlüssel (σ_S),
- Lesen des vorherigen zuletzt eingegebenen elektronischen Transaktionsdokuments (T), das in der Transaktionskette (TC) enthalten ist, und Berechnen von dessen Hash-Wert,
- Identifizieren der Position (n) der zuletzt eingegebenen elektronischen Transaktion (T_n) und Inkrementieren von dieser um Eins,
- Erzeugen eines Tripels der inkrementieren Position (n+1), des Hash-Werts der vorherigen zuletzt eingegeben elektronischen Transaktion (T_n) und des elektronischen Transaktionsdokuments (T),
- Signieren des Tripels mit dem Datenbankschlüssel (σ_S),
- Speichern des signierten Tripels als neue letzte elektronische Transaktion (T_n+1) in der Transaktionskette (TC).

Description

Die vorliegende Erfindung betrifft das Gebiet von kryptographischen Techniken und Datenbanktechniken und insbesondere die Verwaltung eines elektronischen Transaktionsdokuments. Die Erfindung ermöglicht, auf eine neuartige Weise, die Verwaltung von Verträgen und digitalen Transaktionen auf eine kryptographisch zertifizierte, sichere, unveränderliche und dauerhafte Weise.
Die Techniken der Kryptographie sind

1. öffentlich-private Schlüsselpaare zur Verschlüsselung und Entschlüsselung
2. kryptographische Signaturen.

Die Techniken von Datenbanken sind

1. ACID-Transaktionen
2. Serialisierung
3. Integritätsbeschränkungen

Das Verfahren der Erfindung bietet Sicherheit und Dauerhaftigkeit sowohl für den Inhalt von Verträgen als auch für die Buchführung von Verträgen in Transaktionsketten.
Technologischer Hintergrund / Grundlegende Konzepte
Gesetze der öffentlichen Kryptographie
Schlüsselpaare [σ, π] für Eigentümer U bezeichnet durch: [σ_U, π_U]
Ein Schlüsselpaar [σ, π] besteht aus dem privaten Schlüssel σ und dem öffentlichen Schlüssel π.
σ muss durch den Eigentümer geheim gehalten werden und sollte an einen sicheren Platz kopiert werden, damit er nicht verlorengeht .
π ist öffentlich und kann in einer öffentlichen Schlüsseldatenbank UDB (User Data Base - Benutzerdatenbank), optional zusammen mit zusätzlichen Informationen, gespeichert werden. Jeder kann π sehen und die UDB abfragen und lesen. Der Eigentümer U von π kann anonym bleiben oder offenbaren, wer U als eine Person oder eine Organisation ist (Authentisierung/Authentifizierung).
Verschlüsselung und Entschlüsselung
Verschlüsselung von öffentlichen Dokumenten
d kann ein beliebiges Dokument sein, z.B. der Text eines Vertrags oder ein Foto.
Ein Dokument d kann unter Verwendung des privaten Schlüssels σ verschlüsselt und signiert werden, um σ(d) zu berechnen, wobei das Ergebnis nur eine lange Zahl C1 ist. Die verschlüsselte Version C1 von d kann wieder entschlüsselt werden, indem der entsprechende öffentliche Schlüssel π verwendet und π(σ(d)) berechnet wird. Dies spiegelt das erste grundlegende mathematische Gesetz der öffentlichen Kryptographie wider:
π (σ (d)) = d Dieses Gesetz wird später zum Verschlüsseln und digitalen Signieren eines Dokuments verwendet.
Verschlüsselung von geheimen Dokumenten
Das zweite grundlegende mathematische Gesetz der öffentlichen Kryptographie ist das Umgekehrte des ersten: σ (π(d)) = d Dieses Gesetz wird zur Verschlüsselung eines Dokuments verwendet, um seinen Inhalt zu verbergen.
Man nehme an, dass d mit dem öffentlichen Schlüssel π von O chiffriert worden ist, was zu π(d) führt. Daher kann es nur durch den Eigentümer von σ dechiffriert und gelesen werden. Falls daher π(d) irgendwie durch irgendjemanden erhalten wird, z.B. einen Benutzer U oder sogar einen Hacker H, durch ein Abfangen einer Nachricht, die π(d) enthält, ist dies komplett nutzlos, da er es nicht dechiffrieren kann. Um π(d) zu dechiffrieren, würde er σ brauchen, aber σ wird definitionsgemäß durch seinen Eigentümer O geheim gehalten.
Beide Gesetze sind zusammen das grundlegende Gesetz der öffentlichen Kryptographie: $π (σ (d)) = d = σ (π (d))$
Digitale Signatur
Ein unchiffriertes Dokument d zusammen mit der chiffrierten Version σ (d), bezeichnet als [d, σ(d)], sind ein mathematischer Beweis, dass d nicht geändert worden ist, falls die folgende Eigenschaft wahr ist: π (σ(d)) = d Falls d aber zu d1 geändert worden ist, was zu [d1, σ(d)] führt, dann ist die Berechnung von π(σ(d)) = d ungleich d1 und daher kann d1 nicht das Original d sein.
Da σ geheim ist, kann nur der Eigentümer O von σ σ(d) erzeugt haben, mit der Eigenschaft, dass π(σ(d)) = d
Daher verwenden wir σ(d) auch als die digitale Signatur von O, wodurch mathematisch bewiesen wird, dass O das Dokument d signiert hat und dadurch die Richtigkeit von d zertifiziert.
Daher kann irgendjemand, der den öffentlichen Schlüssel π, das Dokument d und σ(d) kennt, verifizieren, dass d nicht geändert worden ist (Unveränderlichkeit von d).
Es ist zu beachten, dass σ(d) drei vollständig unterschiedliche Aspekte aufweist:

1. Verschlüsselung: σ(d) ist verschlüsselt
2. Unveränderlichkeit: falls π(σ(d)) = d, dann ist d nicht geändert worden
3. σ(d) ist durch den Eigentümer von σ digital signiert worden.

Eine derartige digitale Signatur weist die folgenden grundsätzlichen Eigenschaften auf:

1. eine digitale Signatur kann niemals durch den Eigentümer O von σ bestritten werden
2. eine digitale Signatur kann niemals durch O widerrufen werden
3. eine digitale Signatur kann nicht gefälscht werden

Die grundlegenden Gesetze der öffentlichen Kryptographie zusammengefasst: $σ (π (d)) = d = π (σ (d))$

σ(d) wird in einer C-Chain (C-Kette) als eine (öffentliche) digitale Signatur verwendet
π(d) wird in einer C-Chain zur geheimen Kommunikation eines Dokuments verwendet

Digitale Signaturen mit einer Hash-Funktion
Eine Hash-Funktion h ist eine mathematische Einweg-Funktion. h(d) kann leicht berechnet werden, aber es ist praktisch unmöglich, seine Inverse h^-1(d) zu berechnen.
Des Weiteren ist es für zwei verschiedene Dokumente d1 und d2 extrem unwahrscheinlich, dass h(d1) = h(d2). Daher kann h(d) auch zum Beweisen verwendet werden, dass d nicht geändert worden ist. Aber h(d) dient nicht als eine Signatur, da jedermann h(d) für eine öffentlich bekannte Funktion h berechnen kann.
Die US 2017/0257358 A1 offenbart ein Authentifizierungsverfahren, das ein Senden einer Login-Webseite an ein erstes Gerät eines Benutzers, einschließlich eines scanbaren Codes mit einer Umschlag-ID und einer Login-Herausforderung, umfasst. Die von einem Identitätsmanager erzeugte Umschlag -ID ist einem ersten Datenumschlag zugeordnet, die eine Sitzungs-ID enthält. Eine Bestätigungsanmeldeanforderung wird von einem zweiten dem Benutzer zugeordneten Gerät empfangen und enthält einen zweiten Datenumschlag, der die Sitzungs-ID, eine Benutzer-ID und ein Siegel der Benutzer-ID umfasst, die die Benutzer-ID beim Identitätsmanager registriert. Die Bestätigungsanmeldeanforderung für die Anmeldeanforderung wird mithilfe der Sitzungs-ID überprüft und der Benutzer wird anhand der Benutzer-ID und des Kennzeichens verifiziert. Die Benutzeranmeldung wird nach erfolgreicher Überprüfung der Anmeldeanforderung und des Benutzers autorisiert, und eine Kommunikationssitzung mit der Sitzungs-ID wird zwischen dem Webserver und dem ersten Gerät eingerichtet.
Die US 2017/0228731 A1 offenbart einen CETPA (Computational Efficient Transfer Processing und Auditing) genannten Prozess unter Einsatz eines Blockchain-Transaktionsdatenprüfgeräts, das eine Blockchain-Aufzeichnungskomponente, eine Matrixumwandlungskomponente und eine Bloom-Filterkomponente umfasst. Die Blockchain-Aufzeichnungskomponente empfängt mehrere Transaktionsdatensätze für jede einer Vielzahl von Transaktionen, wobei jeder Transaktionsdatensatz eine Quelladresse, eine Zieladresse, einen Transaktionsbetrag und einen Zeitstempel einer Transaktion umfasst. Die die Quelladresse umfasst eine Quellbörsenadresse, die einer digitalen Quellmappe entspricht, und die Zieladresse umfasst eine Zielvermerkadresse, die einer virtuellen Zielwährungsmappe entspricht. Die Blockchain-Aufzeichnungskomponente überprüft, ob der Transaktionsbetrag in der virtuellen Quellenwährung verfügbar ist und, wenn der Transaktionsbetrag verfügbar ist, zeichnet kryptographisch die Transaktion in einer Blockkette auf, die eine Vielzahl von Hashes von Transaktionsdatensätzen umfasst.
Kurzdarstellung der Erfindung
Basierend hierauf schlägt die Erfindung ein Verfahren zum Verwalten eines elektronischen Transaktionsdokuments in einer Datenbank mit den Merkmalen von Anspruch 1, ein Datenbanksystem mit den Merkmalen des Anspruchs 2, ein Computersystem mit den Merkmalen des Anspruchs 3 sowie ein Computerprogramm mit den Merkmalen des Anspruchs 4 vor.
Die Erfindung bietet eine kryptographisch sichere, unveränderliche, skalierbare, effiziente Verwaltung von digitalen Verträgen. Dies wird im Folgenden C-Chain (C-Kette) genannt.
Weitere Merkmale und Ausführungsformen der Erfindung werden aus der Beschreibung und den begleitenden Figuren ersichtlich. In den Zeichnungen zeigen die 1 bis 8 verschiedene Beispiele und Ausführungsformen der Erfindung.
Es versteht sich, dass die oben erwähnten Merkmale und die nachfolgend beschriebenen nicht nur in der angegebenen Kombination, sondern auch in anderen Kombinationen oder alleine verwendet werden können, ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen.
Die Erfindung umfasst auch ein Computerprogramm mit Programmcodemitteln, die zum Ausführen eines Prozesses gemäß der Erfindung, wie oben beschrieben, geeignet sind, wenn das Computerprogramm auf einem geeigneten Computer oder Datenbankverwaltungssystem ausgeführt wird. Sowohl das Computerprogramm selbst als auch auf einem computerlesbaren Medium gespeichert werden beansprucht. Der Ausdruck Computer soll so verstanden werden, dass er eine beliebige Art von Datenverarbeitungseinrichtung abdeckt, die Personal-Computer, Datenbankverwaltungssysteme, Smartphones, Mikrocontroller, die auf Smartcards implementiert sind, oder beliebige andere Einrichtungen, die zur Datentransaktion verwendet werden, einschließen.
Eine digitale Identität cryptlD gemäß der Erfindung ist das Paar [π, σ( h(π)) ].
Für einen speziellen Benutzer U wird dessen cryptlD durch das Paar [π_U, σ_U (h(π_U))] bezeichnet.
Die cryptlD von U kann leicht durch U erzeugt und durch einen anderen Benutzer V wie folgt geprüft werden:

1. Berechnen der Hash-Werte v1 und v2 als h(π_U) = v1 der ersten Komponente des Paares
2. Entschlüsseln von σ_U(h(π_U)) der zweiten Komponente des Paares unter Verwendung der ersten Komponente, um π_U(σ_U(h(π_U ))) = h(π_U) = v2 zu berechnen
3. falls v1 = v2, steht fest, dass U der Eigentümer von π_U ist

Wir verwenden daher die cryptlD zum Einrichten eines Kommunikationskanals mit einem beliebigen Partner, z.B. mit einer anderen Person, einem WEB-Dienst oder einem beliebigen Computerserver.
Eine cryptID wird durch U wie folgt erzeugt:

1. Erzeugen eines Schlüsselpaares [σ_U, π_U] unter Verwendung einer geeigneten Software auf einem Computer, wie auf einem Smartphone, einem Tablet, einem PC oder einem Server.
2. Berechnen der Hash-Funktion h(π_U), was leicht ist
3. Digitales Signieren von h(π_U)durch Berechnen von σ_U (h( π_U)), was auch leicht ist
4. Bilden des Paares [π_U, σ_U(h(π_U))] als die cryptlD von U
5. U kann jetzt seine cryptlD einem Kommunikationspartner V präsentieren oder sie einfach in der öffentlich verfügbaren Datenbank UDB veröffentlichen.

Unter Verwendung einer digitalen Identität der Erfindung kann ein Einloggen in andere Computer mit Einrichtungen, wie etwa einem Smartphone, einem Computer usw., wie folgt durchgeführt werden:
Jetzt kann U eine cryptlD auf seiner Einrichtung und ein automatisch erzeugtes und signiertes PDW zum Einloggen in andere Computer, Server oder WEB-Dienste wie folgt verwenden:

1. Die cryptlD [π_U, σ_U(h(π_U))] wird als der Anmeldename verwendet
2. Ein signiertes Passwort PWD wird auf der Einrichtung wie folgt erzeugt:
1. a. Auswählen einer Zufallszahl r aus einem ausreichend großen Nummernbereich
2. b. Signieren von r als σ_U(r)
3. c. Verwenden von [r, σ_U(r)] als das signierte PWD
3. U loggt sich jetzt mit den Paaren [[π_U, σ_U(h(π_U))], [r,σ_U(r)]] ein
4. Dies kann sogar zum Einloggen mit [π_U,[r,σ_U(r)] ] vereinfacht werden

Da r durch U signiert wird, könnte niemand außer U das PWD [r, σ_U (r)] erzeugt haben. Daher hat der Server oder WEB-Dienst einen Beweis, dass dieses PWD von U stammt. Dies vereinfacht den herkömmlichen Anmeldeprozess dramatisch und macht ihn gleichzeitig viel sicherer, da:

1. das Paar [σ_U, π_U] automatisch von der Einrichtung des Client (Smartphone, Tablet oder PC) erzeugt wird
2. U keinen neuen Anmeldenamen erfinden muss
3. U kein Passwort zum Befolgen von Sicherheitsstufen erfinden muss
4. U sich keine Anmeldenamen und Passwörter merken muss
5. U keine Kopie seiner Passwörter an einem sicheren Platz speichern muss, wie häufig für Anmeldungen empfohlen
6. U die Gefahr vermeidet, dass sein Passwort gestohlen wird, da es niemals sichtbar ist, selbst U braucht sein Passwort nicht zu kennen
7. U unterschiedliche cryptlDs für die verschiedenen Anwendungen im Internet verwenden kann und sollte

Da ein signiertes PWD in weniger als einer Millisekunde erzeugt werden kann, kann ein neues PWD für jede Anmeldung verwendet werden. Dies führt zu Passwörtern, die nur einmal verwendet werden und viel sicherer als heutige herkömmliche Anmeldetechniken wären. Um sich gegen den Diebstahl von Passwörtern zu schützen, behält ein Server leicht den Überblick darüber, dass diese Passwörter nicht wieder verwendet werden. Falls ein derartiges Passwort 20 Byte hat und falls sich ein Benutzer 5 Mal am Tag einloggt, würde dies zu 100 B/Tag oder 36 KB/Jahr/Benutzer führen, ein vernachlässigbares Datenvolumen.
In einer anderen Ausführungsform wird die Zufallszahl r durch einen Webdienst erzeugt und an U übertragen. In dieser Ausführungsform braucht der Server keinen Überblick über die verwendeten Passwörter zu behalten.
Viele Benutzer verwenden denselben Anmeldenamen und dasselbe Passwort, um sich in unterschiedliche Computersysteme oder Internetplattformen einzuloggen. Dies ist eine gefährliche Angewohnheit: falls aus irgendeinem Grund die Anmeldedaten verloren oder gestohlen werden, sind auch andere Plattformen gefährdet. Daher ist es ratsam, die cryptlD mit einem anderen PWD zum Einloggen in unterschiedliche Server oder WEB-Dienste zu verwenden. Da cryptlDs und PWDs automatisch auf der Client-Einrichtung erzeugt werden, bemerkt der Benutzer dies nicht einmal.
Mit der herkömmlichen Anmeldetechnik könnte V die E-Mail-Adresse von U verwenden und ein zufälliges PWD für Anmeldungen auswählen, aber das Verwenden einer cryptlD und eines dynamisch erzeugten PWD garantiert, dass das PWD durch U und nicht durch V erzeugt wurde.
Zertifikate
Fremdzertifikate
Ein Fremdzertifikat ist eine Signatur, dass zwei Entitäten A und B zusammengehören. Die Entitäten A und B könnten ein rechtlicher Name oder eine E-Mail-Adresse einer Person und der öffentliche Schlüssel der Person sein. σ_U([A, B]) ist ein Zertifikat, das durch den Benutzer U ausgestellt wird. Durch seine digitale Signatur zertifiziert U öffentlich, dass A und B zusammengehören. Aber ein derartiges Zertifikat ist nichts anderes als eine durch U signierte Behauptung und häufig sind derartige Behauptungen falsch. Fremdzertifikate sind die standardmäßige Verwendung von Zertifikaten.
Selbstzertifikate σ_V ([V, π_v]) Hierdurch zertifiziert V selbst mit seiner eigenen Signatur σ_V, dass V und π_v zusammengehören. Wir verwendeten das Selbstzertifikat σ_U(h(π_U) ) in der cryptlD von U, um zu beweisen, dass π_U der öffentliche Schlüssel ist, der zu σ_U gehört. Dies ist viel mehr als nur eine Behauptung!
Biometrisches digitales Zertifikat zur Authentifizierung
Eine Authentifizierung ist die Zertifizierung, dass bestimmte Behauptungen wahr sind, zum Beispiel, dass ein Bild von Picasso gemalt wurde. Für Kunstwerke wird eine Authentifizierung durch ein Gutachten zertifiziert und Zertifikate werden durch Kunstexperten garantiert. Aber ein solches Gutachten ist nicht absolut sicher, es ist nur eine Behauptung! Für digitale Objekte versichern wir die Authentifizierung durch digitale Signaturen und nennen sie auch Zertifikate.
Im täglichen Leben findet die Authentifizierung von Personen durch das Vorzeigen einer ID-Karte, wie etwa eines Passes, eines Führerscheins oder einfach des Besitzes einer Kreditkarte statt. Eine Authentifizierung wird gewöhnlich durch eine dritte Person durchgeführt, die gewisse biometrische Eigenschaften, wie das Foto in einem Pass oder auf dem Führerschein oder einfach den Besitz einer Kreditkarte oder in strafrechtlichen Ermittlungen den Fingerabdruck oder eine DNA-Sequenz, überprüft.
In dem C-Chain-System verwenden wir die neuartige Idee einer cryptID kombiniert mit einer biometrischen Authentifizierung, um zu zertifizieren, dass eine Person der Eigentümer eines öffentlichen Schlüssels ist. Dafür könnte U in der UDB ein Foto seines Gesichts, wie auf einem Pass, eintragen, aber irgendjemand anderes könnte auch ein derartiges Foto leicht eintragen. Es ist viel sicherer, dass U ein Video aufzeichnet, in dem er das Hash h(π_U) seines öffentlichen Schlüssels vorliest, während h(π_U) gleichzeitig auf dem Bildschirm für einen sofortigen Vergleich gezeigt wird. Diese biometrische Eigenschaft würde extrem schwer zu fälschen sein. Dieses Video wird dann in der UDB zusammen mit π_U und h(π_U) veröffentlicht. Natürlich muss dieses Video durch U signiert werden, um zu verhindern, dass V ein Video macht und denselben h(π_U) verwendet. Es ist anzumerken, dass wir für diesen Beweis weder σ_U kennen müssen (da σ_U immer geheim gehalten werden muss), noch müssen wir irgendetwas über den Eigentümer U wissen. Alles, was wir wissen, ist, dass U den privaten Schlüssel σ_U hat, wer auch immer U als eine Person oder eine andere Entität, wie eine Organisation oder ein Computer, sein könnte.
Auf diese Weise findet irgendjemand anderes - z.B. ein anderer Benutzer V - leicht U und seine Daten in der UDB und kann sich selbst davon überzeugen, dass π_U wirklich zu U gehört, da alles, was V zur Kommunikation mit U braucht, der öffentliche Schlüssel von U ist. Auf diese Weise zertifiziert U selbst, dass π_U sein öffentlicher Schlüssel ist, selbst wenn die Entität U anonym bleibt. V kann jetzt π_U zum Verifizieren von Signaturen von U oder zum Senden von geheimen Nachrichten zu U verwenden.
Zusätzliche Informationen über U
Zusätzlich dazu könnten der Name, die E-Mail-Adresse, die Telefonnummer, die Firmen-URL, die Sozialmedien-URL usw. von U auch in der UDB gespeichert sein, in Abhängigkeit von der persönlichen Entscheidung von U. Natürlich sollten diese digitalen Objekte auch durch U signiert werden.
Benutzer des C-Chain-Systems
Wir unterscheiden zwischen den folgenden unterschiedlichen Arten von Benutzern:
Normale Benutzer, die durch U, V, W bezeichnet werden. Sie werden versuchen, zu betrügen, falls dies zu ihrem Vorteil ist und die Entdeckungsgefahr gering ist, z.B. zum doppelten Ausgeben von Geld oder zum Verbergen der echten Emission von Autos. Aber eine C-Chain wird verhindern, dass sie beim Betrügen erfolgreich sind.
Vertrauenswürdige Benutzer, die durch B, C, D bezeichnet werden. Sie sind ehrlich und versuchen, akzeptierten Geschäftsregeln zu folgen. Sie sind typischerweise ehrlich, da es im besten Interesse ihres Geschäfts ist, einen guten Ruf zu haben und vertrauenswürdig zu sein. Vertrauen ist ihre wichtigste Geschäftsanlage. Falls z.B. ein Pizzadienst die Pizzas nicht genau wie bestellt oder zu spät oder gar nicht liefert, wird ein Kunde nicht wieder bestellen. Falls ein in einem Restaurant reservierter Tisch bei der Ankunft der Gäste nicht verfügbar ist, werden die Gäste dieses Restaurant in Zukunft meiden.
Hacker, die durch H bezeichnet werden: Sie versuchen, das C-Chain-System anzugreifen, um z.B. cryptlDs und private Schlüssel zu stehlen und sie zum Einkaufen oder zum Umleiten von Geld auf ihre eigenen Konten anzugreifen. Aber wir werden sehen, dass Hacker keine Chance haben, ein C-Chain-System anzugreifen.
Transaktionen
Geschäftsprozesse bestehen im einfachsten Fall aus einer Sequenz von mehreren isolierten und abgeschlossenen Transaktionen, z.B. falls U ein Produkt P von einem Verkäufer V kauft und über seine Bank B bezahlt, besteht dieser Geschäftsprozess aus den folgenden Transaktionen:

1. U bestellt P von V
2. V bestätigt den Verkauf
3. V sendet P an U
4. V sendet die Rechnung an U
5. U weist seine Bank B an, zu bezahlen
6. B tätigt die Bezahlung an V

Falls ein Logistikunternehmen, wie UPS oder DLH, bei der Lieferung des Pakets, das P enthält, beteiligt ist, sind noch mehr Transaktionen bei dem vollständigen Geschäftsprozess eingeschlossen.
Alle Transaktionen in einem Geschäftsprozess werden durch eine C-Chain in eine strikte Sequenz von Transaktionen kombiniert und als eine Transaktionskette TC eingetragen.
Format einer Transaktion
Ein Benutzer U formuliert eine Transaktion T, die Daten d enthält, wie folgt:

[d, σ_U (h(d))], das d als offene Daten und die Signatur des Hashs von d enthält, um die Richtigkeit von d sicherzustellen. U ist verantwortlich, dass der Inhalt d korrekt ist und den Regeln des beteiligten Geschäfts folgt.

Nachrichten
Öffentliche Nachrichten
Falls U eine Nachricht M an V senden will, die die Transaktion T enthält, wird diese durch den Absender und den Empfänger erweitert und besitzt nun das folgende Format: $[π_{U}, π_{V}, [d, σ_{U} (h (d))]] = M$
Die beiden öffentlichen Schlüssel am Anfang von M bestimmen den Absender U und den Empfänger V eindeutig. Andere Identifikationsmöglichkeiten bestehen, um den Absender und den Empfänger zu bestimmen, zum Beispiel kann die digitale Identität des Empfängers verwendet werden, falls sie ohne weiteres zur Verfügung steht. Der Absender kann natürlich auch seine digitale Identität für diesen Zweck verwenden. Für praktische Zwecke und für die Effizienz kann die Nachricht zusätzliche Daten enthalten, wie die E-Mail-Adressen von U und V sowie deren Namen als unverschlüsselten Text.
Jeder, der diese Nachricht sieht, kann überprüfen, ob d modifiziert worden ist oder nicht. Diese Eigenschaft wird Unveränderlichkeit genannt.
Geheime Nachrichten
Falls U eine Nachricht M an V senden will, die die Transaktion T enthält, aber den Inhalt der Nachricht verbergen will, besitzt die Nachricht das folgende Format: $[π_{U}, π_{V}, [π_{V} (α), α (d), σ_{U} (h (d))]] = SM$
Anmerkung: Hier verwenden wir einen symmetrischen Schlüssel α zum Verschlüsseln des Inhalts d, da private/öffentliche Schlüssel zum Verschlüsseln von langen Dokumenten nicht sehr effizient sind. Natürlich müssen wir diesen Schlüssel α geheim an V kommunizieren. Zur Lesbarkeit kürzen wir eine derartige Nachricht in diesem Format als SM ab.
Jetzt ist dieser Inhalt d verschlüsselt und nur V kann ihn lesen, aber jeder kann sehen, dass U und V kommunizieren.
Verbergen des Absenders einer Nachricht
Dies wird leicht durchgeführt, indem auch der Absender U im folgenden Format verschlüsselt wird: $[π_{V} (π_{U}), π_{V}, [π_{V} (α), α (d), σ_{U} (h (d))]] = HM$
Wir kürzen eine Nachricht in diesem Format als HM ab.
Jetzt kann nur V den Absender U sehen. Derartige Nachrichten werden benötigt, falls z.B. ein Unternehmen für eine Angebotsanfrage für ein Projekt von V bieten will, da die Informationen, wer die anderen Bieter sind, geheim sein sollten.
Regeln für Transaktionen:
Die meisten Transaktionen müssen gewissen Regeln folgen, aber es ist wichtig, deutlich zwischen Regeln für Transaktionen und Regeln für die Buchführung von Transaktionsketten zu unterscheiden. Für den obigen Verkaufsprozess sind einige offensichtliche Regeln:

1. Die Produktnummer von P muss korrekt sein
2. Die Bestätigung muss die korrekte Produktnummer und den Preis enthalten
3. V muss das korrekte Produkt und nicht irgendetwas anderes senden
4. In der Rechnung müssen der Preis des Produkts und die Kontonummer von V korrekt sein
5. U muss den korrekten Preis bezahlen und die Kontonummer von V korrekt kopieren
6. B muss die Existenz des Bankkontos von V überprüfen und den richtigen Betrag überweisen

Jede Transaktion muss korrekt formuliert und ausgeführt werden. In digitalen Geschäftsprozessen werden viele Transaktionsschritte durch Softwareprogramme durchgeführt oder zumindest durch Softwareprogramme und Datenbanktransaktionen begleitet.
In Prinzip können diese Regeln vom Benutzer, der eine Transaktion formuliert, befolgt und vom Empfänger der Transaktion auf Richtigkeit überprüft werden. Daher werden die Regeln anstelle einer manuellen Formulierung und Überprüfung derartiger Regeln für jede individuelle Transaktion in die Software programmiert. Häufig können derartige Regeln zweckmäßig als Integritätsbeschränkungen in Datenbanken formuliert werden, die dann automatisch durch die DBMS geltend gemacht werden.
Verwaltung von Transaktionsketten
Transaktionsketten TC werden in Datenbanken TDB (Transaktionsdatenbank) gespeichert. Die Hauptaufgabe eines TDBMS (Transaktionsdatenbank-Verwaltungssystem) ist die richtige Buchführung von Transaktionsketten. Unabhängig von den Eigenschaften und der Richtigkeit der individuellen Transaktionen muss die TC insgesamt die folgenden Eigenschaften aufweisen, für die ein oder mehrere redundante TDBMSe verantwortlich sind:

1. Nur Transaktionen, die durch den Verfasser mit seiner digitalen Signatur zertifiziert werden, sind akzeptabel und werden der Transaktionskette hinzugefügt
2. Sobald eine Transaktion in die TC eingetragen worden ist, muss sie unveränderlich sein, d.h. T kann nicht verändert werden, nachdem sie eingetragen worden ist, nicht einmal durch ihren Verfasser
3. TC insgesamt muss strikt sein, d.h. dass eine T, sobald sie eingetragen ist, nicht aus der TC entfernt werden darf und ihre Position in der TC nicht geändert werden darf
4. Neue Transaktionen können nur an das Ende einer Kette angehängt und nicht dazwischen eingefügt werden. Dafür ist das TDBMS verantwortlich. Im Zusammenhang mit Datenbanksystemen wird diese Eigenschaft gewöhnlich Serialisierung genannt, aber in einer C-Chain wird diese klassische Form einer schwachen Serialisierung durch eine unknackbare kryptographische Zertifizierung erzwungen.
5. Eine TC muss dauerhaft sein, d.h. eine TC darf niemals verschwinden und sie muss zu allen Zeiten, optional für die Öffentlichkeit, für geschlossene Gruppen oder nur für die Partner einer Geschäftstransaktion zugänglich sein.
6. Die Eintragung einer Transaktion muss sofort endgültig und für immer abgewickelt werden. Falls eine Transaktion aus irgendeinem Grund fehlerhaft gewesen sein sollte, kann sie nicht aus der TC entfernt werden, sie kann nur durch eine andere Transaktion (wie in einem richtigen Hauptbuch der Buchführung) kompensiert werden, z.B. indem das Geld für ein fehlerhaftes Produkt zurückbezahlt wird. Aber diese Rückzahlung ist eine neue Transaktion und die ursprüngliche Bezahlungstransaktion wird nicht aus der TC entfernt.

Eine Serialisierung wird durch das TDBMS in der C-Chain garantiert, selbst wenn zwei Transaktionen T1 und T2 am TDBMS exakt zur gleichen Zeit eintreffen. In einem derartigen Fall entscheidet der Transaktionsmanager des TDBMS beliebig, T1 und T2 in irgendeiner Reihenfolge einzutragen, z.B. (T1; T2) oder (T2 ; T1). Das Eintragungsergebnis ist nicht deterministisch, aber es muss korrekt sein.
TDBMS-Protokoll
Die obigen Anforderungen der Transaktionsketten werden durch das TDBMS durch das folgende Protokoll garantiert:

1. Die durch das TDBMS empfangene Transaktion T wird zuerst auf eine richtige Zertifizierung überprüft. Daher weist T, die von U verfasst wurde und an V gerichtet ist, die folgende Form in der C-Chain auf: T = [π_U, π_v, d, σ_U(h(d))] Es ist zu beachten, dass T in dieser Form von U zertifiziert wird. In dieser Form ist die gesamte Transaktion öffentlich sichtbar. Die öffentliche Sichtbarkeit wird für gewisse Formen von Transaktionen gewünscht, z.B. für die Standardanwendung von Blockchains oder zum Bieten in öffentlichen Auktionen.
2. Bevor das TDBMS T an das Ende der Kette anhängt, muss das TDBMS überprüfen, dass T zertifiziert ist, d.h. es berechnet unter Verwendung der verschiedenen Komponenten von T:
1. a. v1 = h(d)
2. b. v2 = π_U (σ_U(h(d)))
3. c. Falls v1 = v2, dann ist T von U zertifiziert worden und kann eingetragen werden, ansonsten weist das TDBMS T zurück und informiert optional den Absender π_U, dass T nicht korrekt ist
3. Zertifizierung von T durch das System TDBMS mit seinem eigenen privaten Schlüssel σ_S: Nach der Überprüfung der richtigen Zertifizierung von U signiert das TDBMS jetzt auch T. Dadurch kann T nicht mehr geändert oder ersetzt werden, nicht einmal von U. Ohne die Zertifizierung durch das TDBMS könnte U T entschlüsseln, T modifizieren (z.B. um den Verkaufspreis zu ändern) und T wieder signieren. Die zusätzliche Zertifizierung durch das TDBMS macht dies unmöglich. Das Ändern von T würde nur möglich sein, falls U und das TDBMS ein Komplott bilden und zusammenarbeiten, um T zu ersetzen. Aber das TDBMS wird dies definitionsmäßig nicht tun. Zusätzlich dazu würde der Empfänger V einer Transaktion das Fehlverhalten entdecken.
4. Jetzt hängt das TDBMS T mit der Seriennummer n+1 an das Ende der Kette TC an. Falls die letzte T in der TC T_n ist, dann wird die neue Transaktion an TC wie folgt angehängt:
1. a. Lesen von T_n vom Ende der TC
2. b. Berechnen von h(T_n)
3. c. Eintragen von T_n+1 in der Form [n+1, h(T_n), T] und Signieren von dieser durch σ_S des TDBMS, d.h. Speichern von σ_S [n+1, h(T_n), T] im TDBMS. h(T_n) als Teil von T_n+1 stellt sicher, dass T_n+1 der Kette durch das TDBMS und nicht durch einen Hacker H hinzugefügt wurde. Es ist zu beachten, dass T nicht von U selbst angehängt wird, sondern nur indirekt durch das TDBMS.
5. Die TC - die auch lokal durch U gespeichert wird - wird synchronisiert, so dass U sofort überprüfen kann, dass diese Transaktion richtig eingetragen wurde.
6. Die lokal durch V gespeicherte TC wird durch eine Push-Benachrichtigung des TDBMS oder sobald V seine Client-Einrichtung einschaltet synchronisiert.

Falls das TDBMS eine öffentliche Datenbank ist, dann ist π des TDBMS bekannt oder kann in der UDB nachgeschlagen werden und jeder, insbesondere U und V, kann überprüfen, dass T richtig eingetragen worden ist. Des Weiteren können U und V lokale Kopien der Transaktionsketten, in denen sie als Agenten beteiligt sind, behalten. Somit haben sie einen zusätzlichen unbestreitbaren Beweis, was beim Geschäftsprozess stattfand.
Um sich noch mehr gegen eine Modifikation der TC zu schützen, könnte das Hash einer Komponente von T_n+1 in T_n eingeschlossen werden (was zu einer Vorwärtsverknüpfung der TC führt). Dies würde eine zusätzliche Verstärkung der TC sein, da jetzt das letzte Element T_n+1 der TC nicht durch ein anderes T_n+1 ersetzt werden könnte.
Datensatz im TDBMS:
Die detaillierte Struktur des Datensatzes für T_n+1 in der TC sieht dann wie folgt aus: $[n + 1, h (T_{n}), σ_{S} (T)] = [n + 1, h (T_{n}), σ_{S} ([π_{U}, π_{V}, d, σ_{U} (h (d))])]$
Der Einfachheit halber und um die Darstellung lesbar zu lassen, wurde σ_S (T) verwendet, aber natürlich könnte jede Komponente von T individuell signiert werden.
Geheime Transaktionen (SM) oder Transaktionen mit einem verborgenen Absender (HM) werden analog gebucht.
Erzeugen einer neuen Kette: Natürlich muss ein Benutzer in der Lage sein, eine neue Kette zu erzeugen. Dies könnte unter Verwendung eines speziellen Dokuments d durchgeführt werden, mit einem Inhalt wie: d = „Diese Kette wird Bankkonto von U genannt. Es wurde von U am <DatumZeit> erzeugt“. Dieser Eintrag könnte das folgende spezielle Format besitzen: [0, 0, σ_S ([π_U, π_S, d, σ_U (h(d)))]]
Richtigkeitsbeweis des Protokolls
Wir argumentieren, dass das Protokoll alle Anforderungen für Transaktionsketten in der Reihenfolge, mit der sie oben dargelegt wurden, erfüllt:

1. Eigenschaft 1 (Zertifizierung) wird durch das TDBMS in den Schritten 1 und 2 des Protokolls garantiert, da alle Transaktionen T_k mit k <= n+1 durch den Verfasser und das σ_S des TDBMS signiert werden. Das TDBMS besitzt natürlich sein eigenes Schlüsselpaar [σ_S, π_S ] und signiert alle Anhänge an die TC. T_k könnte nur durch das TDBMS und U zusammen in einem Komplott geändert werden, da nur das TDBMS σ_S kennt. Aber das TDBMS ist definitionsgemäß vertrauenswürdig, das TDBMS wird dies nicht tun. Zusätzlich dazu besitzen zumindest U und V Kopien der TC und würden erkennen, dass das TDBMS plötzlich betrügt, d.h. möglicherweise von H gehackt ist, und sie würden nicht die modifizierte TC akzeptieren. Für weitere Abwehrmaßnahmen gegen das Hacken siehe Punkt 5 und die Abhandlung über Systemarchitektur und das Konzept von öffentlichen Auditoren, die die öffentliche Datenbank TDB, die alle Transaktionsketten enthält, überprüfen können.
2. Die Unveränderlichkeit von T wird durch Schritt 3 erzielt.
3. Die Striktheit der TC wird durch die Schritte 3 und 4 im Protokoll und unter Verwendung der klassischen Datenbanktechniken für die Serialisierung von Transaktionen erzwungen. Das Einschließen von h(T_n) als eine Komponente von T_n+1 setzt die Striktheit von TC zusätzlich durch.
4. Diese Eigenschaft von nur Anhängen wird durch das TDBMS in Schritt 4 erzwungen.
5. Die Dauerhaftigkeit von TC wird durch redundantes Speichern der Datenbank auf mehreren Festplatten, mehreren lokalen Servern oder sogar in mehreren unabhängigen Clouds garantiert, in Abhängigkeit von den Anforderungen der Anwendung. Das Speichern in mehreren Clouds würde sich selbst gegen Hacks oder Terrorangriffe eignen.
6. Die endgültige Abwicklung wird durch Schritt 4c garantiert.

Weitere wesentliche Eigenschaften der C-Chain
Zusätzlich zu der Richtigkeit des Protokolls der C-Chain-Verarbeitung gibt es andere wichtige Eigenschaften:

1. Digitale Identitäten cryptlD [π, σ (h (π))] werden in einer öffentlichen Datenbank UDB gespeichert und können leicht gefunden und verifiziert werden.
2. Um die Sicherheit zu erhöhen, könnte U seine reine cryptlD optional durch ein Authentifizierungsfoto oder -video, seinen Namen, seine E-Mail-Adresse, seine Firma, die URL seiner Sozialmedienpräsenz, seine Telefonnummer usw. erweitern. Natürlich sollten all diese Daten zur zusätzlichen Sicherheit durch U signiert werden.
3. Ein Benutzer V kann dann alle von U veröffentlichten Informationen über ihn selbst finden, indem er die UDB anfragt und sie sofort auf seine eigene Einrichtung herunterlädt. Auf eine derartige Weise muss die cryptlD mit dem öffentlichen Schlüssel und/oder die Authentizität von U von V nur einmal und sehr zweckmäßig überprüft werden.
4. Perfekte Skalierbarkeit
5. Sehr schnelle Verarbeitung
6. Sofortige endgültige Abwicklung
7. Usw., es gibt eine Zusammenfassung des Vergleichs mit Blockchains und der Vorteile der C-Chain gegenüber der Blockchain-Technologie in einer anderen Abhandlung

Sichtbarkeit und Regeln für Transaktionen
Die Regeln für Transaktionen müssen durch verschiedene Agenten formuliert, befolgt und überprüft werden. Jede Transaktionsart besitzt ihre eigenen Regeln. Dafür müssen gewisse Parameter für die beteiligten Agenten verfügbar und sichtbar sein.
Beispiel Bankgeschäft:

• Agenten
- o Eigentümer O eines Kontos
- o Bank B
- o Empfänger R einer Überweisung
• Transaktionsarten
- o Anzeigen
- o Abheben
- o Überweisen
• Parameter
- o KontoNr
- o Betrag
- o Rechnung

Formate für Transaktionen

Anzeigen [π₀, π_B, [π_B (α), α(d), σ_O (h(d))] ] wobei d = [Anzeigen, KontoNr]
Abheben [π₀, π_B, [π_B (α), α(d), σ_O (h(d))] ] wobei d = [Abheben, KontoNr, Betrag] B muss in der Lage sein, zu überprüfen, dass das Konto nicht überzogen ist
Überweisen [π₀, π_B, [[π_B (α), α(d_B), σ_O (h(d_B))], [π_R (β), β(d_R), σ_O (h(d_R)) ]] wobei d_B = [Überweisen, KontoNr_O, KontoNr_R, Betrag] d_R = [Überweisen, Betrag, Rechnung] B muss die Rechnung nicht sehen, R muss die KontoNr von O nicht sehen

Beispiel Ärztliches Rezept:

• Agenten
- o Arzt D
- o Patient P
- o Apotheke A
• Transaktionsarten
- o Verschreiben: D verschreibt für P
- o Vorlegen: P legt Rezept bei A vor
- o Liefern: A liefert Medikamente M und Rechnung zu P
• Parameter
- o Medikamente: M, der pharmazeutische Name eines Medikaments
- o Betrag: A, z.B. die Anzahl und die Stärke von Tabletten
- o Rezeptnummer: PN = [π_D, π_P, SequenzNr] eine eindeutige Rezeptnummer von einem gewissen Arzt für einen gewissen Patienten, um eine mehrfache Ausgabe eines Rezepts bei unterschiedlichen Apotheken zu verhindern

Formate für Transaktionen

Verschreiben [π_D, π_P, [π_P (α), π_A (α), α(d), σ_D (h(d))]] wobei d = [Verschreiben, PN, M, A] hier sind der Patient und die Apotheke in der Lage, die Einzelheiten des Rezepts zu sehen
Vorlegen [π_P, π_A, [π_P (α), π_A (α), α(d), σ_P (h(d))]] wobei d = [Vorlegen, PN, M, A] hier sind der Patient und die Apotheke in der Lage, die Einzelheiten des Rezepts zu sehen
Liefern [π_A, π_P, σ_A(h(d))]] wobei d = [Liefern, PN, Datum] diese Transaktion ist öffentlich und alle Apotheken können sehen, dass das Rezept geliefert worden ist, um eine doppelte Ausgabe zu verhindern

Anwendungen der oben beschriebenen Erfindung „C-Chain“ sind im Folgenden offenbart:
Zusammenfassung
Bei Geschäftsprozessen können mehrere Agenten beteiligt sein, aber bei den einzelnen Transaktionen sind typischerweise zwei Partner aktiv, der Verfasser und der Absender A der Transaktion und der Empfänger B.
Jeder Agent

1. kann vertrauenswürdig sein und sich fair verhalten (+), gewöhnlich da es in seinem Geschäftsinteresse ist, vertrauenswürdig zu sein. In normalen Situationen wird er nicht betrügen. In dieser Kategorie befinden sich Banken, Notare, Einkaufszentren, Restaurants usw. Bei weitem verlassen sich die meisten Geschäftsprozesse auf ein derartiges Vertrauen, aber ihre Geschäftsprozesse können durch eine C-Chain optimiert und sicherer gemacht werden
2. Ein Agent ist möglicherweise nicht vertrauenswürdig und ist nicht notwendigerweise fair (-) und könnte betrügen, falls dies zu seinem Vorteil ist. Dies passiert typischerweise, falls A oder B nur einmal ein Geschäft durchführen, z.B. beim Verkauf eines Artikels auf dem Flohmarkt, beim Verkauf eines Kunstwerks, beim Bezahlen mit Falschgeld, beim mehrmaligen Transferieren einer Anlage, aber nur einmaligem oder keinmaligem Liefern, beim Verkauf eines minderwertigen oder kaputten gebrauchten Produkts auf Ebay, beim inkorrekten Angeben der Qualität des verkauften Artikels usw.

Wir betrachten alle vier Kombinationen und geben typische Situationsbeispiele.

Fall 1: A- und B-
1. 1. Anonymes Handeln mit Drogen oder Waffen im Darknet,
2. 2. Verkaufen auf einem Flohmarkt
3. 3. A verkauft ein gebrauchtes Auto mit manipuliertem Meilenstand und B bezahlt mit Falschgeld
Fall 2: A- und B+ schlechte Produkt- oder Dienstqualität, fehlende Lieferung oder Verweigerung eines Dienstes
- 1. Verkaufen eines Hauses, ohne das Eigentumsrecht zu haben, oder mit unsichtbaren Schäden, wie ein undichtes Dach
- 2. Verkaufen eines gebrauchten Autos mit manipuliertem Meilenstand
- 3. Versuchen, einen Artikel mehrere Male zu verkaufen (doppelte Ausgabe)
- 4. Verweigerung zum Liefern eines verkauften Artikels, z.B. jemand verkauft einen antiken Stuhl, empfängt aber ein viel besseres Angebot kurz danach, und falls der erste Käufer den Artikel abholen will, bestreitet der Verkäufer, den Verkauf getätigt zu haben
- 5. Eine Taxifirma sendet das Taxi nicht, da es für eine längere und lukrativere Fahrt gebraucht wurde, der Kunde wartet vergeblich
- 6. Ein Pizzaladen liefert die falsche Pizza
Fall 3: A+ und B- dies passiert öfters, aber häufig unabsichtlich
- 1. Ein Kunde wartet nicht auf ein bestelltes Taxi
- 2. Ein Kunde reserviert einen Tisch in einem Restaurant, erscheint aber nicht
- 3. Ein Kunde bestellt telefonisch Heizöl, das in zwei Wochen geliefert werden soll. In der Zwischenzeit fällt der Preis und der Kunde bestreitet, das Öl bestellt zu haben, wenn es eintrifft, und weigert sich, es anzunehmen. Der Händler hat keinen Beweis der Bestellung, es sei denn, dass er den Anruf aufgezeichnet hat, was illegal ist.
- 4. B nimmt einen Kredit auf, gibt das Geld aus und geht bankrott.
Gegen alle Beispiele von Fall 3 hat A gewisse Strategien entwickelt, um einen Schaden so weit wie möglich zu vermeiden:
- • In unerheblichen Fällen nimmt A das Risiko des verlorenen Geschäfts auf sich oder besteht auf eine Vorbezahlung, wie für teure Opernkarten
- • In einigen Fällen, wie für reservierte Kinokarten, versucht der Verkäufer, einen Teil des verlorenen Geschäfts zurückzugewinnen, indem er die Karte verkauft, falls sie nicht 30 Minuten vor der Vorführung abgeholt wird
- • In erheblichen Fällen bestehen der Verkäufer oder eine Bank, die einen Kredit ausgibt, auf eine Sicherheit, wie das Eigentumsrecht auf ein Haus, als Schutz gegen einen Kreditausfall, oder verwenden Hinterlegungstransaktionen
Fall 4: A+ und B+

Dies ist wahrscheinlich die häufigste Transaktion mit der Ausnahme von Bezahlungen. Viele Leute würden ihr Geld mehrere Male ausgeben wollen, falls sie dies leicht tun könnten, ohne erwischt zu werden.
Beispiele für Anwendungen der C-Chain
Anmeldung bei Computern und WEB-Diensten

1. Das Verwenden von cryptIDs zur Anmeldung und für ein PWD (beide werden auf dem Client automatisch erzeugt und gespeichert) ist viel zweckmäßiger und viel sicherer als das herkömmliche Verfahren mit Anmeldungsname und Passwort
2. Verwaltung von digitalen Identitäten cryptlD und öffentlichen Schlüsseln auf einer öffentlichen Datenbank UDB
3. Das herkömmliche Verfahren des Erhaltens von MIME-Zertifikaten oder über die PKI-Infrastruktur ist viel komplizierter und langwieriger als über die Datenbank UDB und die biometrische Authentifizierung.

Finanzielle Dienste

1. Zweckmäßiger und sicherer (keine Fälschungen) Ersatz für Barbezahlungen ohne ein Wechselgeldproblem.
2. Vereinfachtes elektronisches Bankgeschäft: eine Banküberweisung über eine C-Chain wird durch die kryptographische Signatur erheblich vereinfacht. Insbesondere erfordert sie keine Infrastruktur außer einem Smartphone. Im Gegensatz dazu erfordert das herkömmliche elektronische Bankgeschäft eine komplexe und teure Infrastruktur:
1. a. Einen Computer mit einem Browser
2. b. Eine schnelle Internetverbindung
3. c. Eine herkömmliche Anmeldung
4. d. Eine Bankkarte
5. e. Einen CHIP-TAN-Generator
3. Ersatz für EC-Kartenbezahlungen: eine durch eine C-Chain autorisierte Geldüberweisung ist viel einfacher als das derzeitige Verfahren mit EC-Karte, Kartenlesegerät, PIN oder manueller Signatur und der Folgeverarbeitung des Abbuchungsauftrags
4. Vereinfachte Abbuchungsaufträge: herkömmliche Abbuchungsaufträge sind komplex. Mit einer C-Chain kann ein Abbuchungsauftrag mit einer digitalen Signatur unmittelbar zum Zahlungsempfänger gesendet werden. Dieses Verfahren kann durch eine C-Chain verwendet werden, um Geld zu einer anderen Person zu senden, selbst wenn die Bank keine C-Chain unterstützt.
5. Überweisen von Bargeld: Das einfache Bargeldüberweisungs-System KWITT, das durch deutsche Banken verbreitet wird, erfordert die Interaktion von zwei Agenten: den Zahlenden und den Zahlungsempfänger, der auf eine SMS antworten, einen Browser auf seinem Smartphone öffnen, seinen Namen eingeben und seine lange fehleranfällige IBAN von seiner EC-Karte abschreiben muss. Mit der C-Chain ist dies viel einfacher.
6. Überweisen von Geld ins Ausland: Heute ist dies extrem langwierig, kompliziert und teuer, z.B. für Flüchtlinge aus Nahost oder Afrika. Mit der C-Chain wird dies viel leichter, billiger und schneller und kann selbst durch Privatleute mit erheblich reduzierter Interaktion mit Banken durchgeführt werden.
7. Bezahlungen in Einkaufszentren, Supermärkten, Restaurants, Tankstellen usw.: Einfach einen QR-Code lesen und die Bezahlungstaste drücken.

Ersatz von allen Chipkarten
Im Prinzip eignet sich die C-Chain als ein sehr zweckmäßiger, sicherer und gleichzeit billiger Ersatz für alle Chipkarten.

1. EC-Karte, siehe obige Einzelheiten
2. Mitgliedschaftskarten für Clubs, z.B. ADAC, PayBack-Karte von Kaufhof Galerie, Premium-Mitgliedskarten von Fluggesellschaften usw. In diesem Fall signiert der Club digital ein Dokument mit seinem eigenen Logo usw., das auf dem Smartphone des Mitglieds angezeigt und von diesem vorgezeigt wird. Jeder kann die Signatur des Clubs überprüfen und dadurch die Mitgliedschaft verifizieren. Keine Infrastruktur für Kartenlesegeräte wird benötigt, zusätzlich dazu eröffnet dies einen Kommunikationskanal zwischen dem Club und den Mitgliedern mit einer sehr verbesserten Kundenbeziehung.
3. Krankenversicherungskarten zum Beweisen der Versicherungsabdeckung

Ersatz von physischen Schlüsseln mit RFID-Chips
Hochgesicherte und vertrauliche medizinische und legale Informationen

1. Patientenverfügungen: Dies sind extrem sensibel und vertrauliche Informationen. Daher werden Patientenverfügungen häufig bei öffentlichen Notaren hinterlegt. Aber medizinische Ärzte brauchen schnelle und zuverlässige Informationen über Patientenverfügungen. Falls ein Unfallopfer stirbt, müssen medizinische Entscheidungen über Organtransplantationen absolut vertraulich sein und müssen in extrem kurzer Zeit vorgenommen werden. Aber um diese Informationen einem medizinischen Arzt offenzulegen, muss ein Arzt sich selbst mit seiner eHBA (elektronischer Heilberufe Ausweis), einer Chipkarte, die alle Ärzte haben sollten, authentifizieren. Aber diese Karte ist sehr teuer und von mehr als 300.000 Ärzten in Deutschland haben zur Zeit nur etwa 6.000 die Karte. Ein eHBA basierend auf der C-Chain würde viele Vorteile besitzen, wie: Geschwindigkeit, Sicherheit, Benutzerfreundlichkeit.
2. Patientenakte: Deutschland hat für viele Jahre und mit hohen Staatskosten (bisher 1,7 Milliarden €) vergeblich versucht, ein derartiges System aufzubauen. Eine Patientenakte basierend auf der C-Chain würde für die Öffentlichkeit viel akzeptabler und viel billiger sein und sie würde viele zusätzliche Vorteile besitzen, z.B. könnten Eltern die Gesundheitsakte ihrer Kinder auf ihren Smartphones haben und sie selektiv zu einem Arzt, den Notfalldiensten oder einem Krankenhaus senden. Selbst wenn die Eltern bei der Arbeit sind und nicht mit ihren Kindern anwesend sein können, könnten sie diese Informationen von ihren Smartphones senden. Dies würde auch die Versicherungskarte für ihre Kinder beinhalten.

Versorgungskettenverwaltung
Versorgungsketten sind häufig lang, transnational, müssen aber schnell und hochgesichert und zuverlässig verwaltet werden. Versorgungsketten werden häufig als ein Paradebeispiel einer Blockchain-Technologie verwendet, aber die C-Chain ist eine viel bessere Alternative. Falls irgendetwas schiefläuft, können die Kosten extrem hoch sein (unterbrochene Produktionslinien) und die Frage stellt sich, wer für den Schaden verantwortlich ist. Derartige Prozesse können optimiert und viel sicherer gemacht werden, falls alle Transaktionsschritte in der Kette kryptographisch gesichert werden und verfolgt werden können, indem die Kette für alle Partner sichtbar und überprüfbar gemacht wird. Da Signaturen nicht abgestritten werden können, werden sie sofort identifiziert.
Carsharing
Dies gewinnt sehr schnell an Bedeutung, aber es ist immer noch recht unpraktisch: Chipkarten werden benötigt und Safes, die den Autoschlüssel enthalten, müssen mit einem speziellen Code geöffnet werden. Der folgende C-Chain-Prozess würde das Carsharing und die Autovermietung vereinfachen:
Hier ist die Transaktionskette zum Mieten eines Autos:
Beispiel eines Autovermietungsprozesses mit 3 Agenten: Benutzer U, Autovermietungsagentur V und Auto A
Die Transaktionskette: Der Inhalt der Transaktion ist in Kursivschrift gezeigt.

1. U → V U gibt V das Recht, bis zu 300 € vom Bankkonto von U abzuziehen oder V € per Banküberweisung zu überweisen
2. U → V Ich brauche ein Mietauto+Einzelheiten (mein Alter, Führerscheinnr., falls erforderlich)
3. V -7 U hier sind mehrere Angebote, wählen Sie ihre Präferenz aus
4. U -7 V Ich buche das folgende Angebot ...
5. V -7 A Motor entsperren
6. A -7 V Motor wurde gestartet, A kann Einzelheiten an V übertragen
7. U -7 V Ich brachte A zu Standort X zurück
8. V -7 A Motor sperren und den gegenwärtigen Standort übertragen

Reservierungen und Verkauf von Tickets/Karten
für öffentlichen und privaten Transport, Theater, Konzerte usw.
Hotelreservierungen und -bezahlungen
Supermarktbezahlungen und Einkaufszentren
Wenn für Lebensmittel in einem Supermarkt bezahlt wird, versuchen viele Leute, den korrekten Geldbetrag in ihren Portemonnaies zu finden, um diese leichter zu machen. Dies verschwendet viel Zeit für den Kassierer an der Registrierkasse. Dieser Bezahlungsprozess könnte durch eine C-Chain-Lösung beschleunigt werden. Zusätzlich zum Ersparen von Kosten würde dies den Pfad für eine intensivere Kundenbetreuung eröffnen.
Firmenkantinen und Angestelltenkarten
Viele Firmen haben Angestelltenkarten, die für den Zugang zu ihrem Firmengelände, zu eingeschränkten Bereichen, zum Bezahlen in der Kantine und für zusätzliche Dienste verwendet werden. Diese Karten könnten durch eine C-Chain-Lösung ersetzt werden.
Zertifizierte E-Mails
Versicherungen
Mikroversicherungen sind ein großer Markt, besonders in Drittweltländern. Aber Verkaufs- und Schadensbestimmungen durch Versicherungsagenten sind bei weitem zu teuer. Mit der C-Chain-Technologie könnte dieser Markt eröffnet werden.
Elektronische Rezepte
In Deutschland alleine werden jährlich etwa 700 Millionen Rezepte mit veralteten manuellen Geschäftsprozessen auf Papier bearbeitet, die Ärzte, Patienten, Apotheken und Versicherungen einbeziehen. Dieser Prozess könnte durch die C-Chain-Technologie stark automatisiert werden.
Beispiel eines Bankkontos
Beispiel Bankgeschäft:

• Agenten
- o Eigentümer O eines Kontos
- o Bank B
- o Empfänger R einer Überweisung
• Transaktionsarten
- o Anzeigen
- o Abheben
- o Überweisen dies ist die Anordnung des Kontoeigentümers an seine Bank, das Geld zu überweisen
- o Einzahlen dies ist die Transaktion der Bank, das Geld in das Konto von R einzuzahlen
• Parameter
- o KontoNr
- o Betrag
- o Rechnung
• Ketten
- o Jeder Benutzer hat eine Kette für sein Konto, die einem herkömmlichen Bankkonto entspricht, KontoKette AC_O von O und KontoKette AC_R von R

Formate für Transaktionen

Anzeigen [π₀, π_B, [π_B (α), α(d), σ_O (h(d))] ] wobei d = [Anzeigen, KontoNr]
Abheben [π₀, π_B, [π_B (α), α(d), σ_O (h(d))] ] wobei d = [Abheben, KontoNr, Betrag] B muss in der Lage sein, zu überprüfen, dass das Konto nicht überzogen ist
Überweisen [π₀, π_B, [[π_B (α), α(d_B), σ_O (h(d_B)) ], [π_R (β), β(d_R), σ_O (h(d_R)) ]] wobei d_B = [Überweisen, KontoNr_O, KontoNr_R, Betrag] d_R = [Überweisen, Betrag, Rechnung] B muss die Rechnung nicht sehen, R muss die KontoNr von O nicht sehen

Die Transaktionskette:

1. O → B Zeige meinen Kontostand an a. Der Kontostand könnte immer als Teil der letzten Transaktion, die als das Ende der Kette eingetragen wird, angezeigt werden. Dann könnte O auch den Kontostand in der Kopie seiner eigenen Transaktionskette sehen, die lokal in dieser Einrichtung gespeichert ist.
2. O → B Überweise 17 € von meinem Konto an R a. Jetzt hat B die Signatur von O zum Ausführen dieser Überweisung. Es ist anzumerken, dass diese Transaktion in der KontoKette von O eingetragen wird.
3. B → O Einzahlen ok, ich werde 17 € auf das Konto von R einzahlen a. Diese Transaktion wird in der Kette von O eingetragen. Jetzt hat O die Signatur von B, dass B die 17 € bei R einzahlt.
4. B → R dies ist eine Einzahlung von 17 € in Ihrem Konto a. Diese Transaktion wird in der Kette von R gebucht. Jetzt hat R die Signatur von B, dass 17 € auf sein Konto eingezahlt wurden.

In diesem Beispiel zeigt und beweist der Buchungsprozess, dass B wirklich die Anordnung von O ausführt. Ob dies möglich ist oder nicht, hängt von der spezifischen Anwendung ab. Falls physische Güter in der Anwendung transferiert werden, wie in einer Versorgungskette oder durch die Lieferung eines Produkts durch eine Versandhandelsfirma als ein Paket, dann gibt der Kurierdienst das Paket nur aus, falls der Empfänger R eine Transaktion macht, was die klassische handgeschriebene Signatur auf einer Quittung ist.
Einzelheiten einer Transaktion Überweisen im obigen Beispiel 2
Handlungen von O

1. O öffnet das Client-Programm für die C-Chain, z.B. die App mit dem Namen Chain auf seinem Smartphone oder ein Programm Chain auf seinem PC.
2. Infolgedessen zeigt Chain eine Liste von allen Transaktionsketten an, zu denen O als ein Agent zugelassen wird, insbesondere die Kontokette AC_O von O, aber auch andere.
3. O wählt AC_O aus dieser Liste durch ein Klicken aus
4. Jetzt zeigt die App eine Liste von allen Transaktionsarten, die O mit seiner Transaktionskette durchführen darf, z.B. Anzeigen, Abheben, Überweisen, Einzahlen
5. Aus dieser Liste wählt O aus, was er machen will, in diesem Fall Überweisen
6. Jetzt stellt Chain ein spezifisches Formular für die Transaktionsart Überweisen dar.
7. Dieses Formular besitzt mehrere Felder, die ausgefüllt werden müssen, z.B.
1. a. Eine Liste mehrerer cryptID, die Chain schon bekannt und in dieser gespeichert sind. Wir nehmen an, dass sich die cryptID von R in dieser Liste befindet, da R ein Supermarkt mit cryptIDs sein könnte, in dem U regelmäßig Lebensmittel kauft. Wie U diese cryptID bekommt, ist im Folgenden beschrieben, da U dies nur einmal machen muss.
2. b. Ein Feld für das Transaktionsdokument d. Dies könnte ein Teilformular mit mehreren Feldern sein. Dieses Formular würde dem Formular ähneln, das heutzutage beim elektronischen Bankgeschäft verwendet wird. Aber der Einfachheit halber nehmen wir an, dass dieses Feld einfach ein Textfeld ist.
8. O füllt jetzt dieses Formular aus:
1. a. O wählt eine cryptID für den Empfänger dieser Transaktion einfach durch ein Klicken aus, hier die cryptID_B der Bank B
2. b. O füllt d z.B. mit dem folgenden Text aus: Bitte überweisen Sie 17 € auf das Konto mit der IBAN-Nummer DE73 ... mit cryptID_R Falls d ein Teilformular ist, werden manche dieser Felder schon ausgefüllt sein, wie heutzutage beim elektronischen Bankgeschäft.
9. O klickt die Taste Senden. Vor dem Senden führt Chain alle erforderlichen Signaturen usw. durch und erstellt das Transaktionsdokument, wie zuvor beschrieben. All dies passiert automatisch und der Benutzer O sieht nichts davon.

Diese Transaktion T wird zu dem eintragenden Datenbanksystem TDBMS über einen beliebigen Kommunikationskanal wie https oder E-Mail usw. gesendet. TDBMS trägt jetzt diese Transaktion in der Transaktionskette AC_O ein. Die Bank B wird durch eine Push-Nachricht oder Synchronisation benachrichtigt, dass eine neue Transaktion für B eingetroffen ist.
B führt jetzt die folgenden Handlungen durch

1. B analysiert den Inhalt d der empfangenen Transaktion T, überprüft die richtigen Signaturen und extrahiert daraus 17 €, IBAN-Nummer, cryptID_R
2. B formuliert eine neue Transaktion T2 zur Bestätigung von O, dass B die Überweisung des Geldes an R ausführen wird. T hat nun die Zusage von B.
3. B bewegt das Geld vom Konto von O auf das Konto von R und formuliert eine Transaktion T3, die R informiert, dass das Geld auf das Konto von R eingezahlt worden ist. R sieht dies unmittelbar und hat nun einen Beweis, dass B das Geld von O auf das Konto von R überwiesen hat.

Erhalten der cryptID eines anderen Benutzers R
Es gibt mehrere Alternativen

1. Die cryptIDs könnte als ein QR-Code an der Registrierkasse des Supermarkts angezeigt werden und wird durch Chain einmal fotografiert und lokal in Chain gespeichert.
2. Die cryptID_R kann immer in der UDB gefunden werden. Zu diesem Zweck bietet Chain eine praktische Such- und Verifizierungsunterstützung.
3. Es ist anzumerken, dass dies nur einmal für einen Agenten R durchgeführt wird, mit dem U interagieren will.

Individuelle Aspekte der Erfindung betreffen die folgende Liste von nummerierten Aspekten:

1. Verfahren zum Erzeugen einer digitalen Identität (cryptID) eines Benutzers (U) zur Benutzerauthentifizierung bei elektronischen Transaktionen, wobei der Benutzer (U) ein kryptographisches Schlüsselpaar (σ_U,π_U) besitzt, das einen öffentlichen Schlüssel (π_U) und einen privaten Schlüssel (σ_U) umfasst, wobei das Verfahren die folgenden Schritte umfasst:
- - Berechnen einer Hash-Funktion des öffentlichen Schlüssels (π_U), wodurch ein Hash-Wert (h(π_U)) des öffentlichen Schlüssels erzeugt wird;
- - digitales Signieren des Hash-Werts (h(π_U)) des öffentlichen Schlüssels mit dem privaten Schlüssel (σ_U), wodurch ein signierter Hash-Wert (σ_U(h(π_U)) erzeugt wird;
- - Erstellen der digitalen Benutzeridentität (cryptID) als das Paar, das aus dem öffentlichen Schlüssel (π_U) und dem signierten Hash-Wert (σ_U(h(π_U)) besteht.
2. Verfahren gemäß Aspekt 1, mit dem zusätzlichen Schritt des gemeinsamen Nutzens der digitalen Benutzeridentität (cryptID) durch elektronisches Senden der digitalen Benutzeridentität (cryptID) an einen anderen Benutzer (V) und/oder Hochladen der digitalen Benutzeridentität (cryptID) in eine öffentlich zugängliche Datenbank (UDB).
3. Verfahren gemäß Aspekt 1 oder 2, bei dem die digitale Benutzeridentität (cryptID) mit einer biometrischen Eigenschaft des Benutzers (U) kombiniert wird.
4. Verfahren gemäß Aspekt 3, bei dem die biometrische Eigenschaft des Benutzers (U) eine Videoaufzeichnung des Benutzers (U) ist, der den Inhalt des Hash-Werts (h(π_U)) des öffentlichen Schlüssels vorliest.
5. Verfahren gemäß Aspekt 4, bei dem der Inhalt des Hash-Werts (h(π_U)) des öffentlichen Schlüssels gleichzeitig angezeigt wird.
6. Verfahren gemäß Aspekt 4 oder 5, bei dem die Videoaufzeichnung mit dem privaten Schlüssel (σ_U) signiert wird.
7. Digitale Identität (cryptID) eines Benutzers (U) zur Benutzerauthentifizierung bei elektronischen Transaktionen, wobei der Benutzer (U) ein kryptographisches Schlüsselpaar (σ_U,π_U) besitzt, das einen öffentlichen Schlüssel (π_U) und einen privaten Schlüssel (σ_U) umfasst, wobei die digitale Identität (cryptID) aus dem öffentlichen Schlüssel (π_U) des Benutzers (U) und einem Hash-Wert (h(π_U)) des öffentlichen Schlüssels besteht, der mit dem privaten Schlüssel (σ_U) des Benutzers (U) digital signiert wird (σ_U(h(π_U)).
8. Digitale Identität (cryptID) gemäß Aspekt 7, die mit einer biometrischen Eigenschaft des Benutzers (U) kombiniert ist.
9. Digitale Identität (cryptID) gemäß Aspekt 8, bei der die biometrische Eigenschaft des Benutzers (U) eine Videoaufzeichnung des Benutzers (U) ist, der den Inhalt des Hash-Werts (h(π_U)) des öffentlichen Schlüssels vorliest.
10. Digitale Identität (cryptID) gemäß Aspekt 9, wobei der Inhalt des Hash-Werts (h(π_U)) des öffentlichen Schlüssels gleichzeitig angezeigt wird.
11. Digitale Identität (cryptID) gemäß Aspekt 9 oder 10, wobei die Videoaufzeichnung mit dem privaten Schlüssel (σ_U) signiert ist.
12. Verfahren zum Einloggen in eine passwortgeschützte Computeranwendung, die eine digitale Identität (cryptID) gemäß Aspekt 7 als einen Anmeldenamen und ein durch die folgenden Schritte erzeugtes signiertes Passwort verwendet:
- - Wählen einer Zufallszahl (r);
- - digitales Signieren der Zufallszahl, wodurch eine signierte Zufallszahl (σ_U(r)) erzeugt wird;
- - Erstellen des signierten Passworts als das Paar ([r, (σ_U(r)], das aus der Zufallszahl und der signierten Zufallszahl besteht.
13. Verfahren zum Erzeugen eines elektronischen Transaktionsdokuments (T) zwischen einem Benutzer (U) und einem Empfänger (V), wobei sowohl der Benutzer (U) als auch der Empfänger (V) jeweils ein kryptographisches Schlüsselpaar besitzen, das einen öffentlichen Schlüssel (π_U; π_V) und einen privaten Schlüssel (σ_U; σ_V) umfasst, wobei das Verfahren die folgenden Schritte umfasst:
- - Bereitstellen eines Transaktionsinhalts (d) vom Benutzer (U) zum Empfänger (V);
- - Berechnen einer Hash-Funktion des Transaktionsinhalts (d), wodurch ein Transaktionsinhalt-Hash-Wert (h(d)) erzeugt wird;
- - Signieren des Transaktionsinhalt-Hash-Werts (h(d)) mit dem privaten Schlüssel (σ_U) des Benutzers (U);
- - Erstellen des Transaktionsdokuments (T) als das Paar, das aus dem Transaktionsinhalt (d) und dem signierten Transaktionsinhalt-Hash-Wert (σ_U(h(d)) besteht.
14. Verfahren gemäß Aspekt 13, bei dem das Transaktionsdokument (T) des weiteren den öffentlichen Schlüssel (π_U) des Benutzers (U) und den öffentlichen Schlüssel (π_V) des Empfängers (V) umfasst.
15. Verfahren gemäß Aspekt 13 oder 14, bei dem der Transaktionsinhalt (d) im Transaktionsdokument (T) unter Verwendung eines symmetrischen Verschlüsselungsschlüssels verschlüsselt wird.
16. Verfahren gemäß Aspekt 15, bei dem das Transaktionsdokument (T) ferner den symmetrischen Verschlüsselungsschlüssel umfasst, der mittels des öffentlichen Schlüssels (π_V) des Empfängers (V) verschlüsselt wird.
17. Verfahren gemäß einem der Aspekte 14 bis 16, bei dem der öffentliche Schlüssel des Benutzers (U) mittels des öffentlichen Schlüssels (π_V) des Empfängers (V) verschlüsselt wird.
18. Elektronisches Transaktionsdokument (T) zwischen einem Benutzer (U) und einem Empfänger (V), wobei sowohl der Benutzer (U) als auch der Empfänger (V) jeweils ein kryptographisches Schlüsselpaar besitzen, das einen öffentlichen Schlüssel (π_U; π_V) und einen privaten Schlüssel (σ_U; σ_V) umfasst, wobei das elektronische Transaktionsdokument (T) aus einem Transaktionsinhalt (d) von dem Benutzer (U) zu dem Empfänger (V) und einem Transaktionsinhalt-Hash-Wert (h(d)), der mit dem privaten Schlüssel (σ_U) des Benutzers (U) signiert ist, besteht.
19. Elektronisches Transaktionsdokument (T) gemäß Aspekt 18, wobei das Transaktionsdokument (T) des weiteren den öffentlichen Schlüssel (π_U) des Benutzers (U) und den öffentlichen Schlüssel (π_V) des Empfängers (V) umfasst.
20. Elektronisches Transaktionsdokument (T) gemäß Aspekt 18 oder 19, wobei der Transaktionsinhalt (d) im Transaktionsdokument (T) unter Verwendung eines symmetrischen Verschlüsselungsschlüssels verschlüsselt ist.
21. Elektronisches Transaktionsdokument (T) gemäß Aspekt 20, wobei das Transaktionsdokument (T) ferner den symmetrischen Verschlüsselungsschlüssel umfasst, der mittels des öffentlichen Schlüssels (π_V) des Empfängers (V) verschlüsselt ist.
22. Elektronisches Transaktionsdokument (T) gemäß einem der Aspekte 19 bis 21, wobei der öffentliche Schlüssel (π_U) des Benutzers (U) mittels des öffentlichen Schlüssels (π_V) des Empfängers (V) verschlüsselt ist.
23. Verfahren zum Verwalten eines elektronischen Transaktionsdokuments (T) gemäß einem der Aspekte 18 bis 22 in einer Transaktionskette (TC) in einer Datenbank (TDB), wobei das Verfahren die folgenden Schritte umfasst:
- - Empfangen eines zu archivierenden elektronischen Transaktionsdokuments (T);
- - Überprüfen einer Zertifizierung des elektronischen Transaktionsdokuments (T);
- - Zertifizieren des elektronischen Transaktionsdokuments (T) mit einem Datenbankschlüssel (σ_S);
- - Anhängen des elektronischen Transaktionsdokuments (T) an die Transaktionskette (TC).
24. Verfahren gemäß Aspekt 23, wobei der Schritt des Anhängens folgendes umfasst:
- - Lesen des vorherigen zuletzt eingegebenen elektronischen Transaktionsdokuments (T), das in der Transaktionskette (TC) enthalten ist, und Berechnen von dessen Hash-Wert,
- - Identifizieren der Position (n) der zuletzt eingegebenen elektronischen Transaktion (T_n) und Inkrementieren von dieser um Eins;
- - Erzeugen eines Tripels der inkrementieren Position (n+1), des Hash-Werts der vorherigen zuletzt eingegeben elektronischen Transaktion (T_n) und des elektronischen Transaktionsdokuments (T);
- - Signieren des Tripels mit dem Datenbankschlüssel (σ_S);
- - Speichern des signierten Tripels als neue letzte elektronische Transaktion (T_n+1).
25. Datenbanksystem (TDBMS), das ein Verfahren gemäß Aspekt 23 oder 24 implementiert.
26. Verfahren zum Ausführen einer elektronischen Transaktion unter Verwendung einer digitalen Identität (cryptID) gemäß einem der Aspekte 7 bis 11 und unter Verwendung einer Transaktionskette (TC) in einem Datenbanksystem gemäß Aspekt 25 unter der Kontrolle eines Benutzers oder Client-Systems, mit den folgenden Schritten:
- - Anzeigen von mindestens einer Transaktionskette (TC, AC₀) für einen Benutzer (U, O), zu deren Verwendung der Benutzer (U, O) autorisiert ist;
- - Empfangen einer vom Benutzer (U, O) eingegebenen ersten Auswahl, welche Transaktionskette (TC, AC₀) verwendet werden soll;
- - Anzeigen einer Liste von möglichen oder vorausgewählten Transaktionsarten für den Benutzer;
- - Empfangen einer vom Benutzer (U, O) eingegebenen zweiten Auswahl, welche Transaktionsart verwendet werden soll;
- - Anzeigen eines für die Transaktionsart spezifischen elektronischen Formulars für den Benutzer;
- - Empfangen des ausgefüllten Formulars vom Benutzer, das mindestens einen öffentlichen Schlüssel oder eine digitale Identität (cryptID_B) eines Empfängers (V, R, B) und einen Transaktionsinhalt (d) enthält;
- - Erzeugen eines elektronischen Transaktionsdokuments (T) gemäß einem der Aspekte 18 bis 22 basierend auf dem ausgefüllten Formular;
- - Senden des elektronischen Transaktionsdokuments zum Datenbanksystem.
27. Verfahren zum Betreiben einer Datenbank zum Verwalten einer elektronischen Transaktion unter der Steuerung eines Datenbanksystems, mit den folgenden Schritten:
- - Empfangen eines elektronischen Transaktionsdokuments, das gemäß Aspekt 26 erzeugt und gesendet wird;
- - Anhängen des elektronischen Transaktionsdokuments gemäß Aspekt 24 an eine Transaktionskette, die im elektronischen Transaktionsdokument spezifiziert wird;
- - Weiterleiten des elektronischen Transaktionsdokuments zum Empfänger (V, R, B).
28. Verfahren zum Verarbeiten einer elektronischen Transaktion unter Verwendung einer digitalen Identität (cryptID) gemäß einem der Aspekte 7 bis 11 und unter Verwendung einer Transaktionskette (TC) in einem Datenbanksystem gemäß Aspekt 25 unter der Steuerung eines Empfängersystems, mit den folgenden Schritten:
- - Empfangen, vom Datenbanksystem, eines zertifizierten elektronischen Transaktionsdokuments, das schon an eine Transaktionskette gemäß Aspekt 24 angehängt wurde;
- - Bestätigen des Transaktionsinhalts (d), der im Transaktionsdokument enthalten ist, durch Erstellen eines neuen Transaktionsdokuments (T2) gemäß einem der Aspekte 18 bis 22;
- - Senden des neuen Transaktionsdokuments (T2) zum Datenbanksystem zum Anhängen an die Transaktionskette;
- - Verarbeiten des Transaktionsinhalts (d), der im Transaktionsdokument enthalten ist.
29. Computersystem, das ein Verfahren gemäß einem der Aspekte 26 bis 28 implementiert, wobei das Computersystem ein Host-Computer, ein Serversystem, eine tragbare Datenverarbeitungseinrichtung, eine Informations- und Kommunikationseinrichtung, ein Datenbanksystem oder dergleichen ist.
30. Computerprogrammprodukt mit einem computerlesbaren Medium und einem auf dem computerlesbaren Medium gespeicherten Computerprogramm mit Programmcodemitteln, die zum Ausführen eines Verfahrens gemäß einem der Aspekte 1 bis 6, 12 bis 17, 23 bis 24 oder 26 bis 28 geeignet sind, wenn das Computerprogramm auf einem Computer, einem Smartphone, einem Datenbanksystem oder einer beliebigen anderen geeigneten Datenverarbeitungseinrichtung oder dem Computersystem gemäß Aspekt 29 ausgeführt wird.
31. Computerprogramm mit Programmcodemitteln, die zum Ausführen eines Verfahrens gemäß einem der Aspekte 1 bis 6, 12 bis 17, 23 bis 24 oder 26 bis 28 geeignet sind, wenn das Computerprogramm auf einem Computer, einem Smartphone, einem Datenbanksystem oder einer beliebigen anderen geeigneten Datenverarbeitungseinrichtung oder dem Computersystem gemäß Aspekt 29 ausgeführt wird.
32. Computerlesbares Medium mit einem darauf gespeicherten Computerprogramm, wobei das Computerprogramm Programmcodemittel umfasst, die zum Ausführen eines Verfahrens gemäß einem der Aspekte 1 bis 6, 12 bis 17, 23 bis 24 oder 26 bis 28 geeignet sind, wenn das Computerprogramm auf einem Computer, einem Smartphone, einem Datenbanksystem oder einer beliebigen anderen geeigneten Datenverarbeitungseinrichtung oder dem Computersystem gemäß Aspekt 29 ausgeführt wird.

Claims

Verfahren zum Verwalten eines elektronischen Transaktionsdokuments (T) zwischen einem Benutzer (U) und einem Empfänger (V) in einer Transaktionskette (TC) in einer Datenbank (TDB), wobei sowohl der Benutzer (U) als auch der Empfänger (V) jeweils ein kryptographisches Schlüsselpaar besitzen, das einen öffentlichen Schlüssel (nu; nv) und einen privaten Schlüssel (σ_U; σ_V) umfasst, wobei das elektronische Transaktionsdokument (T) aus einem Transaktionsinhalt (d) vom Benutzer (U) zum Empfänger (V) und einem Transaktionsinhalt-Hash-Wert (h(d)), der mit dem privaten Schlüssel (σ_U) des Benutzers (U) signiert ist, besteht, und wobei das Verfahren die folgenden Schritte umfasst: - Empfangen eines zu archivierenden elektronischen Transaktionsdokuments (T) durch die Datenbank (TDB), - Überprüfen einer Zertifizierung des elektronischen Transaktionsdokuments (T), - Zertifizieren des elektronischen Transaktionsdokuments (T) mit einem Datenbankschlüssel (σ_S), - Lesen des vorherigen zuletzt eingegebenen elektronischen Transaktionsdokuments (T), das in der Transaktionskette (TC) enthalten ist, und Berechnen von dessen Hash-Wert, - Identifizieren der Position (n) der zuletzt eingegebenen elektronischen Transaktion (T_n) und Inkrementieren von dieser um Eins, - Erzeugen eines Tripels der inkrementieren Position (n+1), des Hash-Werts der vorherigen zuletzt eingegeben elektronischen Transaktion (T_n) und des elektronischen Transaktionsdokuments (T), - Signieren des Tripels mit dem Datenbankschlüssel (σ_S), - Speichern des signierten Tripels als neue letzte elektronische Transaktion (T_n+1) in der Transaktionskette (TC).
Datenbanksystem (TDBMS), das ein Verfahren gemäß Anspruch 1 implementiert.
Computersystem, das ein Verfahren gemäß Anspruch 1 implementiert, wobei das Computersystem ein Host-Computer, ein Serversystem, eine tragbare Datenverarbeitungseinrichtung, eine Informations- und Kommunikationseinrichtung, ein Datenbanksystem oder dergleichen ist.
Computerprogramm mit Programmcodemitteln, die zum Ausführen eines Verfahrens gemäß Anspruch 1 geeignet sind, wenn das Computerprogramm auf einem Computer, einem Smartphone, einem Datenbanksystem oder einer beliebigen anderen geeigneten Datenverarbeitungseinrichtung ausgeführt wird.