IEEE Journal of Selected Areas in Communications,...

IEEE Journal of Selected Areas in Communications, VOL 18, NO. 4, April 2000 1

Design, Implementation and Deployment of theiKP Secure Electronic Payment SystemMihir Bellare, Juan A. Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk,Michael Steiner, Gene Tsudik, Els Van Herreweghen, Michael Waidner

Abstract This paper discusses the design, implementa-tion and deployment of a secure and practical payment sys-tem for electronic commerce on the Internet. The system isbased on the iKP family of protocols i = 1, 2, 3 developedat IBM Research. The protocols implement credit card-based transactions between buyers and merchants while theexisting financial network is used for payment clearing andauthorization. The protocols are extensible and can be read-ily applied to other account-based payment models, such asdebit cards. They are based on careful and minimal use ofpublic-key cryptography and can be implemented in eithersoftware or hardware. Individual protocols differ in bothcomplexity and degree of security.

In addition to being both a pre-cursor and a direct an-cestor of the well-known SET standard, iKP-based paymentsystems have been in continuous operation on the Internetsince mid-1996. This longevity as well as the security andrelative simplicity of the underlying mechanisms make theiKP experience unique. For this reason, this paper also re-ports on, and addresses, a number of practical issues arisingin the course of implementation and real-world deploymentof a secure payment system.

KeywordsElectronic commerce, payment systems, credit& debit cards, multi-party security, public key cryptogra-phy.

Work was done while all authors were with the IBM Research Di-vision.

Mihir Bellare, Department of Computer Science & Engineering,Mail Code 0114, University of California at San Diego, 9500 GilmanDrive, La Jolla, CA 92093, USA. E-mail: [email protected].

Juan A. Garay, Bell Labs Lucent Technologies, 600 Moun-tain Ave, Murray Hill, NJ 07974, USA. E-mail: [email protected].

Ralf Hauser, McKinsey & Co, Alpenstr. 3, CH-8065 Zurich,Switzerland. E-mail: [email protected]

Amir Herzberg, IBM Research - Haifa Lab (Tel Aviv Office), 2Weizmann st., Tel Aviv, Israel. Email: [email protected],

Hugo Krawczyk, Department of Electrical Engineering, Technion,Haifa 32000, Israel, and IBM T.J. Watson Research Center, NewYork, USA. Email: [email protected]

Michael Steiner, Fachbereich Informatik, Universitat des Saarlan-des, D-66123 Saarbrucken, Germany, and IBM Zurich Research Lab-oratory, Ruschlikon, Switzerland. E-mail: [email protected]

Gene Tsudik, USC Information Sciences Institute, Marina del Rey,CA 90292, USA. E-mail: [email protected]

Els Van Herreweghen, IBM Research Laboratory, Saumerstrasse 4,CH-8803 Ruschlikon, Switzerland. E-mail: [email protected],

Michael Waidner, IBM Research Laboratory, Saumerstrasse 4, CH-8803 Ruschlikon, Switzerland. E-mail: [email protected],

Appeared in the IEEE Journal of Selected Areas in Communica-tions, Vol 18, No. 4, April 2000. Part of this work was presentedat the First USENIX Workshop on Electronic Commerce, New York,July, 1995

c 2000 IEEE. Personal use of this material is permitted. However,permission to reprint/republish this material for advertising or pro-motional purposes or for creating new collective works for resale orredistribution to servers or lists, or to reuse any copyrighted compo-nent of this work in other must be obtained from the IEEE.

I. Introduction and Overview

AT this day and age it is hardly necessary to justify, orstress the importance of, electronic commerce. Sufficeit to say that it has been rapidly gaining momentum sinceearly nineties, and has been equally appealing to on-linemerchants, consumers and payment providers.

There is a widespread agreement that to enable elec-tronic commerce one needs the means for secure electronicpayments. Indeed, the appeal of electronic commerce with-out electronic payment is limited. Moreover, insecure elec-tronic payment methods are more likely to impede, thanto promote, electronic commerce. Thus, we begin with thepremise that security for electronic payments is of the ut-most importance.

In this paper we present and discuss a family of se-cure electronic payment protocols iKP (i-Key-Protocol,i = 1, 2, 3). These protocols are compatible with the ex-isting card-based business models and payment system in-frastructures. They involve three parties: the buyer (whomakes the actual payment), the merchant (who will re-ceive the payment) and the acquirer gateway (who acts asan intermediary between the electronic payment world andthe existing payment infrastructure, and authorizes trans-actions by using the latter). Hereafter, we will refer to theacquirer gateway as simply the acquirer.

Within this framework we focus on the credit card pay-ment model since it has been the most popular thus farand likely to remain so in the near future. However, otheraccount-based payment models (such as debit cards) arequite similar to the credit card model from technical andsecurity viewpoints, and are thus easily supported by iKP.

All iKP protocols are based on public-key cryptography,but they vary in the number of parties (out of the threeinvolved) that possess individual public key-pairs and canthus generate digital signatures. This number is reflectedin the name of the individual protocols: 1KP, 2KP, and3KP. The iKP protocols offer increasing levels of securityand sophistication as the number of parties who possessown public key-pairs increases.

The simplest protocol, 1KP, requires only the acquirerto possess a public key-pair. Buyers and merchants onlyneed to have authentic copies of the acquirers public key,reflected in a public key certificate. This involves a minimalpublic key infrastructure (PKI) to provide certificates for asmall number of entities, namely, the acquirers. This typeof a PKI can be operated, for example, by a large creditcard company. In the 1KP setting, buyers are authen-ticated on the basis of their credit card numbers and op-tional secret PINs. Payments are authenticated by commu-

2 IEEE Journal of Selected Areas in Communications, VOL 18, NO. 4, April 2000

nicating the credit card number and optional PIN appropri-ately encrypted under the acquirers public key, and crypto-graphically bound to relevant transaction information (pur-chase amount, identities, etc.). This prevents fraudulentmerchants from collecting credit card numbers and creatingfraudulent payments.1 1KP does not offer non-repudiationfor messages sent by buyers and merchants. This meansthat disputes about the authenticity of payment orders arenot unambiguously resolvable within the digital system.2

2KP demands that merchants, in addition to acquir-ers, hold public key-pairs and public key certificates. Theprotocol can thereby provide non-repudiation for messagesoriginated by merchants. Additionally, 2KP enables buy-ers to verify that they are dealing with bona fide merchantsby checking their certificates, without any on-line contactwith a third party. As in 1KP, payment orders are au-thenticated via the buyers credit card number and PIN,encrypted before transmission.

3KP further assumes that buyers have their own publickey-pairs and public key certificates, thus achieving non-repudiation for all messages of all parties involved. Pay-ment orders are authenticated by the combination of creditcard number, optional PIN and a digital signature of thebuyer. This makes the forging of payment orders compu-tationally infeasible. Additionally, 3KP enables merchantsto authenticate buyers on-line. This requires a full publickey infrastructure covering all parties involved.

The main reason for designing these three variants wasto enable gradual deployment: 1KP requires only a mini-mal PKI and would have been suitable for immediate de-ployment at the time it was proposed in early 1995. 2KPrequires a PKI covering all merchants, 3KP one coveringall merchants and all card holders. Looking back at whatactually transpired with the deployment of iKP and its de-scendant, SET, there was actually no need for a 1KP-likeprotocol.

All iKP protocols can be implemented in either softwareor hardware. In fact, in 1KP and 2KP, the buyer does noteven need a personalized payment device: only credit carddata and PIN (if present) must be entered to complete apayment. However, for the sake of increased security, itis obviously desirable to use a tamper-resistant device toprotect the PIN and in case of 3KP the secret key ofthe buyer.

We emphasize that the goal of iKP is to enable payments.It is not concerned with any aspect of the determinationof the order; it assumes that the order, including price,have already been decided on between buyer and merchant.It does, however, provide secure and unambiguous linkingof order information with the payment to enable effective

1Strictly speaking, one cannot consider a number that is given toany restaurant waiter or receptionist a valuable secret, in any sense.But even if the buyer is not liable, knowing his or her credit cardnumber is sufficient to commit certain frauds, and thus overall systemsecurity is improved if this number is protected. Moreover, collectingcredit card number over the Internet completely changes the scale ofthe fraud problem; see, e.g., [1].

2From a legal point of view such ambiguities are not necessarily aproblem provided there are fixed rules how to resolve them, and allparties are aware of these rules. Some consequences of systems wherethose rules were not appropriately designed are illustrated in [2].

dispute handling.iKP protocols do not provide secrecy (encryption) of the

order information. Such protection is assumed to be pro-vided by other mechanisms, e.g., SSL [3] or IPSec [4]. Thisdecoupling of order encryption from the electronic paymentprotocol is an important design principle of iKP which sup-ports compatibility with different underlying browsing andprivacy-protecting mechanisms. It also contributes to theoverall simplicity, modularity, and ease of analysis of theprotocols. An additional advantage is freeing iKP from USexport restrictions related to the use of bulk encryption.Nonetheless, if desired, the iKP family (especially, 2KPand 3KP) can be easily extended to generate shared keysbetween buyer and merchant for protection of browsing andorder information.

The rest of this paper is organized as follows: Section IIprovides a brief summary of the history of iKP and its rela-tion to the current credit card payment standard, SET. Thedifferent roles buyer, merchant, acquirer are introducedin Section III, and their different security requirements areanalyzed in Section IV. The iKP family is described andanalyzed in Section V. Then, Section VI describes, in de-tail, the iKP implementation architecture and reports onthe deployment. The paper concludes with the AppendixA elaborating on the particular technique used for publickey encryption in iKP.

II. History and Related Work

iKP was developed in early 1995 by a group of re-searchers at the IBM Research labs in Yorktown Heightsand Zurich. Right from the beginning the main goal was towork towards an open industry standard. We distributedthe iKP protocols in the Internet Draft form, invited com-ments from the scientific community, and presented ourdesign at the Internet Engineering Task Force meetingin Summer of 1995. Subsequently iKP was incorporatedinto the Secure Electronic Payment Protocols (SEPP),a short-lived standardization effort by IBM, MasterCard,Europay and Netscape. SEPP, in turn, was a key startingpoint for Secure Electronic Payments (SET), the jointVISA/MasterCard standard for credit card payments [5].In fact, SET still retains many of the iKP-esque features.

