tvra 004 tvra workshop ecommerce development...

TVRA Workshop

TVRA Workshop Lab:eCommerce Payment

STF 357© ETSI 2009. All rights reserved

TVRA Workshop 23 March 2009

Purpose and Goal of Lab

� Purpose� Get hands-on experience with

1. TVRA method2. eTVRA database

� Goal� Perform one short and focused iteration of the TVRA method

22

� Perform one short and focused iteration of the TVRA method� Get familiar with how to access the eTVRA database� Get familiar with how to insert information and prod uce TVRA reports

from the eTVRA database

TVRA Lab - Task Overview

� Session A:� Step 1: Identify Security Objectives� Step 2: Identify Functional Security Requirements� Step 3: Produce Inventory of Assets

� Session B:� Step 4: Classify Vulnerabilities and Threats

3

� Step 4: Classify Vulnerabilities and Threats� Step 5: Quantify Likelihood and Impact of Threats� Step 6: Determine Risks� Step 7: Specify Detailed Requirements (Countermeasu res)

� Session C:� eTVRA database

TVRA Workshop LabeCommerce Payment

4

Preparation for TVRA

Characteristics of eCommerce Payment

� Commerce is mostly transactional� Select goods → pay for goods → use goods

� Payment means are verified by seller� Cash is real cash� Card details represent ability to pay

• Card details are what needs to be verified

5

• Card details are what needs to be verified• Tying paying party to the card not such a big conce rn

� Payment by credit/debit cards add a third party� Verification of card details done via third party ( the card issuer or his

proxy)

5

Actors in eCommerce Payment

� Purchaser (buyer)� Wants to purchase goods or services using “The Inter net”, a PC and

a web-browser� Wants to pay for purchased goods or services

� eCommerce service provider (seller)� Provides good or services for sale across “The Inter net”

6

� Provides good or services for sale across “The Inter net”� Wants to get paid for the goods or services

� Payment service provider (bank)� Card issuer� Payment verifier

6

Characteristics of a TransactionBank

77

Buyer

Supplier

Relationships Between Actors

� Bank to buyer� Bank acts as card issuer� Credit limit offered is based on customer history a nd risk to bank in

receiving settlement of outstanding customer debt• Predefined relationship

� Bank may be aware of spending patterns

8

� Bank may be aware of spending patterns

� Bank to seller� No predefined relationship

� Buyer to seller� No predefined relationship

8

Overview of eCommerce System

9

Internet Café - Assumptions

10

� What assumptions can we make?� How do we verify that they are valid assumptions?

eCommerce Service Provider - Assumptions

11


Payment Service Provider - Assumptions

LANeLANd

Payment Service Provider

12

Internet

Payment Information

DatabasePayment Service

Server

R4


Payment Scenario Example (1)

UE Web Server Payment Server Payment Info Database

1) msg1=(name, address, card_no, expire_date, cvc)

Appl. Server

4) Check payment information in msg1

2) FW(msg1)

3) FW(msg1)

13

) Check payment information in msg

5) Payment information OK

10) Payment OK

8) Payment OK

9) Payment OK

6) Perform Payment

7) Payment OK


� Message 1)� This message contains the payment information that the user enters

into the web page to pay for requested service• Assumption: Payment information is correct

� The message is sent when the user clicks on ‘OK’ an d the message� Communication media is WLAN and “The Internet”

14

� Communication media is WLAN and “The Internet”� Communication is not protected (HTTP)

� Message 2)� This message is a forward of message 1

• Assumption: Payment information is correct

� Communication media is LAN� Communication is not protected




� Communication media is LAN and “The Internet”� Communication is not protected

� Message 4)

15

� Message 4)� Payment server needs to verify the correctness and validity of the

payment information, which it does by querying the Payment Info Database

� Communication media is LAN� Communication is not protected


� Message 5)� Payment information is both correct and valid and t here is sufficient

funds on the account to perform payment� Communication media is LAN� Communication is unencrypted

� Message 6)

16

� Message 6)� Payment Server performs payment by updating the Pay ment Info

Database (change account information)� Communication media is LAN� Communication is unencrypted

