To: [EMAIL PROTECTED] Subject: RE : [OCF] Basic question Reply-to: [EMAIL PROTECTED] Date: Mon, 22 Mar 1999 11:06:48 Jeng-Ming, Sorry, our email system can't display all your message on the screen because it was sent with very long lines - but we printed it OK, I think. Going back to my message, the PIN pad must be constructed so that: 1. The only route to the display is from the card 2. The keypad sends information only to the card (and in a secure form, as with the EMV V3.1.1 encrypted PIN transmission from keypad to card). And your message adds something else that needs to be explicitly stated: it must not be possible to modify the software or firmware in the PIN pad - no downloading. The PIN pad must be a sealed unit that cannot be modified. So the sequence, when using a PC to carry out the transaction, is: - User enters amount to be charged via the PC kbd. - PC sends message to card to tell it how much to charge. - Card sends message to the PIN pad's display to say how much it has been told to charge. - User either accepts by pressing Accept key on PIN pad, or rejects by pressing Cancel key on keypad. If user does nothing, a timeout causes the amount to be rejected. The Accept or Cancel keypress goes directly and securely tothe card, and the card can then complete the transaction (or cancel it). No, there are no standards for this PIN pad yet. If the payment schemes can be persuaded to go this route, they will have to issue a specification and they will have to certify the devices. That means that the device must have a built-in ID that gets sent up the line to the acquirer in order to satisfy the scheme that the transaction has come from a certified keypad. Patents protecting concepts or ideas? Here in the UK we don't think that they can, but the USA has been issuing patents like this for several years. Peter ------------------------------------------------------------- > From: [EMAIL PROTECTED] > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: RE : [OCF] Basic question > Date: Mon, 22 Mar 1999 15:34:32 +0800 > May I ask some stupid questions: > > 1. How does the card obtain direct confirmation from the cardholder to verify that the amount of the transaction is correct? Is there any global standard (ISO or ANSI) or de facto standard describing > 2. In my understanding, patents didn't protect concepts or ideas. So, we should not mind a USA organization holds patents that may clude this concept, the important things are the methods that impl> > Jeng-Ming Duann > > > > -----Original Message----- > From: Peter W Tomlinson [SMTP:[EMAIL PROTECTED]] > Sent: Saturday, March 20, 1999 12:11 AM > To: [EMAIL PROTECTED] > Subject: Re: [OCF] Basic question > > Following the discussions in the Open Card Forum this week, and after > consulting a few other people in the industry, the following is an > attempt to describe more clearly the concept for a low cost secure > method to implement a debit/credit terminal. This concept is intended > to be applied to the personal home e-commerce situation (PC or TV set > top box), small office e-commerce situation, PC-based till system, and > large networked supermarket till systems. > > > The principles behind this concept are: > > 1. The card obtains direct confirmation from the cardholder to verify > that the amount of the transaction is correct > > 2. The card then authenticates the transaction record > > 3. The equipment used to transmit the transaction record (including > perhaps storing it for a while before forwarding it) must be reliable > but need not be tamper proof and need not be tamper evident > > > The result of all this is that, if the transaction proceeds, the > customer gets assurance that the value transferred is correct. The > organisations processing the transaction (retailer, acquirer, etc) > must on their part shoulder responsibility for processing those > transactions reliably and without tampering - and the risk to them is > regarded as an insurable risk, so the quality levels for their > equipment are set as a tradeoff between the cost to the equipment > owner and the commercial risk to the payment schemes, to banks, to the > acquirer, and to the merchant. Where the transaction is first > processed in a PC owned by the cardholder or used by him in a personal > capacity, it is likely that we are dealing with an Internet > transaction or something similar. In this case, the cardholder takes > responsibility for following the transaction through to the stage > where a commercial service provider (e.g. ISP, merchant web site, > acquirer) takes over responsibility - he should expect to see a > confirmation message or receipt, and he should compare that with the > value transfer that he authorised. > > > The proposal is that the user card be handled in a separate unit which > is a secure keypad plus card reader/writer plus display - let us call > this the PIN pad for convenience. The design of this PIN pad must be > such that the only route to the display is from the card, and the only > route from the keypad is to the card. Thus the transaction message > creation process includes the following sequence: > > 1. Terminal equipment sends message to card giving transaction value > > 2. Card displays transaction value on display > > 3. Cardholder verifies (by pressing a �Yes?key) or rejects (by > pressing a �Cancel?key or doing nothing) the transaction > > > If �Yes? the card authenticates the transaction message and sends it > off to the next stage (local store, remote store, acquirer) > > > The only route from the transaction processing equipment (e.g. from a > PC to which the PIN pad is connected) to the display is via the card. > To display a message from the PC, a display command is sent to the > card. Interlocks in the card prevent the display command from being > used to cause a fake transfer confirmation request to be displayed to > the cardholder in place of the true confirmation request from the > card. When there is no card in the reader/writer, display shows > �Insert card? As there will be a microcontroller in the PIN pad, it > can also display a small number of other system messages (e.g. s/w > version number displayed for a short time after power on). > > > Note that there are now designs of card which incorporate flexible > LCD-style displays, and these could be used to provide an alternative > realisation of this concept. > > > Now the payment processing functions previously carried out by �Level > 2?software in a monolithic terminal are, in this scenario, more > likely to be carried out in a back office system (e.g. supermarkets), > a combination of web browser and web server (standard open system > e-commerce configuration), or a proprietary system running partly in > the user�s PC and partly at a remote site. The argument being put > forward here includes the thesis that such payment processing systems > do not need be type approved, but are allowed to carry an imprimatur > if they have been type approved. The worst that they can do is lose or > corrupt a transaction; the best that they can do is provide new styles > of payment processing. > > > The EMV schemes are required, as part of this payment method, to > provide management services for the issued card base, even through > third party software and systems which are not type approved. > Management here includes security key management (a service which it > is believed is not currently provided), card blacklisting and card > blocking. > > > The cost of a volume manufactured secure PIN pad unit of the type > described here is expected to be under 30 USD. The physical concept is > already produced by several manufacturers and used, for example, by > Proton for Internet transactions - but whether the internal > organisation of these existing units is as required here is unknown, > but it is unlikely to be what we require. > > > The cards themselves need internal software to a level beyond the > current EMV V3.1.1 (which itself has moved beyond the V3.0 UKIS cards > which are just starting to roll out here in the UK). The cards need to > move on from being just an electronic form of a mag stripe card to > being a true intelligent microprocessor card, providing all the secure > functions required for debit/credit. > > > Note that, from my brief introduction to this concept on the OCF, a > message has reached me to the effect that a USA organisation holds > patents that may include this concept. > > Peter Tomlinson > > Iosis, 4 Sommerville Road, Bristol BS7 9AA, UK > Phone +44 117 924 9231, fax +44 117 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. > > 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.
