Jeng-min, I think your question far from being stupid. Peter's proposal
implies a pinpad able to interpret some answer APDU coming from the card
(amount validated by the card), which means that specific softwares must be
loaded into the pinpad. This is not very far from what is expected from a
complete EFT/POS terminal.
Peter speaks, as an alternative possibility, of a LCD-diplay on the card.
This is technically possible, but banks are requiring very low prices for
customer cards, and this is not yet compatible with on card display.
To answer Peter: secure complete EFT/POS terminals for point of sales are
not so expensive (compared to PC). The average current prices are in the
range 500-1000 US dollars. The price has not been a blocking factor in the
countries where smart cards have been massively deployed, like France. I
don't think UK or US retailers are poorer than french ones....
Secure opaque PinPads for e-commerce with a SET like software inside, are
already proposed with an average price in the range 100-300 US dollars. The
same kind of terminals connected to PC is also available to be used by
physicians for healthcare cards.
Jean-Paul
[EMAIL PROTECTED] on 03/21/99 11:34:32 PM
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
cc: (bcc: Jean-Paul Billon/US/BULL)
Subject: RE : [OCF] Basic question
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
May I ask some stupid questions:
1. How does the card obtain direct confirmation from the cardholder to
verify that the amount of the transaction is correct? Is there any glob=
al
standard (ISO or ANSI) or de facto standard describing about this? And,=
how
does the card display transaction value on display of so called PIN pad=
? In
our design, we have to download device applications (in correspondent t=
o
card applications) into PIN pad to handle these keypad inputs and displ=
ay
outputs via monitoring the commands to/from card, is this manner correc=
t?
2. In my understanding, patents didn't protect concepts or ideas. So, w=
e
should not mind a USA organization holds patents that may include this
concept, the important things are the methods that implement the concep=
ts,
is that right?
Jeng-Ming Duann
-----Original Message-----
From: Peter W Tomlinson [SMTP:[EMAIL PROTECTED]]
Sent: Saturday, March 20, 1999 12:11 AM
To: [EMAIL PROTECTED]
Subject: Re: [OCF] Basic question
Following the discussions in the Open Card Forum this week, and after
consulting a few other people in the industry, the following is an
attempt to describe more clearly the concept for a low cost secure
method to implement a debit/credit terminal. This concept is intended
to be applied to the personal home e-commerce situation (PC or TV set
top box), small office e-commerce situation, PC-based till system, and
large networked supermarket till systems.
The principles behind this concept are:
1. The card obtains direct confirmation from the cardholder to verify
that the amount of the transaction is correct
2. The card then authenticates the transaction record
3. The equipment used to transmit the transaction record (including
perhaps storing it for a while before forwarding it) must be reliable
but need not be tamper proof and need not be tamper evident
The result of all this is that, if the transaction proceeds, the
customer gets assurance that the value transferred is correct. The
organisations processing the transaction (retailer, acquirer, etc)
must on their part shoulder responsibility for processing those
transactions reliably and without tampering - and the risk to them is
regarded as an insurable risk, so the quality levels for their
equipment are set as a tradeoff between the cost to the equipment
owner and the commercial risk to the payment schemes, to banks, to the
acquirer, and to the merchant. Where the transaction is first
processed in a PC owned by the cardholder or used by him in a personal
capacity, it is likely that we are dealing with an Internet
transaction or something similar. In this case, the cardholder takes
responsibility for following the transaction through to the stage
where a commercial service provider (e.g. ISP, merchant web site,
acquirer) takes over responsibility - he should expect to see a
confirmation message or receipt, and he should compare that with the
value transfer that he authorised.
The proposal is that the user card be handled in a separate unit which
is a secure keypad plus card reader/writer plus display - let us call
this the PIN pad for convenience. The design of this PIN pad must be
such that the only route to the display is from the card, and the only
route from the keypad is to the card. Thus the transaction message
creation process includes the following sequence:
1. Terminal equipment sends message to card giving transaction value
2. Card displays transaction value on display
3. Cardholder verifies (by pressing a ?es?key) or rejects (by
pressing a ?ancel?key or doing nothing) the transaction
If ?es? the card authenticates the transaction message and sends it
off to the next stage (local store, remote store, acquirer)
The only route from the transaction processing equipment (e.g. from a
PC to which the PIN pad is connected) to the display is via the card.
To display a message from the PC, a display command is sent to the
card. Interlocks in the card prevent the display command from being
used to cause a fake transfer confirmation request to be displayed to
the cardholder in place of the true confirmation request from the
card. When there is no card in the reader/writer, display shows
?nsert card? As there will be a microcontroller in the PIN pad, it
can also display a small number of other system messages (e.g. s/w
version number displayed for a short time after power on).
Note that there are now designs of card which incorporate flexible
LCD-style displays, and these could be used to provide an alternative
realisation of this concept.
Now the payment processing functions previously carried out by ?evel
2?software in a monolithic terminal are, in this scenario, more
likely to be carried out in a back office system (e.g. supermarkets),
a combination of web browser and web server (standard open system
e-commerce configuration), or a proprietary system running partly in
the user? PC and partly at a remote site. The argument being put
forward here includes the thesis that such payment processing systems
do not need be type approved, but are allowed to carry an imprimatur
if they have been type approved. The worst that they can do is lose or
corrupt a transaction; the best that they can do is provide new styles
of payment processing.
The EMV schemes are required, as part of this payment method, to
provide management services for the issued card base, even through
third party software and systems which are not type approved.
Management here includes security key management (a service which it
is believed is not currently provided), card blacklisting and card
blocking.
The cost of a volume manufactured secure PIN pad unit of the type
described here is expected to be under 30 USD. The physical concept is
already produced by several manufacturers and used, for example, by
Proton for Internet transactions - but whether the internal
organisation of these existing units is as required here is unknown,
but it is unlikely to be what we require.
The cards themselves need internal software to a level beyond the
current EMV V3.1.1 (which itself has moved beyond the V3.0 UKIS cards
which are just starting to roll out here in the UK). The cards need to
move on from being just an electronic form of a mag stripe card to
being a true intelligent microprocessor card, providing all the secure
functions required for debit/credit.
Note that, from my brief introduction to this concept on the OCF, a
message has reached me to the effect that a USA organisation holds
patents that may include this concept.
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.
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.
=
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.
