Micropayment proposal with formal verification using ...

74

Int. J. Business Intelligence and Data Mining, Vol. 8, No. 1, 2013

Micropayment proposal with formal verification using coloured Petri nets and performance analysis on the Android platform Andreu Pere Isern-Deyà*, M. Magdalena Payeras-Capellà, Macià Mut-Puigserver, Josep-Lluis Ferrer-Gomila and Llorenç Huguet-Rotger Universitat de les Illes Balears. Cra. de Valldemossa, km 7.5. Palma de Mallorca, Illes Balears, Spain E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author Abstract: Payments involving small amounts of money are usual in the online purchases of low-value services, goods or pieces of information. In these kinds of payments, called micropayments, a trade-off between efficiency and security requirements has to be provided. In a previous work, we presented an efficient and secure micropayment scheme which fulfils both the security properties that guarantee no financial risks and the desired privacy for customers. In order to prove the viability of the proposal, we have proceeded in two directions. First we have formally verified the protocol using coloured Petri nets (CPN). Secondly, once we are able to assure, from the results of the formal verification, that the proposal satisfies the claimed properties, we have successfully implemented the scheme on the Android platform. Using the developed implementation, we have evaluated its performance to prove that the proposal is viable using current mobile devices. Several tests validate that our scheme can execute very fast payments with our simple but secure spending protocol. With the presented formal verification and performance analysis we can assure that the protocol is ready to be used. Keywords: micropayment; formal verification; coloured Petri nets; implementation; performance; Android; smartphone; business intelligence. Reference to this paper should be made as follows: Isern-Deyà, A.P., Payeras-Capellà, M.M., Mut-Puigserver, M., Ferrer-Gomila, J-L. and Huguet-Rotger, L. (2013) ‘Micropayment proposal with formal verification using coloured Petri nets and performance analysis on the Android platform’, Int. J. Business Intelligence and Data Mining, Vol. 8, No. 1, pp.74–104.

Copyright © 2013 Inderscience Enterprises Ltd.

Micropayment proposal with formal verification Biographical notes: Andreu Pere Isern-Deyà received his BSc as Telecommunication Engineer (2008) from the Polytechnic University of Catalonia (UPC). Since 2008, he has been a PhD student at the Department of Mathematics and Computer Science at UIB. His research is focused in security on communications networks, protocols for e-commerce, technical-legal aspects of e-commerce and mobile applications development. He is an author of several articles published in national and international conferences and international journals. M. Magdalena Payeras-Capellà received her title as Telecommunication Engineer (1998) from the Polytechnic University of Catalonia (UPC) and her PhD in Computer Science (2005) from the University of the Balearic Islands (UIB). Her research is focused primarily in the security in communications networks, protocols for e-commerce and technical-legal aspects of e-commerce. Within these lines of research she has had an active pace of publications in international journals and in international and national conferences. She is an author of several articles published in international journals included in Journal Citation Reports (JCR). She has participated in European-funded and Spanish-funded research projects. She has participated in the creation of an awarded spin-off: KEYRON, dedicated to telemedicine. She won the award to the Best Doctoral Thesis in 2005 from the COIT, Engineers Spanish Association. Macià Mut-Puigserver achieved his graduate in Computer Science in 1990 at the Autonomous University of Barcelona. He received his PhD in 2006 at the University of Balearic Islands (UIB). In 1996, he joined to the Department of Mathematics and Computer Science at the UIB as an Associate Professor. He combines his job at the university with the job at the college where he has been the Computer Science Department Head for ten years and the Mobility Coordinator of Erasmus Programme. His current research interests are: design of secure protocols, secure e-commerce, mobile applications and applied cryptography. He is author of articles on these topics in international journals and in international and national conferences. Josep-Lluis Ferrer-Gomila received his BSc as a Telecommunication Engineer (1991) from the Polytechnic University of Catalonia (UPC) and his PhD in Computer Science (1998) from the University of the Balearic Islands (UIB). He is an Associate Professor in the University of the Balearic Islands since 1995 in the Department of Mathematics and Computer Science. His main topic of research is security in e-commerce. He is author of publications in international journals and in international and national conferences, some of them published in international journals included in Journal Citation Reports (JCR). He has participated in European-funded and Spanish-funded research projects, being main researcher in four. He has participated in the creation of an awarded spinoff. Llorenç Huguet-Rotger received his PhD in Computer Science and he is a Full Time Professor of the Department of Mathematics and Computer Sciences at the University of the Balearic Islands (UIB). Since 1995 to 2003, he has been a Chancellor of the UIB. His main research domains are error-correcting coding theory and cryptography, concerning computer and communications security. He is a co-author of three related books, from Masson and Prentice Hall editions.

75

76

A.P. Isern-Deyà et al. This paper is a revised and expanded version of a paper entitled ‘Micropayment scheme implementation on the android platform with performance evaluation’ presented at MoMM2012 (Advances in Mobile Computing and Multimedia 2012), Bali, Indonesia, 3–5 December, 2012.

1

Introduction

Electronic commerce (e-commerce) introduce new requirements and challenges to online applications. Payment is one of the main stages of a commercial transaction and both merchants and customers require new methods to sell and pay in a secure and efficient way. Some purchases (intangible selling of goods such as information: newspapers, product reviews, location-based services (LBSs), etc.; virtual gifts; or electronic data: music, videos, etc.) involve low-value transactions, so the operational cost needs to be as low as possible in order to be profitable for merchants and customers. These payments, called micropayments, have unique functional and security requirements compared to other payment systems designed to manage larger amounts of money that tend to be costly. On one hand, security properties are a primary concern for the development of micropayment systems to control or to avoid financial risks for merchants and to ensure the required privacy for customers. On the other hand, efficiency and the cost of individual transactions are critical factors for the development of these systems. For this reason, the performance of all the proposals have to be evaluated. However, efficiency and security are usually opposed, so micropayment protocols must provide a trade-off between these requirements. Moreover, if the micropayment system has to be implemented on a mobile device, the protocol must be suitable for the specific requirements of this kind of devices.

1.1 Contribution In this paper, we describe the formal verification and the performance analysis based on an implementation on the Android Platform of our efficient, secure, fair and untraceable micropayment system. We presented the micropayment scheme in Momm 2011 (Isern-Deyà et al., 2011) and then we improved it in Isern-Deyà et al. (2012), as a selected paper from the conference, providing full financial risk control to the system. Therefore, the purpose of this paper is double. First, a formal verification using the coloured Petri net (CPN) methodology will be applied to the protocol in order to detect possible mistakes (providing, if it is the case, the opportunity to fix it) and, at the end, assure that the protocol is correct and the claimed properties are achieved. Second, it is necessary to check the viability of the proposal on a real environment. The proposal has been implemented, taking into account that the developed application should be as simple as possible in order to be used by anybody without skills in these types of payment systems. Finally, the implementation of the verified protocol has been tested on current mobile devices in order to obtain a list of performance results (using smartphones with different technical features) proving that our micropayment scheme is suitable to be used in a scenario with mobile devices, although they may have low resources. Once the protocol has been verified and its performance evaluated, we

Micropayment proposal with formal verification

77

are able to affirm that it can be used in practical mobile scenarios to purchase low-value items satisfying the desired features.

1.2 Organisation The paper is organised as follows. In Section 2 we briefly describe the features and the security requirements of micropayment schemes. In Section 3 we review the specification of the proposed micropayment scheme previously published in Isern-Deyà et al. (2011, 2012). In Section 4 we present the formal verification of the protocol using CPNs. In Section 5 we explain how we have implemented the scheme and the results of its performance evaluation. Finally, in Section 6 we expose the conclusions and future work.

2 Micropayment schemes In this section we list the involved parties and the common protocols in the micropayment model (Papaefstathiou and Manifavas, 2004; Poutanen et al., 1998; Schmidt and Müller, 1999). Moreover, we also enumerate and define the security requirements and functional features of an ideal micropayment system (Lipton and Ostrovsky, 1998; Papaefstathiou and Manifavas, 2004; Poutanen et al., 1998; Schmidt and Müller, 1999).

2.1 Scenario The typical involved parties in a micropayment scheme are customer (who wants to buy a good or service), merchant (who wants to sell a good or service) and broker or bank (who issues coins and manages payment accounts). So, the common model consists of a customer who withdraws a coin from his bank’s account (withdrawal or issuing procedure) in order to purchase (payment, spend or transaction procedure) an electronic service or product (henceforth product) offered by a merchant. Finally, the merchant can request a deposit (deposit or claim procedure) in his bank’s account in exchange of a received coin from a customer.

2.2 Security requirements An ideal micropayment system should accomplish a list of security requirements (Poutanen et al., 1998; Schmidt and Müller, 1999) which are depicted below: •

Unforgeability. Coins must be unforgeable, i.e., anyone except the authorised entity is able to issue new coins or modify their content.

•

Overspending. Customers cannot spend more coins than their allowed value.

•

Double spending. A coin must be used only once, so payment schemes should avoid the reuse of a coin or, at least, must detect the reusing coin situations.

78

A.P. Isern-Deyà et al.

•

Unlinkability. It is the property that considers whether different payments can be attributed to the same customer. So, linkability connects different transactions to a user, but this user could remain anonymous.

•

Untraceability. It is defined as the indistinguishability of the past and future interactions of the identity of the user with the knowledge of the current transaction. Thus, the adversary has not to be able to identify the user. In general, untraceability implies anonymity.

•

Anonymity. Anonymity deals with the secrecy of the customer identity in the system in such a way that the customer is able to pay the product without being identified.

•

Atomic exchange. Atomicity allows to logically link multiple operations so that either all of them are executed or none of them are (Tygar, 1996).

•

Fairness. After completion of a protocol run, either each party receives the expected item or neither party receives any useful information about the other’s item (Zhao et al., 2000). Thus, a fair payment is a fair exchange of money for products.

2.3 Functional features A set of functional features are required for micropayment schemes (Lipton and Ostrovsky, 1998; Papaefstathiou and Manifavas, 2004). These schemes should minimise the transactional costs of each microtransaction in order to be a small fraction of the amount transferred in the payment. This fact requires adjustment in the following fields: •

Number of interactions among parties during the payment. Online payments requiring the mediation of the bank are not desirable. The communication costs are lower in offline payments.

•

Volume of information. The volume of transferred information has to be minimised.

•

Computational costs. The use of asymmetric cryptography must be limited or amortised due to its processing time and certificate management costs.

•

Storage requirements. The use of large and complex databases must be avoided.

•

Use of coins. The security algorithms can be implemented more efficiently if coins are built for specific products or specific providers rather than building generic coins for any purpose.

As we can see, most of the functional features deal with efficiency and cost minimisation, which are usually opposed to the security requirements. So, in some cases, the security measures are limited in order to minimise costs. Summarising, an ideal micropayment system should be secure, offline, anonymous, untraceable and it should provide a fair exchange of the coin and the purchased products, with low storage, computational and transactional costs.


79

3 Micropayment proposal review In the literature there are many micropayment proposals (Bayyapu and Das, 2009; Buttyan, 2000; Esmaeeli and Shajari, 2009; Nan et al., 2009; Nguyen and Shao, 2008; Wang et al., 2008; Yang et al., 2009; Zhao et al., 2009; Zongkai et al., 2004) that share the scenario exposed in §2.1, but none of them accomplish all the security requirements stated in §2.2 and functional features described in §2.3. Therefore, new proposals are needed to achieve a micropayment scheme more secure and efficient. To the best of our knowledge, the scheme implemented in this paper is the first one that meets all the security requirements and functional features described in the previous section. In this section, due to space constraints, we simply sketch the micropayment scheme that we had already presented in Isern-Deyà et al. (2011) and improved in Isern-Deyà et al. (2012).

3.1 Cryptographic background We briefly introduce two cryptographic tools (which our scheme is based on): the partially blind signature (PBS for short) and the hash chain. On one hand, a PBS involves a user who requests a signature to the signer. The former sends some blind parameters to the latter, who signs this data without knowing its fully contents. It is similar to the blind signature (Chaum, 1983), but in a PBS scheme, the signer and the user agree on some common information. So, the signer can attach some public verifiable information to the signature. In our scheme, a partially blind signature (Chien et al., 2001) based on RSA has been used. On the other hand, the aim of hash chain is to produce a chained list of elements starting from a random seed element (ωN ) to the last element, called root (ω0 ), by applying iteratively a cryptographic hash function H, i.e., ωN −1 = H (ωN ) , ωN −2 = H (ωN −1 ), . . . , ω0 = H (ω1 ). Then, the verification of an element ωi is done applying i times the hash function on ωi up to the root element, which is public and known by the verifier.

3.2 Proposal overview The micropayment scheme involves the usual parties of the micropayment model: customer (C), merchant (M) and a bank (B) as a trusted third party (TTP). C contacts different merchants to obtain a list of available items and, if she is interested on a product from M, then C starts the process to withdraw a specific coin for M. The coin is composed by a number of tokens that we call coupons. These coupons can be used by C to pay M in exchange of his products. Multiple coupons can be spent using the same transaction, so the efficiency of the protocol is increased. When M has a list of received coupons, he can exchange it for a deposit in his bank account. Finally, the protocol provides an optional refund procedure to allow C to request a reimbursement of her unused coupons whether she is no more interested in the purchase of more products from M. Figure 1 defines the shelf life of a coin, i.e., it describes some time marks to limit when each protocol can be used. These time marks are also useful from the point of view of efficiency, because when a coin is expired, all parties can erase its related data.

80


The coin C (Figure 2) consists on two elements: a coupon chain (Cω ) made by a list of chained elements, called coupons, and the partially blind signature (CPBS ) on the coin identifier. Figure 1

Shelf life of coins (see online version for colours)

7+/+ )(K"(1/

τr

τd

τexp 4τd

4τr

B%/07)+B+$ 1!(,7

)(*",7 7(!-1%/

Figure 2

Coin structure (C), (a) coupon chain (Cω ) (b) partially blind signature (CPBS ) on the coin identifier (see online version for colours)

1((7 &-"!-, ?ω(2N )C @

!+6.(,/ &-"!-, ?ωiC @ !)--* &-"!-, ?ω(i+1)C @ &-"!-, !+%)

)--/ &-"!-, ?ω0C @

(a) ?+@ L-"!-, &0+%, ?Cω @

&-..-, %,*- ?Γ@

&-%, %7(,/%*%() ?ω0C , ω0M @ '()%*%&+/%-, 7+/+ ?∆, Ω@ .()&0+,/ %7(,/%*%() ω0M

)--/ &-"!-, ?ω0C @ (b)

The element Cω [Figure 2(a)] contains 2N + 1 chained coupons, each of them defined as ωiC , where i denotes the coupon position (index) within the chain. This chain is obtained by the use of the hash chain procedure applying 2N hash operations on a random seed element (ω(2N )C ) up to the final coupon called root coupon (ω0C ). The element CPBS [Figure 2(b)] is the result of applying the partially blind signature to the blinded coin identifier (ω0C , ω0M ) together with the common information field (Γ). As a result, CPBS contains three elements: •

The common information (Γ = (2N, v, τexp , △τd , △τr )), describing products offered by M. It contains the required number and value of coupons to be


81

purchased to access M and the list of time marks to conform different time ranges where each protocol can be used. •

Verification data (∆, Ω) which will be used to verify the PBS.

•

The coin identifier (ω0C , ω0M ), where ω0C is the root coupon of the chain and ω0M is the merchant identifier.

Following, we will describe briefly each involved protocol. We address the reader for further details to the full protocol description in Isern-Deyà et al. (2011, 2012). Table 1 shows the notation used in the protocol description. Table 1 Notation used along the protocol description Element

H (x) Hi (x) SKA , PKA

CertA SA (x) R

x ← Zr R

x←

Z∗n

KS EKS [x], DKS [x] C Cω CPBS

(e, n) (d, p, q) τd τr (if it applies)

Description One-way collision resistant hash function H () function applied i times A’s key pair of a public key cryptosystem Digital public key certificate of A A’ signature on the element x Element x randomly chosen from Zr set Element x randomly chosen from Z∗n set Symmetric key KS Encryption and decryption of x using KS Coin issued by B composed by [Cω , CPBS ] Coupon chain list Partially blind signature on the coin identifier RSA public key of B RSA private key of B Time mark until M can request a deposit Time mark until C can request a refund

3.2.1 Setup As a previous step, all parties have to obtain a RSA key pair together with a digital certificate from a trusted Certification Authority (CA). This key pair will be also used by B to use the selected PBS scheme, as described in Chien et al. (2001). Moreover, both C and M setup an account in B and pay a sum into it. Then B links the corresponding digital certificate to the account in order to authenticate parties when it is required (during the withdrawal, deposit and refund protocols, the latter if it is allowed).

3.2.2 Data request protocol C searches for a merchant with interesting offered products and when she finds the proper merchant, C and M agree on some data contained in a common information array. This array describes the characteristics of the product offered by M. During the process (Figure 3), M creates an identifier (ω0M ) from a secret element which should be kept in secret by M in order to prove that he is the proper coin’s receiver.

82


Figure 3

Data request protocol flow

C

M hello R

ω1M ← Zr ω0M ← H (ω1M ) Γ = (2N, v, τexp , △τd , △τr ) SM (ω0M , Γ) stores [Γ, ω1M , ω0M ] ω0M , Γ, SM (ω0M , Γ) , CertM

Checks if Γ is correct (i.e., it has the expected parameters) Stores [Γ, ω0M , SM (ω0M , Γ)]

3.2.3 Withdrawal protocol Using as input the data previously obtained, C runs the withdrawal protocol (Figure 4) with B. The protocol is based on the referred PBS scheme, where B signs a blinded data (the coin identifier, i.e., (ω0C , ω0M )) together with the agreed common information [Γ]. As a result, C obtains CPBS = [(Γ, ∆, Ω) , (ω0C , ω0M )], whose identifier is unknown by B. Thus, C has withdrawn a coin composed by the partially blind signature element and the coupon chain, i.e., C = [Cω , CPBS ]. This coin is anonymous and untraceable, since B will not be able to link a single coin with neither a single withdrawal process nor a particular customer. CPBS can be verified by anyone who knows B’s public key (e, n) comparing both sides of the following equation: ?

2

Ωe ≡ H (Γ) H (ω0C ∥ ω0M )

(

∆2 + 1

)2

mod n

(1)

If this equation holds, the entity accepts CPBS . Otherwise, the entity rejects to receive CPBS .


83

Withdrawal protocol flow

Figure 4

C

B R

ω(2N )C ← Zr ( ) ωiC = Hi ω(i+1)C where 0 ≤ i ≤ 2N Extracts Γ = (2N, v, τexp , △τd , △τr ) η, µ ← Z∗n R

( ) α = η e H (ω0C ∥ ω0M ) µ2 + 1 mod n Signs (Γ, α): SC (Γ, α) (Γ, α) , SC (Γ, α) , CertC Cbalance ≥ N · v, otherwise B stops Are Γ.2N , Γ.v and Γ.τexp valid? λ ← Z∗n R

λ ρ ← Z∗n R

b = ηρ β = be (µ − λ) mod n (*) β φ = β −1 mod n ( ( ) )2d γ = H (Γ)d α λ2 + 1 β −2 mod n Cbalance = Cbalance − N · v (φ, γ) ∆ = (µλ + 1) β −1 be = 2 4

Ω = γη ρ

µλ+1 µ−λ

mod n

mod n

The signature is composed by CPBS = [(Γ, ∆, Ω) , (ω0C , ω0M )] The complete coin is C = [Cω , CPBS ] (*) In the odd case that mcd (β, n) ̸= 1 generate a new ρ, because β has not modular inverse

3.2.4 Spend protocol When C wants to use coupons from C, she invokes the spend protocol (Figure 5). It is defined as an offline operation (B is not involved) and it is a fair exchange between


84

C and M, where a number of coupons and the desired product are exchanged. The protocol allows spending more than one coupon at once, providing many coupons in a single transaction. Thus, with this multi-spending feature, the efficiency of the scheme is improved. Figure 5

Spend protocol flow

C

M

Extracts KS Extracts the next payment coupon ωiC Composes r = (C, req, ωiC , i) Encrypts r: EKS [r] EKS [r] Decrypts r = DKS [EKS [r]] Verifies C (applying eq. 1) Checks τnow ≤ Γ.τexp Gets index j related to C from local database ?

Verifies if ωiC ∈ C: H(i−j) (ωiC ) ≡ ωjC Checks reuse: if i ≤ j then M denies Stores (C, ωiC , j = i) Fills prd according to req Encrypt prd: EKS [prd] EKS [prd] Decrypts prd = DKS [EKS [prd]] Extracts the next proof coupon ω(i+1)C Composes r = (ωiC , ω(i+1)C , i + 1) Encrypts r: EKS [r] EKS [r] Decrypts r = DKS [EKS [r]] Verifies if ω(i+1)C belongs C ( ) ? Verifies ωiC ≡ H ω(i+1)C ( ) Updates C, ω(i+1)C , j = i + 1


85

3.2.5 Deposit and refund protocols On one hand, the deposit protocol (Figure 6) allows M to deposit in his bank account the value of the received coupons from customers. M can request as many partial deposits within the allowed time range, although he has not received all the coupons from a particular coin. So, B increases M’s balance according to the value and the number of received coupons if all the verifications hold. Figure 6

Deposit protocol flow

M

B

Composes r = (C, ω1M , ωiC , i, {prd}) Encrypts r : EPKB [r] EPKB [r], SM (r) , CertM Decrypts r = DSKB [EPKB [r]] Verifies signature of r Verifies C (applying eq. 1) Verifies Γ.τexp < τnow ≤ τd Gets index j related to C from local database ?

ω0M ≡ H (ω1M ) ?

Verifies if ωiC ∈ C: H(i−j) (ωiC ) ≡ ωjC Checks reuse: if i ≤ j then B denies Deposited coupons will be: Case1. i odd and prd provided (M claims): [ ] ⌋ deposit value of ω(i+1)C , ωjC : ⌊ (i+1)−j 2 store prd for later refund procedure Case2. i even (M does not claim): deposit value of [ωiC , ωjC ]: ⌊ i−j ⌋ 2 Otherwise: B denies Sets j = i SB (”accept/reject”, ωjC , i, C)

On the other hand, the refund protocol (Figure 7) is an optional procedure that can be run by C after the allowed deposit range of time. It benefits C allowing her to request B a reimbursement of a number of unused coupons from an expired coin. This protocol is similar to the deposit protocol, so we address again readers to the full protocol

86


specification in Isern-Deyà et al. (2011, 2012) for further details. The availability of this protocol will always depend on the type of product offered by M. Refund protocol flow

Figure 7

C

B

r = (C, ωkC , ωiC , k, i) Encrypts r : EPKB [r] Signs r : SC (r) EPKB [r], SC (r) , CertC Decrypts r = DSKB [EPKB [r]] Verifies signature of r Verifies C (applying eq. 1) Verifies τd < τnow ≤ τr Gets index j related to C from database ?

Verifies if ωiC ∈ C: H(i−j) (ωiC ) ≡ ωjC Verifies if ωkC is the seed coupon of C Refund coupons will be: Case1. j even (M has not claimed): [ ] refund value of ωkC , ω(j+1)C : ⌊ (k−(j+1)) ⌋ 2 Case2. j odd (M has claimed): [ ] refund value of ωkC , ω(j+2)C : ⌊ (k−(j+2)) ⌋ 2 Sets j = k SB (”accept/reject”, ωjC , j, C, prd)

4 Formal fairness verification with CPNs 4.1 Coloured Petri nets A Petri net is a mathematical and graphical discrete-event modelling language for constructing models of concurrent and distributed systems and analyse their properties. There are other modelling languages (such as UML activity diagrams), but Petri nets are the only methodology that is supported by a mathematical theory that defines both their construction and their analysis. A Petri net is defined mainly by places, transitions, arcs and tokens:


87

•

Place. It can store a discrete number of tokens.

•

Transition. It is the action that changes the contents of a place. When a transition fires, the global state of the system changes.

•

Arc. It connects places and transitions. A token is transferred between a place and a transition (or from a transition to a place) through an input arc (or an output arc).

•

Token. It is an element that is transferred along the model. It can enable transitions whenever there are sufficient tokens at input arcs.

Once a transitions fires, the global state of the system is changed and configured by a new distribution of tokens over places. Each of these states are called markings and they can be seen such as photos of the token distribution along the model. CPNs are an extension of the original Petri net adding some functionalities to the Petri net language. In a Petri net, tokens are indistinguishable whereas in CPN, each token has a concrete type, called colour. Like original Petri nets, CPN could be also useful to analyse applications and services such as communication protocols, data networks, embedded systems, business processes, and so on. CPNTools (CPNTools, http://cpntools.org/; Jensen et al., 2007) is the most popular tool to deal with CPN. CPNTools presents a simple but powerful graphical interface that allows us to create, edit, model, simulate and analyse complex and distributed systems using CPN. The application is bounded with a functional programming language, called standard ML (Jensen et al., 2007) which is used to provide the primitives to define colours, describing data and its manipulation, allowing the creation of parametrised models. An interactive simulation provides a way to check whether a CPN model is properly implemented and whether it works as expected. Moreover, an automatic simulation tool is provided to execute the CPN model as fast as possible, without detailed human interaction and inspection. After a complete simulation, we can analyse all the states of the system using the state space tool provided by CPNTools. Therefore, we can extract the complete behaviour through the analysis of the computed state space. In addition to the elements that define a Petri net such as places, transitions, arcs and tokens, CPNs also add the following components to the language: •

Colour set. Tokens that move through places and transitions have a value, called a colour.

•

Variable. It is an identifier whose value can be changed during the execution of the model.

•

Function. CPNTools introduce some functions that can be used by a model to deal with colour sets. Functions follow the syntax of the ML language and it is also possible to define and develop custom and powerful functions to change the behaviour of the model (for example, a transition can be only fired under a condition written by function) or to inspect the state space (query function traversing the state space looking for whether tokens are or not present in some states and in order to know their value at any time of the simulation).

88


Figure 8 shows a simple CPN example, where all of the above elements are depicted. There are two places (with names place1 and place2 and marked with an integer colour), two transitions (called t1 and t2) and four arcs connecting the places with the transitions. Each arc has a variable which will be filled by a token to transfer it along the model. Note that only one transition is enabled to be fired due to a condition (enclosed by square brackets). Finally, a simple function relies at output arcs, causing that the input token value is increased by an integer value. Figure 8

A CPN example built using CPNTools (see online version for colours)

[vi=1] 1`1 place1 1

vi

1`1

t1

vi+2

INT

[vi=2] vi

t2

vi+1

place2 INT

As stated before, Petri net and CPN models are formal methods backed by a solid mathematical foundation, so they can be used to formally verify properties of distributed systems and communication protocols. Following the CPN methodology, Sornkhom and Permpoontanalarp (2008, 2009) and Payeras-Capellà et al. (2009) formally analyse the fairness of two contract signing protocols, and Katsaros (2009) formally verify the Netbill micropayment protocol.

4.2 General assumptions and methodology In order to use the CPN language to model our micropayment proposal, we have to define some initial assumptions: •

we define an initial marking, where each party of the model has an unique identifier

•

each party already has the public keys of the other entities just before to start the model execution

•

we suppose that all the cryptographic algorithms (signature and encryption algorithms) are secure, since we do not check the security of these algorithms, but the fairness of the whole protocol.


89

In addition to these initial assumptions, we have defined a process starting from the creation of the model up to the analysis of the results given in by CPNTools: •

First of all, we build the model following these basic steps (based on a bottom-up process): 1

declare colour sets to represent all the messages and the elements of the protocol

2

create a top-level net to model the parties

3

create an entity-level net to model the behaviour of each party

4

create a process-level net for each entity where we define all the actions performed by each entity

5

declare several variables within the model to store results and transfer tokens

6

declare a number of functions to include conditions and token transformations.

•

Once the model is created, we have to setup the initial marking for each entity.

•

After that, we can generate the full state space, using the corresponding tool from CPNTools, obtaining all the available markings and combinations of them.

•

Before to analyse the results, we have to create some query functions to look for markings that meet certain conditions.

•

Finally, using these functions, we can extract a list of dead markings (markings where the execution of the protocol is already concluded) where probably an unfair state happens. If some unfair markings are detected, we can graphically explore the path from the initial marking to that dead marking to investigate the exact attack trace which has conducted to the unfair marking.

4.3 Fairness verification using CPN Armed with the methodology listed above and using the CPNTools application, we formally verify the fairness of our micropayment scheme (comprising spend, deposit and refund protocols). In order to do that, we have implemented the original micropayment (Isern-Deyà et al., 2011), to prove that our formal verification method can detect the theft flaw described in a later improved version of the same micropayment (Isern-Deyà et al., 2012). Figure 9 contains the representation of the top-level net that models the micropayment scheme. In this figure, we define the three involved entities and the messages exchanged between them. Note that we have defined many colours in order to model all types of messages transferred during the protocols and also to store tokens of different colours in the databases of each entity. Each rectangle represents a substitution transition, i.e., a big transition that covers the concrete behaviour of the corresponding party, as stated by the above methodology.

90


Figure 9

Top-level net modelling the micropayment scheme (see online version for colours)

Figure 10 Query functions bring us some unfair dead markings (see online version for colours)


91

Table 2 List of likely unfair states output by CPNTools State

Caccount

Maccount

Crs

Advantage

172 175 176 118 177

2 2 1 0 1

0 0 1 2 1

1 1 2 1 0

Customer Customer Customer Merchant Merchant

Notes: Caccount : value of the customer’s account in B. Maccount : value of the merchant’s account in B. Crs : number of received services by C from M.

Once the model is fully deployed, we have to add all the initial markings to the model, such as setting the key pairs and initialising the coin with the number of considered coupons to be exchanged during the protocol execution. We have decided to evaluate the model taking into account two pairs of coupons, so we will execute the spend protocol up to twice. The next stage to perform is to check the model step-by-step verifying whether it works well. When we are sure that the model works as expected, we initialise the simulation process obtaining the complete state space of the system. Applying different search queries, Figure 10 lists the markings where either the customer or the merchant acquires, at least initially, certain advantage over the counterpart. The following enumeration explains what is happening in each case of interest, depicted in Table 2. •

Marking 172. Malicious C stops the first spend transaction after receiving the requested service. M cannot run the deposit protocol since he only has the first payment coupon. C waits for the refund time and finally, C executes the refund protocol, obtaining a refund of the whole chain, i.e., the value of two pairs of coupons. Thus, C gains advantage over M.

•

Marking 175. M maliciously stops the first spend transaction before sending the service. Then, M tries to execute a deposit, but he only has the first payment coupon, so B denies it. C inits a new spend transaction using the third coupon, M sends the service and C does not send the corresponding proof coupon. M does not run the deposit protocol within the allowed time using the third or the second coupon. Finally, C obtains a refund of the whole chain. So, C gains advantage over M although the latter first has played maliciously and secondly M has harmed himself because he has not requested a deposit in time.

•

Marking 176. The first spend transaction finishes correctly, then M executes the deposit protocol and he obtains the value of the first pair of coupons. During the second instance of the spend protocol, C maliciously stops the exchange after receiving the desired service (she does not send the corresponding proof coupon). Therefore, M cannot request a deposit using only a payment coupon without the corresponding proof coupon, because B denies it. Finally, C waits and executes the refund protocol, obtaining a reimbursement of the second pair of coupons. So, C gains advantage over M.

92


•

Marking 118. Malicious M stops the first spend transaction before sending the requested service. Then M tries to run the deposit protocol, but he only has the first payment coupon, so B denies it. C starts a new spend transaction finishing successfully. M runs the deposit protocol, obtaining the corresponding value of the whole chain, i.e., the two pairs of coupons. Finally, C does not receive a refund as a compensation for the lost service during the first spend transaction. So, M gains advantage over C.

•

Marking 177. Malicious M stops both spend transactions with C before sending her the requested service. So, M has up to the third coupon without sending any service to C. Then, M runs the deposit protocol using the third coupon and he obtains a deposit of the first pair of coupons. C runs the refund protocol and B refunds her the second pair of coupons. Therefore, M obtains some advantage over C, even though C is able to recover the value of the last pair of coupons.

Analysing carefully each case, we have detected that there are cases where unfair situations arise due to the malicious behaviour of either C or M. On one hand, in the instances 172, 175 and 176, C obtains advantage over M. However, only cases 172 and 176 are due to the malicious behaviour of C who stops the protocol after receiving the desired service from M (case 172 was detected and corrected in Isern-Deyà et al. (2012)). Instance 175 is different, because in this case, M stops the spend protocol (so M acts maliciously) causing an unfair situation but M forgets to execute the deposit protocol within the allowed time. As a result, C obtains an advantage when she refunds an already used pair of coupons. On the other hand, both markings 118 and 177 contain two situations where M follows a malicious behaviour, stopping the spend protocol after receiving the payment coupon. Thus, M gains advantage over C in both cases. Therefore, we have proved that the proposed CPN methodology to formally verify the micropayment system helps us to identify the previously detected flaws and in addition, to discover new unfair situations not so easy to find out without an automatic checking tool like CPNTools. Now, we have to apply the same process to model the modified version of the micropayment scheme presented in Isern-Deyà et al. (2012). During the step-by-step model checking, we have found a notation mistake in the way that B refreshes the indexes once deposit and refund protocols finish, causing some inconsistencies in the number of deposited and refunded coupons. So, before to perform an automatic simulation to obtain the complete state space of the system, we already have corrected this little problem in the protocol. Thus, the CPN methodology has been proved very useful to check the behaviour of a concurrent system even without using the automatic simulation tool. Regarding the deposit protocol, Figure 11 shows the piece of pseudo-code that replaces the corresponding fragment of Figure 6. Note that we highlight the modified lines. Concerning the refund protocol, a similar trouble has been detected, so Figure 12 shows the changes that must be applied to the Figure 7. As before, modified lines are highlighted. Now, after applying the last modification to the micropayment scheme, we are ready to perform an automatic simulation, analysing the results obtained applying the query functions to look for unfair states. Figure 13 shows that the new improved scheme is fair due to the fact the query functions applied over the resulting state space do not


93

find any unfair dead marking. Thus, we have successfully verified formally that the new protocol is fair for both customers and merchants. Figure 11 Changes to the deposit protocol (see online version for colours)

Case1. i odd. (it means that M claims for a previously lost proof coupon) 1. Verifies whether res is provided, otherwise stops [ ] 2. Deposits value between coupons ω(i+1)C , ωjC : ⌊ i−j+1 ⌋ 2 3. Stores res for a later refund call ′

4. j = i + 1 (the new j becoming as an even index) Case2. i even. (it means that M does not claim) ⌋ 1. Deposits value between coupons [ωiC , ωjC ] : ⌊ i−j 2 ′

2. j = i Otherwise. Denies the request

Figure 12 Changes to the refund protocol (see online version for colours)

Case1. k odd. (1) [ ] 1. Refunds value between coupons ω(k−1)C , ωjC : ⌊ k−j−1 ⌋ 2 ′

2. j = k − 1 (the new j becomes even) (1) 3. If M has claimed in the deposit: B sends lost res to C Case2. k even. 1. Refunds value between coupons [ωkC , ωjC ] : ⌊ k−j ⌋ 2 ′

2. j = k 3. If M has claimed in the deposit: B sends lost res to C Otherwise. Denies the request

Notes: (1): It means that C renounces to obtain a full refund, because she only sends the payment coupon rather than the corresponding proof coupon. (2): B cannot refund k + 1 coupons due to the fact C does not provide the corresponding proof coupon (ω(k+1)C ), because she only sends the payment coupon (ωkC ). So B proceeds to make a refund up to the previous pair of coupons).

94


Figure 13 Query functions do not detect any unfair marking (see online version for colours)

5 Prototype implementation and performance analysis In this section we describe the prototype design and the implementation of our micropayment protocol on the Android Platform, putting emphasis on how the user experience for customers is. Later, in §5.3 we will discuss the performance results obtained by our implementation, proving that our scheme is suitable to its use in a real mobile environment with current smartphones.

5.1 Android Android (http://www.android.com) is a Linux-based operating system for mobile devices from smartphones to tablets. It is developed by the Open Handset Alliance, led by Google, together with other software and hardware manufacturer companies. Actually, Android is the leading mobile operating system with about 400 million of Android devices activated and over a million new activations every day (Android Developers Google+ Profile, 2012). The system consists on a kernel based on the Linux kernel, with middleware, libraries and APIs written in C and applications running on top of an application framework available to developers which includes a set of Java libraries. Android applications run on a modified Java Virtural Machine (VM), called Dalvik, and it is the responsible of executing applications in the operating system. There are other mobile operating systems such as iOS, Windows Phone (formerly Windows Mobile and soon called Windows 8), Blackberry OS or webOS, among others. The decision to use the Android Platform instead of other environments to develop the prototype of our micropayment scheme is due to the following reasons: •

the existence of a software development kit (SDK) with a well structured application programming interface (API) allowing developers to build applications using the Java language in which we have experience

•

the constant improvement of the platform by many software and hardware manufacturers bringing us new features over the time

•

the availability of a great number of different handset devices to test developments

Micropayment proposal with formal verification •

95

a very big community of developers around the platform that allows us to find a huge number of resources, examples and so on.

5.2 Prototype implementation The micropayment scheme described in §3 can be used to pay for any low-value electronic file, data or information; therefore, it is a general single-merchant micropayment system. In order to provide an example of a service that could be paid with our micropayment scheme, we have chosen to apply the system to a LBS. In this service example, customer acquires a coin of coupons to pay a location-based provider who acts as a merchant. The provider offers location-based responses providing customer information and localisation of points of interest (POI), restaurants, hotels or cinemas close to her current position, depending on the request made by her. Then, localisation of requested places are sent back to the customer application. Locations are placed on a geolocalised Google Map using the corresponding public API, together with her current location, so customer can easily find the desired place. Thus, it is a clear example of an application to buy small pieces of information (location data) using an efficient micropayment scheme to pay small amounts of money in each spending transaction. Figure 14 System workflow: interactions between customer application, bank and merchant servers (see online version for colours)

Customer Application 0. con gure

Merchant Application 0. con gure

double-spending check

2. data request protocol

1. select merchant

store and retrieve 3. provide data

Products provide

Coins and coupons storage

store and retrieve 6. start spend

9. spend protocol

7. retrieve coin 8. current position

Bank Application

5. store coin

Secure Store 4. withdrawal protocol 11. retrieve coin

Parties accounts

check balance balance--

10. start refund Authentication required by password/PIN

balance++ store and retrieve

KeyStore 12. refund protocol

balance++ store and retrieve

Coins and coupons storage

deposit protocol

96


In order to implement the described service, using the referenced micropayment scheme, we identify the system workflow that is shown in Figure 14. The workflow represents all the interactions between the customer application and the servers. So we can distinguish four key parts in the application design: the client side and the provided experience to its users; the server side; the messages exchanged during the protocol flow; and finally the PBS scheme implementation. Below we describe further each module.

5.2.1 Customer application and user experience Even though the micropayment scheme was designed to be as simple as possible in order to increase the efficiency and decrease the computational, storage and network costs, the implementation needs to be even simpler keeping in mind that maybe users do not have previous skills in similar payment methods. So, our implementation minimises the effort that customers have to do to use the scheme. So much so that we have made transparent for the customer the withdrawal process since once the user chooses the target merchant, the application collects the required information to withdraw the coin, making the user experience more comfortable and reducing possible mistakes from the customer input. Since the application is required to use some private information stored in the customer smartphone, she needs to provide some authentication data in order to access in a secure way to this information. So, the application asks the customer for a PIN or password to access her private credential storage when it is required. Android provides a secure credential storage module used to store credentials in a secure way. For versions before Ice Cream Sandwich (4.0, API level 14), private keys and certificates could be installed in the secure credential storage through the use of the Settings application, but the credential storage does not expose a public API to access this data from third party applications. Since we have to use API level 8 to accomplish compatibility for testing devices (see §5.3.1), we cannot use the secure credential storage. Then, customer credentials (RSA key pair, digital certificate) have been installed in the SD card using a password-protected keystore (using the standard Java class KeyStore). The application requires the customer to type in her password to open the keystore in order to read credentials on her behalf. The customer application is defined through five instances to the main class of Android UI, the android.app.Activity, following the protocol workflow described in Figure 14: •

DataReqWithdrawalActivity. This is the first window of the application [Figure 15(a)]. It shows to the customer the list of available services in various merchants. Every row describes the number of available requests and the price for each of them. When the customer clicks on one of the merchants, a request of a new and specific coin for the desired merchant is sent to the bank. If the customer is already registered by the bank and if she has enough balance in her account, the application guides her automatically to the SpendActivity view. Otherwise, an error message is sent back to the customer.

•

SpendActivity. In this view, customer is geolocalised on the map and when she clicks the ‘Spend’ button, the spend protocol is invoked. Then, the list of received results from merchant is also geolocalised on the map [Figure 15(c)].


97

•

RefundActivity. This activity starts the refund protocol requesting to the bank a reimbursement of her unused coupons.

•

LogActivity. It shows the activity log of the application, such as the protocol state and the exchanged messages.

•

SettingsActivity. It allows the customer to tweak various settings concerning the application configuration, like network addresses, paths and credentials [Figure 15(d)].

Figure 15 Screenshots of the developed Android application, (a) DataReqWithdrawalActivity view before withdrawal (b) SpendActivity view before execute the spend protocol (c) SpendActivity view after the spend protocol (d) SettingsActivity view to configure the application (see online version for colours)

(a)

(b)

(c)

(d)

5.2.2 Server applications The server applications cover the bank and the merchant parties, so each of them has been developed as an independent and standalone server instance. Both servers have been developed using the Java JDK 6.0 platform. As the customer application does, each server needs some private data (public and private keys, and digital certificates) and it should be stored in a secure way. To do so, private credentials have been stored and protected through a password in a Java KeyStore file. The bank server stores accounts and current balances for every party in a local file. The merchant server stores the received coins, coupons and the current state of each step of the protocol in a temporal in-memory data store. As it is the first prototype and we prioritise the performance testing, we do not want to use a complex relational database management system (RDBMS) such as MySQL or similar one, because we want to analyse only the scheme applicability and performance regardless of the used database engine. In contrast, every time servers are shutdown, the temporal data store will be deleted and given back to its initial state.

98


5.2.3 Messages formatting Messages exchanged among parties during every protocol run are encoded using eXtensible Markup Language (XML). It is a markup language that defines a set of rules for encoding documents and data structures in a format that is both human-readable and machine-readable since it provides a textual representation. Therefore, it is focused on simplicity, usability and generality. There are lots of frameworks and libraries that can be considered to deal with XML documents, but not all of them can be used in an Android environment. For example, JAXB (http://jaxb.java.net) is the Java reference implementation for (un)marshall Java objects into their corresponding XML representation. However, JAXB is not supported by Android since it is not included in the provided SDK and thus, it cannot be executed by the Dalvik Virtual Machine (VM). Then, we have decided to use a combination of document object model (DOM) and simple API for XML (SAX), both fully supported by the Android API. Messages are sent through a servlet in the server side and received using Java sockets in the customer application. Nevertheless, the message formatting conforms a building block in our implementation. It means that the process of (un)marshall Java objects can be replaced by other methods or representation languages since our implementation removes the link between the message contents and the message building. Therefore, a change in the (un)marshalling module does not affect to the message management in the system, therefore it will remain the same. For example, this building block can be replaced by using Simple XML framework (Simple XML Framework, http://simple.sourceforge.com) to manage the process of (un)marshall or it could be changed by other representation languages like ASN.1, YAML or JSON.

5.2.4 The partially blind signature implementation The implementation of the PBS scheme (Chien et al., 2001) has been challenging since modular operations are mixed with hash operations. Moreover, methods are required to encode values into strings ready to be send inside the XML messages and again decoded at the reception to the corresponding object. Operations have been computed using the Java’s BigInteger class and the Bouncy Castle cryptographic library (Bouncy Castle Library, http://www.bouncycastle.org/java.html), which are in charge of modular large exponentiations, modular multiplications, modular inverses and RSA computations. The most complex computations of the PBS scheme, due to the number of modular operations combined with hash computations are ) )2d d( ( γ = H (Γ) α λ2 + 1 β −2 mod n (during the step 4th of the withdrawal protocol) and equation (1) (to verify the PBS element). However, as claimed in §5.3, these operations can be computed efficiently by a mobile device. Figure 16 depicts the Java code to compute the signature [Figure 16(a)] and to verify the corresponding signature [Figure 16(b)].

5.3 Performance evaluation Now we are going to show that our implementation, and therefore our micropayment scheme, is efficient and usable in a real mobile environment, evaluating and discussing the performance results obtained after an extensive test.


99

Figure 16 Code snippets of the implemented PBS scheme, (a) piece of code referred to the PBS computing process (b) piece of code refered to the PBS verification process "B;AMi2;2` 6A 4 #2i X KQ/AMp2`b2 U#MF X `bL"MFV c "B;AMi2;2` J4 J#2i R4 l i B H b X ;2i>b?U+QKKQMAM7QV XKQ/SQrU#MF X `b."MF - #MF X `bL"MFV c "B;AMi2;2` : 6A X KQ/AMp2`b2 U#MF X `bL"MFV c "B;AMi2;2` XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X `bL"MFV X //U "B;AMi2;2` "B;AMi2;2` :JJkR :JJR 44 lHK#/ i B H b X ;2i>b?U+QKKQMAM7QV XKQ/SQrU#MF X `b."MF - #MF X `bL"MFV c XPL1V XKQ/U#MF X `bL"MFV c "B;AMi2;2` :JJkR 4 HK#/ XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X `bL"MFV X //U "B;AMi2;2` "B;AMi2;2` :JJkk 4 #2i X KQ/AMp2`b2 U#MF X `bL"MFV XKQ/SQrUM2r "B;AMi2;2` UǴkǴV #MF X XPL1V XKQ/U#MF X `bL"MFV c `bL"MFV c "B;AMi2;2` :JJkk 4 #2i X KQ/AMp2`b2 U#MF X `bL"MFV XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X "B;AMi2;2` :JJ `bL"MFV c k 4 HT? X KmHiBTHv U:JJkRV XKQ/U#MF X `bL"MFV c :"B;AMi2;2` JJk 4 :J J J kX KmHiBTHv U:JJkkV XKQ/U#MF X `bL"MFV : J k 4 HT? X KmHiBTHv U:JJkRV XKQ/U#MFcX `bL"MFV c : X `b."MF X KmHiBTHv UM2r "B;AMi2;2` UǴkǴV V - #MF X `bL"MFV c : J JJ J kk 4 4: : J JJ J kXKQ/SQrU#MF kX KmHiBTHv U:JJkkV XKQ/U#MF X `bL"MFV c "B;AMi2;2` J J J 4 :JJRX KmHiBTHv U:XJ JkV XKQ/U#MF X `bL"MFVUǴkǴV c : JJk 4 :: J kXKQ/SQrU#MF X `b."MF KmHiBTHv UM2r "B;AMi2;2` V - #MF X `bL"MFV c "B;AMi2;2` :JJ 4 :JJRX KmHiBTHv U:JJkV XKQ/U#MF X `bL"MFV c

(a)

PBS

ai`BM; J 4 +QBM X ;2iqylb2`U V X iQai`BM; UReVY+QBM X ;2iqyS`QpB/2` U V X iQai`BM; UReV c "B;AMi2;2` 4 +QBM ;2iPK2;U V XKQ/SQrU#MF X `b1"MFU -V X#MF X `bL"MFV ai`BM; J 4 +?2+F*QBMR +QBM X ;2iqylb2`U V X XiQai`BM; UReVY+QBM X ;2iqyS`QpB/2` iQai`BM; UReV c c "B;AMi2;2` i B H bX ;2iPK2;U X ;2i>b?U+QKKQMAM7QV XKQ/U#MF X `bL"MFV c "B;AMi2;2` +?2+F*QBMk +?2+F*QBMR 4 4 l +QBM V XKQ/SQrU#MF X `b1"MF - #MF X `bL"MFV c +?2+F*QBMk +?2+F*QBMk U l i B H b X ;2i>b?UJV XKQ/SQrUM2r "B;AMi2;2` "B;AMi2;2` 4 +?2+F*QBMk 4X KmHiBTHv l i B H b X ;2i>b?U+QKKQMAM7QV XKQ/U#MF X `bL"MFV c UǴkǴV - #MF X `bL"MFV V XKQ/U#MF X `bL"MFV c +?2+F*QBMk 4 +?2+F*QBMk X KmHiBTHv U l i B H b X ;2i>b?UJV XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X +?2+F*QBMk 4 +?2+F*QBMk U +QBM `bL"MFV V XKQ/U#MFX KmHiBTHv X `bL"MFV c X ;2i.2Hi U V XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X `bL"MFV X //U "B;AMi2;2` XPL1V X +?2+F*QBMk 4 +?2+F*QBMk X KmHiBTHv U +QBM X ;2i.2Hi U V XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X KQ/U#MF X `bL"MFV XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X `bL"MFV V XKQ/U#MF X `bL"MFV c `bL"MFV X //U "B;AMi2;2` XPL1V X B 7 KQ/U#MF U 5 +?2+F*QBMR X 2[mHb U +?2+F*QBMk V V X `bL"MFV XKQ/SQrUM2r "B;AMi2;2` UǴkǴV - #MF X `bL"MFV V XKQ/U#MF X `bL"MFV c M2r 1t+2TiBQM UǴU o 2 ` B 7 B + i B QVMV Q7 i?2 T ` i B H H v #HBM/ bB;Mim`2 /Q2b MQi ?QH/ ǴV c B 7 i?`Qr U 5 +?2+F*QBMR X 2[mHb +?2+F*QBMk

i?`Qr M2r 1t+2TiBQM UǴ o 2 ` B 7 B + i B Q M Q7 i?2 T ` i B H H v #HBM/ bB;Mim`2 /Q2b MQi ?QH/ ǴV c

(b)

Figure 17 Test scenario (see online version for colours)

5.3.1 Test scenario The considered test scenario (Figure 17) is composed by a notebook, where servers run, and two different Android smartphones, where the customer application runs. The technical features of each device are shown in Table 3. The first one (HTC Desire)

100


is a medium-high class Android device while the second one (HTC Wildfire) is a low-medium class Android smartphone. Testing our scheme over two devices with different processing capabilities is interesting because it can provide us information about the performance of the scheme depending on the device features. It is also useful to estimate the efficiency evolution as future devices increase their capacities. Connectivity between the client side and servers is provided through the use of a 802.11g wireless network, while interactions between servers are done through laptop’s localhost network interface. Finally, each test has been performed 100 times to obtain average measures. Table 3 Technical features of test devices Device Notebook HTC Desire HTC Wildfire

CPU

RAM

Intel Core Duo 2 2.4 GHz Qualcomm Snapdragon 1 GHz Qualcomm MSM7225 528 MHz

4 GB

ROM

576 MB

512 MB

384 MB

512 MB

OS Debian Linux (testing branch) Android 2.2 (API level 8) Android 2.3 (API level 10)

5.3.2 Discussion We are going to discuss the performance results of data request, withdrawal, spend and refund protocols. These protocols are executed by customers on mobile devices which have less computing and bandwidth capabilities than servers. Instead, deposit protocol is performed between two servers, so it is difficult to become a system bottleneck. In Figure 18(a), we can see how RSA key length affects the performance of each protocol. First, the only protocol clearly affected by the growth of RSA key length is the withdrawal protocol but the difference is only important from 2,048-bit to 4,096-bit key length. So it is no problem to use a higher level of security through the use of a 2,048-bit RSA key, because the protocol takes only 1.2 seconds in the Desire smartphone and around 1.5 seconds in the Wildfire device. Nevertheless, the time spent for all protocols is almost the same whether we use 1,024-bit or 2,048-bit keys. Moreover, it is clear that the spend protocol is independent of RSA since this protocol does not use asymmetric cryptography. It remains constant around of 200 ms in Desire and 400 ms in Wildfire. The refund protocol uses asymmetric cryptography but it only takes around 700 ms using the Desire and around 1 second in the Wildfire device. Figure 18(b) shows us the relation between the time elapsed to execute the withdrawal protocol depending on the number of coupons within the chain. The withdrawal cost for both devices remains very low up to a coin composed by 2001 coupons, where the Desire device spends approximately 1 second while the Wildfire takes almost 4 seconds. The difference happens when the coupon chain length rises to 20,001 coupons, where Wildfire device seems to be unusable because it takes more than 24 seconds to execute the process. However, Desire seems to allow the use of this length. This is due to the coupon chain creation in the customer application during the first step, where the customer creates all the coupons applying iteratively the hash chain procedure. Since Wildfire is less powerful than Desire in both memory and


101

CPU, Wildfire takes more time than Desire. Nevertheless, most of the time elapsed in the protocol execution corresponds to the coupon chain generation, which can be precomputed before by the client, allowing this way very long coupon chains using both devices. However, real chain lengths will never be as long because we are considering coins with low value, suitable for micropayments, instead of coins to pay for large amounts of money. Figure 18 Performance graphs from benchmark measures, (a) time elapsed for each protocol and smartphone depending on the RSA modulus length (b) withdrawal time depending on the chain length for each smartphone (RSA: 1,024 bits) (c) time elapsed depending on the number of coupons spent at once for each smartphone

3000

Desire Wildfire

2500

Time (ms)

2000 1500 1000 500 0

Wit Sp Re end fun hdr d aw Re al q RSA modulus 1024 bits

Pro d

uct

Sp Pro Re Wit end fun h duc d tRe drawa l q RSA modulus 2048 bits

Pro

Re Wit Sp end fun h duc d tRe drawa l q RSA modulus 4096 bits

(a) 25000

Desire Wildfire Time (ms)

Time (ms)

20000

600 Desire Wildfire

15000 10000

400

200

5000 0

0 21

201

(b)

2001

20001

2

20

200

2000

20000

(c)

Figure 18(c) shows that the time elapsed to execute the spend protocol depending on the number of coupons used to pay for the product remains constant and very low, about 200 ms on Desire and 300 ms on Wildfire. So, the spend protocol is independent of the number of used coupons. As we can see, we can pay for a product that costs 20,000 coupons, using more or less the same time as paying for a product in exchange of a single pair of coupons. So, the spend protocol is scalable in relation to the growing number of coupons needed to pay for the product. Regarding data transferred and stored during the spend protocol, it depends mainly on the size of the coin. Its size depends on the used RSA modulus and the hashing algorithm, since the size of the PBS depends on them. For example, if we use a RSA

102


modulus of 1,024 bits and SHA-1 as the hashing algorithm, the coin size is around 300 bytes plus some common information of variable size. Thus, the cost for the bank and the merchant to store both a coin and the last coupon spent by customers is very low: they should store only 300 bytes due to the coin, 20 bytes due to the last received coupon and some bytes to store the chain index. As a conclusion, we have proved that our scheme is efficient, scalable and ready to use on devices with different processing features. Since the spend protocol does not use expensive asymmetric cryptography, the process can be very fast. Moreover, the protocol allows a scalable and efficient multi-spending process during the spend protocol. It grants customers to pay for more expensive items with the same computational and communications cost as cheaper products. Regarding the withdrawal protocol, its cost is not high at all and it can be independent of the coupon chain length if precomputation for very long chains is applied, generating the coupon chain before the execution of the withdrawal protocol. In the server side, our scheme is also efficient regarding data storage costs, since both bank and merchants only need to store less than 350 bytes for each unexpired coin. Note that this data can be erased when the coin ends its shelf life.

6 Conclusions In recent publications we have proposed a micropayment scheme. This proposal achieves the most important features of micropayment schemes and it has been designed taking into account its possible use in mobile devices. Although we improved in Isern-Deyà et al. (2012) the original version (Isern-Deyà et al., 2011) of the scheme to totally avoid fraud, in order to be sure of the correctness of the protocol, a formal verification is required. We have used CPNs to formally verify both versions of the micropayment scheme. As a result, we have detected the already known flaw in the original scheme and we also have found a minor mistake that has been corrected in the second version. Thus, now we can assure that the protocol satisfies the claimed properties. Finally, we have introduced an implementation on the Android Platform of this micropayment scheme so as to effectively prove its functional features. As a result, we can conclude that the system achieves efficiency in relation to the following items: number of interactions, volume of information exchanged and storage requirements. As we have seen in §5, this efficiency has been reached with scalability and low computational costs as well. Our proposed scheme can be used by current mobile devices, non-top-feature smartphones are needed. Once the protocol has been formally verified, implemented and its performance analysed it can be assured that the protocol is ready to be used. Regarding to further work on this scheme, we want to evaluate the use of the near-field communication (NFC) technology to accomplish the communications between the involved parties, comparing costs with the results obtained through the use of a Wi-Fi network.


103

Acknowledgements This work is partially supported by MEC ARES-CONSOLIDER INGENIO CSD2007-004.

and

FEDER

under

project

References Android [online] http://www.android.com (accessed January 2013). Android Developers Google+ Profile (2012) ‘Android activations’, Google+ official profile [online] https://plus.google.com/108967384991768947849/posts/jHLD6HTfx9U (accessed 26 June 2012). Bayyapu, P.R. and Das, M.L. (2009) ‘An improved and efficient micro-payment scheme’, Journal of Theoretical and Applied Electronic Commerce Research, Vol. 4, No. 1, pp.91–100. Bouncy Castle Library [online] http://www.bouncycastle.org/java.html (accessed January 2013). Buttyan, L. (2000) ‘Removing the financial incentive to cheat in micropayment schemes’, Electronics Letters, Vol. 36, No. 2, pp.132–133. Chaum, D. (1983) ‘Blind signatures for untraceable payments’, Advances in Cryptology Proceedings of Crypto, pp.199–203. Chien, H-Y., Jan, J-K. and Tseng, Y-M. (2001) ‘RSA-based partially blind signature with low computation’, International Conference on Parallel and Distributed Systems, ICPADS 2001, pp.385–389. CPNTools [online] http://cpntools.org/ (accessed January 2013). Esmaeeli, A. and Shajari, M. (2009) ‘MVPayword: secure and efficient payword-based micropayment scheme’, in Second International Conference on the Applications of Digital Information and Web Technologies, ICADIWT ‘09, pp.609–614. Isern-Deyà, A.P., Payeras-Capellà, M.M., Mut-Puigserver, M. and Ferrer-Gomila, J.L. (2011) ‘Untraceable, anonymous and fair micropayment scheme’, in Proceedings of the 9th International Conference on Advances in Mobile Computing and Multimedia, MoMM ‘11, ACM, pp.42–49. Isern-Deyà, A.P., Payeras-Capellà, M.M., Mut-Puigserver, M. and Ferrer-Gomila, J.L. (2012) ‘Anonymous and fair micropayment scheme with protection against coupon theft’, International Journal of Adaptative, Resilent and Autonomic Systems (IJARAS), to be published. Java Architecture for XML Binding (JAXB) [online] http://jaxb.java.net (accessed January 2013). Jensen, K., Kristensen, L.M. and Wells, L. (2007) ‘Coloured Petri nets and CPN tools for modelling and validation of concurrent systems’, Int. J. Softw. Tools Technol. Transf., May, Vol. 9, No. 3, pp.213–254. Katsaros, P. (2009) ‘A roadmap to electronic payment transaction guarantees and a colored Petri net model checking approach’, Information and Software Technology, Vol. 51, No. 2, pp.235–257. Lipton, R. and Ostrovsky, R. (1998) ‘Micro-payments via efficient coin-flipping’, in Financial Cryptography, Vol. 1465 of Lecture Notes on Computer Science, pp.1–15. Nan, J., Liu, X-d., Zhao, J-y. and Yang, D-l. (2009) ‘A mobile micropayment protocol based on chaos’, in Eighth International Conference on Mobile Business, pp.284–289. Nguyen, A. and Shao, X. (2008) ‘A secure and efficient micropayment system’, in Advances in Computer and Information Sciences and Engineering, Springer, Netherlands, pp.63–67.

104


Papaefstathiou, I. and Manifavas, C. (2004) ‘Evaluation of micropayment transaction costs’, Journal of Electronic Commerce Research, Vol. 5, No. 2, pp.99–113. Payeras-Capellà, M., Mut-Puigserver, M., Isern-Deyà, A.P., Ferrer-Gomila, J.L. and Huguet-Rotger, L. (2009) ‘Formal analysis of FPH contract signing protocol using colored Petri nets’, in Yan Chen, Tassos D. Dimitriou and Jianying Zhou (Eds.): Security and Privacy in Communication Networks, Vol. 19 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, pp.101–120, Springer, Berlin Heidelberg. Poutanen, T., Hinton, H. and Stumm, M. (1998) ‘NetCents: a lightweight protocol for secure micropayments’, in USENIX Workshop on Electronic Commerce, pp.25–36. Schmidt, C. and Müller, R. (1999) ‘A framework for micropayment evaluation’, NETNOMICS, pp.187–200. Simple XML Framework [online] http://simple.sourceforge.com (accessed January 2013). Sornkhom, P. and Permpoontanalarp, Y. (2008) ‘Security analysis of Micali’s fair contract signing protocol by using coloured Petri nets’, in Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, SNPD ‘08, Ninth ACIS International Conference on, August, pp.329–334. Sornkhom, P. and Permpoontanalarp, Y. (2009) ‘Security analysis of Micali’s fair contract signing protocol by using coloured Petri nets: multi-session case’, in Parallel Distributed Processing, IPDPS 2009, IEEE International Symposium on, May, pp.1–8. Tygar, J.D. (1996) ‘Atomicity in electronic commerce’, in Proceedings of the 15th Annual ACM Symposium on Principles of Distributed Computing, PODC ‘96, ACM, pp.8–26. Wang, F., Dong, W. and Ji, Y. (2008) ‘A new credit based micropayment scheme’, in IEEE International Conference on e-Business Engineering, ICEBE ‘08, pp.596–601. Yang, C-N., Wu, C-C., Chiu, C-Y., Chiou, S-Y. and Liao, W-C. (2009) ‘Micropayment schemes with ability to return changes’, in Proceedings of the 11th International Conference on Information Integration and Web-based Applications & Services, iiWAS ‘09, ACM, pp.356–363. Zhou, J., Deng, R. and Bao, F. (2000) ‘Some remarks on a fair exchange protocol’, in Public Key Cryptography, Vol. 1751 of Lecture Notes on Computer Science, pp.46–57. Zhao, X., Lv, Y. and He, W. (2009) ‘A novel micropayment scheme with complete anonymity’, in Fifth International Conference on Information Assurance and Security, IAS ‘09, pp.638–642. Zongkai, Y., Weimin, L. and Yunmeng, T. (2004) ‘A new fair micropayment system based on hash chain’, in IEEE International Conference on e-Technology, e-Commerce and e-Service, EEE ‘04, pp.139–145.