DE102021004020A1 - Verfahren zum registrieren von token eines elektronischen transaktionssystems - Google Patents

Verfahren zum registrieren von token eines elektronischen transaktionssystems Download PDF

Info

Publication number
DE102021004020A1
DE102021004020A1 DE102021004020.1A DE102021004020A DE102021004020A1 DE 102021004020 A1 DE102021004020 A1 DE 102021004020A1 DE 102021004020 A DE102021004020 A DE 102021004020A DE 102021004020 A1 DE102021004020 A1 DE 102021004020A1
Authority
DE
Germany
Prior art keywords
token
registration request
transaction system
key pair
register
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.)
Withdrawn
Application number
DE102021004020.1A
Other languages
English (en)
Inventor
Daniel Albert
Raoul-Thomas Herborg
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 DE102021004020.1A priority Critical patent/DE102021004020A1/de
Priority to BR112024002177A priority patent/BR112024002177A2/pt
Priority to US18/681,044 priority patent/US20240275600A1/en
Priority to CN202280053895.8A priority patent/CN117916735A/zh
Priority to EP22744114.4A priority patent/EP4381408A1/de
Priority to PCT/EP2022/025325 priority patent/WO2023011756A1/de
Publication of DE102021004020A1 publication Critical patent/DE102021004020A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4033—Local solvency checks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Bioethics (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Registrieren von Token eines elektronischen Transaktionssystems, wobei jeder Token des Transaktionssystems zumindest einen Tokenwert und einen privaten Teil eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist, mit den Verfahrensschritten: Empfangen, in einem Tokenreferenz-Register des Transaktionssystems, einer Registrieranfrage aufweisend zumindest eine einem Token des Transaktionssystems eindeutig zugeordnete Tokenreferenz, wobei die Tokenreferenz zumindest den Tokenwert des Tokens und einen öffentlichen Teil des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil des tokenindividuellen Schlüsselpaars des Tokens erhalten wurde, Verifizieren, durch eine Verifiziereinheit des Tokenreferenz-Registers, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register gespeichert ist, und Speichern der zumindest einen Tokenreferenz in einer Speichereinheit des Tokenreferenz-Registers zum Registrieren des dieser Tokenreferenz eindeutig zugeordneten Tokens im Transaktionssystem, wenn im Verifizieren-Schritt festgestellt wird, dass die zumindest eine Tokenreferenz der empfangenen Registeranfrage nicht im Tokenreferenz-Register gespeichert ist. Die Erfindung betrifft zudem ein Tokenreferenz-Register und ein Transaktionssystem.

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Die Erfindung bezieht sich auf ein Verfahren zum Registrieren von Token, beispielsweise elektronischen Münzdatensätzen, eines elektronischen Transaktionssystems, beispielsweise eines elektronischen Bezahlsystems. Zudem betrifft die Erfindung auch ein Tokenreferenz-Register, in dem Tokenreferenzen gespeichert werden, die eindeutig einem Token zugeordnet sind. Die Erfindung bezieht sich zudem auf ein Transaktionssystem.
  • Die Erfindung bedient sich dabei eines Verfahrens zum Registrieren von direkt zwischen Teilnehmereinheiten übertragbaren Token.
  • TECHNISCHER HINTERGRUND DER ERFINDUNG
  • Sicherheit von Transaktionen und den dazugehörigen Transaktionsdaten bedeutet sowohl Schutz der Vertraulichkeit der ausgetauschten Daten; als auch Schutz der Integrität der ausgetauschten Daten; als auch Schutz der Verfügbarkeit der ausgetauschten Daten.
  • Herkömmliche auf Blockchain-Topologien basierte Transaktionssysteme, wie beispielsweise Bitcoin, stellen einen hohen Schutz der Integrität dar. Wenn sogenannte „Coins“ als Datensätze in einer Blockchain-Topologie den Besitzer wechseln, werden viele Informationen veröffentlicht. Dabei wird beispielsweise eine eindeutige Adresse einer Teilnehmereinheit verifizierbar in der Blockchain registriert. Somit sind Blockchain-Transaktionen nicht anonym. Zudem sind diese Transaktionen sehr rechenintensiv und damit energieaufwendig.
  • Zur Steigerung der Anonymität können anstelle der vertraulichen Daten beispielsweise nur die Hash-Werte der vertraulichen Daten in einem Blockchain-Ledger abgespeichert werden. Die korrespondierenden Klartext-Daten müssen dann außerhalb der Blockchain verwaltet werden. Für elektronische Transaktionen mit sicherheitsrelevanten oder wertvollen Daten sind solche hashwertbasierten Konzepte nicht anwendbar, weil sie grundlegende Kontrollfunktionen, insbesondere (1) das Erkennen von Mehrfachausgaben von Transaktionsdatensätzen, auch Double-Spending genannt, und (2) das Erkennen von ungedeckten Transaktionsdatensätzen, wie bspw. ungedeckten Zahlungen, nicht abbilden können. Im Fall (1) versucht jemand denselben Transaktionsdatensatz mehrfach auszugeben und im Fall (2) versucht jemand einen Transaktionsdatensatz auszugeben, den er nicht (mehr) besitzt.
  • Aus der DE 10 2009 038 645 A1 und der DE 10 2009 034 436 A1 sind Systeme zum Übertragen von geldwerten Beträgen in Form elektronischer Datensätze, bei denen ein Bezahlen mit Duplikaten des Datensatzes verhindert und ein hoher Grad an Manipulationssicherheit gegeben ist, bekannt, wobei hier komplexe Strukturen und aufwendige Verschlüsselungs- und Signiervorgänge für die Transaktionen erforderlich sind. Diese haben sich als wenig praxistauglich herausgestellt.
  • In der WO 2016/200885 A1 ist ein Verfahren zur Verschlüsselung eines mittels Blockchain-Ledger übertragenen Betrags beschrieben, wobei die Verifizierbarkeit der Transaktion des Betrags erhalten bleibt. Dabei wird ein Verschleierungsbetrag zu einem Eingangswert addiert. Dann wird ein Ausgangswert erzeugt und verschlüsselt. Sowohl der Eingangswert als auch der Ausgangswert liegen innerhalb eines Wertebereichs, wobei eine Summe von zwei beliebigen Werten innerhalb des Bereichs einen Schwellenwert nicht überschreitet. Bereichsprüfungen sind jedem der Eingangswerte und dem Ausgangswert zugeordnet. Diese Bereichsprüfungen sollen beweisen, dass der Eingangswert und der Ausgangswert in den zugeordneten Wertebereich fallen. Jeder öffentliche Schlüssel kann mit einer Ringsignatur signiert werden, die auf einem öffentlichen Schlüssel eines Empfängers in der Transaktion basiert. In diesem Verfahren ist eine Blockchain-Technologie notwendig, die nach Erhalt eines elektronischen Münzdatensatzes angerufen werden muss, um den elektronischen Münzdatensatz zu validieren.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren zum Registrieren von Token eines Transaktionssystems zu schaffen, in denen eine Transaktion vom Token sicher aber dennoch einfach ausgestaltet ist. Dabei soll insbesondere eine direkte Transaktion eines Tokens zwischen Teilnehmereinheiten geschaffen werden. Diese Transaktion soll für Dritte anonym bleiben. Der Token soll nach dem Erhalt in einer Teilnehmereinheit sofort weiterverwendet werden können, um eine Transaktion auch ohne Verbindung zu einer entfernten Einheit, beispielsweise einem zentralen Register oder einem dezentralen Ledger, zu ermöglichen. Ein empfangener Token soll einerseits geheim gegenüber nicht an der Transaktion beteiligten Teilnehmereinheiten sein. Jede Teilnehmereinheit des Transaktionssystems soll einen erhaltenen Token überprüfen können, insbesondere sollen Mehrfach-Ausgabe-Versuche und Versuche, nicht vorhandene Tokenwerte zu übertragen, von einer Teilnehmereinheit oder allgemein im Transaktionssystem erkannt werden können.
  • 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.
  • Die Aufgabe wird insbesondere durch ein Verfahren zum Registrieren von Token eines elektronischen Transaktionssystems gelöst, wobei jeder Token des Transaktionssystems zumindest einen Tokenwert und einen privaten Teil eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist.
  • Das Verfahren umfasst die Verfahrensschritte: Empfangen, in einem Tokenreferenz-Register des Transaktionssystems, einer Registrieranfrage aufweisend zumindest eine einem Token des Transaktionssystems eindeutig zugeordneten Tokenreferenz, wobei die Tokenreferenz zumindest den Tokenwert des Tokens und einen öffentlichen Teil des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil des tokenindividuellen Schlüsselpaars des Tokens erhalten wurde, Verifizieren, durch eine Verifiziereinheit des Tokenreferenz-Registers, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register gespeichert ist, und Speichern der zumindest einen Tokenreferenz in einer Speichereinheit des Tokenreferenz-Registers zum Registrieren des dieser Tokenreferenz eindeutig zugeordneten Tokens im Transaktionssystem, wenn im Verifizieren-Schritt festgestellt wird, dass die zumindest eine Tokenreferenz der empfangenen Registeranfrage nicht im Tokenreferenz-Register abgespeichert ist.
  • Das Empfangen erfolgt bevorzugt an einer Schnittstelle des Tokenreferenz-Registers, bevorzugt einer Schnittstelle der Verifiziereinheit des Tokenreferenz-Registers.
  • Ein Transaktionssystem ist ein System in dem zumindest zwei, bevorzugt eine Vielzahl von Teilnehmereinheiten Token direkt untereinander austauschen (übertragen) können. Das Transaktionssystem ist beispielsweise ein Bezahltransaktionssystem zum Austausch von geldwerten Beträgen in Form von Bezahl-Token.
  • Ein Token ist ein zwischen Teilnehmereinheiten direkt austauschbarer Datensatz eines Transaktionssystems. Mit Kenntnis des Tokens ist die empfangende Teilnehmereinheit 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 „Bitcoin“, „Ethereum“ oder „Neo“, übertragbar ist - kann direkt zwischen Teilnehmereinheiten ohne dazwischengeschaltete Einheiten übertragen werden.
  • In einer Ausgestaltung ist der Token ein elektronischer Münzdatensatz oder Bezahl-Token, um geldwerte Beträge zwischen Teilnehmereinheiten 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.
  • Der Token unterscheidet sich von einem Datensatz zum klassischen Datenaustausch oder Datentransfer, da beispielsweise ein klassischer Datenaustausch auf Basis eines Frage-Antwort-Prinzips bzw. auf einer Interkommunikation zwischen den Partnern des Datenaustauschs stattfindet. Ein Token ist dementgegen einmalig und eindeutig im Transaktionssystem. Der Token steht im Kontext eines Sicherheitskonzepts, welches beispielsweise Signaturen oder kryptografische Verschlüsselungen umfasst. In einem Token sind alle Datenelemente enthalten, die für eine empfangende Teilnehmereinheit bezüglich Verifikation, Authentisierung und Weitergeben des Tokens an eine andere Teilnehmereinheit benötigt werden. Eine Interkommunikation zwischen den einen Token übertragenden Teilnehmereinheiten ist daher bei einem Token grundsätzlich nicht erforderlich.
  • Jeder, der im Besitz eines Tokens oder uneingeschränkten Zugriff auf den Token mit seinen Tokenelementen hat, kann diesen Token mit einer anderen Teilnehmereinheit 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 Teilnehmereinheit ü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 Teilnehmereinheit erzeugt werden. Dazu muss die Teilnehmereinheit Kenntnis von dem Token mit seinen Tokenelementen aufweisen. Das Erzeugen der Tokenreferenz kann durch eine elektronische Geldbörse einer Teilnehmereinheit erfolgen, die den Token senden möchte. Alternativ kann das Erzeugen der Tokenreferenz durch eine elektronische Geldbörse einer Teilnehmereinheit erfolgen, die den Token empfangen hat.
  • Die Verwendung einer Tokenreferenz ist nicht mit der Verwendung von Adressen von Teilnehmereinheiten in einem Blockchain-basierten Transaktionssystem vergleichbar, da im erfindungsgemäßen Tokenreferenz-Register keine Adressen der Teilnehmereinheiten verwendet werden, um eine Verfolgbarkeit der Token zu verhindern.
  • Das Verfahren zum Registrieren sieht einen Empfangen-Schritt vor, um eine Tokenreferenz in einem Tokenreferenz-Register im Rahmen einer Registrieranfrage zu empfangen. Beispielsweise wird die Registrieranfrage von einer Teilnehmereinheit des Transaktionssystems oder eines Tokenherausgebers des Transaktionssystems gesendet.
  • Das Tokenreferenz-Register ist eine Einheit des Transaktionsregisters die die Tokenreferenzen ablegt, wodurch die dazugehörigen Token registriert sind. Dieses Register kann eine zentrale Datenbank oder Speichereinheit sein. Dieses Register kann ein dezentraler Ledger, beispielsweise in einer Blockchain-Topologie sein. Das Tokenreferenz-Register kann eine Historie zu den Tokenreferenzen und/oder den Registrieranfragen führen.
  • Die empfangene Registrieranfrage wird durch eine Verifiziereinheit im Tokenreferenz-Register verifiziert. Dabei wird verifiziert, ob die zumindest eine Tokenreferenz der empfangenen Registrieranfrage in dem Tokenreferenz-Register bereits gespeichert ist.
  • Im Tokenreferenzregister 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.
  • In einer Ausgestaltung wird im Verifizieren-Schritt durch die Verifiziereinheit des Tokenreferenz-Registers zudem festgestellt, ob die Tokenreferenz in der empfangenen Registrieranfrage einem Token zugeordnet werden kann. Dazu muss die Tokenreferenz oder eine Ableitung der Tokenreferenz oder eine Historie zu der Tokenreferenz in dem Tokenreferenz-Register abgespeichert sein, die zu der Tokenreferenz der empfangenen Registrieranfrage zugeordnet werden kann.
  • In einer Ausgestaltung wird im Verifizieren-Schritt festgestellt, ob die empfangene Registrieranfrage syntaktisch korrekt ist. Damit wird beispielsweise geprüft, ob die Registrieranfrage plausibel ist, ob in der Registrieranfrage ein Kommandotyp korrekt angegeben wurde, ob der Token, der der Tokenreferenz eindeutig zugeordnet ist, tatsächlich vorhanden ist (existieren kann); und/oder ob eine Differenzbildung von Tokenwerten in der Registrieranfrage zu einem in der Registrieranfrage angegebenen Kommandotyp passt.
  • In einer Ausgestaltung wird im Verifizieren-Schritt festgestellt, ob eine Signatur der Registrieranfrage korrekt ist.
  • In einer Ausgestaltung wird im Verifizieren-Schritt zudem festgestellt, ob eine Summe von Tokenwerten aller Tokenreferenzen innerhalb der Registrieranfrage null ist. Dabei werden Eingangs-Tokenwerte und Ausgangs-Tokenwerte der Registrieranfrage aufsummiert. Bei Registrieranfragen, die von Teilnehmereinheiten stammen, muss eine Summe aller Tokenwerte der Registrieranfrage null ergeben. Ergibt die Summe nicht null, so wurde in unerlaubter Weise zusätzlich ein Tokenwert im Transaktionssystem geschaffen oder ein Tokenwert aus dem Transaktionssystem vernichtet. Damit kann ein Betrugsversuch mit nicht-vorhandenen Token oder unerlaubt generierten Token leichter erkannt werden. Bislang waren aufwendige Bereichsnachweise (zero-knowledge-proofs, ZKP) notwendig, die durch dieses Verfahren entfallen können.
  • Die empfangene Tokenreferenz wird in einer Speichereinheit des Tokenreferenz-Registers gespeichert. Mit dem Speichern erfolgt ein Registrieren des der empfangenen Tokenreferenz eindeutig zugeordneten Tokens im Transaktionssystem. Das Speichern erfolgt nur wenn im Verifizieren-Schritt festgestellt wird, dass die zumindest eine Tokenreferenz der empfangenen Registeranfrage nicht im Tokenreferenz-Register gespeichert ist.
  • Das Grundprinzip des Registrierens eines Tokens ist demnach, dass eine empfangene Registrieranfrage verifiziert wird daraufhin, ob die dem Token zugeordnete Tokenreferenz im Tokenreferenz-Register bereits bekannt ist. Ist die Tokenreferenz bereits bekannt, wird sie nicht nochmal abgespeichert. Ist die Tokenreferenz nicht bekannt, wird sie in das Tokenreferenz-Register eingetragen (gespeichert), um für zukünftige Verifizier- und Prüfschritte im Transaktionssystem verfügbar zu sein.
  • In einer Ausgestaltung ist der öffentliche Schlüsselteil des tokenindividuellen Schlüsselpaars der Tokenreferenz zugleich ein Datenbankenindex einer Datenbank des Tokenreferenz-Register. Dabei ist der Datenbankindex eine von der Datenstruktur getrennte Indexstruktur in dem Tokenreferenz-Register, die die Suche und das Sortieren nach Tokenreferenzen beschleunigt. Er kann eine Ansammlung von Zeigern (Verweisen) sein, die eine Ordnungsrelation auf eine oder mehrere Einträge im Tokenreferenz-Register definieren. Durch Verwendung des öffentlichen Schlüsselteils als Index wird das Verifizieren stark vereinfach. Damit ist keine Prüfung von Dubletten mehr nötig, weil in dem Tokenreferenz-Register die Eineindeutigkeit des Index bereits geprüft wird.
  • In einer Ausgestaltung ist die empfangene Registrieranfrage mit dem privaten Teil des tokenindividuellen Schlüsselpaars signiert, um eine Zuordnung von der Tokenreferenz zu dem Token prüfen bzw. verifizieren zu können. Ist das Verifizieren im Verifizieren-Schritt erfolgreich, also kann die Signatur verifiziert werden, dann muss der Sender der Registrieranfrage im Besitz des Tokens bzw. in Kenntnis des Tokens sein. Damit kann ein Betrugsversuch mit nicht-vorhandenen Token oder unerlaubt generierten Token erkannt werden.
  • In einer Ausgestaltung weist das Tokenreferenz-Register eine oder mehrere Speichereinheit zum Speichern von Tokenreferenzen zum Registrieren der Token im Transaktionssystem auf. Diese Speichereinheit(en) kann/können als eine zentrale Datenbank des Transaktionssystems geführt sein. Die Verwendung von mehreren Speichereinheiten ermöglicht eine parallele Bearbeitung von Registrieranfragen und beschleunigt das Registrieren im Transaktionssystem.
  • In einer Ausgestaltung weist das Tokenreferenz-Register eine oder mehrere Verifiziereinheiten zum Verifizieren von empfangenen Registrieranfragen auf. Die Verwendung von mehreren Verifiziereinheiten ermöglicht eine parallele Bearbeitung von Registrieranfragen und beschleunigt das Registrieren im Transaktionssystem.
  • Diese Verifiziereinheit(en) vergleicht/en beispielsweise einen Kommandotyp der empfangenen Registrieranfrage mit den Tokenwerten der empfangenen Registrieranfrage. Wird von einem Kommandotyp erwartet, dass keine Tokenwerte zum Transaktionssystem addiert oder vom Transaktionssystem subtrahiert werden sollen, so wird geprüft, ob dies mit den Tokenwerten der empfangenen Tokenreferenzen auch eingehalten wird. Bei fehlgeschlagener Verifzierung wird ein Betrugsfall erkannt und ein Registrieren verhindert.
  • In einer Ausgestaltung weist das Tokenreferenz-Register eine Prüfeinheit zum Prüfen einer Summe von Tokenwerten betreffend die empfangene Registrieranfrage auf. Diese Prüfeinheit vergleicht die empfangene Registrieranfrage mit einem Datenbestand der Speichereinheit ab und prüft insbesondere eine Gesamtsumme aller Tokenwerte auf Veränderung aufgrund der Registrieranfrage. Damit kann die Gültigkeit des Tokenwerts daraufhin geprüft werden, ob ein neuer Tokenwert unerlaubter Weise generiert wurde. Damit könnten auch alte Registrieranfragen und deren Erfolg geprüft werden, diese Registrieranfragen-Historie könnte verwendet werden, um ohne Belastung der Speichereinheit des Tokenreferenz-Registers, doppelt gesendete Registrieranfragen zu bearbeiten.
  • In einer Ausgestaltung weist das Tokenreferenz-Register eine Neuregistrierungseinheit auf, um Tokenreferenzen zu neu erzeugten Token (=neue Token) oder gelöschten Token (deaktivierte Token) eines Tokenherausgebers zu registrieren. In diese Neuregistriereinheit des Tokenreferenz-Registers können diese neu erzeugte Token und diese gelöschte Token eingetragen werden. Mit der Neuregistriereinheit kann ein Referenzwert betreffend den Gesamt-Tokenwert der im Transaktionssystem befindlichen Token auf Basis der erzeugten und/oder gelöschten Token im Tokenreferenz-Register (beispielsweise in einer Prüfeinheit davon) aktualisiert werden. Wird beispielsweise ein neuer Token generiert, so wird dessen Tokenwert zum Gesamt-Tokenwert addiert. Wird beispielsweise ein Token gelöscht, so wird dessen Tokenwert vom Gesamt-Tokenwert subtrahiert.
  • In einer Ausgestaltung weist die Tokenreferenz zumindest einen Zählwert als weiteres Tokenreferenz-Element auf. Der Zählwert kann ein weiteres Token-Element sein. Der Zählwert kann beispielsweise die Anzahl von Offline-Transaktionen des Tokens repräsentieren. Eine Offline-Transaktion ist dabei eine direkte Transaktion zwischen Teilnehmereinheiten im Transaktionssystem zum Übertragen von Token, ohne dass der Token im Tokenreferenz-Register registriert wird. Der Zählwert erhöht sich (inkrementiert sich) mit jeder Offline-Transaktion. Es kann systembedingt vorgesehen sein, dass Token bei Überschreiten eines vordefinierten Schwellwerts für den Zählwert automatisch im Tokenreferenz-Register registriert werden müssen.
  • In einer Ausgestaltung weist die Tokenreferenz zumindest eine Identität einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit als weiteres Tokenreferenz-Element auf. Die Identität kann ein weiteres Token-Element sein. Diese Identität dient beispielsweise im Prüfen-Schritt dazu, die Tokenreferenz zu validieren oder zu verifizieren. Damit wird die Anonymität im Transaktionssystem aufgehoben und ein Betrugsfall schneller aufgedeckt.
  • In einer Ausgestaltung weist die Tokenreferenz zumindest ein Pseudonym einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit als weiteres Tokenreferenz-Element auf. Das Pseudonym kann ein weiteres Token-Element sein. Dieses Pseudonym dient beispielsweise im Prüfen-Schritt dazu, die Tokenreferenz zu validieren oder zu verifizieren. Damit wird die Anonymität im Transaktionssystem nicht aufgehoben und ein Betrugsfall dennoch schneller aufgedeckt, wenn eine Einheit des Transaktionssystems das Pseudonym auflöst.
  • Zum Erzeugen der Tokenreferenz kann jedes weitere Tokenreferenz-Element durch eine Verkettung (Konkatenation) mit dem ersten und/oder zweiten Tokenreferenz-Element hinzugefügt werden.
  • In einer Ausgestaltung betrifft die Registrieranfrage eine Aufteilung eines Tokens und bevorzugt weist die Registrieranfrage eine Tokenreferenz des aufzuteilenden Tokens und jeweils eine Tokenreferenz der (zumindest zwei) aufgeteilten Token auf. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Die Aufteilung (=Split) ist eine Modifikationsmöglichkeit an einem Token, mit der ein Tokenwert eines Tokens in zumindest zwei (kleinere) Tokenwerte aufgeteilt werden kann. Damit ist es möglich den Tokenwert zu verkleinern und auf eine Transaktionsforderung tokenwertgenauer zu reagieren. Damit wird der aufgeteilte Token ungültig und die (zumindest zwei) geteilten Token werden in dem Tokenreferenz-Register registriert, um im Transaktionssystem prüfbar zu werden.
  • Alternativ oder zusätzlich wird für das Aufteilen vorgesehen, dass der Tokenwert des aufzuteilenden Tokens in wenigstens einen ersten Tokenwert und in einen zweiten Tokenwert aufgeteilt wird. Die Aufteilung kann symmetrisch erfolgen, sodass die aufgeteilten Tokenwerte gleich groß sind. Die Aufteilung kann asymmetrisch erfolgen, sodass die aufgeteilten Tokenwerte ungleich groß sind.
  • Alternativ oder zusätzlich wird beim Aufteilen vorgesehen: Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars für einen ersten aufgeteilten Token; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars für den ersten aufgeteilten Token; Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars für einen zweiten aufgeteilten Token; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars für den zweiten aufgeteilten Token; Aufteilen des Tokenwerts in einen ersten Tokenteilwert und in einen zweiten Tokenteilwert, unter Beachtung, dass die Summe aus dem ersten Tokenteilwert und dem zweiten Tokenteilwert dem Tokenwert des aufzuteilenden Tokens entspricht; Erzeugen einer Tokenreferenz für den ersten aufgeteilten Token aufweisend den ersten Tokenteilwert und den öffentlichen Teil des tokenindividuellen Schlüsselpaars des ersten aufgeteilten Tokens; Erzeugen einer Tokenreferenz für den zweiten aufgeteilten Token aufweisend den zweiten Tokenteilwert und den öffentlichen Teil des tokenindividuellen Schlüsselpaars des zweiten aufgeteilten Tokens; und Erstellen der Registrieranfrage unter Verwendung der Tokenreferenz des aufzuteilenden Tokens, der Tokenreferenz für den ersten aufgeteilten Token und der Tokenreferenz für den zweiten aufgeteilten Token.
  • In einer Ausgestaltung betrifft die Registrieranfrage eine Umschaltung eines Tokens und bevorzugt weist die Registrieranfrage eine Tokenreferenz des umzuschaltenden Tokens auf. Die Umschaltung des Tokens ist eine weitere Modifikationsmöglichkeit. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Wird ein Token von einer Teilnehmereinheit direkt an eine andere Teilnehmereinheit übertragen, beispielsweise wenn im Rahmen einer Bezahltransaktion der geldwerte Betrag als Tokenwert übertragen werden soll, so kann die empfangende Teilnehmereinheit nun den Tokenwert auf sich umregistrieren lassen. Damit wird im Tokenreferenz-Register die Umschaltung registriert.
  • Beim Übertragen eines Tokens zwischen zwei Teilnehmereinheiten, haben diese beiden Teilnehmereinheiten zugleich Kenntnis über den Token. Um zu verhindern, dass die sendende Teilnehmereinheit den Token auch noch bei einer anderen (dritten) Teilnehmereinheit ebenfalls verwendet (sogenanntes Mehrfachausgeben des Tokens), wird bevorzugt ein Umschalten („Switch“) des übertragenen Tokens von der ersten Teilnehmereinheit auf die zweite Teilnehmereinheit ausgeführt. Das Umschalten kann bevorzugt automatisch beim Empfangen eines Tokens in der zweiten Teilnehmereinheit erfolgen.
  • Alternativ oder zusätzlich wird beim Umschalten vorgesehen: Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars; Erstellen der Registrieranfrage unter Verwendung der Tokenreferenz für den umzuschaltenden Token und den öffentlichen Teil des tokenindividuellen Schlüsselpaars für den umgeschalteten Token.
  • Der Tokenwert des umzuschaltenden Tokens entspricht dem Tokenwert des umgeschalteten Tokens. Beim Umschalten wird demnach ein Token mit gleichem Tokenwert aber neuem privaten Teil bei dem Tokenreferenz-Register registriert.
  • In einer Ausgestaltung betrifft die Registrieranfrage ein Verbinden von zumindest zwei Token betrifft und bevorzugt weist die Registrieranfrage eine Tokenreferenz des verbundenen Tokens und jeweils eine Tokenreferenz der zu verbindenden Token auf. Die in der Registrieranfrage enthaltenen Tokenreferenzen können durch Verkettung (Konkatenation) aneinandergefügt sein. Die Verbindung (= Merge) ist eine Modifikationsmöglichkeit an einem Token, mit der zwei Tokenwerte miteinander verbunden also verknüpft werden. Damit ist es möglich zwei Tokenwerte zu einem Tokenwert zu verschmelzen, um auf eine Transaktionsforderung tokenwertgenau zu reagieren. Damit werden die zu verbindenden Token ungültig und der verbundene Token wird in dem Tokenreferenz-Register registriert, um im Transaktionssystem prüfbar zu werden.
  • Alternativ oder zusätzlich wird beim Verbinden vorgesehen: Erzeugen eines neuen privaten Teils eines tokenindividuellen Schlüsselpaars; Anwenden einer kryptografischen Funktion zum Erhalten eines entsprechenden öffentlichen Teils des tokenindividuellen Schlüsselpaars für den verbundenen Token; Berechnen des Tokenwerts für den verbundenen Token durch Bilden der Summe aus den jeweiligen Tokenwerten der zumindest zwei zu verbindenden Token; Erzeugen einer Tokenreferenz für den verbundenen Token aufweisend den berechneten Tokenwert und den öffentlichen Teil des tokenindividuellen Schlüsselpaars für den verbundenen Token; und Erstellen der Registrieranfrage unter Verwendung jeder Tokenreferenz der zu verbindenen Token und der Tokenreferenz für den verbundenen Token.
  • In einer Ausgestaltung wird eine Registrieranfrage von einem Tokenherausgeber versendet, wobei die Registrieranfrage ein Erstellen eines Tokens oder ein Löschen eines Tokens betrifft.
  • Ein Tokenherausgeber ist im Gegensatz zu einer Teilnehmereinheit eine privilegierte Instanz im Transaktionssystem, durch die Token erzeugt und gelöscht werden können. Eine Teilnehmereinheit kann keinen Token erzeugen oder löschen, sie kann Token nur modifizieren (Umschalten, Aufteilen, Verbinden).
  • Der Token ist in einer Teilnehmereinheit abgelegt. Die Teilnehmereinheit kann eine Vielzahl von Token aufweisen, beispielsweise kann in einem Datenspeicher der Teilnehmereinheit 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 Teilnehmereinheit abgelegt sind.
  • Die Teilnehmereinheit kann beispielsweise ein mobiles Endgerät, wie z.B. ein Smartphone, ein Tablet-Computer, ein Computer, ein Server oder eine Maschine sein. Die Teilnehmereinheit kann eine Smartcard sein, die betriebsbereit in einem Endgerät eingebracht ist.
  • Der Datenspeicher ist beispielsweise einen Geldbörsenspeicher einer elektronischen Geldbörse (Wallet). Die elektronische Geldbörse ist beispielsweise eine Softwareapplikation, die auf einer Teilnehmereinheit ausführbar abgespeichert ist. Die elektronische Geldbörse (Wallet) kann der Teilnehmereinheit die Teilnahme am Transaktionssystem ermöglichen. So kann die elektronische Geldbörse eine Registrieranfrage generieren, um einen Token in einem Tokenreferenz-Register zu registrieren. Zudem kann die elektronische Geldbörse Modifikationen (Umschalten, Verbinden, Aufteilen) an einem Token vornehmen und die dabei möglicherweise notwendigen Registrieranfragen generieren und an das Tokenreferenz-Register senden. Zudem kann die elektronische Geldbörse Token an eine andere Geldbörse (in einer anderen Teilnehmereinheit) übertragen.
  • Eine Transaktion im Transaktionssystem ist vorzugsweise atomar.
  • Das Tokenreferenz-Register hat demnach Kenntnis über Tokenreferenzen von Token des Transaktionssystems und führt bevorzugt auch die Verarbeitungen bzw. Modifikationen an den Token (Token-Historie). Die Transaktionen mit den Token wird in dem Tokenreferenz-Register nicht registriert und findet in einer Direkttransaktionsschicht des Transaktionssystems direkt zwischen Teilnehmereinheiten des Transaktionssystems statt.
  • Erfindungsgemäß ist ein Tokenreferenz-Register für ein Transaktionssystem vorgesehen, das eingerichtet ist zum Durchführen der Verfahrensschritte gemäß dem zuvor beschriebenen Verfahren.
  • In einer Ausgestaltung weist das Tokenreferenz-Register auf: zumindest eine Speichereinheit zum Speichern von Tokenreferenzen zum Registrieren von Token im Transaktionssystem; eine Prüfeinheit zum Prüfen von empfangenen Registrieranfragen; zumindest eine Verifiziereinheit zum Verifzieren, ob eine Tokenreferenz einer empfangenen Registrieranfrage in dem Tokenreferenz-Register gespeichert ist; und/oder eine Neuregistriereinheit zum Registrieren von von einem Tokenherausgeber neu generierten Token oder von von einem Tokenherausgeber gelöschten Token.
  • Erfindungsgemäß ist ein Transaktionssystem vorgesehen, das aufweist: eine Registerschicht mit einem Tokenreferenz-Register der vorhergehenden Art zum Registrieren von Tokenreferenzen; und eine Direkttransaktionsschicht mit einer Vielzahl von Teilnehmereinheiten, 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. Das Tokenreferenz-Register gibt auf Anfrage Auskunft über die Tokenreferenzen, die eindeutig zu den Token des Transaktionssystems zugeordnet sind, um beispielsweise eine Mehrfach-Ausgabe des gleichen Tokens zu vermeiden oder die Echtheit des Tokens zu verifizieren.
  • Die Speichereinheit des Tokenreferenz-Registers speichert bevorzugt nur Tokenreferenzen von im Transaktionssystem tatsächlich vorhandenen 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.
  • Das Endgerät kann also in der Direktbezahltransaktionsschicht einem anderen Endgerät elektronische Münzdatensätze übertragen ohne Verbindung zur Überwachungsinstanz, insbesondere wenn das Endgerät offline ist, also keine Kommunikationsverbindung zu der Überwachungsinstanz vorhanden ist.
  • Eine Teilnehmereinheit 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 Endgerät und sicherem Element als Teilnehmereinheit kann mittels APDU erfolgen. Die Kommunikation zwischen Endgerät und Tokenreferenz-Register oder Herausgebereinheit kann mittels API-Aufrufen erfolgen. Das Endgerät ist dabei nur ein Protokollübersetzer und verändert die Registrieranfragen nicht.
  • Die Kommunikation zwischen zwei Teilnehmereinheiten 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 teilnehmereinheitenindividuellen Schlüsselpaars.
  • Figurenliste
  • 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äß der Erfindung;
    • 2 zeigt ein Ausführungsbeispiel eines Tokenreferenz-Registers gemäß der Erfindung;
    • 3a zeigt eine Übersicht über erfindungsgemäße Kommandos für Token;
    • 3b zeigt eine Übersicht über erfindungsgemäße signierte Registrieranfragen für die erfindungsgemäßen Kommandos;
    • 4 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Erstellen und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht;
    • 5 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Löschen eines Tokens und Registrieren;
    • 6 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Aufteilen und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht;
    • 7 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Verbinden und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht;
    • 8 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Umschalten und Registrieren eines Tokens und eine Übersicht über die Kommandodetails in Abhängigkeit der Transaktionsschicht; und
    • 9 zeigt ein weiteres Ausführungsbeispiel eines Tokenreferenz-Registers gemäß der Erfindung.
  • DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN
  • 1 zeigt ein Ausführungsbeispiel eines Transaktionssystems TS gemäß der Erfindung. 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 Teilnehmereinheiten TE vorgesehen sein können, stellvertretend sind zwei Teilnehmereinheiten TE1, TE2 gezeigt.
  • Die Teilnehmereinheiten 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, siehe 2). Jeder Token T kann von jeder Teilnehmereinheit TE aufgeteilt, verbunden oder umgeschaltet werden (siehe 6 bis 8) und kann von dem Tokenherausgeber TH generiert (Siehe 4) und auch gelöscht werden (siehe 5). 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 Teilnehmereinheit TE hat exklusiven Zugriff auf diesen Tokenspeicher oder umfasst diesen Tokenspeicher in einem Datenspeicher der Teilnehmereinheit TE.
  • Ein Token kann als ein TLV kodierter Datensatz in einem Tokenspeicher abgelegt sein und weist dann einen eindeutigen Tag und eine Längeninformation auf, beispielsweise in folgendem Format auf.
    Name Tag (hex) Länge Tokenwert v Zufallszahl r
    TLV-kodierter Token 42 1 Byte 4 Byte 32 Byte
  • Ein Beispiel eines TLV-codierten Token in hexadezimaler Form ist nachfolgend dargestellt:
    • 42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
    und wird wie folgt interpretiert:
    • „42“ ist der Tag zur Identifizierung des TLV-kodierten Tokens T;
    • „24“ zeigt die Länge an, hier also, dass es sich um einen 36 Byte großen Datensatz handelt;
    • „00 00 40 00“ ist der Tokenwert (integer) v = 16384 und beträgt demnach € 163,84;
    • „00 01 02 03 04 05 06 07 08 09 ... 1D 1E 1F“ ist die Zufallszahl r als integer.
  • 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. Die Tokenreferenz TR des Tokens T kann jederzeit im Register TRR des Transaktionssystems TS eingesehen werden. Damit ist der Tokenwert v eines Tokens T durch das Tokenreferenz-Register TRR offengelegt.
  • 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 secp256rl-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 Verknüpfung oder Verkettung von Tokenwert v und öffentlichem Teil R.
  • Diese Tokenreferenz TR kann als Registrieranfrage RA ggf. zusammen mit einem Kommando (siehe Übersicht in 3a und 3b) bezüglich des Tokens T an das Tokenreferenz-Register TRR gesendet werden.
  • Zusätzlich kann die Registrieranfrage RA 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.
  • In der Teilnehmereinheit TE wird die signierte Registrieranfrage RAsig als ein sogenannter PROOF abgelegt, beispielsweise in folgendem Format:
    Typ Tag (hex) Länge Daten
    PROOF 4A N Bytes
  • Ein Beispiel eines PROOF (=RAsig) in hexadezimaler Form ist nachfolgend dargestellt:
    • 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56
    und wird wie folgt interpretiert (siehe auch 8 zur Struktur einer Umschalte-Registrieranfrage):
    • „4A“ ist der Tag zur Identifizierung des TLV-Proof RAsig_Th;
    • „81 8F“ zeigt die Länge an;
    • „03“ zeig an, dass es sich um eine Umschalte (=SWITCH) Registrieranfrage handelt;
    • „11 12 13 14“ ist der Tokenwert vg;
    • „15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35“ ist der öffentliche Teil Rg;
    • „36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56“ ist der öffentliche Teil Rh;
    • „30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56“ ist die Signatur als X690-Sequenz.
  • Diese Registrieranfrage RA kann an das Tokenreferenz-Register TRR gesendet werden. Im Tokenreferenz-Register TRR wird diese Registrieranfrage RA empfangen. Nach Prüfung der Registrieranfrage RA durch das Tokenreferenz-Register TRR wird die Tokenreferenz TR im Tokenreferenz-Register TRR abgelegt, wodurch der Token T im Transaktionssystem TS registriert ist.
  • Diese 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 und prü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 die entsprechenden Registrieranfragen RA von Teilnehmereinheiten TE abgelegt.
  • Die Token T werden beispielsweise in elektronischen Geldbörsen, sogenannten Wallets, einer TE abgelegt. Diese Wallets sind beispielsweise Softwareapplikationen innerhalb der Teilnehmereinheiten TE 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 und/oder Token T auszutauschen. Wallets dienen dazu, mit dem Tokenreferenz-Register TRR zu kommunizieren, Registrieranfragen RA an das Tokenreferenz-Register TRR zu generieren und/oder Transaktion von Token T zu einer Teilnehmereinheit TE vorzunehmen.
  • Für eine Transaktion mit einer Teilnehmereinheit 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 Teilnehmereinheit 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.
  • Das Übertragen einer Tokenreferenz TR von einer elektronischen Geldbörse erfolgt beispielsweise als APDU Kommando(s) zu einem Endgerät (Smartphone) als Teilnehmereinheit TE. Ein APDU ist ein kombinierter Kommando-/Datenblock eines Verbindungsprotokolls zwischen dem sicheren Element und dem Endgerät. Die Struktur der APDU ist durch den Standard ISO-7816-4 definiert. Das Endgerät entpackt APDU Kommando(s) und überträgt die Daten in API-Aufrufen an das Tokenreferenz-Register TRR, wo sie in HTTP-Codes umgesetzt werden.
  • In 2 ist ein Ausführungsbeispiel eines Tokenreferenz-Register TRR der Erfindung dargestellt.
  • Das Tokenreferenz-Register TRR verwaltet insbesondere den Speicherort für die Tokenreferenzen TR, hier als Datenbank 1 als Beispiel einer Speichereinheit im Tokenreferenz-Register TRR dargestellt. Stellvertretend ist in der Datenbank 1 das TR zum Token T der Teilnehmereinheit TE1 eingetragen. Diese Datenbank 1 kann aus einem Zusammenschluss vieler Datenbanken bestehen (siehe auch 9), die untereinander vernetzt sind. Zum einfachen Auffinden einer Tokenreferenz TR, ist der öffentliche Teil R der Tokenreferenz TR gleichzeitig ein Datenbankenindex in der Datenbank 1, denn sowohl ein Index einer Datenbank als auch ein öffentlicher Teil R einer Tokenreferenz TR müssen im Transaktionssystem TS eineindeutig sein.
  • Zudem kann das Tokenreferenz-Register TRR zumindest eine Verifiziereinheit 2 umfassen. 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 eine Historie aus alten (vergangenen) Registrieranfragen RA bezüglich eines Tokens T kann dabei verifiziert 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.
  • Zudem kann das Tokenreferenz-Register TRR eine Prüfeinheit 3 umfassen, die prüft, ob mit dem Tokenwert v einer empfangenen Tokenreferenz TR ein Gesamt-Tokenwert Σ im Transaktionssystem TS verändert wird. Ist dies der Fall, dann wurde ein neuer Tokenwert v geschaffen oder ein existierender Tokenwert v vernichtet. Dies dürfen nur privilegierte Einheiten, wie einer Herausgeberinstanz TH, im Transaktionssystem TS. Wenn ein derartiges Verändern der Gesamtsumme der Tokenwerte durch eine Tokenreferenz TR einer Teilnehmereinheit TE erkannt wird, dann kann von einem Betrugsfall ausgegangen werden. Somit kann eine illegale Generierung von Tokenwerten v sehr leicht entdeckt und verhindert werden.
  • Die Prüfung des Gesamt-Tokenwerts durch die Prüfeinheit 3 stellt ein weiteres Sicherheitskonzept im Transaktionssystem TS dar.
  • Zudem kann das Tokenreferenz-Register TRR eine Neuregistriereinheit 4 umfassen, in die neu generierte Tokenreferenzen TR eines Tokenherausgebers TH erst-registriert werden oder zu löschende Tokenreferenzen TR ent-registriert werden. Damit wird eine Funktionstrennung zwischen Tokenreferenzen TR von privilegierten Teilnehmern, wie einem Tokenherausgeber TH, von Tokenreferenzen TR von unprivilegierten Teilnehmern, wie den Teilnehmereinheiten TE, erreicht. Die Tokenwerte v von neu generierte Tokenreferenzen TR oder zu löschenden Tokenreferenzen TR haben direkten Einfluss auf eine Änderung des Gesamt-Tokenwerts, der in der Prüfeinheit 3 überwacht wird.
  • Eine Registrieranfrage RA 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 Verifziereinheit 2. Zudem kann eine Registeranfrage RA beispielsweise syntaktisch validiert werden durch Prüfen der Signatur und/oder der Tokenreferenz TR.
  • Auch wenn eine Signatur in einer Teilnehmereinheit 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 Teilnehmereinheiten 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.
  • In 3a ist eine Übersicht von Kommandos CO gezeigt, die an einem Token T vorgenommen werden können. Die Kommandos CO können Modifikationen an einem vorhandenen Token T sein, beispielsweise „Umschalten (=Switch)“, „Aufteilen (=Split)“ oder „Verbinden (=Merge)“. Die Kommandos CO können auch das Erzeugen (=Create) eines Tokens T oder das Löschen (Destroy) vorhandenen Token T betreffen. In 3a sind beispielhaft Kommandocodierungen angegeben (0x01 bis 0x05), die sodann Teil einer Registrieranfrage RA sein können.
  • In 3b ist eine Übersicht von Kommandos CO und deren signierte Registrieranfrage-Syntax RA gezeigt. Dabei werden pro Kommando CO Eingangs-Token T und Eingangs-Tokenreferenzen TR „verbraucht“. Dabei werden pro Kommando CO Ausgangs-Token T Ausgangs-Tokenreferenzen TR „generiert“.
  • Ein Kommando CO hat die grundlegende Struktur aus den folgenden drei Elementen: Kommandotyp, Eingangs-Tokenreferenz(en), Ausgangs-Tokenreferenz(en).
  • Jedes Kommando hat eine charakteristische Anzahl von Eingangs-Tokenreferenz(en) („Eingänge“) und Ausgangs-Tokenreferenz(en) („Ausgänge“), die in den 4 bis 8 näher erläutert und dargestellt sind.
  • Zu beachten ist, dass für die Kommandos CO „Aufteilen“, „Umschalten“ und „Verbinden“ die Differenz der Tokenwerte v aller beteiligten Token T bzw. Tokenreferenzen TR den Betrag „null“ ergeben muss. Mit anderen Worten, diese Kommandos CO „Aufteilen“, „Umschalten“ und „Verbinden“ erzeugen keine Tokenwerte v und vernichten keine Tokenwerte v. Dies kann am Kommandotyp CO selbst oder auch von der Prüfeinheit 3 des Tokenreferenz-Register TRR nachgeprüft werden und ist ein Prüfkriterium für eine Registeranfrage RA.
  • Zu beachten ist auch, dass nur für die Kommandos CO „Erzeugen“ und „Löschen“ eine Differenz der Tokenwerte v des beteiligten Tokens T bzw. Tokenreferenzen TR erlaubt ist, aber nur in Höhe des Tokenwerts v des Tokens T und nicht darüber hinaus.
  • Jede Registrieranfrage kann signiert werden, um prüfen zu können, dass der Sender der Tokenreferenz TR auch im Besitz des dazugehörigen Tokens T ist. Als Signatur kann ein ECDSA-Schema angewendet werden. Die Registrieranfrage RA wird bevorzugt mit dem privaten Teil r des Tokens T signiert.
  • Für signierte Registrieranfragen der Kommandotypen CO „Erzeugen“ und „Löschen“ wird eine weitere Signatur eines Tokenherausgebers TH verlangt, um sicherzustellen, dass diese Kommandos von einer privilegierten Einheit des Transaktionssystems TS generiert worden sind.
  • In 4 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Erstellen eines Tokens T und das Registrieren im TRR gezeigt. Zudem ist die signierte Registrieranfrage RAsig und die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
  • Beim Erstellen gibt es keinen Eingangsparameter in der TE-Schicht. In einer privilegierten Einheit, hier dem Tokenherausgeber TH, wird eine Zufallszahl r generiert. Auf Basis von der Zufallszahl r wird ein öffentlicher Teil R errechnet, wie es oben beschrieben wurde. Somit kann im Tokenherausgeber TH eine Tokenreferenz TR ausgehend vom Tokenwert v und dem öffentlichen Teil R durch Konkatenation von v und R gebildet werden.
  • Eine Registrieranfrage RA bestehend aus dem Kommando „CREATE“ bzw. dem Kommandocode gemäß 3a und der erzeugten Tokenreferenz TR wird im Tokenherausgeber TH signiert. Dazu wird der private Schlüssel pKey des Tokenherausgebers TH verwendet.
  • In der TE-Schicht wird der Token T an die TE1 ausgegeben. In der TRR-Schicht wird die signierte Registrierungsanfrage RAsig an das TRR ausgegeben.
  • Im Tokenreferenz-Register TRR wird die Signatur der Registrieranfrage RA mit dem öffentlichen Schlüssel PKey der Herausgeberinstanz TH geprüft. Dieser öffentliche Schlüssel PKeyTH ist transaktionssystemweit bekannt oder wurde dem Tokenreferenz-Register TRR im Vorfeld zur Verfügung gestellt. Ist die Signaturprüfung erfolgreich, dann wird die Tokenreferenz TR in das Tokenreferenz-Register TRR eingetragen.
  • In einer Ausgestaltung wird der Gesamt-Tokenwert des Transaktionssystems TS in der Prüfeinheit 3 des Tokenreferenz-Register TRR um den Tokenwert v durch die Neuregistriereinheit 4 des Tokenreferenz-Register TRR erhöht.
  • In 5 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Löschen eines Tokens T und Registrieren des gelöschten T im TRR gezeigt. Zudem sind die dazu benötigten signierten Registrieranfrage RAsig_TH und RASig_T sowie die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
  • Beim Löschen wird als Eingangsparameter in der TE-Schicht der zu löschende Token T verwendet und in der TRR-Schicht die zu löschende Tokenreferenz TRR und zwei signierte Registrieranfrage RASig_TH und RASig_T verwendet.
  • Die Registrieranfrage RA bestehend aus dem Kommando „DESTROY“ und der zu löschenden Tokenreferenz TR wird einmal mit dem privaten Schlüssel pKey des Tokenherausgebers TH signiert.
    Eine weitere Registrieranfrage RA bestehend aus dem Kommando „DESTROY“ und der zu löschenden Tokenreferenz TR wird zudem mit dem privaten Teil r des Tokens T signiert.
  • Beide signierte Registrieranfragen werden an das Tokenreferenz-Register TRR versendet. Im Tokenreferenz-Register TRR wird die Signatur mit dem öffentlichen Schlüssel der Herausgeberinstanz TH geprüft. Dieser öffentliche Schlüssel ist transaktionssystemweit bekannt oder wurde dem Tokenreferenz-Register TRR im Vorfeld zur Verfügung gestellt. Zudem wird die Signatur der weiteren Registrieranfrage RA mit dem öffentlichen Teil der Tokenreferenz TR geprüft. Sind beide Signaturprüfungen erfolgreich, dann wird die Tokenreferenz TR in dem TRR gelöscht oder als gelöscht markiert.
  • In einer Ausgestaltung wird der Gesamt-Tokenwert des Transaktionssystems TS in der Prüfeinheit 3 des Tokenreferenz-Register TRR um den Tokenwert v durch die Neuregistriereinheit 4 des Tokenreferenz-Register TRR verringert.
  • Das Tokenreferenz-Register TRR oder der Tokenherausgeber TH veranlassen zudem das Löschen des Tokens T in der Teilnehmereinheit TE1.
  • In 6 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Aufteilen eines Tokens Ta und Registrieren der aufgeteilten Token Tb Tc im Tokenreferenz-Register TRR gezeigt. Zudem ist die dazu benötigte signierte Registrieranfrage RASig_Ta sowie die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
  • In der TE-Schicht wird durch die TE1 eine erste Zufallszahl rb und eine zweite Zufallszahl rc erzeugt. Basierend darauf wird dann jeweils ein öffentlicher Teil Rb und Rc erzeugt. Als Eingangsparameter steht in der TE-Schicht der aufzuteilende Token Ta zur Verfügung. Es erfolgt in der TE-Schicht eine Aufteilung des Tokenwerts va in einen ersten Tokenteilwert vb und einen zweiten Tokenteilwert vc. Die Summe aus Tokenteilwert vb und Tokenteilwert vc muss den Tokenwert va ergeben. Damit wird sichergestellt, dass kein neuer Tokenwert v erzeugt wird oder ein Tokenwert v vernichtet wird.
  • Sodann werden von der TE1 die Tokenreferenzen TRb und TRe erzeugt. Die Registrieranfrage RA enthält sodann das Kommando „SPLIT“ bzw. den dafür in 3a gezeigten Kommandocode, die Eingangs-Tokenreferenz TRa und die Ausgangs-Tokenreferenzen TRb und TRe. Diese Registrieranfrage RA wird mit der Zufallszahl ra des Tokens Ta signiert. Die signierte Registrieranfrage RASig_Ta wird vom TE1 an das Tokenreferenz-Register TRR gesendet. Dort wird die Signatur geprüft und die Summe von vb und vc gebildet und mit dem Tokenwert va verglichen. Wenn va = vb + vc gilt und die Signaturprüfung erfolgreich ist, dann wird die Tokenreferenz TRa in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenzen TRb und TRe in das Tokenreferenz-Register TRR eingetragen.
  • In einer Ausgestaltung wird im Tokenreferenz-Register in der Verifiziereinheit 2 die Tokenwertedifferenz der Eingangs-Tokenreferenz TRa und der Ausgangs-Tokenreferenzen TRb und TRc gebildet und geprüft, diese Differenz null ist. Ist die Differenz nicht null, so wurde in unerlaubter Weise ein Tokenwert v generiert oder vernichtet. Zudem kann auch der Gesamt-Tokenwert des Transaktionssystems TS in der Prüfeinheit 3 des Tokenreferenz-Register TRR vor oder nach der Registrierung der Tokenreferenzen TRb und TRc geprüft werden. Der Gesamt-Tokenwert v in der Prüüfeinheit 3 darf sich nicht verändert haben und muss dem Wert vor der Verarbeitung der Registrieranfrage im Tokenreferenz-Register TRR entsprechen.
  • Der aufgeteilte Token Tb (oder Tc) (der zwischenzeitlich von TE1 an TE2 übertragen wurde) kann nun von der Teilnehmereinheit TE2 im TRR auf Gültigkeit geprüft werden.
  • In 7 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Verbinden eines Tokens Td mit einem Token Te und Registrieren des verbundenen Tokens Tf im TRR gezeigt. Zudem sind die dazu benötigten signierten Registrieranfragen RASig_Td und RAsig_Te sowie die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
  • Dabei wird in einer TE1 der TE-Schicht eine Zufallszahl rf erzeugt. Basierend darauf wird dann ein öffentlicher Teil Rf erzeugt. Zudem erfolgt das Bilden einer Summe aus den Tokenwerten vd und ve zum Tokenwert vf basierend auf den Eingangs-Token Td und Te.
  • Sodann wird die Ausgangs-Tokenreferenz TRf erzeugt. Eine Registrieranfrage RA enthält sodann das Kommando „MERGE“ bzw. den in 3a gelisteten Kommandocode, die zwei Eingangs-Tokenreferenzen TRd und TRe sowie die Ausgangs-Tokenreferenz TRf. Diese Registrieranfrage RA wird einmal mit der Zufallszahl rd des Tokens Td signiert, um eine erste signierte Registrieranfrage RAsig_Td zu erhalten. Diese Registrieranfrage wird zudem mit der Zufallszahl re des Tokens Te signiert, um eine zweite signierte Registrieranfrage RAsig_Te zu erhalten. Beide signierte Registrieranfragen RAsig_Td und RAsig_Te werden von der Teilnehmereinheit TE1 an das Tokenreferenz-Register TRR gesendet. Dort werden jeweils die Signaturen der Registrieranfragen RAsig_Ta und RAsig_Te geprüft.. Zudem wird die Summe von den Tokenwerten vd und ve gebildet und mit dem Tokenwert vf verglichen. Wenn vf = vd + ve gilt und beide Signaturprüfungen erfolgreich sind, dann werden TRd und TRe in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenz TRf in das Tokenreferenz-Register TRR eingetragen. Der verbundene Token Tf (der zwischenzeitlich von TE1 an TE2 übertragen wurde) kann nun von der Teilnehmereinheit TE2 im TRR auf Gültigkeit geprüft werden.
  • In 8 ist ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens zum Umschalten eines Tokens Tg auf einen Token Th und Registrieren des umgeschalteten Tokens Th im Tokenreferenz-Register TRR gezeigt. Zudem ist die dazu benötigte signierte Registrieranfragen RAsig_Tg sowie die Kommandostruktur sowohl aus Sicht der TE-Schicht als auch der TR-Schicht tabellarisch dargestellt.
  • Dabei wird in einer TE1 eine Zufallszahl rh erzeugt. Basierend darauf wird dann ein öffentlicher Teil Rh erzeugt. Zudem wird der zum Tokenwert vg des Eingangs-Token Tg identische Tokenwert vb gebildet.
  • Sodann wird die Tokenreferenz TRh erzeugt. Eine Registrieranfrage RA enthält sodann das Kommando „SWITCH“ oder einen entsprechenden Kommandocode gemäß 3a, die Eingangs-Tokenreferenz TRg und den gebildeten öffentlichen Teil Rh (bzw. die Ausgangs-Tokenreferenz TRh). Diese Registrieranfrage RA wird mit der Zufallszahl rg des Tokens Tg signiert. Die signierte Registrieranfrage RAsig_Tg wird von der Teilnehmereinheit TE1 an das Tokenreferenz-Register TRR gesendet. Dort wird die Signatur geprüft. Zudem wird der Tokenwert vg mit dem Tokenwert vb verglichen. Wenn vg = vb gilt und die Signaturprüfung erfolgreich ist, dann wird die Tokenreferenz TRg in dem Tokenreferenz-Register TRR gelöscht oder als gelöscht markiert und die Tokenreferenz TRh in das Tokenreferenz-Register TRR eingetragen.
  • In 9 ist eine weitere Ausgestaltung eines Tokenreferenz-Registers TRR eines Transaktionssystems TS gezeigt. In 9 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 Registrieranfragen RA zu beschleunigen. Zudem ist eine Teilnehmereinheit TEB dargestellt, die als Schnittstelle zwischen dem Transaktionssystem TS und einem Buchgeldsystem (Kreditvergabe, Kontenmanagement) funktioniert und es Teilnehmereinheiten TE ermöglicht, Token T des Transaktionssystems TS in ein anderes Transaktionssystem TS zu überführen. Diese Überführung ist bidirektional und erfolgt unter Verwendung des Tokenherausgebers TH, der für die Generierung von Token T und auch das Löschen von Token T allein verantwortlich ist.
  • Bezugszeichenliste
    • CO
    Kommando
    PKeyTH
    öffentlicher Teil des Tokenherausgeber-Schlüsselpaars
    pKeyTH
    privater Teil des Tokenherausgeber-Schlüsselpaars
    R
    öffentlicher Teil des tokenindividuellen Schlüsselpaars
    r
    privater Teil des tokenindividuellen Schlüsselpaars
    RA
    Registrierungsanfrage
    RAsig_T
    Registrierungsanfrage signiert mit privatem Teil des tokenindividuellen Schlüsselpaars
    RAsig_TH
    Registrierungsanfrage signiert mit privatem Teil des Tokenherausgeber-Schlüsselpaars
    T
    Token
    TE
    Teilnehmereinheit
    TEB
    Teilnehmereinheit Bank TE-Schicht Direkttransaktionsschicht TRR-Schicht Registerschicht
    TH
    Tokenherausgeber
    TR
    Tokenreferenz
    TRR
    Tokenreferenz-Register
    1
    Datenbank, Speichereinheit
    2
    Verifiziereinheit
    3
    Prüfeinheit
    4
    Neuregistriereinheit
    TS
    Transaktionssystem
    TW
    Tokenwert
    a-h
    Indizes für verschiedene Token und Tokenreferenzen
    Σ
    Gesamt-Tokenwert des Transaktionssystems
  • 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 [0006]
    • DE 102009034436 A1 [0006]
    • WO 2016200885 A1 [0007]

