CA2883737A1 - E-payment over hostile paths - Google Patents

Description

E-Payment over hostile paths Author: Stanley Chow, 2015 Mar 3 Scenario: a consumer wants to make a purchase, but how can they make the payment? Traditionally, there was physical money, the physical object represents some amount of "value"; then came cheques and credit cards that represents a promise by a third-party (typically a bank) to pay. As soon as the third-party is involved, there is a problem of trust ¨ how to verify that promise is real. The usual way is for the consumer to contact the payer to get a coupon of some sort, but this requires a trusted path, which is often not available to the consumer, or at least without great cost ¨ think roaming data rates.
Credit card companies attacked this problem many ways ¨ making the card hard to forge (e.g. by adding holograms), issuing "black-lists" of banned-cards (e.g. stolen cards). The current solutions of embedding a processor chip in the card (the "Chip Card" or "Smart Card") works as follows:
= The chips are designed to securely store a secret;
= This secret is used to participate in a cryptographic protocol, but only if the user enters the correct pin code;
= The bank (the "Issuer") knows the secret (or some other corresponding value) associated with the card/user and so they can be sure that it is the correct card and the correct user;
The problem with this approach is that the credit companies have to build-out an infrastructure of Chip-card machines that lets the user enter their pin code. This is a very costly undertaking and requires cooperation to standardize the card, processor, protocol, etc. With this colossal undertaking, there is still a security problem ¨ securing the POS (Point-of-Sale) devices. Since these POS devices are paid for by the merchants, and located at the merchants' premises, they are only as secure as the merchants are willing to pay for and to maintain; and the merchants are not motivated to pay very much for security of the user's cards. In other words, the POS devices are not very secure ¨ there are all kinds of attacks that use modified devices to clone cards and steal pin codes, not to mention rogue/incompetent merchants that use devices that store these pin codes. The 2007 TJX breach compromisr 1 96 million credit/debit cards used at TJ Maxx, Marshalls and other TJX
stores. Another data breach at Target in 2013, impacted over 70 million users and exposed their credit/debit card information.
When we go to e-payments, the problem gets even worse. In this case, the third-party promising to pay is typically the e-payment operator, and the merchant probably does not have any special POS
device for this e-payment operator. The User Device cannot be assumed to have any communication capability ¨ especially when one considers the cost of roaming. The typical solution is to secure the consumer device with a "fortress", and issue the promise based on the security of the fortress (the fortress could be a custom Fligh-Security Module, or a special SIM card). This brings many problems like cost of the secure module, making sure the fortress is in sync with the master D/B, etc. For example, in Canada, RBC, Bank of Montreal ,TD Bank, CIBC & Scotiabank all offer their customers using Android or Blackberry devices the ability to do contactless mobile payments provided they have their app, Near Field Communication (NFC) contactless technology enabled on their devices along with an NFC SIM Card supplied by their carrier/wireless provider and support for such at the merchant. A similar situation exists with the Major banks in the U.S. and Softcard (formerly ISIS) formed by AT&T
Mobility, T-Mobile USA Inc. and Verizon Wireless, requiring costly hardware both on the smartphone as well as on the merchants POS hardware is required to facilitate ecommerce. No doubt the recent acquisition of Softcard by Google will provide some much needed momentum but the obstacles highlighted above still remain.
Solution:
We propose a solution that lets the user handle all of the secret processing, so the merchant has no access to any user secrets, nor does the merchant have to maintain highly secure equipment. We can accomplish this by treating the merchant as an untrusted communications channel. The steps:
= Merchant must have intemet access (hardly a requirement these days) and equipment that can do NFC and Bluetooth (this can literally be a smartphone, tablet or a laptop with a custom app). Optionally, this can also communicate to the cash register to download transaction details; indeed, this smartphone could be the cash register.
= User must have a processor with communications capability ¨ a smart phone, a laptop, etc. In the current day and age, this is not a stringent requirement at all. Indeed all e-payment systems require this;
= Before any transactions, User must obtain credentials (and authentication secret) from e-payment company. The credential/secret can be in many forms ¨ userid/password, account number, X.509 certificates, hardware tokens that generate One-Time-Passwords, etc. It is also possible that an "app" will be installed ¨ this app is written by the e-payment company, runs on the User Device and handles transactions for that e-Payment company. It is likely that users will have multiple payment apps on a single device. It is also possible to not use an app, but use programs like a web browser instead;
= When User wants to make a payment to Merchant, communication is established between the User Device and the Merchant Device. The User Device will contain credentials as discussed above and the Merchant Device will provide real-time communication;
= The communication can go over any medium ¨ wired ethernet, WiFi, Bluetooth, NFC (Near Field Communication), etc. The only requirement is that the communication be two ways. We will continue this explanation with using NFC to pair Bluetooth, then use Bluetooth to do the actual communication;
= User and Merchant negotiate transaction, and agree on payment amount. The amount is entered by merchant onto Merchant Device along with Merchant name, date and other details (much like it is done for credit card purchases);
= User "bongs" User Device (that is ¨ brings User Device to close proximity to Merchant Device to allow NFC to work) establishing NFC channel. Using Bluetooth Secure Simple Pairing with NFC, the Bluetooth pairing is established using a "Payment Proxy" profile (Bluetooth is a generic communication capability and a profile is used to define the kind of device ¨ examples are headphones, keyboards, mice).
= Using the API defined by the profile, User Device can query the Merchant Device to obtain transaction details.
These details are displayed to the user and the user can confirm/deny the transaction;
= If the user denies the transaction, then we abort, if not, we continue;
= Using the API defined by the profile, User Device can establish a channel to the e-payment company. The API will of course be implemented by the Merchant Device using its own communications.
At this point, the User Device has an untrusted channel that is at the mercy of the merchant (or anyone who has "hacked" into the system).
= User Device initiates a secure channel over the untrusted channel. This is a well known problem with different solutions for different contexts. In our case, a suitable solution is to use SSL with both sides checking the certificates. That is each side will present its X.509 certificate for the other side authenticate, once this is done, each side is assured of the identity of the other side. More precisely, the certificates are publicly redistributable, the authentication is done by checking that the claimant has the private key corresponding to the certificate. We just make use of standard X.509 protocols;
= Alternative to the SSL solution is sometimes desirable (since that requires X.509 certificates to be issued by the payer). One can use any of SSFI, VPN or any other methods to establish a secure channel; then use userid/password to authenticate;
= Over this secure channel, User (more precisely, the payment app) can ask for a coupon/confirmation of transaction from the e-Payment company. There are many ways, we assume the use of X.509 certificates signed by the e-Payment company. User Device sends:
o User authentication in the form of Credentials, passwords, etc. This is to authenticate user as opposed to the SSL certificate that authenticated the device. This is at the discretion of the e-Payment app ¨ possibly based on amount of transaction, credit rating of user, time of day, location, transaction history, etc.

