WO2022063851A1 - Server zur abwicklung von transaktionen - Google Patents

Server zur abwicklung von transaktionen Download PDF

Info

Publication number
WO2022063851A1
WO2022063851A1 PCT/EP2021/076110 EP2021076110W WO2022063851A1 WO 2022063851 A1 WO2022063851 A1 WO 2022063851A1 EP 2021076110 W EP2021076110 W EP 2021076110W WO 2022063851 A1 WO2022063851 A1 WO 2022063851A1
Authority
WO
WIPO (PCT)
Prior art keywords
identity
distributed ledger
server
requesting
transaction
Prior art date
Application number
PCT/EP2021/076110
Other languages
English (en)
French (fr)
Inventor
Thomas BOCEK
Samuel EMDE
Daniel KILLENBERGER
Elliot WALMSLEY
Stephan D. MEYER
Original Assignee
Fqx Ag
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 Fqx Ag filed Critical Fqx Ag
Publication of WO2022063851A1 publication Critical patent/WO2022063851A1/de

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224Transactions dependent on location of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • G06Q20/38215Use of certificates or encrypted proofs of transaction rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4015Transaction verification using location information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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 using cryptographic hash functions
    • H04L9/3239Cryptographic 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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3263Cryptographic 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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the invention relates to a server for processing transactions, the server being designed for connection to a computer network which stores a distributed ledger which comprises a plurality of data blocks which are replicated, shared and synchronized between a number of computers in the computer network.
  • the invention further relates to a corresponding computer-aided system and a method for processing transactions.
  • DLT distributed ledger technology
  • DLT applications typically have, among other things: with the aim of making the use of a TTP unnecessary. DLT applications are also very well suited for processing anonymous transactions. However, it is often not easy to meet identification requirements within this framework.
  • the object of the invention is to create a server belonging to the technical field mentioned at the outset, which enables efficient processing of transactions with reliable identification of the transaction partners.
  • the server for processing transactions comprises the following: a) a linking module that is set up to receive a public key from a certification authority and to generate and store fingerprint data that represent the public key in one of the data blocks of the distributed ledger; b) an authorization module configured to store access authorizations associated with identity certificates issued by the certification authority in one of the data blocks of the distributed ledger; c) an input module that is set up to receive a
  • Transaction request from a requester where the request is signed with the requester's private key, signed with a public key of an identity certificate of the requesting authority issued by the certification authority; d) a verification module configured to verify an identity of the requesting entity based on the requesting entity's request, the stored fingerprint data and the stored access authorizations; e) a recording module that is set up to record a transaction that corresponds to the transaction request in a data block of the distributed ledger, provided that the identity has been successfully verified by the verification module.
  • a computer-assisted system for processing transactions accordingly comprises: a) a certification authority for issuing identity certificates, the identity certificates comprising a public key and an identity and being signed by the certification authority; b) a computer network storing a distributed ledger comprising a plurality of data blocks replicated, shared and synchronized between multiple computers of the computer network; c) a server according to the invention for processing transactions as described above.
  • a method according to the invention for processing transactions also includes the following steps: a) Storage of fingerprint data, which represents the public key of a certification authority, in one of a plurality of data blocks of a distributed ledger, the plurality of data blocks being replicated between a number of computers in a computer network , shared and synchronized; b) storing access credentials associated with identity certificates issued by the certification authority in one of the plurality of data blocks of the distributed ledger; c) receiving a transaction request from a requester, the request being signed with the requester's private key linked to a public key of a requester's identity certificate issued by the certification authority; d) verification of an identity of the requesting body, based on the request of the requesting body, the stored fingerprint data and the stored access authorizations; e) Recording a transaction corresponding to the transaction request in a data block of the distributed ledger, provided that the identity has been successfully verified by the verification module.
  • Server is to be understood broadly in the context of the present application. These are computing resources that can receive, process and output data.
  • a server within the meaning of the present application can be formed by a single computer or multiple computers and can be fully or partially virtualized.
  • the distributed ledger is in particular a private blockchain.
  • the certificate authority is a trusted third party (TTP).
  • the fingerprint data can be the public key itself or a processing result (digest) obtained from the public key or the certificate. Accordingly, in addition to the public key, the fingerprint data can include further information or can be obtained from further information.
  • the identity certificates are generated in particular based on the X.509 standard.
  • the access authorizations are linked to the identity certificates in particular using a unique identifier (serial number) of the respective certificates.
  • the transaction requirements are linked to a public key of an identity certificate in particular by using a qualified electronic signature (QES).
  • Corresponding certificates each comprise at least two linked certificates, namely the user certificate and one or more publisher certificates.
  • the appropriate certificate chain can be used to verify that the QES identity certificate comes from the appropriate issuer, namely the appropriate Certificate Authority (TTP).
  • the transaction request is generated independently of the distributed ledger ("off-chain") by the requesting body (or on behalf of the requesting body) and already includes the information necessary to verify the identity of the requesting body. The verification itself is then based on data stored in the distributed ledger ("on-chain").
  • the recording of the transaction may be subject to additional conditions, e.g. B. in relation to the possibility or validity of the transaction itself.
  • the server according to the invention and the method according to the invention are characterized in that certificates issued by TTP are linked using distributed ledger technology (DLT).
  • Transaction data can thus be stored reliably and securely in a distributed ledger, which e.g. B. also enables the use of smart contracts.
  • requirements can be met that require identification of the parties involved. Such requirements arise e.g. B. from legal provisions on the regulation of financial transactions, but the identifiability can of course also be desired by the parties involved.
  • the DLT (for processing the actual transactions) is thus combined with the use of a TTP or several TTPs (to ensure identification) in a new way in order to combine the advantages of both approaches.
  • the transaction request can relate in particular to the issue, transfer or settlement of financial instruments, in particular bills of exchange (promissory notes).
  • the system according to the invention thus serves to manage digital Security certificates (digital security certificates).
  • digital Security certificates digital security certificates
  • it is essential for the parties involved to have certainty about the identity of the transaction partner. Identification is also often mandatory due to regulatory requirements.
  • the invention can also be used in connection with other transactions, e.g. B. in the financial and real estate sector, especially where secure identification is required by the parties and/or due to legal regulations.
  • the authorization module is set up to store assignments to administrators' identity certificates
  • the input module is set up to receive transaction requests that include an access certificate with an administrator's signature
  • the verification module is set up to check whether the administrator's signature is one of Identity certificates linked to the stored access permissions.
  • the access authorizations are assigned identity certificates from administrators
  • the transaction request from the requesting body includes an access certificate with an administrator's signature
  • a successful verification of the identity requires that the administrator's signature be linked to one of the identity certificates of the stored access authorizations is.
  • the assignment to the identity certificates takes place in particular with the help of a unique identifier (serial number) of the certificates.
  • the publisher certification authority
  • identity certificates from different publishers can be used without further ado if necessary, provided that the corresponding fingerprint data of these publishers are stored in the distributed ledger as explained above.
  • Administrators can now authorize other people to request transactions based on their identity certificates by providing them with an access certificate. This is essentially a piece of data signed by the administrator, specifically with a QES. In this way, such authorizations are granted outside of the distributed ledger (off- chain). Authorization is checked using the administrator's access authorization stored on-chain, the access certificate, i.e. the data portion with the administrator's signature, and the identity certificate of the requesting authority.
  • the access certificate preferably includes a unique identifier for the requesting party (e.g. a unique identifier for the identity certificate) and an association with an entity. This ensures that the access certificate can only be used by a designated, clearly identified person to request transactions, i.e. it cannot be transferred to other persons.
  • a unique identifier for the identity certificate e.g. a unique identifier for the identity certificate
  • an association with an entity e.g. a unique identifier for the identity certificate
  • an entity e.g. a unique identifier for the identity certificate
  • the administrators and authorized bodies can be assigned to a common entity.
  • the administrators and authorized bodies are in particular natural persons (for whom identity certificates can usually be issued), the entity is in particular a legal person, e.g. B. a company.
  • the assignment to the entity takes place, for example, via standardized, state-administered numbers (e.g. company numbers or codes, supplemented with information on the respective jurisdiction).
  • large and complexly organized companies can also be mapped in a simple manner, in that ultimately only the administrators have to be managed in the distributed ledger, while the administration of the specific authorizations takes place within the company by issuing the access certificates.
  • the data portion of the access certificate may include other information, e.g. B. in relation to the signing rights of the authorized person. So e.g. B. it can be noted that the person can only validly sign together with another (specified or unspecified) authorized person of the entity.
  • the access certificates advantageously have a limited period of validity, so that authorizations have to be checked regularly.
  • the access authorizations of the authorized users are stored directly on-chain. It is also possible to enable both variants in the same system, ie both directly authorized and delegated, authorized bodies can make transaction requests.
  • verifying the identity of the requester includes verifying that the requester is not listed in a revocation list stored in a data block of the distributed ledger.
  • the access certificates are advantageously stored off-chain in that they are issued by the administrators by means of certificates and are transmitted in transactions as part of the transaction request.
  • the identity certificates are also issued off-chain, in particular by a certification authority that is independent of the system.
  • the transaction can be encrypted before recording using symmetric encryption, so transactions can be discarded by deleting an encryption/decryption key.
  • the content of the transaction is encrypted using the symmetric encryption method (e.g. AES 256 bit) encrypted and stored in the distributed ledger. If the encryption/decryption key is deleted, the corresponding information can no longer be accessed. The transaction is therefore no longer visible and therefore no longer effective.
  • the symmetric encryption method e.g. AES 256 bit
  • transaction requests can be signed by multiple (two or more) parties.
  • a corresponding transaction request is thus signed by additional parties involved in the transaction to be recorded, and the identity of the additional parties is verified on the basis of the respective stored fingerprint data and stored access authorizations.
  • Such transactions include, for example, the transfer or settlement of a bill of exchange where the old and new holders or the issuer and the (current) holder must sign for the transaction to be valid.
  • the storage of access authorizations in a data block can also be made dependent on an identity check that is independent of the identity certificate.
  • Such an examination includes, for example, a real or virtual interview, verification of identity documents, etc.
  • 1 shows a block diagram of the participants in transactions according to the system according to the invention
  • 2 shows a flow chart of a method according to the invention for processing transactions.
  • the exemplary embodiment described here relates to transactions in connection with bills of exchange or promissory notes (promissory notes), namely transactions between companies (legal entities).
  • a bill of exchange one party (the issuer) promises to pay another party (the drawee) a specified sum to that other party or a third party (payee) at a time due.
  • each of the involved parties is assigned specific users (natural persons) who can act on behalf of the parties, i.e. H. can provide binding (virtual) signatures in the context of the transactions.
  • Figure 1 is a block diagram showing in a simplified manner the participants in such transactions.
  • a user company 10 is shown with a natural person as administrator 11 and several natural persons as users 15.1, 15.2, 15.3.
  • User company 10 is for example only. Transactions usually involve several such user companies, each of which can also assume different roles. All user companies are integrated into the system in the same way.
  • the service provider's computer-assisted system 100 which includes a server 101 with communication interfaces and computing resources and a private blockchain 150, which is managed by the service provider itself or by another service provider on behalf of the service provider.
  • a private blockchain 150 which is managed by the service provider itself or by another service provider on behalf of the service provider.
  • data is stored in blocks of data, which blocks of data are replicated, shared and synchronized between multiple computers on a computer network.
  • the server 101 comprises a linking module 102, an authorization module 103, an input module 104, a verification module 105 and a recording module 106.
  • a certification authority 200 for issuing identity certificates is also involved.
  • these are certificates for qualified electronic signatures (QES).
  • QES qualified electronic signatures
  • Each of the certificates comprises two or more certificates that are chained together, namely the user certificate of the respective natural person whose identity is to be confirmed and one or more publisher certificates chained to it.
  • Several certification authorities can be provided, whose certificates are accepted by the service provider.
  • the user company 10 or the administrator 11 and the users 15.1. . , 3 interact with the certification authority 200 to obtain identity certificates associated with the administrator 11 and the users 15.1...3, respectively.
  • the service provider's server 101 also interacts with the certification authority 200, e.g. B. to obtain publisher certificates.
  • the linking module 102 of the server 101 receives an issuer's certificate from the certification authority 200 and stores a fingerprint derived from its public key in the blockchain 150 (step 301).
  • the fingerprint is obtained from the data in the certificate, which is available in pem format, for example. It is obtained, for example, by applying a SHA-256 hash function to this data.
  • the public key of the certificate for example, is suitable for obtaining the fingerprint. Other elements can be used.
  • Fingerprints of identity certificates from administrators 1 1 , linked to information about the user company 10 are stored by the authorization module 103 of the server 101 in the blockchain 150 (step 302).
  • the administrator 11 recorded in this way can then grant users 15. 1 ... 3 authorization to act on behalf of the user company 10 with respect to the service provider.
  • Authorized Users 15.1. ..3 can then interact with the service provider's server 101 within the framework of transactions. To do this, they transmit a corresponding transaction request to the server 101 via the input module 104 of the server 101, which includes, among other things, data portions signed by the user and the authorization certificate received from the administrator 11 (step 304).
  • the verification module 105 of the server 101 in addition to the signatures of the signing users, using the stored fingerprint of the publisher's certificate, also checks whether they have authorization for the legal person concerned (step 305). After a successful check, data about the transactions or the changes affected by them are also stored in the blockchain 150 by the recording module 106 (step 306).
  • the signature of the user signing the bill of exchange This consists of a hash of the following elements signed by the user: the hash of the bill of exchange, the name of the user's legal entity and a hash of any conditions that may exist (discounts or other information that is not visible in the bill of exchange but can still be checked during the signing process). should); 2.
  • a signature of an administrator of the legal entity This consists of a hash signed by the administrator of the following elements: the unique sequence number of the user and the designation of the legal entity of the administrator and the user;
  • a change (promissory note PN) is represented in the system described by a structure with the following elements:
  • the signature structure of the bill of exchange includes several signature structures and more
  • the issuer and the (initial) holder agree on the hash of the information according to the main structure (item 1 above) and the legal entity of the holder.
  • the issuer In the case of a combined issuance and transmission, the issuer must sign the same data as in the case of issuance. In the case of the original and new owner, the legal entity of the new owner and any conditions for the transfer are added to the data to be signed.
  • the promissory note structure is used to check whether the transfer of the bill of exchange is restricted and, if so, whether the intended transfer is permissible within the framework of the restrictions.
  • a bill of exchange can be processed - especially after the issuer has paid the agreed amount - at the request of the (current) owner. To do this, the owner signs a piece of data with the identification number of the bill of exchange, the note that the bill of exchange has been completed and the legal entity of the owner. No further signatures are required for completion.
  • a signature is valid if the corresponding certificate is valid, the authorization of the signatory has not been revoked (see below) and the signing user is linked to the acting legal entity via valid access authorization.
  • stored signing authorizations e.g. regarding collective signing authorization
  • the validity of signatures within the framework of the system described is checked according to the following steps, each applied to each signature of a PN:
  • the corresponding certificate data is obtained, both for the signing user and for the assigned administrator.
  • the Promissory Notes stored in the blockchain are encrypted with a symmetric key, for example using AES encryption.
  • the key (and possibly also an initialization vector) is generated and stored off-chain. It is required to access the Promissory Note; if it is deleted, the information in the corresponding Promissory Note can no longer be read or written to. Accordingly, the Promissory Note loses all effect and, despite the storage of the corresponding data in the blockchain, it is no longer clear what its content was.
  • the invention is not limited to the illustrated embodiment. Thus, specific aspects of the described system and method may be implemented differently. In addition, the invention can be used not only for processing transactions in connection with bills of exchange or other financial instruments, but also for other transactions.
  • the invention creates a server, a system and a method that enable transactions to be processed efficiently with reliable identification of the transaction partners.

