Issues in Securing Electronic Commerce over the Internet
Vijay Varadharajan & Yi Mu
Distributed System and Network Security Research Unit
University of Western Sydney
PO Box 10, Kingswood, NSW 2747, Australia
Email:
vijay@st.nepean.uws.edu.au,
yimu@st.nepean.uws.edu.au
Abstract
The explosive growth of the Internet, coupled with its potential use as
the core of the National and Global Information Infrastructure, is creating a
huge field of business opportunities. At the heart of all the
current debate on how to - and whether you even should - do business
on the Web, lies the issue of security. Security and, in
particular, secure electronic payment is a key enabling technology for
the provision of such commercial services over a wide area network.
In this paper, we first consider the characteristics of a secure electronic
commerce framework and reveal the design choices involved in the development
of secure electronic payment schemes. The paper then
analyses an electronic payment scheme and discusses
some of the design choices that have been made.
1 Introduction
The explosive growth of the Internet, coupled with its potential use as
the core of the National and Global Information Infrastructure, is creating a
huge field of business opportunities. These opportunities include a
wide range of online services from home shopping, networked village to
unforeseen network-based ventures. Activities can include
researching a topic, accessing library books electronically from home,
providing education electronically, viewing movies, news on-demand,
purchasing items from electronic catalogues, or more generally,
conducting business transactions electronically.
At the heart of all the
current debate on how to - and whether you even should - do business
on the Web lies the issue of security. In
particular, secure electronic payment is a key enabling technology for
the provision of such commercial services over a wide area network.
Of course, this is just the first step in the spectrum of collaborative
activities that can be envisaged over the network.
In the future, one can imagine hundreds of speciality firms
meeting, negotiating and making contracts with each other over the network.
2 Secure Electronic Commerce Framework
Many of today's electronic commerce initiatives vary in their
approach to security and privacy, their ability to handle micropayments, and their applicability to various types of transactions. They also differ in their business models - for example, in their pricing strategy and in their assumptions
as to who bears the risk in case of insufficient funds or disputes. Such a
diversity promotes innovation and allows for providers' and users' choices.
Furthermore, many present electronic commerce implementations automate only
a portion of the entire transaction process. For example, although ordering
and distribution of an information-based service is automated, the supporting
accounting and inventory information and payment and funds transfer are
often decoupled. Ideally, an electronic commerce system should integrate the
various stages of ordering, distribution, payment and
enable real-time links to accounting systems with minimal transactional costs.
Recently, there has been an explosion of interest in the area of electronic
commerce and payment schemes over Internet. In particular, several protocols
dealing with payment for Internet transactions have been proposed, while
several others are in development. It is clear that if the Internet were to
become an open marketplace for goods and services, the need for secure
charging and payment is essential. In the non-electronic world, payments
are made in a variety of ways; namely,
using cash, cheques, credit cards, debit cards and prepaid tokens.
Each of these mechanisms have different types of attributes that
make them suitable for
different types of electronic commerce transactions.
Similarly, in a network
environment, it should be possible for payments to be made using any or all of the above methods.
Needless to say, security aspects become critical to the successful
operation of any of these electronic payment schemes.
Broadly speaking, there are two classes of electronic payment schemes
that have been proposed so far. Schemes
such as DigiCash (Chaum et al. 1988,
Chaum 1992),
and NetCash (Medvinsky & Neuman 1993) try to emulate 'cash'-like properties for electronic payment. Others such as
iKP,
NetBill (Sirbu and Tigar 1995),
NetCheque (Neuman & Medvinsky 1995), CyberCash,
STT, SEPP,
and SET consider credit
and debit-based electronic payments. In addition, several other protocols
have also been proposed to deal with micropayments over the Internet;
for instance, MicroMint and
PayWord (Rivest & Shamir 1996), and
Millicent. All of these protocols have their own
virtues and they all help to increase the understanding of the area.
The key to guiding the design and development of such secure electronic
commerce systems is an overall security architectural framework. The
framework should provide a way of mapping security
requirements to security services and how the security services can be
provided to meet customers' security needs. It also
gives a means of describing components or the building blocks that
are required in the design of specific secure systems.
In designing a secure electronic commerce framework, we need to consider
the following issues: the structure of electronic money tokens, the
characteristics of the services that can be provided, the different
charging and payment models that can be used and the types of disputes
that can arise and that need to be resolved within the model. These aspects
lead to the identification of design choices in the development of
secure electronic payment services and protocols, and the components that are required
to support them. Let us now consider each of these issues in turn.
2.1 Electronic Money Tokens
In defining electronic money, we need to consider the properties that
we wish the electronic money to have. For instance, there are some fundamental
differences between cash and cheque. Cash is anonymous and if lost or stolen
is difficult (or impossible) to trace, whereas an ordinary cheque
has some form of identity and there exists mechanisms for recovery when lost
or stolen. Let us consider some of the basic design choices we have in the
defintion of the electronic money token.
- Value: Electronic money tokens must have some form of monetary value;
for instance, they may represent cash or bank-authorised credits or cheques.
One has the option of assigning some upper-limit on the allowable value that
could be assigned to a single electronic money token.
- Transferrability: The property here is whether a user be able to
transfer or exchange electronic money tokens without the intervention of
a bank or a financial broker; that is, can a user exchange the electronic
money tokens that s/he received for further transactions without first
depositing them into some financial institution?
- Divisibility: Should an electronic money token be divisible, thereby
enabling splitting of the token into arbitrary or predefined pieces; this
allows each piece to be spent individually. For
instance, if some service costs 9 dollars and 50 cents and if the user
pays the service provider 10 dollars, then the provider should be able to
return 50 cents to the user.
- Loss Recovery: If the electronic money token is lost or stolen, should
it be treated like a cheque or cash?
- Forgery: Throughout the life cycle of electronic money tokens,
it should not be possible to tamper, copy or forge them. Mechanisms must
be provided to detect and prevent double spending of electronic money tokens.
The international nature of electronic transactions makes the counterfeiting
problem and its detection particularly difficult.
- Validity: Some form of legal stamping of the electronic money token
to guarantee its validity is important. With this process, one needs to
ensure that only the authorised banking authorities be able to create
valid electronic money tokens. This may also include the assignment
of unique identifiers (for example, serial numbers) to electronic money tokens and
the provision of valid signatures, whereby only
the legal banking authority can sign the token, whereas anyone (including
users across international boundaries) should be able to verify the
validity and the legality of the electronic token.
- Ownership: The property of ownership is concerned with the ability
to uniquely identify the owner of an electronic money token. In non-electronic
cash-based systems, this is not the case, and there is anonymity, whereas
cheque or credit based schemes have some form of identity. The advantage
of having an ownership is that lost or stolen electronic money tokens will
be worthless to anyone but the owner. However, this introduces traceability of
transactions and does not provide anonymity.
- Anonymity: There are a range of options associated with anonymity.
Many users may wish their transactions to be completely anonymous with the
identity of either the buyer or the provider unknown. However, when a
court order is issued, it may be required to present both the identities
of the users concerned and the transaction details.
- Time Period: This property is concerned with whether an electronic token should have a time period associated
with it, beyond which the token expires. This means that the user will have
to redeem or exchange the token prior to the expiration time. This requires
additional facilities with respect to synchronisation of time across the
network to some degree of precision.
- Storage and Transfer: Electronic money tokens should be able to be
stored and transferred. The tokens can be stored in some form of smart cards
or in computer's memory. It is important to ensure that the tokens cannot be
copied or modified in storage or during transfer.
2.2 Services
There are different types of services that may be provided over the
network, and consequently the charging and payment schemes that need
to be devised may also vary. In general, some services may be public
(that is, anyone can read and access them at no cost), some services
may be private (that is,
provided to users at a price), and some may be private and
confidential (that is, provided at a cost to some subset of users).
Some services are provided over a period of time whereas other
services can be treated as discrete events. For instance,
a video movie service is provided over a period of time, whereas
a service such as the purchase of a book is a collection of
of one or more discrete events. The charging mechanisms for a continuous
service may be different compared to a discrete service. For instance,
consider the situation whereby the use,r after watching 20 minutes
of a 3 hour video, decides to abandon it. In this case, from the user
point of view, s/he may wish to pay only for the service that has been
used.
Some services can be reviewed on-line, paid on-line and delivered
on-line. For instance, an information service such as electronic
journal publications fits into this category. There are other
services for which the delivery cannot be on-line, but a 'real-world' event should occur subsequently; for instance, ordering a pizza.
Some on-line services are likely to be of low cost, not exceeding a few
dollars. An example could be access pages in a document. The user may be
asked to pay a few cents per page that s/he wishes to read. For services
of this type, it is important that the transactions are processed quickly
and costs kept to a minimum. The requirements on such micropayment
schemes are somewhat different compared to those for services of
high value.
In practice, services with all and various combinations of these
characteristics may occur in electronic commerce.
2.3 Secure Payment Models
In understanding the design of secure payment models, we first need
to identify the relevant security information that is required
in the process. In general, there are two types of security
information. The first type is some form of authentication information.
This is concerned with the issue of - Will the user pay for the
transaction?. For instance, the service provider can use this
information to identify the transaction and the purchaser in the case of
non-payment following delivery. The financial
institution may use this information to update the user's account after
the completion of the transaction. The second type of information is the
creditworthiness information. This is concerned with the issue - Can the
user pay? For instance, the service provider may wish to obtain a
guarantee from a third party (for example, a financial institution) regarding the
creditworthiness of the requesting user prior to delivering the service.
When it comes to using this information in the design of secure
electronic payment schemes, the following issues need to be addressed.
- Who provides what security information?; that is, who provides
Authentication Information and Creditworthiness Information?
Management of these information involves some trusted authorities,
namely Authentication or Certification Authority
and Credit or Banking Authority.
- When is the security information provided and to whom? Here, there
are a number of issues to consider. At one end of the spectrum, the user may
collect the relevant security information from the authorities and push
them to the service provider, whereas at the other end, the service provider
may pull the security information from the appropriate authorities. The
overall design principle is that if the security information is generic and
static in nature, then it can be pushed, whereas any dynamic and specific
information needs to be pulled by the service provider at the time
of decision-making. For instance, the authentication information which
is static can be pushed by the user to the provider, whereas the
creditworthiness information, which is dynamic, needs to be pulled to make
sure that the user has enough credit to make this specific purchase.
The policy and its enforcement may differ depending on the
value of the transactions. For instance, for high value transactions,
the service provider may wish to check the creditworthiness of the user
at the time of the transaction, whereas for small value services, the provider
may decide that this is not necessary.
- Who verifies what security information? This identifies what decisions
can be made and by whom. For instance, the service provider may have the
capability to verify the authentication information presented to it by
the user. The provider may then contact the Credit or Banking Authority
to verify the creditworthiness information of the user.
- Where is the security information stored and updated, and by whom?
For instance, the creditworthiness information is stored at the server in the
bank, whereas the authentication information may be stored at the server in the
user's organisation.
The specific choices that are made for the above issues lead to the
design of various secure electronic payment protocols. The framework
should support a range of payment schemes including pre-payment (for example,
pre-paid tokens), post-payment (for example, credit cards) and payment at the time
of transactions (for example, electronic cash). Depending on the type of
payment scheme chosen, there are different requirements on the accounts
that need to be maintained. For instance, the accounts can be held with
a trusted third party such as a bank or at the service providers.
Furthermore, the accounts may be for groups of users such as organisations
or individual users. This has implications upon who is responsible for
conducting transactions. There may also be a need to issue electronic
receipts for the transactions made. Once again, the issues to consider
here are when are the receipts generated, who generates them and how
are they distributed.
2.4 Disputes
In any real-life situation, disputes can arise, and hence we need
mechanisms to arbitrate and resolve them. It is important to be
able to characterise the types of disputes that may arise and that
need to be resolved within the model. Here are some of the
disputes that can arise in an electronic commerce
situation.
The user may order a service and then claim that s/he did not
do so. The user may claim that s/he did not receive the service, even though
it has been delivered. Consequently, s/he may refuse to pay for the service.
If the user pays before the delivery of the service, then the user may
refuse to deliver the service on the basis that s/he did not receive
the payment (even though s/he actually did). There could also be disputes
in the content of the service provided. The user may claim that s/he was
sent a wrong service that was not requested, although the correct service
was delivered.
The characterisation of disputes will in turn give rise
to the types of information that need to be generated and
maintained for resolving disputes. It will also identify who should be
involved in the generation and the maintenance of this information.
For instance, we may need to be able to
prove the occurrence of a transaction and its properties such as when it
occurred, its value, the type of transaction, and the parties involved.
We will also require mechanisms to generate electronic proof of receipt of
services and payment.
2.5 Security Components
From the above discussion, we can identify at least the
following basic security components:
- Service Users : Clients
- Charging and Payment Software Component and Protocols
- Fetching Authentication Ticket
- Fetching Electronic Money Token
- Security Mechanisms Libraries : Signature, Hash Function, Encryption.
- Service Providers : Servers
- Charging and Payment Software Component and Protocols
- Authentication Ticket Verification
- Electronic Money Token Verification
- Audit Logging
- Security Mechanisms Libraries : Signature, Hash Function, Encryption.
- Broker Server: dealing with Creditworthiness Information
- Charging and Payment Software Component and Protocols
- Authentication Ticket Verification
- Electronic Money Token Generation and Verification
- Audit Logging
- Security Mechanisms Libraries : Signature, Hash Function, Encryption.
- Accounts Information Repository
- Authentication Server: dealing with Authentication Information
- Authentication Ticket Generation and Verification
- Authentication Information Repository
- Security Mechanisms Libraries : Signature, Hash Function, Encryption.
3 An Electronic Credit-Based Payment Scheme
In the light of the above, let us now consider an electronic credit-based
payment scheme and consider some of the design choices that have been
made.
In general, an on-line credit card payment system involves at least the
following parties: Clients (Service Users) requesting services from
Merchants (Service Providers)
who provide the services, and Financial Institutions providing
guarantee and transfer of cash and credits between Clients and
Merchants. We will use the iKP family of protocols in our
discussion below, though our discussion is equally applicable
to other protocols such as the STT, SEPP and SET.
The system consists of Client, Merchant and the Financial Institution.
In our discussion, we use the terms
similar to iKP. The Merchant presents the information about the service
in terms of an Offer (or some sales information). When the Client wishes to
make a purchase, s/he sends an Order and a payment Slip to the Merchant. The
Order is intended for the Merchant whereas the Slip is passed on to the
Financial Institution. The Merchant requests the authorisation from the
Financial Institution, and upon receipt of the authorisation (referred
to as Authz), the Merchant confirms to the Client the conclusion of the
payment transactions. This is then followed by the service delivery. All the
systems mentioned above rely on the use of public key technology and
certificates.
3.1 Notation
The basic quantities used in the message flows are as follows:
- Merchant's offer:
Offer = {offer description,
price, items, expiration time, identity of merchant}
- Client's order:
Order = {order description, amount, currency, timestamp,
identity of merchant, identity of client, delivery address }
- The client's payment slip:
Slip = {credit card number, expiration date, amount, currency,
timestamp, PIN, identity of merchant, h(Order)}
- The authorisation from the financial server:
Authz = {`approve'/`reject', identity of financial server,
(amount, currency, timestamp), identity of merchant, h(Order)}
- Public key certificate for user X:
Cert_X = {identity of X, X's public key, timestamp,
validity of public key, issuing authority} signed by the
issuing authority.
We also use the following notation in the protocol description:
- C: Client
- M: Merchant
- TA: Trusted Certification Authority.
- T_X: Timestamp generated by X.
- SK_X: Private Key of user X.
- PK_X: Public Key of user X (associated with SK_X).
- < ... >_{PK_X}: Public Key Encryption using PK_X.
- < ... >_{SK_X}: Public Key based Signature using SK_X.
- TransNo: Transaction Number.
- A --> B : message : denotes that a
message is sent from party A to party B.
3.2 A la 3KP Protocol
Let us now consider a protocol a la 3KP, and look at what each of the parties have in terms of security information. We will consider the case where all the three parties have public key and private key pairs. This case corresponds to the 3KP protocol.
- Financial Institution (F): F,SK_F, PK_F, Cert_F, K_{TA}, PIN.
F has its public key - private key pair, (PK_F, SK_F).
This enables F to sign its messages. F has the certificate Cert_F
validating PK_F, which has been issued by the trusted authority TA.
We will assume the existence of such an authority.
- Merchant (M): M, SK_M, PK_M, Cert_M, Cert_F, PK_{TA}.
M has its own public key - private key pair (PK_M, SK_M);
hence M can sign its messages. M also has F's certificate Cert_F
and his own certificate Cert_M. Once again, M's certificate is signed
by the trusted authority TA. Note: If the trusted authorities are
different, then we assume the existence and access to cross-certificates
enabling one party to verify another party's certificate.
- Client (C): C, SK_C, PK_C, Cert_C, PIN, PK_{TA}.
C has a public key - private key pair (PK_C, SK_C), its
certificate Cert_C, and a PIN.
To illustrate some of the issues in the design of
of payment schemes, we use as an example the 3KP protocol given
below.
- 1: M --> C : Cert_M, Cert_F, Offer
- 2: C --> M : Cert_C, Order,
<< Slip >_{PK_F}, h(Order)>_{SK_C}
- 3: M --> F : Cert_M, Cert_C, <<<Slip >_{PK_F}, h(Order)>_{SK_C}>_{SK_M}
- 4: F --> M : <Authz, <Slip>_{PK_F}>_{SK_F}
- 5: M --> C : <Authz, <Slip>_{PK_F}>_{SK_F},
<<<Slip>_{PK_F}, h(Order)>_{SK_C}>_{SK_M}.
- 6: M --> C : {Service}
3.3 Transaction Goals
In general, some or all of the following goals need to be satisfied by the
run of a payment protocol.
- F's Point of View
- F believes (Service Transaction requested by C)
When F authorizes the debiting of C's account, it must believe that C has
requested the particular transaction.
- F believes (Service Transaction can be provided by M).
When F authorizes the payment to M, F believes that
M has the capability to provide and will provide the services to C.
- M's Point of View
- M believes (Service Transaction authorized by F)
- M believes (Service Transaction requested by C)
- M believes (Payment made by C)
- M believes (Service provided to C)
- C's Point of View
- C believes (Service Transaction authorized by F).
- C believes (Payment made to M). That is, C believes that C's account has been or
will be debited and M account has been or will be credited.
- C believes (Service provided by M).
3.4 Discussion
Firstly, note that in the protocol discussed above, the encrypted version of Slip
has been signed by the Client. A general principle to follow in the design of
cryptographic protocols is to avoid signing encrypted content. This is because
signing of an encrypted message does not necessarily
imply that the plain message has been seen the by the person who signed it.
Now consider the problem of replay of message in Step 2.
Note that the Merchant cannot read the contents of Slip
but can check the contents of the Order. In principle,
message replay can be detected by checking the timestamp that appears
within the order. However, from the Merchant's point of view,
s/he may feel that it is perfectly legitimate for a Client
to make multiple purchases within a time window for
the same service as long as the Client pays.
As the Merchant sees only the encrypted
Slip, s/he will pass on the Order and the encrypted Slip
(the replayed message) to F. The burden is therefore on F
to determine that the message 2 in Step 2 (or
the message 3 in Step 3) is a replayed message.
Though it is quite correct for F to thoroughly validate
the integrity and uniqueness of message at Step 3 before it
takes the authorization decision, the above argument shows
the ample opportunity that exists for replays to occur;
hence the need for efficient mechanisms at F to deal
with these situations thereby not degrading the system performance.
In the class of payment protocols such as the one analysed above,
the Client sends both the Order and the payment instruction
Slip together (compare with Step 2). The assumption is that
when the Financial Institution receives the Slip via
the Merchant in Step 3, it will carry out procedures to debit the
Client's account and credit the Merchant's account.
This may be done during the protocol run or may be done
at a later point in time in an off-line manner.
But the crucial point is that the decision to debit and
credit appropriate accounts has been taken
and committed after Step 3. This aspect introduces several issues.
Firstly, at this point in time, the decision to credit Merchant's
account and debit Client's account has been committed
even though neither has the Client received the service
and nor has the service been provided by the Merchant.
Subsequently, the Merchant may deny that s/he has received
the authorisation from F as s/he knows that the account has
or will be credited. The denial by the Merchant can be genuine
if there has been a communication error in Step 4, or
it may be malicious if s/he has received the Step 4 message.
After a certain wait period for receiving Step 5 message
from the Merchant, the Client may decide to contact
the Merchant again. If the Merchant is in fact malicious, or
if the communication links between the Merchant and the Client
are loss prone, then the Client has to get in contact with
F with a reliable evidence that it did not receive the requested
Service. If the Client decides to purchase the same Service
from another Merchant, this poses a problem because the decision
to debit Client's account has already been committed.
Hence, there is a need for the Client to go through another process
for obtaining refunds which in general, increases the transaction costs.
We will refer to this characteristic in payment protocols design as merchant
trusted since it relies on the honesty of the merchant.
Not only do the trust assumptions need to be made explicit but also suitable mechanisms should exist to deal with situations when such disputes arise. The protocols proposed so far have tended to ignore these aspects.
Any scheme that requires the use of public
key technology creates the need for secure
storage of private keys associated with the public key system.
The scheme such as the one above requires storage of
private keys for all the three parties.
The storage of Client's private key raises additional issues.
The Client's secret key can be stored in a tamper-proof
device such as a smartcard or may be stored within the
Client's machine protected using access control mechanisms.
Here it is important to consider the assumptions
that one can make about the operating environment. If one considers a
simple environment where we have PCs connected to the Internet, neither
of the above solutions may be practical. The use of smartcard
requires some form of a smartcard reader attached to the PCs.
One cannot assume that all the PCs connected to the Internet
have or will have smartcard readers attached to them.
Use of access control mechanisms to protect the private key
stored in the PC is in general not very secure. One can encrypt the
private key using some other symmetric key which the user can
remember. Note that the assumption here, is that it is far more difficult
to remember a 512-bit private key of an RSA system compared to remembering
a 8-10 character symmetric key. However, the problem here is that
this places constraints on the mobility of the user;
that is, it ties the user to a particular machine
where the private key of the user is stored.
4 Concluding Remarks
In this paper, we have first outlined the choices involved in the design of
secure electronic payment protocols. The paper then analysed an
an electronic payment scheme and discussed some of the design choices
made. We have proposed an improved new scheme which
overcomes some of the issues raised above. The new
scheme separates the purchase request
and payment instruction, thereby reducing the dispute problems discussed above.
It removes the need to store the secret key (of the public key system)
at the Client's machine or the need for a smartcard reader. Finally, the
scheme introduces an identity which is used only in carrying out electronic
commerce transactions, based on the principle of separation of tasks.
This mechanism gives the user an additional handle in choosing whether
or not to use his or her credit card for electronic payment transactions
over the Internet.
Bibliography
- 1
- Chaum, D., Fiat, A. & NaorReichelt, M. (1988) Untraceable electronic cash
in Advances in Cryptology - CRYPTO '88 Proceedings, Springer, Berlin, pp. 319-327.
- 2
- Chaum, D. (1992) Achieving electronic privacy, Scientific American, August, pp. 96-101.
- 3
- Medvinsky, G. & Neuman, B. C. (1993) Netcash: A design for practical electronic currency on the internet in Proceedings of the ACM Conference
on Computer and Communication Security.
- 4
- IBM (1995) Secure Electronic Commerce, iKP - a family of secure electronic payment
protocols, IBM.
URL: http://www.zurich.ibm.com/Technology/Security/extern/ecommerce/
- 5
- Sirbu, M. & Tygar, J. D. (1995) Netbill: An internet commerce system
optimized for network delivered services, Carnegie Mellon University.
URL: http://www.ini.cmu.edu/netbill/
- 6
- Neuman, B. C. & Medvinsky, G. (1995) Requirements for network payment:
The netcheque(TM)$ perspective in Proceedings of the IEEE CompCon'95.
- 7
- CyberCash (1995) The cybercash(TM) system - how it works.
URL:
http://www.cybercash.com/
- 8
- STT (1995) Secure transaction technology.
URL: http://www.visa.com/Visa-stt/Stt-os.html
- 9
- SEPP (1995) Secure electronic payment protocol, Mastercard Inc.
URL: http://www.mastercard.com/Sepp/
- 10
- Rivest, R. L. & Shamir, A. (1996) PayWord and MicroMint: Two simple micropayment schemes.
URL: http://theory.lcs.mit.edu/~rivest/
- 11
- DIGITAL (1996) The Millicent protocol for inexpensive electronic commerce.
URL: http://www.research.digital.com/SRC/millicent/
- 12
- Schneier, B. (1995) Applied Cryptography, John Wiley and Sons, New York.
- 13
- Varadharajan, V. & Mu, Y. (1996) On the Design of Secure Electronic Payment Protocols
for the Internet in Proceedings of
the IEEE Annual Computer Security Applications Conference, USA.
- 14
- SET, VISA & MasterCard (1996) Secure electronic transactions.
URL: http://www.mastercard.com/SET/
Return to Conference Proceedings