I followed the recent discussion about security of payments and would like to discuss a different approach. Usually, card-to-card payment protocols are secured end-to-end: All sensitive messages exchanged between a purse card and a merchant card are secured by MACs (Message Authentication Codes) or digital signatures. One scheme that works this way is the German GeldKarte scheme. This is a real life purse scheme, about 50,000,000 GeldKarte cards were issued in Germany and pilots are starting in other European countries. It is impossible to modify messages exchanged between a purse card and a merchant card. However, without special card readers, it is possible for a criminal merchant to display a certain amount to be paid in a payment applet but to debit a bigger amount from the card. Also, there is a possibility that a virus on the customers PC could open a connection to the server of a criminal merchant and debit a certain amount from the purse card if it is inserted. Another threat would be a virus that connects to the server of a law abiding merchant and debits a certain amount just for fun. To make card-to-card payment schemes secure for the Internet, no debit operation may be possible without "trusted" confirmation by the customer. Such a "trusted" confirmation can be achieved by usage of a smart card reader with filter function. Such a reader would have an EEPROM memory holding critical payment APDUs patterns, logic for filtering these APDUs out of the APDU stream, a little display for showing amounts contained in these APDUs, and a confirmation button for confirming the amount to be paid. Assuming that the payment is conducted by a payment applet that has access to a purse card via a card reader with filter function and a servlet that has access to a merchant card, it would work like this: 1. The payment applet connects to the payment servlet. 2. The payment is initiated. 3. Non-critical APDUs are exchanged between purse and merchant card. The card reader lets all these non-critical APDUs pass. 4. The critical debit APDU is sent from the servlet to the applet and from the applet to the card reader. 5. The card reader identifies the critical APDU, displays the amount contained in the APDU and waits for the customer to press the confirmation button. 6. The customer presses the confirmation button. 7. The card reader forwards the confirmed command to the purse card. 8. The purse card validates the MAC or signature that protects the command and performs the debit if validation is successful. 9. The payment protocol continues with non-critical APDUs, which pass the card reader without confirmation. As no special reader API would be required and the card reader would only filter out some special payment APDUs, it can still be used as a generic card reader by other applications. Applications using a card reader with filter function would also work with general purpose card readers without filter functions, because the filter function is transparent for the application. This is especially important if we consider laptops with PCMCIA card readers without any displays and buttons. For cards to be issued in the future, the scheme can be further improved by putting a card specific list of critical APDUs on each card. After obtaining the ATR and before any command can be sent to the card by an application, this card specific list of critical APDUs would be read by the reader and stored in its RAM as long as the card would be inserted. This way, the EEPROM of the reader would not need to be updated to support new cards. The concept described above leaves a choice to the customer: He can use a reader with filter function and a high level of security or he can use a cheaper - or in the case of a PCMCIA card reader a smaller - card reader and take a little risk. Probably his decision will strongly depend on the amount stored on his purse card. Best Regards, Thomas Thomas Schaeck IBM Pervasive Computing Division - Smart Card Solutions E-mail: [EMAIL PROTECTED] 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.