� Message 7)� Payment Info Database is updated and payment status is OK� Communication media is LAN� Communication is unencrypted


� Message 8)� Payment Server sends a message to Application Serve r stating that

payment has been performed and was OK� Communication media is LAN and “The Internet”� Communication is not protected

� Message 9)

17

� Message 9)� Application Server sends Payment OK message to Web Server� Communication media is LAN� Communication is not protected

� Message 10)� Web Server sends Payment OK message to UE� Communication media is LAN and “The Internet”� Communication is not protected


� Message 10)� Application server decrypts and checks the validity and authenticity

of signature from Payment Server• Assumption: PS public key is distributed to Applica tion Server prior to

payment session• Assumption: Signature is both valid and authentic

� Communication is internal to AP

18

� Communication is internal to AP� Message 11)

� Application Server sends (payment=OK) to Web Server� Communication channel is LANb� Communication is unencrypted

� Message 12)� Web Server sends (payment=OK) to UE� Communication channel is Internet� Communication is over SSL

TVRA Workshop LabSession A

19

Session A

TVRA Steps 1-3

Tasks� Use the information given about eCommerce payment ( slides 4-

18) and� Specify the purpose and goal of TVRA� Specify the TOE and the TOE environment� Specify the assumptions for TOE and TOE environment

� Carry out TVRA Steps 1 -3

20

� Carry out TVRA Steps 1 -3� Step 1: Identify Security Objectives

• Examples of security objectives are in CPN TVRA� Step 2: Specify Security Functional Requirements

• Examples of security functional requirements are in CPN TVRA� Step 3: Produce Inventory of Assets (according to the TVRA asset

categories: physical, logical and human)• Description of how to do an systematic inventory of assets are in clause

6.4 in TS 102 165-1 • Example of an inventory of asset are in CPN TVRA

TVRA Workshop LabSession B

21

Session B

TVRA Steps 4-7

Tasks

� TVRA Steps 4-7� Step 4: Classify Vulnerabilities and Threats (examp le on slide 23)

• Denial of Service (DOS) attacks of interest are lis ted in ETSI TS 102 165-1 Annex D• Examples of threats and threat agents are given in clause 5.1.2 in ETSI TS 102 165-1 • List of general threats to security objective categ ories (as defined in ETSI TS 187 001

Annex D) are in table 1A: Threats to security objec tives (clause 5.1.2) in ETSI TS 102 165-1

22

165-1

� Step 5: Quantify Likelihood and Impact of Threats ( hints on slide 24-32)• Description on how to estimate likelihood are in cl auses 6.4 and 6.5 in ETSI TS 102

165-1 • Description on how to assess impact are in clause 6 .6 in ETSI TS 102 165-1

� Step 6: Determine Risks (hints on slide 23)• Risk is defined as the product of likelihood and im pact• TVRA risk definition and support for TVRA Step 6 ar e in clause 6.7 in ETSI TS 102

165-1

� Step 7: Specify Detailed Requirements (Countermeasu res) (hints on slide 23)• Examples are in CPN TVRA

TVRA Step 4: Classify Vulnerabilities and Threats

� Example: � Asset: Payment information� Weakness: Communication between UE and Internet Caf é

Server is in clear text (not protected)� Threat Agent: Attacker

23

� Threat Agent: Attacker� Threat: Eavesdropping on communication between UE a nd

Internet Café Server to disclose payment informatio n� Unwanted incident: Attacker gains knowledge of paym ent

information

Step 5: Quantify Likelihood – Time� Task description:

� Quantify likelihood and impact for each threat usin g the guidelines given in clauses 6.5 and 6.6 in ETSI TS 102 165-1

� Likelihood is calculated over Time, Expertise, Knowledge, Opportunity and Equipment� Time denote the calendar time from an attacker identifie s the weakness and

until the attack is successfully executed and is me asured as:

24

until the attack is successfully executed and is me asured as:• Within minutes, which means that the attack can be identified and exploited in less

than one hour• Within hours, which means that the attack can be id entified and exploited in less than

one day• Within days, which means that the attack can be ide ntified and exploited in less than

one week• Within weeks, which means that the attack can be id entified and exploited in less

