This is an interesting discussion, as is the list at times.
I have 2 comments/questions:
One issue which Peter's proposal, although sound, does not seem to
address is the move toward separation of pin pad and reader.
ie there are cases where Smartcard power requirements can make a
TV-like remote control too heavy or an unacceptable shape.
Insteaed, the smartcard is in a Set Top box, operated by wireless
or infrared.
The explosion in resources devoted to Bluetooth, Home Network
Alliances and like technologies etc increase the likelihood that
PIN pad and reader will not be co-located in all cases.
Peter's conceptual model may also make some transactions models in
existence obsolete e.g mobile phone handsets as authorisation
terminals.
Does anyone know of any work underway to merge financial industry
tamper-resistance to such devices ?
Cheers,
Lyal
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, March 23, 1999 7:09 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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.
>
> 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.
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.
