CH716505B1 - System und Verfahren zum Bereitstellen von kryptographischer Asset-Transaktionen, Hardware-Genehmigungsterminal, Backend-Server und Computerprogrammprodukt. - Google Patents

Abstract

Die Erfindung betrifft ein System (100) zur Durchführung kryptographischer Asset-Transaktionen. Das System (100) ist so ausgestaltet, dass es mit einem Hardware-Sicherheitsmodul (40) kommunizieren kann. Das System (100) umfasst ein Client-Gerat (10), das so konfiguriert ist, dass es eine Frontend-Anwendung (11) ausführt, einen Backend-Server (20), der so konfiguriert ist, dass er eine Backend-Anwendung (21) ausführt, und eine Vielzahl von Hardware-Genehmigungsterminals (30). Der Backend-Server (20) ist so konfiguriert, dass er eine Genehmigungslogik für eine Quell-Assetadresse vom Hardware-Sicherheitsmodul (40) empfängt. Der Backend-Server (20) ist so konfiguriert, dass er die Transaktionsanforderung und die korrespondierende Genehmigungslogik an die mit der Genehmigungslogik verknüpften Hardware-Genehmigungsterminals (30) sendet. Die Hardware-Genehmigungsterminals (30) sind so konfiguriert, dass sie die Genehmigungslogik mit Hilfe des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40) verifizieren und dem Hardware-Sicherheitsmodul (40) signierte Transaktionsgenehmigungen, die den Namen des Asset-Adressschlüssels und die Transaktionsanforderung umfassen, zur Verfügung stellen. Der Backend-Server (20) empfangt nach der Verifizierung die signierte Transaktion vom Hardware-Sicherheitsmodul (40) und liefert die signierte Transaktion an einen Blockchain-Knoten. Ebenso betrifft die Erfindung eine Hardware-Genehmigungsterminal, einen Backend-Server, ein Verfahren zum Durchführen kryptographischer Asset-Transaktionen und ein Computerprogrammprodukt zum Betreiben einer Backend-Anwendung.

Description

Technisches Gebiet

[0001] Die vorliegende Erfindung bezieht sich auf ein System zur Durchführung kryptographischer Asset-Transaktionen. Weitere Aspekte beziehen sich auf ein Verfahren zur Durchführung kryptographischer Asset-Transaktionen und ein Computerprogramm zur Durchführung kryptographischer Asset-Transaktionen.

Hintergrund

[0002] Kryptographische Assets umfassen z.B. kryptographische Währungen wie Bitcoin, Ether (ETH), Bitcoin Cash (BCH) oder IOTA sowie kryptographische Fonds und Token, die Off-Chain-Assets darstellen. Solche kryptographischen Assets, die oft auch als Krypto-Assets bezeichnet werden, bilden ein digitales Asset, welches ein Tauschmittel darstellt, das Kryptographie zur Sicherung von Transaktionen und zur Kontrolle der Schaffung zusätzlicher Einheiten verwendet. Kryptographische Assets können auch als virtuelle Assets bezeichnet werden.

[0003] Krypto-Assets verwenden dezentrale Steuerungsverfahren über eine Blockchain, die eine öffentliche Transaktionsdatenbank ist, die als verteiltes Ledger arbeitet, oder andere global konsistente Datenstrukturen (z.B. ein Tangle).

[0004] Solche kryptographischen Assets gewinnen immer mehr an Interesse, z.B. angesichts ihrer geringen Kosten für die Übertragung von Assets.

[0005] Die sichere Speicherung solcher Assets ist jedoch eine Herausforderung, insbesondere die Speicherung der privaten Schlüssel von kryptographischen Asset-Adressen, z.B. von Bitcoin-Adressen.

[0006] Eine übliche Lösung ist es, die privaten Schlüssel völlig offline zu speichern.

[0007] Einer solchen Lösung mangelt es jedoch an Flexibilität und sie eignet sich nicht für alle Geschäftsanforderungen.

[0008] Daher besteht ein Bedarf an alternativen Systemen und Verfahren.

Darstellung der Erfindung

[0009] Dementsprechend besteht ein Problem eines Aspekts der Erfindung darin, ein System bereitzustellen, mit dem kryptographische Asset-Transaktionen auf sichere Weise durchgeführt werden können.

[0010] Insbesondere befassen sich Aspekte der Erfindung mit dem Problem, ein System zur Durchführung kryptographischer Asset-Transaktionen bereitzustellen, die eine sichere Speicherung kryptographischer Assets beinhalten.

[0011] Darüber hinaus befassen sich Aspekte der Erfindung mit dem Problem, ein System zur Durchführung kryptographischer Asset-Transaktionen bereitzustellen, das die Genehmigung durch mehrere Benutzer erleichtert.

[0012] Entsprechend einem ersten Aspekt der Erfindung wird ein System zur Durchführung kryptographischer Asset-Transaktionen bereitgestellt. Das System umfasst ein Client-Gerät, das so konfiguriert ist, dass es eine Frontend-Anwendung ausführt, einen Backend-Server, der so konfiguriert ist, dass er eine Backend-Anwendung ausführt, und eine Vielzahl von Hardware-Genehmigungsterminals. Das System ist für die Kommunikation, den Betrieb und/oder die Interaktion mit einem Hardware-Sicherheitsmodul ausgelegt. Ein solches Hardware-Sicherheitsmodul, das mit einem System gemäss den Ausführungsformen der Erfindung interagieren kann, ist insbesondere so konfiguriert, dass es einen privaten Schlüssel des Hardware-Sicherheitsmoduls und eine Vielzahl von Asset-Adressdateien speichert, die einer kryptographischen Asset-Adresse entsprechen. Jede der Vielzahl von Asset-Adressdateien umfasst einen Asset-Adressschlüsselnamen, einen privaten Asset-Adressschlüssel und eine Genehmigungslogik. Die Genehmigungslogik kann eine Vielzahl von öffentlichen Genehmigungsschlüsseln umfassen.

[0013] Das System ist so konfiguriert, dass es durch die Vielzahl der Genehmigungs-Terminals einen öffentlichen Schlüssel des Hardware-Sicherheitsmoduls und einen oder mehrere private Genehmigungsschlüssel einer kryptographischen Asset-Transaktion speichert. Das System ist ferner so konfiguriert, dass es durch die Frontend-Anwendung eine Transaktionsanforderung zum Signieren einer kryptographischen Asset-Transaktion an den Backend-Server ausgibt. Die Transaktionsanforderung umfasst eine Quell-Assetadresse, insbesondere den Namen des Asset-Adressschlüssels, eine Ziel-Assetadresse und einen Asset-Transaktionswert. Das System ist so konfiguriert, dass es durch den Backend-Server die Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul anfordert. Der Backend-Server ist so konfiguriert, dass er die Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul empfängt. Der Backend-Server ist so konfiguriert, dass er die Transaktionsanforderung und die korrespondierende Genehmigungslogik an ein oder mehrere Genehmigungsterminals sendet, insbesondere an die Genehmigungsterminals, die mit den Genehmigungsregeln verknüpft sind. Bei den mit den Genehmigungsregeln verknüpften Genehmigungsterminals kann es sich insbesondere um Terminals handeln, an denen die Genehmigenden für die jeweilige Transaktion angemeldet sind und/oder über ein Konto verfügen. Die Genehmigungsterminals sind so konfiguriert, dass sie die Genehmigungslogik mit Hilfe des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls verifizieren und signierte Transaktionsgenehmigungen an den Backend-Server senden. Die signierten Transaktionsgenehmigungen bestehen aus dem Asset-Adressschlüsselnamen und der Transaktionsanforderung. Der Backend-Server ist so konfiguriert, dass er die signierten Transaktionsgenehmigungen zur Verifizierung an das Hardware-Sicherheitsmodul weiterleitet. Das Hardware-Sicherheitsmodul verifiziert dann die erhaltenen Transaktionsgenehmigungen gemäss der für die entsprechende Asset-Adresse gespeicherten Genehmigungslogik und signiert nach erfolgreicher Verifizierung die Transaktion mit dem entsprechenden privaten Asset-Adressschlüssel. Der Backend-Server empfängt die signierte Transaktion vom Hardware-Genehmigungsterminal. Der Backend-Server ist so konfiguriert, dass er die signierte Transaktion an einen Blockchain-Knoten bereitstellt, insbesondere sendet.

[0014] Ein solches System erlaubt es, kryptographische Asset-Transaktionen auf sichere Weise durchzuführen. Darüber hinaus beinhaltet eine solche Lösung eine sichere Speicherung der kryptographischen Assets im Hardware-Sicherheitsmodul. Insbesondere ermöglicht die Speicherung der Genehmigungslogik im Hardware-Sicherheitsmodul die sichere Implementierung von Mehrparteien-Genehmigungsschemata. Gemäss solchen Mehrparteien-Genehmigungsschemata sind für eine Transaktion zwei oder mehr Genehmigungen erforderlich. Darüber hinaus ist das Backend nicht an der Sicherheit der Lösung beteiligt. Insbesondere kann selbst in Fällen, in denen der Backend-Server und die Frontend-Anwendung kompromittiert werden, die Sicherheit der kryptographischen Assets dennoch gewährleistet werden. Dies hat den besonderen Vorteil, dass die Eigentümer der kryptographischen Assets dem Backend-Server nicht voll vertrauen müssen.

[0015] Je nach Ausführungsform kann die Vielzahl der Asset-Adressdateien auch eine Sperr- und/oder Entsperrlogik enthalten. Die Sperr- und/oder Entsperrlogik kann eine Vielzahl von öffentlichen Sperr- und/oder Entsperrschlüssein umfassen, die Personen zugewiesen werden, die berechtigt sind, eine Quell-Assetadresse und die korrespondierenden Schlüssel zu sperren.

[0016] Gemäss einer Ausführungsform ist das System ferner so konfiguriert, dass es bei Empfang einer Transaktionsanforderung durch die Genehmigungsterminals eine Zeitstempelanforderung an das Hardware-Sicherheitsmodul sendet und eine signierte Transaktionsanforderung einschliesslich eines Zeitstempels vom Hardware-Sicherheitsmodul empfängt. Die Genehmigungsterminals sind so konfiguriert, dass sie die signierte Transaktionsanforderung einschliesslich des Zeitstempels verifizieren. Der Zeitstempel kann für jede Transaktionsanforderung ein Signierfenster auslösen, während dem ein Hardware-Sicherheitsmodul berechtigt ist, eine Transaktionsanforderung zu signieren.

[0017] Der Zeitstempel kann von einer internen Uhr des Hardware-Sicherheitsmoduls abgeleitet werden.

[0018] Die Genehmigungslogik kann für jede kryptographische Asset-Adresse eine kombinatorische Logik aus einer Vielzahl von Genehmigungssignaturen definieren, die für die Genehmigung einer Transaktion der kryptographischen Asset-Adresse erforderlich sind.

[0019] Mit einer solchen kombinatorischen Logik kann eine Vielzahl von Genehmigungsregeln definiert werden. Insbesondere kann die kombinatorische Logik eine oder mehrere Kombinationen von Signaturen umfassen, die für die Genehmigung einer Transaktion erforderlich sind. Die erforderlichen Signaturen werden durch die öffentlichen Genehmigungsschlüssel definiert.

[0020] Gemäss einer Ausführungsform werden die privaten Genehmigungsschlüssel mit einem Passwort und einem Smartcard-Schlüssel verschlüsselt.