Claims (17)

  1. Ein Verfahren zum Registrieren von Token (T) eines elektronischen Transaktionssystems (TS), wobei jeder Token (T) des Transaktionssystems (TS) zumindest einen Tokenwert (v) und einen privaten Teil (r) eines tokenindividuellen Schlüsselpaars als Token-Elemente aufweist, mit den Verfahrensschritten: - Empfangen, in einem Tokenreferenz-Register (TRR) des Transaktionssystems (TS), einer Registrieranfrage (RA) aufweisend zumindest eine einem Token (T) des Transaktionssystems (TS) eindeutig zugeordnete Tokenreferenz (TR), wobei die Tokenreferenz (TR) zumindest den Tokenwert (v) des Tokens (T) und einen öffentlichen Teil (R) des tokenindividuellen Schlüsselpaars als Tokenreferenz-Elemente aufweist, wobei der öffentliche Teil (R) des tokenindividuellen Schlüsselpaars durch Anwenden einer kryptografischen Einwegfunktion auf den privaten Teil (r) des tokenindividuellen Schlüsselpaars des Tokens (T) erhalten wurde, - Verifizieren, durch eine Verifiziereinheit (2) des Tokenreferenz-Registers (TRR), ob die zumindest eine Tokenreferenz (TR) der empfangenen Registrieranfrage (RA) in dem Tokenreferenz-Register (TRR) gespeichert ist, und - Speichern der zumindest einen Tokenreferenz (TR) in einer Speichereinheit (1) des Tokenreferenz-Registers (TRR) zum Registrieren des dieser Tokenreferenz (TR) eindeutig zugeordneten Tokens (T) im Transaktionssystem (TS), wenn im Verifizieren-Schritt festgestellt wird, dass die zumindest eine Tokenreferenz (TR) der empfangenen Registeranfrage (RA) nicht im Tokenreferenz-Register (TRR) gespeichert ist.
  2. Das Verfahren nach Anspruch 1, wobei im Verifizieren-Schritt durch die Verifiziereinheit (2) des Tokenreferenz-Registers (2) zudem festgestellt wird: - ob die Tokenreferenz (TR) in der empfangenen Registrieranfrage (RA) einem Token (T) zugeordnet werden kann; und/oder - ob die empfangene Registrieranfrage (RA) syntaktisch korrekt ist; und/oder; und/oder - ob eine Summe von Tokenwerte (v) aller Tokenreferenzen (TR) innerhalb der Registrieranfrage (RA) null ist.
  3. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei der öffentliche Schlüsselteil (R) des tokenindividuellen Schlüsselpaars der Tokenreferenz (TR) zugleich ein Datenbankindex im Tokenreferenz-Register (TRR) ist.
  4. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die empfangene Registrieranfrage (RA) mit dem privaten Teil (r) des tokenindividuellen Schlüsselpaars signiert ist, um eine Zuordnung von der Tokenreferenz (TR) zu dem Token (T) verifizieren zu können.
  5. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei das Tokenreferenz-Register (TRR) zudem aufweist: - die oder mehrere Speichereinheiten (1) zum Abspeichern von Tokenreferenzen (TR) zum Registrieren der Token (T) im Transaktionssystem (TS); und/oder - die oder mehrere Verifiziereinheiten (2) zum Verifizieren empfangener Registrieranfragen (RA); und/oder - eine Prüfeinheit (3) zum Prüfen einer Summe aller Tokenwerte (v) des Transaktionssystems (TS); und/oder - eine Neuregistriereinheit (4) zum Registrieren von neuen Token (T) oder von gelöschten Token (T).
  6. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tokenreferenz (TR) zumindest eines der weiteren Tokenreferenz-Elemente aufweist: - einen Zählwert, - eine Identität einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit, und/oder - ein Pseudonym einer Teilnehmereinheit oder eines Besitzers der Teilnehmereinheit.
  7. Das Verfahren nach einem der vorhergehenden Ansprüche, wobei die Registrieranfrage (RA) von einer Teilnehmereinheit (TE) versendet wurde.
  8. Das Verfahren nach Anspruch 7, wobei die Registrieranfrage (RA) eine Aufteilung eines Tokens (Ta) betrifft und bevorzugt weist die Registrieranfrage (RA) eine Tokenreferenz (TRa) des aufzuteilenden Tokens (Ta) und jeweils eine Tokenreferenz (TRb, TRc) der aufgeteilten Token (Tb, Tc) auf.
  9. Das Verfahren nach Anspruch 8, wobei zum Aufteilen des Tokens (Ta) in einer Teilnehmereinheit (TE) die folgenden Verfahrensschritte durchgeführt werden: - Erzeugen eines neuen privaten Teils (rb) eines tokenindividuellen Schlüsselpaars für einen ersten aufgeteilten Token (Tb), - Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rb) zum Erhalten eines entsprechenden öffentlichen Teils (Rb) des tokenindividuellen Schlüsselpaars für den ersten aufgeteilten Token (Tb); - Erzeugen eines neuen privaten Teils (rc) eines tokenindividuellen Schlüsselpaars für einen zweiten aufgeteilten Token (Tc); - Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rc) zum Erhalten eines entsprechenden öffentlichen Teils (Rc) des tokenindividuellen Schlüsselpaars für den zweiten aufgeteilten Token (Tc); - Aufteilen des Tokenwerts (va) in einen ersten Tokenteilwert (vb) und in einen zweiten Tokenteilwert (vc), wobei die Summe aus dem ersten Tokenteilwert (vb) und dem zweiten Tokenteilwert (vc) dem Tokenwert (va) des aufzuteilenden Tokens (Ta) entspricht; - Erzeugen einer Tokenreferenz (TRb) für den ersten aufgeteilten Token (Tb) aufweisend den ersten Tokenteilwert (vb) und den öffentlichen Teil (Rb) des tokenindividuellen Schlüsselpaars des ersten aufgeteilten Tokens (Tb); - Erzeugen einer Tokenreferenz (TRc) für den zweiten aufgeteilten Token (Tc) aufweisend den zweiten Tokenteilwert (vc) und den öffentlichen Teil (Rc) des tokenindividuellen Schlüsselpaars des zweiten aufgeteilten Tokens (Tc); und - Erstellen der Registrieranfrage (RA) unter Verwendung der Tokenreferenz (TRa) des aufzuteilenden Tokens (Ta), der Tokenreferenz (TRb) für den ersten aufgeteilten Token (Tb) und der Tokenreferenz (TRe) für den zweiten aufgeteilten Token (Tc).
  10. Das Verfahren nach einem der Ansprüche 7 bis 9, wobei die Registrieranfrage (RA) eine Umschaltung eines umzuschaltenden Tokens (Tg) betrifft und bevorzugt weist die Registrieranfrage (RA) eine Tokenreferenz (TRg) des umzuschaltenden Tokens (Tg) auf.
  11. Das Verfahren nach Anspruch 10, wobei zum Umschalten des Tokens (Tg) in einer Teilnehmereinheit (TE) die folgenden Verfahrensschritte durchgeführt werden: - Erzeugen eines neuen privaten Teils (rh) eines tokenindividuellen Schlüsselpaars, - Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rh) zum Erhalten eines öffentlichen Teils (Rh) des tokenindividuellen Schlüsselpaars für den umgeschalteten Token (Th); - Erstellen der Registrieranfrage (RA) unter Verwendung der Tokenreferenz (TRg) für den umzuschaltenden Token (Tg) und den öffentlichen Teil (Rh) des tokenindividuellen Schlüsselpaars für den umgeschalteten Token (Th).
  12. Das Verfahren nach einem der Ansprüche 7 bis 11, wobei die Registrieranfrage (RA) ein Verbinden von zumindest zwei Token (Td, Te) betrifft und bevorzugt eine Tokenreferenz (TRf) des verbundenen Tokens (Tf) und jeweils eine Tokenreferenz (TRd, TRe) der zu verbindenden Token (Td, Te) aufweist.
  13. Das Verfahren nach Anspruch 12, wobei zum Verbinden des Tokens (Tf) in einer Teilnehmereinheit (TE) die folgenden Verfahrensschritte durchgeführt werden: - Erzeugen eines neuen privaten Teils (rf) eines tokenindividuellen Schlüsselpaars, - Anwenden einer kryptografischen Funktion auf den neuen privaten Teil (rf) zum Erhalten eines entsprechenden öffentlichen Teils (Rf) des tokenindividuellen Schlüsselpaars für den verbundenen Token (Tf); - Berechnen des Tokenwerts (vf) für den verbundenen Token (Tf) durch Bilden der Summe aus den jeweiligen Tokenwerten (vd, ve) der zu verbindenden Token (Td, Te); - Erzeugen einer Tokenreferenz (TRf) für den verbundenen Token (Tf) aufweisend den berechneten Tokenwert (vf) und den öffentlichen Teil (Rf) des tokenindividuellen Schlüsselpaars für den verbundenen Token (Tf); und - Erstellen der Registrieranfrage (RA) unter Verwendung jeder Tokenreferenz (TRd, TRe) der zu verbindenen Token (Td, Te) und der Tokenreferenz (TRf) für den verbundenen Token (Tf).
  14. Das Verfahren nach einem der vorhergehenden Ansprüche 1 bis 6, wobei die Registrieranfrage (RA) von einem Tokenherausgeber (TH) versendet wurde und wobei die Registrieranfrage (RA) ein Erstellen eines Tokens (T) oder ein Löschen eines Tokens (T) betrifft.
  15. Ein Tokenreferenz-Register (TRR) für ein Transaktionssystem (TS), eingerichtet zum Durchführen der Verfahrensschritte nach einem der vorhergehenden Ansprüche.
  16. Das Tokenreferenz-Register (TRR) nach Anspruch 15, aufweisend: - zumindest eine Speichereinheit (1) zum Speichern von Tokenreferenzen (TR) zum Registrieren von Token (T) im Transaktionssystem (TS); - eine Prüfeinheit (3) zum Prüfen von empfangenen Registrieranfragen (RA); - zumindest eine Verifiziereinheit (2) zum Verifizieren, ob eine Tokenreferenz (TR) einer empfangenen Registrieranfrage (RA) in dem Tokenreferenz-Register (TRR) gespeichert ist - eine Neuregistriereinheit (4) zum Registrieren von von einem Tokenherausgeber (TH) neu generierten Token (T) oder von von einem Tokenherausgeber (TH) gelöschten Token (T).
  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 Teilnehmereinheiten (TE), eingerichtet zum direkten Austausch von Token (T) untereinander.
