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.

Saturday, June 14, 2014

Nigerian Prince Meet British Banker

I think I encountered my first Nigerian Prince email in 2002. Spam filtering does a good job of making sure I don't see them, but every once in a while it snags something it should have let through.

As I was looking to see there might be any legitimate email in my spam folder, I cam across this gem. For some reason, I find it quite entertaining that the character in this email is a British banker rather than a Nigerian prince.

I'm almost tempted to reply using dummy information just to see where it leads. It would be trivial for me to create a phone number just for this occasion and I'd be very curious to hear what accent the caller would have.

I am Mr. Algoth Cyprian, an Accountant with Bank, I am the personal Account Manager to Late Mr. Enevald Helmut.

On the 21st of April 2008, Mr. Enevald Helmut (Herein after shall be referred to as my client), his wife and their two children were involved in a car accident in London. Unfortunately they all lost their lives in the event of the accident, since then I have made several inquiries to locate any of my client's extended relatives, this has also proved unsuccessful. After these several Unsuccessful attempts, I decided to trace his relatives over the Internet, to locate any member of His family but of no avail, hence I contacted you to stand as his next of kin.

I contacted you to assist in repatriating the money in addition, property left behind by my client before they get Confiscated or declared unserviceable by the bank where this huge deposits were lodged. Particularly, Lloyds Bank, where the deceased had an account valued at about Six hundred thousand Great British Pounds. Consequently, the bank issued me a notice to provide the Next of Kin or have the account confiscated within the next twenty official working days.

Since I have been unsuccessful in locating the relatives for over 2 years now I seek your consent to present you as the next of kin of the deceased based on the fact that you are a foreigner so that the proceeds of this account valued at about six hundred thousand Great British Pounds can be paid to you and then you and I can share the money. 50% to me and 40% to you, while 10% should be for expenses or tax as your government may require. An attorney will be contracted to help re-validate and notarize all the necessary legal documents that can be used to back up any claim we make. All I require is your honest cooperation to enable us sees this deal through. I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law.

To enable us discuss further, I would like you to send me the following information so I can open up a next of kin file on your behalf here in the bank.

1. Name in full:
2. Address:
3. Nationality:
4. Age/Sex:
5. Occupation:
6. Direct Phone number:

Best regards,
Mr. Algoth Cyprian