CONSEPP: CONvenient and Secure Electronic Payment Protocol Based on X9.

59

Albert Levi Çetin Kaya Koç

Information Security Lab Information Security Lab
Electrical and Computer Engineering Dept. Electrical and Computer Engineering Dept.
Oregon State University, Oregon State University,
Corvallis, Oregon 97331 Corvallis, Oregon 97331
levi@ece.orst.edu koc@ece.orst.edu

Abstract We will follow e-commerce terminology and refer to the

The security of electronic payment protocols is of interest to payer as “consumer” and the payee as “merchant”. All e-
researchers in academia and industry. While the ultimate payment systems involve transfer of funds and monetary
objective is the safest and most secure protocol, convenience instruments. Thus, FIs are irreplaceable players in e-
and usability should not be ignored, or the protocol may not be payment systems.
suitable for large-scale deployment. Our aim in this paper is to There are several e-payment methods proposed, but
design a practical electronic payment protocol which is both only a few are being used successfully. CyberCash [1],
secure and convenient.
which is based on payment-card transactions, is one.
ANSI X9.59 standard describes secure payment objects to be
used in electronic payment in a convenient and secure way. It Electronic money systems [2] are not as successful as
has many useful convenience features for large-scale consumer credit-card methods. Secure Electronic Transaction (SET)
market deployment, the best being the elimination of consumer [3] is another payment-card based protocol. Although it is
certificates. Consumer public keys are stored in account records not specifically designed for electronic payment, Secure
at financial institutions; the digital signatures issued by Socket Layer (SSL) [4] based e-payment methods are at
consumers are verified by financial institutions. Encryption is present the most widely used. Combinations of these
deliberately not provided by X9.59. methods are also possible. For example, a system might
In this paper we propose a new Internet e-payment protocol, use SSL between the consumer and merchant, and SET
namely CONSEPP (CONvenient and Secure E-Payment
between the merchant and FIs.
Protocol), based on the account authority model of ANSI X9.59
standard. CONSEPP is the specialized version of X9.59 for The security of an e-payment method is very
Internet transactions (X9.59 is multi-purpose). It has some extra important for all parties involved in a transaction, but
features on top of the X9.59 standard. X9.59 requires merchant security alone does not guarantee success in the
certificates; in CONSEPP we propose a lightweight method to marketplace. An e-payment system must also be
avoid the need for merchant certificates. Moreover, we propose convenient. This requirement has different meanings for
a simple method for secure shopping experience between different parties. From the consumer’s point of view,
merchant and consumer. Merchant authentication is embedded “convenience” means to pay quickly and without an
in the payment cycle. CONSEPP aims to use current financial additional cost or too much effort. From the FI’s point of
transaction networks, like VisaNet, BankNet and ACH networks,
view, “convenience” means low deployment and
for communications among financial institutions. No certificates
(in the classical sense) or certificate authorities exist in operational cost. The “convenience” requirement is
CONSEPP. Convenience is not traded for security here; basic generally ignored by security developers whose aim is to
security requirements are fulfilled in the payment authorization make the system as secure as possible. However, the aim
cycle without extra messaging and significant overhead. should be to design a system which is both “secure” and
“convenient”.

1. Introduction 1.1. Contribution of the paper

