Accountability as Fundamental property for ... - Semantic Scholar

Accountability as Fundamental property for Electronic Commerce Protocols

Mr. Supakorn Kungpisdan

A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Engineering Department of Computer Engineering Faculty of Engineering King Mongkut’s University of Technology Thonburi 2001

ISBN XXX-XXXX-XX-X

Copyright reserved

Accountability as Fundamental property for Electronic Commerce Protocols Mr. Supakorn Kungpisdan

B.Eng. (Electrical Engineering)

A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Engineering Department of Computer Engineering Faculty of Engineering King Mongkut’s University of Technology Thonburi 2001

Thesis Committee

…………………………………………

Chairman

(Dr. Yongyuth Permpoontanalarp)

…………………………………………

Member

(Dr. Suthep Madarasmi)

…………………………………………

Member

(Dr. Naruemon Wattanapongsakorn)

………………………………………… (Assoc. Prof. Dr. Damras Wongsawang)

Copyright reserved

Member

ii

Thesis Title

Accountability as Fundamental Property for Electronic Commerce Protocols

Thesis Credits

12

Candidate

Mr. Supakorn Kungpisdan

Supervisor

Dr. Yongyuth Permpoontanalarp

Degree of Study

Master of Engineering

Department

Computer Engineering

Academic Year

2001

Abstract

Accountability in electronic commerce (e-commerce) protocols is concerned with the ability to show that particular parties who engage in the protocols are responsible for some transactions. Traditionally, it is used only for resolving payment disputes amongst parties. In this thesis, we argue that the accountability is not just a property for resolving disputes but a fundamental and critical property for analyzing e-commerce protocols. In particular, we show a novel use of the accountability in that it can be used to specify and analyze many goals of e-commerce protocols. The general goal of e-commerce protocols is to ensure engaging parties that they have authorizations to perform transactions relevant to them. Some specific goals of the protocols include client privacy property and each party’s requirement on authorizations for payment transaction. Furthermore, we show that the accountability can be used to resolve an additional kind of disputes also, namely disputes on goods. In order to demonstrate the novel use of the accountability, we develop a logic which extends existing logics for the accountability. We show the practical

iii

usefulness of our logic by analyzing two real-world e-commerce protocols : SET and iKP.

Keywords:

Formal Methods for security protocols, Analysis of Electronic Commerce Protocols

iv

หัวขอวิทยานิพนธเรื่อง

Accountability: คุณสมบัติพื้นฐานสําหรับ

โปรโตคอลสําหรับพาณิชยอิเลคทรอนิกส หนวยกิตของวิทยานิพนธ

12 หนวย

โดย

นายศุภกร กังพิศดาร

อาจารยที่ปรึกษา

ดร. ยงยุทธ เพิ่มพูนธนลาภ

ระดับการศึกษา

วิศวกรรมศาสตรมหาบัณฑิต

ภาควิชา

วิศวกรรมคอมพิวเตอร

ปการศึกษา

2544

บทคัดยอ คุณสมบัติ Accountability ที่ใชในพาณิชยอิเลคทรอนิกสเปนความสามารถในการแสดง วาบุคคลผูนั้นมีความเกี่ยวของกับการทําธุรกรรมนั้นๆ อยางไร ที่ผานมานั้น Accountability ไดถูกนํามาใชเพียงเพื่อแกไขขอขัดแยงระหวางบุคคลในการทําธุรกรรมเทานั้น วิทยานิพนธฉบับนี้ไดแสดงใหเห็นวา Accountability ไมไดเปนเพียงคุณสมบัติที่ใช สํ า หรั บ แก ไ ขข อ ขั ด แย ง เท า นั้ น แต ยั ง เป น คุ ณ สมบั ติ พื้ น ฐานและสํ า คั ญ สํ า หรั บ การวิ เ คราะห โปรโตคอลสํ า หรั บ พาณิ ช ย อิ เ ลคทรอนิ ก ส อี ก ด ว ย โดยเฉพาะอย า งยิ่ ง เราได เ สนอการนํ า Accountability ไปใชงานในอีกรูปแบบหนึ่งคือ การนําไปใชในการระบุและวิเคราะหเปาหมาย ของโปรโตคอลสําหรับพาณิชยอิเลคทรอนิกส ซึ่งเปนหมายโดยทั่วไปของโปรโตคอลสําหรับ พาณิชยอิเลคทรอนิกสนั้นคือ การทําใหบุคคลที่เกี่ยวของมั่นใจไดวาพวกเขาไดรับอนุญาตให กระทําธุรกรรมที่เกี่ยวของกับพวกเขา เปาหมายเหลานี้รวมถึงสมบัติดานการปกปดความลับของ ลูกคา (Client Privacy) และการระบุความตองการของแตละบุคคลในดานการไดรับอนุญาตใน ดานการทําธุรกรรมดานการจายเงิน ยิ่งกวานั้น ยังสามารถใชในการแกไขขอขัดแยงอีกประเภท หนึ่ง คือ ขอขัดแยงเกี่ยวกับสินคาไดอีกดวย เพื่อที่จะแสดงใหเห็นถึงการใชงานตางๆ เหลานี้ เราไดพัฒนาวิธีการทางตรรกศาสตรที่ เพิ่มเติมจากวิธีการที่ใชวิเคราะห Accountability ที่มีอยู เรายังไดแสดงใหเห็นถึงประโยชนใช สอยที่สามารถนําไปใชงานไดจริงๆ โดยการนําไปใชในการวิเคราะหโปรโตคอลสําหรับพาณิชย อิเลคทรอนิกสที่ใชงานจริงๆ คือ SET และ iKP

v

คําสําคัญ (Keywords):

Formal Methods for security protocols, Analysis of Electronic Commerce Protocols

vi

Acknowledgments

I would like to first thanks to my advisor Dr. Yongyuth Permpoontanalarp for his guidance and support throughout my thesis. His supervision and encouragement during discussions are very helpful for me about this work. This thesis is not complete without his suggestions. Thanks to the Department of Computer Engineering for its support during my master degree study. Thanks to all lecturers for the knowledge and research experience. Thanks to all friends in the logic and security laboratory for the helpful suggestions. Thanks to all my friends in the department who made my life here enjoyable. Thanks to Kesarin Jintanapornpan for support and encouragement. Final thanks to my parents, grandmother, brother, and sister for their understanding and encouragement which help me through all tough times.

vii

Contents

Title

Page

English Abstract

ii

Thai Abstract

iv

Acknowledgements

vi

Contents

vii

List of Figures

x

Chapter 1

Chapter 2

Introduction

1

1.1 Motivation

1

1.2 Objectives

5

1.3 Contributions

5

1.4 Organization of Thesis

6

Background

7

2.1 Electronic Commerce Protocols

7

2.1.1 Overview of Electronic Commerce Protocols

7

2.1.2 SET Protocol

8

2.1.3 iKP Protocol

10

2.2 Accountability

12

2.3 Accountability Logics

13

2.3.1 Kailar’s Logic

13

2.3.2 Kessler and Neumann’s Logic

14

viii

2.4 Analysis of Accountability on Real-World Electronic Commerce Protocols

15

2.5 Formal Requirements of Electronic Commerce Protocols

19

Chapter 3

The Logic

21

Chapter 4

Accountability for Dispute Resolution

27

4.1 Set of Assumptions of SET and iKP

27

4.2 Analysis of Money Accountability of SET and iKP

32

4.2.1 Analysis of Money Accountability of SET

33

4.2.2 Analysis of Money Accountability of iKP

39

4.3 Analysis of Goods Accountability of SET and iKP

40

4.3.1 Analysis of Goods Accountability of SET

41

4.3.2 Analysis of Goods Accountability of iKP

45

Chapter 5

4.4 Discussion

48

Goals of Electronic Commerce Protocols as Accountability

49

5.1 Goals of SET and iKP as Accountability

49

5.2 Client Privacy

51

5.2.1 Analysis of Client Privacy of SET

52

5.3 Each Party’s Requirement for Payment Transactions as Accountability 5.4 Discussion

53 60

ix

Chapter 6

Chapter 7

Discussion

62

6.1 Discussion

62

6.2 Future Work

63

Conclusion

64

References

66

Appendix A. General Assumptions for Proving Money and Goods Authorizations

69

B. Analysis of Accountability for Dispute Resolution of SET and iKP

73

C. Accountability for Specifying and Analyzing Goals of Electronic Commerce Protocols

89

D. Meadows and Syverson’s Each Party Requirements for Payment Transactions of SET E. Published Papers

109 115

x

List of Figures Title

Page

Figure 2.1

SET Protocol

9

Figure 2.2

iKP Protocol

11

Figure 2.3

Primitive Transactions

17

CHAPTER 1

INTRODUCTION

1.1

Motivation

In electronic commerce (e-commerce), every party requires a guarantee that any transaction that occurs is carried out in a secure fashion. In fact, it is unavoidable to prevent malicious behaviors of some parties. This malicious behavior causes “Dispute” amongst parties. An example of dispute is that Bob buys a $50 book from Bookshop.com, but he claims that he was deducted money $70 by a bank. Although the system cannot prevent the dishonest party from modifying transactions, it should allow honest parties to prove their rightful behavior when a dispute amongst parties occurs. This property should be included in well-designed protocols since it gives assurances to users in that each user can prove what has actually happened in a transaction to a verifier, who may be a court or someone acting as a dispute solver. This property is called accountability. Accountability in e-commerce protocols [1] is concerned with the ability to show that particular parties who engage in such protocols are responsible for some transactions. In particular, the accountability [1] involves the ability of a party, called a prover to convince to another party, called a verifier, that a statement is true without revealing any secret information to the verifier. Traditionally, the

2

accountability is used only to resolve disputes amongst parties. In such cases, a judge would act as the verifier, and a defendant would act as a prover. On one hand, many logics [1][3] were proposed for reasoning about the accountability in e-commerce protocols. However, these logics lack of the application to real-world e-commerce protocols. On the other hand, Herreweghen [2] proposed an analysis of two real world protocols: SET [8] and iKP [7] on the accountability property. The analysis shows that SET lacks of the accountability whereas iKP has the property. However, the analysis is carried not informally since it does not use any formal logic. We argue that the existing logics for analyzing the accountability are inadequate to analyze real-world e-commerce protocols. In particular, we argue that the existing logics are not able to reason about multiply encrypted and/or hashed messages, which are signed. Such messages are obtained from applying encryption, digital signature, hash function, or a combination of them to a plain message. Indeed, this kind of messages is that which is employed in most, if not all, e-commerce protocols. Moreover, in order to reason about the accountability in general, it requires reasoning about verifiers whether a verifier would be convinced of some statement, after a prover sends some non-secret or non-private information to the verifier. We argue that Kailar’s logic [1] does not provide reasoning about verifiers at all. Even though Kessler and Neumann’s (KN) logic [3] offers reasoning about verifier’s belief as a result of the receipt of some information, it does not address the issue about proving without revealing secret or private information to verifiers. Note that this issue is a part of the definition of the accountability [1].

3

In this thesis, we argue that the accountability is not just a property for resolving disputes but a fundamental and critical property for analyzing e-commerce protocols. In particular, the accountability can be used not only for resolving disputes, but also for specifying and analyzing goals of e-commerce protocols. We propose a novel use of the accountability for specifying and analyzing the goals of e-commerce protocols. The main and general goal of e-commerce protocols is to ensure that after the completion of the protocols, all parties who engage in the protocols are convinced that they have authorized messages concerning transactions relevant to them. We argue that this goal can be understood as a special case of the accountability where the prover is the originator of a message, the verifier is the intended recipient and the statement to be proved is about some transactions. Also, we show that the client privacy property, which is a specific goal of ecommerce protocols, can be understood as the accountability. The client privacy is concerned with clients’ provability of their authorized payment for a transaction without revealing goods description and payment information (e.g. credit card numbers) in the transaction to banks and merchants, respectively. Thus, the client privacy can be understood as a special case of the accountability where a client is a prover, both a bank and a merchant are verifiers, and the proving statement is about the payment authorization. Moreover, both goods description and payment information are considered as client’s private information, which must not be revealed to the bank and the merchant, respectively. Moreover, we show that each party’s requirement on authorizations for payment transactions, proposed by Meadows and Syverson [9], can be specified by the accountability. Such a party’s requirement expresses the kind of authorizations

4

that are needed by the party in order to complete its task. A party’s requirement is complete if the party is convinced that its requirement on authorizations is satisfied. The practical aspect of the accountability that was discussed so far in the literature [2][5] is about payment or money only. In particular, the money accountability is about the authorized transfer of money from customer’s account to merchant’s account. In this thesis, we introduce another kind of accountability, called goods accountability, which is about the authorized order of goods by a client. The goods accountability can be used to resolve disputes on the mismatch between the goods which is ordered and that which is delivered. In order to demonstrate the novel use of the accountability, we develop a logic which extends existing logics for the accountability. Our logic can reason not only about the accountability of complex cryptographic messages, which are signed, but also about verifiers’ beliefs as a result of the receipt of some information. Moreover, our logic captures the provability without revealing any secret or private information to verifiers naturally by using provers’ beliefs about verifiers’ possession of information. We show the practical usefulness of our logic by analyzing two realworld e-commerce protocols: SET and iKP. Particularly, the results obtained from the informal analysis [2] can be obtained from our logic. By using our logic, we also show that both SET and iKP lack of the goods accountability.

5

1.2

Objectives

1.2.1

To develop a logic for accountability that is adequate for analyzing

real-world e-commerce protocols. 1.2.2

1.3

To propose a novel use of the accountability for: -

Resolving disputes on goods, and

-

Specifying and analyzing goals of e-commerce protocols.

Contributions

The contribution of this thesis can be summarized as follows. 1.3.1 We develop a logic for accountability that is adequate for analyzing real-world e-commerce protocols. In particular, our logic offers reasoning about the accountability of complex cryptographic messages, which are signed. Moreover, our logic captures the provability without revealing any secret or private information to verifiers. 1.3.2 We propose a novel use of the accountability for resolving disputes on goods, and specifying and analyzing goals of e-commerce protocols. Two kinds of goals, namely general and specific goals, can be specified by our logic. Specific goals include client privacy property and each party’s requirement on authorizations for payment transaction.

6

1.4

Organization of Thesis

This thesis is organized as follows: chapter 2 provides the background for the accountability and the existing logics. Chapter 3 presents our logic. In chapter 4, we applied our logic to analyze accountability for resolving disputes. Chapter 5 presents how we use the accountability property to specify and analyze goals of e-commerce protocols. Chapter 6 presents the discussion of our work. Chapter 7 concludes our work.

CHAPTER 2

BACKGROUND

2.1

Electronic Commerce Protocols

2.1.1

Overview of Electronic Commerce Protocols Nowadays, electronic commerce (e-commerce) becomes an important

issue for driving business. It employs the Internet as a medium for driving commercial transactions. With online transactions, every participant is not necessary to go out to perform transaction as traditional transactions. Many kinds of e-commerce protocols have been developed in order to support the online transactions. For example, SET [8] and iKP [7] protocols for credit-card based payment transaction and Millicent protocol [14] for the payment transactions with small amount of money. The main purpose of e-commerce protocols is to secure payment transactions. There are three main parties involved in e-commerce transactions: client, merchant, and financial institution (or bank). Client is the party who makes an order for goods and pay money for the goods to merchant. Merchant receives money and delivers goods the client who ordered for the goods. Bank deducts or deposits money from other parties.