[0021] Dies ermöglicht eine sichere Speicherung der öffentlichen Genehmigungsschlüssel im Hardware-Genehmigungsterminal. Um Zugriff auf den privaten Genehmigungsschlüssel zu erhalten, muss der jeweilige Genehmigende seine Smartcard in das Hardware-Genehmigungsterminal eingeben und zusätzlich sein Passwort, z.B. eine PIN-Nummer, eingeben. Ein Hardware-Genehmigungsterminal kann mehrere private Genehmigungsschlüssel speichern, auf die einzeln mit einer entsprechenden Smartcard und einem Passwort, z.B. einer PIN-Nummer, zugegriffen werden kann. Ein typisches Beispiel wären 16 private Genehmigungsschlüssel pro Genehmigungsterminal.

[0022] Gemäss einer Ausführungsform ist das System ferner so konfiguriert, dass es von der Frontend-Anwendung eine Adresserzeugungsanforderung zur Erzeugung einer Asset-Adresse an den Backend-Server sendet. Die Adresserzeugungsanforderung umfasst einen Asset-Adressschlüsselnamen, einen Asset-Typ, eine Genehmigungslogik und eine Vielzahl von öffentlichen Genehmigungsschlüsseln der Genehmigungslogik. Der Backend-Server ist so konfiguriert, dass er eine Schlüsselerzeugungsanforderung an das Hardware-Sicherheitsmodul sendet, um ein asymmetrisches Schlüsselpaar zu erzeugen, das einen öffentlichen Asset-Adressschlüssel und einen privaten Asset-Adressschlüssel umfasst. Die Schlüsselerzeugungsanforderung umfasst den Asset-Adressschlüsselnamen, die Genehmigungslogik und die Vielzahl der öffentlichen Genehmigungsschlüssel der Genehmigungslogik. Das Hardware-Sicherheitsmodul kann dann das asymmetrische Schlüsselpaar erzeugen und den privaten Asset-Adressschlüssel des asymmetrischen Schlüsselpaares und die zugehörige Genehmigungslogik speichern, und der Backend-Server kann als Antwort den öffentlichen Asset-Adressschlüssel des asymmetrischen Schlüsselpaares erhalten. Der Backend-Server ist so konfiguriert, dass er der Frontend-Anwendung den Asset-Adressschlüsselnamen, den öffentlichen Asset-Adressschlüssel oder eine Ableitung des öffentlichen Asset-Adressschlüssels als kryptographische Asset-Adresse zur Verfügung stellt.

[0023] Mit einer solchen Ausgestaltung können neue kryptographische Asset-Adressen von der Frontend-Anwendung auf flexible Weise initiiert werden, einschliesslich einer sicheren Speicherung einer individuellen Zugriffslogik für jede kryptographische Asset-Adresse.

[0024] Gemäss einer Ausführungsform ist das System ferner so konfiguriert, dass es ein Verfahren zur Verifizierung der Asset-Adresse durchführt. Das Verfahren zur Verifizierung der Asset-Adresse umfasst das Senden einer Anforderung zur Überprüfung der Asset-Adresse durch die Frontend-Anwendung über den Backend-Server an das Hardware-Sicherheitsmodul und das Empfangen der Genehmigungslogik und des korrespondierenden öffentlichen Asset-Adressschlüssels, der mit dem privaten Schlüssel des Hardware-Sicherheitsmoduls signiert ist, durch das Hardware-Genehmigungsterminal über den Backend-Server. Das Verfahren zur Verifizierung der Asset-Adresse umfasst ferner die Durchführung einer Integritätsprüfung der empfangenen signierten Genehmigungslogik durch das Hardware-Genehmigungsterminal. Die Integritätsprüfung umfasst die Verifizierung der Signatur des Hardware-Sicherheitsmoduls und die Berechnung der entsprechenden Asset-Adresse aus dem empfangenen öffentlichen Schlüssel der Asset-Adresse. Das Verfahren zur Verifizierung der Asset-Adresse umfasst ferner das Anzeigen der vom Hardware-Genehmigungsterminal berechneten Asset-Adresse und der Genehmigungslogik durch das Hardware-Genehmigungsterminal auf einem Display des Hardware-Genehmigungsterminals zur Verifizierung durch einen Bediener.

[0025] Ein solches Verfahren zur Verifizierung von Asset-Adressen gewährleistet eine sichere Erzeugung von Asset-Adressen einschliesslich der entsprechenden Zugriffslogik. Im Falle eines kompromittierten Backends würde der Bediener ein böswilliges Verhalten mit Hilfe der Hardware-Genehmigungsterminals erkennen.

[0026] Gemäss Ausführungsformen ist die Vielzahl der Hardware-Genehmigungsterminals so konfiguriert, dass sie einen oder mehrere private Richtliniengenehmigungsschlüssel erzeugen und speichern und eine oder mehrere Richtlinien speichern, die mit den privaten Richtliniengenehmigungsschlüsseln verknüpft sind. Die eine oder mehrere Richtlinien können Signierungskriterien für eine automatische Signierung einer Transaktionsanforderung mit einem oder mehreren privaten Richtliniengenehmigungsschlüsseln festlegen. Die Signierungskriterien können einen oder mehrere vordefinierte Asset-Transaktionswerte einer Transaktion und/oder eine oder mehrere vordefinierte Ziel-Asset-Adressen umfassen.

[0027] Solche Richtliniengenehmigungsschlüssel können verwendet werden, um zusätzliche Flexibilität bei der Definition von Signierrichtlinien mit Hilfe der Hardware-Genehmigungsterminals zu schaffen. Insbesondere können solche in den Hardware-Genehmigungs-Terminals gespeicherten Signierrichtlinien dazu verwendet werden, automatische Signierprozeduren zu implementieren, die automatisch von den Hardware-Genehmigungs-Terminals ohne eine weitere Genehmigung durch einen menschlichen Genehmiger durchgeführt werden können.

[0028] Gemäss einer Ausführungsform ist der Backend-Server so konfiguriert, dass er eine erforderliche Anzahl von Transaktionsgenehmigungen, die gemäss der entsprechenden Genehmigungslogik erforderlich ist, von den Hardware-Genehmigungsterminals sammelt. Der Backend-Server ist ferner so konfiguriert, dass er die gesammelten Transaktionsgenehmigungen an das Hardware-Sicherheitsmodul weiterleitet, sobald die erforderliche Anzahl von Genehmigungen eingegangen ist.

[0029] Dadurch wird vermieden, dass Transaktionsgenehmigungsanforderungen bereits an das Hardware-Sicherheitsmodul gesendet werden, obwohl die erforderliche Anzahl von Genehmigungen noch nicht erreicht ist. Auf diese Weise wird unnötiger Datenverkehr zwischen dem Backend-Server und dem Hardware-Sicherheitsmodul vermieden. Da dem Backend-Server die jeweilige Genehmigungslogik bekannt ist, kann er aus der Genehmigungslogik die entsprechend erforderliche Anzahl von Genehmigungen ermitteln.

[0030] Ein Hardware-Sicherheitsmodul (HSM), das mit einem System gemäss den Ausführungsformen der Erfindung interagieren soll, kann allgemein als ein manipulationssicheres physisches Computergerät definiert werden, das hochsensible Daten schützt und verwaltet. Insbesondere können HSMs im Allgemeinen so definiert werden, dass sie kryptographische Aufgaben wie Schlüsselerzeugung, Kryptographie mit öffentlichem/privatem Schlüssel, Datenverschlüsselung und sichere Speicherung kryptographischer Daten übernehmen. Wie der Name impliziert, stellen konventionelle HSMs ihre Funktionalität über Hardware, d.h. Schaltungen, zur Verfügung. Je nach Ausführungsform werden umfangreiche komplexe Schaltungen verwendet, um die Funktions- und Speicheranforderungen des HSM zu implementieren.

[0031] Gemäss einer Ausführungsform ist das System ferner so konfiguriert, dass es einen sicheren Kommunikationskanal für eine sichere Kommunikation zwischen dem Backend-Server und dem Hardware-Sicherheitsmodul, für eine sichere Kommunikation zwischen dem Backend-Server und dem Frontend und für eine sichere Kommunikation zwischen dem Backend-Server und den Hardware-Genehmigungsterminals bereitstellt.

[0032] Entsprechend einem anderen Aspekt der Erfindung wird ein Hardware-Genehmigungsterminal für ein System nach dem ersten Aspekt bereitgestellt.

[0033] Gemäss einem anderen Aspekt der Erfindung wird ein Backend-Server für ein System gemäss dem ersten Aspekt bereitgestellt.

[0034] Entsprechend einem weiteren Aspekt der Erfindung wird ein Verfahren zur Durchführung kryptographischer Asset-Transaktionen mittels eines Systems des ersten Aspekts bereitgestellt.

[0035] Gemäss einem weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt zum Betrieb der Backend-Anwendung eines Systems zur Durchführung kryptographischer Asset-Transaktionen gemäss dem ersten Aspekt bereitgestellt. Das Computerprogrammprodukt umfasst ein computerlesbares Speichermedium mit darin enthaltenen Programmbefehlen, wobei die Programmbefehle durch die Backend-Anwendung eines Backend-Servers ausführbar sind, um den Backend-Server zu veranlassen, ein Verfahren auszuführen, das den Empfang einer Transaktionsanforderung von einer Frontend-Anwendung umfasst, um eine kryptographische Asset-Transaktion zu signieren, wobei die Transaktionsanforderung eine Quell-Assetadresse, insbesondere den Asset-Adressschlüsselnamen, eine Ziel-Assetadresse und einen Asset-Transaktionswert umfasst. Das Verfahren umfasst ferner ein Anfordern einer Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul, ein Empfangen der Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul, ein Senden der Transaktionsanforderung und der korrespondierenden Genehmigungslogik an die Hardware-Genehmigungsterminals und das Empfangen von signierten Transaktionsgenehmigungen von den Hardware-Genehmigungsterminals, wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen. Weitere Schritte umfassen eine Weiterleitung der signierten Transaktionsgenehmigungen an das Hardware-Sicherheitsmodul zur Verifizierung, ein Empfangen einer signierten Transaktion vom Hardware-Sicherheitsmodul und ein Bereitstellen der signierten Transaktion an einen Blockchain-Knoten.

[0036] Entsprechend einer Ausführungsform eines anderen Aspekts der Erfindung wird ein Computerprogrammprodukt für den Betrieb von Hardware-Genehmigungsterminals eines Systems zur Durchführung kryptographischer Asset-Transaktionen gemäss dem ersten Aspekt der Erfindung bereitgestellt. Das Computerprogrammprodukt umfasst ein computerlesbares Speichermedium mit darin enthaltenen Programmbefehlen, wobei die Programmbefehle durch die Hardware-Genehmigungsterminals ausführbar sind, um die Hardware-Genehmigungsterminals zu veranlassen, ein Verfahren durchzuführen, das die folgenden Schritte umfasst: Speichern eines öffentlichen Schlüssels des Hardware-Sicherheitsmoduls und eines oder mehrerer privater Genehmigungsschlüssel von Genehmigern einer kryptographischen Asset-Transaktion, Empfangen einer Transaktionsanforderung und der entsprechenden Genehmigungslogik vom Backend-Server und Verifizieren der Genehmigungslogik mittels des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls. Weitere Schritte umfassen ein Anzeigen der Transaktionsanforderung und der Genehmigungslogik auf einem Display des Hardware-Genehmigungsterminals, ein Empfangen einer Bestätigung der Transaktionsanforderung von Genehmigern, die mit dem Hardware-Genehmigungsterminal verknüpft sind, und das Senden von signierten Transaktionsgenehmigungen an den Backend-Server, wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen.