Other important ancestors of SET are the CyberCashCredit Card Protocol by CyberCash, and the SecureTransaction Technology (STT) by Microsoft and VISA.All these ancestors were proposed independently of eachother but use similar forms of cryptographic protocols.

From 1994 to 1996 an almost countless number of pay-ment protocols for all kinds of payment models were pro-posed (see [6] for a survey). One important difference be-tween iKP and most of these proposals is that iKP was notjust a paper design: The Zurich iKP Prototype (ZiP) isa fully operational prototype of 2KP and 3KP. Although itdid not become a commercial product, ZiP has been suc-cessfully deployed in a number of business trials in Europeand Japan since mid-1996. At the time of this writing,a major Dutch payment provider (Interpay Nederland) isstill using ZiP in their I-Pay system, supporting 80 onlinemerchants and 17, 000 card holders.

BELLARE ET AL.: Design, Implementation and Deployment of the iKP Secure Electronic Payment System 3

Another important difference between iKP and othercredit card payment protocols is its simplicity, modular-ity, and to the extent the term can be used elegance.iKP was designed from a small, well-defined set of secu-rity requirements (as seen in Section IV), which resultedin a multi-party secure scheme where no party is forced totrust other parties unnecessarily. We focused on the corepayment functionality and deliberately omitted all non-payment functionality that could be easily added on topof iKP, such as secrecy of order information or fair de-livery of goods. Finally we designed iKP as a family ofprotocols, thus anticipating gradual deployment.

Today only two approaches for secure credit card pay-ments over the Internet are practically relevant: SET andencryption of credit card data via SSL [3] or its eventualsuccessor TLS [7]

SET and its ancestor iKP, especially 3KP, are very sim-ilar. The main difference is in their overall functionalityand complexity: iKP was designed as a lightweight proto-col that provides the core payment functionality only, andis therefore relatively simple to understand and to analyze.SET was designed to support all options that exist in to-days credit card operation and is therefore semanticallymuch richer than iKP, but also much more difficult to an-alyze, implement and deploy.

SSL is the de facto standard for secure (i.e., encryptedand integrity-protected) client-server communication onthe web; it is integrated in virtually all web browsersand servers. SSL uses public-key cryptography, like SETand iKP, but typically only servers (i.e., merchants) havepublic-key certificates while clients (i.e., buyers) are anony-mous. Encrypting credit card data with SSL is certainlybetter than sending them in the clear, but the gain in pay-ment security is very limited:

For the acquirer the use of SSL is completely transpar-ent no messages are signed and thus the merchantdoes not gain any security.

SSL does not hide credit card numbers or any otherinformation from the merchant. Thus, it cannot beused for PIN-based authorization.

Unlike SET or ZiP, SSL does not mandate any specificpublic-key infrastructure. Thus, there is no guaranteethat a buyer can verify the merchants public-key cer-tificate, and even if the certificate can be verified thesemantics of such a certificate is not clear. In SET, aspecial purpose public-key infrastructure can be man-aged by the credit card organizations.

In SSL, merchants and acquirers need additional mech-anisms (beyond SSL) to transmit credit card and au-thorization information. iKP and SET, in contrast,provide a complete, self-contained solution.

Most types of payment systems, not just credit and debitcards, exist in the digital world. Typically each model re-quires its own type of protocols, i.e., one cannot expect thatiKP can be applied to payment models that are very dif-ferent to the credit card model. We refer to [6] for a surveyof other account-based payment models and protocols.

-

6

?

Payment System Provider

Clearing

Payment

Acquirer

SellerBuyer

Issuer

Fig. 1

Generic model of a payment system

III. iKP Payment Model

Parties. All iKP protocols are based on the existingcredit-card payment system. The parties in the paymentsystem are shown in Figure 1.

The iKP protocols deal with the payment transactiononly (i.e., the solid lines in Figure 1), and therefore involveonly three parties, called B Buyer, S Seller, and A Acquirer (gateway). Recall that A is not the acquirer inthe financial sense, but a gateway to the existing creditcard clearing/authorization network. In other words, thefunction of A is to serve as a front-end to the current in-frastructure that remains unchanged.

The payment system is operated by a payment systemprovider who maintains a fixed business relationship witha number of banks. Banks act as credit card (account)issuers to buyers, and/or as acquirers of payment recordsfrom merchants (sellers). Each issuer has a Bank Identi-fication Number (BIN) assigned when an issuer signs upwith a payment system provider. A BIN is embossed oneach credit card included as part of the credit card number.BIN also identifies the payment system provider.

We assume that each buyer receives its credit card froman issuer, and is somehow assigned (or selects) an optionalPIN as is common in current credit card systems. In 1KPand 2KP, payments are authenticated only by means of thecredit card number and the optional PIN (both suitablyencrypted), while, in 3KP, a digital signature is used, inaddition to the above.

It is also assumed (as is natural in the context of elec-tronic payments) that the buyer is using a computer toexecute the payment protocol. Since this computer mustreceive the buyers PIN and/or secret signature key, it mustbe a trustworthy device. We caution that even a buyer-owned computer is vulnerable: it may be used by severalpeople and may contain a Trojan horse or a virus thatcould steal PINs and secret keys. The best payment device


would be a secure isolated and strictly-personal device, e.g.,a tamper-resistant smartcard, connected to the computerused for shopping via a buyer-owned smartcard reader withits own keyboard and display. (This is often referred to asan electronic wallet.) Technically, 1KP and 2KP can beused with any kind of payment device, while for 3KP thebuyers need secure personal devices to store their secretsignature keys and certificates.

A seller signs up with the payment system provider andwith a specific bank, called an acquirer, to accept deposits.Like a buyer, a seller needs a secure device that stores thesellers secret keys and performs the payment protocol.

Clearing between acquirers and issuers is done using theexisting financial networks.

Public Keys and Certification. Since all iKP proto-cols are based on public key cryptography, a mechanismis needed to authenticate these public keys. We assume acertification authority, CA, which has a secret key, SKCA.Its public counterpart, PKCA, is held by all other parties.CA will certify a public key of party X by signing the pair(X, PKX) consisting of the identity of X and X s publickey. (The signature is computed under SKCA.) Note thatPKCA must be conveyed in an authenticated manner toevery party. This is typically done out-of-band, via any ofa number of well-known mechanisms.

For simplicitys sake, it is assumed in the rest of the pa-per that there is a single certification authority. However,it is easy to extend the protocols to support multiple CAssuch that the payment system provider at the top-level CAissues certificates to its constituent issuers and acquirers,while these, in turn, issue certificates to their buyers andsellers. The implementation architecture described in Sec-tion VI-G supports this model.

In all iKP protocols, each acquirer A has a secret key,SKA, which enables signing and decryption. Its publiccounterpart, PKA, which enables signature verification andencryption is held by each accredited seller together withits corresponding CAs certificate. certificate.3 As in cur-rent operation, acquirers receive the buyers credit cardnumbers and PINs, and are trusted to keep these valuesconfidential.

Each seller in 2KP/3KP and each buyer in 3KP, hasa secret/public key-pair. The public keys are included incertificates issued by the CA. The certificates also identifythe type of each party (i.e., seller buyer, acquirer.)

Adversaries and Threats. We consider three differentadversaries:

Eavesdropper: listens to messages and tries to learnsecrets (e.g., credit card numbers, PINs)Active attacker: introduces forged messages in anattempt to cause the system to misbehave (e.g., tosend him goods instead of to the buyer)

3 The above is somewhat oversimplified since, in practice, an ac-quirer needs two public key-pairs: one for signatures and the otherfor encryption. (It is well-known that using the same key-pair forboth purposes is not a good idea.) However, for conciseness sake,this distinction is not reflected in the protocol description below.

Insider: either a legitimate party or one who learnsthat partys secrets. (One example is a dishonest sellerwho tries to get paid without buyers authorization.)

Before delving into security requirements in Section IV,we briefly discuss common threats and attacks.

The Internet is a decentralized, heterogeneous network,without single ownership of the network resources and func-tions. In particular, one cannot exclude the possibilitythat messages between the legitimate parties would passthrough a maliciously controlled computer. Furthermore,the routing mechanisms in the Internet are not designedto protect against malicious attacks. Therefore, it is follyto assume either confidentiality or authentication for mes-sages sent over the Internet, unless proper cryptographicmechanisms are employed. To summarize, it is easy to stealinformation off the Internet. Therefore, at least credit cardnumbers and PINs must not be sent in the clear.

In addition, one must be concerned about the trustwor-thiness of the sellers providing Internet service. The kindof business that is expected in the Internet includes the so-called cottage industry small sellers. It is very easy for anadversary to set up a shop and put up a fake electronic storefront in order to get buyers credit card numbers (e.g., [1]).This implies that the credit card number should travel frombuyer to acquirer without being revealed to the seller (whoneeds only the BIN which can be provided separately.)

Obviously, a good deal of care must be taken to protectthe keys of acquirers. One of the biggest concerns is that ofan adversary breaking into an acquirer computer throughthe Internet connection. Therefore, the acquirers com-puter must be protected with the utmost care; includinga very limited Internet connection using advanced firewalltechnology (e.g., [8], [9].)

Furthermore, the trust in the acquirers computer mustbe limited, so that a break-in would have a limited effectonly.

IV. Security Requirements

In this section we consider a range of security require-ments for each party involved in the payment process: is-suer/acquirer, seller and buyer. They range from manda-tory security requirements to optional features.

Issuer/Acquirer Requirements. The issuer and theacquirer are assumed to enjoy some degree of mutual trust.Moreover, an infrastructure enabling secure communica-tion between these parties is already in place. Therefore,we unify their respective requirements.