8

In e-commerce transactions, it is unavoidable to prevent malicious behaviors of some parties. For example, Bob buys a $50 book from Bookshop.com by credit card, after that Bob accuses Bank that Bank deducts money amount $70 from his account, which is more than that requested. This situation causes “Dispute”. E-commerce systems cannot prevent a party to accuse some parties or claim about the occurrence of the strange situation. The main goal of developing e-commerce protocols is to ensure that after the completion of the protocols, all parties who engage in the protocols are convinced that they have authorized messages concerning transactions relevant to them. For example, merchant is ensured that client has requested to purchase goods and pay money to him, or client is ensured that he will receive goods after paying money to merchant. According to the SET protocol, one of its goals is Client Privacy property. The client privacy is concerned with clients’ provability of their authorized payment for a transaction without revealing goods description and payment information (e.g. client’s credit card numbers) in the transaction to banks and merchants, respectively. In SET, merchant cannot infer client’s payment information, and acquirer cannot infer goods description after the completion of protocol. 2.1.2

SET Protocol SET (Secure Electronic Transaction) protocol [8] is the most widely

used credit-card based protocol using public key cryptography scheme proposed by two major credit card companies (VISA and Mastercard). There are three parties engaging in SET protocol: client, merchant, and acquirer (or bank). Client is an authorized party who has a credit card and wants to buy goods or services from

9

merchant. Merchant is an authorized party who has goods or services to sell to customer. A merchant that accepts payment credit cards must have a relationship with an acquirer. Acquirer, behaving as a payment gateway between Customer, Merchant, and Banks, is a party who deducts the money from customer’s account and transfers the money to merchant’s account. In SET, every party is required to have his own public key certificate. The basic SET protocol model is shown as follows:

PinitReq: C→M: PinitRes: M→C:

Initial Request {TID}K - 1

PReq:

TID, OI, h(PI), {h(OI), h(PI)}K - 1 , {h(OI), PI}K A

C→M:

AuthReq: M→A:

M

C

{{TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}K - 1 , C

{h(OI), PI}K A }K -1 }K A M

AuthRes: A→M:

{{TID, Price, AuthDate}K - 1 }K M

PRes:

{TID, AuthDate}K - 1

M→C:

A

M

Figure 2.1 SET Protocol Where - {A, C, M} stands for a set of acquirer (or bank), client, and merchant, respectively. - {KA, KC, KM,} stands for the set of public key of acquirer, client, and merchant, respectively. - {K A-1 , K C-1 , K M-1 } stands for the set of private key of acquirer, client, and merchant, respectively.

- Price stands for amount and currency of goods. - OI stands for order information, which contains client’s credit card information. OI = {TID, h(OD, Price)}.

10

- PI stands for payment information. PI contains {TID, h(OD, Price), MerchantID, Price, Client’s Credit-card Information}. - TID stands for transaction ID. TID contains purchase request date (PReqDate), which is the date of issuing purchase request.

- AuthReqDate stands for the date of making request by merchant for transferring money.

- AuthDate stands for the date of authorization made by bank. In Purchase Initial-Request (PinitReq), client and merchant exchange variables needed to ensure payment messages. In Purchase-Request (PReq), client sends the purchase request to merchant in order to make the payment. In Authorization-Request (AuthReq), merchant requests acquirer for transferring money to his account. In Authorization-Response (AuthRes), acquirer sends the commitment of transferring money to merchant’s account to merchant. In Purchase-

Response (PRes), merchant sends the receipt of payment to client in order to commit to deliver goods to client. 2.1.3 iKP Protocol iKP (Internet Key Protocol) [7] is another credit-card based ecommerce payment protocol. The protocol step of iKP is similar to that of SET. iKP is a family of protocol in that it consists of three types of protocol, which depends on the number of certificate of the engaging party. SET is similar to 3KP, which is the protocol that all engaging parties have their own certificates. The basic iKP protocol model as the following:

11

ClientID MerchantID, h(OI), Date, InvExpDate PI, {PI, h(OI)}K -1

Initiate: Invoice: Payment:

C→M: M→C: C→M:

(Cancel:

M→C:

RESPCODE,{h(OI)}K -1 )

AuthReq:

M→A:

MerchantID, h(OI), Date, InvExpDate, h(OD), PI, {h(OI)}K -1 , {PI, h(OI)}K -1

C

M

M

C

AuthRes:

A→M:

AI, {AI, h(OI)}K -1

Confirm:

M→C:

AI, {h(OI)}K -1 , {AI, h(OI)}K -1

A

M

A

Figure 2.2 iKP Protocol Where -

PI is payment information PI contains {Price, h(OI), Client’s

Credit-card Information}Ka. -

OI is order information. It contains (TID, Price, ClientID,

MerchantID, Date, InvExpDate, h(OD)). -

InvExpDate stands for invoice (offer) expiration date specified by

-

Date stands for the date of invoice (offer) issued by merchant.

-

AI is authorization information. It contains RESPCODE and

merchant.

AuthTime. From [7], the main differences between SET and iKP is in their overall functionality and complexity, that is, iKP was designed only for payment functionality whereas SET is designed to support all credit-card operations. Thus SET is more complex than iKP. In this thesis, we focus on only payment functionality of SET and iKP.

12

2.2

Accountability

As stated in section 2.1.1 that we cannot prevent the occurrence of disputes, it is necessary that any secure e-commerce system must provide the ability to handle such disputes. A property that can be used to deal with dispute handling is called

Accountability. Accountability is concerned with the ability to show that particular parties who engage in protocols are responsible for some transactions. From the example of dispute in section 2.1.1, each engaging party has to find the way to show to a party who acts as a dispute resolver that he is honest in performing such transaction. If Bob is able to show that he has really requested Bookshop.com to buy a $50 book, and he has requested Bank to deduct money amount $50 from his account. Bookshop.com can prove that he really received the purchasing order amount $50 from Bob. Bank shows to the judge that Bob really requests to deduct $50 from his account. This dispute is resolved in that Bob, the accuser, is right, and Bank is guilty. What happen if Bob cannot prove his honesty to the judge even if he is honest? This situation can be occurred in the protocol that lacks of the accountability. Such protocol does not provide the necessary evidence that each party can use to prove to a judge. The protocol with accountability could provide the assurance about performing transactions to each party. Hence, it is desirable to ensure that any secure e-commerce system has the accountability property.

13

2.3

Accountability Logics

2.3.1

Kailar’s Logic Kailar [1] is probably the first who propose a modal logic to reason

about accountability. Kailar’s definition of accountability is concerned with the ability to prove the association of an originator (of a message) with some action to a third party without revealing any private information to the third party. The party who can prove such a statement is called a prover whereas the third party who is convinced of the proof is called a verifier. Kailar employs the modal operator ‘CanProve’ to formalize the concept of accountability, i.e. P CanProve φ to V where

P and V stand for prover and verifier, respectively, and φ stands for a general statement about some action. However, Kailar’s logic [1] is not suitable for analyze the real-world e-commerce protocols because of the following two reasons: firstly, Kailar’s logic can analyze the signed plain message only. However, messages in real-world ecommerce protocols are not just signed plain messages, but they often are multiply encrypted and/or hashed messages which are signed, i.e. {h(X)}K or {{X}K' }K -1 , where K’ is public key of a party and K-1 is private key of another party. Secondly, Kailar’s logic does not reason about verifiers at all. Recently, it was pointed out in [2] that reasoning about verifiers is essential for analyzing real-world e-commerce protocols. We shall discuss this issue in detail in a later section. It should be noted also that Kailar’s definition for accountability is

general in that the actions that are associated with an originator can be of any kinds.

14

2.3.2

Kessler and Neumann’s Logic Following Kailar [1], Kessler and Neumann (KN) [3] employs a

modal logic to reason about the accountability. However, KN provides an alternative definition of the modal operator ‘CanProve’ by means of sending messages. KN’s goal to show the accountability is to show ‘P believes P CanProve φ to V’ where P and V stands for a prover and a verifier, respectively. One way to show that P

believes P CanProve φ to V holds is for P to believe that P can convince V to believe

φ by sending some messages that P has to V. Thus, this logic offers reasoning about both prover’s beliefs and verifier’s beliefs, and in particular, prover’s beliefs about verifier’s beliefs. Even though KN’s logic offers reasoning about the accountability of hashed messages which are signed, its definition for dealing with such messages is

too strong in that verifiers are able to infer the input m of any hash h(m), which may be private information. Consider the following rule for dealing with such kind of message in KN’s logic:

P CanProve (Q said h(X)) to V ∧ V believes ¬Q sees h(X)

→ P CanProve (Q said X) to V

This rule states that if P can prove that Q said the hash value of X,

i.e. h(X), and V believes that Q does not receive h(X) from anyone, then P can prove to V that Q said X. We argue that this is not intuitive. Generally, to prove that Q said the input X of a hash function, both prover and verifier need to know:

15

a) The hashed message h(X) and the input (X), and b) That the hashed message is really obtained from applying hash function h to X. Obviously, in KN’s approach, the verifier does not need to know a) and b) but simply that the verifier must believe that the initiator does not receive the hash of the message from anyone in order to be convinced that the initiator originates the hashed message and thus its input. The verifier is convinced even though to show

b) requires the knowledge of some private information, which should not be revealed to any third party (e.g. goods description). Moreover, their logic does not deal with the accountability of encrypted messages which are signed, i.e. {{X}K' }K -1 where K’ is public key of a party and K-1 is private key of another party.

2.4

Analysis of Accountability in Real-World E-Commerce Protocols

Herreweghen [2,4] proposed the analysis of the accountability of the realworld e-commerce protocols: SET [8] and iKP [7]. The analysis shows that SET lacks of the accountability whereas iKP has the property. The analysis is not formal since it is done without using any formal logic. However, the analysis is presented partly in rule-based styles. For example,

16

evidence (OIData, HPIData, HODContents) verify (HOIDATA = H(OIData), HOD = H(OD, PurchAmt, ODSalt) SigC = SC(HOIDATA, HPIData) → C authorized payment(C, M=?, PurchAmt, TIDs.PreqDate, Ref)

This rule states that if verifier receives evidence, and verifier can verify that the statements are true, then verifier can make the conclusion that a party C wants to make the payment to someone at amount PurchAmt. This rule cannot prove the identity of merchant because verifier cannot infer merchant’s ID from the evidence. Unlike the accountability in Kailar’s approach and KN’s approach, the kind of the accountability that is analyzed in [2] is specific in that it focuses on primitive transactions [5], which are the core of e-commerce protocols. It was proposed in [5] that a payment transaction in any e-commerce protocol consists of three types of primitive transactions: -

Payment: client makes the payment to merchant.

-

Value subtraction: client allows acquirer to deduct money from his

account. - Value claim: merchant requests acquirer to deposit money to merchant’s account.

17

Acquirer

Figure 2.2 Primitive Transactions Value claim

Value subtraction payment Client

Merchant

Figure 2.3 Primitive Transactions

Thus, in order to show that an e-commerce protocol has the accountability for resolving disputes, it suffices to show that at the completion of the protocol, each party in the protocol must be able to prove the authorizations of primitive transactions concerning the party to an external verifier. The following shows such kind of statements: -

M can prove “C authorized payment(C, M, Amount, Date, Ref)” Merchant can prove that client has sent authorized message on making

the payment to him. -

C can prove “M authorized payment(C, M, Amount, Date, Ref)” Client can prove that merchant has sent authorized message on

acknowledgement of payment to him. -

A can prove “C authorized value subtraction(A, C, Amount, Date, Ref)” Acquirer can prove that client has sent authorized message on requesting

him to deduct money from client’s account. -

C can prove “A authorized value subtraction(A, C, Amount, Date, Ref)” Client can prove that acquirer has sent authorized message on

acknowledgement of requesting to deduct money from client’s account.

18

-

A can prove “M authorized value claim(A, M, Amount, Date, Ref)” Acquirer can prove that merchant has sent authorized message on

requesting him to transfer money to merchant’s account. -

M can prove “A authorized value claim(A, M, Amount, Date, Ref)” Merchant can prove that acquirer has sent authorized message on

acknowledgement of transferring money to merchant’s account. The analysis in [2] shows that SET lacks of the accountability because of the following two problems: Firstly, prover does not have key for decrypting the encrypted message, which contains the necessary information. For example, prover wants to derive PI from {PI}K A , but he does not have acquirer’s private key. Secondly, prover has to reveal the private information to verifier in order to prove the authorization. The source of this problem is that the required information is hashed together with the information which is considered to be private information to verifier e.g. h(Price,OD) where Price is the required information and OD is private information. To derive Price, prover is required to send both Price and OD to verifier to convince him. Thus the verifier knows the private information. This problem does not occur in iKP. The message format in iKP is h(Price, h(OD)) . Thus, the prover can convince the verifier about Price without revealing OD because it is hashed. We argue that Herreweghen’s analysis [2] is sensible. To solve disputes, prover wants to send only the necessary evidence to judge. The unnecessary private information is not what he wants to reveal for proving some statements. The disadvantages of this approach are as the following:

19

1) It is unsystematic since the analysis is not formal. 2) It is specific to only SET and iKP. Those rules cannot be applied to other protocols.

2.5

Formal Requirements of Electronic Commerce Protocols

Meadows and Syverson (MS) [9] proposed the specification of requirements for payment transactions in SET protocol using NPATRL, which is the language for analyzing cryptographic protocols using symbols representing actions and events with temporal operator. They model a transaction as a vector representing knowledge that each party has and message that each party sends. Knowledge is represented by accept event, and message is represented by send action. For example, cust_accept(V) is knowledge known by customer when it accepts that the transaction is complete, and

merch_respsend(V) is the message sent from merchant representing purchase response. The requirements are stated in terms of implications where the conditions represent the requirements and the conclusions represent actions that must be previously happened. For example,

