set cryptography and e-commerce

8/3/2019 SET Cryptography and E-commerce

1/37

Secure Electronic Transactionsin E-Commerce

Cryptography & Electronic Commerce

Due Date 13th

Feb 2006

Peter Davies B.Sc - 05004306

MSc Information Security & Computer Crime


2/37

University of Glamorgan Cryptography & Electronic Commerce

2

AbstractThis 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 besecured.


3/37


3

ContentsAbstract............................................................................................................................... 2

Contents .............................................................................................................................. 3

Introduction......................................................................................................................... 5Why do we need web security ........................................................................................ 7

Security Vs Availability.................................................................................................. 9

Available Protocols & Authentication Techniques........................................................... 10

Existing Infrastructure .................................................................................................. 10Internet Protocol........................................................................................................ 12

Transmission Control Protocol ................................................................................. 13

Transport Layer Security Solutions (SSL / TLS / PCT)........................................... 13Protocol Failures........................................................................................................... 14

SET Secure Electronic Transactions.............................................................................. 16

What is SET? ................................................................................................................ 16

History....................................................................................................................... 16Overview................................................................................................................... 17

Versions of the Protocol............................................................................................ 17

Requirements ............................................................................................................ 17Certification Principles ................................................................................................. 18

One-way or Two-way Certification .......................................................................... 19

Certificate Revocation List (CRL)............................................................................ 19X.509 Certificate Revocation Lists........................................................................... 20

SET in Detail................................................................................................................. 21

Participants................................................................................................................ 21Software Components............................................................................................... 22

Hashing Principle...................................................................................................... 23Making a Purchase.................................................................................................... 23Shopping Online with SET....................................................................................... 26

SET Extensions............................................................................................................. 27

Elliptic Curve Cryptography..................................................................................... 27

Chip and PIN............................................................................................................. 27Biometrics ................................................................................................................. 28

Version 2 Details........................................................................................................... 29

Functionality Enhancements..................................................................................... 29Encryption Alternatives ............................................................................................ 29

Certification Enhancements...................................................................................... 29

Order Enhancements................................................................................................. 29Payment Enhancements ............................................................................................ 29

Transaction Processing Enhancements ..................................................................... 29

Non-repudiation Facilities ............................................................................................ 30

SSL - Secure Socket Layer ....................................................................................... 30SET - Secure Electronic Transactions ...................................................................... 30

Other Protocols ......................................................................................................... 30

Conclusion ........................................................................................................................ 31


4/37


4

Needs of e-buyers and e-vendors.................................................................................. 31

In Terms of the Technical Details of the Protocol........................................................ 31Infrastructure required to support it .............................................................................. 32

Application to Business ................................................................................................ 32

Summary....................................................................................................................... 34

References......................................................................................................................... 35Bibliography ................................................................................................................. 35

Journals ......................................................................................................................... 36Footnotes....................................................................................................................... 36


5/37


5

IntroductionIn the year 2000 it was estimated that 384 trillion dollars1 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. Despitethe 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 Internet2. 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 Survey3

revealed that eighty-three percent ofsurvey 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, webapplication 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 Layerprotocol (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 issecure. 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 carddetails 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.


6/37


6

Secure Electronic Transaction as a series of protocols has been designed to introducenon-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 bookBuilding SET

Applications for Secure Transactions (1998) describe how this new technology willaffect 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 SETwith aim to provide a general introduction to the protocols involved for anybodywishing 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 secureelectronic transactions on the World Wide Web.


7/37


7

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 transactionalsituation should have a risk assessment carried out within the organisation to discoverareas 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?a. password disclosure leading to masquerade attackb. social engineering attacksc. theft of credit details

2. What are the possible consequences?a. loss of some businessb. loss of credibilityc. gain of liability

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 ofsecuring 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 includesthe following steps4.

1. identify what you are trying to protect2. determine what you are trying to protect it from3. determine how likely the threats are4. implement measures which will protect your assets in a cost-effective manner5. review the process continuously and make improvements each time a weakness is

found


8/37


8

Under every circumstance the organisation should base their objectives around theconcept of authorisation, which is describing who is allowed to access whatand in what

manner5. 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

:

Confidentialityprotecting information from unauthorised access and disclosure

Integritysafeguarding 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 wedevelop 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-repudiationcharacteristics 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 expertsi:

1. Denial Of Service preventing access to a particular system2. Eavesdropping listening to a particular transmission3. Masquerade pretending to be someone else4. Modification using a combination of 1,2,3 to change data5. Traffic Analysis monitoring how much data is transferred6. Replay transmitting multiple copied packets7. Repudiation claiming you never sent anything8. Social Engineering attacking the weakest element, humans9. 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 withina 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 specificrelevance to e-commerce will be described later in this report.

iThis list is a collaboration of lecture notes from Blyth, A and Young, A subsequently summarised


9/37


9

Security Vs Availability

When developing web applications such as shopping carts, the developer and the clientneed 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 takeprecedence over the other, where the agreed trade off is the decision on which one ofthese should take precedence and why.

An example of security versus availability in the context of this report is the downtimeof 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 thatthese 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 considerationmany 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 tointroduce 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 wereattacked, would prevent the business from operating. At this stage you would be

considering redundant servers, with advanced Intrusion Detection Systems (IDS) to helpidentify 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 gatewaysown systems are attacked (for instance, a denial of service attack).


10/37


10

Available Protocols & Authentication Techniques

Existing Infrastructure

At the beginning of this report it was identified that businesses should use risk assessmentand 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 assesseach 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

o non-repudiationo scalability

2. Choose SSL Digital Certificates if you needo secure online transactionso existing infrastructure

3. Choose SET if you needo secure online transactionso non-repudiationo integrity of transmitted data

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 applicationsoftware 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 forcommunication. So for purchases online using any of the suggested techniques: PKI, SSL

or SET, requires the use of the existing TCP/IP protocol suite.


11/37


11

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, butthe 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 applicationlevel communication.

Application

Presentation

Session

Transport

Link

Physical

Application

Transport

Network

Data

Link

OSIModelOSIModelOSIModelOSIModel TCPModelTCPModelTCPModelTCPModel

Consistofapplicationsand

processesthatusethe

Internet

Providesend-to-enddata

deliveryservices

Definesthedatagramand

handlestheroutingofdata

Consistsofroutinesfor

accessingphysical

networks

Network


12/37


12

Internet Protocol

Internet Protocol (IP) is a connectionless protocol in that the datagram is constructed andsent, 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 newsolution 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 forIP 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 andencryption 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).