One of the most important components of an SET is a good example of a protocol that ignores
electronic commerce (e-commerce) application is a “convenience”. SSL-based methods, on the other hand,
digitally secure means of electronic payment (e-payment). are ignoring important “security” requirements. In this
E-payment may be treated as a protocol among the payer, paper we propose a new e-payment protocol for Internet
the payee and their respective Financial Institutions (FIs). based transactions. Our aim is to balance the trade-off
between security and convenience. This protocol, named An SSL based protocol provides privacy, integrity and
CONSEPP (CONvenient and Secure E-Payment authentication of merchant to consumer. However, it does
Protocol), is based on ANSI X9.59 [5] standard. This not guarantee the authentication of consumer to merchant
standard describes secure payment object to be used in and consumer non-repudiation. The consumer may deny
electronic payment. It is not restricted to Internet-based making the payment and the merchant may not be able to
payment; same idea could be applied to Point-of-Sale prove the fact even if the transaction was legitimate. This
terminals, Mail-Order and Telephone-Order payments. causes a “charge-back” cost for honest merchants due to
However, CONSEPP is for Internet transactions only. In dishonest consumers. The SSL based methods may also
CONSEPP, we add some more features on top of the work for dishonest merchants to make illegal money. The
X9.59 standard to make it more specific for Internet based merchant has to see the consumer’s account information
payments. We solve the existing merchant certificate in order to initiate the authorization process after
problem of X9.59 with dynamic public key transfers receiving the payment order from the consumer. The
embedded in authorization messages. We propose a merchant could intentionally or unintentionally disclose
secure method for shopping experience in which this sensitive account information. Furthermore, since the
merchant authentication is embedded in payment cycle. consumer’s FI has no way to check the intent of the
These extra features are light methods and do not create a consumer to make the payment, a dishonest merchant is
significant burden on transactions. As a result, we end up also able to use this account information later to make
with a certificate-free and convenient Internet e-payment charges without the consent of consumer. Of course, the
method that satisfies the security requirements of all consumer can rightfully repudiate this bogus transaction.
parties. However, transactions that are overlooked would be to the
In the rest of this section the trade-off of security vs. benefit of the dishonest merchant.
convenience will be detailed using two applications, SSL Another class of electronic payment methods involves
and SET. Section 2 discusses the basic characteristics of the FIs in the protocol. The most well-known example is
the X9.59 model. CONSEPP is explained in Section 3. the Visa and MasterCard joint effort, the Secure
The advantages of CONSEPP are the subject of Section 4. Electronic Transaction (SET) protocol [3]. The
Some further discussions are given in Section 5. interaction among FIs in the settlement network is not a
Conclusions are in Section 6. part of SET. Communication between FIs and
consumer/merchant is defined in the protocol. The
1.2. SSL, SET and their disadvantages authentication and non-repudiation requirements require
the use of digital signatures and consequently of digital
SSL [4] is a protocol that provides a private, encrypted certificates for each message. Privacy and integrity are
session between the client and the server. The protocol also attained. Each SET cardholder must have a digital
and its related certificates are widely used in web certificate issued by a trusted Certificate Authority (CA).
browsers. The server authenticates itself to the client The cardholder’s public key is certified via a digital
using the server certificate, but the authentication of the certificate. This is necessary, because otherwise no one
client to the server is optional. In electronic payment can be sure of the legitimacy of a cardholder’s identity or
terminology, server means merchant; client means of the public key. SET provides all necessary security
consumer. In a basic electronic payment protocol based requirements, unfortunately by sacrificing “convenience”.
on SSL, a consumer sends account information and the Currently, SET is not widely deployed and we believe
transaction amount over an SSL protected connection. that it will not be in the near future. We also believe that
The merchant also sends the acknowledgment over the the FIs are less than eager to deploy SET, for reasons
same channel. The authorization for the transfer of funds discussed below.
from the consumer’s account is done as in classic Mail-
Order/Telephone-Order transactions. This step is 1. SET requires the registration of consumers by their FIs.
transparent to the consumer. Such a protocol is not only They need to have certificates in order to use the
easy to implement but also minimally changes the protocol. However, SSL based solutions do not require
traditional business model. Therefore it is very such registration.
“convenient”. The consumer does not need to register and 2. SET requires a PKI (Public Key Infrastructure) that is
obtain another account or card for electronic payment. defined in [3]. A PKI is a complete system for
The merchant and the FIs will make only slight certificates. The FIs, the payment brands and the end
modifications to the traditional authorization and users come together in a hierarchical manner in this
settlement procedures. Some new interfaces may need to PKI. The certificates are issued by independent CAs.
be implemented in order to provide automated responses We think that this PKI, as all other distributed and
to the consumer. large CA-based PKIs, is unlikely to be used, because
the implementation and maintenance cost of this PKI,
 which is to be paid to CAs, would be an extra expense acknowledgment to the merchant via the Merchant’s FI
