WO2013140196A1

WO2013140196A1 - A system for electronic payments with privacy enhancement via trusted third parties

Info

Publication number: WO2013140196A1
Application number: PCT/IB2012/000587
Authority: WO
Inventors: Dimitar JETCHEV; Apostol Vassilev
Original assignee: Jetchev Dimitar; Apostol Vassilev
Priority date: 2012-03-23
Filing date: 2012-03-23
Publication date: 2013-09-26

Abstract

A method for electronic payments with privacy enhancements comprising one or more mobile phone operators, one or more financial entities holding user cash deposits (e.g., banks, credit unions, electronic payment providers, etc), one or more trusted parties, one or more merchants with one or more sale terminals, and one or more users with mobile web- enabled phone with a SIM card or Near Field Communication chip communicating over a network using a variety of cryptographic confidentiality, authentication, and privacy methods. Users pay for goods and services over the Internet or at conventional stores using their mobile phones supported by the secure SIM card or Near Field Communication chip without revealing any personal payment information that is not directly relevant for the transaction to any of the non-trusted parties. The SIM cards or Near Field Communication chips do not reveal any information to the terminal or to the financial entity holding the user cash account or any information to which the terminal or the financial entity should not have access. The system allows configuration of different types of cryptographic methods or hardware components to allow proper balancing of the performance of any specific implementation by assigning heavier computational load to more capable components and reducing the load on the less-powerful SIM cards or Near Field Communication chips while maintaining strong security and privacy guarantees. The system is resilient to connection breakdowns and allows users and merchants to recover gracefully from such service disruptions without the need to maintain complex transaction state on the SIM card or on the Near Field Communication chip and without financial losses to any of the parties involved. The system and protocols can also be configured for electronic cash payments with smart cards on the Internet or at conventional merchant sale terminals.

Description

A SYSTEM FOR ELECTRONIC PAYMENTS WITH PRIVACY

ENHANCEMENT VIA TRUSTED THIRD PARTIES

This invention relates to methods for electronic payments, and more specifically to a method for performing secure electronic payment with privacy enhancements.

Prior art methods and protocols were designed for electronic payments with privacy enhancements. One problem with these protocols is the need for live communication between the user who wants to pay to a merchant at the point-of-sale terminal POS and the payment provider that manages the payment services. This requirement can put heavy constraints on end-user devices with limited connectivity such as mobile handheld platforms.

In addition, the reimbursement of the merchant by the payment provider in most of these protocols is usually done simultaneously when the merchant delivers the goods or services to the user. This information may be used to correlate withdrawal amounts and reimbursement amounts. For instance, the merchant usually waits to receive the money from the payment provider before delivering the purchased goods or services. The existing algorithms guarantee that a third-party observer or the merchant cannot discover the identity of the user U. However, any party that has access to the back-end facilities of the payment provider can look at the incoming withdrawal requests and the subsequent reimbursement requests and try to correlate them by amount and time. In practice, using a simple technique like this may reveal the identity of the user or at least narrow down the possibilities to a few choices. Thus, most of the existing electronic payments systems are far from being equivalent to real cash transactions in term of privacy. In contrast, when a user withdraws cash from her bank account at an automatic cash machine, the only information that the bank knows is that the user made a withdrawal of a certain amount at a certain time. The bank cannot tell how the user is spending the cash and in addition, the corresponding merchants that the user deals with cannot tell his identity.

Another problem with the prior art methods and protocols that store electronic money on a security module such as a SIM card, a smart card or a Near field Communication card is the order of deducing the amount of electronic cash and the merchant verification of a generated electronic token or receipt. There are protocols that reduce the amount of electronic cash from the security module prior to the merchant verifying the generated electronic token or receipt. One problem with such schemes is that in the case of a dishonest merchant or in the case of a problem with the validation tool when the merchant cannot confirm a properly generated token, one may not be able to restore the original amount on the security module even if the payment has been refused. This usually leads to schemes that may not be fully compliant with current payment standards and protocols.

