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.
