Automatic Verification of Security in Payment Protocols for Electronic ...

Automatic Verification of Security in Payment Protocols for Electronic Commerce M. Panti, L. Spalazzi, S. Tacconi, S. Valenti Istituto di Informatica, University of Ancona

Via Brecce Bianche, Ancona, Italy fpanti,spalazzi,tacconi,[email protected]

Keywords:

payment protocols, electronic commerce, security requirements, model checking, automatic verification, protocol attacks

Abstract:

In order to make secure transactions over computer networks, various cryptographic protocols have been proposed but, because of subtleties involved in their design, many of them have been shown to have flaws, even a long time after their publication. For this reason, several automatic verification methods for analyzing these protocols have been devised. The aim of this paper is to present a methodology for verifying security requirements of electronic payment protocols by means of NuSMV, a symbolic model checker. Our work principally focus on formal representation of security requirements. Indeed, we propose an extension of the correspondence property, so far used only for authentication, to other requirements as confidentiality and integrity. These are the basic security requirements of payment protocols for electronic commerce. We illustrate as case study a variant of the SET protocol proposed by Lu & Smolka. This variant has been formally verified by Ly & Smolka and considered secure. Conversely, we have discovered two attacks that allow a dishonest user to purchase a good debiting the amount to another user.

1

Introduction

In the last years, the diffusion of computer networks has received an enormous development. These systems provide a growing number of different services (for instance e-commerce services) each needy of peculiar security requirements. In order to satisfy such requirements, various cryptographic protocols have been proposed. A cryptographic protocol is a protocol that exploits cryptographic primitives in order to satisfy one or more security requirements. Among various kinds of security protocols, the spread of electronic commerce makes very attractive those devoted to protection of on-line payments. The most popular payment protocol is the Secure Electronic Transaction (SET in short), a protocol jointly developed by Visa and Mastercard (Mastercard and Visa, 1997) to guarantee secure transactions over open networks. Unfortunately, the definition of a cryptographic protocol involves many subtleties that often lead designers into error. For this reason many protocols have been shown to have flaws, even a long time after their publication. To avoid these subtle misconceptions, several automatic verification methods for analyzing cryptographic protocols have been devised. Model

checking has been proved to be very useful for this purpose. Model checking is a general-purpose, automatic technique for verifying finite-state concurrent systems. Indeed, given the model of the system to analyze, a model checker simulates all its possible behaviors in order to verify whether a requirement is satisfied. When a requirement is not satisfied, a counterexample is produced. In applying this approach to the verification of cryptographic protocols, security requirements (properties) are expressed by a propositional temporal logic, and protocols are modelled as state-transition systems. In this context, the counterexamples can be used for discovering possible attacks on protocols. This is possible only when the model of the environment includes the presence of a dishonest entity having the control of network where protocols run. The aim of this paper is to present a methodology for analyzing cryptographic protocols by means of NuSMV (Cimatti et al., 1999), a symbolic model checker. The most innovative feature of our methodology is constituted by formal representation of security requirements. Indeed, we propose an extension of the correspondence property, so far used only for authentication, to other requirements as secrecy and integrity. Notice that, these are the basic security re-

1

quirements of payment protocols for electronic commerce. We illustrate the feasibility of our approach using as case study a simplified variant of SET proposed by Lu and Smolka (Lu and Smolka, 1999). This variant has been analysed by the same authors and considered secure. Conversely, we have discovered two attacks that allow a dishonest entity to purchase a good debiting the amount to another user. The rest of paper is organised as follows. In Section 2 we sketch a brief description of the Lu-Smolka protocol. At this point, we describe how we have employed the model checking to verify the security of this protocol. For this purpose, we first describe the model of protocol in Section 3, then we illustrate the formalization of security requirements in section 4. In Section 5, we discuss the attacks that we have found and their effects. In Section 6 we compare our work with those dealing with automatic verification of SET and of its variants. Final remarks are drawn in Section 7.

2

The Lu-Smolka Variant of the SET Protocol

