You are on page 1of 18

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 1 of 18

A survey of current techniques and issues surrounding the security of electronic (financial) transactions.
Abstract
In this paper we discuss the current techniques and technologies being used and developed in the software 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 a legitimate 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

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 2 of 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 issuing them. 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 key user requirements in electronic commerce as being Security, Privacy and Trust. [3] We shall consider these in order.

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.
Peter Gradwell (pjg7) Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 3 of 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 Security


The 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 SSL technology 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 establishing TLS 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 testing plan.) 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 the cost 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.
Large Scale SSL users typically use dedicated hardware to speed up the public key transactions, such as those by NCipher (http://www.ncipher.com/).
Peter Gradwell (pjg7) Peter Gradwell 2001
2

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 4 of 18

2. They also suggest that certificates could be cached by the client. The removes the need for the server 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 server generate 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, they argue 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 it is 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 identifier block 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.

This technique of changing the private key every 30 minutes only works if the data you are securing does not need to be valid for longer than 30 minutes. If the data needs to be kept secure for longer then the length of the private key needs 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.
Peter Gradwell (pjg7) Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 5 of 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 to develop 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 somewhat unspecified 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 many technical 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 expensive when 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 of signing 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]

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 6 of 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 test of 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 hard mathematical problems. Two techniques have stood the test of time. 1. The factorisation of large integers into prime numbers. Essentially, whilst it is easy to generate two 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 hard task. Garrett, 2001 [10], states that: Fix a modulus m and integers b,c. An integer solution x to the equation bx c mod m is a (discrete) logarithm base b or c modulo m. It is important to know that for random m, b and c there may be no such x. But, for prime modulus p and good choice of base b there will exist a discrete logarithm for any c not divisible by p. Therefore, when p 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 points P and Q on the curve, find a number k such that Q= kP. k is called the discrete logarithm of Q to the base P. When P and k are large, it is computationally difficult to determine k from P or 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.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 7 of 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 detecting forged 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 and verification, 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.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 8 of 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 in the 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 be able 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 the transaction 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 logarithm of 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 and personal preferences.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 9 of 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/3 power [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 been spent 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.
Peter Gradwell (pjg7) Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 10 of 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 the normal 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 online 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 each transaction. 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-spent payments). 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).

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 11 of 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 to unambiguously 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 of belief and proof. 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 3rd 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 trust principals 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.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 12 of 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 ecommerce, 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: ECommerce 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 ecommerce 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 to buying 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 secure electronic wallet.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 13 of 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 nonrepudiation. 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 been relied 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 relied upon 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
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.
Peter Gradwell (pjg7) Peter Gradwell 2001
4

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 14 of 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-based world. 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 to protect 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 evidence about 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 evidence about 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.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 15 of 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 are minor 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 that will support blind signatures and anonymous accounts. We also require trusted 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.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 16 of 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.

Conclusion
I 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.

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 17 of 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

Peter Gradwell (pjg7)

Peter Gradwell 2001

SEM10 Survey Paper The Security of Electronic (Financial) Transactions

Page 18 of 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

Peter Gradwell (pjg7)

Peter Gradwell 2001