DE102021004020.1A 2021-08-04 2021-08-04 Verfahren zum registrieren von token eines elektronischen transaktionssystems Withdrawn DE102021004020A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE102021004020.1A DE102021004020A1 (de) 2021-08-04 2021-08-04 Verfahren zum registrieren von token eines elektronischen transaktionssystems
BR112024002177A BR112024002177A2 (pt) 2021-08-04 2022-07-12 Elemento seguro, método para registrar tokens e registro de referência de token
US18/681,044 US20240275600A1 (en) 2021-08-04 2022-07-12 Secure element, method for registering tokens, and token reference register
CN202280053895.8A CN117916735A (zh) 2021-08-04 2022-07-12 安全元件、注册令牌的方法和令牌参考注册器
EP22744114.4A EP4381408A1 (de) 2021-08-04 2022-07-12 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
PCT/EP2022/025325 WO2023011756A1 (de) 2021-08-04 2022-07-12 Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021004020.1A DE102021004020A1 (de) 2021-08-04 2021-08-04 Verfahren zum registrieren von token eines elektronischen transaktionssystems

Publications (1)

Publication Number Publication Date
DE102021004020A1 true DE102021004020A1 (de) 2023-02-09

Family

ID=82611281

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021004020.1A Withdrawn DE102021004020A1 (de) 2021-08-04 2021-08-04 Verfahren zum registrieren von token eines elektronischen transaktionssystems