for the FIs. (MFI).
3. SET is only for payment-card (credit or debit) based Since the account information of the consumer is
transactions. Account based transactions, like already held in the CFI’s site, it would not be difficult to
electronic check (e-check), are not included in SET. hold the consumer’s public key as another field of this
account record. Moreover, the transaction should be
1.3. Motivation behind X9.59 forwarded to the CFI in order to allocate enough funds for
the authorization. An acknowledgment should also be sent
SSL based protocols are convenient but have some to the merchant for this fund authorization. In X9.59,
authentication and non-repudiation problems. SET and these authorization and acknowledgment messages
other payment-card based protocols, which require either contain the digital signature and its verification
intermediary agents or CA-based PKI, are secure, but not information as well. The X9A10 committee believes that
so convenient, particularly for FIs. X9.59 standard tries to this payment method does not require changing the
find a middle ground in the security-versus-convenience existing settlement infrastructure tremendously. A few
trade-off. addenda fields in the current messages would solve the
The Account Authority Digital Signature (AADS) problem. Furthermore, the business model remains the
model was first introduced by Lynn and Anne Wheeler same.
[6] in 1997 as the part of the ANSI X9.59 “Electronic Another important characteristic of the X9.59 model is
Commerce for Financial Services Industry” that messages transmitted among the consumer, merchant
standardization efforts. The Wheelers and ANSI X9A10 and FIs are not encrypted. However, the X9.59 draft
working group shaped the AADS idea and used it in the standard [5] states that encryption could be provided by
X9.59 standard. As of this writing, X9.59 is in DSTU some other means outside the scope of X9.59 standard.
(Draft Standard for Trial Use) status. Some prototype Justifications for this challenging characteristic are as
implementations are being developed. In the rest of this follows.
paper, the terms AADS model and X9.59 model will be
used interchangeably. 1. X9.59 uses Payment Routing Code (PRC) instead of
The Wheelers tried to eliminate the requirement of a consumer and merchant account/card numbers. This is
Certificate Authority (CA), and consequently a CA-based an FI-assigned account number that internally
PKI, in order to verify a public-key based digital identifies a consumer or a merchant. PRCs are X9.59
signature, because they strongly believe that the existence specific and are not used elsewhere. FIs assign and
of a CA-based certification system has no part in business pass PRCs to their customers when they are registered
models for the financial services industry. They use the for the first time. This is part of the account setup
name “Certificate Authority Digital Signature (CADS)” to procedure. Consumers and merchants use their PRCs
describe the classical way to obtain a public key using for all X9.59 transactions, instead of regular
certificate(s) and to verify a digital signature using this account/card numbers. PRCs are not one-time, their
certificate. They name their method AADS, since the holders use the same value for all their X9.59
public key necessary for the verification does not come transactions. The FIs keep the mappings between the
from a CA in their method. The public key is stored and PRCs and conventional account numbers in order to
used by the account authority (i.e., the FI) of the entity. process an X9.59 transaction, but they do not reveal
this mapping. In this way, the binding between a PRC
2. Basic characteristics of the X9.59 model and its holder becomes a secret between the holder and
its FI. A PRC is not valid unless there is an
The basic idea behind the AADS model as proposed accompanying digital signature issued by its owner.
by the Wheelers for the X9.59 standard is to avoid the Any third party cannot take advantage of knowing
necessity of consumer certificates. However, to verify the PRC, since it cannot produce a digital signature. Thus,
signatures issued by the consumer, a public key is still PRCs need not be encrypted.
necessary. The merchant verifies the digital signature of 2. The strong authentication that X9.59 claims to provide
the consumer in most of the electronic payment protocols. is sufficient to prevent the majority of consumer and
However in X9.59, the Consumer’s FI (CFI) is the merchant frauds. Using the PRC concept and strong
authority who verifies the consumer’s digital signature. authentication make encryption a luxury in X9.59. The
The consumer’s public key is stored in the consumer’s X9.59 group believe that strong privacy via encryption
account record held by the CFI. Therefore, no consumer is one of the reasons behind the failure of SET [3],
certificate is necessary. Having verified the signature of since such an approach slows down the transaction
the consumer on the payment order, the CFI sends an processing and creates extra key distribution problems.
3. Having no encryption makes the system suitable for – merchant authentication that is embedded in the
consumers who use wireless devices. Processing speed payment cycle,
and power consumption are important problems of – a method for secure shopping experience,
wireless devices. End-user wireless devices can save – authorization request and response messages,
some time and power by having no encryption. – a lightweight method for merchant’s public key
4. X9.59 is not an Internet-only standard. Implementation transfer from MFI to consumer.
is possible in existing point-of-sale networks where the
consumer/merchant transaction occurs at a physical These features are detailed in Sections 3.2, 3.3, 3.4
box located on the merchant’s premises. The and 3.5.
encryption requirement is minimal in such a classical
transaction. 3.1. Basic payment cycle

Integrity is inherently supplied by the digital signature A generic CONSEPP payment cycle as described in
scheme in X9.59. Replay attacks are avoided by the X9.59 standard [5] is given in Figure 1. First we start
supplying a unique “nonce” called Locally Unique by explaining the payment infrastructure and trust
IDentifier (LUID). relationships among the consumer, merchant and FIs.
The X9.59 model tries to take full advantage of the Then the protocol is detailed.
current payment infrastructure and business model. It is
not restricted to a specific payment method and 2 AutReqObject

infrastructure. It defines secure payment objects that can Payment MFI

Merchant

be applied to any payment method. The credit/debit card, Infrastructure 4 AutAckObject

3 Interchange
1 SigPayObject
wire transfers and e-check methods are immediate CFI Protocol
5 SigPayAckObject
candidates that can be adopted into the X9.59 model with Ack code PRCC
PRCC Consumer PRCM
minor changes in the current infrastructure. PRCM
Amount authorized
Payment amount
LUID
Initial registration of both consumer and merchant to LUID
Other
Hash of order
Other
sign
their respective FIs is necessary. The public-private key Signature on
sign

pairs are created and the public keys are deposited in their SigPayAckObject Signature on
SigPayObject

FIs. Moreover, merchant and consumer learn the public