SET is a suite comprising seventeen subprotocols, each devoted to make secure a specific phase of a commercial transaction. The Lu-Smolka variant of this protocol, depicted in Figure 1 both graphically and formally, is a simplified version of the subprotocols involved in the payment phase only. Therefore, it is assumed that such a variant is invoked during a web-based commercial transaction. This means that a client (the cardholder) selects the goods/services that it wishes to purchase/request, the shipping address, the billing address (if any) and after that uses the protocol to perform the on-line payment. In Figure 1, C denotes the cardholder, M the merchant, and P the payment gateway. fmgKx expresses a message m encrypted with the public key of X , whereas Sx fmg is a message m signed by X . T IDR denotes a record with initialisation data for the protocol. T ID represents the unique identifier of the transaction, it can be considered as a nonce. P A is the amount that the cardholder is supposed to pay, P Y is the amount that the cardholder is willing to pay, and AA is the amount of charge that the merchant requests for authorization. CA and MA are the identifiers of cardholder’s account and merchant’s account, respectively. Finally, T r denotes the answer of the gateway that can be either an authorization or a negation of authorization. Intuitively, the protocol works as follows. In step (1), C sends to M the request for a unique transaction identifier. M assigns the T ID to the transaction, signs it, and returns it to C in step (2). At this point, in step (3), C sends to M the Ordering Information (OI), i.e., T ID and P A, and the Payment Instruction (PI), i.e., T ID,P Y ,CA. P Y may be lower than P A if the

2

cardholder tries to deceive the merchant. Moreover, the P I is destined to the payment gateway, while OI is destined to merchant. In step (4), M decrypts OI , checks if it is correct, then encrypts a new OI (OI 0 composed by T ID,AA,MA) with the payment gateway’s public key. Finally, M sends to P , in a single message, an authorization and capture request. Notice that AA might be higher than P Y . In step (5), P authorizes C ’s payment card, checks for consistency between OI 0 and P I , performs appropriate account operations, and returns the transaction result T r to M . In step (6), M reads the response and forwards the message to C .

3

Model of the Protocol

Our approach is based upon model checking, an automatic technique for verifying finite state concurrent systems. In the temporal logic model checking, the concurrent system is modelled as a state transition diagram.The NuSMV model checker, following the above approach, adopts a structured input language to describe the model of system. In this context, the model of protocol describes all the issues related to the behavior of the honest and the dishonest entities belonging to the system where the protocol runs. The model of protocol has a modular structure. Each module is associated to an entity of the system and describes its behavior. As showed in the overall view, depicted in Figure 2, the model consists on honest entities, i.e., the client C , the merchant M , the payment gateway P , and a dishonest entity I .

3.1

Honest Entities

The model of protocol is composed by several variables and processes. First of all, we have the communication channel, a set of variables which are shared among all the entities. In particular, we treat protocol messages flowing in the channel as records having a specific field for each message component. For each honest entity C ,M and P , we have a set of processes. Each process of any entity corresponds to an instance of the entity involved in a particular execution of the protocol. Moreover, all the processes work asynchronously and concurrently. The concurrency is simulated by means of a non-deterministic interleaving of process running. Each process that constitutes an entity is a very simple automaton. The most important variable involved in these processes, named state, is initialised at idle. When the automaton of an honest entity sends a message h, the variable is set to sendh , when it receives a message k , the variable is set to re eivek , finally when the protocol session ends successfully, the value is terminated. Each entity has also a set of counters that are used to specify

P

5: Authorization & Capture Response

4: Authorization & Capture Request 1: Initiate Request 2: Initiate Response

C

3: Purchase Request

M

6: Purchase Response

(1)

C! M

:

Initiate Request

(2)

M

C

:

(3)

C! M

:

(4)

M

!

P

:

(5)

P

!

M

:

(6)

M

!

C

:

Initiate Response Sm fT IDg Purchase Request S fT IDg; fT ID; P AgKm ; S ffT ID; P Y; CAgKp g Authorization & Capture Request S ffT ID; P Y; CAgKp g; Sm fT IDg; fT ID; AA; MAgKp Authorization & Capture Response Sp fT ID; T rg Purchase Response Sp fT ID; T rg

