We describe our attack in Section 3. Finally, we conclude in Section 4 by a brief review of the related works.

Transcription

1 Information Processing Letters 97 (2006) A flaw in the electronic commerce protocol SET S. Brlek a,2, S. Hamadou b,1, J. Mullins b,,2 a Laboratoire LaCIM, Département d Informatique, Université du Québec à Montréal, Canada b Laboratoire CRAC, Département de Génie Informatique, École Polytechnique de Montréal, Canada Received 27 April 2005; received in revised form 3 September 2005; accepted 6 October 2005 Available online 28 October 2005 Communicated by D. Basin Abstract The Secure Electronic Transaction (SET) protocol has been developed by the major credit card companies in association with some of the top software corporations to secure e-commerce transactions. This paper recalls the basics of the SET protocol and presents a new flaw: a dishonest client may purchase goods from an honest merchant (with the help of another merchant) for which he does not pay. Fortunately, by checking his balance sheet, the merchant may trace with the help of his bank the client and his accomplice. We also propose a modification to fix the flaw Elsevier B.V. All rights reserved. Keywords: Safety/security in digital systems; Electronic payment protocol; Secrecy; Authentication 1. Introduction From the early 90 s, many payment systems on open networks have been proposed. This initial blossoming has lead to the implementation of complex and ambitious systems. SET [9], which stands for Secure Electronic Transaction, is the most complex and challenging payment system. It is sponsored by the major credit card companies Visa and MasterCard in associ- * Corresponding author. Mailing address: B.P. 6079, Succ. Centreville, Montréal (Québec), Canada H3C 3A7. addresses: brlek@lacim.uqam.ca (S. Brlek), sardaouna.hamadou@polymtl.ca (S. Hamadou), john.mullins@polymtl.ca (J. Mullins). 1 Supported by a NATEQ doctoral scholarship (Government of Quebec). 2 Supported by individual NSERC research grants (Government of Canada). ation with some of the top corporations (IBM, GTE, RSA, Microsoft, Netscape, etc.). SET is not a single payment protocol but rather a set of security protocols divided into two different phases: the registration phase and the purchase phase. Such a complex system is likely to contain errors, but its complexity makes it very hard to verify. Based on previous works (see Section 4) on the SET s verification, one could conclude that if the Acquirer, the Certificate Authority and the Payment Gateway are honest, then SET is a secure system. In this paper we present a flaw in SET which proves that even if these users directly linked to the financial system and having more lucrative crimes to commit are honest, an attack against SET is still possible. The attack is against the purchase phase and exploits a lack of verification in the payment authorization process. It may allow a dishonest customer to cheat on the merchant. The rest of the paper is organized as follows. Section 2 describes the purchase phase of the SET protocol /$ see front matter 2005 Elsevier B.V. All rights reserved. doi: /j.ipl