Country Status (6)

Country Link
US (1) US20240275600A1 (de)
EP (1) EP4381408A1 (de)
CN (1) CN117916735A (de)
BR (1) BR112024002177A2 (de)
DE (1) DE102021004020A1 (de)
WO (1) WO2023011756A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4425405A1 (de) 2023-03-01 2024-09-04 Giesecke+Devrient advance52 GmbH Sicherer dienstanbieter, sichere geldbörse, verfahren zur ausgabe einer oder mehrerer sicherer geldbörsen
EP4432191A1 (de) 2023-03-14 2024-09-18 Giesecke+Devrient advance52 GmbH Sichere tokenausgebereinheit, sichere dienstanbietereinheit, elektronisches zahlungstransaktionssystem, verfahren zur bereitstellung neuer token, verfahren zum empfangen alter token

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080147563A1 (en) 2006-12-14 2008-06-19 Institute For Information Industry System, method, and computer readable medium for micropayment with varying denomination
US7555460B1 (en) 2000-06-05 2009-06-30 Diversinet Corp. Payment system and method using tokens
US20090198617A1 (en) 2007-07-27 2009-08-06 Ntt Docomo, Inc. Method and apparatus for performing delegated transactions
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
WO2016065390A1 (en) 2014-10-31 2016-05-06 In4Ma Pty Ltd Electronic money, method of producing electronic money and transaction method using electronic money
WO2016200885A1 (en) 2015-06-08 2016-12-15 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
US20170163617A1 (en) 2015-12-04 2017-06-08 Prasanna Laxminarayanan Unique code for token verification
US20170293899A1 (en) 2016-04-12 2017-10-12 Digicash Pty Ltd. Digital value token processing systems and methods having improved security and scalability

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102305825B1 (ko) * 2014-10-31 2021-09-27 삼성에스디에스 주식회사 토큰을 이용한 결제 방법 및 그 장치
US11037162B2 (en) * 2018-05-14 2021-06-15 Visa International Service Association System, method, and computer program product for determining an event in a distributed data system
DE102019002732A1 (de) 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7555460B1 (en) 2000-06-05 2009-06-30 Diversinet Corp. Payment system and method using tokens
US20080147563A1 (en) 2006-12-14 2008-06-19 Institute For Information Industry System, method, and computer readable medium for micropayment with varying denomination
US20090198617A1 (en) 2007-07-27 2009-08-06 Ntt Docomo, Inc. Method and apparatus for performing delegated transactions
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
WO2016065390A1 (en) 2014-10-31 2016-05-06 In4Ma Pty Ltd Electronic money, method of producing electronic money and transaction method using electronic money
WO2016200885A1 (en) 2015-06-08 2016-12-15 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
US20170163617A1 (en) 2015-12-04 2017-06-08 Prasanna Laxminarayanan Unique code for token verification
US20170293899A1 (en) 2016-04-12 2017-10-12 Digicash Pty Ltd. Digital value token processing systems and methods having improved security and scalability

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4425405A1 (de) 2023-03-01 2024-09-04 Giesecke+Devrient advance52 GmbH Sicherer dienstanbieter, sichere geldbörse, verfahren zur ausgabe einer oder mehrerer sicherer geldbörsen
EP4432191A1 (de) 2023-03-14 2024-09-18 Giesecke+Devrient advance52 GmbH Sichere tokenausgebereinheit, sichere dienstanbietereinheit, elektronisches zahlungstransaktionssystem, verfahren zur bereitstellung neuer token, verfahren zum empfangen alter token