[0037] Merkmale und Vorteile eines Aspekts der Erfindung können gegebenenfalls auf die anderen Aspekte der Erfindung übertragen werden.

[0038] Weitere vorteilhafte Ausführungsformen sind sowohl in den abhängigen Ansprüchen als auch in der nachstehenden Beschreibung aufgeführt.

Kurze Beschreibung der Zeichnungen

[0039] Die Erfindung wird besser verstanden und andere als die oben genannten Ziele werden aus der folgenden detaillierten Beschreibung der Erfindung ersichtlich. Diese Beschreibung nimmt Bezug auf die beigefügten Zeichnungen, wobei: FIG. 1 zeigt ein beispielhaftes Blockdiagramm eines Systems zur Durchführung kryptographischer Asset-Transaktionen gemäss einer Ausführungsform der Erfindung; FIG. 2 zeigt ein Flussdiagramm eines Verfahrens zur Erstellung/Generierung einer kryptographischen Asset-Adresse mit Hilfe des Systems von FIG. 1; FIG. 3 zeigt ein Flussdiagramm eines Verfahrens zur Durchführung kryptographischer Asset-Transaktionen mit Hilfe des Systems von FIG. 1; FIG. 4 zeigt eine beispielhafte Ausführungsform einer Asset-Adressdatei, die in einem Hardware-Sicherheitsmodul gespeichert ist; FIG. 5 zeigt eine beispielhafte Ausführungsform einer weiteren Asset-Adressdatei, die in einem Hardware-Sicherheitsmodul gespeichert ist; FIG. 6 zeigt eine beispielhafte Ausführungsform einer weiteren Asset-Adressdatei, die in einem Hardware-Sicherheitsmodul gespeichert ist; FIG. 7 zeigt ein Flussdiagramm eines Verfahrens zur Einführung oder Initialisierung von Richtliniengenehmigungsschlüsseln; FIG. 8a zeigt ein Verfahren zur Durchführung automatischer Signaturen mit den Richtliniengenehmigungsschlüsseln durch ein Hardware-Genehmigungsterminal; und FIG. 8b zeigt einige Teilschritte des Verfahrens von FIG. 8a im Detail.

Weg(e) zur Ausführung der Erfindung

[0040] In der nachfolgenden Beschreibung können die folgenden Abkürzungen verwendet werden: Privater Genehmigungsschlüssel (SKapp) Öffentlicher Genehmigungsschlüssel (PKapp) Privater Schlüssel des Hardware-Sicherheitsmoduls (SKHSM) Öffentlicher Schlüssel des Hardware-Sicherheitsmoduls (PKHSM) Kryptographische Asset-Transaktion CAA Asset-Adressschlüsselname (namekaa) Privater Asset-Adressschlüssel (SKaa) Öffentlicher Asset-Adressschlüssel (PKaa) Asset-Adresse(AA) Genehmigungslogik (AL) Kombinatorische Logik (CL) Genehmigungsregeln (AR) Zeitstempel (TP) Signatur (sign) Signatur-Fenster (SW) Asset-Adressdatei (AAF) Richtlinie (P) Öffentlicher Richtliniengenehmigungsschlüssel (PKpak) Privater Richtliniengenehmigungsschlüssel (SKpak)

[0041] FIG. 1 zeigt ein beispielhaftes Blockdiagramm eines Systems 100 zur Durchführung kryptographischer Asset-Transaktionen nach einer Ausführungsform der Erfindung. Das System besteht aus einem Frontend-Gerät 10, das für die Ausführung einer Frontend-Anwendung 11 konfiguriert ist. Das Frontend-Gerät 10 kann jedes geeignete Gerät sein, das vom Benutzer der Frontend-Anwendung bedient wird. Bei der Frontend-Anwendung 11 kann es sich insbesondere um ein Computerprogramm handeln, das einem Benutzer des Systems Zugang zum System bietet, insbesondere zur Speicherung kryptographischer Assets und zur Durchführung kryptographischer Asset-Transaktionen. Bei den Benutzern der Frontend-Anwendung 11 kann es sich insbesondere um bestimmte Unternehmen oder Betriebe, z.B. Banken oder Broker, handeln. Das System 100 umfasst ferner einen Backend-Server 20, der für die Ausführung einer Backend-Anwendung 21 konfiguriert ist.

[0042] Das System 100 umfasst ferner eine Vielzahl von Hardware-Genehmigungsterminals 30 mit einem Kryptoprozessor 31 und einem sicheren Speicher 32. Der Kryptoprozessor 31 kann einen Schlüsselgenerator zur Erzeugung asymmetrischer Schlüsselpaare enthalten. Die Genehmigungsterminals 30 umfassen ferner ein Display 33.

[0043] Das System 100 umfasst ferner ein Hardware-Sicherheitsmodul 40 mit einem Kryptoprozessor 41 und einem sicheren Speicher 42. Der Kryptoprozessor 41 kann einen Schlüsselgenerator zur Erzeugung asymmetrischer Schlüsselpaare enthalten.

[0044] Die Backend-Anwendung 21 kann insbesondere als Computerprogramm ausgebildet sein, das als Schnittstelle zwischen der Frontend-Anwendung 11, dem Hardware-Sicherheitsmodul 40 und der Vielzahl von Hardware-Genehmigungsterminals 30 dient. Beispielsweise empfängt die Backend-Anwendung 21 Nachrichten von den Hardware-Genehmigungsterminals 40 und dem Hardware-Sicherheitsmodul 30 und leitet Nachrichten an das Hardware-Sicherheitsmodul bzw. die Hardware-Genehmigungsterminals 30 weiter. Darüber hinaus führt die Backend-Anwendung administrative und buchhalterische Aufgaben für das System 100 aus.

[0045] Das Hardware-Sicherheitsmodul 40 ist ein manipulationssicheres Gerät, das es ermöglicht, kryptographische Schlüssel sicher zu erzeugen, zu speichern und zu verwalten und kryptographische Transaktionen durchzuführen, insbesondere kryptographische Signaturen gemäss einer vordefinierten Sicherheitsstufe.

[0046] Das Hardware-Sicherheitsmodul 40 kann z.B. eine Sicherheit gemäss der Federal Information Processing Standard (FIPS) Publikation 140-2 bieten, die ein Computersicherheitsstandard der US-Regierung ist, der zur Genehmigung kryptographischer Module verwendet wird. Gemäss Ausführungsformen ist das Hardware-Sicherheitsmodul 40 nach FIPS 140-2 von mindestens Stufe 1, vorzugsweise Stufe 2, noch bevorzugter Stufe 3 und noch bevorzugter Stufe 4 oder mit einer Sicherheitsstufe gleichwertiger Standards zertifiziert.

[0047] Die Vielzahl der Genehmigungsterminals 30 sind so konfiguriert, dass sie einen öffentlichen Schlüssel PKHSMdes Hardware-Sicherheitsmoduls 40 speichern und einen oder mehrere private Genehmigungsschlüssel SKapp1, SKapp2, ..., SKappnvon Genehmigern einer kryptographischen Asset-Transaktion erzeugen und speichern. Die Genehmigenden der kryptographischen Asset-Transaktionen können z.B. Mitarbeiter der Entität sein, die das System 100 für die Speicherung und den Handel ihrer kryptographischen Assets verwendet. Die privaten Genehmigungsschlüssel SKapp1, SKapp2, ..., SKappnwerden jeweils einem einzelnen Genehmigenden zugewiesen und mit Hilfe eines Passworts und eines Smartcard-Schlüssels gesichert, insbesondere verschlüsselt. Dementsprechend muss eine Genehmigende, welche auf ihren privaten Schlüssel zugreifen will, eine Smartcard mit dem Smartcard-Schlüssel, insbesondere einen geheimen Schlüssel eines asymmetrischen Schlüsselpaares, in das Hardware-Genehmigungsterminal 30 eingeben. Darüber hinaus muss die Genehmigende ein Passwort, z.B. eine PIN-Nummer, eingeben. Erst nach einer solchen Doppel-Authentifizierung kann die jeweilige Genehmigende auf ihren privaten Genehmigungsschlüssel zugreifen und eine auf dem Display 33 angezeigte Transaktionsgenehmigungsanforderung unterschreiben.

[0048] Gemäss Ausführungsformen ist die Vielzahl der Genehmigungsterminals 30 so konfiguriert, dass sie einen oder mehrere private Richtliniengenehmigungsschlüssel SKpak1, SKpak2, ..., SKpaknfür kryptographische Asset-Transaktionen erzeugen und speichern. Entsprechend diesen Ausführungsformen werden die entsprechenden öffentlichen Richtliniengenehmigungsschlüssel PKpak1, PKpak2, ..., PKpaknin den Asset-Adressdateien AAF des Hardware-Sicherheitsmoduls 40 gespeichert. Die privaten Richtliniengenehmigungsschlüssel und die öffentlichen Richtliniengenehmigungsschlüssel werden allgemein als Richtliniengenehmigungsschlüssel bezeichnet. Darüber hinaus speichern die Hardware-Genehmigungsterminals 30 eine oder mehrere Richtlinien P, die mit den privaten Richtliniengenehmigungsschlüsseln assoziiert sind. Die eine oder mehreren Richtlinien P können z.B. Signierkriterien für eine automatische Signierung einer Transaktionsanforderung mit einem oder mehreren privaten Richtliniengenehmigungsschlüsseln festlegen. Die Signierkriterien können z.B. einen oder mehrere vordefinierte Asset-Transaktionswerte einer Transaktion und/oder eine oder mehrere vordefinierte Ziel-Assetadressen angeben.

[0049] Die Richtliniengenehmigungsschlüssel können verwendet werden, um zusätzliche Flexibilität bei der Definition von Signierrichtlinien mit Hilfe der Hardware-Genehmigungsterminals 30 zu schaffen. Gemäss Ausführungsformen können solche Signierrichtlinien P insbesondere dazu verwendet werden, Signierrichtlinien P zu definieren, die vom Transaktionswert der Assets einer Transaktion abhängen. Darüber hinaus können solche Richtliniengenehmigungsschlüssel verwendet werden, um automatische Signierprozeduren zu implementieren, die automatisch durch die Hardware-Genehmigungsterminals 30 ohne weitere Genehmigung durch einen menschlichen Genehmiger durchgeführt werden können. So können z.B. sehr kleine Transaktionswerte, die z.B. einem Betrag von weniger als 100 CHF entsprechen, automatisch mit einem Richtliniengenehmigungsschlüssel signiert werden.

[0050] Als Beispiel kann eine Signierrichtlinie P festlegen, dass die Hardware-Genehmigungsterminals 30 automatisch mit einem privaten Richtliniengenehmigungsschlüssel SKpakxsignieren sollen, wenn der Wert der Asset-Transaktion unter einem vordefinierten Betrag liegt. Als ein weiteres Beispiel kann eine Signierrichtlinie P festlegen, dass die Hardware-Genehmigungsterminals 30 automatisch mit einem privaten Richtliniengenehmigungsschlüssel SKpakxfür eine oder mehrere vordefinierte Ziel-Assetadressen signieren sollen.

[0051] Dies wird im Folgenden unter Bezugnahme auf FIG. 6 näher erläutert.