13/37


13

Transmission Control Protocol

The Transmission Control Protocol (TCP) is a connection-orientated protocol usinghandshakes to initialise communication using flow control for data transfer. Data is

streamed after a data connection is made, and then it utilises sliding windows techniquesto transport data. Each packet that is transmitted across a network contains a sequencenumber 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 inthe 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 processas a result Netscape published the first implementation of Secure Sockets Layer (SSL)

back in 19967. 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 thetime, 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 isdiscussed, the actual transport layer security being used would be the latest TLS version

1.18.


14/37


14

Protocol Failures

The first item that many protocols fail to achieve is to enhance the procedures already inplace. 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 becausethe infrastructure it needs to survive is complicated and needs third party assistancewhereas 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-commercepurposes 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 trustmodels appears in the certification section later in this report.

Additionally, the protocol must be vendor independent, for example S/MIME allowsusers 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


15/37


15

As previously described, without some form of data encryption, the TCP/IP protocolscommunicate 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 encryptnetwork traffic. By encrypting the traffic it still wont avoid the possibility of a man inthe 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-forcepassword crack, the data revealed would most likely be out-of-date, and therefore useless.

Alice Bob

Eve

Hub

DataCommunication

UnknowntoAliceandBob,

Eveislisteningtoall

transmittedtrafficonthe

network.

Eve

EncryptedEncryptedEncryptedEncryptedDataCommunicationDataCommunicationDataCommunicationDataCommunication

Evecanstilllistenfor

trafficbutcannolonger

interpretthedata.

Alice

Hub

Bob


16/37


16

SET Secure Electronic TransactionsThe 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 in1996 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 19952. 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 wereopen 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.


17/37


17

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 theparticipants. ASN provides a mechanism for describing the complex objects within theSET 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 therelationships between each of the entities.


18/37


18

Certification Principles

A certificate is basically a signed statement that something is true, and in a technicalsense 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 thecertificate describing how it is going to be checked for validity.

For example, a software tool called Pretty Good Privacy (PGP) provides a Public KeyInfrastructure (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.

USER (X) HAS PUBLIC KEY (Y)


19/37


19

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 ofsecurity, 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, butUser 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. Thislist 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 auser 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.


20/37


20

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 thecertificate 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.


21/37


21

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 cardto purchase goods in a shop.

Merchant

This is the business that wishes to sell goods online, but unlike a normal shopthe 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 paymentcard on behalf of the merchant. The purpose for which is to obtain payment

authorisation from the issuer.

Payment GatewayWorking on behalf of the acquirer, the payment gateway processes the card,

bridging the gap between electronic purchases and the existing credit cardnetworks.

Certificate Authority

The certification authority provides a trust model for all participants, providing amechanism 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


22/37


22

Software Components

As previously described, SET requires specific software components to allow all of theparticipants 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 thatperform this comparative behaviour. The specific software components are:

1. the digital wallet the front-end for the card holder2. the merchant server the merchants SET software3. the certificate authority handles all of the SET participants certificates4. the payment gateway bridges the merchant with its acquirers legacy systems

The diagram below demonstrates where the software components sit in conjunction withthe 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 theysay they are

2. the acquiring bank certifies that the merchant is who they say they are3. 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

Issuing Banks Acquiring Banks

Card Holder Merchant


Digital Wallet Merchant Server


Gateway

Internet

Internet

Internet

Financial Network


23/37


23

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 asigned 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 beensubsequently 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 ofcreating 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.

One-WayHash Function

User Name

User Password

Timestamp

Random Number

Protected

Password

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 signaturemessage digest which is created for each of the following:


24/37


24

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 aPR (purchase request) see diagram below.

The order information is visible, so the merchant has what it needs, they cannot read thepurchase 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 ofthe order.

OI

PI

HASH

HASH

HASH

OIMD

PIMD

ENCDual Signed

POMD


25/37


25

SSL however does not offer any of these services, or any similar services, to buyers andvendors 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 itdeals 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 knowwho 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 allowsthe user to make the choice of purchasing. Any merchant can be perceived to betrustworthy 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 andnon-repudiation facilities are in place.

iiVeriSign issued two certificates to individuals claiming to be Microsoft by error -

http://amug.org/~glguerin/opinion/revocation.html


26/37


26

Shopping Online with SET

As described by Drew (1998) in his book on using SET, the process of SET onlyaddresses payment authorisation and transport, order confirmation and inquiry, and

merchant reimbursements. For example, SET cannot deal with the process of goodsdelivery, 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 outsidethe SET protocol):