A1 Proof of Transaction Authorization by Buyer.When the acquirer debits a certain credit card ac-count by a certain amount, the acquirer must be inpossession of an unforgeable proof that the owner ofthe credit card has authorized this payment. Thisproof must not be replayable, or usable as prooffor some other transaction. This means it must cer-tify at least the amount, currency, goods descrip-tion, seller identification, and delivery address, and


be obtained in such a way that replay is not pos-sible. (We use a combination of time stamps andnonces for this purpose). Note also that in this con-text the seller may be an adversary, and even sucha seller must not be able to generate a fake debit.We distinguish between:

(a) Weak Proof, which authenticates the buyer tothe acquirer but does not serve as a proof forthird parties, and

(b) Undeniable Proof, which provides full non-repudiation, i.e., can be used to resolve dis-putes between the buyer and the payment sys-tem provider.

The same distinction will be made for all subse-quently required proofs of transaction.

A2 Proof of Transaction Authorization by Seller.When the acquirer authorizes a payment to a cer-tain seller, the acquirer must be in possession ofan unforgeable proof that this seller has asked thatthis payment be made to him.

Seller Requirements.

S1 Proof of Transaction Authorization by Acquirer.The seller needs an unforgeable proof that the ac-quirer has authorized the payment. This includescertification and authentication of the acquirer, sothat the seller knows he is dealing with the realacquirer, and certification of the actual authoriza-tion information. Note that, again, the amount andcurrency, the time and date, and information toidentify the transaction must be certified. We alsodistinguish between (a) Weak proof and (b) un-deniable proof, with the latter providing full non-repudiation.

S2 Proof of Transaction Authorization by Buyer. Evenbefore the seller receives the transaction authoriza-tion from the acquirer, the seller might need anunforgeable proof that the buyer has authenticatedit. Again we distinguish between (a) Weak Proofand (b) Undeniable Proof. This requirement is nec-essary to provide for off-line authorization.

Buyer Requirements.

B1 Impossibility of Unauthorized Payment. It must beimpossible to charge a buyers credit card withoutpossession of the credit card number, PIN and, incase of 3KP, the buyers secret signature key. Thus,neither Internet rogues nor malicious sellers mustbe able to generate spurious transactions which endup approved by the acquirer. This must remain thecase even if the buyer has engaged in many priorlegitimate transactions. In other words, informa-tion sent in one (legitimate) transaction must notenable a later spurious transaction. So in particu-lar the PIN must not be sent in the clear, and not

even be subject to guessing attacks! Similar to thetwo type of proofs of transactions, we distinguishbetween:

(a) Impossibility: unauthorized payments are im-possible provided the acquirer is honest and itssecret key is not available to the adversary, and

(b) Disputability: buyer can prove not having au-thorized a payment even if the acquirers secretkey is available to the adversary (e.g., becausethe adversary colludes with an insider).

We can observe that, in fact, these two require-ments are typically met by satisfying the corre-sponding acquirer requirements A1.a and A1.b, re-spectively.

B2 Proof of Transaction Authorization by Acquirer.Buyer might need to have proof that the acquirerauthorized the transaction. This receipt fromthe acquirer is not of paramount importance, butis convenient to have. Again, we distinguish be-tween (a) Weak Proof and (b) Undeniable Proof(full non-repudiation).

B3 Certification and Authentication of Seller. Buyerneeds proof that the seller is accredited at someknown acquirer (which could be considered as someguarantee for the trustworthiness of the seller).

B4 Receipt from Seller. Buyer might need proof thatthe seller who has previously made the offer has re-ceived payment and promised to deliver the goods.This takes the form of undeniable receipt. 2KP and3KP satisfy this requirement, but will not ensurefairness [10], [11]: since the seller can always refusesending this receipt while already having receivedthe authorization from the acquirer. In this case,the buyer must take the next statement of accountas replacement for this receipt.

Additional possible buyer requirements. The fol-lowing requirements (B5 B6) may also be desirable. Herewe shortly discuss their relation to iKP; however, they arenot explicitly addressed by the iKP protocols.

B5 Privacy. Buyers might require privacy of orderand payment information. For example an investorpurchasing information on certain stocks may notwant competitors to know which stocks he is inter-ested in. The privacy of order information and theamount of payment should be implemented inde-pendently of the payment protocol, e.g., based onSSL [3].

B6 Anonymity. Buyers may also want anonymity fromeavesdroppers and (optionally) from sellers. Fur-thermore, buyers may even want anonymity withrespect to the payment system provider. iKP doesnot focus on anonymity and, in particular, offers noanonymity from the payment system provider. Thismight be desirable for systems that aim to imitate


cash, but is not essential for protocols, like iKP,that follow the credit card-based payment model.However, iKP does try to minimize exposure ofbuyers identities with respect to sellers and out-siders.

V. The iKP Protocol Family

In this section we present the three iKP protocols, i {1, 2, 3}. We first describe the cryptographic primitivesas well as the general protocol structure. The subsequentsubsections describe the actual protocols and discuss themwith respect to the security requirements outlined above.

Primitives and keys. Figure 2 summarizes the notationfor the cryptographic keys held by the various parties, andthe cryptographic primitives we will be using. While Askey-pair must enable signature and encryption, all otherkey-pairs need to enable signatures only. (For simplicityssake, it is assumed that each party has only one key-pair; inSection VI specialized key-pairs for encryption and signa-tures will be used). Note that signing and encryption (evenwhen performed with the same key-pair) are independentoperations; in particular: EX(SX()) 6= .

As reflected in table 2 the encryption function EX mustprovide some form of message integrity. Thus, a de-cryption operation results in either a plaintext messageor in a flag indicating failure (invalid ciphertext). For-mally, the primitive we need is an encryption function se-cure against adaptive choosen ciphertext attacks. The im-plication is that correct decryption convinces the decryptorthat the transmitter knew the plaintext that was orig-inally encrypted. In other words, ciphertext tamperingis detectable. Two practical and provably secure schemesachieving this property are: Optimal Asymmetric Encryp-tion Padding (OAEP) [16] (which provides for plaintextawareness) and Cramer-Shoup [17]. We use the formerscheme which we describe in Appendix A.

We stress that plaintext-aware encryption does not pro-vide authentication in the manner of a signature (i.e., nonon-repudiation). Nonetheless, it can be made to providean authentication-like capability between parties sharing akey (such as the BAN or PIN). We also note that the en-cryption function must be randomized: EX over messagem mixes in a strong randomizing value (a nonce or con-founder) such that muliple encryptions of the same plain-text are different and unlinkable.

The iKP prototype implementation described in Sec-tion VI uses RSA with 1024-bit key length for signaturesand for RSA-based plaintext-aware encryption. MD5 isused as both a hash function H() and a primitive in thekeyed hash function Hk(K, ). (The actual keyed hash con-struct is based on HMAC [14]).

Figure 3 is a list of quantities that will occur in the pro-tocols. Their meaning and usage will be further explainedas we go along.

Framework of iKP protocols. The protocols havea common framework. Figure 4 illustrates the flows at avery high level. Before the protocol begins, each party

Keys:

PKX , SKX Public and secret key of Party X (X =Certification Authority CA, Buyer B,Seller S, Acquirer A).

CERTX Public key certificate of Party X , issuedby CA. We assume it includes X, PKXand CAs signature on X, PKX .

All protocols assume A has a public key, and any partyneeding it has PKCA. 1KP assumes no other keys;2KP additionally assumes S has a public key; 3KPfurther assumes B also has a public key.

Cryptographic primitives:

H() A strong collision-resistant one-wayhash function which returns strongpseudo-random values. (Examples:MD5 [12], SHA-1 [13])

Hk(K, ) A one-way hash function requiring, inaddition to collision-resistance, no in-formation leakage with respect to itsother arguments, if the first argu-ment K is chosen at random. I.e.,Hk(K, ) should behave like a familyof pseudo-random functions. (Example:HMAC [14], [15].)

EX() Public-key encryption with PKX , per-formed in a way to provide both con-fidentiality and some kind of computa-tional message integrity. (Example:OAEP [16].)

SX() Signature computed with SKX . Notethat the signature does NOT includethe actual message M , i.e., the signa-ture function hashes the message beforesigning.

Fig. 2

Keys and cryptograhic primitives used in iKP protocols

X {A, B, S} has some starting information representedby ST-INFX . The buyer starts with the public key PKCAof the certification authority. The seller has the certifi-cate CERTA of the acquirer, and the acquirer has his owncertificate CERTA plus the corresponding secret key SKA.Each party might also have other information, which differsdepending on the specific protocol.

It is assumed that before the protocol starts, the buyerand the seller have agreed on the description and price ofthe items to buy. The functionality required to shop andagree on the item and price are provided by other means


Quantities occuring in all three protocols:

SALTB Random number generated by B. Used to salt DESC and thus ensure privacy of order information(DESC) on the S to A link; also used to provide freshness of signatures (SigS and SigA).

AUTHPRICE Amount and currency.

DATE Sellers date/time stamp, used for coarse-grained payment replay protection

NONCES Sellers nonce (random number) used for more fine-grained payment replay protection

IDS Seller id. This identifies seller to acquirer.

TIDS Transaction ID. This is an identifier chosen by the seller which uniquely identifies the context.

DESC Description of purchase/goods, and delivery address. Includes payment information such ascredit card name, bank identification number, and currency. Defines agreement between buyerand seller as to what is being paid for in this payment transaction.

BAN Buyers Account Number (e.g., credit card no.).

EXPIRATION Expiration date associated with Buyers Account Number.

RB Random number chosen by buyer to form IDB. It must be random (not just unique) in order toserve as proof to the buyer that the seller agreed to the payment.

IDB A buyer pseudo-ID which computed as IDB = Hk(RB , BAN).RESPCODE Response from the clearing network: YES/NO or authorization code.

Quantities occuring in some of the protocols:

PIN Buyer PIN which, if present, can optionally be used in 1KP and 2KP to enhance the security.

SALTC Random number used to salt the account number in the buyers certificate.

V Random number generated by seller in 2KP and 3KP for use as a proof that seller has acceptedpayment (i.e., to bind Confirm and Invoice messages).

