September 18, 2005

Dave Birch on Payment Tokens

Low value hardware tokens being used for simple closed system payments are on the uprise due to success in mass-transit systems. Financial Cryptographer Dave Birch describes in an article over on Principia. Here's an extract on the tech details.

Payment tokens

So how do payment tokens work to deliver the appropriate levels of both security and privacy? To answer this question, it's necessary to understand how they work. In the general case, the payment token comprises a microprocessor with hardware support for cryptographic operation and an RF interface. There are various standards in this space, but the one most widely used for payment tokens at present is ISO/IEC 14443.

In a typical retail environment the retailer's point-of-sale (POS) terminal and the payment token both contain a microprocessor; the microprocessors communicate using a payment protocol (on top of the ISO 14443 protocol for basic data exchange). When it is time to pay, the customer brings their tag close to the POS terminal. The terminal interrogates the card and gets back the serial number and a cryptogram (a one-time code calculated inside the token). It feeds these to the acquiring bank, which passes them back to the issuer. From the serial number, the issuer knows which account to authorise and from the cryptogram the issuer knows that the token is valid. The cryptogram is made up from the serial number and a transaction counter, encrypted using the token security key. This key is inserted in the token during manufacturing; it is derived from the serial number and a bank master key. Once in the token, it is never divulged. This kind of solution provides:
  • Privacy, because the token ID is meaningless to anyone other than the issuing bank which can map that ID to an actual account or card number;
  • Security, because knowing the token ID is insufficient to create a cloned token. Also, a cloned token would not generate a correct cryptogram because it would not have the right security key and if the transaction is replayed the transaction counter will be wrong.

Please note that this is an example given for the purpose of discussion; it is not meant to represent any of the operational schemes discussed in this article. The security of this typical example scheme is not absolute. There is no cardholder verification (i.e. a signature or a PIN), but all transactions are authorised online, so a lost or stolen card can be blocked as soon as it is reported (although it has to be said that consumers will generally notice the loss or their keys or mobile phone pretty quickly). For this example scheme, it might be useful to add an online PIN only for transactions above 20 or so.

Posted by iang at September 18, 2005 09:39 AM | TrackBack
Comments

"Privacy, because the token ID is meaningless to anyone other than the issuing bank which can map that ID to an actual account or card number;"

But it can still be used for user-tracking, right? The retailer will recognize me as "the same guy, who bought a can of glue last time", won't he?

Posted by: Daniel A. Nagy at September 18, 2005 12:55 PM

Note that low cost hardware tokens don't necessarily have to be low value.

hardware token costs are basically packaging, processing, and the chip.

A chip may have big upfont costs associated with design ... which has to be amortized across the production run. given large enuf production runs, this can approach cents (what the epc effort is looking for with rfid chips).

the actual per chip costs are primarily related to the number of good chips that you get out of a wafer ... and are pretty much unrelated to the kind of chip. complexity of the chip affects yields and therefor the number of the chips per wafer. complexity can also affect size of chip ... which also affects number of chips per wafer. the move from 8in to 12in wafers increase the number of chips per wafer. simple, small chips cut both the upfront design costs ... but also can significantly increase the chips per wafer .... with the manufactoring costs being essentially a per wafer issue.

i once joked that i was going to take a $500 milspec part, decrease the cost by better than two orders of magnitude and make it more secure .... aka complexity itself can represent a security issue ... less complex can be more secure.

if the hardware token purely represents "something you have" authentication ... from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

it is actually possible to do aggresive cost optimization with aggresive simplicity and aggresive reduction in processing ... and still have an extremely high integrity "something you have" authentication token.

aka low cost ... doesn't necessarily mean low integrity ... it must may simply mean low function. however, if an aggresive attitude is taken regarding what is actually required to prove that you have a uniquely specific token for "something you have" authentication .... and everything else is extraneous, contributes to increase cost and complexity ... and may actually lower integrity and security ... then it is possible to have you cake and eat it to ... very low cost and very high integrity.

various aads chip strawman posts ... some involving aggresive KISS and simplicity
http://www.garlic.com/~lynn/index.html#aads

Posted by: Lynn Wheeler at September 18, 2005 02:27 PM

we've frequently pointed out that high integrity token and x9.59 protocol is privacy agnostic.
http://www.garlic.com/~lynn/subpubkey.html#privacy
http://www.garlic.com/~lynn/index.html#x959

the issue of a bank mapping an account for identification is typically a government requirement as part of "know your customer" mandate ... as opposed to an intrinsicly characteristic of the token/protocol.

theoritically you could register for some offshore, anonymous bank account ... and there would be no difference between the x9.59 transaction when used with a bank account that was under "know your customer" mandates and a bank account that was strictly anonomous.

note also that the magstripe token implementations for stored-value, debit, and credit transactions all ride the same rails ... and it is possible to morph all three kinds of magstripe tokens into the same chip token and the same x9.59 transaction ... where the stored-value transactions can be truely anonymous ... while the debit/credit transactions might have accounts under gov. "know your customer" mandate.

It isn't strictly a characteristic of the x9.59 protocol or the token ... it is a characteristic of govs. having mandates for "know your customer" with respect to bank accounts.

one of the characteristics of x9.59 protocol is that it can carry a simple digital signature for authentication; where the verification of the digital signature implies "something you have" authentication ... aka the person originating the transaction has access to and use of a unique private key, uniquely contained in a specific hardware token/chip.

of course, all bets are off if digital sigantures also
require the appending of x.509 identity certificates ... which actually does morph even the simplest of authentication protocols into heavy weight identification protocol