1. Browsing and ShoppingUsing a shopping cart system, the user browsers the available products on thewebsite 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 giventhe 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 TransportThe messages used for the authorisation of payment from the card holder to the

merchant are sent between the correct participants.

6. Payment Confirmation and Inquiry

The merchant or card holder can inquire about the status of a purchase.7. Delivery of GoodsThe merchant having taken an order and payment will ship the purchased

products.

8. Merchant ReimbursementThe merchant is reimbursed by the card holder.


27/37


27

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 iswidely 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 thesecomponents 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 paymentgateway 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 PINat the requested moment during the transaction.


28/37


28

Biometrics

Using a similar principle to the Chip and PIN system, what I propose is that the userswould 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 theirbiometric details with a bank, this process acts like a digital wallet, with their fingerprintacting 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 ofpurchase.


29/37


29

Version 2 Details

SET version 2 was proposed by a company called SETco LLC (the detail of which wasunavailable 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 cardso Europay, MasterCard, and VISA (EMV)o Multi-application

Debit (PIN system)o PIN for online debito PIN pads (PIN entry not from keyboards)

Encryption Alternatives

Algorithm independence

Hardware vendor support

Separate symmetric key from account information

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


30/37


30

Non-repudiation Facilities

SSL - Secure Socket Layer

SSL does not support any form of non-repudiation. SSL was developed primarily tocreate 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 verydifficult 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 certificateshowever 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 toauthenticate with one another. Unlike SSL, the decision on who and who notto 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 themessage, and she revoked the key before the message was supposed to be sent. However,

if it can be proved that the revocation came afterthe message was sent, then Alice would

not be able to repudiate Bobs claims.


31/37


31

ConclusionThe 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 Online12 organisation observes this loss of business and tries to address the issue bycreating 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 aclear 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-vendorsThis 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 functionsthat 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 linksthem 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 itsmain 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 theserver thus creating a secure channel between the two.

SET is not actually a protocol as such but more of an application that mandates thealgorithms 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


32/37


32

communications between customers and merchants. For example the client and the

merchant must have additional software in order to communicate the payment and orderdetails 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 merchantsupporting SET. If this is the case then they will not be able to complete their purchase

using their digital wallet.

Infrastructure required to support itThe 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 theuser 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 VeriSign13

, and then they can partake in secure transactions with customers. Thecommunication 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 followingparticipants 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 cannotbe trusted by means of a trust hierarchy.

Application to Business

Most businesses will understand computer security from the concepts outlined in thisreport. 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.


33/37


33

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. Thisleaves the businesses with three major problems14:

1. to build a business case that non-technical staff and management will understand

and support2. to determine the appropriate level of security for the company3. 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 modelsells 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

onReturn On Investmentdiscusses,

mental pictures and diagrams work well. Their suggestion is to use a castle-and-moatanalogy, 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 isa 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 theloss.

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


34/37


34

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 productselection 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 ofthe 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 theInternet 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 bothtechnology and cryptographic techniques have improved dramatically in the past 8 years.


35/37


35

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: PrenticeHall, 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. Part1: 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


36/37


36

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, 1September 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

1Global 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]

2National Statistics (July 2005)Internet Access [Online] National Statistics. Available

from: http://www.statistics.gov.uk/cci/nugget.asp?id=8 [Accessed 18th Dec 2005].

3Deloitte (2004) Global Security Survey [Online] Deloitte Touche Tohmatsu. Available

from: http://www.deloitte.com/dtt/research/ [Accessed 14th Oct 2005].

4Fraser, B., (1997)RFC 2196 Site Security Handbook[Online] NWG. Available From:

http://www.faqs.org/rfcs/rfc2196.html [Accessed: 31 October 2005]

5Denning, D. E., (1999)Information Warfare and Security [Book] Addison Wesley. Part

1: Introduction [Page 41]

6Blyth, 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]

9Passcracking.ru (2006) Online Rainbow Tables [Online] Available from:

http://passcracking.ru/index.php [Accessed 2nd February 2006]

10Blake-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)


37/37


11RSA 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]

set cryptography and e-commerce

Documents