Wednesday, January 29, 2014

An actually secure payments protocol, and Coin's broken security

Here is a sketch of what should happen when I pay for a meal at a restaurant:

Waiter brings the bill over, which contains a QR code or some such. QR code contains the name of the merchant, its public key, and an amount. I point my phone at it, up pops a screen that says "Acme Burgers Inc. would like to charge $33.04", I add a tip, bringing the total to $39.04, then press 'Authorize'. The payment app on my phone uses my private key (stored only on my phone in RAM) to sign the tuple ($39.04, timestamp, Acme Burgers Inc public key). My phone renders this signed tuple as a QR code. I get up and walk out of the restaurant, stopping at the door to scan my QR code at a reader. Acme Burgers now has information needed to charge my bank later.

At any point later, or perhaps immediately, Acme Burgers contacts my bank and demonstrates cryptographic proof that I have authorized a charge to them of $33.04, and said bank transfers cash money to Acme and debits my account with them. The signature prevents any other party without Acme's private key from authorizing this transfer, and Acme is prevented from replaying this later due to the timestamp / nonce.

Unlike credit cards, I don't give the merchant access to all my credit, for all time, and hope they only use the credit I've authorized. I've given them exactly the capability they need, no more. The security of the merchant's accounting systems is no longer something that concerns me.

A few notes:

This protocol does not require internet access at the time of sale, and it's pretty damn convenient too.

The protocol could be made anonymous, so the merchant does not even learn my public key.

Recurring payments could work the same way, only what is being signed by me is something like "allow a charge of $7/mo, for the next 12 months", rather than a single amount.

Online payments could use the same sort of protocol. Obviously we can dispense with using QR codes as a communication channel (or not).

This is obvious stuff, and not in any way new, right?

Now, why the heck doesn't something like this exist? Software lets us solve these problems better, and yet the payments industry is still using the virtual equivalent of distributing and transferring account numbers on scraps of paper.

Here is what passes for innovation in the payments industry:

Coin was announced several months ago. It's a single physical card, called a 'Coin', which can store all your cards. By pressing a button on the Coin, you reprogram the magnetic strip to a different active card. Now, rather than giving the merchant access to all your credit, for all time, for one of your accounts, you can give them access to ALL of your accounts. When I pointed out this very real and very serious security issue, I got radio silence...

LevelUp lets you pay with your phone. Rather than carrying around a credit card, which gives access to all your credit, you carry around your phone with the LevelUp app, which has a QR code that gives access to all your credit... The security model is unchanged! Nothing stops the merchant or anyone who hacks the merchant's systems from repeatedly using the information from your QR code to drain your bank account. Nothing stops a nefarious bystander from grabbing your QR code and draining your bank account (they just need to have or control a merchant account with LevelUp). What's missing is the step where the user actually authorizes the charge.

Bob: Oh, come on. Credit cards aren't so bad. Even if they are technically insecure, I'm not liable for fraudulent or unauthorized charges, so what difference does it make to me?

Alice: Who do you think pays for all those fraudulent charges?

Bob: What do you mean? My credit card company pays for it. Or the merchant pays for it.

Alice: Yes, and how do you think they pay for it?

Bob: Umm...

Alice: It's paid for via credit card processing fees, which get passed on to you, the customer, in the form of higher average prices. The money has to come from somewhere. So actually, it's you that pays for fraudulent charges, you just pay for them as a tax on every transaction, rather than in bursts. And those are just the direct costs of fraud. The indirect costs are also significant--consider the additional time spent having to review your credit card statement more carefully due to higher probability of fraud. Consider the time spent having to update your payment information with dozens of merchants when Target or some other merchant with your information gets hacked. Consider the additional machine learning algorithms the credit card companies have to run, to analyze transactions and detect fraud. Consider the cost of the false positives in these systems, the salaries of the phone operators who have to be on hand when you call to say 'no, really, I am in Montana trying to buy some beef jerky, my card has not been stolen'. And that's just off the top of my head.

11 comments:

@Anonymous - good question. I can have the bank sign my (public key, expiration date) pair when I establish the account and present this in lieu of just my public key. Assuming the merchant has access to the bank's public key, they can verify I have an active account with the bank. Of course, that doesn't prove I have enough credit for the transaction... perhaps I can ask my bank at any time for timestamped, signed proof of my current balance.

I don't believe there is any protocol that can give perfect certainty in this regard, in offline mode, since I could have just spent all available credit twice at two merchants in offline mode that have not yet reconciled with the bank. All that we can do is have the bank sign information deemed relevant to determining likelihood of sufficient credit. For instance, the bank could sign some sort of timestamped rating of how often I have sufficient credit for transactions I engage in. The merchant can look at this and see that I reliably have sufficient credit for my transactions (according to the bank), and decide offline whether it's okay with that level of risk.

Well, you know, Europe has actually secure payement cards that works somehow like that (see gemplus, javacard, etc). In France, we even have FOR DECADES a normalized common interbank system that allow any bank to ask to any other in real rime if I have the amount of money available, so that ALL payment cards works with ALL banks, no visa/MasterCard/etc incompabilities. So no, nothing new, just something not invented in the US ages ago...

@Fanf - I'm kind of skeptical. :) Unless this is a smartphone app, I do not see how such a system can possibly be secure. The key step missing is the step where you authorize exactly one charge, for a particular party, for a particular amount, once, on a device you control and trust, rather than on merchant hardware or POS terminal. I don't really see how a card can ever be secure, unless the card has a processor that can run crypto algorithms, display text, and accept user input (aka, a smartphone).

Anyway, please provide details if you think some existing system does satisfy my requirements. :)

Actually, the cards in Europe do have their own processors to generate one-time tokens. At least in Germany banks do supply the customers with hardware (display+keyboard) into which the card can be mounted to generate the one-time tokens. Despite this system is not universally in use today the customer can use it for all transfers in Europe if they want to – some banks force this method for online banking transfers.

In Europe, we have smart card that has there own processor, read only memory storing a crypted private key and ram where the uncrypted version lived for short time. But you are right, the user I/O (pin for decrypting the key) are on the terminal, and there is some kind of attacks possible (even if hard: cpu&time based guessing, these kind, litterature available on internet :) with a pirate terminal. In fact, in France, we even have that since a french patent of 1974 from M. Moreno) and it's commercial use in Gemplus (1988).

The actual protocol used is more complex than the one you depicted to overcome some kind of attack, but the logic is the same: a unique nounce produced and asymetrically signed for each transaction (plus some real time verification, for example to check that the user has the actual money to pay on his account).

Nowaday, there is a groupement of Europay/Mastercard and Visa for the evolution of the protocol and standards on the subject, and they smartly call it the "EMV" protocol. There is a large litterature on it (attack and countermesure, proof of correctness, etc).

> Expect smart phones aren't very secure. At some point a hardware backed key store will become standard, which will improve matters considerably, but still not entirely if the phone is rooted.

Smartphones can be made as secure as you want. You can have multiple authentication factors on the phone, and multiple levels of credit / authorization if you don't wish to fully trust your own phone's hardware. Like it is perfectly fine to, say, temporarily store in RAM the unencrypted key which grants the ability to spend only $50 per day. The 'root' key which grants access to all your credit you might choose to be more paranoid about, require additional authentication, etc.