(Apologies to OCF management if you think this is the wrong place for
all this, but it has been waiting to be aired for a long time, and
this seems to be the only place where we can discuss it. Peter)
Jean-Paul Billon of Bull wrote:
> Hi Peter,
>
> It is clear that in any case the card should sign all the elements
> identifying the transaction, which includes (among other) the amount. Is
> this enough for a complete security of everyone involved in the payment?
> No, for the following reasons:
>
> 1. Customer protection: when signing the transaction by PIN entry, the
> customer gives a legal acceptation that he cannot repudiate afterward. So,
> he must be absolutely certain that the amount displayed is really the one
> that he accepts. This means that the display of the amount should not be
> controlled by an unsecure PC but only by a certified secure device
> controlling in an opaque mode all the exchanges between the customer
> (display and pinpad) and the customer card. This means that all the APDU
> exchanges with the customer card for making it validating the transaction
> must be driven by a program residing in the secure device, which excludes
> an open PC.
>
Jean-Paul, you misunderstood the concept here: it is the card that
displays the amount of the transaction that the customer authorises,
and the card that controls the subsequent transmission of the
transaction message to the next stage - could be a local transaction
message store either in the till or in the back office (off-line
transaction) or the acuirer's or the card company's (or bank's)
system for an online transaction.
> 2. Merchant protection: in off-line processing mode, the info about
> the accepted transaction are just stored in the terminal until some
> collection from the acquirer. If the elements identifying the transaction
> are properly signed, there is no possibility to tamper the amount. But
> there is still the possibility to alter the stored data, which would make
> them unusable, with the consequence that the merchant would not be paid. On
> an unsecure PC there is also the possibility to download fake programs
> which would simulate the acceptation of transactions for some cards while
> in fact no real transaction were performed. When knowing that such a fake
> program is running, a gang can "buy" goodies for hundred of thousands of
> dollars in a shop before the merchant understand he will never be paid...
>
Yes, there is a risk that the transaction will be voided by altering
it. That is a risk that the merchant must take - balancing that risk
(which should be insurable) against the huge cost of terminal
equipment and the operational problems being identified under the
present system architecture, large merchants in particular will want
to go the way that I suggest (and, via private email overnight, I
understand that the ideas that I put forward have already been
patented, presumably in the USA).
> 3. Payment system protection: if, for instance, Visa stored
> transaction data were systematically altered and unusable for merchant
> payment, the merchant would forbid the use of Visa cards in its shop and
> accept only cards from other brands. In the same spirit, a brand could spy
> the transactions performed by a concurrent and gathers interesting
> statistics. Etc.
>
Sorry, hard luck on the payment system. I don't see why the customers
should suffer (a) extra costs because of high equipment costs in the
shop, (b) delays in implementing chip debit/credit causing delays in
reducing fraud and therefore extra costs to cardholders
> Complete security of the customer,the merchant and the payment system
> implies secure certified EFT/POS terminal devices providing a high level of
> protection against all these kinds of attacks: tempering of the amount
> displayed to the customer, alteration of stored data, secure downloading
> and registration of programs, firewalling between applications runtime
> memory and storage, etc.
>
I believe that there is a growing feeling in the USA that this is all
much much too expensive to implement (a) in the multi-lane retail
store, (b) for home and small office use in a general e-commerce
environment.
> Jean-Paul
>
>
>
>
>
> "Peter W Tomlinson" <[EMAIL PROTECTED]> on 03/18/99 05:16:41 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To: "Lyal Collins" <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED] (bcc: Jean-Paul Billon/US/BULL)
> Subject: Re: [OCF] Basic question
>
>
>
>
> Lyal,
> You wrote:
> > ------- Forwarded Message Follows -------
> > Reply-to: <[EMAIL PROTECTED]>
> > From: "Lyal Collins" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Subject: RE: Re: [OCF] Basic question
> > Date: Thu, 18 Mar 1999 08:51:28 +1100
> > Importance: Normal
> >
> > I support these views that secure PIN entry (or eventually,
> > possibly biometrics) are required.
> > A couple of local manufacturers make smartcard readers with PIN
> > entry keypad for around US$50-80, with a card. I don't see cost
> > as an issue.
> >
> > Lyal
> >
> That is part of the answer to implementing debit/credit smart card
> terminals, and it is the part which, as you say, is being implemented
> now.
> The part which is NOT being implemented now concerns ensuring that
> the amount of charge that I key in (or that is added up on the till)
> is the amount that gets sent securely to (for offline transactions)
> the secure transaction message store and then on the merchant
> acquirer and hence to the bank account or credit card company. It
> seems that EMV are afraid that this amount may get altered as it is
> being transmitted, and thus they want to have the transaction
> messsage store in a secure box which either contains the card slot or
> is closely coupled to it. They don't trust PCs! (Nor do I) They think
> that someone may hack into the PC in order to change the amount
> charged.
> My proposal to solve this, which I here place in the public domain,
> is that the debit/credit smart cards be enhanced so that the amount
> of charge be entered securely into the CARD, and then the amount be
> encrypted by the card before being sent on to the transaction store
> and then to the acquirer. Encryption will, of course, be by signature
> to satisfy certain government requirements. Thus the card does its
> job of authenticating the amount of the charge, and tampering becomes
> evident. This allows the transaction store to be held remotely from
> the till (e.g. in a server in the back office in a supermarket), or
> it allows it to be in a PC (probably in a high reliability
> non-volatile memory module), or it allows it to be at the other end
> of an Internet link.
> Note that this answers the argument from Bull against low cost
> reader/writer implementations of transaction terminals in association
> with a PC.
> Anyone who is interested in implementation help should go and try to
> talk to the NatWest Development Team in London (Dr David Everett),
> who I'm sure will be checking this out and thinking of ways to
> implement it.
>
> Peter Tomlinson
> Iosis, 4 Sommerville Road, Bristol BS7 9AA, UK
> Phone +44 117 924 9231, fax +44 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.
