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.