Abstract

Ein Server (101) zur Abwicklung von Transaktionen ist zur Verbindung mit einem Computernetzwerk ausgebildet, das einen Distributed Ledger (150) speichert, welcher eine Mehrzahl von Datenblöcken umfasst, die zwischen mehreren Rechnern des Computernetzwerks repliziert, geteilt und synchronisiert sind. Der Server (101) umfasst ein Verknüpfungsmodul (102), das eingerichtet ist zum Empfangen eines öffentlichen Schlüssels einer Zertifizierungsstelle (200) und zum Generieren und Speichern von Fingerprintdaten, die den öffentlichen Schlüssel repräsentieren, in einem der Datenblöcke des Distributed Ledger (150). Der Server (101) umfasst weiter ein Berechtigungsmodul (103), das eingerichtet ist zum Speichern von Zugriffsberechtigungen, die mit von der Zertifizierungsstelle (200) ausgegebenen Identitätszertifikaten verknüpft sind, in einem der Datenblöcke des Distributed Ledger (150). Er umfasst weiter ein Eingangsmodul (104), das eingerichtet ist zum Empfangen einer Transaktionsanforderung von einer anfordernden Stelle (10), wobei die Anforderung mit dem privaten Schlüssel der anfordernden Stelle (10) signiert ist, der mit einem öffentlichen Schlüssel eines von der Zertifizierungsstelle (200) ausgegebenen Identitätszertifikats der anfordernden Stelle (10) verknüpft ist. Der Server (10) umfasst weiter ein Überprüfungsmodul (105), das eingerichtet ist zum Überprüfen einer Identität der anfordernden Stelle (10), gestützt auf die Anforderung der anfordernden Stelle (10), den gespeicherten Fingerprintdaten und den gespeicherten Zugriffsberechtigungen, und ein Aufzeichnungsmodul (106), das eingerichtet ist zum Aufzeichnen einer Transaktion, die der Transaktionsanforderung entspricht, in einem Datenblock des Distributed Ledger (150), sofern die Identität erfolgreich durch das Überprüfungsmodul (105) verifiziert wurde.