keys of their respective FIs. The registration process is
Figure 1. Payment cycle
outside of the scope of X9.59 standard.
The shopping experience until the payment step is not
a part of the X9.59 standard. In other words, it is assumed
that the consumer knows the PRC of the Merchant 3.1.1. Payment infrastructure and trust relationships
(PRCM) and the order details. Payment Infrastructure is the existing payment
The interchange protocol among the FIs is also out of network among financial institutions and the related
the scope of the X9.59 standard. This protocol might be payment mechanism it supports. Automated Clearing
updated in order to carry some addenda fields (e.g. the House (ACH) networks [8] are interconnected networks
signature of the consumer over the payment object). for electronic check clearing and direct fund transfers.
Authorization request and response messages are VisaNet and BankNet are two such infrastructures for
assumed to be a part of the existing infrastructure and credit card transactions operated by Visa [10] and
they are not defined by the X9.59 standard. MasterCard [11] respectively. The topology of these
networks is hierarchically interconnected local star
networks. There are local transaction hubs (transaction
3. CONSEPP: CONvenient and Secure centers) where local transactions are completed. National
Electronic Payment Protocol and international transactions pass through higher-level
hubs.
CONSEPP is based on X9.59 standard, but there are There are well-defined security policies and trust
some add-ons. CONSEPP is for Internet based payments relationships within the payment infrastructure. Each pair
and defines most of the features that are excluded in of entities communicating with each other also trust each
X9.59 because of its general-purpose characteristic. Thus other and have enough information and resources to
CONSEPP must be considered as an instantiation of the send/receive authenticated and secured information.
X9.59 standard. The basic CONSEPP payment cycle as Therefore, once a transaction has reached the MFI its
described by the X9.59 standard is given in Section 3.1. security and integrity are guaranteed within the financial
CONSEPP also defines the following features that are network. Security and authentication are provided via
excluded in the core X9.59 standard: leased lines and hardware devices based on public key
cryptography like the ones produced by Zaxus [12]. ISO
8583 standard defines the messaging among FIs and 3.1.2. Basic payment steps
transaction centers for credit card payments, but security Now let us briefly explain the steps of basic payment
and authentication are above this layer. “Interchange cycle as shown in Figure 1.
protocol” is the general name for messaging within a 1. SigPayObject: This object is the payment object
financial network and is not a part of CONSEPP. created and signed by the consumer to show its intent
CONSEPP assumes that consumer and merchant of payment. It contains
ultimately trust all FIs involved in the payment cycle. – consumer’s PRC (PRCC),
This trust is explicit between consumer and CFI, and – merchant’s PRC (PRCM),
between merchant and MFI as there are agreements – locally unique transaction identifier (LUID)
between them. Consumer-MFI and merchant-CFI trust – the hash of the order details,
relationships are implied by the protocol. Merchant trusts – payment amount and
CFI since the consumer’s signature is verified by CFI. – other payment, transaction and protocol details.
Consumer trusts MFI since it plays an important role in 2. AutReqObject: The merchant does not perform any
merchant authentication. The consumer-MFI and signature verification over SigPayObject. It forwards
merchant-CFI trust relationships are actually results of SigPayObject to MFI as the authorization request
transitive trust among the FIs. For example, consumer AutReqObject. AutReqObject is nothing but the
knows and trusts only CFI. CFI trusts MFI due the inter- SigPayObject packed in the format of a standard
FI trust relationships within the payment infrastructure. authorization request. The consumer signature on
Consequently consumer trusts MFI. SigPayObject is also packed in AutReqObject. This
In certificate based e-payment protocols CAs are the object is not part of the core X9.59 standard since it
trusted third parties. FIs replace CAs in CONSEPP. We is assumed that payment infrastructure already has
believe that trusting an FI is much better than trusting a such an interface. Section 3.4 gives more information
CA. Some justifications of this proposition follow. on AutReqObject.
– We already trust FIs since we deposit our funds there. 3. Interchange Protocol: The MFI transfers the fields
The level of trust that we assign to FIs in CONSEPP is of the SigPayObject and the consumer signature over
not more than controlling our savings. it to CFI together with other standard authorization
– FIs are already business partners of all merchants. details of the selected payment mechanism. CFI
CONSEPP just opens a new area of partnership. performs two operations: i) fund allocation for the
– FIs have a well-established legal base with transaction, ii) reconstruction of SigPayObject and
responsibilities and obligations spelled out by law. verification of the consumer signature over it. CFI
There is also a large body of precedent that enforces uses the public key of the consumer stored in the
FIs to behave properly. An FI would not want to account records for this verification. After that, CFI
destroy its reputation by behaving dishonestly. responds to MFI with positive or negative
– On the other hand, CA companies do not have a long acknowledgment. The communication between CFI
background. Their commercial durability as and MFI is a part of the interchange protocol and is
technological companies is in question in today’s outside the scope of X9.59 and CONSEPP.
market conditions. A business model relying on a CA 4. AutAckObject: MFI forwards the authorization
is prone to fail if that company cannot continue its response back to the merchant as Authorization
operations later. Changing a CA is not like changing a Acknowledgment AutAckObject. This object, as
server machine. All business models must change AutReqObject, is a part of the standard payment
tremendously when the CA company is changed. infrastructure interface and not described in the core
X9.59 standard. Section 3.4 gives more information
Now let us briefly analyze the trust relationship on this object.
between consumer and merchant. They need not know 5. SigPayAckObject: At the final step, the merchant
their public keys a priori. Therefore, they do not have any signs the authorization response using its private key
cryptographic trust relationships. The consumer must trust and sends it to consumer as Signed Payment
the merchant only commercially. By commercial trust it is Acknowledgment SigPayAckObject. This object
meant that the merchant is trusted to send the goods contains
ordered to the consumer in reasonable condition and time. – acknowledgment code (approved or rejected),
Such a trust also exists in mail-order and telephone-order – PRCC,
business models, so it is not a new concept for – PRCM,
CONSEPP. Unlike mail-order and telephone order, – LUID (the same one used in corresponding
merchant does not need to trust consumer in CONSEPP, SigPayObject),
because consumer authentication and payment – actual amount authorized,
authorization are taken care of by CFI. – other payment, transaction and protocol details.
 SigPayAckObject should also bear the certificate of merchant authentication. Moreover this authentication
