Print

Secure electronic transactions (SET) in e-commerce

Written by Peter Davies on .

This report has been prepared to critically examine the various techniques and protocols for providing a secure method of electronic communication with an aim to making electronic commerce a more viable concept. By examining present e-commerce practices, this report will demonstrate how Secure Electronic Transaction (SET) as a protocol will enable businesses and end-users to make payments online with the assurance that security was a main design requirement. Using modern cryptographic, certification and authentication techniques, this report will identify using an introduction to the SET protocol how in the future transactions will be secured.

Introduction

In the year 2000 it was estimated that 384 trillion dollars [1] was transferred electronically throughout Europe alone. Although this is an enormous figure, retail electronic commerce (e-commerce) barely generates a quarter of a percent of this global sales amount. Despite the dotcom bomb failure of the late nineties, a steady increase in the number of users online resulted in a huge surge of electronic purchases which could mainly be attributed to the fact that we now have fifty-five percent (12.9 million) of Britains households connected to the Internet [2]. The same National Statistics Omnibus Survey reported that sixty-three percent of people aged 25 to 44 had bought or ordered goods, tickets or services online.

As well as this mammoth increase, as users of a global community, they are becoming more and more aware of security threats to themselves, and more importantly, the security of the information such as credit card details they leave with online retailers (e-tailors). Deloittes 2004 Global Security Survey [3] revealed that eighty-three percent of survey respondents acknowledged that their systems had been compromised in the past year, compared to thirty-nine percent in 2003. Furthermore, forty percent of respondents whose systems were attacked said they sustained financial losses.

To demonstrate the reality of these statistics, more and more businesses are converting their legacy sales systems to more bleeding-edge online equivalents. As a result, web application development techniques must be implemented to create a visual front-end to these shops. Whether or not the developers know of the flaws they introduce, it is difficult to manage a myriad of open source products such as the Secure Socket Layer protocol (SSL) over which they have no direct control, and in some cases, no understanding of how it works.

The present-day common protocol for secure online communication is Secure Socket Layer (SSL) which in its simplest form provides end to end encryption between browser and server. The majority of household users are not aware of this protocol but understand that when the browser has a padlock in the bottom right-hand corner their transaction is secure. The problem with this protocol is not with its design, more with how it is applied on the Internet. Take for example the scenario of an online merchant selling some products. On purchasing one of these products, the merchant believes that the credit card details they obtained will be captured and processed securely, but at no point can the merchant prove that a user has entered their own card details. The merchant also cant guarantee the security of the machine that contains the credit card details. This is the basis of the principles behind Secure Electronic Transaction (SET); aiming to create a standardised mechanism for secure electronic commerce.

Secure Electronic Transaction as a series of protocols has been designed to introduce non-repudiation into a SSL style environment, that is, to solve the problem of proving a single user instigated an action through a clear audit trail. In a more generalised sense, Merkow, Mark S., Jim Breithaupt, and Ken L. Wheeler in their book Building SET Applications for Secure Transactions (1998) describe how this new technology will affect our lives:

Secure Electronic Transactions (SET) will help make the new "industrial revolution" a reality in the 21st century, this time without smokestacks or assembly lines

and now provides the mechanism to unleash explosive and unlimited global commerce the likes of which the world has never before seen.

The rest of the report has been divided into sections covering areas of general security on the Internet, current protocols and authentication techniques. It then finally discusses SET with aim to provide a general introduction to the protocols involved for anybody wishing to learn more about the subject. The main objective of this report is to develop a greater understanding of SET and its position within todays e-commerce infrastructure, and as a result it will need to highlight the technologies presently required to make secure electronic transactions on the World Wide Web.

Why do we need web security

More and more businesses are deciding to complete electronic transactions online, whether through bank facilities or simply selling goods online. Each transactional situation should have a risk assessment carried out within the organisation to discover areas of risk and potential security loop holes that may cause harm to the company. Within this assessment, risk should be weighed against the potential cost of a security incident/breach, and thus this now introduces two levels to risk assessment:

  1. What do we protect against?
  2. What are the possible consequences?

As commented earlier, potential risks must be weighed against its consequence, for instance it would not be feasible to secure an online shopping cart system if the cost of securing the item outweighed that of the potential security breach, thus it may not be feasible to protect. But in reality, security breaches are whole business problems and for an online shop to be compromised and credit details lost, would as a result be detrimental to the reputation of the organisation.

One generally accepted approach to follow is suggested by Fites, et. al. [Fites 1989] and subsequently summarised by the 1997 Site Security Handbook (RFC2196) that includes the following steps [4].

  1. identify what you are trying to protect
  2. determine what you are trying to protect it from
  3. determine how likely the threats are
  4. implement measures which will protect your assets in a cost-effective manner
  5. review the process continuously and make improvements each time a weakness is found

Under every circumstance the organisation should base their objectives around the concept of authorisation, which is describing who is allowed to access what and in what manner [5]. This concept of authorisation is drawn from the CIA model, which has been developed from a need for standardisation. Its three main sections that describe its acronym are [6]:

Confidentiality protecting information from unauthorised access and disclosure

Integrity safeguarding the accuracy and completeness of information and processing methods

Availability ensuring that information and services are available to authorised users