2 S. Brlek et al. / Information Processing Letters 97 (2006) We describe our attack in Section 3. Finally, we conclude in Section 4 by a brief review of the related works. 2. The SET protocol In order to ensure the security of electronic transactions involving credit cards, the major players Visa and MasterCard, in association with some of the top corporations, have implemented a security standard for such transactions: Secure Electronic Transaction (SET) [9]. SET has a global scope and its main security objectives are to ensure the confidentiality and integrity of the transaction s data as well as the authentication of the different involved entities. SET consists of the following five sub-protocols: Cardholder registration: the Cardholder or client (C) transmits to a trusted Certificate Authority (CA) his card number (called the primary account number or PAN), a secret nonce (called CardSecret) and his public signature key. Upon validation, the CA issues a public key certificate (digital ID) including the hash code of the PAN and the PANSecret a secret nonce which is the result of an exclusive-or of the CardSecret and a random nonce chosen by the CA that plays the role of the PIN for the physical card. Merchant and Payment Gateway registration: itis similar to the client registration. They register both their public encryption and signature keys, and obtain two certificates. Purchase request: it enables the client to securely send payment instructions to the Merchant, but the latter does not have access to the client s card data. Payment authorization: it enables the Merchant to check with the Payment Gateway the client s card clearance and to validate the transaction. Transaction payment: the Merchant issues a payment request to the Gateway. The first two protocols constitute the SET s registration phase and its main goal is to provide the customer, Merchant and Payment Gateway with certificates signed by a trusted Certificate Authority that associate their public keys to their identities. The issued certificates are then used for their mutual authentication in any subsequent transaction. The last three protocols, usually called the SET purchase protocols, constitute the electronic transaction itself. Cryptographic notations. The agents are the Cardholder (C), the Merchant (M) and a Payment Gateway (G). A secret session key generated by the principal X is denoted by K X and his public encryption key by PK X. The cryptogram {m} K is obtained by encrypting the message m with the key K, and H(m)is the hashing of m. The signature of a message m by the principal X is denoted by S X (m) and the signature only by SO X (m) (it does not include the message m). We suppose, as stated in SET s specification, that certificates are implicit; that is, a signed message always contains the certificate of the public key needed to verify the signature. Chall X denotes a random fresh challenge (a nonce) generated by X. Finally, CertE X (Y ) and CertS X (Y ) denote, respectively, the certificates of encryption and public signature keys of Y signed by X. The purchase phase is complex and involves three parties: the Cardholder (C), the Merchant (M) and a Payment Gateway (G). SET uses many optional data and, depending on which are taken into account, we may obtain different alternative versions of the purchase phase. The most difficult task is to find a version that is both simple and relatively close to reality. Following an idea in [3] we consider a single transaction involving no optional data. We suppose that when a transaction is authorized, the Merchant does not need to request a payment capture to be paid. Therefore the payment capture is not included in our version. To simplify the analysis, we use public key encryption as an abstraction of digital envelopes. Fig. 1 illustrates SET s purchase protocol where a transaction is processed as follows. Initialization request. Before the purchase begins, the Cardholder and the Merchant agree upon the order description and the purchase amount. This shopping step is out of the SET protocol. The Cardholder then sends to the Merchant his local ID (LID C ) and a fresh random challenge. Initialization response. The Merchant generates a transaction ID (XID), a 20 bytes random number, serving as a unique transaction ID and sends it to the customer together with the Gateway s public encryption key certificate. The purpose of this step is to provide the Cardholder with the Merchant s signature certificate and the Gateway s encryption certificate (recall that certificates are implicit). Order request. After validating both certificates, the Cardholder sends an order request which contains the Payment Instruction (PI), the Order Information (OI) and the Dual Signature (DualSign) to the Merchant. The OI carries information to link the purchase request to prior shopping and ordering dialogue between the Cardholder and the Merchant. PI is the most central and sensitive data structure

3 106 S. Brlek et al. / Information Processing Letters 97 (2006) Initialization (1) InitReq C M: LID C, Chall C (2) InitRes C M: S M (LID M, LID C, XID, Chall C, Chall M, CertE CA (G)) Purchase (3) PurchReq C M: OI,DualSign, {PI} PKG Authorization (4) AuthReq M G: {S M (AuthData, LinkOIPI)} PKG, DualSign, {PI} PKG where AuthReqData = H(OIData), HOD, LID M, LID C, XID, AuthRRTags and LinkOIPI = H(AuthReqData, DualSign, {PI} PKG ) (5) AuthRes M G: {S G (LID M, LID C, XID, AuthRRTags, PurchAmt, AuthCode)} PKM Purchase continued (6) PurchRes C M: S M (LID M, LID C, XID, Chall C, AuthCode) Fig. 1. SET purchase phase. in SET. It is used to pass the data required to authorize a payment card from the Cardholder to the Payment Gateway, which uses the data to initiate a payment card transaction through the traditional payment card financial network. The data is encrypted by the Cardholder using the Gateway s public key and sent via the Merchant so that it is hidden from the Merchant. The purpose of the Dual Signature (DualSign) is to link the two messages OI and PI that are intended for two different recipients. The link ensures the Gateway that the Cardholder and the Merchant agree on the same order and it can be used to resolve disputes. The OI, PI and Dual- Sign are computed as follows. HOD := H(OrderDesc, PurchAmt) PIHead := LID M, LID C, XID, HOD, PurchAmt, MerID, H(XID, CardSecret) OIData := LID M, LID C, XID, Chall M, Chall C, HOD PANData := PAN, PANSecret PIData := PIHead, PANData DualSign := SO C (H (PIData), H (OIData)) PI := PIHead,H(OIData), PANData OI := OIData,H(PIData) where OrderDesc is the description of the customer s detailed order and PurchAmt the total amount of the purchase order. PAN is the Cardholder s primary account number (his credit card number) and PANSecret a secret number known to the Cardholder used to prove his identity when making purchases. MerID is the Merchant ID (assigned by his bank) copied by the Cardholder from the Merchant s certificate. The Merchant verifies the OI and the Dual Signature using the hash code H(PIData) included in the OI. Authorization request. It contains the PI and the DualSign sent by the Cardholder, the hash codes H(OIData) and HOD, which enable the Gateway to verify the Dual Signature, the different IDs involved in the transaction, and the authorization request/response tags (AuthRRTags) that the Gateway must include in the authorization response. The purpose of AuthRRTags is to match the request/response paired messages; it contains (MerID) the Merchant s financial ID and some optional data that may be used by the Merchant s bank to authorize the transaction. Authorization response. If both PI and OI agree, the Gateway proceeds to the transaction authorization with the Acquirer using the existing financial networks. If authorization is allowed, the Gateway sends the authorization response containing AuthRRTags copied from AuthReq, the purchase amount and the transaction status (a boolean value). Purchase response. The Merchant verifies the Gateway s signature and that the IDs and AuthRRTags included in the response match those sent in his request message. Then he forwards to the Cardholder the authorization status combined with the different IDs and challenges involved in the transaction. We analyzed the SET s purchase phases using ASPIC [1], a model-checker for cryptographic protocols under development and discovered a design flaw that can be exploited by dishonest customers to cheat the Merchant.