the merchant signed by MFI in order to allow the does not create extra message rounds.
consumer to check the validity of the merchant’s
signature over SigPayAckObject. The standard X.509 3.3. Secure shopping experience in CONSEPP
[9] certificate lists are proposed for this purpose in
[5]. However, this proposal is vague and the details In CONSEPP shopping experience and initial data
are missing in [5]. Thus we propose a novel method exchange between merchant and consumer might be SSL
for merchant’s public key transfer from MFI to based. Two modes of SSL are proposed below.
consumer. This method will be described in Section
3.5. SSL using only merchant certificate: This mode of
SSL is the most widely used one in practice. Merchant
X9.59 standard also defines a signed object for the (server) uses his certificate, but the consumer (client)
consumer to acknowledge the receipt of goods or need not have a certificate. SSL is used for secure
services. Payment query request and acknowledgment are communication between them and for initial and
two other objects defined in X9.59 to allow the consumer conditional authentication of the merchant. Here SSL
to learn about the current status of a payment operation authentication is one-way, merchant to consumer. The
that it initiated. Another signed object is the request for merchant sends its PRCM and they negotiate on the
refund that is useful in case the consumer returns the payment details over a SSL protected channel. The
goods to the merchant. The details of these objects can be consumer finds out merchant’s URL and commercial
found in [5] and they can be used in CONSEPP. name from this session and believes in its authenticity
under SSL protocol rules. However, neither CFI nor MFI
3.2. Merchant authentication are responsible of this authentication since SSL
certificates are issued by independent certificate
In certificate based e-payment methods, merchant authorities like Verisign. The actual merchant
authentication is performed by using merchant certificates authentication takes place during the payment cycle as
at the beginning of the payment steps. This authentication explained in Section 3.2. The use of merchant SSL
is on the binding between the URL and the commercial certificate only helps the consumer to feel more secure
name of the merchant. CONSEPP does not use classical during the shopping experience.
merchant certificates. The verification of merchant’s
signature on the AutAckObject can provide authentication SSL in Anonymous Diffie-Hellman mode (no
of merchant’s URL, but this is done at the end of the certificate): The regular use of SSL explained above
payment cycle. If the merchant’s URL is not the correct requires a CA-signed merchant certificate. This certificate
one, then it is too late for the consumer to realize this fact. is unnecessary, because the actual merchant
Merchant authentication should be performed before the authentication is performed during the payment cycle.
payment authorization. Such an early merchant Anonymous Diffie-Hellman mode of SSL [4] can be used
authentication can be embedded in the payment cycle of instead. No certificates are needed in this mode. Merchant
CONSEPP as explained below. and consumer exchange their Diffie-Hellman public
First, consumer finds out merchant’s URL and parameters without any signature on them. This mode
commercial name during the shopping experience helps them to decide on a secret encryption key, but does
(Section 3.3). Consumer includes this information in not provide any authentication. This is not a very big
SigPayObject. Merchant forwards it to MFI in problem since actual authentication will be performed by
AutReqObject. MFI cross-checks merchant’s URL and MFI during payment authorization. Another known
commercial name that it received in AutReqObject with problem of this mode is being vulnerable to man-in-the-
the ones in its account records. If they match, then MFI middle attacks where the attacker plays the role of
proceeds the transaction. Otherwise, it rejects the merchant to consumer, and consumer to merchant.
transaction as fraud. The merchant cannot alter the URL Although such an attack is still possible in our scheme, it
and name information before sending to the MFI, because can eventually be detected since the attacker cannot
this causes the SigPayObject not to be verified at CFI’s continue its attack during the payment cycle. The security
site. of the CONSEPP payment cycle is based on the
We rely on the correctness of the MFI’s account signatures on the CONSEPP payment messages. Those
records for merchant authentication. This is a reasonable signatures are created using previously generated private
assumption since CONSEPP is based on “Account keys, so it is not possible for the attacker to obtain those
Authority” model. CFIs are in charge for customer keys during its man-in-the-middle attack. One may argue
signature verification; similarly MFIs are in charge for that an independent Diffie-Hellman protocol [13] could
be used here instead of embedding it into SSL. That
would help to save some overhead due to SSL headers. AADS idea. Here we propose an easy solution to the
Although this argument is correct, SSL is still preferred merchant certificate problem in CONSEPP.
since major browsers support it. Embedding an Our aim in CONSEPP is to avoid certificates that are
independent Diffie-Hellman protocol within the browsers pre-generated by CAs, since the idea behind X9.59 is not
would not be so easy. to have individual CAs. We assumed that each consumer
initially registers with a CFI. It is also assumed that they
3.4. Authorization request and response messages know the public keys of their CFIs.
(AutReqObject and AutAckObject) in CONSEPP First consumer includes a request for merchant’s
public key in SigPayObject. This request is transferred to
AutReqObject and AutAckObject are not defined in MFI in AutReqObject. The merchant’s public key is
X9.59 standard [5], but an annex of the standard explains stored at the MFI’s site. This public key is returned to
how to use ISO 8583 messages’ addenda records for these consumer using AutAckObject, SigPayAckObject and the
authorization messages in X9.59. As an X9.59 based financial network’s authorization messages. The protocol
protocol CONSEPP uses the same approach and it is is explained below and depicted in Figure 2.
briefly explained here.
Authorization request and response messages between Payment
Infrastructure 3. merchant’s PK
merchant and MFI are parts of the existing payment signed by CFI
Merchant
system. Credit card transactions use ISO 8583 standard as 1. merchant’s PK MFI
the messaging standard for authorization messages. In 4. merchant’s PK
signed by CFI
order to use those messages in CONSEPP and X9.59, CFI
2. merchant’s PK
some extra fields, like the consumer’s signature on signed by CFI
Consumer
SigPayObject, must be included in ISO 8583 1 and 2: Payment Infrastructure’s
authorization messages. ISO 8583 allows “addenda authorization messages 5. Consumer verifies
CFI’s signature on
3: AutAckObject
records” to add extra information to authorization 4: SigPayAckObject merchant’s PK