Only after understanding the weaknesses within the current e-commerce system, can we develop new protocols and authentication techniques to counteract the threats. Thus, after understanding and applying the CIA trust model it is possible for a business to determine which security architecture to implement. The protocols and non-repudiation characteristics of these technologies will be examined later in this report.

There are basically nine different threats to security on the Internet as identified by numerous security experts [i]:

  1. Denial Of Service preventing access to a particular system
  2. Eavesdropping listening to a particular transmission
  3. Masquerade pretending to be someone else
  4. Modification using a combination of 1,2,3 to change data
  5. Traffic Analysis monitoring how much data is transferred
  6. Replay transmitting multiple copied packets
  7. Repudiation claiming you never sent anything
  8. Social Engineering attacking the weakest element, humans
  9. External Factors poor programming, protocol design

The Internet is particularly vulnerable from, or can facilitate, the majority of the above threats due to the inherently insecure nature of the Internet Protocol (IP). The data within a datagram (including the header information) is sent in plain text and at the same time the information within a datagram is never validated therefore you cannot prove a particular user sent any specific piece of data. The Internet Protocol and its specific relevance to e-commerce will be described later in this report.

Security Vs Availability

When developing web applications such as shopping carts, the developer and the client need to agree at which level they are willing to accept that there is a conflict between the business requirements and the security requirements. In essence one must take precedence over the other, where the agreed trade off is the decision on which one of these should take precedence and why.

An example of security versus availability in the context of this report is the downtime of the server running the shopping cart application. If a user tries to access the resources that it needs but these are not available due to downtime, then the business could start losing clients because the service they seek to access is not available. Because the Internet provides 24 hour business access from anywhere in the World it is likely that these clients would then go elsewhere to obtain the service they require.

For a company to deploy a security infrastructure it needs to take in to consideration many factors that may affect its business. If too much emphasis is placed on the security of a web-based application, availability could then become an issue, but the aim of such protocols such as SSL (secure socket layer) or SET (secure electronic transaction) is to introduce a mechanism for compromise. If the security of the transmission between the server and the users browser is secured using encryption, businesses can then concentrate on maintaining availability.

When implementing security into web applications we need to ask what affect the new security infrastructure will have on the business operation. Case in hand, will it affect the networks in terms of service or working practices? For example with a payment infrastructure in place, you now have a single point of failure, a target which if it were attacked, would prevent the business from operating. At this stage you would be considering redundant servers, with advanced Intrusion Detection Systems (IDS) to help identify potential security threats. If the payment gateway is external to the organisation, such as with a third party, the business would need to examine the Service Level Agreement (SLA) to determine what assurances are given in case the payment gateways own systems are attacked (for instance, a denial of service attack).

Available Protocols & Authentication Techniques

Existing Infrastructure

At the beginning of this report it was identified that businesses should use risk assessment and as a result we need to consider a range of solutions that could solve the problems identified. By taking into account all the solutions available it will be possible to assess each one based on its strengths and weaknesses and how it may or many not fit within an organisations structure.

Using the distinguishing factors of each solution it would become easier to see how it could be applied within an organisation. For example, the following three scenarios provide an overview of several current technologies:

  1. Choose Public Key Infrastructure (PKI) if you need the following facilities
  2. Choose SSL Digital Certificates if you need
  3. Choose SET if you need

Whether or not a new technique is developed for creating a secure means of purchasing goods online, the system has to be built on a pre-existing network infrastructure called TCP/IP.

TCP/IP is a suite of data communications protocols developed around the idea of world-wide communication. Based on the ISO-OSI seven layer model of allowing application software to communicate on different system architectures, the data is sent down the stack when it is sent to the net, and then up the stack when it is being received from the network (see diagram on following page). As a result, any e-commerce payment structure must be capable of using the same network infrastructure for its end-to-end communication.

All software that is run on an operating system uses the application layer for communication. So for purchases online using any of the suggested techniques: PKI, SSL or SET, requires the use of the existing TCP/IP protocol suite.

As you can see from the above diagram, the TCP model is difficult to map to an existing model, especially as it is constructed with only four layers.

When the International Standard Organisation (ISO) developed the Open System Interconnect (OSI) model, they had hoped that it would be adopted as the standard, but the TCP/IP system had already been implemented by the American Department of Defence with an aim to provide interconnectivity over adhering to rigid model requirements.

The main difference between the two standards is that TCP/IP cannot guarantee that the data sent will in fact arrive at its destination. To solve this issue, a subsequent protocol called the User Datagram Protocol (UDP) was added to the suite to provide application level communication.

Internet Protocol

Internet Protocol (IP) is a connectionless protocol in that the datagram is constructed and sent, and the sender has no idea whether it was delivered correctly (as this was a subsequent development of the Transmission Control Protocol).

Each level within a datagram has a header (above diagram). With IP, this header has many fields but the most significant are the following that allow routers and switches to direct the transmitted data to and from its destination:

  • Source IP address
  • Destination IP address
  • Datagram ID
  • TTL (time to live)

The current IP protocol is running at version 4 providing several billion IP addresses, but as the growth of the Internet has increased exponentially over the past few years, a new solution to solve this issue is to be introduced. The IPv6 development has been introduced to solve some of the flawed entries of the previous version. It provides streamlined headers removing some of the more superfluous fields and replacing them with additional support for packet routing, and now with extended address reservation for IP addresses up to 128bits long. This is a substantial increase from version four which contained several unused fields and support for only 4,294,967,295 unique addresses. The most important addition to this new version is the built-in security for authentication and encryption solving the previous versions lack of non-repudiation support. Unlike the present version, IPv6 provides a facility for encryption prior to generation of the authentication data in the header field. This is achieved using Cipher Block Chaining (CBC) which is part of the Data Encryption Standard (DES).

Transmission Control Protocol

The Transmission Control Protocol (TCP) is a connection-orientated protocol using handshakes to initialise communication using flow control for data transfer. Data is streamed after a data connection is made, and then it utilises sliding windows techniques to transport data. Each packet that is transmitted across a network contains a sequence number so that it is easy to acknowledge the receipt of one packet, and thus determine if any packets are missing and need retransmitting.

As can been seen by the diagram on the previous page, TCP packets are encapsulated in the IP payload, and with each layer you also get a header. For TCP the header is used to direct data to specific ports for particular applications.

Transport Layer Security Solutions (SSL / TLS / PCT)

As discussed previously, the present version of IP provides no direct encryption process as a result Netscape published the first implementation of Secure Sockets Layer (SSL) back in 1996 [7]. At the time of release, Netscape were the leading web browser vendor and subsequently SSL became the industry standard. The final release of SSL was version 3, at which stage it was released as an open standard so that it could be improved upon by the Internet community.

Not wanting to be left out of the browser market, Microsoft developed an incompatible proprietary protocol called Private Communications Technology (PCT) which was a direct challenge to SSL version 2. As Netscape were the dominant browser vendor at the time, the protocol never really took off, despite claims that it had much better security.

When SSL version 3.1 was released it became known as TLS version 1, and quickly adopted by all major browser vendors. For the purposes of this report, when SSL is discussed, the actual transport layer security being used would be the latest TLS version 1.1 [8].

Protocol Failures

The first item that many protocols fail to achieve is to enhance the procedures already in place. For example SET improves upon SSL in regards to transactions in almost every way; however it is still not widely used. The reason for this lack of adoption is because the infrastructure it needs to survive is complicated and needs third party assistance whereas SSL has an infrastructure already in place as it uses items that the Internet already possesses as its platform (browsers and web servers).

So a sound infrastructure is important, however the infrastructure also needs to be scalable so that it can be distributed across the Internet. For example this is why PGP (Pretty Good Privacy) as a certification protocol worked and has become a standard for both e-mail and general secure electronic communication. PGP only fails for e-commerce purposes because it uses what is classified as a web of trust; allowing any entity to certify another. This introduces little control over the structure of the trust model, and is why for e-commerce something hierarchal was developed. Further information on trust models appears in the certification section later in this report.

Additionally, the protocol must be vendor independent, for example S/MIME allows users to send email messages to other people regardless of their email client. PGP-Mime however is not supported by all clients and thus has not succeeded to gain common usage.

So we can see that certain attributes are essential to creating a good protocol, in particular:

  • adaptable infrastructure
  • scalability
  • non-bias to vendors
  • standards

As previously described, without some form of data encryption, the TCP/IP protocols communicate in plain text. Using software called a sniffer enables you to eavesdrop on network traffic. The diagram below showing a simplified view of this process.

The only solution to the above scenario is to implement SSL or IPSEC to encrypt network traffic. By encrypting the traffic it still wont avoid the possibility of a man in the middle attack, it will simply prevent examination of the data that is captured. To illustrate this further, if an attacker could break the encryption through a brute-force password crack, the data revealed would most likely be out-of-date, and therefore useless.

SET Secure Electronic Transactions

The following detail has been collated from three main sources to try and help explain how SET is implemented and to demonstrate which participants are involved.

The main criticism of this report topic is the lack of readable documentation on either the Internet or in printed form, but despite this brick wall, there were several useful resources I have found:

The first book Using SET for Secure Electronic Commerce written by Drew, Grady N. (1998) provides an extremely coherent description of the inner-workings of SET.

The second book Building SET Applications for Secure Transaction written by Merkow, Mark S., Breithaupt, Jim, and Wheeler, Ken L. (1998) gives a more technical approach to setting SET in a business environment.

The final source of SET related material was obtained from various lectures notes written by Young, Andrew (2001) at the University of Salford.

What is SET?

History

Originally SET was joint specification between VISA and MasterCard but there were also many other organisations involved in developing the infrastructure including Microsoft, IBM, Netscape and VeriSign. The SET project started development back in 1996 and was officially proposed as a standard in February that year.

Prior to the formal specification of SET, there were initially two contenders for the development of a secure method of transaction online. These separate developments were:

  1. Secure Transaction Technology (STT) developed by VISA and Microsoft in 1995
  2. Secure Electronic Payment Protocol (SEPP) developed by MasterCard, Netscape and IBM around the same time as STT

The main concern brought to attention by the Internet Engineering Task Force (IETF) was that the two systems were incompatible and that despite both claiming that they were open source, neither could be endorsed by the IETF because the standardisation process was performed outside their control. Finally, the banks forced the two groups to develop what we now classify as version 1.0 of SET, which itself was released on May 31st 1997.