4 S. Brlek et al. / Information Processing Letters 97 (2006) The attack We exploit now a weakness in the purchase authorization process by the Gateway to develop an attack against SET. The attack is similar to the Lowe s [7] attack against the Needham Schröder protocol and other published attacks such as the Gürgens and Rudolph s attack [5] on the Zhou Gollmann non-repudiation protocol; it involves the deliberate re-use of a supposedly unique session identifier. It is also similar to the attack against SET found by Bella et al. [3]: the attack is possible because signed SET messages contain too little contextual information (so-called explicitness). Both attacks involve a dishonest person re-encrypting received information by using another person s public encryption key. But unlike the attack in [3], requiring the existence of a corrupted Payment Gateway who has more lucrative crimes to commit our attack requires only a collusion between a dishonest merchant and the client. Note that SET defines the local IDs as follows ([9], book 2, p. 267): LID C and LID M are identifiers which are assigned by the Cardholder, Merchant, and/or payment system infrastructure to tag transactions in a manner convenient for each of them; however, other parties may not assume characteristics of these labels. LID M may often be used to hold the Merchant s order number associated with the transaction. Therefore the LID M cannot identify the Merchant and any other Merchant could possibly use the same LID M. Our attack is based on the way the authorization request message (AuthReq) (Fig. 1) is processed by the Gateway. It proceeds as follows. The customer decides to purchase goods but does not want to pay the Merchant. With the help of his accomplice (the Intruder), who must be a Merchant, the customer purchases the same goods from both the honest Merchant and his accomplice using the same supposedly unique transaction IDs (LID M, LID C, XID). This is possible in SET since neither LID M nor XID (a random number) identify the Merchant. The Cardholder sends them the purchase requests (3) PurchReq C M: OI, DualSign, {PI} PKG (3 ) PurchReq C I: OI, DualSign4I, {PI4I} PKG These two messages differ only in the PIHead which appears in both DualSign and PI. In the first message it contains the honest Merchant s ID (MerID) and in the second one the Intruder s one. Both Merchants generate their authorization requests and send them to the Gateway, but the Intruder intercepts the Merchant s request and destroys it. The Gateway proceeds with the Intruder s (4) AuthReq I G: {S I (AuthReqData, ILinkOIPI)} PKG, DualSign4I, {PI4I} PKG where and AuthReqData = H(OIData), HOD, LID M, LID C, XID, AuthRRTags ILinkOIPI = H(AuthReqData, DualSign4I, {PI4I} PKG ) and validates it. Note that the AuthRRTags in the Intruder s authorization request contains MerID, the honest Merchant s ID (not the Intruder s one), but the Gateway does not verify this value ([9], book 3, p. 354). Therefore it is not a real lack of explicitness, but rather a bad verification process. Indeed, the message contains all that is necessary to detect the attack but a weak process verification makes it possible in SET. The Gateway authorizes the transaction and sends the authorization response (5) AuthRes I G: {S G (LID M, LID C, XID, AuthRRTags, PurchAmt, AuthCode)} PKI to the Intruder. As in the Lowe s attack [7], he reencrypts it using the Merchant s public key. When the Merchant receives this authorization response (5 ) AuthRes M I(G): {S G (LID M, LID C, XID, AuthRRTags, PurchAmt, AuthCode)} PKM containing the right transaction IDs and AuthRRTags, signed by the Gateway, he believes that he will receive payment and delivers the goods; so the customer purchased goods from the honest Merchant but pays his accomplice. Fortunately when the Merchant realizes that sales do not balance in his account, he may request the necessary information from his bank in order to trace the faulty transactions and identify the client and his accomplice. It would be sufficient that the Gateway compares the Merchant s ID in the AuthRRTags and the one included in the customer s PI to detect the attack. But a more realistic solution which can guarantee non-repudiation is to bind under the Gateway signature the merchant s and the client s identities. 4. Related works and conclusion Before concluding, let us briefly review some previous works on the verification of SET. In [10] Meadows and Syverson use the temporal language NPATRL to