!

T IDR

Figure 1: The Lu-Smolka variant of SET

the security properties, as discussed in section 4. Such variables are the following:





X:begin(role; Y ), X:end(role; Y )

counts the number of protocol executions that the entity X has begun/ended with the entity Y acting as specified in role 2 finit; respg, with X; Y 2 fC; M; P g and init=resp standing for initiator/responder. We allow a multi-role behavior for C and M among different protocol executions. For this reason, C can be a responder and M can be an initiator. Conversely, the role of P is forced to be only a responder.

X:send(Y; term), X:re v(Y; term) counts how many times the entity X has sent/received the sensible information specified in term to/from entity Y . The counter X:re v(Y; term) is incremented only if X is able to extract term from the received message. There are different kinds of terms, each defined over a set of possible values. In the model exists a pair of counters for each possible value of each kind of term.

As a consequence of finiteness of model checking approach, the value of each counter can range from 0 to the maximum number of protocol executions admitted in the model. For the same reason, each term ranges inside a finite set of values.

3.2

Dishonest Entity

Modelling the dishonest entity requires identification of relevant assumptions that allow to capture its possible behaviors. A dishonest entity is usually assumed to be as powerful as possible, in order to verify the protocol in the possible worst situation where it can be executed. Therefore, we assume that a dishonest entity has a complete control of the communication channel. In other words, it must be able:

 to eavesdrop each message sent over the channel;  to remove a message sent to another principal;  to generate new protocol messages;

 to store in the memory messages eavesdropped;  to send messages to other principals. The dishonest entity must be able to generate messages built out of messages previously sent over the channel by honest entities. As a consequence, the model of the dishonest entity must be provided with a memory to store eavesdropped messages sent during the current or previous sessions of the protocol. In the general case, a dishonest entity must be able to build new messages starting from the readable components of the messages eavesdropped or from components belonging to its initial knowledge about the protocol. The model of the dishonest entity is made

3

Dishonest Entity I

Communication Channel

Client C

Payment Gateway P

Merchant M

Figure 2: The overall view of the model

according to the above assumption. The most important variables involved are the following:  state ranges over the possible actions that the dishonest entity can perform and whose value in each state represents the action it has chosen. According to dishonest entity’s abilities previously enumerated, state admits the following values: eavesdrop, remove, generate, store, send.  memory represents the memory of the dishonest entity and is an array whose elements range over the messages of the protocol. The dishonest entity stores eavesdropped messages in this array. The size of the array basically depends on the number of messages of the protocol and the maximum number of distinct sessions allowed in the model. At any step, the dishonest entity non deterministically chooses an action between all the possible actions, for this reason state can non deterministically take any of its values. The automaton of dishonest entity performs the current action specified by the value of state and changes all the other local variables accordingly. Finally, in order to formalize security requirements, the model of the dishonest entity is also provided with counters similar to those of honest principals.

4

Security Requirements

There are several requirements that a security protocol needs to satisfy. In the analysis of Lu and Smolka protocol, we have focused our attention on: authentication, i.e. the parties convince each other of their identities, confidentiality, i.e. nobody but the authorized parties must know a term, and integrity, i.e. assurance that a term has not been altered by an unauthorized entity. These properties express the security goals of the original version of SET and thus those of the Lu and Smolka variant as well. In order to formalize the above requirements, we propose to adopt the so called correspondence property. This property has been introduced for authentication (Woo and Lam, 1993). An

4

attempt to generalize correspondence can be found in (Marrero et al., 1997), but the authors still apply this property to authentication only. In the following section we will show it can encompass confidentiality and integrity too.

4.1

Generalization of Correspondence Property