VC Random number generated by seller in 2KP and 3KP for use as proof that seller has not acceptedpayment i.e., to bind negative Confirm/Cancel and Invoice messages.

Fig. 3

Definitions of atomic fields used in iKP protocols

Buyer(ST-INFB)

Seller(ST-INFS)

Acquirer(ST-INFA)

Initiate Invoice

Payment

Auth-RequestAuth-Response

ConfirmGoods and Services

Fig. 4

Framework of iKP protocols


(e.g., the web browser).4 Thus, DESC and AUTHPRICEare part of the starting information of seller and buyer. Thebasic protocol consists of five flows. (Section VI describesauxiliary flows that provide transaction cancellation, pay-ment clearance, and payment status inquiry.)

The exact content of the flows depends on the actualprotocol. At a high level, however, there is a commonstructure. The buyer starts with the Initiate flow. Theseller responds by sending back the Invoice. The buyer thenforwards the Payment flow which the seller uses to send anauthorization request Auth-Request flow to the acquirer.The acquirer goes through the financial network to obtainauthorization and returns the authorization response flowAuth-Response to the seller. Finally, the seller processesthis flow and produces a confirmation flow Confirm for thebuyer.

The main difference between 1,2 and 3KP is the increas-ing use of digital signatures as more of the parties involvedpossess a public/secret key-pair.

A. 1KP

Figure 5 shows the three iKP protocols. For the discus-sion of 1KP, the additional variables and messages addedfor the 2KP and 3KP protocols ([2,3 . . . ] and [3 . . . ]) are ig-nored. 1KP represents the initial step in the gradual intro-duction of a public-key infrastructure. Although it requiresthe use of public-key encryption by all parties, only the ac-quirer, A, needs to possess and distribute its own publickey certificate, CERTA. In particular, the total numberof certificates is small since it is determined only by thenumber of acquirers.

Like all members of the iKP Family, 1KP requires allbuyers and sellers to have an authentic copy of PKCA, thepublic key of the certification authority. Each buyer B hasan account number BAN (e.g., a credit card number) andassociated EXPIRATION, both known to the payment sys-tem. B may also have a secret PIN which is also known(possibly under a one-way function image) to the paymentsystem (but not to sellers). Every seller knows the certifi-cate of its acquirer, CERTA and, if needed, can send it tothe buyer during the course of the protocol. The transportof certificates is not made explicit in our description of iKP;where necessary they are assumed to be piggybacked ontoiKP messages.

1KP does not require A to keep state on a per buyer ba-sis. Buyers information is verified through the existingauthorization infrastructure which uses tamper-resistanttechnology for processing and verification of PINs.

All parties in 1KP must perform certain public key com-putations. Encryption is only performed once and only byB, for sending account data (and optional PIN) as part ofSLIP. Conversely, decryption is only performed by A (thisis also the case for 2KP and 3KP). In 1KP, only A signsdata, which is then verified by both B and S. We now turnto the flow-by-flow actions of the parties.

4Indeed, the current consensus is that functions that are beyondpayment, such as price negotiation, should be separated, and stan-dardized; e.g., JEPI [18], SEMPER [19], [20].

Initiate: Buyer forms IDB by generating a random numberRB and computing IDB = Hk(RB, BAN). Buyer generatesanother random number SALTB to be used for saltingthe hash of merchandise description (DESC) in subsequentflows. Buyer sends Initiate flow.

Invoice: Seller retrieves SALTB and IDB from Initiate,obtains DATE. Generates random quantity (nonce)NONCES . The combination of DATE and NONCESis used later by A to uniquely identify this pay-ment: the nonce disambiguates payments with commonDATE. Seller then chooses transaction id TIDS whichidentifies the context and computes Hk(SALTB, DESC).Seller forms Common as defined above and computesH(Common). (Note: seller does not need to additionallysalt H(Common) because it contains the already-saltedHk(SALTB, DESC).) Finally seller sends Invoice. CERTAcan be tagged onto this message or sent to B at a latertime, e.g., together with the Confirm message.

Payment: Buyer retrieves Clear from Invoice and vali-dates DATE within a pre-defined time skew. B com-putes Hk(SALTB, DESC). (Note that B already hasAUTHPRICE and IDB and can thus form Common.) Hethen computesH(Common) and checks that it matches thevalue in Clear. Next, B forms SLIP as defined in Figure 5with PIN being optional. Finally, the slip is encrypted un-der the acquirers public key (EncSlip = EA(SLIP)) andsent to the seller in the Payment flow.

Auth-Request: The seller now requests the acquirer to au-thorize the payment. He forwards EncSlip along with Clearand Hk(SALTB, DESC).

Auth-Response: The acquirer extracts Clear, EncSlip andHk(SALTB, DESC) from Auth-Request. A then does thefollowing:(1) Extracts from Clear: IDS , TIDS , DATE, NONCES

and the value h1 which presumably corresponds toH(Common). A now checks for replays, i.e., makessure that there is no previously processed requestwith the same quadruple: IDS , TIDS , DATE andNONCES .

(2) Decrypts EncSlip. If decryption fails, A assumes thatEncSlip has been altered (by an adversary or by S)and the transaction is therefore invalid. Otherwise,A obtains SLIP and, from it, extracts AUTHPRICE,h2 (corresponding to H(Common)), BAN, EXPIRA-TION, RB , and, optionally, PIN.

(3) It checks that h1 and h2 match; this ensures thatbuyer and seller agree on the order information (price,identity of seller, etc).

(4) A then re-constructs Common. (It has AUTHPRICEfrom SLIP. It has IDS , TIDS , DATE, and NONCESfrom Clear. It can compute IDB = Hk(RB, BAN)because it has RB and BAN from SLIP. Finally it hasHk(SALTB, DESC) from Auth-Request. Put together,these yield Common.) A then computes H(Common)and checks that it matches h1 above.


Composite Fields:

Common AUTHPRICE, IDS , TIDS , DATE, NONCES , IDB, Hk(SALTB , DESC), [2,3H(V ), H(V C) ]Clear IDS , TIDS , DATE, NONCES , H(Common), [2,3H(V ), H(V C) ]SLIP AUTHPRICE, H(Common), BAN, RB, [PIN[3 |SALTC ]], EXPIRATIONEncSlip EA(SLIP)SigA SA(RESPCODE,H(Common))[2,3 SigS ] SS(H(Common))[3 SigB ] SB(EncSlip,H(Common))

Starting information of parties:

ST-INFB DESC, AUTHPRICE, BAN, EXPIRATION, PKCA, [PIN], [3 SKB, CERTB, [SALTC ] ]

ST-INFS DESC, AUTHPRICE, PKCA, CERTA, [2,3 SKS , CERTS ]

ST-INFA PKCA, SKA, CERTA

Protocol Flows:

Initiate: B SALTB, IDB S

Invoice: B Clear, [2,3 SigS ] S

Payment: B EncSlip, [3 SigB ] S

Auth-Request: S Clear, Hk(SALTB, DESC), EncSlip, [2,3 SigS , [3 SigB ] ] A

Auth-Response: S RESPCODE, SigA A

Confirm: B RESPCODE, SigA, [2,3 V |V C ] S

Fig. 5

iKP Protocols

(5) Next, the acquirer uses the credit card organizationsexisting clearing and authorization system to obtainon-line authorization of this payment. This entailsforwarding: BAN, EXPIRATION, PIN (if present),price, etc., as dictated by the authorization system.Upon receipt of a response RESPCODE from the au-thorization system, A computes a signature, using thefunction SA, on RESPCODE and H(Common).

Finally A sends Auth-Response to S. TIDS can be taggedonto the message enabling the seller to easily recover thetransaction context.

Confirm: The seller extracts RESPCODE and the ac-quirers signature from Auth-Response. He then verifiesthe acquirers signature and forwards both RESPCODEand SigA to the buyer.

1KP satisfies the following requirements:

A1(a) Proof of Transaction Authorization by Buyer. SLIPincludes the BAN, EXPIRATION and the PIN. (The lastone, if present, is known only to the buyer and paymentsystem and is the basis of the buyers security. If PIN isnot present, one must assume the BAN and EXPIRATIONare not known to the adversary.) Since B knows PKCAand verifies CERTA, it is ensured that B does not unwit-tingly send the BAN, EXPIRATION and PIN to a non-authorized party. A decrypts and checks that the BAN,EXPIRATION and PIN are correct. The chosen-ciphertextsecurity (or plaintext-awareness) of the encryption (see be-ginning of Section V) implies that SLIP originated withthe BAN and PIN holder. An adversary not knowing theBAN or PIN can neither create a fake SLIP nor modify theencryption of a legitimate one to its advantage.

Note that PIN-based authentication provides only a weakproof whereas signature-based authentication (as used in


3KP) provides undeniable proof. Moreover, the probabil-ity of guessing the correct PIN is much higher than theprobability of guessing a valid signature.However, the security of the encryption against chosen mes-sage attacks (and in particular the fact that it is random-ized) implies security against dictionary attacks. Note thathad EA() been a deterministic encryption function, an at-tacker who knows all data fields within SLIP (except PIN)could compute encryptions EA(SLIP) for all possible val-ues of PIN and determine the correct PIN by comparingall encryptions with the one produced by B. In [21] it isformally proven that off-line dictionary attacks against thePIN number are provably prevented if one uses an encryp-tion function which is semantically secure against chosenciphertext attacks. (Interestingly, they show that semanticsecurity against plaintext-only attacks is not sufficient toensure such resistance to dictionary attacks.)It is important to stress that the transaction for whichwe need proof includes the item description, and in par-ticular the delivery address. It should be impossible foran adversary to divert a legitimate payment by changingthe delivery address. The value H(Common) is included inAs authorization in order to prevent such attacks. In par-ticular, it prevents a special kind of person-in-the-middleattack that we now describe.An attacker who impersonates a seller can get the buyerto agree to purchase something for a given amount. Theattacker then obtains from the buyer the encrypted slipauthorizing payment. The attacker now impersonates thebuyer to the seller, but this time the adversary buys forthe same amount a (possibly) different merchandise withdifferent delivery address and pays for it with the buyersslip. Notice, however, that in this case there will be amismatch between the view of the order by the real buyerand the seller, and, consequently, a mismatch in the valueof H(Common).Finally, replay of SLIP by a dishonest seller is detectedby the combination of DATE and NONCES . There is anacceptable delay period Tdelay. All SLIP-s are cachedfor Tdelay time units past DATE. Different SLIP-s withthe same DATE are disambiguated by nonces.