accept(customer(P,[honest]), merchant(Q,[X], cust_accept(V), N?)

- send(merchant(Q, [X]), customer(P, [honest]), →

merch_respsend(V), N?)

20

The implication above states that customer will accept that the transaction is complete if merchant has previously sent purchase response to customer. MS’s work shows necessary conditions for each party’s requirement in ecommerce systems. Each party will complete the task relevant to transactions if the requirements is previously happened in the protocol. It can be seen as the requirement on the occurrence of relevant requests and relevant acknowledgement whereas Herrreweghen’s work [2] deals only with the derivability of authorized (authenticated) information from either a request or an acknowledgement. The details of MS’s party requirements are shown in Appendix D.

CHAPTER 7

CONCLUSION

In this thesis, we show that accountability is not just a property for resolving disputes but a fundamental and critical property for analyzing e-commerce protocols. In particular, the accountability can be used not only for dispute resolution, but also for specifying and analyzing goals of e-commerce protocols. We then develop a logic which extends existing logics for the accountability to deal with real-world ecommerce protocols. For reasoning about dispute resolution, we show that the existing logics for reasoning about accountability are inadequate to deal with real world e-commerce protocols. We show formally that SET lacks of the money accountability whereas iKP does not. Moreover, we show that both SET and iKP lack of the goods accountability. The lack of the goods accountability in our sense means that the two protocols can still provide enough evidence tokens to resolve disputes on goods description, but in order to resolve such disputes, provers must reveal their private information to verifiers. In some situations, this is undesirable. Furthermore, we demonstrate the practicality of our logic by showing that the result obtained from Herreweghen’s informal analysis [2] can be also obtained formally from our logic. For reasoning about the goals of e-commerce protocols, we show that accountability can be used to specify and analyze the client privacy property and

65

each party’s requirement on authorization for payment transactions of SET. We show that such kind of reasoning can be considered as a special case of the accountability.

CHAPTER 3

THE LOGIC

Our logic is based on Kessler and Neumann’s logic (KN) [3]. In particular, our logic can be seen as an extension and a simplification of KN’s logic. It employs the concept of provable authorization in the present of private information. In order to solve disputes, a prover wants to send only the necessary information to prove some statements to a judge who acts as a verifier without revealing the unnecessary private information. With this concept, prover can prove the statement without revealing private information to verifier. We extend KN’s logic in two main aspects. Firstly, we provide axioms for the accountability of multiply encrypted and/or hashed messages which are signed in order to resolve disputes. Secondly, we propose axioms for dealing with the use accountability to specify and analyze the goals of electronic commerce protocols.

Syntax

Terms -

{P, Q, V} : A set of principles that communicate with each other in the protocol.

-

{X, Y} : Messages or message components sent in the protocol.

-

{φ, ψ} : The statements derived from messages.

22

-

{KP, KQ} : A set of the public key of the principal P and Q, respectively.

-

{K P−1 , K Q-1 } : A set of private key of the principal P and Q, respectively.

-

{X}K : The message X encrypted with key K.

-

h(X) : The hash function of a message X.

-

K → Q : Key K is the public key of Q.

-

P ↔ Q : K is the shared key between P and Q.

-

X-is-fingerprint-of-Y : X can be used as the representative (fingerprint) of Y (in

K

other words, X may be the hashed form of Y). -

K-is-decrypting-key-for-{X}K : Key K can be used to decrypt the encrypted

message {X}K.

Formulae -

P believes φ : A principle P believes that the statement φ is true by doing some

actions. -

P sees X : Someone has sent a message X to P and P is able to read X.

-

P has X : A principle P possesses a message X. He can send X to other principles

or use it for further computations. -

P says X : A principle P has sent a message X.

-

P CanProve φ to Q : A principal P can prove to Q that the statement φ is true by

sending a message X to Q. After Q receives X, he believes that the statement φ is true. -

P authorized payment(P, Q, Price, Date) : A principle P has authorization on

making the payment amount Price to Q on date Date.

23

-

P authorized value subtraction(P, Q, Price, Date) : A principle P has

authorization on requesting Q to deduct money amount Price from P’s account on date Date. -

P authorized value claim(P, Q, Price, Date) : A principle P has authorization on

requesting Q to transfer money amount Price to P’s account on date Date. -

P authorized goods-order(P, Q, OD, Date) : A principle P has authorization on

ordering goods as specified in order description OD to Q on date Date.

Axioms

Modalities: KD45-logic K:

P believes φ ∧ P believes (φ → ψ) → P believes ψ

D:

P believes φ → ¬P believes ¬φ

4:

P believes φ → P believes P believes φ

5:

¬P believes φ → P believes ¬P believes φ

Possession H1:

P sees X → P has X

H2:

(P has X1 ∧ … ∧ P has Xn) ↔ P has (X1, … , Xn) Where (X1, … , Xn) stands for a list of message X1, X2, …, Xn, respectively.

H3:

P has X → P has h(X) The following axioms (H4, H5, and H6) are based on BAN logic [6] in order

to deal with cryptographic messages.

24

H4:

If P has an encrypted message {X}K, P believes that K is shared between P’

and Q, and P has key K, then P has X. K

( P has {X}K ∧ P believes P’ ↔ Q ∧ P has K ) → P has X H5:

If P has an encrypted message {X}K, P believes that K is the public key of P’,

and P has its private key K-1, then P has X. K ( P has {X}K ∧ P believes → P’ ∧ P has K-1 ) → P has X

H6:

If P has a signed message {X}K -1 , P believes that K is the public key of P’, and

P has its verification key K, then P has X. K ( P has {X}K -1 ∧ P believes → P’∧ P has K ) → P has X

Comprehension C1:

If P has received X, P then believes that he receives X.

P sees X → P believes P sees X C2:

If P has sent X, he then believes that he has sent X.

P says X → P believes P says X

Seeing SE1:

P sees (X1,…, Xn) ↔ (P sees X1 ∧ P sees X2 ∧ … ∧ P sees Xn)

Saying SA1: P says (X1, …, Xn) ↔ (P says X1 ∧ P says X2 ∧ … ∧ P says Xn) SA2: P says X → P has X

Provability P1:

P CanProve (φ → ψ) to V → (P CanProve φ to V → P CanProve ψ to V)

25

P2:

(V-is-external-party) ∧ (P has X) ∧ (V sees X → V believes φ)

→ (P CanProve φ to V) It can be seen that axiom P2 can be used to deal with the provability to an external verifier. Thus, the axiom states the accountability for resolving disputes. P2’:

If V is an internal party, P has sent a message X’, V receives X, and if V

receives X, then he believes that φ is true and he has X’, then P can prove to V that φ is true.

(V-is-internal-party) ∧ (P says X’) ∧ (V sees X) ∧ [ V sees X → (V believes φ ∧ V has X’) ]

→ (P CanProve φ to V) It should be noted that the verifier V in this axiom is an internal party who engages in the protocol. This axiom is intended to deal with the accountability for specifying and analyzing the goals of e-commerce protocols. We shall discuss this issue and the intuition of axiom P2’ in section 4.4. P3:

K P has {X}K -1 ∧ P has (K, X) ∧ P CanProve ( → Q) to V

→ P CanProve (Q says X) to V The following shows our axiom to deal with the provability about hashed messages. Intuitively, it states that in order to prove a statement about a hashed message, it requires both prover and verifier to know the input of the hash in order to compare the input with such hashed message. P4:

If P can prove to V that Q has sent h(X) and he can prove to V that h(X) is

represented as fingerprint of X, P then can prove to V that Q has sent X.

26

P CanProve (Q says h(X)) to V ∧ P CanProve (h(X)-is-fingerprint-of-X) to V

→ P CanProve (Q says X) to V The following shows our axiom to deal with the provability about encrypted messages. In order to prove a statement about an encrypted message, it requires both prover and verifier to know the decrypting key for such encrypted message. P5:

If P can prove to V that Q has sent the encrypted message {X}K and he can

prove to V that the key K’ can be used to decrypt this encrypted message, he can prove to V that Q has sent message X.

P CanProve (Q says {X}K) to V ∧ P CanProve (K’-is-decrypting-key-for-{X}K) to V

→ P CanProve (Q says X) to V P6:

P CanProve (Q says (X1, …, Xn) to V

↔ [ P CanProve (Q says X1) to V ∧ … ∧ P CanProve (Q says Xn) to V ] Inference Rules MP:

If φ and φ → ψ then ψ

M:

If φ is a theorem then P believes φ is a theorem Where theorem is a formula, which can be derived from axioms alone.

Apart from the axioms and rules of inference presented here, our logic contains a set of assumptions. Some of these assumptions are general whereas others are specific to protocols which are to be analyzed. For the ease of the presentation here, we discuss both kinds of assumptions in chapter 4.

CHAPTER 4

ACCOUNTABILITY FOR DISPUTE RESOLUTION

We demonstrate how our logic works by analyzing SET [8] and iKP [7], which are the real-world and widely used protocols. In section 4.1, we describe the set of assumptions of SET and iKP protocols used in the analysis. Section 4.2 and 4.3 illustrate the analysis of proving money and goods accountability, respectively. Particularly, section 4.2 shows that the results obtained from Herreweghen’s analysis [2] can also be obtained in our logic. Section 4.4 presents the discussion about accountability for resolving disputes.

4.1

Set of Assumptions of SET and iKP

From the SET and iKP protocol descriptions described in chapter 2, we state the assumption used in the analysis of SET and iKP. The assumption can be divided into general assumptions (A1-A12) and the assumptions that specific to SET and iKP (A13-A14).

Notations -

P stands for any participant.

28

-

{A, C, M} stands for a set of acquirer (or bank), client, and merchant,

respectively. -

V stands for a verifier.

-

X stands for A, C, or M.

-

CertX stands for the certificate of principle X. CertX contains (X, KX), where X is

the identity of a party X and KX stands for the public key of X.

Assumptions (A1)

Every participant believes that he has the certificates of all participants. P believes P has (CertA, CertC, CertM)

(A2)

P believes that if V has X’s certificate, he will believe that KX is the public

key of X. P believes (V has CertX → V believes ( → X)) KX

(A3)

Every participant believes that he has only his private key, and nobody

believes that he has the private keys of other participants. P believes P has K P−1

¬P believes P has ( K Q−1 , K Q−1 ) 1

2

Where Q1 and Q2 are the parties, which are different from P.

(A4)

Every participant believes that if V receives messages X and Y and the

message X is h(Y), V will believe that X is fingerprint of Y. P believes [ ( V has (X, Y) ∧ X = h(Y) ) → V believes X-is-fingerprint-of-Y ]

29

(A5)

Every participant believes that if V receives a message encrypted with key K

({X}K) and the key K’, and K’ can be used to decrypt {X}K, V will believe that K’ is the decrypting key for {X}K. P believes ( V has ({X}K, K’) ∧ X = {{X}K}K’

→ V believes K’-is-decrypting-key-for-{X}K )

The assumptions A4 and A5 are general in that they can be used for analyzing any protocol. Indeed, together with P4 and P6, the two assumptions are used to reason about the provability of hashed messages and encrypted messages.

(A6)

Every participant believes that if V has the signed message ( {X}K -1 ), the key

K, and the message X, and V believes that K is the public key of Q, then V will believe that Q has sent X. K P believes [ ( V has {X}K -1 ∧ V has (K, X) ∧ V believe ( → Q) )

→ V believes (Q says X) ]

This assumption together with axiom P2 or P2’ can be used to derive similar conclusion as the axiom P3. However, this assumption would derive the conclusion, based on verifier’s possession of some information whereas the axiom P3 would derive the conclusion, based on prover’s possession of some information.

30

No Disclosure of Private Information to Verifier (A7)

Every participant does not believe that verifier has payment information and

the private keys of all participants, order description in case of proving money authorization, and price in case of proving goods authorization.

¬P believes V has PI

where V is not acquirer.

¬P believes V has K P−1

where V is not the same party as P.

In case of Money Authorization,

¬P believes V has OD

In case of Goods Authorization,

¬P believes V has Price

By specifying the requirement “No disclosure of private information to verifier” as a set of assumptions specific to protocols, our logic formalizes intuitively the concept of the unrevealing private information to verifier when a prover proves a certain statement. This concept is essential in the accountability property for reasoning about accountability in the present of party privacy.

Internal Parties (A8)

All participants believe that they are internal parties.

R believes R’-is-internal-party

Where R and R’ stand for A, C, and M.

Sending and Receiving Messages (A9)

Every participant believes that client has sent PReq and received PRes,

merchant has sent AuthReq and received AuthRes, and acquirer has received AuthReq and sent AuthRes.

31

P believes C says PReq

P believes M sees PReq

P believes M says AuthReq

P believes A sees AuthReq

P believes A says AuthRes

P believes M sees AuthRes

P believes M says PRes

P believes C sees PRes

Client Privacy (A10) Client does not believe that merchant has payment information, and client and merchant do not believe that acquirer has order description.

¬C believes M has PI ¬Q believes A has OD

Where Q stands for client and merchant.

General Assumptions for Proving Money Authorizations (A11) Every participant believes that he can prove to verifier that if client has sent the message containing merchant’s ID, price, and the date of execution, then client has authorization on payment ordering.

P believes P CanProve [ C says (M, Price, Date)

→ C authorized payment(C, M, Price, Date) ] to V Assumptions for proving money authorizations for other primitive transactions are shown in Appendix A.

General Assumptions for Proving Goods Authorizations (A12) Every participant believes that he can prove to verifier that if client has sent the message containing merchant’s ID, order description, and the date of execution, then client has authorization on goods ordering.

32

P believes P CanProve [ C says (M, OD, Date)

→ C authorized goods-order(C, M, OD, Date) ] to V Assumptions for proving goods authorizations for other primitive transactions are shown in Appendix A.

SET Specific Assumption (A13) Client and merchant believe that they have order description and price.

Q believes Q has (OD, Price)

Where Q stands for C and M.

iKP Specific Assumptions (A14) Merchant believes that he knows order description and price because these two parameters are his own information.

Q believes Q has (OI, OD)

where Q stands for Client and Merchant.

Every participant believes that he has the identities of all participants.

P believes P has (C, M, A) After receiving AuthReq, acquirer can collect the necessary parameters to reconstruct OI.

A believes (A sees AuthReq → A has OI)

4.2

Analysis of Money Accountability of SET and iKP

Money accountability is the provability of authorizations of primitive transactions focused on the price of goods. When proving money authorization, we concern only the price can be proved to verifier. Goods description (OD) is

33

considered to be client’s private information, which should not be revealed to verifier. The following formula shows how we capture the Herreweghen’s approach [2] by using our logic:

M believes M CanProve [ C says (M, Price, Date)

→ C authorized payment(C, M, Price, Date) ] to V

If merchant believes that he can prove that client has sent merchant’s ID, price, and date of execution, then the authorization on Payment in [2] can be proved. In this section, we perform the analysis of accountability for resolving disputes of the two real-world e-commerce protocols: SET and iKP on money accountability. Recall that the money accountability is about the authorized transfer of money from customer’s account to merchant’s account. Section 4.2.1 and 4.2.2 present the analysis on this kind of accountability of SET and iKP, respectively. 4.2.1

Analysis of Money Accountability of SET In this section, we analyze the money accountability of SET. Recall

that in accountability for resolving disputes, prover is a party relevant in transaction and verifier is an external party who does not involve in transaction. We show that SET lacks of accountability because of the following two main problems: 1) Prover does not have key for decrypting the encrypted message. 2) Prover is required to reveal his private information to verifier in order to prove the statement. The source of this problem is that the required information is hashed together with the information which is considered to be private

34

information to verifier e.g. h(Price,OD) where Price is the required information and

OD is private information. To derive Price, prover is required to send both Price and OD to verifier to convince him. Thus the verifier knows the private information. In this section, we show the analysis on only one primitive transaction, which can illustrate how SET lacks of accountability as follows: The goal of proof

M believes M CanProve (C authorized payment(C, M, Price, PReqDate)) to V Where V stands for any external verifier. Outline of the proof Because this statement is the proof of the interaction between client and merchant in that merchant wants to prove to an external verifier that client wants to make the payment to him, we focus on proving PReq. We first apply axiom P3, then we can produce:

M believes M CanProve ( C says (h(OI), h(PI)) ) to V Applying axiom P6, we can produce:

M believes M CanProve (C says h(PI)) to V Since (M, Price, PReqDate) is in PI, we need to show using axiom P4 that:

M believes M CanProve (C says (M, Price, PReqDate)) to V However, the proof for M believes M CanProve (h(PI)-is-fingerprint-

of-PI) to V in rule P4 would fail since it is not the case that M believes M has K A−1 which is required to show that M believes M has (h(PI), PI). Note that PI is encrypted with K A . Note also that if it were the case that M believes M has K A−1 , the

35

proof would still fail since it would require M believes (V has PI), due to A4, which contradicts to our assumption A7. It is also easy to see that M believes M CanProve (C says OI) to V follows mainly by rules P4 and P3. Since h(OD, Price) is in OI, the proof for M

believes M CanProve (C says Price) to V may be shown by using rule P4. However, such proof would require M believes V has OD due to A4, which contradicts to our assumption A7. We perform the analysis on the two proof steps in order to show the problems of SET. The first proof step illustrates the first problem, and the second illustrates the second problem. Guideline for the proof We show how to read the proof in order to help the reader understand the proof. For example,

1, C: M believes M sees PReq

(2)

This means that this is the statement (2), and it was derived from applying statement (1) with axiom C. The Proof Step (Lacking of acquirer’s private key)

M sees PReq

(1)

1, C:

(2)

M believes M sees PReq

2, H1, M: M believes M has PReq

(3)

3, H2, M: M believes M has {h(OI), h(PI)}Kc-1

(4)

3, H2, M: M believes M has (OI, h(PI))

(5)

5, H3, M: M believes M has (h(OI), h(PI))

(6)

A1, H2, M: M believes M has KC

(7)

36

6, 7, H2, M:

M believes M has (KC, (h(OI), h(PI)))

K A1, A2, P2, M: M believes M CanProve ( → C) to V C

(8) (9)

4, 8, 9, P3, M: M believes M CanProve (C says (h(OI), h(PI))) to V

(10)

10, P6, M: M believes M CanProve (C says h(PI)) to V

(11)

3, H2, M:

M believes M has {h(OI), PI}Ka

(12)

K M believes M believes → A

(13)

A1, A2, K:

A

12, 13, H5, M: M believes M has {h(OI), PI}Ka ∧ M believes M believes K→ A ∧ A

M believes M has K A−1

→ M believes M has (h(OI), PI)

(14)

The condition ‘M believes M has K A−1 ’ contradicts the assumption A3 ‘¬M believes M has K A−1 ’. Thus the proof fails because merchant does not have acquirer’s private key.

14, H2, M: M believes M has PI

(15)

6, 15, H2, M: M believes M has (h(PI), PI)

(16)

16, A4, P2, M: M believes M has (h(PI), PI) ∧ M believes ( ( V has (h(PI), PI) ∧ h(PI) = h(PI)

→ V believes h(PI)-is-fingerprint-of-PI ) → M believes M CanProve (h(PI)-is-fingerprint-of-PI) to V

(17)

37

The condition ‘M believes V has (h(PI), PI)’ implies that ‘M believes

V has PI’. This statement contradicts assumption A7 ‘¬M believes V has PI’. Thus the proof fails because merchant has to reveal PI to verifier.

11, 17, P4, M: M believes M CanProve (C says PI) to V

(18)

18, P6:

(19)

M believes M CanProve (C says (M, Price, PReqDate)) to V

19, A11, K: M believes M CanProve (C authorized payment(C, M, Price, PReqDate)) to V (20) Proof Steps (Revealing OD to verifier)

M sees PReq

(1)

1, C:

(2)

M believes M sees PReq

2, H1, M: M believes M has PReq

(3)


(4)


(5)


(6)


(7)

6, 7, H2, M:

(8)


A1, A2, P2, M:

K M believes M CanProve ( → C) to V C

(9)


(10)

10, P6, M: M believes M CanProve (C says h(OI)) to V

(11)

5, H2, M: M believes M has OI

(12)


(13)

A1, A2, K:

M believes M believes ( → C) KC

13, 14, 7, H6, M: M believes M has (h(OI), h(PI))

(14) (15)

38

15, H2, M: M believes M has h(OI)

(16)

12, 16, H2, M: M believes M has (h(OI), OI)

(17)

17, A4, P2, M: M believes M CanProve (h(OI)-is-fingerprint-of-OI) to V

(18)

11, 18, P4, M: M believes M CanProve (C says OI) to V

(19)

19, P6, M: M believes M CanProve (C says PReqDate) to V

(20)

19, P6, M: M believes M CanProve (C says h(OD, Price)) to V

(21)

12, H2, M: M believes M has h(OD, Price)

(22)

22, A13, A4, P2, M: M believes M has (h(OD, Price), (OD, Price)) ∧ M believes ( (V has (h(OD, Price), (OD, Price)) ∧ h(OD, Price) = h(OD, Price))

→ V believes h(OD, Price)-is-fingerprint-of-(OD, Price) ) → M believes M CanProve (h(OD, Price)-is-fingerprint-of-(OD, Price)) to V (23) The condition ‘M believes V has (h(OD, Price), (OD, Price))’ implies that ‘M believes V has OD’. This statement contradicts assumption A7 ‘¬M believes

V has OD’. Thus the proof fails because merchant has to reveal OD to verifier. 21, 23, P4, M: M believes M CanProve (C says (OD, Price)) to V

(24)

20, 24, P6, M: M believes M CanProve (C says (PReqDate, Price)) to V

(25)

Other analyses of money accountability of SET protocol are shown in Appendix B.

39

4.2.2

Analysis of Money Accountability of iKP The problem of lacking of money accountability in SET does not

occur in iKP because iKP has better message format. The message format in iKP comparing with that in SET is h(Price, h(OD)) . Thus, the prover can convince the verifier about Price without revealing OD because it is hashed. In this section, we show the analysis of the same primitive transaction as that in SET in order to show that iKP has money accountability. The Goal of the Proof

M believes M CanProve (C authorized payment(C, M, Price, Date)) to V Proof Steps

M sees Payment

(1)

1, C: M believes M sees Payment

(2)

2, H1, M:

(3)

M believes M has Payment

3, H2, M: M believes M has {PI, h(OI)}Kc-1

(4)


(5)

A14, H3, M: M believes M has h(OI)

(6)


(7)

5, 6, 7, H2, M: M believes M has (KC, h(OI), PI)

(8)

A1, A2, P2, M:


(9)

4, 8, 9, P3, M: M believes M CanProve (C says (PI, h(OI))) to V

(10)


(11)

M believes M believes ( → C)

(12)

A1, A2, K:

KC

4, 7, 12, H6, M: 13, H2, M:

M believes M has (PI, h(OI))

M believes M has h(OI)

(13) (14)

40

A14, 14, H2, M: M believes M has (OI, h(OI))

(15)


(16)


(17)

17, P6, M: M believes M CanProve (C says (Price, M, Date)) to V

(18)

18, A11, K: M believes M CanProve (C authorized payment(C, M, Price, Date)) to V

(19)

Other analyses of money accountability of iKP protocol are shown in Appendix B.

4.3

Analysis of Goods Accountability of SET and iKP

We introduce a new kind of accountability “Goods Accountability” to reason about the assurance of goods. Goods accountability concerns with two parties: clients and merchants. Clients are responsible for ordering goods but merchants are responsible for delivering goods to the clients. In the goods accountability, price is considered to be merchant’s private information, which should not be revealed to verifier. With goods accountability, client and merchant have assurance on both goods ordering and goods receiving. The goods accountability property can be specified by the following formula:

M believes M CanProve [ C says (M, OD, Date)

→ C authorized goods-order(C, M, OD, Date) ] to V

41

In this section, we show that both SET and iKP lack of goods accountability. Section 4.3.1 and 4.3.2 present the analysis on this kind of accountability of SET and iKP, respectively. 4.3.1

Analysis of Goods Accountability of SET In this section, we show that SET also lacks of goods accountability

because of the same problems occurred in proving SET for money accountability. The following proofs illustrates its lacks of this kind of accountability: The goal of proof

M believes M CanProve (C authorized goods-order(C, M, OD, PReqDate)) to V Outline of the Proof Similar to the proof for M believes M CanProve (C says Price) to V discussed in section 4.2, the proof for M believes M CanProve (C authorized goods-

order(C, M, OD, PReqDate)) to V would fail since it would require M believes V has Price that contradicts to our assumption A7. Proof Steps (Lacking of acquirer’s private key)

M sees PReq

(1)


(2)

2, H1, M:

(3)

M believes M has PReq


(4)


(5)


(6)


(7)

6, 7, H2, M:

(8)


42

A1, A2, P2, M:


(9)


(10)

10, P6, M: M believes M CanProve (C says h(PI)) to V

(11)

3, H2, M:

(12)

M believes M has {h(OI), PI}Ka

K A1, A2, K: M believes M believes → A A

(13)

12, 13, H5, M: M believes M has {h(OI), PI}Ka ∧ K M believes M believes → A∧ A

M believes M has K A−1

→ M believes M has (h(OI), PI)

(14)

The condition ‘M believes M has K A−1 ’ contradicts assumption A3 ‘¬M

believes M has K A−1 ’. Thus the proof fails because merchant does not have acquirer’s private key.


(15)

6, 15, H2, M: M believes M has (h(PI), PI)

(16)

16, A4, P2, M: M believes M has (h(PI), PI) ∧ M believes ( (V has (h(PI), PI) ∧ h(PI) = h(PI)

→ V believes h(PI)-is-fingerprint-of-PI ) → M believes M CanProve (h(PI)-is-fingerprint-of-PI) to V

(17)

The condition ‘M believes V has (h(PI), PI)’ implies that ‘M believes

V has PI’. This statement contradicts assumption A7 ‘¬M believes V has PI’. Thus the proof fails because merchant has to reveal PI to verifier.

43

11, 17, P4, M: M believes M CanProve (C says PI) to V

(18)

18, P6, M: M believes M CanProve (C says (PReqDate, M, Price)) to V

(19)


(20)

5, H2, M:

(21)

M believes M has h(OD, Price)


→ V believes h(OD, Price)-is-fingerprint-of-(OD, Price) ) → M believes M CanProve (h(OD, Price)-is-fingerprint-of-(OD, Price)) to V (22) From condition ‘M believes V has (h(OD, Price), (OD, Price))’, it implies that ‘M believes V has Price’. This statement contradicts assumption A7 ‘¬M

believes V has Price’. Thus the proof fails because merchant has to reveal Price to verifier.

20, 22, P4, M: M believes M CanProve (C says (OD, Price)) to V

(23)

19, 23, P6, M: M believes M CanProve (C says (M, OD, PReqDate)) to V

(24)

24, A12, K:

M believes M CanProve (C authorized goods-order(C, M, OD, PReqDate)) to V

(25)

44

Proof Steps (Revealing Price to verifier)

M sees PReq

(1)


(2)

2, H1, M:

(3)

M believes M has PReq


(4)


(5)


(6)


(7)

6, 7, H2, M:

(8)


A1, A2, P2, M:


(9)


(10)


(11)

5, H2, M: M believes M has OI

(12)

3, H2, M:

M believes M has {h(OI), h(PI)}Kc-1

(13)

A1, A2, K: M believes M believes ( → C) KC

(14)

13, 14, 7, H6, M:

M believes M has (h(OI), h(PI))

(15)


(16)

12, 16, H2, M: M believes M has (h(OI), OI)

(17)


(18)


(19)

19, P6, M: M believes M CanProve (C says PReqDate) to V

(20)


(21)

12, H2, M: M believes M has h(OD, Price)

(22)

45


→ V believes h(OD, Price)-is-fingerprint-of-(OD, Price) ) → M believes M CanProve (h(OD, Price)-is-fingerprint-of-(OD, Price)) to V (23) The condition ‘M believes V has (h(OD, Price), (OD, Price))’ implies that ‘M believes V has Price’. This statement contradicts assumption A7 ‘¬M

believes V has Price’. Thus the proof fails because merchant has to reveal Price to verifier.

21, 23, P4, M: M believes M CanProve (C says (OD, Price)) to V

(24)

20, 24, P6, M: M believes M CanProve (C says (OD, PReqDate)) to V

(25)

The other analysis of goods accountability of SET protocol is shown in Appendix B. 4.3.2

Analysis of Goods Accountability of iKP iKP protocol lacks of goods accountability due to similar reason to