Some of the prior art electronic payment schemes are designed to integrate the existing EMV financial protocols and as such, they rely on explicit communication between the user who pays and the payment provider at the time of the transaction. The present invention proposes an electronic payment method with privacy enhancements for which there are no need for such a direct link between the user and the payment provider at the time of the transaction. Moreover, this solution allows for a trusted third party in such a way that trust is transferred from the payment provider to the trusted third party.

Finally, all prior art protocols that involve a financial back-end server and a smart card require complex financial transaction state management that render them unusable for the unstable environment of the roaming mobile user we consider.

In the present application there is disclosed a new method for performing secure electronic payments with privacy enhancements without the need for live

— communication-between- the user and the payment-pro vider^_or the-merchant-and- the- payment provider in order to complete a transaction of payment for goods or services. The method allows for the use of a secure database maintained and accessed by a trusted third party such as an Escrow service so that trust is transferred from the payment provider to the trusted third party.

For the sake of clarity, the following definitions will be used in the present application. A security module is a tamper-resistant hardware token with a cryptographically- enabled CPU that is designed to securely store and withstand attacks on the data contained within. Smart cards, SIM cards for GSM mobile telephony as well as Near Field Communication (NFC) chips are examples of such security modules. There are other types of security modules based on different technologies for ensuring tamper- resistance and security. Although we will mainly refer to NFC chips in the specifications below, the method can be used with other types of security modules and the corresponding protocols can be configured accordingly.

A personal secure device is any personal device incorporating a security module. This could be, for instance, a hand-held device such as a mobile phone, a smart phone or a smart card. Although we mainly refer to mobile phones in the specification, the method can be used with other types of personal secure devices as well and the corresponding protocols can be configured accordingly.

A secure database is a database maintained by the trusted third party whose records may contain personal information about the users as well as information related to the amount of the user outstanding electronic cash together with other cryptographic data specific to the user. Certain data from the database might be accessed by parties that are not fully trusted via the trusted third party, but at no time, such a party can access data by specifying any personal information about the user. In other words, parties that are not fully trusted should not be able to access data that could compromise the identity of a user. For instance, if the trusted third party associates a random identifier to a given user, a non-trusted party that specifies this identifier can be given access to certain data corresponding to the identifier as long as this data does not reveal any information-about-the identity of the user associated^"with^"this^{" "}entffief.^"

Throughout, we assume that a user is provided with a security module such as a SIM card or NFC chip on his mobile phone from a mobile phone operator or a payment provider. In practice, the mobile phone with the security module is in physical possession of the user and it might carry additional personal information such as name, picture, list of contacts. Moreover, the person in possession of the module must know a PIN code to use the services and the data stored on the device. We also assume that there is a trusted third party that is linked to the payment provider and who maintains and accesses a secure database with account and transaction data for all the users. In some cases, such a trusted third party could be an external Escrow service, thus allowing one to transfer trust away from the payment provider. In other cases, the trusted third party might be the payment provider itself.

The aim of the present invention is to provide:

A method for secure electronic payments with privacy enhancements via trusted third parties that is configurable for usage in mobile payment applications, Internet payment applications or traditional merchant stores

a method that allows a user to utilize his mobile web-enabled phone with a SIM card or Near Field Communication chip to pay anonymously for goods or services without revealing any information not directly necessary for the transaction to any party that is not fully trusted such as the merchant, the mobile carrier and (in the case when the trusted third party is different from the payment provider) the payment provider ;

a method that guarantees security and privacy enhancements via state-of-the-art cryptographic confidentiality and authentication technologies

a method that allows the user to reload money for spending from his account at the payment provider onto his SIM card or NFC chip without any possibility for any party that is not fully trusted to monitor and link the subsequent spending transactions to the individual user