Also Published As

Publication number Publication date
BR112024002177A2 (pt) 2024-04-30
US20240275600A1 (en) 2024-08-15
WO2023011756A1 (de) 2023-02-09
EP4381408A1 (de) 2024-06-12
CN117916735A (zh) 2024-04-19

Similar Documents

Publication Publication Date Title
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
DE69022424T2 (de) Nichtablehnung in Rechnernetzwerken.
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
WO2020212331A1 (de) Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP4381408A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102020004121A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
WO2022200035A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
DE102020004116A1 (de) Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
WO2023011761A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
EP4111399B1 (de) Verfahren, endgerät, überwachungsinstanz sowie bezahlsystem zum verwalten von elektronischen münzdatensätzen
EP4179489A1 (de) Verfahren, endgerät sowie münzregister zum übertragen von elektronischen münzdatensätzen
EP4111347B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021002329A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102022002780A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102022000857B3 (de) Verfahren zur sicheren Identifizierung einer Person durch eine Verifikationsinstanz
DE102022002518A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE10061102B4 (de) System zur Statusabfrage von digitalen Zertifikaten
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE102022130483A1 (de) Verfahren zum beglaubigen eines hardware-wallets einer blockchain

Legal Events

Date Code Title Description
R163 Identified publications notified
R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT ADVANCE52 GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT GESELLSCHAFT MIT BESCHRAENKTER HAFTUNG, 81677 MUENCHEN, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee