10.1.1.94.7157

8/2/2019 10.1.1.94.7157

1/18

SEM10 Survey Paper The Security of Electronic (Financial) Transactions Page 1 of 18

Peter Gradwell (pjg7) Peter Gradwell 2001

A survey of current techniques and issues surrounding thesecurity of electronic (financial) transactions.

Abstract

In this paper we discuss the current techniques and technologies being used and developed in thesoftware engineering industry to protect electronic transactions across public networks. We discuss

the issues that form a basis for the provision of trust, privacy and security. We consider initiatives

such as the Secure Electronic Transaction protocol (SET) and the Transport Layer Security protocol

(TLS). Finally we consider advances in digital money, electronic settlement systems and methods to

support anonymous, non-repudiatable transactions of all values.

Introduction

A 1996 Survey of corporate security chiefs and senior executives indicates that 78% of the

respondents experienced some financial loss resulting from Internet security breaches. [2]

Electronic payment systems must enable an honest payer to convince the payee to accept alegitimate payment and at the same time prevent a dishonest payer from making unauthorised

payments, all the while ensuring the privacy of honest participants. [4]

This paper is a survey of the current techniques and issues surrounding the security of electronic

transactions that are typically conducted over insecure, public wide area networks.

Much of the hype in this subject area has been centred on the mass-market potential of digital

cash and many of the issues, particularly to do with trust and privacy are better explained in

association with digital cash systems. However, I feel that it is important to remember that the

B2B community, with inter-corporation trading is a significant, if not larger potential user of

electronic money systems and the same issues are applicable.

Current methods

Traditionally, trust and security has been built and maintained on a physical basis. Car dealers shake

hands and exchange keys. Lawyers frequently witness the joint signing of contracts. In the world of

Electronic Data Interchange (EDI), companies typically built secure private networks using private

access technologies, such as dialup modem pools or X.25 networks. By physically separating the

corporate networks from any public network there was inherent security and trust in the system.

Contractual restrictions and testing procedures are typically used to ensure that both parties provide

valid and safe information to each others systems.

Such companies now have a desire to stop using expensive private networks and make greater use

of the cheaper, but less secure wide area networks such as the Internet. On these networks we need

to ensure the security of every transaction. Further, companies wish to interact with a wider range of

parties, they might now wish to deal globally. At this level, the traditional contractual processes

become prohibitively expensive. How can Company A trust what purports to be a computer

acting for Company B without any form of physical assurance?

For the typical business to consumer e-commerce the values of transactions is small and it has

largely been up to the consumer to decide if they trust the retailer. The retailer typically implicitly

8/2/2019 10.1.1.94.7157

2/18



trusts the consumer (perhaps only on remittance of appropriate funds). The basis upon which a

consumer is supposed to decide whether or not to trust the retailer is a little vague1.

At the transport layer communications are typically secured using SSL, the Secure Sockets Layer

protocol. This is a proven method for encrypting Internet Protocol transmissions; however it does

not scale terribly efficiently. There are also problems with identifying the client end of the

connection. Not many users have client side digital certificates because of the complexity of issuingthem.

At the payment level, customers simply pass their plain text credit card details across an SSL

secured link. They must trust that the merchant will not misuse the card details. Systems such as

SET provide a mechanism through which the retailer can receive payment by credit card without

being exposed to the customers details. However, it has yet to be widely adopted due to a

dependence on slow cryptography techniques and bloated infrastructure requirements.

In order to evaluate the suitability of current security techniques, most notably the use of the Secure

Sockets Layer Protocol (SSL) and the Secure Electronic Transaction Protocol (SET), it is important

to understand the needs of the market place. Albrecht et als analysis of SSL and SET defines keyuser requirements in electronic commerce as being Security, Privacy and Trust. [3] We shall

consider these in order.

1 In 1999 Cheskin did a study of eCommerce Trust [18] and they concluded that customers tend to look for strong

brands, established companies and accreditation with internet trust bodies, such a Verisign and Trust-e.

8/2/2019 10.1.1.94.7157

3/18



Security

There are a number of different technologies in existence which support the security of electronic

transactions. These focus primarily on the use of cryptographic systems to ensure that messages

cannot be read by a malicious third party.

Transport Layer SecurityThe Secure Sockets Layer (SSL) was first proposed as an Internet standard by Netscape

Corporation in 1995. The objective at the time was to provide encryption and security for the HTTP

transport mechanism. Shortly after Netscape submitted their standard for consideration two

companies, Enterprise Integration Technologies Inc. and Microsoft Corp both also submitted

proposals for technologies known as S-HTTP and PCT (Private Communication Technology). The

following year, an IETF working group on Transport Layer Security (TLS) was formed and the

TLS specification was published from a combination of the SSL and PCT specifications.

Whilst the current accepted standard for transport layer security on the Internet is the TLS

specification, its not the commonly used buzz word. Most internet users refer to the use of SSLtechnology when they implement or request encryption. However, the TLS v1 standard is virtually

identical to the SSL v3 standard and most common web servers and browsers support both even if

the hype has yet to catch up.

In their evaluation of TLS performance, Apostolopoulos, Peris and Saha suggest that TLS has

outgrown other transport layer security mechanisms such as SSH, SET and SMIME in terms of

application protocol independent deployment. [7] This is because, in theory, any application which

runs over TCP can run over TLS. TLS provides a secure layer which plugs in on top of TCP and

below the application layer. The other protocols are more application specific and not as universal.

TLS contains two main components. The TLS Handshake Protocol is responsible to establishingTLS sessions between the two parties whilst the TLS Record Protocol is responsible for securing

the data transfer between them.

The Handshake protocol uses public key cryptography for exchanging sufficient secret keys in

order to setup a symmetrical session key which is then used to encrypt the actual traffic.

In the evaluation of TLS paper [7] the authors express some concerns about the scalability of using

the TLS mechanism to encrypt traffic.Using both the Apache and the Netscape web servers they

found that there is a point at which the web server performance quickly becomes intolerable2. On

their reasonably configured IBM RS/6000 server, this point was about twenty SSL requests per

second. (This is obviously a generalisation; the report is based around a thorough and valid testingplan.)

The paper compares TLS encrypted traffic with normal plain text HTTP based traffic. It finds that

the price paid for TLS based security is quite significant. It makes some suggestions as to how

future versions of the TLS protocol could become more efficient:

1. They suggest that the TLS sessions states could be reused more as this would greatly reduce thecost of a TLS connection setup. Without the public key encryption operations the time taken to

instantiate a secure channel is between 3 and 4 msec which are very similar to a normal TCP

connection setup.

2 Large Scale SSL users typically use dedicated hardware to speed up the public key transactions, such as those by

NCipher (http://www.ncipher.com/).

8/2/2019 10.1.1.94.7157

4/18



2. They also suggest that certificates could be cached by the client. The removes the need for theserver to send its certificate (and any associated certificate chain) to the client. Typically, each

element in a certificate chain is about 750 bytes.

3. The most expensive operation in the handshake process is the server side decryption of the

master secret with the servers private key. The paper suggests that by having the servergenerate the pre-master secret (rather than the client, which is what happens in the existing

system) the handshake can be streamlined and the expensive master secret decryption load can

be placed on the client.

4. Finally, the authors suggest that typically a 1024-bit encryption key is used. However, theyargue that whilst the use of 1024-bit encryption is good because it makes it nearly impossible to

crack it greatly adds to the encryption overhead on the client and server. They suggest that the

temporary private signing key (negotiated in the handshake phase) should be only a 512-bit key,

but the session key should be re-generated approximately every 30 minutes. This will ensure

that it is virtually impossible to crack the key (it takes a number of days to crack 512-bit

encryption so if the key changes every 30 minutes, it will never be possible to crack it before itis thrown away).3

The authors suggested improvements vastly improve the efficiency of the TLS protocol without

compromising the security it provides. It will be interesting to see if the future versions of the TLS

protocol take these suggestions into account.

Secure Electronic Transactions (SET)

In their 1997 paper The State of the Art in Electronic Payment Systems a group of researchers

from IBMs Zurich Research Laboratory suggested that Within the next two to three years, SET

will become the predominant method for credit card purchases on the Internet. [4]

However, at the dawn of 2002 SET has not yet become widely accepted. It is sensible to pose the

question: What went wrong? Firstly, we shall consider the SET process:

In their analysis of SSL and SET [3] Albrecht and Malone outline the basic workings of the SET

specification. SET is intended to make a secure loop between the customer (card holder), the

retailer (merchant) and the credit card issuer (payment gateway). The card details go directly

between the customer and bank and the approval message is then given to the retailer. This all

happens in real time. The card holder initially obtains digital certificates for both the merchant and

the payment gateway. After preparing two sets of data, a payment information (PI) block and an

order information (OI) block, both of which contain a merchant supplied transaction identifierblock the card holder generates a dual signature covering both blocks which can be verified by both

the merchant and payment gateway. A one time session key is then used to encrypt the PI block.

Next, the session key is encrypted with the payment gateways public key and the whole bundle

is forwarded to the merchant along with an unencrypted version of the OI. After verifying the dual

signature the merchant forwards the bundle (minus the order details) to the payment gateway for

authorisation. This process ensures that the merchant never sees the card information and that the

payment gateway sees none of the details related to the purchase in question.

3 This technique of changing the private key every 30 minutes only works if the data you are securing does not need tobe valid for longer than 30 minutes. If the data needs to be kept secure for longer then the length of the private keyneeds to be adjusted so that the data is kept appropriately secure. However, it seems unlikely, in the common use of

SSL as a transport layer security device, that data will need to be kept secure for more than 30 minutes or an hour.

8/2/2019 10.1.1.94.7157

5/18



SET is obviously a useful specification, but it has yet to be adopted. In his 1998 Masters thesis,

Wolrath [8] considers why and outlines a number of the problems with the existing SET

specification:

1. Interoperability SET is just a specification upon which banks and software vendors have todevelop payment gateways, customer wallets and point of sale interfaces. However: Many

issues still remain to be resolved, mainly because the SET Specification in itself is somewhatunspecified in certain areas and doesnt cover the entire shopping process (e.g. SET-payment

initiation, Order description content, communication port identification, Language support). [8]

The interoperability issues will be compounded if a new version of the SET protocol is

developed.

2. There has also been much criticism about SET. It has been very slowly developed with manytechnical set backs and problems in agreeing a standard. SET is also costly to implement (in

terms of software development). This has hindered acceptance, particularly by payment

gateways (banks) and merchants (retailers).

3. It is also unclear whom SET will benefit the most. SET implementations are very expensivewhen compared against the existing credit card acceptance options. SET is also not widely

adopted by consumers. In 1999 Vernon Keenan, a senior analyst at Zona Research claimed that

the concept of a digital wallet is SETs biggest hurdle because it requires users to actually install

a piece of software. He argues [9] that: "Anything that requires consumers to take an extra step

deters them from adopting it".

4. Finally, SET is slow. It makes heavy use of RSA encryption to perform a fairly large number ofsigning and encryption activities per payment. Lag times of 50 seconds have been reported for

typical user purchases in the pilot schemes. This is clearly unacceptable. This problem mostly

stems from the use of the slow RSA algorithms. It is suggested that future versions of SET may

use the elliptic curve technologies to secure transactions. [9]

8/2/2019 10.1.1.94.7157

6/18



Elliptic-curve cryptography

One of the key problems with the existing methods of performing public key software encryption is

that they are slow. The SET protocol particularly suffers from these problems because it contains a

fairly large number of public key exchanges as data is transferred between the three parties.

To date, SET has relied on RSA's S/Pay toolkit. "RSA was chosen because it has withstood the testof time, but people are anxious to explore something called elliptic curve security," says Mr.

Greene. [Of IBM] [9]

To date, the encryption technologies have revolved around hardmathematical problems. Two

techniques have stood the test of time.

1. The factorisation of large integers into prime numbers. Essentially, whilst it is easy to generatetwo large prime numbers and multiply them together, it is computationally very difficult to

factor the number to identify the original two prime numbers. This technique forms the basis of

the RSA cipher.

2. The computation of discrete logs is a second hardtask. Garrett, 2001 [10], states that:

Fix a modulus m and integers b,c. An integer solutionx to the equation bx c mod m is a

(discrete) logarithm baseb orcmodulom. It is important to know that for random m, b and c

there may be no such x. But, for prime modulusp and good choice of base b there willexist a

discrete logarithm for any c not divisible byp.

Therefore, whenp is a prime number it is possible to determine a discrete logarithm which can be

used as a key for the encryption.

The concepts of using discrete logs are fundamental to the ElGamal cipher, a public key cipher

which is used in conjunction with elliptic-curve cryptography.

The use of elliptic curves comes when it is desirable to identify cases where it is hard to compute

discrete logarithms. The success of the ElGamal cipher depends on the impracticability of finding .

Elliptic curves are useful because of their geometry. This geometry makes them particularly suitable

for identifying prime numbers quickly that make the elliptic curve discrete logarithm problem hard.

The problem is that, given pointsPand Q on the curve, find a numberksuch that Q= kP. kis called

the discrete logarithm ofQ to the baseP.

WhenPand kare large, it is computationally difficult to determine kfromPor from kP.

The mathematics of elliptic curve cryptography and the process and justifications for determining

suitable points on the elliptic curve are, whilst fascinating, rather complex and certainly beyond the

scope of this paper. Good, albeit complicated introductions are given in [10] and [11].

Clearly, the maths surrounding elliptic curves, once packaged into a suitable application

programming interface will enable a different approach to be taken in dealing with the SET

specifications needed for several public key operations, hopefully speeding up the overall

transaction time.

8/2/2019 10.1.1.94.7157

7/18



Finally, it is worth noting other proposed mechanisms for speeding up electronic transactions. In

their paper [5] PayWord and MicroMint: Two Simple Micropayment Schemes Rivest and Shamir

discuss the use of hash functions in micropayment systems to validate the integrity of the coins

rather than spend time trying to validate their origin:

a user who loses a micropayment is similar to some one who loses a nickel in a candy

machine. Similarly, candy machines arent built with expensive mechanisms for detectingforged coins, and yet they work well in practice, and the overall level of abuse is low.

They argue that, As a rough guide, hash functions are about 100 times faster than RSA signature

verification and about 10,000 times faster than RSA signature generation. Therefore, they propose

their Micromint system which uses coins (formed of bit strings) whose validity can be easily

checked by any party, but which are hard to produce. In this case, Micromint coins are the result of

a k-way collision of k hash functions and thus expensive to produce, except in large quantities.

It seems, therefore, that there are two approaches to speeding up the processes of authentication and

validation using public key cryptography. The first is to use different cipher techniques which are

more efficient. The second is to avoid the use of expensive public key signature generation andverification, typically by producing tokens which are very hard to manufacture, but very easy to

verify. These tokens are then exchanged by the vendor with a broker for payment. This kind of

system mirrors our existing real money system almost identically and is clearly effective.

8/2/2019 10.1.1.94.7157

8/18



Privacy

It can easily be argued that nothing has been more popular in financial transactions than the used

fiver. Through out the ages, people have welcomed the privacy that cash provides. People are

usually of a private nature and do not like to have their every move recorded. A digital replacement

for our cash based society will need to maintain those attributes if it is to be successful.

Key attributes of an Electronic Cash System

Before examining ways of achieving privacy in electronic transactions it is perhaps worth

considering what the useful elements of a digital cash system would be. A paper by Daniel Simon

of Microsoft Corp [1] outlines a number of properties that any ideal electronic cash protocol should

have:

Correctness: People using the system should be able to spend and accept electronic money inthe knowledge that their relevant bank accounts will be correctly debited and credited.

Integrity: The system should be immune to attempts by other parties to forge coins and lay

claim to existing coins. There should also be no disputes regarding account balances. Recoverability: If the bank is dishonest then there is little that any customers can do to make it

honour its coins. However, parties should be able to identify such dishonest behaviour. There

should be mechanisms to discipline the bank. Finally, the dishonesty of the bank should not

affect the spending ability of the consumers. For example, if a dishonest bank is taken over by

an honest bank then the coins should continue in circulation unaffected.

Anonymity: Spending of coins should be untraceable. Parties to a transaction should only beable to know the information directly related to their handling of the coin.

Efficiency: An electronic cash system needs to be efficient, so that the cost of handling thetransaction is less than the value of the transaction. Simon suggests that the amount of work

per transaction (both computation and communication) for each party involved (spender,

receiver and bank) [should be] at most polynomial in the security parameter and the logarithmof the number of parties in the network.

Its interesting to note that most of the parameters deemed desirable for electronic systems are those

that consumers require of our existing traditional banking systems. This is clearly not brand new

rocket science!

Privacy with SET

The SET protocol was designed with consumer privacy in mind. It ensures that the retailer never

sees the consumers credit card details, thus removing the possibility of abuse by rogue traders.

As previously discussed, the paper An Analysis of SSL and SET for Electronic Commerce [3]describes how the SET protocol secures the consumers credit card details from being viewed by the

merchant by placing them inside a secure digital envelope to which only the payment processor

can view them.

Blind Signatures

Our current use of credit cards and loyalty cards enables the providers to keep track of how we

spend our money. It is currently possible to use a major supermarket chain as your food and

clothing supplier, your bank and Credit Card Company, your financial advisor and investment

partner and your internet provider. We might well imagine that you could also purchase your gas,

electricity and telecom requirements from the same organisation. This company would be able to

build up a fearsome electronic picture of your activities and movements as well as your wealth andpersonal preferences.

8/2/2019 10.1.1.94.7157

9/18



Whilst a scary (but real) thought, it is an acceptable situation for the majority of people. This is

largely because there is a still a choice. Its possible to buy each of the above functions from an

independent company. We can still get anonymous cash and spend it.

However, if we begin to use entirely digital money then there will be no anonymous form of

purchasing and the databases of banks and associated companies will become ever larger.

In an electronic transaction the key feature is the digital signature. As discussed, this electronically

signs the message so that the recipient can be sure of who sent it (assuming the senders keys have

not been compromised). Digital signatures can therefore provide security. If the First Virtual Bank

was to issue electronic bank notes, all signed by the banks private key, then they could be verified

by shops and consumers with the banks public key.

The problem with such a system is that, whilst its secure, it has no privacy. This is discussed in

Achieving Electronic Privacy [15], a 1992 paper by David Chaum.

Chaum suggests that when Alice withdraws an electronic bank note from the bank, she will

presumably authenticate her self (perhaps signing the withdrawal request with her private key).

Each note will have a serial number allocated by Alice (she can choose a random 100 digit number

to minimise collisions) which the bank will record. When Alice takes the note to Bobs shop, Bob

will contact the bank to verify the note and surrender it in return for credit to his bank account. A

series of digitally signed receipts will be distributed to all parties. This will of course complete the

loop. The banks dossier will place Alice in Bobs shop with a particular bank note at a particular

time.

The key to preventing this big brother syndrome is stopping the bank and the shop linking the

bank note numbers. Chaum has developed a technique titled Blind Signatures. Blind signatures

work on the premise that user of the cash can remain anonymous so long as they do not spend it

more than once. If they do double-spend then their identity would be revealed.

Under his proposed system Alice and the Bank create an unforgeable digital signature from the

Bank which the Bank will not recognise as coming from Alice when she later gives it to Bob, the

merchant.

When withdrawing the money, Alice will, as before, select the bank notes serial number [f(x)],

but this time she will multiply it by a random factor [r]. After receiving the blind note, Alice divides

out the blinding factor and uses the note as before. The important detail is that Alice actually sends

f(x)*r^3 to the bank [f(x) is a one way function of x, e.g. MD5[19]] and then the bank takes the 1/3power [i.e. rf(x)^(1/3)]. The reason for using the cube root is that it makes forging the serial

numbers hard?. Only the bank can find the cube root of a one way function of x.

As with the previous system, when Alice wishes to spend the money Bob will submit the electronic

note to the Bank to ensure that it hasnt already been spent. However, the Bank wont recognise the

notes specific serial number as having come from Alice. It will however know that its a valid

serial number and so it can determine whether it has previously been spent (and so if it is valid).

When Alice deposits the money, Bob must call the bank to make sure that it hasn't been deposited

before, this being an "on-line" system. Although the bank won't recognize x (it's never heard of it) it

will remember all the x's which have been deposited and so can alert Bob if the money has beenspent before. Both Bob and the bank can verify the digital signature on the money and so the bank

can decide whether or not to honour the note.

8/2/2019 10.1.1.94.7157

10/18



Anonymous Accounts

An alternative approach to keeping a consumers identity private is to conceal it at the withdrawal

phase. A number of authors have suggested that this might be achieved through the use of

anonymous accounts. In the paper An Efficient Electronic Payment System Protecting Privacy

[14] the process is described as follows:

A bank is responsible for maintaining two kinds of accounts. A Personal account, which is thenormal type of account, associated with an identifiable customer and Anonymous accounts,

where the identity of the owner is unknown.

The authors have devised a set of protocols which allow a customer to move money from their

personal account to an anonymous account.

An anonymous account is opened by a party requesting the account from the bank without showing

any credentials. The bank will permit accounts to be opened by any party.

In order to move funds from the personal account into the anonymous account the customer will use

a blinded withdrawal technique. They will, firstly, withdraw the money using a blinded coin

technique before anonymously depositing it into their anonymous account.

When the customer wishes to make a payment they identify themselves to the bank as the owner of

a particular anonymous account (each such account has a unique secret key attached to it) and they

authorise the funds transfer into the recipients account. The payee can be allowed to hear the on-

line request and confirmation and thus they will know that the transaction completed.

This system ensures the anonymity of the consumer. However, if the same anonymous account was

to be used for multiple transactions it would be possible to trace a consumers activities. Therefore,

anonymous accounts should be used as one-time accounts and thrown away after eachtransaction.

It is worth considering why the consumer needs to re-deposit the money back into an anonymous

account if they have managed to withdraw it using a blinded coin. The authors note a subtle

difference:

In our proposal, the account number is chosen by the bank during the anonymous account

opening phase, while in [blinded coin systems] the generation of a blinded coin preceding

the withdrawal does not necessitate the intervention of the bank. [14]

This is an important, but subtle difference. The anonymous bank account system only requires the

Bank to maintain an online database of currently open anonymous accounts (the not-yet-spentpayments). This database is likely to be of a manageable size which makes the system practical.

Frustratingly, the paper does not state whether they think that this means that a blinded coin system

would require a database of an unmanageable size as it would be helpful in deciding which the

better system is. However, we may infer that the difference in the data storage requirements is the

difference between storing a list of all coins ever generated to ensure there are no collisions (the

blinded coin system) and just storing the account numbers currently active (the anonymous account

system).

8/2/2019 10.1.1.94.7157

11/18



Trust

In order for electronic commerce over public wide area networks to become accepted it must

provide the same level of accountability as a traditional paper transaction does.

One important factor in commerce transactions is the ability to hold a particular party accountable

for a transaction. In an electronic transaction such accountability includes the ability tounambiguously prove the association between users and their messages. This is usually done

through the use of public key based digital signatures and hash based checksums.

In his paper Accountability in Electronic Commerce Protocols Kailar [12] suggests that we need

to define belief in the digital context. He suggests that there is a difference, with respect to

accountability, between beliefs and proofs. In simple terms, an individual is said to believe a

statement if he is convinced of that statement. (In principle) An individual can prove a statement

to another individual if he can convince the latter about the statement.

What does this mean for electronic commerce? Firstly, our digital transaction systems must contain

mechanisms to support the concepts ofbeliefandproof.

The concepts of belief and proof have interesting applications in the case of encryption. The

problems are different for symmetric and asymmetric encryption. For example, using symmetric

encryption:

If Alice and Bob share a secret key, and if Bob receives a message encrypted with this key, he

can believe that Alice sent this message (if he has not sent it himself), but cannot prove this to a

3rd party (e.g., a court of law), unless Bob is trusted by the 3 rd party not to fake a message using

the shared key and hold Alice responsible for that message. [12]

Note however, that for asymmetric encryption:

such an assumption of trust would not be necessary if Alice were to digitally sign the message

using her private key of an asymmetric key pair [12]

Of course, we should not trust Alice entirely if she is using asymmetric encryption because she

could intentionally compromise her own private key.

In order to trustprincipals in these sorts of digital transactions, we need to ensure that we are able to

hold them accountable for any messages signed with their keys until the fact that a key has been

compromised has been made suitably public.

It is for this reason (and for reasons of speed) that the current best practice in cryptographic

systems is to use an asymmetric cipher to setup a session key which is then used in a symmetrically

encrypted session. [10] Using this technique, assuming of course that Alice and Bob trust their

software, they ought to be able to pass a message between each other whilst trusting its origin.

8/2/2019 10.1.1.94.7157

12/18



Initial Trust

The biggest problem for electronic payment systems is establishing an initial trust between the

parties. Once the initial contact has been made further foundations can be built.

As previously discussed, the existing mechanism for deciding which online retailer a consumer

wishes to entrust with their credit card details is entirely arbitrary. A study by Cheskin [18]investigating the concept of trust as it relates to e-commerce on the World Wide Web identified six

fundamental forms, mostly related to corporate image that communicated trustworthiness.

The Cheskin report surveyed 463 Web users and a wide range of experts in the worlds of e-

commerce, Web site development and academia. It found that:

Brand, navigation, fulfilment, presentation, up-to-date technology and the logos of security

guaranteeing firms constitute the essential formal characteristics of Web sites that

communicate trustworthiness to visitors.

They also found that trust is a value which changes over time. Cheskin concluded that: E-

Commerce Trust Begins in Chaos and Ends in Trustworthiness

Consumers see the world of the Web as one of chaos, offering both possibilities and

threats. Only after they believe they have secured control over their own personal data

within the system, are they willing to begin to try out e-commerce. While trust develops

over time, communicating trustworthiness must occur as soon as interaction with a site

begins. [18]

Finally, and perhaps most importantly, the Cheskin study found that consumers expect their e-

commerce experience to be very similar to a traditional shopping experience. For example, they are

happier buying traditionally mail-order orientated products via the web than they are buying fresh

fruit and vegetables. Consumers also apply their typical preferences, particularly with respect tobuying from particular vendors and buying particular branded produce, presumably because they

believe that this will ensure quality i.e. they have greater trust in familiar items.

In their 1997 paper [13] The State of the Art in Electronic Payment Systems, the authors discuss a

number of different mechanisms for achieving trusted authorisation. Surprisingly, for a paper

entitled the state of the art, the first suggested authorisation method is a traditional out of band

authorisation using the telephone or fax confirmation.

It therefore seems likely that this trend will continue. We will need to maintain a small number of

central bodies which are trusted by consumers and retailers equally. Its likely that organisations

such as Banks (HSBC Group, Royal Bank of Scotland Group, Barclays), Credit Card processors(e.g: Visa, MasterCard), Governments and other digital trust companies (e.g.: Verisign) will prevail

in this area by certifying (probably through some physical process) consumers and vendors before

they can operate in a digital market place. (Again, we can see parallels in the traditional world. For

example, a consumer cannot have a credit card until they are 18 and they must ask a bank to trust

them before they are issued with the card, buy their bank.)

The paper goes onto to suggest that in order to have properly secure systems we need tamper proof

hardware at the payers end. For example, every user will require a smart card containing their

personal digital certificate which can then become an effective party in a SET transaction. The

advent of mobile phone and wireless network technologies (e.g. Bluetooth) which would allow your

phone to talk to a nearby computer or point of sale teller might provide a mechanism for a secureelectronic wallet.

8/2/2019 10.1.1.94.7157

13/18



Non-repudiation of digital transactions

If a party was to repudiate a transaction they would refuse to recognise it as a legally binding

contract or debt. Clearly, in electronic transactions it is especially important to ensure that

transactions are non-repudiatable because, in a digital world, there is no equivalent of a firm

handshake and steady eye contact.

There is currently no legal basis for non-repudiation of digital transactions. This is however because

there are no laws in either the US or UK on the subject (neither statute nor case law) rather than

because there is no technical basis for non-repudiation.

The SET protocol uses a triangle of authenticated digital certificates to create digital signatures

which are recognised by all three parties. This does, at least, provide a technical basis for non-

repudiation.

In their paper Repudiation in the Digital Environment, McCullagh and Caelli investigate what the

term non-repudiation really means in the current legal and crypto fields of understanding. It

appears that governments and lawmakers are confused about the implications of digital signatures

and their repudiation.

For a traditional pen and ink signature a signatory can always repudiate their signature for one of

a number of reasons4. If a signatory chooses to repudiate their signature then the responsibility falls

on the party which wishes to rely on the signature to prove its validity.

In the crypto-technical sense to be non-repudiatable means that the authentication can be

deemed genuine with a high level of confidence and that it cannot be subsequently refuted.

This is an important and subtle difference. A traditional signature can be refuted after it has beenrelied upon; however, in the digital environment this right is effectively denied:

That is, if a digital signature is verified so as to identify the owner of the private key that

was used to create the digital signature in question then it is that person who has the onus of

proving that it is not their digital signature. [17]

The problem with having an onus of proof in a digital environment is that, without a trusted

environment, it would be very difficult for either party to prove whether a signature is valid or not.

There is no equivalent of a witness in the digital system. The proposed solution is to make use of

trusted hardware:

A trusted computing system performs in accordance with its documented specification and

will prevent any unauthorised activity. Specifically a trusted computing system can be reliedupon to enforce a documented security policy. [17]

An example of a trusted piece of hardware is a banks "pin pad" (used to enter pin numbers and

provide authorisation to a retailer) which would be an integral part of the traditionally highly trusted

point of sale systems. The use of trusted systems resolves problems associated with the theft of

cryptographic keys and the possible penetration of viruses into consumers on, presumably less well

managed computer systems.

The benefit of using trusted hardware is that the hardware can provide a secure signing mechanism

and prevent unauthorised access to the signers private key. Presuming the trusted hardware has

4 The signature is a forgery or; The signature is not a forgery, but was obtained via: (a) unconscionable conduct by a

party to a transaction, (b) fraud instigated by a third party or (c) undue influence exerted by a third party.

8/2/2019 10.1.1.94.7157

14/18



been verified to prove that it only provides the required function and no other, it can then be the

basis for the implementation of the common law position (that the onus of proof of a valid signature

rests with the party reliant on the signature and not the signer).

The paper [17] concludes that:

If a trusted computing system is used to affect a digital signature, then and only then can

the onus of proof lie with the recipient in the same manner that exists in the paper-basedworld. Without a trusted computing system, neither party - the signer or the recipient - is in

a position to produce the necessary evidence to prove their respective case.

As discussed in the previous section, initial trust, it is clear that for digital signatures to become

widely adopted we require an easy to use trusted hardware platform, in the form of digital wallets

attached to our mobile phones, or smart cards inserted into electronic point of sale systems, through

which we can easily affect a digital signing, before we can accept main stream electronic

transactions.

So far, we have highlighted the need for a third party to provide mediation for the digital signing

process if we are to have a legal basis for non-repudiation. A non-repudiation service is required toprotect the parties in a transaction against the other party denying that a particular event or action

took place, or indeed that a particular signature is valid.

Two researchers, Zhou and Gollmann have investigated what is required to provide a fair and

efficient non-repudiation protocol [16]. They argue that Non-repudiation is one of the essential

security services in computer networks and that there are typically two applications for such a

service:

1. Non-repudiation of Origin (NRO) provides the recipient of a message with evidenceabout where it the message came from. This protects against the sender denying they sent it.

2. Non-repudiation of Receipt (NRR) provides the sender of the message with evidenceabout who has received the message. This protects against the recipient denying they

received it.

In a good non-repudiation protocol there should be methods for evidence gathering to support these

two important functions.

Their paper also highlights two further properties of a good non-repudiation protocol. Firstly, it

must ensure that the work load of the trusted third party is very minimal and that the trusted third

party will only be involved in the case that one party cannot obtain the expected non-repudiation

evidence from the other party.

The idea is that, because a trusted third partys (TTP) involvement might be expensive or time

consuming, they should be a mechanism of last resort. Normally, both parties (Alice and Bob)

would exchange both the message and the non-repudiation evidence directly. However, if either

Alice or Bob failed to pass a bit of the evidence to the other party then the TTP could be called

upon to verify the digital signatures of the messages, their labels and the available evidence of

origin/receipt with a view to verifying the complainants claim.

8/2/2019 10.1.1.94.7157

15/18



Current Progress

In this paper we considered a brief overview of a number of the topics, issues and points of view

related to the problems of securing electronic transactions. We have seen that much work towards

providing a complete solution has already been done.

There are already well proven technologies to support the security of digital transactions. There areminor improvements that can be made to them which will help them scale effectively. However, a

lack of encryption technology is not the problem.

Certain techniques, particularly those which would provide widespread digital cash and secure

online purchasing, such as the use of blind signatures and anonymous accounts, the SET protocol

and the widespread use of public key systems are however, not well developed in the consumer

world. They remain difficult to use.

It seems that this is largely because the complexity of these systems is not, at present hidden from

the end users. In much the same way that Alice and Bob are these days unlikely to understand the

engine in their family motor car, we need to embed the complexities of their digital wallets in a

black box, or more preferably, a slim patent leather one!

We need personal smart cards, trusted hardware and intelligent mobile payment computers

(probably embedded in our watches and mobile phones) which can do the computation for us in

order for them to become popular. We are not yet at the stage of Alice simply having to enter her

pass phrase into her mobile phone whilst standing at the checkout of Bobs general store in order to

complete the transaction.

We have also seen that we need to be careful when adopting these systems. We must ensure that

digital cash systems, when introduced, are anonymous and convenient. We must have banks thatwill support blind signatures and anonymous accounts. We also requiretrusted third parties to

provide non-repudiation services to verify and notarize the validity of parties signatures in

transactions.

Moving Forward

It seems that most of these issues are human issues and the adoption of the technology will, in

time, be driven by the high street banks and credit card issuers like Visa and MasterCard, the

mobile telephone operators and the marketing agencies. Its worth noting that these are the

establishments that have already earned the trust of the man in the street a significant and

necessary advantage.

In order to take the current technologies forward we need to identify which will bring end to end

trust. That is to say that we need to consider the whole purchasing process and not just the

encrypting and transmission of payment details. The need to make SET, a protocol designed with

these goals in mind, more efficient is clear.

We must also develop a system for Business-To-Business transactions which provides similar

safeguards as SET does for consumers. B2B transactions are typically of much higher values than