messages. The extra information that must be sent to MFI

via AutReqObject and the extra information that must be Figure 2. Merchant public key transfer
sent to merchant via AutAckObject can be embedded into
these addenda records. In this way the existing interface 1. MFI sends the merchant’s public key towards the CFI
between MFI and the merchant would not change in addenda records of “existing” financial network
significantly. authorization messages. Since the public key
The solution for ACH-based transactions is not so information travels along with the authorization
different. Addenda records are also possible in ACH request, no extra messaging rounds are necessary.
authorization messages. Therefore the extra CONSEPP 2. Upon receipt the merchant’s public key, CFI signs it
fields that are not part of the existing ACH authorization and returns the signed merchant’s public key to MFI
messages could be sent/received in addenda records as in along with authorization response in the financial
ISO 8583 messages. network.
AutReqObject can be signed by the merchant and 3. MFI forwards the CFI-signed merchant’s public key to
AutAckObject can be signed by the MFI. These signed merchant in AutAckObject.
objects can be verified by the recipient since both 4. Merchant forwards the signed public key to the
merchant and MFI know each other’s public key from the consumer in SigPayAckObject. Merchant cannot alter
registration phase. the public key information since it is signed by the
CFI.
3.5. Merchant certificate problem and its solution 5. Consumer verifies the signature over the merchant’s
public key using CFI’s public key and, then, use
Although the basic idea of X9.59 is to get rid of the merchant’s public key to verify its signature on
certificates and CAs, X.509 based merchant certificates SigPayAckObject (of course the merchant’s signature
are still referred to as merchant-to-consumer does not cover its public key information).
authentication method (SigPayAckObject in Figure 1) in
the X9.59 standard [5]. Moreover, the FIs are referred to The method proposed for public-key transfer above
as CAs. It seems that a CA-based PKI would be necessary does not require extra messages. Public key requests and
for merchant certificates, but the merchant certificate actual public keys are piggybacked to CONSEPP and
management is still obscure in [5]. We think that such a financial networks transaction messages. Public key
CA-based certificate mechanism does not conform to the information is transferred in “addenda records” of these
“convenience” characteristic of the X9.59 model and the existing messages.
 Financial networks like ACH, VisaNet and BankNet SigPayObject (Consumer à Merchant)
have their own security, authentication and integrity
Consumer PRC (PRCC)
mechanisms for existing payment authorization requests Merchant PRC (PRCM)
and responses among the FIs in the interchange protocol. Payment amount
Since the public key information is embedded in these LUID (unique transaction identifier)
Hash of order
authorization messages, authentication and integrity of the Merchant’s public key requested (YES/NO)
public key transmitted between CFI and MFI in this Other payment, transaction and protocol details
network are automatically provided. The merchant’s sign
public key is signed by CFI only for verification of this
public key by the consumer. Signature on SigPayObject issued by Consumer
There is no direct connection between CFI and MFI in
the financial network. There is at least one transaction
center to connect these two FIs. In some cases, there AutReqObject (Merchant à MFI)
might be several transaction centers between them. We Consumer PRC (PRCC)
assume that the public key information passes through Merchant PRC (PRCM)
these transaction centers along with other authorization Payment amount
LUID (unique transaction identifier)
information. Hash of order
Merchant’s public key requested (YES/NO)
3.6. Object contents Signature on SigPayObject that had been issued by Consumer
Other payment, transaction, protocol and authorization details

