PAYMENT SYSTEM, COIN REGISTER, PARTICIPANT UNIT, TRANSACTION REGISTER, MONITORING REGISTER AND METHOD FOR PAYMENT WITH ELECTRONIC COIN DATA SETS
20230267426 · 2023-08-24
Inventors
Cpc classification
G06Q20/425
PHYSICS
G06Q20/38215
PHYSICS
H04L2209/56
ELECTRICITY
G06Q20/389
PHYSICS
G06Q20/3678
PHYSICS
G06Q20/02
PHYSICS
International classification
Abstract
A payment system is provided for making a payment using electronic coin data sets, having a coin register which is designed to register the electronic coin data sets; participating units which are designed to carry out payment transactions by transmitting the electronic coin data sets and to transmit status and registration requests relating to the electronic coin data sets to the coin register; and a monitoring register which is designed to analyze monitoring data sets relating to the payment transactions. A monitoring data set includes at least one register data set and at least one transaction data set in the monitoring register. The at least one register data set is provided by the coin register, and the at least one transaction data set is provided by a transaction data set source and/or the coin register.
Claims
1.-45. (canceled)
46. A payment system for payment with electronic coin data sets comprising: a coin register arranged to register the electronic coin data sets; participant units arranged for executing payment transactions by transmitting said electronic coin data sets and for sending status and/or registration requests concerning said electronic coin data sets; and a monitoring register arranged for evaluating monitoring data sets concerning said payment transactions, wherein: a monitoring data set in the monitoring register is formed from at least one register data set and at least one transaction data set, wherein the at least one register data set is provided by the coin register and wherein the at least one transaction data set is provided by a transaction data set source and/or the coin register.
47. The payment system according to claim 46, wherein the coin register in a first mode provides only the at least one register data set and in a second mode provides the at least one register data set and the at least one transaction data set.
48. The payment system according to claim 46, wherein the coin register is further arranged to register modified electronic coin data sets and wherein the status and/or register requests of the participant units further concern the modified electronic coin data sets.
49. The payment system according to claim 46, wherein the transaction data set source is a participant unit or a transaction register.
50. The payment system according to claim 46, wherein each participant unit is arranged to provide a transaction data set relating to transmitting an electronic coin data set to another participant unit or relating to an electronic coin data set to be registered at the coin register.
51. The payment system according to claim 46, wherein each electronic coin data set comprises at least a monetary amount as a data element and an obfuscation amount as a data element, the obfuscation amount being secret to the coin register and the monitoring register.
52. The payment system according to claim 51, wherein each electronic coin data set comprises a first check value as a data element which is incremented when transmitting the electronic coin data set directly between two participant units.
53. The payment system according to claim 51, wherein each electronic coin data set comprises a coin identifier as a data element, the coin identifier being used to identify a register data set relating to the electronic coin data set and a transaction data set relating to the electronic coin data set.
54. The payment system according to claim 46, wherein a register data set comprises one or more of the following data elements: a signature of the electronic coin data set; a range proof of an electronic coin data set; a check value of the electronic coin data set; a check value relating to the electronic coin data set; a participant identifier of a participant unit transmitting the register data set; a masked electronic coin data set; and/or a monetary amount of the electronic coin data set.
55. The payment system according to claim 46, wherein in the coin register a register data set concerning the electronic coin data set is replaced by a registering data set to be registered concerning the electronic coin data set or the modified electronic coin data set.
56. The payment system according to claim 47, wherein the mode in the coin register is set in dependence on a performed authentication of a participant unit at the coin register, wherein the second mode is set in the coin register only when a participant unit successfully authenticates itself at the coin register.
57. The payment system according to claim 54, wherein a status and registration request concerning an electronic coin data set or a modified electronic coin data set from an anonymous participant unit to the coin register is only processed when a transaction data set concerning the electronic coin data set or the modified electronic coin data set is provided evaluable in the monitoring register.
58. The payment system according to claim 46, wherein the payment system comprises a person register, wherein in the person register natural persons are assigned to respective participant identifiers of participant units of the payment system and/or to respective pseudonyms of participant units.
59. The payment system according to claim 46, wherein a register data set has one of different anonymity levels and wherein the coin register is arranged to set the anonymity level of the register data set before providing it to the monitoring register.
60. The payment system according to claim 46, wherein a transaction data set has one of different anonymity levels, wherein the transaction data set source is arranged to set the anonymity level of the transaction data set prior to providing it to the monitoring register.
61. The payment system according to claim 59, wherein for setting the anonymity level a participant identifier of a participant unit is pseudonymised or anonymised.
62. The payment system according to claim 59, wherein for setting the anonymity level a monetary amount of an electronic coin data set is pseudonymised or anonymised.
63. The payment system according to claim 59, wherein in a register data set the anonymity level of a monetary amount of an electronic coin data set is different from the anonymity level of a participant identifier of a participant unit.
64. The payment system according to claim 59, wherein in a transaction data set the anonymity level of a monetary amount of an electronic coin data set is different from the anonymity level of a participant identifier of a participant unit.
65. The payment system according to claim 59, wherein the anonymity level of a monetary amount of an electronic coin data set in a transaction data set is different from the anonymity level of a monetary amount of an electronic coin data set in a register data set.
Description
BRIEF SUMMARY OF FIGURES
[0301] In the following, the invention or further embodiments and advantages of the invention will be explained in more detail with reference to figures, the figures merely describing embodiments of the invention. Identical components in the figures are given the same reference signs. The figures are not to be regarded as true to scale, and individual elements of the figures may be shown in exaggeratedly large or exaggeratedly simplified form.
[0302] They show:
[0303]
[0304]
[0305]
[0306]
[0307]
[0308]
[0309]
[0310]
[0311]
[0312]
[0313]
[0314]
[0315]
[0316]
[0317]
[0318]
[0319]
[0320]
[0321]
FIGURE DESCRIPTION
[0322]
[0323] The problem can occur if, for example, an attacker with terminal M1 directly forwards a coin data set C.sub.b (without permission) to two terminals M2 and M3. As soon as one of the two participants with terminal M2 registers the coin data set in coin register 2 (so-called coin change), the coin data set C.sub.b becomes invalid. An unsuspecting subscriber with terminal M3 instead passes the coin data set C.sub.b directly to terminal M5 without registering it. Only terminal M7 breaks the direct transmission chain and displays coin data set C.sub.b at coin register 2. In parallel, the subscriber with terminal M2 splits coin data set C.sub.b into coin data set C.sub.c and C.sub.x and passes C.sub.c directly to terminal M4. Terminal M4 passes the coin data set C.sub.c directly to terminal M6. Terminal M6 passes the coin data set C.sub.c directly to terminal M8. Only when coin data set C.sub.c is registered with coin register 2 can the invalidity of coin data set C.sub.b and consequently the double spending be detected. Thus, an attack (double-spending of an electronic coin data set) of M1 is detected late in the prior art and a large number of direct transmissions have been executed in an unauthorised manner. In addition, due to the large number of transactions of an electronic coin data set and also due to the advancing life span, the risk increases that manipulation(s) have been carried out on the electronic coin data set.
[0324] Therefore, in a payment system, if a certain lifetime or number of actions on/with the coin data set is exceeded, the coin data set should expire, i.e. on the one hand, the number of direct transmitting of coin data sets should be limited and on the other hand, in case of a detected attack, it should be possible to trace who carried out the attack (here terminal M1). For the purpose of securing evidence, a method/system is described below in which transaction data of participant units (terminals or security elements) are archived in a remote transaction register and can be checked in the event of an official decision.
[0325] For this purpose, the payment system according to the invention comprises at least two, preferably a plurality of participant units TEs, which are also referred to or shown below as security elements SEx or terminals Mx, and a transaction register. The payment system may further comprise, for example, at least one issuing instance 1, one or more commercial banks, one (or more) central issuing register 2, which performs the registration of the coin data sets and checks and records the modifications to the coin data set. Further examples of payment systems according to the invention are shown in
[0326]
[0327] In the payment system of
[0328] During a scheduled or already executed transmitting 105 of an electronic coin data set C, as will be described in further detail below, a transaction data set TDS is generated in the first terminal M1. The transaction data set TDS has a subscriber ID of the sending terminal M1, a subscriber ID of the receiving terminal M2, optionally a transaction number, optionally a monetary amount of the coin data set, optionally a masked coin data set Z corresponding to the electronic coin data set C (masking will be explained later), and optionally a transaction time. Each subscriber ID of a terminal is assigned to a natural person for payment purposes, which is carried out and also managed in the person assignment 7. This assignment 7 is only carried out after the person has been successfully identified by presenting an identity card or passport. This assignment 7 can be changed at the request of the person, for example when changing the participant unit or adding another participant unit.
[0329] After generating the transaction data set TDS, it can be encrypted by the first terminal M1 with a cryptographic key, this is shown in more detail in
[0330] As a result of the court decision, the transaction data can be read out
[0331] The payment system BZ of
[0332] The payment system shown in
[0333] The person allocation 7 is also arranged in this first layer. The issuing instance 1 can be reached by the TEs via an air interface, for example mobile radio or WLAN or NFC. The provision of participant units TE must meet regulatory requirements. Ultimately, all participant units TE should be provided by an instance that is authorised to issue participant units TE. In one embodiment, the person allocation (person register 7) is responsible for managing personal identities of users (natural persons). Technically, this can be realised by providing each participant unit with an individual key and a certificate signed by its intermediate or root CA (Certificate Authority). This means that only participant units TE signed by the root CA can establish a secure communication channel, and malicious or modified participant units TE with invalid keys are blocked. Through the unique serial number of each certificate, an association with a determined user can be established if the relationship between serial number and user are recorded in the person register 7.
[0334] In a second layer, the coin register 2, the monitoring register 6 and the transaction register 4 are provided. This layer is used for the secure operation of checking the coin data sets C, in particular the validity, the presence of the correct monetary amount and the authenticity of the circulating coin data sets C, and checks whether coin data sets C have been issued twice. This layer can be a “distributed network”. Up to this point in the second layer, the payment system BZ is completely private. By default, payment transactions are untraceable, i.e. anonymous. This applies both to the participant (payer, payee) and to the monetary amount (payment amount).
[0335] There are country-specific requirements regarding the traceability of the electronic coin data sets both in terms of the current coin levels in the participant units TE and the transactions already carried out (history). In order to set up a law enforcement system and/or, to allow anonymous—non-trustworthy participants in the payment system BZ, the transaction register 4 is provided. It is conceivable to decouple this transaction register 4 from the payment system BZ in order to follow the principle of “separation of concerns”. For the sake of simplicity, the transaction register 4 will be assigned to the second layer of the payment system BZ in the following. Information relevant for tracing a coin data set C is stored in a transaction register 4 (of the second layer) as a “trusted instance”, i.e. a trustworthy instance. The purpose of the transaction register 4 is to keep track of data elements (payer, payee, monetary amount) of payment transactions at the payment system 2 and to keep track of payments with the associated participant units TE, their monetary amounts and a transaction time among other information. The transaction register 4 can monitor transactions for various scenarios such as money laundering, terrorist financing or tax evasion, but also analyse the use of a single coin data set. Preferably, no personal information of a natural persons is stored in the transaction register, but only subscriber unit identifiers or their pseudonyms.
[0336] In case of suspicious activities, the participant unit can thus be identified. Optionally, participant units are not linked to natural persons in order to remain anonymous. Here, participation in the payment system is only permitted with limited functionality or restrictions on monetary amounts. Accessing the transaction register can be strictly controlled and the TDS stored there can be secured. The advantage of this set-up is that unauthorised tapping from the transaction register does not constitute procurement of money and thus the monetary amounts cannot be stolen. The transaction register 4, as a trusted instance, is responsible for protecting people's privacy in regular situations and disclosing (encrypted) transaction data sets TDS when required by court decisions or when requested by the monitoring register 6. This makes it possible to check that no irregular transactions or money operations are taking place, in particular that no (new) money is being illegally created or destroyed. On the one hand, the transaction register 4 represents an extension for use cases in law enforcement with the aim of uncovering suspicious transaction data. On the other hand, the transaction register 4 is an extension for use cases where participant units cannot or do not want to authenticate themselves with the coin register 2. The transaction register 4 stores (encrypted) data records about transactions TDS that are (have to be) reported by the participating units and passes them on to the authorities or the monitoring register 6 of the payment system BZ according to a proper method. The transaction register 4 may store the transaction data sets TDS in encrypted form. This ensures that due method must be followed and that no one can access this sensitive transaction data at will. In addition, a re-encryption unit can be used in the transaction register 4 to perform re-encryption of the TDS so that a law enforcement agency obtains access only to the officially authorised data. Metadata, such as transaction time and subscriber ID, is used to provide the requested data. The re-encryption unit of the transaction register 4 can access and decrypt all data.
[0337] The third layer is a direct transaction layer 3 in which all participants, i.e. consumers, merchants, etc., participate equally via their participant units TE to exchange electronic coin data sets C. Each participant unit TE may have a wallet application to manage coin data sets C. The coin data sets C can be stored locally in the participant unit TE or they can be stored in an online storage (=cloud storage) and the participant unit TE can manage them remotely. In the case of an offline scenario, where a transmission 105 takes place without control instances or register instances 2, 4, 6 of the payment system BZ, participant units TE can interact directly (directly) with other participant units TE. The actual data transmission for a coin data set may comprise further intermediary instances. This offline design of the payment system BZ requires that the coin data sets C are saved in certified areas, for example a wallet application, ideally within security elements SE, for example smart cards or an eSim environment, in order to obtain trustworthiness in the payment system BZ.
[0338] To generate an electronic coin data set C, the following method is proposed.
[0339] The transmitting 105 is done, for example, wirelessly via WLAN, NFC or Bluetooth, thus preferably locally. The transmitting 105 may be further secured by cryptographic encryption methods, for example by negotiating a session key or applying a PKI infrastructure. The transmitting 105 may also be performed involving an online data memory from which the electronic coin data set C is transmitted to the TE2 (M2, SE2).
[0340] In the transmission step 105, for example, a secure channel is established between the SE1 and the SE2, during which both SEs authenticate each other. The transmission path between SE1 and SE2 is not necessarily direct, but can be an Internet or near-field communication path with instances (terminals, routers, switches, applications) connected in between. By using SEs as a secure environment instead of terminals ME as TEs, a higher level of trust is generated, i.e. trustworthiness in the payment system BZ is increased. At the same time as the eMD C is sent, or immediately before or after, a timer is optionally started. Before this, the eMD C can be invalidated and then no longer be used by SE1 for actions (as described below). The eMD C is thus blocked in the payment system BZ due to a transmission process 105 that has already been initiated (and not yet completed). This prevents double spending. Invalidation enables easy handling during the transmission process 105.
[0341] When the eMD C is properly received in the SE2, a receipt confirmation is generated by the SE2 and sent back to the SE1. The receipt confirmation from the SE2 can be sent as a deletion request, because only after deletion of the eMD C in the SE1 can (may) the eMD C be validated and used in the SE2. Optionally, the deletion of the eMD C can be displayed by SE1. For example, an amount display of the SE1 (or of a terminal ME1 in which the SE1 is logically located) is updated. For example, the monetary amount of the eMD C is subtracted from an amount of the SE1 available for payment transactions. A deletion confirmation can be sent from the SE1 to the SE2. This serves as an acknowledgement that the eMD C is no longer available in SE1 and can therefore be validated in SE2. Upon obtaining the deletion confirmation in the SE2, the SE2 can convert a status of the eMD C in the SE2 into an active status, the eMD C is thus validated and can be used for further payment transactions or actions (splitting, combining, switching) in the SE2 from this point on. Optionally, the eMD C of the SE2 is switched to the SE2 in coin register 2 (see below), whereby the eMD C is registered to the SE2 (step 104).
[0342] A transmitting error 105 may be detected in the SE1, for example by exceeding a predefined time period, indexed by a timer, or by receiving an error message from the SE2 or the terminal M1 or the other terminal M2 (not shown). For example, with each new transmitting attempt for transmitting the eMD C (RETRY), a counter value can be incremented and, if a maximum permissible number of retries is exceeded, for example 10 or 5 or 3 times, it is decided in step 308 automatically and independently of the error case that no new transmitting attempt (RETRY) is carried out, but that the transmitting 105 is to be terminated as unsuccessful and a ROLLBACK is to be carried out.
[0343] In an alternative embodiment of the transmitting method 105, the status of the eMD is reported by the SE1 to the coin register 2. A connecting is then established with the coin register 2 for a status request to the eMD C. If the coin register 2 continues to report an inactive status back to the eMD C (registered to the SE1), no transaction error (tampering attempt) is assumed. However, if coin register 2 returns an active status to the eMD C or a registration to another SE, a transaction error (tampering attempt) is assumed and the payment system is alerted. The transaction data set TDS of the SE1 is used for proof.
[0344] The electronic coin data set C may be requested in advance from an issuing instance 1 and optionally received by a terminal M (or an SE) or the issuing instance 1 or another payment system. Steps 104 and 105 may correspond to steps 104 and 105 of
[0345] For example, a true random number is generated as the obfuscation amount r.sub.i. The obfuscation amount r.sub.i is known in the direct transaction layer 3 and also in the issuing instance 1, but is secret to the transaction register 4, the monitoring register 6 and the coin register 2. The obfuscation amount r.sub.i is associated with a monetary amount ν.sub.i. Accordingly, an i-th electronic coin data set according to the invention could read:
C.sub.i={ν.sub.i;r.sub.i} (1)
[0346] In addition to these data elements, the electronic coin data set C may comprise at least one check value. The check value represents, for example, the number of off-line transmissions (payment transactions) with this electronic coin data set. For example, the check value represents the number of offline transmissions (payment transactions) of the participant unit without performing registration.
[0347] In addition to these data elements, the electronic coin data set C may comprise a coin identifier M-ID. For example, the coin identifier is a unique number that is unique to the payment system BZ. For example, the coin identifier M-ID is a random number generated by the participant unit or the issuing instance 1.
[0348] A valid electronic coin data set can be used for payment. The owner of the two values ν.sub.i and r.sub.i, is therefore in possession of the digital money. The digital money is defined by a pair consisting of a valid electronic coin data set C.sub.i and a corresponding masked electronic coin data set Z.sub.i. A register data set, or RDS, is associated with the electronic coin data set.
[0349] For example, a masked electronic coin data set Z.sub.i is obtained as RDS, by applying a homomorphic one-way function f (C.sub.i) according to equation (2):
Z.sub.i=f(C.sub.i) (2)
[0350] This function f(C.sub.i) is public, i.e. any system participant can call and use this function. This function f(C.sub.i) is defined according to equation (3):
Z.sub.i−ν.sub.i.Math.H+r.sub.i.Math.G (3)
where H and G are generator points of a group G in which the discrete logarithm problem is hard, with generators G and H for which the discrete logarithm of the other basis is unknown. For example, G and H are generator points of an elliptic curve encryption, ECC—that is, private keys of ECC. These generator points G and H must be chosen in such a way that the context of G and H is not publicly known, so that if:
G=n.Math.H (4)
the association n must be practically unlocatable to prevent the monetary amount ν.sub.i from being manipulated and yet a valid Z.sub.i could be calculated. Equation (3) is a “Pederson commitment for ECC”, which ensures that the monetary amount can be committed to a coin register 2 without revealing it to the coin register 2.
[0351] Alternatively, the RDS may comprise an amount category in addition to the masked coin data set Z.sub.i. The amount category is a pseudonymised form of the monetary amount ν.sub.i of the electronic coin data set C. For example, the amount category is a range (from to) in which the monetary amount ν.sub.i lies. For example, the amount category is a range threshold (greater than; less than) above or below which the monetary amount ν.sub.i lies. For example, the amount category is a rounded value of monetary amount ν.sub.i. For example, the amount category is a rounded up value of the monetary amount ν.sub.i. This makes the RDS amount pseudonymous and identity anonymous.
[0352] Alternatively, the RDS may comprise a coin identifier M-ID in addition to or instead of the masked coin data set Z.sub.i. This creates a unique reference in the RDS to the electronic coin data set C.
[0353] Alternatively, the RDS may comprise a pseudonym P of the participant unit. The pseudonym may be managed in the person assignment 7. Thus, the RDS is amount-anonymous and identity-pseudonymous. In this embodiment, the RDS may comprise a check value p of the coin data set.
[0354] In the following, for simplicity, an RDS may be equated with a masked coin data set Z, as this is a highly preferred embodiment.
[0355] Therefore, only the RDS, for example the masked coin data set Z.sub.i is sent (revealed) to the coin register 2, which is shown in
[0356] Even though in the present example an encryption based on elliptic curves is described, another cryptographic method based on a discrete logarithmic method would also be conceivable.
[0357] Due to the entropy of the obfuscation amount r.sub.i, equation (3) makes it possible to obtain a cryptographically strong Z.sub.i even with a small range of values for monetary amounts ν.sub.i. Thus, a simple brute force attack by merely estimating monetary amounts ν.sub.i is practically impossible.
[0358] Equation (3) is a one-way function, which means that computing Z.sub.i from C.sub.i is easy because an efficient algorithm exists, whereas computing C.sub.i starting from Z.sub.i is very hard because no polynomial-time solvable algorithm exists.
[0359] Moreover, equation (3) is homomorphic for addition and subtraction, which means:
Z.sub.i+Z.sub.j=(ν.sub.i.Math.H+r.sub.i.Math.G)+(ν.sub.j.Math.H+r.sub.j.Math.G)=(ν.sub.i+ν.sub.i).Math.H+(r.sub.i+r.sub.j).Math.G (5)
[0360] Thus, addition operations and subtraction operations can be executed both in the direct transaction layer 3 and in parallel in the coin register 2 without the coin register 2 having knowledge of the electronic coin data sets C. The homomorphic property of equation (3) allows monitoring of valid and invalid electronic coin data sets C.sub.i based solely on the masked coin data sets Z.sub.i and ensuring that no new monetary amount ν.sub.j has been created.
[0361] This homomorphic property allows the coin data set C.sub.i to be split according to equation (1) into:
C.sub.i=C.sub.j+C.sub.k={ν.sub.j;r.sub.j}+{ν.sub.k;r.sub.k} (6)
Where it holds that:
ν.sub.i=ν.sub.j+ν.sub.k (7)
r.sub.i=r.sub.j+r.sub.k (8)
For the corresponding masked coin data sets holds:
Z.sub.i=Z.sub.j+Z.sub.k (9)
[0362] Equation (9) can be used, for example, to easily check a “symmetric or asymmetric splitting” processing or a “symmetric or asymmetric splitting” processing step of a coin data set according to
[0363] Electronic coin data sets C can also be joined (connected) in the same way, see
[0364] In addition, it is important to check whether (not allowed) negative monetary amounts are registered. An owner of an electronic coin data set C.sub.i must be able to prove to the coin register 2 and/or a monitoring register 6 that all monetary amounts ν.sub.i in a processing operation are within a value range of [0, . . . , n] without informing the coin register 2 of the monetary amounts ν.sub.i. These range proofs are also called “range proofs”. Preferably, ring signatures are used as range proofs. For this example, both the monetary amount ν and the obfuscation amount r of an electronic coin data set C are resolved in bit representation. It holds:
ν.sub.i=Σa.sub.j.Math.2.sup.j for 0≤j≤n and a.sub.j∈{0;1} (9a)
As well as
r.sub.i=Σb.sub.j.Math.2.sup.j for 0≤j≤n and b.sub.j∈{0;1} (9b)
[0365] For each bit, preferably a ring signature with
C.sub.ij=a.sub.j.Math.H+b.sub.j.Math.G (9c)
and
C.sub.ij−a.sub.j.Math.H (9d)
is preferably carried out for each bit, whereby in one embodiment it can be provided that a ring signature is only carried out for certain bits.
[0366] According to
[0367] In the payment system BZ, a counter value p.sub.i2 can also be maintained or determined to include the check value p.sub.i1, for example as the sum of the previous (registered) counter value p.sub.i2 and the check value p.sub.i1, to determine whether to return the coin data set C. Each action with coin data set C increases this counter value p.sub.i2. Different action types weight the counter value p.sub.i2 differently, so that, for example, a direct transmission of the coin data set C has a higher weight than a modification (splitting, combining, switching). In this way, the lifetime and the actions performed in it of a coin data set C are evaluated and criteria for its return are defined according to the actions performed. The check value p.sub.i1 and also the counter value p.sub.i2 map the life cycle of the coin data set C, which is then used to decide whether to return it.
[0368] In the payment system BZ, a check value p can also be provided in a participant unit TE (i.e. the terminals M1, M2 or security elements SE1, SE2 shown in
[0369]
[0370] In
[0371] In SE2, the transmitted electronic coin data set C.sub.i is obtained as C.sub.i*. Upon obtaining the electronic coin data set C.sub.i*, the SE2 is in possession of the digital money represented by the electronic coin data set C.sub.i*. With direct transmission 105, it is available to the SE2 for further action.
[0372] Due to the higher trustworthiness when using SEs, SE1, SE2 can trust each other and in principle no further steps are necessary for transmitting 105. However, SE2 does not know whether the electronic coin data set C.sub.i* is actually valid. Further steps in the method may be provided to further validate transmitting 105, as explained below.
[0373] To check the validity of the obtaining electronic coin data set C.sub.i*, another RDS, for example the masked transmitted electronic coin data set Z.sub.i*, can be calculated in SE2 using the—public—one-way function from equation (3). The RDS, for example the masked transmitted electronic coin data set Z.sub.i*, is then transmitted to the coin register 2 in step 104 and searched for there. If both RDSs match with respect to the same coin data set C, for example a match with a registered and valid masked electronic coin data set Z.sub.i, the validity of the obtaining coin data set C.sub.i* is displayed to the SE2 and it is valid that the obtained electronic coin data set C.sub.i* is equal to the registered electronic coin data set C.sub.i. In one embodiment, the validity check can be used to determine that the obtained electronic coin data set C.sub.i* is still valid, i.e. that it has not already been used by another processing step or in another transaction/action and/or has not been subject to further modification.
[0374] Preferably, a switching (=Switch) of the obtained electronic coin data set takes place afterwards.
[0375] The sole knowledge of an RDS, e.g. a masked electronic coin data set Z.sub.i, does not authorise the issuing of the digital money of the corresponding electronic coin data set C.sub.i.
[0376] The sole knowledge of the electronic coin data set C.sub.i entitles for payment, i.e. to perform a transaction successfully, especially if the coin data set C.sub.i is valid, for example if the electronic coin data set C.sub.i has an active status. The status is preferably set to an active status only upon obtaining the deletion confirmation of the SE1. There is a one-to-one relationship between the electronic coin data sets C.sub.i and the corresponding masked electronic coin data sets Z.sub.i. The masked electronic coin data sets Z.sub.i are registered in the coin register 2, for example a public database. This registration 104 first makes it possible to check the validity of the electronic coin data set C.sub.i, for example whether new monetary amounts have been created (in an illegal manner).
[0377] The masked electronic coin data sets Z.sub.i are stored in the coin register 2. All processing on the electronic coin data set Z.sub.i is registered there or in the monitoring register 6, whereas the actual transmitting of the digital money takes place in a (secret, i.e. not known to the public) direct transaction layer 3 of the payment system BZ. Moreover, in this payment system BZ, monitoring operations on the coin data set C and the participant unit TE can be recorded in a monitoring register 6.
[0378] To prevent multiple issuance or to ensure more flexible transmitting 105, the electronic coin data sets C can be modified. Table 1 below lists exemplary operations, with the specified command also executing a corresponding processing step:
TABLE-US-00001 TABLE 1 Number of operations that can be performed per processing of a C in the TE or the issuing instance command create create random create create range or step signature number masking proof generating 1 1 1 0 or 1 returning 1 0 1 0 or 1 splitting 1 1 3 0 or 1 connecting 1 0 3 1 switching 1 1 2 1
[0379] Other operations not listed in table 1 may be required, such as changing the currency or redeeming the monetary amount in an account. Instead of the implementation listed, other implementations are also conceivable that imply other operations. Table 1 shows that for each coin data set, each of the processing operations (modifications) “generating”, “returning”, “splitting”, “connecting” and “switching” may provide for different operations “create signature”; “create random number”; “create masking”; “range check”, each of the processing operation being registered in the coin register 2. Alternatively and preferably, each of the processing operation is appended in the monitoring register 6 in invariant form to a list of previous processing operations for masked electronic coin data sets Z.sub.i. The monitoring register 6 thus represents an archive for RDS concerning previous coin data sets. The operations of the processing operations “create” and “return” an electronic coin data set C are executed only at secure locations and/or only by selected instances, for example the issuing instance 1, while the operations of all other processing operations can be executed on the participant units TE, i.e. the terminals M or their security elements SE.
[0380] The number of operations for the individual processings is marked with “0”, “1” or “2” in Table 1. The number “0” indicates that a participant unit TE or the issuing instance 1 does not need to perform this operation for this processing of the electronic coin data set C. The number “1” indicates that the participant unit TE or the issuing instance 1 must be able to perform this operation once for this processing of the electronic coin data set C. The number “2” indicates that the participant unit TE or the issuing instance 1 must be able to perform this operation twice for this processing of the electronic coin data set.
[0381] In principle, in one embodiment, it can also be provided that an range check is also performed by the issuing instance 1 during generating and/or deleting.
[0382] Table 2 below lists the operations required for the coin register 2 and/or the monitoring register 6 for the individual processing operations:
TABLE-US-00002 TABLE 2 Number of operations that can be performed per processing of a C in the coin register retrace homomorphic check check validity properties of check signature of masked masked electronic command signature from security electronic retrace coin data sets, i.e. or step from issuer element coin data set range proof adding or subtracting generating 1 0 0 0 or 1 0 returning 1 0 1 0 or 1 0 splitting 0 1 1 2 or more 1 connecting 0 1 2 or more 1 1 switching 0 1 1 1 0
[0383] Other operations not listed in table 2 may be required. Instead of the listed implementation, other implementations are conceivable that imply other operations. All operations of table 2 can be performed in the coin register 2, which is a trusted instance, for example a server instance, for example a distributed trusted server, which ensures sufficient integrity of the electronic coin data sets C.
[0384] Table 3 shows the preferred components to be installed for the system participants in the payment system of
TABLE-US-00003 TABLE 3 Preferred units in the system components coin register/monitoring issuing participant register/transaction command or step instance unit register random number generator yes — — (high security) random generator — yes —/—/yes (deterministic) PKI for signing yes yes —/—/yes PKI for signature check — (yes) yes read access yes yes yes write access yes yes yes returning the electronic yes yes — coin data set transport encryption yes yes —/—/yes secure storage (yes) yes —/—/yes masking unit yes yes — range proof — yes — check range proof — — yes/yes/—
[0385] Table 3 shows an overview of the preferred components to be used in each system participant, i.e. the issuing instance 1, a participant unit TE and the register instances, namely the coin register 2, the monitoring register 6, the transaction register 4.
[0386] The participant units TE can be designed by means of an e-wallet for electronic coin data sets C.sub.i (with the check value p, p.sub.i1, p.sub.i2), i.e. as an electronic purse with a memory section in which a plurality of coin data sets C.sub.i can be stored, and thus be implemented, for example, in the form of an application on a smartphone or IT system of a trader, a commercial bank or another market participant. Thus, the components in the participant unit TE, as shown in table 3, are implemented as software. It is assumed that the coin register 2, the transaction register 4 and/or the monitoring register 6 are based on a server or on a DLT and are operated by a number of trusted market participants.
[0387] In the coin register 2, an RDS relating to the electronic coin data set C may be replaced by an RDS relating to the electronic coin data set C or a modified electronic coin data set C to be registered. Thus, (only) current coin data sets C—existing in the payment system BZ—are maintained as RDS in the coin register 2. Any previous versions or earlier modifications are then maintained, for example, in monitoring register 6 as monitoring data set ÜDS and are made available for this purpose from coin register 2 to monitoring register 6 during the replacement process and are saved there. This allows the history of the electronic coin data set C to be logged by the monitoring register 6. In this way, the coin register 2 is optimised in terms of register data records (=memory optimised) and reacts more quickly to registers or status requests from participant units TE and/or the monitoring register 6.
[0388] The monitoring register 6 stores monitoring data sets, or ÜDS for short, for this purpose. An ÜDS is formed from at least one TDS and at least one RDS in the monitoring register 6.
[0389] A ÜDS corresponds to exactly one electronic coin data set C and is formed from exactly one TDS, which also corresponds to the electronic coin data set, and exactly one RDS, which also corresponds to the electronic coin data set, in the monitoring register 6. This formation takes place after the TDS has been provided by the transaction register and the RDS has been provided by the coin register. A monitoring data set ÜDS relates to exactly one payment transaction.
[0390] In an alternative embodiment, a ÜDS may also concern a plurality of electronic coin data sets C, for example all electronic coin data sets C sent by a participant unit TEx within a predefined time period. In this context, an ÜDS is formed, for example, from a plurality of TDS concerning this participant unit TEx in the time period. In addition, the ÜDS is formed, for example, from several RDS relating to modifications to coin data sets C. The modifications are thereby initiated and/or requested and/or status checked by the TEx within the time period. Next, a ÜDS concerns a plurality of TDS (corresponding to respective electronic coin data sets C of this participant unit TE, preferably in this transaction time period) and at least one, preferably several register data sets RDS (also corresponding to the respective electronic coin data sets C of this participant unit TE, preferably in this transaction time period) formed in the monitoring register 6. A monitoring data set ÜDS then concerns several payment transactions of this participant unit TEx, preferably within a predefined time period.
[0391] After the respective monitoring data set ÜDS has been formed, the monitoring register 6 can evaluate the monitoring data set ÜDS. This evaluating concerns checking for double issuing of electronic coin data sets C or unauthorised generation of monetary amounts by a participant unit TE and/or also checking for ageing of electronic coin data sets C. By forming and evaluating in the monitoring register 6, it can be determined, for example, that a participant unit TE has issued a coin data set C twice or has changed a monetary amount. In addition, it can be determined that a coin data set C has not been used for a predefined period of time and this is communicated to the subscriber TE or an automatic return to the issuing instance 1 is initiated.
[0392]
[0393] Reference is made to the executions of
[0394] In
[0395] In addition, the sending of TDS in the payment system BZ is represented by a solid line. In principle, TDS are created by a TE and made available to the transaction register 4 (see
[0396] In the payment system BZ, data elements that can lead to a TDS are also shown as a solid line. On the one hand, participant identifiers or pseudonyms P derived from them are kept in the person register 7 or a commercial bank 1a or a service server (not shown).
[0397] This mapping is then provided to the transaction register 4 to pseudonymise, for example, a TDS of a participant unit TE1 to provide a pseudonymised TDS* to the monitoring register 6. Pseudonymising a TDS will be explained in more detail with steps 410 and/or 411 of
[0398] In one embodiment of the payment system BZ, a TE (in this case the TE2) authenticates itself to the coin register 2. During authentication, participant identifiers or pseudonyms P are queried. Thus, the coin register 2 is aware of participant identifiers and can use them in a second mode (
[0399] In an alternative embodiment of the payment system BZ, a TE (here the TE2) does not authenticate itself to the coin register 2. Thus, the coin register 2 is not aware of participant identifiers and only provides RDS to the monitoring register 6 in a first mode (
[0400]
[0401] In one embodiment, an assignment of the person register 7 or the TE is made known to the coin register 2, for example, to pseudonymise an RDS to provide a pseudonymised RDS* to the monitoring register 6. Pseudonymising an RDS is similar to steps 410 and/or 411 of
[0402] A mode switch MODE in coin register 2 sets either the first mode of the coin register 2, in which only the RDS are provided to the monitoring register 6, or sets the second mode of the coin register 2, in which the RDS and the TDS are provided to the monitoring register 6. The TDS can be obtained from the authentication data.
[0403]
[0404]
[0405]
[0406] After generating the transaction data set TDS, it is encrypting by the first terminal M1 with a cryptographic key. This cryptographic key is, for example, a public key part of a corresponding composed private key part. This private key part is composed of three partial keys 8a, 8b, 8c, where the partial keys 8a, 8b, 8c have been added or XOR-associated, for example. This association of the partial keys 8a, 8b, 8c takes place either in the first terminal M1 or in the transaction register 4. This association of the partial keys 8a, 8b, 8c is, for example, secret throughout the system. Knowledge or possession of only one partial key 8a, 8b, 8c does not enable decryption of the transaction data set TDS.
[0407] In
[0408] In cases of suspected fraud, an official order, for example a court order, could be issued to decrypt the encrypted transaction data set TDS in order to detect and analyse the transaction recorded with it (the transmitting 105). By means of the official order, for example, all stored transactions would then be queried at the transaction register 4 for a terminal M (by means of the identifier) over a determining time or period of time. In addition, further attributes of the transaction data, such as the monetary amounts of the coin data sets, the respective transaction partners, etc., could be queried.
[0409] As a result of the court decision, the transaction data can be decrypted by a plurality of remote instances as authorised parties generating (or providing) a decryption key by combining their partial keys. The remote instances are, for example, law enforcement agencies, notaries, the ministry of justice, a central bank or others. All remote instances (authorised parties) have only partial keys 8a, 8b, 8c of the decryption key. All members or a minimum number n of m remote instances are required to decrypt the transaction data set TDS together. Technically, the individual partial keys 8a, 8b, 8c of the different remote instances are composed into a common private key part by addition or by bitwise XORing. This private key part (which corresponds to the corresponding public key part of the encryption) is then used to decrypt the transaction data set TDS. This concept guarantees that no remote instance can decrypt the transaction data set TDS on its own and could thus bypass other instances. If the concept should not rely on the availability of all m remote instances, threshold cryptography could be applied to use a subset n of these partial keys 8a, 8b, 8c. This subset n then defines the minimum number of partial keys 8a, 8b, 8c to be combined.
[0410] In addition to identifying illegal activities, storing transaction data in the transaction register can perform the following additional tasks: [0411] 1. A monitoring of the movement and use of a coin data set: all information is stored in a transaction register 4, for example a large data memory available. The corresponding data analysis enables an adaptation of the behaviour of a central bank when issuing the coin data set. [0412] 2. The visibility of the coin data sets in circulation to control the offering: The issuing instance, for example a central bank, always knows the exact amount of coin data sets currently in circulation. It is thus possible to track and deactivate both participant units and coin data sets that have not participated in the payment system FC for a long period of time, for example 1 year, so as not to jeopardise the security of the payment system BZ. [0413] 3. Provision of monitoring information by commercial banks or service providers is not necessary anymore. This information is automatically provided at a transaction-based level by all participant units.
[0414]
[0415] In step 301, a transaction data set TDS is generated. The transaction data set TDS comprises the participant identifiers from the first participant unit TE1 (sending TE) and from the second participant unit TE2. In addition, information about the electronic coin data set C to be transmitted (or the transmitted) is included, for example the monetary amount ν. Instead of the information about the electronic coin data set C to be transmitted (or the transmitted), the masked electronic coin data set Z can be inserted into the TDS. In addition, a transaction time may be included in the TDS to indicate the time of transmitting 105 the electronic coin data set C between both participant units TE. The time of generating 301 may be closely timed to the time of transmitting 105. The payment system BZ may require that the electronic coin data set C is transmitted first (step 105) before the encrypted transaction data set TDS is sent.
[0416] After the generating step 301, the generated transaction data set TDS is encrypted. For this purpose, the first participant unit TE1 has a public key part K composed of partial keys of different remote instances. The key composition is shown, for example, in
[0417] In step 303, the encrypting of the transaction data set TDS with the cryptographic key K in the first participant unit TE1 takes place, for example by an encryption module or a computing unit of the first participant unit TE1.
[0418] Not shown in
[0419] In step 304, a communication link to the transaction register 4 is then initiated. This attempts to establish a communication channel between the first participant unit TE1 and the transaction register 4. Initiating also comprises the respective participant unit TE detecting/knowing that an offline transaction is currently scheduled/performed and that a connecting to the remote transaction register 4 cannot or should not be established.
[0420] In the subsequent check step 305, the participant unit TE1 is queried whether a connection could be established in step 304. In the yes case of check step 305, the encrypted transaction data set TDS is sent to transaction register 4 in step 306. If necessary, other transaction data sets TDS from previous transmissions of electronic coin data sets C are also transmitted, should this communication link have been established for the first time since these transmissions. In this context, a check value is then also reset (not shown in
[0421] In the no case of check step 305 (offline transaction, flight mode, no sending of transaction data TDS desired (by subscriber)) and also in the yes case of check step 305a (transmission error, disconnection), a connection error is detected in step 307. Following this, a check value p in the first participant unit TE1 is compared with a threshold value X in check step 308. The check value in step 308 represents a number of (offline) transmissions 105 of electronic coin data sets C that have occurred without sending a transaction data set TDS. These (offline) transmissions 105 from the first participant unit TE1 may have been transmitted to any other participant unit TEx. In the yes case of the check step 308, i.e. if this check value p is greater than the threshold value X, for example 100 or 50 or 10 transmissions, the transaction data set TDS is stored (encrypted and/or unencrypted) and it is mandatory to repeat step 304. In the no case of the checking step 308, transmitting 105 takes place if a default in the payment system BZ is that the encrypted transaction data set TDS must be sent first before the electronic coin data set C may be transmitted in step 105. In step 310, the check value p is then incremented, i.e. increased in steps, preferably by 1.
[0422] Steps 308 to 310 ensure that the off-line behaviour of the participant units TE remains monitored and is not possible to exceed a predefined determined (payment system predetermined) threshold value X of transmission numbers. Transaction data sets TDS of an offline transaction that cannot be transmitted immediately, i.e. a transmitting 105 without registering 104 or reporting to one of the register instances 2, 4, 6 of the payment system BZ, are temporarily stored in step 309 and transmitted at a later time. The number of offline transactions that a participant unit TE may perform is limited by the payment system and controlled by means of the check value p in step 308. If the threshold value X is reached, the transaction data sets TDS must first be sent before another offline transaction 105 is possible (see step 309 for step 304). This check value p may be recorded and maintained independently of other checks in the participant unit TE. This check value p can be combined with other check or count values p.sub.i1, p.sub.i2, of the coin data set C for checking in the coin register 2 or the monitoring register 6, see payment system BZ of
[0423] Individual method steps can be interchanged. For example, a general first requirement in the payment system BZ can be that coin data sets C are first transmitted between TEs before a transaction data set TDS is created for them. In this case, a TDS would always relate to a coin data set C that has already been transmitted, and step 105 would be performed before the associated steps 301, 303.
[0424] Alternatively, a general first default in the payment system BZ can be that coin data sets C are only transmitted between TEs (step 105) after a transaction data set TDS has been created for it (step 301). In this case, a TDS would always concern a coin data set C that has yet to be transmitted, and step 105 would be carried out after the corresponding step 301.
[0425] A second general requirement in the payment system BZ could concern the local storage of TDS in the TE. Thus, it may be required that TDS are also to be stored locally (i.e. history or archiving). The storage step 309 is then not only to be provided for transmitting repetitions (in case of error of a first transmitting attempt). It may be a default detail that the TDS shall also be stored encrypted in the TE. This local storage of the TDS, which is redundant to the storage of the TDS in the transaction register 4, can be read out in the context of an official request (a court order), i.e. the participant can be forced to provide this local storage or the transmission of the local storage can take place in a (background) process of the participant unit TE without participant interaction.
[0426] A third general requirement in the payment system BZ can be to store pseudonymised TDS* in a monitoring register 6 of the payment system BZ. These pseudonymised TDS* are taken into account in the validity of the coin data sets in order to be able to detect fraud scenarios within the payment system. A fourth general requirement in the payment system FC can be not to send encrypted TDS to the transaction register 4 if an offline transaction is planned/carried out. This default can be closely coupled to the check value p, so that a participant unit TE issues a warning to the participant even before a transmitting mode (online or offline) is selected that a check value p has exceeded a threshold value for the maximum number of offline transmissions 105 and no further offline transmission is possible without first sending (old) TDS to the transaction register 4 (with resetting of the check value counter).
[0427] In
[0428] Here, in step 401, an encrypted transaction data set TDS is received from a participant unit TE in the transaction register 4. This transaction data set TDS has been generated according to the method shown in
[0429] In the optional check step 402, it is checked whether different generations of partial keys are present in the payment system BZ, for example the transaction register 4, preferably an HSM module within the transaction register 4 as a key store. In the yes case of step 402, the transaction data set TDS is decrypted with the private key part k of the cryptographic key as decryption key in step 403 and re-encrypted with a cryptographic key, for example an HSM key of the transaction register 4. In this way, storing differently encrypted transaction data sets TDS encrypted with different key versions of the remote instances can be prevented in the transaction register 4. The administrative overhead in transaction register 4 is thus reduced.
[0430] After the re-encrypting step 403 or in the no case of the checking step 402, the transaction data set TDS is stored in a memory section and archived there. If applicable, the transaction data set TDS has metadata in plain text that is entered or kept track of in a database of the transaction register 4. For example, if a transaction time exists as a metadata of the TDS, a deletion time can be generated as part of a data retention. The TDS would then be automatically deleted from the transaction register 4 after a set period of time (the deletion time) has elapsed.
[0431] In the transaction register 4 (e.g. a database as a trusted instance), the TDS are stored in encrypted form, requiring multiple partial keys to decrypt them. This ensures that due method must be followed and that no one can access sensitive transaction data TDS at will.
[0432] Optionally, for example in the absence of a key store in the transaction register 4, partial keys of the cryptographic key k are received in step 405 and combined in step 406 in the transaction register 4, for example to form the private key part of the private key part when using a PKI key structure. The combination is secret, for example, so as not to allow owners of the partial keys 8a, 8b, 8c to combine the decryption key. The combined key may also be composed of only a subset of partial keys, which is possible by applying threshold value cryptography.
[0433] In the context of an official request—generated from outside the payment system BZ—in particular on the basis of a court order, a decryption request is made to the transaction register 4 in step 407. In this step, the metadata of the transaction data sets can be matched with parameters of the decryption request, for example to query all transaction data sets with a determining participant ID for a determining point in time or period of time. Subsequently, in step 408, each remote instance is requested to authenticate to the transaction register 4. Alternatively, only a required subset of remote instances necessary to decrypt the desired transaction data set(s) TDS is requested. In step 409, decryption is then performed using the combined key from the shared partial keys of the remote instances.
[0434] Optionally, in step 410, for example, even without step 407, a participant unit identifier in the decrypted transaction data set TDS is replaced by a pseudonym of the participant unit TE. The pseudonym preferably corresponds to the pseudonym of
[0435] Optionally, in step 411, for example, even without step 407, a monetary amount in the decrypted transaction data set TDS is replaced with one or more amount categories in addition to or as an alternative to step 410. In one embodiment, for example, the monetary amount of the coin data set C is rounded up or down, for example: [0436] monetary amount of 1.97 becomes the amount category “2 euros” [0437] monetary amount of 878.99 becomes the amount category “1000 euros” [0438] monetary amount of 4.07 becomes amount category “4 euros” [0439] monetary amount of 2118.22 becomes the amount category “2000 euros”
[0440] In a further embodiment, the monetary amount is sorted into one or more amount categories that represent amount ranges, for example: [0441] a monetary amount of 1.97 becomes the amount category “less than 10 euros” [0442] monetary amount of 878.99 becomes the amount category “between 100 and 1000 euros”) [0443] monetary amount of 4.07 becomes the amount category “greater than 1 euro”.
[0444] Steps 410 and/or 411 may be performed by an HSM in transaction register 4. The pseudonymised transaction data TDS* and/or the amount categorised transaction data is (re)sent to the monitoring register 6 or the participant unit TE in step 412. changed for the respective transaction data set. The encrypted transaction data set TDS is stored in the transaction register (step 404 after step 412, if applicable).
[0445] The pseudonymised transaction data set TDS* always has a higher level of anonymity than the (non-pseudonymised) transaction data set TDS. With this higher anonymity level, the pseudonymised transaction data set TDS*—in a default of the payment system BZ—can also be stored unencrypted in the coin register 2, monitoring register 6 and/or the transaction register 4 and used for further validity checks in the payment system BZ. This could improve the detection of cases of fraud or manipulation in the payment system BZ by the payment system BZ itself; a request by the authorities (court order) may then not be necessary.
[0446] The measures described here for pseudonymising or anonymising a TDS to obtain a pseudonymised TDS* or an anonymised TDS* can also be used for anonymising or pseudonymising register data sets RDS to obtain a pseudonymised RDS* or an anonymised RDS*.
[0447] Thus, according to the invention, different anonymity levels are provided for the RDS and the TDS. These anonymity levels may comprise, for example, 3 levels, such as level 1 (anonymous), level 2 (pseudonymous) and level 3 (open, non-anonymous, personalised). These levels can be set in the coin register 2 and/or the transaction register 4. These levels can be system requirements to be able to track coin data sets C without (or to be able to track) identities/amounts.
[0448] These anonymity levels apply in particular to the data element “participant identifier of the TE” in the respective RDS or TDS. Thus, each TDS or RDS can be either identity anonymous, identity pseudonymous and identity open. These anonymity levels apply in particular to the data element “monetary amount of coin data set C” in the respective RDS or TDS. Thus, each TDS or RDS can be either amount anonymous, amount pseudonymous and amount open.
[0449] These anonymity levels may vary within the RDS or TDS for different data elements. In addition, the anonymity level of a participant identifier (identity) may be different from an anonymity level of a monetary amount. Preferably, the anonymity levels of a participant identifier (identity) is less than from an anonymity level of a monetary amount to protect the identity of the participant in priority to the payment amount.
[0450] Preferably, the TDS for the participant identifier and/or monetary amount have a lower anonymity level than the RDS.
[0451] Amount-neutral register changes can also be made, whereby at least one RDS of an already registered coin data set is replaced in the coin register 2 by at least one RDS of a coin data set to be registered. Thus, the coin register 2 will only have RDS to electronic coin data sets currently available in the payment system BZ.
[0452]
[0453] The public key part K is derived from the private key part k and provided to the participant unit TE. The re-encryption step 303 in
[0454] Before using the private key part k to decrypt the stored encrypted transaction data set TDS, the subset or all remote instances must authenticate themselves to the transaction register 4. If authentication is successful, the transaction data set TDS is decrypted using the private key part k.
[0455] The generated transaction data set consisting of, for example, a transaction number, a recipient address (here from TE2), a sender address (here from TE1) and a monetary amount of the eMD C. The generated transaction data set may also be used in TE1 to log the transmitting 105 to perform a reverse transaction (ROLLBACK) or a repetition (RETRY) of the transmitting 105 in the event of a transmitting error.
[0456]
[0457]
[0458] The coin register 2 contains a register 210 in which only valid masked electronic coin data set Z.sub.i is stored. The electronic coin data set C.sub.i represents a monetary amount ν.sub.i. The electronic coin data set C.sub.i is output to a first terminal M1. Electronic coin data sets C.sub.i, preferably for which a masked electronic coin data set Z.sub.i is registered, can be used for payment. The masked electronic coin data set Z.sub.i can also be referred to as an amount-masked electronic coin data set, since the monetary amount ν.sub.i for the coin register 2 is unknown (and also remains unknown in the further course). A receiver, here for example a second terminal M2, of the electronic coin data set C.sub.i can check its validity with the help of the coin register 2. The coin register 2 can confirm the validity of the electronic coin data set C.sub.i with the help of the masked electronic coin data set Z.sub.i. For the coin register 2, the masked electronic coin data set Z.sub.i is an anonymous electronic coin data set, especially since it does not know an owner of the associated electronic coin data set C. The anonymity level of a masked coin data set Z.sub.i in the register 201 of the coin register 2 is therefore level 1 (completely anonymous).
[0459]
[0460] The coin register 2 stores in the register 210 anonymous (amount) masked coin data sets Z.sub.i of electronic coin data sets C of the issuing instance 1 or of modified electronic coin data sets of the terminals M.
[0461]
[0462] The pseudonym P can be a derivative of the above-mentioned participant unit identifier. The pseudonym P may additionally be listed in the personal identifier 7 of the issuing instance 1 (or alternatively of a service provider, e.g. a wallet application provider or an online storage provider) next to the participant unit identifier. To protect the natural person, the pseudonym P can only be assigned to a natural person in a trusted instance, if applicable.
[0463] The monitoring register 6 processes the pseudonymously sent masked electronic coin data set S a pseudonymous mode 2p, in which it is also confirmed to the second terminal M2 that the sent masked electronic coin data set Z.sub.i* is valid. However, the assignment of the masked electronic coin data set Z.sub.i to the pseudonym PM 2 is additionally stored in a data structure 220 of the monitoring register 6. As will become clear in the further embodiments, the data structure 220 can be used as a register for masked electronic coin data sets Z.sub.i still to be checked, i.e. it can also fulfil the function of a coin register 2. In pseudonymous mode 2p, the monitoring register 6 postpones or skips, in particular, a checking step performed in anonymous mode 2a (more frequently or always). In the checking step, it is checked—preferably further in ignorance of the monetary amount ν.sub.i—whether the monetary amount ν.sub.i of the masked electronic coin data set Z.sub.i is within a range.
[0464] The aspects described below are based at least in part on details of this embodiment of
[0465]
[0466] Each processing operation for a processing (creating, deactivating, splitting, connecting and switching) is registered in the coin register 2 and appended there, for example in unchangeable form, to a list of previous processing operations for masked electronic coin data sets Z.sub.i. The individual operations and their check results, i.e. the intermediate results of a processing operation, are recorded in the coin register 2. Although a continuous list is assumed in the following, this data structure can also be cleaned or compressed, if necessary according to predetermined rules, or provided separately in a cleaned or compressed form.
[0467] The processing operations “creating” and “deactivating”, which concern the existence of the monetary amount ν.sub.i, per se, i.e. imply the creation and the destruction of money, require an additional authorisation by the issuing instance 1 to be registered (i.e. logged) in the coin register 2 and/or the monitoring register 6. The remaining processing operations (splitting, connecting, switching) do not require authorisation by the issuing instance 1 or by the command initiator (=payer, e.g. the first terminal M1). However, the other processing operations must be checked with regard to various check criteria.
[0468] A registration of the respective processing is realised, for example, by corresponding list entries in the database according to
[0469] For anonymous coin data sets, all checks must always be executed, so that all flags 25-28 could also be discarded. For pseudonymised coin data sets, on the other hand, a check can be omitted or executed later.
[0470] In
[0471] An optional flag 29 can, for example, display the completion of processing. The flags 29 are in the state when a processing command is received, for example, and are set to the state “1” after all checks have been successfully completed (for flags 25-28) and are set to the state “0” if at least one check has failed. A (completion) flag 29 with the value “2” could display, for example, that only the necessary examinations were completed and that examinations that could be made up for were omitted. If checks for one or more entries are later made up by the terminal with the pseudonym, the flag can be set to the value “1”. Instead of using the completion flag 29 in this way, the flags 27b and 27c of the checks to be made up could of course also be used and/or a separate pseudonym flag could be used.
[0472] For example, a possible structure for a list entry of a coin data set comprises two columns 22a, 22b for a predecessor coin data set (O1, 02), two columns 23a, 23b for a successor coin data set (S1, S2), a signature column 24 for signatures of issuing entity (issuing entities) 1 and signatures of terminals M, and six marker columns 25, 26, 27a, 27b and 27c and 28. Each of the entries in columns 25 to 28 has three alternative states “−”, “1” or “0”.
[0473] Column 25 (O flag) displays whether a validation check was successful with regard to a predecessor electronic coin data set in column 22a/b. The “1” state indicates that a validity check revealed that the electronic coin data set of column 22a/b is valid and the “0” state indicates that a validity check revealed that the electronic coin data set of column 22a/b is invalid and the state “−” indicates that a validity check has not yet been completed. For multiple predecessor coin data sets, it is preferred to use a common O flag (both valid) rather than two separate O flags. Column 26 (C flag) displays whether an initial check calculation was successful for the masked electronic coin data sets. The first check calculation checks in particular whether the command is amount-neutral, i.e. primarily that the sum of the monetary amounts involved is zero. The state “1” means that a calculation was successful and the state “0” indicates that calculation was not successful and the state “−” displays that a calculation has not yet been completed.
[0474] For example, the calculation to be performed in column 26 is:
(Z.sub.O1+Z.sub.O2)−(Z.sub.S1+Z.sub.S2)==0 (10)
[0475] Column 27a (R1 flag) displays whether a first check of a range proof or the range proof was successful. The same applies to the other columns 27b (R2 flag) and 27c (R3 flag). The state “1” means that a validity check showed that the range proofs or the range evidence could or could not be retraced and the state “0” indicates that a validity check showed that the range proofs or the range evidence could not or could not be retraced and the state “−” indicates that a validity check is not yet completed, was not successful. The first range proof of column 27a is always necessary for the coin data set(s) to be considered valid. A typical example of a necessary check is the check that the monetary amount is not negative (or none of the monetary amounts are negative). The second and third range proofs do not affect the validity of the coin data set and can be made up for pseudonymised masked coin data sets, for example in a later transaction of the pseudonym. The range proof of column 27b is used to check whether the monetary amount of the masked coin data set (or each coin data set) is below a maximum amount. The maximum amount can be pre-determined system-wide or for specific terminal types. For example, the range proof of column 27c compares a sum of monetary amounts (sent or) received by the participant unit TE in a specified time period, such as 24 hours, against a sum limit, or checks, for example, a transaction count per time period for the participant unit TE, such as a maximum of 5 per minute or 100 per day. The limit values can be predefined by the payment system BZ system-wide or defined for specific participant unit types (i.e. participant unit-specific). For example, a coffee machine of type X can only dispense four portions of hot drinks per minute due to the device and accordingly only four coin transactions per minute are permitted.
[0476] The column 28 (S flag) displays whether a signature of the electronic coin data set matches the signature of column 24, where state “1” indicates that a validity check revealed that the signature could be identified as that of the issuing instance and state “0” indicates that a validity check revealed that the signature could not be identified as that of the issuing instance and the state “−” indicates that a validity check has not yet been completed.
[0477] A change in the status of one of the flags (also referred to as a “flag”) requires authorisation by the coin register 2 and/or the monitoring register 6 and must then be stored unalterably in the data structure of
[0478] In the following, a data structure without completion flag 29 is assumed and the validity of anonymous coin data sets is considered first. In order to determine whether a masked electronic coin data set Z is valid, the coin register 2 searches for the last change affecting the masked electronic coin data set Z. The coin register 2 then checks whether the masked electronic coin data set Z is valid. It holds that the masked electronic coin data set Z is valid if the masked electronic coin data set Z is listed for its last processing in one of the successor columns 23a, 23b, if and only if that last processing has the corresponding final flag 25 to 28. It also applies that the masked electronic coin data set Z is valid, provided that the masked electronic coin data set Z is listed for its last processing in one of the predecessor columns 22a, 22b, if and only if this last processing has failed, i.e. at least one of the corresponding required states of the flags 25 to 28 is set to “0”.
[0479] If the masked electronic coin data set Z is not found in the coin register 2, it is invalid. It is also true that the anonymous masked electronic coin data set Z is not valid for all other cases. For example, if the last processing of the masked electronic coin data set Z is listed in one of the successor columns 23a, 23b, but this last processing never became final, or if the last processing of the masked electronic coin data set Z is in one of the predecessor columns 22a, 22b and this last processing is final.
[0480] The checks made by coin register 2 and/or monitoring register 6 to determine whether a processing is final are represented by columns 25 to 28: The state in column 25 displays whether the masked electronic coin data set(s) are valid according to predecessor columns 22a, 22b. The state in column 26 indicates whether the calculation of the masked electronic coin data set according to equation (10) is correct. The state in column 27a indicates whether the range checks for the masked electronic coin data set Z could be successfully verified. The state in column 28 indicates whether the signature in column 24 of the masked electronic coin data set Z is a valid signature of issuing instance 1.
[0481] The state “0” in a column 25 to 28 thereby displays that the verification was not successful. The status “1” in a column 25 to 28 indicates that the verification was successful. The state “−” in a column 25 to 28 displays that no check was carried out. The states can also have a different value, as long as a clear distinction can be made between success/failure of a check and it is evident whether a determining check was carried out.
[0482] As an example, five different processes are defined, which are explained in detail here. Reference is made to the corresponding list entry in
[0483] For example, one processing is “generating” an electronic coin data set C.sub.i. Generating in the direct transaction layer 3 by the issuing instance 1 involves selecting a monetary amount ν.sub.i and creating an obfuscation amount r.sub.i, as described earlier with equation (1). As shown in
[0484] For example, one processing is “deactivate”. The deactivating, i.e. destroying money, causes the masked electronic coin data set Z.sub.i to become invalid after successful executing of the deactivate command by the issuing instance 1. One can therefore no longer process the (masked) electronic coin data set to be deactivated in the coin register 2 and/or in the monitoring register 6. To avoid confusion, the corresponding (non-masked) electronic coin data sets C.sub.i should also be deactivated in the direct transaction layer 3. When “deactivating”, the predecessor column 22a is written to with the electronic coin data set Z.sub.i, but no successor column 23a, 23b is occupied. The masked electronic coin data set Z.sub.i shall be checked during deactivation to ensure that the signature matches the signature according to column 24 to ensure that the electronic coin data set C.sub.i has indeed been created by an issuing instance 1, again other means may be used for this check. If the signed Z.sub.i sent in the deactivate command can be confirmed as signed by issuing instance 1, flag 28 is set (from “0” to “1”). The flags according to columns 26 to 27 do not require a status change and can be ignored. The flags according to columns 25 and 28 are set after appropriate verification.
[0485] A processing (modification) is, for example, “splitting”. Splitting, i.e. dividing an electronic coin data set Z.sub.i into a number n, for example 2, of electronic coin data sets Z.sub.j and Z.sub.k is first carried out in the direct transaction layer 3, as still shown in
[0486] For example, one processing is “connecting”. Connecting, i.e. merging, two electronic coin data sets Z.sub.i and Z.sub.j into one electronic coin data set Z.sub.m is first performed in the direct transaction layer 3, as still shown in
[0487] Another processing is, for example, “switching”. Switching is necessary when an electronic coin data set has been transmitted to another participant unit TE and re-issuing by the transmitting participant unit TE is to be prevented. During switching, the electronic coin data set C.sub.k obtained from the first participant unit TE1 is exchanged for a new electronic coin data set C.sub.i with the same monetary amount. The new electronic coin data set C.sub.i is generated by the second participant unit TE2. This switching is necessary to invalidate (invalidate) the electronic coin data set C.sub.k obtained from the first participant unit TE2, thus avoiding re-issuing the same electronic coin data set C.sub.k. This is because, as long as the electronic coin data set C.sub.k is not switched, since the first participant unit TE1 is aware of the electronic coin data set C.sub.k, the first participant unit TE1 can pass this electronic coin data set C.sub.k to a third participant unit TE. The switching is done, for example, by adding a new obfuscation amount r.sub.add to the obfuscation amount r.sub.k of the obtained electronic coin data set C.sub.k, thereby obtaining an obfuscation amount r.sub.i that only the second participant unit TE2 knows. This can also be done in the coin register 2 or the monitoring register 6. To prove that only a new obfuscation amount r.sub.add has been added to the obfuscation amount r.sub.k of the masked obtained electronic coin data set Z.sub.k, but the monetary amount has remained the same, and thus equation (11):
ν.sub.k=ν.sub.l (11)
holds, the second participant unit TE2 must be able to prove that Z.sub.l-Z.sub.k can be represented as a scalar multiple of G, i.e. as r.sub.add*G. This means that only one obfuscation amount r.sub.add has been generated and the monetary amount of Z.sub.l is equal to the monetary amount of Z.sub.k, i.e. Z.sub.l=Z.sub.k+r.sub.add*G. This is done by generating a signature with the public key Z.sub.l-Z.sub.k=r.sub.add*G.
[0488] The modifications “splitting” and “connecting” to an electronic coin data set can also be delegated from one participant unit TE1 to another participant unit TE, for example if a communication link to the coin register 2 and/or to the monitoring register 6 is not available.
[0489]
ν.sub.i=ν.sub.k (12)
[0490] Each of the obtained amounts ν.sub.j, ν.sub.k, must be greater than 0, because negative monetary amounts are not permitted.
[0491] In a preferred embodiment, the monetary amount ν.sub.i is split symmetrically into a number n of equally large partial monetary amounts ν.sub.j.
ν.sub.j=ν.sub.i/n (12a)
[0492] The number n is an integer greater than or equal to two. For example, a monetary amount of 10 units can be split into 2 partial amounts of 5 units (n=2) or into 5 partial amounts of 2 units each (n=5) or 10 partial amounts of one unit each (n=10).
[0493] In addition, new obfuscation amounts are derived:
r.sub.i=r.sub.j+r.sub.k (13)
[0494] When symmetrically splitting, an individual unique obfuscation amount r.sub.j is formed in participant unit TE1 for each coin partial amount, where the sum of the number n of obfuscation amounts r.sub.j of the coin data sets is equal to the obfuscation amount r.sub.i of the split coin data set:
r.sub.i=Σ.sub.k=1.sup.nr.sub.j_k (13a)
[0495] In particular, the last obfuscation partial amount r.sub.j_n is equal to the difference between the obfuscation amount r.sub.i and the sum of the remaining obfuscation partial amounts:
r.sub.j_n=r.sub.i−Σ.sub.k=1.sup.n-1r.sub.j_k (13b)
[0496] In this way, the obfuscation amounts r.sub.j_1 to r.sub.j_n-1 can be chosen arbitrarily and the rule of equation (13a) is satisfied by calculating the “last” individual obfuscation amount r.sub.j_n accordingly.
[0497] For asymmetric splitting, masked coin data sets Z.sub.j and Z.sub.k are obtained from coin data sets C.sub.j and C.sub.k according to equation (3) and registered in coin register 2 and/or monitoring register 6. For splitting, the predecessor column 22a is described by the coin data set Z.sub.i, the successor column 23a by Z.sub.j and the successor column 23b by Z.sub.k. Additional information for the range proof (zero-knowledge-proof) is to be generated. The flags in columns 25 to 27 require status change and the coin register 2 and/or the monitoring register 6 performs the corresponding checks. The flag according to column 28 and the status according to column 29 are ignored.
[0498] In the case of symmetrical splitting, a signature is calculated in the respective participant unit TE. For this purpose, the following signature key sig is used for the kth coin part record C.sub.j_k:
sig=r.sub.i−n.Math.r.sub.j_k (13c)
[0499] Where n is the number of symmetrically split coin part records. In the case of symmetrical splitting, the signature of the k.sup.th coinage record C.sub.j_k can be verified according to (13c) with the following verification key Sig:
Sig=Z.sub.i−n.Math.Z.sub.j_k (13d)
[0500] Where Z.sub.j_k is the masked kth coin part record and n is the number of symmetrically split coin part records. This simplification results from the relationship with equation (3):
Z.sub.i−n.Math.Z.sub.j_k=(ν.sub.i−n.Math.ν.sub.j_k).Math.H|(r.sub.l−n.Math.r.sub.j_k).Math.G (13e)
where, due to the symmetry properties of splitting, the following applies:
(ν.sub.i−n.Math.ν.sub.j_k).Math.H=0 (13f)
so that equation 13e is simplified to:
Z.sub.i−n.Math.Z.sub.j_k=(r.sub.i−n.Math.r.sub.j_k).Math.G (13g)
[0501] The simplification due to equation 13f makes it possible to completely dispense with zero-knowledge proofs, whereby the application of symmetrical splitting saves enormous computing power and data volume. Then, a coinage data set, here C.sub.k is transmitted from the first participant unit TE1 to the second participant unit TE2. To prevent double spending, a switching operation is useful to exchange the electronic coin data set C.sub.k obtained from the first participant unit TE1 for a new electronic coin data set C.sub.l with the same monetary amount. The new electronic coin data set C.sub.l is generated by the second participant unit TE2. The monetary amount of the coin data set C.sub.l is taken over and not changed, see equation (11).
[0502] Then, according to equation (14), a new obfuscation amount r.sub.add is added to the obfuscation amount r.sub.k of the obtained electronic coin data set C.sub.k,
r.sub.l=r.sub.k+r.sub.add (14)
thereby obtaining an obfuscation amount r.sub.i known only to the second participant unit TE2. In order to prove that only a new obfuscation amount r.sub.add has been added to the obfuscation amount r.sub.k of the obtaining electronic coin data set Z.sub.k, but that the monetary amount has remained the same (ν.sub.k=ν.sub.l), the second participant unit TE2 must be able to prove that Z.sub.l-Z.sub.k can be represented as a multiple of G. This is done by means of public signature r.sub.add according to equation (15):
where C.sub.i is the generator point of the ECC. Then the coin data set C.sub.l to be switched is masked using equation (3) to obtain the masked coin data set Z.sub.i. In the coin register 2 and/or the monitoring register 6, the private signature r.sub.add can then be used to sign, for example, the masked to-be-switched electronic coin data set Z.sub.l, which is taken as proof that the second participant unit TE2 has only added an obfuscation amount r.sub.add to the masked electronic coin data set and no additional monetary value, i.e. ν.sub.l=ν.sub.k.
[0503] The proof is as follows:
[0504]
[0505] When combined by the payment system BZ, the highest of the two individual check values of the respective electronic coin records C.sub.i and C.sub.j is determined. This highest check value is taken as the check value C.sub.i and C.sub.j of the combined electronic coin data set.
[0506] Alternatively, when combining (=connecting) by a payment system BZ, a new check value is determined from the sum of all check values of the electronic coin data records C.sub.i and C.sub.j divided by the product of the number (here two) of coin data records C.sub.i and C.sub.j with a constant correction value. The correction value is constant for the payment system. Preferably, the correction value is greater than or equal to 1. Preferably, the correction value is dependent on a maximum deviation of the individual check values of the electronic coin data sets C.sub.i and C.sub.j or on a maximum check value of one of the electronic coin data sets C.sub.i and C. Further preferably, the correction value is less than or equal to 2. This new check value is adopted as the check value of the combined electronic coin data set C.sub.m.
[0507]
[0508] In the optional step 108, the switching of a obtained coin data set C.sub.k (of course, the obtained coin data set C.sub.i could also be switched) to a new coin data set C.sub.i is then carried out, whereby the coin data set C.sub.k becomes invalid and double spending is prevented. To do this, the monetary amount ν.sub.k—of the transmitted coin data set C.sub.k is used as the “new” monetary amount ν.sub.l. In addition, as already explained with equations (14) to (17), the obfuscation amount r.sub.i is created. The additional obfuscation amount r.sub.add is used to prove that no new money (in the form of a higher monetary amount) was generated by the second participant unit TE2. Then the masked coin data set is signed and the signed masked coin data set Z.sub.i to be switched is sent to the coin register 2 and/or the monitoring register 6 and the switching from C.sub.k to C.sub.l is instructed. In addition, a signature S.sub.k is created by the first participant unit TE1 or the second participant unit TE2 and stored in the coin register 2 and/or the monitoring register 6. In addition or alternatively, a signature S.sub.l could also be created and deposited in the coin register 2 and/or monitoring register 6 if sending participant units TE were registered instead of receiving participant units TE.
[0509] In step 108′, the corresponding check is made in coin register 2 and/or monitoring register 6, entering Z.sub.k in column 22a according to the table in
[0510] In optional step 109, connecting two coin data sets C.sub.k and C.sub.i to a new coin data set C.sub.m is performed, invalidating the coin data sets C.sub.k, C.sub.i preventing double spending. For this purpose, the monetary amount ν.sub.m is formed from the two monetary amounts ν.sub.k and ν.sub.i. For this purpose, the obfuscation amount r.sub.m is formed from the two obfuscation amounts r.sub.k and r.sub.i. In addition, the masked coin data set Z.sub.m to be connected is obtained by means of equation (3) and this is sent (together with other information) to the monitoring register 6 and/or the coin register 2 and connecting is requested as processing. In addition, a signature S.sub.k and a signature S.sub.i are generated and communicated to the monitoring register 6 and/or the coin register 2.
[0511] In step 109′, the corresponding check is made in the coin register 2 and/or the monitoring register 6. In the process, Z.sub.m is entered in column 23b according to the table in
[0512] In optional step 110, an asymmetric splitting of a coin data set C.sub.i into two coin data sets C.sub.k and is performed, whereby the coin data set C.sub.i is invalidated and the two asymmetrically split coin data sets C.sub.k and C.sub.j are to be made valid. In an asymmetric splitting, the monetary amount ν.sub.i is split into monetary partial amounts ν.sub.k and ν.sub.j of different sizes. For this purpose, the obfuscation amount r.sub.i is split into the two obfuscation amounts r.sub.k and r.sub.j. In addition, the masked coin data sets Z.sub.k and Z.sub.j are obtained by means of equation (3) and sent to the coin register 2 and/or the monitoring register 6 with further information, for example the range checks (zero-knowledge-proofs), and the splitting is requested as processing. In addition, a signature S.sub.i is created and sent to coin register 2 and/or monitoring register 6.
[0513] In step 110′, the corresponding check is made in coin register 2 and/or monitoring register 6, with 4 and Z.sub.k being entered in columns 23a/b according to the table in
[0514]
[0515] In one case, the electronic coin data set C.sub.i is shown as a printout on paper. In this case, the electronic coin data set may be represented by a QR code, an image of a QR code, or may be a file or a string of characters (ASCII).
[0516] The device M1 has at least one interface 12 available as a communication channel for outputting the coin data set C.sub.i. This interface 12 is for example an optical interface, for example for displaying the coin data set C.sub.i on a display unit (display), or a printer for printing out the electronic coin data set C.sub.i as a paper printout. This interface 12 can also be a digital communication interface, for example for near field communication, such as NFC, Bluetooth, or an internet-enabled interface, such as TCP, IP, UDP, HTTP or accessing a smart card as a security element. For example, this interface 12 is a data interface such that the coin data set C.sub.i is transmitted between devices via an application, such as an instant messenger service, or as a file or string.
[0517] In addition, the interface 12 or another interface (not shown) of the device M1 is arranged to interact with the coin register 4. The device M1 is preferably online capable for this purpose.
[0518] In addition, the device M1 may also have an interface for receiving electronic coin data sets. This interface is arranged to receive visually presented coin data sets, for example by means of a capture module such as a camera or scanner, or digitally presented coin data sets, received via NFC, Bluetooth, TCP, IP, UDP, HTTP or coin data sets presented by means of an application.
[0519] The device M1 also comprises a computing unit 13 capable of performing the coin data set masking method and coin data set processing operations described above.
[0520] The device M1 is online capable and can preferably detect when it is connecting to a WLAN by means of a location detection module 15. Optionally, a specific WLAN network can be marked as preferred (=location zone) so that the device M1 executes special functions only if it is logged into this WLAN network. Alternatively, the location detection module 15 detects when the device M1 is in predefined GPS coordinates including a defined radius and performs the special functions according to the location zone thus defined. This location zone can be inserted into the unit M1 either manually or via other units/modules. The special functions that the device M1 performs when the location zone is detected are, in particular, transmitting electronic coin data sets from/to the external data memory 10 from/to a safe module 14 and, if necessary, transmitting masked coin data sets Z to the coin register 4 and/or the monitoring register 6, for example as part of the above-mentioned processing operations on a coin data set. The device M1 is thus arranged to execute the method according to
[0521] In the simplest case, all coin data sets C.sub.i are automatically connected to a coin data set in the device M1 after obtaining (see connecting-processing or connecting-step). That is, as soon as a new electronic coin data set is received, a connecting or switching command is sent to the coin register 4. The device M1 can also prepare electronic coin data sets in algorithmically defined denominations and hold them in the data memory 10, 10′ so that a payment process is possible even without a data connection to the coin register 4 and/or monitoring register 6.
[0522]
[0523] In addition, in
[0524] In
[0525] In the upper part of the figure, the payment system BZ consisting of three terminals M1, M2, M3 is shown. In the lower part of the figure three data structures 910, 920, 930 of the respective registers 2, 4, 6 are shown. The valid masked coin data sets Z.sub.i are stored in the data structure 910 of the coin register 2. The data structure 920 of the monitoring register 6 comprises the assignment of pseudonymously sent masked coin data sets to the pseudonym and of can be considered as monitoring register 6 still to be checked pseudonymously sent coin data sets. Based on the data in data structure 920, monitoring register 6 can decide whether a range proof is requested for a pseudonym. Encrypted transaction data sets TDS are stored in the transaction register data structure 930.
[0526] The following transactions were performed:
[0527] 1. The first terminal M1 has split a coin 901. the coin register 2 therefore knows that the coin C is a result of this splitting and stores the masked coin data set Z.sub.i in the data structure 910. the first terminal M1 could send the split to the monitoring register 6 anonymously or pseudonymously. In the illustration, it is assumed that terminals M1 and M3 send their masked coin data sets to monitoring register 6 anonymously.
[0528] 2. The first terminal M1 sends the coin C.sub.1 directly to the second terminal M2 in a direct transmission step 902. Neither the coin register 2 nor the monitoring register 6 obtain any information about this. The first terminal M1 generates a transaction data set TDS.sub.902 relating to the transmission step 902, encrypts this transaction data set TDS.sub.902 and sends it to the transaction register 4. The encrypted transaction data set TDS.sub.902 contains an identifier of the first terminal M1, an identifier of the second terminal M2 and the monetary amount ν.sub.i of the coin C.sub.1.
[0529] 3. The second terminal M2 converts (switches) 903 the coin C.sub.1 to the coin C.sub.2. The new masked coin data set Z.sub.2 is stored in the data structure 910 of the coin register 2 and the old masked coin data set Z.sub.1 is deleted (or marked as invalid). The second terminal M2 sends its masked (or at least the represented) coin data sets pseudonymised to the monitoring register 6. Thus, the monitoring register 6 also obtains the information that the second terminal M2 with the pseudonym P.sub.M2 has received the coin C.sub.1 (and now possesses coin C.sub.2) and accordingly stores in the data structure 920 of the monitoring register 6 the masked coin data set Z.sub.2 (and/or the masked coin data set Z.sub.1) for P.sub.M2. In addition, the monitoring register 6 will skip at least one verification step, such as a range proof for the coin data set Z.sub.2 or a sum range proof for the terminal M2.
[0530] 4. The second terminal M2 sends the coin C.sub.2 to the third terminal M3 in another direct transmission step 905. Neither the coin register 2 nor the monitoring register 6 obtains any information about this. The second terminal M2 generates a transaction data set TDS.sub.905 relating to the transmission step 905, encrypting this transaction data set TDS.sub.905 and sending it to the transaction register 4. The encrypted transaction data set TDS.sub.905 includes an identifier of the second terminal M2, an identifier of the third terminal M3, and the monetary amount ν.sub.2 of the coin C.sub.2.
[0531] 5. In step 904, the third terminal M3 connects the received coin C.sub.2 to the connected coin C.sub.3 and sends this information with anonymous masked coin data sets to the coin register 2. The coin register 2 executes all verification steps, i.e. in particular all range proofs for the involved masked coin data sets Z.sub.2 . . . and Z.sub.3 or also a sum range proof for the third terminal M3. The coin register 2 only then deletes the masked coin data set Z.sub.2 (as well as the other coin data sets of the operation) from the data structure 910 and stores the new masked coin data set Z.sub.3 as a valid masked coin data set.
[0532] 6. The third terminal M3 sends the coin C.sub.3 directly to the second terminal M2 in step 906. Neither the coin register 2 nor the monitoring register 6 obtains any information about this. The third terminal M3 generates a transaction data set TDS.sub.906 relating to the transmitting step 906, encrypting this transaction data set TDS.sub.906 and sending it to the transaction register 4. The encrypted transaction data set TDS.sub.906 includes an identifier of the third terminal M3, an identifier of the second terminal M2 and the monetary amount ν.sub.3 of the coin C.sub.3.
[0533] 7. In a further step 903, the second terminal M2 converts (switches) the coin C.sub.3 to the coin C.sub.4 and sends a masked coin data set Z.sub.4 together with its pseudonym to the monitoring register 6. The monitoring register 6 obtains the information and performs the necessary checks. Using the data structure 920, the monitoring register 6 determines whether one or more checks should now be made up for the pseudonym of the terminal M2. If the criterion for a catching up, such as time lapse or number of transactions for a pseudonym, is not yet fulfilled, only the further masked coin data set Z.sub.4 for the pseudonym is noted in the data structure 920 of the monitoring register 6. The coin register 2 stores the masked coin data set Z.sub.4 in the data structure 910 and deletes the masked coin data set Z.sub.3 there. If, on the other hand, a criterion for catching up on the verification step is fulfilled, it first executes the catching up of the verification step (or its equivalent).
[0534] In the concrete example, the monitoring register 6 has the information that the second terminal M2 had the coin C.sub.2 (see step 3). Since the sum of the monetary amounts of coin C.sub.2 and coin C.sub.4 could exceed a coin threshold, monitoring register 6 requests a sum range proof (or sum range confirmation) from the second terminal M2. The sum range proof shows that the sum of the monetary amounts of coins C.sub.2 and C.sub.4 does not yet exceed the—for example daily—limit of transactions for the second terminal M2. The monitoring register 6 can also monitor a limit for a time-independent number of transactions (range proof after Mar. 5, 2010/ . . . transactions). As an alternative or in addition to a cumulative check of several coin data sets, the monitoring register 6 can make up a range check for the individual coin data sets associated with the pseudonym P.sub.M2 in the data structure 920 of the monitoring register 6 (Is the monetary amount of each coin data set Z.sub.2 and Z.sub.4 less than X?). If checks have been successfully made up, the corresponding records in the data structure 920 of the monitoring register 6 can also be deleted.
[0535] The transaction register 4 has the transaction data sets TDS.sub.902, TDS.sub.905 and TDS.sub.906 in encrypted form in its data structure 930.
[0536] In an embodiment not shown in
[0537]
[0538] The coin register 2 responds to each of the anonymous sending steps 151 of the first terminal M1 (in its anonymous mode) with a (catch-up) check for the masked coin data set or the first terminal M1. The additional necessary checks, if any, are not shown in
[0539] The monitoring register 6 responds to the first transmitting step 161 of the second terminal M2 (in its pseudonymous mode) by skipping a (catch-up) check for the masked coin data set or the second terminal M2. The pseudonymously sent masked coin data set is registered as valid. For example, necessary checks not shown here take place, but do not require further communication with the second terminal M2. As previously described in other examples, the monitoring register 6 stores a mapping between the pseudonym and the masked coin data set(s) sent pseudonymously. In the example shown, the monitoring register 6 also responds in an analogous manner to a second (or further) transmission steps 161 of the second terminal M2. In each case, it checks for the pseudonym whether a catch-up criterion is fulfilled.
[0540] Only in the third step 161 shown does the monitoring register 6 determine that a check is to be made up for the pseudonym. It sends a request 162 to the second terminal M2 to create, for example, range proofs for multiple coin data sets or a sum range proof. In step 163, the second terminal M2 creates a plurality of range proofs, a sum range proof or a sum range confirmation and sends them to the monitoring register 6 in step 164. In step 163, for example, a plurality of coin data sets of the second terminal M2 are selected and summed over their monetary amounts. These coin data sets concern either only pseudonymised coin data sets or anonymous and pseudonymised coin data sets (in this case, the masked coin data sets that have already been sent are used and the sum is formed from the monetary amounts of the corresponding unmasked coin data sets). The selection can be made on the basis of criteria that are either known to the system or transmitted from the monitoring register 6 in step 162. The criteria are, for example, a period of time, in particular a predefined period of time in which a sum of all monetary amounts should/must not exceed a certain range, for example a monetary amount x euros per time unit y. The criterion can alternatively or additionally be a list in the first terminal M1 or the monitoring register 6. This makes a certain randomisation of the range possible, with which the system is further secured. The sum formed is then matched against the range (and using the criterion if applicable). In step 164, the requested sum range confirmation (or requested sum range proof) is transmitted from the second terminal M2 to the monitoring register 6.
[0541] Since a payment transaction (transmitting coin data sets) of a large monetary amount can also be split into several payment transactions of smaller monetary amounts, each of which could be below a range, the method defines the range (=limit), if necessary, on a terminal-specific and time period-dependent basis. The range usually concerns a sum of all transactions within a determining time unit that are received and/or sent by a terminal. A mechanism is therefore provided for determining what the sum of all monetary amounts sent or received by a terminal is within a determined unit of time.
[0542] Within the scope of the invention, all elements described and/or drawn and/or claimed may be combined with each other as desired.