In its most general formulation, the correspondence property states that the relation between an event E and an event F must be a one to one mapping. Usually, it must be taken into account multiple sessions of the same protocol to verify security. Indeed, many attacks occur in the presence of multiple sessions only. In such a situation, we may have several events of type E and F , and thus we need to count them. Therefore, the correspondence property can be reformulated (Marrero et al., 1997) as follows: If the event E occurs n times, then the event F must have occurred at least n times. In NuSMV , system requirements are formalized in the propositional temporal logic CT L (Computational Tree Logic) (Emerson, 1990). When we represent the generalized correspondence property in CT L, we use the counters (one for each event) introduced in the model. Therefore, the correspondence property can be formalized by means of the following general schema:

AG(X: ounterF >= Y: ounterE )

(1)

X: ounterE and Y: ounterF denote counters related to entities X and Y . These meta-variables must be

instantiated to appropriate counters, depending on the property to formalize. AG is a CT L operator (it is an abbreviation for Always Globally. Informally speaking, AG p means that the propositional formula p must be true in every possible state of the system.

4.2

Authentication

In the original formulation for authentication, the correspondence property states that when an entity finishes its part of the protocol, the other entity must have taken part in the protocol execution. In other words, if an entity X ends n protocol executions with Y as responder (initiator), then in the past the entity Y must have started at least n protocol executions with X as initiator (responder). The above property asserts that Y must prove its identity to X . In the case of mutual authentication protocol, there exists a similar property for representing X that must prove its identity to Y . A violation of this property means that an entity ends a session (i.e., it accepts the authentication of the other entity) that the other entity has not started, i.e., the dishonest entity must have impersonated an entity. In order to formalize in CT L the authentication property according to the above schema, we use some of the counters that we have introduced in the model. Thus, the authentication property is represented by the following CT L specification:

AG(X:begin(init; Y ) >= Y:end(resp; X )) AG(X:begin(resp; Y ) >= Y:end(init; X ))

4.3

(2) (3)

Confidentiality

The extension of correspondence property to other requirements is quite natural. Intuitively, confidentiality means that a term must not be known by unauthorized entities. In other words, it is required that the dishonest entity never receives or deduces this term. From another point of view, a dishonest entity can receive only the terms intended for it. Therefore, this entity can not obtain term from an entity X more times than this term has been expressly sent to it. Thus, we can write the following specification:

AG(X:send(I; term) >= I:re v(X; term))

(4)

Obviously, this formula assumes that the dishonest entity can be a legitimate member of the system. Notice that when I does not take part to a certain protocol execution, nobody sends confidential terms to it, thus X:send(I; term) is always equal to 0. As a consequence, in this case the specification requires that I:re v(X; term) must be 0. Nevertheless, the above conditions are necessary but non sufficient. Indeed, a dishonest entity, even if does not know a confidential term, can trick an entity Y into thinking that it has received a secret term from the entity X , whereas in fact X has never sent term to Y . In order to cover this situation, the following specification must be added:

AG(X:send(Y; term) >= Y:re v(X; term))

(5)

Informally speaking, the above expression means that if an entity X receives n times a term from Y , then

in the past the entity Y must have expressly sent at least n times this term to X . Notice that, if this term must be fresh, the maximum value admitted for these counters is 1.

4.4

Integrity

Integrity is the assurance that an information has not been altered by unauthorized entity. In the model, when X sends a term to Y , it increases the counter X:send(Y; term) associated to this specific term. Similarly, the intended recipient Y , after the receipt of this term, increases the counter Y:re v (X; term). If an alteration of this term is occurred on the network during its transit, the associated counter of the recipient does not increase, but increases the counter Y:re v(X; term0 ), with term = 6 term0 . As a consequence, specification (5) is not satisfied. Indeed, this specification, only necessary for confidentiality, assures also integrity. This is congruent, since typically, for a confidential term it is also required integrity. Conversely, integrity may be required without confidentiality (for example, when a term is only signed). For this reason, we employ the specification (5) (in conjunction with (4)) to express integrity of a confidential term, whereas we adopt only the specification (5) for integrity of terms transmitted in clear.

5

Attacks on the Protocol

The above model and requirements have been submitted to NuSMV . From the verification arises that the expected security requirements do not hold. In order to justify this outcome, the model checker has generated a counter-example showing how a dishonest entity can compromise an execution of the protocol. In the attack traces, when the dishonest entity intercepts a message m in transit from X to Y , preventing from its receipt, we write X ! I (Y ) : m. When the dishonest entity sends a message m to Y , impersonating X , we write I (X ) ! Y : m. The first attack proceeds as reported in Figure 3. The dishonest entity I acts as merchant in  with C while in session it impersonates the client C towards another merchant M . As a consequence of the above attack on a commercial transaction, a dishonest buyer I succeeds into debiting to another buyer C a purchase that C in fact has never performed. Moreover, if the good is delivered by means of the network system, as the content of a web-page, or I has altered the shipping address in the (often insecure) phase before the invocation of the protocol, I is able to obtain that good without paying it. From the point of view of requirements, this attack violates the requirements of authentication and secrecy. Indeed, it is a counter-example of the follow-

5

:1) C ! I : T IDR ( :1) I (C ) ! M : T IDR ( :2) M ! I (C ) : Sm fT ID g (:2) I ! C : Si fT ID g (:3) C ! I : S fT ID g; fT ID; P AgKi ; S ffT ID; P Y; CAgKp g ( :3) I (C ) ! M : S fT ID g; fT ID; P AgKm ; S ffT ID; P Y; CAgKp g ( :4) M ! P : S ffT ID; P Y; CAgKp g; Sm fT ID g; fT ID; AA; MAgKp ( :5) P ! M : Sp fT ID; T r g ( :6) M ! I (C ) : Sp fT ID; T r g (

Figure 3: The first attack on the protocol

ing instances of specifications (2) and (5):

AG(C:begin(init; M ) >= M:end(resp; C )) AG(C:send(M; P A) >= M:re v(C; P A)) The second attack, reported in Figure 4, is similar to the previous one, but now the dishonest entity acts as buyer in session . As a consequence, also this attack allows I to perform a purchase from M , debiting the payment to an unaware buyer C . This attack violates only the requirement of authentication. Indeed, it is a counter-example of the following instance of specification (3):

AG(M:begin(resp; C ) >= C:end(init; M )) The first attack is possible because who receives the message of step (3) is not able to deduce the identity of the intended receiver. This problem exists also in the original version of SET and has also implications on the non-repudiation requirement (Van Herreweghen, 2000). However, in the original protocol, the presence of the identifier of merchant in the Payment Instruction allows the gateway P to deduce the real identity of intended merchant and thus to avoid the above fraud. The second attack occurs when M does not check the second signature of the message received in step (3), but it simply forwards it to P . Notice that, the original protocol does not require such a control. Indeed, the signature is inside the encryption with the gateway’s public key. However, also in this case, in the original protocol the gateway is able to detect the fraud in step (4).

6

Related Work

The literature about formal verification of cryptographic protocols is very wide. Many papers concern on verification of authentication and key exchange protocols. Among these, the work that has mostly influenced our approach to the formalization of security requirements is (Woo and Lam, 1993). In that paper, the correspondence property is used to formalize the authentication requirement for the classical authentication protocols. Conversely, in our work we

6

have generalized the correspondence property to capture also secrecy and integrity requirements. Moreover, we have extended the domain applicability, applying this property to electronic payment protocols. In literature there exists various attempts aimed to extend the formal verification methods previously devised for authentication protocols to electronic payment protocols. We restrict our brief survey on papers dealing with the analysis of the SET protocol. With the paper of Lu and Smolka (Lu and Smolka, 1999) we share the same variant of SET. The aim of their work is to verify their protocol with F DR, a model checker based on the CSP language. The result of their verification is that their variant of SET is secure. On the contrary, we have discovered two attacks on such a protocol. In (Meadows and Syverson, 1998), it is proposed the use of NRL Protocol Analyzer to verify SET. In this work, specifications are expressed with a temporal language, named NP AT RL, but the authors leave the complete analysis of the protocol to future work. Another work concerning the analysis of SET is (Bella et al., 2000). In this paper, the authors show how they have analyzed the first subprotocol of SET, named Cardholder Registration, by means of the theorem prover Isabelle. From their verification many ambiguities and contradictions on the protocol specification arise. In our work, we have focused on a different phase, i.e., the payment phase. The work (Van Herreweghen, 2000) proposes a methodology based on a language expressing the claims that the participants to a protocol execution must be able to prove. From this analysis some problems about non-repudiation requirement emerge. In particular, the fact that SET does not provide a secure receipt of payment to the cardholder. In (Kessler and Neumann, 1998), the authors propose an authentication logic that extends the AUT LOG logic of belief in order to model accountability in electronic payment protocols. This logic is also applied to verify SET. The result is that SET is secure. Finally, in (Bolignano, 1997), it is described a verification methodology that allows to analyze a payment protocol by means of modal logic proofs. The authors use as casestudy C-SET, a different variant of SET.

:1) C ! I (M ) : T IDR ( :1) I ! M : T IDR ( :2) M ! I : Sm fT ID g (:2) I (M ) ! C : Sm fT ID g (:3) C ! I (M ) : S fT ID g; fT ID; P AgKm ; S ffT ID; P Y; CAgKp g ( :3) I ! M : Si fT ID g; fT ID; P AgKm ; S ffT ID; P Y; CAgKp g ( :4) M ! P : S ffT ID; P Y; CAgKp g; Sm fT ID g; fT ID; AA; MAgKp ( :5) P ! M : Sp fT ID; T r g ( :6) M ! I : Sp fT ID; T r g (

Figure 4: The second attack on the protocol

7

Conclusion

We have proposed a methodology for verifying security requirements of electronic payment protocols by means of model checking. Our approach is based on the extension of correspondence property, so far used only for authentication, to other requirements, as confidentiality and integrity. We have illustrated as case study a variant of SET proposed by Lu and Smolka. Even if this protocol was considered secure, we have discovered two attacks that allow a dishonest user to purchase a good debiting the amount to another user.

Acknowledgments The authors wish to thank Lorenzo Baldini, Loic Jay, Johann Dimarti, and Luca Roganti for their help in verifying the Lu and Smolka variant of the SET protocol.

REFERENCES Bella, G., Massacci, F., Paulson, L., and Tramontano, P. (2000). Formal Verication of Cardholder Registration in SET. In Proceedings of 6th European Symposium on Research in Computer Security (ESORICS).

Lu, S. and Smolka, S. (1999). Model Checking the Secure Electronic Transaction (SET) Protocol. In Proceedings of 7th International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, pages 358–365. Marrero, W., Clarke, E., and Jha, S. (1997). Model Checking for Security Protocols. In Proceedings of the DIMACS Workshop on Design and Formal Verification of Security Protocols. Mastercard and Visa (1997). SET Secure Electronic Transaction Specification. Mastercard & Visa. Available at http://www.setco.org. Meadows, C. and Syverson, P. (1998). A Formal Specification of Requirements for Payment Transactions in the SET Protocol. In Proceedings of the 2nd Financial Cryptography. Van Herreweghen, E. (2000). Non-repudiation in SET: Open Issues. In Proceedings of the 4th Conference on Financial Cryptography. Woo, T. and Lam, S. (1993). A Semantic Model for Authentication Protocols. In Proceedings of IEEE Computer Society Symposium on Research in Security and Privacy, volume 25, pages 178– 194.

Bolignano, D. (1997). Towards the Formal Verification of Electronic Commerce Protocols. In Proceedings of 10th Computer Security Foundations Workshop, pages 133–146. Cimatti, A., Clarke, E., Giunchiglia, F., and Roveri, M. (1999). NuSMV: A New Symbolic Model Verifier. In Proceedings of 11th Conference on Computer-Aided Verification, number 1633 in Lecture Notes in Computer Science, pages 495– 499. Springer. Emerson, A. (1990). Handbook of Teoretical Computer Science, volume 2. Elsevier. Kessler, V. and Neumann, H. (1998). A Sound Logic for Analysing Electronic Commerce Protocol. In Proceedings of 5th European Symposium on Research in Computer Security (ESORICS).

7