A simple solution to credit card fraud, part 6: It's the protocol, stupid

This is part 6 of a long series.  This post is another technical post.  Some people have been (justifiably) pressing me for more details on the "simple solution" I've been promising in the title.  That's what this post is about.

Let us start by observing that credit cards don't actually require either credit or cards.  What matters is not the card, but the information on the card.  This is particularly evident in e-commerce transactions.  If you possess the right information, you can type that information in to a web browser and a few days later stuff will magically appear on your doorstep.  The fundamental problem is that the information you have to type in is not bound to a particular transaction.  It is reusable.  So you have to trust everyone you do business with.  Sooner or later that trust will fail.  Some random e-commerce web site that you place an order from will turn out to be a well crafted phishing site, or their database will get hacked, or a waiter in a restaurant or cashier at the shop will skim your card or just write down the number on a Post-It note.  Something.  If you use credit cards, it is a question of when, not if, you will get hacked.

Despite consumer protections, getting a card hacked can be a major hassle, especially if, like me, you have a lot of your regular bills set up to auto-pay.  I get hacked every few years, and as you might imagine I am extremely careful.  The last time it happened I was just on my way out of the country for six weeks, so they couldn't even send me a replacement card.  I didn't lose any money, but it was a colossal pain in the ass.

Debit cards, of course, have all the same problems as credit cards, except that they lack a layer of protection.  When you authorize a transaction with a debit card, you authorize the merchant to reach directly into your checking or savings account and extract money.  There are two reasons you don't hear as much about debit card fraud as credit card fraud.  First, people use credit cards a lot more than they use debit cards.  And second, debit cards typically have an extra layer of protection: the PIN.  Consumers have been effectively trained to guard their PINs closely, but the fact that a compromised debit card gives the fraudster direct access to cash makes debit card fraud lucrative enough that fraudsters go to considerable effort and expense to steal them.

Regular paper checks, by the way, are even worse.  Unlike debit cards, they actually expose your account number, and they don't have a PIN.  Anyone to whom you have ever given a check could, if they chose to, take all the money from your account.  Electronic checks, of course, are the worst of all.  They are completely insecure.  An electronic check has no security at all.  Writing an electronic check is effectively the same as opening up your bank account and saying, "Here, help yourself to whatever you like any time you like."  This is the reason you don't see electronic checks as a payment option very often.  They are so insecure that you have to be carefully vetted before you can gain official access to the electronic check system.

All of these problems could be solved at a stroke using secure digital signatures.  Instead of making a payment by handing over your account details, you would instead write and sign a digital check (not to be confused with an electronic check).  A digital check would be just some text in some standard format, e.g.:

Transaction ID: 1234

Pay to the order of: Joe Merchant

Account ID: 4321

Amount: $123.45

Expires: 4 March 2013

The digital check itself could be generated either by you or the merchant.  To authorize the transaction you would simply generate a digital signature for that text and give that to the merchant.  The merchant would then "cash" the check by presenting the check and your digital signature to the bank.

That's it.  That's the simple solution to not only credit card fraud but check fraud and debit card fraud and just about any other kind of financial fraud that involves stealing credentials.  It works because digital signatures are unforgeable and non-reusable.  The merchant can't change any of the information on the check because that would make the signature invalid.  The merchant can't cash the check twice because it contains a transaction identifier.

Now, there are some real-world complications.  The most serious is that users have to be trained to manage their secret keys.  Keeping a secret key secret is not a trivial matter, but at least it is possible.  Keeping your credit card number secret is not possible because the protocol requires you to disclose it for every transaction.

So what would the user experience be like?  (Are you paying attention, pbreit?)  There are myriad possibilities.  The most straightforward is what is already out there.  Chip-and-pin systems in use in Asia and Europe already implement a similar protocol.  But it doesn't have to be a chip-and-pin card.  It can be a dongle, or a smartphone app, or a browser plug-in.

To give you some concrete examples, here is an actual digital signature for the digital check shown above:

---MSGID---
149302O5AAVHKAEC7N5IPIGDPJAC8MBOJ2T0E6M8LQ3M40BABREI
---PUBLIC KEY---
1RBNESSNAFFOD4G05MJPTK9TLGS95QHOEBK3CD6O1KIOV5GHKAQT
---SIGNATURE---
1EQEB9T51UDVGHFVGMTANQS3JQVLV17H5HAOECHSRDJ67H4MNT1M
29SDNR6V8VCH1C3TICVDDDIA67GTG0V46H4ST2Q7IP4LF8GM548

For you hard-core geeks, this signature was generated using the Ed25519 elliptic curve digital signature algorithm.  The message ID is the SHA512 hash of the ascii text of the check, truncated to 256 bits.  All values are rendered as base 32 big-endian numbers.  You can verify that this signature is valid here.  And you can generate your own Ed25519 signatures here.  As a proof-of-concept for a standalone security dongle, I have implemented Ed25519 on a Teensy3, which costs $19 in single quantities.  So no, pbreit, distributing new hardware is not hard, and it is not expensive.  Not any more.

The physical manifestations of this protocol are endless.  Here, for example, is the above signature rendered as a QR code:

You can scan this image with any QR code reader to verify that the signature is valid.  Or, if you don't trust my verification web site, you can use a standalone verification app written by someone else.  There is nothing at all proprietary about this protocol.  It is entirely open.  The only secret is your secret key.

Again I have to stress that what matters here is the protocol, not any of the implementation details.  I happen to like Ed25519 because it generates highly secure signatures that are short enough to render as reasonable-looking QR codes, but that is a detail.  The point is that by changing the protocol you can solve the fraud problem.

And you can solve lots of other problems too.  More on that in a future post.