that in SET. Mainly, prover is required to reveal Price, which is his private information, to verifier. Outline of the Proof It is easy to see that M believes M CanProve (C says h(OI)) to V follows mainly by rules P3. Since (Price, h(OD) is in OI, the proof for M believes M

CanProve (C says OI) to V can be shown by using rule P4. However, such proof

46

would require M believes V has Price due to A4, which contradicts to our assumption A7. The following proof shows the lack of goods accountability of iKP: Goal of the Proof

M believes M CanProve (C authorized goods-order(C, M, OD, Date)) to V Proof Steps (Revealing Price to verifier)

M sees Payment

(1)

1, C: M believes M sees Payment

(2)

2, H1, M:

(3)

M believes M has Payment

3, H2, M: M believes M has {PI, h(OI)}Kc-1

(4)


(5)


(6)


(7)

5, 6, 7, H2, M: M believes M has (KC, h(OI), PI)

(8)

A1, A2, P2, M:

M believes M CanProve ( → C) to V KC

(9)

4, 8, 9, P3, M: M believes M CanProve (C says (PI, h(OI))) to V

(10)


(11)

M believes M believes ( → C)

(12)

A1, A2, K:

KC

4, 7, 12, H6, M: 13, H2, M:

M believes M has (h(OI), PI)

M believes M has h(OI)

A14, 14, H2, M:

M believes M has (OI, h(OI))

(13) (14) (15)

47

15, A4, P2, M: M believes M has (h(OI), OI) ∧ M believes ( (V has (h(OI), OI) ∧ h(OI) = h(OI))

→ V believes h(OI)-is-fingerprint-of-OI ) → M believes M CanProve (h(OI)-is-fingerprint-of-OI) to V

(16)

From condition ‘M believes V has (h(OI), OI)’ and OI contains Price, it implies that ‘M believes V has Price’ is true. This statement contradicts assumption A7 ‘¬M believes V has Price’. Thus the proof fails because merchant has to reveal

Price to verifier. 11, 16, P4, M: M believes M CanProve (C says OI) to V

(17)

17, P6, M: M believes M CanProve (C says (M, Date)) to V

(18)

17, P6, M: M believes M CanProve (C says h(OD)) to V

(19)

14, H2, M: M believes M has h(OD)

(20)

A14, 20, H2, M: M believes M has (h(OD), OD)

(21)

21, A4, P2, M: M believes M CanProve (h(OD)-is-fingerprint-of-OD) to V

(22)

19, 22, P4, M: M believes M CanProve (C says OD) to V

(23)

18, 23, P6, M: M believes M CanProve (C says (M, OD, Date)) to V

(24)

24, A12, K: M believes M CanProve (C authorized goods-order(C, M, OD, Date)) to V (25) The other analysis of goods accountability of iKP protocol is shown in Appendix B.

48

4.4

Discussion

The analysis of two kinds of accountability shows that SET lacks of both kinds of accountability because of its message format that combines Price and OD with in the same hash h(Price, OD). When proving money accountability, prover is required to send both Price and OD, which are the inputs of hash, to verifier in order to prove Price. Prover is also required to reveal Price to verifier in order to prove goods accountability. Proving money accountability in iKP is successful because Price and OD are separated with applying hash function e.g. h(Price, h(OD)). Verifier cannot infer OD because it is hashed. However, iKP has problem when proving goods accountability. In order to prove OD, prover is required to reveal Price to verifier. Herreweghen [2] proposed a way to solve the problem of revealing secret or private information to verifier of money accountability by an additional level of hashing. For example, we can apply hash function to OD to produce h(Price, h(OD)). This can solve such problem on money accountability only. It would be better if

Price and OD are separately hashed and then are hashed together e.g. h(h(Price), h(OD)). For proving each kind of accountability, verifier cannot infer prover’s private information because verifier receives only the hash of private information. We argue that if money accountability in [2] is sensible, goods accountability is sensible as well since goods accountability is focused on solving disputes on the mismatch between the goods which is ordered and that which is delivered, which can be occurred in practical transactions.

CHAPTER 5

GOALS OF ELECTRONIC COMMERCE PROTOCOLS AS ACCOUNTABILITY

In this chapter, we propose a novel use of the accountability for specifying and analyzing the goals of e-commerce protocols. Section 5.1 presents how to specify the goals of e-commerce protocols for all engaging parties by accountability. Section 5.2 presents how we specify the client privacy property, which is a goal of e-commerce protocols, using accountability. In section 5.3, we show that each party’s requirement on authorizations for payment transactions of SET protocol can also be captured by accountability.

5.1

Goals of SET and iKP as Accountability

In this section, we discuss the use of the accountability for specifying and analyzing the goals of SET and iKP protocols. For such kind of accountability, a verifier is an internal party, which involves in e-commerce protocols. Recall that the goal of e-commerce protocols is to ensure that all parties are convinced that they have authorized messages concerning primitive transactions relevant to them after the completion of the protocols.

50

After sending some messages to intended recipients, the originator must be able to prove the association of the originator with an intended action (or an intended message) to intended recipient(s). Such intended actions are just about primitive transactions. Such proof would ensure the originator that the intended recipients would recognize the originator’s intention regarding to primitive transactions. This intuition is formalized by axiom P2’. The axiom states explicitly the preconditions for the sending and receiving of messages. The rule also caters for the case where the intended recipient receives messages from an intermediate party. Thus, the goals of e-commerce protocols for all engaging parties can be expressed by the following: a) C believes C CanProve (C authorized payment(C, M, Price, Date)) to M b) M believes M CanProve (M authorized payment(C, M, Price, Date)) to C c) C believes C CanProve (C authorized value subtraction(A, C, Price, Date)) to A d) A believes A CanProve (A authorized value subtraction(A, C, Price, Date)) to C e) M believes M CanProve (M authorized value claim(A, M, Price, Date)) to A f)

A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M

g) C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M h) M believes M CanProve (M authorized goods-receipt(C, M, OD, Date)) to C

51

It is not hard to see that in SET these goals cannot be shown due to similar reason to those for the accountability for dispute resolving discussed in chapter 4. However, these goals can be shown for iKP. The details of the proof are shown in Appendix C. With provable authorization in the present of private information, our logic can be used to specify and analyze goals of e-commerce protocols efficiently in that the originator can ensure that the recipient recognizes the intention about primitive transaction without revealing private information. This will be much benefit to protocol designers in that he can design a protocol with intended purposes.

5.2

Client Privacy

What we demonstrate below is how client privacy property can be represented by accountability. We show that our logic can be used to analyze client privacy, which is an important goal for designing SET protocol. The client privacy is concerned with clients’ provability of their authorized payment for a transaction without revealing goods description and payment information (e.g. credit card numbers) in the transaction to banks and merchants, respectively. Thus, the client privacy can be understood as the accountability where a client is a prover, both a bank and a merchant are verifiers, and the proving statement is about the payment authorization. SET achieves client privacy if merchant cannot infer client’s payment information (PI), and acquirer cannot infer goods description (OD) from the protocol.

52

Client Privacy can be represented by accountability as the following formulae: C believes C CanProve (C authorized payment(C, M, Price, Date)) to M…(1) C believes C CanProve (C authorized value subtraction(A, C, Price, Date)) to A

…(2) 5.2.1

Analysis of Client Privacy of SET

In this section, we show that SET has client privacy by using accountability logic. What is shown below is the outline of the analysis. The details of the proof are shown in Appendix C. Outline of the Proof In order to prove (1), it suffices to show that

C believes C CanProve (C says (M, Price, PReqDate)) to M

It is easy to see that C believes C CanProve (C says (Price, PReqDate)) to M follows mainly by axioms P4 and P3. Although the proof is not successful because of the lacking of merchant’s ID, merchant cannot infer PI from the receiving message. We prove (2) in the same way as proving (1). It is not hard to see that acquirer cannot infer OD, which is client’s private information, from the receiving message. As a result, our logic can analyze client privacy, which is an essential property of SET protocol, in that verifier can get only necessary information to prove without getting any private information.

53

5.3

Each Party’s Requirement for Payment Transactions as Accountability

Meadows and Syverson [9] work on many aspects according to specifying the requirements for payment transaction of SET protocol. In our thesis, we focus on each party’s requirement on authorization for payment transaction, which is related to our work. Each party’s requirement is composed of customer requirement, merchant requirement, and gateway (or acquirer) requirement. These types of requirements are most relevant to our goals of e-commerce protocols. According to each party’s requirement in [9], MS’s work employs two predicate operators send and accept representing action and event, respectively. Action send represents the action a party sends a message to another party. Event accept represents the event a party accepts that the statement is true after being

convinced by other parties. We provide the semantics for action send action and event accept by using the accountability, which is natural and simple. MS’s operators send and accept can be simulated as follows:

Action send(S, R, CM) can be simulated by S believes S CanProve ( S authorized PM ) to R Where -

S and R stand for sender and receiver of message, respectively.

-

PM and CM stand for plain message and cipher message, respectively.

54

Action send(S, R, CM) means that S sends a cipher message CM to R. It can be simulated by the statement S believes S CanProve ( S authorized PM ) to R since in order to convince R (a verifier) about the statement PM, S (a prover) is required to send a cipher message CM to R. After that R can infer that S authorized PM.

Event accept(P, req-complete(Y)) can be simulated by X believes X CanProve ( req-complete(Y)) to P Where -

P stands for a party and X stands for any party(ies).

-

req-complete(Y) means that the requirement with a set of relevant

parameters Y is complete. The event accept(P, req-complete(Y)) means that a party P accepts to other parties that the his requirement relevant to transaction is complete. It can be simulated by using our logic by the statement X believes X CanProve ( reqcomplete(Y)) to P since P is convinced by other party(ies) X that the statement reqcomplete(Y) is true. To represent MS’s each party’s requirement by accountavility, we transform the intuition of MS’s party’s requirements in to the concept and then we capture such concept by accountability. We show how MS’s each party’s requirement can be simulated by accountability as the following: Notations -

X, X’, X’’ stand for any party(ies).

55

-

cust-req-complete(Y) means that the customer requirement relevant to the transaction is complete.

-

merchant-req-complete(Y) means that the merchant requirement relevant to the transaction is complete.

-

gw-req-complete(Y) means that the gateway requirement relevant to the transaction is complete.

Customer Requirement Customer requirement can be simulated by accountability as the following: If X believes X CanProve cust-req-complete(C, M, OD, Price, Date) to C then C believes C CanProve (C authorized payment(C, M, Price, Date)) to M, C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M X’ believes X’ CanProve gw-req-complete(A, C, M, Price, Date) to A X’’ believes X’’ CanProve merchant-req-complete(C, M, Price, OD, Date) to M M believes M CanProve (M authorized payment(C, M, Price, Date)) to C M believes M CanProve (M authorized goods-receipt(C, M, OD, Date)) to C

This means that if customer C is convinced that C’s requirement is complete, then the authorized request for C’s payment and the authorized acknowledgement for ordered goods must be issued. The details of using accountability to simulate the customer requirement are as follows:

56

The statement, - send(merchant(Q, [X]), customer(P, [honest]), merch_respsend(V), N?) can be simulated by M believes M CanProve (M authorized payment(C, M, Price, Date)) to C M believes M CanProve (M authorized goods-receipt(C, M, OD, Date)) to C

The statement, ∃V’((cust_accept(V) ~ merch_resp(V’)) ∧ - accept(merchant(Q, [honest]), customer(P, [honest]), merch_resp(V’), N?))) can be simulated by X’’ believes X’’ CanProve merchant-req-complete(C, M, Price, OD, Date) to M

The statement, ∃V’((cust_accept(V) ~ apg_resp(V’)) ∧ - accept(gateway(R, [honest]), customer(P, [honest]), apg_resp(V’), N?))) can be simulated by X’ believes X’ CanProve gw-req-complete(A, C, M, Price, Date) to A

The statement, - send(customer(P,[honest]), merchant(Q,[X]), cust_reqsend(V), N) can be simulated by

57

C believes C CanProve (C authorized payment(C, M, Price, Date)) to M, C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M

Merchant Requirement Merchant requirement can be simulated by accountability as the following: If X believes X CanProve merchant-req-complete(C, M, Price, OD, Date) to M then C believes C CanProve ( C authorized payment(C, M, Price, Date) ) to M C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M M believes M CanProve (M authorized value claim(A, M, Price, Date)) to A A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M X’ believes X’ CanProve (gw-req-complete(A, C, M, Price, Date)) to A

This means that if merchant M is convinced that M’s requirement is complete, then authorized request for M’s value claim and authorized acknowledgement for transferring money to M’s account must be issued. The details of using accountability to simulate the merchant requirement are as follows: The statement, - send(gateway(R,

[honest]),

(customer(P,

[honest]),

merchant(Q,

[honest])), apg_respsend(V), N?) can be simulated by A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M

58

The statement, - send(merchant(Q, [honest]), gateway(R, [honest]), merch_reqsend(V), N?) can be simulated by M believes M CanProve (M authorized value claim(A, M, Price, Date)) to A

The statement, ∃V’((apg_resp(V’) ~ merch_resp(V)) ∧ - accept(gateway(R,

[honest]),

(customer(P,

[honest]),

merchant(Q,

[honest])), apg_resp(V’), N?)) can be simulated by X’ believes X’ CanProve (gw-req-complete(A, C, M, Price, Date)) to A

The statement, ∃V’((cust_reqsend(V’) ~ merch_req(V)) ∧ - send(customer(P, [honest]), merchant(Q, [honest])), cust_reqsend(V’), N)) can be simulated by C believes C CanProve ( C authorized payment(C, M, Price, Date) ) to M C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M

59

Gateway Requirement Gateway requirement can be simulated by accountability as the following: If X believes X CanProve (gw-req-complete(A, C, M, Price, Date)) to A then C believes C CanProve (C authorized value subtraction(A, C, Price, Date)) to A M believes M CanProve (M authorized value claim(A, M, Price, Date)) to A A believes A CanProve (A authorized value subtraction(A, C, Price, Date)) to C A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M