Description

Server zur Abwicklung von Transaktionen
Technisches Gebiet
Die Erfindung betrifft einen Server zur Abwicklung von Transaktionen, wobei der Server zur Verbindung mit einem Computernetzwerk ausgebildet ist, das einen Distributed Ledger speichert, welcher eine Mehrzahl von Datenblöcken umfasst, die zwischen mehreren Rechnern des Computernetzwerks repliziert, geteilt und synchronisiert sind. Die Erfindung betrifft weiter ein entsprechendes computergestütztes System und ein Verfahren zur Abwicklung von Transaktionen.
Stand der Technik
Herkömmlich wurden Transaktionen mit Wertpapieren, z. B. solche in Bezug auf Wechsel, gestützt auf physische Dokumente, abgewickelt. Dies ist aber gerade im internationalen Verkehr oder bei kurzfristigen Geschäften sehr umständlich. Es besteht entsprechend ein Bedürfnis, solche Transaktionen rein elektronisch durchzuführen. Dabei sind strenge finanzrechtliche Vorschriften zu beachten - zudem kommt es bei solchen Transaktionen oft entscheidend darauf an, dass sich die beteiligten Parteien einander gegenüber verlässlich identifizieren.
Es sind zahlreiche Verfahren zur elektronischen Abwicklung von Finanztransaktionen bekannt. Sie lassen sich üblicherweise in zwei Gruppen unterteilen: Verfahren der ersten Gruppe bedienen sich eines Dienstleisters (Trusted Third Party), der von allen beteiligten Parteien als vertrauenswürdig eingestuft wird und die Transaktion im Auftrag der Parteien abwickelt. Verfahren der zweiten Gruppe basieren auf der so genannten Distributed- Ledger-Technologie (DLT), bei der die Daten in einem Computernetzwerk abgelegt sind, und zwar in einer Mehrzahl von Datenblöcken, die zwischen mehreren Rechnern des Computernetzwerks repliziert, geteilt und synchronisiert sind. Die Datenblöcke sind untereinander so verknüpft, dass neue Transaktionen innerhalb des Netzwerks stets nachgeführt werden und bei divergierenden Dateninhalten Konsens geschaffen wird, welche Daten als korrekt anzusehen sind. Sicherheit wird zudem durch den Einsatz von kryptografischen Verfahren und elektronischen Signaturen geschaffen. Ein Beispiel einer DLT bildet die Blockchain-Technologie.
DLT-Anwendungen haben in der Regel u. a. zum Ziel, dass sich der Einsatz einer TTP erübrigt. Zur Abwicklung anonymer Transaktionen sind DLT-Anwendungen denn auch sehr gut geeignet. Anforderungen zur Identifizierung kann in deren Rahmen aber oft nicht auf einfache Weise Genüge getan werden.
Darstellung der Erfindung
Aufgabe der Erfindung ist es, einen dem eingangs genannten technischen Gebiet zugehörenden Server zu schaffen, der eine effiziente Abwicklung von Transaktionen bei sicherer Identifikation der Transaktionspartner ermöglicht.
Die Lösung der Aufgabe ist durch die Merkmale des Anspruchs 1 definiert. Gemäss der Erfindung umfasst der Server zur Abwicklung von Transaktionen folgendes: a) ein Verknüpfungsmodul, das eingerichtet ist zum Empfangen eines öffentlichen Schlüssels einer Zertifizierungsstelle und zum Generieren und Speichern von Fingerprintdaten, die den öffentlichen Schlüssel repräsentieren, in einem der Datenblöcke des Distributed Ledger; b) ein Berechtigungsmodul, das eingerichtet ist zum Speichern von Zugriffsberechtigungen, die mit von der Zertifizierungsstelle ausgegebenen Identitätszertifikaten verknüpft sind, in einem der Datenblöcke des Distributed Ledger; c) ein Eingangsmodul, das eingerichtet ist zum Empfangen einer
Transaktionsanforderung von einer anfordernden Stelle, wobei die Anforderung mit dem privaten Schlüssel der anfordernden Stelle signiert ist, der mit einem öffentlichen Schlüssel eines von der Zertifizierungsstelle ausgegebenen Identitätszertifikats der anfordernden Stelle verknüpft ist; d) ein Überprüfungsmodul, das eingerichtet ist zum Überprüfen einer Identität der anfordernden Stelle, gestützt auf die Anforderung der anfordernden Stelle, den gespeicherten Fingerprintdaten und den gespeicherten Zugriffsberechtigungen; e) ein Aufzeichnungsmodul, das eingerichtet ist zum Aufzeichnen einer Transaktion, die der Transaktionsanforderung entspricht, in einem Datenblock des Distributed Ledger, sofern die Identität erfolgreich durch das Überprüfungsmodul verifiziert wurde.
Ein erfindungsgemässes computergestütztes System für die Abwicklung von Transaktionen umfasst entsprechend: a) eine Zertifizierungsstelle zur Ausgabe von Identitätszertifikaten, wobei die Identitätszertifikate einen öffentlichen Schlüssel und eine Identität umfassen und von der Zertifizierungsstelle signiert sind; b) ein Computernetzwerk, das einen Distributed Ledger speichert, welcher eine Mehrzahl von Datenblöcken umfasst, die zwischen mehreren Rechnern des Computernetzwerks repliziert, geteilt und synchronisiert sind; c) einen erfindungsgemässen Server zur Abwicklung von Transaktionen wie vorstehend beschrieben.
Ein erfindungsgemässes Verfahren zur Abwicklung von Transaktionen, umfasst zudem entsprechend die folgenden Schritte: a) Speichern von Fingerprintdaten, die den öffentlichen Schlüssel einer Zertifizierungsstelle repräsentieren, in einem einer Mehrzahl von Datenblöcken eines Distributed Ledger, wobei die Mehrzahl von Datenblöcken zwischen mehreren Rechnern eines Computernetzwerks repliziert, geteilt und synchronisiert sind; b) Speichern von Zugriffsberechtigungen, die mit von der Zertifizierungsstelle ausgegebenen Identitätszertifikaten verknüpft sind, in einem der Mehrzahl von Datenblöcken des Distributed Ledger; c) Empfangen einer Transaktionsanforderung einer anfordernden Stelle, wobei die Anforderung mit dem privaten Schlüssel der anfordernden Stelle signiert ist, der mit einem öffentlichen Schlüssel eines von der Zertifizierungsstelle ausgegebenen Identitätszertifikats der anfordernden Stelle verknüpft ist; d) Überprüfung einer Identität der anfordernden Stelle, gestützt auf die Anfrage der anfordernden Stelle, den gespeicherten Fingerprintdaten und den gespeicherten Zugriffsberechtigungen; e) Aufzeichnen einer Transaktion, die der Transaktionsanforderung entspricht, in einem Datenblock des Distributed Ledger, sofern die Identität erfolgreich durch das Überprüfungsmodul verifiziert wurde.
"Server" ist im Rahmen der vorliegenden Anmeldung breit zu verstehen. Es handelt sich um Rechnermittel, die Daten empfangen, verarbeiten und ausgeben können. Ein Server im Sinn der vorliegenden Anmeldung kann durch einen einzelnen Rechner oder mehrere Rechner gebildet und ganz oder teilweise virtualisiert sein.
Beim Distributed Ledger handelt es sich insbesondere um eine private Blockchain. Die Zertifizierungsstelle ist ein vertrauenswürdiger Dritter (Trusted Third Party, TTP).
Bei den Fingerprintdaten kann es sich um den öffentlichen Schlüssel selbst handeln oder um ein Verarbeitungsergebnis (digest), das aus dem öffentlichen Schlüssel bzw. dem Zertifikat gewonnen wird. Entsprechend können die Fingerprintdaten nebst dem öffentlichen Schlüssel weitere Informationen umfassen bzw. aus weiteren Informationen gewonnen werden.
Die Identitätszertifikate werden insbesondere gestützt auf den Standard X.509 erzeugt. Die Verknüpfung der Zugriffsberechtigungen mit den Identitätszertifikaten erfolgt insbesondere anhand einer eindeutigen Kennung (serial number) der jeweiligen Zertifikate. Die Verknüpfung der Transaktionsanforderungen mit einem öffentlichen Schlüssel eines Identitätszertifikats erfolgt insbesondere durch die Anwendung einer qualifizierten elektronischen Signatur (QES). Entsprechende Zertifikate umfassen jeweils mindestens zwei miteinander verkettete Zertifikate, namentlich das Nutzerzertifikat und eines oder mehrere Herausgeberzertifikate. Mithilfe der entsprechenden Zertifikatskette kann verifiziert werden, dass das QES-Identitätszertifikat vom entsprechenden Herausgeber, namentlich der entsprechenden Zertifizierungsstelle (TTP), stammt.
Die Transaktionsanforderung wird unabhängig vom Distributed Ledger ("off-chain") von der anfordernden Stelle (oder im Auftrag der anfordernden Stelle) erzeugt und umfasst bereits die zur Überprüfung der Identität der anfordernden Stelle notwendigen Informationen. Die Überprüfung selbst erfolgt dann anhand von Daten, die im Distributed Ledger abgelegt sind ("on-chain").
Die Aufzeichnung der Transaktion kann von weiteren Bedingungen abhängig sein, z. B. in Bezug auf die Möglichkeit oder Gültigkeit der Transaktion selbst.
Der erfindungsgemässe Server und das erfindungsgemässe Verfahren zeichnen sich dadurch aus, dass Zertifikate, die von TTP ausgestellt werden, mit Distributed-Ledger- Technologie (DLT) verknüpft werden. Transaktionsdaten lassen sich somit zuverlässig und sicher in einem Distributed Ledger ablegen, was z. B. auch die Nutzung von Smart Contracts ermöglicht. Gleichzeitig kann Anforderungen Genüge getan werden, die eine Identifizierung der involvierten Parteien verlangen. Solche Anforderungen ergeben sich z. B. aus rechtlichen Bestimmungen zur Regulierung von Finanztransaktionen, die Identifizierbarkeit kann aber natürlich auch von den beteiligten Parteien selbst gewünscht sein.
Die DLT (zur Abwicklung der eigentlichen Transaktionen) wird also mit der Nutzung einer TTP oder mehrerer TTPs (zur Sicherstellung der Identifikation) in einer neuartigen Weise verknüpft, um die Vorteile beider Ansätze miteinander zu verbinden.
Die Transaktionsanfrage kann insbesondere die Ausgabe, die Übertragung oder die Verrechnung von Finanzinstrumenten, insbesondere von Wechseln (promissory notes), betreffen. Das erfindungsgemässe System dient somit zur Verwaltung von digitalen Sicherheitszertifikaten (digital security certificates). In diesem Zusammenhang ist es für die beteiligten Parteien essenziell, Sicherheit über die Identität der Transaktionspartner zu haben. Eine Identifizierung ist auch aufgrund regulatorischer Anforderungen oft zwingend.
Die Erfindung lässt sich auch im Zusammenhang mit anderen Transaktionen, z. B. im Finanz- und Immobilienbereich, einsetzen, insbesondere dort, wo eine sichere Identifikation von den Parteien und/oder aufgrund rechtlicher Vorschriften gefordert ist.
Mit Vorteil ist das Berechtigungsmodul eingerichtet zum Speichern von Zuordnungen zu Identitätszertifikaten von Administratoren, das Eingangsmodul ist eingerichtet zum Empfangen von Transaktionsanforderungen, die ein Zugriffszertifikat mit einer Signatur eines Administrators umfassen, und das Überprüfungsmodul ist eingerichtet zur Prüfung, ob die Signatur des Administrators mit einem der Identitätszertifikate der gespeicherten Zugriffsberechtigungen verknüpft ist.
Somit sind im Rahmen des erfindungsgemässen Verfahrens den Zugriffsberechtigungen Identitätszertifikate von Administratoren zugeordnet, die Transaktionsanforderung der anfordernden Stelle umfasst ein Zugriffszertifikat mit einer Signatur eines Administrators, und eine erfolgreiche Überprüfung der Identität setzt voraus, dass die Signatur des Administrators mit einem der Identitätszertifikate der gespeicherten Zugriffsberechtigungen verknüpft ist.
Die Zuordnung zu den Identitätszertifikaten erfolgt insbesondere mit Hilfe einer eindeutigen Kennung (serial number) der Zertifikate. Daneben ist mit Vorteil der Herausgeber (Zertifizierungsstelle) vermerkt, so dass bei Bedarf Identitätszertifikate verschiedener Herausgeber ohne Weiteres genutzt werden können, vorausgesetzt entsprechende Fingerprintdaten dieser Herausgeber sind wie oben erläutert im Distributed Ledger abgelegt.
Administratoren können nun - gestützt auf deren Identitätszertifikate - weiteren Personen die Berechtigung zur Anforderung von Transaktionen erteilen, indem sie diesen ein Zugriffszertifikat zur Verfügung stellen. Dabei handelt es sich im Wesentlichen um eine Datenportion, die vom Administrator signiert ist, insbesondere mit einer QES. Die Erteilung solcher Berechtigungen erfolgt auf diese Weise ausserhalb des Distributed Ledger (off- chain). Die Prüfung der Berechtigung erfolgt anhand der on-chain gespeicherten Zugriffsberechtigung des Administrators, des Zugriffszertifikats, also der Datenportion mit der Signatur des Administrators, und des Identitätszertifikats der anfordernden Stelle.
Daneben werden natürlich alle involvierten Identitätszertifikate auf ihre Gültigkeit hin geprüft, wie oben erläutert wiederum mit Hilfe von Daten, die on-chain gespeichert sind (Fingerprintdaten).
Bevorzugt umfasst das Zugriffszertifikat eine eindeutige Kennung der anfordernden Stelle (z. B. eine eindeutige Kennung des Identitätszertifikats) und eine Zuordnung zu einer Entität. Dadurch wird sichergestellt, dass das Zugriffszertifikat nur von einer designierten, eindeutig identifizierten Person, zur Anforderung von Transaktionen genutzt werden kann, sie also nicht an andere Personen übertragbar ist. Zudem lassen sich jeweils mehrere Administratoren und/oder berechtigte anfordernde Stellen einer gemeinsamen Entität zuordnen. Bei den Administratoren und berechtigen Stellen handelt es sich insbesondere um natürliche Personen (für welche gängigerweise Identitätszertifikate ausgegeben werden können), bei der Entität handelt es sich insbesondere um eine juristische Person, z. B. ein Unternehmen. Die Zuordnung zur Entität erfolgt beispielsweise über standardisierte, staatlich verwaltete Nummern (z. B. Unternehmensnummern bzw. - Kennziffern, ergänzt mit einer Angabe zur jeweiligen Jurisdiktion).
Im Rahmen der Erfindung können somit auch grosse und komplex organisierte Unternehmen auf einfache Weise abgebildet werden, indem im Distributed Ledger letztlich nur die Administratoren verwaltet werden müssen, während die Verwaltung der spezifischen Berechtigungen unternehmensintern durch das Ausstellen der Zugriffszertifikate erfolgt.
Die Datenportion des Zugriffszertifikats kann weitere Informationen umfassen, z. B. in Bezug auf die Zeichnungsrechte (signing rights) der berechtigten Person. So kann z. B. vermerkt sein, dass die Person nur zusammen mit einer weiteren (spezifizierten oder nicht spezifizierten) berechtigten Person der Entität gemeinsam wirksam signieren kann.
Die Zugriffszertifikate haben mit Vorteil eine beschränkte zeitliche Gültigkeit, so dass Berechtigungen regelmässig überprüft werden müssen. In einer einfacheren, alternativen Ausführungsform der Erfindung werden direkt die Zugriffsberechtigungen der berechtigten Nutzer on-chain gespeichert. Es ist auch möglich, beide Varianten in demselben System zu ermöglichen, d. h. es können sowohl direkt berechtigte als auch delegiert, berechtigte Stellen Transaktionsanforderungen stellen.
Mit Vorteil umfasst die Überprüfung der Identität der anfordernden Stelle eine Überprüfung, ob die anfordernde Stelle nicht in einer Widerrufsliste aufgeführt ist, die in einem Datenblock des Distributed Ledgers gespeichert ist.
Dadurch kann sichergestellt werden, dass nicht mehr berechtigte Stellen keine gültigen Transaktionsanforderungen mehr stellen können, denn Nutzer mit gültigem Identitätszertifikat können weiterhin Daten qualifiziert elektronisch signieren und on-chain ist nicht bekannt, welche Stellen von den verzeichneten Administratoren durch Ausstellung entsprechender Zugriffszertifikate berechtigt wurden.
Bevorzugt sind die folgenden Elemente on-chain gespeichert:
- die Transaktionsdaten (ggf. einschliesslich der Finanzinstrumente in virtueller Form);
- Daten zur Identifikation der Echtheit der Zertifikate zugelassener Zertifikationsdienste;
- die berechtigten Administratoren mit Zuordnung zur jeweiligen juristischen Person;
- die Widerrufsliste.
Die Zugriffszertifikate sind dagegen mit Vorteil off-chain gespeichert, indem diese mittels Zertifikaten von den Administratoren erteilt und bei Transaktionen jeweils im Rahmen der Transaktionsanforderung übermittelt werden. Auch die Erteilung der Identitätszertifikate erfolgt off-chain, insbesondere durch eine vom System unabhängige Zertifizierungsstelle.
Die Transaktion kann vor der Aufzeichnung unter Verwendung einer symmetrischen Verschlüsselung verschlüsselt werden, so dass Transaktionen durch Löschen eines Ver- /Entschlüsselungsschlüssels verworfen werden können.
Nach Erhalt und erfolgreicher Prüfung einer Transaktionsaufforderung wird der Inhalt der Transaktion somit mit Hilfe des symmetrischen Verschlüsselungsverfahrens (z. B. AES 256 bit) verschlüsselt und im Distributed Ledger abgelegt. Wenn der Ver- /Entschlüsselungsschlüssel gelöscht wird, kann auf die entsprechende Information nicht mehr zugegriffen werden. Die Transaktion ist somit nicht mehr ersichtlich und so auch nicht mehr wirksam.
Mit Vorteil können Transaktionsanforderungen von mehreren (zwei oder mehr) Parteien unterzeichnet werden. Eine entsprechende Transaktionsanforderung ist also von zusätzlichen Parteien unterzeichnet, die an der aufzuzeichnenden Transaktion beteiligt sind, und die Identität der zusätzlichen Parteien wird auf der Grundlage der jeweiligen gespeicherten Fingerprintdaten und gespeicherten Zugriffsberechtigungen überprüft.
Solche Transaktionen beinhalten beispielsweise die Übertragung oder Begleichung eines Wechsels, wo der alte und der neue Inhaber bzw. der Herausgeber und der (aktuelle) Inhaber unterzeichnen müssen, damit die Transaktion gültig ist.
In Anwendungen, wo die Identität der beteiligten Parteien durch einen gesonderten Prozess überprüft werden muss, z. B. im Rahmen von "Know Your Customer"- Anforderungen im Finanzbereich, kann das Speichern der Zugriffsberechtigungen in einem Datenblock zusätzlich von einer Identitätsprüfung abhängig gemacht werden, die unabhängig ist vom Identitätszertifikat.
Eine solche Prüfung beinhaltet beispielsweise ein reales oder virtuelles Interview, die Prüfung von Ausweisdokumenten usw.
Aus der nachfolgenden Detailbeschreibung und der Gesamtheit der Patentansprüche ergeben sich weitere vorteilhafte Ausführungsformen und Merkmalskombinationen der Erfindung.
Kurze Beschreibung der Zeichnungen
Die zur Erläuterung des Ausführungsbeispiels verwendeten Zeichnungen zeigen:
Fig. 1 ein Blockdiagramm der Mitwirkenden in Transaktionen gemäss dem erfindungsgemässen System; und Fig. 2 ein Flussdiagramm eines erfindungsgemässen Verfahrens zum Abwickeln von Transaktionen.
Grundsätzlich sind in den Figuren gleiche Elemente mit gleichen Bezugszeichen versehen.
Wege zur Ausführung der Erfindung
Das hier beschriebene Ausführungsbeispiel betrifft Transaktionen im Zusammenhang mit Wechseln bzw. Schuldscheindarlehen (Promissory Notes), namentlich Transaktionen zwischen Unternehmen (juristischen Personen). In einem solchen Wechsel verspricht eine Partei (der Aussteller), einer anderen Partei (dem Bezogenen) zu einem Fälligkeitszeitpunkt eine bestimmte Summe an diese andere Partei oder einen Dritten (Zahlungsempfänger) zu bezahlen.
Im Rahmen des beschriebenen Systems sind jeder der beteiligten Parteien (juristischen Personen) bestimmte Nutzer (natürliche Personen) zugeordnet, die im Namen der Parteien handeln können, d. h. bindend (virtuelle) Unterschriften im Rahmen der Transaktionen leisten können.
Die Figur 1 zeigt ein Blockdiagramm, in dem auf vereinfachte Weise die Mitwirkenden in solchen Transaktionen dargestellt sind. Dargestellt ist ein Nutzerunternehmen 10 mit einer natürlichen Person als Administrator 1 1 und mehreren natürlichen Personen als Nutzer 15.1 , 15.2, 15.3.
Das Nutzerunternehmen 10 dient nur als Beispiel. In Transaktionen sind in der Regel mehrere solche Nutzerunternehmen involviert, die jeweils auch unterschiedliche Rollen wahrnehmen können. Alle Nutzerunternehmen sind auf dieselbe Art und Weise in das System eingebunden.
Weiter dargestellt ist das computergestützte System 100 des Dienstleisters, das u.a. einen Server 101 mit Kommunikationsschnittstellen und Rechnermitteln umfasst und eine private Blockchain 150, die vom Dienstleister selbst oder im Auftrag des Dienstleisters von einem weiteren Dienstleister verwaltet wird. In der Blockchain sind in an sich bekannter Weise Daten in Datenblöcken gespeichert, wobei die Datenblöcke zwischen mehreren Rechnern eines Computernetzwerks repliziert, geteilt und synchronisiert sind.
Der Server 101 umfasst ein Verknüpfungsmodul 102, ein Berechtigungsmodul 103, ein Eingangsmodul 104, ein Überprüfungsmodul 105 und ein Aufzeichnungsmodul 106.
Weiter involviert ist eine Zertifizierungsstelle 200 zur Ausgabe von Identitätszertifikaten. Dabei handelt es sich im dargestellten Beispiel um Zertifikate für qualifizierte elektronische Signaturen (QES). Jedes der Zertifikate umfasst zwei oder mehr Zertifikate, welche miteinander verkettet sind, namentlich das Nutzerzertifikat der jeweiligen natürlichen Person, deren Identität bestätigt werden soll und eines oder mehrere damit verkettete Herausgeberzertifikate. Es können mehrere Zertifizierungsstellen vorgesehen sein, deren Zertifikate vom Dienstleister akzeptiert werden.
Das Nutzerunternehmen 10 bzw. der Administrator 1 1 und die Nutzer 15.1. . , 3 interagieren mit der Zertifizierungsstelle 200 zum Erhalt von Identitätszertifikaten, die dem Administrator 1 1 bzw. den Nutzern 15.1 ... 3 zugeordnet sind. Der Server 101 des Dienstleisters interagiert ebenfalls mit der Zertifizierungsstelle 200, z. B. zum Erhalt von Herausgeberzertifikaten.
Ein vereinfachtes Flussdiagramm eines erfindungsgemässen Verfahrens zum Abwickeln von Transaktionen ist in der Figur 2 dargestellt. Zunächst erhält das Verknüpfungsmodul 102 des Servers 101 von der Zertifizierungsstelle 200 ein Herausgeberzertifikat und speichert einen aus dessen öffentlichen Schlüssel abgeleiteten Fingerprint in der Blockchain 150 (Schritt 301).
Der Fingerprint wird aus den Daten des Zertifikats gewonnen, das beispielsweise im pem- Format vorliegt. Er wird beispielsweise durch die Anwendung einer SHA-256-Hashfunktion auf diese Daten gewonnen. Für die Gewinnung des Fingerprints geeignet ist beispielsweise der öffentliche Schlüssel (Public Key) des Zertifikats. Weitere Elemente können herangezogen werden.
Fingerprints von Identitätszertifikaten von Administratoren 1 1 , verknüpft mit Angaben zum Nutzerunternehmen 10 (z. B. mit einer eindeutigen Firmenkennung bzw. Unternehmensnummer) werden vom Berechtigungsmodul 103 des Servers 101 in der Blockchain 150 abgelegt (Schritt 302). Der so erfasste Administrator 1 1 kann dann Nutzern 15. 1 ... 3 eine Berechtigung erteilen, um im Namen des Nutzerunternehmens 10 gegenüber dem Dienstleister zu handeln. Dazu signiert er eine Datenportion, die die eindeutige Kennung des zu berechtigenden Nutzers (serial number des entsprechenden Identitätszertifikats) umfasst und die Angabe der juristischen Person, für welche der Administrator und der Nutzer handeln (sollen). Das so erzeugte Berechtigungszertifikat überlässt er dem jeweiligen Nutzer 15. 1 ... 3 zu dessen Verwendung (Schritt 303).
Die berechtigten Nutzer 15.1 . ..3 können dann mit dem Server 101 des Dienstleisters im Rahmen von Transaktionen Zusammenwirken. Dazu übermitteln sie über das Eingangsmodul 104 des Servers 101 eine entsprechende Transaktionsanforderung an den Server 101, die u.a. durch den Nutzer signierte Datenportionen und das vom Administrator 1 1 erhaltene Berechtigungszertifikat umfasst (Schritt 304).
Bei sämtlichen Transaktionen wird vom Überprüfungsmodul 105 des Servers 101 nebst den Signaturen der signierenden Nutzer, unter Rückgriff auf den gespeicherten Fingerprint des Herausgeberzertifikats, auch geprüft, ob diese eine Berechtigung für die betroffene juristische Person haben (Schritt 305). Nach erfolgreicher Prüfung werden Daten über die Transaktionen bzw. die davon betroffenen Wechsel vom Aufzeichnungsmodul 106 ebenfalls in der Blockchain 150 gespeichert (Schritt 306).
Unterschriften der Nutzer werden durch eine Signaturstruktur mit folgenden Elementen repräsentiert:
1. Die Signatur des Nutzers, der den Wechsel unterzeichnet. Diese besteht aus einem vom Nutzer signierten Hash folgender Elemente: dem Hash des Wechsels, der Bezeichnung der juristischen Person des Nutzers und einem Hash von allenfalls vorhandenen Bedingungen (Rabatte oder weitere Angaben, die im Wechsel nicht sichtbar sein, während der Unterzeichnung aber dennoch überprüfbar sein sollen); 2. einer Signatur eines Administrators der juristischen Person. Diese besteht aus einem vom Administrator signierten Hash folgender Elemente: der eindeutigen laufenden Nummer des Nutzers und der Bezeichnung der juristischen Person des Administrators und des Nutzers;
3. den Namen der juristischen Person.
Ein Wechsel (Promissory Note PN) wird im Rahmen des beschriebenen Systems durch eine Struktur mit folgenden Elementen repräsentiert:
1. Eine Hauptstruktur, die während der Lebensdauer des Wechsels unverändert bleibt, umfassend folgende Elemente:
- die Angabe des Nominalwerts;
- die Angabe der Währung;
- die Angabe des Fälligkeitsdatums;
- die Angabe möglicher Transferempfänger (juristische Personen) (optional);
- eine Nonce (zur Verhinderung von Replay-Attacken);
- eine Angabe der juristischen Person des Ausstellers;
- eine Angabe der juristischen Person des Garantiegebers (optional);
- fixe Metadaten;
2. einer Kennung;
3. einem Ausgabedatum;
4. einer Signaturenstruktur (siehe unten) mit den derzeitigen Signaturen;
5. Angaben zur Geschichte der PN (aktualisiert, wenn die PN erledigt, gelöscht oder übertragen wird);
6. eine Statusangabe (offen, fällig, erledigt, gelöscht, evtl, weitere);
7. die Angabe der juristischen Person des Inhabers und
8. veränderliche Metadaten, umfassend einfach und mehrfach veränderliche Daten. Die Signaturenstruktur des Wechsels umfasst mehrere Signaturstrukturen und weitere
Elemente wie folgt:
Figure imgf000016_0001
Zur Ausstellung eines neuen Wechsels einigen sich der Aussteller und der (initiale) Inhaber auf den Hash der Angaben gemäss der Hauptstruktur (Punkt 1 oben) und die juristische Person des Inhabers. Dazu kommt allenfalls ein Hash von Daten, die zwischen den Parteien vereinbarte Bedingungen betreffen. Diese zwei bzw. drei Datenportionen werden sodann von Nutzern signiert, die für die beiden Parteien zur Unterzeichnung berechtigt sind.
Bei einer kombinierten Ausstellung und Übertragung muss der Aussteller dieselben Daten wie bei der Ausstellung signieren. Beim ursprünglichen und neuen Inhaber kommen zu den zu signierenden Daten jeweils noch die juristische Person des neuen Inhabers dazu und allenfalls Bedingungen für die Übertragung. Im Rahmen der Abwicklung des Transfers wird anhand der Promissory- Note-Struktur geprüft, ob die Übertragung des Wechsels eingeschränkt ist und falls ja, ob die vorgesehene Übertragung im Rahmen der Einschränkungen zulässig ist. Ein Wechsel kann - insbesondere nach Leistung des vereinbarten Betrags durch den Aussteller - durch Antrag des (aktuellen) Inhabers erledigt werden. Dazu signiert der Inhaber eine Datenportion mit der Identifikationsnummer des Wechsels, dem Vermerk, dass der Wechsel erledigt ist und der juristischen Person des Inhabers. Es bedarf zur Erledigung keiner weiteren Unterschriften.
Im Rahmen des beschriebenen Systems ist eine Unterschrift gültig, wenn das entsprechende Zertifikat gültig ist, die Berechtigung der Unterzeichnenden nicht zurückgezogen wurde (siehe unten) und der unterzeichnende Nutzer über eine gültige Zugriffsberechtigung mit der handelnden, juristischen Person verknüpft ist. Ergänzend können hinterlegte Zeichnungsberechtigungen (z. B. betreffend kollektiver Zeichnungsberechtigung) geprüft werden. Entsprechend wird die Gültigkeit von Unterschriften im Rahmen des beschriebenen Systems gemäss folgenden Schritten geprüft, jeweils angewandt auf jede Unterschrift einer PN:
1. Die entsprechenden Zertifikatsdaten werden erhalten, sowohl für den unterzeichnenden Nutzer als auch für den zugeordneten Administrator.
2. Die Liste der erfassten Administratoren der der Signatur zugeordneten juristischen Person wird abgerufen.
3. Es wird geprüft, ob das Zertifikat des Nutzers von einem registrierten Herausgeber (Zertifizierungsstelle) stammt. Dazu wird anhand des Herausgeberzertifikats, das mit dem Identitätszertifikat des Nutzers verkettet ist, ein Fingerprint generiert. Dieser wird dann mit den Fingerprints verglichen, die in der Blockchain hinterlegt sind.
4. Es wird geprüft, ob der Nutzer nicht in einer Liste mit zurückgezogenen Zugriffsberechtigungen aufgeführt ist. Solche Listen sind in der Blockchain abgelegt und werden für jede juristische Person separat geführt, weil ein spezifischer Nutzer (natürliche Person) Zugriffsberechtigungen für mehrere juristische Personen haben kann und weil diese unabhängig voneinander verwaltet werden sollen. 5. Es wird geprüft, ob das Zertifikat des Nutzers eine Zugriffsberechtigung eines der erfassten Administratoren der juristischen Person umfasst und ob diese Zugriffsberechtigung gültig vom entsprechenden Administrator signiert wurde.
Weitere Prüfungen sind möglich, z. B. ob alle Unterschriften, die mit einer Partei einer Transaktion verknüpft sind, derselben juristischen Person zugeordnet sind, ob die Anzahl der Unterschriften ausreichend ist usw.
Die in der Blockchain gespeicherten Promissory Notes sind mit einem symmetrischen Schlüssel verschlüsselt, beispielsweise mittels AES-Verschlüsselung. Der Schlüssel (und gegebenenfalls auch ein Initialisierungsvektor) wird off-chain erzeugt und abgelegt. Er wird für den Zugriff auf die Promissory Note benötigt; wird er gelöscht, kann auf die Information der entsprechenden Promissory Note weder lesend noch schreibend mehr zugegriffen werden. Entsprechend verliert die Promissory Note jegliche Wirkung, und es ist trotz Speicherung der entsprechenden Daten in der Blockchain auch nicht mehr ersichtlich, was ihr Inhalt gewesen war.
Die Erfindung ist nicht auf das dargestellte Ausführungsbeispiel beschränkt. So können spezifische Aspekte des beschriebenen Systems und des beschriebenen Verfahrens anders ausgeführt sein. Die Erfindung lässt sich zudem nicht nur bei der Abwicklung von Transaktionen im Zusammenhang mit Wechseln oder anderen Finanzinstrumenten, sondern auch für andere Transaktionen verwenden.
Zusammenfassend ist festzustellen, dass die Erfindung einen Server, ein System und ein Verfahren schafft, die eine effiziente Abwicklung von Transaktionen bei sicherer Identifikation der Transaktionspartner ermöglichen.