B2C ones and the market is much larger. The need for trust here is probably greater.

Finally, we need to develop low cost, large scale methods of providing people with wearable

digital signatures, so that they can authenticate transactions any place, any time.

8/2/2019 10.1.1.94.7157

16/18



My MEng final year project is addressing some of these issues by producing an efficient internet

based third party billing system which will allow an organisation to mediate between a supplier and

a purchaser and manage the credit relationship, for both macro and micro purchases. It is intended

that it should be (subject to the appropriate credit management facility being available) available to

all organisations, large and small as well as consumers.

ConclusionI have presented a number of different techniques, protocols and services which are designed to

provide (mostly financial) electronic transactions, greater trust, privacy and security when

conducted over public networks. I have also examined what the next steps are that need to be

taken in order to progress the much needed widespread adoption of these approaches.

Most of the remaining issues are non-technical. I hope that the organisations which already

command the trust and respect of the public (such as the banks and utilities) are able to encourage

the increased adoption of electronic transactions.

8/2/2019 10.1.1.94.7157

17/18



References

[1] D. Simon. Anonymous Communication and Anonymous Cash. In Crypto96, Springer Lecture

Notes in Computer Science (Vol. 1109), pages 61--73.

[2] M. Phoon, Hong Kong-IT Representatives Discuss Net Security,

http://www.cnnfn.com/digitaljam/newsbytes/117685.htm, October 10, 1998

[3] Charles Albrecht, Steve Malone, Bo He, Larry Bombard, An Analysis of SSL and SET for

Electronic Commerce. http://citeseer.nj.nec.com/252522.html

[4] N. Asokan, Philippe A. Janson, Michael Steiner, and Michael Waidner. The State of the Art in

Electronic Payment Systems. IEEE Computer, pages 28--35, September 1997.

http://citeseer.nj.nec.com/asokan99state.html

[5] Rivest, R.L., A. Shamir, PayWord and MicroMint: Two Simple Micropayment Schemes.

RSA '96 conference, Security Protocols Workshop, pages 69-87, 1996.

http://citeseer.nj.nec.com/rivest96payword.html

[6] C. Allen and T. Dierks. The TLS Protocol Version 1.0. Internet Draft, Internet Engineering Task

Force, November 1997. http://www.ietf.org/rfc/rfc2246.txt

[7] G Apostolopoulos, V Peris and D Saha. Transport Layer Security: How much does it really

cost? In Proceedings of the IEEE INFOCOM, 1999 http://citeseer.nj.nec.com/apostolopoulos99transport.html

[8] Carl Eric Wolrath. Secure Electronic Transaction: a market survey and a test implementation of

SET technology. Sep. 1998 http://www.wolrath.com/set.html

[9] Nikki Goth Itoi. PROMISES, PROMISES What ever happened to SET? 1999.

http://www.versaggi.net/ecommerce/articles/set.htm

[10] Garrett, Paul B. Making, Breaking Codes: An Introduction to Cryptography. Prentice Hall,

2001. ISBN 0-13-030369-0.

[11] An Introduction Course to Elliptic Curve Cryptosystems

http://www.ge.kochi-ct.ac.jp/~takagi/crypto/

[12] R. Kailar. Accountability in electronic commerce protocols. IEEE Transactions on Software

Engineering, 22(5), May 1996. http://citeseer.nj.nec.com/kailar96accountability.html

[13] N. Asokan, Philippe A. Janson, Michael Steiner, and Michael Waidner. The State of the Art in

Electronic Payment Systems. IEEE Computer, pages 28--35, September 1997.

http://citeseer.nj.nec.com/asokan99state.html

[14] J. Camenisch, J-M. Piveteau, and Stadler M. An efficient electronic payment system protecting

privacy. In Computer Security --- ESORICS'94, (LNCS 875), pages 207--215. Springer-Verlag,

1994. http://citeseer.nj.nec.com/camenisch94efficient.html

[15] Chaum, D., Achieving Electronic Privacy, Scientific American, August 1992, pp. 96-101.

http://ntrg.cs.tcd.ie/mepeirce/Project/Chaum/sciam.html

8/2/2019 10.1.1.94.7157

18/18


[16] Jianying Zhou and Dieter Gollmann. "An Efficient Non-repudiation Protocol", Proceedings of

the 1997 IEEE Computer Security Foundations Workshop (CSFW 10), (IEEE CS Press), pp. 126--

132, 1997. Preprint http://citeseer.nj.nec.com/article/zhou97efficient.html

[17] Non-Repudiation in the Digital Environment by Adrian McCullagh and William Caelli

First Monday, volume 5, number 8 (August 2000),

http://www.firstmonday.dk/issues/issue5_8/mccullagh/

[18] eCommerce Trust Study. Cheskin Research and Studio Archetype / Sapien. January1999

http://www.cheskin.com/think/studies/ecomtrust.html

[19] The MD5 Message-Digest Algorithm. Internet Request for Comments 1321. R. Rivest. April

1992.http://www.ietf.org/rfc/rfc1321.txt

10.1.1.94.7157

Documents

Transcript of 10.1.1.94.7157