This means that if gateway A is convinced that A’s requirement is complete, then both authorized request for C’s value subtraction and M’s value claim and the authorized acknowledgement for both transaction must be issued. In other words, gateway has successfully done the services relevant to transactions. The details of using accountability to simulate the gateway requirement are as follows: The statement, - send(customer(P, [X]), merchant(Q, [Y]), cust_reqsend(V), N?) ∧ ( send(merchant(Q, [X]), (gateway(R, [honest]), merch_reqsend(V), N?))

can be simulated by C believes C CanProve (C authorized value subtraction(A, C, Price, Date)) to A M believes M CanProve (M authorized value claim(A, M, Price, Date)) to A

60

We add the statement A believes A CanProve (A authorized value subtraction(A, C, Price, Date)) to C and A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M into the representation of gateway requirement since our specification aims to capture the essential property representing each party’s requirement on authorizations. This is opposed to MS’s work [9] which captures the occurrence of events in a protocol.

5.4

Discussion

Accountability can be used to specify and analyze the goals of e-commerce protocols. We have shown that many aspects about the goals of e-commerce protocols can be represented by the accountability. These aspects include the goals for all engaging parties, the client privacy property, and each party’s requirement on authorization for payment transactions. With the goals of e-commerce protocols for all engaging parties, it is intuitive in that, in designing a new e-commerce protocol, the designer wants the protocol to achieve its goals after the completion of protocol. In each protocol step, the recipient of message wants to get the necessary information concerning transaction. Accountability can be helpful for the designer in analyzing this. We can extend the goals for all engaging parties to specify the client privacy property in that we focus on the interaction between client and merchant and between client and acquirer. Each party’s requirement on authorization for payment

61

transactions, which is considered to be another aspect of goals of e-commerce protocols, can also be specified by accountability. The difference between our work and MS’s work is that our specification aims to capture the essential property representing each party’s requirement on authorizations. This is opposed to MS’s work which captures the occurrence of events in a protocol. Thus, our work is more general than Meadow in a way.

CHAPTER 6

DISCUSSION

6.1

Discussion

In this thesis, we study accountability property on both for resolving disputes and specifying goals of e-commerce protocols. We propose the modification of existing logics for analyzing real-world e-commerce protocols. Our concept of provable authorization in the present of private information is general and sensible in that in proving some statements, prover does not want to reveal the unnecessary private information to verifier. Our logic is adequate for both resolving disputes and specifying and analyzing goals of e-commerce protocols. For resolving disputes, our logic is more practical than the existing logics [1][3] in that it can analyze the real-world ecommerce protocols, which consists of the multiply encrypted and/or hashed messages which are signed whereas Kailar’s logic [1] can analyze just signed plain messages. Our logic can be used to resolve disputes on both money and goods. Moreover, the results obtained from the informal analysis [2] can also be obtained from our logic. The goals of e-commerce protocols can be represented by our accountability logic. We show that client privacy property, which is one of the goals of e-commerce

63

protocols, can be represented by accountability. We also demonstrate the analysis of client privacy. Moreover, we can specify each party’s requirement on authorization for payment transactions of SET [9] using accountability.

6.2

Future Work

In this thesis, we apply accountability for analyzing SET and iKP protocols, which is credit-card based e-commerce payment protocols. As a future work, we aim to apply our logic to analyze other kinds of e-commerce protocols, e.g. micropayment protocols. Our analysis is implemented manually. Thus we aim to study an automated tool for our logic.

CHAPTER 7

CONCLUSION

In this thesis, we show that accountability is not just a property for resolving disputes but a fundamental and critical property for analyzing e-commerce protocols. In particular, the accountability can be used not only for dispute resolution, but also for specifying and analyzing goals of e-commerce protocols. We then develop a logic which extends existing logics for the accountability to deal with real-world ecommerce protocols. For reasoning about dispute resolution, we show that the existing logics for reasoning about accountability are inadequate to deal with real world e-commerce protocols. We show formally that SET lacks of the money accountability whereas iKP does not. Moreover, we show that both SET and iKP lack of the goods accountability. The lack of the goods accountability in our sense means that the two protocols can still provide enough evidence tokens to resolve disputes on goods description, but in order to resolve such disputes, provers must reveal their private information to verifiers. In some situations, this is undesirable. Furthermore, we demonstrate the practicality of our logic by showing that the result obtained from Herreweghen’s informal analysis [2] can be also obtained formally from our logic. For reasoning about the goals of e-commerce protocols, we show that accountability can be used to specify and analyze the client privacy property and

65

each party’s requirement on authorization for payment transactions of SET. We show that such kind of reasoning can be considered as a special case of the accountability.

REFERENCES

[1]

Kailar, R., “Accountability in Electronic Commerce Protocols,” IEEE Transaction on Software Engineering 1996.

[2]

Herreweghen, E. V., “Non-Repudiation in SET: Open Issues,” Proceedings of the Financial Cryptography, 1999.

[3]

Kessler, V. and Neumann, H., “A Sound Logic for Analyzing Electronic Commerce Protocols,” Proceedings of ESORICS’98.

[4]

Herreweghen, E. V., “Using Digital signatures as Evidence of Authorizations in Electronic Credit-Card Payments,” Research Report 3156, IBM Research, June 1999.

[5]

Asokan, N., Herreweghen, E. V., and Steiner, M., “Towards A Framework for Handling Disputes in Payment Systems,” Proceedings of the 3rd USENIX Workshop on Electronic Commerce, Boston, Massachusette, August31-September3, 1998.

[6]

Burrows, M., Abadi, M., and Needham, R. M., “A Logic of Authentication,” ACM Transactions in Computer Systems, February 1990.

67

[7]

Bellare, M., Garay, J. A., Hauser, R., Herzberg, A., Krawczyk, H., Steiner, M., Tsudik, G., Herreweghen, E. V., and Waidner, M., “Design, Implementation, and Deployment of the iKP Secure Electronic Payment System,” IEEE Journal of Selected Areas in Communications, 2000.

[8]

Mastercard and Visa, May 1997, “SET Secure electronic Transaction Protocol, version 1.0 edition, Book One: Business Specifications, Book Two: Technical Specifications, and Book Three: Formal Protocol Protocol Definition,” http://www.setco.org/set_specifications.html

[9]

Meadows, C. and Syverson, P., “A Formal Specification of Requirements for Payment Transactions in the SET Protocol,” Proceedings of Financial Cryptography, February 1998.

[10]

Stallings, W., 1998, Cryptography and Network Security: Principles and Practices, New Jersey, Prentice Hall, pp. 461-472.

[11]

Burrows, M., Abadi, M., and Needham, R. M., “A Logic of Authentication,” Rep. 39, Digital Equipment Corporating Systems Research Center, Palo Alto, calif., February 1989.

[12]

Kessler, V. and Wedel, G., “AUTLOG – An Advanced Logic of Authentication,” Proceedings of the 7th Computer Security Foundation Workshop, Franconia, IEEE Computer Society Press 1994, pp. 90-99.

68

[13]

Wedel, G. and Kessler, V., “Formal Semantics for Authentication Logics,” Proceedings of ESORICS 96, Rome, Springer LNCS 1146, 1996, pp. 219241.

[14]

S. Glassman. The Millicent Protocol for Inexpensive Electronic Commerce. World Wide Web Journal, Fourth International World Wide Web Conference Proceeding, December 1995, pp. 603-618.

[15]

Kungpisdan, S. and Permpoontanalarp, Y., “A Logic for Solving Disputes in Electronic Commerce,” Proceedings of the 24th Electrical Engineering Conference, November 22-23, 2001, Thailand.

[16]

Kungpisdan, S. and Permpoontanalarp, Y., “Practical Reasoning about Accountability in Electronic Commerce Protocols,” Proceedings of the 4th International Conference on Information Security and Cryptology, December 6-7, 2001, Seoul, Korea.

Appendix A General Assumptions for Proving Money and Goods Authorizations

70

A.1

General Assumptions for Proving Money Authorizations

Every participant believes that he can prove to verifier that if merchant has sent the message containing client’s ID, price, and the date of execution, then merchant has authorization on payment receipt.

P believes P CanProve [ M says (C, Price, Date)

→ M authorized payment(C, M, Price, Date) ] to V

Every participant believes that he can prove to verifier that if acquirer has sent the message containing client’s ID, price, and the date of execution, then acquirer has authorization on value subtraction.

P believes P CanProve [ A says (C, Price, Date)

→ A authorized value subtraction(A, C, Price, Date) ] to V

Every participant believes that he can prove to verifier that if client has sent the message containing acquirer’s ID, price, and the date of execution, then client has authorization on value subtraction.

P believes P CanProve [ C says (A, Price, Date)

→ C authorized value subtraction(A, C, Price, Date) ] to V

71

Every participant believes that he can prove to verifier that if acquirer has sent the message containing merchant’s ID, price, and the date of execution, then acquirer has authorization on value claim.

P believes P CanProve [ A says (M, Price, Date)

→ A authorized value claim(A, M, Price, Date) ] to V

Every participant believes that he can prove to verifier that if merchant has sent the message containing acquirer’s ID, price, and the date of execution, then merchant has authorization on value claim.

P believes P CanProve [ M says (A, Price, Date)

→ M authorized value claim(A, M, Price, Date) ] to V

72

A.2 General Assumptions for Proving Goods Authorizations Every participant believes that he can prove to verifier that if merchant has sent the message containing merchant’s ID, order description, and the date of execution, then merchant has authorization on goods receipt.

P believes P CanProve [ M says (C, OD, Date)

→ M authorized goods-receipt(C, M, OD, Date) ] to V

Appendix B Analysis of Accountability for Dispute Resolution of SET and iKP

74

B.1

Analysis of Money Accountability on SET

The Goal of the Proof C believes C CanProve (M authorized payment(M, C, Price, AuthDate)) to V Proof Steps (Lacking of client’s ID and Price) C sees PRes

(1)

1, C:

(2)

C believes C sees PRes

2, H1, M: C believes C has PRes

(3)

3, H2, M: C believes C has {TID, AuthDate}Km-1

(4)

A1, H3, M: C believes C has KM

(5)

A1, A2, K:

C believes C believes ( → M) KM

4, 5, 6, H6, M:

(6)

C believes C has (TID, AuthDate)

(7)

C believes C has (KM, TID, AuthDate)

(8)

A1, A2, P2, M:

C believes C CanProve ( K→ M) to V

(9)

4, 8, 9, P3, M:

C believes C CanProve (M says (TID, AuthDate)) to V

5, 7, H2, M:

10, P6, M:

M

C believes C CanProve (M says AuthDate) to V

(10) (11)

The proof fails because client cannot prove to verifier that M says (C, Price, AuthDate). It lacks of client’s ID and Price.

75

The Goal of the Proof A believes A CanProve (C authorized value subtraction(C, A, Price, PReqDate)) to V Proof Steps (Revealing PI to verifier) A sees AuthReq

(1)

1, C: A believes A sees AuthReq

(2)

2, H1, M:

(3)

A believes A has AuthReq K A believes A believes → A

A1, A2, K:

(4)

A

3, 4, A3, H5, M: A believes A has { TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka }Km-1

(5)

A1, H2, M: A believes A has KM

(6)

A1, A2, K:

A believes A believes ( → M) KM

(7)

5, 6, 7, H6, M: A believes A has ( TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka ) 8, H2, M: A1, H2, M: 8, H2, M:

A believes A has {h(OI), h(PI)}Kc-1 A believes A has KC

(9) (10)

A believes A has {h(OI), PI}Ka

11, 4, A3, H5, M: 12, H3, M:

(8)

A believes A has (h(OI), PI)

A believes A has (h(OI), h(PI))

10, 13, H2, M: A believes A has (KC, (h(OI), h(PI)))

(11) (12) (13) (14)

A believes A CanProve ( → C) to V

(15)

9, 14, 15, P3, M: A believes A CanProve (C says (h(OI), h(PI))) to V

(16)

A1, A2, P2, M:

KC

76

16, P6, M: A believes A CanProve (C says h(PI)) to V

(17)

K A1, A2, K: A believes A believes ( → C)

(18)

9, 18, 10, H6, M: A believes A has (h(OI), h(PI))

(19)

19, H2, M: A believes A has h(PI)

(20)

12, H2, M: A believes A has PI

(21)

20, 21, H2, M: A believes A has (h(PI), PI)

(22)

C

22, A4, P2, M: A believes A has (h(PI), PI) ∧ A believes ( (V has (h(PI), PI) ∧ h(PI) = h(PI))

→ V believes h(PI)-is-fingerprint-of-PI ) → A believes A CanProve (h(PI)-is-fingerprint-of-PI) to V

(23)

The condition ‘A believes V has (h(PI), PI)’ implies that ‘A believes V has PI’. This statement contradicts assumption A7 ‘¬A believes V has PI’. Thus the proof fails because acquirer has to reveal PI to verifier. 17, 23, P4, M: A believes A CanProve (C says PI) to V

(24)

24, P6, M: A believes A CanProve (C says (Price, PReqDate)) to V

(25)

Even though A cannot prove that C says acquirer’s ID to V, it is not the problem that leads to dispute since A is the only one who can decrypt the message encrypted with A’s private key. It implies implicitly that verifier can infer acquirer’s ID. Proving this authorization is successful.

77

The Goal of the Proof C believes C CanProve (A authorized value subtraction(A, C, Price, AuthDate)) to V

C cannot prove this authorization to verifier because there is no message signed with the acquirer’s private key.

The Goal of the Proof A believes A CanProve (M authorized value claim(M, A, Price, AuthReqDate)) to V Proof Steps A sees AuthReq

(1)


(2)

2, H1, M:

A believes A has AuthReq

(3)

A1, A2, K:

K A believes A believes → A

(4)

A

3, 4, A3, H5, M: A believes A has { TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka }Km-1

(5)


(6)

A1, A2, K:

KM

A believes A believes ( → M)

(7)

5, 6, 7, H6, M: A believes A has ( TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka )

(8)

78

6, 8, H2, M: A believes A has ( KM, TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka ) A1, A2, P2, M:

(9)

A believes A CanProve ( → M) to V KM

(10)

5, 9, 10, P3, M: A believes A CanProve (M says ( TID, Price, AuthReqDate, h(OI), OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka ) ) to V 11, P6, M: A believes A CanProve (M says (Price, AuthReqDate)) to V

(11) (12)

Even though A cannot prove that M says acquirer’s ID to V, it is not the problem that leads to dispute since A is the only one who can decrypt the message encrypted with A’s private key. It implies implicitly that verifier can infer acquirer’s ID. Proving this authorization is successful.

The Goal of the Proof M believes M CanProve (A authorized value claim(A, M, Price, AuthDate)) to V Proof Steps (Lacking of merchant’s ID) M sees AuthRes

(1)

1, C:

(2)

M believes M sees AuthRes

2, H1, M:

M believes M has AuthRes

A1, A2, K:

M believes M believes → M

KM

3, 4, A3, H5, M:

M believes M has {TID, Price, AuthDate}Ka-1

A1, H2, M: M believes M has KA A1, A2, K:

(3) (4) (5) (6)

KA

M believes M believes ( → A)

(7)

79

5, 6, 7, H6, M: 6, 8, H2, M:

M believes M has (TID, Price, AuthDate)

(8)

M believes M has (KA, TID, Price, AuthDate)

(9)

A1, A2, P2, M:

KA

M believes M CanProve ( → A) to V

(10)

5, 9, 10, P3, M: M believes M CanProve (A says (TID, Price, AuthDate)) to V (11) 11, P6, M: M believes M CanProve (A says (Price, AuthDate)) to V

(12)

The proof fails because merchant cannot prove to verifier that A says (M, Price, AuthDate). It lacks of merchant’s ID.

80

B.2

Analysis of Goods Accountability on SET

Goal of the Proof C believes C CanProve (M authorized goods-receipt(M, C, Price, AuthDate)) to V Proof Steps (Lacking of client’s ID and OD) C sees PRes

(1)

1, C:

(2)

C believes C sees PRes

2, H1, M: C believes C has PRes

(3)

3, H2, M: C believes C has {TID, AuthDate}Km-1

(4)


(5)

K A1, A2, K: C believes C believes ( → M)

(6)

4, 5, 6, H6, M:

C believes C has (TID, AuthDate)

(7)

C believes C has (KM, TID, AuthDate)

(8)

C believes C CanProve ( K→ M) to V

(9)

M

5, 7, H2, M:

A1, A2, P2, M:

M

4, 8, 9, P3, M: C believes C CanProve (M says (TID, AuthDate)) to V

(10)

10, P6, M: C believes C CanProve (M says AuthDate) to V

(11)

The proof fails because client cannot prove to verifier that M says (C, OD, AuthDate). It lacks of client’s ID and OD.

81

B.3

Analysis of Money Accountability on iKP

Goal of the Proof C believes C CanProve (M authorized payment(M, C, Price, Date)) to V Proof Steps M sees Confirm

(1)

1, C:

(2)

C believes C sees Confirm

2, H1, M:

C believes C has Confirm

(3)

3, H2, M: C believes C has {h(OI)}Km-1

(4)

A14, H2, M: C believes C has h(OI)

(5)


(6)

5, 6, H2, M: C believes C has (KM, h(OI))(7) A1, A2, P2, M:

C believes C CanProve ( → M) to V KM

(8)

4, 7, 8, P3, M: C believes C CanProve (M says h(OI)) to V

(9)

C believes C believes ( K→ M)

(10)

A1, A2, K:

M

4, 6, 10, H6, M:

C believes C has h(OI)

(11)

A14, 11, H2, M:

C believes C has (OI, h(OI))

(12)

12, A4, P2, M: C believes C CanProve (h(OI)-is-fingerprint-of-OI) to V

(13)

9, 13, P4, M: C believes C CanProve (M says OI) to V

(14)

14, P6, M: C believes C CanProve (M says (Price, C, Date)) to V

(15)

15, A11, K: C believes C CanProve (M authorized payment(M, C, Price, Date)) to V (16)

Proving this authorization is successful.

82

Goal of the Proof A believes A CanProve (C authorized value subtraction(C, A, Price, Date)) to V Proof Steps A sees AuthReq

(1)


(2)

2, H1, M:

(3)


3, H2, M: A believes A has {h(OI), PI}Kc-1

(4)

3, H2, M: A believes A has (h(OI), PI)

(5)

A1, H2, M: A believes A has KC

(6)

5, 6, H2, M:

A believes A has (KC, h(OI), PI)

A1, A2, P2, M:

K A believes A CanProve ( → C) to V C

4, 7, 8, P3, M: A believes A CanProve (C says (h(OI), PI)) to V

(7) (8) (9)

9, P6, M: A believes A CanProve (C says h(OI)) to V

(10)

3, A14, K:

(11)

A believes A has OI

K C) A1, A2, K: A believes A believes ( →

(12)

4, 6, 12, H6, M:

(13)

C

13, H2, M:

A believes A has (h(OI), PI)

A believes A has h(OI)

(14)

11, 14, H2, M: A believes A has (h(OI), OI)

(15)

15, A4, P2, M: A believes A CanProve (h(OI)-is-fingerprint-of-OI) to V

(16)

10, 16, P4, M: A believes A CanProve (C says OI) to V

(17)

17, P6, M: A believes A CanProve (C says (Price, Date)) to V

(18)

Even though A cannot prove that C says acquirer’s ID to V, it is not the problem that leads to dispute since A is the only one who can decrypt the message

83

encrypted with A’s private key. It implies implicitly that verifier can infer acquirer’s ID. Proving this authorization is successful.

Goal of the Proof C believes C CanProve (A authorized value subtraction(A, C, Price, Date)) to V Proof Steps C sees Confirm

(1)

1, C:

(2)


2, H1, M:


(3)

3, H2, M: C believes C has {AI, h(OI)}Ka-1

(4)


(5)

3, H2, M: C believes C has AI

(6)

A1, H2, M: C believes C has KA

(7)

5, 6, 7, H2, M: C believes C has (KA, AI, h(OI))

(8)

A1, A2, P2, M:

K C believes C CanProve ( → A) to V

4, 8, 9, P3, M:

C believes C CanProve (A says (AI, h(OI))) to V

A

(9) (10)

10, P6, M: C believes C CanProve (A says h(OI)) to V

(11)

K A1, A2, K: C believes C believes ( → A)

(12)

4, 7, 12, H6, M:

(13)

A

C believes C has (AI, h(OI))

13, H1, M: C believes C has h(OI)

(14)

A14, 14, H2, M: C believes C has (OI, h(OI))

(15)

15, A4, P2, M: C believes C CanProve (h(OI)-is-fingerprint-of-OI) to V

(16)

11, 16, P4, M: C believes C CanProve (A says OI) to V

(17)

84

17, P6, M: C believes C CanProve (A says (Price, C, Date)) to V

(18)

18, A11, K: C believes C CanProve (A authorized value subtraction(A, C, Price, Date)) to V (19) Proving this authorization is successful.

Goal of the Proof A believes A CanProve (M authorized value claim(M, A, Price, Date)) to V Proof Steps A sees AuthReq

(1)


(2)

2, H1, M:

(3)


3, H2, M: A believes A has {h(OI)}Km-1

(4)

3, H2, M: A believes A has h(OI)

(5)


(6)

5, 6, H2, M:

(7)

A believes A has (KM, h(OI))

A1, A2, P2, M:

A believes A CanProve ( → M) to V KM

4, 7, 8, P3, M: A believes A CanProve (M says h(OI)) to V 3, A14, K:

A believes A has OI

(8) (9) (10)

K M) A1, A2, K: A believes A believes ( →

(11)

4, 6, 11, H6, M:

(12)

M

A believes A has h(OI)

10, 12, H2, M: A believes A has (h(OI), OI)

(13)

13, A4, P2, M: A believes A CanProve (h(OI)-is-fingerprint-of-OI) to V

(14)

9, 14, P4, M: A believes A CanProve (M says OI) to V

(15)

85

15, P6, M: A believes A CanProve (M says (Price, Date)) to V

(16)


Goal of the Proof M believes M CanProve (A authorized value claim(A, M, Price, Date)) to V Proof Steps M sees AuthRes

(1)

1, C:

(2)

M believes M sees AuthRes

2, H1, M:

M believes M has AuthRes

(3)

3, H2, M: M believes M has {AI, h(OI)}Ka-1

(4)

3, H2, M: M believes M has AI

(5)


(6)

A1, H2, M: M believes M has KA

(7)

5, 6, 7, H2, M: M believes M has (KA, h(OI), AI)

(8)

A1, A2, P2, M:

K A) to V M believes M CanProve ( → A

(9)

4, 8, 9, P3, M: M believes M CanProve (A says (AI, h(OI))) to V

(10)

10, P6, M: M believes M CanProve (A says h(OI)) to V

(11)

K A1, A2, K: M believes M believes ( → A)

(12)

4, 7, 12, H6, M:

(13)

A

M believes M has (AI, h(OI))


(14)

86

A14, 14, H2, M:

M believes M has (OI, h(OI))

(15)


(16)

11, 16, P4, M: M believes M CanProve (A says OI) to V

(17)

17, P6, M: M believes M CanProve (A says (Price, M, Date)) to V

(18)

18, A11, K: M believes M CanProve (A authorized value claim(A, M, Price, Date)) to V (19) Proving this authorization is successful.

87

B.4

Analysis of Goods Accountability on iKP

Goal of the Proof C believes C CanProve (M authorized goods-receipt(M, C, OD, Date)) to V Proof Steps (Revealing Price to verifier) M sees Confirm

(1)

1, C:

(2)


2, H1, M:


(3)

3, H2, M: C believes C has {h(OI)}Km-1

(4)


(5)


(6)

C believes C has (KM, h(OI))

5, 6, H2, M:

A1, A2, P2, M:

(7)

C believes C CanProve ( K→ M) to V M

4, 7, 8, P3, M: C believes C CanProve (M says h(OI)) to V A1 A2, K:

C believes C believes ( → M) KM

(8) (9) (10)

4, 6, 10, H6, M:

C believes C has h(OI)

(11)

A14, 11, H2, M:

C believes C has (OI, h(OI))

(12)

12, A4, P2, M: C believes C has (h(OI), OI) ∧ C believes ( (V has (h(OI), OI) ∧ h(OI) = h(OI))

→ V believes h(OI)-is-fingerprint-of-OI ) → C believes C CanProve (h(OI)-is-fingerprint-of-OI) to V

(13)

From condition ‘C believes V has (h(OI), OI)’ and OI contains Price, it implies that ‘C believes V has Price’ is true. This statement contradicts assumption

88

A7 ‘¬C believes V has Price’. Thus the proof fails because merchant has to reveal Price to verifier. 9, 13, P4, M: C believes C CanProve (M says OI) to V

(14)

14, P6, M: C believes C CanProve (M says (C, Date)) to V

(15)

14, P6, M: C believes C CanProve (M says h(OD)) to V

(16)

A14, H3, M:

(17)

C believes C has (h(OD), OD)

17, A4, P2, M: C believes C CanProve (h(OD)-is-fingerprint-of-OD) to V

(18)

16, 18, P4, M: C believes C CanProve (M says OD) to V

(19)

15, 19, P6, M: C believes C CanProve (M says (C, OD, Date)) to V

(20)

20, A12, K: C believes C CanProve (M authorized goods-receipt(M, C, OD, Date)) to V (21)

Appendix C Accountability for Specifying and Analyzing Goals of Electronic Commerce Protocols

90

C.1

Analysis of Goals for All Engaging Parties of SET

Goal of the Proof C believes C CanProve (C authorized payment(C, M, Price, PReqDate)) to M Proof Steps (Lacking of merchant’s ID) C says PReq

(1)

1, C2: C believes C says PReq

(2)

2, SA2, M: C believes C has PReq

(3)

3, H2, M: C believes C has {h(OI), h(PI)}Kc-1

(4)

3, H2, M: C believes C has (OI, h(PI))

(5)

5, H3, M: C believes C has (h(OI), h(PI))

(6)

A1, H2, M: C believes C has KC

(7)

6, 7, H2, M: C believes C has (KC, (h(OI), h(PI)))

(8)

K 2, A8, A9, P2’, M: C believes C CanProve ( → C) to M

(9)

C

4, 8, 9, P3, M: C believes C CanProve (C says (h(OI), h(PI))) to M

(10)

10, P6, M: C believes C CanProve (C says h(OI)) to M

(11)

2, SA1, M: C believes C says (OI, {h(OI), h(PI)}Kc-1)

(12)

A9, SE1, M:

C believes M sees (OI, {h(OI), h(PI)}Kc-1)

(13)

12, A8, 13, A4, P2’, M: C believes C CanProve (h(OI)-is-fingerprint-of-OI) to M

(14)

11, 14, P4, M: C believes C CanProve (C says OI) to M

(15)

15, P6, M: C believes C CanProve (C says PReqDate) to M

(16)

15, P6, M: C believes C CanProve (C says h(OD, Price)) to M

(17)

12, SA1, M:

(18)

C believes C says h(OD, Price)

91

A9, SE1, M:

C believes M sees h(OD, Price)

(19)

18, A8, 19, A4, P2’, M: C believes C CanProve (h(OD, Price)-is-fingerprint-of-(OD, Price)) to M (20) 17, 20, P4, M: C believes C CanProve (C says (OD, Price)) to M

(21)

16, 21, P6, M: C believes C CanProve (C says (Price, PReqDate)) to M

(22)

The proof fails because client cannot prove to merchant that C says (M, Price, PReqDate). It lacks of merchant’s ID.

Goal of the Proof M believes M CanProve (M authorized payment(M, C, Price, AuthDate)) to C Proof Steps (Lacking of client’s ID and Price) M says PRes

(1)

1, C2: M believes M says PRes

(2)

2, SA1, M: M believes M has PRes

(3)

A1, H2, M: M believes M has KM

(4)

A1, A2, K: M believes M believes ( → M)

(5)

3, 4, 5, H6, M: M believes M has (TID, AuthDate)

(6)

KM

4, 6, H2, M:

M believes M has (KM, TID, AuthDate)

(7)

K 2, A8, A9, P2’, M: M believes M CanProve ( → M) to C

(8)

3, 7, 8, P3, M: M believes M CanProve (M says (TID, AuthDate)) to C

(9)

M

9, P6, M:

M believes M CanProve (M says AuthDate) to C

(10)

The proof fails because merchant cannot prove to client that M says (C, Price, AuthDate. It lacks of client’s ID and Price.

92

Goal of the Proof C believes C CanProve (C authorized value subtraction(C, A, Price, PReqDate)) to A Proof Steps C says PReq

(1)


(2)


(3)


(4)


(5)


(6)


(7)


(8)

2, SA1, M: C believes C says (OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

(9)

A9, SE1, M:

C believes A sees (OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

9, A8, 10, P2’, M:

K C believes C CanProve ( → C) to A C

(10) (11)

4, 8, 11, P3, M: C believes C CanProve (C says (h(OI), h(PI))) to A

(12)

12, P6, M: C believes C CanProve (C says h(PI)) to A

(13)

2, SA1, M: C believes C says ({h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

(14)

10, SE1, M: C believes A sees ({h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

(15)

13, A8, 15, A4, P2’, M: C believes C CanProve (h(PI)-is-fingerprint-of-PI) to A

(16)

13, 16, P4, M: C believes C CanProve (C says PI) to A

(17)

17, P6, M: C believes C CanProve (C says (Price, PReqDate)) to A

(18)

93

Even though A cannot prove that C says acquirer’s ID to V, it is not the problem that leads to dispute since A is the only one who can decrypt the message encrypted with A’s private key. It implies implicitly that verifier can infer acquirer’s ID. Proving this authorization is successful.

Goal of the Proof A believes A CanProve (A authorized value subtraction(A, C, Price, AuthDate)) to C Acquirer cannot prove AuthRes because he does not have merchant’s private key. SET cannot achieve the goal for this authorization.

Goal of the Proof M believes M CanProve (M authorized value claim(M, A, Price, AuthReqDate)) to A Proof Steps M says AuthReq

(1)

1, C2: M believes M says AuthReq

(2)

2, A8, A9, A6, P2’, M: M believes M CanProve (M says (TID, Price, AuthReqDate, h(OI), OI,{h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)) to A 3, P6, M:

M believes M CanProve (M says (Price, AuthReqDate) to A

(3) (4)

Even though A cannot prove that M says acquirer’s ID to V, it is not the problem that leads to dispute since A is the only one who can decrypt the message

94


Goal of the Proof A believes A CanProve (A authorized value claim(A, M, Price, AuthDate)) to M Proof Steps (Lacking of merchant’s ID) A says AuthRes

(1)

1, C2: A believes A says AuthRes

(2)

2, A8, A9, A6, P2’, M: A believes A CanProve (A says (TID, Price, AuthDate)) to M 3, P6, M:

A believes A CanProve (A says (Price, AuthDate) to M

(3) (4)

The proof fails because acquirer cannot prove to merchant that A says (M, Price, AuthDate). It lacks of MerchantID. SET fails for this authorization.

Goal of the Proof C believes C CanProve (C authorized goods-order(C, M, OD, PReqDate)) to M Proof Steps (Lacking of merchant’s ID) C says PReq

(1)


(2)


(3)


(4)

95


(5)


(6)


(7)


(8)

2, A8, A9, P2’, M: C believes C CanProve ( → C) to M

(9)

KC


(10)


(11)


(12)

A9, SE1, M:


(13)


(14)


(15)


(16)


(17)

12, SA1, M:


(18)

A9, SE1, M:


(19)


(21)

16, 21, P6, M: C believes C CanProve (C says (OD, PReqDate)) to M

(22)

The proof fails because client cannot prove to merchant that C says (M, OD, PReqDate). It lacks of merchant’s ID.

96

Goal of the Proof M believes M CanProve (M authorized goods-receipt(M, C, OD, AuthDate)) to C Proof Steps (Lacking of client’s ID and OD) M says PRes

(1)

1, C2: M believes M says PRes

(2)

2, SA1, M: M believes M has PRes

(3)


(4)

A1, A2, K: M believes M believes ( K→ M)

(5)

3, 4, 5, H6, M: M believes M has (TID, AuthDate)

(6)

4, 6, H2, M:

(7)

M

M believes M has (KM, TID, AuthDate)

2, A8, A9, P2’, M:

M believes M CanProve ( K→ M) to C M

3, 7, 8, P3, M: M believes M CanProve (M says (TID, AuthDate)) to C 9, P6, M:

M believes M CanProve (M says AuthDate) to C

(8) (9) (10)

The proof fails because merchant cannot prove to client that M says (C, OD, AuthDate). It lacks of client’s ID and OD.

97

C.2

Analysis of Goals for All Engaging Parties of iKP

Goal of the Proof C believes C CanProve (C authorized payment(C, M, Price, Date)) to M Proof Steps C says Payment

(1)

1, C2:

(2)

C believes C says Payment

2, SA2, M: C believes C has Payment

(3)

3, H2, M: C believes C has {PI, h(OI)}Kc-1

(4)

3, H2, M: C believes C has PI

(5)


(6)


(7)

5, 6, 7, H2, M: C believes C has (KC, h(OI), PI)

(8)

2, A8, A9, P2’, M:

K C believes C CanProve ( → C) to M C

(9)

4, 8, 9, P3, M: C believes C CanProve (C says (PI, h(OI))) to M

(10)


(11)

2, SA1, M: C believes C says {PI, h(OI)}Kc-1

(12)

A9, SE1, M:

C believes M sees {PI, h(OI)}Kc-1

(13)


(14)


(15)

15, P6, M: C believes C CanProve (C says (Price, M, Date)) to M

(16)

16, A11, K: C believes C CanProve (C authorized payment(C, M, Price, Date)) to M (18)

98


Goal of the Proof M believes M CanProve (M authorized payment(M, C, Price, Date)) to C Proof Steps M says Confirm

(1)

1, C2:

(2)

M believes M says Confirm

2, SA2, M: M believes M has Confirm

(3)

2, H2, M: M believes M has {h(OI)}Km-1

(4)


(5)


(6)

5, 6, H2, M:

M believes M has (KM, h(OI))

(7)

2, A8, A9, P2’, M: M believes M CanProve ( → M) to C

(8)

4, 7, 8, P3, M: M believes M CanProve (M says h(OI)) to C

(9)

2, SA1, M:

M believes M says {h(OI)}Km-1

(10)

A9, SE1, M:

M believes C sees {h(OI)}Km-1

(11)

KM

10, A8, 11, A4, P2’, M: M believes M CanProve (h(OI)-is-fingerprint-of-OI) to C

(12)

9, 12, P4, M: M believes M CanProve (M says OI) to C

(13)

13, P6, M: M believes M CanProve (M says (Price, C, Date)) to C

(14)

14, A11, K: M believes M CanProve (M authorized payment(M, C, Price, Date)) to C (15)

99

Proving this authorization is successful. Goal of the Proof C believes C CanProve (C authorized value subtraction(C, A, Price, Date)) to A Proof Steps C says Payment

(1)

1, C2:

(2)



(3)


(4)


(5)


(6)


(7)


(8)


(9)

A9, SE1, M:

C believes A sees {PI, h(OI)}Kc-1

9, A8, 10, P2’, M:

(10)

K C believes C CanProve ( → C) to A C

(11)

4, 8, 11, P3, M: C believes C CanProve (C says (PI, h(OI))) to A

(12)

12, P6, M: C believes C CanProve (C says h(OI)) to A

(13)

9, A8, A9, A4, P2’, M: C believes C CanProve (h(OI)-is-fingerprint-of-OI) to A

(14)

13, 14, P4, M: C believes C CanProve (C says OI) to A

(15)

15, P6, M: C believes C CanProve (C says (Price, Date)) to A

(16)

Even though A cannot prove that C says acquirer’s ID to V, it is not the problem that leads to dispute since A is the only one who can decrypt the message

100


Goal of the Proof A believes A CanProve (A authorized value subtraction(A, C, Price, Date)) to C Proof Steps A says AuthRes

(1)

1, C2:

(2)

A believes A says AuthRes

2, SA2, M: A believes A has AuthRes

(3)

1, H2, M: A believes A has {AI, h(OI)}Ka-1

(4)

3, H2, M: A believes A has AI

(5)

A14, H3, M: A believes A has h(OI)

(6)

A1, H2, M: A believes A has KA

(7)

5, 6, 7, H2, M: A believes A has (KA, h(OI), AI)

(8)

2, A8, A9, P2’, M: A believes A CanProve ( → A) to C

(9)

KA

4, 8, 9, P3, M: A believes A CanProve (A says (AI, h(OI))) to C

(10)

10, P6, M: A believes A CanProve (A says h(OI)) to C

(11)

2, SA1, M: A believes A says {AI, h(OI)}Ka-1

(12)

A9, SE1, M:

A believes C sees {AI, h(OI)}Ka-1

(13)

12, A9, 13, A4, P2’, M: A believes A CanProve (h(OI)-is-fingerprint-of-OI) to C 11, 14, P4, M: A believes A CanProve (A says OI) to C

(14) (15)

101

15, P6, M: A believes A CanProve (A says (Price, C, Date)) to C

(16)

16, A11, K: A believes A CanProve (A authorized value subtraction(A, C, Price, Date)) to C

(17)


Goal of the Proof M believes M CanProve (M authorized value claim(M, A, Price, Date)) to A Proof Steps M says AuthReq

(1)

1, C2:

(2)

M believes M says AuthReq

2, SA2, M:

M believes M has AuthReq

(3)


(4)


(5)


(6)

5, 6, H2, M:


(7)

2, A8, A9, P2’, M: M believes M CanProve ( → M) to A

(8)

4, 7, 8, P3, M: M believes M CanProve (M says h(OI)) to A

(9)

KM

2, SA1, M: M believes M says {h(OI)}Km-1

(10)

10, A8, A9, A4, P2’, M: M believes M CanProve (h(OI)-is-fingerprint-of-OI) to A

(11)

9, 11, P4, M: M believes M CanProve (M says OI) to A

(12)

12, P6, M: M believes M CanProve (M says (Price, Date)) to A

(13)

102


Goal of the Proof A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M Proof Steps A says AuthRes

(1)

1, C2:

(2)

A believes A says AuthRes

2, SA2, M: A believes A has AuthRes

(3)

3, H2, M: A believes A has {AI, h(OI)}Ka-1

(4)

3, H2, M: A believes A has AI

(5)

A14, H3, M: A believes A has h(OI)

(6)

A1, H2, M: A believes A has KA

(7)

5, 6, 7, H2, M: A believes A has (KA, h(OI), AI)

(8)

2, A8, A9, P2’, M:

K A believes A CanProve ( → A) to M A

(9)

4, 8, 9, P3, M: A believes A CanProve (A says (AI, h(OI))) to M

(10)

10, P6, M: A believes A CanProve (A says h(OI)) to M

(11)

2, SA1, M: A believes A says {AI, h(OI)}Ka-1

(12)

A9, SE1, M:

A believes M sees {AI, h(OI)}Ka-1

(13)

12, A8, 13, A4, P2’, M: A believes A CanProve (h(OI)-is-fingerprint-of-OI) to M

(14)

103

11, 14, P4, M: A believes A CanProve (A says OI) to M

(15)

15, P6, M: A believes A CanProve (A says (Price, M, Date)) to M

(16)

16, A11, K: A believes A CanProve (A authorized value claim(A, M, Price, Date)) to M (17) Proving this authorization is successful.

Goal of the Proof C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M Proof Steps C says Payment

(1)

1, C2:

(2)



(3)


(4)


(5)


(6)


(7)


(8)

K C) to M 2, A8, A9, P2’, M: C believes C CanProve ( →

(9)

C

4, 8, 9, P3, M: C believes C CanProve (C says (PI, h(OI))) to M

(10)


(11)


(12)

A9, SE1, M:

C believes M sees {PI, h(OI)}Kc-1

(13)

104


(14)


(15)

15, P6, M: C believes C CanProve (C says (M, Date)) to M

(16)

15, P6, M: C believes C CanProve (C says h(OD)) to M

(17)

12, A8, 13, A4, P2’, M: C believes C CanProve (h(OD)-is-fingerprint-of-OD) to M

(18)

17, 18, P4, M: C believes C CanProve (C says OD) to M

(19)

16, 19, P6, M: C believes C CanProve (C says (M, OD, Date)) to M

(20)

20, A12, K: C believes C CanProve (C authorized goods-order(C, M, OD, Date)) to M (21) Proving this authorization is successful.

Goal of the Proof M believes M CanProve (M authorized goods-receipt(M, C, Price, Date)) to C Proof Steps M says Confirm

(1)

1, C2:

(2)

M believes M says Confirm

2, SA2, M: M believes M has Confirm

(3)


(4)


(5)


(6)

105

5, 6, H2, M:


(7)

2, A8, A9, P2’, M: M believes M CanProve ( K→ M) to C

(8)

4, 7, 8, P3, M: M believes M CanProve (M says h(OI)) to C

(9)

2, SA1, M:

M believes M says {h(OI)}Km-1

(10)

A9, SE1, M:

M believes C sees {h(OI)}Km-1

(11)

M

10, A8, 11, A4, P2’, M: M believes M CanProve (h(OI)-is-fingerprint-of-OI) to C

(12)

9, 12, P4, M: M believes M CanProve (M says OI) to C

(13)

13, P6, M: M believes M CanProve (M says (C, Date)) to C

(14)

13, P6, M: M believes M CanProve (M says h(OD)) to C

(15)

10, A8, 11, A4, P2’, M: M believes M CanProve (h(OD)-is-fingerprint-of-OD) to C

(16)

15, 16, P4, M: M believes M CanProve (M says OD) to C

(17)

14, 17, P6, M: M believes M CanProve (M says (C, OD, Date)) to C

(18)

18, A12, K: M believes M CanProve (M authorized goods-receipt(M, C, OD, Date)) to C (19) Proving this authorization is successful.

106

C.3

Analysis of Client Privacy of SET

To achieve client privacy, client must be able to prove the authorizations to both merchant and acquirer without revealing private information. The statements that must be proved are as the following:

a) C believes C CanProve (C authorized payment(C, M, Price, PReqDate)) to M b) C believes C CanProve (C authorized value subtraction(A, C, Price, PReqDate)) to A

Goal of the Proof C believes C CanProve (C authorized payment(C, M, Price, PReqDate)) to M Proof Steps C says PReq

(1)


(2)


(3)


(4)


(5)


(6)


(7)


(8)

2, A8, A9, P2’, M:

K C believes C CanProve ( → C) to M C


(9) (10)

107


(11)


(12)

A9, SE1, M:


(13)


(14)


(15)


(16)


(17)

12, SA1, M:


(18)

A9, SE1, M:


(19)


(21)

16, 21, P5, M: C believes C CanProve (C says (Price, PReqDate)) to M

(22)

Proving client privacy to merchant is successful.

Goal of the Proof C believes C CanProve (C authorized value subtraction(A, C, Price, PReqDate)) to A Proof Steps C says PReq

(1)


(2)


(3)


(4)

108


(5)


(6)


(7)


(8)

2, SA1, M: C believes C says (OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

(9)

A9, SE1, M:

C believes A sees (OI, {h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

9, A8, 10, P2’, M:

C believes C CanProve ( → C) to A KC

(10) (11)

4, 8, 11, P3, M: C believes C CanProve (C says (h(OI), h(PI))) to A

(12)

12, P5, M: C believes C CanProve (C says h(PI)) to A

(13)

2, SA1, M: C believes C says ({h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

(14)

10, SE1, M: C believes A sees ({h(OI), h(PI)}Kc-1, {h(OI), PI}Ka)

(15)

13, A8, 15, A4, P2’, M: C believes C CanProve (h(PI)-is-fingerprint-of-PI) to A

(16)

13, 16, P4, M: C believes C CanProve (C says PI) to A

(17)

17, P5, M: C believes C CanProve (C says (Price, PReqDate)) to A

(18)

Proving client privacy to acquirer is successful.

Appendix D Meadows and Syverson’s Each Party’s Requirement for Payment Transactions of SET Protocol

110

C.1

Customer Requirement

Customer Requirement states about how customer accepts transaction. Customer will accept the transaction if all these requirements below are true:

1) accept(customer(P,[honest]), merchant(Q,[X], cust_accept(V), N?) - send(merchant(Q, [X]), customer(P, [honest]), merch_respsend(V), → N?)

Customer will accept transaction if customer receives the guarantee of his purchase order (PRes). This guarantees that customer will receive goods. In this case, merchant has sent merch_respsend(V) in order to guarantee customer about his purchase order.

2) accept(customer(P,[honest]), merchant(Q,[honest], cust_accept(V), N?) → ∃V’((cust_accept(V) ~ merch_resp(V’)) ∧ - accept(merchant(Q, [honest]), customer(P, [honest]), merch_resp(V’), N?)))

Customer will accept transaction if merchant has previously accepted customer’s purchase order, and both customer and merchant agree that they have the same information (knowledge) about transaction.

111

3) accept(customer(P,[honest]), merchant(Q,[X], cust_accept(V), N?) → ∃V’((cust_accept(V) ~ apg_resp(V’)) ∧ - accept(gateway(R, [honest]), customer(P, [honest]), apg_resp(V’), N?)))

Customer will accept transaction if gateway has previously accepted merchant’s authorization request, and both of them agree that they have the same information (knowledge) about transaction.

4) accept(customer(P,[honest]), merchant(Q,[X], cust_accept(V), N) - send(customer(P,[honest]), merchant(Q,[X]), cust_reqsend(V), N) →

Customer accepts transaction if customer has previously sent purchase request (cust_reqsend(V)) to merchant.

112

C.2

Merchant Requirement Merchant requirement states about how merchant accepts customer’s

purchase request. Merchant will accept customer’s purchase request if all these requirements below are true:

1) accept(merchant(Q,[honest]), customer(P,[X], merch_resp(V), N?) - send(gateway(R, [honest]), (customer(P, [honest]), merchant(Q, → [honest])), apg_respsend(V), N?)

Merchant will accept customer’s purchase request if gateway has previously sent the authorization response (apg_respsend(V)) to merchant.

2) accept(merchant(Q,[honest]), customer(P,[X], merch_resp(V), N?) - send(merchant(Q, [honest]), gateway(R, [honest]), merch_reqsend(V), → N?)

Merchant will accept customer’s purchase request if merchant has previously sent the authorization request (merch_reqsend(V)) to gateway.

3) accept(merchant(Q,[honest]), customer(P,[X], merch_resp(V), N?) → ∃V’((apg_resp(V’) ~ merch_resp(V)) ∧ - accept(gateway(R, [honest]), (customer(P, [honest]), merchant(Q, [honest])), apg_resp(V’), N?))

113

Merchant will accept customer’s purchase request if gateway has previously accepted the authorization request from merchant, and both of them agree that they have the same information (knowledge) about transaction.

4) accept(merchant(Q,[honest]), customer(P,[X]), merch_req(V), N) ∧ (merch_req(V)[11] = signed)) → ∃V’((cust_reqsend(V’) ~ merch_req(V)) ∧ - send(customer(P, [honest]), merchant(Q, [honest])), cust_reqsend(V’), N))

Merchant will accept customer’s purchase request and parts of merchant’s authorization request was signed by customer if customer has previously sent purchase request (cust_reqsend(V’)) to merchant, and both of them agree that they have the same information (knowledge) about transaction.

114

C.3

Gateway Requirement Gateway requirement states about how gateway accepts merchant’s

authorization request (and customer’s money subtraction request). Gateway will accept merchant’s authorization request if the requirement below is true:

accept(gateway(R,[honest]), (merchant(Q,[honest], customer(P, [honest])),

apg_resp(V), N?) - send(customer(P, [X]), merchant(Q, [Y]), cust_reqsend(V), N?) ∧ → ( send(merchant(Q, [X]), (gateway(R, [honest]), merch_reqsend(V),

N?))

Gateway will accept merchant’s authorization request (and customer’s money subtraction

request)

if

customer

has

previously

sent

purchase

request

(cust_reqsend(V)) to merchant, and merchant has sent authorization request (merch_reqsend(V)) to gateway.

Appendix E Published Papers

116

E.1

List of Published Papers

1. Kungpisdan, S. and Permpoontanalarp, Y., “A Logic for Solving Disputes in Electronic Commerce,” Proceedings of the 24th Electrical Engineering Conference, November 22-23, 2001, Thailand. 2. Kungpisdan, S. and Permpoontanalarp, Y., “Practical Reasoning about Accountability in Electronic Commerce Protocols,” Proceedings of the 4th International Conference on Information Security and Cryptology, December 6-7, 2001, Seoul, Korea.