Claims

Patentansprüche
1. Server zur Abwicklung von Transaktionen, wobei der Server zur Verbindung mit einem Computernetzwerk ausgebildet ist, das einen Distributed Ledger speichert, welcher eine Mehrzahl von Datenblöcken umfasst, die zwischen mehreren Rechnern des Computernetzwerks repliziert, geteilt und synchronisiert sind, und wobei der Server folgendes umfasst: a) ein Verknüpfungsmodul, das eingerichtet ist zum Empfangen eines öffentlichen Schlüssels einer Zertifizierungsstelle und zum Generieren und Speichern von Fingerprintdaten, die den öffentlichen Schlüssel repräsentieren, in einem der Datenblöcke des Distributed Ledger; b) ein Berechtigungsmodul, das eingerichtet ist zum Speichern von Zugriffsberechtigungen, die mit von der Zertifizierungsstelle ausgegebenen Identitätszertifikaten verknüpft sind, in einem der Datenblöcke des Distributed Ledger; c) ein Eingangsmodul, das eingerichtet ist zum Empfangen einer Transaktionsanforderung von einer anfordernden Stelle, wobei die Anforderung mit dem privaten Schlüssel der anfordernden Stelle signiert ist, der mit einem öffentlichen Schlüssel eines von der Zertifizierungsstelle ausgegebenen Identitätszertifikats der anfordernden Stelle verknüpft ist; d) ein Überprüfungsmodul, das eingerichtet ist zum Überprüfen einer Identität der anfordernden Stelle, gestützt auf die Anforderung der anfordernden Stelle, den gespeicherten Fingerprintdaten und den gespeicherten Zugriffsberechtigungen; e) ein Aufzeichnungsmodul, das eingerichtet ist zum Aufzeichnen einer Transaktion, die der Transaktionsanforderung entspricht, in einem Datenblock des Distributed Ledger, sofern die Identität erfolgreich durch das Überprüfungsmodul verifiziert wurde.
2. Server zur Abwicklung von Transaktionen nach Anspruch 1, dadurch gekennzeichnet, dass das Berechtigungsmodul eingerichtet ist zum Speichern von Zuordnungen zu Identitätszertifikaten von Administratoren, dass das Eingangsmodul eingerichtet ist zum Empfangen von Transaktionsanforderungen, die ein Zugriffszertifikat mit einer Signatur eines Administrators umfassen, und dass das Überprüfungsmodul eingerichtet ist zur Prüfung, ob die Signatur des Administrators mit einem der Identitätszertifikate der gespeicherten Zugriffsberechtigungen verknüpft ist. Server zur Abwicklung von Transaktionen nach Anspruch 2, dadurch gekennzeichnet, dass das Zugriffszertifikat eine eindeutige Kennung der anfordernden Stelle und eine Zuordnung zu einer Entität umfasst. Computergestütztes System für die Abwicklung von Transaktionen, umfassend: a) eine Zertifizierungsstelle zur Ausgabe von Identitätszertifikaten, wobei die Identitätszertifikate einen öffentlichen Schlüssel und eine Identität umfassen und von der Zertifizierungsstelle signiert sind; b) ein Computernetzwerk, das einen Distributed Ledger speichert, welcher eine Mehrzahl von Datenblöcken umfasst, die zwischen mehreren Rechnern des Computernetzwerks repliziert, geteilt und synchronisiert sind; c) einen Server zur Abwicklung von Transaktionen nach einem der Ansprüche 1 bis 3. Verfahren zur Abwicklung von Transaktionen, umfassend die folgenden Schritte: a) Speichern von Fingerprintdaten, die den öffentlichen Schlüssel einer Zertifizierungsstelle repräsentieren, in einem einer Mehrzahl von Datenblöcken eines Distributed Ledger, wobei die Mehrzahl von Datenblöcken zwischen mehreren Rechnern eines Computernetzwerks repliziert, geteilt und synchronisiert sind; b) Speichern von Zugriffsberechtigungen, die mit von der Zertifizierungsstelle ausgegebenen Identitätszertifikaten verknüpft sind, in einem der Mehrzahl von Datenblöcken des Distributed Ledger; c) Empfangen einer Transaktionsanforderung einer anfordernden Stelle, wobei die Anforderung mit dem privaten Schlüssel der anfordernden Stelle signiert ist, der 19 mit einem öffentlichen Schlüssel eines von der Zertifizierungsstelle ausgegebenen Identitätszertifikats der anfordernden Stelle verknüpft ist; d) Überprüfung einer Identität der anfordernden Stelle, gestützt auf die Anfrage der anfordernden Stelle, den gespeicherten Fingerprintdaten und den gespeicherten Zugriffsberechtigungen; e) Aufzeichnen einer Transaktion, die der Transaktionsanforderung entspricht, in einem Datenblock des Distributed Ledger, sofern die Identität erfolgreich durch das Überprüfungsmodul verifiziert wurde. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass den Zugriffsberechtigungen Identitätszertifikate von Administratoren zugeordnet sind, die Transaktionsanforderung der anfordernden Stelle ein Zugriffszertifikat mit einer Signatur eines Administrators umfasst, und dass eine erfolgreiche Überprüfung der Identität voraussetzt, dass die Signatur des Administrators mit einem der Identitätszertifikate der gespeicherten Zugriffsberechtigungen verknüpft ist. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das Zugriffszertifikat eine eindeutige Kennung der anfordernden Stelle und eine Zuordnung zu einer Entität umfasst. Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass die Überprüfung der Identität der anfordernden Stelle eine Überprüfung umfasst, ob die anfordernde Stelle nicht in einer Widerrufsliste aufgeführt ist, die in einem Datenblock des Distributed Ledgers gespeichert ist. Verfahren nach einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, dass die Transaktion vor der Aufzeichnung unter Verwendung einer symmetrischen Verschlüsselung verschlüsselt wird und dass Transaktionen durch Löschen eines Ver- /Entschlüsselungsschlüssels verworfen werden können. 20 . Verfahren nach einem der Ansprüche 5 bis 9, dadurch gekennzeichnet, dass die Transaktionsanforderung von zusätzlichen Parteien unterzeichnet ist, die an der aufzuzeichnenden Transaktion beteiligt sind, und dass die Identität der zusätzlichen Parteien auf der Grundlage der jeweiligen gespeicherten Fingerprintdaten und gespeicherten Zugriffsberechtigungen überprüft wird. 1. Verfahren nach einem der Ansprüche 5 bis 10, dadurch gekennzeichnet, dass das Speichern der Zugriffsberechtigungen in einem Datenblock von einer Identitätsprüfung abhängig ist, die unabhängig ist vom Identitätszertifikat. . Verfahren nach einem der Ansprüche 5 bis 1 1, dadurch gekennzeichnet, dass die Transaktionsanfrage die Ausgabe, die Übertragung oder die Verrechnung von
Finanzinstrumenten, insbesondere von Wechseln, betrifft.
PCT/EP2021/076110 2020-09-24 2021-09-22 Server zur abwicklung von transaktionen WO2022063851A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CH01213/20A CH717898A1 (de) 2020-09-24 2020-09-24 Server zur Abwicklung von Finanz-Transaktionen.
CHCH01213/20 2020-09-24

