an investigation into electronic commerce frauds and their
TRANSCRIPT
An Investigation into Electronic Commerce Frauds and their Security
Implications
Thesis
Submitted in partial fulfilment of the
requirements for the Degree of
Bachelor of Science (Honours)
in Computer Science and Information Systems
at Rhodes Univers ity.
by
Kevin Boardman
Department of Computer Science
7 November 2004
1
Abstract
Electronic commerce has the potential to offer many benefits both to the consumer
and to the business, but the recent rapid rise in online fraud causes concerns over the
security of e-commerce transactions. This paper identifies a number of common
options for securing the e-commerce transaction and critically analyses these
mechanisms. A number of weaknesses in one of the most readily implemented
solutions to e-commerce security (SSL) are identified and it is found that payments
protocols, if widely adopted, would offer the best solution to securing the e-commerce
transaction.
2
Acknowledgements
To my project supervisor, John Ebden, for all his guidance, patience and support.
To everyone at the Rhodes University Computer Science and Information Systems
Department.
To Telkom SA, Business Connexion, Comverse SA, and Verso Technologies for the
financial and technical support of this project through the Telkom Centre of
Excellence at Rhodes University.
To my parents for all their support.
To all my friends for all the good times.
Thank you
3
Table of Contents
Chapter 1 - Introduction .............................................................................................8
1.1 Motivation............................................................................................................8
1.2 Research Goals.....................................................................................................8
1.3 Document overview .............................................................................................8
Chapter 2 - E-commerce Background .....................................................................10
2.1 Importance of e-commerce ................................................................................10
2.2 Types of E-commerce ........................................................................................11
2.3 Fraud in E-commerce.........................................................................................12
Chapter 3 - Design Considerations ...........................................................................14
3.1 Scope..................................................................................................................14
3.2 Merchant perspective .........................................................................................15
3.3 Limitations .........................................................................................................15
3.4 Approach............................................................................................................16
Chapter 4 - Taxonomy of Threats to E-commerce .................................................17
4.1 Types of threats ..................................................................................................17
4.2 Types of attacks .................................................................................................19
4.3 Methods of attack...............................................................................................19
4.4 Opportunities for attack in the e-commerce transaction....................................21
Chapter 5 - Securing the E-commerce Transaction ...............................................23
5.1 Data Transport Security requirements ...............................................................24
5.2 E-Commerce Security Mechanisms...................................................................25
5.2.1 User IDs and passwords, tokens and biometrics.........................................26
5.2.2 Public Key Infrastructure (PKI), Digital Certificates and Digital signatures
..............................................................................................................................27
5.2.3 Secure channels and the Secure Socket layer (SSL)...................................31
5.2.4 Secure Payments and SET ..........................................................................33
5.2.5 Pseudo Card Numbers.................................................................................35
4
Chapter 6 - Critical Analysis of the E-commerce transaction security
mechanisms .................................................................................................................40
6.1 User IDs and passwords, tokens and biometrics................................................42
6.2 Tokens ................................................................................................................43
6.3 Biometrics ..........................................................................................................44
6.4 Public Key Infrastructure (PKI), Digital Certificates and Digital signatures ....44
6.5 The Secure Socket Layer (SSL).........................................................................45
6.5.1 Problems with SSL .....................................................................................45
6.5.1.1 The insecure merchant and Illegitimate merchant problem.................45
6.6 Secure Payments and SET .................................................................................48
6.6.1 Advantages of SET .....................................................................................48
6.6.2 Disadvantages of SET.................................................................................49
6.7 Pseudo Credit Card numbers .............................................................................50
6.7.1 Advantages..................................................................................................50
6.7.2 Disadvantages .............................................................................................51
6.8 Summary............................................................................................................51
Chapter 7 - Case Study ..............................................................................................52
7.1 CD Universe.......................................................................................................52
7.2 MSNBC discovers flaw .....................................................................................53
Chapter 8 - Options and Recommendations ...........................................................54
8.1 Option 1..............................................................................................................55
8.2 Option 2..............................................................................................................55
8.3 Option 3..............................................................................................................56
8.4 Option 4..............................................................................................................56
8.5 Option 5..............................................................................................................57
8.6 Option 6..............................................................................................................57
8.7 Option 7..............................................................................................................57
8.8 Option 8..............................................................................................................58
8.9 Options 9, 10 and 11 ..........................................................................................58
8.10 Option 12..........................................................................................................59
8.11 Conclusion .......................................................................................................59
5
Chapter 9 - Conclusion..............................................................................................61
9.1 Research contributions .......................................................................................61
9.2 Application.........................................................................................................61
9.3 Future Work .......................................................................................................62
6
List of Figures
Figure 1: The increase in internet related frauds reported to Consumer Sentinel from
2001 to 2003.................................................................................................................12
Figure 2: An example of a visual representation of a digital certificate issued by the
Thawte Certificate Authority to Kalahari.net ..............................................................30
Figure 3: Steps involved in the pseudocard transaction based on those identified by
Clark [2001] .................................................................................................................38
Figure 4: The insecure merchant problem...................................................................46
Figure 5: The illegitimate merchant problem ..............................................................47
Figure 6: The use of payments protocols in order to prevent the illegitimate merchant
and insecure merchant problems..................................................................................48
7
List of Tables
Table 1: Comparison of the advantages and disadvantages of mechanisms used to
secure the e-commerce transaction..............................................................................40
Table 2: Options for securing e-commerce..................................................................54
8
Chapter 1
Introduction
This chapter introduces the project, discusses the need for it, identifies the research
goals and gives a brief overview of the paper.
1.1 Motivation
Recently there have been a number of cases of fraud involved in e-commerce. This
raises the question of whether the security measures involved in securing the e-
commerce transaction are adequate. If they are not adequate, the question of whether
there are other measures available that may improve this security and prevent these
frauds is raised. Because of the number of recent frauds and the questions raised by
them, this project was conceived.
1.2 Research Goals
This paper has two major aims:
1. To evaluate current implantations of e-commerce security in order to discover
potential strengths and weaknesses
2. To identify solutions to these weaknesses.
1.3 Document overview
Chapter 2 discusses the background of e-commerce in order to ascertain the degree of
e-commerce frauds currently being perpetrated and its effects on the adoption of e-
commerce. Chapter 3 identifies the design considerations that needed to be taken into
account when writing this paper and introduces the formulated approach. Chapter 4
then discusses the types of threats, attacks, methods of attack and opportunities for
attack in the e-commerce transaction. Chapter 5 identifies the requirements of a
secure transaction and the mechanisms available to fulfil those requirements. In
9
chapter 6 a critical analysis of the mechanisms identified in chapter 4 is conducted. A
case study is then discussed in chapter 7 and chapter 8 identifies a number of options
and recommendations for securing the e-commerce transaction.
10
Chapter 2
E-Commerce background
Ghosh [1998] describes electronic commerce as a new way of interacting, bartering
and transacting with people and businesses. Hutchinson and Warren [2003] state that
e-commerce focuses on the electronic exchange of information using information and
telecommunications infrastructures to perform a wide range of commercial activities
that can be divided into business-to-consumer and business-to-business sectors. Some
of these commercial activities include online auctions and internet banking. E-
commerce can therefore be seen as a new way of trading of goods and services over
an electronic infrastructure such as the internet.
2.1 Importance of e-commerce
According to Verisign [2004] electronic commerce is a “strategic imperative for most
competitive organisations today as it is a key to finding new sources of revenue,
expanding into new markets, reducing costs, and creating breakaway business
strategies”. It can therefore be seen that e-commerce has the potential to offer many
rewards to businesses that involve themselves in this new form of business. E-
commerce also offers benefits to the consumer. These benefits may include savings in
time, convenient access to a broad variety of shops and merchandise, and instant
ability to compare price and quality of products [Ahuja, 1997]. Electronic commerce
has the potential to offer many benefits both to the consumer and to the business but
because of concerns over the security of e-commerce transactions many consumers
and businesses are still wary of it. According to Ghosh [1998] the first concern for
both business and consumer of entering the e-commerce market is the potential for
loss of assets and privacy due to breaches in the commercial transactions and
corporate computer systems. However, this is not to say that e-commerce potential is
being totally ignored by consumers, in fact Burrows [2004] states that according to
internet analyst World Wide Worx, the number of online banking accounts in South
Africa grew by 28% to 1.04 million in 2003, and that these figures are expected to
11
increase by 30% in 2004. Electronic banking in America is also on the increase as
according to the Gartner Group [2003] 17 percent of Americans used online banking
services by the end of 2002 and this figure will continue to grow by 14 percent up to
the end of 2007. These figures show that despite some security concerns electronic
commerce related activities such as e-banking continue to grow.
2.2 Types of E-commerce
There are many types of e-commerce, that can be categorised into groups depending
on the involved parties and types of transaction. The Queensland government’s
department of state development and innovation [2001] identify the following types
of e-commerce:
• Business to Business (B2B) – Interaction between two businesses in order to
support one business trading with another. According to the Queensland
governments department of state development and innovation [2001] B2B e-
commerce made up 94% of all e-commerce transactions.
• Business to Consumer (B2C) – Direct interaction by the consumer with the
supplier’s system through the clients own computers. In this case the web is
usually used as a medium to order goods.
• Consumer to Business (C2B) – In this case the consumer requests a specific
service from a consumer to business e-commerce site. A specific business will
then access the web site and reply to services that they are able to fulfil.
• Business to Employee (B2E) – This type of e-commerce facilitates the
interaction between the company and its employees. This is usually done
through private networks such as intranets and extranets.
• Consumer to Consumer (C2C) – In this case a central consumer to consumer
e-commerce site allows one consumer to list a product or service and another
consumer to purchase that product or service through the specific site. Online
12
auction sites are a prime example of this type of e-commerce, where an e-
commerce site facilitates the interaction between two consumers.
This paper concentrates on the Business to Consumer type of e-commerce
transactions that are conducted over the internet in which payment is performed by
credit card, but in many cases can be generalised to suit any type of e-commerce
mentioned above.
2.3 Fraud in E-commerce
Some security concerns in e-commerce may be well founded when some of the
statistics relating to electronic commerce security are considered. Fraud is increasing
at a rapid rate. Figure 1 represents the increase in internet related frauds based on
information published by Consumer Sentinel [2004] from 2001 to 2003.
Internet Related Frauds reported to Consumer Sentinal from 2001 to 2003
020,00040,00060,00080,000
100,000120,000140,000160,000180,000
2001 2002 2003
Number of reportedfrauds
Figure 1: The increase in internet related frauds reported to Consumer Sentinel from
2001 to 2003
According to the Journal of Computer Security and Fraud [2003] the cost of fraud in
2002 more than doubled that in 2001. The above information indicates that there is a
gradual increase in internet related frauds and therefore questions the security of many
commercial activities that occur over the internet.
13
E-commerce is a new way of performing business transactions that can be beneficial
to both consumer and business. Unfortunately statistics show that although there is a
general increase in the use of e-commerce applications, such as electronic banking,
many of the commercial activities are still insecure.
14
Chapter 3
Design Considerations
When analysing security within e-commerce a number of design cons iderations need
to be identified. Design considerations include the scope and limitations of the project
which lead to the type of approach taken in order to investigate the problem identified
by this project.
3.1 Scope
The area of e-commerce security is extremely broad and all areas of e-commerce and
its security cannot be dealt with in this paper. A number of types of e-commerce have
been identified in the background (Business to Business, Consumer to Business,
Consumer to Consumer and Business to Consumer). While all of these types of e-
commerce should be kept in mind when considering e-commerce security, as much of
what is mentioned in this report can be generalised to all types of e-commerce, this
paper will concentrate on Business to Consumer e-commerce. This was decided on as
security breaches in this area occur relatively often and receive a great deal of
publicity. After narrowing the type of e-commerce for this project down to Business-
to-Consumer a number of types of payment can be identified, these include stored
value payments such as E-Bucks and standard credit card payments. It was decided
that credit card payments should be an area of focus in this paper, as a number of
credit card thefts and fraud keep taking place.
Security itself is a broad category and the scope of this paper needs to be refined in
this regard. This paper will therefore not be concerned with general security factors
such as firewalls and will only focus on e-commerce specific mechanisms for
securing the credit card transaction.
15
3.2 Merchant perspective
Another important design consideration when analysing e-commerce security, is
deciding from which perspective to consider e-commerce security. Two different
perspectives can be identified: Client and Merchant. The client’s perspective on
security involves the client wanting to purchase goods online knowing that his details
are kept confidential and that no illegitimate charge will be charged to his/her credit
card. The client may also be concerned with ease of use of the system and factors
such as this could affect his adoption of the security mechanism.
The merchant on the other hand is concerned with security firstly. This is because of
the loss in credibility the merchant suffers if there is a breach, and because customers
are obviously more comfortable buying from a site that is recognized as being secure.
The merchant is also concerned with the ease of implementation and maintenance of
the e-commerce system as well as consumer adoptability and cost. Because of these
factors a merchant should also be concerned with the client perspective mentioned
above. This paper will therefore take the perspective of a new or existing merchant
looking to implement a secure e-commerce system.
3.3 Limitations
A number of limitations have been considered when writing this paper. The main
limitation is the difficulty in gaining real information from e-commerce security
breaches in the form of case studies. This is due to the secretive nature of many of
these breaches. Companies obviously do not like to publicly declare details on
systems breaches because of the effect it might have on their reputation and for fear of
further attacks. Detailed technical information on real world e-commerce frauds is
therefore difficult to find and has had a limiting effect on this project. This limitation
means that this project was only able to consider one case study which was based on
investigative journalism rather than formal technical reports.
16
3.4 Approach
After considering the factors mentioned above, an approach for the paper can be
generated. Firstly it was decided that in order to understand e-commerce frauds, the
threats to e-commerce need to be identified, therefore a taxonomy of threats should be
created. After the threats are identified, the requirements of a secure e-commerce
transaction as well as the mechanisms used to secure e-commerce need to be
identified. A critical analysis of the mechanisms will then be conducted in order to
discuss the advantages and disadvantages of each technique. It was then decided that
in order to identify real world problems, a case study of a breach in e-commerce
security should be discussed. Once the case study has been discussed a number of
options for securing e-commerce are identified and recommendations are made.
17
Chapter 4
Taxonomy of Threats to E-commerce
In order to successfully analyse the security of e-commerce the threats to electronic
commerce security must be examined. A threat can be defined as “the potential to
exploit a weakness that may result in unauthorised access, disclosure of information
or consumption, theft or destruction of a resource” [Ahuja, 1997]. These threats
emerge as the infrastructure that supports e-commerce can be susceptible to abuse,
misuse and failure causing financial loss due to fraud and lost business opportunities
due to loss of service [Verisign, 2004]. Ford [1998] argues that these weaknesses in
the infrastructure emerge as the internet was never designed with security in mind and
is therefore an “open network”. This openness of the network combined with an
absence of a prior real world relationship creates problems of confidentiality,
identification and trust.
4.1 Types of threats
Computer security experts consulted in Freedman [2000] stated that hacking into a
bank’s system was possible but usually only if information from the “inside” was
provided. This introduces two types of threats, identified by Ghosh [1998] as internal
and external threats. Internal threats are perpetrated by individuals who have
authorised access to at least some of the organisation’s internal systems while external
threats are perpetrated by those who do not have this access. Ghosh [1998] states that
internal threats are the threats that are most likely to be overlooked yet the most likely
to occur. Internal threats include:
1. Current employees: Anyone with knowledge of the workings of the company
e-commerce system has a significant advantage over external attackers and
may use this inside information to compromise the system. This may be
motivated by curiosity, financial gain or dissatisfaction at the company.
18
Systems administrators have significant power and expertise in order to
perpetrate internal attacks.
2. Disgruntled ex-employees: Employees that have had technical experience
within the company and have been fired are potentially very dangerous as they
have the motivation and expertise to perpetrate attacks.
This paper however, will concentrate on external threats faced by e-commerce.
External threats include:
1. Script Kiddies: These types of attackers are usually not very skilled and use
scripts or programs created by others to compromise systems. Script kiddies are
usually vandals defacing web sites or performing denial of service attacks for
example, rather than intentionally stealing money directly through credit card
transactions.
2. Cracker: These attackers are usually very technically astute and have the ability
to understand systems and write programs in order to exploit them. Some
crackers penetrate systems in order to test their technical ability and skills and
may therefore focus on “breaking” the system instead of trying to gain financial
advantage. These individuals may however seek recognition for their
achievements by publishing their exploits of systems on the internet; these
published exploits may then be used for ill purpose by script kiddies or by
criminals or fraudsters.
3. Criminals and fraudsters: Attackers of this nature range from individuals wanting
to avoid small payments to organised criminals looking to steal large amounts of
money. Their sole intention however is financial gain which could be perpetrated
through credit card fraud or extortion for example.
19
4.2 Types of attacks
In order to protect against e-commerce fraud not only the types of attackers must be
identified but types of attacks that can be perpetrate and protected against must be
considered as well. Types of attacks include:
1. Vandalism and Sabotage: involves intentionally defacing of digital property
for example adding graffiti to a web site. The illicit modification of e-goods
and denial of service would also fall under this category.
2. Breach of privacy/confidentiality: involves secret data such as a clients
personal details being disclosed to unauthorised parties. A compromise of a
client’s credit card number would be another example which could result in
either unauthorised funds or political embarrassment.
3. Theft and Fraud: involves an attacker gaining unauthorised access to a system
to steal resources by impersonating an authorised user in the case of fraud.
4. Breach of Data Integrity: involves the altering of data by an unauthorised
entity even though the information itself might not have been disclosed. An
example of this would be the spoofing of a packet’s source IP address.
5. Repudiation: involves a party falsely denying a transaction occurred such as a
merchant denying an order was placed after the fact.
Many of these types of exploits may be used to perpetrate theft and fraud and
therefore this paper concentrates on exploitations of theft and fraud.
4.3 Methods of attack
In order to perpetrate the above mentioned exploits specific methods of attacks may
be employed by the attacker. Some of these exploits include:
20
1. Denial of service attacks: involves an attack on a network or a service which
floods the network with traffic so that the network is slowed or interrupted. An
example would be the continuous request for information from a web server by an
attacker resulting in the server being unable to cope with these requests, crashing
or not being able perform its function.
2. Spoofing (web, e-mail or IP): involves the forging of a piece of information so
that someone authenticating the information believes you are someone you are
not. A simple example is a web page that has the official logo and a similar
address of the spoofed company displayed but however is run by a fraud thereby
assuming the companies identity for personal gain. More complex spoofing, of IP
addresses and authentication information for example can be achieved by
transmission interception and replay attacks. These attacks involve recording and
altering of confidential transactions such as authentication packets and
“replaying” these packets so that the intended recipient believes you are someone
you are not.
3. Man in the middle attacks: These attacks involve the interception of information
while in transit between the sender and receiver. This information can then either
be read and/or altered and then forwarded to the intended receiver to achieve
fraudulent activity for example.
4. Buffer overflows: allow attackers to execute their own code through a flaw in
legitimate software that results from the user being able to overwrite the space
allocated for a specific input. A fraudster could use a buffer overflow flaw in an e-
commerce system to execute a program that steals credit cards for example.
5. Backdoors: A program that allows security measures to be circumvented, allowing
easy access to unauthorised persons.
6. Spyware: A program that monitors a user’s actions without the user’s knowledge.
An example would be a key stroke logging application that records a user’s
password and then forwards it to a fraudster.
21
4.4 Opportunities for attack in the e-commerce transaction
There are certain procedures and processes in an e-commerce transaction and
payment process that provide opportunities for attack. The following opportunities for
attack are loosely based on guidelines identified by The Australian Government’s
Department of defence [1999].
1. Opportunities for attackers to obtain goods or services without making payment.
a) A merchant selling electronic goods or services can be vulnerable to
unauthorised access to the merchant server on which these goods are stored.
b) If an attacker can compromise the payment server the attacker can falsely
advise the merchant that a payment has been made.
2. Opportunity for attackers to compromise client’s details.
a) Client’s payment details (e.g. credit card numbers) that are stored on merchant
systems are vulnerable to attack from an attacker who can access this system.
b) Client’s payment details could be intercepted while in transit between the
client, merchant or payment provider.
3. Opportunities for attackers to modify merchant’s online goods and services.
a) Compromise of the merchant server on which these goods and services are
stored could result in the unauthorised modification of these assets.
4. Opportunities for other types of attacks.
a) Potential for an attacker to generate false refunds if he/she is able to access the
payment system.
b) The potential for an attacker having gained access to the payment system to
redirect funds to his/her account.
Claessens et al [2002] point out that one of the biggest threats to security is not a
technical threat but the threat of “the human factor” which can be caused by human
error or carelessness such as the sharing of a password. According to Claessens et al
22
[2002] these human factor risks can be prevented by education and the enforcement of
policies. It is thus important to note that although the focus of this paper is the
technical risk to e-commerce, risks such as the human factor should be considered
when securing an e-commerce system.
Threats in e-commerce emerge from the fact the internet was not created with
commercial transactions security in mind. The underlying infrastructure on which
these transactions are based is therefore insecure. External threats to secure
transactions such as fraud and breach of confidentiality and opportunities for attackers
to compromise client details will be specifically addressed. Next the methods of
preventing these threats will be considered.
23
Chapter 5
Securing the E-Commerce Transaction
Now that the threats to e-commerce security have been identified some common
safeguards can be identified and discussed. Ghosh [1998] identifies four fronts on
which the e-commerce system must be secured: web client security, operating system
security, web server security and transport security. Hutchinson and Warren [2003]
identifies three similar areas of security within an electronic commerce banking
environment, these include the bank (merchant), the internet and the client. For the
purpose of this study three main areas of concern will be considered: merchant
security, transport security and client security, where merchant security includes the
merchant’s and bank’s web server and operating systems.
Merchant security involves the security of the systems of the provider of the service
for example an online book store. This includes the merchant’s web server security
and the merchant’s operating system’s security upon which the web server security is
based. Most sources cited the merchant side as being vulnerable as information is
stored unencrypted by merchants after transmission. Techniques to secure the
merchant side of transactions rely heavily on the use of firewalls to prevent the
operating system from being exploited by hackers [Ghosh, 1998]. According to
Hutchinson and Warren [2003] the responsibility of the merchant side of security, the
bank in an electronic banking environment, is to validate customers by authentication,
to authorise and honour transactions and to ensure non-repudiation.
Client side security is generally agreed to be the most difficult area to enforce. This is
due to the fact that it is up to the user to make sure security procedures and protocols
are in place. Most users however do not understand computer security and therefore
client machines are usually left unprotected. Ghosh [1998] identifies two main risks
on the client side as being vulnerabilities in the browser software and risk associated
with active content on the web.
24
Secure transport involves the securing of information when it is in transit between the
client and the merchant. The following section deals with the requirements of
securing the e-commerce transaction at the transport stage.
5.1 Data Transport Security requirements
Claessens et al [2002], Hutchinson and Warren [2003], Radha [2004], Sahut and
Galuszewska [2004] and Versign [2004] all agree on four basic security requirements
of e-commerce transactions: authentication, confidentiality, data integrity and non-
repudiation.
Authentication can be defined as “the ability to uniquely identify a person or entity
and to prove such identity” [Hutchinson and Warren, 2003]. An example of this
would be a merchant verifying that it is the company it professes to be through the
presentation of a digital certificate. Entity authentication in the context of e-commerce
is the process in which a consumer verifies that a merchant’s presented identity
corresponds with their real identity. This is an extremely important requirement in
securing e-commerce transactions and according to most literature reviewed is the
cornerstone of electronic commerce security. The Federal Financial Institut ions
Examination Council [2001] states that reliable customer authentication is imperative
for financial institutions involved in any form of electronic commerce as effective
authentication systems can help prevent fraud. The council argues that the risks of
conducting business with incorrectly authenticated individuals could cause
irreversible damage to a company through financial loss and reputation damage due to
fraud, corrupted data or disclosure of confidential information. It is thus of paramount
importance that secure authentication techniques are set up when performing business
transactions over an open electronic network such as the Internet.
Confidentiality makes sure that only authorized users have access to the content of the
exchanged information [Claessens at al, 2002]. It also can be described as the ability
to prevent unauthorised parties from understanding transmitted data [Hutchinson and
Warren, 2003]. Confidentiality can therefore be seen as the process of keeping data
secret when it is transmitted over an open network. This can be achieved by
cryptographic techniques and infrastructures such as the Public Key Infrastructure
25
(PKI) which will be discussed in more detail a little later. The importance of
confidentiality in an e-commerce context can be seen when a consumer sends a
merchant payment details. The consumer would obviously not like these details,
which may include credit card numbers for example, to be intercepted and used by a
third unauthorised party and therefore confidentiality is required.
Data integrity is another security factor required when dealing with e-commerce
transactions. Sahut and Galuszewska [2004] indicate that for a transaction to be
secure data cannot be intentionally or unintentionally changed during the session.
According to Hutchinson and Warren [2003] data integrity is the ability to assure that
data has not been modified accidentally or by any unauthorised entity. Data integrity
is important in electronic commerce as it prevents unauthorised users from changing
critical data such as credit card numbers while in transit. Techniques used to ensure
data integrity include the use of digital signature which will be discussed further on in
this paper.
Non-repudiation can be defined as “the ability to prevent a denial of actions by a
person or entity” [Hutchinson and Warren, 2003]. This means that a recipient of a
message should be in a position to prove that he (the recipient) received a message
that could only have originated from the sender [Radha, 2004]. In an e-commerce
context a person placing an order can therefore not refute that fact that he and no one
else could have placed the order.
5.2 E-Commerce Security Mechanisms
In order to enforce the requirement mentioned above, mechanisms need to be put in
place. These mechanisms vary in effectiveness of enforcing the above requirement
and each has advantages, disadvantages and different applications within varied
environments. Some mechanisms are best suited to creating secure channels and
others to securing payments or simply enforcing authentication. These mechanisms
include: user IDs and passwords, Public key infrastructure and Digital certificates,
Digital Signatures, Secure Socket layer (SSL), and SET (Secure Electronic
transactions).
26
5.2.1 User IDs and passwords, tokens and biometrics
User IDs and passwords, tokens and biometrics are fundamentally concerned with
authentication of an individual. According to The Federal Financial Institutions
Examination Council [2001] authentication methodologies involve three factors:
something a user knows (a password or pass phrase), something the user possesses (a
token) or something the user is (a biometric characteristic, such as a fingerprint).
The user ID/password technique provides for authorisation by verifying the user ID
against the password provided. This technique relies on the fact that the password is
kept secret. User IDs in combination with passwords are considered a single factor
authentication technique which has gained popularity because of its ease of use and its
adaptability [The Federal Financial Institutions Examination Council, 2001]. The
popularity of this mechanism can be seen in its wide spread adoption in operating
systems login authentication. Both Ford [1998] and Verisign [2004] agree that
although passwords and user IDs (usernames) have become the most widely used
authentication technique, it is unfortunately one of the least secure methods of
authentication available.
Authentication involving “something that a user owns” involves the use of tokens.
These tokens can come in the form of devices that interact directly with the computer
e.g. : smartcards or devices that don’t interact with the computer at all e.g. Digitags
that generate one time passwords. Tokens can be used in isolation or in combination
with passwords, PKI, SSL and payment protocols. Due to these vulnerabilities and
threats, passwords are often combined with physical tokens to create multi- factor
authentication in order to improve the reliability of the authentication [Ford, 1998].
According to The Federal Financial Institutions Examination Council [2001]
multifactor authentication methods are more reliable indicators of authentication and
are therefore stronger fraud deterrents. Thus passwords can be used in combination
with tokens such a smartcards which provide a higher level of authentication security.
Because the authentication process cannot be completed without the device being
present, or in some cases the device itself being locally authenticated, the transmission
of shared secrets over an open network such as the internet can be avoided [The
Federal Financial Institutions Examination Council, 2001]. Tokens that generate one
27
time passwords provide protection against guessing of passwords, while tokens that
store private keys prevent unauthorised parties accessing the user’s computer and
copying the keys for their own use.
The authentication process can be greatly improved through the use of tokens in
combinations with passwords to create a multifactor authentication process but
authentication also relies on the correct implementation of policies, procedure and
controls.
Biometric techniques such as retinal scanning, fingerprint analysis and handwriting or
voice recognition it is generally agreed is one of the securest methods of
authentication. Despite this Ford [1998] points out that these techniques are very
expensive to implement correctly and are therefore usually only considered for high
security applications with a big budget.
6.7.1 Public Key Infrastructure (PKI), Digital Certificates and Digital signatures
The user ID/password, token and biometric techniques for securing e-commerce all
concentrated only on authentication that required the password or key to be kept
secret. The following section deals with techniques used to fulfil the other
requirements of e-commerce transactions security such as data integrity, non-
repudiation and confidentiality. Confidentiality in electronic transactions relies
heavily on encryption techniques but an in depth discussion of encryption is beyond
the scope of this paper. Therefore a technique for providing confidentiality, data
integrity, non-repudiation and authentication, the public key infrastructure (PKI), will
be examined briefly.
According to Verisign [2004] one of the most popular methods of protecting
information is through the use of a virtual key system, in which information is
encoded according to an encryption algorithm so that it can only be decrypted by a
user who holds the correct key. In a private key system one key that has the ability to
encrypt and decrypt a message is shared between users needing to communicate. The
sharing of this secret key therefore makes this system vulnerable when keys are
transmitted over an open network such as the internet. Public Key Infrastructure (PKI)
28
uses public key cryptography which is asymmetric. This means that two separate but
related keys are involved: a public key which is shared with entities with which a user
wishes to communicate and a private key which is not shared and kept secret [Radha,
2004]. “The public key and private key perform inverse operations” Verisign [2004]
and therefore when the one is used to encrypt a message the other is used to decrypt it.
Therefore when a sender “A” wishes to communicate with a receiver “B”, “A” will
encrypt a message with “B’s” public key. “B” on receiving this encrypted message
will decrypt it with his private key. This method ensures that only the holder of “B’s”
private key will be able to decrypt the message. According to Radha [2004] the
advantage of using PKI over private keys is that key management becomes much
easier, for example if A needs to communicate with 10 people he does not have to
share 10 different secret keys but only has to share his public key in each case.
However this method is somewhat inefficient in speed and involves the trusted third
party, a Certification Authority (CA) [Radha, 2004].
The method described above deals with confidentiality of a transaction but does not
ensure data integrity, authentication and non-repudiation. Radha [2004] indicates that
hashing, which generates a unique hash code called a message digest for any message,
is used to ensure the integrity of a messages. This hashing technique will ensure that a
change in the message when transmitted will cause a change in the message digest
which is generated from the received message at the receiving end. Therefore at the
receiving end the newly generated message digest is compared against the original
message digest which is sent by the receiver along with the message. If both message
digests compute to be the same then the message has not been altered.
In order to provide authentication and non-repudiation this hashing function is
combined with public key cryptography to form a digital signature. According to
Radha [2004] digital signatures verify that the sender is in possession of a unique
private key and that the message has not been altered in transit. The process of
sending messages and receiving messages that provide authentication, confidentiality,
non-repudiation and data integrity using the techniques described above is outlined by
Radha [2004] in the algorithm below:
29
For sender A to send a message to B, he
1. Encrypts the message with B’s Public Key
2. Computes the hash of the message
3. Encrypts this hash with his own private key (Digital signature)
4. Sends the encrypted message, his public key and the digital signature to B
At the receiving end, B
1. Decrypts the digital signature with the Public Key of B and receives the hash
sent by A
2. Decrypts the message with his own Private Key
3. Computes the hash of this message
4. Compares the hash sent by A and the one he computed
5. If they match, the message has met all security criteria including integrity, if
not the message should be discarded
It must be remembered that it is usually the software that performs these action in the
background without the client being aware.
The techniques above all have the potential to make the transactions in e-commerce
more secure, however a problem still exists: an owner of a public key could claim to
be someone he is not. The sender must therefore be capable of assuring the receiver
that a given public key is indeed from the sender [Ahuja, 1997]. This assurance is
created by the use of digital certificates which are data structures that associate public
keys with specific people [Radha, 2004]. An example of a visual representation of a
digital certificate can be seen in Figure 2. According to Ford [1998] the function of
distributing digital certificates, thereby attesting to the relationship between the public
key and a specific person, is performed by certification authority (CA). In Figure 2 the
certificate authority attesting to the relationship between the certificate and
Kalahari.net is the Thawte Certificate Authority.
30
Figure 2: An example of a visual representation of a digital certificate issued by the
Thawte Certificate Authority to Kalahari.net
Radha [2004] states that the association between public key and subject is achieved
by having a trusted CA verify the subject's identity and digitally sign each public key
along with other user credentials. So instead of a public key being distributed, one has
to distribute his digital certificate to the public. Certification authorities eliminate the
problems of physical separation associated with digital signatures, and introduce the
problem of accepting a third party as suitably trustworthy [Ford 1998]. Radha [2004]
explains that this problem may allow fraudsters to set up their own certificate
authority and issue themselves with digital certificates which they can force the
browser to trust. A suggestion is made that to secure the PKI further, control of which
certificates should be trusted should be given to a local authority instead of trust being
preinstalled in the browser.
31
According to Radha [2004] PKI can be used to secure transactions between a client
and a merchant server so that no-one can sniff information passing along the wire.
This can be achieved by using protocols such the Secure Socket Layer (SSL) which
will be discussed later in this paper. PKI can also be used to authenticate software by
distributing software that is signed by the publisher. This helps to prevent fraud as
much fraud is committed through the distribution of malicious software.
PKI is relatively secure infrastructure which has many benefits but is usually not used
in isolation for e-commerce. The Federal Financial Institutions Examination Council
[2001] states that PKI decreases many of the vulnerabilities related to passwords as it
does not rely on shared secrets and its electronic credentials are difficult to
compromise. Disadvantages of the infrastructure include the reasonably high cost to
implement and the high complexity of implementation and management of PKI.
5.2.3 Secure channels and the Secure Socket layer (SSL)
Secure channels which ensure confidentiality, authentication, and data integrity
should be established between the client and the merchant before any e-commerce
transactions take place. The Secure Socket Layer (SSL) is a method of providing a
secure channel between clients and merchants. In fact according to Ghosh [1998] SSL
is the “de facto” protocol for securing communication channels in e-commerce
although it does not provide mechanism for handling payment. SSL is a protocol that
is positioned above the transport layer and below the application layer in the protocol
stack. It can therefore conceptually provide secure services to many different
applications at the application layer such as telnet and ftp [Ahuja, 1997] but its main
application is securing channels through the web. SSL provides security through some
of the methods mentioned in the public key infrastructure: confidentiality is provided
by end to end encryption, while authentication and data integrity is provided through
digital certificates, digital signatures and hashing.
The process of setting up a secure connection through SSL relies on public key
encryption to authenticate the merchant server and to set up a private session key
shared between the client and merchant web server. After setting up a secure
32
connection, symmetric encryption can be used for secure communications; this is
preferable as it is more efficient than asymmetric encryption [Ghosh, 1998].
Below is listed the algorithm involved in initialising, communicating in and ending a
SSL session between a client and a server based on Gosh [1998].
1. Client Hello: Contains a suite of secure protocols that the client browser
supports and a random challenge string generated by the browser. The
challenge string is unique to the session and will be used at the end of the
initialisation process to make sure the secure channel has been established.
The suite of secure protocols consists of key exchange algorithms for
agreeing to a private session key, private key encryption protocols for
transaction confidentiality, and hashing algorithms for data integrity.
2. Server Hello : Contains the servers X.509 i standard certificate, an
acknowledgement that the server can support the protocols requested by
the client and a random connection identifier used, as with the random
challenge string, at the close to determine if the protocol has been set up.
3. The server’s certificate will then be authenticated by the client’s web
browser. The client will then generate a master secret to be shared between
the client and server. This master secret serves as a seed to generate a
number of keys used for both symmetric encryption and data integrity.
This master secret is encrypted with the server’s public key and sent to the
server.
After this public key encryption is no longer necessary for this session and
private key algorithms such as RC2 (40 Bit encryption) and RC4 (128 Bit
encryption) can be used to secure subsequent messages. From the master
secret both server and client will generate 2 identical symmetric key pairs.
One key pair is used to encrypt outgoing messages from the client and
i X.509 is a standard for PKI that specifies standard formats for digital certificates.
33
decrypt incoming messages to the server. In other words the clients
outgoing write key is the same as the servers incoming read key.
4. Client finish: Client encrypts the server’s random connection ID with
client write key. The server will know the connection is set up if this
decrypts to the same as the original connection ID
5. Server Finish: Server encrypts the clients challenge string with the servers
write key. The client then decrypts this with the clients read key and
compared it to the original challenge string. Now both client and server
know the connection has been set up.
5.2.4 Secure Payments and SET
There exist many payment schemes that use a variety of payment protocols and
implementations to provide secure payment services. Ghosh [1998] indicates that the
key difference between secure payment protocols and secure web sessions is that
secure payment protocols provide a method for guaranteeing that merchants receive
payments while keeping payment details such as credit card number confidential.
Secure web sessions however leave payment details up to the merchant. An advantage
of secure payment protocols is that credit card details are not available to the
merchant and are therefore safeguarded from a potential unsafe merchant. Examples
of secure payments protocols include the iPK protocols by IBM and Secure Electronic
Transaction (SET).
SET is a technical standard for secure payments over the Internet that focuses on
credit cards and was developed by MasterCard and Visa. According to Ghosh [1998]
SET does not specify actual implementation and therefore does not specify the
ordering process, the payment method selection and the platform or security
procedures needed to secure the SET client and host machines.
34
SET does however specify the following requirement s:
• Confidentiality: SET is only concerned with the confidentiality of payment
information such as credit card numbers and is not concerned with order
information. The securing of payment details is achieved through encryption.
If confidentiality of order details was needed SET could conceptually use the
lower level SSL to create a secure channel thereby encrypting the entire web
session [Ghosh, 1998].
• Data integrity: Digital signatures are used to guard against data corruption or
malicious tampering of data [Ahuja, 1997].
• Client Authentication: Ahuja [1997] indicates that the client must be
authenticated to be a legitimate user of a valid bank-card account number.
This can be achieved by a digital certificate issued to the client by the credit
card issuer or by digital envelopes which contain the client digital signature
[Ghosh, 1998].
• Merchant Authentication: The client must have a method of verifying that the
merchant has a relationship with a banking institution that permit the merchant
to accept bank-card payments [Ahuja, 1997]. This is achieved through
merchant digital certificates.
The following is an example of the steps involved in a typical SET transaction based
on Ghosh [1998]:
1. Consumer sends request for transaction to merchant.
2. Merchant acknowledges request. The consumer and merchant exchange their
digital signatures in these first 2 steps.
3. Consumer digitally signs a message digest of the order and encrypts the credit
card number. The digital signature can be used by the merchant to provide
authentication, non-repudiation and data integrity. The card number is
35
encrypted with the merchant’s bank’s public key in order to hide the number
from the merchant.
4. The merchant sends the purchase amount to be approved and the credit card
number to the merchant bank. The merchant’s bank then uses traditional back-
end structures to check credit.
5. The approval or denial is sent back to the merchant.
6. The merchant confirms the purchase with the consumer stating that the request
has been approved or denied.
7. The consumer can then request the status of the order i.e.: if the merchant has
received payment from the bank the merchant can start delivering the product.
8. The merchant can respond to the status enquiry – the merchant only wants to
release the product once payment has been received and can report back on the
status of the order. If the order is processed in batch cycles instead of real time
the order payment may take longer to receive and therefore the order longer to
deliver.
9. The merchant requests payment from the bank (in real time or batch cycles).
10. The bank will send confirmation of the transfer from the consumers credit card
account to the merchant.
It can be seen that in the SET transaction payment of the merchant is included in the
transaction. This differs from the SSL transaction which is only concerned with
securing the channel and does not consider payments.
5.2.5 Pseudo Card Numbers
Pseudo credit card numbers are card numbers that are non permanent and can be used
once only. Users are able to use a one time credit card number for each purchase
36
made online and therefore do not have to submit their real credit card numbers online.
According to Clark [2001] the purchases made by the pseudo credit card numbers are
recorded against the user’s real credit card number and once a purchase has been
made with the number it expires and any attempts to use that number are rejected.
Clark [2001] identifies pseudo credit card numbers as the easiest fraud reduction
system to implement. Benefits offered to the consumer include increased fraud
prevention through client authentication techniques for example: entering a password
before receiving a pseudo card number.
Benefits to the merchant identified by Clark [2001] include the fact that the entire
process is transparent to the merchant, meaning that the merchant need not alter his
existing systems to support the pseudo card numbers. Another benefit addresses the
insecure merchant problem. Because the pseudo card numbers expire after the
transaction, if a merchant stores these credit card number and a hacker gains access to
them they will be of no use.
Another advantage is that this approach seems to be gaining acceptance with card
issuers. Clark [2001] identifies American Express and MasterCard as card issuers that
seem to have implemented this type of systems to a degree.
The following is a typical process involved when making payment with a pseudo card
number based on those identified by Clark [2001]. Figure 3 shows a visual
representation of the interaction of the steps mentioned below between the cardholder,
merchant, acquirer and issuer.
1. Cardholder authenticates himself with the digital wallet.
2. Cardholder request a pseudo card number through a digital wallet.
3. The wallet server issues a pseudo number to the cardholder.
4. Customer purchases an item using the pseudo number.
5. Merchant sends payment request to acquirer through an internet payment
gateway.
6. The acquirer sends a payment authorisation message to the issuer via and
inter bank network.
37
7. The issuer replaces the pseudo card number with the real credit card
number.
8. The transaction is authorised.
9. The issuer sends the response to the acquiring bank containing the pseudo
card number not the real number.
10. The acquirer sends a response to the merchant.
11. The Merchant sends a transaction response to the consumer.
38
Figure 3: Steps involved in the pseudocard transaction based on those identified by
Clark [2001]
Internet
Internet
Internet
Inter bank network
Issuer
Wallet Sever
Consumer
Wallet
Acquirer
Payment Gateway
Merchant
Acquirer Plugin
2. Cardholder request pseudocard number
3. Cardholder receives pseudocard number
4. Cardholder makes a purchase
5. Merchant sends transaction request to acquirer
10. Acquirer sends transaction response to merchant
11. Merchant sends transaction confirmation to customer
6. Acquirer sends request to issuer via inter bank network
9. Issuer sends response to acquirer via inter bank network
7. Pseudocard number is replaced with real number
8. Real card number is replaced with pseudocard number
1. Cardholder
authenticates
himself with the
digital wallet.
39
5.3 Conclusion
A number of methods for securing the e-commerce transaction have been described
and identified. Because of factors such as simplicity, interoperability and popularity
of the original payment mode, SSL has emerged as the dominant protocol in the e-
commerce market despite its security flaws [Sahut and Galuszewska, 2004]. In order
to further assess the reason that SSL has kept its popularity over other solutions, a
critical analysis of the different mechanisms will now be conducted.
40
Chapter 6
Critical Analysis of the E-Commerce transaction security
mechanisms
In order to critically analyze the mechanisms used to secure e-commerce a table of the
advantages and disadvantages has been generated. These advantages and
disadvantages are then discussed in more detail.
Table 1: Comparison of the advantages and disadvantages of mechanisms used to
secure the e-commerce transaction
Mechanisms Advantages Disadvantages Security
Provided
User ID and
Passwords
1. Familiar
2. Quick
3. User friendly.
Weaknesses caused
by :
1. External disclosure
2. Guessing
3. Eavesdropping
4. Replay attacks
5. Host compromise.
1. Authentication
Tokens 1. Can provide
multifactor
authentication.
2. Can be used to
increase security by
generating ‘one
time’ passwords.
3. Can prevent
unauthorised access
(stealing) of
1. Inconvenience.
2. Cost.
1. Authentication
41
authentication
mechanisms
(passwords or
keys).
Biometrics 1. High level of
security.
1. Inconvenience and
invasiveness.
2. High cost.
1. Authentication
PKI 1. Difficult to
compromise.
2. Doesn’t rely on
shared secrets.
3. Wide spread
general use.
1. Complexity to
implement and
manage.
2. Higher cost than
passwords.
3. Slower – more
processing time
needed.
1.
Confidentiality*
2. Data integrity
3. Non-
repudiation
4. Authentication
* Only provided
over through the
secure channel
SSL 1. Difficult to
compromise.
2. Doesn’t rely on
shared secrets.
3. Widely adopted
in e-commerce.
1. Does not handle
payments.
2. Does not provide
non-repudiation and
client authentication.
3. The insecure
merchant /
illegitimate merchant
problem.
4. Slower – more
processing time
needed.
5. Higher costs than
passwords.
1.
Confidentiality*
2. Authentication
3. Data integrity
* Only provided
over through the
secure channel
Payment
Protocols (SET in
particular)
1. Difficult to
compromise.
2. Doesn’t rely on
1. Resistance to
adoption.
2. Slow speed of
1.Confidentiality
2. Data integrity
3. Non-
42
shared secrets.
3. Guarantee
merchants receive
payment.
4. Prevent the
insecure merchant/
illegitimate client
problem.
system.
3. High cost to
implement.
4. Lack of portability.
5. Difficulty in
managing
certificates.
repudiation
4. Authentication
Pseudo Credit
Card Numbers
1. Ease of
implementation
2. No insecure
merchant problem.
3. High security
against fraud
prevention.
4. Increasing
acceptance with
card issuers.
1. Relatively new and
not yet widely
adopted.
2. The illegitimate
merchant problem
still exists.
3. Merchant has to
stop accepting real
credit card numbers.
1.Confidentiality
2. Data integrity
3. Non-
repudiation
4. Authentication
6.1 User IDs and passwords, tokens and biometrics
The use of user IDs in combination with passwords as an authentication technique
relies on the fact that the password is kept secret. Although this technique is very
familiar to most computer users, doesn’t take much time to process and is user
friendly, the use of a secret has inherent weaknesses. These weaknesses unfortunately
make one of the most widely adopted authentication techniques one of the least secure
methods of authentication available. Ford [1998] and Verisign [2004] both identify
five major threats to password use in e-commerce:
• External disclosure
• Guessing
• Eavesdropping
• Replay attacks
43
• Host compromise.
External disclosure is caused by writing the password somewhere easy to access
causing it to be learned by an attacker, and guessing results from using password that
are easy to remember and therefore have an obvious connection to the user.
Eavesdropping results from intercepting passwords during electronic transactions,
while replay attacks involve an attacker intercepting an encrypted password and
reusing it at a later stage. Host compromise involves the attacker actually gaining
access to the system that stores the password.
6.2 Tokens
Tokens can provide a higher level of authentication and negate some of the threats to
authentication mechanisms such as password use by combining with these
authentication techniques to proved multifactor authentication. For example a user
having to enter a password as well as having to be in possession of a valid token in
order to authenticate themselves, is far more secure than the singular use of a
password.
Tokens such as First National Bank’s Digitags provide a token that doesn’t interact
directly with the computer. This system requires a user to enter a standard password
in order to access a “one time” password that is automatically generated by the
Digitag. The “one time password” can then be used once for banking authentication.
The system thus increases security not only by implementing multiple authentications
(one local authentication on the token itself and another authentication for the banking
system), but by generating a unique one time password that helps prevent problems
such as external disclosure guessing, eavesdropping, replay attacks and host
compromise.
Tokens are often used to store authentication mechanisms such as private keys. In this
way these mechanisms become more secure as they prevent unauthorised parties
accessing the user’s computer and copying the keys for their own use.
44
The use of tokens such as smartcard for authentication can also help prevent the
transmission of shared secrets through local authentication. For example the
smartcard would be inserted into a specialized device attached to the computer and
would authenticate the e-commerce user locally, preventing the user from having to
send a password or key over the Internet for central authentication.
Tokens however do have their disadvantages. The price of a physical token is
obviously more expensive than the use of a non physical authentication technique
such as a password, and this price needs to either be paid by the user or the merchant.
The high price and current limited distribution of specialised devices used to read
some tokens, such as smartcard readers, is even more of a disadvantage. The
inconvenience of having to be in possession of a physical token which may readily be
lost also needs to be considered when thinking of authentication techniques for e-
commerce.
6.3 Biometrics
Biometric techniques are highly secure authentication mechanisms based on
something the user is. This makes them almost impossible to fake. Unfortunately
some of these techniques are not always 100% accurate and this, in combination with
the high price of the equipment needed and the invasiveness of some of the
techniques, means that currently biometrics is not a viable solution to e-commerce.
6.4 Public Key Infrastructure (PKI), Digital Certificates and Digital
signatures
PKI could be a reasonably secure method of providing confidentiality, data integrity,
non-repudiation, and authentication to e-commerce making it difficult to compromise.
It doesn’t rely on shared secrets and therefore prevents some weaknesses associated
with the sharing of secrets. PKI has wide general use for example in securing e-mail,
but has only really been adopted in the form of SSL in the e-commerce sector. One
reason that it has not been adopted is because of the complexity of the management of
digital certificates and keys for client authentication. If a merchant has 5000 clients
for example, the merchant would have to store 5000 client public keys and would
45
have to add a new key each time a new client wished to make a purchase. This
method is a little less efficient in speed and has a slightly higher cost to implement
than password for example, but is mainly used as part of SSL to provide secure e-
commerce.
6.5 The Secure Socket Layer (SSL)
SSL is a mechanism that uses PKI to secure the channel between the merchant and
client. It is therefore also a difficult mechanism to compromise that doesn’t use shared
secrets and that provides confidentiality, data integrity, and authentication but not
non-repudiation. An advantage of this technique is that it is widely adopted for use in
e-commerce.
6.5.1 Problems with SSL
SSL only usually enforces server authentication through digital certificates and
therefore client authentication is usually performed by username and password over
SSL. According to Radha [2004] the protocol does not provide any non-repudiation
and once the communicated information is transferred to the server it may become
insecure as SSL only protects the channel communication. A server could therefore
for example deny that they received a clients order and use his credit card details for
unauthorised transactions. These weaknesses and SSL’s inability to handle
transferring of payments may make it less secure for e-commerce than payment
protocols such as SET for example.
6.5.1.1 The insecure merchant and Illegitimate merchant problem
SSL only secures the channel between the merchant and client, therefore when the
client’s payment details reach the merchant side these details are no longer encrypted
and are readable by anyone that has access to that system. This introduces two
problems, the insecure merchant and the illegitimate merchant. The insecure merchant
46
problem involves a legitimate merchant receiving a client’s payment details but then
failing to secure them from outsiders, because of an insecure system on which these
details are stored. Figure 4, shows the inability of the hacker to access the client’s
details while in transit between the client and the merchant. Once these details reach
the merchant server however, the details are stored unencrypted on an insecure
system. The insecurity of the merchants systems allows a hacker to access the client’s
payment details, which could then be fraudulently used. The use of a payment
protocol could prevent these problems as a payment protocol automatically takes care
of payment thus not allowing merchants direct access to the client’s payment details.
This is achieved by keeping the details in an encrypted state until the details reach the
banks systems, which are legitimate and presumed to be secure.
Figure 4: The insecure merchant problem
The illegitimate merchant problem involves a merchant with fraudulent intent
pretending to offer legitimate services. Again, because SSL only encrypts the client’s
payment details while in the channel between the client and the merchant, the
merchant will have direct access to the client’s payment details when these details
reach the merchant server (Figure 5). The merchant thus has only to convince the
47
client that he/she is offering a legitimate service in order to gain direct access to the
client’s payment details.
Figure 5: The illegitimate merchant problem
The use of a payment protocol could prevent these problems as a payment protocol
automatically takes care of payment through the bank, thus not allowing merchants
direct access to the client’s payment details (figure 6). This is achieved by keeping the
details in an encrypted state until the details reach the banks systems which are
legitimate and presumed to be secure.
48
Figure 6: The use of payments protocols in order to prevent the illegitimate merchant
and insecure merchant problems
6.6 Secure Payments and SET
6.6.1 Advantages of SET
As had been discussed above the main advantage of using a payments protocol over
using a mechanism that only provides a secure channel is that it prevents the
illegitimate merchant/ insecure merchant problem. SET and payments protocols are
usually high security mechanisms that don’t use shared secrets for merchant
authentication and are therefore difficult to compromise. Another advantage of
payments protocols is that they ensure that the merchant automatically receives
payment after the transaction has occurred; this means that merchants don’t have to
manage the complex interaction between issuers and banks. SET had an advantage as
it was backed by two powerful credit card issuers in VISA and MasterCard and
despite this and other advantages mentioned above was still not generally adopted.
Some of the disadvantages of SET and payments protocols that caused the lack of
adoption are now discussed.
49
6.6.2 Disadvantages of SET
It is generally accepted that SET has not been the success it was hoped to be and in
fact Sahut and Galuszewska [2004] list it as a failure. Denny [1998] proposes that this
is due to the complexity involved in its implementation. Cardholder certificates are
the cornerstone to providing the real value of SET but because many banks which are
responsible for the issuing of these certificates have not implemented the
infrastructure to support this, SET has not been as successful as hoped [Denny, 1998].
Sahut and Galuszewska [2004] indicate that in order to create a successful payment
solution client needs such as security, cost, convenience and speed need to be taken
into account. According to Sahut and Galuszewska [2004] these criteria were not
taken into account in the case of SET as “slow SET-based systems encountered a lot
of resistance and had to be abandoned”. Peters [2002] identifies the following reasons
as to why SET failed:
• The scope of SET was too large. Strict requirement of securing credit
card details resulted in burdensome messages between the merchant
and the acquiring institution.
• Certificate Management in SET was burdensome. SET was one of the
first mature adopters of public key infrastructure (PKI) and might have
been easier to deploy if cardholder public keys were registered with the
issuer rather than the cardholder requiring certificates.
• Timing. At the time of SET’s release merchants were focused on
gaining market share and didn’t worry about losses.
• Banks resisted liability that SET would enforce upon them. At present
merchants are responsible for chargebacks and have to pay penalties
accordingly. Banks thus avoid liability and generate revenue from
chargebacks.
Wolrath [1998] states that SET is slow, having Lag times of up to 50 seconds for the
processing of a typical cardholder purchase request to the finalization of the
transaction by the merchants server, as apposed to a couple of seconds with SSL. SET
is also relatively expensive for the merchants to implement. According to Wolrath
50
[1998] experiences during the Swedish SET pilot project had typical costs amounting
to over 30 000 US dollars, which makes SET unprofitable to smaller merchants.
Another serious problem with SET is that it is not portable. This means that if a client
wants to use more than one computer for SET transactions he has to download a
digital certificate and software for each computer that he uses [Wolrath, 1998].
6.7 Pseudo Credit Card numbers
6.7.1 Advantages
Pseudocard numbers can be used in combination with a secure channel mechanism
such as SSL to provide confidentiality, data integrity, non-repudiation, and
authentication. The pseudo credit card system is recognised as one of the easiest
mechanisms for merchants and clients to implement. It is completely transparent to
merchants as pseudocard numbers are treated as normal credit card number as far as
they are concerned. Although it is easy for clients to use pseudocard numbers, they
still need to understand the process of acquiring this number. This could be
accomplished through the use of a digital wallet which automatically provides the
client with a pseudocard number when it is requested, and should therefore not be too
difficult to understand.
A significant advantage of the pseudocard number is that it protects against the
insecure merchant problem. Pseudocard numbers are obviously only valid for one
transaction, therefore even if these card numbers are stored on an insecure merchant’s
systems and accessed by an unauthorised entity, they would be invalid after the
transaction was performed. This eliminates the risk of not knowing the quality of the
security mechanism used to secure a client’s credit card details on the merchant ’s
server.
This method of securing e-commerce is very effective against fraud and is slowly
gaining acceptance with credit card issuers.
51
6.7.2 Disadvantages
Unfortunately the pseudocard number system is still a relatively new system and has
not been adopted widely yet. Another disadvantage is that it does not protect against
the illegitimate merchant problem. That is a merchant that pretends to sell legitimate
goods in order to gain access to credit card numbers, or a merchant that sells goods
but over-charges the cardholder for the purchase. Transaction price limits however
can be set by the cardholder to minimise this threat. Another downfall of this
approach is the fact that for this method to be effective the merchant will have to stop
accepting real credit card numbers. This means that consumers not actively adopting
this method of security may be isolated from the merchant’s target market.
6.8 Summary
The most commonly used mechanism to secure the e-commerce transaction, SSL, has
many disadvantages in that it doesn’t take care of securing the clients credit card
details past the channel between the merchant and the client. Payment protocols
address this problem by making it unnecessary for the merchant to know the client
credit card details thereby eliminating the insecure/illegitimate merchant problem.
Implementations of payment protocols, such as SET, have not been successful and
therefore new methods of preventing fraud in e-commerce must be considered.
Pseudo credit card numbers are an emerging mechanism in preventing fraud in e-
commerce that could be very successful if widely adopted.
52
Chapter 7
Case Study
The following case study is outlined in order to illustrate the potential real world
weaknesses in systems that rely on the security of the merchant server. It illustrates a
prime example of the insecure merchant problem identified in chapter 6.
7.1 CD Universe
In 1999 a hacker called Maxus broke into CD Universes CD retail e-commerce site.
According to MSNBC [2000a] up to 300 000 credit card numbers were stolen by the
hacker. After stealing these credit card numbers Maxus demanded that if he was not
paid $100 000 he would release these credit card details to the public. CD Universe
decided not to pay the hacker and in January 2000, Maxus published these details on a
web page. According to PrivacyTimes.com [1999] before Maxus’ site was shut down
a traffic counter indicated that 25 000 credit card numbers had been downloaded
between the 25th of December 1999 and the 7th of January 2000 by several thousand
different visitors.
How exactly the hacker gained access to these credit card numbers is still unknown.
According to MSNBC [2000a] the chairman of the eUniverse, CD Universe’s parent
company, blamed the breach of security on credit card processing software called
ICVerify. However, a spokesperson from ICVerify denies that CD Universe use their
product and stated “they told us they had credit cards stored in an SQL database.”
Two ways in which the hacker gained access to the credit card numbers have been
identified. The first states that CD Universe may not have stored their consumer’s
credit card details in an encrypted format in their databases. The hacker therefore may
have been able to gain access to CD Universe’s systems and have direct access to the
unencrypted details. A similar method identified by MSNBC is outlined and discussed
below. The second suggested method involves a weakness in the ICVerify software
program. According to MSNBC [2000a] ICVerify logs each transaction, then at the
end of the day saves that log file (including credit card numbers) in a plain text
archive. All the hacker then needs to do, is gain access to the computer performing the
53
credit card verification services, and all credit cards processed will be available in
plain text.
7.2 MSNBC discovers flaw
In January 2000, just after the CD Universe case occurred, MSNBC received
instructions on how to obtain credit card numbers through e-commerce web sites. The
method for obtaining these credit card numbers was as simple as starting up SQL
Server software (a commercially available software tool) and connecting to a web site
through this software. This approach targeted web sites that stored credit card details
in plain text on SQL databases that are connected directly to the web. According to
MSNBC [2000b] in most cases these web pages were using default user names and in
some cases no passwords. Using this approach MSNBC was able to gain access to
2,500 credit card numbers from 20 web sites that either had no password protection or
had password information available on their web sites. MSNBC [2000b] state that as
well as credit cards they were still able access billing addresses, phone numbers and
sometimes even social security numbers.
This case study illustrates the insecure merchant problem mentioned as a weakness of
the SSL infrastructure. Although it is not known whether SSL was used in the CD
Universe case, the concept of the insecure merchant that stores credit card numbers on
their servers is clearly illustrated. If a payment protocol was used the approach
identified by MSNBC (discussed above) would no have been possible.
54
Chapter 8
Options and Recommendation
A number of different technologies that can be used to secure e-commerce have been
identified in the discussion above. Combinations of these technologies can be used to
enforce the needs of e-commerce security and a number of approaches to securing e-
commerce are identified in table 1.
Table 2: Options of combinations for securing e-commerce
Passwords
and User ID
Tokens Biometrics PKI SSL Payment
Protocols
Pseudocard
numbers
1 *
2 *
3 *
4 * *
5 * *
6 * *
7 * * *
8 * *
9 * *
10 * *
11 * * *
12 * *
Passwords and user IDs, tokens and biometrics can all be used to provide
authorisation and authentication in e-commerce. Passwords and user IDs provide the
simplest and most readily adopted method of authentication but however is known as
one of the least secure methods of authentication available. Tokens such as smartcards
and Digitags provide a much higher level of authentication due to the fact that they
prevent transmission of shared secrets over an open network through local
authentication. Tokens in combination with user IDs and passwords provide multi-
55
factor authentication which provide an even higher level of authentication security
and could have viable implementations in high security e-commerce areas such as
electronic banking. Biometric techniques provide the highest level of authentication
security, however due to the high cost and inconvenience of implementation biometric
techniques are not currently a viable option for authentication in the e-commerce
environment. It must be remembered that all of the techniques mentioned above only
provide authentication and do not provide solutions to confidentiality, data integrity
and non-repudiation; they therefore are not viable options for securing e-commerce in
isolation. These techniques should therefore be used in combination with some of the
techniques discussed below in order to provide greater security through
authentication.
8.1 Option 1
PKI in isolation (option 1) is a viable solution to providing security to e-commerce as
it offers protection of confidentiality and authentication through encryption and key
management; and data integrity and non-repudiation through digital signatures and
digital certificates. PKI however, has not been adopted widely as a solution in
industry, although aspects of it have been used extensively in other implementations
such as SSL. The difficulties with key management in business to consumer e-
commerce in particular, are one of the main reasons as to why PKI has not been
widely adopted. For small business to business e-commerce the use of PKI could be
an excellent simple solution.
8.2 Option 2
SSL is one of the most readily implemented solutions to e-commerce security. It uses
public key cryptography to create a secure channel of communication thus providing
confidentiality of data over the network. SSL in isolation is a viable option for
securing small to medium businesses’ e-commerce systems. This option does
however have its weaknesses as it does not provide client authentication and non-
repudiation which could allow the use of fraudulent credit card numbers. It also does
not take care of payment leaving those details to the merchant which can be
burdensome. Because SSL doesn’t provide for payment it allows potentially insecure
56
or illegitimate merchants access to credit card details potentially allowing fraudulent
activity. SSL could therefore be used but only in combination with mechanism that
provide security to the merchant servers e.g. firewalls and encryption, which is
beyond the scope of this paper. This approach adds complexity to the management of
the security of the e-commerce transaction and places high dependency on the
merchant’s security systems.
8.3 Option 3
Payment protocols such as 3D Secure and Secure Payments Application (SPA) in
isolation (option 3) could be used as a very effective way of securing e-commerce.
The advantages of using payment protocols is that it provides for payment, thus
eliminating the need for merchant to have access to credit card details, eliminating
potential fraud by illegitimate merchants or by fraudsters gaining access to insecure
merchants. The problem here lies not as much in the security it provides, but in the
adoption of payments protocols by banks, merchants and clients. If payments
protocols are widely adopted then they would be one of the best mechanisms for
providing e-commerce.
8.4 Option 4
Security in PKI could be improved dramatically by using PKI in combination with
tokens. Each user could own a token that contains his public priva te key combination
thus preventing fraudsters from stealing private keys that are stored on the computer
itself. Tokens could also provide multiple authentication of users, requiring them to
enter a password in order to use their private key stored on their token. A
disadvantage of this method is the inconvenience of having to have a separate token to
perform transactions. The availability of token readers (e.g. : smart card readers) is
also limited at the moment. This option may be used widely in the future and could be
used with more specialized e-commerce activities which don’t require the large
distribution of specialized token readers.
57
8.5 Option 5
SSL in combination with usernames and passwords for client authentication is a
viable option for securing e-commerce. An advantage of this approach is that an easy
to use and familiar method of client authentication helps to prevents credit card
number theft and fraud. This method provides for greater security through client
authentication but still has inherent weaknesses that are associated with passwords use
(i.e.: external disclosure, guessing, eavesdropping, replay attacks and host
compromise). This approach only takes into account one of the weaknesses of SSL in
isolation (option 2) and still has weaknesses with insecure or illegitimate merchants.
8.6 Option 6
Using SSL in combination with tokens is a more secure method of securing e-
commerce than SSL with passwords and user IDs. Both methods provide user
authentication but tokens provide a physical “real world” method of verifying a
cardholder’s identity. This eliminates the weaknesses associated with password use,
but introduces other difficulties. These disadvantages include difficulties involved in
token distribution (i.e.: a client cannot perform a transaction until they have received a
valid physical token), and difficulties involved with the distribution and availability of
physical token readers (very few clients have smart cards readers for example at this
stage). This option still does not take care of problems with insecure or illegitimate
merchants. Option 6 could be viable for use for companies with medium to high
security needs where the potential costs of breach of security outweigh the costs of
distribution of tokens and/or token readers.
8.7 Option 7
SSL in combination with tokens and usernames and passwords provide multiple
levels of client authentication and is more secure than option 6. It however does have
the same disadvantages associated with tokens and also does not handle the problems
of the insecure or illegitimate merchants (both discussed above). If a company is
considering using option 6, option 7 would be a more secure method of securing e-
commerce with very little extra cost.
58
8.8 Option 8
The use of SSL along with biometrics would not be a very viable solution to securing
e-commerce at present. Firstly these technologies are still considered to be costly, and
are still emerging and therefore not always accurate. Client adoption of this method of
authentication would also be difficult due to the perceived invasiveness of some of the
methods and the cost of the equipment. This could be a viable option in the future of
e-commerce but at the moment the cost of using this method would in most cases
outweigh the advantages offered by it.
8.9 Options 9, 10 and 11
Payment protocols as mentioned in the discussion of option 3 take care of the insecure
and illegitimate merchant problem by providing for payment directly from the bank
thus hiding the client’s credit card details from the merchant. Payment protocols,
however, sometimes do not provide for client authentication. This can be added
through the use of password and user IDs, tokens or both. The advantages and
disadvantages of each authentication technique are the same when used in
combination with payments protocols and have been discussed above. Payments
protocols in combination with client authentication techniques can be considered the
most secure methods of securing the e-commerce transaction. This is due to the fact
that they provide for client authentication, thus preventing unauthorised use of credit
card numbers, and that they prevent the insecure and illegitimate merchant problem
by automatically providing for payment. It is thus suggested that the use of payment
protocols in combination with usernames and passwords for client authentication is
one of the most secure and most viable options to securing the e-commerce
transaction. A merchant could implement tokens for client authentication when a
higher level of security is needed, but the cost of a potential breach of security should
outweigh the cost of implementing the token authentication system.
59
8.11 Option 12
The use of pseudocard numbers for fraud prevention in combination with SSL for
securing the communication channel is an extremely effective method of securing the
e-commerce transaction. In terms of security this combination provides all the
advantages of SSL and prevents the insecure merchant problem associated with SSL.
It is therefore an extremely secure method of implementing security in the e-
commerce transaction.
In terms of ease of adoptability pseudocard numbers are an easy and transparent way
for a merchant to implement fraud prevention. The consumer however may have to
download special software (a digital wallet) which issues the pseudo credit card
numbers, which means that it is not portable and may cause inconvenience when the
user wants to shop from multiple computers. This approach has not yet been widely
adopted and much of its general adoption depends on whether there is wide spread
implementation of this method by issuers. In this approach the onus is on the
consumer to actively adopt the pseudo credit card system. Clients with less technical
knowledge, which may be required for downloading digital wallets for example, or
clients with less concern with security may not choose to adopt the pseudocard
system. As has been mentioned, for this system to be effective a merchant would have
to stop accepting normal credit card numbers and may isolate non adopters of pseudo
credit card systems.
Although the use of SSL in combination with pseudocard numbers is a very effective
security mechanism, it does have adoptability downfalls which may affect the extent
of its use. At the moment pseudocard numbers are not widely adopted enough to be
considered the best option for securing e-commerce but in the near future it may be
the most effective method of securing the e-commerce transaction.
8.11 Conclusion
The Secure Socket Layer (SSL) is one of the most commonly used mechanisms to
secure the e-commerce transaction. SSL is a viable option when considering secure e-
commerce but it has a number of weaknesses which could be rectified by the use of
60
payments protocols. The inability of SSL to handle payments means that an
illegitimate merchant could have direct access to a client’s payment details or that an
insecure merchant could allow unauthorised users access to these details. SSL also
does not provide non-repudiation. Payment protocols in combination with client
authentication techniques do not have these weaknesses and therefore provide the
safest method of securing the e-commerce transaction. Another viable solution to this
problem is the use of pseudo card number although it too has some downfalls. To the
standard merchant looking to upgrade or create a new e-commerce system; I would
strongly recommend considering using payments protocols in combination with
passwords and/or tokens for client authentication in order to provide a secure service.
61
Chapter 9
Conclusion
This chapter discusses whether the project has met its aims; it then summarizes the
findings and concludes the research.
9.1 Research contributions
The aims for this project, identified in section 1.2, included identifying weaknesses in
current e-commerce security mechanisms and identifying options and
recommendations in order to prevent future frauds.
In terms of identifying weaknesses in current e-commerce security implementations a
number of weaknesses in SSL have been identified. Although SSL can be used
successfully to secure an e-commerce transaction, it does have weaknesses especially
in terms of the insecure merchant problem.
In term of identifying options and recommendations for securing e-commerce, a
number of different options in the form of combinations of mechanisms, have been
formulated in chapter 8. A number of recommendations for solving the weaknesses in
the various mechanisms have also been discussed. For example it was recommended
that the implementation of payments protocols in combination with a client
authentication technique may provide for greater security than SSL alone.
It can therefore be seen that the aims of the project have been reached.
9.2 Application
The findings of this paper could be used by any merchant looking to implement or
improve an e-commerce system. The merchant could use the insight provided in this
paper to decide which method of securing the e-commerce is most secure and most
suited to his/her company.
62
9.3 Future Work
This paper identifies payments protocols as a suitable method for decreasing fraud in
e-commerce. Future work could be done in order to evaluate the different payments
protocols available (e.g. Visa’s 3D Secure and MasterCard’s Secure payments
application). This type of future work could be used to help merchants decide which
payment protocol is most suitable to their companies.
63
References
Ahuja [1997] Ahuja, V. Secure Commerce on the Internet, AP Professional,
London, 1997.
Australian
Government’s
Department of
Defence
[1999]
Australian Government’s Department of Defence. The security
of Electronic Payment Systems. Published: 15 June 1999. Accessed:
9 September 2004.
URL: < http://www.dsd.gov.au/library/infosec/security.html >
Burrows
[2004]
Burrows, T. A million SA e-bank accounts, more coming.
Published: 3 March 2004. Accessed: 6 March 2004.
URL:
<http://www.itweb.co.za/sections/internet/2004/0403031143.asp?A
=EBU&S=e-Business&O=E&CiRestriction= >
Claessens et al
[2002]
Claessens , J; Dem ,V; De Cock, D; Preneel, B; Vandewalle, J.
“On the Security of Today’s Online Electronic Banking Systems”
in Computers and Security, 2002, Vol 21, No 3, pp 257-269.
Consumer
Sentinel
[2004]
Consumer Sentinel. Three year trend for sentinel complaints.
Published: 22 January 2004. Accessed: 21 March 2004. URL:
<http://www.consumer.gov/sentinel/states03/3year_trends.pdf >
Denny [1998]
Denny, S. “Is SET really the answer to E-Commerce?” in Journal
of internet banking and commerce January 1998, vol 3, no. 1.
Ford [1998]
Ford M. 'Identity Authentication and 'E-Commerce'' in The Journal
of Information, Law and Technology (JILT), Issue 3, 1998.
Freedman Freedman, D. How to hack a bank. Published: 4 March 2000.
64
[2000]
Accessed: 21 March 2003. URL:
<http://www.forbes.com/asap/2000/0403/056.html>
Gartner
Group [2003]
The Gartner Group. Online banking goes mainstream in US.
Published: 10 March 2003. Accessed: 23 March 2004. URL:
<http://www.nua.com/surveys/index.cgi?f=VS&art_id=905358738
&rel=true>
Ghosh [1998]
Ghosh, A. E-Commerce Security: weak links, best defences, Wiley
Computer Publishing, Canada, 1998.
Hutchinson
and Warren
[2003]
Hutchinson, D and Warren, M. “Security for internet banking: a
framework” in Logistics Information Management, Number 1,
2003, pp. 64 – 73.
Journal of
Computer
Security and
Fraud [2003]
“Fraud rises with ID theft on top” in Journal of Computer Fraud
and Security, 2003, Volume 2003, Issue 2, pp. 2.
MSNBC
[2000a]
MSNBC. Stealing credit cards from babies. Published: 11 January
2000. Accessed: 13 October 2004.
URL < http://zdnet.com.com/2100-11-501775.html?legacy=zdnn >
MSNBC
[2000b]
MSNBC. How to steal 2,500 credit cards. Published: 14 January
2000. Accessed: 14 October 2004.
URL < http://zdnet.com.com/2100-11-501784.html?legacy=zdnn >
Peters [2002] Peters, M. Emerging E-Commerce Credit and Debit Card
Protocols. Published: 2002. Accessed: 9 August 2004.URL: <
http://ecommerce.ncsu.edu/ISEC/papers/05_peters_emerging.pdf >
65
Privacy
Times.com
[2000]
Privacy Times.com. CD universe case suggests a gang of 'carders'
dedicated to stealing credit card numbers. Published: 2000.
Accessed: 10 October 2004.
URL: < http://www.privacytimes.com >
The
Queensland
government’s
department of
state
development
and
innovation
[2001]
The Queensland government’s department of state development
and innovation. Types of E-commerce. Published: 15 May 2001.
Accessed: 12 October 2004. URL:
<http://www.sd.qld.gov.au/dsdweb/htdocs/global/content.cfm?id=1
364 >
Radha [2004]
Radha, V. “Preventing Technology Based Bank Frauds” in Journal
of Internet Banking and Commerce, vol. 9, no. 1, 2004.
Sahut and
Guluszewska
[2004]
Sahut, J and Guluszewska M. “Why does SSL dominate the e-
payment market ?” in Journal of Internet Banking and Commerce
February 2004, vol. 9, no. 1
The Federal
Financial
Institutions
Examination
Council [2001]
The Federal Financial Institutions Examination Council.
Authentication in an electronic banking environment. Published: 8
August 2001. Accessed: 3 June 2004.
URL:< http://www.occ.treas.gov/ftp/advisory/2001-8a.pdf >
Verisign
[2004]
Verisign. Building the Infrastructure for secure Electronic
Commerce. Published: 2004, Accessed: 10 May 2004. URL:
<http://www.verisign.com.au/whitepapers/enterprise/ecommerce/inf
ra5.shtml>
66
Wolrath
[1998]
Wolrath, C. Secure Electronic Transaction: a market survey and a
test implementation of SET technology. Published: 27 September
1998. Accessed: 9 August 2004. URL: <
http://www.wolrath.com/set.html >.