Thursday, February 4, 2016

Chip and PIN as Informed by SQRL

This document is a rough draft intended to provoke dialogue about how we might improve chip and PIN technology. It has yet to undergo the scrutiny that is required to point out its flaws and it is deliberately brief in its detail. Some of the details may be inexact or outrightly wrong, but they should be close enough to serve as a starting point. Anyone reading this is welcome to comment within this document on Google Docs here:

Chip and PIN’s Problem and the Proposed Solution

Chip and PIN has been bypassed by using a shim that always provides an affirmative response the POS when it queries the card to verify the PIN. The problem is that the POS is placing too much trust in the card.
Additionally, the payment card system trusts the POS not to divulge the cardholder’s card number. When this trust has been breached, cardholders have been inconvenienced and banks have incurred significant costs in replacing cards.
One way of solving this is to require the card to reply to a cryptographic challenge that is mathematically dependent on the PIN being correct. Every possible PIN will produce a different response, but only one of those will satisfy the cryptographic challenge. The POS will be able to compute that the PIN is correct without ever seeing it.

SQRL as a Model Solution

Existing SQRL Implementation

SQRL combines the carefully guarded master key with the domain name to produce a domain specific public-private key pair using an HMAC function. SQRL proves its identity using its public key and its signing of a cryptographic challenge.

Proposed Chip and PIN Implementation

Proposed Chip and Pin Implementation

No More Card Numbers

The POS submits the transaction information, including the merchant ID, the amount, and a cryptographically secure nonce. Instead of replying with the cardholder’s card number, the card replies with a cryptographic signature. This signature must be transmitted along with the transaction information in order for the merchant to get paid. Requiring a cryptographic signature greatly increases the complexity of forging transactions.
Every card has a master key burned into it during manufacturing. These keys are cryptographically random, never recorded, and never divulged by the card. The master key is never used directly, but is combined using the cardholder’s PIN using an HMAC hash to produce a public-private keypair. The private key is never stored or transmitted, so that the signing process should always require both the card and the cardholder’s PIN.

Verification Process

Every possible PIN produces a different public-private keypair. Therefore, the POS can rely on key signing to verify the PIN instead of relying on the integrity of the card. Public keys are verified much in the same way TLS certificates are verified: there is a chain of trust and the POS can choose to verify offline, against a local database, or online, against bank operated servers that will also warn of any revoked keys.
Keys are revoked every time a PIN is changed, a card is reported stolen, or a a card is replaced, so an online verification is always preferable. However, in the event of a network outage or in the interest of speed, some merchants and payment processors may deem an offline verification acceptable for smaller transactions. This is similar to merchants that forgo handwritten signatures today, except for the general anachronism of handwritten signatures.

Changing PINs

The cardholder changes the PIN using an ATM to update the bank’s records and obtain a new signature for their new public-private keypair. First, the ATM issues a cryptographic challenge and prompts the cardholder to enter their PIN. Once the ATM has verified the signature, the cardholder is prompted for a new PIN. This results in a new key which the bank signs and the card stores the new bank signature.


I’ve tried to avoid being overly specific in order to stick to the details that I’m fairly certain I have a handle on. For example, I’m fairly certain that existing chip and pin still transmits the card number based on this video:
However, I’m less certain about the master key. I’m basically hinting that the SQRL folks have solved how to take a key and combine it with a predictable domain name and produce a public-private keypair that can’t be reasonably reverse engineered and the reader should look into SQRL to find out what I’m proposing chip and pin should do. Similarly, I’ve pointed at TLS for other solutions without much in the way of specifics.
I’m hoping nobody is confused by my use of the term key. The key contained in the card is the same kind of key that SQRL uses as one of the inputs to its HMAC function, which isn’t the same as the asymmetric key that I’m writing about the rest of the time I use the work key.

I’ve skipped over a lot of the defensive tactics in this design. For instance, I’ve left out why the POS includes a nonce. I think that including an incremental transaction counter on the card might also help reduce fraud. These are just a couple of the very important discussions that much better informed people should have before placing their faith in this design.