[0052] Das Hardware-Sicherheitsmodul 40 ist so konfiguriert, dass es seinen eigenen privaten Schlüssel SKHSMerzeugt und speichert. Darüber hinaus ist das Hardware-Sicherheitsmodul so konfiguriert, dass es eine Vielzahl von Asset-Adressdateien AAF speichert, die einer kryptographischen Asset-Adresse AA entsprechen. Jede der Vielzahl von Asset-Adressdateien AAF umfasst einen Asset-Adressschlüsselnamen „namekaa“ und eine Genehmigungslogik AL, die eine Vielzahl von öffentlichen Genehmigungsschlüsseln PKapp1, PKapp2... PKappnund ein oder mehrere Signierfenster SW1, SW2, ... SWnumfasst. Die Asset-Adressdateien AAF umfassen ferner einen privaten Asset-Adressschlüssel SKaaund optional den korrespondierenden öffentlichen Asset-Adressschlüssel PKaa.

[0053] Mit einer solchen Einrichtung kann das Hardware-Sicherheitsmodul 40 Nachrichten, die mit den privaten Genehmigungsschlüsseln SKappsigniert sind, mit Hilfe des entsprechenden öffentlichen Genehmigungsschlüssels PKappverifizieren, der in der AL des AAF in dem Hardware-Sicherheitsmodul 40 gespeichert ist. Und die Hardware-Genehmigungsterminals 30 können Nachrichten, die mit dem privaten Schlüssel SKHSMdes Hardware-Sicherheitsmoduls 40 signiert sind, mittels des korrespondierenden öffentlichen Schlüssels PKHSMdes Hardware-Sicherheitsmoduls 40, der in den Hardware-Genehmigungsterminals 30 gespeichert ist, verifizieren.

[0054] FIG. 2 zeigt ein Flussdiagramm 200 eines Verfahrens zur Erstellung einer kryptographischen Asset-Adresse mit Hilfe des Systems 100 von FIG. 1.

[0055] In einem Schritt 201 sendet die Frontend-Anwendung 11 eine Adresserzeugungsanforderung zur Erzeugung einer kryptografischen Asset-Adresse an die Backend-Anwendung 21. Die Adresserzeugungsanforderung besteht aus einem Asset-Adressschlüsselnamen namekaa, der später als Referenzname für die Frontend-Anwendung 11 dient. Darüber hinaus umfasst die Adresserzeugungsanforderung einen Asset-Typ, z.B. die jeweilige Krypto-Währung, für die die Asset-Adresse erstellt werden soll. Die Währung kann z.B. Bitcoin, ETH, BCH oder IOTA sein. Darüber hinaus umfasst die Adresserzeugungsanforderung eine Genehmigungslogik AL. Die Genehmigungslogik AL besteht aus einer Vielzahl von öffentlichen Genehmigungsschlüsseln PKappund einem oder mehreren Signierfenstern SW.

[0056] In einem Schritt 202 sendet der Backend-Server 20 eine Schlüsselerzeugungsanforderung an das Hardware-Sicherheitsmodul 40, um ein asymmetrisches Schlüsselpaar zu erzeugen, das einen öffentlichen Asset-Adressschlüssel PKaaund einen privaten Asset-Adressschlüssel SKaaumfasst. Die Schlüsselerzeugungsanforderung umfasst den Asset-Adressschlüsselnamen namekaaund die Genehmigungslogik AL einschliesslich der mehreren öffentlichen Genehmigungsschlüssel PKappund der Signierfenster SW.

[0057] In einem Schritt 203 erzeugt das Hardware-Sicherheitsmodul 40 ein asymmetrisches Schlüsselpaar und speichert mindestens den privaten Asset-Adresschlüssel SKaades asymmetrischen Schlüsselpaares und die zugehörige Genehmigungslogik AL einschliesslich der mehreren öffentlichen Genehmigungsschlüssel PKappund der Signierfenster SW im sicheren Speicher 42 des Hardware-Sicherheitsmoduls.

[0058] In einem Schritt 204 gibt das Hardware-Sicherheitsmodul 40 den öffentlichen Asset-Adressschlüssel PKaades asymmetrischen Schlüsselpaares an den Backend-Server 20 aus.

[0059] In einem Schritt 205 speichert die Backend-Anwendung 21 den öffentlichen Asset-Adressschlüssel PKaain ihrer internen Datenbank und berechnet aus dem öffentlichen Asset-Adressschlüssel PKaaeine kryptografische Adresse AA. Diese Berechnung erfolgt gemäss der jeweiligen Regel der jeweiligen Kryptowährung des kryptographischen Assets. Im Allgemeinen ist die kryptographische Asset-Adresse AA eine Ableitung des öffentlichen Asset-Adressschlüssels PKaa. Als Beispiel kann die kryptographische Asset-Adresse AA eine Hash-Funktion des öffentlichen Asset-Adressschlüssels PKaasein.

[0060] In einem Schritt 206 liefert, d.h. sendet, die Backend-Anwendung 21 den Asset-Adressschlüsselnamen und die Asset-Adresse AA oder den öffentlichen Schlüssel PKaaan die Frontend-Anwendung 11.

[0061] Die Frontend-Anwendung 11 oder insbesondere ein Bediener der Frontend-Anwendung 11 löst dann ein anschliessendes Asset-Adressen-Verifizierungsverfahren 210 aus, in dem der Bediener die empfangene Asset-Adresse AA und die zugehörige Genehmigungslogik AL verifiziert. Insbesondere sendet die Frontend-Anwendung 11 in einem Schritt 211 eine Anforderung zur Verifizierung der Asset-Adresse an den Backend-Server 20. Der Backend-Server 20 sendet dann in Schritt 212 eine Anforderung zum Erhalt der Genehmigungslogik AL für den jeweiligen Asset-Adressschlüsselnamen namekaaan das Hardware-Sicherheitsmodul 20. Im Gegenzug sendet das Hardware-Sicherheitsmodul 20 in einem Schritt 213 die Genehmigungslogik AL und den korrespondierenden öffentlichen Asset-Adressschlüssel PKaa, signiert mit dem privaten Schlüssel SKHSM, an den Backend-Server 20. Der Backend-Server 20 leitet dann in einem Schritt 214 die signierte Genehmigungslogik AL und den zugehörigen öffentlichen Asset-Adressschlüssel PKaaan die Hardware-Genehmigungsterminals 30 weiter. Die Hardware-Genehmigungs-Terminals 30 führen dann in einem Schritt 215 eine Integritätsprüfung der erhaltenen signierten Genehmigungslogik durch, indem sie die Signatur mit dem öffentlichen Schlüssel des Hardware-Sicherheitsmoduls PKHSMverifizieren. Darüber hinaus berechnen die Hardware-Genehmigungsterminals 30 aus dem empfangenen öffentlichen Schlüssel PKaadie entsprechende Asset-Adresse AA. Die Hardware-Genehmigungsterminals 30 zeigen dann in Schritt 216 die Genehmigungslogik AL und die Asset-Adresse AA an. Der Bediener verifiziert dann in Schritt 217 die Genehmigungslogik AL und prüft, ob die von den Hardware-Genehmigungsterminals 30 berechnete Asset-Adresse mit der Asset-Adresse übereinstimmt, die vom Backend-Server 20 in Schritt 206 bereitgestellt wurde. Dadurch wird sichergestellt, dass die Asset-Adresse korrekt ist. Insbesondere ermöglicht es die Erkennung des Falls, wenn ein kompromittierter Backend-Server im Schritt 206 eine falsche Asset-Adresse gesendet hat.

[0062] FIG. 3 zeigt ein Flussdiagramm 300 eines Verfahrens zur Durchführung kryptographischer Asset-Transaktionen mit Hilfe des Systems 100 von FIG. 1.

[0063] In einem Schritt 301 gibt die Frontend-Anwendung 11 eine Transaktionsanforderung zum Signieren einer kryptografischen Asset-Transaktion an die Backend-Anwendung 21 / den Backend-Server 20 aus. Die Transaktionsanforderung umfasst als Quell-Assetadresse einen Asset-Adressschlüsselnamen namekaa, der z.B. durch die oben unter Bezugnahme auf FIG. 2 beschriebenen Schritte ausgegeben und verifiziert wurde. Darüber hinaus umfasst die Transaktionsanforderung einen Asset-Transaktionswert und eine Ziel-Assetadresse, die eine kryptographische Asset-Adresse angibt, an die der Asset-Transaktionswert, z.B. eine Anzahl von Bitcoins, übertragen werden soll.

[0064] In einem Schritt 302 fordert die Backend-Anwendung 21 von dem Hardware-Sicherheitsmodul 40 die Genehmigungslogik AL des Asset-Adressschlüsselnamens namekaaan, korrespondierend zu der Quell-Assetadresse. In einem Schritt 303 liest das Hardware-Sicherheitsmodul 40 die Genehmigungslogik AL, die dem empfangenen Asset-Adressschlüsselnamen namekaazugeordnet ist, aus seinem sicheren Speicher 42 und sendet die Genehmigungslogik AL an die Backend-Anwendung 21.

[0065] In einem Schritt 304 sendet die Backend-Anwendung 21 eine Anforderung zur Schätzung der Transaktionsgebühren an einen Blockchain-Knoten 60.

[0066] In einem Schritt 305 gibt der Blockchain-Knoten 60 eine geschätzte Transaktionsgebühr zurück. Solche Transaktionsgebühren für kryptografische Assets hängen hauptsächlich vom Angebot an Netzkapazität im Vergleich zur Nachfrage des Asset-Inhabers nach einer schnelleren Transaktion ab.

[0067] In einem Schritt 306 sendet die Backend-Anwendung 21 die Transaktionsanforderung und die entsprechende Genehmigungslogik AL an die der Genehmigungslogik zugeordneten Hardware-Genehmigungsterminals 30.

[0068] In einem Schritt 307 führen die Genehmigungsterminals 30 eine Integritätsprüfung durch und verifizieren die empfangene Genehmigungslogik AL mit Hilfe des öffentlichen Schlüssels PKHSMdes Hardware-Sicherheitsmoduls 40.

[0069] In einem Schritt 308 senden die Genehmigungsterminals 30 eine Zeitstempelanforderung für die empfangene Transaktionsanforderung an die Backend-Anwendung 21. Die Backend-Anwendung 21 leitet die Zeitstempelanforderung in einem Schritt 309 an das Hardware-Sicherheitsmodul 20 weiter.

[0070] Dann, in einem Schritt 310, fügt das Hardware-Sicherheitsmodul 40 der Transaktionsanforderung einen Zeitstempel hinzu. Dieser Zeitstempel wird von einer internen Uhr des Hardware-Sicherheitsmoduls 40 abgeleitet, und daher wird der Zeitstempel in Bezug auf die interne Uhr des Hardware-Sicherheitsmoduls 40 referenziert. Das Hardware-Sicherheitsmodul 40 signiert dann die Transaktionsanforderung einschliesslich des Zeitstempels mit seinem privaten Schlüssel SKHSMund übermittelt die signierte Transaktionsanforderung einschliesslich des Zeitstempels an die Backend-Anwendung 21.

[0071] Die Backend-Anwendung 21 leitet die signierte Transaktionsanforderung einschliesslich des Zeitstempels oder den signierten Zeitstempel einschliesslich der Transaktionsanforderung in einem Schritt 311 an die Hardware-Genehmigungsterminals 30.

[0072] In einem Schritt 312 führen die Hardware-Genehmigungsterminals 30 eine Integritätsprüfung durch und verifizieren die empfangene Transaktionsanforderung einschliesslich des Zeitstempels mit Hilfe des öffentlichen Schlüssels PKHSMdes Hardware-Sicherheitsmoduls 40.

[0073] Der Zeitstempel löst für jede Transaktionsanforderung das Signierfenster SW aus, während dem das Hardware-Sicherheitsmodul 40 eine Transaktionsanforderung signieren kann.