than one month• In months, which means that the attacker needs more than one month to carry out a

successful attack

� For our example, Time is evaluated to Within minutes, as the communication is unprotected (information is sent i n clear text).

Step 5: Quantify Likelihood - Expertise

� Expertise refers to the generic knowledge of the relevant underlying principles, product type or attack metho ds.� Laymen, which refers to no particular expertise� Proficient, which means knowledgeable or familiar with the se curity

behaviour of the product or system type� Experts, which means familiar with relevant security proto cols,

25

� Experts, which means familiar with relevant security proto cols, cryptography, etc., and the relevant information on the actual implementation of the product or system

� For our example, the attacker Expertise is evaluated to Proficient, as the attacker needs basic security knowledge to c arry out eavesdropping

Step 5: Quantify Likelihood – Knowledge

� Knowledge is measured in terms of the specific expertise in relation to the assets.� Public, which means that information about the assets can be found

in publicly available sources (e.g. the Internet).� Restricted, which means that information on the assets are co ntrolled

within the relevant organization or shared with othe r organizations

26

within the relevant organization or shared with othe r organizations through Non-Disclosure Agreements.

� Sensitive, which means that information about the assets is constrained and only available to a limited group w ithin the organization.

� Critical, which means that information about the assets is very tightly controlled on a strict need to know basis.

� For our example, the Knowledge is evaluated to Public, as information on how to eavesdrop on unprotected comm unication is publicly available.

Step 5: Quantify Likelihood – Opportunity� Opportunity refers to the window of opportunity to exploit the

vulnerability and carry out the attack and is measu red in terms of:� Unnecessary/unlimited access, which means that the attack does not need

any kind of opportunity to be realized. � Easy, which means that access is required for less than one day or that the

number of asset samples required to perform the att ack is less than ten. � Moderate, which means that access is required for less than one month or

that the number of asset samples required to perfor m the attack is less than

27

� Moderate, which means that access is required for less than one month or that the number of asset samples required to perfor m the attack is less than fifty.

� Difficult, which means that access is required for at least one month or that the number of asset samples required to perform the attack is less than one hundred.

� None, which means that the opportunity window is not su fficient to perform the attack (the length for which the asset to be ex ploited is available or is sensitive is less than the opportunity length neede d to perform the attack).

� For our example, Opportunity is evaluated to Unnecessary/Unlimited access, as there are no restrictions on the access to the Internet Café site.

Step 5: Quantify Likelihood – Equipment

� Equipment refers to the IT hardware/software or oth er equipment needed to identify and exploit the vulnerability an d carry out the attack.� Standard, which means no particular equipment or that the

equipment needed are publicly available.� Specialized, which means that the equipment is not readily ava ilable

28

� Specialized, which means that the equipment is not readily ava ilable to the attacker, but could be acquired without undu e effort.

� Bespoken, which means that the equipment is not readily ava ilable to the attacker and cannot be easily obtained. Example s are specialized hardware, very expensive equipment, controlled dist ribution, etc.

� For our example, Equipment is evaluated to Standard, as the attacker only needs a computer with WLAN card and t o be within range of the WiFi zone.

Step 5: Quantify Impact – Asset Impact

� Impact is measured as a combination of asset impact and attack intensity

� Asset Impact relates to the assets and expresses th e severity of the threat for the concerned party.

� Asset impact is measured in terms of:� Low, which means that the concerned party is not harme d very

30

� Low, which means that the concerned party is not harme d very strongly or that the possible damage is low.

� Medium, which means that the threat addresses the interes ts of providers/subscribers and cannot be neglected.

� High, which means that a basis of business is threatene d and severe damage might occur.

� For our example, the Impact is evaluated to High, as the payment information is regarded by the concerned party (buy er and seller) as being highly sensitive.

Step 5: Quantify Impact – Attack (Threat) Intensity

� Attack intensity refers to how the attack must be c arried out to be successful and is measured in terms of:� Single, which means one threat agent operating from one l ocation.� Moderate, which means several threat agents possibly operat ing from

multiple locations.� Heavy, which means several threat agents operating from multiple

31