S1(b): Proof of Transaction Authorization by Acquirer.The unforgeable, undeniable non-repudiable proof is thedigitally-signed message sent by A. The inclusion ofH(Common) prevents replay of authorization messageswhich would otherwise result in fake authorization ofbuyers payments.Since the seller knows Common in advance, the signaturewould accurately reflect any tampering in the informationsent from seller to acquirer and any disagreement betweenbuyer and seller as far as payment data.The inclusion of H(Common) in both the buyer-generatedSLIP and (explicitly) in Auth-Request enables A to detectany conflicts between the sellers and buyers views of theorder contents (prior to submitting the transaction to theclearing network).

B1(a): Unauthorized Payment is Impossible. This is a

direct consequence of satisfying A1(a).

B2(b): Proof of Transaction Authorization by Acquirer.This is a direct consequence of satisfying S1(b).

B5: Privacy. 1KP provides partial privacy. Specifically,acquirer is not given DESC, but only Hk(SALTB, DESC).Furthermore, acquirer (or an eavesdropper on the acquirer-to-seller link) cannot obtain DESC via dictionary attack,for the following reason.In a dictionary attack, the attacker who has a set of pos-sible values of DESC wants to determine whether oneof them corresponds to what the buyer is ordering. Ifsalt was not used, the attacker could easily make thecheck by evaluating H on collected values and seeingwhether one of the results matchesH(DESC) in the subjectflow. However, without the knowledge of SALTB used inHk(SALTB, DESC) all possible description guesses DESCwill have the same likelihood due to the pseudo-randomnature of Hk().Of course, an attacker who eavesdrops on both buyer-sellerand seller-acquirer links can record SALTB (transmittedin the clear on the former) and mount a dictionary at-tack. However, recall that order privacy is not one of ourcentral goals and, if deemed to be a strong concern, buyer-seller communication may be protected by complementarymeans, such as SSL [3].1KP also hides buyers identification information by onlydisclosing the one-time randomized pseudo-identity IDB.This quantity is sufficient for the acquirer to bind the trans-actions to the actual buyer but it does not allow for disclos-ing of actual ID information (such as the BAN) in public(including to sellers) or to allow an attacker to link differentpurchases by the same buyer.

The last protocol flow carrying signed authorization bythe acquirer is optional. Its only purpose is to provide atransaction receipt for the buyer but is has no impact onthe security of the protocol.

To summarize, 1KP is a simple and fairly efficient pro-tocol. Its main achievement was (at the time of its design,circa 1995) to get a secure electronic payment system withas little modification as possible to the existing infrastruc-ture. Its main weaknesses are: 1) the buyer authenticatesitself via the acquirer by means of only account numberand optional PIN (as opposed to strong authentication viadigital signatures); 2) the seller does not directly authenti-cate itself to the buyer or acquirer (there is however somelevel of indirect authentication via the buyers SLIP andthe authorization by the acquirer); and 3) neither sellernor buyer provide undeniable receipts for the transaction.Enhancing 1KP to provide these missing features results inthe protocols described in the next two subsections, 2KPand 3KP.

B. 2KP

The second protocol, 2KP, is obtained by including alsothe values and fields specific to 2KP ([2,3 . . . ]) to the pro-tocol in Figure 5. The basic difference with respect to 1KPis that, in addition to A, each seller S needs to possess a


public key with a matching secret key, and distribute itsown public key, with its certificate, CERTS .

We now describe the additions to the flows and actions.There are two new elements in Invoice. The first is that theseller chooses random values V and V C and puts H(V ) andH(V C) in Clear. (The inclusion of V or V C in Confirm willlater serve as a (one-time) signature, thereby saving theseller one signature computation. See below.) These valueswill be added to Common for what follows. Second, theseller signsH(Common) and includes this signature SigS inInvoice. Upon receipt of Invoice the buyer checks the sellerssignature, and then proceeds as before to generate Payment.Auth-Request is augmented by the seller to include the samesignature SigS he sent to the buyer earlier. The acquirerchecks this signature before authorizing payment. Finally,the value V (success) or V C (failure) is included by theseller in Confirm. The buyer computes H(V ) (or H(V C))and checks that it matches the value sent earlier in Invoice.

2KP satisfies all the requirements addressed by 1KP, aswell as:

A2: Proof of Transaction Authorization by Seller. This isachieved by the inclusion of the sellers signature SigS andthe acquirers verification of it.

B3: Certification and Authentication of Seller. Similarlyachieved by inclusion of signature of seller and its check bybuyer.

B4: Receipt from Seller. This is achieved by the combi-nation of Ss signed message sent to A, and the value V(V C) sent in Confirm. V (V C) assures the buyer (and anythird party) that the seller has accepted (rejected) the pay-ment. This is because no other party is capable of findingV (V C). (It would require inverting the one-way functionH on the point H(V ) or H(V C)). In this way the cost ofan extra digital signatures (such as RSA) is saved.Obviously, S can refuse forwarding As authorization mes-sage to the buyer and sending its last message. In this case,B does not know whether the transaction was aborted orfinalized. This must be handled based on the next accountstatement.

C. 3KP

The last protocol3KPis obtained by including inFigure 5 the fields that are 2KP- and 3KP-specific ([2,3 . . . ]and [3 . . . ], respectively.). As can be expected, in 3KP allprotocol participants, including buyers, possess a publickey with the associated secret key and certificate. All par-ties are now able to provide non-repudiation.

CERTB, sent (out-of-band) to the seller in addition tothe iKP flows, may contain some additional data besidesthe buyers public key and ID. These data are included inthe certificate in salted hashed form using Hk(). This al-lows to open the information only on demand and preventsthe leaking of information to unauthorized users. For in-stance, CERTB might include the hash of the buyers phys-ical address, and whether ordered goods should be sent toBs home address, B can reveal Buyers physical addressand the corresponding salt to the seller who can verify it

based on CERTB. Similarly, CERTB can securely link theBAN to the signing key. This allows the acquirer to ef-ficiently verify that the payer has the necessary authorityover BAN contained in the SLIP (see [15]). 3KP certificatesas implemented in the ZiP prototype (Section VI) containa salted hash Hk(SALTC , BAN) of the BAN. Since SALTCis included in EncSlip, the acquirer can do this check.

The buyers signature serves as undeniable proof oftransaction (A1.b), and enables disputability (B1.b). If the3KP certificate contains no cleartext buyer identity (e.g.,only the above hashed data or possibly a pseudonym), 3KPdoes not provide the seller with more information about thebuyer than 1KP or 2KP. On the other hand, the sellers canlink all payments of the buyer with CERTB and Bs sig-nature, i.e., the buyer loses some privacy when comparedto 1KP and 2KP. One way to avoid this is by encryptingCERTB and the signature with As public key. In thatcase, the seller of course cannot verify SigB but can stillrely on SigA for a guarantee of the transaction outcome.

Notice that in 3KP PIN numbers can still be used, butonly for compatibility with the existing infrastructure. Ex-cept for that reason, PINs can be omitted since the level ofauthentication provided by the buyers signature is signifi-cantly superior to that provided by a PIN. (Note, however,that the inclusion of a user-memorizable PIN can still pro-vide some defense in the case that the buyers signaturekey is stolen.)

3KP satisfies all the requirements addressed by 2KP, aswell as:

A1(b): Undeniable Proof of Transaction Authorization byBuyer. The buyer signs the SLIP using a secret key SKBknown to B only.

S2(b): Proof of Transaction Authorization by Buyer.Based on Bs signature, S can verify that SLIP was signedby B. S cannot verify the correctness of the contents ofSLIP, especially not of the PIN.

B1(b): Unauthorized Payment is Impossible. Follows fromA1.b.

D. Comparison of the iKP protocols

The iKP protocols presented above vary in the degree ofboth protection and complexity. They proceed in an in-cremental path towards electronic payment with strong se-curity features with respect to all parties involved. Prac-tically speaking, it was envisaged at the time of the de-sign that 1KP would represent a short-term, interim steptowards payment protocols with stronger security guaran-tees. Thereafter, 2KP and 3KP could be gradually phasedin. Table V-D presents a comparison of the iKP protocols.

The iKP family can fulfill all stated requirements and,in particular, provides non-repudiable receipts from the ac-quirer to the seller/buyer, and from the seller to the buyer.In case that the buyer also possesses a public key-pair(3KP), buyer payment non-repudiation becomes possible.

Although anonymity is not the focus of iKP, both 1KPand 2KP provide anonymity of the buyer to the seller, andto the outside: the buyer uses a pseudo-identity IDB which


TABLE I

Comparison of the iKP payment protocols. A requirement marked by

is satisfied but not disputable (weak), while

indicates that the requirement is satisfied based on undeniable proof (strong) providing non-repudiation and disputability.

REQUIREMENTS/PROTOCOLS 1KP 2KP 3KPIssuer/AcquirerA1. Proof of Transaction Authorization by Buyer

A2. Proof of Transaction Authorization by Seller

SellerS1. Proof of Transaction Authorization by Acquirer

S2. Proof of Transaction Authorization by Buyer

BuyerB1. Unauthorized Payment is Impossible

B2. Proof of Transaction Authorization by Acquirer

B3. Certification and Authentication of Seller

B4. Receipt from Seller

is different in each transaction and unlinkable across trans-actions. The buyers payment activity is thus unlinkableand untraceable. 3KP clearly leaks identity informationthrough the use of buyer certificates. However, throughthe use of pseudonyms, buyers can remain anonymous, ifnot unlinkable.