[0074] In einem Schritt 313 zeigen die Hardware-Genehmigungsterminals 30 die Transaktionsanforderung auf den Displays 33 an. Die Genehmigenden können dann die angezeigte Transaktionsanforderung prüfen und verifizieren. Dazu kann die Verifizierung der AL aller Quellen und Ziele gehören. Die Genehmigenden können dann die Transaktion genehmigen, z.B. durch Drücken eines Genehmigungsknopfes des Hardware-Genehmigungsterminals 30 in einem Schritt 314.

[0075] Dann signiert das Hardware-Genehmigungsterminal 30 in einem Schritt 315 die Transaktionsanforderung und sendet in einem Schritt 316 eine signierte Transaktionsgenehmigung an den Backend-Server 20. Die signierten Transaktionsgenehmigungen umfassen den Asset-Adressschlüsselnamen, die Transaktionsanforderung und den Zeitstempel.

[0076] Da gemäss Ausführungsformen zwei oder mehr Genehmigungen gemäss der jeweiligen Genehmigungslogik AL erforderlich sind, sammelt der Backend-Server 20 die erforderliche Anzahl von Transaktionsgenehmigungen, bevor er sie weiterleitet. Wenn die erforderliche Anzahl von Genehmigungen eingegangen ist, leitet der Backend-Server 20 die signierten Transaktionsgenehmigungen in einem Schritt 317 an das Hardware-Sicherheitsmodul 40 weiter.

[0077] In einem Schritt 318 verifiziert das Hardware-Sicherheitsmodul 40 die empfangenen Transaktionsgenehmigungen gemäss der Genehmigungslogik AL, die für die entsprechende Asset-Adresse gespeichert ist und die zu dem Asset-Adressschlüsselnamen namekaakorrespondiert. Insbesondere prüft es mit Hilfe der gespeicherten Genehmigungslogik AL und der gespeicherten öffentlichen Genehmigungsschlüssel PKapp, ob die erhaltenen Genehmigungen mit einer der Genehmigungsoptionen der jeweiligen kryptographischen Asset-Adresse übereinstimmen. Darüber hinaus prüft es anhand des signierten Zeitstempels, ob der Zeitpunkt, zu dem die Transaktionsgenehmigungen am Hardware-Sicherheitsmodul 40 eingegangen sind, innerhalb des Signierfensters SW liegt. Wie bereits erwähnt, hat das Signierfenster ein oberes Zeitlimit und ein unteres Zeitlimit.

[0078] Wenn die Überprüfung der erhaltenen Transaktionsgenehmigungen erfolgreich war, signiert das Hardware-Sicherheitsmodul 40 in einem Schritt 319 die Transaktion mit dem privaten Schlüssel der Asset-Adresse und stellt in einem Schritt 320 die signierte Transaktion der Backend-Anwendung 21 zur Verfügung..

[0079] In einem nächsten Schritt 321 sendet die Backend-Anwendung 21 die signierte Transaktion an einen Blockchain-Knoten 60.

[0080] Dann, in einem Schritt 322, wird die Transaktion von Minern eines entsprechenden Blockchainnetzwerks verifiziert und nach erfolgreicher Verifizierung durch eine ausreichende Anzahl von Minern bestätigt.

[0081] Schliesslich sendet die Backend-Anwendung 21 in einem Schritt 323 eine Transaktionsbestätigung an die Frontend-Anwendung 11, und der Bediener kann bei Schritt 324 die empfangene Transaktionsbestätigung überprüfen.

[0082] FIG. 4 zeigt eine beispielhafte Ausführungsform einer Asset-Adressdatei 400, die auch als AAF1 bezeichnet wird. Die Asset-Adressdatei 400 umfasst einen Asset-Adressschlüsselnamen namekaa, einen privaten Asset-Adressschlüssel SKaa, einen entsprechenden öffentlichen Asset-Adressschlüssel PKaaund eine Genehmigungslogik AL. Der öffentliche Asset-Adressschlüssel PKaader Asset-Adresse kann aus dem privaten Asset-Adressschlüssel SKaader Asset-Adresse abgeleitet werden und kann optional in der Asset-Adressdatei 400 gespeichert werden.

[0083] Die Asset-Adressdatei 400 entspricht einer kryptographischen Asset-Adresse AA, die aus dem öffentlichen Asset-Adressschlüssel PKaaabgeleitet werden kann. Insbesondere kann die kryptographische Asset-Adresse AA eine Funktion, insbesondere eine Hash-Funktion, des öffentlichen Asset-Adressschlüssels PKaasein. Die Funktion oder das Verfahren zur Berechnung der Asset-Adresse AA aus dem öffentlichen Asset-Adressschlüssel PKaahängt von der jeweiligen Spezifikation der kryptographischen Assets, z.B. der jeweiligen Krypto-Währung, ab.

[0084] Die Genehmigungslogik AL umfasst eine Vielzahl von öffentlichen Genehmigungsschlüsseln PKapp. Die öffentlichen Genehmigungsschlüssel PKappsind in die Genehmigungslogik AL eingebettet. Die Genehmigungslogik AL definiert für den kryptographischen Asset AA des öffentlichen Asset-Adressschlüssels PKaaeine kombinatorische Logik aus einer Vielzahl von Genehmigungssignaturen, die für die Genehmigung einer Transaktion der kryptographischen Assetadresse AA erforderlich sind. Die Signaturen müssen mit den privaten Genehmigungsschlüsseln durchgeführt werden, die zu den jeweiligen öffentlichen Genehmigungsschlüsseln PKappkorrespondieren. Die Genehmigungslogik ist so ausgelegt, dass sie technisch im Hardware-Sicherheitsmodul implementiert werden kann, ohne ein Sicherheitsrisiko darzustellen, selbst wenn sie im inneren Kern des Hardware-Sicherheitsmoduls implementiert ist. Entsprechend der gezeigten Ausführungsform ist die Genehmigungslogik eine kombinatorische Logik, die aus einem oder mehreren UND-Operatoren und einem oder mehreren ODER-Operatoren besteht. Solche einfachen Operatoren ermöglichen eine sichere Implementierung der Genehmigungslogik. Entsprechend der in FIG. 4 gezeigten Ausführungsform umfasst die Genehmigungslogik AL drei Genehmigungsoptionen 401, 402 und 403, die durch einen ODER-Operator kombiniert werden.

[0085] Die Genehmigungsoptionen umfassen eine Vielzahl von öffentlichen Genehmigungsschlüsseln PKapp, die durch die Operatoren UND und ODER kombiniert werden. Als Beispiel liest sich die Genehmigungsoption 401 wie folgt: (PKapp1ODER PKapp2) UND PKapp3

[0086] Dies bedeutet, dass eine Transaktionsgenehmigungsanforderung für den öffentlichen Asset-Adressschlüssel PKaaentweder durch die privaten Genehmigungsschlüssel, die zu den öffentlichen Genehmigungsschlüsseln PKapp1oder PKapp2korrespondieren, und zusätzlich durch den privaten Genehmigungsschlüssel, der zu dem öffentlichen Genehmigungsschlüssel PKapp3korrespondiert, genehmigt werden kann. Im Gegensatz dazu erlaubt die Genehmigungsoption 3 die Genehmigung eines einzelnen Genehmigenden, nämlich durch die privaten Schlüssel, die zu den öffentlichen Genehmigungsschlüsseln PKapp7oder PKapp8korrespondieren.

[0087] Die drei Genehmigungsoptionen 401, 402 und 403 umfassen jeweils ein separates Signierfenster SW1, SW2 und SW3, wodurch eine zeitliche Logik festgelegt wird. Die Signierfenster SW1, SW2 und SW3 können unterschiedlich sein und haben jeweils eine vordefinierte untere Zeitgrenze und eine vordefinierte obere Zeitgrenze. Zum Beispiel kann das Signierfenster SW1 eine untere Zeitgrenze von 10 Minuten und eine obere Zeitgrenze von 20 Minuten haben. Das Signierungsfenster SW2 kann die gleiche untere Zeitgrenze von 10 Minuten und eine obere Zeitgrenze von 30 Minuten haben. Und das Signierungsfenster SW3 kann ein unteres Zeitlimit von 1 Monat und ein oberes Zeitlimit von 2 Monaten haben. Letzteres kann z.B. eine Wiederherstellung des kryptographischen Assets im Katastrophenfall ermöglichen.

[0088] FIG. 5 zeigt eine beispielhafte Ausführungsform einer Asset-Adressdatei 500, die auch als AAF2 bezeichnet wird. Die Asset-Adressdatei 500 umfasst einen Asset-Adressschlüsselnamen namekaa, einen privaten Asset-Adressschlüssel SKaa, einen entsprechenden öffentlichen Asset-Adressschlüssel PKaaund eine Genehmigungslogik AL. Der öffentliche Asset-Adressschlüssel PKaakann aus dem privaten Asset-Adressschlüssel SKaaabgeleitet werden und kann optional in der Asset-Adressdatei 500 gespeichert werden.

[0089] Die Asset-Adressdatei 500 korrespondiert zu einer kryptographischen Asset-Adresse AA, die aus dem öffentlichen Asset-Adressschlüssel PKaaabgeleitet werden kann.

[0090] Die Genehmigungslogik AL umfasst eine Vielzahl von öffentlichen Genehmigungsschlüsseln PKapp. Die öffentlichen Genehmigungsschlüsseln PKappsind in die Genehmigungslogik AL eingebettet.

[0091] Gemäss der in FIG. 5 dargestellten Ausführungsform umfasst die Genehmigungslogik AL zwei Genehmigungsoptionen 501 und 502, die durch einen ODER-Operator kombiniert werden.

[0092] Die Genehmigungsoptionen umfassen eine Vielzahl von öffentlichen Genehmigungsschlüsseln. Nach dieser Ausführungsform umfasst die erste Option 501 Gruppenlogiken. Insbesondere definiert die Genehmigungslogik eine erste Gruppe, die die öffentlichen Genehmigungsschlüssel PKapp1, PKapp2und PKapp3umfasst, und eine zweite Gruppe, die die öffentlichen Genehmigungsschlüssel PKapp4, PKapp5und PKapp6umfasst. Die beiden Gruppen werden mit einem UND-Operator kombiniert. Die Gruppenlogik legt fest, dass ein Genehmigender der ersten Gruppe und ein Genehmigender der zweiten Gruppe gemäss der ersten Genehmigungsoption genehmigen müssen.

[0093] Die zweite Genehmigungsoption entspricht der dritten Genehmigungsoption von FIG. 4 und ermöglicht die Genehmigung eines einzelnen Genehmigenden, nämlich durch die privaten Schlüssel, die zu den öffentlichen Genehmigungsschlüsseln PKapp7oder PKapp8korrespondieren.

[0094] Die beiden Genehmigungsoptionen 501 umfassen jeweils ein separates Signierfenster SW1 und SW2.

[0095] FIG. 6 zeigt eine beispielhafte Ausführungsform einer Asset-Adressdatei 600, die auch als AAF3 bezeichnet wird. Die Asset-Adressdatei 600 umfasst einen Asset-Adressschlüsselnamen namekaa, einen privaten Asset-Adressschlüssel SKaa, einen korrespondierenden öffentlichen Asset-Adressschlüssel PKaaund eine Genehmigungslogik AL. Der öffentliche Asset-Adressschlüssel PKaakann aus dem privaten Asset-Adressschlüssel SKaaabgeleitet und optional in der Asset-Adressdatei 600 gespeichert werden.