Overview

SET is a protocol for allowing secure transactions to take place on the Internet. It is based on the idea that the merchant and the end-user dont directly transfer funds, but they use a third party (payment gateway). It provides a set of protocols and formats that allow users to securely use the existing credit card payment infrastructure on the Internet.

Defined by the SET protocol is a series of messages with content and format as specified by the Abstract Syntax Notation One (ASN.1) for communication between each of the participants. ASN provides a mechanism for describing the complex objects within the SET architecture, just like object-orientated programming (OOP) has helped enhance software development.

Versions of the Protocol

Version 1 of the protocol is discussed here; at the end of this report, various extensions will be examined, together with the proposed version 2 (which itself incorporates some of the extensions).

Requirements

Based mainly on business requirements, the IETF determined that for the SET protocol to work it should satisfy the following:

  • Confidentiality of payment and ordering information
  • Integrity of transmitted data
  • Authentication that cardholder is a legitimate user of the card account
  • Authentication that a merchant can accept credit card transactions
  • Open, vendor-independent and interoperable to protect all participants

The bullets above are primarily based around the CIA model discussed during the introduction of this report. Each point is fairly reliant on the use of digital certificates for proving a user is who they say they are. The following section will describe how simple certification works, and how trust models can be developed by understanding the relationships between each of the entities.

Certification Principles

A certificate is basically a signed statement that something is true, and in a technical sense provides the following facilities:

  • a document that is un-forgeable
  • a document that is tamperproof

As an Internet based technology, both SSL and SET use its principles for determining who wrote message during some form of communication (e-mail, website security).

The idea of having a certificate relies on the principle that you trust the entity that gives you a certificate. This reciprocates up a hierarchy with each Certificate Authority (CA) trusting the CA above them; this can be demonstrated in the diagram below.

What this diagram shows is that as the user we trust only the CA above ourselves (yellow circle), and by implication we do not trust the Other CA (green circle) because our own CA does not trust it (only the preceding CA in blue does). This type of rule is specified in a Certificate Practice Statement (CPS) which provides a meaning to the certificate describing how it is going to be checked for validity.

For example, a software tool called Pretty Good Privacy (PGP) provides a Public Key Infrastructure (PKI) capable of generating certificates that say we are who we say we are. In summary, a certificate is a signed statement that user X is the holder of public key Y.

One-way or Two-way Certification

Certification can work in two ways in regard to who trusts who:

  • One-way Certification
  • Two-way Certification

One way certification is used when you have two departments like in the diagram above. Each department has its own Certification Authority, providing digital certificates to the members of the department.

In the above example, the Computer Science CA has a higher level of security (as determined by the CPS). The ISelS department has been issued with a lower level of security, so we have what could be described as one-way certification, where by principle you do not certify any department with a lower security level than yourself.

What this implies is that User 2 can be cross-certified by the Computer Science CA, but User 1 cannot be certified by the ISelS CA because its CPA stipulates that it will not certify a user in a CA with a lower security level. In essence, it would not be upholding its agreement if it allowed its subscribers to become vulnerable in any way.

Two-way certification would work in a similar fashion but both CAs would have equal security levels, allowing both sides to cross-certify the other.

Certificate Revocation List (CRL)

Every CA has a list of revoked or withdrawn certificates which it signs itself. This list allows a user to check the validity of a certificate before accepting it or not. Often CRLs are updated approximately every 24 hours or using a protocol called Online Certificate Status Protocol (OCSP), the CRL is published and updated constantly so that a user can at any time query the list (online) and ask is this certificate valid now?. This means a user can make an instant decision on whether to trust a certificate or not.

X.509 Certificate Revocation Lists

X.509 is a specification for the format of a certificate and adds detail to a regular certificate that can hold various fields for storing information about the subject (user), and the certification authority (CA).

V3 of the X.509 standard provides extensions such as constraints on when and how the certificate can be used, for example, you have an extension called PATH_LENGTH (we will call this pl for short). This allows a CA to trust only the next CA along (when pl=0) or the next two (when pl=1). Any CA beyond the pl is rejected which provides an excellent means of controlling who in the hierarchy of trust can actually be certified.

Another extension is called NAME_CONSTRAINT and this allows instant checking on the name of certification authority to determine certification rights.

SET in Detail

Participants

Having briefly explained the requirements of SET, it is essential to understand the roles of the individual participants within the process as described by Drew (1998).

Card Holder

In SET, the card holder is the same as any normal person wishing to use their card to purchase goods in a shop.

Merchant

This is the business that wishes to sell goods online, but unlike a normal shop the transaction would be electronic, with no customer physically present.

Issuer

The issuer is the organisation that provides the card holder with the payment card.

Acquirer

The acquirer is a financial organisation that processes the card holders payment card on behalf of the merchant. The purpose for which is to obtain payment authorisation from the issuer.

Payment Gateway

Working on behalf of the acquirer, the payment gateway processes the card, bridging the gap between electronic purchases and the existing credit card networks.

Certificate Authority

The certification authority provides a trust model for all participants, providing a mechanism for identifying who users say they are (see previous section).

The relationships of these participants can be better described using a diagram (below) showing the SET process against the traditional card not present (CNP) in dark orange.

Original source, Secure Electronic Transaction LLC

Software Components

As previously described, SET requires specific software components to allow all of the participants to communicate in a secure and efficient manner. For example, a user cannot physically swipe their card at the merchants request, so a digital wallet is created that perform this comparative behaviour. The specific software components are:

  1. the digital wallet the front-end for the card holder
  2. the merchant server the merchants SET software
  3. the certificate authority handles all of the SET participants certificates
  4. the payment gateway bridges the merchant with its acquirers legacy systems

The diagram below demonstrates where the software components sit in conjunction with the participants that were described on the previous page.

The diagram above represents the process described on the previous page mapped against the individual software components. In simple form this can be described as:

  1. the issuer provides the card holder with a wallet, thus certifying s/he is who they say they are
  2. the acquiring bank certifies that the merchant is who they say they are
  3. on making a purchase the information is sent to the gateway for processing, where payment is removed from the card holder and deposited in the merchants account

Hashing Principle

The best solution for signing a document is to create a fixed hash of the document which produces a block of cipher text. The user then signs the hash and it means that a signed summary has been generated. The chances of having two hash functions that generate the same output are very remote.

One problem with the hash function is that its susceptible to brute force attacks. Recent indications show that certain well-known hash functions (such as MD5) have been subsequently broken though cryptographic techniques that finds collisions (multiple hash values with the same message) within a given digest. [9]

There are various solutions to developing secure hash functions for the function of creating digital signatures. For example, the diagram below demonstrates that by taking several fields such as: user name, password, timestamp and a random number, you can generate a hash value that is pretty much impossible to reverse.

Making a Purchase

Without going into too much detail regarding the technical operations of the dual signature, SET basically separates the purchase and order information in a way that it is still linked and only the relevant parties receive what they need (need to know basis).

The client will send both purchase information (PI) and order information (OI) to the merchant, however the merchant cannot read the purchase information (which is viewable by the bank only), but knows its certified because of the dual signature message digest which is created for each of the following:

  • Purchase Information Message Digest (called a PIMD)
  • Order Information Message Digest (called a OIMD)

Using dual signatures, PI (payment information) is hashed together with the hash of the OI (order information) creating a POMD (payment order message digest).

So using the diagram above as an example, the merchant would receive:

  • Order Information, PIMD & Dual Signature (POMD)
  • The merchant would then use a PG (payment gateway) subsequently creating a PR (purchase request) see diagram below.

The order information is visible, so the merchant has what it needs, they cannot read the purchase information as the credit cards are secure and the transaction is linked together via the dual signature, so this offers non-repudiation facilities to all parties involved.

And in more detail we can see that in the diagram above, by using a combination of cryptography techniques specifically DES and RSA (Data Encryption Standards, and the public key algorithm developed by Rivest, Shamir, Adleman), the merchant will receive a Purchase Request (PR) which contains all the details required to determine the validity of the order.

SSL however does not offer any of these services, or any similar services, to buyers and vendors on the Internet. For example all transactions that occur between buyer and vendor only have one secure channel and that is between User and Merchant, the rest of the process is out of the hands of the individual as the merchant now has the relevant information to charge that individual. However it is at the merchants discretion how it deals with this contact to the bank, and how they store the details afterwards (ignoring what the Data Protection Act stipulates). Additionally with SSL we do not actually know who we are dealing with as the certificate could have been forged, or obtained through social engineering. [ii]

SSL creates a channel from A (Client) to B (Merchant) and authenticates and creates a secure channel between the two parties. However, how can A truly know who B is unless they know they are dealing with a reputable company with well known brand names such as Dell or say Amazon?

This is when SSL becomes potentially dangerous as its user centric trust model allows the user to make the choice of purchasing. Any merchant can be perceived to be trustworthy by social engineering of the perception (words such as Certified or Valid on the certificate). Additionally how can B be sure that A is not buying with a fraudulent credit card? With SET all parties are known and are trusted thus true authentication and non-repudiation facilities are in place.

Shopping Online with SET

As described by Drew (1998) in his book on using SET, the process of SET only addresses payment authorisation and transport, order confirmation and inquiry, and merchant reimbursements. For example, SET cannot deal with the process of goods delivery, nor cover the process of product selection on the e-commerce website.

Drew (1998) goes on to explain what areas of online shopping directly deal with SET (stages in bold are directly provided by SET, the others in italics are performed outside the SET protocol):

  1. Browsing and Shopping Using a shopping cart system, the user browsers the available products on the website and creates a virtual shopping basket of products.
  2. Merchant and Goods SelectionIf given the choice of multiple merchants offering similar goods, the user is given the option of shopping elsewhere.
  3. Negotiation and OrderingThe user selects the products the want and agrees that the selected price the merchant lists is acceptable.
  4. Payment Selection The user (card holder) selects their method of payment
  5. Payment Authorisation and Transport The messages used for the authorisation of payment from the card holder to the merchant are sent between the correct participants.
  6. Payment Confirmation and InquiryThe merchant or card holder can inquire about the status of a purchase.
  7. Delivery of Goods The merchant having taken an order and payment will ship the purchased products.
  8. Merchant ReimbursementThe merchant is reimbursed by the card holder.

