Patent Application
20240296441
The invention relates to a secure service provider unit in an electronic transaction system in particular an electronic payment transaction system. The invention also relates to a secure wallet. The invention also relates to an electronic transaction system in particular an electronic payment transaction system. The invention further relates to a method for issuing one or more secure wallets, issued by a secure service provider unit of an electronic transaction system.
Tokens—also referred to as digital assets, electronic coins, coin data sets—may represent any digital asset, in particular a digital currency, preferably a central bank digital currency, short CBDC. These tokens are issued and deleted by a unit of the transaction system, such as an issuing authority, a central bank unit or a commercial bank unit, hereinafter also referred to as secure token issuing unit.
Electronic token transactions and/or storage of tokens and any associated transaction data and/or storage data must be safe and secure and so, means for protecting confidentiality, integrity, and availability of exchanged and/or stored token data must be implemented. This is in particular true for electronic payment transactions and associated payment transactions and payment storages in which a monetary value is linked with each token.
There are different technical approaches for a digital asset e.g. digital currency such as CBDC, issued by a central bank.
According to a first approach, tokens are merely cryptographically secured by the central bank unit and the cryptographically secured tokens are exchanged directly between token management units—also referred to as wallets—of the participants in an encrypted manner. The exchanged token may also be stored in an encrypted manner. The token management units can verify the authenticity of the tokens based on the cryptographic security, such as keys and signatures, and for example checks a certificate from the central bank and/or the other token management units for validity within the certificate hierarchy in advance via online access or following the offline-protocol of the system.
According to a second approach, tokens are stored in a centralized or decentralized blockchain/distributed ledger of the transaction system, e.g., organized by a central bank unit. For a transaction, an ownership of a token record changes in the blockchain for which a lot of information (sender/recipient/amount) is required and/or even published. Sender and recipient of the token need an online access to the blockchain at the time of the transaction.
According to a favorable third approach as for instance described in WO 2020/212 331 A1 tokens are stored in a local token management unit (also called wallet or payment application unit or secure element) to be directly exchanged between participants of an electronic payment transaction system. The transferred token can validly be used after receipt from another participant without a need of approval or verification via an online connection. So, if an online connection is not available or inconvenient or should not be used for a specific token transaction, it remains possible to validly transfer tokens directly between participants in the electronic payment transaction system. For security-, verification- and registration-purposes, a token register stores token references of all valid tokens without knowing the tokens itself. So, the user can check validity of a received token. The token register only stores token references of the corresponding token. Tokens can be further modified by each individual participant, e.g., ownership of tokens can be switched from one participant to another participant (SWITCH modification), tokens can be split into plural tokens, e.g., for obtaining a token with a reduced monetary value (SPLIT modification) and/or plural tokens can be merged to a single token, e.g., for obtaining a token with a higher monetary value (MERGE modification).
For managing the tokens, such as performing the transactions and storing the tokens, secure token management units, also known as wallets, are used. For the second approach these wallets can be referred to as account wallets. For the third approach, these wallets are typically referred to as token-wallets.
A wallet can be provided as a hardware wallet, e.g. as a smart card issued to a participant, or can be a so-called hosted-wallet, e.g. a wallet that is hosted by the individual service provider.
For security it is necessary to provide an onboarding process that allows to relate to real participants in the electronic payment system. However at the same time it is required to assure a high degree of anonymity and/or privacy.
It is known that financial service providers follow a known “know-your-customer” KYC-concept to assign a verified identity of each customer with an internal customer name or an internal customer ID by using internal databases. The financial service provider issues hosted wallets or hardware wallets that are assigned only with these internal customer names/IDs. In this KYC-concept, a fraud can only be identified if transaction data are evaluated. For that, the transaction data need to include the internal customer names/IDs. In case of a suspicious transaction, an official authority needs to request access to the internal database to resolve which “real” person is assigned to an internal customer name/ID. Each financial service provider in an electronic payment system following the CBDC approach must run such a KYC concept to resolve such fraud attempts. This is considered highly inefficient.
It is further known from WO 2022/048 826 A1 that a known ID is encrypted for a central bank instance and this encrypted ID is transferred in an additional data field in each transaction. This highly increases the required data needed to perform the transaction and is thus considered inefficient, too.
So, there is a need for more efficiently identifying real participants in an electronic payment transaction system if secure token management units, such as hardware wallets or hosted wallets, are used. So, additional data fields in each transaction data or decentralized plural KYC-concepts should be avoided. Furthermore, KYC requirements need to be fulfilled in an efficient way even if the to be onboarded real person is not previously known to a secure token management unit (=wallet) issuing unit, e.g. efficient onboarding of unbanked people.
In an aspect of the present invention there is provided a secure service provider unit in an electronic transaction system, in particular an electronic payment transaction system, the secure service provider unit comprising a secure wallet issuing unit comprising control means configured to issue one or more secure wallets for users in the electronic transaction system. Each secure wallet comprises wallet identification data. The wallet identification is provided by the secure wallet issuing unit. The wallet identification data is assigned to a secure wallet for uniquely identifying the secure wallet in the electronic transaction system. The control means of the secure wallet issuing unit is further configured to derive at least a part of the wallet identification data based on at least external digital identification data.
A secure wallet may be a secure token-wallet that is also referred to as secure token management unit to preferably follow the above-mentioned third approach of transaction systems. Such a secure token-wallet is used to locally manage the token, e.g. in a secure element itself or in a wallet hosting server such as the secure service provider unit. The secure token-wallet may modify the tokens (e.g. split, merge or switch tokens-see above) and to register the token in the electronic transaction system. The token may be stored in a token storage that is also managed by the token-wallet.
Alternatively, or additionally, a secure wallet may be a secure account-wallet that is also referred to as secure account management unit in particular to follow the above-mentioned second approach of transaction systems. Such a secure account-wallet is used to not manage tokens in a secure element itself but in a decentralized ledger, such as a blockchain or a centralized ledger, such as a database that stores the token centrally in the electronic transaction system. Managing, modifying, and/or registering of the tokens in the electronic transaction system is initiated by the secure account-wallet, however, token transaction or token storage is performed remote of the secure element or the service provider unit.
Accordingly, the secure wallet issuing unit may be configured to provide at least the derived part of the wallet identification data or the derived wallet identification data. In particular, the wallet identification data may comprise data fields, wherein one of the data fields is used for inserting the derived part of the wallet identification data.
It could be added that, after issuance, the wallet identification data will be stored in the issued secure wallet and/or used in transactions with other wallets of the transaction system.
The external digital identification data is assigned to a respective user to whom the secure wallet is to be issued in the electronic transaction system. This user can be a natural person, a legal person or an organization. The external digital identification data may be assigned to the user in an external, preferably national or government, digital identity system for uniquely identifying the user. The term “external” in this context means external to the transaction system. Hence, transaction system internal data, such as e.g. a transaction account number or a customer number, are no external data. Finally, for secure wallets of devices/machines preferably the user also is a natural person, a legal person or an organization, but could be the device/machine (at least in future digital identity systems).
The respective user to whom the secure wallet is to be assigned may hereinafter be referred to as “real” participant.
The wallet identification data includes the external digital identification data—and optionally a type-value and/or a count-value (see below)—in a form hidden by the derivation. In addition or alternatively the external digital identification data—and optionally the type-value and/or the count-value—can only be inverse-derived from the wallet identification data based on secret inverse-derivation data. In other words, at least the part of the wallet identification data is derived such that inverse-derivation requires secret inverse derivation data. The secret inverse derivation data typically is cryptographic secret data, such as a key (e.g. of a symmetric or asymmetric cryptographic scheme). The secret inverse derivation data may be static or individual for each secure service provider unit, user or derivation session (e.g. by adding respective individual data to a base secret). Only the owner of secret inverse derivation data, typically a single central unit of the transaction system, would be able to inverse-derive the external digital identification data from the wallet identification data.
For security reasons and for not jeopardizing the privacy and/or anonymity in the electronic payment system, the reversal (resolving) of the “real” participant should not be generally possible (for the public/participants if the transaction system). In particular it would take place, if a legal title obliges the cooperation of the involved organizations in order to infer back to the person. The wallet identification data is part of the transaction data exchanged in the transaction system and/or the transaction protocol data protocolled in the transaction system. The transactions and/or the transaction protocol data are user-anonymous, but allow the inverse derivation unit of the transaction system, such as a fraud management unit or a system management unit, to find out the user (real participant).
A service provider unit may be a financial service provider unit, such as a commercial bank or Fintech company. Alternatively, or additionally, a service provider unit may be an official authority. Alternatively, or additionally, a service provider unit may be a mobile communication service provider. Alternatively, or additionally, a service provider unit may be any other regulated or non-regulated party that participates in the electronic transaction system, e.g. a payment transaction system that involves CBDC, as authorized by the token issuing authority.
The external digital identification data may be assigned to the user in an external digital identity system for uniquely identifying the user. The external digital identity system preferably is a national/government/official authority digital identity system. The external digital identification data may be at least one of the following: a tax number for identifying the user in a tax office; an identity card number for identifying an identity card of the user; a passport number for identifying a passport of the user; a driver's license number for identifying a driver's license of the user; an international mobile subscriber identity for identifying the user in a mobile network. Other uniquely assigned identification data of external digital identity systems could be selected.
The digital identification data preferably is a national or international digital identity that a citizen may be assigned to in a registration process at an official authority, such as a residents' registration office or a tax office or a vehicle registration authority, and so on. So, the digital identification data can be a national or international electronic identification number of a real person issued by an authority and not just a number that is assigned or linked with a user ID.
With the digital identification data, a transaction and/or storing within the transaction system can now—under certain preconditions—be directed to the “real” participant without increasing the overall transaction data amount and without compromising the privacy level of the transaction system to the user.
Providing the wallet identification data may comprise the derivation (generating) of the wallet identification data at the wallet issuing unit. In this case, the provisioning may be the coding of the identification data by control means of the wallet issuing unit. In such a case, the service provider unit (or its respective secure token management unit issuing unit control means) codes the wallet identification data. This coding is performed to assign the wallet identification data with the secure wallet that is to be issued. Each token transaction made by this wallet and/or each token being managed, such as stored, by this wallet can be locally or centrally protocolled. In case of a suspicious transaction or fraudulent pattern is identified, the protocols may be reviewed.
Alternatively, providing the wallet identification data may comprise the receipt of the wallet identification data from a derivation unit, preferably a central derivation unit, such as one or more of an official authority; a secure token issuing unit, e.g. a central bank unit; and/or an electronic identity system.
So, the service provider unit may issue secure elements, such as smartcards or other hardware token that may comprise identification data for identifying the user. These identification data may be known to a secure element manufacturer during a request for personalization. This secure element manufacturer may receive these identification data as personal data during a personalization procedure and may provide these identification data to the service provider unit, especially the wallet issuing unit.
In a preferred embodiment, the wallet identification data is a mandatory data to be transmitted between individual participants in the electronic transaction system, preferably for direct exchange of tokens, in particular digital currency tokens. This may be a system requirement to ensure high standard security. The wallet identification data is not only used to uniquely identify the electronic participant, but it is now selectively also possible to identify the “real” participant by resolving the identification data. Only one data for identifying both “real” and electronic participant is required which may reduce the overall data transfer rates for token transactions.
In a further embodiment, the wallet identification data comprises a plurality of data fields. One of the plurality of data fields is used for inserting the derived part of the wallet identification data.
One or more other data fields of the plurality of data fields may include a version value that expresses the current version of the wallet identification data format that is used.
One or more other data fields of the plurality of data fields may include a central token issuing unit identifier that expresses the central token issuing unit of the electronic transaction system. With such a data field it is possible to enable multi-currency token transactions. A first identifier may be used to identify a first central token issuing unit (=central bank herein) that issues token of a first currency, whereas a second identifier may be used to identify a second central token issuing unit that issues token of a second currency.
One or more other data fields of the plurality of data fields may include an identifier of the service provider unit and/or a smart card producer and/or card manufacturer and/or card issuer to identify the service provider unit and/or the smart card producer and/or card manufacturer and/or card issuer or other stakeholder in the transaction system.
Preferably, the wallet identification data further comprises a data element for a type-value configured to identify the type of the digital identification data, preferably the digital identity system of the digital identification data.
Preferably, the wallet identification data further comprises a data element for a count-value configured to identify a number secure wallets of issued. The count value may represent the number of secure wallets issued for the external digital identification data and/or for the user. In particular, the number may represent the number of secure wallets issued for the external digital identification data and/or the user in the transaction system (or in a less preferred option, in the secure service provider unit). The count value may also represent the number of secure wallets issued (for any users) in the secure service provider unit.
The derived part of the wallet identification data may comprise the type-value and/or the count-value. So, type value and/or count value can be provided in the wallet identification data either in clear text or in a hidden form/as a derived part.
Preferably, the wallet identification data is inserted into a subject name data field of a cryptographical certificate used within a transaction or storage of tokens within the electronic transaction system. Since, certificates may be used to clearly identify the participant in a token transaction/storage, no additional data set is required to derive the “real” participant in case of suspicious transaction and or suspiciously stored token.
Each combination as named herein may be referred to as a concatenation, which is a logical combination used in information technology.
More preferably, the certificate further comprises a serial number data field for inserting a serial number, wherein the serial number is unique in the electronic transaction system. Thus at least the combination of the subject name and serial number is also unique for the certificate in the electronic transaction system.
The secure service provider unit further comprises a secure wallet comprising control means for managing one or more token of the electronic transaction system using the wallet identification data to protocol a direct exchange of one or more token with one or more other secure wallets in the electronic transaction system, wherein the control means is configured to cause the direct exchange of the one or more token with the one or more other wallets in the electronic transaction system, and to send registration requests including token references to a token register of the electronic transaction system.
The secure service provider unit may comprise a token storage accessible by the control means of the secure service provider unit, preferably the control means of the secure wallet.
The secure service provider unit may be further configured to manage one or more secure wallets of users of the electronic transaction system, wherein preferably, the secure service provider unit comprises the one or more secure wallets (hosted wallets).
The secure service provider unit may optionally comprise a token storage as a physical entity. The secure wallet of the secure service provider unit may be configured to access the token storage. The token storage may be a token vault of this secure service provider unit. Each secure service provider unit in the transaction system may comprise its own token storage.
From the secure wallet the token can be transferred to any other secure wallet, e.g., owned by a customer of the service provider unit.
The secure service provider unit may further be configured to manage one or more secure wallets of users (e.g., customers of the service provider unit, such as service receiving units or participants in the payment system) of the electronic transaction system. Preferably, the secure service provider unit comprises (hosts) the one or more secure wallets as entities in the secure service provider unit, which hereinafter is referred to as hosted wallets.
As addressed before, the wallets may be token-wallets or account-wallets.
The secure wallet issuing unit may be further configured to generate one or more secure sub-wallets from the issued secure wallet for that user in the electronic transaction system. The wallet identification data of the one or more generated secure sub-wallets may be generated from the wallet identification data of the issued secure wallet for that user for uniquely identifying the one or more secure sub-wallet in the electronic transaction system. Preferably the generation for the sub-wallet comprises adding a sub-wallet indicator and/or increasing or adding a count value in the wallet identification data of the issued secure wallet.
So, one can now register a secure root wallet with the identification data of the user. Subsequently, secure sub-wallets can be generated by the secure wallet issuing unit based on the already known identification data of the user which relate to the secure root wallet. So, complex onboarding processes for further secure wallets of that person in that secure service provider unit can be avoided, once a secure root wallet is issued. In such scenarios, secure sub-wallets can be passed on to kids or as a present. These sub-wallets are still traceable back to the issuing authority (central bank, etc.) and the “real” person deriving the wallets.
According to another aspect, an electronic transaction system, in particular an electronic payment transaction system, comprises a plurality of secure wallets of users-preferably as described above or below; and one or more service provider units as described above. The system preferably further comprises a secure token issuing unit and/or a token register. The toke issuing unit comprises a minting unit configured to generate a new token to be issued in the electronic transaction system and a melting unit configured to delete tokens to be deleted from the electronic transaction system. The token register for registering the tokens, preferably token references of the tokens, of the electronic payment transaction system.
The secure wallet may be a hardware security module built in hardware or software to enable tamperproof and secure access to the tokens.
Preferably, the secure token issuing unit may comprise a dedicated identification data server. This dedicated identification data server may be used to derive identification data used for the secure wallets and/or the derived secure sub-wallets.
In an embodiment, the dedicated identification data server is configured to determine whether the user comprises (is assigned to) more than one secure wallet identification data. In an electronic transaction system requirement, it may be that a user is not allowed to own more than one secure wallet identification data. In case, it is determined, that the user is assigned to more than one secure wallet identification data, the dedicated identification data server generates a warning to the system so that the secure wallets that are assigned to the users may be blocked.
According to an aspect of the invention a secure wallet in an electronic transaction system is provided. The secure wallet comprising wallet identification data being assigned to the secure wallet for uniquely identifying the wallet in the electronic transaction system. At least a part of the wallet identification data is derived based on external digital identification data.
The secure wallet may be a token-wallet or an account-wallet as describe above.
The secure wallet may be implemented in a secure element, e.g. as a hardware-wallet. Alternatively, the secure wallet may be implemented as a hosted-wallet.
The secure wallet may have wallet identification data according to the above-described manner.
In another aspect there is provided a method for issuing one or more secure wallets for users in an electronic transaction system, preferably an electronic transaction system as described above, the one or more secure wallets being issued by a secure service provider unit of the electronic transaction system. The method comprising the steps of:
The method preferably further comprises, prior to the receiving step:
A protocolling of transactions may be caused by the secure wallet by inserting the wallet identification data in the transaction, preferably a direct exchange of the one or more tokens; and/or by adding the wallet identification to protocol data (locally or centrally stored for each transaction).
In a further aspect, a non-transitory computer readable storage medium for tangibly storing computer program instructions capable of being executed by a processor is described. The computer program instructions defining the steps the method as described above.
Each token comprises a monetary value as a first token element. The monetary value may be a data that represents money usable in one or more electronic payment transaction.
Each token may further comprise a private value as a second token element. The private value may be a random number or may be a secret that is not known to participants not involved in a transaction. The private value may be a private element of a token element pair. A corresponding public element of such a token element pair may be used as an element in a token reference that is stored in a token register to register first-type tokens and second-type tokens.
In addition, each token may have further token elements as outlined below and may also have further token elements such as further metadata, e.g., currency data that indicates the currency which the monetary amount represents and/or validity data and/or timestamp data.
The token may also be referred to as a value note within this disclosure. The token can be used in online and offline payment transactions. The token may represent central bank digital currency, CBDC.
The token may comprise one or more token-individual history entries as a further token element. One history entry may represent one modification, such as SWITCH, SPLIT, MERGE, performed with this token. Such a further token element may also be referred to as history data.
It is possible to exchange a token in offline electronic payment transactions between two locally communicating wallets/secure token managing units (e.g. wallets, preferably secure elements having established a secured communication channels) within the electronic payment transaction system.
An online electronic payment transaction payment is defined herein as a transaction in which a secure wallet (e.g. in a secure element) that participates in the transaction, e.g. the secure wallet that initiates the token transfer (payer) or the secure wallet that receives a token (payee), has access and can communicate with one or more remote instances of the electronic payment system, such as a token register, a transaction register, a token issuing unit, a service provider unit such as financial service provider (FSP) via classical internet or mobile communication means or any other suitable online communication protocol. So, immediately before, while or after performing the transaction, also a registration of the transaction by storing a respective token reference in a remote token register may be performed by one of the secure wallets involved in the transaction.
An offline electronic payment transaction payment is defined herein as a direct transaction between two secure wallets (e.g. residing in secure elements) that participate in the transaction, e.g. the secure wallet that initiates the token transfer (payer) and/or the secure wallet that receives a token (payee). At least one of payer or payee has no access and cannot communicate with remote instances of the transaction system, such as a token register, a transaction register, a token issuing unit and/or a service provider unit, such as financial service provider (FSP) via classical internet or mobile communication means. The token transfer may then take place by local wireless communication means, such as Bluetooth, NFC, or any other suitable wireless communication protocol. The token transfer may also take place by contact-based communication means, such as USB, ISO 7816, or any other suitable contact-based communication protocol.
For a registration of a token in the token register, a token reference of the token may be generated. Each token reference comprises a public value as well as a monetary value as two distinct token reference elements.
The public value as a token reference element may be a public key of an asymmetric cryptographic key pair, wherein the private value of the token is the private key of the asymmetric cryptographic key pair. In this embodiment, the private value and the public value are considered as a token element pair.
The token reference may also comprise a monetary value as a distinct token reference element. This monetary value may be the monetary value of the first-type token from which the one or more second-type token is originated from. In case, just one second-type token is generated in the generating step, the monetary value of the second-type token may be used as monetary value for the token reference, because both monetary values are equal.
The token reference may be sent to and stored in the token register. So, a token becomes registered as a valid token in the transaction system and can be used for further online or offline electronic payment transactions.
A token “managed by” a token management unit, such as the above described secure wallets, is a token that resides in a memory (storage) space. The memory space can be an internal memory space of the token management unit, or it can be an external memory space to which the token management unit has exclusive access rights. This memory space can include a remote memory space, such as a cloud memory (storage) space.
Implementation of modifications to tokens can be performed with the known payment transactions of WO 2020/212 337 A1; WO 2020/212 331 A1; WO 2021/170 646 A1 and WO 2021/170 645 A1 protocols.
A technical implementation of the methods at the service provider unit(s) can be performed using computer applets, such as agents, for instance running on secure hardware modules. A technical implementation of the described method steps can be the inclusion into secure element as software agent.
A corresponding token reference is associated with each token in the method and payment transaction system. Knowledge of a token reference does not authorize issuing of the digital money represented by the token. This represents a key difference between token references and tokens. A token reference is unique and also uniquely associated with one token, so there is a 1-to-1 relationship between the token and the token reference. The token reference can be computed by each participant, such as a secure wallet (e.g. in a secure element) of a participant in the electronic payment system. The computing is preferably performed by the control means.
The token reference may be obtained by applying a one-way function, for example a homomorphic one-way function or a cryptographic function. This function is a one-way function, i.e., a mathematical function that is “easy” to compute in terms of complexity theory, but “difficult” to practically impossible to reverse. Here under one-way function also a function is designated, to which up to now no inversion practically executable in appropriate time and with justifiable expenditure is known. Thus, the calculation of a token reference from a token is comparable to or equivalent to the generation of a public key in an encryption method via a residue class group. Preferably, a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as a cryptographical method analogous to an elliptic curve encryption, or ECC, from a private key of a corresponding cryptographic method. The reverse function, i.e., the generation of the token from the token reference, is thereby-equivalent to the generation of the private key from a public key in an encryption method over a residue class group-very time-consuming.
In one embodiment, the one-way function is homomorphic, i.e., a cryptographical method that has homomorphism properties. Thus, mathematical operations can be performed on the token reference that can also be performed in parallel on the token and thus be traced. Using the homomorphic one-way function, calculations with token references can be traced in the monitoring entity without the corresponding tokens being known there.
In a preferred embodiment, the one-way function is a cryptographical encryption function, e.g., based on an asymmetric or symmetric encryption scheme.
When transmitting a token directly between secure wallets, both have knowledge of the token. Preventing a double spending (one secure wallet sends the token to two different secure wallets), a switch operation on the token may be executed. The switch can preferably occur automatically when a token is received. In addition, it may also occur upon request, for example, a command from a secure wallet.
Switching, splitting, and merging are different modifications to the token. These modifications require registering the token reference in the payment system in case the validity should be proven.
In addition, it is advantageous that the tokens can be transmitted in any format. This implies that they can be communicated, i.e. transmitted, on arbitrary channels. They do not have to be stored in a determined format or in a determined program.
A mobile terminal or another user equipment, for example a smartphone, may be used as a terminal to power-up a token management unit. The secure wallet may be a physically attachable/detachable element. Alternatively, or additionally, the terminal can also be an apparatus, such as a wearable, machine, tool, vending machine or even container or vehicle.
A terminal or another user equipment according to the invention is thus either stationary or mobile. The terminal is preferably adapted to use the internet and/or other public or private networks. For this purpose, the terminal uses a suitable connection technology, for example Bluetooth, LoRa, NFC and/or Wi-Fi, and has at least one corresponding interface. The terminal may also be adapted to be connected to the internet and/or other networks by means of access to a mobile network.
In the following, the invention or further embodiments and advantages of the invention are explained in more detail based on drawings, wherein the drawings describe only embodiments of the invention. Identical components in the drawings are given the same reference signs. Elements drawn with dashed lines are considered as optional elements.
The drawings are not to be regarded as true to scale, and individual elements of the drawings may be shown in exaggeratedly large or exaggeratedly simplified form.
A minting unit MU of the issuing unit CB, e.g., of a central bank, generates new token. These generated tokens are transferred to a CB-vault of an outputting unit e.g., using an air-gap process. The outputting unit may be a secure wallet, such as a secure token management unit of the central bank TMU-CB. The new token to be issued is registered in the token register T-Reg by sending a create request 32.
For example, upon request from a token managing unit TMU1, e.g., a token managing unit (secure wallet) of a service provider unit, such as a financial service provider, e.g., a commercial bank, new tokens T are directly transferred 11 into the TMU1. Typically, TMU1 will generate a token T of the required monetary value (switch, split or merge), send a replacement request 31 to the token register T-Reg and will transfer 15 the token T to a secure wallet TMU2, e.g., a token managing unit (secure wallet) of a costumer of the commercial bank. Typically, TMU2 will perform a switch or a merge for the token T received and optionally send a registration/replacement request 31 to T-Reg. Tokens T that a costumer would like to redeem, may be transferred 15 to TMU1. TMU1 may request a deletion 12 of the old token T at the CB. CB will create a destruction request (in the melting unit), send the destruction request 33 to the token register T-Reg and will delete the token in the CB-Vault. So, payment transactions and receiving new/old tokens are handled by a single secure wallet, hereinafter referred to as TMU meaning token management unit.
In
Here an electronic payment system TS is shown having a secure token issuing unit CB for issuing new tokens and deleting old tokens. The CB is a part of a central bank issuing CBDC.
The TS further comprises a service providing unit SPU1. Further service provider units SPU may be included in the TS (not shown in
The SPU1 may have a secure management token unit TMU-SPU1 (shown in dashed lines). This TMU-SPU1 comprises control means (not explicitly shown in
The optional secure token issuer unit CB, in addition to a minting unit (not shown) and a melting unit (not shown) may comprise control means TCM and may comprise a token management unit TMU-CB (not shown in
A TMU-CB (not shown in
The optional token register T-Reg registers token references of tokens of TS. T-Reg may receive and process replacement requests 31 including token references from CB and/or SPU1 and/or TMU-Ux. Replacement requests 31 will typically comprise at least one registered token reference and at least one replacement token reference. Replacement requests 31 must be value neutral (no change of sum of monetary values registered). Replacement requests 31 furthermore include a (cryptographic) proof of ownership of the registered token(s). T-Reg will accept creation requests 32 (add token reference of new token) and/or destruction (delete token reference of old token) requests 33 only, if created by CB.
In TS only the token issuer unit CB may issue new tokens into TS or delete old tokens from TS. Only CB may thus change the overall sum of monetary values of tokens in TS.
A control means TCM in the CB (or in an SPU, SPU1) is adapted to control the processing of tokens T of multiple token management units TMU. The CB may comprise a plurality of TMUs of further service provider units SPU. The TCM in CB is provided for multiple service provider token management units.
A transfer of tokens between TMU-1-SP1 and TMU-Ux is for instance described in WO 2020/212 331 A1, DE 10 2021 004548 or DE 10 2021 004 020. The processing details for tokens described therein not only include the receiving and sending of tokens T, but for example also include token modifications (generating, replacement) or token registration, e.g. by registration request 31 provided to a token register T-Reg as well as access to respective token storages, such as SPU1-Vault (which is either located in the CB and/or in the SPU1 and/or elsewhere in the TS) to which the SPU1 has exclusive access.
At least the above aspects (of TS/CB/SPU1/T-Reg) described for
For issuing a token management unit TMU-U to a user, e.g., upon explicit request 101, the SPU1 receives 102 digital identification data D-ID-Ux of the user at an external entity. Here, the external entity is a central database hosted by an official authority unit AUTH, e.g., a resident's registration office or etc. The AUTH in
For example in return to a request of the TMU-IU and/or as a part of an authentication process, the D-ID-Ux is received 102, preferably from the AUTH or the electronic identity document or application, eID.
In an embodiment not shown in
The derivation hides the digital identification data D-ID-Ux in the TMU-ID. It may be cryptographically hidden, e.g. by using a cryptographic key of the CB known to the source of the derived part/derived TMU-ID. Another or a further cryptographic key and/or another or further digital signatures may be used, e.g., a cryptographic key and/or digital signature from the official authority unit AUTH. To reveal the D-ID-Ux, a legal authority, such as a police authority or court authority must release a specific order (e.g. a legal motion or a legal order) that allows to inverse-derive (e.g. decrypt) the D-ID-Ux. Inverse-derivation of D-ID-Ux from TMU-ID requires an inverse-derivation secret, such as the cryptographic key of a first entity, preferably the CB, a private key of a (CB) key pair including the (public) key of the entity and the private key and/or a further cryptographic key of a second entity, such as AUTH.
The result of the derivation is at least a part TMU-ID-VAR of token management unit identification data TMU-ID, which is based on at least the digital identification data D-ID-Ux. The TMU-ID is then assigned to the TMU-Ux to be issued 108 to the participant that requested it. TMU-Ux with TMU-ID may be issued as a hosted wallet hosted in SPU1 or in another SPU. Alternatively the wallet TMU-Ux may be issued as an independent wallet, for example a new secure element (card, SIM, NFC token, TEE, Wearable) or by loading the secure wallet into a existing secure element.
With the solution as shown in
The aim of a CBDC is also to increase financial inclusion, i.e. processes are needed to systematize the onboarding of new users, especially if the solution is not to be entirely anonymous.
The shown solution in
In this case, the wallet ID is at least partly derived from the D-ID-Ux during issuing the secure wallet and is traceable in case of irregularity. So this treats unbanked citizen the same as banked citizens whose wallet ID is created by the bank and is traceable.
The solution is designed in such a way that this traceability is one-way, i.e. the inverse derivation is not possible, but inverse derivation requires the inverse-derivation secret(s).
This solution as shown in
For example, the tax number is encrypted with the CB's public key and the result is used as the part TMU-ID-VAR of the wallet ID (TMU-ID).
This is in so far different from known approaches as there are D-ID (or plain text names) is encrypted for the CB and it is transmitted in each token transaction as an additional data element intended only for the purpose of ID disclosure by the CB. So, such data have not been used as a part of the wallet ID, which is however advantageous, since no additional data elements are required in the data transmission between the TMUs which reduces network efforts. Furthermore, it is now not necessary anymore that each SPU builds up its own register based on KYC data.
In the TS as shown, a PKI may be used in which certificates are used to identify important structures, such as hardware wallets, T-Reg or CB and governing certificate authorities, CA. For certificates, there are two important fields: subject names (=common names) and serial numbers, both are 16 bytes long. The subject, which is the logical name of the entity identified by the certificate, requires a naming scheme for practical purposes. The certificate for the wallet ID typically further comprises a public key of (a public key pair) the wallet, the public key preferably being a public key of a public key pair and/or an public authentication key.
Serial numbers of certificates must be unique relative to their CA. The serial number is a number given by the issuing CA, which is just counted up. The combination of serial number and subject name is globally unique for the certificate within the TS.
Subject name of a wallet, such as a hardware wallet (smart card) and a hosted wallet (within the SPU), may be the wallet ID (TMU-ID).
The TMU-ID may need to fulfil some or all of the following criteria:
The TMU-ID may need to convey if it is a Wallet certificate, or CA certificate or Admin-CA end-entity certificate.
The TMU-ID may need to be small to be transferred and stored in a hardware wallet, e.g. a smart card. The TMU-ID may need to fit into the subject field of a certificate, e.g. a length of 16 bytes should not be exceeded.
The TMU-ID may need to remain stable across changes to certificates.
The TMU-ID may need to contain information about the SPU (FSP) so that SPUs (or their payment processors) can use it to route data to the SPU (or their payment processor). For example the information enables entities to find the IP address of the SPU (or their payment processor).
The TMU-ID should contain an identifier of the CB to allow cross-currency transfers (=multi-currency transactions or multi-currency transaction systems).
The TMU-ID may need to contain an identifier for identifying the TMU within the FSP.
Options for detailed structures of TMU-IDs is provided in
In
TS may comprise a derivation unit DER in the SPU1 (or in each SPUx). Alternatively a central derivation unit C-DER may be provided in CB or as a separate central unit.
Here an electronic payment system TS is shown having a secure token issuing unit CB for issuing new tokens and deleting old tokens. The CB is a part of a central bank. The CB comprises a minting unit MU and has access to a CB-wallet TMU-CB. The wallet of the CB is preferably part of the CB to ensure security requirements. Alternatively, the CB-wallet may be a wallet remote to the CB (not shown in
The TS further comprises a service providing unit SPU1. Further service provider units SPU are indicated in dashed lines. The SPU1 has a secure management token unit TMU-SPU1. This TMU-SPU1 comprises control means for managing one or more token of the TS. The control means is configured to cause a direct exchange of one or more token with one or more other secure management units TMU-Ux in the TS. The TMU-Ux are either hosted in the SPU1 (entity in the SPU1, a user logs in remotely via a terminal device, such as computer or smart phone). Alternatively, the TMU-Ux are external to the SPU1, e.g., as physical hardware or software entities in the sphere of the individual users. Both, hosted and external TMU-Ux can be issued by the SPU1. The transfer of tokens between TMU-SP1 and TMU-Ux is for instance described in WO 2020/212 331 A1 and includes receiving and sending of tokens, modifications, registration request provided to a token register T-Reg as well as access to respective token storages, to which the SPU1 has exclusive access. The tokens of the wallets in SPU may be stored in a token vault (not shown). E.g. via encryption, each wallet is allowed/enabled to access its own tokens in the token vault only.
In
The TMU-SP1 is thus able to generate and send registration requests 31 including token references to the T-Reg and can access its tokens, which may be stored in the SPU-Vault.
The TMU-SPU1 is also referred to as FSP wallet, assuming that the SPU1 is part of a financial service provider (FSP), such as a commercial bank. The TMU-SPU1 is configured to receive new tokens issued from the CB, e.g. stored in the CB-vault, and/or is configured to send tokens to be deleted (old token) to the CB for being melted in a melting unit (not shown in
The issuing unit CB itself may comprise/transfer high monetary amounts at once. The token(s) may preferably be stored in a token vault, such as an HSM, and/or transferred by TMU-CB. The TMU-CB only acts internally to the CB. Since the CB unit preferably comprises an internal airgap, between MU and the wallet(s), including TMU-CB, there is a high security process now implemented to avoid attacks.
So, the TMU-SPU1 can be implemented for quick token transfer with TMU-Ux, e.g. for charging the token balance upon request. The TMU-SPU1_CB is furthermore exclusively used for ordering/deleting tokens from/at the CB.
The TMU-SPU1_CB in which the new tokens and the old tokens are handled needs to assure that the new tokens are separately organized from the old tokens. This can be done by different access rules or independent storages or by marking the token as “new” or “old” by using dedicated token elements or listing these tokens in a database exclusively accessible by the TMU-SPU1_CB. An access rule may be that in automated manner, new tokens are directed to the TMU-SPU1 by TMU-SPU1_CB and that old tokens are stored in a storage accessed by the TMU-SPU_CB until the CB/TMU-CB requests these old tokens.
Alternatively and not shown in
In further contrast to
While using the TMU-SPU1, it is also possible to implement direction restrictions and transaction restrictions. A technical implementation of the direction restrictions and transaction restrictions and other usage restrictions for wallets are described in more detail in DE 10 2021 004 025 and it is referred thereto for further technical details. A technical implementation of conditional transactions can be obtained from DE 10 2021 005 040 and it is referred thereto for further technical details.
In
In
The TMU-ID-FIX and the TMU-ID-VAR are combined to form the TMU-ID. This combination preferably is a concatenation, although in some cases it may be a logical combination.
In
The TMU-ID-FIX, the TMU-ID-VAR and the TMU-ID-TYP are combined to form the TMU-ID. This combination preferably is a concatenation, although in some cases it may be a logical combination.
In
The TMU-ID-FIX, the TMU-ID-VAR and the TMU-ID-CNT are combined to form the TMU-ID. This combination preferably is a concatenation, although in some cases it may be a logical combination.
In
The TMU-ID-FIX, the TMU-ID-VAR, the TMU-ID-TYP and the TMU-ID-CNT are combined to form the TMU-ID. This combination preferably is a concatenation.
Each of these Figures shows different input data for the derivation and indicates that a “Secret” may be involved in the derivation. The Secret may be the inverse derivation secret. In these cases derivation and inverse derivation use the same secret. A typical example for these cases would be a symmetric key (of a symmetric cryptographic algorithm). However, the data element “Secret” used in the derivation might also be a public data element, such as a public key of a key pair. Hence, in other cases, the derivation uses: a derivation secret or a public key and/or a public data element and the inverse derivation uses the inverse derivation secret, e.g. the private key of the key pair (of an asymmetric cryptographic algorithm).
In
In
In
In
Any of the derived parts TMU-ID-VAR of
In optional step 101, a user entity UE of user Ux requests a new TMU from a SPU. The UE is an equipment from a costumer (user) Ux of the financial SPU (commercial bank). For example, the user may have a bank account at the SPU. This request 101 is received at the SPU. Each of the steps in
In step 102 external digital identification data D-ID-Ux identifying the user are received by the SPU. Preferably, the D-ID-Ux are received from an digital identity document/application eID of the user or from an digital identity system AUTH. eID and/or AUTH are parts of the external identity system IDS.
In a first variant the SPU derives, in step 104, at least a part TMU-ID-VAR of TMU-ID from D-ID-Ux. Hence, the SPU may include a derivation unit DER. SPU and/or DER preferably are not able to perform the inverse-derivation and/or do not include the inverse derivation secret.
In a second variant the SPU receives, in step 104c, at least the derived part TMU-ID-VAR of TMU-ID (or the derived TMU-ID), which has been derived, in previous step 104b, by a central derivation unit C-DER, AUTH. In an optional step 104a the SPU requests the derived part TMU-ID-VAR or derived TMU-ID from the central derivation unit.
The central derivation unit C-DER may be a separate unit, a subunit of the issuer CB of the TS or a subunit of the identity system IDS. C-DER may be adapted to perform derivation and/or inverse derivation and thus could include the inverse-derivation secret. However, inverse-derivation would of course only be performed, if requested by an authorized entity/process, but not upon request of an SPU.
In step 105, the TMU-ID is assigned to the new TMU-Ux to be issued. In optional step 106 further wallet data, such as a certificate including TMU-ID and optionally including a public authentication key of the wallet, are received and/or generated for the wallet to be issued.
In step 108, the TMU-Ux with TMU-ID is issued by the SPU for the user. The wallet TMU-Ux comprises the TMU-ID and uses the TMU-ID in transactions with other wallets of TS. Transaction protocol data, which are preferably stored in an SPU and/or a central protocol unit of TS, comprise the TMU-ID. The transaction protocol data may comprise the wallet ID TMU-IDs of both wallets involved in the transaction and the transaction.
The wallet TMU-Ux may be a hosted wallet hosted in the SPU. Thus the step 108 of issuing may comprise providing the hosted wallet in the SPU and informing the user. For example, the user entity UE (Ux) may receive TMU-ID and/or wallet access means (such as password and/or a wallet access application).
The wallet TMU-Ux issued may be independent from the SPU. The wallet could be provided in or into a secure element, such as smart card, RFID or NFC token, USB token, SIM, Bluetooth token, TPM of a device, NFC module of a device, TEE of a device or secure wearable. In step 108 for example, the secure element including the wallet may be provided to the user or the wallet may be loaded into the user's secure element, optionally included in the user entity UE.
The SPU is preferably an entity at a financial service provider. The system TS may also comprise a token register T-REG. The token register T-Reg can be reached via an internet connection and/or a mobile communication, using typical protocols such as HTTP, TCP, IP, UDP and or other suitable communication protocols. The transaction system and/or their units may be as described above, in particular in accordance with any of
It is referred to WO 2020/212 337 A1; WO 2020/212 331 A1; WO 2021/170 646 A1 and/or WO 2021/170 645 A1 for more technical details related to the structure of tokens and their corresponding token reference as well as modifications performed or performable at a token, such as SWITCH, SPLIT, MERGE.
In any case, during direct electronic payment transactions between secure elements, in an offline electronic payment transaction, a modification (merge, split, switch) of a token may be recorded as a history date entry in the token. In an online electronic payment transaction, a modification (merge, split, switch) of a token may be registered upon registration request at the T-Reg.
Finally,
In this example C-DER is assumed to be the entity including the inverse-derivation secret. C-DER could be provided as described above or as a separate unit for inverse-derivation only. FD is a unit of TS which is allowed to request inverse-derivation from C-DER. FD preferably is a fraud detection unit. FD may be a subunit of CB. PROT may be a central transaction protocol data unit of TS. Hence, FD may analyze transaction protocol data and/or detect fraud in TS.
In an optional first step 201 FD receives TMU-ID from PROT, for example within a fraud detection process.
In step 202 FD requests inverse-derivation for TMU-ID (or the derived part TMU-ID-VAR only) from C-DER.
From TMU-ID(-VAR) C-DER in step 203 invers-derives D-ID-Ux—and optionally further input data of the derivation such as a counter and/or a ID type—using the inverse-derivation secret. In step 204 C-DER provides D-ID-Ux and optionally TMU-ID-CNT and/or TMU-ID-TYP, to FD. FD may request 206 and receive 208 user details, such as a user name and address, from the identity system AUTH. Alternatively, user details may be provided by C-DER in step 204.
In preferred embodiments of C-DER of
| Number | Date | Country | Kind |
|---|---|---|---|
| 23020100.6 | Mar 2023 | EP | regional |
