DE102022002780A1 - Sicheres element, verfahren zum registrieren von token und tokenreferenzregister - Google Patents

Sicheres element, verfahren zum registrieren von token und tokenreferenzregister Download PDF

Info

Publication number
DE102022002780A1
DE102022002780A1 DE102022002780.1A DE102022002780A DE102022002780A1 DE 102022002780 A1 DE102022002780 A1 DE 102022002780A1 DE 102022002780 A DE102022002780 A DE 102022002780A DE 102022002780 A1 DE102022002780 A1 DE 102022002780A1
Authority
DE
Germany
Prior art keywords
token
validity
trr
transaction
token reference
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022002780.1A
Other languages
English (en)
Inventor
Klaus Alfert
Matthias Fasching
Lars Hubel
Peter Zeller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Advance52 GmbH
Original Assignee
Giesecke and Devrient Advance52 GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Advance52 GmbH filed Critical Giesecke and Devrient Advance52 GmbH
Priority to DE102022002780.1A priority Critical patent/DE102022002780A1/de
Priority to PCT/DE2023/100487 priority patent/WO2024027869A1/de
Publication of DE102022002780A1 publication Critical patent/DE102022002780A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein sicheres Element als Transaktionseinheit eines Transaktionssystems mit einem Tokenreferenzregister, ein Verfahren in dem Tokenreferenzregister sowie das Tokenreferenzregister. Das sichere Element umfasst einen Tokenspeicher für Token des Transaktionssystems und ist als Transaktionseinheit eingerichtet, um Token des Transaktionssystems direkt mit einer anderen Transaktionseinheit des Transaktionssystems auszutauschen. Jedem Token (T) des Transaktionssystems (TS) ist eine Tokenreferenz (TR( eindeutig zugeordnet ist, welche in einem Tokenreferenz-Register (TRR) des Transaktionssystems (TS) registrierbar ist. Das sichere Element ist eingerichtet ist, um ausgehend von mindestens einem Eingangstoken mindestens einen Ausgangstoken und dessen Ausgangs-Tokenreferenz (TRA) zu erzeugen. Das sichere Element stellt eine Modifikationsangabe, mit Eingangs-Tokenreferenz (TRE), Kommando (KO) und Ausgangs-Tokenreferenz (TRn), für das Tokenreferenz-Register (TRR) bereit. Vorliegend stellt das sichere Element, die mindestens eine Modifikationsangabe (MA) als Gültigkeitsanfrage (GA) bereit. Es ist zudem eingerichtet, eine Gültigkeitsbestätigung (GB) für zumindest eine auf Gültigkeit zu prüfende Ausgangs-Tokenreferenz der Gültigkeitsanfrage (GA) zu empfangen.

Description

  • Die Erfindung bezieht sich auf ein Verfahren zum Registrieren von Token, insbesondere eines sicheren Elements als Transaktionseinheit, auf ein sicheres Element sowie auf ein Tokenreferenzregister, in dem Tokenreferenzen gespeichert werden, die eindeutig einem Token zugeordnet sind, sowie auf das Transaktionssystem insgesamt.
  • Mit Hilfe sicherer Elemente, wie Chipkarten, SIM-Module etc, als Transaktionseinheiten kann bekanntermaßen eine sichere direkte Übertragung zwischen den Transaktionseinheiten erreicht werden, wobei bewusste Mehrfachausgaben von Token, auch Double-Spending genannt, bereits ausgeschlossen sind.
  • Beispielsweise aus DE 10 2009 038 645 A1 und der DE 10 2009 034 436 A1 sind Systeme bzw. tragbare Datenträger als sichere Elemente zum Übertragen von geldwerten Beträgen in Form elektronischer Datensätze bekannt, bei denen ein Bezahlen mit Duplikaten des Datensatzes verhindert und ein hoher Grad an Manipulationssicherheit gegeben ist. Hier sind komplexe Strukturen und aufwendige Verschlüsselungs- und Signiervorgänge für die Transaktionen erforderlich.
  • Zur Sicherheit von Transaktionen und den dazugehörigen Transaktionsdaten gehören sowohl Schutz der Vertraulichkeit der ausgetauschten Daten; als auch der Schutz der Integrität der ausgetauschten Daten; als auch der Schutz der Verfügbarkeit der ausgetauschten Daten.
  • Als Lösungsansätze für sichere Transaktionssysteme wird oft zwischen tokenbasierten Systemen und accountbasierten Systemen unterschieden. Neben herkömmlichen accountbasierten Systemen, wie beispielsweise Guthaben- oder Kreditkonten, wurden zuletzt neuartigere accountbasierte Systeme basierend auf Blockchain-Topologien diskutiert. Die accountführende Einheit hat dabei jeweils den Zugriff auf den Datensatz, der den geldwerten Betrag repräsentiert. Die neuartigeren accountbasierten Systeme stellen zwar einen hohen Schutz der Integrität bereit, veröffentlichen jedoch auch viele Informationen, beispielsweise wenn Datensätze in einer frei lesbaren Datenstruktur vorliegen und dort den Besitzer wechseln.
  • Es ist ebenfalls bereits bekannt, ein tokenbasiertes Transaktionssystem noch um ein Token-Register zu erweitern. Das sichere Element sendet eine Registrierungsanfrage für seinen Token an das Register. Das Register verifiziert die Registrierungsanfrage und speichert beispielsweise nur eine Tokenreferenz für den Token, kennt also nicht den Token selbst.
  • WO 2020/212337 A1 beschreibt ein Transaktionssystem, bei dem sogar Modifikationen von Token - beispielsweise durch Aufteilen des Tokens, offline, also direkt zwischen den sicheren Elementen des Transaktionssystems und ohne weitere Kontrollinstanz, gesichert möglich sind. Die Token können nach dem Erhalt in einem sicheren Element bzw. einer Teilnehmereinheit sofort weiter übertragen werden, ohne dass eine Registrierung einer Modifikation in einem Token-Register des Transaktionssystems erfolgen muss. Die Registrierung der Modifikation in dem Token-Register kann zeitlich unabhängig von der eigentlichen Transaktion, dem Übertragen des Token, erfolgen. Die sicheren Elemente sind bekanntermaßen jedoch ressourcenbeschränkt, insbesondere bezüglich Speicherplatz, Verarbeitungsgeschwindigkeit, Übertragungszeit und/oder -geschwindigkeit begrenzt.
  • Der Erfindung liegt die Aufgabe zu Grunde, ein neues Verfahren bereit zu stellen, das für ein sicheres Element als Transaktionseinheit besser geeignet ist, also insbesondere ressourcensparend ist. Die Abläufe im Transaktionssystem, wie das direkte Übertragen der Token zwischen den Transaktionseinheiten und die Registrierung von Token in dem Register, sowie die verbundenen Vorteile und Einsatzmöglichkeiten sollten bevorzugt erhalten bleiben. Insbesondere sollen auch mehrere Modifikationsangaben einer Transaktionseinheit ressourcensparend verarbeitet werden.
  • Die gestellte Aufgabe wird durch die in den unabhängigen Patentansprüchen beschriebenen Merkmalen gelöst. Weitere vorteilhafte Ausgestaltungen sind in den jeweils abhängigen Patentansprüchen beschrieben.
  • Ein sicheres Element eines elektronischen Transaktionssystems weist einen Tokenspeicher für Token des Transaktionssystems auf und ist eingerichtet, Token direkt mit einer anderen Transaktionseinheit des Transaktionssystems auszutauschen. Jedem Token des Transaktionssystems ist eine Tokenreferenz eindeutig zugeordnet. In einem Tokenreferenz-Register des Transaktionssystems sind Tokenreferenzen (und somit die zugeordneten Token) registrierbar. Das sichere Element ist weiter eingerichtet, um ausgehend von mindestens einem Eingangstoken mindestens einen Ausgangstoken und dessen Ausgangs-Tokenreferenz zu erzeugen. Das sichere Element stellt mindestens eine Modifikationsangabe für das Tokenreferenz-Register bereit, welche mindestens eine Eingangs-Tokenreferenz, ein Kommando und mindestens eine Ausgangs-Tokenreferenz umfasst.
  • Nun stellt das sichere Element die mindestens eine Modifikationsangabe als eine Gültigkeitsanfrage bereit und empfängt eine Gültigkeitsbestätigung für zumindest eine auf Gültigkeit zu prüfende Ausgangs-Tokenreferenz der Gültigkeitsanfrage.
  • Das Senden der Modifikationsangabe in einer Gültigkeitsanfrage ermöglicht, wie im Folgenden näher dargelegt, eine Vielzahl von zunächst scheinbar eher kleinen Fortschritten, die spätestens in der Summe für das sichere Element und sogar für das Tokenreferenz-Register hilfreich sein können. Da das Tokenreferenz-Register die Gültigkeitsanfrage mit (nur optionaler) Modifikationsangabe im Schnitt schneller bearbeiten kann als eine herkömmliche Registrieranfrage, reduziert sich bereits die Verbindungs- oder Übertragungszeit und somit der Aufwand im sicheren Element die Verbindung zu verwalten, insbesondere aufrecht zu erhalten (Timeouts ...) oder wieder herzustellen.
  • Die Gültigkeitsanfrage kann vorzugsweise die zumindest eine zu prüfende Ausgangs-Tokenreferenz und mindestens eine nicht zu prüfende Ausgangs-Tokenreferenz umfassen. Es sind also nicht alle Ausgangs-Tokenreferenzen auf Gültigkeit zu prüfen.
  • Die Gültigkeitsanfrage kann die Modifikationsangabe und zusätzlich eine Prüfungsangabe umfassen, welche die zumindest eine (oder mehreren) zu prüfende(n) Ausgangs-Tokenreferenz(en) angibt. Die Prüfungsangabe kann beispielsweise die Ausgangs-Tokenreferenz(en) enthalten, einen (oder die) Verweis(e) auf die Ausgangs-Tokenreferenzen enthalten oder auch durch ein (oder mehrere) gesetzte Flag(s) für die Ausgangs-Tokenreferenz(en) kodiert sein. Flags sind in der Regel Bits, die entweder gesetzt oder nicht gesetzt sind. Für jede Ausgangs-Tokenreferenz der Gültigkeitsanfrage oder der Modifikationsangabe wäre beispielsweise ein Flag vorgesehen, das entweder gesetzt oder nicht gesetzt sein kann. Besonders bevorzugt betrifft die Prüfungsangabe Ausgangs-Tokenreferenzen von mindestens zwei unterschiedlichen Modifikationsangaben der Gültigkeitsanfrage.
  • Insbesondere zugunsten des Tokenreferenz-Registers könnte das sichere Element eingerichtet sein, um Modifikationsangaben entweder als Gültigkeitsanfrage oder als Registrieranfrage bereit zu stellen. Als Auswahlkriterium für das Senden als Gültigkeitsanfrage könnte das sichere Element beispielsweise verwenden:
    • - eine Anzahl der im sicheren Element gespeicherten Modifikationsangaben, insbesondere ab mehr als zwei Modifikationsangaben, und/oder
    • - ein Zeitkriterium, insbesondere mit Hilfe eines Zeitstempels, beispielsweise einer Transaktion und/oder Modifikation oder der letzten Kommunikation mit dem Tokenreferenz-Register verwenden, und/oder
    • - ein Herkunftskriterium, beispielsweise falls die Modifikationsangabe empfangen wurde, insbesondere von einer anderen Transaktionseinheit.
  • Eine solche Auswahl durch das sichere Element ist jedoch nicht wirklich erforderlich. Wie im Folgenden noch deutlich wird, kann das sichere Element eine (oder mehrere) Modifikationsangabe(n) immer als Gültigkeitsanfrage senden.
  • Es ist prinzipiell denkbar den Datenaustausch mit dem Tokenreferenz-Register, inklusive Gültigkeitsanforderung und -bestätigung, kryptographisch abzusichern, also zu verschlüsseln und/oder zu signieren. Insbesondere eine von Dritten manipulierte Gültigkeitsbestätigung würde so erkannt werden.
  • Besonders vorteilhaft (und für die Absicherung einer Gültigkeitsanfrage hinreichend) ist es, wenn die Gültigkeitsbestätigung für jede zu prüfende Ausgangs-Tokenreferenz eine separate kryptographische Bestätigung, wie Prüfsumme oder Signatur, umfasst. Die kryptographische(n) Bestätigung(en) für die zu prüfende(n) Ausgangs-Tokenreferenz(en), werden vorzugsweise in dem sicheren Element gespeichert und/oder zusammen mit dem(den) zugeordneten Token an eine andere Transaktionseinheit übertragen.
  • Die Gültigkeitsanfrage kann mehrere Modifikationsangaben umfassen, insbesondere einen Stapel und/oder zumindest eine Folge von Modifikationsangaben umfassen. Voneinander (in ihren Tokenreferenzen) unabhängige Modifikationsangaben werden vorliegend als Stapel bezeichnet. Die Modifikationsangaben eines Stapels können in dem Tokenreferenz-Register in beliebiger Reihenfolge verarbeitet werden. Voneinander (in ihren Tokenreferenzen) abhängige Modifikationsangaben werden dagegen als Folge (oder Sequenz) bezeichnet. Mindestens eine Ausgangs-Tokenreferenz einer Modifikationsangabe ist zugleich Eingangs-Tokenreferenz einer anderen Modifikationsangabe. Vorzugsweise umfasst die Folge mehrere Ausgangs-Tokenreferenzen, die zugleich Eingangs-Tokenreferenz einer nachfolgenden Modifikationsangabe in der Folge sind. Die Modifikationsangaben einer Folge können in dem Tokenreferenz-Register nicht in beliebiger Reihenfolge verarbeitet werden. Das Tokenreferenzregister wird die Modifikationsangaben der Folge(n) insbesondere in der Reihenfolge ausführen, in der sie in der Gültigkeitsanfrage vorliegen oder die in der Gültigkeitsanfrage vorgegeben ist. Die Folge kann insbesondere mit oder ohne Verzweigungen aufgebaut sein, nur beispielsweise „MA1 => MA2 => ... => MAn“ oder „(MA1, MA2) => MA3 ... (MA4, MA5) => MA6 ...“.
  • Die Modifikationsangabe(n) der Gültigkeitsanfrage ist (sind) insbesondere nur optional auszuführen. Eine Gültigkeitsbestätigung kann das Tokenreferenz-Register selbst im Falle einer (oder mehrerer) fehlerhafter Modifikationsangabe(n) senden. Ob das Tokenreferenz-Register die Modifikationsangabe(n) prüft und gegebenenfalls ausführt und/oder welche der Modifikationsangaben geprüft und ausgeführt wurden, ist unabhängig von der Gültigkeitsbestätigung für die zumindest eine (oder mehreren) zu prüfende(n) Ausgangs-Tokenreferenz(en).
  • Die Gültigkeitsanfrage kann für ein Tokenreferenz-Register, welches nur die gültigen Tokenreferenzen in einer Speichereinheit für Tokenreferenzen speichert, eine Aufforderung sein zu prüfen, ob die zu prüfende(n) Ausgangs-Tokenreferenz(en) bereits in der Speichereinheit gespeichert ist (sind).
  • Das sichere Element umfasst regelmäßig einen Prozessor, insbesondere zur Ausführung der Schritte als Transaktionseinheit, und/oder eine Schnittstelle, insbesondere zu einem lokalen Endgerät, über welche die Gültigkeitsanfrage für das Tokenreferenz-Register (TRR) bereitgestellt wird. Eine Transaktionseinheit kann eine Teilnehmereinheit sein bzw. wird im Folgenden teilweise auch als solche bezeichnet.
  • Der bzw. jeder Token wird als Datenelemente insbesondere einen Tokenwert sowie einen geheimes Tokenelement umfassen, der insbesondere ein geheimer Schlüssel eines Schlüsselpaares ist. Tokenreferenzen können als Datenelemente einen Tokenwert, insbesondere den Tokenwert des Tokens, sowie ein öffentliches Tokenelement, insbesondere den öffentlichen Schlüssel des Schlüsselpaares des Tokens, umfassen.
  • Eine Modifikation ist insbesondere ein Aufteilen und/ Verbinden oder Umschalten von Token. Das Kommando der Modifikationsangabe ist entsprechend beispielsweise „Aufteilen“, „Verbinden“ oder „Umschalten“. Ein (oder mehrere) Eingangstoken mit einem (Gesamt-)Tokenwert kann in mehrere Ausgangstoken mit anderem Tokenwert (aber gleichem Gesamtwert) aufgeteilt werden. Zwei oder mehr Eingangstoken mit einem Gesamtwert können zu einem Ausgangstoken mit dem Gesamtwert verbunden werden. Ein Eingangstoken mit einem Tokenwert kann auf einen Ausgangstoken mit dem gleichen Tokenwert umgeschaltet werden.
  • Die Transaktionseinheit, also beispielsweise das Sicherheitselement, kann einen (oder mehrere) Ausgangstoken, insbesondere inklusive Tokenwert und geheimem Tokenelement, sowie die zugeordnete Ausgangs-Tokenreferenz für die Modifikationsangabe erzeugen.
  • Die Transaktionseinheit, also beispielsweise das Sicherheitselement, speichert Ihre Token sowie optional eine oder mehrere Modifikationsangaben. Die Modifikationsangabe ist zusammen mit oder zumindest verknüpft mit dem Ausgangstoken abgespeichert.
  • Das Sicherheitselement kann bevorzugt in Antwort auf den Empfang der Gültigkeitsbestätigung die im Sicherheitselement gespeicherten Modifikationsangabe(n) löschen, die in der Gültigkeitsanfrage enthalten war(en).
  • Token können direkt mit anderen Transaktionseinheiten ausgetauscht werden. Für noch nicht registrierte Token ist der Token zusammen mit der (oder den) Modifikationsangabe(n) zu übertragen. Bereits registrierte Token können ohne die Modifikationsangabe übertragen werden.
  • Vorliegend wird ein Verfahren zum Prüfen der Gültigkeit eines Tokens eines sicheren elektronischen Transaktionssystems bereitgestellt. Jedem Token des Transaktionssystems ist eine Tokenreferenz eindeutig zugeordnet. Ein Tokenreferenz-Register des Transaktionssystems umfasst eine Verifikationseinheit und eine Speichereinheit, in welcher die Tokenreferenzen gültiger Token gespeichert sind. In dem Tokenreferenz-Register werden folgende Schritt ausgeführt:
    • - Empfangen einer Gültigkeitsanfrage, die eine Modifikationsangabe mit mindestens einer Eingangs-Tokenreferenz, mindestens einer Ausgangs-Tokenreferenz und einem Kommando umfasst;
    • - Prüfen mindestens einer auf Gültigkeit zu prüfenden Ausgangs-Tokenreferenz der Gültigkeitsanfrage darauf, ob sie in der Speichereinheit gespeichert ist; und
    • - Senden einer Gültigkeitsbestätigung für die mindestens eine zu prüfende Ausgangs-Tokenreferenz.
  • Die Gültigkeitsanfrage umfasst eine Prüfungsangabe, welche die zumindest eine zu prüfende Ausgangs-Tokenreferenz angibt, und/oder die nur optional zu bearbeitende Modifikationsangabe.
  • Das Prüfen (und optional das Empfangen und Senden) erfolgt vorzugsweise durch die Verifikationseinheit des Tokenreferenz-Registers. Das Empfangen und Senden kann durch eine Schnittstelleneinheit des Tokenreferenz-Registers erfolgen.
  • Vorzugsweise bearbeitet die Verifikationseinheit Modifikationsangaben, also optional auch die Modifikationsangabe(n) der Gültigkeitsanfrage, mit einem oder mehreren der Teilschritte:
    • - Prüfen ob die mindestens eine Eingangs-Tokenreferenz in der Speichereinheit gespeichert ist; und/oder
    • - Verifizieren der Modifikationsangabe, insbesondere einer (oder mehrerer) Signatur(en) in der Modifikationsanfrage und/oder einer Wertneutralität der Modifikationsangabe und/oder einer Syntax der Modifikationsangabe; und/oder
    • - Ausführen des Kommandos (bzw. der Modifikationsangabe) durch Speichern einer Ausgangs-Tokenreferenz in der Speichereinheit und insbesondere durch Löschen einer Eingangs-Tokenreferenz in der Speichereinheit.
  • In vorteilhaften Ausgestaltungen wird die Gültigkeitsbestätigung - insbesondere ohne weitere Bearbeitung der Modifikationsangabe - gesendet, falls die zu prüfende(n) Ausgangs-Tokenreferenz(en) der Gültigkeitsanfrage bereits in der Speichereinheit gespeichert sind. Andernfalls erfolgt die Bearbeitung der Modifikationsangabe(n). Die Gültigkeitsbestätigung kann alternativ oder ergänzend gesendet werden, nachdem die Bearbeitung der (einen oder mehreren) nur optional zu bearbeitenden Modifikationsangabe(n) vollständig oder in Teilschritten ausgelassen wurde, also keiner der Teilschritte ausgeführt wurde oder nicht alle Teilschritte ausgeführt wurden.
  • Die Gültigkeitsanfrage umfasst vorzugsweise mindestens eine, weiter vorzugsweise mehrere, nicht auf Gültigkeit zu prüfende Ausgangs-Tokenreferenz(en). Die Gültigkeitsbestätigung (GB) kann für jede zu prüfende Ausgangs-Tokenreferenz eine separate kryptographische Bestätigung, wie Signatur oder Prüfsumme umfassen.
  • Die auf Gültigkeit zu prüfende Ausgangs-Tokenreferenz muss nicht explizit in der Prüfungsangabe der Gültigkeitsanfrage angezeigt sein. Sie kann eine der in der Modifikationsangabe enthaltenen Ausgangs-Tokenreferenzen sein. Bevorzugt wird(werden) die zu prüfende(n) Tokenreferenz(en) jedoch in der Prüfungsangabe, als eigenständiges Datenelement der Gültigkeitsanfrage, vom Tokenreferenzregister empfangen. Die Prüfungsangabe kann durch einen (oder mehrere) Verweis(e) auf die zu prüfende Ausgangs-Tokenreferenz(en) gebildet sein (beispielsweise Position oder Nummer der Ausgangs-Tokenreferenz in der Gültigkeitsanfrage) oder die Ausgangs-Tokenreferenz(en) enthalten.
  • Die Gültigkeitsanfrage kann mehrere Modifikationsangaben umfassen, wobei jede Modifikationsangabe eine oder mehrere Eingangs-Tokenreferenzen, eine oder mehrere Ausgangs-Tokenreferenzen und ein Kommando umfasst. Die Modifikationsangaben sind vorzugsweise ein Stapel von Modifikationsangaben und/oder eine Folge von Modifikationsangaben sind. Stapel bestehen aus unabhängigen Modifikationsangaben. Folgen bestehen aus mindestens teilweise voneinander abhängigen Modifikationsangaben.
  • Der zu prüfende Token ist in der Direkttransaktionsschicht des Transaktionssystems direkt zwischen zwei Transaktionseinheiten des Transaktionssystems übertragbar (muss aber noch nicht übertragen worden sein). Der zu prüfende Token ist bevorzugt in einer Transaktionseinheit modifiziert worden, ohne dass der Token im Transaktionssystem registriert wurden.
  • Bevorzugt wird die Gültigkeitsbestätigung auch gesendet, wenn einige der mehreren Modifikationsangaben nicht ausführbar sind (die Zuordnung der Tokenreferenzen zu Token des Transaktionssystems also teilweise nicht möglich ist), insbesondere wenn diese Modifikation(en) nur in der Direkttransaktionsschicht ohne ein Registrieren der Modifikation(en) im Tokenreferenzregister erfolgt ist. Es ist damit keine Voraussetzung der Gültigkeitsprüfung, dass alle Modifikationsangaben einer Gültigkeitsanfrage von der Verifiziereinheit nachvollziehbar oder ausführbar sind. Lediglich die Zuordnung der zumindest einen zu prüfenden Tokenreferenz muss nachprüfbar sein. Somit erfolgt das Verifizieren unabhängig von einer Registrierung einer oder mehrerer Modifikation aus der Modifikationsangabe im Tokenreferenzregister.
  • Die Verifikationseinheit des Tokenreferenzregister kann an die Speichereinheit des Tokenreferenzregister Speicherabfragen und/oder Speicheranweisungen senden. So kann sie beispielsweise abfragen, ob eine Tokenreferenz in der Speichereinheit gespeichert ist und/oder anweisen eine Tokenreferenz zu speichern oder zu löschen. Bevorzugt sendet die Verifikationseinheit an die Speichereinheit eine gemeinsame Speicherabfrage für Ausgangs-Tokenreferenzen unterschiedlicher Modifikationsangaben und/oder für Ausgangs-Tokenreferenzen und Eingangs-Tokenreferenzen zumindest einer Modifikationsangabe.
  • Insbesondere für einen Stapel von Modifikationsangaben in der Gültigkeitsanfrage kann das Tokenreferenzregister eine Teilgültigkeitsbestätigung senden. Die Teilgültigkeitsbestätigung betrifft vorzugsweise die gültigen Ausgangstokenreferenzen der auf Gültigkeit zu prüfenden Ausgangstokenreferenzen des Stapels.
  • Für eine Folge von Modifikationsangaben in der Gültigkeitsanfrage kann die Verifikationseinheit zumindest eine (oder) Ausgangs-Tokenreferenz(en) mindestens einer Modifikationsangabe nur intern zwischenspeichern (also nicht in der Speichereinheit speichern). Die zwischengespeicherte(n) Ausgangs-Tokenreferenz(en) wird, falls sie Eingangs-Tokenreferenz einer weiteren Modifikationsangabe ist verworfen oder andernfalls in die Speichereinheit gespeichert. Zumindest eine (oder mehrere) Ausgangstokenreferenz(en) einer Modifikationsangabe wird erst nach Prüfung einer, mehrerer oder aller weiteren Modifikationsangaben der Folge in der Speichereinheit gespeichert.
  • Das Tokenreferenz-Register kann das Verfahren mit einer Transaktionseinheit oder dem bereits beschriebenen sicheren Element ausführen.
  • Das Tokenreferenz-Register kann ferner umfassen weitere Verifikationseinheiten und/oder eine Archiveinheit, welche nicht mehr gültige Tokenreferenzen und/oder bereits ausgeführte Gültigkeitsanfragen und/oder Registrierungsanfragen speichert.
  • Ein Tokenreferenz-Register für ein Transaktionssystem ist eingerichtet zum Durchführen eines der vorgenannten Verfahren, insbesondere mit einer Transaktionseinheit TE des Transaktionssystems oder mit einem der vorgenannten sicheren Elemente.
  • Das Tokenreferenz-Register umfasst die Speichereinheit zum Speichern der gültigen Tokenreferenzen im Transaktionssystem; eine Schnittstelle eingerichtet zum Empfangen einer Gültigkeitsanfrage und die zumindest eine Verifiziereinheit.
  • Ein Transaktionssystem umfasst eine Registerschicht mit dem Tokenreferenz-Register; und eine Direkttransaktionsschicht mit einer Vielzahl von Transaktionseinheiten, einschließlich einem sicheren Element.
  • Die Gültigkeitsanfragen im Transaktionssystem können auf verschiedene Verifiziereinheiten eines Tokenreferenz-Registers verteilt werden und diese können damit parallel von verschiedenen Verifiziereinheiten des Tokenreferenz-Registers verarbeitet werden. Damit kann eine große Anzahl von Gültigkeitsanfragen intern im Tokenreferenz-Register auf verschiedene Verifiziereinheiten aufgeteilt werden („Load balancing“).
  • Die Gültigkeitsbestätigung und/oder die gültige(n) zu prüfende Ausgangstokenreferenz(en) ist bevorzugt mit einem privaten Teil eines Schlüsselpaars des Tokenreferenzregisters, bevorzugt der Verifizier-Einheit (ggf. einer von einer Vielzahl von Verifizier-Einheiten), signiert. Diese Signatur wird von der Transaktionseinheit beim Empfang der Gültigkeitsbestätigung mit dem öffentlichen Teil des Schlüsselpaars des Tokenreferenz-Registers überprüft. Dies erhöht die Sicherheit, denn Gültigkeitsbestätigung, die von unberechtigten Dritten - beispielsweise im Rahmen von Man-in-the-Middle-Attacken - erzeugt werden, werden von einer Transaktionseinheit aufgrund einer fehlenden oder ungültigen Signatur erkannt. Derartige Gültigkeitsbestätigung können dann von der Transaktionseinheit ignoriert werden.
  • Ein Token ist ein zwischen Transaktionseinheiten direkt austauschbarer Datensatz eines Transaktionssystems. Mit Kenntnis des Tokens ist die empfangende Transaktionseinheit im Besitz des Tokenwerts, den der Token repräsentiert. Mit dem Austauschen wechselt der Token demnach automatisch den Besitzer. Ein Token - ein Datensatz, der unabhängig von einer Transaktionstopologie, wie Blockchain-Topologien, übertragbar ist - kann direkt zwischen Transaktionseinheiten ohne dazwischengeschaltete Einheiten übertragen werden.
  • In einer Ausgestaltung ist der Token ein elektronischer Münzdatensatz oder Bezahl-Token, um geldwerte Beträge zwischen Transaktionseinheiten zu tauschen. Umgangssprachlich wird ein derartiger Bezahl-Token auch als „digitale Münze“ oder „elektronische Münze“, englisch „digital/electronic coin“ bezeichnet und repräsentiert Bargeld in elektronischer Form.
  • Jeder Token im Transaktionssystem ist ein Datensatz umfassend zumindest zwei Tokenelemente.
  • Ein erstes Tokenelement jedes Tokens des Transaktionssystems ist ein Tokenwert, bspw. ein Vermögenswert, ein Vermögensgegenstand, ein Wirtschaftsgut und/oder ein geldwerter Betrag.
  • Ein zweites Tokenelement jedes Tokens des Transaktionssystems ist ein privater Teil eines tokenindividuellen Schlüsselpaars. Dieser private Teil ist ein Geheimnis im Transaktionssystem und wird nicht veröffentlicht und darf nicht mehrfach verwendet werden. Die Erzeugung des privaten Teils darf nicht vorhersagbar sein. Dieser private Teil kann eine Zufallszahl sein. Bevorzugt ist die Zufallszahl das Ergebnis eines echten Zufallsgenerators.
  • Aus dem Tokenwert (erstes Tokenelement) und dem privaten Teil wird der Token gebildet. Dieses Bilden ist bevorzugt das Verketten (Konkatenation) dieser beiden Tokenelemente. Jede andere Art der Verknüpfung dieser beiden Tokenelemente ist erfindungsgemäß nicht ausgeschlossen und umfasst beispielsweise das Hintereinander-Anfügen, das Einbringen in eine TLV-Datenstruktur und/oder das logische Verknüpfen.
  • Jeder, der im Besitz eines Tokens oder uneingeschränkten Zugriff auf den Token mit seinen Tokenelementen hat, kann diesen Token mit einer anderen Transaktionseinheit austauschen. Der Besitz des Tokens mit seinen zumindest zwei Tokenelementen (Tokenwert und privater Teil des tokenindividuellen Schlüsselpaars) ist also gleichbedeutend mit dem Besitz des Wertes, den der Token repräsentiert.
  • Jedem Token im Transaktionssystem wird eine Tokenreferenz zugeordnet. Diese Zuordnung ist eineindeutig, das heißt, einem Token ist genau eine Tokenreferenz zugeordnet und jeder Tokenreferenz ist genau ein Token zugeordnet. Die Tokenreferenz ist ein öffentlicher Datensatz, der in einer Speichereinheit des Tokenreferenz-Registers des Transaktionssystems für jede Transaktionseinheit überprüfbar abgespeichert ist.
  • Sowohl der Token als auch die Tokenreferenz sind einzigartig. Durch die eineindeutige Zuordnung herrscht eine 1-zu-1 Beziehung zwischen dem Token und der Tokenreferenz.
  • Jede Tokenreferenz im Transaktionssystem ist ein Datensatz umfassend zumindest zwei Tokenreferenz-Elemente.
  • Ein erstes Tokenreferenz-Element jeder Tokenreferenz ist der Tokenwert des der Tokenreferenz eindeutig zugeordneten Tokens. Der Tokenwert des Tokens ist damit identisch zum Tokenwert der zugeordneten Tokenreferenz. Beispielsweise ist der Tokenwert der Tokenreferenz eine Kopie des Tokenwerts des zugeordneten Tokens.
  • Ein zweites Tokenelement jeder Tokenreferenz des Transaktionssystems ist ein öffentlicher Teil des tokenindividuellen Schlüsselpaars. Dieser öffentliche Teil der Tokenreferenz bildet zusammen mit dem privaten Teil des Tokens das tokenindividuelle Schlüsselpaar. Der öffentliche Teil wird durch Anwenden einer kryptografischen Funktion auf den privaten Teil erhalten.
  • Diese kryptografische Funktion ist eine Einwegfunktion. Diese kryptografische Funktion ist demnach eine mathematische Funktion, die komplexitätstheoretisch „leicht“ berechenbar, aber „schwer“ bis praktisch unmöglich umzukehren ist. Hierbei wird unter Einwegfunktion auch eine Funktion bezeichnet, zu der bislang keine in angemessener Zeit und mit vertretbarem Aufwand praktisch ausführbare Umkehrung bekannt ist. Vorzugsweise wird eine Einwegfunktion verwendet, die auf eine Gruppe operiert, in der das diskrete Logarithmusproblem schwer zu lösen ist, wie z. B. ein kryptographisches Verfahren analog einer elliptischer-Kurve-Verschlüsselung, kurz ECC, aus einem privaten Schlüssel eines entsprechenden Kryptographie-Verfahrens. Die umgekehrte Funktion, also die Erzeugung eines Tokens (oder des Teils des elektronischen Münzdatensatzes) aus einer Tokenreferenz ist dabei sehr zeitintensiv.
  • Die (bloße) Kenntnis oder der Besitz einer Tokenreferenz berechtigt nicht dazu, den Tokenwert (Tokenreferenz-Element) zu verwenden/ übertragen/auszugeben. Dies stellt einen wesentlichen Unterschied zwischen der Tokenreferenz und dem Token dar und ist ein Kern der hier vorliegenden Erfindung.
  • Nach dem Anwenden der kryptografischen Funktion auf den privaten Teil des tokenindividuellen Schlüsselpaars wird der öffentliche Teil des tokenindividuellen Schlüsselpaars als zweites Tokenreferenz-Element erhalten.
  • Aus dem Tokenwert (erstes Tokenreferenz-Element) und dem öffentlichen Teil wird die Tokenreferenz gebildet. Dieses Bilden ist bevorzugt das Verketten (Konkatenation) dieser beiden Tokenreferenz-Elemente. Jede andere Art der Verknüpfung dieser beiden Tokenreferenz-Elemente ist erfindungsgemäß nicht ausgeschlossen und umfasst beispielsweise das Hintereinander-Anfügen, das Einbringen in eine TLV-Datenstruktur und/oder das logische Verknüpfen.
  • Eine Tokenreferenz kann bevorzugt durch eine elektronische Geldbörse (=Wallet) einer Transaktionseinheit erzeugt werden. Dazu muss die Transaktionseinheit Kenntnis von dem Token mit seinen Tokenelementen aufweisen. Das Erzeugen der Tokenreferenz kann durch eine elektronische Geldbörse einer Transaktionseinheit erfolgen, die den Token senden möchte. Alternativ kann das Erzeugen der Tokenreferenz durch eine elektronische Geldbörse einer Transaktionseinheit erfolgen, die den Token empfangen hat.
  • Die Verwendung einer Tokenreferenz ist nicht mit der Verwendung von Adressen von Transaktionseinheiten in einem Blockchain-basierten Transaktionssystem vergleichbar, da im erfindungsgemäßen Tokenreferenz-Register keine Adressen der Transaktionseinheiten verwendet werden, um eine Verfolgbarkeit der Token zu verhindern.
  • Das Tokenreferenz-Register ist eine Einheit des Transaktionsregisters, die die Tokenreferenzen ablegt, wodurch die Token als gültige Token registriert sind. Dieses Register kann eine zentrale Datenbank oder Speichereinheit sein. Dieses Register kann ein dezentraler Ledger sein. Das Tokenreferenz-Register kann separat in einer Archiveinheit eine Historie der Tokenreferenzen und/oder den Registrieranfragen und/oder den Gültigkeitsanfragen führen.
  • Im Tokenreferenz-Register ist eine Tokenreferenz nur ein einziges Mal gespeichert. Da eine Tokenreferenz eines Tokens nur ein einziges Mal im Transaktionssystem vorhanden ist, kann durch den Verifizieren-Schritt festgestellt werden, ob versucht wurde, einen Token mehrfach auszugeben.
  • Der Token ist in einem Tokenspeicher abgelegt, auf den die Transaktionseinheit exklusiv zugreifen kann. Dieser Tokenspeicher kann eine Vielzahl von Token aufweisen, beispielsweise kann in einem Datenspeicher der Transaktionseinheit die Vielzahl von Token abgelegt sein. Der Datenspeicher kann beispielsweise intern, extern oder virtuell sein. In einer Ausgestaltung kann beim Empfangen eines Tokens automatisch ein „Verbinden“ stattfinden, sodass bevorzugt nur ein (oder eine bestimmte Anzahl an) Token in der Transaktionseinheit abgelegt sind.
  • Die Transaktionseinheit kann beispielsweise ein mobiles Endgerät, wie z.B. ein Smartphone, ein Tablet-Computer, ein Computer, ein Server oder eine Maschine sein. Die Transaktionseinheit kann eine Smartcard sein, die betriebsbereit in einem Endgerät eingebracht ist. Die Transaktionseinheit ist bevorzugt ein Secure Element.
  • Der Datenspeicher ist beispielsweise einen Geldbörsenspeicher einer elektronischen Geldbörse (Wallet). Die elektronische Geldbörse ist beispielsweise eine Softwareapplikation, die auf einer Transaktionseinheit ausführbar abgespeichert ist. Die elektronische Geldbörse (Wallet) kann der Transaktionseinheit die Teilnahme am Transaktionssystem ermöglichen. So kann die elektronische Geldbörse eine Gültigkeitsanfrage generieren, um die Gültigkeit eines Tokens prüfen zu lassen. Zudem kann die elektronische Geldbörse Modifikationen (Umschalten, Verbinden, Aufteilen) an einem Token vornehmen und die dabei möglicherweise notwendigen Gültigkeitsanfrage generieren und an das Tokenreferenz-Register senden. Zudem kann die elektronische Geldbörse Token an eine andere Geldbörse (in einer anderen Transaktionseinheit) übertragen.
  • Eine Transaktion im Transaktionssystem ist vorzugsweise atomar.
  • Erfindungsgemäß ist ein Tokenreferenz-Register für ein Transaktionssystem vorgesehen, das eingerichtet ist zum Durchführen der Verfahrensschritte gemäß dem zuvor beschriebenen Verfahren.
  • Das Tokenreferenz-Register kann eingerichtet sein zum Empfangen einer Vielzahl von Gültigkeitsanfragen, die parallel in einer Mehrzahl von Verifizier-Einheiten darauf verifiziert werden, ob die in der jeweils empfangenen Gültigkeitsanfrage enthaltene zumindest eine Tokenreferenz gültig ist.
  • Erfindungsgemäß ist ein Transaktionssystem vorgesehen, das aufweist eine Registerschicht mit einem Tokenreferenz-Register der vorhergehenden Art zum Registrieren von Tokenreferenzen und Prüfen von Token mittels Tokenreferenzen und eine Direkttransaktionsschicht mit einer Vielzahl von Transaktionseinheiten, eingerichtet zum direkten Austausch von Token untereinander.
  • Erfindungsgemäß ist also ein zweischichtiges Transaktionssystem aus einer Direkttransaktionsschicht zum direkten Austauschen von Token und einer Registerschicht vorgesehen. In der Registerschicht werden keine Transaktionen protokolliert, sondern ausschließlich Tokenreferenzen abgespeichert und Modifikationen zu Token über entsprechend angepasste Tokenreferenzen zum Zweck der Verifizierung der Gültigkeit von Token abgespeichert. So wird die Anonymität der Teilnehmer des Transaktionssystems gewährleistet.
  • Die Speichereinheit des Tokenreferenz-Registers speichert bevorzugt nur Tokenreferenzen von im Transaktionssystem gültigen Token. Sobald ein Token modifiziert wird und eine entsprechende (modifizierte) Tokenreferenz registriert werden soll, werden die (alten) Tokenreferenzen ungültig und (nur) die modifizierten Tokenreferenzen werden in der Speichereinheit gespeichert.
  • Alte (also ungültig gewordene) Tokenreferenzen werden in einer Ausgestaltung aus der Speichereinheit gelöscht und in einem (Tokenreferenz-)Archiv archiviert. Das Tokenreferenz-Archiv kann ein Teil der Archivierungseinheit sein, es kann aber auch als getrennte Einheit im Tokenreferenz-Register oder im Transaktionssystem vorgesehen sein. Das Tokenreferenz-Archiv kann auch vollständig durch die Archivierungseinheit ersetzt werden, wenn dort alle Registrieranfragen vollständig abgelegt sind. Das zeitlich abhängige Löschen von Registrieranfragen kann auch für das Löschen von alten Tokenreferenzen gelten.
  • Erfindungsgemäß ist eine Transaktionseinheit, bevorzugt ein Secure Element, in einem sicheren elektronischen Transaktionssystem mit: einer Schnittstelle, die eingerichtet ist zum: Übertragen von Token zu einer anderen Transaktionseinheit; Erstellen und Senden, an ein Tokenreferenz-Register, einer Gültigkeitsanfrage zum Prüfen eines Tokens gemäß einem der vorhergehenden Ausgestaltungen; einem Zugriffsmittel auf einen Tokenspeicher oder Tokenspeicher, wobei im Tokenspeicher zumindest ein Token der Transaktionseinheit mit Modifikationsangabe abgelegt ist; und einer Recheneinheit, eingerichtet zum: Anwenden einer kryptografischen Einwegfunktion auf einen privaten Teil eines tokenindividuellen Schlüsselpaars eines Tokens des Tokenspeichers zum Erhalten einer Tokenreferenz; und Modifizieren von Token.
  • Zudem hat die Transaktionseinheit Zugriffsmittel auf einen Tokenspeicher und/oder die Transaktionseinheit weist einen Tokenspeicher auf, wobei im Tokenspeicher zumindest ein Token der Transaktionseinheit mit der Folge von Registrieranfragen abgelegt ist.
  • Zudem hat die Transaktionseinheit eine Recheneinheit, die eingerichtet ist zum Anwenden einer kryptografischen Einwegfunktion auf einen privaten Teil eines tokenindividuellen Schlüsselpaars eines Tokens des Tokenspeichers zum Erhalten einer Tokenreferenz; und zum Modifizieren von Token. Das Modifizieren von Token umfasst insbesondere das Aufteilen von Token, das Verbinden von Token und/oder das Umschalten von Token gemäß der oben beschriebenen Art.
  • Die Transaktionseinheit kann derart eingerichtet sein, dass in deren Tokenspeicher nur ein Token gespeichert ist. Dieser Token wird für direkte Transaktionen aufgeteilt (SPLIT), um einen korrekten Tokenwert entsprechend der zu tätigenden Transaktion zu erzeugen. Werden Token in der Transaktionseinheit empfangen, wird der empfangene Token mit dem Token des Tokenspeichers sofort verbunden (MERGE).
  • Zum Übertragen eines Tokens an eine andere Transaktionseinheit kann dieser Token des Tokenspeichers demnach aufgeteilt (SPLIT) werden, wobei dazu eine Registrieranfrage erzeugt wird. Bevorzugt weist die Registrieranfrage eine Tokenreferenz des aufzuteilenden Tokens und jeweils eine Tokenreferenz der aufgeteilten Token auf.
  • Beim Empfangen eines Tokens von einer anderen Transaktionseinheit wird der empfangene Token mit dem Token im Tokenspeicher verbunden, wobei dazu eine Registrieranfrage erzeugt wird. Bevorzugt weist die Registrieranfrage eine Tokenreferenz des verbundenen Tokens und jeweils eine Tokenreferenz der zu verbindenden Token auf.
  • Eine Transaktionseinheit kann vorliegend ein sicheres Element sein, das einen gesicherten Zugriff auf Token in einem Tokenspeicher hat. Das sichere Element ist beispielsweise betriebsbereit in einem Endgerät eingebracht. Das sichere Element und oder das Endgerät haben ein spezielles Computerprogrammprodukt (elektronische Geldbörse, Wallet), insbesondere in Form einer abgesicherten Laufzeitumgebung innerhalb eines Betriebssystems eines Endgeräts, englisch Trusted Execution Environments, TEE, gespeichert auf einem Datenspeicher, beispielsweise eines mobilen Endgeräts, einer Maschine, vorzugsweise Bankautomat. Alternativ ist das sichere Element beispielsweise als spezielle Hardware, insbesondere in Form eines gesicherten Hardware-Plattform-Moduls, englisch Trusted Platform Module, TPM oder als ein eingebettetes Sicherheitsmodul, eUICC, eSIM, ausgebildet. Das sichere Element stellt eine vertrauenswürdige Umgebung bereit.
  • Die Kommunikation zwischen zwei Transaktionseinheiten zum Austauschen von Token kann drahtlos oder drahtgebunden, oder z.B. auch auf optischem Weg, bevorzugt über QR-Code oder Barcode, erfolgen und kann als ein gesicherter Kanal ausgebildet sein. Der Austausch von Token ist beispielsweise durch kryptografische Schlüssel zusätzlich transportgesichert, beispielsweise einem für einen Token-Austausch ausgehandelten Sitzungsschlüssel oder auf Basis eines Transaktionseinheitenindividuellen Schlüsselpaars.
  • Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
    • 1 zeigt ein Ausführungsbeispiel eines Transaktionssystems gemäß dem Stand der Technik;
    • 2a zeigt eine Registrierungsanfrage gemäß dem Stand der Technik;
    • 2b zeigt eine Registrierungsprozedur für eine Registrierungsanfrage gemäß 2a gemäß dem Stand der Technik;
    • 3a zeigt ein erstes Ausführungsbeispiel einer Gültigkeitsanfrage gemäß der Erfindung;
    • 3b zeigt ein erstes Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens anhand einer Gültigkeitsanfrage gemäß 3a gemäß der Erfindung;
    • 3c zeigt ein zweites Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens anhand einer Gültigkeitsanfrage gemäß 3a gemäß der Erfindung;
    • 4a zeigt ein zweites Ausführungsbeispiel einer Gültigkeitsanfrage gemäß der Erfindung;
    • 4b zeigt ein erstes Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens anhand einer Gültigkeitsanfrage gemäß 4a gemäß der Erfindung;
    • 4c zeigt ein zweites Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens anhand einer Gültigkeitsanfrage gemäß 4a gemäß der Erfindung;
    • 5a zeigt ein drittes Ausführungsbeispiel einer Gültigkeitsanfrage gemäß der Erfindung;
    • 5b zeigt ein erstes Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens anhand einer Gültigkeitsanfrage gemäß 5a gemäß der Erfindung;
    • 5c zeigt ein zweites Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens anhand einer Gültigkeitsanfrage gemäß 5a gemäß der Erfindung;
    • 6 zeigt ein weiteres Ausführungsbeispiel eines Transaktionssystems mit einem Tokenreferenz-Register gemäß der Erfindung;
  • 1 zeigt ein Ausführungsbeispiel eines Transaktionssystems TS gemäß dem Stand der Technik. Das Transaktionssystem TS umfasst eine Registerschicht TRR-Schicht, in der ein Tokenreferenz-Register TRR angeordnet ist. Das TS umfasst zudem eine Direkttransaktionsschicht TE-Schicht, in der eine Vielzahl von Transaktionseinheiten (oder Teilnehmereinheiten) TE vorgesehen sein können, stellvertretend sind zwei Transaktionseinheiten TE1, TE2 gezeigt. Die Transaktionseinheiten TE1, TE2 sind bevorzugt sichere Elemente.
  • Die Transaktionseinheiten TE des Transaktionssystem TS sind eingerichtet, Token T direkt untereinander auszutauschen. Im Fall von 1 sind die Token Bezahl-Token, die auch als digitale Münze bezeichnet werden. Jeder Token T wird von einem Tokenherausgeber TH generiert (in 1 nicht gezeigt). Jeder Token T kann von jeder Transaktionseinheit TE modifiziert, also aufgeteilt, verbunden oder umgeschaltet werden und kann von dem Tokenherausgeber TH generiert und auch gelöscht werden. Ein Tokenherausgeber TH ist beispielsweise eine Zentralbank.
  • Ein Token T wird durch einen Tokenwert v und eine Zufallszahl r als Tokenelemente eindeutig im Transaktionssystem TS repräsentiert. Der Tokenwert v kann in einem Wertebereich von 1 bis 231-1 angegeben werden. Die Zufallszahl r kann eine Zahl im Bereich von 0 bis 2256 -1, also die Ordnung einer elliptischen Kurve, beispielsweise secp256r1, sein.
  • Die Zufallszahl r ist dabei ein privater Teil eines tokenindividuellen Schlüsselpaars. Die Zufallszahl r ist im Transaktionssystem TS einmalig und geheim und darf nicht veröffentlicht oder wiederverwendet werden. Die Erzeugung der Zufallszahl r darf nichtvorhersehbar sein.
  • Beispielsweise ist der Tokenwert v ein 32 Bit großes Tokenelement vom Typ integer. Beispielsweise ist die Zufallszahl r ein 32 Byte großes Tokenelement vom Typ integer. Eine Transaktionseinheit TE hat exklusiven Zugriff auf diesen Tokenspeicher oder umfasst diesen Tokenspeicher in einem Datenspeicher der Transaktionseinheit TE.
  • Für jeden Token T kann im Tokenreferenz-Register TRR eine Tokenreferenz TR gespeichert werden. Die Tokenreferenz TR umfasst den Tokenwert v des zugeordneten Tokens T und einen öffentlichen Teil R des tokenindividuellen Schlüsselpaars. Damit ist der Tokenwert v eines Tokens T in dem Tokenreferenz-Register TRR bekannt.
  • Der öffentliche Teil R des tokenindividuellen Schlüsselpaars wird durch Anwenden einer kryptografischen Funktion auf den privaten Teil r des tokenindividuellen Schlüsselpaars erzeugt. Diese Funktion ist schwer umkehrbar und gibt dem Transaktionssystem TS so die gebotene Sicherheit. Es gilt R = r * G, wobei G beispielsweise ein globaler Parameter des Transaktionssystems TS, bspw. ein Generatorpunkt einer elliptischen Kurve, hier der secp256r1-Kurve, sein kann.
  • Die Tokenreferenz TR wird dann gebildet durch den Tokenwert v des Tokens und den öffentlichen Teil R des Schlüsselpaars. Die Tokenreferenz TR ist somit die Verkettung von Tokenwert v und öffentlichem Teil R.
  • Eine Tokenreferenz TR kann zusammen mit einer Modifikationsangabe (siehe Übersicht in 6a und 6b) als Registrieranfrage RA bezüglich des Tokens T an das Tokenreferenz-Register TRR gesendet werden. Der modifizierte Token T wird mit seiner Tokenreferenz im Tokenreferenz-Register TRR registriert. In 1 erzeugt die Transaktionseinheit TE1 einen neuen Token TA, dessen Tokenreferenz TRA anstelle der Tokenreferenz TRE des alten Tokens TE mit gleichem Tokenwert v im Tokenreferenz-Register TRR gespeichert werden soll. Die Registrieranfrage kann die Transaktionseinheit TE1 und/oder - nach Übertragung des Tokens TA mitsamt seiner Modifikationsangabe zur Transaktionseinheit TE2 - die Transaktionseinheit TE2 senden.
  • In 1 ist zunächst ein bekanntes Tokenreferenz-Register TRR dargestellt.
  • Das Tokenreferenz-Register TRR verwaltet insbesondere den Speicherort für die Tokenreferenzen TR, der optional auch die bisherigen Registrieranfragen RA speichern kann, hier als Datenbank 1 als Beispiel einer Speichereinheit im Tokenreferenz-Register TRR dargestellt. Stellvertretend ist in der Datenbank 1 die Tokenreferenz TR zum Token T der Transaktionseinheit TE1 eingetragen. Diese Datenbank 1 kann aus einem Zusammenschluss vieler Datenbanken bestehen (siehe auch 6), die untereinander vernetzt sind.
  • Zudem umfasst das Tokenreferenz-Register TRR zumindest eine Verifiziereinheit 2. Die Verifiziereinheit 2 des Tokenreferenz-Registers TRR verifiziert Registrieranfragen RA. Dabei kann eine syntaktische Korrektheit oder auch die korrekte Angabe eines Kommandos in der Registrieranfrage RA verifiziert werden. Auch die Historie aus alten (vergangenen) Registrieranfragen RA kann geprüft werden. Die Trennung dieser Verifiziereinheit 2 von der Datenbank 1 verteilt die Aufgaben von Ablegen und Prüfen und erhöht die Geschwindigkeit im Tokenreferenz-Register TRR.
  • In 1 angedeutet ist ebenfalls bereits, dass das Tokenreferenz-Register TRR von Transaktionseinheiten TE Registrierungsanfragen RA empfängt 11 und gegebenenfalls eine Registrierungsbestätigung RB an die Transaktionseinheit sendet 18.
  • In 2a ist ein Beispiel für eine Registrierungsanfrage RA gemäß dem Stand der Technik dargestellt. Die Registrierungsanfrage der 2a umfasst zwei Eingangstokenreferenzen TRE, eine Ausgangstokenreferenz TRA und ein Modifikationskommando KO.
  • Zusätzlich kann die Registrierungsanfrage RA mit dem privaten Teil r des tokenindividuellen Schlüsselpaars signiert werden (nicht dargestellt). Das Signieren ermöglicht es, zu verifizieren, ob der Sender der Tokenreferenz TRE im Besitz des Eingangstokens TE war, wodurch die Sicherheit im Transaktionssystem TS weiter erhöht ist.
  • In 2b ist ein Verfahrensablauf zur Registrierung eines Tokens gemäß dem Stand der Technik dargestellt. Im Schritt 11 wird die RA im TRR empfangen. Im Schritt 12 wird geprüft, ob eine Eingangstokenreferenz TRE11 der RA im TRR gespeichert ist. Im Nein-Fall des Schritts 12 wird in Schritt 16 noch geprüft, ob die Registrieranfrage RA bereits ausgeführt wurde und als Teil der Historie der Registrieranfragen in der Speichereinheit 1 gespeichert ist. Im JA-Fall wird die Registrierung (erneut) bestätigt 18. Im Nein-Fall von Schritt 16 wird gemäß Schritt 19 die RA nicht bestätigt (Fehlermeldung).
  • Im Ja-Fall von Schritt 12 wird Schritt 13 ausgeführt. Im Schritt 13 wird geprüft, ob eine Eingangstokenreferenz TRE12 von RA im TRR gespeichert ist.
  • Im Ja-Fall von Schritt 13 wird Schritt 14 ausgeführt. Im Schritt 14 wird geprüft, ob das Kommando mit den Eingangstokenreferenzen TRE12 und TRE11 zu der Ausgangstokenreferenz TRA11 der RA führt, also beispielsweise vE11 + vE12 = vA11 ist und die Signaturen gültig sind. In Schritt 14 wird sinngemäß das Kommando auf Fehler geprüft.
  • Im Nein-Fall von Schritt 13 oder im Ja-Fall von Schritt 14 wird gemäß Schritt 19 die RA nicht bestätigt (Fehlermeldung). Im Nein-Fall von Schritt 14 werden in Schritt 15 die TRA11 von RA und die RA im TRR abgespeichert. Der Transaktionseinheit wird bestätigt, dass die Registrierung erfolgt ist mit Schritt 18.
  • Das Tokenreferenz-Register TRR ist für die Transaktionseinheiten TE1, TE2 vorzugsweise nicht auslesbar. Wenig praxisrelevant aber theoretisch bekannt ist es, dass eine Transaktionseinheit den Status eines Tokens abfragen kann, also abfragen kann, mit welchem Status eine Tokenreferenz TR im Tokenreferenz-Register TRR gespeichert ist. Eine solche Statusabfrage, ist aber keine Gültigkeitsanfrage im vorliegenden Sinne, wie sie nun näher beschrieben wird.
  • Eine Transaktionseinheit TE1, TE2 kann eine oder mehrere vorhandene Modifikationsangaben MA, die jeweils einen (oder mehrere) Ausgangstoken über ein Kommando mit einem (oder mehreren) Eingangstoken verknüpft, als Gültigkeitsanfrage an das Tokenreferenz-Register senden. Insbesondere für Sicherheitselemente als Transaktionseinheit ist die dadurch erzielbare Entlastung seiner begrenzten Ressourcen hilfreich. Gerade in Sicherheitselementen können mehrere Modifikationsangaben für unterschiedliche Token (Stapel von Modifikationsangaben) und/oder für einen Token (Folge von Modifikationsangaben) vorliegen.
  • Die Transaktionseinheit TE1, TE2 sendet die Modifikationsangabe(n) in einer Gültigkeitsanfrage für mindestens eine Tokenreferenz und empfängt eine Gültigkeitsbestätigung des Tokenreferenz-Register TRR für die mindestens eine angefragte Tokenreferenz. Die Gültigkeitsanfrage umfasst mehrere Ausgangs-Tokenreferenzen Das Tokenreferenz-Register TRR kann in der Gültigkeitsbestätigung eine Signatur für jede angeforderte Tokenreferenz bereitstellen.
  • Das in 1 gezeigte Tokenreferenz-Register TRR ist nunmehr auch dazu eingerichtet, Gültigkeitsanfragen GA zu verifizieren. Dazu ist beispielsweise die Verifiziereinheit 2 des TRR vorgesehen. Die Verifiziereinheit 2 des Tokenreferenz-Registers TRR verifiziert dann Registrieranfragen RA und/oder Gültigkeitsanfragen GA.
  • Auch eine Historie aus alten (vergangenen) Gültigkeitsanfragen GA bezüglich eines Tokens T kann dabei verifiziert werden. Für die Bearbeitung von Gültigkeitsanfragen GA wird die Historie jedoch nicht benötigt. Die Speichereinheit 1 des TRR kann insofern vorteilhafterweise nur die gültigen Tokenreferenzen TR enthalten. Eine Historie von ehemals gültigen Tokenreferenzen TR und/oder bereits ausgeführten Modifikationsangaben kann in einer separaten Einheit, einer Archiveinheit, bereitgestellt werden. Im Folgenden wird teilweise verkürzt gesagt, dass geprüft wird, ob eine Tokenreferenz im TRR gespeichert ist, es wird dabei jedoch jeweils geprüft ob die Tokenreferenz als gültige Tokenreferenz gespeichert ist bzw. unter der Annahme dass die Speichereinheit 1 nur die gültigen Tokenreferenzen enthält, ob sie in der Speichereinheit 1 gespeichert ist.
  • 3a zeigt ein erstes Ausführungsbeispiel einer Gültigkeitsanfrage GA gemäß der Erfindung. Die GA der 3a umfasst eine (einzige) Modifikationsangabe MA. Diese MA umfasst Eingangstokenreferenzen TRE11, TRE12 und Ausgangstokenreferenzen TRA11 TRA12 und ein Modifikationskommando KO. Die Anzahl von Ausgangstokenreferenzen TRA und die Anzahl von Eingangstokenreferenzen TRE in der Modifikationsanfrage MA ist nicht einschränkend, es können mehr sein (angedeutet durch die Punkte) oder auch weniger. Beispiele für die Anzahl von Eingangs- und Ausgangstokenreferenzen TR pro spezifischem Modifikationskommando KO werden später gegeben.
  • Die Modifikationsangabe MA kann optional eine oder mehrere Signaturen 32 umfassen. Neben den Detaildaten 31 der Modifikation umfasst die Modifikationsangabe MA eine Signatur der Modifikationsangabe. Eine Signatur 32 wird vorzugsweise mit dem privaten Teil r einer Eingangstokenreferenz erstellt, insbesondere kann für jede Eingangstokenreferenz TRE11, TRE12 der Modifikationsanfrage MA eine Signatur 32 mit dem zugehörigen privaten Teil rE11, rE12 vorliegen.
  • Die Gültigkeitsanfrage GA kann optional eine Prüfungsangabe 33 umfassen. Die Prüfungsangabe gibt die ein oder mehreren auf Gültigkeit zu prüfende Ausgangstokenreferenz(en) an. Im gezeigten Beispiel ist also die Gültigkeit der Ausgangstokenreferenz TRA12 zu prüfen. Für eine Gültigkeitsanfrage GA ohne explizite Prüfungsangabe 33 können beispielsweise alle Ausgangstokenreferenzen auf Gültigkeit geprüft werden. Die MA der GA umfasst mindestens eine auf Gültigkeit zu prüfende Ausgangstokenreferenz TRA12 und vorzugsweise eine (oder mehrere) nicht auf Gültigkeit zu prüfende Ausgangstokenreferenz(en) TRA11.
  • In 3b ist ein erstes Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens T anhand einer Gültigkeitsanfrage GA, beispielsweise gemäß 3a, gemäß der Erfindung gezeigt. Im Schritt 101 empfängt das TRR die GA und prüft optional die MA der GA in weiteren Schritten 103-105.
  • Im Schritt 102 prüft das TRR, ob die TRA12 der MA als gültige Tokenreferenz im TRR (insbesondere in dessen Speichereinheit 1) abgespeichert ist. TRA12 ist die in der Prüfungsangabe 33 der GA enthaltene Ausgangstokenreferenz. Im Ja-Fall des Schritts 102 im Schritt 108 eine Gültigkeitsbestätigung GB als Antwort auf die GA an die TE gesendet. Die MA der GA wird dagegen nicht weiter geprüft. Es existiert bereits eine Ausgangstokenreferenz der MA im TRR. Das TRR muss die MA bereits in der Vergangenheit ausgeführt haben.
  • Optional wird in einem Schritt 106 zumindest eine Signatur des TRR erstellt, insbesondere eine Signatur des TRR für die gültige(n) Ausgangstokenreferenz(en) TRA12. Die Gültigkeitsbestätigung GB kann die Signatur des TRR für die gültige(n) Ausgangstokenreferenz(en) enthalten bzw. durch diese gebildet sein.
  • Im Nein-Fall des Schritts 102 prüft (verifziert) das TRR die MA 103, 104 und führt sie gegebenfalls aus 105. Im Schritt 103 prüft das TRR, ob jede Eingangstokenreferenz TRE11 und TRE12 der MA im TRR abgespeichert ist. Wenn die Eingangstokenreferenzen TRE11 und TRE12 der MA im TRR gespeichert sind (Ja-Fall), prüft das TRR die MA auf Fehler 104. Geprüft wird beispielsweise die Syntax der MA, also insbesondere das Kommando KO (z.B.: unbekannter KO-Typ oder KO-Typ des TH) und/oder die Anzahl der Eingangs- und Ausgangstokenreferenzen (z.B.: keine oder zu wenige Ausgangstokenreferenzen/ Eingangstokenreferenzen). Geprüft wird die Wertneutraltiät der Tokenreferenzwerte (Summe Eingangswert(e) = Summe Ausgangswert(e)) und/oder die Signatur(en) 32 der MA.
  • Ist die Verifikation 103, 104 der MA nicht erfolgreich, wird eine Ungültigkeitsbestätigung UGB für die GA gesendet 109. Abweichend von einer Behandlung der MA als Registrieranfrage wird also nicht mehr anhand der Historie geprüft, ob die MA bereits ausgeführt wurde. Sowohl im Nein-Fall von Schritt 103 als auch im Fall eines Fehlers in der MA (Ja-Fall von Schritt 104) erfolgt das Senden der UGB in Schritt 109.
  • Ist die Verifikation 103, 104 der MA erfolgreich, führt das TRR die MA aus 105 und sendet die Gültigkeitsbestätigung GB für die GA in Schritt 108. In Schritt 105 löscht das TRR die Eingangstokenreferenz(en) TRE11 und TRE12 und speichert die Ausgangstokenreferenz(en) TRA11 und TRA12 der MA im TRR, bzw. in der Speichereinheit 1 des TRR. Der Schritt 106 wird wiederum optional vor dem Schritt 108 ausgeführt, im vorliegenden Beispiel also nur TRA12 signiert und die Signatur für TRA12 in der GB für die GA des TRR der Transaktionseinheit TE bereitgestellt.
  • Mit dem Verfahren nach 3b wird zunächst geprüft, ob die (angegebene(n)) TRA der GA im als gültige TR im TRR gespeichert ist (sind) und nur, wenn die TRA im TRR nicht gültig sind, werden TRE und KO geprüft (also die MA verifiziert). Dies verringert den Aufwand der Gültigkeitsprüfung. Zudem erfolgt für die MA auch keine Prüfung einer Historie mehr, da die MA in einer Gültigkeitsanfrage GA empfangen wurde.
  • In 3c ist ein zweites Ausführungsbeispiel eines Verfahrensablaufs zum Prüfen der Gültigkeit eines Tokens T anhand einer Gültigkeitsanfrage GA gemäß 3a gemäß der Erfindung gezeigt.
  • Im Schritt 101 empfängt das TRR die GA und prüft 104 nun zunächst die MA der GA auf Fehler (insbesondere in Syntax, Wertneutralität und/oder Signaturen). In dem Schritt 103 prüft das TRR, falls MA selbst fehlerfrei ist, ob die Eingangstokenreferenz(en) TRE11 und TRE12 der MA im TRR abgespeichert sind. Sind die Eingangstokenreferenzen TRE11 und TRE12 im TRR gespeichert (Ja-Fall), wird die MA der GA ausgeführt 105.
  • Ist dagegen die MA fehlerhaft (Ja-Fall von Schritt 104) oder sind die Eingangstokenreferenz(en) der MA nicht im TRR gespeichert (Nein-Fall von Schritt 103), wird der Schritt 102 ausgeführt. Insbesondere falls die MA nicht verifiziert werden kann, wird in Schritt 102 geprüft, ob die (optional angegebene) Ausgangstokenreferenz TRA12 bzw. die (optional angegebenen) Ausgangstokenreferenzen in der Speichereinheit 1 des TRR gespeichert ist.
  • Im Ja-Fall des Schritts 102 wird in dem Schritt 108 eine Gültigkeitsbestätigung GB als Antwort auf die GA an die TE gesendet. Die (angegebene(n)) Ausgangstokenreferenz (en) ist (sind) bereits im TRR, insbesondere in dessen Speichereinheit 1, gespeichert. Das TRR hat die MA mit dieser TRA bereits in der Vergangenheit ausgeführt. Optional wird zuvor eine Signatur des TRR für die (angegebene(n)) Ausgangstokenreferenz (en), hier also TRA12, erstellt 106. Im Nein-Fall des Schrittes 102 sendet 109 das TRR dagegen eine Ungültigkeitsbestätigung UGB für die (angegebene(n)) Ausgangstokenreferenz (en) der MA.
  • Im Ja-Fall des Schritts 103 führt das TRR im Schritt 105 das Modifikationskommando KO der MA aus und sendet anschließend die Gültigkeitsbestätigung 108. Im TRR werden in Schritt 105 die Eingangstokenreferenzen der MA gelöscht und die Ausgangstokenreferenzen der MA gespeichert.
  • Mit dem Verfahren nach 3c wird zunächst geprüft, ob die MA fehlerhaft und/oder die TRE nicht im TRR gespeichert sind. Andernfalls, also obwohl die MA der GA nicht ausführbar ist, wird geprüft, ob die (angegebene(n)) TRA der GA bereits gespeichert sind.
  • Auch das Verfahren nach 3c verringert den Aufwand der Gültigkeitsprüfung.
  • 4a zeigt ein zweites Ausführungsbeispiel einer Gültigkeitsanfrage GA gemäß der Erfindung. Diese GA umfasst zwei oder mehr Modifikationsanfragen MA (MA1, MA2, ... MAx). Jede MA umfasst (eine oder) mehrere Eingangstokenreferenzen TRE11, TRE12 und (eine oder) mehrere Ausgangstokenreferenzen TRA11 TRA12 und ein Modifikationskommando KO. Die Anzahl von Ausgangstokenreferenzen TRA und die Anzahl von Eingangstokenreferenzen TRE in der Modifikationsanfrage MA ist nicht einschränkend, es können mehr sein oder auch weniger. Beispiele für die typische Anzahl von Eingangs- und Ausgangstokenreferenzen TR pro spezifischem Kommando KO werden später aufgelistet. Hier nicht separat dargestellt sind optionale Signaturen der MA.
  • Die MA der GA werden einzeln verifiziert. Bevorzugt wird die jüngste MA, Max, zuerst verifiziert. Allgemein werden optional MA der GA verifiziert, bis entweder eine GB oder eine UGB für die GA gesendet werden kann. Fallweise können alle MA der GA nacheinander geprüft und ausgeführt werden, bevor eine GB gesendet wird. Eine GB für die GA kann fallweise jedoch bereits auch ohne Prüfung einer einzigen MA gesendet werden (gemäß 4b beispielsweise im Sonderfall: TRAij = TRA1j).
  • Die Modifikationsanfragen MA der GA können als Stapel oder als Folge von Modifikationsanfragen MA vorliegen.
  • Im Falle einer Folge von MA werden die MA im Wesentlichen zeitlich aufeinanderfolgende Modifikationen an Token angeben. Zumindest eine Ausgangstokenreferenz einer MA der Folge wird Eingangstokenreferenz einer anderen MA der Folge sein. Bevorzugt haben zwei oder mehr aufeinander folgende MA, beispielsweise MAx-1 und MAx, der GA eine Eingangstokenreferenz, die Ausgangstokenreferenz einer vorherigen MA der GA ist. Entsprechend sind die Modifikationsanfragen MA der GA in der Reihenfolge MA1... MAx auszuführen, in der sie in der GA vorliegen. MAx ist die jüngste MA und repräsentiert die letzte Modifikation an einem Token.
  • 4a zeigt jedoch als Beispiel einen Stapel von MA in der GA. Die Ein- und Ausgangstokenreferenzen TR der Modifikationsanfragen MA in der GA sind im Wesentlichen unabhängig voneinander (weder TRA11 noch TRA12 entsprechen beispielsweise TRE21 oder TRE12). Gerade für größere Stapel (mit beispielsweise i > 5) und/oder für Stapel mit MA nur einer Transaktionseinheit kann es dennoch vorkommen, dass eine Ausgangstokenreferenz einer MA des Stapels Eingangstokenreferenz einer anderen MA des Stapels ist.
  • Als optionale Prüfungsangabe 43 umfasst die gezeigte Gültigkeitsanfrage 40 eine oder mehrere auf Gültigkeit zu prüfende Ausgangstokenreferenzen TRAij (j-te Ausgangstokenreferenz der i-ten Modifikationsangabe). Die angegebene(n) Ausgangstokenreferenz(en) TRAij kann eine, mehrere oder keine Ausgangstokenreferenz der letzten Modifikationsangabe (MAx) der GA, auch im Falle einer Folge, umfassen. Insbesondere kann die Prüfungsangabe zwei oder mehr Ausgangstokenreferenzen TRAij der GA aus unterschiedlichen MA umfassen, wie TRA21 und TRAx1. Weiterhin kann die die Prüfungsangabe zwei oder mehr Ausgangstokenreferenzen TRAij der GA, vorzugsweise aus unterschiedlichen MA, nicht umfassen, wie TRA11, TRA22 und/oder. TRAx2.
  • In 4b ist ein erstes Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit zumindest eines Tokens T anhand einer Gültigkeitsanfrage GA mit mehreren MA, beispielsweise gemäß 4a, gezeigt. Der Ablauf des Verfahrens der 4b entspricht im Kern dem Verfahren nach 3b (identische Schritte 102, 103, 104, 105, 106) und diesbezüglich wird auf die Ausführungen in 3b verwiesen.
  • Das Verfahren gemäß 4b umfasst eine Schleife 141, 142 für die Modifikationsanfragen MA der GA (mit Schleifenindex i=1 bis x für MAi). Beginnend mit der ersten MA der GA, MA1, wird geprüft 102, ob eine angegebene Ausgangstokenreferenz, TRA1j, bzw. alternativ alle Ausgangstokenreferenzen der MA, TRA11 und TRA1l, der MA bereits (als gültige TR) gespeichert sind. Gegebenenfalls wird die Modifikationsanfrage MAi ausgeführt 105. In einer nicht dargestellten Variante des Verfahrens könnte in Schritt 109 eine UGB gesendet werden, sobald die aktuelle MA der GA nicht ausführbar ist (Nein-Fall von Schritt 103 oder Ja-Fall von Schritt 104), falls alle TR der GA auf Gültigkeit zu prüfen sind. In dem in 4b gezeigten Beispiel wird dagegen die Schleife 141, 142, inklusive der Schritte 102-106 (und 146), für jede MA, MA1 ... MAx, der GA durchlaufen.
  • Gemäß Schritt 102 bereits zuvor gespeicherte oder in Schritt 105 gespeicherte Ausgangstokenreferenzen TRAij können in der Schleife als - als gültig erkannte oder bereits signierte - TRA der GA zwischengespeichert werden. Optional wird in Schritt 146 zudem zwischengespeichert, dass das oder die angegebenen TRAij der MA1 bzw. der oder die Ausgangstokenreferenzen, TRA1j, der MA1 ungültig sind.
  • Wenn alle angegebenen TRAij gültig sind oder alle Ausgangstokenreferenzen der GA gültig sind, wird eine Gültigkeitsbestätigung GB für die GA, inklusive optionaler Signaturen, gesendet 108. Andernfalls kann eine Ungültigkeitsbestätigung gesendet werden 109. Optional kann eine Teilgültigkeitsbestätigung TGB (erstellt und) gesendet werden 148, sofern nicht alle aber mindestens eine fragliche Ausgangstokenreferenz gültig ist (Schritt 147) . Die Teilgültigkeitsbestätigung TGB umfasst vorzugsweise nur die Signaturen des TRR für die gültigen Ausgangstokenreferenzen der GA bzw. der gültigen auf Gültigkeit zu prüfenden Ausgangstokenreferenzen TRAij.
  • In Schritt 141 wird geprüft ob die aktuelle Modifikationsangabe MAi die letzte Modifikationsangabe der GA ist (also ob I == X ist). Alternativ oder ergänzend kann geprüft werden, ob alle angegebenen TRAij bereits als gültig und/oder ungültig erkannt wurden. Im Nein-Fall des Schritts 141 wird die nächste MA der GA verifiziert, angedeutet durch den Schritt 142, der den Laufindex „i“ inkrementiert (der Index i ist bei Start im Schritt 101: i = 1). Sodann wird in erneuten Schritten 102-106, 146 die nächste MA geprüft. Ist ein Abbruchkriterium der Schleife erkannt (Ja-Fall von 141), wird fallabhängig (Schritt 107, 147) an die TE die Gültigkeitsbestätigung GB für die GA gesandt oder die Ungültigkeitsbestätigung UGB für die GA gesandt (oder optional eine Teilgültigkeitsbestätigung für die GA gesandt).
  • In 4c ist ein weiteres Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens T anhand einer Gültigkeitsanfrage GA mit mehreren MA, insbesondere gemäß 4a, gezeigt. Der Ablauf des Verfahrens der 4c entspricht im Kern dem Verfahren nach 3c (identische Schritte bzw. Schrittfolge 104, 103, 102, 105, 106) und diesbezüglich wird auf die Ausführungen in 3c verwiesen.
  • Auch das Verfahren gemäß 4c umfasst eine Schleife 141, 142 mit einem Abbruchkriterium (alle angegebenen TRAij auf Gültigkeit geprüft oder alle MA durchlaufen), welche bis zum Erreichen des Abbruchkriteriums jede MA der GA die Schrittfolge 102-106, 146 durchlaufen lässt. Wie zuvor wird danach fallabhängig die entsprechende Bestätigung GB/UGB/TGB gesandt 108/109/149. Auch in einem Ablauf gemäß 4c können MA der GA ungeprüft bleiben und dennoch eine Gültigkeitstätigung GB für die auf Gültigkeit zu prüfenden TRAij gesendet werden.
  • Mit dem Verfahren gemäß 4b und 4c werden vorzugsweise Stapel von Modifikationsangaben MA geprüft. Die Modifikationsangaben enthalten voneinander unabhängige Tokenreferenzen.
  • 5a zeigt ein drittes Ausführungsbeispiel einer Gültigkeitsanfrage GA gemäß der Erfindung. Die GA umfasst mehrere Modifikationsangaben MA1, MA2, ... MAx. Die Modifikationsangaben der GA sind voneinander abhängig. Die GA umfasst insofern eine Folge von Modifikationsangaben, wie sie teils auch zuvor bereits näher beschrieben wurde.
  • Im gezeigten Beispiel ist die Ausgangstokenreferenz TRA1l > von MA1) eine Eingangstokenreferenz der MA2 sein. Die Ausgangstokenreferenz TRA22 von MA2 könnte eine Eingangstokenreferenz einer anderen MA der GA sein, beispielsweise der MA3, MA4 oder MAx.
  • Die erste Eingangstokenreferenz von MAx ist die Ausgangstokenreferenz TRAx1lder MAx-l. Als die auf Gültigkeit zu prüfenden Ausgangstokenreferenzen TRAij der GA enthält die Prüfungsangabe 53 der GA die Ausgangstokenreferenzen TRA21 und TRAx2. Die optional vorhandenen Signaturen der MA sind wiederum nicht in der Figur dargestellt.
  • 5b zeigt ein erstes Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens T anhand einer Gültigkeitsanfrage GA mit mehreren, vorzugsweise voneinander abhängigen, MA - insbesondere gemäß 5a.
  • Di GA wird empfangen 101 und in Schritt 102 wird geprüft, ob die auf Gültigkeit zu prüfenden Tokenreferenzen TRAij als gültige TR im TRR gespeichert sind, insbesondere also ob sie in der Speichereinheit 1 des TRR, die nur die gültigen TR enthält, vorliegen. Wenn die angegeben Ausgangstokenreferenzen TRA21 und TRAx2 bereits gespeichert sind, kann - optional nach Erstellung der Signaturen 106 als kryptographische Bestätigung des TRR für die gültigen TR - die Gültigkeitsbestätigung GB gesendet werden 108. In diesem Fall wird keine der MA der GA (auf Fehler und/oder Ausführbarkeit) geprüft.
  • In einer Schleife 153a -c werden die x Modifikationsangaben MA der Folge nacheinander geprüft 103, 104. Für die jeweilige MAi wird in Schritt 103 geprüft, ob die Eingangstokenreferenz(en) TREi1 und TREi2 in der Speichereinheit 1 des TRR gespeichert sind, also gültig sind. Im Nein-Fall wird eine Ungültigkeitsbestätigung UGB gesendet 109. Ebenso in dem (Ja-)Fall von Schritt 104, dass eine Prüfung der MAi einen Fehler (wie zuvor: Syntax, Wertneutralität, ...) ergibt.
  • Im Nein-Fall von Schritt 104 wird - da das Verfahren auf eine Folge ausgerichtet ist, deren Tokenreferenzen vorneinander abhängen - die MA jedoch noch nicht tatsächlich ausgeführt. Es erfolgt noch kein Speichern der Ausgangstokenreferenzen TRA der MAi. Ein Löschen der Eingangstokenreferenzen TRE der MA; in der Schleife wäre denkbar, erfolgt aber bevorzugt auch erst in Schritt 155. Die Verifikationseinheit 2 speichert die zu speichernden Ausgangstokenreferenzen TRA der MAi (und die zu löschenden Eingangstokenreferenzen TRE der MA;) nur zwischen. Mehrere dieser zwischengespeicherten Ausgangstokenreferenzen werden Eingangstokenreferenz einer weiteren MA der GA sein (wären damit also wieder zu löschen). Nun werden sie einfach aus dem Zwischenspeicher der Verifikationseinheit entfernt. Ein unnötiger schreibender Zugriff (bzw. mehrere unnötige schreibende oder löschende Zugriffe) auf die Speichereinheit 1 kann (können) somit vermieden werden. Erst in Schritt 155 werden die zwischengespeicherten (und nicht wieder dort gelöschten) Ausgangstokenreferenzen in die Speichereinheit geschrieben. Der Schritt 155 kann auch als selektives Speichern der Gesamt-Ausgangstokenreferenzen der Folge bezeichnet werden. Im Beispiel der 5b werden die Ausgangstokenreferenzen TRA21 TRAx1 TRAX2 gespeichert und die Eingangstokenreferenzen TRE11 TRE12 TRE21 gelöscht. Danach kann die Gültigkeitsbestätigung für die Ausgangstokenrefenzen TRA21, TRAx2 gesendet werden.
  • 5b zeigt mit den Schritten 151, 152 optionale Schritte die verhindern würden, dass bereits ausgeführte Modifikationsangaben MA in der Folge von MA der GA fälschlich zu einer Ungültigkeitsbestätigung UGB führt. Wenn in Schritt 102 bzw. 151 festgestellt wird, dass ein TRAnj bereits gespeichert ist, wird in Schritt 152 diese TR signiert und der Index der Schleife auf i= n+1 gesetzt. Die Modifikationsangabe MAn wurde bereits ausgeführt. Die Bearbeitung der Folge von Modifikationsangaben kann also mit der in der Folge nachfolgenden Modifikationsangabe MAn+1 begonnen werden. In nicht dargestellten Ausgestaltungen kann die Folge der MA ausgewertet werden, um Nebenäste der Folge zu erkennen und als solche in der Bearbeitung der Folge zu berücksichtigen.
  • In 5c ist ein weiteres Ausführungsbeispiel eines Verfahrens zum Prüfen der Gültigkeit eines Tokens T anhand einer Gültigkeitsanfrage GA mit mehreren MA, insbesondere gemäß 5a bzw. einer GA mit einer Folge von MA, gezeigt.
  • Für die in Schritt 101 empfangene GA werden zunächst in Schritt 164a alle Modifikationsangaben MA1 bis MAx der GA auf Fehler geprüft. Enthalten die MA einen Fehler (Nein-Fall von Schritt 164b), wird geprüft, ob die angegebenen Ausgangstokenreferenzen TRAij der GA alle bereits gespeichert sind 102. Fallabhängig wird entsprechend die UGB gesendet 109 oder - nach optionaler Signierung 106 der TRAij - die Gültigkeitsbestätigung GB gesendet 108.
  • Im Ja-Fall von Schritt 164b werden alle TR der GA aus der Speichereinheit 1 gelesen 162 (für alle TR geprüft, ob sie schon gespeichert sind). Sind alle angegebenen Ausgangstokenreferenzen TRAij vorhanden 102, wird wie zuvor die Gültigkeitsbestätigung 108 gesendet. Falls nicht (Nein-Fall von Schritt 162), werden in Schritt 165 selektiv die Gesamt-Ausgangstokenreferenzen der Folge gespeichert und die Eingangstokenreferenzen (soweit noch gespeichert) gelöscht.
  • Auch das Vorgehen gemäß 5c führt zu einer optimierten Bearbeitung der GA mit einer Folge (oder einem Stapel).
  • Nach der Prüfung der GA der 3a bis 5c bzw. der RA gemäß 2a/b sind die geprüften (verifizierten) Tokenreferenzen TR im Tokenreferenz-Register TRR abgelegt, wodurch die Modifikation am Token T im Transaktionssystem TS registriert ist.
  • Die Tokenreferenz TR ist dem Token T eindeutig zugeordnet und dient zur Registrierung des Tokens T im Transaktionssystem TS. Die Tokenreferenz TR ist demnach die öffentliche Repräsentation des Tokens T aus der Direkttransaktionsschicht TE-Schicht. Das alleinige Wissen oder nur der Besitz der Tokenreferenz TR erlaubt es nicht, den Token T zu übertragen und ist nicht gleichbedeutend damit, dass die TE im Besitz des Tokens T ist. Die Tokenreferenz TR dient zur Verhinderung von Mehrfachausgabe-Versuchen. Es wird geprüft, ob Tokenwerte v in unzulässiger Weise generiert wurden. Deshalb wird im Tokenreferenz-Register TRR die Tokenreferenz TR und ggf. die Historie über die Token T und entsprechende Modifikationen durch von Transaktionseinheiten TE gesendete Registrieranfragen RA abgelegt.
  • Die Token T werden beispielsweise in Tokenspeichern bzw. elektronischen Geldbörsen, sogenannten Wallets, einer TE abgelegt. Ein Wallet ist beispielsweise eine Softwareapplikation innerhalb einer Transaktionseinheit TE (insbesondere eines Secure Elements) oder eines Endgeräts, in dem die TE betriebsbereit eingebracht ist. Ein Wallet kann als Applikation auf einem Smartphone, einer Smartcard oder einem Bezahlterminal eingerichtet sein. Das Wallet dient dazu, Token T der TE sicher zu verwalten, Tokenreferenzen TR zu erzeugen, Token T zu modifizieren, Token T auszutauschen und/oder die Prüfung der Gültigkeit von Token anzustoßen. Wallets dienen dazu, mit dem Tokenreferenz-Register TRR zu kommunizieren, Registrieranfragen RA zu Modifikationen des Tokens T an das Tokenreferenz-Register TRR zu generieren, Transaktion von Token T zu einer Transaktionseinheit TE vorzunehmen und/oder Gültigkeitsanfragen GA zu generieren.
  • Für eine Transaktion mit einer Transaktionseinheit TE ist es nicht notwendig, dass eine Kommunikationsverbindung zu dem Tokenreferenz-Register TRR des Transaktionssystems TS besteht. Das Transaktionssystem TS ist dazu eingerichtet, eine Transaktion offline, also ohne Kommunikationsverbindung mit dem Tokenreferenz-Register TRR, durchzuführen. Eine entsprechende Registrierung von Token T kann daher einer Übertragung des Token T zu einer Transaktionseinheit TE zeitlich nachgelagert sein.
  • Das Tokenreferenz-Register TRR ist eine Einheit des Transaktionssystems TS und ist entweder ein zentrales Register oder eine zentrale Datenbank des Transaktionssystems TS oder ein dezentrales Register oder eine dezentrale Datenbank (DLT) des Transaktionssystems TS.
  • Erfindungsgemäß ist vorgesehen, die Gültigkeit eines Tokens T einfach prüfen zu lassen. Dazu wird eine Gültigkeitsanfrage GA von der Transaktionseinheit TE erstellt. Die Gültigkeitsanfrage GA umfasst die Tokenreferenz TR des Tokens T, dessen Gültigkeit geprüft werden soll. Die Gültigkeitsanfrage GA umfasst auch eine Modifikationsangabe zu einer oder mehrerer Modifikationen an dem Token T.
  • Eine Tokenreferenz TR kann zusammen mit einer Modifikationsangabe als Gültigkeitsanfrage GA bezüglich des Tokens T an das Tokenreferenz-Register TRR gesendet werden.
  • Zusätzlich - wie in 1 angedeutet - kann die Gültigkeitsanfrage GA mit dem privaten Teil r des tokenindividuellen Schlüsselpaars signiert werden. Das Signieren ermöglicht es, zu verifizieren, ob der Sender der Tokenreferenz TR im Besitz des Tokens T war, wodurch die Sicherheit im Transaktionssystem TS weiter erhöht ist.
  • Eine Gültigkeitsanfrage GA kann an das Tokenreferenz-Register TRR gesendet werden, um zu prüfen, ob der Token T gültig ist. Im Tokenreferenz-Register TRR wird diese Gültigkeitsanfrage GA empfangen. Nach Prüfung der Gültigkeitsanfrage GA durch das Tokenreferenz-Register TRR (bzw. dessen Verifikationseinheit2) wird der Transaktionseinheit TE mitgeteilt, ob der Token T gültig ist oder nicht.
  • Eine Gültigkeitsanfrage GA ist bevorzugt mit dem privaten Teil r signiert. Durch die Signatur kann eine syntaktische Echtheit des Kommandos durch den Empfänger (TRR oder TE) einfach geprüft werden. Diese Prüfung erfolgt bevorzugt in der Datenbank 1 oder der Verifizier-Einheit 2. Zudem kann eine Gültigkeitsanfrage GA beispielsweise syntaktisch validiert werden durch Prüfen der Signatur und/oder der Tokenreferenz TR.
  • Auch wenn eine Signatur in einer Transaktionseinheit TE geprüft werden kann, so wird damit nicht sichergestellt, dass keine Mehrfachausgabe des gleichen Tokens T versucht wurde. Daher ist das Registrieren im Tokenreferenz-Register TRR vorgesehen. Zudem wird durch die Transaktionseinheiten TE eine sichere Hardwareplattform vorgehalten. Mit verfügbarer Verbindung zum Tokenreferenz-Register TRR werden die Tokenreferenzen TR übertragen und im Tokenreferenz-Register TRR kann der Mehrfachausgabe-Versuch entdeckt werden.
  • Wenn eine Tokenreferenz TR im Tokenreferenz-Register TRR noch nicht bekannt ist, wird sie hinzugefügt (gespeichert).
  • In dem Tokenreferenz-Register TRR kann zudem auch eine Archivierungseinheit vorgehalten sein (nicht dargestellt in 1). In dieser Archivierungseinheit werden Registrieranfragen RA und/oder Gültigkeitsanfragen und/oder nicht mehr gültige Tokenreferenzen abgespeichert.
  • Als Kommandos KO können beispielsweise folgende Modifikationen an einem vorhandenen Token T vorliegen: beispielsweise „Umschalten (=Switch)“, „Aufteilen (=Split)“ oder „Verbinden (=Merge)“. Kommandos KO, die dem Tokenherausgeber vorbehalten sind, können auch das Erzeugen (=Create) eines Tokens T oder das Löschen (Destroy) eines vorhandenen Token T betreffen. In der Theorie war ferner auch ein anderer Kommandotyp zum Prüfen der Gültigkeit eines unmodifizierten Tokens T in dem TRR bekannt. In der folgenden Tabelle sind beispielhaft Kommandocodierungen angegeben (0x01 bis 0x05). Die hier gezeigte Codierung und auch die in den Figuren verwendete Reihenfolge der Datenelemente in der MA ist austauschbar bzw. nur beispielhaft.
    Kommando KO Beschreibung Kommandocode
    ERZEUGEN Erzeugen eines neuen T im TS 0x01
    LÖSCHEN Löschen eines vorhandenen T im TS 0x02
    UMSCHALTEN Ersetze in einem vorhandenen T ein r mit einem neuen r 0x03
    AUFTEILEN Teile einen (oder mehrere) vorhandenen T in zwei (oder mehr) kleinere T 0x04
    VERBINDEN Verbinde zwei (oder mehr) vorhandene T in einen (oder mehrere) T 0x05
  • In der folgenden Tabelle sind Beispiele für eine denkbare Signatursyntax angegeben. Dabei werden pro Kommando Eingangs-Token T und Eingangstokenreferenzen TR angegeben („verbraucht“). Dabei werden pro Kommando Ausgangs-Token T und Ausgangstokenreferenzen TR angegeben („generiert“).
    Kommando Signatursyntax
    ERZEUGEN RAsig_TH = sig (pKeyTH, [CREATE, TR])
    LÖSCHEN RAsig_TH = sig (pKeyTH, [DESTROY, TR])
    RAsig_T = sig (r, [DESTROY, TR])
    UMSCHALTEN RAsig_Ta = sig (ra, [SWITCH, TR, Rb])
    AUFTEILEN RAsig_Ta = sig (ra, [SPLIT, TRa TRb TRc])
    VERBINDEN RAsig_Ta = sig (ra, [MERGE, TRa TRb TRc])
    RAsig_Tb = sig (rb, [MERGE, TRaTRbTRc])
  • Eine Modifikationsangabe (beispielsweise einer Registrierungsanfrage RA oder einer Gültigkeitsanfrage GA) hat die grundlegende Struktur aus den folgenden drei Elementen: Kommandotyp, Eingangstokenreferenz(en), Ausgangstokenreferenz(en).
  • Jedes Kommando KO hat eine teilweise charakteristische Anzahl (eine oder mehrere) von Eingangs-Tokenreferenz(en) („Eingänge“) und Ausgangs-Tokenreferenz(en) („Ausgänge“). Ein Umschalten beispielsweise hat vorzugsweise genau eine Eingangs-Tokenreferenz und genau eine Ausgangstokenreferenz. Ein Aufteilen hat genau einen (oder mehrere) Eingangs-Tokenreferenz und zumindest zwei (oder mehr) Ausgangstokenreferenz. Ein Verbinden hat zumindest zwei (oder mehr) Eingangs-Tokenreferenzen und genau eine (oder mehrere) Ausgangstokenreferenz(en).
  • In 6 ist eine weitere Ausgestaltung eines Tokenreferenz-Registers TRR eines Transaktionssystems TS gezeigt. Hierbei ist angedeutet, dass mehrere Speichereinheiten 1 im Tokenreferenz-Register TRR vorgehalten sein können, um ein Abspeichern einer
  • In 6 ist eine weitere Ausgestaltung eines Tokenreferenz-Registers TRR eines Transaktionssystems TS gezeigt. Hierbei ist angedeutet, dass mehrere Speichereinheiten 1 im Tokenreferenz-Register TRR vorgehalten sein können, um ein Abspeichern einer Vielzahl von Tokenreferenzen TR zu beschleunigen. Hierbei ist zudem angedeutet, dass mehrere Verifiziereinheiten 2 im Tokenreferenz-Register TRR vorgehalten sein können, um eine Verifizierung von Gültigkeitsanfragen GA und/oder Registrieranfragen RA zu beschleunigen.
  • Zudem ist eine Transaktionseinheit einer Bank TEB dargestellt, die als Schnittstelle zwischen dem Transaktionssystem TS und einem Buchgeldsystem (Kreditvergabe, Kontenmanagement) dienen kann. Es kann Transaktionseinheiten TE ermöglichen, Token T des Transaktionssystems TS in ein anderes Transaktionssystem TS zu überführen. Diese Überführung ist bidirektional möglich. Der Tokenherausgeber TH, ist für die Generierung von Token T und auch das Löschen von Token T im TS allein verantwortlich.
  • Zudem zeigt 6 eine Registrierungsanfrage-Einheit RAE, die von einer Transaktionseinheit TE1 eine Gültigkeitsanfrage GA (und/oder RA) erhalten kann und die GA (und/oder RA) an das TRR weiterleitet.
  • Das TRR enthält ferner eine Archiveinheit 5, in welcher bereits ausgeführte RA und/oder GA und/oder nicht mehr gültige Tokenreferenzen, insbesondere als verketteter Graph, gespeichert sind.
  • Transaktionseinheiten TE können ihre RA und/oder GA über eine erste Schnittstelle 3 des TRR an das TRR senden. Nur der Tokenherausgeber TH darf dagegen über die zweite Schnittstelle 4 des TRR Kommandos an das TRR senden.
  • Es kann von Vorteil sein, wenn pro Transaktionseinheit TE (hier als ein sicheres Element, bspw. Smart Card oder TEE) nur ein (oder wenige) Token T verwendet wird. Das bedeutet, dass das TE einen erhaltenen Token T mit dem im Tokenspeicher abgelegten Token T verbindet (MERGE). Das bedeutet auch, dass das TE einen zu versendenden Token T von dem im Tokenspeicher abgelegten Token T abteilt (SPLIT). Diese Modifikationen am Token T können ohne Registrieranfrage RA oder Gültigkeitsanfrage GA durchgeführt werden und der Token T kann nach einer Modifikation sofort weitergegeben werden. Es kann also zu einer Folge von Modifikationen am Token T kommen, die dem TRR nicht bekannt sind. Typischerweise besteht die Folge von Modifikationsangaben MA aus einer Kombination von SPLIT und MERGE Modifikationen. Jede dieser Modifikationen wird auch als „Proof“ (siehe oben zur 1) bezeichnet bzw. als, vorzugsweise signierte, Modifikationsangabe MA mit dem Token T abgespeichert. Damit entsteht in der TE1 zu dem Token T die Folge von Modifikationsangaben MAF bzw. MA1, MA2,... MAx.
  • Erfindungsgemäß ist nun eine Gültigkeitsanfrage GA vorgesehen, um einen Token auf Gültigkeit zu prüfen.
  • Das Endgerät erhält dazu die GA und/oder die MA bzw. MAF. Alternativ oder zusätzlich kann zwischen dem TE und dem TRR auch eine Registrieranfrage-Einheit RAE als Vermittlungsinstanz vorgesehen sein, siehe 6. Die RAE erhält sodann die GA und/oder die MA bzw. MAF vom TE oder dem Endgerät. An das TRR wird eine GA gesendet.
  • Das Endgerät (nicht gezeigt in 6) oder die RAE versucht, die GA an das TRR zu übermitteln. Das bedeutet, dass das Endgerät oder die RAE nur eine Protokollübersetzung, beispielsweise von APDU zwischen Endgerät/RAE und TE zu HTTP(S), vornimmt. GA und/oder die MA bzw. MAF werden weder vom Endgerät noch von der RAE ausgewertet oder interpretiert. Die Reihenfolge der Modifikationsangaben in einer GA einer Folge MAF wird durch das Endgerät oder die RAE nicht verändert. Eine Gültigkeitsbestätigung GB (oder eine Registrierbestätigung RB) des TRR wird dann vom Endgerät und/oder der RAE an das TE übertragen. Jede GA und/oder die MA bzw. MAF kann mit dem privaten Teil r (der Zufallszahl r) des relevanten tokenindividuellen Schlüsselpaars signiert sein. Daher werden die Modifikationsangaben MA, die in der TE (im Tokenspeicher) abgelegt sind, teils auch als Proof bezeichnet.
  • Die Verifiziereinheit 2 des TRR prüft die Gültigkeit, insbesondere mit einem Verfahren nach 3b bis 5c. Eine GB wird an das sichere Element bzw. die TE (ggf. über die RAE oder das Endgerät) zurückgesendet.
  • Angenommen, eine TE1 hat beispielsweise folgende Modifikationssequenz an einem Token A durchgeführt:
    Split: A → B, C (Token A wird in Token B und C aufgeteilt)
    Switch: C → D (Token C wurde auf Token D umgeschaltet)
  • Der Token D wird mit den beiden Modifikationen (Proofs) „Split“ und „Switch“ an TE2 übertragen. TE2 führt zudem durch:
    Merge: D, E → F (Token D und E werden zum Token F verbunden)
  • Gültigkeitsprüfung des Token F: Es soll nur der Token F auf Gültigkeit geprüft werden. Dazu wird eine GA generiert und die Tokenreferenz des Token F (als Prüfungsvorgabe) zusammen mit den Modifikationsangaben MA bestehend aus den drei Modifikationen (Proofs) „Split“, „Switch“ und „Merge“ von der TE2 an das TRR als GA gesendet. Die Ausgangstokenreferenz TRB der ersten MA der GAs ist gemäß der GA, die nur den Token F mittels seiner Tokenreferenz als zu prüfenden Token angibt, ist nicht zu prüfen bzw. wird vom TRR nicht auf Gültigkeit geprüft. In diesem Fallbeispiel werden die ersten beiden Modifikationsangaben der GA nur optional ausgeführt, beispielsweise falls TE1 (oder eine andere TE) noch keine RA oder GA mit diesen beiden MA an das TRR gesendet hat.
  • Die GB kann des TRR kann optional in Form einer Statusmeldung zurückgegeben werden, die auch zusätzliche Informationen kodiert, beispielsweise:
    • 200: Token ist gültig, alle Modifikationen der Modifikationsangabe konnten aufgelöst werden
    • 400: Token ist gültig, einige Modifikationen der Modifikationsangabe konnten nicht aufgelöst werden
    • 500: Interner Fehler
    • 600: Token ist ungültig.
  • An eine solche Statusmeldung kann/können die kryptographische Bestätigungen, also insbesondere Signaturen, der TRR angehängt sein.
  • Die GB kann oder die gültigen TR können mit einem privaten Schlüssel pKeyTRR eines Schlüsselpaars der Verifiziereinheit 2 signiert werden.
  • BEZUGSZEICHENLISTE
    • PKeyTH
    öffentlicher Teil des Tokenherausgeber-Schlüsselpaars
    pKeyTH
    privater Teil des Tokenherausgeber-Schlüsselpaars
    PKeyTRR
    öffentlicher Teil des Verifiziereinheiten-Schlüsselpaars
    pKeyTRR
    privater Teil des Verifiziereinheiten-Schlüsselpaars
    R
    öffentlicher Teil des tokenindividuellen Schlüsselpaars
    r
    privater Teil des tokenindividuellen Schlüsselpaars
    GA
    Gültigkeitsanfrage
    GAsig_T
    Gültigkeitsanfrage signiert mit privatem Teil des tokenindividuellen Schlüsselpaars
    GB
    Gültigkeitsbestätigung
    UGB
    Ungültigkeitsbestätigung
    GBsig_TRR
    Gültigkeitsbestätigung signiert mit privatem Teil des Tokenreferenzregister-Schlüsselpaars
    RA
    Registrieranfrage
    RAsig_T
    Registrieranfrage signiert mit privatem Teil des tokenindividuellen Schlüsselpaars
    RAsig_TH
    Registrieranfrage signiert mit privatem Teil des Tokenherausgeber-Schlüsselpaars
    MA
    Modifikationsangabe
    RAE
    Registrieranfrage-Einheit
    RB
    Registrierantwort, Registrierbestätigung
    T
    Token
    TE
    Transaktionseinheit
    TEB
    Transaktionseinheit Bank
    TE-Schicht
    Direkttransaktionsschicht
    TRR-Schicht
    Registerschicht
    TH
    Tokenherausgeber
    TRx
    Tokenreferenz der GA
    TRE
    Eingangstokenreferenz
    TRA
    Ausgangstokenreferenz
    KO
    Kommando, Modifikationskommando
    TRR
    Tokenreferenz-Register
    TS
    Transaktionssystem
    v, TW
    Tokenwert
    a-h
    Indizes für verschiedene Token und Tokenreferenzen
    Σ
    Gesamt-Tokenwert des Transaktionssystems
    1
    Datenbank, Speichereinheit
    2
    Verifiziereinheit 11-19 Verfahrensschritte im Stand der Technik
    3
    Teilnehmerschnittstelle / MA-Empfangseinheit
    4
    Herausgeberschnittstelle / Neuregistriereinheit
    5
    MA-Archivierungseinheit
    6
    Gesamtsummenprüfeinheit
    30
    Gültigkeitsanfrage
    31
    Modifikationsangabe
    32
    Signatur der Modifikationsangabe
    33,43,53
    Prüfungsangabe
    40
    Gültigkeitsanfrage für Stapel von MA
    50
    Gültigkeitsanfrage für Folge von MA
    101
    Empfangen GA
    102
    Prüfen ob TRA gespeichert
    103
    Prüfen ob TRE gespeichert
    104
    MA auf Fehler prüfen
    105
    Speichern TRA
    106
    Erstellen Signatur
    108
    Senden Gültigkeitsbestätigung
    109
    Senden Ungültigkeitsbestätigung
    141,142
    Bearbeitungs-Schleife für MAi
    146
    Ungültigkeit für TRA merken
    107
    Prüfen ob Gesamtgültigkeit festgestellt
    147
    Prüfen ob Teilgültigkeit festgestellt
    148
    Senden Teilgültigkeitsbestätigung
    151
    Prüfen ob ein TRA1l gespeichert
    152
    Signieren des TRA1l
    153a,153b, 153c
    Bearbeitungs-Schleife für für MAi
    155
    Selektives Speichern für TRA der MA-Folge
    164a
    Verifzieren der MA-Folge
    164b
    Prüfen ob Folge verifiziert
    165
    Selektives Speichern für TRA der MA-Folge
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102009038645 A1 [0003]
    • DE 102009034436 A1 [0003]
    • WO 2020/212337 A1 [0007]

Claims (17)

  1. Sicheres Element eines elektronischen Transaktionssystems (TS), wobei das sichere Element einen Tokenspeicher für Token (T) des Transaktionssystems (TS) aufweist; wobei das sichere Element als Transaktionseinheit (TE) eingerichtet ist, um Token (T) des Transaktionssystems direkt mit einer anderen Transaktionseinheit (TE) des Transaktionssystems (TS) auszutauschen; wobei jedem Token (T) des Transaktionssystems eine Tokenreferenz (TR) eindeutig zugeordnet ist, welche in einem Tokenreferenz-Register (TRR) des Transaktionssystems registrierbar ist; wobei das sichere Element eingerichtet ist, um ausgehend von mindestens einem Eingangstoken (TE) mindestens einen Ausgangstoken (TA) und dessen Ausgangs-Tokenreferenz (TRA) zu erzeugen; wobei das sichere Element mindestens eine Modifikationsangabe (MA), welche mindestens eine Eingangs-Tokenreferenz (TRE), ein Kommando (KO) und mindestens eine Ausgangs-Tokenreferenz (TRA) umfasst, für das Tokenreferenz-Register (TRR) bereitstellt, dadurch gekennzeichnet, dass das sichere Element eingerichtet ist, die mindestens eine Modifikationsangabe (MA) als Gültigkeitsanfrage (GA) bereit zu stellen, und das sichere Element eingerichtet ist, eine Gültigkeitsbestätigung für zumindest eine auf Gültigkeit zu prüfende Ausgangs-Tokenreferenz (TRAij) der Gültigkeitsanfrage (GA) zu empfangen.
  2. Sicheres Element nach Anspruch 1, dadurch gekennzeichnet, dass die Gültigkeitsanfrage die zumindest eine zu prüfende Ausgangs-Tokenreferenz (TRAij) und mindestens eine nicht zu prüfende Ausgangs-Tokenreferenz umfasst.
  3. Sicheres Element nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Gültigkeitsanfrage neben der Modifikationsangabe (MA) eine Prüfungsangabe (33;43;53) umfasst, welche die zumindest eine zu prüfende Ausgangs-Tokenreferenz (TRAij) angibt.
  4. Sicheres Element nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das sichere Element eingerichtet ist, um Modifikationsangaben entweder als Gültigkeitsanfrage (GA) oder als Registrieranfrage (RA) bereit zu stellen.
  5. Sicheres Element nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Gültigkeitsbestätigung für jede zu prüfende Ausgangs-Tokenreferenz (TRAij) eine separate kryptographische Bestätigung umfasst, die vorzugsweise in dem sicheren Element gespeichert wird.
  6. Sicheres Element nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Gültigkeitsanfrage mehrere Modifikationsangaben (MA) umfasst, insbesondere einen Stapel und/oder eine Folge von Modifikationsangaben umfasst.
  7. Sicheres Element nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass das sichere Element ferner einen Prozessor, insbesondere zur Ausführung der Schritte als Transaktionseinheit, und/oder eine Schnittstelle, insbesondere zu einem lokalen Endgerät, über welche die Gültigkeitsanfrage für das Tokenreferenz-Register (TRR) bereitgestellt wird, umfasst; und/oder Token (T) als Datenelemente einen Tokenwert (v) sowie einen geheimes Tokenelement (r) umfassen; und/oder Tokenreferenzen (TR) als Datenelemente einen Tokenwert (v) sowie ein öffentliches Tokenelement (R) umfassen.
  8. Verfahren zum Prüfen der Gültigkeit eines Tokens (T) eines sicheren elektronischen Transaktionssystems (TS), wobei jedem Token (T) des Transaktionssystems eine Tokenreferenz (TR) eindeutig zugeordnet ist, wobei ein Tokenreferenz-Register (TRR) des Transaktionssystems (TS) eine Verifikationseinheit (2) und eine Speichereinheit (1), in welcher die Tokenreferenzen (TR) gültiger Token (T) gespeichert sind, umfasst, mit den folgenden Verfahrensschritten in dem Tokenreferenz-Register (TRR): - Empfangen (101) einer Gültigkeitsanfrage (GA), die eine Modifikationsangabe (MA) mit mindestens einer Eingangs-Tokenreferenz (TRE), mindestens einer Ausgangs-Tokenreferenz (TRA) und einem Kommando (KO) umfasst; - Prüfen (102) mindestens einer auf Gültigkeit zu prüfenden Ausgangs-Tokenreferenz (TRAij) der Gültigkeitsanfrage (GA) darauf, ob sie in der Speichereinheit (1) gespeichert ist; und - Senden (108) einer Gültigkeitsbestätigung (GB) für die mindestens eine zu prüfende Ausgangs-Tokenreferenz (TRAij); wobei die Gültigkeitsanfrage (GA) die nur optional zu bearbeitende Modifikationsangabe (MA; MA1) und/oder eine Prüfungsangabe (33;43;53) umfasst, welche die zumindest eine zu prüfende Ausgangs-Tokenreferenz (TRAij) angibt.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Verifikationseinheit (2) Modifikationsangaben (MA) mit einem oder mehreren der Teilschritte bearbeitet: - Prüfen (103) ob die mindestens eine Eingangs-Tokenreferenz (TRE) in der Speichereinheit (1) gespeichert ist; - Verifizieren (104) der Modifikationsangabe (MA) durch die Verifikationseinheit (2), insbesondere einer Signatur in der Modifikationsanfrage (MA) und/oder einer Wertneutralität der Modifikationsangabe (MA) und/oder einer Syntax der Modifikationsangabe (MA); und/oder - Ausführen des Kommandos (KO) durch Speichern (105) einer Ausgangs-Tokenreferenz in der Speichereinheit (1) und insbesondere durch Löschen einer Eingangs-Tokenreferenz in der Speichereinheit (1).
  10. Verfahren nach Anspruch 8 oder 9, wobei die Gültigkeitsanfrage (GA) mindestens eine, vorzugsweise mehrere, nicht auf Gültigkeit zu prüfende Ausgangs-Tokenreferenz(en) (TRA11) umfasst; und/oder die Gültigkeitsbestätigung (GB) für jede zu prüfende Ausgangs-Tokenreferenz (TRAij) eine separate kryptographische Bestätigung umfasst.
  11. Verfahren nach einem der Ansprüche 8 bis 10, wobei die Gültigkeitsanfrage (GA) mehrere Modifikationsangaben (MA1, MA2, ... MAx) umfasst, wobei jede Modifikationsangabe (MA) eine oder mehrere Eingangs-Tokenreferenzen (TRE), eine oder mehrere Ausgangs-Tokenreferenzen (TRA) und ein Modifikationskommando (KO) umfasst, wobei die Modifikationsangaben vorzugsweise ein Stapel (40) von Modifikationsangaben und/oder eine Folge (50) von Modifikationsangaben (MA) sind, wobei insbesondere Stapel aus unabhängigen Modifikationsangaben (MA) bestehen bzw. Folgen mindestens teilweise voneinander abhängige Modifikationsangaben (MA) umfassen.
  12. Das Verfahren nach einem der Ansprüche 8 bis 11, wobei die Verifikationseinheit (2) eine gemeinsame Speicherabfrage an die Speichereinheit (1) richtet für Ausgangs-Tokenreferenzen unterschiedlicher Modifikationsangaben und/oder für Ausgangs-Tokenreferenzen und Eingangs-Tokenreferenzen zumindest einer Modifikationsangabe (MA).
  13. Das Verfahren nach einem der Ansprüche 11 oder 12, wobei für den Stapel von Modifikationsangaben (MA) eine Teilgültigkeitsbestätigung (TGB) gesendet wird;und/oder für eine Folge von Modifikationsangaben zumindest eine Ausgangs-Tokenreferenz einer Modifikationsangabe (MA) nur intern zwischengespeichert wird und/oder erst nach Prüfung einer, mehrerer oder aller weiteren Modifikationsangaben (MA) der Folge in der Speichereinheit (1) gespeichert wird.
  14. Das Verfahren nach einem der Ansprüche 8 bis 13, wobei das Tokenreferenz-Register (TRR) das Verfahren mit einer Transaktionseinheit TE oder dem sicheren Element nach einem der Ansprüche 1 bis 7 ausführt und/oder das Tokenreferenz-Register (TRR) ferner umfasst: - weitere Verifikationseinheiten (2) und/oder eine - Archiveinheit (5), welche nicht mehr gültige Tokenreferenzen und/oder bereits ausgeführte Gültigkeitsanfragen (GA) und/oder Registrierungsanfragen (RA) speichert.
  15. Ein Tokenreferenz-Register (TRR) für ein Transaktionssystem (TS), eingerichtet zum Durchführen der Verfahrensschritte nach einem der vorhergehenden Ansprüche 8 bis 14, insbesondere mit einer Transaktionseinheit TE oder dem sicheren Element nach einem der Ansprüche 1 bis 7.
  16. Das Tokenreferenz-Register (TRR) nach Anspruch 15, aufweisend: - die Speichereinheit (1) zum Speichern von Tokenreferenzen (TR) zum Registrieren von Token (T) im Transaktionssystem (TS); - eine Schnittstelle (3) eingerichtet zum Empfangen einer Gültigkeitsanfrage (GA); - die zumindest eine Verifiziereinheit (2).
  17. Ein Transaktionssystem (TS) aufweisend: - eine Registerschicht (TRR-Schicht) mit einem Tokenreferenz-Register (TRR) gemäß Ansprüchen 15 oder 16 zum Registrieren von Tokenreferenzen (TR); und - eine Direkttransaktionsschicht (TE-Schicht) mit einer Vielzahl von Transaktionseinheiten (TE), einschließlich einem sicheren Element nach einem der Ansprüche 1 bis 7.
DE102022002780.1A 2022-08-01 2022-08-01 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister Pending DE102022002780A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102022002780.1A DE102022002780A1 (de) 2022-08-01 2022-08-01 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
PCT/DE2023/100487 WO2024027869A1 (de) 2022-08-01 2023-06-28 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102022002780.1A DE102022002780A1 (de) 2022-08-01 2022-08-01 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Publications (1)

Publication Number Publication Date
DE102022002780A1 true DE102022002780A1 (de) 2024-02-01

Family

ID=87429466

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022002780.1A Pending DE102022002780A1 (de) 2022-08-01 2022-08-01 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Country Status (2)

Country Link
DE (1) DE102022002780A1 (de)
WO (1) WO2024027869A1 (de)

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60029455T2 (de) 1999-08-26 2007-07-19 Moneycat Ltd. Elektronisches geld, zugehörige elektronische börse und diese anwendende elektronische bezahlungssysteme
DE102009034436A1 (de) 2009-07-23 2011-01-27 Giesecke & Devrient Gmbh Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze
DE102009038645A1 (de) 2009-08-24 2011-03-24 Giesecke & Devrient Gmbh Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
EP3035270A1 (de) 2014-12-15 2016-06-22 Giesecke & Devrient GmbH Kartenbasierte offline-token generierung
DE102016100110A1 (de) 2015-01-26 2016-07-28 International Business Machines Corporation Verwaltung einer Ressourcenkontoanwendung
EP3226191A1 (de) 2016-04-03 2017-10-04 Trinkaus, Hans Alternatives zahlungsmittel, stark personifiziert, schwach personifiziert oder ohne personifizierung
DE102018009949A1 (de) 2018-12-18 2020-06-18 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen
WO2020212337A1 (de) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
WO2022020609A1 (en) 2020-07-22 2022-01-27 ZUZLab, Inc. Method and system for defining, creating, managing, and transacting multiple classes of digital objects
DE102006017911B4 (de) 2006-04-18 2023-01-26 creditPass GmbH Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
DE102021004548A1 (de) 2021-09-08 2023-03-09 Giesecke+Devrient Advance52 Gmbh Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108764865A (zh) * 2012-04-01 2018-11-06 深圳市可秉资产管理合伙企业（有限合伙） 一种用于移动支付的方法和系统
CN113962676A (zh) * 2020-07-20 2022-01-21 华为技术有限公司 交易验证的方法、装置
DE102021004019A1 (de) * 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Verfahren zum registrieren von token eines elektronischen transaktionssystems

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60029455T2 (de) 1999-08-26 2007-07-19 Moneycat Ltd. Elektronisches geld, zugehörige elektronische börse und diese anwendende elektronische bezahlungssysteme
DE102006017911B4 (de) 2006-04-18 2023-01-26 creditPass GmbH Elektronisches Bezahlsystem und Verfahren zum Ausführen eines Bezahlvorgangs
DE102009034436A1 (de) 2009-07-23 2011-01-27 Giesecke & Devrient Gmbh Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze
DE102009038645A1 (de) 2009-08-24 2011-03-24 Giesecke & Devrient Gmbh Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
EP3035270A1 (de) 2014-12-15 2016-06-22 Giesecke & Devrient GmbH Kartenbasierte offline-token generierung
DE102016100110A1 (de) 2015-01-26 2016-07-28 International Business Machines Corporation Verwaltung einer Ressourcenkontoanwendung
EP3226191A1 (de) 2016-04-03 2017-10-04 Trinkaus, Hans Alternatives zahlungsmittel, stark personifiziert, schwach personifiziert oder ohne personifizierung
DE102018009949A1 (de) 2018-12-18 2020-06-18 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen
WO2020212337A1 (de) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
WO2022020609A1 (en) 2020-07-22 2022-01-27 ZUZLab, Inc. Method and system for defining, creating, managing, and transacting multiple classes of digital objects
DE102021004548A1 (de) 2021-09-08 2023-03-09 Giesecke+Devrient Advance52 Gmbh Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems

Also Published As

Publication number Publication date
WO2024027869A1 (de) 2024-02-08

Similar Documents

Publication Publication Date Title
WO2020212337A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
EP3956845A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
DE102007011309B4 (de) Verfahren zur authentisierten Übermittlung eines personalisierten Datensatzes oder Programms an ein Hardware-Sicherheitsmodul, insbesondere einer Frankiermaschine
WO2021170645A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
EP3743844B1 (de) Blockchain-basiertes identitätssystem
WO2023011761A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
WO2023036458A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE102022002780A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102018009951A1 (de) Verfahren zum direkten Austausch eines Münzdatensatzes zwischen Sicherheitselementen
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
DE102018115348A1 (de) Fälschungssicherung und Abgabekontrolle von Verbrauchsgütern
EP1994485A2 (de) Verfahren zum verknüpfen eines digitalen inhalts mit einer person
WO2006058828A2 (de) Verfahren zur personalisierung von chipkarten
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
EP3215977A1 (de) Verfahren zur änderung einer in einer chipkarte gespeicherten datenstruktur, signaturvorrichtung und elektronisches system
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
DE102018202676A1 (de) Verfahren zum Authentifizieren eines Benutzers
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102019000985A1 (de) System und Computernetzwerk zur datensicheren Erstellung, Adaption und Validierung von Smart Contracts
DE102021004023A1 (de) Verfahren zum direkten übertragen von token
DE102020203861A1 (de) Validieren und Speichern von V-Modell Transaktionsdatensätzen in einer Blockchain
WO2021069613A1 (de) Verfahren zum validieren von vertrauenswürdigen daten in einem computersystem
DE102021106261A1 (de) Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06Q0020000000

Ipc: G06Q0020380000

R163 Identified publications notified