Order privacy against eavesdroppers can be attained byemploying a secure communication protocol (e.g., [3], [4]).Alternatively, the iKP protocols themselves could be ex-tended to provide this type of protection. Since iKP aimsat credit card-like payments, no anonymity against the pay-ment system is provided.

As shown in the next section, the iKP protocols can beeasily extended to support batch processing of paymentsfrom the same buyer by the seller and/or to guarantee(block) payment amounts as commonly done, for exam-ple, in the case of hotel or car rentals payments. Anotheravenue for extensions are micro-payments: the relativelyhigh cost of credit card transactions makes iKP unsuitablefor payments of very small amounts. However, Hauser etal. [22] show how iKP can be extended to support micro-payments efficiently without sacrificing strong multi-partysecurity.5

The iKP protocols were implemented at the IBM ZurichResearch Lab in early 1996. The implementation and de-ployment of the resulting system, referred to as ZiP (ZurichiKP Prototype), is described in the next section.

VI. ZiP: Implementation and Deployment

A. Protocol scenarios

The payment authorization core of the ZiP implementa-tion is formed by the 2KP and 3KP protocols described inthe previous section. Additional functionality was addedduring the implementation phase following the requests ofthe target user community. The actual ZiP protocol suiteincludes four protocol scenarios:

5Note that most other micro-payment protocols such as Milli-cent [23] and NetBill [24] gain their efficiency through the use ofshared-key cryptosystems and therefore require complete trust in thepayment system provider.

1. Payment Authorization (2KP and 3KP augmentedwith cancellation option)

2. Separate Payment Clearance (Capture)6

3. Refunds

4. Inquiry

B. Payment Authorization

ZiP payment authorization consists of the basic paymentscenario described in Section V and Figure 5. The ZiPimplementation (Figure 6) is augmented with an optionalCancel flow (carrying the sellers cancellation commitmentV C) which is used by the seller if he decides, for whateverreason, not to go ahead with the authorization request.RESPCODE, in this case, is set by the seller rather thanby the acquirer.

The ZiP protocols were also augmented with a number oftimestamps enabling efficient replay detection and transac-tion lifetime management: the acquirer sets a timestampof authorization in AUTHTIME; and the seller specifiesan invoice expiration INVOICEEXP. In addition, ZiP al-lows for optional data, OPTSIGZ , which is not carried iniKP flows, to be included in the signatures (see also Sec-tion VI-F).

The variable PFLAGS contains a number of protocolflags set jointly by buyer and seller: PFLAGS:SIG B - Buyers signature SigB present inPayment and Auth-Request.This option is set by the buyer but must be fixed for agiven buyer-account combination. In other words, a buyerwho has the ability to generate signatures must always doso. However, it is ultimately the acquirers responsibilityto make sure that a buyer with signature capability alwaysuses PFLAGS:SIG B.A seller can refuse to issue an Invoice if it is the sellerspolicy to always require SigB and the buyer is not able toprovide it.

6The terms clearance and capture are used interchangeablythroughout this paper.


Composite Fields:

Common PFLAGS, AUTHPRICE, IDS , TIDS , DATE, INVOICEEXP, NONCES , IDB,Hk(SALTB, DESC), H(V ), H(V C)

Clear PFLAGS, IDS , TIDS , DATE, NONCES , H(Common), INVOICEEXP, H(V ), H(V C)SLIP AUTHPRICE, H(Common), BAN, RB , [PIN|SALTC ], EXPIRATIONEncSlip EA(SLIP)SigA SA(RESPCODE, AUTHTIME,H(Common), OPTSIGA)SigS SS(H(Common), OPTSIGS)SigB SB(EncSlip,H(Common), OPTSIGB)

Protocol Flows:

Initiate: B PFLAGSa, SALTB, IDB S

Invoice: B Clear, [SigS ] S

Payment: B EncSlip, [SigB] S

Cancel: B RESPCODE, VC, [SigS ] S

Auth-Request: S Clear, Hk(SALTB, DESC), EncSlip, SigS , [SigB ] A

Auth-Response: S RESPCODE, AUTHTIME, SigA A

Confirm: B RESPCODE, AUTHTIME, V|VC, [SigA], [SigS ] S

aPFLAGS in Initiate contains all the options set by the buyer; seller may add PFLAGS:CLRN to the final PFLAGS sent in Clear.

Fig. 6

ZiP Payment Authorization

PFLAGS:SIG S - Sellerss signature SigS requested inInvoice.If SigS is not present in Invoice, it has to be present inConfirm (or Cancel) and checked by the buyer at that time.This option is set by the buyer. A buyer may, e.g., gatherSigS s from multiple sellers for the purpose of compara-tive shopping, each time suspending the transaction afterhaving received the signed invoice. Such an abbreviatedprotocol run can be resumed at a later time provided thatSigS is still timely/valid.As before, a given seller can refuse to comply because, forexample, it is not interested in giving out signed offersfor buyers that arent ready to pay. PFLAGS:CONFIRM - Confirm is requested.It is set by the buyer; it is envisaged that every seller shouldsupport this option. If PFLAGS:CONFIRM is set but theseller delays authorization or cannot reach the acquirer, theseller can reply with a Status flow (see Section VI-E). PFLAGS:SIG A - SigA is requested in Confirm.It is set by the buyer and can only be used in conjunctionwith the PFLAGS:CONFIRM option.

PFLAGS:CLRN - Authorization and clearance (capture)are performed together.This option is set by the seller. If set, the protocolin Figure 6) suffices to complete payment. Otherwize,the protocol only achieves payment authorization; theseller must subsequently perform a seperate clearance func-tion (Section VI-C) or take further processing of thispayment off-line. The response code from the acquirerin Auth-Responseindicates whether authorization is given,and, if clearance was requested, whether the payment wascleared.While a buyer may, in principle, refuse this option, this isnot likely. PFLAGS:noEnc - The buyer does NOT use encryption.SLIP is sent in the clear and contains neither a PIN norSALTC . This flag is set by the buyer. Sellers have nosay over this option. The purpose is to avoid the expenseof encryption and to satisfy certain export regulations incases when BANs are not treated as secret or sensitiveinformation. Can only be used in conjunction with thePFLAGS:SIG B option.


C. Separate Payment Clearance/Capture

The protocol shown in Figure 7 performs separate clear-ance after a prior successful payment authorization withPFLAGS:CLRN not set. This clearance must be performedwith the same acquirer that handled the previous autho-rization.

Multiple clearance flows against the same payment au-thorization are supported. Replay of clearance requests ischecked by the acquirer based on the CLRNSEQ counter.CLRNPRICE represents the total amount cleared; ifCLRNPRICE is lower than in the previous Clrn-Request,this is a request for refunds (Section VI-D). Includingthe total cleared price (as opposed to incremental differ-ences) makes the system more robust against inconsisten-cies between seller and acquirer due to loss of messages;also, it allows for more efficient state-keeping and proof-collection (both seller and acquirer only have to store thelast Clrn-Request and/or Clrn-Response).

D. Refunds

Sellers may issue refunds for previously cleared pay-ments. Although it is understood that refunds are typ-ically triggered by consumers/buyers, the interaction be-tween buyer and seller that leads to an eventual refund isassumed to take place off-line (i.e., outside iKP/ZiP).

Within iKP/ZiP, a refund transaction for all practi-cal purposes is equivalent to (and treated as) a clear-ance/capture transaction. As explained above, a refund is,essentially, a clearance with the lower amount. The differ-ence between a refund and a clearance manifests itself onlywithin the domain of the financial clearing network.

E. Inquiry

The buyer can ask the seller about the status of a spe-cific payment. The protocol is shown in Figure 8. Thebuyer may transmit Inquiry at any time after submitting aPayment flow. The seller must be able to respond for sometime after the payment transaction is completed; the exacttime period is the choice of the seller or may be specifiedby the financial institutions. The response from the selleris either Confirm (if the seller has received Auth-Response),a Status message with his view on the current transactionstate (if he hasnt received Auth-Response), or Cancel (if hedecided to cancel the payment and hasnt previously sentAuth-Request to the acquirer nor Confirm to the buyer).

F. Implementation rationales and explanations

This section explains some of the features of the ZiPprotocol design.

Opaque fields. Some protocol fields are treated opaquelyby ZiP. Opaque in this context means that these flowsare not carried within the protocol messages. At the sametime, these fields are authenticated and integrity-protectedby ZiP. Some of these fields may (and sometimes have to)be tacked on by the higher-layer software. These fields are:

DESC. Purchase details (e.g., merchandise descrip-tion) may have to be explicitly transmitted between

Protocol Flows:

Inquiry: B H(Common) S

Confirm: S (same as in Figure 6) S

OR

Cancel: S (same as in Figure 6) S

OR

Status: S STATE S

Fig. 8

ZiP: Inquiry protocol

buyers and sellers. However, it is not recommendedfor transmission to the acquirer.

All fields of the form OPTSIGZ are (as the name sug-gests) optional. They carry optional data and are in-cluded in the respective SigZ signatures.

For example, they can be used to carry creden-tials/certificates of various entities (hence their ab-sence from the ZiP protocol flows), or other optionaldata like periodic account statements or additionalinformation returned by the clearing network (suchas additional authorization codes needed for separateclearing).

Replay Detection. Since both TIDS as well as buyer-chosen random values serve as input to H(Common), as-sociation management and replay detection by buyer andseller Transaction Layers (see Section VI-G) is largely basedon H(Common). (An exception is Initiate: since this flowdoesnt containH(Common), a buyer transaction identifierTIDB is tagged onto Initiate by the Transaction Layeras thereplay detection key for this flow.)

Similarly, the Transaction Layer at the acquirer usesH(Common) as a transaction identifier. Note that the ac-quirer and/or financial network must perform replay de-tection only if the seller requests payment capture process-ing, to ensure that old Clrn-Request messages cannot beused to change the captured amount. Replay detection forauthorization-only requests is a policy matter determinedby the individual payment system providers.

