Jean-Paul
We have got to keep the costs of e-commerce down, or else it will not
get used. It seems to me that your scenario results in an expensive
terminal, even for the home PC user. Either the home user will have
to purchase this terminal if the merchant is to be charged less than
2% merchant fee, or the user will use a non-approved terminal (simple
card reader/write with software in the PC) and the merchant gets
stuck with 'cardholder not present' fees (6% to 10%, with the higher
charge applying if he uses a thrid party secure server). This is all
too expensive.
Similarly, the large retailer wants 75 dlr max PIN pads, not 250 dlr
terminals at each till position. The way this works is that the large
retailer has a secure transaction store in his back office system,
alongside the transaction store that he presently has for mag stripe
transactions. The secure store can be a PC adapter board containing
non-volatile memory and a crypto processor controlling access to that
memory. During a transaction which is off-line to the acquirer, the
card is then in fact on-line to the transaction storage module in the
back office. For a small retailer with just one till, the transaction
store module can be in the till (which will be a PC-based system),
and should not cost more than 50 dlrs. Note that this system
architecture was worked out between Philip Andreae and myself in the
middle of last year, and I hereby put it in the public domain (since
I don't have the money to develop it), but design copyright is
claimed by Control G Ltd (Iosis) of Bristol, England, and Philip
Andreae & Associates of Genval, Belgium.
Yes, when using a PC or other open system to transmit messages, there
is a risk of tampering - but the card to transaction store messaging
(and card to acquirer for an on-line transaction, and transaction
store to acquirer for forwarding of off-line transactions) will be
tamper evident. Yes, the commercial risks that you describe are
there, but they are not a problem for us with mag stripe, so why will
they be a problem with smart cards?
THE CARD DOES THE WORK OF SECURING THE TRANSACTION MESSAGE. THE
PINPAD, DESIGNED AS I HAVE DESCRIBED, ALLOWS THE CARD TO TRUST THE
VALUE MESSAGE SENT TO IT. I believe that this is the original
philosophy agreed by the major schemes when they started development
of smart credit/debit (just as they intended to be ISO compliant).
Now, can you tell me if the FINREAD project aims to specify the low
cost solution that I have outlined, or the expensive solution that
you have outlined? Or perhaps both, as there may still be a niche
market for your solution.
Peter
------------------------------------------------------
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Date: Thu, 18 Mar 1999 13:53:11 -0500
> Subject: Re: [OCF] Basic question
>
> 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.
>
> 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...
>
> 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.
>
> 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.
>
> 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.
>
>
>
>
>
>
>
> ***** 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.