SET Extensions

Elliptic Curve Cryptography

An Internet Draft document describes the concept of Elliptic Curve Cryptography (ECC) as:

Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments. Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.

Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, Transport Layer Security (TLS) Extensions, (September 2005)

Another issue is the potential for catastrophic failures when a single elliptic curve is widely used. [10]

In relation to SET, Drew (1998) explains that the RSA algorithm is replaced by the Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures, and the Elliptic Curve Encryption Scheme (ECES) for encryption. The combination of these components creates an extension to SET called Elliptic Curve Enabled Secure Electronic Transactions (ECSET).

He also describes there are multiple advantages when such technologies are introduced into the SET environment:

  • ECC keys are smaller than RSA keys
  • Digital signatures in ECSET are smaller

The security implications of an elliptic curve cryptosystem lies in the discrete logarithm problem, which is as closest you might get to a one-way function. [11]

Chip and PIN

For SET to function in a debit environment requires the merchant and the payment gateway to implement some new functions:

  • Personal Identification Numbers (PINs)
  • Integrated smart card technology
  • Elliptic Curve Cryptography (as above)

Having PIN verification introduces an extra level of card holder verification, just like the present Chip and PIN system, where the card holder must be present and supply the PIN at the requested moment during the transaction.

Biometrics

Using a similar principle to the Chip and PIN system, what I propose is that the users would now be given an electronic fingerprint reader for home / business / merchant use, which would replace the need for both a PIN and smart card. Having pre-registered their biometric details with a bank, this process acts like a digital wallet, with their fingerprint acting like a PIN.

The diagram above is representative of a possible infrastructure (on top of SET and SSL) designed to show how a user could be authenticated and verified at the moment of purchase.

Version 2 Details

SET version 2 was proposed by a company called SETco LLC (the detail of which was unavailable at the time of printing) that proposed the integration of several of the extensions previously explained. As described by Drew (1998) they include:

Functionality Enhancements

  • Smart cards
  • Debit (PIN system)

Encryption Alternatives

  • Algorithm independence
  • Hardware vendor support
  • Separate symmetric key from account information/li>

Certification Enhancements

  • Smaller certificates
  • Formatted registration forms

Order Enhancements

  • Multiple payment instructions (PI) on a single order
  • Order cancellation
  • Renegotiation of order description (OD)
  • Delivery receipt for electronic delivery

Payment Enhancements

  • Payment negotiation
  • Funds transfer
  • Purchasing card support
  • Travel agent business model
  • Merchant authentication prior to shopping

Transaction Processing Enhancements

  • Enhanced error messages
  • Reduced processing loads on applications

Non-repudiation Facilities

SSL - Secure Socket Layer

SSL does not support any form of non-repudiation. SSL was developed primarily to create a secure channel between two parties A and B, and was not invented to deal with credit card transactions; however, it has become the standard implementation on todays web browsers. Such is the level on non-repudiation offered by SSL that it would be very difficult for a merchant to prove in a court of law that the customer purchased the goods. It can however be enhanced to allow non-repudiation above the SSL layer, but this is not standard. This may seem to be a contradiction as SSL also uses digital certificates however these certificates are not issued by the bank, thus they cannot be linked with the credit card used, and unlike SET, SSL does not check the validity before completing the transaction.

SET - Secure Electronic Transactions

SET has non-repudiation facilities built into its architecture to allow customers, merchants and banks the ability to make sure that any party cannot repudiate what they have purchased or sold. Every part of the transaction is logged and an audit trail is created. All participants in the system are also known to each other and have to authenticate with one another. Unlike SSL, the decision on who and who not to trust is not user centric as each party knows who they are dealing with before hand, and when the transaction is going through measures are taken to link information with signatures.

Other Protocols

Specifically for e-mail communication, S/MIME offers non-repudiation of the origin again through the use of digital signatures. If a message is sent from Alice to Bob signed by Alices private key then Bob knows that the message was sent from Alice and only Alice. Alice can repudiate this saying that someone else stole her key and sent the message, and she revoked the key before the message was supposed to be sent. However, if it can be proved that the revocation came after the message was sent, then Alice would not be able to repudiate Bobs claims.

Conclusion

The introduction to this report stated that a Deloittes 2004 survey found that 40 percent of respondents whose systems were attacked said they sustained financial losses. The ASIS Online [12] organisation observes this loss of business and tries to address the issue by creating various guidelines aimed. They comment:

In an age when information is king, a companys very survival may hinge on its secrets.

If the developers of online e-commerce applications do not have the aptitude and awareness to make informed decisions regarding a companys security requirements, or a clear understanding of the organisations business, they cannot develop and implement effective sales systems that maintain customer confidence in the purchasing of goods form their online marketplace.

Needs of e-buyers and e-vendors

This is probably the biggest aspect regarding the contradiction between SSL and SET, and it lies with the wants and needs of both the buyer and merchants respectively.

SSL is now commonly used however it does not provide many of the aspects of functions that the buyer or vendor say is important for online transactions. SET was designed to take into consideration the security of both entities: the buyer and vendor.

