Jean-Paul,
Thanks for your further contribution - but you may not be very happy
with my responses.
Most of my comments are embedded in the copy of your message. These
comments should be read along with my comments on your 18 March
message.
Peter
> From: [EMAIL PROTECTED] To:
> [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date:
> Mon, 22 Mar 1999 15:08:57 -0500 Subject: RE : [OCF]
> Basic question
>
> 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.
This is a long way from a complete EFT/POS terminal, because the
PINpad does not have to interpret any of these APDUs, just route
them. An APDU from the PC to the card will be interpreted as follows:
Value to be transferred or charged: the card takes this in and
prepares to issue a certificate for a transaction message
incorporating this value.The card then issues an APDU which says
'route this data to the display in the PINpad'. The response from the
keypad is routed into the card in a secure manner by another APDU. If
the card decides that that response is valid, it issues the
certificate. (Note that I'm not a security expert, but the
certificate is what Philip Andreae tells me secures the transaction).
THE CARD DOES THE WORK. THE 'TERMINAL' (keypad + card slot + display
+ interface to PC) IS ONLY THERE TO CONNECT THINGS TOGETHER IN A
TRUSTED MANNER.
> 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.
>
For stand-alone use (e.g. in my favourite bar that only has one
till), this 500 dlr terminal is OK. When a large retailer has been
happily accepting mag stripe cards for years using a slot in a 30-100
dlr keyboard, he does not want to pay 100-300 dlrs for a PINpad. He
wants to pay no more than 75 dlrs. Remember, every till position
needs one of these. He expects the off-line transaction store to be
in his back office computer, and the card will be on-line to that
transaction store until the card is satisfied that the message has
been securely transferred to that store (for details of the method of
construction of that store, see the comments on the earlier message).
So he does not need a 'highly secured transactional IC card reader'
(quote from the bottom of page 1 of the ISIS info fiche for the
FINREAD project).
For home use on my PC, I will pay 50 dlrs, but no more. All my
transactions should be on-line, so I do not need a 'highly secured
transactional IC card reader'.
Thus the PINpad does not need SET software - it runs in the PC.
> 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.
>
> ***** THIS IS INTERNAL MAIL FROM INTERNET *****
>
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.