5 108 S. Brlek et al. / Information Processing Letters 97 (2006) specify many SET requirements, leaving the verification for further research. In [3] the authors prove that the presence of the double signature in the payment authorization request implies that the client is actually the message sender. However, this does not guarantee non-repudiation. Indeed, the analysis carried out by Van Herreweghen [12] reveals some open problems, in particular the fact that SET does not deliver any secure acknowledgment to the client. Also in [3] an attack against SET is described which is similar to our attack involving the presence of a bad Payment Gateway who colludes with a bad Merchant to harm the Cardholder. In [6] Kessler and Neumann propose an authentication logic extending the logic AUTLOG used for modeling the accountability in electronic commerce and then use that logic for formally checking SET and conclude that it is secure. Bolignano [4] describes a verification methodology for analyzing the payment protocols by means of proofs in modal logic. A case study has been done on C-SET, a variant of SET. In [8] Lu and Smolka propose a simplified version of SET checked with FDR, a modelchecker based on the language CSP. Their analysis concludes that the simplified version is secure. However Panti et al. [11] propose two attacks on that version, although these attacks cannot be performed on SET itself. In [2] Bella et al. analyze the registration phase of SET with the help of the Isabelle theorem prover. Their analysis reveals some ambiguities and contradictions in the specification of SET. They also discovered that the verification of properties such as authentication (of messages) and (client merchant) agreement cannot be proved for the whole protocol because of the optional use of nonces. In this paper, we outline the SET protocol and present a flaw in its purchase phase. The attack exploits a weak verification process and allows a dishonest customer to purchase goods for which he does not pay. Our model of SET is more complex than the one in [3], which does not include the AuthRRTags. The flaw could have been discovered in that model [3] but it seems that many authors consider that the supposedly unique IDs (LID M, XID) uniquely identify a given Merchant and a given transaction. This is a plausible explanation for their failure to find the flaw. Acknowledgements The authors wish to thank the anonymous referees for the very careful reading of the paper and their valuable comments. References [1] G. Bastien, J. Mullins, ASPiC: a tool for symbolic analysis of crypto-protocols based on interference checking, in: K. Adi, D. Amyot, L. Logrippo (Eds.), Actes du 5-ième colloque international sur les Nouvelles Technologies de la Répartition (NOTERE2005), 2005, pp [2] G. Bella, F. Massacci, L. Paulson, P. Tramontano, Formal verification of cardholder registration in SET, in: Proc. 6th European Symp. on Research in Comp. Security (ESORICS00), in: Lecture Notes in Comput. Sci., vol. 1895, Springer, Berlin, 2000, pp [3] G. Bella, F. Massacci, L. Paulson, The verification of an industrial payment protocol: the SET purchase phase, in: V. Atluri (Ed.), Proc. 9th ACM Conf. on Computer and Comm. Security, ACM Press, New York, 2002, pp [4] D. Bolignano, Towards the formal verification of electronic commerce protocols, in: Proc. 10th IEEE Computer Security Foundations Workshop, 1997, pp [5] S. Gürgens, C. Rudolph, Security analysis of (un-)fair non-repudiation protocols, in: Lecture Notes in Comput. Sci., vol. 2629, Springer, Berlin, 2003, p. 97. [6] K. Kessler, H. Neumann, A sound logic for analyzing electronic commerce protocol, in: Proc. 5th European Symp. on Research in Comp. Security (ESORICS98), in: Lecture Notes in Comput. Sci., vol. 1485, Springer, Berlin, 1998, pp [7] G. Lowe, Breaking and fixing the Needham Schröder public-key protocol using CSP and FDR, in: Proc. 2nd Internat. Conf. on Tools and Algorithms for the Construction and Analysis of Systems, TACAS 96, in: Lecture Notes in Comput. Sci., vol. 1055, Springer, Berlin, 1996, pp [8] S. Lu, S.A. Smolka, Model checking the secure electronic transaction (SET) protocol, in: Proc. 7th Internat. Symp. on Modeling, Analysis and Simulation of Comp. and Telecom. Systems, 1999, pp [9] MasterCard/Visa, SET Secure Electronic Transaction Specification: Books 1 3, May [10] C. Meadows, P. Syverson, A formal specification of requirements for payment transactions in the SET protocol, in: Proc. 2nd Conf. on Financial Cryptography, in: Lecture Notes in Comput. Sci., vol. 1465, Springer, Berlin, 1998, pp [11] M. Panti, L. Spalazzi, S. Tacconi, S. Valenti, Automatic verification of security in payment protocols for electronic commerce, in: Proc. 4th Internat. Conf. on Enterprise Inform. Systems (ICEIS 02), 2002, pp [12] E. Van Herreweghen, Non-repudiation in SET: open issues, in: Proc. 4th Conf. on Financial Cryptography, in: Lecture Notes in Comput. Sci., vol. 1962, Springer, Berlin, 2001, pp