a method that is resilient to connection losses and that allows users and merchants to recover gracefully from such service disruptions without the need to maintain complex transaction state on the SIM card or the NFC chip and without financial losses to any of the parties involved .

These objectives are reached with a method as claimed in claim 1. The method object of the present invention will now be described in detail with reference to the accompanying figures in which: Figure 1 is a schematic view of the different parties and components involved in the secure payment method object of the invention and depicts the necessary requirements and prerequisites.

Figure 2 illustrates schematically the flow of information between the different entities involved in a cash reload operation of the user's mobile device.

Figure 3 depicts the flow of steps performed in a cash reload operation.

Figure 4 illustrates schematically the flow of information involved when a secure payment between a user and a merchant occurs.

Figure 5 is a flow diagram showing the different steps performed during a payment transaction.

Figure 6 illustrates schematically the process of reimbursement of the merchant from the payment provider.

Figure 7 show schematically the steps involved in the process of the reimbursement of the merchant.

Figure 1 depicts the different components and entities of the system that allows the mobile payment method for secure electronic payments with privacy enhancements via a trusted third party according to the present invention, as well as the prerequisites for its integration and implementation and the protocol for reimbursing the merchant. On the left of Figure 1, a user is represented with a mobile device 1 such as a smart phone equipped with a SIM card 2 and a NFC chip 3. On the top of the figure, a mobile operator 4 is schematically represented and is able to communicate with the user's mobile device 1 thanks to traditional over the air (OTA) communication protocols and with a payment provider 5 depicted on the upper right part of the figure. The payment provider 5 is linked to a trusted third party 6 who maintains a secure database 7 for storing securely information related to payment transactions. The bottom of Figure 1 depicts schematically the merchant equipped with a point-of-sale (POS) terminal such as a near field communication (NFC) reader 9 as in our example that may exchange data with the user's mobile device 1. In order to set up the environment and the prerequisites for enabling the secure payment method, the following events take place. The payment provider 5 establishes a business relationship with the mobile operator 4 allowing the payment provider 5 to install applet 10 and store data on the NFC chip 3 of the user's mobile device 1.

The merchant 8 subscribes with the payment provider 5 and the payment provider 5 provides the merchant 8 with specific software used for validity verification of transaction receipts.

The user then signs up for mobile phone services with the mobile operator 4. The mobile operator 4 has full control on the two security modules of the user's phone: the SIM card 2 and the NFC chip 3, i.e., it knows the cryptographic keys 11,12,13 that allow lifecycle management of the NFC chip 3 and the applications on it.

The user then signs up for payment services with the payment provider 5 who installs, via the mobile operator 4, an applet 10 loaded on the NFC chip 3 of the user's mobile device 1. The applet 10 is loaded and installed onto the NFC card 3 of the user's mobile device 1 by means of well-known secure protocols for loading applications on smart phones. Upon installation, the applet 10 generates an asymmetric key pair that is used in conjunction with the trusted third party's static public key to derive an ephemeral session key TTP EY 13 used for establishing a secure channel between the applet 10 and the trusted third party 6, using Diffie-Hellman or Elliptic Curve Diffie-Hellman types of key agreement protocols. (Note that alternatively, the applet

10 may come preloaded with a unique shared secret symmetric key TTP_KEY to be used for encrypting the data exchanged between the applet 10 and the payment provider 5 but the utilization of static shared secret is not the preferred embodiment). The NFC chip 3 of the user's mobile device is also provided with a payment provider's signing key pair 1 1 PP SIGN SK, and PP SIGN PK, and payment provider's public encryption key PP PKEY 12. Here, the signing key pair PP SIGN SK, PP SIGN PK

1 1 is the same for all users , and could, be ..updated by the payment - provider 5 periodically and the public key PP_SIGN_PK is moreover also provided to the merchant 8 by the payment provider 5 for verification of the validity of the transaction receipts.