a recent post regarding the confusing of authentication and identificaiton
http://www.garlic.com/~lynn/aadsm21.htm2 Another entry in the internet security hall of shame

Posted by: Lynn Wheeler at September 18, 2005 02:41 PM

(fwd from elsewhere)

> http://www.nccmembership.co.uk/pooled/articles/BF_WEBART/view.asp?Q=BF_WEBART_171100


Interesting article, but despite the title, there seems to be no mention of any of the actual security (or privacy) challenges involved in deploying massive RFID payment systems. E.g. I can extract money from your RFID payment tag whenever you walk past, whether you authorized the transaction or not. And even assuming you wanted it this way, if your Nokia phone has an RFID chip in it, who's going to twist the arms of all the transit systems and banks and ATM networks and vending machines and parking meters and supermarkets and libraries? Their first reaction is going to be to issue you an RFID themselves, and make you juggle them all, rather than agreeing that your existing Nokia RFID will work with their system. If you lose your cellphone, you can report it gone (to fifty different systems), and somehow show them your new Motorola RFID, but how is each of them going to know it's you, rather than a fraudster doing denial of service or identity theft on you?

Then there's the usual "tracking people via the RFIDs they carry" problem, which was not just ignored -- they claimed the opposite: "This kind of solution provides privacy, because the token ID is meaningless to anyone other than the issuing bank which can map that ID to an actual account or card number." That is only true once -- til anyone who wants to correlates that token ID "blob" with your photo on the security camera, your license plate number (and the RFIDs in each of your Michelin tires), the other RFIDs you're carrying, your mobile phone number, the driver's license they asked you to show, the shipping address of the thing you just bought, and the big database on the Internet where Equifax will turn a token ID into an SSN (or vice verse) for 3c in bulk.

The article seems to have a not-so-subtle flavor of boosterspice. Anybody got a REAL article on contactless payments and security challenges?

John

Posted by: John Gilmore at September 20, 2005 10:29 AM

John (and Bob and Ian),

Thanks for the interest in the article, which I really appreciate. I can safely say I had no idea that NCC IT Advisor was so widely read!

> http://www.nccmembership.co.uk/pooled/articles/BF_WEBART/view.asp?Q=BF_WEBART_171100
>
> Interesting article,

Thanks, much appreciated.

> but despite the title, there seems to be no
> mention of any of the actual security (or privacy) challenges involved
> in deploying massive RFID payment systems.

Please find enclosed an updated draft of a longer version, which I hope helps to stimulate this debate further.

>E.g. I can extract money
> from your RFID payment tag whenever you walk past, whether you
> authorized the transaction or not.

You can extract a transaction, certainly. But not money: the only place the money can go to is a merchant acquiring account (if you're talking about Visa, MC, Amex schemes).

> And even assuming you wanted it
> this way, if your Nokia phone has an RFID chip in it, who's going to
> twist the arms of all the transit systems and banks and ATM networks
> and vending machines and parking meters and supermarkets and
> libraries?

Transit is a special case, so let's put that to one side for a second.

As for banks, supermarkets etc: they're already installing the terminals.

> Their first reaction is going to be to issue you an RFID
> themselves, and make you juggle them all,

Just like your existing payment cards.

>rather than agreeing that
> your existing Nokia RFID will work with their system.

No, not really. Your Nokia phone will become your Visa or MC card and therefore work with the terminals.

Things may develop in a different direction in the world of NFC, but that's a different issue (ie, phone as POS terminal rather than phone as card).

>If you lose
> your cellphone, you can report it gone (to fifty different systems),
> and somehow show them your new Motorola RFID, but how is each of them
> going to know it's you, rather than a fraudster doing denial of
> service or identity theft on you?

Very good point, and this will have to be addressed.

> Then there's the usual "tracking people via the RFIDs they carry"
> problem, which was not just ignored -- they claimed the opposite:

Remote tracking is a non-issue with these schemes, the range is too short. I'll track the tag on your shirt rather than your card.

> "This kind of solution provides privacy, because the token ID is
> meaningless to anyone other than the issuing bank which can map that
> ID to an actual account or card number." That is only true once --
> til anyone who wants to correlates that token ID "blob" with your
> photo on the security camera,

Or the loyalty card I used in the transaction. But your point is correct: using my MasterCard keyfob gives me privacy from the clerk etc, but of course it is not designed to be impervious to correlated data fusion.

> your license plate number (and the RFIDs
> in each of your Michelin tires), the other RFIDs you're carrying, your
> mobile phone number, the driver's license they asked you to show, the
> shipping address of the thing you just bought, and the big database on
> the Internet where Equifax will turn a token ID into an SSN (or vice
> verse) for 3c in bulk.

That's a different kind of privacy. I am not claiming that the payment tokens being introduced provide any kind of anonymity. Nor do they and nor, as far as I am aware, will it ever be one of their design goals.

> The article seems to have a not-so-subtle flavor of boosterspice.

Absolutely. I love contactless payments.

> Anybody got a REAL article on contactless payments and security
> challenges?

Please let me have a copy as I'm interested in anything around this topic.

And thanks again for taking the trouble to comment: I genuinely do value the input.

Best regards,
Dave Birch.

Posted by: Dave Birch at September 20, 2005 03:19 PM

If the token could encrypt the message to the issuing bank that would address the privacy concerns. Maybe even a fixed per-bank AES key would work. That would not put much more computational load on the token than it must have to produce this so-called "cryptogram".

Posted by: Cyphrpunk at September 23, 2005 01:48 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.