Information Processing Letters 97 (2006) 104–108

www.elsevier.com/locate/ipl

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.
 2005 Elsevier B.V. All rights reserved.

Keywords: Safety/security in digital systems; Electronic payment protocol; Secrecy; Authentication

1. Introduction ation with some of the top corporations (IBM, GTE,

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 am-
bitious systems. SET [9], which stands for “Secure
Electronic Transaction”, is the most complex and chal-
lenging payment system. It is sponsored by the major
credit card companies Visa and MasterCard in associ-
* Corresponding author. Mailing address: B.P. 6079, Succ. Centre-
ville, Montréal (Québec), Canada H3C 3A7.
E-mail 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).
0020-0190/$ – see front matter  2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.ipl.2005.10.002
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 Ac-
quirer, the Certificate Authority and the Payment Gate-
way 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 mer-
chant. The rest of the paper is organized as follows. Sec-
tion 2 describes the purchase phase of the SET protocol.
 S. Brlek et al. / Information Processing Letters 97 (2006) 104–108
We describe our attack in Section 3. Finally, we con-
clude in Section 4 by a brief review of the related works.
2. The SET protocol
In order to ensure the security of electronic transac-
tions involving credit cards, the major players Visa and
MasterCard, in association with some of the top corpo-
rations, have implemented a security standard for such
transactions: Secure Electronic Transaction (SET) [9].
SET has a global scope and its main security objec-
tives 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 fol-
lowing five sub-protocols:
• Cardholder registration: the Cardholder or client
(C) transmits to a trusted Certificate Authority (CA)
his card number (called the primary account num-
ber 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 se-
cret 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: it is
similar to the client registration. They register both
their public encryption and signature keys, and ob-
tain 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 pay-
ment request to the Gateway.
The first two protocols constitute the SET’s regis-
tration phase and its main goal is to provide the cus-
tomer, Merchant and Payment Gateway with certificates
signed by a trusted Certificate Authority that associate
their public keys to their identities. The issued certifi-
cates are then used for their mutual authentication in any
subsequent transaction. The last three protocols, usually
called the SET purchase protocols, constitute the elec-
tronic transaction itself.
Cryptographic notations. The agents are the Card-
holder (C), the Merchant (M) and a Payment Gate-
105
way (G). A secret session key generated by the principal
X is denoted by KX 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 SX (m) and the signature only by SOX (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. ChallX de-
notes a random fresh challenge (a nonce) generated by
X. Finally, CertEX (Y ) and CertSX (Y ) denote, respec-
tively, 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 pay-
ment 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 digi-
tal 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 (LIDC ) 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 Informa-
tion (OI) and the Dual Signature (DualSign) to the
Merchant. The OI carries information to link the
purchase request to prior shopping and ordering di-
alogue between the Cardholder and the Merchant.
PI is the most central and sensitive data structure
106 S. Brlek et al. / Information Processing Letters 97 (2006) 104–108

Initialization
(1) InitReq C → M: LIDC , ChallC
(2) InitRes C ← M: SM (LIDM , LIDC , XID, ChallC , ChallM , CertECA (G))
Purchase
(3) PurchReq C → M: OI, DualSign, {PI}PK G
Authorization
(4) AuthReq M → G: {SM (AuthData, LinkOIPI)}PK G , DualSign, {PI}PK G
where AuthReqData = H (OIData), HOD, LIDM , LIDC , XID, AuthRRTags
and LinkOIPI = H (AuthReqData, DualSign, {PI}PK G )
(5) AuthRes M ← G: {SG (LIDM , LIDC , XID, AuthRRTags, PurchAmt, AuthCode)}PK M
Purchase continued
(6) PurchRes C ← M: SM (LIDM , LIDC , XID, ChallC , AuthCode)

Fig. 1. SET purchase phase.

in SET. It is used to pass the data required to au-
thorize 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 en-
crypted by the Cardholder using the Gateway’s pub-
lic key and sent via the Merchant so that it is hidden
from the Merchant. The purpose of the Dual Signa-
ture (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 := LIDM , LIDC , XID, HOD, PurchAmt,
MerID, H (XID, CardSecret)
OIData := LIDM , LIDC , XID, ChallM ,
ChallC , HOD
PANData := PAN, PANSecret
PIData := PIHead, PANData
DualSign := SOC (H (PIData), H (OIData))
PI := PIHead, H (OIData), PANData
OI := OIData, H (PIData)
where OrderDesc is the description of the cus-
tomer’s detailed order and PurchAmt the total
amount of the purchase order. PAN is the Cardhold-
er’s primary account number (his credit card num-
ber) 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 Mer-
chant’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 Du-
alSign sent by the Cardholder, the hash codes
H (OIData) and HOD, which enable the Gate-
way to verify the Dual Signature, the different
IDs involved in the transaction, and the autho-
rization request/response tags (AuthRRTags) that
the Gateway must include in the authorization re-
sponse. The purpose of AuthRRTags is to match
the request/response paired messages; it contains
(MerID) the Merchant’s financial ID and some op-
tional 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 authoriza-
tion with the Acquirer using the existing financial
networks. If authorization is allowed, the Gate-
way 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 Gate-
way’s signature and that the IDs and AuthRRTags
included in the response match those sent in his re-
quest 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.
 S. Brlek et al. / Information Processing Letters 97 (2006) 104–108
3. The attack
We exploit now a weakness in the purchase autho-
rization process by the Gateway to develop an attack
against SET. The attack is similar to the Lowe’s [7] at-
tack 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 pro-
tocol; it involves the deliberate re-use of a supposedly
“unique” session identifier. It is also similar to the at-
tack 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 at-
tacks 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 lucra-
tive crimes to commit—our attack requires only a collu-
sion between a dishonest merchant and the client. Note
that SET defines the local IDs as follows ([9], book 2,
p. 267):
“LIDC and LIDM are identifiers which are assigned by
the Cardholder, Merchant, and/or payment system in-
frastructure to tag transactions in a manner convenient
for each of them; however, other parties may not assume
characteristics of these labels. LIDM may often be used
to hold the Merchant’s order number associated with the
transaction.”
Therefore the LIDM cannot identify the Merchant
and any other Merchant could possibly use the same
LIDM . 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 Mer-
chant. 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 ac-
complice using the same supposedly “unique” transac-
tion IDs (LIDM , LIDC , XID). This is possible in SET
since neither LIDM nor XID (a random number) identify
the Merchant. The Cardholder sends them the purchase
requests
(3) PurchReq C → M: OI, DualSign, {PI}PK G
(3 ) PurchReq C → I: OI, DualSign4I, {PI4I}PK G
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 Gate-
way, but the Intruder intercepts the Merchant’s request
107
and destroys it. The Gateway proceeds with the Intrud-
er’s
(4) AuthReq I → G:
{SI (AuthReqData, ILinkOIPI)}PK G , DualSign4I, {PI4I}PK G
where
AuthReqData = H (OIData), HOD, LIDM , LIDC , XID, AuthRRTags
and
ILinkOIPI = H (AuthReqData, DualSign4I, {PI4I}PK G )
and validates it. Note that the AuthRRTags in the Intrud-
er’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). There-
fore 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 au-
thorizes the transaction and sends the authorization re-
sponse
(5) AuthRes I ← G:
{SG (LIDM , LIDC , XID, AuthRRTags, PurchAmt, AuthCode)}PK I
to the Intruder. As in the Lowe’s attack [7], he re-
encrypts it using the Merchant’s public key. When the
Merchant receives this authorization response
(5 ) AuthRes M ← I(G):
{SG (LIDM , LIDC , XID, AuthRRTags, PurchAmt, AuthCode)}PK M
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 pur-
chased goods from the honest Merchant but pays his ac-
complice. 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 ac-
complice.
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 re-
alistic 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 previ-
ous works on the verification of SET. In [10] Meadows
and Syverson use the temporal language NPATRL to
108 S. Brlek et al. / Information Processing Letters 97 (2006) 104–108
specify many SET requirements, leaving the verifica-
tion 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 par-
ticular the fact that SET does not deliver any secure ac-
knowledgment 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 ac-
countability in electronic commerce and then use that
logic for formally checking SET and conclude that it is
secure. Bolignano [4] describes a verification method-
ology 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 model-
checker based on the language CSP. Their analysis con-
cludes 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 it-
self. 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 contradic-
tions 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 cus-
tomer 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
(LIDM , 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 valu-
able 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 in-
ternational sur les Nouvelles Technologies de la Répartition
(NOTERE2005), 2005, pp. 63–76.
[2] G. Bella, F. Massacci, L. Paulson, P. Tramontano, Formal verifi-
cation of cardholder registration in SET, in: Proc. 6th European
Symp. on Research in Comp. Security (ESORICS00), in: Lec-
ture Notes in Comput. Sci., vol. 1895, Springer, Berlin, 2000,
pp. 159–174.
[3] G. Bella, F. Massacci, L. Paulson, The verification of an indus-
trial 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. 12–20.
[4] D. Bolignano, Towards the formal verification of electronic com-
merce protocols, in: Proc. 10th IEEE Computer Security Foun-
dations Workshop, 1997, pp. 133–146.
[5] S. Gürgens, C. Rudolph, Security analysis of (un-)fair non-repu-
diation 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. 345–360.
[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 Sys-
tems, TACAS’96, in: Lecture Notes in Comput. Sci., vol. 1055,
Springer, Berlin, 1996, pp. 146–166.
[8] S. Lu, S.A. Smolka, Model checking the secure electronic trans-
action (SET) protocol, in: Proc. 7th Internat. Symp. on Modeling,
Analysis and Simulation of Comp. and Telecom. Systems, 1999,
pp. 358–365.
[9] MasterCard/Visa, SET Secure Electronic Transaction Specifica-
tion: Books 1–3, May 1997.
[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. 122–140.
[11] M. Panti, L. Spalazzi, S. Tacconi, S. Valenti, Automatic ver-
ification of security in payment protocols for electronic com-
merce, in: Proc. 4th Internat. Conf. on Enterprise Inform. Sys-
tems (ICEIS’02), 2002, pp. 968–974.
[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. 140–156.