I have a Nexus S (thanks, Mom!), which means I now have a phone that supports
NFC. That has led me to think about how I would create a payment system that
uses my mobile phone that is completely secure not only from sniffing but from
phone theft as well. In other words something better than EMV (as recently
shown again to be imperfect).
A
Buzz by Tim O'Reilly on the topic
finally caused me to decide to blog about this.
Two things should be stated upfront. First, I am no security expert; these
are just some ideas I have on the matter. Second, this is not meant to make
sense to your parents; I'm assuming only people comfortable with a smartphone
to use this system. I am more worried about a completely secure system than I
am about my parents being able to use this approach.
So, to start, the payment app will require some passphrase protection.
Whether this is a PIN, password, lock screen, or biometric I honestly don't
care as long as it can be used to perform some encryption.
The key point is that the user must know some secret to use the payment
app properly. This protects the user from having their dropped or stolen phone
being used to make a ton of charges.
Now, with the user logged into the payment app they visit their bank's website
(I might be saying "bank", but I mean whomever is going to handle your
transactions and knows your account number). There they will have a QR Code
(should be a simple enough QR Code to not require a high-end camera feature on
the phone) to
scan with their payment app. The barcode will contain a very large account
number (think 100 digits), an increment value, some identifier of who the bank
is, and a protocol version number. Thanks to having a camera in the phone, the
app just scans the QR Code and the user has to manually type nothing. And all
the info is encrypted on the phone based on the passphrase as entered by the
user. This prevents a clever thief from nabbing your phone and simply reading
the memory to get the details necessary to clone your phone to make charges.
The app will also reset its transaction count to zero.
With the payment app and phone ready to go, you can now pay for something.
Let's say you are at In-N-Out and just bought some food for $6.54. You hold your
phone up to the NFC pad of the POS system and two pieces of data are sent to
your phone: name of
the business and the amount to be paid. Your payment app will prompt you saying
that In-N-Out would like you to pay them $6.54. This helps prevent random
people trying to charge you under a fradulent name and the cost will be used as
a way to verify with the bank how much you are authorizing to charge. If you
decide to authorize the charge, you enter your passphrase and your details are
decrypted and the payment app gets down to business.
First, it temporarily increments your transaction count, multiplies it against
the increment value, appends it to your account number, and then hashes it.
This creates a number identifying your account unique per transaction. It also
allows the bank to easily associate the transaction with your account without
any overally expensive process (hashes are relatively cheap). I am using a
unique multiplier to help prevent people guessing the increment amount by
having you do two transactions in a row at the same POS system
(security-by-obscurity might be bad to rely on, but it doesn't hurt to make
input values into a hash function harder to guess).
Next, the $6.54 cost has your account appended to it and that string is hashed.
This will provide a way for the bank to easily verify that the amount
being charged is what you want to be charged.
These two hashed values along with your bank's identifier are sent back to the
POS system. All of this is sent to your bank along with the amount In-N-Out
wants to charge you. The bank can easily look up your account by the hashed
value. It can then easily hash the charge amount with your account to verify
the amount be asked matches what you authorized. The bank clears the charge.
Back at the POS system, it tells your phone the charge went through and the
transaction counter is permanently incremented by one. And the whole
transaction is finished without any repeatable values being sent from your
phone to the bank that can be sniffed. Nor is the charge amount unverifiable by
the bank to prevent the shop from altering the charged amount without you
knowing. And because of the hashing there is no easy way to brute force
discover your account number.
I see two issues with all of this. One is that I used the account number for
both hashed values. This could be a problem as it means the POS system has
two separate hashes involving your account number, which could make it easier
to reverse the hash (but very hard to do). While the value used in hashing the
charge amount could be changed (e.g., the account + increment or something),
I don't know how much that solves the problem (if it is a problem). Another
solution is that the protocol version number can change what hash is used. This
would allow, e.g., switching from SHA-2 to SHA-3 when it is selected.
The other is my worry that the transaction count could get out of sync. I see
three possible solutions to this is. One is not to worry about it and rely on
the phone waiting for the bank's response to increment the count. Two, the bank
could assume one or two missed transaction increments (e.g., it was cancelled
at the POS system) and simply check two or three possible identification
values. Third, a back-channel communication from the payment app to the bank
could be made to help keep the numbers in sync (something as simple as an HTTPS
connection).
I think this covers phone theft (by encrypting the data on the phone), POS
system lying about the charge amount (by creating a hash with the charge
amount), sniffing (by hashing everything in a way that is unique per
transaction with no repeated values as seen by the POS system) and replay
attacks (by using a transaction counter in a hash).