SET does two things that are important to online transactions, and these are:

  1. Keeps Payment Information (PI) & Order Information (OI) separate but links them using a dual signature (concatenation of the two)
  2. Offers non-repudiation

In Terms of the Technical Details of the Protocol

SSL may not have been specifically designed to facilitate electronic transactions as its main aim was to secure communications from a client to a server; however it has evolved to become the protocol of choice when securing transactions. This protocol works on the transport layer of the OSI model and uses session keys known only to the client and the server thus creating a secure channel between the two.

SET is not actually a protocol as such but more of an application that mandates the algorithms that it uses, rather than allowing the user to choose as with SSL, which during the initial handshake hello, allows the user to specify what they are willing to use in terms of cryptographic algorithms (and at what key strength).

Due to the fact the SET is not a protocol and does not work within current technology additional items are needed to allow it to work and create secure electronic communications between customers and merchants. For example the client and the merchant must have additional software in order to communicate the payment and order details to each other and also the bank. This means it is not as freely available to consumers as SSL which is distributed by default in the majority of operating systems.

Not only do they have to download software, they will also be dependant on the merchant supporting SET. If this is the case then they will not be able to complete their purchase using their digital wallet.

Infrastructure required to support it

The SSL infrastructure is basically the web and its users; therefore the infrastructure needed to support its use is already in place. Any user with a web browser has the ability to conduct secure transactions with merchants willing to sell their products across the Internet. The emphasis of trust for this infrastructure is placed on the user; it is up to the user who they trust and who they do not, so the trust model can be classified as user centric.

Additionally, at the other end of the scale in regards to the merchants, the facilities are in place for them to buy digital certificates and have them signed by trust worthy CAs such as VeriSign [13], and then they can partake in secure transactions with customers. The communication between the banks and the merchant are done via traditional channels such as Card Not Present (CNP).

SET is different, as the current infrastructure would not allow for all the millions of credit card transactions to be supported. SET needs all parties to be a part of the infrastructure for it to succeed, from the client all the way through to the issuing bank. As previously mentioned, special software is needed to support the SET system and thus is not freely available to all web users, unlike SSL. So for SET to work on the Internet the following participants need to co-operate:

- Customers
- Merchants
- Banks
- Certification Authorities

These all have to work together to form a certain environment of trust in order for the infrastructure to work. Trust is not placed with the user as the system itself chooses who can and cannot be trusted by means of a trust hierarchy.

Application to Business

Most businesses will understand computer security from the concepts outlined in this report. They believe that security consists of a few firewalls and typically some virus protection for the mail. Threats and the increase in threat agents have now outgrown those simple defences.

As a result, businesses are now required to justify their security expenditure and activities through means of Return On Investment (ROI) to board level management. This leaves the businesses with three major problems [14]:

  1. to build a business case that non-technical staff and management will understand and support
  2. to determine the appropriate level of security for the company
  3. to show that there is a financial return resulting from the investment

This, of course, will prove very difficult to achieve as the security system implemented is non-profit making, and if working correctly, will simply lower fraudulent transactions. The added expense of spending money on the SET infrastructure will not be apparent to many executives especially when the majority of present-day SET implementations are for business-to-business transactions. It is still apparent that if the business does spend a great deal of money on a SET infrastructure, it has to be because their business model sells many high-value products (in the £10 - £20 range) to cover the over-heads of the SET system.

Explaining these security concepts to senior executives would be challenging, but as a recent article in Security Advisor Middle East7 on Return On Investment discusses, mental pictures and diagrams work well. Their suggestion is to use a castle-and-moat analogy, for example:

Explain that youre building a moat around a castle. Until you get the moat completely around the castle, youve spent a lot of money with no improvement in security.

Until youve established a minimum level of protection, youre spending a lot of money but are still totally vulnerable.

The analogy goes on to explain how digging a shallow moat and having it a mile wide is a waste of money. You would be spending a great deal of money and not getting any results in return. This is like a form of business insurance; it is necessary to spend money to insure against losses of material, fire or flood, or personal injury - everyone hopes it will never happen, but when it does the insurance policy offers some ability to offset the loss.

SET cannot guarantee absolute protection from online fraud, only minimising the damage, however, to get to this position requires expenditure by the organisation.

Summary

The original assignment question asked: At which point is the SET protocol used in a secure online transaction?

Only after completing the research that went into this report do you understand that SET describes the process of making a complete transaction, from the ordering of the goods to the final processing of your card details. Admittedly it overlooks the initial product selection and the final delivery, but as a transactional protocol it fulfils its job.

The only foreseeable weaknesses with SET are more to do with the supporting protocols that it relies on, such as IPv4, DES, MD5 and SSL. If a security flaw is found in one of the underlying protocols, SET can only be as secure as these subsidiary components.

The main criticism of this report topic is the lack of readable documentation on either the Internet or in printed form, but despite this brick wall you can lookup each of the individual components and derive where it would sit in the SET process. It also became apparent that the only two books available were both published in 1998 and that both technology and cryptographic techniques have improved dramatically in the past 8 years.

References

Bibliography

Blyth, A & Kovacich, G.L., (2001) Information Assurance [Book] Springer. [Page 99]

Comer D (2000), Internetworking with TCP/IP Volume 1 [Book] Publisher: Prentice Hall, ISBN: 0 13 018380 6