The NFC chip 3 of the user's mobile device is also provided with a unique user identifier key K that allows the payment provider 5 to identify a particular applet 10 thanks to this unique identifier K. The identifier K is linked to the account of the user with the payment provider 5. The private keys on the SIM 2 and NFC 3 cards are protected by a PIN code , therefore the user must authenticate himself by entering his PIN code to enable private key operations.

The trusted third party 6 maintains a secure database 7 for storing lease data in such a way that the payment provider 5 is allowed to access that database 7 without seeing any information about the user. It is assumed in the following that the trusted third party 6 is an independent party that maintains an appropriate secure database 7 and to which the payment provider 5 can make queries in order to get certain information (relevant to enabling financial transactions but insufficient to link a transaction to user's identity) from the database 7 maintained by the trusted third party 6. Yet, the payment provider 5 should not have full access to the database maintained by the trusted third party 6.

Throughout, we have assumed that the trusted third party 6 is not the same party as the payment provider 5, however the payment provider 5 may itself be a trusted third party as an alternative. In this case all the steps that involve the trusted third party 6 role are performed by the payment provider 5.

Referring now to Figure 2, the operation of a cash reload on the NFC 3 of the user's mobile device 1 will be described in more details.

The user wishes to initially load or subsequently reload cash on the NFC card 3 of its mobile device 1 for being able to perform a secure payment at a store for example. Typically, the user has subscribed for services with the payment provider 5 and the user lists the payment provider 5 as a payee to his account with a financial entity in the same way as an electricity company is listed as a payee for example.

The user then requests the loading of a nominal amount of cash 1 on the NFC card 3 via the applet 10 using a_ secure OTA _(Ovej^he^ir)j2hannel.protected..by_the-ephemeral symmetric key S and using the shared secret identifier K. The payment provider 5 debits said amount 1 from the user's account and deposits this amount into a special pool account 14. The payment provider's server submits user's information to the trusted third party 6 who generates a random identification number or lease identifier id for the cash reloaded and associates the amount 1 and the user credentials with it in the secure database 7. The trusted third party 6 also generates a cryptographic key pair KP[id] and associates this key pair with the debit lease. The pair consisting of the identity of the user as well as the lease identification number id are stored in the secure database 7 on the side of the trusted third party 6. In case a transaction needs to be traced for fraud or money laundering by the authorities, this can always be done on the trusted third party side. Note that the payment provider 5 does not see anything about the link between the user's personal identity and the lease identifier. Simultaneously, the lease identification id and the key pair KP[id] are encrypted using TTP_ EY on the side of the trusted third party and are sent to the applet 10. The pool account 14 contains money from many customers who have the payment applet 10 installed on their NFC cards. The total amount is subdivided logically into debit leases of capacity 1, each identified by the corresponding id and the key pair KP[id] consisting of a pair (PK[id], SK[id]) of a secret key SK[id] and a public key PK[id]. The pool account 14 and the applet 10 initially have the same values for 1 and id. The payment provider server does not store any information link between the original customer account and the pair of the lease identification id and KP[id], thus, preventing anyone, but the trusted third party 6 to trace the identity of the user from id or KP[id].

Referring to Figures 3 and 4, the following steps are hereunder described in greater detail during a cash reload transaction.

The user first selects to reload cash from the user interface (UI) on his mobile phone. The user is then prompted to enter the cash reload amount 1 after which he points his browser to the online banking to make an online payment to the payment provider 5. The payment provider 5 submits the reload amount 1 and the identification of the user to the trusted third party 6. The trusted third party generates a new random lease identification number new id, retrieves the old identification number old id corresponding to the user as well as the amount l^old[U, db] currently stored in the secure database 7. Note that the payment provider 5 does not see in any way which new_id corresponds to the user asking the reload. The old identification number old_id is stored by the trusted third party 6 to allow for further reimbursement. The trusted third party 6 generates then a new key pair KP[new_id] corresponding to new id. The trusted third party 6 encrypts new_id and P[new_id] with the symmetric key TTP_KEY that is stored on the user's NFC chip 3 and sends the encrypted new identification number to the user's NFC card thanks to OTA via the payment provider 5 and the mobile operator 4. The trusted third party 6 sets 1[U, db] = 1 + l^old[U, db], where 1[U, db] indicates the amount on the database corresponding to the user. The trusted third party 6 then updates the identification number new_id and the amount 1[U, db] corresponding to the user in the database.

The applet 10 receives the encrypted new id, 1 and KP[new_id], decrypts them using the symmetric key TTP_KEY and calculates the new amount 1[U] = 1 + l^old[U] where l^old[U] is the old amount stored on the card. The applet 10 then updates the lease identification number, the amount and the lease key pair with the new values new id, 1[U] and KP[new_id]. The applet 10 (via the user interface application) sends a confirmation to the payment provider.

The user's financial entity then transfers the amount for the reloaded cash to the payment provider's pool account 14 via the standard payee method.

Note that the current amount 1[U, db] stored in the secure database 7 on the trusted third party 6 side at a given time need not be the same as the current amount 1[U] on the NFC chip 3 of the user. Indeed, the difference is the amount of all transactions for which the user has already paid, but the corresponding merchants have not received their reimbursement yet (we refer to these transactions as outstanding transactions).

With reference to Figures 4 and 5, a typical secure payment process will now be disclosed in detail.

The user places his mobile device 1 such as a smart phone equipped with an NFC chip 3 in proximity to the point-of-sale terminal (POS) 9, in our example, an NFC reader 9 operated by the merchant, the merchant 8 inputs the total payment amount on the NFC reader 9, as well as the merchant' identification which then submits the digitally-signed payment amount to the applet 10 running on the NFC chip 3 of the user's mobile device _ L _The payment, requests

digital signature algorithms (e.g., DSA or ECDSA) and thereby prevents dishonest merchants from refusing the disbursement of goods or services paid for in the transaction. The applet 10 loaded on the NFC 3 of the user's device 1 then verifies the digital signature of the incoming payment request and asks the user to enter his PIN code in order to allow for private key operations on the card. Once the user enters his PIN code, the applet 10 verifies that the NFC card 3 contains the necessary amount, generates an electronic transaction receipt TREC, signs the receipt with the private key of the user and sends it back to the NFC reader 9. The latter then verifies the signature using a public key contained in the receipt and if the verification fails, it rejects the payment. If the signature is valid, the NFC reader 9 sends back a message to the applet 10 on the NFC card 3 for deducing the payment amount. Once the applet 10 deduces the payment and a confirmation is received by the NFC reader 9, the merchant 8 releases the goods and services to the user. The merchant 8 then stores the electronic transaction receipt TREC for later reimbursement from the payment provider 5. The merchant wants to collect the funds in a form that complies with the current requirements, represented by a financial entity. The user wants to remain anonymous to the merchant and to the payment provider. The user must also get a receipt for the transaction which is generated by the applet App.

The protocol for electronic payment with privacy enhancements via trusted-third parties using mobile phones equipped with NFC chips will now be described in more detail.

Assume that PP_SIGN_KP = (PP SIGN PK, PP_SIGN_SK) is a signing key pair of a public and a private key used by the applet 10 for signing certain information on the NFC chip 3 and pre-installed by the payment provider 5. Let PP_KP = (PP PKEY, PP SKEY) be a key pair used by the applet 10 for encryption and by the payment provider 5 for decryption (again, pre-installed on the NFC). Moreover, let TTP_KEY be a shared key used for secure communication between the trusted third party 6 and the applet 10 (again, it can be pre-installed) in such a way that the payment provider 5 does not know TTPJ EY. As before, let KP[id] = (PK[id], SK[id]) be the key pair (signing keys) corresponding to the current lease. Moreover, we assume that we have a signing function SIGN(MSG, SK) taking as arguments a message MSG and a (signing) secret key SK and producing as an output a signature SIG. We also define a corresponding function VERIFY(MSG, SIG, PK) taking as arguments a message, a signature and a public key PK and returning TRUE or FALSE depending on whether the signature SIG is a valid signature for the message MSG under the public key PK for the signing key pair. Similarly, a function ENCRYPT(MSG, PK) produces a cipher text and a function DECRYPT(C, SK) produces the plaintext message. Finally, let a||b denote the concatenation of the binary representations of two strings a and b. We also have an application UI installed on the operating system of the user's mobile phone 1 that is serving as a proxy for the cash reload use case and that can securely communicate with the NFC card and the applet 10 on it.

The protocol consists of the following steps:

The user interface of the user's mobile device prompts the user for a PIN code and sends to the applet 10 the PIN value to be verified. The applet 10 verifies the PIN code. If the PIN code is incorrect, it generates an error and exits. Else, the applet 10 enables private key operations on the NFC chip 3 and the user places the mobile phone 1 in a close proximity to the merchant's point of sale terminal (i.e the NFC reader 9) to proceed with the transaction.

The NFC reader then generates a transaction request TREQ that contains the amount m of the transaction as well as other information such as the merchant's identification, a transaction identification, a time stamp, etc, together with a digital signature TREQJVI SIG of all this data with the merchant's private key M_SIG_SKEY and transfers via the NFC reader (TREQ, SIG[M]).

It is to be noted that the key pair M_SIG_{SK,PK} are specific to each merchant and are maintained in a database at the payment provider's location that associates keys M SIG PK with a specific merchant in order to authenticate the merchant.

The applet 10 then reads the transaction request TREQ and the signature SIG[M] for a payment amount m.

The applet 10 checks that the user has a sufficient amount of funds on the NFC card 3.

If the digital signature is invalid, the transaction request is rejected and both the user and the merchant 8 are notified.

If the amount of the transactions is greater than the amount on the NFC card (i.e m > 1) , the transaction request TREQ is also rejected notifying the user and the merchant 8 that the amount is insufficient. If both the above conditions are fulfilled, the applet 10 generates a random string RS, and computes

TREQ FULL = TREQ || SIG[M] || RS || id.

The applet 10 then computes

TREQ EXT = TREQ || SIG[M] || RS.

The applet 10 computes SIG FULL = SIGN(TREQ_FULL, SK[id]). The applet 10 further computes SIG_EXT = SIGN(TREQ_EXT, PP_SIGN_SK).

The applet 10 then computes C(id) = ENCRYPT(id PP_PKEY) and finally computes TREC = TREQ || SIG[M] || RS || SIG_FULL || C(id) II SIG EXT.

The applet 10 then sends TREC to the NFC reader 9

The NFC reader extracts RS and SIG EXT from TREC and computes the message TREQ EXT = TREQ || RS.

The NFC reader 9 then runs

VERIFY(TREQ_EXT, SIG EXT, PP SIGN PKEY) If the verification fails, the NFC reader 9 rejects the payment. Else, The NFC reader sends a confirmation to the applet 10 on the NFC chip 3.

The applet 10 receives the confirmation and updates 1 := 1 - m after which TREC is sent to UI and a copy is stored on the user's mobile phone operating system.

The merchant 8 (via the NFC reader) stores its copy of TREC for later reimbursement and releases the goods and services to the user. The merchant 8 also uses the stored copy of the transaction record TREC o-prevent-dishonest-customers^"irom^"repVaying ld payment^' receipts]

One can use a symmetric key S instead of the asymmetric key pair PP_KP for a faster encryption of the debit lease id. In this case

C(id) = ENCRYPTs (id)

is the result of the symmetric encryption of id with the key S. In practice, one can use AES with the key S to perform this operation. A random string RS is used to mark each payment receipt TREC in order to facilitate undeniable tracing of past transactions by the trusted third party and the payment provider.

The user may also be prompted to enter the payment amount m along with his PIN code in order to ensure that no amount is withdrawn from the NFC chip 3 without the explicit consent of the user. In addition, the user may also be asked to provide the answer to a difficult-to-solve-by-a-computer puzzle along with the PIN in order to ensure that each payment is a direct result from the human-to-phone interaction between the user and the applet 10 running on its mobile device. This would eliminate attacks on the PIN code by malicious key-logging software tools and further enhance the protection of the user.

Figure 6 shows schematically the operations performed during a fund reimbursement. The merchant 8 collects the funds from the payment provider 5 in a form usable within the legitimate financial system. The user does not reveal his personal payment information neither to the merchant 8, nor to the payment provider 5. The customer gets an electronic receipt from the NFC reader of the merchant. Finally, the merchant 8 gets reimbursed by the payment provider.

Now the protocol for the reimbursement of the merchant 8 by the payment provider 5 will be disclosed in more details in reference to figures 6 and 7.

The method consists of the following steps:

The merchant 8 sends a transaction receipt TREC to the payment provider 5.

The payment provider 5 extracts the digital signature SIG[M] of the merchant 8, verifies it with the merchant public key M SIGN PK and rejects the requestjf Aey^rification_fails._

The payment provider 5 then extracts C(id) from the transaction request TREC and computes

id = DECRYPT(C(id), PP SK).

In the alternative case in which a symmetric encryption key K is used, the back-end server of the payment provider 5 computes

id = DECRYPT_K(C(id)). The payment provider 5 then queries the secure database 7 via the trusted third party 6 to get PK[id] from id.

The payment provider 5 then extracts TREQ || RS from TREC and computes

TREQ FULL = TREQ || RS || id.

The payment provider 5 then extracts SIG FULL from TREC and runs

VERIFY(TREQ_FULL, SIG_FULL, PK[id]). If the verification fails, the payment provider 5 generates an error and rejects the reimbursement. Otherwise, the payment provider 5 sends the id and the amount m to the trusted third party 6 who then updates the secure database 7.

The trusted third party 6 searches the secure database 7 for the amount corresponding to a user whose lease identification number has been (at some point in the past) equal to id. Since id may not be a currently used lease identification number (in the case when the user whose lease identification has been id has already reloaded new cash before the reimbursement request is made). This is why the secure database contains all previous lease identification numbers associated to a given user and thus, could search the user by a past lease identification.

If the reimbursement amount m is larger than the amount corresponding to the user the trusted third party 6 returns false to the payment provider 5 who rejects the reimbursement request to the merchant 8. Else, it subtracts m for the corresponding lease id and returns a confirmation to the payment provider 5.

The trusted third party_6 ^ Jhen jecords_.. the_transaction - information - contained in TREQ and RS to prevent replay of old messages by dishonest merchants.

Finally, the payment provider 5 reimburses the merchant 8 via an amount taken from the pool account 14. The following relates to the advantages provided by the invention in relation with privacy enhancements of the financial transaction implemented by the payment, reimbursement, and cash reload protocols

There is no way for the payment provider 5 or the merchant 8 to identify any specific information that links a user buying goods or services to the financial transaction recorded between the user and the payment provider 5. At most, the payment provider 5 can compile a database of leases id and associated customer accounts, in contravention of the protocol, and thereby link customers to merchants during the reimbursement phase of the protocol. However, a similar attack is also possible with real cash, in which a financial entity records the serial numbers of banknotes that are deposited and withdrawn from the financial entity.

Even if an adversarial user or a merchant gain knowledge of the secret key PP SKEY, the hacker would find out id but he will not be able to discover the identity of the user behind it nor abuse the account of the user. Recall that by setup, there is no link between id and the identity of the user other than the link located in the secure database hosted by the trusted third party TTP. To drain the account of a user, the hacker needs to gain physical possession of the user's phone and hack the PIN code because the PIN code has a limited number of tries before it is blocked, this is very difficult to achieve. Therefore the total gain of the hacker is that he will be able to figure out the different debit lease identifiers id but this is not enough to give him relevant information to drain money from the pool account 14. (The attacker can also forge payments from id and thereby defraud merchants, but the user's funds are not at risk). This is an acceptable level of risk for the scenario in the case of the key PP SKEY is compromised.

