[fc-discuss] Financial Cryptography Update: Dave Birch on Payment Tokens

[iang@iang.org]

(((((( Financial Cryptography Update: Dave Birch on Payment Tokens ))))))

                           September 18, 2005


------------------------------------------------------------------------

https://www.financialcryptography.com/mt/archives/000552.html



------------------------------------------------------------------------

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.

======8<=============8<=============8<=======
http://www.nccmembership.co.uk/pooled/articles/BF_WEBART/view.asp?Q=BF_
WEBART_171100

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.
======8<=============8<=============8<=======

-- 
Powered by Movable Type
Version 2.64
http://www.movabletype.org/