[0096] Die Asset-Adressdatei 600 entspricht einer kryptographischen Asset-Adresse AA, die aus dem öffentlichen Asset-Adressschlüssel PKaaabgeleitet werden kann.

[0097] Die Genehmigungslogik AL besteht aus einer Vielzahl von öffentlichen Genehmigungsschlüsseln PKappund einem oder mehreren öffentlichen Richtliniengenehmigungsschlüsseln PKpak1, PKpak2, ..., PKpakn. Die Richtliniengenehmigungsschlüssel können verwendet werden, um zusätzliche Flexibilität bei der Definition von Signierrichtlinien oder Signierkriterien zu schaffen.

[0098] Die öffentlichen Genehmigungsschlüssel PKappund die öffentlichen Richtliniengenehmigungsschlüssel PKpaksind in die Genehmigungslogik AL eingebettet. Die Signaturen müssen mit den privaten Genehmigungsschlüsseln, die zu den jeweiligen öffentlichen Genehmigungsschlüsseln PKappkorrespondieren, und den privaten Richtliniengenehmigungsschlüsseln, die zu den öffentlichen Richtliniengenehmigungsschlüsseln PKpakkorrespondieren, durchgeführt werden.

[0099] Gemäss der in FIG. 6 dargestellten Ausführungsform umfasst die Genehmigungslogik AL drei Genehmigungsoptionen 601, 602 und 603, die durch einen ODER-Operator kombiniert werden.

[0100] Die Genehmigungsoptionen umfassen eine Vielzahl von öffentlichen Genehmigungsschlüsseln PKapp, und jede der Optionen umfasst einen öffentlichen Richtliniengenehmigungsschlüssel. Als Beispiel lautet die Genehmigungsoption 601 wie folgt: ((PKapp1ODER PKapp2) UND PKapp3) UND PKpak1)

[0101] Dies bedeutet, dass eine Transaktionsgenehmigungsanforderung des öffentlichen Asset-Adressschlüssels PKaagemäss Option 601 nur mit dem privaten Richtliniengenehmigungsschlüssel SKpak1genehmigt werden kann, der zu dem öffentlichen Richtliniengenehmigungsschlüssel PKpak1korrespondiert. Die Signatur mit dem privaten Richtliniengenehmigungsschlüssel SKpak1kann automatisch vom Hardware-Genehmigungsterminal 30 in Abhängigkeit von vordefinierten Merkmalen der Transaktionsanforderung, insbesondere dem Transaktionswert und der Zieladresse des Assets, durchgeführt werden. Im Gegensatz zu den Signaturen mit den privaten Genehmigungsschlüsseln ist daher keine zusätzliche Überprüfung des Genehmigers mittels Smartcard und PIN eines menschlichen Genehmigers erforderlich.

[0102] Beispielsweise kann das Hardware-Genehmigungsterminal 30 automatisch mit dem privaten Richtliniengenehmigungsschlüssel SKpak1unterschreiben, wenn der Transaktionswert unter einem vordefinierten Transaktionswert liegt.

[0103] Darüber hinaus ist gemäss Genehmigungsoption 601 eine Signatur eines der privaten Genehmigungsschlüssel, die zu den öffentlichen Genehmigungsschlüsseln PKapp1oder PKapp2korrespondieren, und eine Signatur des privaten Genehmigungsschlüssels, der zu dem öffentlichen Genehmigungsschlüssel PKapp3korrespondiert, erforderlich.

[0104] Die drei Genehmigungsoptionen 601, 602 und 603 umfassen jeweils ein separates Signierfenster SW1, SW2 bzw. SW3 und legen damit eine Zeitlogik fest.

[0105] Die im Hardware-Genehmigungsterminal 30 gespeicherte Richtlinie P kann individuelle Signierkriterien oder Signierregeln für jeden der öffentlichen Richtliniengenehmigungsschlüssel angeben, in diesem Beispiel für PKpak1, PKpak2und PKpak3.

[0106] Als Beispiel kann die Richtlinie P festlegen, dass das Hardware-Genehmigungsterminal 30 automatisch mit dem privaten Richtliniengenehmigungsschlüssel SKpak1unterschreibt, wenn der Asset-Transaktionswert der erhaltenen Transaktionsanforderung unter einem vordefinierten Betrag liegt.

[0107] Darüber hinaus kann sie festlegen, dass das Hardware-Genehmigungsterminal 30 automatisch mit dem privaten Richtliniengenehmigungsschlüssel SKpak2signiert, wenn die empfangene Transaktionsanforderung eine vordefinierte Ziel-Assetadresse umfasst.

[0108] Darüber hinaus kann sie festlegen, dass das Hardware-Genehmigungsterminal 30 automatisch mit dem privaten Richtliniengenehmigungsschlüssel SKpak3signiert, wenn die empfangene Transaktionsanforderung eine andere vordefinierte Ziel-Assetadresse umfasst oder wenn der Asset-Transaktionswert der empfangenen Transaktionsanforderung innerhalb eines vordefinierten Bereichs liegt.

[0109] FIG. 7 zeigt ein Flussdiagramm eines Verfahrens zur Einführung oder Implementierung von Richtliniengenehmigungsschlüsseln in Systeme gemäss Ausführungsformen der Erfindung.

[0110] In einem Schritt 710 gibt der Bediener eine oder mehrere Richtlinien P in das/die Genehmigungsterminal(s) 30 ein.

[0111] In einem Schritt 720 erstellt das jeweilige Genehmigungsterminal 30 ein oder mehrere Richtliniengenehmigungsschlüsselpaare (SKpakx, PKpakx) und speichert die privaten Richtliniengenehmigungsschlüssel SKpakxund die Richtlinie P im jeweiligen Hardware-Genehmigungsterminal 30.

[0112] Die eine oder die mehreren Richtlinien P sind mit den privaten/öffentlichen Richtliniengenehmigungsschlüssel verknüpft und können insbesondere Signierkriterien oder mit anderen Worten Signierregeln für eine automatische Signierung einer Transaktionsanforderung mit dem einen oder mehreren privaten Richtliniengenehmigungsschlüsseln festlegen.

[0113] In einem Schritt 730 exportiert der Bediener die öffentlichen Richtliniengenehmigungsschlüssel PKpakxder Richtliniengenehmigungsschlüsselpaare über das Frontend 10 in die entsprechende Genehmigungslogik AL.

[0114] FIG. 8a zeigt ein Verfahren zur Durchführung automatischer Signaturen mit den Richtliniengenehmigungsschlüsseln durch ein Hardware-Genehmigungsterminal 30.

[0115] In einem Schritt 810 sendet der Backend-Server 20 eine Transaktionsanforderung mit einer Genehmigungslogik AL an das Hardware-Genehmigungsterminal 30.

[0116] In einem Schritt 820 führt das Hardware-Genehmigungsterminal 30 ein automatisches Signatur-/Signierverfahren durch, das unter Bezugnahme auf FIG. 8b näher beschrieben wird und die Schritte 821-824 umfasst.

[0117] In einem Schritt 821 beginnt das automatische Signaturverfahren.

[0118] In einem Schritt 822 prüft das Hardware-Terminal 30, ob in der jeweiligen Zugriffslogik AL der empfangenen Transaktionsanforderung ein öffentlicher Richtliniengenehmigungsschlüssel vorhanden ist.

[0119] Wenn ja, prüft das Hardware-Genehmigungsterminal 30 in einem Schritt 823, ob ein oder mehrere Signierkriterien für eine automatische Signierung gemäss der gespeicherten Richtlinie P erfüllt sind.

[0120] Wenn dies der Fall ist, signiert das Hardware-Genehmigungsterminal 30 in einem Schritt 824 die Transaktionsanforderung mit dem jeweiligen privaten Richtliniengenehmigungsschlüssel SKpakx, der durch die Richtlinie P festgelegt ist.

[0121] In einem Schritt 830 sendet dann das Hardware-Genehmigungsterminal 30 die mit dem jeweiligen privaten Richtliniengenehmigungsschlüssel SKpakxsignierte Transaktionsanforderung an den Backend-Server 20.

[0122] Ein solches Verfahren ermöglicht eine automatische Signierung durch das Hardware-Genehmigungsterminal 30 ohne Benutzerinteraktion auf der Grundlage der im Hardware-Genehmigungsterminal 30 gespeicherten Richtlinie P. Darüber hinaus können die Genehmigungsoptionen mit Hilfe der Richtliniengenehmigungsschlüssel und der entsprechenden Richtlinie flexibel konfiguriert und insbesondere mit Genehmigungsschlüsseln kombiniert werden.

[0123] Aspekte der vorliegenden Erfindung können in Form eines Systems, insbesondere eines Systems zur Durchführung kryptographischer Asset-Transaktionen, eines Verfahrens und/oder eines Computerprogrammprodukts ausgebildet sein. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder Medien) mit darauf befindlichen computerlesbaren Programmbefehlen umfassen, die einen Prozessor veranlassen, Aspekte der vorliegenden Erfindung auszuführen.

[0124] Das computerlesbare Speichermedium kann ein materielles Gerät sein, das Befehle zur Verwendung durch ein Befehlsausführungsgerät aufbewahren und speichern kann. Das computerlesbare Speichermedium kann z.B. ein elektronisches Speichergerät, ein magnetisches Speichergerät, ein optisches Speichergerät, ein elektromagnetisches Speichergerät, ein Halbleiterspeichergerät oder eine geeignete Kombination der vorgenannten sein, ist aber nicht darauf beschränkt. Eine nicht erschöpfende Liste mit spezifischeren Beispielen für das computerlesbare Speichermedium umfasst das Folgende: eine tragbare Computerdiskette, eine Festplatte, einen Speicher mit wahlfreiem Zugriff (RAM), einen Nur-Lese-Speicher (ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM oder Flash-Speicher), einen statischen Speicher mit wahlfreiem Zugriff (SRAM), einen tragbaren Nur-Lese-Speicher für Compact Discs (CD-ROM), eine digitale vielseitige Diskette (DVD), einen Speicherstick, eine Diskette, eine mechanisch kodierte Vorrichtung wie Lochkarten oder erhabene Strukturen in einer Rille mit darauf aufgezeichneten Befehlen und jede geeignete Kombination der vorgenannten. Ein computerlesbares Speichermedium, wie es hier verwendet wird, ist nicht als flüchtiges Signal an sich auszulegen, wie z.B. Radiowellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich über einen Wellenleiter oder andere Übertragungsmedien ausbreiten (z.B. Lichtimpulse, die durch ein Glasfaserkabel laufen), oder elektrische Signale, die über einen Draht übertragen werden.

[0125] Die hierin beschriebenen computerlesbaren Programmbefehle können von einem computerlesbaren Speichermedium oder über ein Netzwerk, z.B. das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk, auf die entsprechenden Rechen-/Prozessorgeräte heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, optische Übertragungsfasern, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jedem Rechen-/Prozessorgerät empfängt computerlesbare Programmbefehle vom Netzwerk und leitet die computerlesbaren Programmbefehle zur Speicherung in einem computerlesbaren Speichermedium innerhalb des jeweiligen Rechen-/Prozessorgeräts weiter.