A user does not have to worry about a merchant recording any identifiable information relating purchases to his electronic cash. Indeed, if one uses random padding of the id before encrypting it using PP PKEY then the merchant cannot correlate two subsequent transactions made with the same NFC card.

Although the invention has been described in language specific to structural

features and/or methodological acts, it is to be understood that the invention defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.

Claims

1. A method for executing secure electronic transactions between one or more users and one or more merchants while not exposing any personal information of the user to the merchant or any untrusted party via one or more payment providers and one or more trusted third parties comprising the following steps:

said user subscribes for payment services with said payment provider, said payment provider installs secure software and cryptographic keys on a security module of a personal secure device,

said user requests cash reload for a specified amount to be loaded on said personal secure device,

if said reload request is successfully approved by said payment provider, said payment provider generates (via said trusted third party) a unique identifier associated to said cash reload together with a signing key pair that is then transferred and saved on said security module of said personal secure device, said merchant send to the applet on the user's device a transaction request for a specified amount and said applet verifies that the amount stored is sufficient for the payment and generates a transaction receipt via signature and encryption algorithms using private and public keys stored on said security module of said personal secure device such that the transaction receipt contains at least the amount of the transaction, the signatures, merchant identification as well as the unique identifier either encrypted or not, but it does not contain any personal information specific to the user,

