Internet Keyed Payment Protocols (iKP)

Phil Janson, Zürich Information Technology Solutions Department Manager

Overview

As the Internet is rapidly moving from the realm of the academic and research communities to the commercial world, the World-Wide Web has become its hottest application by far, growing at over 500% per year. There are thus serious reasons to believe that the Internet will become a significant if not the most important vehicle for electronic commerce. While the WWW allows anyone to access any information server from anywhere at any time, what is missing from it to realize its full commercial potential are means for making electronic payments securely over the network. A number of companies (e.g., EIT, Netscape) and consortia (e.g., Terisa, W3C ) are driving new security standards (most notably SHTTP and SSL). However secure bilateral communication protocols alone are not sufficient. What is required is secure multi-party payment protocols. Several companies are already offering or about to offer various solutions in that direction. However most of these emerging solutions suffer from one or more problems: some solutions are proprietary, which is totally inappropriate in this field; others use cryptography in ways that make them unusable in certain countries and/or prevent their export from the U.S. (where most are developed); some are coupled to specific WWW browsers and servers instead of catering to any browser and server; others work with specific payment instruments (e.g., credit cards) and are not extendible to other models (e.g., checks); last but not least, most are pure software solutions whereas some payment systems will require solutions involving secure hardware such as smart cards.

The IBM Research Division has developed a family of secure payment protocols, called iKP, that circumvent most of the above problems: while developed at IBM, the technology has been immediately disclosed for public review, and it is being openly discussed in a number of fora and consortia (e.g. W3C, FSTC, IETF, etc.) and with a number of financial and technical partners as IBM has no intention of keeping it proprietary; the technology uses strong cryptography in a very secure way but packages it so that it should satisfy usage and import/export restrictions in most countries; it was designed to work with any browser and server on any platform; the first prototype of it is designed to work with credit cards, but the intrinsic design is flexible and will allow supporting other payment instruments in due time; this first prototype is also entirely in software because typical Internet stations today do not include secure hardware or support smart card readers, but provisions are made in the design to accommodate such devices later, and work is already in progress in that direction.

The iKP technology is designed to allow customers to order goods, services, or information over the Internet, while relying on existing secure financial networks to implement the necessary payments, as suggested in the figure below.

          + - - - - - - - - - - -  - - - - - - - - - - +
            +--------+                      +--------+
          | | Issuer |--------------------->|Acquirer| |
            |        |  financial networks  |        |
          | |   I    |<---------------------|   Q    | |
            +--------+                      +--^-----+
          + - - - - - - - - - - -  - - - - - - * -*- - +
                                               *  *
          + - - - - - - - - - - -  - - - - - - * -*- - +
            +--------+                      +-----v--+
          | |customer|*********************>|Merchant| |
            |        |  commercial networks |        |
          | |   C    |<*********************|   M    | |
            +--------+                      +--------+
          + - - - - - - - - - - -  - - - - - - - - - - +

      ******>  Protocol Flows of iKP
      ------>  Unchanged Protocols of existing Financial Networks

The iKP technology is based on RSA public-key cryptography. Depending on requirements, an electronic payment transaction using iKP may involve one, two, or three public keys: in all cases the bank acquiring the transaction for processing will have a public-private key pair for receiving confidential information such as credit card numbers and signing authorization messages; in many cases the merchant will also have a public-private key pair for receiving confidential information and signing payment requests and purchase confirmations; in some cases even customers may have a public-private key pair for signing payment transactions. In all cases they have a PIN for confirming authorization of payment.

For more information, see the following document:

Mihir Bellare, Juan Garay, Ralf Hauser, Amir Herzberg,
Hugo Krawczyk, Michael Steiner, Gene Tsudik,
Els Van Herreweghen, and Michael Waidner:
Design, implementation and deployment of the iKP secure electronic payment system;
IEEE Journal on Selected Areas in Communications, 18(4):611-627, April 2000.
Appeared earlier with a slightly different focus as Research Report RZ 3137, IBM Research Division, June 1999.
Mihir Bellare, Juan A. Garay, Ralf Hauser, Amir Herzberg,
Hugo Krawczyk, Michael Steiner, Gene Tsudik, Michael Waidner:
iKP -- A Family of Secure Electronic Payment Protocols;
IBM T.J. Watson Research Centre and IBM Zürich Research Lab. In Proceedings of the
First USENIX Workshop on Electronic Commerce, New York, July 1995, extended abstract,
(Uncompressed postscript version of iKP).
Ralf Hauser, Michael Steiner and Michael Waidner:
Micro-Payments based on iKP
IBM Zürich Research Lab.
Zürich iKP Prototype: Protocol Architecture (March 20, 1996);
Zürich iKP Prototype: Cryptographic Library Specification (March 20, 1996); (see also foils from ZiP education-session)
Zürich iKP Prototype: Certificate Library Specification (February 29, 1996); (see also foils from ZiP education-session)
Zürich iKP Prototype: Transaction layer specifications (April 25, 1996); (see also foils from ZiP education-session)
INTERNET-DRAFT draft-tsudik-ikp-00.txt (June, 1995);

Last modified : Saturday, 28 October 2000 14:48 CEST