The Open Card Forum discussion over the last week has been very
interesting, and has illuminated numerous corners of the business of
implementing terminals for debit/credit applications. In the glow of
these contributions, some of the simplicity of today's debit/credit
cards has been seen clearly. Up till now, the only specifications for
debit/credit terminals have been the EMV specifications, the
derivative specifications coming separately from E, M and V, and the
national specifications (UKIS here in the UK being the only one
implemented so far). The OCF traffic has identified some ideas for
implementing different types of terminals, and also the contribution
from Thomas Schaeck has been useful, in that it shows how GeldKarte
takes a system design approach to card to card transfers over insecure
links. Other e-purse schemes also do this, notably Proton and Mondex.
Proton has not yet let me into the secrets of how it works. As for
Mondex, I am subject to NDA and cannot give details about it in
public.
But why do we have a problem? What do we want to do about it? And what
is the difference between e-purse and debit/credit?
The problem for debit/credit is security and reliability of all types
of transaction, at low cost. Security includes fraud and tampering.
Reliability includes loss of the transaction message and corruption of
the message. Corruption of the message and tampering with the message
both render it equally useless. Cost includes capital cost of the
equipment as well as transmission and processing cost for the
transaction.
The difference between debit/credit and e-purse is not always easy to
see. At one extreme, debit/credit starts with a card and creates a
transaction message. The message makes its way to the cardholder's
account (either in a bank or in a credit card company). The message
may be stored somewhere on the way, for forwarding later (offline
transactions). At the other extreme, many e-purse schemes carry out
card to card transfer directly between a user card and a merchant
card. Later, the e-purse transactions may be sent on to a card company
or bank account.
The basic way to process debit/credit at the point of sale is through
a dedicated terminal. This terminal has the card reader/writer slot, a
keypad, a display, a secure transaction message store, a data comms
interface, a printer, and possibly an external interface so that the
amount to be charged can be entered directly by the till. Because the
device is certified secure by the card scheme, the transactions are
guaranteed by the scheme and the transaction fee charged by the scheme
is low. The EMV and related specifications only describe this type of
terminal, and the type approval schemes only approve this type of
terminal.
>From the point of view of the merchant who wants to process
debit/credit through his till or till system in his retail store, with
the customer present, the problem is that the dedicated terminal is
expensive and is not easily integrated into his store system. He wants
a low cost 'front end' to accept the customer's card, he wants to
process the transaction through his till system, and he wants to store
the offline transaction messages at a place convenient to him - just
like he does with mag stripe transactions at the moment.
>From the point of view of the e-commerce user, he is not on the
merchant's premises and so his transaction is classed as 'cardholder
not present'. Thus the transaction is not guaranteed, and someone is
going to charge a large fee in order to, in effect, insure the
transaction. And the merchant may not even be given an account by an
acquirer unless he has a secure server (or rents a secure transaction
server's services) - that's expensive.
The task is (a) to design suitable low cost card accepting devices
which handle the user card but leave the rest of the transaction to be
handled in relatively insecure equipment (e.g. PCs), while still
maintaining the guarantee of non-repudiation for the merchant, and (b)
to make such modifications to the card specs as are required to assist
in making the card accepting device low cost. From a system point of
view, the retail store system and the remote e-commerce user pose the
same problem: how to ensure that the card authenticates the
transaction, independent of anything between the immediate vicinity of
the card on the one hand and the cardholder's account on the other
hand, with the card being sure that the amount of the transaction is
the amount authorised by the cardholder.
What we have seen this last week is that there are a variety of
solutions. I am aware that there is also a project about to start in
this area, with the aim of developing yet another secure terminal. The
project is believed to be called FINREAD, has European Community
finance, and I have not been able to track it down, so can anyone give
me a contact name and email address for the organisations involved in
this project? What we do not have is any suitable specifications from
E, M or V, so at the moment we cannot develop such a terminal for
debit/credit with any confidence that it will pass type approval.
Some of the solutions to the problem are, we read, the subject of
patents, but that should not prevent them being made generally
available under the umbrella of, say, a European standard (see later).
I proposed one solution, which would fit well on the PC on my desk.
But that may not suit everyone. In particular, Europe asks us to be
very sure that we cater for people with special needs. In any case,
why should we just define a solution for debit/credit?
Multi-application cards are likely to have both debit/credit and
e-purse in them, so one terminal should be able to handle both types
of value transfer transaction, with security adeqaute for each scheme.
For the debit/credit transaction to be guaranteed, or for the e-purse
transaction not to affect the money supply, we need to have a security
model for the whole end to end transaction system: card, computer
systems for transaction processing, message store, data transmission,
maybe another card. That security model needs to have both the
mechanism for guaranteeing the transaction and a mechanism for
repairing the entire scheme if it is damaged (for example, fraud by
cloning of cards, or potential fraud opportunities by revealing of
secret keys). That security model has to assume that non-secure
devices are going to be used to process transactions - and thus the
cardholder's card number may be made public, but the security provided
by the card must ensure that that card number cannot be used without
the real cardholder's card being active.
Now that we are moving into a multi-application environment, I
propose that the basics of the transaction guarantee mechanism be
governed by public standards rather than by individual scheme
specifications. Since the EC is so keen on quality of service to the
public, and so keen on taking us forward into the information society,
so keen on enabling self-service for so many transactions, and so keen
on 'Design for All' (i.e. the special needs of some people, common
user interfaces for the ordinary person, and the enthusiasm of techno
gurus), it seems that the right place to co-ordinate all this is
within the EC, and within the EC the group to do it is the ICT
Standards Board (they sit above CEN and ETSI).
In summary, the retailer wants to process smart card transactions just
like he processes mag stripe transactions: through his PC-based system
or network. He wants more transactions offline, to reduce cost. The
card should be used to guarantee the transactions, not the terminal.
The e-commerce user wants a low cost way to use his card through the
web browser on his PC. Again, the card should guarantee the
transaction, not the terminal. One solution for the terminal hardware
is a secure PIN pad with card slot and display, configured as
described earlier, and designed so that the PC cannot alter what it
does. That solution requires the cards to be modified, and probably
all the solutions do - the debit/credit card spec will have to migrate
beyond EMV V3.1.1, and the UK will have to accept PIN at point of
sale. An overall standard, if properly crafted, will make possible a
variety of solutions to the problem.
Peter Tomlinson
Iosis, 4 Sommerville Road, Bristol BS7 9AA, UK
Phone +44 117 924 9231, fax +44 117 924 9233
Email [EMAIL PROTECTED], web www.iosis.co.uk
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