said transaction receipt is then transferred to said merchant and said merchant verifies the validity of the receipt,

if the verification is successful, said merchant releases the goods and services to said user,

said merchant saves said transaction receipt for later reimbursement from said payment provider.

2. A method according to claim 1 wherein said user reloads cash via the following sequence of steps:

said user requests cash reload of a specified amount to said payment provider either via the mobile phone or via a website.

said trusted third party generates a random lease identifier specific to the cash reload as well as a signing key pair specific to this identifier and the secure database is updated with the newly generated data.

data specific to said cash reload containing at least the identifier and the key pair is securely transferred to said security module so that no party other than the trusted third party can read this data.

said data is stored on the security module and the amount of electronic cash on the security module is updated.

3. A method according to one of the preceding claims 1-2 wherein said merchant gets reimbursed by said payment provider via the following sequence of steps:

said merchant sends said electronic transaction receipt to said payment provider.

said payment provider extracts said lease identifier from the receipt and retrieves the public key corresponding to that identifier from the secure database via the trusted third party.

said payment provider extracts a signature from the transaction receipt and verifies the validity of that signature using the public key;

if the signature is valid, said payment provider releases reimbursement for said merchant and updates said secure database via said trusted third party.

4. A method according to claims 1-3 wherein said^ers^naj_secure^eyjcejs_a mobile phone and said security module is a SIM card.

5. A method according to claims 1-3 wherein said personal secure device is a mobile phone and said security module is an NFC chip.

6. A method according to claims 1-3 wherein said personal secure device is a smart card and said security module is the secure chip on the smart card.

7. A method according to claims 1-6 wherein said communication between said user and said merchant takes place over the internet.

8. A method according to claims 1-3 and 5 where said communication at the time of the payment between said personal secure device and said merchant is a near-field communication.

9. A method according to claims 1-3 and 6 where said communication at the time of the payment between said personal secure device and said merchant is operated via a smart card reader.

10. A method according to claims 1-9 wherein said payment providers themselves are trusted parties.

11. A method according to claims 1 -9 wherein said trusted third parties are distinct from said payment providers and are communicating securely with said payment providers.