Comments: Dave Birch on Payment Tokens

"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.
MT::App::Comments=HASH(0x5642635f68a8) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.