Publications (1)

Publication Number Publication Date
WO2022063851A1 true WO2022063851A1 (de) 2022-03-31

Family

ID=75339377

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/076110 WO2022063851A1 (de) 2020-09-24 2021-09-22 Server zur abwicklung von transaktionen

Country Status (2)

Country Link
CH (1) CH717898A1 (de)
WO (1) WO2022063851A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170180128A1 (en) * 2015-12-22 2017-06-22 Gemalto Inc. Method for managing a trusted identity
US20180048461A1 (en) * 2016-08-10 2018-02-15 Peer Ledger Inc. Apparatus, system, and methods for a blockchain identity translator
US20190347656A1 (en) * 2018-05-10 2019-11-14 Alibaba Group Holding Limited Blockchain member management data processing methods, apparatuses, servers, and systems
WO2020002009A1 (en) * 2018-06-28 2020-01-02 International Business Machines Corporation Delegating credentials with a blockchain member service
US10547457B1 (en) * 2016-10-21 2020-01-28 Wells Fargo Bank N.A. Systems and methods for notary agent for public key infrastructure names

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170180128A1 (en) * 2015-12-22 2017-06-22 Gemalto Inc. Method for managing a trusted identity
US20180048461A1 (en) * 2016-08-10 2018-02-15 Peer Ledger Inc. Apparatus, system, and methods for a blockchain identity translator
US10547457B1 (en) * 2016-10-21 2020-01-28 Wells Fargo Bank N.A. Systems and methods for notary agent for public key infrastructure names
US20190347656A1 (en) * 2018-05-10 2019-11-14 Alibaba Group Holding Limited Blockchain member management data processing methods, apparatuses, servers, and systems
WO2020002009A1 (en) * 2018-06-28 2020-01-02 International Business Machines Corporation Delegating credentials with a blockchain member service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MONEYCAB: "FQX verwendet DCHF-Stable-Coin der Sygnum Bank für sofortige Bezahlung elektronischer Wechsel | Moneycab", 17 September 2020 (2020-09-17), pages 1 - 3, XP055819821, Retrieved from the Internet <URL:https://www.moneycab.com/it/fqx-verwendet-dchf-stable-coin-der-sygnum-bank-fuer-sofortige-bezahlung-elektronischer-wechsel/> [retrieved on 20210630] *