Typing of message fields. Every signature type gen-erated in ZiP is assigned a unique signature identifier. Ev-ery signature operation (generation/verification) automat-ically includes a signature identifier for a specific signaturetype. The same holds for all hash function computations.


Composite Fields:

SigClrnS SS(H(Common),CLRNPRICE, OPTSIGCLRNS , CLRNSEQ)SigClrnA SA(RESPCODE, CLRNTIME, CLRNPRICE, CLRNSEQ, H(Common), OPTSIGCLRNA)

Protocol Flows:

Clrn-Request: S H(Common),CLRNPRICE, CLRNSEQ, SigClrnS A

Clrn-Response: S RESPCODE, CLRNTIME, CLRNSEQ, SigClrnA A

Fig. 7

ZiP: Clearance protocol

The following distinct signature types are identified:SigB, SigS , SigA, SigClrnS , SigClrnA.7

The following hash function computations are uniquelyidentified: H(Common), H(V ), H(V C), Hk(RB , BAN)and Hk(SALTB, DESC).Performance. Cryptographic operations such as com-putation/verification of public key signatures and en/de-cryption are computationally expensive. iKP and ZiP aredesigned to improve performance by minimizing the num-ber of cryptographic operations.

Adherence to export regulations. The protocol isdesigned to minimize the amount of data encrypted, inorder to satisfy the export control rules of the U.S. govern-ment. As described in detail in A, only SLIP is encrypted,and the data therein is limited to financial information.

G. Architecture

Figure 9 shows the architecture of ZiP. Buyer, Seller andAcquirer applications, residing on different network nodes,access the iKP functionality through the Transaction Layerinterface [25]. The Transaction Layer provides the paymentapplications with a high-level (C++) interface using sim-ple payment objects, such as a BuyerTransaction class withmethods Initiate(), Pay(), Inquiry(). The Transaction Layertakes care of association management, audit and config-uration. The assocation management finds transactionsmatching incoming messages based on transaction ids (orH(Common), as described in Section VI-F). It detects du-plicate messages and unexpected messages, i.e., those notcorresponding to an outstanding or recorded transaction.Unexpected requests are acknowledged with an error mes-sage, unexpected replays are ignored.

The Transaction Layer realizes robustness of the ZiP pro-tocols in the presence of failures. It keeps transaction state

7 Since multiple clearance transactions against the same pay-ment authorization are allowed, the clearance signatures (SigClrnS ,SigClrnA) are further distinguished by CLRNSEQ.

in persistant storage and recovers from system crashes. Toovercome unreliable communication, the Transaction Layertries retransmitting after appropriate timeouts. The re-play detection in the Transaction Layer will catch this andcorrespondingly resend the previous reply. (Note that themessages are idempotent!)

The Comm module sends iKP messages between differ-ent ZiP users. It supports several underlying transportmechanisms such as HTTP, Internet e-mail, TCP/IP.

Glue is an optional part that glues the network-independent buyer application to a user application suchas a WWW browser, a CD-ROM catalog, etc. (see [26])

Payment applications, Transaction Layer, Glue, Command Safe Storage are all implemented in C++. The lowerlayers, consisting of the iKP, certificate and crypto li-braries, are written in C.

The iKP Library [27] provides the core functionality forcomposing and verifying iKP protocol messages, using Cer-tificate Library [28] for verifying certificates and Crypto [29]for accessing cryptographic primitives. The iKP Library al-lows Buyer, Seller and Acquirer applications to verify re-ceived iKP messages against a context kept by the Trans-action Layer, and to compose iKP messages to be sent. Itreturns an updated state to the Transaction Layer after eachsuccessful verification or composition.

Crypto separates the iKP protocol functionality from thecryptographic functionality, and allows support for differ-ent cryptographic toolkits. The Crypto API consists ofmethods for signature generation and verification, encryp-tion and decryption, hashing and key handling (genera-tion, destruction). The ZiP Crypto module is based on theRSA and MD5 functions of the RSA BSAFE 2.1 library.It provides additional functionality such as the randomizedand plaintext-aware encryption (using OAEP) described inAppendix A. It also provides an interface for seeding therandom number generator and implements seed collectioncombining various sources of randomness such as network


Glue Buyer / Seller / Acquirer Application

Transaction Manager

Buyer Seller Acquirer

iKP Library

Crypto Library (BSAFE)C

erti

fica

te L

ibra

ry

Crypto

SafeStorage

Comm

Fig. 9

ZiP implementation architecture

traffic and inter-keystroke intervals of user-provided data.ZiP also implements a dummy Crypto module which al-

lows for non-export-controlled and platform-independenttesting, and serves as an example for implementors of newcrypto modules.

The Certificate Library implements a simple certificate is-suing and verification functionality for certificates and cer-tificate chains in a hierarchical model. The content of thecertificates is taken from the X.509 [30] specification.

For a complete set of ZiP documentation, check our webserver on http://www.zurich.ibm.com/Technology/Security/extern/ecommerce/iKP_overview.html.

H. Deployment

At Europays Annual Members Meeting in Seville,Spain, in June 1996, Europay and IBM jointly ran a small-scale trial allowing visitors to the conference to use theirpre-loaded Europay CLIP purse card to make secure inter-net payments from a card reader-equipped terminal. Thepayment scheme used was an integration of CLIP cardpayment functionality with ZiP-3KP, resulting in a securescheme for Internet payments from pre-loaded purses.

From April 1997 till February 1998, the EMP (ElectronicMarket Place) project in Japan, funded by MITI (Ministryof International Trade and Industry), deployed ZiP-3KP ina trial with 5 on-line merchants and 2000 users. Each userreceived a smartcard storing his/her ZiP account (keysand certificates), allowing secure Internet purchases frompublic kiosks and terminals.

ZiP is also the payment technology behind the I-Paypayment product offered by Interpay Nederland and theDutch banks. I-Pay was launched as a trial in June 1996,offering debit-type purchases from twenty on-line shops, us-ing ZiP-3KP. Later, Eurocard/Mastercard credit card pay-ments were added to the I-Pay brand. Currently I-Pay isaccepted by 80 on-line merchants and has a user base of17000 users. In line with initial plans to use iKP only

for the initial trial and to move to the more standardizedSET [5] technology once available and accepted, a phasedtransition is currently replacing ZiP technology with SETtechnology.

Acknowledgements

We thank Phil Janson and Mark Linehan for helpfuldiscussions, and Jose L. Abad Peiro, Hans Granqvist andSteen Larsen for their contributions to the implementationof iKP/ZiP.

References

[1] Paul Wallich, Cyber view: How to steal millions in champchange, Scientific American, pp. 3233, August 1999.

[2] Ross Anderson, Why cryptosystems fail, Communications ofthe ACM, vol. 37, no. 11, pp. 3241, Nov. 1994.

[3] Alan O. Freier, Philip Kariton, and Paul C. Kocher, The SSLprotocol: Version 3.0, Tech. Rep., Internet Draft, 1996, Willbe eventually replaced by TLS[7].

[4] Stephen Kent and Randall Atkinson, Security architecture forthe Internet Protocol, Internet RFC 2401, Nov. 1998.

[5] Mastercard and Visa, SET Secure Electronic Transac-tions Protocol, version 1.0 edition, May 1997, Book One:Business Specifications, Book Two: Technical Specification,Book Three: Formal Protocol Definition. Available fromhttp://www.setco.org/set specifications.html.