� Heavy, which means several threat agents operating from multiple locations with short time between executions (autom ated attack).

� For our example, Attack Intensity is evaluated to Single, as only one threat agent is needed.

Step 5: Quantify Impact - Example

32

TVRA Step 6: Determine Risks (1)

� Task description:� Risk is defined as the product of likelihood and im pact� Definition of Risk is in clause 6.7 in ETSI TS 102 165-1

� Risk is measured in terms of:� Minor, which refers to that no essential assets are conc erned or the

attack is unlikely. Threats causing minor risks hav e no primary need

33

attack is unlikely. Threats causing minor risks hav e no primary need for countermeasures.

� Major, which refers to that threats on relevant assets a re likely to occur although their impact is unlikely to be fatal . Major risks should be handled seriously and should be minimized by the appropriate use of countermeasures.

� Critical, which refers to that the primary interest of the concerned parties are threatened and the effort required from a potential attacker to implement the threat is not high. Criti cal risks should be minimized with highest priority.

TVRA Step 6: Determine Risks (2)

� Risk is calculated as the product of likelihood and impact� For our example, the likelihood value is 3 and the impact value is

3

34

TVRA Workshop LabSession C

35

Session C

eTVRA Database

eTVRA web-database – Documenting TVRA results

� http://portal.etsi.org/eTVRA/

36

Step 1

Step 3

Steps 4, 5 and 6

Step 2Step 7

Tasks

� Go to: http://portal.etsi.org/eTVRA/� Insert information as specified by instructor

37

TVRA Workshop – Extra SlidesPreparing for TVRA

38

Preparing for TVRA

eCommerce Payment Assumptions

Overview of eCommerce System

39

Internet Café - Assumptions

40

� The UE is always a portable computer� WiFi-WLAN is encrypted using WEP with 64 bit key length and easily guessable key� Authentication to web server is done using assigned user name and password (8 characters long)� All communication is over TCP/IP using SSL� Payment scenario assumes successful authentication, but not secure authentication� Authentication between UE and Internet Café Server is out of scope� For the sake of the payment scenario, the Internet Café Server acts as a simple relay and we assume

that the Internet Café Server cannot be attacked� This means that the WiFi WLAN can be used as an attack interface

eCommerce Service Provider - Assumptions

41

� Operating system: MS Windows Server 2003 Service Pa ck 2 (32-bit x86) � Web server: MS Internet Information Server (IIS) 6. 0� User Profile Database is a MS SQL 2000 database� User Profile is comprised of: user name, password, first name and last name,

address, and shopping preferences� The web server uses SSL for all (except setup of SS L session) communication

through Internet and on LANa� Communication on LANb is unencrypted

Payment Service Provider - Assumptions

Internet

Payment Information

Database

LANeLANd

Payment Service Provider

Payment Service

R4

42

� Payment service provider is the customer’s bank� Payment Service Server operating system: SUN Micros ystems Solaris 10� Payment Information Database runs on Oracle 11g Ent erprise Edition� Payment Information Database contains: first name a nd last name,

address, account number, card number, expire date, CCV

InternetServer

TVRA Workshop – Extra SlidesExample Solution

43

Example Solution

eCommerce Payment Scenario –Example Solution

Payment Scenario – One Possible Solution (1)

44


� Pre-conditions: SSL session is established and user is authenticated

� Message 1)� This message contains the payment information that the user enters

into the web page to pay for requested service• Assumption: Payment information is correct

45


� The message is sent when the user clicks on ‘OK’ an d the message� Communication is protected by SSL� Communication media is WLAN using WEP 64 bits key



� Communication media is LAN� Communication is unencrypted


� Message 3)� Application server signs the forwarded message 1 us ing AP private

key• Assumption: Key pair (AP private key and AP public key) is created and

public key distributed to Payment Server prior to p ayment session• Assumption: Payment information is correct

46


� Communication is internal to Application Server� Communication is unencrypted

� Message 4)� The signed forwarded message 1 is sent from Applica tion Server to

Payment Server• Assumption: Payment information is correct

� Communication media is LANc and Internet• Assumption: Communication between the two routers R 2 and R3 are

secure