Also Published As

Publication number Publication date
CH717898A1 (de) 2022-03-31

Similar Documents

Publication Publication Date Title
EP3596653B1 (de) Ausstellen virtueller dokumente in einer blockchain
DE60034159T2 (de) Verfahren zur elektronischen speicherung und wiedergewinnung von authentifizierten originaldokumenten
DE102008040416A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP3993318B1 (de) Blockchain-basiertes digitales dokumentensystem
DE102008042262A1 (de) Verfahren zur Speicherung von Daten, Computerprogrammprodukt, ID-Token und Computersystem
DE102009034436A1 (de) Verfahren und System zum Bezahlen mit geldwerten Beträgen in Form elektronischer Datensätze
EP3814970B1 (de) Manipulationssicheres ausstellen und speichern von elektronischen urkunden
EP3295354A1 (de) Verfahren und vorrichtung zur authentifizierung eines dienstnutzers für eine zu erbringende dienstleistung
DE102021122557A1 (de) Konformitätsmechanismen in blockchain-netzwerken
EP2136528A1 (de) Verfahren und System zum Erzeugen einer abgeleiteten elektronischen Identität aus einer elektronischen Hauptidentität
DE60122349T2 (de) Verahren zur erzeugung von nachweisen über das senden und empfangen eines elektronischen schreibens und seines inhaltes über ein netzwerk
EP3422274A1 (de) Verfahren zur konfiguration oder änderung einer konfiguration eines bezahlterminals und/oder zur zuordnung eines bezahlterminals zu einem betreiber
EP3767513B1 (de) Verfahren zur sicheren durchführung einer fernsignatur sowie sicherheitssystem
EP4224786A1 (de) Verfahren und vorrichtung zur erstellung elektronischer signaturen
DE102019217738A1 (de) Computerimplementiertes Verfahren zur Steuerung und Kontrolle der Verteilung von verifizierten personenbezogenen Nutzer-Daten eines Nutzers auf einer Vielzahl von Anbieter-Servern
EP1701282A1 (de) Computersystem und Verfahren zur Signierung, Signaturverifizierung und/oder Archivierung
WO2023036458A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP3125464B1 (de) Sperrdienst für ein durch einen id-token erzeugtes zertifikat
WO2022063851A1 (de) Server zur abwicklung von transaktionen
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
EP1921556A1 (de) Signaturerweiterung
EP1054364A2 (de) Verfahren zur Erhöhung der Sicherheit bei digitalen Unterschriften
EP3180729B1 (de) Digitale identitäten mit fremdattributen
DE10061102B4 (de) System zur Statusabfrage von digitalen Zertifikaten
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21783178

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21783178

Country of ref document: EP

Kind code of ref document: A1