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.
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.