[6] N. Asokan, Phil Janson, Michael Steiner, and Michael Waidner,State of the art in electronic payment systems, IEEE Com-puter, vol. 30, no. 9, pp. 2835, Sept. 1997, A Japanese trans-lation of the article appeared in pp 195-201, Nikkei Computer(http://nc.nikkeibp.co.jp/jp/) issue of March 30, 1998.

[7] Tim Dierks and Christopher Allen, The TLS protocol version1.0, Internet RFC 2246, Jan. 1999.

[8] William R. Cheswick and Steven M. Bellovin, Firewalls and In-ternet Security Repelling the Wily Hacker, Professional Com-puting Series. Addison-Wesley, 1994, ISBN 0-201-63357-4.

[9] Pau-Chen Cheng, Juan Garay, Amir Herzberg, and HugoKrawczyk, A security architecture for the internet protocol,IBM Systems Journal, Special issue on the Internet, vol. 37, no.1, pp. 4260, 1998, Updated version of [31].

[10] N. Asokan, Victor Shoup, and Michael Waidner, Asyn-chronous protocols for optimistic fair exchange, in Pro-ceedings of the IEEE Symposium on Research in Securityand Privacy, Oakland, CA, May 1998, Research in Se-

http://www.zurich.ibm.com/Technology/Security/extern/ecommerce/iKP_overview.html


curity and Privacy, pp. 8699, IEEE Computer SocietyPress, A minor bug in the proceedings version was fixed.An errata sheet, distributed at the conference, is available athttp://www.zurich.ibm.com/Technology/Security/publications/1998/ASW98-e\%rrata.ps.gz ;A related paper [32] is available as well.

[11] N. Asokan, Fairness in Electronic Commerce, Ph.D. thesis,University of Waterloo, May 1998.

[12] Ron Rivest, The MD5 message-digest algorithm, InternetRFC 1321, Apr. 1992.

[13] NIST National Institute of Standards and Technology (Com-puter Systems Laboratory), Secure hash standard, FederalInformation Processing Standards Publication FIPS PUB 180-1, Apr. 1995.

[14] Mihir Bellare, Ran Canetti, and Hugo Krawczyk, Keying hashfunctions for message authentication, in Advances in Cryp-tology CRYPTO 96. 1996, number 1109 in Lecture Notes inComputer Science, pp. 115, Springer-Verlag, Berlin Germany.

[15] Hugo Krawczyk, Blinding of credit card numbers in the SETprotocol, in Proceedings of the 3rd Conference on FinancialCryptography (FC 99), Anguilla, British West Indies, Feb 1999,International Financial Cryptography Association (IFCA).

[16] Mihir Bellare and Phillip Rogaway, Optimal asymmetric en-cryption how to encrypt with rsa, in Advances in Cryptology EUROCRYPT 94, I.B. Damgard, Ed. 1994, Lecture Notesin Computer Science, pp. 92111, Springer-Verlag, Berlin Ger-many, final (revised) version appeared November 19, 1995.

[17] Ronald Cramer and Victor Shoup, A practical public keycryptosystem provably secure against adaptive chosen cipher-text attack, in Advances in Cryptology CRYPTO 98, HugoKrawczyk, Ed. Aug. 1998, number 1462 in Lecture Notes inComputer Science, pp. 1325, Springer-Verlag, Berlin Germany.

[18] Eui-Suk Chung and Daniel Dardailler, Joint electronic paymentinitiative (jepi), White paper, JEPI, Apr. 1997.

[19] Michael Waidner, Development of a secure electronic mar-ketplace for Europe, in Proceedings of the Fourth Eu-ropean Symposium on Research in Computer Security (ES-ORICS), E. Bertino, H. Kurth, G. Martella, and E. Monto-livo, Eds., Rome, Italy, Sept. 1996, number 1146 in LectureNotes in Computer Science, Springer-Verlag, Berlin Germany,also published in: EDI Forum 9/2 (1996) 98-106, see alsohttp://www.semper.org .

[20] SEMPER Consortium, Final report of project SEMPER, De-liverable D13 of ACTS project AC026, Aug. 1999, To appear inthe LNCS Series, Springer Verlag.

[21] Shai Halevi and Hugo Krawczyk, Public-key cryptography andpassword protocols, ACM Transactions on Information andSystem Security, vol. 2, no. 3, pp. 2560, 1999, Preliminaryversion in Proc. of the 5th ACM Conference on Computer andCommunications Security, 1998, pp. 122-131.

[22] Ralf Hauser, Michael Steiner, and Michael Waidner, Micro-payments based on iKP, Research Report 2791 (# 89269),IBM Research, Feb. 1996.

[23] Steve Glassman, Mark Manasse, Martin Abadi, Paul Gauthier,and Patrick Sobalvarro, The millicent protocol for inexpensiveelectronic commerce, in Fourth International Conference onthe World-Wide Web, MIT, Boston, Dec. 1995.

[24] Benjamin Cox, J. D. Tygar, and Marvin Sirbu, NetBill secu-rity and transaction protocol, In First USENIX Workshop onElectronic Commerce [33].

[25] Steen Larsen, Zurich iKP Prototype (ZiP): iKP TransactionLayer Functional Specification, IBM Zurich Research Labora-tory, May 1996.

[26] Ralf Hauser and Michael Steiner, Generic extensions of WWWbrowsers, In First USENIX Workshop on Electronic Commerce[33], pp. 147154.

[27] Gene Tsudik, Zurich iKP prototype: Protocol specificationdocument, Research Report RZ 2792, IBM Research, Feb. 1996.

[28] Els Van Herreweghen, Zurich iKP Prototype (ZiP): CertificateLibrary (CERT) Specification, IBM Zurich Research Laboratory,Feb. 1996.

[29] Michael Steiner, Zurich iKP Prototype (ZiP): CryptographicLibrary Specification, IBM Zurich Research Laboratory, Mar.1996.

[30] ISO/IEC, Information technology - open systems interconnec-tion - the directory: Authentication framework, June 1994,same as ITU-T Rec X.509.

[31] P. Chen, J. Garay, A. Herzberg, and H. Krawcczyk, Designand implementation of modular key management protocol and

IP Secure Tunnel on AIX, in Proc. 5th USENIX UNIX SecuritySyposium, Salt Lake City, Utah, June 1995.

[32] N. Asokan, Victor Shoup, and Michael Waidner, Optimisticfair exchange of digital signatures, in Advances in Cryptol-ogy EUROCRYPT 98, Kaisa Nyberg, Ed. 1998, number 1403in Lecture Notes in Computer Science, pp. 591606, Springer-Verlag, Berlin Germany.

[33] USENIX, First USENIX Workshop on Electronic Commerce,New York, July 1995.

Contents

I Introduction and Overview 1

II History and Related Work 2

III iKP Payment Model 3

IV Security Requirements 4

V The iKP Protocol Family 6V-A 1KP . . . . . . . . . . . . . . . . . . . . . . 8V-B 2KP . . . . . . . . . . . . . . . . . . . . . . 10V-C 3KP . . . . . . . . . . . . . . . . . . . . . . 11V-D Comparison of the iKP protocols . . . . . . 11

VI ZiP: Implementation and Deployment 12VI-AProtocol scenarios . . . . . . . . . . . . . . 12VI-BPayment Authorization . . . . . . . . . . . 12VI-CSeparate Payment Clearance/Capture . . . 14VI-DRefunds . . . . . . . . . . . . . . . . . . . . 14VI-E Inquiry . . . . . . . . . . . . . . . . . . . . . 14VI-F Implementation rationales and explanations 14VI-GArchitecture . . . . . . . . . . . . . . . . . . 15VI-HDeployment . . . . . . . . . . . . . . . . . . 16

A The Encryption Function 19A-A Payload . . . . . . . . . . . . . . . . . . . . 19A-B Encryption process . . . . . . . . . . . . . . 19A-C Decryption process . . . . . . . . . . . . . . 19

List of Figures

1 Generic model of a payment system . . . . . . 32 Keys and cryptograhic primitives used in iKP protocols 63 Definitions of atomic fields used in iKP protocols 74 Framework of iKP protocols . . . . . . . . . . 75 iKP Protocols . . . . . . . . . . . . . . . . . . 96 ZiP Payment Authorization . . . . . . . . . . 138 ZiP: Inquiry protocol . . . . . . . . . . . . . . 147 ZiP: Clearance protocol . . . . . . . . . . . . 159 ZiP implementation architecture . . . . . . . . 1610 Sizes of fields in EncSlip . . . . . . . . . . . . 1911 Encryption using OAEP . . . . . . . . . . . . 1912 Hash-function H1 for OAEP . . . . . . . . . . 1913 Hash-function H2 for OAEP . . . . . . . . . . 2014 Decryption using OAEP . . . . . . . . . . . . 20

http://www.zurich.ibm.com/Technology/Security/publications/1998/ASW98-e% rrata.ps.gzhttp://www.semper.org


Mihir Bellare received his BS (in Mathemat-ics) from the California Institute of Technologyin 1986, and his Ph.D (in Computer Science)from the Massachusetts Institute of Technol-ogy in 1991. He worked at IBM before takinga faculty position at the University of Califor-nia at San Diego. He is a recipient of a Davidand Lucile Packard Fellowship in Science andEngineering, and a NSF CAREER award. Hisresearch areas are cryptography and complex-ity theory. He is one of the designers of HMAC

(an Internet standard for message authentication) and of OAEP (anRSA based encryption scheme currently being proposed to replaceRSA PKCS #1). He has published about 40 papers in cryptography(including 26 in the Crypto and Eurocrypt conferences) and about20 in complexity theory.

Juan A. Garay received his Ph.D. in Com-puter Science from Penn State University in1989. He also holds the degree of Electri-cal Engineer from the Universidad Nacional deRosario in Argentina, and a Masters in EEfrom the Netherlands Universities Foundation(PII) in Eindhoven, Holland. He has been withthe Secure Systems Research Department ofBell Labs since 1998. From 1990 until 1998he was with IBMs T.J. Watson Research Cen-ter. In 1992 he was a postdoctoral fellow at

The Weizmann Institute of Science in Israel, and in 1996 a visitingscientist at the Centrum voor Wiskunde en Informatica (CWI) inHolland. Dr. Garay has published extensively in the areas of al-gorithms, distributed computing, fault tolerance, and cryptographicprotocols.

Ralf Hauser holds a M.Sc. in ComputerScience from the University of Toronto and aPh.D. from the University of Zurich. From1992-1995 he worked as a researcher with theIBM Research Laboratory in Zurich in the fieldof network security and since, he is a consul-tant with McKinsey & Co. Since December1998, he is building for the recently foundedMcKinsey Business Technology Office a GlobalKnowledge Management Team (Service and In-frastructure).

Amir Herzberg received the B.Sc. (Com-puter Engineering), M.Sc. (Electrical Engi-neering) and D.Sc. (Computer Science) de-grees from the Technion Israel Institute ofTechnology, in 1982, 1986, and 1991, respec-tively. Since 1991, he is with the IBM Re-search Division, currently as manager of the E-Business and Security Department at the HaifaResearch Lab. Previously he managed Net-work Security at the Watson Research Center.He has authored numerous papers and patents.

His research areas include electronic commerce, network security, ap-plied cryptography, communication protocols and fault tolerant dis-tributed algorithms.

Hugo Krawczyk is an associate professorat the Department of Electrical Engineering,Technion, Israel, and a visiting scientist at theIBM T.J. Watson Research Center. He re-ceived his Ph.D. in Computer Science from theTechnion, Israel, in 1990. From 1991 to 1997he was a research staff member in the Cryp-tography and Network Security Group at theIBM T.J. Watson Research Center. His areasof interest span applied and theoretical aspectsof cryptography with particular emphasis on

applications to network security. In particular he has been a co-designer of the HMAC authentication function, the IKE key exchangeprotocol for IPSEC, and of the SET protocol for secure credit cardtransactions over the Internet.

Michael Steiner is a research scientist at theDepartment of Computer Science, Universitatdes Saarlandes, Saarbrucken and in the net-work security research group at the IBM ZurichResearch Laboratory. His interests include se-cure and reliable systems as well as cryptogra-phy. He received a Diplom in computer sciencefrom the Swiss Federal Institute of Technology(ETH) in 1992 and expects to receive a Ph.D.in computer science from the Universitat desSaarlandes, Saarbrucken.

Gene Tsudik is a project leader at USC/ISIand a research associate professor in the Com-puter Science Department at USC. His re-search interests include network security, ap-plied cryptography and routing in wireless n

IEEE Journal of Selected Areas in Communications,...

Documents

Transcript of IEEE Journal of Selected Areas in Communications,...