= Transaction amount, possibly with currency translation and tax handling;
= Optionally, details of the transaction provided by the merchants;
o Optionally, any other details that User enters;
= e-Payment company receives the request, confirms user credit (however it wishes), signs the transaction approval with its X.509 certificate, and sends the signed approval back;
= User receives the signed approval (over the secure channel) and uses the profile API to give the approval to the Merchant Device. This is most easily done via the API of the Bluetooth profile;
= Merchant Device confirms approval by checking the signature of the e-Payment, using standard X.509 checking protocols. Optionally, this confirmation can be return via the API and the User Device can display the confirmation and whatever confirmation code;
= At this point, the payment has been made and the transaction is completed. The channels and connection can now be dismantled;
= Note that with this arrangement, each actor is responsible for its own security and is therefore motivated to act correctly, that is:
= The e-Payment company needs to keep their certificate secure (or more precisely, the certificate is public, but the secret key corresponding to it is secret). It is clearly important and clearly any sensible e-Payment company will want to safeguard this;
o The e-Payment company needs to keep their client list/credentials secure.
Again, clearly important and will be done;
o The Merchant merely has to provide communication (to allow the transaction to happen) but no security is implied. (The Merchant does have to secure their own data, but that is irrelevant for this discussion);
o The User has to secure the User Device. Any User that neglects security will only harm themself, not any other user;

Claims

Claims:
.cndot. Merchant providing a communication path (untrusted by the User), allowing User Device to communicate securely to e-Payment company at no cost;
.cndot. User controls own secrets on their own equipment will no reliance on anyone ¨ be it the e-payment company, the merchant, etc.
.cndot. Using Bluetooth profile to establish secure channels;