[0126] Bei computerlesbaren Programmbefehlen zur Ausführung von Operationen der vorliegenden Erfindung kann es sich um Assemblerbefehle, Instruktionssatz-Architektur-Befehle (ISA-Befehle), Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Firmware-Befehle, zustandsetzende Daten oder entweder um Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen, einschliesslich einer objektorientierten Programmiersprache wie Smalltalk, C++ o.ä., und herkömmlichen prozeduralen Programmiersprachen, wie der Programmiersprache „C“ oder ähnlichen Programmiersprachen, geschrieben sind. Die computerlesbaren Programmbefehle können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem Remote-Computer oder vollständig auf dem Remote-Computer oder Server ausgeführt werden. Im letzteren Fall kann der Remote-Computer über jede Art von Netzwerk, einschliesslich eines lokalen Netzwerks (LAN) oder eines Weitverkehrsnetzwerks (WAN), mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer hergestellt werden (z.B. über das Internet mit Hilfe eines Internet Service Providers). In einigen Ausführungsformen können elektronische Schaltungen, z.B. programmierbare Logikschaltungen, feldprogrammierbare Gate-Arrays (FPGA) oder programmierbare Logik-Arrays (PLA), die computerlesbaren Programmbefehle ausführen, indem sie die Statusinformationen der computerlesbaren Programmbefehle zur Personalisierung der elektronischen Schaltung verwenden, um Aspekte der vorliegenden Erfindung auszuführen.

[0127] Aspekte der vorliegenden Erfindung werden hier unter Bezugnahme auf Flussdiagrammdarstellungen, und/oder Blockdiagramme von Verfahren, Apparaten (Systemen) und Computerprogrammprodukten entsprechend den Ausführungsformen der Erfindung beschrieben. Es wird davon ausgegangen, dass jeder Block der Flussdiagrammdarstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammdarstellungen und/oder Blockdiagrammen durch computerlesbare Programmbefehle implementiert werden kann.

[0128] Diese computerlesbaren Programmbefehle können einem Prozessor eines Allzweckrechners, eines Spezialrechners oder eines anderen programmierbaren Datenverarbeitungsgeräts zur Erzeugung einer Maschine zur Verfügung gestellt werden, so dass die Befehle, die über den Prozessor des Rechners oder eines anderen programmierbaren Datenverarbeitungsgeräts ausgeführt werden, Mittel zur Implementierung der im Flussdiagramm und/oder in einem Blockdiagrammblock oder in Blöcken spezifizierten Funktionen/Aktionen schaffen. Diese computerlesbaren Programmbefehle können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, ein programmierbares Datenverarbeitungsgerät und/oder andere Vorrichtungen anweisen kann, in einer bestimmten Weise zu funktionieren, so dass das computerlesbare Speichermedium mit den darin gespeicherten Befehlen ein Erzeugnis umfasst, das Befehle enthält, die Aspekte der im Flussdiagramm und/oder in einem Blockdiagrammblock oder in Blöcken spezifizierten Funktion/Aktion implementieren.

[0129] Die computerlesbaren Programmbefehle können auch auf einen Computer, ein anderes programmierbares Datenverarbeitungsgerät oder eine andere Vorrichtung geladen werden, um eine Reihe von Betriebsschritten auf dem Computer, dem anderen programmierbaren Gerät oder der anderen Vorrichtung auszuführen, um einen computerimplementierten Prozess zu erzeugen, so dass die Befehle, die auf dem Computer, dem anderen programmierbaren Gerät oder der anderen Vorrichtung ausgeführt werden, die Funktionen/Aktionen implementieren, die im Flussdiagramm und/oder in einem Blockdiagrammblock oder in Blöcken spezifiziert sind.

[0130] Das Flussdiagramm und die Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und die Funktionsweise möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten entsprechend den verschiedenen Ausführungsformen der vorliegenden Erfindung. In dieser Hinsicht kann jeder Block in dem Flussdiagramm oder den Blockdiagrammen ein Modul, ein Segment oder einen Teil von Befehlen darstellen, der einen oder mehrere ausführbare Befehle zur Implementierung der spezifizierten logischen Funktion(en) umfasst. In einigen alternativen Implementierungen können die im Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten. So können z.B. zwei nacheinander dargestellte Blöcke tatsächlich im wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, je nach der betreffenden Funktionalität. Es wird auch darauf hingewiesen, dass jeder Block der Blockdiagramme und/oder der Flussdiagrammdarstellung sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder der Flussdiagrammdarstellung durch auf Spezialzweck-Hardware basierende Systeme implementiert werden kann, die die angegebenen Funktionen oder Aktionen ausführen oder Kombinationen von Spezialzweck-Hardware und Computerbefehlen ausführen.

[0131] Es werden zwar gegenwärtig bevorzugte Ausführungsformen der Erfindung gezeigt und beschrieben, aber es ist deutlich zu verstehen, dass die Erfindung nicht darauf beschränkt ist, sondern im Rahmen der folgenden Ansprüche auch anderweitig auf unterschiedliche Weise ausgeführt und praktiziert werden kann.

Claims (16)

1. System (100) zum Bereitstellen von kryptographischen Asset-Transaktionen, wobei das System (100) so ausgelegt ist, dass es mit einem Hardware-Sicherheitsmodul (40) kommunizieren kann, wobei das Hardware-Sicherheitsmodul (40) so konfiguriert ist, dass es einen privaten Schlüssel des Hardware-Sicherheitsmoduls (40) und eine Vielzahl von Asset-Adressdateien speichert, die einer kryptographischen Asset-Adresse entsprechen, wobei jede der Vielzahl von Asset-Adressdateien einen Asset-Adressschlüsselnamen, einen privaten Asset-Adressschlüssel und eine Genehmigungslogik umfasst, wobei die Genehmigungslogik eine Vielzahl von öffentlichen Genehmigungsschlüsseln umfasst; das System (100) umfassend ein Client-Gerät (10), das für die Ausführung einer Frontend-Anwendung (11) konfiguriert ist; einen Backend-Server (20), der für die Ausführung einer Backend-Anwendung (21) konfiguriert ist; und eine Vielzahl von Hardware-Genehmigungsterminals (30); wobei das System (100) dazu konfiguriert ist, einen öffentlichen Schlüssel des Hardware-Sicherheitsmoduls (40) und einen oder mehrere private Genehmigungsschlüssel von Genehmigern einer kryptographischen Asset-Transaktion durch die Vielzahl von Hardware-Genehmigungsterminals (30)zu speichern; Transaktionsanforderungen, um eine kryptographische Asset-Transaktion an den Backend-Server (20) zu signieren, durch die Frontend-Anwendung (11) auszugeben, wobei die Transaktionsanforderung Folgendes umfasst eine Quell-Assetadresse, insbesondere einen Asset-Adressschlüsselnamen; eine Ziel-Assetadresse; und einen Asset-Transaktionswert; durch den Backend-Server (20) die Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul (40) anzufordern; durch den Backend-Server (20) die Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul (40) zu empfangen; durch den Backend-Server (20) die Transaktionsanforderung und die korrespondierende Genehmigungslogik an die Hardware-Genehmigungsterminals (30) zu senden; die Transaktionsanforderung und die Genehmigungslogik auf einem Display (33) des Hardware-Genehmigungsterminals anzuzeigen; eine Bestätigung der Transaktionsanforderung von Genehmigenden, die mit dem Hardware-Genehmigungsterminal (30) verknüpft sind zu empfangen; durch die Hardware-Genehmigungsterminals (30) die Genehmigungslogik mit Hilfe des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40) zu verifizieren; durch die Hardware-Genehmigungsterminals (30) signierte Transaktionsgenehmigungen an den Backend-Server (20) zu senden, wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen; durch den Backend-Server (20) die signierten Transaktionsgenehmigungen an das Hardware-Sicherheitsmodul (40) zur Verifizierung weiterzuleiten; durch den Backend-Server (20) die signierte kryptographische Asset-Transaktion nach Verifizierung vom Hardware-Sicherheitsmodul (40) zu empfangen; und die signierte kryptographische Asset-Transaktion durch den Backend-Server (20) an einen Blockchain-Knoten bereit zu stellen.

2. System nach Anspruch 1, wobei das System (100) ferner konfiguriert ist, um nach Erhalt einer Transaktionsanforderung durch die Hardware-Genehmigungsterminals (30) eine Zeitstempelanforderung an das Hardware-Sicherheitsmodul (40) zu senden; durch die Hardware-Genehmigungsterminals (30) eine signierte Transaktionsanforderung mit einem Zeitstempel zu empfangen; durch die Hardware-Genehmigungsterminals (30) die signierte Transaktionsanforderung einschliesslich des Zeitstempels zu verifizieren; wobei der Zeitstempel für jede Transaktionsanforderung ein Signierfenster für das Hardware-Sicherheitsmodul (40) auslöst.

3. System gemäss einem der vorhergehenden Ansprüche, bei dem die privaten Genehmigungsschlüssel mit Hilfe eines Passworts und eines Smartcard-Schlüssels verschlüsselt sind.

4. System gemäss einem der vorhergehenden Ansprüche, wobei das System (100) ferner dazu konfiguriert ist, durch die Frontend-Anwendung (11) eine Adresserzeugungsanforderung zur Erzeugung einer Asset-Adresse an den Backend-Server zu senden, wobei die Adresserzeugungsanforderung einen Asset-Adressschlüsselnamen, einen Asset-Typ, eine Genehmigungslogik und eine Vielzahl von öffentlichen Genehmigungsschlüsseln der Genehmigungslogik umfasst; durch den Backend-Server (20) eine Schlüsselerzeugungsanforderung an das Hardware-Sicherheitsmodul (40) zusenden, um ein asymmetrisches Schlüsselpaar zu erzeugen, das einen öffentlichen Asset-Adressschlüssel und einen privaten Asset-Adressschlüssel umfasst, wobei die Schlüsselerzeugungsanforderung den Asset-Adressschlüsselnamen, die Genehmigungslogik und die Vielzahl der öffentlichen Genehmigungsschlüssel der Genehmigungslogik umfasst; durch den Backend-Server (20) den öffentlichen Asset-Adressschlüssel des asymmetrischen Schlüsselpaares vom Hardware-Sicherheitsmodul (40) zu empfangen; durch den Backend-Server (20) den Asset-Adressschlüsselnamen, den öffentlichen Asset-Adressschlüssel oder eine Ableitung des öffentlichen Asset-Adressschlüssels als kryptographische Asset-Adresse für die Frontend-Anwendung (11) bereitzustellen.

5. System nach Anspruch 4, wobei das System (100) ferner so konfiguriert ist, dass es ein Asset-Adressen-Verifizierungsverfahren durchführt, wobei das Asset-Adressen-Verifizierungsverfahren umfasst Senden einer Anforderung zur Verifizierung der Asset-Adresse durch die Frontend-Anwendung (11) über den Backend-Server (20) an das Hardware-Sicherheitsmodul (40) ; Empfangen der Genehmigungslogik und der korrespondierenden öffentlichen Asset-Adressschlüssel, die mit dem privaten Schlüssel des Hardware-Sicherheitsmoduls (40) signiert sind, durch das Hardware-Genehmigungsterminal (30) vom Hardware-Sicherheitsmodul (40) über den Backend-Server (20), Durchführen einer Integritätsprüfung der empfangenen signierten Genehmigungslogik durch das Hardware-Genehmigungsterminal (30), wobei die Integritätsprüfung die Verifizierung der Signatur des Hardware-Sicherheitsmoduls (40) und die Berechnung der entsprechenden Asset-Adresse aus dem empfangenen öffentlichen Asset-Adressschlüssel umfasst; Anzeigen der vom Hardware-Genehmigungsterminal (30) berechneten Asset-Adresse und der Genehmigungslogik durch das Hardware-Genehmigungsterminal (30) auf einem Display (33) des Hardware-Genehmigungsterminals zur Überprüfung durch einen Bediener.