The CONSEPP extensions proposed in Sections 3.2 sign

through 3.5 change the object contents of the basic
Signature on AutReqObject issued by Merchant
payment cycle described in Section 3.1. The object
contents after those extensions are depicted in Figure 3.
Those extensions change only the content and processing
of the objects; the flow remains unchanged. AutAckObject (MFI à Merchant)
AutReqObject and AutAckObject fields are packed into
Acknowledgment code (Accept / Reject)
standard authorization messages as explained in Section Consumer PRC (PRCC)
3.4. Merchant PRC (PRCM)
Actual amount authorized
LUID (the one used in SigPayObject)
4. Advantages of CONSEPP Other payment, transaction, protocol and authorization details
sign
Consumers generally worry about the theft of their
card or account numbers and refrain from using this Signature on AutAckObject issued by MFI
sensitive information for electronic payments. Although it
is possible to send the classical card or account numbers Merchant’s public key
over an encrypted line, the merchant may not be able to CFI’s signature on merchant’s public key
hide this private information properly. CONSEPP
eliminates the possibility of improper usage of the card
and account numbers, because they are not used in SigPayAckObject (Merchant à Consumer
CONSEPP transactions. CONSEPP uses specific PRCs
instead of account and card numbers. PRCs cannot be Acknowledgment code (Accept / Reject)
Consumer PRC (PRCC)
used for some other purpose. A CONSEPP transaction Merchant PRC (PRCM)
that holds the PRC of a consumer must be digitally signed Actual amount authorized
by the same consumer. Therefore, theft of PRC does not LUID (the one used in SigPayObject)
Other payment, transaction, protocol and authorization details
cause any problem.
There are three advantages of not having consumer sign
certificates in CONSEPP:
Signature on SigPayAckObject issued by merchant
1. There is no need for a CA-based PKI. Implementation
of such a PKI would bring some extra cost to FIs and
Merchant’s public key
some inconveniences to consumers and merchants.
CFI’s signature on merchant’s public key

Figure 3. Object contents

2. A certificate revocation mechanism must be The model that is proposed for merchant public key
implemented for CA-based PKIs in order to check the transfer in Section 3.5 eliminates the need for merchant
validity of unexpired certificates. Verifiers must certificates. This feature uses the existing authorization
contact an online validation server or periodically message rounds and does not put a significant cost on the
download validity lists for revocation control. FIs, merchant and consumer.
However, in CONSEPP, there is no such Elimination of both consumer and merchant
inconvenience for certificate revocation. If the certificates makes CONSEPP totally certificate/CA-free.
consumer’s public key must be revoked or changed, This is a very important advantage of CONSEPP, since
the account records that are held at the CFI’s site can having no CA-based PKI results in fast, cheap and simple
be updated. The verifiers should not take any action for transactions.
revocation control. Cryptographic burden on consumer is minimal in
3. Certificate-based systems are often criticized since CONSEPP. Excluding the shopping experience, consumer
they carry some private information via certificates. In should generate only one (for SigPayObject) and verify
CONSEPP, no private information, such as the name, two digital signatures (one is to learn the merchant’s
birth date, account number are revealed to a third party public key, the other is to verify SigPayAckObject) for
(i.e. merchant), since there are no classical certificates. payment processing. Most of the advantages described
This protects the consumer’s privacy. above also have efficiency improvement aspects. For
examples:
CONSEPP offers strong protection against consumer – Consumer should not spend time to verify a chain of
transaction repudiation. This is a very important problem certificates to find out merchant’s public key; only one
in payment systems that use conventional cards. signature verification is sufficient for this.
Merchants are responsible for verifying the consumer’s – Since no CA-based PKI exists in CONSEPP, there is
authenticity in these systems. If the merchant does not no need to spend time for certificate revocation control.
receive a strong evidence, such as a signature, from the – Having no encryption in the payment part of
consumer, then the consumer can deny initiating the CONSEPP is another speed-up factor.
transaction and the merchant faces a charge-back. On the Secure shopping experience method described in
contrary, in CONSEPP, the merchants are not responsible Section 3.3 requires some encryption. However
for authenticating the consumers; CFIs authenticate the encryption is a standard approach for all e-payment
consumers by verifying the consumer signature on protocols that require confidentiality during shopping
SigPayObject. This signature is created by consumer experience; CONSEPP does not create an extra burden
using his/her public key 1, which is supposed to be known that does not exist in its rivals. Moreover, an encrypted
only by the consumer. Since the CFI keeps the shopping experience is not a prerequisite for the rest
consumer’s correct public key in its records, this (actual payment part) of the protocol. Consumers may
verification serves as strong evidence for the initiation of prefer not to have an encrypted shopping experience due
the transaction by the claimed consumer. The consumer to performance concerns.
can still dispute it by claiming that his/her private key or
the password that is used to unlock the private key is 5. Discussion
stolen, but this is an issue between the consumer and its
CFI. Merchant is not responsible for the outcomes of such Both merchant and consumer should register with
a consumer dispute, so its charge-back cost is reduced to their FIs before taking place in CONSEPP. This
zero. registration should be offline, because he/she must sign a
The above advantages result from the characteristics contract and prove his/her identity. On the other hand, if
of X9.59 standard. The special CONSEPP extensions an FI already knows its customer, it may establish an
over X9.59 that have been explained in Sections 3.2 online agreement page and get the customer’s approval by
through 3.5 provide extra flexibility. The proposed secure clicking on a “I accept” button at the end of the “terms
shopping experience method makes use of common SSL and conditions”. However, it would be difficult for the FI
technology, but bypasses its trusted certificate to prove the existence of such an agreement if its
requirements. This method allows merchant customer denies it.
authentication to be done by MFI with no significant extra Initial merchant/consumer key generation and
cost. distribution can be performed in two different ways.

1 1. Key pairs may be created by the FIs.

Since a private key is a long and hard-to-remember string, in practice it
Consumers/merchants get their private keys within
is cryptograhically locked using a password, and the key holder uses
this password to unlock it when he/she wants to issue a digital
smart cards issued by their FIs. They may also obtain
signature.
 soft versions of their private keys in order to use it in a Acknowledgments
computer without a smart card reader.
2. Consumer/merchant may run a program to create a set This work is supported by rTrust Technologies. The
of keys and send (or take) the public key to FI. Private authors are grateful to Behzad Sadeghi, Anne and Lynn
key may be kept by the owner and be used in software. Wheeler and anonymous referees for their valuable
comments.
The first method is more convenient, but the
possibility of FI’s access to the private key during its
References
generation may raise some security concerns. The FIs
must act honestly and carefully here.
[1] CyberCash Inc., http://www.cybercash.com/
Since the CFI acts as a trusted authority to resolve
possible disputes raised by the consumer, the consumer [2] P. Wayner, Digital Cash: Commerce on the Net, 2nd
must assign the CFI as a proxy for dispute resolution a Edition, Morgan Kaufmann Publishers, March 1997.
priori. This fact may be included in the contract between
the consumer and CFI. Moreover, the local laws must [3] MasterCard Inc., SET Secure Electronic Transaction
endorse such a role to CFI. Specification, Book 1: Business Description, MasterCard Inc.,
CFI or its agent should always be online in order to May 1997.
provide proper service. This is not only for CFI’s
signature verification responsibility, but also for fund [4] A. O. Freier, P. Karlton, and P. C. Kocher, The SSL Protocol
authorization. Indeed such a requirement is not new for Version 3, Netscape Communications Corp., 1996, available
payment mechanisms. Traditional authorization from http://home.netscape.com/eng/ssl3
responsibility compels the financial institutions to be
online all the time. Therefore, signature verification does [5] American National Standard DSTU X9.59, Electronic
not cause an extra burden of being online. Commerce for Financial Services Industry: Account Based
Secure Payment Objects, 2000.

6. Conclusions [6] A. Wheeler, and L. Wheeler, Payment, Security & Internet

References, http://www.garlic.com/~lynn/
We proposed a new Internet e-payment system, called
CONSEPP (CONvenient and Secure E-Payment Protocol) [7] ISO 8583, Financial Transaction Card Originated Messages
based on ANSI X9.59 standard [5]. Our aim was to – Interchange Message Specifications, 1993
balance the security and convenience features. CONSEPP
minimally changes the existing payment infrastructure [8] NACHA - The Electronic Payments Association,
and business models, thus it is convenient. Moreover, http://www.nacha.org
CONSEPP has enough authentication, integrity and
confidentiality features to support security. [9] ITU-T Recommendation X.509, ISO/IEC 9594-8,
CONSEPP inherits the basic idea of X9.59, which is Information Technology - Open Systems Interconnection - The
Directory: Public-key and Attribute Certificate Frameworks,
to use the Consumer’s Financial Institution (CFI), instead
2000 (fourth) edition.
of the merchant, to verify the consumer’s signature over
the payment request. The ultimate aim is to get rid of the [10] Visa International, http://www.visa.com
need for consumer certificate. However, X9.59 still needs
merchant certificates. In CONSEPP we proposed a [11] Mastercard International, http://www.mastercard.com
dynamic and convenient method to transfer merchant’s
current public key to the consumer using existing [12] Zaxus Limited, http://www.zaxus.com
authorization messages and payment infrastructure. This
does away with the need for merchant certificates. In this [13] W. Diffie, and M. E. Hellman, New directions in
way CONSEPP becomes a CA/certificate-free protocol. cryptography. IEEE Transactions on Information Theory,
This results in faster and less costly payment transactions. 22:644-654, November 1976.
X9.59 standard does not rule out encryption, but does
not include it in the standard. CONSEPP does not include
encryption for the payment messages either. In case of a
need for optional encryption and anonymous data transfer
between consumer and merchant, a third party
anonymizer/privacy wrapper or an extension of SSL
protocol could be used.