� Message 5)� Payment Server decrypts and checks the validity and authenticity of

the signed message from AP using AP public key• Assumption: AP public key is distributed to Payment Server prior to


47

• Assumption: Signature is both valid and authentic• Assumption: Payment information is correct

� Communication is internal to Payment Server

� Message 6)� Payment Server sends a request to Payment Info Data base to checks

the payment information contained in the signed mes sage from AP• Assumption: Payment information is correct

� Communication media is LANe� Communication is unencrypted


� Message 7)� Payment Server receives response (payment=OK) from Payment Info

Database• Assumption: Payment information is correct

� Communication media is LANe� Communication is unencrypted

48

� Communication is unencrypted

� Message 8)� Payment Server signs (payment=OK) message with PS p rivate key

• Assumption: Key pair (PS private key and PS public key) is created and public key distributed to Application Server prior to payment session

� Communication media is Internet� Communication is over SSL


� Message 10)� Application server decrypts and checks the validity and authenticity

of signature from Payment Server• Assumption: PS public key is distributed to Applica tion Server prior to


� Communication is internal to AP

49

� Communication is internal to AP� Message 11)

� Application Server sends (payment=OK) to Web Server� Communication channel is LANb� Communication is unencrypted

� Message 12)� Web Server sends (payment=OK) to UE� Communication channel is Internet� Communication is over SSL

Inherent Weaknesses in Payment Scenario (1)� Secure Sockets Layer (SSL)

� SSL is the most common authentication protocol used for web-based secure transactions

� SSL handles mutual or one-way authentication and is meant to preserve the integrity and confidentiality of data exchanged bet ween clients and servers

� SSL has two phases: a handshake phase and a data tr ansfer phase� The problem is the handshake phase, which is not pr otected� Several known Man -In-The-Middle (MITM) attacks that all exploit the fact tha t

50

� Several known Man -In-The-Middle (MITM) attacks that all exploit the fact tha t most secure sites either redirect from insecure (ht tp) servers or blatantly start from an insecure page and post login over https fro m there. A MITM simply have to rewrite the pages to strip out the https.

� Examples of MITM attack are ARP spoofing or ARP cac he poisoning. To execute these attacks you need access to the physic al or wireless network somehow. This is fairly easy in an Internet Café, e ven when WEP is used, as there are WEP key crackers available for free downl oad on the Internet. This MITM attack is done by tricking the client into thi nking that you are the gateway. ARP is the address resolution protocol and is broadcast based so it is possible to either use the race condition and tr y to respond before the real gateway responds or to exploit a caching mechanism by constantly broadcasting yourself as the gateway.

Inherent Weaknesses in Payment Scenario (2)� Wired Equivalent Privacy (WEP) – 64bit

� Uses cryptographic provision of confidentiality wit h 64-bit implementations of the RC4 algorithm. However, in practise the key length is o nly 40 bit (because of the use of repeated (re-used) initialisation vectors). A numbe r of researchers have shown that using some known plaintext and signal injection, the key in WEP can be recovered from a few thousand transactions hence negating any security o f the RC4 algorithm itself. The attacks can be performed over the air in real time with easily accessible tools.

� RC4 is a two stage key stream generator, where the first phase is the key scheduling algorithm, and the second stage is the random numbe r generator. RC4 was designed in

51

algorithm, and the second stage is the random numbe r generator. RC4 was designed in 1987 to be very simple to implement, but practical implementations (such as in WEP) often fail. A stream cipher attempts to achieve the perfect secrecy of the One Time Pad ( nbits of plain text protected by a key of length n to give a cipher text also of length n where the key is absolutely random) but using a short key (i.e. key length l is much less than plain text length n) and a pseudo random generator with some seed info rmation (initialisation vector) to generate a key stream se quence. If the generator is good and the seed information is sufficiently long (with respect to the key) and where the seed is changed for every instance of key stream generation a key stream generator should approach the goals of the One Time Pad.

� WEP only provides confidentiality and does not offe r any support for identification. Furthermore WEP installations use a shared secret t hat may be susceptible to directory attacks.

tvra 004 tvra workshop ecommerce development...

Documents