6. System gemäss einem der vorhergehenden Ansprüche, bei dem der Backend-Server (20) dazu konfiguriert ist, eine erforderliche Anzahl von Transaktionsgenehmigungen von den Hardware-Genehmigungsterminals (30) zu sammeln; und die gesammelten Transaktionsgenehmigungen an das Hardware-Sicherheitsmodul (40) weiterzuleiten.

7. System gemäss einem der vorhergehend en Ansprüche, wobei das System (100) ferner so konfiguriert ist, dass es einen sicheren Kommunikationskanal, insbesondere einen SSL/TLS-Kanal, für eine sichere Kommunikation zwischen dem Backend-Server (20) und dem Frontend (10) und für eine sichere Kommunikation zwischen dem Backend-Server (20) und den Hardware-Genehmigungsterminals (30) bereitstellt.

8. System gemäss einem der vorhergehenden Ansprüche, wobei die Vielzahl von Hardware-Genehmigungs-Terminals (30) so konfiguriert sind, dass sie einen oder mehrere private Richtliniengenehmigungsschlüssel erzeugen und speichern; eine oder mehrere Richtlinien speichern, die mit den privaten Richtliniengenehmigungsschlüssel verknüpft sind; wobei die eine oder die mehreren Richtlinien Signierungskriterien für eine automatische Signierung einer Transaktionsanforderung mit einem oder mehreren privaten Richtliniengenehmigungsschlüsseln festlegen.

9. System nach Anspruch 8, wobei die Signierungskriterien umfassen einen oder mehrere vordefinierte Asset-Transaktionswerte einer kryptographischen Asset-Transaktion; und/oder eine oder mehrere vordefinierte Ziel-Assetadressen; und/oder einen oder mehrere vordefinierte Asset-Transaktionsbereiche einer kryptographischen Asset-Transaktion.

10. Hardware-Genehmigungsterminal (30) für ein System (100) gemäss einem der vorhergehenden Ansprüche, wobei das Hardware-Genehmigungsterminal (30) einen Kryptoprozessor (31), einen sicheren Speicher (32) und ein Display (33) umfasst, wobei das Hardware-Genehmigungsterminal (30) dazu konfiguriert ist, einen öffentlichen Schlüssel eines Hardware-Sicherheitsmoduls (40) und einen oder mehrere private Genehmigungsschlüssel von Genehmigern einer kryptographischen Asset-Transaktion zu speichern; von einem Backend-Server (20) eine Transaktionsanforderung und eine entsprechende Genehmigungslogik zu empfangen; die Transaktionsanforderung und die Genehmigungslogik auf einem Display (33) des Hardware-Genehmigungsterminals anzuzeigen; eine Bestätigung der Transaktionsanforderung von Genehmigenden, die mit dem Hardware-Genehmigungsterminal (30) verknüpft sind zu empfangen; die Genehmigungslogik mittels des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40) zu verifizieren; und signierte Transaktionsgenehmigungen an den Backend-Server (20) zu senden, wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen.

11. Hardware-Genehmigungsterminal (30) nach Anspruch 10, welches dazu konfiguriert ist einen oder mehrere private Richtliniengenehmigungsschlüssel zu erzeugen und zu speichern; und eine oder mehrere Richtlinien zu speichern, die mit den privaten Richtliniengenehmigungsschlüsseln verknüpft sind; wobei die eine oder die mehreren Richtlinien Signierungskriterien für eine automatische Signierung einer Transaktionsanforderung mit einem oder mehreren privaten Richtliniengenehmigungsschlüsseln festlegen.

12. Hardware-Genehmigungsterminal (30) nach Anspruch 11, wobei die Signierungskriterien umfassen einen oder mehrere vordefinierte Asset-Transaktionswerte einer kryptographischen Asset-Transaktion; und/oder eine oder mehrere vordefinierte Ziel-Assetadressen; und/oder einen oder mehrere vordefinierte Asset-Transaktionsbereiche einer kryptographischen Asset-Transaktion.

13. Backend-Server (20) für ein System (100) gemäss einem der Ansprüche 1 bis 9, wobei der Backend-Server (20) so konfiguriert ist, dass er eine Backend-Anwendung (21)ausführt, wobei die Backend-Anwendung (21) dazu konfiguriert ist von einer Frontend-Anwendung (11) eine Transaktionsanforderung zu empfangen, um eine kryptographische Asset-Transaktion zu signieren, wobei die Transaktionsanforderung Folgendes umfasst eine Quell-Assetadresse, insbesondere den Asset-Adressschlüsselnamen; eine Ziel-Assetadresse; und einen Asset-Transaktionswert; eine Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul (40) anzufordern; die Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul (40) zu empfangen; die Transaktionsanforderung und die korrespondierende Genehmigungslogik an die Hardware-Genehmigungsterminals (30) zu senden; von den Hardware-Genehmigungsterminals (30) signierte Transaktionsgenehmigungen zu empfangen, wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen; die signierten Transaktionsgenehmigungen zur Verifizierung an das Hardware-Sicherheitsmodul (40) weiterzuleiten; vom Hardware-Sicherheitsmodul (40) eine signierte kryptographische Asset-Transaktion zu empfangen; und die signierte kryptographische Asset-Transaktion einem Blockchain-Knoten zur Verfügung stellen.

14. Verfahren zum Durchführen kryptographischer Asset-Transaktionen mittels eines Systems (100), das Folgendes umfasst ein Client-Gerät (10), das für die Ausführung einer Frontend-Anwendung (11) konfiguriert ist; einen Backend-Server (20), der für die Ausführung einer Backend-Anwendung (21) konfiguriert ist; und eine Vielzahl von Hardware-Genehmigungs-Terminals (30); wobei das System (100) so ausgelegt ist, dass es mit einem Hardware-Sicherheitsmodul (40) kommunizieren kann, wobei das Hardware-Sicherheitsmodul (40) so konfiguriert ist, dass es einen privaten Schlüssel des Hardware-Sicherheitsmoduls (40) und eine Vielzahl von Asset-Adressdateien speichert, die einer kryptographischen Asset-Adresse entsprechen, wobei jede der Vielzahl von Asset-Adressdateien einen Asset-Adressschlüsselnamen, einen privaten Asset-Adressschlüssel und eine Genehmigungslogik umfasst, wobei die Genehmigungslogik eine Vielzahl von öffentlichen Genehmigungsschlüsseln umfasst; wobei das Verfahren umfasst Speichern eines öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40) und eines oder mehrerer privater Genehmigungsschlüssel einer kryptographischen Asset-Transaktion durch die Vielzahl der Hardware-Genehmigungsterminals (30); Ausgabe einer Transaktionsanforderung durch die Frontend-Anwendung (11), um eine kryptographische Asset-Transaktion an den Backend-Server (20) zu signieren, wobei die Transaktionsanforderung Folgendes umfasst eine Quell-Assetadresse, insbesondere den Namen des Asset-Adressschlüssels; eine Ziel-Assetadresse; und einen Asset-Transaktionswert; Anfordern der Genehmigungslogik der Quell-Assetadresse durch den Backend-Server (20) vom Hardware-Sicherheitsmodul (40); Empfangen der Genehmigungslogik der Quell-Assetadresse durch den Backend-Server (20) vom Hardware-Sicherheitsmodul (40); Senden der Transaktionsanforderung und der korrespondierenden Genehmigungslogik durch den Backend-Server (20) an die Hardware-Genehmigungsterminals (30); Anzeigen der Transaktionsanforderung und der Genehmigungslogik auf einem Display (33) des Hardware-Genehmigungsterminals; Empfangen einer Bestätigung der Transaktionsanforderung von Genehmigenden, die mit dem Hardware-Genehmigungsterminal (30) verknüpft sind; Verifizieren der Genehmigungslogik durch die Hardware-Genehmigungsterminals (30) mit Hilfe des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40); Senden von signierten Transaktionsgenehmigungen durch die Hardware-Genehmigungsterminals (30) an den Backend-Server (20), wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen; Weiterleiten der signierten Transaktionsgenehmigungen durch den Backend-Server (20) an das Hardware-Sicherheitsmodul (40) zur Verifizierung; Empfangen der signierten kryptographischen Asset-Transaktion durch den Backend-Server (20) vom Hardware-Sicherheitsmodul (40); und Bereitstellen der signierten kryptographischen Asset-Transaktion durch den Backend-Server (20) an einen Blockchain-Knoten.

15. Computerprogrammprodukt zum Betreiben der Backend-Anwendung (21) eines Systems (100) zum Durchführen von kryptographischen Asset-Transaktionen gemäss irgendeinem der Ansprüche 1-9, wobei das Computerprogrammprodukt ein computerlesbares Speichermedium mit darin ausgebildeten Programmbefehlen umfasst, wobei die Programmbefehle durch die Backend-Anwendung (21) eines Backend-Servers (20) ausführbar sind, um den Backend-Server (20) zu veranlassen, ein Verfahren auszuführen, das Folgendes umfasst Empfangen einer Transaktionsanforderung von einer Frontend-Anwendung (11), um eine kryptographische Asset-Transaktion zu signieren, wobei die Transaktionsanforderung Folgendes umfasst eine Quell-Assetadresse, insbesondere den Asset-Adressschlüsselnamen; eine Ziel-Assetadresse; und einen Asset-Transaktionswert; Anfordern einer Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul (40); Empfangen der Genehmigungslogik der Quell-Assetadresse vom Hardware-Sicherheitsmodul (40); Senden der Transaktionsanforderung und der korrespondierenden Genehmigungslogik an die Hardware-Genehmigungsterminals (30); Empfangen von signierten Transaktionsgenehmigungen von den Hardware-Genehmigungsterminals (30), wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen; Weiterleiten der signierten Transaktionsgenehmigungen an das Hardware-Sicherheitsmodul (40) zur Verifizierung; Empfangen einer signierten kryptographischen Asset-Transaktion vom Hardware-Sicherheitsmodul (40); und Bereitstellen der signierten kryptographischen Asset-Transaktion an einen Blockchain-Knoten.

16. Computerprogrammprodukt zum Betreiben von Hardware-Genehmigungsterminals (30) eines Systems (100) zum Durchführen von kryptographischen Asset-Transaktionen gemäss irgendeinem der Ansprüche 1-9, wobei das Computerprogrammprodukt ein computerlesbares Speichermedium mit darin ausgebildeten Programmbefehlen umfasst, wobei die Programmbefehle durch die Hardware-Genehmigungsterminals (30) ausführbar sind, um die Hardware-Genehmigungsterminals (30) zu veranlassen, ein Verfahren durchzuführen, das Folgendes umfasst Speichern eines öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40) und eines oder mehrerer privater Genehmigungsschlüssel von Genehmigern einer kryptographischen Asset-Transaktion; Empfangen einer Transaktionsanforderung und der korrespondierenden Genehmigungslogik vom Backend-Server (20); Verifizieren der Genehmigungslogik mit Hilfe des öffentlichen Schlüssels des Hardware-Sicherheitsmoduls (40); Anzeigen der Transaktionsanforderung und der Genehmigungslogik auf einem Display (33) des Hardware-Genehmigungsterminals (30); Empfangen einer Bestätigung der Transaktionsanforderung von Genehmigenden, die mit dem Hardware-Genehmigungsterminal (30) verknüpft sind; und Senden signierter Transaktionsgenehmigungen an den Backend-Server (20), wobei die signierten Transaktionsgenehmigungen den Asset-Adressschlüsselnamen und die Transaktionsanforderung umfassen.