Hi Dirk,
Two remarks on your thoughts.
1. You wrote:<<Non-technical people will not know how to distinguish a
certified
device from a non-certified device or even from a certified but tampered
with
device. The same questions you raise with regards to the PC (and I agree
completely with what you are concerned about, don't misunderstand me) can
be
raised about a certified card-acceptance device. Perhaps smart cards with
an
LCD display are the solution after all...>>
I agree partly with you. If a dishonnest retailer wants to replace its
certified terminals by uncertified and fake ones, the customer will not see
the difference. This is far less easy however than just modifying a program
on a PC. A certified terminal is a physical device you don't buy freely at
the corner's shop (contrarily to a PC)! And to download inside a fake
program that can simulate a real one to deceive both the card and the
acquirer, if not impossible, is very difficult, because you need the
downloading program and the signature keys from the acquirer... Moreover,
in the case of electronic purses, a crucial part of the transaction
security is performed by a special merchant card (SAM) inserted in the
terminal, and you cannot modify such a smart card.
And for the protection of the retailer from dishonnest customer attacks, it
is clear that replacing all the terminals of a shop by fake ones is more
difficult to do without being noticed by the retailer than downloading a
fake program into the retailer's PC....
A second point to notice, is that the need of additional security through
certified terminals is not proper to smart card based payment. The same
need for security of amount display and PIN entry exists for magnetic
stripe payment.
2. You wrote also: <<Well, no system is ever going to be completely secure.
Also, if I'm a merchant
having wares worth "hundreds of thousands of dollars" in my shop I'd
probably
would have an online connection to make sure that I get my money in the
end.>>.
Well, I'm not sure the point is there. Online connection (which is one of
the costly thing smart cards can avoid to use systematically) does not
provide more security to the retailer if his computers are tempered. A fake
program can simulate an online connection while performing no connection at
all! Once again the problem is not specific of smart cards: the same
problems arise with magnetic stripe based payment (with in this case no
additional security provided by the card) and I am sure that for such a
kind of payment retailers don't rely on an open PC with a connected
transparent magnetic stripe reader!! Smart cards can bring a much higher
degree of security both in online and offline processing, but specific,
secure, non open, certified computers (POS/EFT terminals) are required,
like it is the case for magnetic stripe based POS, but more sophisticated
than it is the case for magnetic stripes in order to drive sophisticated
transactions with smart cards.
Jean-Paul
[EMAIL PROTECTED] (Dirk Husemann) on 03/19/99 03:18:35 AM
To: Jean-Paul Billon/US/BULL
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [OCF] Basic question
Jean-Paul, Peter, et al,
>>>>> "jb" == Jean-Paul Billon <[EMAIL PROTECTED]> writes:
jb> Hi Peter,
jb> It is clear that in any case the card should sign all the elements
jb> identifying the transaction, which includes (among other) the
amount. Is
jb> this enough for a complete security of everyone involved in the
payment?
jb> No, for the following reasons:
jb> 1. Customer protection: when signing the transaction by PIN
entry, the
jb> customer gives a legal acceptation that he cannot repudiate
afterward. So,
jb> he must be absolutely certain that the amount displayed is really
the one
jb> that he accepts. This means that the display of the amount should
not be
jb> controlled by an unsecure PC but only by a certified secure device
jb> controlling in an opaque mode all the exchanges between the
customer
jb> (display and pinpad) and the customer card. This means that all the
APDU
jb> exchanges with the customer card for making it validating the
transaction
jb> must be driven by a program residing in the secure device, which
excludes
jb> an open PC.
The problem is much more subtle than just having a "certified"
device. Non-technical people will not know how to destinguish a certified
device from a non-certified device or even from a certified but tampered
with
device. The same questions you raise with regards to the PC (and I agree
completely with what you are concerned about, don't misunderstand me) can
be
raised about a certified card-acceptance device. Perhaps smart cards with
an
LCD display are the solution after all...
jb> 2. Merchant protection: in off-line processing mode, the info
about
jb> the accepted transaction are just stored in the terminal until some
jb> collection from the acquirer. If the elements identifying the
transaction
jb> are properly signed, there is no possibility to tamper the amount.
But
jb> there is still the possibility to alter the stored data, which
would make
jb> them unusable, with the consequence that the merchant would not be
paid. On
jb> an unsecure PC there is also the possibility to download fake
programs
jb> which would simulate the acceptation of transactions for some cards
while
jb> in fact no real transaction were performed. When knowing that such
a fake
jb> program is running, a gang can "buy" goodies for hundred of
thousands of
jb> dollars in a shop before the merchant understand he will never be
jb> paid...
Well, no system is ever going to be completely secure. Also, if I'm a
merchant
having wares worth "hundreds of thousands of dollars" in my shop I'd
probably
would have an online connection to make sure that I get my money in the
end.
Just a couple of thoughts on these topics.
Dirk
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.