Drew, Grady N. (1999) Using SET for Secure Electronic Commerce. [Book] Publisher: Prentice Hall, ISBN: 0-13-099715-3

Dolan, A., (2004) Social Engineering [Online] SANS Institute. Available From: http://www.sans.org/resources/popular.php [Accessed 15th Oct 2005].

Denning, D. E., (1999) Information Warfare and Security [Book] Addison Wesley. Part 1: Introduction [Page 41]

De Carteret and Vidgen (1995), Data Modelling for Information Systems [Book] Publisher: Pitman, ISBN: 0-273-60262-4

Fraser, B., (1997) RFC 2196 Site Security Handbook [Online] NWG. Available From: http://www.faqs.org/rfcs/rfc2196.html [Accessed: 31 October 2005]

Teare D (1999), Designing Cisco Networks [Book] Publisher: Cisco Press, ISBN: 1-57870-105-8

Merkow, Mark S., Breithaupt, J, and Wheeler, K L. (1998) Building SET Applications for Secure Transactions [Book] 1st ed. Publisher: Wiley, ISBN: 0-471-28305-3

Mitnick, K. E., (2003) The Art of Deception [Book] Wiley. Chapter 16

Pressman R S. (1997), Software Engineering: A Practitioners Approach [Book] Publisher: McGraw Hill, ISBN: 0 07 709 411 5

SANS, (2001) Password Policy [Online] SANS Institute. Available From: http://www.sans.org/resources/policies/Password_Policy.pdf [Accessed: 3rd November 2005]

Siyan K (1998), Inside TCP/IP [Book] Publisher: New Riders, ISBN: 1-56205-714-6

Sommerville I (1998), Software Engineering [Book] Publisher: Addison Wesley, ISBN: 0 201 42765 6

Journals

What drives mobile commerce? Article: Information & Management, Volume 42, Issue 5, 1 July 2005, Pages 719-729, Wu, J.H.; Wang, S.C.

Marketplace and technology standards for B2B e-commerce: progress, challenges, and the state of the art. Article: Information & Management, Volume 42, Issue 6, 1 September 2005, Pages 865-875, Albrecht, C.C.; Dean, D.L.; Hansen, J.V.

Trust and e-commerce: a study of consumer perceptions. Article: Electronic Commerce: Research and Applications, Volume 2, Issue 3, 1 September 2003, Pages 203-215, Corbitt, B.J.; Thanasankit, T.; Yi, H.

Footnotes

[i] This list is a collaboration of lecture notes from Blyth, A and Young, A subsequently summarised

[ii] VeriSign issued two certificates to individuals claiming to be Microsoft by error - http://amug.org/~glguerin/opinion/revocation.html

[1] Global Payments Industry Metrics, 2000 & 2010 (March 2003) Statistics for Electronic Transactions [Online] ePayNews.com. Available from: http://www.epaynews.com/statistics/transactions.html [Accessed 16th Jan 2006]

[2] National Statistics (July 2005) Internet Access [Online] National Statistics. Available from: http://www.statistics.gov.uk/cci/nugget.asp?id=8 [Accessed 18th Dec 2005].

[3] Deloitte (2004) Global Security Survey [Online] Deloitte Touche Tohmatsu. Available from: http://www.deloitte.com/dtt/research/ [Accessed 14th Oct 2005].

[4] Fraser, B., (1997) RFC 2196 Site Security Handbook [Online] NWG. Available From: http://www.faqs.org/rfcs/rfc2196.html [Accessed: 31 October 2005]

[5] Denning, D. E., (1999) Information Warfare and Security [Book] Addison Wesley. Part 1: Introduction [Page 41]

[6] Blyth, A & Kovacich, G.L., (2001) Information Assurance [Book] Springer. [Page 99]

[7] Netscape Online (1996) SSL 3.0 Specification [Online] Netscape, Available from: http://wp.netscape.com/eng/ssl3/ [Accessed 10th February 2006]

[8] IETF Secretariat (2006) Transport Layer Security (tls) [Online] IETF, Available from: http://www.ietf.org/html.charters/tls-charter.html [Accessed 11th February 2006]

[9] Passcracking.ru (2006) Online Rainbow Tables [Online] Available from: http://passcracking.ru/index.php [Accessed 2nd February 2006]

[10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, (2005) Transport Layer Security (TLS) Extensions, IETF, draft-ietf-tls-rfc3546bis-02.txt (work in progress)

[11] RSA Security (2004) What is the dicrete logarithm problem? [Online] RSA Security, Available from: http://www.rsasecurity.com/rsalabs/node.asp?id=2193 [Accessed 4th Feb 2006]

[12] ASIS Online (2004) Chief Security Officer Guidelines [Online] ASIS International. Available from: http://www.asisonline.org/guidelines/guidelineschief.pdf [Accessed 11th Oct 2005].

[13] VeriSign (2006) VeriSign Security, Payments and Communications [Online] VeriSign. Available from: http://www.verisign.com/ [Accessed 29th Jan 2006]

[14] Security Advisor Middle East (2004) Selling Security to the Board [E-Magazine] Security Advisor Middle East, Issue 8 [Accessed 11th Oct 2005]