DESIGN AND FEASIBILITY OF PEER-TO-PEER MOBILE PAYMENT SYSTEMSessay.utwente.nl/66418/1/thesis.pdf · OF PEER-TO-PEER MOBILE PAYMENT SYSTEMS rick van galen [email protected]

D E S I G N A N D F E A S I B I L I T YO F P E E R - T O - P E E R M O B I L E

PAY M E N T S Y S T E M S

rick van galen

[email protected]

master’s thesis:Rick van Galen: Design and Feasibility of Peer-to-Peer Mobile Payment SystemsUniversity of Twente - department of Computer ScienceResearch work was performed at ING Bank N.V., Amsterdam© November 2014

supervisors:Dr. Andreas Peter (UT)Dr. Maarten Everts (UT)Roderick Simons (ING)

To Dora.For all her love and words of motivation.

A B S T R A C T

Digital payment methods are becoming increasingly popular. The adventof Bitcoin and Apple Pay is an indication that digital payment systems arerelevant today and even moreso in the future. However, these payment sys-tems firmly rely on central infrastructures. Many also only bring paymentsto digital platforms, but lack the possibility for people to be paid without ad-ditional infrastructure. Lastly, privacy for payers is rarely achieved in mostcurrent commercial payment systems.

In this thesis, we investigate a novel design of digital payments especiallytargeted at smartphones and tablets to address the above shortcomings. Wename this system a peer-to-peer payment system because it transfers digitalcoins from device to device. This design choice enables two distinguishingfeatures: offline payments - the sending of payments without a third party -and receiving payments. In this thesis, we represent three protocol designsfor such mobile peer-to-peer payment systems, as well as a novel contribu-tion by introducing a method for sharing the responsibility of anonymityprotection amongst multiple partiesde.

The main result of this thesis is an assessment of the feasiblity of a peer-to-peer mobile payment system. We developed a prototype application andassessed technical choices that can be made. It was found that from theavailable local communication methods, the newly available Wi-Fi Directmedium was preferable to NFC and Bluetooth. The prototype applicationshows that the right technology is currently available to succesfully imple-ment peer-to-peer payment systems on mobile devices.

The protocol designs use a number of cryptographic constructs. An im-portant finding in our thesis is that it is possible to design an anonymous,scalable payment system using only cryptographic hashes, digital signa-tures and elliptic curve arithmetic. These basic constructs were found tostill be very demanding of these mobile devices’ computational power. Wewrote a benchmarking application and tested over 30 Android devices ontheir performance in cryptographic computations and payment protocol sce-narios. It was found that the computational performance at present leadsto some difficult tradeoffs for real-world applications. Nonetheless, we con-clude that practical applications are within the realm of possibility.

The contributions presented in this thesis are the following:

• The design of a simple peer-to-peer payment protocol

• An extension of this protocol in which a bank cannot trace paymentswithout a trusted third party

• An extension of this protocol in which multiple banks can issue coins

• A mechanism by which multiple parties can share the responsibilityof payer anonymization

• A prototype application that demonstrates a viable medium for peer-to-peer mobile communications for payments

• Benchmark results of a large number of Android devices on crypto-graphic operations used in the presented payment protocols

iii

C O N T E N T S

i background 1

1 introduction 3

2 description of digital payment systems 5

2.1 Parties and communication 5

2.2 Security properties 6

3 protocol principles 9

3.1 Online payments 10

3.2 Offline payments 11

4 cryptographic principles 15

4.1 Secure channels 15

4.2 Cryptographic assumptions 15

4.3 Public key cryptography 16

4.4 Elliptic curve arithmetic 17

4.5 Double spending prevention 19

4.6 Blind signatures 20

4.7 Fair blind signatures 21

4.8 Group signatures 24

4.9 Secret sharing 26

5 mobile security considerations 29

5.1 Offline authentication 29

5.2 Wallet protection 36

5.3 Random number generators 37

5.4 Cryptographic performance 38

5.5 NFC Security 39

6 electronic cash protocols 41

6.1 Chaum’s untraceable electronic cash 41

6.2 Gaud & Traore’s payment protocol 42

6.3 Scalable group signatures 44

6.4 Divisible coins 47

6.5 Transferable coins 47

7 existing electronic money systems 49

7.1 EMV 49

7.2 Wireless EMV applications 51

7.3 Proton 51

7.4 Cryptocurrencies 51

ii experiment 53

8 protocol design 55

8.1 Protocol features 55

8.2 The essential protocol 57

8.3 The untraceable protocol 60

8.4 The multibank protocol 64

9 prototype 71

9.1 Basic technology choices 71

9.2 Libraries 72

9.3 Mobile connectivity 73

9.4 Protocol implementation 74

v

9.5 Prototype organization 76

9.6 Storage security notes 79

9.7 User interface 80

iii results 83

10 benchmarks 85

10.1 Description 85

10.2 Methodology 86

10.3 Devices 87

10.4 Cryptographic constructs 89

10.5 Proofs of knowledge 92

10.6 Group signatures 97

10.7 Payment and withdrawal simulations 100

11 discussion & conclusions 105

11.1 A comparison with fiat money 105

11.2 Cryptography 106

11.3 Prototype 107

11.4 Performance 107

11.5 Concluding remarks 109

12 recommendations 111

12.1 Secure element 111

12.2 Usability research 112

12.3 Implementation improvements 112

12.4 Lattice-based cryptography 112

References 115

vi

Part I

B A C K G R O U N D

1I N T R O D U C T I O N

Electronic payments systems have existed for decades. Originally employedas payment methods in telephony cards since the 1980s, many banks haveintroduced digital smart cards to serve as alternative payment methods.Adoption of electronic payment has sharply increased over the years, andthe number of cash payments has corresponingly been dropping for manyyears [58].

Smartphones have become nearly as ubiquitous as electronic payments inrecent years. Becoming ever more useful in terms of sensors, radios andprocessing power, many people always carry their smartphone with them.The mutual ubiquity of smartphones and electronic payments has led tosome initiatives for mobile payments, but none of these have succeeded.The motivation for this thesis was to create a successful mobile paymentsystem. The goal was to make describe a system that could make obsoletecash money, aiming to provide a replacement for cash on mobile devices.

Current mobile payment initiatives use the wireless capabilities of mobiledevices to communicate payment information. Phones connect to a mobilenetwork, which allows use of SMS and mobile internet services. Further-more, mobile devices can connect to other mobile devices using Bluetoothand Wi-Fi Direct. Recently, adoption of near-field communication (NFC)enabled mobile devices has surged [11]. NFC technology enables mobile de-vices to instantaneously communicate with other generic mobile devices orpurpose-made service technology. In addition, the Bluetooth 4.0 and Wi-FiDirect standards allow for a similar mode of operation for direct commu-nication between mobile devices [17, 1]. There appear to be a plethora ofmedia available for mobile payments, but few if any systems take advantageof this.

As of November 2014, popular application markets show some adoptionof these new wireless communication technologies, in accordance with somepredictions that mobile payments will be the biggest impactor in paymentbusiness in the coming years [11]. None of the initiatives presently availablein the Netherlands is a complete payment system however; they are prepaidservices that do not manage actual money. Nor are we aware of popularpayment systems in other countries. This is inconvenient from a user’sperspective; firstly a user needs to manage accounts as well as a cash sourcefor independent payment services, and secondly independent service do notreadily possess network effect for large adoption of such payment services.

Another limitation of many commercial payment systems is their unidi-rectional character. Most payment systems are developed with the focus onsendingpayments only, and receiving payments is rarely a design goal. Oftenspecial equipment and fees are necessary to receive payments, which halvesthe potential use cases for users and keeps control with the payment pro-cessor. We will use this thesis to present the design of a payment protocolwhere receiving payments is just as accessible as sending them.

3

In this thesis we will use the term mobile devices to mean consumer ori-ented portable devices that usually get marketed as ’smartphones’ or ’tablets’or similar terms. This is a loose definition that attempts to encompass thecategory of devices that many people increasingly carry along - and there-fore have readily available to use in payment transactions. We define mobilepayment technology or mobile payment systems as technology enabling digitalpayments on mobile devices [71, 100].

We will investigate a novel payment system, a so-called peer-to-peer pay-ment system, for mobile devices. The payment system consists of a descrip-tion of communication, along with a set of cryptographic computations thatfacilitate security features. The presented system in this thesis is the resultof answering the following research questions:

• What do peer-to-peer payment protocols look like on mobile devices?

– What security features do peer-to-peer payment protocols needto possess?

– Can these features be incorporated in a real-world application?

• Do there exist usable and performant communication methods forpeer-to-peer payments between mobile devices?

• Does the required cryptography for peer-to-peer payments performquickly enough on mobile devices?

This thesis is structured into three parts. The preliminary background partserves as an introduction to the concepts of digital payment systems: sec-tion 2 deals with identification of parties and responsibilities in paymentsand section 3 provides the reader with conceptual details of payment sys-tems. The next chapters explore literature that allows us to fill in details ofdigital payment protocols; generally necessary cryptographic techniques toconstruct them in section 4 and other techniques suitable for use in the mo-bile context in chapter 5. We will then see applications of these techniquesin payment systems; those from literature in chapter 6 and those currentlyon the market in chapter 7. We will then present the design and consid-erations of our protocol and experiments in system in the experiment part,in which we will present a chapter on the design of different peer-to-peerpayment protocols (chapter 8) and a chapter detailing the implementationof a demo application (chapter 9). Finally, we will conclude with a resultspart, in which we describe benchmarks and present their results in chapter11, and discuss some recommendations of further work based on this thesisin chapter 12.

4

2D E S C R I P T I O N O F D I G I TA L PAY M E N T S Y S T E M S

In this chapter, we provide the reader a conceptual description of whatdigital payment systems are. We identify the division of responsibilities ina payment protocol and also define what makes such a system secure.

2.1 parties and communication

We define two participating entities in a payment called the payer (alsoknown as ’client’ or ’buyer’ in other literature), the entity that commits topaying a sum of money to a payee (’merchant’, ’shop’), some entity willingto receive a payment, usually but not necessarily in exchange for goods. Themoney transfer between the parties is named the payment or transaction. Inmany cases, the payer’s and payee’s respective financial service providersparticipate as third and fourth participants in the protocol [114, 74, 22, 55].

In figure 1 the relations between several entities in the protocols areshown. The issuing bank is the financial service provider who providesservices as well as technology to the payer. The acquiring bank is the finan-cial service provider to do the same for the payee. These entities might notbe separate; indeed, for simplification we will often make the assumptionthat this is one entity in the remainder of this paper. If both of these serviceproviders are the same, or act behind some trusted broker, this participantis sometimes considered to be a trusted third party. Furthermore, any payeror payee can interchangeably be a payer of payee in another payment. Wedefine any payer or payee using any of the bank’s services to be the bank’sclient.

Observe that there are two methods of money transfer. One is where thepayer commands its issuing bank to send a payment to the acquiring bank.We shall name such systems in which every transfer involves processing by

Payer Payee

Issuing bank Acquiring bank

Payment commitment

Payment receipt

Payment processing

Payment processing

?

Figure 1: A representation of the payment model

5

some services offered by the bank a processed payment system. Note thatprocessed payment systems by necessity are online systems since payer andpayee need to be informed of the payment traffic from their respective banks.An example of such a payment system is the debit card payment system.

Another is where the payer transfers the money directly to the payee.This is what we call a peer-to-peer payment system. During a peer-to-peerpayment, the involvement of banks is not necessary. Payers and payeeswithdraw money from their bank accounts into their own possession at adifferent time at which payments occur. An example of a peer-to-peer pay-ment system is the fiat money system.

A payment system is composed of a set of protocols that accomplish differ-ent phases in the payment process. These protocols are the following [22,36, 23, 55, 43]:

1. Setup phase – performed by the bankThe bank publishes information about its own identity and definescryptographic parameters used in the system. This phase is run onlyonce during the very start of the protocol.

2. Account setup protocol – performed by the client and the bankThe client notifies the bank that he/she desires to use the bank’s ser-vices, and the bank provides the user with the data to make use ofits services. This can be seen as the digital equivalent of opening anaccount.

3. Withdrawal protocol – performed by payer and bankThe payer withdraws money from his bank account. The bank pro-vides the payer with the corresponding amount of money, which canbe spent by the payer. The payer stores this money in his/her wallet.

4. Payment protocol – performed by two clients (one payer, one payee)The payer sends the payee an amount of money from his/her wallet:this amount gets stored by the payee. The payer can then no longervalidly spend this money.

5. Deposit protocol – performed by payee and bankThe payee sends money from his/her wallet to the bank. The bankverifies the validity of the money, and credits the payee’s account withthe corresponding monetary value.

These definitions are made in such a way that the payment system becomean analagy for the flow of fiat money.

A property a payment protocol may or may not possess is transferability.We say that a payment protocol is transferable if it is possible for a client tofirst receive money (as a payee) and immediately spend this money again (asa payer), without having to contact the bank first [6, 74]. As we will see insection 6.5, transferability in payment protocols is not easily accomplishedin digital systems. Payment protocols discussed in this paper do not possessthe transferability property unless otherwise noted.

2.2 security properties

The first security service necessary is authentication between payer and payee,and both of these parties with the trusted third party. A payer desires tomake a payment to some payee, and therefore the payee needs to authenti-cate to the payer. The payee conversely needs knowledge about the payer’s

6

authorisation and capability to fulfil payments, and therefore requires toauthenticate the payer. Payer and payee further need authentication of theadditional trusted parties in the protocol.

The second security service required is non-repudiation of a committedpayment. Once a payer commits to a payment and has transferred it to thepayee, there should be no way for the payer to later deny the creation of thiscommitment. The payee needs to ensure this to truly guarantee the validityof this payment.

Thirdly, payments should be singular. Once a payment has been commitedto by a payer, he cannot commit to a payment that includes a money unitused in a previous payment again.

The final required security service is that of integrity: once a payment istransmitted it cannot be modified in such a way that the payment details ofpayer, payee and amount transferred can be modified. Nor can additionaldetails of the payment be modified, such as time stamps or the number oftimes the payment can be repeated.

When authentication of both parties is achieved and non-repudiation andintegrity can be claimed on the payments, payments satisfy the propertythat:

1. Payments occur between the intended identities

2. Payments are final and intractable

3. Payments are singular

4. Payments cannot be modified

We define payment systems satisfying the above properties as secure pay-ment systems. In principle, the features above are defined to guarantee thatno user can illegally obtain money that was not explicitly sent to him or her.Although payment traffic can operate normally in secure payment systemsunder this definition, its properties only ensure proper operation from theperspective of the bank. Ideally however, security properties of the systemshould also provide security for the users of the system. This is becauseof the fact that, in practice, the bank’s status as trusted third party may bequestioned. Additional features can be introduced to alleviate the bank ofsome responsibilities and limit the trust users need to place in the bank’soperations. We list these additional desired features below.

The first such security feature is the confidentiality of payments when com-municated between payer and payee. Confidentiality is not always used inexisting payment systems. For example, the EMV protocol (see section 7.1)does not use cryptography to make payment communication confidential,instead relying on the physical security of contact smartcards [42] to preventeavesdropping.

Another security feature is untraceability. Untraceability decouples trans-action information from the identity of the payer. A bank can see that one ofits clients withdraws money, but cannot identify which units of money are inthe possession of their clients. This makes it impossible for involved banksto track payments executed within the system as only the payee knowsabout the identities of the payer he or she has been involved with. In ad-dition, it should be impossible for the bank to tell which money is held bywhich client. This property provides protection for payers in the system incase the bank is compromised or cannot be trusted. As an example, note thatdebit cards do not have untraceability, as issuing and acquiring bank pos-sess knowledge of the location and timing of payments made and received

7

Features of secure payment systemsAuthentication All parties can have proof that they are con-

ducting business with the payer, payee andbanks they intend.

Non-repudiation No payer can deny creating a payment after itwas received by a payee.

Singularity No payer can validly commit a payment a sec-ond time.

Integrity Once committed, a valid payment cannot bemodified into another valid payment.

Additional features of anonymous payment systemsConfidentiality Payment traffic among payer, payee and

banks cannot be eavesdropped.Untraceability The bank cannot trace the flow of money

within the system and cannot follow whichidentities possess which coins in the system.

Table 1: Overview of security features necessary for mobile payment sys-tems

using debit cards. Fiat money does possess the untraceability property, asbanks only know the timing, location and serial numbers of withdrawalsand deposits, but do not know where money has been within the system.

We define a secure payment system extended with confidentiality and un-traceability as an anonymous payment system. An overview of these featuresis given in table 1. In this thesis, we will focus on the design and impleme-nation of a payment system that is both a peer-to-peer payment system andan anonymous payment system.

8

3

P R O T O C O L P R I N C I P L E S

Before we delve into the cryptographic details of payment protocols, we willfirst introduce some principles in this chapter. This serves as a conceptualoverview, and we will fill in the required concepts. High-level descriptionsof some important building blocks for payment protocols is given below.

secure channels [28] Secure channels are prepared communication chan-nels which have the property that data passed through them cannotbe modified or eavesdropped. They are usually established by ap-plying some symmetric cipher to the communication, and are usedextensively in devices capable of network communication.

one-way functions [90] A one-way function is a function f with whichit is easy to compute f (a) = b given f and a, but it is computationallyinfeasible to compute the inverse f−1(b) = a given f and b. The irre-versibility of this function allows it to act as a trapdoor. An importantcryptographic property of the one-way function is collision resistance -that it is very hard to find distinct function inputs that result in thesame output. It is not known whether one-way functions truly exist,but many hashing algorithms are considered to be one-way in practice.

digital signatures [104] By signing a message with a private key froman assymmetric public/private key pair, integrity of the message ispreserved. Under the assumptions that the private key is kept secretby the signer and that adversaries cannot otherwise obtain the privatekey in the employed public-key cryptography scheme, digital signa-tures also provide authentication and nonrepudation. Digital signa-tures can be used to approve payment commitment, payment verifica-tion or payment acceptance by each party in a payment system.

blinding [32] Blinding is a technique used to implement untraceabilityof payments. A payer generates coins during signing, but sends thebank a transformation (called the blinded coin) of this coin to be signed.The blinded coin is signed by the bank, but the bank does not knowwhich coins it has signed, making payments untraceable. The blindingis done in such a way that the payer can afterwards unblind this coinand possess a valid signature on an unblinded coin.

double spending detection [35] Double spending detection methodsallow a bank to see when a coin has been doubly spent. This is doneby cryptographically adding information to payments that will keepsecret the identity of the payer the first time it is spent, but will revealthe identity of the payer if a single coin is used in more payments.Usually, this included information is randomized by a challenge sent tothe payer by the payee during payment. If the bank receives different

9

Construct Security propertiesSecure channels Integrity, confidentialityOne-way functions IntegrityDigital signatures Authentication, integrity, confiden-

tiality, non-repudationBlinding UntraceabilityDouble spending detection Singularity

Table 2: Relation of cryptographic constructs to security features

pieces of double spending information for the same coin for two dif-ferent challenges, the bank has legal proof that the user has spent thecoin twice.

In addition to these principles, we also need a definition of a coin. In thecontext of a digital payment protocol, a coin represents the closest analogyof the real-world concept of a coin. It is a piece of data that is indivis-able and unforgeable, and it corresponds to some monetary value. Whatdata is actually contained in the coin is based on the requirements set bythe cryptographic constructs used in the protocol. At bare minimum, thedata contained in the coin must uniquely identify each one. In addition toan identifier, a coin will usually consist of cryptographic parameters thathelp ensure its unforgeability and indivisability. In contrast to real coins,which come in many nominations corresponding to different monetary val-ues within the same currency, it is conceptually simpler to use only onesingle coin tied to one corresponding monetary value.

Using these techniques, it is possible to construct digital payment proto-cols with varying security features. A survey by the U.S. National SecurityAgency in 1996 lists the state-of-the-art in payment protocols at the time [74].Since their work provides a good conceptual explanation of payment proto-cols, this next section will summarize the concepts in this publication, withsome additions and modifications. Each protocol describes three subproto-cols: that of withdrawal in which the payer obtains money from the bank tospend. The payment part refers to the transfer of digital money from payerto payee. The deposit protocol defines the process with which the payeeredeems received payments at the bank.

3.1 online payments

The simplest version of a payment protocol with the discussed contructs isone which is fully online, and in which no attempt is being made to obscureany party’s identity. It is described as follows [74]. Please note that inthis and the subsequent sections, we assume the communication channelsbetween payer, payee and bank are secure channels.

Protocol 1. Simple online protocol

withdrawal

1. Payer sends a request for withdrawal to the bank

2. The bank prepares the coin with a digital signature

3. The bank sends the coin to the payer and withdraws the amount fromthe payer’s account

10

payment and deposit

1. The payer sends the signed coin to the payee

2. The payee sends the signed coin to the bank

3. The bank verifies that the coin has not already been sent and that theamount has been withdrawn from the payer’s account.

4. The bank registers the coin as spent

5. The bank moves the money to the payee’s account and shows a signedreceipt to the payee

6. The payee forwards this receipt to the payer

7. Payment is completed

This protocol is a straightforward implementation of a payment proto-col, that uses the bank as a trusted third party to determine and verify thevalidity of the payments.

We can improve this protocol by making transactions untraceable, so thatthe bank cannot know the flow of money. This is done by moving theresponsibility of issuing coins to the payer, which can then blind the coin.This makes the issuing of coins untraceble for the bank. Chaum proposedthe original idea for this protocol [74, 36].

Protocol 2. An untraceable online protocol

withdrawal

1. The payer creates a coin and blinds it

2. Payer sends a request for withdrawal to the bank with the coin

3. The bank prepares the blinded coin with a digital signature

4. The bank sends the blinded coin to the payer and withdraws the amountfrom the payer’s account

5. The payer unblinds the signed coin

payment and deposit

1. The payer sends the coin to the payee

2. The payee sends the coin to the bank



5. The bank moves the money to the payee’s account and shows a signedreceipt to the payee

6. The payee forwards this receipt to the payer


3.2 offline payments

We can improve protocol 2 by transforming it into a protocol that movesout communication with the bank out of the payment process. Since onlycommunication between payer and payee is required in this stage, we callthis an offline payment [74].

11

Protocol 3. An untraceable offline protocol

withdrawal

1. The payer creates a coin and blinds it

2. Payer sends a request for withdrawal to the bank with the coin




payment


2. The payee verifies the bank’s digital signature


deposit

1. The payee sends the coin to the bank



4. The bank moves the money to the payee’s account and shows a receipt tothe payee

Having achieved an offline protocol, we can now further improve theproperties of regular currency by making the protocol anonymous for thepayer.

Protocol 4. An anonymous untraceable offline payment protocol

withdrawal

1. The payer creates a coin and double spending information

2. The payer blinds the coin

3. The payer sends a request for withdrawal to the bank with the coin anddouble spending information




payment


2. The payee verifies the bank’s digital signature

3. The payee sends the payer the double spending challenge

4. The payer sends the response

12

5. The payee verifies the response to the payer to complete the payment

deposit

1. The payee sends the coin, challenge and response to the bank

2. The bank verifies the presence of its digital signature on the coin

3. The bank verifies that the coin has not already been spent

4. The bank enters the coin, challenge and response in a database for spentcoins

5. The bank deposits the money into the payee’s account

13

4

C RY P T O G R A P H I C P R I N C I P L E S

In the previous chapter, we have presented an outline of how cryptographicprinciples can create a secure, offline, anonymous digital payment protocol.However, we have treated the building blocks of these protocols as blackboxes. In this chapter, we will detail how these building blocks operate.Along the way, we will also cover additional cryptographic topics not previ-ously discussed, but which we will need in later chapters.

4.1 secure channels

Implementations of secure channels are widespread; the Transport Layer Se-curity (TLS) [39] and Secure Shell (SSH) [122] protocols are popular exam-ples of secure channels. Both standards are defined for different network-ing contexts, but their conceptual operation is identical. Both wrap trafficthrough a symmetric cipher (the Advanced Encryption Standard being themost popular choice) using a key exchanged by a predefined key exchangeprotocol based on public key cryptography. It is also important for theirsecurity that the channels are authenticated, for which both protocols alsodefine mechansisms.

In general, a secure channel can be established by first establishing authen-tication, negotiating a secret key. We will discuss authentication in section5.1. Once authentication and a secret key of sufficient length are established,a secure channel can me made over an insecure channel by using the com-mon key as input to symmetric cipher algorithm and message authentica-tion code mechanism. One such method preferred for packetized networktraffic is the Galois Counter Mode of the Advanced Encryption Standard(AES-GCM) [82]. This method offers both encryption and authentication.

4.2 cryptographic assumptions

The security of the following sections is dependent on a set of assumptions.These assumptions state that certain computations by are hard to perform.If a cryptographic construct is built upon one of these assumptions in sucha way that it can be shown that an adversary can break the scheme only if itcan be shown that this would break one of these assumptions, this schememay be considered secure.

cryptographic hashes are one-way functions We assume the roleof one-way functions can be fulfilled by cryptographic hashes. Crypto-graphic hashes are algorithms that accept an arbitrary amount of datato generate another, distinct, bit string. This generation has the prop-erty that, given a hash function application h(a) = b, it is easy tocompute h(a), that given b it is infeasible to compute a and infeasibleto compute a distinct a′ so that h(a′) = b [91].

15

Traditionally, the SHA family of hashes is used in integrity checkingand as one-way functions. Some concern exists however about the ca-pabilities of modern GPUs or dedicated integrated circuits to processlarge amounts of hashes to produce hash collisions. Therefore, thebcrypt [101] and scrypt [98] hashes have been proposed.

random oracle model The random oracle model is often used to provethe security of cryptographic protocols. A random oracle is a concep-tual function f that provides a completely random result f (a) for anyinput a, but will always yield the same result for any a. If a crypto-graphic protocol is shown to be secure under the random oracle model,it means that the protocol is shown to be secure if and only if everycryptographic hash function employed by the protocol is replaced bya random oracle.

The notion of ”secure under the random oracle model” is often crit-icised. This is because cryptographic hash functions are intended tobehave as random oracles, but are not known to be behaving as such.The random oracle model provides an indication of security, but is nota complete proof [29].

discrete logarithm problem We assume that certain groups exhibitthe property that it is computationally infeasible to reverse the re-peated application of the group operation on its elements. For ex-ample, given a finite multiplicative group of integers (G ⊂ Z∗, ·), itis assumed that it is computationally infeasible to find the integer agiven g ∈ G and ga ∈ G. The discrete logarithm problem is thoughtto be hard in both multiplicative groups of integers of prime order aswell as the additive group of points on certain elliptic curves, amongstothers.

computational diffie-hellman problem This assumption states thatthere exist cyclic groups G of order q for which holds that, given gen-erator g ∈ G and powers ga, gb of that generator, it is computationallyinfeasible to compute the value for gab as long as a, b ∈ Zq are notknown.

decisional diffie-hellman problem There exist cyclic groups G oforder q for which holds that, given a generator g ∈ G and three el-ements ga, gb, gc, it is computationally infeasible to decide whetherc ≡ a · b mod q for any unknown a, b, c ∈ Zq [18].

4.3 public key cryptography

An encryption scheme is said to be a public key cryptography scheme ifit seperates encryption and decryption capabilities in seperate (but related)keys named the public and private key. The public key is freely distributedto anyone, and the private key is kept secret. This division allows the holderof the private key to be the only one capable of decrypting messages thathave been encrypted using a private key, or conversely be the only one ableto encrypt messages that can be decrypted by anyone. This last propertycan be used to generate digital signatures on messages [40, 104].

The first public key cryptography schemes were based on the integer fac-torization problem (Rivest et al. [104]) or the discrete logarithm problem inmultiplicative integer groups (ElGamal [41]). Increasingly, the public key

16

-5 -4 -3 -2 -1 0 1 2 3 4 5

-3

-2

-1

1

2

3

(a) y2 = x3 − 2x

-5 -4 -3 -2 -1 0 1 2 3 4 5

-3

-2

-1

1

2

3

(b) y2 = x3 − 2x + 2

Figure 2: Plots of two Weierstrass equations over R. The left plot shows a discontinuouscurve, and therefore its equation is not an elliptic curve. The continuous curve inthe right plot shows the second equation is a valid elliptic curve.

cryptography approach of choice is based on the discrete logarithm prob-lem on the group of points on certain elliptic curves [85]. Because of thenature of the operations on elliptic curves, this approach allows for a moreefficient keyspace distribution yielding smaller keys for similar security [69].Furthermore, elliptic curves have long resisted methods that can ease solv-ing simpler versions of competing cryptographic schemes [85, 110]. Thisis because the most efficient integer factorization and discrete logarithm al-gorithms depend on the notion of primality of integers, and no equivalentnotion exists for the points on elliptic curves. Because of these advantagesover the more traditional RSA and ElGamal-derived schemes, elliptic curvecryptography has become increasingly popular.

4.4 elliptic curve arithmetic

Throughout this thesis, we will often use elliptic curve arithmetic as the fun-damental tool to create cryptographic constructs. A familiar reader will findelliptic curve cryptography to be analogous to multiplicative arithmetic ininteger groups of size n, but the principles of elliptic curves differ substan-tially from these groups to warrant further explanation.

An elliptic curve over R can be defined1as the (infinite) set of points that 1)satisfy the equation y2 = x3 + ax+ b and 2) of which the plot of this functionin the (x, y)-plane contains all points within one curve and there are no gapsbetween two points. See figure ?? for an illustration. This defining ellipticcurve equation is called the Weierstrass equation; different elliptic curves canbe obtained by filling in different constants for a and b. An elliptic curveover a field Fp of prime size p is defined in the exact same way as an ellipticcurve over R; the only additional constraint is that the x and y solutions areelements of Fp, and thus the set of elliptic curve points becomes a finite setE.

An elliptic curve E defined over of over a finite field Fp becomes an addi-tive group G = (E,+) under a certain definition of addition. This definition

1 The definition chosen in this section is a simplified one for pedagogical purposes, thoughsufficient for our needs in this thesis.

17

-4,8 -4 -3,2 -2,4 -1,6 -0,8 0 0,8 1,6 2,4 3,2 4 4,8

-3,2

-2,4

-1,6

-0,8

0,8

1,6

2,4

3,2

P

Q

R

(a) P + Q + R = 0

-4,8 -4 -3,2 -2,4 -1,6 -0,8 0 0,8 1,6 2,4 3,2 4 4,8

-3,2

-2,4

-1,6

-0,8

0,8

1,6

2,4

3,2

P

Q

R

-R

(b) P + Q = −R

Figure 3: Illustration of elliptic curve addition

of addition requires the introduction of the the ”point at infinity”; any pointthat lies at an infinite y coordinate in this plot satisfies this definition. Wethen set this point at infinity to be the additive identity 0 of the group. Ad-dition of three points P, Q, R on an elliptic curve is then defined as in thefollowing way:

P, Q and R lie on a straight line⇔ P + Q + R = 0

Since P + Q + R = 0 we have P + Q = −R, or, the addition of two points onan elliptic curve becomes the inverse of the third point on the curve definedby those two points. The inverse of an elliptic curve point is defined as theelliptic curve point mirrored in the x-axis. See figure 3. We refer the readerto other work for proofs that these definitions of a set and addition indeedforms a cyclic abelian group [54, 95]. If R is the addition of two points P andQ with coordinates (xP, yP) and (xQ, yQ) its coordinates can be computedby the following formulae:

s =yP − yQ

xP − xQ

xR = s2 − xP − xQ

yR = yP + s(xR − xP)

By extension, we may also define multiplication on elliptic curves as re-peated addition: for an integer k and elliptic curve point we define:

k · P = P + P + . . . + P + P︸︷︷︸k times

It is thought that a version of the discrete logarithm assumption holds forelliptic curve multiplication on at least some elliptic curves. The elliptic curvediscrete logarithm states that given an elliptic curve points P and R, whereR = a · P for some integer a, it is computationally infeasible to compute a.More informally, it is thought that the division operation R/P = a on someelliptic curves is computationally infeasible.

18

The name ”discrete logarithm problem” becomes somewhat of a mis-nomer when applied to elliptic curves since the operation thought to behard is not the taking of a discrete logarithm, but the division of curvepoints. The term is derived from the analagous discrete logarithm problemin groups of integers modulo n. This is because cryptosystems based on el-liptic curve arithmetic and those based on multiplicative arithmetic modulon are both varieties of the ElGamal cryptosystem [41]. Since the ElGamalcryptosystem was first described based on the hardness of the discrete log-arithm problem in integer groups, the same term is used for the divisionproblem in elliptic curve groups.

4.5 double spending prevention

We introduced the concept of double spending prevention in section ?? asa means to include identifying information to coins that is only revealedwhen a coin is spent twice. Identifying information satisfy the propertiesthat a single transaction does not reveal information about the coin or theuser, but that a double transaction using a single coin reveals the full identiyof the user. We show two methods to accomplish this here.

Double spending prevention in other payment systems is usually depen-dent on hardware security; the devices involved in payments are simplyincapable of copying coin information, and are extremely difficult to betampered with. Indeed, Chaum [33] originally proposed equipping pay-ment devices with so-called observers; hardware devices which guaranteedcopying would be prevented or would otherwise be noticeable by other par-ties. Since observers are not generally available in mobile devices, we willnot consider such solutions in this thesis.

4.5.1 The division method

This is the method used in several electronic cash proposals [48, 120] andwas originally proposed by Ferguson [44]. We assume a payment systemthat gives users a user identity u that is representable as a unique integer foreach user. Each coin signed by the bank is associated with a bank-verifiedcoin identity i during the withdrawal phase. The trick is to have a payer gen-erated coin spending message generation depend on some independentlycheckable variable, such as a timestamp τ. This timestamp is included withother transaction information using some cryptographic hash that maps ar-bitrary strings onto the integers H : {0, 1} → Z. This requires a user tocompute the double spending information c:

c = H(other information‖i‖τ)

Which is then sent to the payee, which can verify the timestamp andother information to be correct. Then, another variable r is introduced thatcouples this cut-and-choose information to a number u representing thespender’s identity.

r = i− cu

A pair of c and r values is included with every payment. Given twoseperate payments to process, the bank obtains two sets of values {c1, r1}and {c2, r2}. Because both c1 and c2 are dependent on the cryptographichash of the timestamp the payment was made, these two sets are distinct

19

values with overhelming probability. However, both payments include thesame coin information i. Therefore, we can now compute

r1 − r2

c2 − c1=

(i− c1u)− (i− c2u)c2 − c1

=c2u− c1u

c2 − c1= u

to reveal the identity of a double spending user.

4.5.2 Cut-and-choose

A method named cut-and-choose was used in the original e-cash paper [36]for double spending detection. We present a simplified version here. A largenumber k is defined as well as a cryptographic hash function H : Z → Z

with a large output length. The integer u uniquely identifies each user ofthe system. Upon withdrawal, the payer sends the bank a signed array ofcontaining the hashes of random values a1, a2, ..., ak ∈ Z.

c = Sigskpayer (H(a1),H(a2), . . . ,H(ak))

The bank stores c. During a payment, the payee sends the payer k randomlychosen bits. For each of the k bits sent, the payer sends the following infor-mation to the payee.

c′ =

⟨{a1 z1 = 0a1 ⊕ u z1 = 1

,

{a2 z2 = 0a2 ⊕ u z2 = 1

, . . . ,

{ak zk = 0ak ⊕ u zk = 1

⟩

The payee verifies the correctness of this information, and eventually sendsit to the bank. If k is large enough, there is a large chance that the bank endsup with a pair of ai and ai ⊕ u, from which it can extract the user u. Thebank then has a signature on the hash of this value, proving that u has usedthe coin twice.

It should be noted that this method carries potentially prohibitive limita-tions with it in practice. k has to be chosen large enough to guarantee thatthe bank ends up with a pair of complementary values in this hash and krandom numbers need to be generated and stored by the bank. This createsa considerable amount of data for any coin withdrawn in the system, whichneeds to be stored on the server or by the user for every coin in his/herwallet.

4.6 blind signatures

Blind signatures are a concept that allows some authority to sign messages,without that authority obtaining any information about the message thatneeds to be signed. As described above, we use blind signatures to have thetrusted third party sign coins to be valid, without giving the authority theability to sign these messages. Blind signatures were introduced by DavidChaum in 1982 in the context of digital payments [32]. His example of blindsignatures using the RSA signature scheme is discussed here.

Suppose the bank is in possession of an RSA private key d and the payeris in possession of the corresponding public key e and the product d · e = N.Further, the payer has generated a coin transfer message C, which the payerwants to have signed by the bank. First, the payer generates the number rwhich we call the blinding factor. r must be chosen to be relatively primeto N. The payer then generates a different message C′ by computing C′ ≡

20

C · re(modN) which he/she then sends to the bank. We call C′ the blindedmessage.

The bank then signs the blinded message using the usual RSA signaturescheme, generating a blind signature s′ ≡ (C′)d(mod N) and returns this tothe payer. Now note that s′ is the result of a permutation of the originalmessage; it is a reversible operation. From the blind signature, the payee canobtain the normal signature s ≡ s′ · r−1 (mod N). Since s ≡ C (mod N) wehave a valid signature for the message C while the bank has no informationabout the actual coin that is to be spent.

Blind signatures have been extended to digital signatures based on ID-based cryptography based on the Weil pairing and elliptic curve cryptogra-phy [124].

4.7 fair blind signatures

Blind signatures were conceived by Chaum [32] in the original propositionfor digital cash. Although many works still use blind signatures in theoriginal way, practical implications of blind signatures could cause manyproblems for a real-world money system. Money, digital or not, is inherentlysubject in many illegal transactions and crime. Current cash systems can beconsidered untraceable, since no additional party is involved when cash isexchanged. Nonetheless, authorities and banks can provide some insightwhen criminal activities end up requiring the use of bank services in thecase of money withdrawal or deposit. Blind signatures effectively removethe banks’ (and authorities’) insight for this business.

This problem was first presented in a paper by von Solms and Naccache[118]. The authors show how the perfect anonymity of blind signatureswould have hypothetically prevented law enforcement to capture a criminalin the example of a Japanese kidnapping case. The perpetrator had max-imized his anonymity as much as was possible, but still had to physicallywithdraw money from the bank account he had set up to receive the ransommoney. The perpetrator’s identity was revealed by security cameras regis-tering his withdrawal from the flagged bank account at an ATM. Shouldthe victim have had access to banking services that dealed with digital cashusing blind signatures, the money in his account would be fully untraceableto anyone, and his identity would have remained secret. It is reasonable tofear that should such a fully untraceable payment system be widely avail-able, it would enable (and therefore motivate) many criminal activities thatare otherwise not undertaken because of the larger risks involved.

We therefore conclude that a further requirement for a payment system isthe ability to selectively reveal the identities of payers in the system2. Sincea protocol between both parties cannot be both anonymous and optionallytraceable, a mutually trusted third party called a judge is introduced into thepayment system [113]. The judge and bank can then run an additional pro-tocol, the link detection protocol, that ties transactions to identities. The termfor generating blind signatures using this trusted mutual party is called fairblind signatures. Different requirement sets exist for what features a protocollike this should implement [113]. Stadler et al. [113] and Davida et al. [37]distinguish two tracing types that may be provided by fair blind signatureschemes.

2 Note that we deviate from the conceptual protocols introduced in chapter 2 here.

21

• Type I: Coin tracing The judge provides the bank with information toefficiently recognize a coin once it is spent. This allows authorities torecognize the target of a transaction.

• Type II: Owner tracing The judge provides the bank with informationto efficiently find the identity of a coin owner. This allows authori-ties to recognize who withdrew a certain piece of cash from his/heraccount.

Both of these types provide different services which can address differentrequirements in a payment protocol.

Fair blind signatures build upon standard blind signatures, and encodeadditional information to allow a judge to mediate tracking of money spent.Many proposals exist for cryptographic constructs in fair blind signatures.We explain here the original proposal for fair blind signatures [23, 113];further protocols that employ fair blind signatures can be found in section6.

4.7.1 Stadler et al.’s protocol

This scheme is a derivative of Chaum’s original protocol. The followingsystem parameters are chosen: G is a multiplicative group of prime orderq for which it is hard to compute discrete logarithms; a publicly knownelement g ∈ G; y = gx, with y and x being the bank’s public and privatekeys respectively; a function Sigj which represents the judge’s signaturescheme, and a function H, a cryptographically secure hash.

A payer registers with the judge to obtain two identities in the followingway.

1. The payer sends the judge a registration request

2. The judge chooses a random A ∈ G and α ∈ Zq, and computes A′ =Aα. A and A′ represent the two payer’s identities, and the judge storesboth. The judge sends two messages 〈A, Sigj(A||0)〉, 〈α, Sigj(A||1)〉 tothe payer.

3. The payer computes A′ = Aα

The payer then has the bank sign his/her coins blindly by performing thefollowing protocol.

1. The payer sends the bank A, Sigj(A||0).

2. The bank verifies the signature and computes z = Ax and sends theresult to the payer.

3. The payer computes z′ = zα.

4. The bank chooses some r ∈ Zq and computes t1 = gr, t2 = Ar, both ofwhich are sent to the payer.

5. The payer chooses random β, γ ∈ Zq. With this, he/she computes

the following. t′1 = tβ1 gγ; t′2 = tα

2 A′γ; the hash c′ = H(m||A′||z′||t′1||t′2)where m is a coin message. The payer finally computes the blindedcoin c ≡ β/c′ (mod q) and sends it to the bank.

6. The bank computes the signature s ≡ r + cx (mod q) and returns it tothe payer.

22

7. The payer obtains the signed coin s′ ≡ βs + γ (mod q)

The resulting signature is the tuple 〈A′, Sigj(A′||1), z′, t′1, t′2, s′〉 of which thevalidity can be verified with the judge’s public key on Sigj(A′||1) , and theequivalences gs = t′1yc′ and A′s

′= t′2z′c

′. The coupling of identities for A

and A′ by the judge to the bank is sufficient for revealing the identity of thesigner of coins.

4.7.2 Passive judge protocols

A downside of Stadler et al.’s protocol is that the introduction of a judge inthe withdrawal protocol is unpractical. Schemes were found that omittedthe judge’s involvement in the withdrawal process, and made the judge apassive actor, which only needs to be contacted afterwards. Here we presenttwo ways to achieve fair blind signatures on electronic cash with a passivejudge.

Camenish et al.’s withdrawal

The first such proposal came from Frankel et al. [45]. A passive judge sys-tem was independently introduced by Camenisch et al. [24]. The core ideaof their proposal is to have three components associated with coins: a pairof group members 〈hp, zp〉; a proof W that this pair is related by zp = hx

pwith x the bank’s signing key; a second proof V that anonymity revocationis possible. The proof W is computed blindly by the bank: it is computed ona different pair 〈hw, zw〉 and transformed by the client in the appropriate pair.The proof V is computed entirely by the client. The judge is granted the ca-pability to link the pairs 〈hp, zp〉 and 〈hw, zw〉, thus revoking coin anonymity.

Let G be a cyclic group of prime order q with three elements g, g1, g2 ∈ G.Let H be a cryptographic hash function that maps arbitrary strings onto ele-ments of G. The bank chooses a secret x ∈ Z∗q , computes the correspondingpublic key y = gx, and publishes all parameters but its secret key. The judgechooses a secret key j ∈ Z∗q and publishes public key yj = gj

2. The client andbank then run the protocol shown in figure 4 to create two unlinked pairs〈hp, zp〉 and 〈hw, zw〉.

Given a coin 〈tg, hp, zp, W〉, the judge can trace the original revocationparameter d by computing

(hp/g1)j = gα·j = d

which the bank has stored during coin generation, revealing the originalwithdrawer of the coin. The judge performs coin tracing by, given a revoca-tion parameter d, computing

g1dj−1= g1gα

2 = hp

which reveals the coin generated in the withdrawal associated with d.With each payment, the client associates a proof V that shows hp = g1gα

2 .Since each coin is associated with the value tg = gk (where k ≡ r · γ · δ · x(mod q)), the payee can request a value l ≡ k− cα (mod q) from the payer,where c is an integer based on a unique value like a timestamp or a counter.If the bank obtains two distinct pairs 〈l, c〉, 〈l′, c′〉 for the same coin he cancompute α ≡ l − l′/c′ − c (mod q) and compute the revocation parameter d =yα

j .An example of a passive judge as in Camenisch et al.’s fair blind signature

method is found in the protocol by Gaud and Traore [48].

23

Client BankAuthenticate←−−−−−−−−→

α←R Z∗q Choose unlink factor

hw ← gα−1

1 g2d← yα

j the ’revocation parameter’Proof logyj

d=− logg1hw/g2=α

−−−−−−−−−−−−−−−−→Store d

Bank has 〈hw, zw〉 zw ← hxw

Choose nonce r ←R Zqtg ← gr

th ← hrw

zw, tg, th←−−−−−γ, δ←R Zqhp ← hα

w Unlink hp from hw

zp ← zαw Unlink zp from zw

tg ← tgγyδ Proof of knowledge γ, δ (1)

th ← thγp , zδ

p Proof of knowledge γ, δ (2)

c← H(tg‖g‖hp‖y‖zp‖tg‖th) Create coin info

c← c− δ (mod q) Blind coin infoc−→

Perform blinded signature s← r− cx (mod q)s←−

s← s + γ (mod q) Obtain unblinded signature

W ← 〈c, s〉coin = 〈tg, hp, zp, W〉 Debit client’s account

Figure 4: Camenisch et al.’s withdrawal protocol

4.8 group signatures

Group signatures are a modification of regular digital signatures. Digitalsignatures allow a single party to sign a message that can be verified byanyone. Group signatures allow any party within a group to sign a message,of which anyone can verify that this message was signed by a member ofthis group. In addition, group signatures do not allow a verifier to recognizewhich group member signed the original message [34].

The group manager is a party that possesses a master key. The masterkey is used to generate seperate private keys for each member of the group.Secondly, it can be used to resolve disputes in the case one group memberneeds to deny signing a message that another group member has signed.The master private key corresponds to a group public key. Every group mem-ber’s private key is derived from the master key and can be used to signa message that can pass verification against the group public key. In addi-tion, there is a way for group members to disavow the creation of a groupsignature, with the help of a public key [34].

As an example, we will explain a group signature scheme by Boneh et al.[20]. This particular group signature scheme, like identity-based signatures,employs a bilinear pairing to gain control of signature output. Its security

24

is based on the Strong Diffie-Hellman Assumption, which states that thereexist groups G1, G2 with generators g1 ∈ G1 and g2 ∈ G2 so that it is

computationally infeasible given the tuple 〈g1, g2, gγ2 , g(γ

2)2 , ..., g(γ

q)2 〉 of size

q + 2 for an attacker to find a pair 〈x, g1/γ + x1 〉 with x ∈ Z. The authors define

a zero-knowledge protocol that allows a party in communication to showthe other party that it has knowledge of this pair.

setup Define a bilinear group pair G1, G2 with an isomorphism ψ : G1 →G2 and bilinear map e : G1 × G1 → G2 that are both computable.Select generator g2 ∈ G2 and g1 = ψ(g2) ∈ G1. Randomly select anelement h ∈ G1\{1} and numbers ξ1, ξ2 ∈ Z as well as secret γ ∈ Z.Set u, v ∈ G1 so that uξ1 = vξ2 = h, and set w = gγ

2 . Finally, define acryptographic hash function H which maps arbitrary strings onto theintegers.

For every ith member in a group of size n, select xi ∈ Z∗ randomly,and set Ai = g1/(γ+xi)

1 .

Publish the public key 〈g1, g2, h, u, v, w〉 and set every ith user’s groupsigning key to 〈Ai, xi〉. The group manager stores 〈ξ1, ξ2〉 as the masterkey.

proof-of-knowledge protocol This protocol proves that a group signerknows the pair 〈A, x〉 so that A = g1/x + γ

1 . Exponents α, β ∈ Z are cho-sen, and the values

T1 = uα, T2 = vβ, T3 = Ahα+β, δ1 = x · α, δ2 = x · β

are computed. Then, blinding parameters rα, rβ, rx, rδ1 , rδ2 ∈ Z for allthese values are chosen. The blinded parameters are computed asfollows:

R1 = urα , R2 = vrβ , R3 = e(T3, g2)4x · e(h, w)−rα−rβ · e(h, g2)

−rδ1−rδ2

R4 = Trx

1 · u−rδ1 , R5 = Trx

2 · v−rδ2 ]

The first part of the proof of knowledge is the tuple 〈T1, T2, T3, R1, R2, R3, R4, R5〉.An interested verifier responds with randomly chosen challenge c ∈ Z.The signer computes the values

sα = rα + cα, sβ = rβ + cβ, sx = rx + cx, sδ1 = rδ1 + cδ1, sδ2 = rδ2 + cδ2

and returns these.

sign A message M ∈ {0, 1}∗ is signed as follows. The signer executesabove proof-of-knowledge protocol with itself, taking the challenge tobe c = H(M, T1, T2, T3, R1, R2, R3, R4, R5). The signature is providedby the result of the proof: its form is 〈T1, T2, T3, c, sα, sβ, sx, sδ1 , sδ2〉.

verify The verifier is given of the message M, the group public key andthe signature as above. He/she rederives the R values:

R1 = usα · T−c1 , R2 = vsβ · T−c

2 , R4 = Tsx1 · u

−sδ1 , R5 = Tsx2 · v

−sδ2

and R3 = e(T3, g2)sx · e(h, w)−sα−sβ · e(h, g2)

−sδ1−sδ2 ·

(e(T3, w)

e(g1, g2)

)c

The signature is accepted if and only if c = H(M, T1, T2, T3, R1, R2, R3, R4, R5).

25

disavowal The group manager can, given the group’s public key, the mas-ter key, a message and its signature, check which group member signedthe message. This makes use of the fact that the value T3 is a linearencryption of A, T1 and T2. If the signature is valid, the managercomputes Ai = T3/Tξ1

1 · Tξ22 to reveal the original signer.

A scheme to perform blinded group signatures was proposed by Maitlandand Boyd [81].

4.9 secret sharing

The technique of secret sharing was first proposed by Shamir [108] to dis-tribute a secret among multiple parties in such a way that no informationabout the secret is obtained unless a certain number of parties work together.More formally, a secret sharing scheme describes a method to distribute in-formation of a secret s into parts s1, s2, . . . , sk, . . . , sn with the properties that:

• If a party obtains less than k parts of the secret, this party obtains noinformation about the original secret.

• If a party obtains at least k parts of the secret, then this party canefficiently compute the original secret s.

A scheme in which k secret shares are shared among n parties, wherek ≤ n, is called a (k, n)-treshold secret sharing scheme.

Shamir originally proposed a secret sharing method based on polyno-mial interpolation. He observed that given the general polynomial formf (x) = a0 + a1 · x + a2 · x2 + . . . ak · xk one can find the value for every aiby performing regression analysis on k points on that polynomial3. There-fore, one can distribute a secret s by constructing a polynomial f (x) =s + a1 · x + a2 · x2 + . . . + ak · xk with a1 . . . ak are randomly chosen integers.Next, for every ith party to which a secret share is to be distributed, com-pute the point Si = (i, f (i)) on the polynomial, and send this secret share tothe party.

If at least k parties come together to compute the secret, they can usetheir k points on the polynomial to recompute the original polynomial co-efficients. One algorithm to reconstruct a polynomial from a set of pointis the Lagrange polynomial method, which is often suggested to efficientlyrecompute the original polynomial form [13].

4.9.1 The Chinese Remainder Theorem

The Chinese Remainder Theorem states that given a sequence of modulin1, n2, . . . , nk which are pairwise coprime, and a sequence of integers a1, a2, . . . , ak,

3 Informally: two points are required to define a line; three points are required to define aparabola; four points are required to define a cubic curve; and so on for polynomials of higherdegree.

26

there is a unique positive integer a which is a solution to the sequence ofmodular congruences:

a ≡ a1 (mod n1)

a ≡ a2 (mod n2)

. . .

a ≡ ak (mod nk)

More specifically, a can be computed in the following way:

1. Let N = n1 · n2 · . . . · nk be the product of all moduli.

2. For every ni, solve Bezout’s identity r · ni +s·Nni

= 1 for integers r and

s using the Extended Euclidean Algorithm. Let ei =s·Nni

.

3. Compute a = a1 · e1 + a2 · e2 + . . . + ak · ek.

The reader is referred to Gillian [51] for more information on the ChineseRemainder Theorem and proofs of the theorem statement and presentedalgorithm.

Interpreted in reverse, the Chinese Remainder Theorem states that the in-formation of a positive integer a can be shared in the description of k modularcongruences. Therefore, the Chinese Remainder Theorem presents a way todivide a secret s into a (n, k)-treshold scheme by distributing the informa-tion about modular congruences. Several methods to accomplish this havebeen proposed in literature [4, 84]; we will discuss the method presented byAsmuth and Bloom [4] here.

A (k, n)-treshold Asmuth and Bloom secret sharing scheme is definedby integers 2 ≤ k ≤ n in which k is the amount of shares required torecompute the original secret and n is the total amount of shares to begenerated. Pick a sequence of numbers w < m1 < . . . < mn such thatw · (mn ·mn−1 · ... ·mn−k+2) > m1 ·m2 · . . . ·mk. More specifically, given theproducts of sequences πlower and πlower as in

m1 ·m2 . . . ·mk︸︷︷︸πlower

· . . . ·mn

m1 · . . . ·mn−k+2 · . . . ·mn−1 ·mn︸︷︷︸πupper

the sequence must be chosen to have πlower < w · πupper.

Define the product M = m1 · . . . · mn. A secret S is then chosen fromintegers modulo w: S ∈ Zw. Then a random integer α is chosen so that

27

S + α · w > M. Let x = S + α · w and compute the sequence s1, . . . , sk usingthe following system of congruences:

x ≡ s1 (mod m1)

x ≡ s2 (mod m2)

. . .

x ≡ sk (mod mk)

The secret shares are the tuples 〈s1, m1〉, . . . , 〈sk, mk〉. The value w is pub-lished and known to all parties. Using all pairs of tuples, one can use theChinese Remainder Theorem to compute x. Finally, the secret is obtainedby finding S ≡ x (mod w).

28

5

M O B I L E S E C U R I T Y C O N S I D E R AT I O N S

The previous chapters have discussed the cryptography of digital paymentprotocols. We instead focus our efforts at the circumstances a mobile plat-form presents. We address questions about connectivity, authentication,storage and other factors that are relevant for the mobile context.

5.1 offline authentication

During mobile payments, both payer and payee authenticate mutually beforeestablishing a secure channel over which to transfer money. The authentica-tion is a necessity because to assure both parties that their transaction occursbetween the intended parties, and not an intruder or an impostor.

Although subsequent improvements in infrastructure and cellular net-work technology have significantly raised availability, internet connectivityon mobile devices is subject to location (crowded or rural areas, indoors),vulnerable equipment and many other unpredictable circumstances. In ad-dition, a payment system building a reliability on an internet connection tiesa payment’s system context too strictly to devices with internet connectionsand prohibits other point-of-sale devices from functioning as a payee. Fora payment system to function reliably and scale better, authentication mustnot require an internet connection and work offline instead.

Public key cryptography is most often employed for authentication. Anexample is the Schnorr [107] identification scheme, which performs authen-tication by proving to the other party the possession of some private keycorresponding to a previously interchanged public key. The interchangeand authentication of this public key for identification is the crucial prop-erty of any authentication system. In online systems, this key is placed insome public directory, or, certificated by a set of predetermined and prede-ployed certificate authorities [70]. In an offline system, users themselves areresponsible for authentication of the public key.

This section describes two methods to accomplish this; the first is out-of-band band authentication of mutually shared secrets; the second is identity-based cryptography.

5.1.1 Out-of-band authentication methods

Out-of-band authentication is an authentication mechanism that uses availablecommunication methods outside of the channel that needs to be authenti-cated [9]. In the mobile context, users set up their secure channel in proxim-ity with one another. They can therefore reveal additional information aboutthe internal state of the cryptography by inspecting one another’s screen.When the authentication method specifically requires human interaction forapproval, this method has been named manual authentication [49].

29

For example, suppose that two users perform a key exchange using theDiffie-Hellman protocol [40]. The result is a mutually shared secret, butbased on channel communication alone, the authors cannot verify whetherthe communication was subject to man-in-the-middle attack by which anadversary has placed him/herself in the middle of the key exchange andacts as a proxy of the communication. To lift this uncertainty, mobile deviceusers can simply manually confirm whether they have agreed to the samekey. This model was proposed by Laur and Nyberg [73] and proven securein the context of the Bluetooth pairing protocol.

Bluetooth pairing requires users to enter the same PIN code on both de-vices intended to be paired [17]. Older versions of the Bluetooth pairingprotocol derived all key entropy from the entered 4-digit PIN code, andare not considered secure. This is despite the fact that formal verificationrevealed that the protocol is reasonably secure [31]. The Bluetooth specifica-tion has since then been updated to proceed with pairing using ephemeralkeys exchanged using the Diffie-Hellman protocol, which is optionally au-thenticated using a variety of methods:

• Numeric comparison: both devices display a six-digit numeric code,which has to be confirmed

• Passkey entry: the user manually enters a numberic code on both orone of the two devices to complete key exchange

• Out-of-band: another communication channel like NFC is used to con-firm the key that is exchanged over the Bluetooth channel

The usability of several of out-of-band authentication methods was in-vestigated by Kainda et al. [64] and Kumar et al. [72]. Both authors notethat security failures are a problem when it comes to authentication methodswhere the user simply needs to confirm a value. Security failures occurwhen a user erroneously rejects an agreed upon value. Kumar et al. con-clude that comparison of numeric values combines high user preferencewith a low amount of security errors, which is confirmed by Kainda et al..Both authors also looked at more exotic ways of data agreement, such asvisual comparison of images by the user (which had a larger amount of se-curity errors) as well as using microphone and camera sensors for the extrachannels (which had low user preference).

5.1.2 Secret exchange mechanisms

Having established an out-of-band method to confirm a shared secret, webriefly describe three methods that are suitable for sharing such a secret andcreating an authenticated channel.

diffie-hellman key exchange [40] The Diffie-Hellman key exchangeis a simple secure two-party computation to secretly generate a mutuallyshared secret based on the computational Diffie-Hellman assumption1. Thisassumption is used to exchange a secret as follows:

1 See section 4.2

30

Alice Bobchoose prime q,G of order q, g ∈ G

a←R Zqq, G, g, A = ga−−−−−−−−−−→

b←R Zq

B = gb←−−−−−

s← Ba = (gb)a = gab s← Ab = (ga)b = gab

Where ← denotes assignment, and ←R denotes a random choice. Afterthe key is established, it can be used to symmetrically encrypt subsequentcommunication. Each encrypted subsequent message is implicitly authenti-cated with the knowledge that only both parties possess knowledge of thekey.

secure hash commitment before knowledge [64] [105] An al-ternative method is the SHCBK-check protocol. The idea is have one partycompute a secret and sending its cryptographic hash to the other partyalong with a commitment to the secret value, in the form of a cryptographichash of another random value. The other party makes a similar commitmentto its public key. Once commitments are made, the plaintext of the previ-ously sent hashes is revealed to each other to show that the first messagesoriginated from the right parties. Finally, the secret value is then transferredencrypted by the public key.

We assume Alice and Bob possess a cryptographic hash function H andBob possesses a public/private key pair 〈pk, sk〉. Encryption using the pub-lic key of some message m is denoted {[m]}pk.

Alice Boba←R Z,k←R Z

ca = H(a), ck = H(k)−−−−−−−−−−−−−−−→

b←R Z

cb = H(b), pk←−−−−−−−−−a, x = {[k]}pk−−−−−−−−−→

check H(a) = ca,ck = H(k),k = [{x}]sk

b←−check H(b) = cb

This protocol repeats itself if any check fails. Failure is not an unlikelyevent as the communication without confidentiality or integrity measure-ments in place. After the protocol has completed succesfully, both partieshave agreed upon the secret value k.

This protocol is somewhat more efficient than the Diffie-Hellman secretexchange as it reduces the number of modular exponentiation operationsthat need to be done, and it instead uses many more easily computablecryptographic hashes. It trades this off with a larger susceptibility to denialof service attacks through lack of integrity checking and a larger number ofmessages involved.

31

9.

The scheme works with 100% ASK only and it is not part of the ISO standard on NFC. The idea is that both devices, say Device A and Device B, send random data at the same time. In a setup phase the two devices synchronize on the exact timing of the bits and also on the amplitudes and phases of the RF signal. This is possible as devices can send and receive at the same time. After that synchronisation, A and B are able to send at exactly the same time with exactly the same amplitudes and phases.While sending random bits of 0 or 1, each device also listens to the RF field. When both devices send a zero, the sum signal is zero and an attacker, who is listening, would know that both devices sent a zero. This does not help. The same thing happens when both, A and B, send a one. The sum is the double RF signal and an attacker knows that both de-vices sent a one. It gets interesting once A sends a zero and B sends a one or vice versa. In this case both devices know what the other device has sent, because the devices know what they themselves have sent. However, an attacker only sees the sum RF signal and he cannot figure out which device sent the zero and which device sent the one. This idea is illustrated in Figure 2. The top graph shows the signals produced by A in red and by B in blue. A sends the four bits: 0, 0, 1, and 1. B sends the four bits: 0, 1, 0, and 1. The lower graph shows the sum signal as seen by an attacker. It shows that for the bit com-binations (A sends 0, B sends 1) and (A sends 1, B sends 0) the result for the attacker is absolutely the same and the attacker cannot distinguish these two cases.

Figure 2 NFC specific Key Agreement

0 1 2 3 4 5 6 7 8-2

-1

0

1

2Total Signal seen on RF field

0 1 2 3 4 5 6 7 8-3

-2

-1

0

1Send: 0/0, 0/1, 1/0 1/1 : Signal A/B

The two devices now discard all bits, where both devices sent the same value and collect all bits, where the two devices sent different values. They can either collect the bits sent by A or by B. This must be agreed on start-up, but it doesn’t matter. This way A and B can agree on an arbitrary long shared secret. A new bit is generated with a prob-ability of 50%. Thus, the generation of a 128 bit shared secret would need approximate-

Figure 5: An illustration of how interference creates an unintelligible signalfor an external observer. From Haselsteiner and Breitfuß [57]

.

radio secrets [57] Haselsteiner and Breitfuß proposed to use char-acteristics of NFC radio communication to generate a secret. Both radio-equipped parties send out a string of random bits at the same time. Thisresults in a channel collision; for an observer, the radiowaves of both signalscombine and appear to become random noise. Both parties know the orig-inal signal they sent, however, and can substract their own signal from therandom noise that was observed on the channel. Since both parties knowwhat the other party has sent, they can combine this data to a shared secretonly they know, and use this as a shared secret. See figure 5 for an illus-tration. Conceptually, this is similar to the Diffie-Hellman secret exchange.The difference is that this relies on a hardware trapdoor function instead ofmodular exponentiation.

5.1.3 Identity-based cryptography

Shamir [109] introduced the idea of identity-based (ID-based) cryptographyin 1984 to show a different approach to solve this problem. Whereas thepublic key in traditional public key cryptography the public key is an arbi-trary looking consequence of cryptographic operations on random numbers,he suggested a scheme in which the public key was chosen. The public keymay then be chosen to represent identifying information, such as a user’sname, bank account number or other properties which can convince anotherparty of authenticity. Anyone wanting to authenticate this public key canuse the information contained in it and check if this information matchesthe person claiming this public key is his or hers. Subsequently, the verifiercan be convinced that signatures that verify against this identifying stringare in fact signed by the proper private key.

One of the first practical ID-based signature schemes was introduced byBoneh and Franklin in 2001 [19]. It is based on the Weil pairing of ellipticcurves, and performs as fast as traditional signature schemes based on the

32

digital logarithm. The key difference between this scheme and traditionalschemes is that here the desired public key is an input of the key genera-tion algorithm, as opposed to the pseudorandom result of a key generationalgorithm.

The Boneh-Franklin scheme extends the regular discrete logarithm prob-lem to be able to solve this problem. Let G1 and G2 be two groups of orderp with p a large prime and a map f : G1 × G1 → G2 with the followingproperties:

bilinear For all elements P, Q ∈ G1 and all integers a, b ∈ Z it holds thatf (aP, bQ) = f (P, Q)ab.

non-degenerative f does not map all pairs in G1×G1 onto the identityof G2.

computable Computing the result of f (P, Q) can be done quickly for anyP, Q ∈ G1.

The mapping f satisfying these properties is called an admissable map. TheWeil pairing of elliptic curvers is used as the example for such an admiss-able map by Boneh and Franklin. They show that a mapping satisfyingthese properties can be used to build an identity-based cryptosystem in thefollowing way.

setup

1. Choose a large prime p, two groups G1, G2 of order p, and anadmissable bilinear map f of the two groups as described beforeand a generator P ∈ G1.

2. Pick any number kpriv ∈ Z∗q as a master private key and its corre-sponding public key by finding kpub = kpriv · P.

3. Define two cryptographic hash functions H1 : {0, 1}∗ → G∗1 andH2 : G2 → {0, 1}n, i.e. a function that maps strings of arbitrarylength onto elements of G1 and a function that maps elements ofG2 on strings of fixed length n.

extraction of private key We transform the public ID string to be amember of G1. Given a public ID string ID of arbitrary length {0, 1}∗the algorithm computes QID = H1(ID). QID is a member of G1 bydefinition of the H1 function. The private key is generated by dpriv =kpriv ·QID.

encryption using the public key To encrypt some message M underthe public key ID, take QID = H1(ID), some random r ∈ Z∗q andeID = f (QID, kpub). Then the ciphertext is the tuple C = 〈rP, M ⊕H2(er

ID)〉.

decryption using the private key The possesor of the private key dprivcan decrypt the tuple C = 〈U, V〉 by computing M = V⊕H2( f (dpriv, U)).This yields the original message since:

f (dpriv, U) = f (kpriv ·QID, rP) = f (QID, P)r·kpriv

= f (QID, P · kpriv)r = f (QID, kpub)

r

= erID

Using this method, some trusted third party can generate private keyscorresponding to arbitrarily chosen public keys, which can subsequently

33

be used in a similar fashion as regular public key cryptography. In theiroriginal description, Boneh and Franklin prove the algorithm’s consistencyand show its security under the random oracle model. The reader is referredto their work [19].

Other schemes to implement ID-based cryptography also exist, but theBoneh-Franklin method was the first to describe a system that yields near-to the same efficiency as such algorithms as the digital signature algorithm(DSA).

5.1.4 Key escrow and extensions of identity-based cryptography

The Boneh-Franklin scheme in itself does not fully mirror the capabilities ofdigital signatures as it weakens the notion of non-repudiation. The privatekey generator party (PKG) retains all the power to regenerate private keysfor all public keys used in the system. In the case this PKG becomes com-promised, if only temporarily, private keys can be generated and messagescan be signed for users that have kept their keys private. Because the PKGremains in power to generate these message, the non-repudiation propertythat only the holder of the private key can sign messages is violated.

Boneh and Franklin themselves proposed to solve key escrow by usingShamir secret sharing to distribute the information over multiple parties.This idea was shown to be feasible, but has serious practical problems whenit comes to performance and the amount of network communication re-quired [68].

Several modifications to classical identity based encryption have been pro-posed to solve this escrow problem without a distribution of trust. Threedifferent trust levels of escrow migitation have been proposed to distinguishbetween methods of key escrow [52, 123]. They are as follows:

• Level 1: The PKG can recompute users’ private keys.

• Level 2: The PKG cannot recompute users’ private keys, but still re-tains capabilities to impersonate them with the master key.

• Level 3: The PKG cannot recompute users’ private keys, and will bedetected if trying to impersonate as a user.

The first level corresponds to Boneh and Franklin’s scheme. Three examplesof higher escrow migitation levels are given here:

certificateless signatures [3] In this scheme, the PKG does notgenerate the full private key for the user. Instead, the PKG generates a keythat is a partial private key from which the user itself can derive a finalprivate key by adding a secret multiplicative factor to the private key. Thismakes the user the only one able to encrypt using his/her own private key.

Although the bank has no access to a user’s private key, it is still capableof impersonating a user by simply generating its own secret and private keybased on the partial private key it generates for a user’s public ID string.Signature verifiers will still verify this other signature as being correct, andthe user cannot prove that it did not sign a message. Therefore, this schemehas escrow migitation level 2. Strictly speaking certificateless signaturesprevent key escrow, but the scheme does not guarantee non-repudiation inany sense.

34

certificate-based signatures [65] In this scheme, the key genera-tion of an ID-based signature is done by a certificate authority (CA). Despiteits name, the function of this CA is however closer to the private key gen-erator discussed earlier than it is to the cerficate authority used in internetTLS networks.

The CA generates certificates that are bound to the user’s ID string anda certain time period. The user generates a seperate private and public keypair seperately from the CA. The verification of signatures is dependent ona user’s public key, ID string and the certificate, and verification is there-fore bound to the expiration time of the certificate. Since the verificationof the ID string is independent of the actual signing of the message, keyescrow is prevented. Moreover, a CA cannot impersonate a user, since theuser’s private key is not generated by the CA and, in contrast with certifi-cateless signatures, the CA cannot generate a different private key capableof upholding verification to the user’s public ID. Therefore, certificate-basedsignatures uphold level 3 of escrow migitation.

Like Boneh and Franklin’s identity-based encryption, proposed certificatebased signatures are usually based on a group pairing. Here, we brieflynote a scheme by Liu et al. [78] which does not rely on a group pairing. Leta certificate authority setup by finding a prime q and a group G of order qwith generator g ∈ G. The authority then finds a secret a ∈ G and generatespublic key A = ga. It publishes q, G, A and hash function H : {0, 1}∗ → Z∗q .

A user generates a public key and obtains a certificate for identity stringID in the following way:

User Authorityu←R Z∗qπu ← proof of knowledge of uPK ← 〈gu, Xu, τu〉

PK−−→r ←R Z∗q

h← H(PK, ID)R← gr

s← r−1(h− aR) mod qcert = 〈R, s〉←−−−−−−−−

Using a certificate from the certificate authority, a user Alice can sign amessage m and send it to user Bob who can then verify the validity of hersignature.

Alice Boby←R Z∗qY ← R−y

h← H(Y‖R‖m)z← y + h · s · u mod q

PKAlice = 〈gu, Xu, πu〉−−−−−−−−−−−−−−−→σ = 〈Y, R, z〉−−−−−−−−−→

verify PK by verifying πuh′ ← H(Y‖R‖m)h′ ← H(PK, ID)

check (gu)h′ ,h′ = RzY(Xu)hR

35

The correctness of signature verification is shown by the following equality.

RzY(Xu)hR = RzR−y(Xu)hR = Ry+hsuR−y(Xu)hR

= Rhsu(Xu)hR = grhsuguahR = grhu(r−1(h−aR))+uahR

= ghuh−uahR+uahR = ghuh = (gu)hh

escrow-free identity-based signatures [123] This scheme wasdesigned to provide level 3 escrow migitation, while only relying on theuser’s ID string as public information. Although the user does generate aprivate and public key independent of the PKG, but the information aboutthe user’s public key is encoded within the identity string without givingthe PKG access to the user’s information. This is accomplished by havinganother trusted party presiding over the key extraction phase.

5.2 wallet protection

Digital cash for offline use and associated cryptographic keys must be storedon device itself. Metaphorically, we call this place of storage the wallet.The wallet must not be accessible by applications other than the paymentapplication with user’s consent. Securing it properly is challenging in themobile context. We will discuss some approaches in this section.

5.2.1 Secure element

A practical problem that occurs when developing smartphone applicationsto use certain aspects of NFC communication is the inaccesibility of a secureelement. A secure element is a piece of hardware that is tamper resistant andhas limited availability for the host operating system. This secure element isoften used as the target for NFC ’Card Emulation’ mode, in which an NFCchip emulates behaviour of a wireless smart card. The secure element actssimilar to a trusted platform module; it guarantees certain hardware behav-ior not accessible or exploitable by software. A secure element is thereforeincluded in almost any mobile device that includes NFC hardware.

The secure element can be used a safe storage for payment data. Indeed,MasterCard’s PayPass service uses the secure element of a device to storepayment credentials for wireless EMV applications. Google Wallet, a Pay-Pass implementation, similarily stores payment information within this pro-tected area. Access to use this secure element is quite restricted, however;an application must present the secure element with the right credentialsduring installation, and interfacing with it is otherwise restricted. Otherdevelopers have to use other means to secure sensitive information.

A secure element can be implemented in various ways [102]. There arepseudo-secure secure elements, which attempt to obfuscate the secure datain such a way that makes it hard, but not impossible, to obtain the secretdata from software. The different methods to implement secure elementsare summarized in table 3.

5.2.2 Symmetric encryption

If the use of a secure element is not available, only ’regular’ storage becomesan option on mobile devices. This usually comes down to an application

36

https://mobile.mastercard.com/Partner/MobilePayPass/SecureElements

Method Security DeploymentSoftware secureelement

Compromisablewith phone rootaccess

Readily available

Built-in hard-ware

Full Only available to NFC chipsetmanufacturers

USIM integrated Full Dependant on telecommunica-tion providers

Add-on hard-ware

Full Requires distribution of hard-ware, does not work on all phones

Table 3: A comparison of secure element alternatives

designated area on regular flash storage that offers no specific hardwaresecurity. The wallet must be secured using software techniques.

Popular mobile operating systems offer ’private storage’ on the device2,which is to say that the operating system guarantee that they will not grantaccess to this data to other apps or unprivileged users. This is no real se-curity; the data can still be plainly read by priviliged users or by physicalaccess to the flash storage. Indeed, reports show payment applications arecompromisable with root access on phones, leading developers to recom-mend turning off root access on the users’ phones.

The best way to protect a user’s private keys appears to be to protect ac-cess to the keys by the entering of a passphrase. By symmetrically encrypt-ing the key and decrypting it using a passphrase within the application, onecan make up some ground. This however is at best a migitation, as smart-phones do not posess proper ways to have users enter high entropy pass-words efficiently. Presently, we are not aware of literature that researchessymmetric keys on mobile phones.

An area in which some advancements are made is that of physically un-cloneable functions (PUFs). PUFs are pieces of hardware that, because ofthe inherent variations in hardware manufacturing, exhibit unique unpre-dictable behaviour for every distinct piece of hardware. These variations aretied to a specific hardware setup, and quantifying these variations thereforeyields information that can tie key generation to physical devices [115, 119].

Unfortunately, research towards PUFs in mobile devices appears to beabsent, and applying other research to the mobile device context appearsinfeasible. PUFs have been demonstrated on controlled groups of hardwaresets, and there is no indication that a methodology for extracting PUFs canbe extended to a group as diverse as mobile devices.

5.3 random number generators

Many cryptographic constructs depend on the strength of the random num-ber generators used in mobile devices. If random nonces used in challengesin the protocol can be guessed up front, adversaries can succesfully convincepayers or payees possession of a digital certificate when they do not.

Within random number generators, there is a distinction between truerandom number generators (TRNGs) of which the randomness of its outputis generated by some random physical process and those of pseudorandomnumber generators (PRNGs) which are based on some mathematical func-

2 Private storage is available on the Android, Windows Phone and iOS platforms.

37

http://developer.android.com/guide/topics/data/data-storage.html#filesInternal

http://msdn.microsoft.com/en-us/library/hh821020.aspx

http://resources.infosecinstitute.com/ios-application-security-part-20-local-data-storage-nsuserdefaults-coredata-sqlite-plist-files/

tion based on some nonrandomly chosen original seed. PRNGs are deter-ministic and considered an inferior choice for cryptography. Some PRNGsare called cryptographically secure if they satisfy the following properties:

• Given a sequence of bits generated by the PRNG, no polynomial algo-rithm exists to predict the next bit generated by the generator.

• If at some point during the generation all information about the in-ternal state of the PRNG becomes known, it should be impossible torecreate the previous bits generated in the stream.

Most Android versions use an SHA-1 based random number generator, butit is unknown what algorithm is used on iOS and Windows Phone and An-droid starting version 4.4. Although this algorithm is claimed to be crypto-graphically secure, no research has scrutinized the predictability of randomnumbers and entropy sources. Based on our own research, we hypothesizethat as of Android 4.4, Android’s random number generator mostly usesprocessor interrupt timing as an entropy source.

As an alternative to using the operating system’s provided PRNGs, it ispossible to construct a TRNG using the mobile devices’ sensors [47]. Usinga mobile devices’ accelerometer, magnetometer, orientation sensor and GPSsource, and combining the output of the most entropy-rich bits in thosereadings, it is possible to construct a string of truly random bits.

5.4 cryptographic performance

Mobile devices have traditionally been lacking in computing performance.In recent years computing power of mobile devices has increased. A mobilesmartphone CPU like the Qualcomm Snapdragon S4 has over half of theperformance of a modern desktop CPU when computing elliptic curves3.Published work on performance of mobile processors on cryptographic per-formance however remains, to our knowledge, sparse.

Using the NEON instruction set found in CPUs used in nearly all modernmobile devices, Bernstein and Schwabe tested the performance of severalcryptographic operations, including elliptic curve performance, RSA perfor-mance and shared key generation [12]. Improvements in mobile systemsseem to indicate that mobile systems possess enough performance to runcomplex cryptographical operations.

Some notes on optimizing the implementation of pairing-based cryptog-raphy are also available [25]. It appears that choosing the right way to im-plement the required G1 and G2 makes a substantial difference. It is notedthat delegation of the computing of pairings is a possibility while keepingthe system secure, and that it is possible to transform the scheme in such away that only exponentiation is required. Nonetheless, it appears the Boneh,Boyen and Shacham group signature scheme which employs bilinear pair-ing using elliptic curves, can perform pairing within less than 100ms on aSamsung Galaxy S2 smartphone.

Group signature performance on mobile devices was tested in Potzmaderet al.’s work [99]. The authors tested several group signature schemes ona set of 2012 and 2013 smartphones and found signature and verificationperformance to be varying from 100s of milliseconds per signature to severalseconds per signature, depending on the particular group signature schemechosen. We will use part their work in the benchmarks of chapter 10.

3 http://cr.yp.to/talks/2013.06.24/slides-djb-20130624-a4.pdf

38

5.5 nfc security

Communication in between devices will be done using near-field communi-cation. Near-field communication is an implementation of the ISO/IEC 8192

standard as well as the ISO/IEC 14443 wireless smartcard protocol. The firststandard covers the second networking layer specification of the NFC spec,but no default security mechanisms are in place to prevent eavesdroppingon the connection. Although the range of NFC devices is said to be in therange of centimeters, sensitive antennae can snoop NFC data from dozensof meters away among wireless smart cards [67].

The NFC specification [92] does not standardize or even recommend keyagreement or encryption schemes; it is left to the implementer to specifysoftware mechanisms running on top of the regular NFC hardware interface.We discussed possible methods for this in section 5.1.2.

39

6E L E C T R O N I C C A S H P R O T O C O L S

We now have sufficient background to discuss some academic proposalsthat have been made for digital payment protocols that possess the featuresdiscussed in chapter 2. We discuss these protocols as a background forthe introduction of our own protocols in chapter 8. Nomenclature of theseprotocols is not always clear; these protocols have sometimes been referredto as digital cheques, e-cheques, e-cash and digital cash. We will use theterm electronic cash to refer to all of these protocols. Not only was this theterm used in the original work towards this goal [36], it also captures themetaphor these protocols accomplish: implementing a software alternativefor coins and banknotes.

6.1 chaum’s untraceable electronic cash

This was the original protocol by Chaum and Noar, as referred to already inthis paper. In contrast to many later proposals, there are severable notabledifferences with later e-cash proposals. Chaum et al.’s proposal predates thelarge scale adoption of the discrete logarithm problem on elliptic curves, andinstead uses RSA-based integer factorization as public key cryptography.Secondly, the dangers of employing blind signatures was not realized in thisproposal. Lastly, the cut-and-choose principle used in this protocol (alreadydiscussed in section 4.5.2) can be considered inefficient. Nonetheless, wepresent a full description of this protocol here.

setup The bank generates parameters of an RSA public-private key pair: itselects two large primes p and q, and computes their product n = p · q.The bank publishes n. The bank also publishes a security parameter kand defines two cryptographic hash functions f and g that each taketwo arguments.

account setup A client generates a bank account number u. The bankassociates this number with a coin counter v.

withdrawal 1. A client chooses 4 · k random numbers. For all i so that0 < i ≤ k the client picks random ai, ci, di, ri ∈ Zn.

2. The client then blinds these coins, like seen earlier. For each 0 <i ≤ k he/she computes

xi = g(ai, ci)

yi = g(ai ⊕ u‖(v + i), di)

Bi ≡ r3i · f (xi, yi) mod n

and sends these values to the bank.

41

3. From the indices 0 < i ≤ k the client sent to the bank, the bankrandomly chooses half of those indices. The bank returns that setR of indices of size k/2 to the client.

4. For each i ∈ R, the client sends the bank the corresponding valuefor ri, ai and ci.

5. The bank checks whether those values are correct. It can do thisby recomputing each value Bi for each i ∈ R from the variablesthe client has provided him, since ai, ci, ri, u and v are known tothe bank.

6. The bank computes the coin as the product of the values of Bi forall i not included in the random selection:

P = ∏i/∈R

B1/3i

which is sent to the client. The bank then increases the client’scounter v by k.

7. The client generates his/her coin by computing the product ofthe computed hashes corresponding to the non-selected i values:

C = ∏i/∈R

f (xi, yi)1/3

payment 1. The payer sends a coin C to the payee.

2. The payee sends a random binary string Z of length k/2 to thepayer.

Z = z1, z2, ..., zk/2

3. The payer responds in the following way, for all i in 0 < i ≤ k/2:

wi =

{〈ai, ci, yi〉 if zi = 1〈xi, ai ⊕ u‖(v + i), di〉 if zi = 0

All values of wi make up the ordered set W.

4. The payee verifies whether the responses are of the proper form,and whether they can result in the received value for C.

deposit The values received by the payee are tied to the payer itself. Thepayee cannot respend this money; he/she first needs to deposit andthen make a withdrawal. To deposit, the payee sends the bank thevalue for C, Z and W.

double spending detection If a user double spends a coin, there isoverwhelming probability that for some 0 < i ≤ k the bank receivesdistinct values wi, w′i . Suppose wi was created for zi = 0 and w′i wascreated for zi = 1. Then wi = 〈xi, ai ⊕ u‖(v+ i), di〉 and w′i = 〈ai, ci, yi〉.The bank can then find the value for u‖(v + i), by ⊕’ing out the aivalue found in the first tuple by the ai found in the second tuple.

6.2 gaud & traore’s payment protocol

In their work, Gaud and Traore present a system that is presented to beoffline, fair and resilient to known attacks [48]. In addition, it provides

42

features to be categorized as both a Type I and Type II fair blind signaturescheme1.

The setup by the bank is as follows:

1. The bank chooses primes p and q and constants δ and γ so that |p−1| = δ + n and p = γq + 1.

2. The bank chooses the group Gq ⊂ Z∗q and four generators g1, g2, g3, g4 ∈Gq.

3. The secret key is the randomly picked element b ∈ Z∗q .

4. The bank chooses a cryptographic hash function H that maps anystring {0, 1}∗ to Zq.

5. The bank’s public parameters are p, q, the generators g1, g2, g3, g4, thehash function H, and the bank’s public keys h1 = gb

1, h2 = gb2, h4 = gb

4.

The judge’s setup protocol:

1. The judge chooses a secret key randomly j ∈ Z∗q .

2. The judge publishes public keys f2 = gj2 and f3 = gj

3.

3. The bank publishes F = f b3 .

Each user registers by the following protocol:

1. The user chooses secret key u ∈ Z∗q and publishes public identityI = gu

1 which doubles in use as the user’s bank account number.

2. The user uses Schnorr’s identification scheme [107] to prove to thebank that he/she knows the discrete logarithm of I.

The user withdraws money from the bank in two steps. The coin tracingstep ensures that information is exchanged so that the bank can trace moneywith the assistance of the judge. Subsequently, and actual withdrawal ismade. The coin tracing phase:

1. The user authenticates him/herself to the bank to be the owner ofaccount I.

2. The user chooses numbers s, t ∈ Z∗q and computes E1 = gs2 f t

3 andE2 = gt

3.

3. The user proves to the bank that log f3E1 is equal to logg3

E2.

4. The bank verifies the proof and stores the pair (E1, E2) coupled to theuser in some withdrawal database.

The withdrawal:

1. The user randomly chooses numbers a, b ∈ Z∗q and computes A2 = f s2 ,

D = ga1gb

2, E = f b2 to generate a message m′ = A2‖D‖E.

2. Both bank and user compute the blinded coin m = I · g4 · E1. Thebanks signs the coin using Chaum’s blind signature protocol [32], andthe user obtains a signature on m′‖coin. This is possible because coinis defined as coin = I · g4 · gs

2 and m = coin · f t3 of which only the user

knows the factor f t3.

1 See section 4.7

43

3. The bank debits the withdrawn money from bank account I.

Having obtained coins, the user pays with these coins in the following way:

1. The payer obtains the public identity of the payee Ipayee and a paymenttimestamp DH.

2. The payer computes c = H(Ipayee‖DH‖coin‖m′) as well as the valuesr1 ≡ a− cu mod q and r2 ≡ b− cs mod q.

3. The payer sends a signed packet of coin, m′, c, r1 and r2 to the payee.In addition, a proof is added that the payer knows the the value ofA1 = coin/g4 and that logg2

A1 = log f2A2.

The coin is then deposited by having the bank verify the same steps as thepayee and crediting the payee’s account with the money.

Given the above protocol, there are three tracing mechanisms in placenow. In the case of double spending, the bank will obtain two pairs c, r andc′, r′1 which are distinct with very high probability. The bank can compute

u =r′1−r1c−c1

revealing the double spending user’s identity.The owner of a certain coin can be found by the judge. The judge is given

the values A1 and A2. The judge then computes A1/A1/j2 = gu

1 = I. Thisobtains the owning users’ account number.

Coins can be traced by providing the judge with a payment transcript andusing its knowledge of the E1 and E2 values to obtain the values of gs

2, fromwhich the judge can compute the coin value I · g4 · gs

2. This coin can then berecognized when it appears in payments and deposits.

6.3 scalable group signatures

Most payment algorithms focus on solving the problem of coin spendingwith a single bank. The problem of adding additional banks to a paymentsystem was first considered by Lysyanskaya and Ramzan [80]. They con-sider a more general analogy of cash; in most national systems, many banksissue money created by a central bank. The central bank ’manages’ eachbank within national payment traffic, and each of the issuing banks providepeople with payment services. Within this more general view of paymentsystems, they consider the following additional properties to be important:

1. Untraceability holds: no bank, including the central bank, can followpayments

2. It is easy to verify authenticity of e-cash received by the payee

3. Addition or removal of banks from the system does not require recom-putation of system parameters

4. No payee can distinguish which bank issued any received e-cash; thiscan only be accomplished by the central bank

5. Neither the central bank or any other bank can issue cash on behalf ofanother bank

The authors use group signatures to accomplish most of these features intheir protocol. Group signatures, originally proposed by Chaum and Heyst[34], are signature schemes in which any member of a group can anony-mously sign a message on behalf of some larger group. As employed by

44

Lysyanskaya and Ramzan [80], they allow banks to sign messages on behalfof a group of national banks capable of signing electronic cash. Their pro-posal has the merit of proving the concept that groups signatures can beused to build a scalable payment system, but has some practical problems.First, the authors present a system that blinds signatures, which, althoughnovel at the time, has practical consequences2. Secondly, the computation ofprotocol parameters is dependendent on a large number of modular expo-nentation operations during payment, which puts substantial requirementsof the processing power of involved devices.

A development of earlier protocols, Wang et al. [120] present a protocolthat works in the context of multiple banks with group signatures and usesID-based signatures for authentication. It introduces the notion of a centralbank, which is an additional party that gives banks credentials to participatein these payment systems. It uses partially blind signatures; an extensionof blind signatures that allow the bank to include unblinded informationabout an expiry date in the signature of the coin.

system setup The central bank generates the following parameters:

• q, a group size

• G1 and G2, cyclic groups of order q

• s ∈ Zq, the central bank’s secret

• P ∈ G1, a generator

• Ppub = s · P, the central bank’s public key

• e : G1 ·G1 → G2, an admissable map

• Cryptographic hash functions H0 : {0, 1}∗ → G1 and H1 : {0, 1}∗ →Z∗q

The judge computes chooses a secret sjudge and computes and pub-lishes public keys Pjudge = sjudge · P and P′judge = s−1

judge · P.

Any bank interested in offering services submits and identifying stringIDbankto the central bank. The central bank then computes a pub-lic/private key pair 〈Pbank, Sbank〉 for the bank.

account setup A client wishing to use the bank’s services generates asecret u1 ∈ Zq and computes Iu = u1 · P1, where IU + P2 6= 0. Thebank receives IU and associates it with this client.

2 See section 4.7

45

withdrawal In the withdrawal phase, the user obtains a partially blindedsignature from the bank, and provides the bank with information thatallows it to detect double spending.

User Bankα←R Z∗qA1 ← P2 + α−1(IU + P3)A2 ← αP′judgeV1 ← Signα(in f o)

A1, A2, V1−−−−−−−→Check V1

W ←R G1a′ = e(P, W)

b′ = e(A1, W)z′ = e(A1, SIDB)

a′, b′, z′←−−−−−x1, x2, u, v←R Z∗qA← αA1A′ ← e(A, QI DB)z← z′α

a← a′ugv

b← b′uα A′v

B←= x1P1 + x2P2c = H1(in f o, A, B, z, a, b)c′ ← c/u mod q

c′−→S′ ←W + c′SIDB H1(in f o)

S′←−Check e(P, S′) = a′hc′H1(in f o)

Check e(A1, S′) = b′z′c′H1(in f o)

S← uS′ + vQIDB

payment During payment, the payer creates transaction information andauxiliary information for payment tracing by judge, and signs thisinformation.

Payer PayeeE2 = αPjudgeV2 = Sigpayer(payment)

payment, A, B, E2−−−−−−−−−−−−→IDB〈z, a, b, S〉, V2−−−−−−−−−−−−→

Validate σ(A, B, payment)Validate V2

Confirmation←−−−−−−−−−

46

deposit

Payee Bankin f o, A, B, E2, σ(A, B, in f o), payment, r1, r2−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

Validate σ(A, B, in f o)Detect if A has

been spent beforeCredit payee’s account

Double-spending can be detected by the reception of two tuples ofvalues 〈r2, d〉 and 〈r′2, d′〉 from which u1 ≡ r′2 − r2/d− d′ mod q can becomputed. The owner of a certain coin can be revealed by having thejudge calculate IU = A− P3− x−1

judgeE2 after having been supplied with〈A, E2〉 by the bank. The coins in possession of a certain user can beby the judge by computing xjudge A2 = αP2. The bank can then findA = IU − xjudgeP2 + P3, yielding the identities of the coin.

6.4 divisible coins

Fiat cash has the property of divisiblity. A banknote of e10 is divisiblein two notes of e5, 10 e1 coins or 5 e1 coins and 25 e0.20 coins. Wenoted in section ?? that we assume a single coin corresponding to a singlemonetary value. This significantly simplifies payment protocols; havingmultiple denominations would require a different signature on behalf of thebank in most payment systems.

A different approach is taken in the payment system by Okamoto [94].They propose to structure coin information like binary trees. A coin worth2l−1 cents is represented by a binary tree of l levels. A coin representedby a node at level 2l−2 is worth half of the value of the top node, and soon. In general the monetary value of a coin is 2l−1−n for levels 0 ≤ n <l. Using a certain coin represented by a node disallows spending of itschildren. Furthermore, that node cannot be used in a different payment. Aprotocol is proposed in which this tree information is exchanged, and thusdivisibility of coins is achieved.

Further systems that employ coin divisibility are, among others, the pro-posals by Nakanishi and Sugiyama [89] and Au et al. [5]. These protocolsimprove upon performance and anonymity features of Okamoto’s proposal.

6.5 transferable coins

The payment protocols discussed so far resemble fiat cash. Similarly, bankclients withdraw money from their banks, spend it freely without involve-ment of any party, and deposit this money some time later. The metaphoris not complete however; in none of the protocols discussed so far it is arequirement for payees to deposit their money and they cannot respend it.This limits the offline character of the system; receiving money from some-one does not enable a user to do something with it on its own. As notedin section 2, these systems do not posses the transferability property. Thissection introduces some systems that do possess this property.

Introducing transferability presents changes to mechanisms for coin trac-ing and double spending. Coin tracing has so far depended on informationexchanged during withdrawal, for example, using the ”revocation parame-ter” d in Camenisch et al.’s fair blind signatures. Since the association with

47

a withdrawal, payees can no longer be traced if they respend the money.Double spending is an inherent feature of transferable payment systems; asingle coin can be spent multiple times. Moreover, if a coin being spent endsup again at a payee who has spent the coin before, the coin can legally bespent again by the same person. Double spending is a large concern when itcomes to transferability because digital coins can be spent inifinitely. Sincethe bank can only detect double spending once coins are deposited, andcoin deposition can be delayed indefinitely in transferable payment systems,fraud detection can be delayed indefinitely by malicious users. This makes itpossible for many users in the system to spend coins many times beforedetection, breaking the system [117].

A set of modifications to existing payment models was introduced byFuchsbauer et al. [46] to add fairness and double spending detection in apayment system. This is done by record-keeping among payers in the sys-tem; they all store receipts for payments that allow clients to disprove theirinvolvement in illegal actions. Further research in this area is mainly fo-cused on improving efficiency and anonymity of users in a payment system.Work towards improving transferable payment systems has been done byBlazy et al. [16] and Canard et al. [27]. Additional research has not solvedthe double spending problems of transferable payment systems, however.

48

7

E X I S T I N G E L E C T R O N I C M O N E Y S Y S T E M S

In this chapter we present a comparison of some existing payment initiativesthat are widely used already. Although none of these mirror the protocolsdiscussed in the previous chapters, they are described here as a point ofcomparison and background for the protocols presented later in this thesis.

7.1 emv

The EMV protocol is a protocol specified by a collaboration of Europay, Mas-tercard and Visa. It was the first major initiative of implementing a commonstandard in debit card payment. Currently, EMV is the dominant standardin most parts of the world to handle electronic payment transactions forbanks [87].

As noted by other authors, EMV is not necessarily a single ’protocol’ inthe classical sense. Instead, the EMV standard allows for many deviations ofthe protocol and propietary extensions. Configurations of EMV often differacross companies or countries, and may possess proprietary extensions notdefined in the standard. The term ’protocol’ is usually taken to define com-mon functionality and interoperability, but this is not necessarily the case inEMV. Instead, EMV has been called a protocol toolkit, a set of componentsof which one can build a payment protocol [106].

The core of EMV can be summarized as follows. A banking card is in-serted to a service station. First, there is card authorization, the process inwhich the card signals the service point that it is a card authorized by thebank to perform payments. Next, there is an authentication phase, in whichthe debit card holder authenticates him or herself by inputting a debit card.Next, a payment is registered by the generation of an unforgeable message.The service point processes this in a backend that is not part of the EMVspecification.

The EMV specification provides standards to implement the followingconcepts [42, 106]:

card authorization This describes how a debit card can prove that abank has authorized the card to perform payments. There are threeways specified by EMV to accomplish this, in order of number of secu-rity features provided. In the first method, named Static Data Authenti-cation or SDA, relies on symmetric cryptography. The card shows thatit can encrypt a challenge presented by a service station. Since the keyis contained unprotected with the data on the card, this authenticationmeasure provides integrity but does not limit cloning in any way.

Dynamic Data Authentication (DDA) authenticates the card using a pub-lic/private keypair of which the private key is protected on the card.By proving possession of the private key by signing a challenge, thecard is authenticated. This mechanism is extended in the Combined

49

Data Authentication (CDA) which signs every message of the card in-stead of just the authorization phase, preventing man-in-the-middleattack on malicious service points.

cardholder authentication A card holder authenticates him or her-self by showing knowledge of a personal information number (PIN).The holder is usually asked by the service terminal to enter this num-ber. There are online and offline modes, in which the validity of the PINis cross verified with the bank and the offline version only verifies thePIN with the card. It is also optional to encrypt the PIN in transaction.

Cardholder authentication is subject to many different configurations.EMV specifies a negotiation of supported options by both the debitcard and the service point.

transaction commitment A commitment to a money transfer is gen-erated in the transaction commitment, which authorizes banks to trans-fer money from the payer to the payee’s bank account. Generating atransaction constitutes the generation of a message, a so-called cryp-togram, in which transaction information in contained. By signing thismessage with a digital signature, the integrity of this message is guar-anteed, and furthermore the cardholder cannot deny the creation ofthis cryptogram.

This cryptogram can be stored offline on the service point. Thesecryptograms are then sent to a backend service which delivers themessage to the service provider’s bank, which in turn can validate thecryptogram and process the transaction.

Although it is possible to create a secure system using the EMV system,legacy options push systems to support unsafe configurations. Systems thatdo not use the CDA authentication scheme are subject to attacks using mod-ified service points which can skim card data or manipulate the communi-cation between the debit card. Furthermore, the PIN number and other datacan be read out if a configuration is chosen that does not encrypt these datafields.

The configuration as used in Dutch debit cards has been investigated [106].Despite the lack of public knowledge on implementation choices done byDutch banks, under some assumptions made by some researchers, the EMVprotocol is still vulnerable to some attacks. By using ProVerif to formallyverify the security properties of the protocol used on the Dutch market, theyfound the issues of the use of cloned cards in SDA mode, fake transactionsin DDA offline mode and the ability to fool a terminal into thinking the PINwas entered correctly.

All of these attacks were known at the time of said research. The firsttwo are a result of legacy weaknesses in the EMV specification. The thirdattack is described in seperate research focussed on UK implementations ofEMV [87]. It is possible to circumvent the PIN check by using a man-in-the-middle-attack to modify the communication with the embedded smartcard.This man-in-the-middle attack can convince the smartcard that no PIN isasked (which is optional and still omitted in unsafe service point configura-tions) and can convince the service point that the PIN was entered correctly.This is possible because the smartcard has full responsibility of doing thePIN check, even in offline payments. This is because in none-CDA environ-ments the PIN exchange is not signed and therefore can be modified by aman-in-the-middle device.

50

The EMV protocol toolkit provides a diverse range of possible configura-tions each with his own problems. Because most EMV transactions happenin controlled environments where the physical security of controlled devicesand the smartcard contact point migitate tampering with the connection. Inthe next section we will focus on wireless applications of EMV.

7.2 wireless emv applications

EMV has been extended to be implemented in wireless smartcards, com-monly referred to as NFC chips. The ”Contactless Specifications for Pay-ments” specify how EMV can be used in a wireless setting [43]. It is a hard-ware specification, and not a modification of the protocol. Deployments ofthis standard have been underway in the United Kingdom and the Nether-lands.

The propietary PayPass protocol is an implementation and extension ofContactless EMV by MasterCard. It is currently used by Google Wallet andseveral other services. Little research has been spent on this protocol; weare not aware of any publications discussing the wireless varieties of theEMV protocol in particular. There is some indication that eavesdropping ispossible on some wireless EMV applications, however [76].

7.3 proton

Another way to perform payments using smartcard equipped bank cardsis by charging money on them instead of commiting a payment pledge tobe transferred to the bank. Whereas in EMV cryptograms represented anapproval of bank transfer between two bank accounts, in this prepaid sce-nario the cryptograms represent actual money, to be redeemed by the bankdirectly instead of a bank account.

One example of such a protocol is one originally conceived by the Belgiancompany Proton. Its system was subsequently introduced in the Nether-lands, Germany and many other European countries under a variety ofmarketing names. In the Netherlands, it was marketed as ’Chipknip’ andissued by several major banks.

Proton may be considered an implementation of e-cash, but it lacks thecryptographic sophistication of the protocols discussed in the previous sec-tions. Instead of an elaborate public-key infrastructure, its security is de-rived from a combination of hardware security and symmetric key encryp-tion; it has been described as showing strong signs of compromise becauseof cost reduction [116]. The public documentation and analysis of Proton ismostly absent. What is known is that because of reliance on hardware secu-rity, all that is necessary for a Proton card is authentication as valid. Thereare no protections against tampering and double spending, as the smartcardis trusted.

7.4 cryptocurrencies

An entire different way to implement electronic money is through the useof cryptocurrencies. Whereas each of the previously discussed methodsrequires the backing of a financial service provider as a trusted party, theaim of cryptocurrencies is to build a system in which no single party hasauthority over which payment is valid and which is not. This is different

51

from the model as discussed in section ??, and will only be discussed in thissection.

As of 2014, examples of cryptocurrencies include Bitcoin, Litecoin andPrimecoin. Each cryptocurrency conceptually works in the same manner.All of them may be considered a derivative of the original Bitcoin examplewith variations on some system parameters and use of one-way function.

Conceptually, the payment system in cryptocurrencies is backed by a pub-licly available, shared list of all transactions in the system. This large chainof transactions is named the blockchain. For a payment to be committedto the blockchain, it is processed by miners to verify its validity. In returnfor supplying their processing power, miners are rewarded with some ever-decreasing amount of cryptocurrency in return. Each payment validationis associated with a proof-of-work, some result of a computation using a one-way function that is difficult to compute but easy to verify. Most often, apartial collision of a cryptographic hash function is used - such as the SHA-256 hash function in the case of Bitcoin, or the scrypt hash function in thecase of Litecoin. The blockchain is ’refreshed’ periodically (10 minutes inthe case of Bitcoin), to which payments can be submitted by everyone whois synchronized with it.

Cryptocurrencies are designed to minimize the required trusted comput-ing base (TCB) by not assigning a fixed trusted third party in the protocol.In EMV and any Chaum-derived [36] payment protocol discussed in thispaper, this trusted third party (or even fourth party) is required to processany payment [88]. The side-effects of these design choices are the following.

• It is impossible to meaningfully make an offline version of this pro-tocol, as a payer needs to periodically synchronize with the publicnetwork to be able to make and receive payments.

• The network requires an incentive for participation of the public - thisis done by rewarding Bitcoins to those who process payment trans-actions. It is not practical to create digital cash backed by physicalgoods this way, as it is impractical to deliver physical goods to eachparticipating in a distributed network of payment verifiers.

• Several attacks [88, 7, 66] are a possibility on cryptocurrencies due tothe nature of proof-of-work and blockchain synchronization mecha-nisms.

52

Part II

E X P E R I M E N T

8P R O T O C O L D E S I G N

In this chapter, we present the design of three protocols that implement apeer-to-peer payment protocol with an offline payer and an optional offlinepayee. These protocols have been explicitly designed for an applicationin mobile devices. We will first take a look at the rationale behind whatfeatures we have considered for these protocols, based on the material wehave discussed in the first part of this thesis.

8.1 protocol features

Multiple banks

One step to increase practicality is to introduce support for multiple banks.Multiple banks are needed to create network effect, and make a paymentsystem more practically attractive. The limitation of one group of bankingclients to perform payments with each other is not likely to be compellingfor potential users.

A naive way to introduce support for multiple banks is to simple makebank clients aware of the public keys of different banks. Any client can thenrecognize the signature on coins generated by other banks, and accept those.Receiving banks agree on coin denominations as well as share a databaseof spent coins for double spending detection. This poses scalability prob-lems in both payment processing as well as key distribution. Importantlycross-compatibility is not guaranteed as different banks may predistributedifferent sets of public keys, creating incompatibilities.

A more unified approach would be to have coins signed by group sig-natures. This would have every bank become part of a group, similar toLysyanskaya and Ramzan’s protocol. Then there would be no or neglig-ble distinction between coins, and would require only knowledge of thegroup’s public key. It would require a group manager, which could poten-tially be done using secret sharing or be accomplished by a central bank. Itshould be noted that group signatures are potentially less performant thanmore conventional digital signatures.

The key difference between a singular bank protocol and a multiple bankprotocol is that the bank can no longer reasonably be considered a fullytrusted third party. Adoption of a multiple bank protocol therefore morestrongly implies adoption of untraceability.

Untraceability

Untraceability is a feature that increases privacy at a tradeoff of complexity.Fair blind signatures, extensively discussed in sections 4.6 and 4.7, are usedto this end to provide conditional untraceability to clients.

55

There are two potential downsides to introducing fair blind signatures.Protocol complexity increases substantially when blinding schemes are em-ployed: during withdrawal blinding and cryptographically encoding infor-mation for the judge become the main operation bottlenecks, and duringpayment the payer must generate (and the payee must verify) informationto enable identity revelation if the money is doubly spent. The large amountof cryptographic operations necessary for this is possibly prohibitive for mo-bile payments. Secondly, finding a party that can serve as the trusted judgemight be a problem in practice.

Double spending

The double spending problem is not fully solved in literature. It is in factunsolveable; if a string of bits as a coin in one payment, an identical copyof this string of bits is valid in another. There is no way to discriminatebetween two identical copies of bit strings unless a third party can confirmthis string of bits has been observed before1.

This renders double spending detection futile from the perspective of asystem’s designer. Indeed, double spending detection enables the bank toidentify the double spender after the fact. But this is not particularly advan-tageous as double spending will always victimize at least one person. Underthe assumption that at least one victim is willing to cooperate in identifyinga double spender, and the assumption that payments can be deanonymized,there is no tangible advantage in identifying a double spender by crypto-graphic means. Assuming victims are willing to cooperate in identifyingthe original source, and assuming the protocol allows coins to be traced tooriginal withdrawers (as is the case in non-blinded or fairly blinded sys-tems), cryptographic effort put into identifying double spenders presents asuperfluous complication.

Considering the receiving of offline payments and double spending, wecan see that a payee has no way to determine whether a coin is doubly spentor not. Therefore, if a payee receives a coin with no access to the internet,the payee must trust the payer to not double spend the coin. During thedesign of these protocols we assume that this trust is not the default mode.In the realities of real-world payment, trust in the payer’s good intentions isoften not considered and often not warranted. Under this assumption, wecannot design a payment protocol with after the matter double spendingdetection1. Note that we do not claim that offline payments are not possible- but offline payments can only fully happen when there is mutual trust be-tween the payer and the payee.

In the next few sections, we will outline a protocol design according tothe above considerations. We will begin with describing a protocol thatserves as the basis for further protocols. It will have no untraceability andno multiple banks. We then extend this first protocol with the propertiespreviously discussed.

1 The analogy of a payment protocol and fiat money breaks down here because of a differencein the characteristics of coins between the two systems. A coin (or banknote) in fiat money isdesigned to be hard to copy; it is from this that it achieves its authenticity as only the mint isassumed to be capable of creating a coin with the appropriate characteristics. A coin in a digitalpayment system as described is copyable by necessity; if it was not copyable digital hardwareand software could not operate on it. The consequence of all of this is that a payee can knowthat a received fiat coin is not double spent as much as the payee knows it is authentic, whereasa payee in a digital setting can only know it is authentic but not if it has been spent before.

56

Attribute PurposeCoin identifier Proof of bank signature; double spending detection by bankWithdrawer public key Coin tieing to public key; stealing migitationBank signature Authorization of coin by bank

Table 4: Explanation of the attributes on a coin in the essential protocol

As the protocols mentioned in the previous chapters, the protocols con-sist of a set of components containing at least a setup routine for the bankand subprotocols for withdrawals, deposits, and payments. We make anassertion that subprotocols that do not occur among payers are secure chan-nels providing confidentiality. This is based on the assumption that thesesubprotocols will be run on conventional TCP/IP based networks for whichpreviously mentioned existing methods can be used to set up such a secureconnection, such as Transport Layer Security with certificate pinning. Wedo not make any assumption about a certain network technology to be usedfor the communication among payers an payees, and therefore we do notassume a secure channel.

8.2 the essential protocol

The first protocol is one we shall name P2PPay-Essential (or Essential inshort); named so because it provides all essential features for a paymentsystem to be consistent as defined in chapter 2. In addition, this protocolalso provides confidentiality because of a simple implementation of a TLS-like secure channel over the communication channel.

In the essential protocol, payers and payees exchange coins that contain acoin identifier signed by the bank. In addition, the coins are tied to a clientby having the bank also include the client’s public key in the signature. Therationale for this is that in addition to the bank’s signature, a payee can alsoverify the public key is present on the coin during payment. In the eventof payment with stolen coins, a thief is unable to make a payment unlessthe thief has also stolen the associated private key. In the mobile context, itis more reasonable to assume that a private key can be secured from theftthan other data. We will detail such mechanisms later.

The component protocols therefore exist to pass around these coins amongbank, payer and payee.

Protocol 5. Essential setup phaseThe bank chooses an additive group G of prime order q in which the discrete log-arithm problem is hard. From this group, the bank picks a generator P ∈ G.The bank furthermore chooses a digital signature scheme with generating functionSigkey(message). The bank generates a public-private key pair by choosing a secretb ∈R Zq and computing its public key B = b · P. Lastly, the bank defines a sym-metric encryption/decryption function #{x}k with key length l and a hash functionH : G → {0, 1}l that maps group elements onto strings of that length. The bankdistributes functions Sig, #,H, the parameters G, q, P and its public key B in amobile application.

Protocol 6. Essential subscription phaseThe client generates a public private key pair by selecting u ∈R Zq randomly andcomputing U = u · P. The client sends this public key to the bank, proves possession

57

of a private key in a challenge-response protocol, after which the bank opens up anaccount for the client. The bank replies with an account identifier for the client.

Client Bank〈G, q, P, Sig〉〈G, q, P, b, B, Sig〉u ∈R Zq; U = u · P

U−→Choose r ∈ Z

r←−Generate s = Sigu(r)

s−→Verify s

Choose account idChoose validity period τ

Compute certU = Sigb(U‖τ)account id,τ,certU←−−−−−−−−−

〈G, q, P, u, U, certU , Sig〉

Protocol 7. Essential withdrawal protocolThe client authenticates to the bank using a challenge-response protocol, and pro-ceeds to request an amount of n coins from the bank. The bank responds withthe coins if authentication and challenge succeed; the bank credits the client’s bankaccount with the corresponding amount.

Client Bank〈G, q, P, u, U, Sig, n〉〈G, q, P, b, B, Sig〉

Withdrawal request−−−−−−−−−−→r ∈R Z

r←−a = Sigu(account id‖r‖n)

n,account id,a−−−−−−−→Fetch associated U

Verify a with UCheck client’s funds

Generate {c0, . . . , cn−1} byci = 〈ci#, U, sig〉 where

ci# ∈R Z

sig = Sigx(ci#‖U)Debit client’s account

c0,...,cn−1←−−−−−Verifies and stores c0, . . . , cn−1

Protocol 8. Essential deposit protocolThe client authenticates to the bank using a challenge-response protocol. and pro-ceeds to upload a set of coins to the bank. The bank checks the coins for validity anddouble spending and responds with a signed receipt if successful.

58

Client Bank〈G, q, P, u, U, Sig, c0, . . . , cn−1〉〈G, q, P, b, B, Sig〉

Deposit request−−−−−−−→r ∈R Z

r←−a = Sigu(account id‖r‖c0‖ . . . ‖cn−1)

account id,r,c0,...,cn−1,a−−−−−−−−−−−−→fetch Uverify a

verify c0, . . . , cn−1generate s0, . . . , sn−1 with

si = Sigb(c#i)s0,...,sn−1←−−−−−

Protocol 9. Essential payment protocolA payer and payee with respective key pairs 〈x, X〉 and 〈y, Y〉 exchange payments.The first step in the protocol is to establish a mutual secret key for symmetric connec-tion encryption. After that, both parties authenticate mutually through challenge-response protocols and the transfer of coins is done. Upon receiving the coins, thepayee performs the deposit protocol and obtains a receipt from the bank. The payeethen forwards this receipt to the payer to confirm the payment was successful.

Client Bank〈G, q, P, x, X, certX , Sig, c0, . . . , cn−1〉〈G, q, P, y, Y, certY, Sig〉Choose k1 ∈R ZqCompute K1 = k1 · P

K1−→Choose α ∈R Z

Choose k2 ∈R ZqCompute K2 = k2 · P

K2,α←−−Compute k = H(k1 · K2) Compute k = H(k2 · K1)

Compare k←−−−−→Compute s = SigX(α)Choose β ∈R Z

#{s,β,certX}k−−−−−−−→Verify s

Compute s′ = SigY(β)#{s′ ,certY}k←−−−−−−

Verify s′

Generate γ ∈R Z#{γc0,...,cn−1}k−−−−−−−−→

Performs deposit protocolwith challenge γ

s0,...,sn−1←−−−−−

The comparison of the mutual secret K can happen out of band. Notethat this description assumes that the payee does not trust the payer, andperforms a deposit immediately. Although this should be the default as-sumption a payee makes, this deposit step can be omitted if and only if there

59

is mutual trust between payer and payee. Instead of performing the depositprotocol, the payee replies with its own signature on the challenge γ, whichthe payer stores to later prove the payment to bank.

The above description of the Essential protocol is a description of thecryptography of the protocol. It assumes verification of signatures andproofs-of-knowledges succeed, but these will not always succeed. To com-pletely show what states a client sees during the execution of the protocol,refer to figure 6.

The state diagram begins in an unsubscribed state; the client then at-tempts a subscription. If the subscription is successful, the client entersthe state in which it awaits commands. The user of a client applicationcan then invoke commands or await the initiation of a payment by anotherclient. When making a withdrawal, deposit or payment, or when receivinga payment, the client enters into states waiting for cryptographic informa-tion. When the verification of a signature, or knowledge of a private keyfails, the client returns to the awaiting command stage and does not per-form any further automated action. Upon the reception of a payment, theclient can choose to store the coins on his/her device or initiate a deposit ofthese coins, of which the latter should be the default behaviour.

8.3 the untraceable protocol

This protocol is named P2PPay-Untraceable (or Untraceable in short). Itis a modified version of the Essential protocol with changes in its with-drawal subprotocol. The withdrawal protocol is modified so that the clientclient instead generates coins and they are signed blindly by the bank. Dur-ing this withdrawal phase, an additional revocation parameter is generatedby the client that makes it possible for the bank to reveal the original theidentity of the client who originally withdrew the coin. The bank can onlyperform this identity revelation with the help of an additional party intro-duced called a judge, which acts as a trusted third party, as well as a routineby which the judge can reveal an identity from a revocation parameter.

Other protocol components in this protocol work equivalently to theirP2PPay-Essential counterparts, but are modified to facilitate passing aroundthe additional variables required for the new withdrawal protocol.

Protocol 10. Untraceable set-up phaseThe bank chooses an additive group G of prime order q. The bank selects threeelements from this group: P, P1, P2 ∈R G through a method that allows publicverification that the discrete logarithms these elements have with respect to oneanother is not known. The bank further chooses a private-public key pair withprivate key b ∈R Zq and public key B = b · P. Finally, the bank chooses a digitalsignature function using G called Sig and a cryptographically secure hash functionH.The judge performs setup by generating a public-private key pair based on the thirdchosen group element. He chooses a secret j ∈R Zq and computes a secret keyJ = j · P2, and finally publishes J.Finally, the bank publishes a mobile application containing G, q, P, P1, P2, B, Sigand J. Users of the application should be able to verify J on their own terms.

Protocol 11. Untraceable subscription protocolAs the essential subscription protocol, with G, q, P, Sig obtained from the setupphase.

60

Await subscription

Awaitingcommand

Await withdawal challenge

Await coins

Await deposit challenge

Await key exchange response

Await payer authentication

Await coinsAwait receipt Await payee authentication

Await receipt

Previously set up

Subscribe

Withdrawal Deposit Pay Receive paymentinitiation

Deposit success

Deposit failure

Withdrawal failure or invalid coins

Authentication success

Key exchange success

Subscription success

Subscription failure

Authentication successBank identity verified Bank identity verified

Invalid receipt or error

Valid receipt

Valid coins andimmediate deposit

Authentication failure

Invalid coins

Valid coins andno deposit

Key exchange failure

Authentication failure

Bank identification failure

Bank identification failure

Withdrawal success

Figure 6: The state diagram of the Essential protocol.Underlined transitions indicate a user-driven command.

61

The withdrawal protocol makes use of a two proof-of-knowledge con-structs, pklog and plogeq as described in section 4.7. Recall that the pklog

proves that the issuer knows the discrete logarithm of a pair 〈P, P′〉. Thepklog consists of the points P and P′ as well as numbers c and s com-puted from the discrete logarithm such that the proof can be verified us-ing c = H(P‖P′‖c · P + s · P′). Recall that the plogeq proof is an exten-sion of the pklog proof to prove knowledge that the same discrete log-arithm seperates two pairs of group elements 〈P, P′〉, 〈Q, Q′〉: a plogeq

consists of a tuple 〈P, P′, Q, Q′, c, s〉 such that the verification equation c =H(msg‖P‖P′‖Q‖Q′‖c · P + s · P′‖c · Q + s · Q′) holds for some known mes-sage msg.

The withdrawal protocol contains a multiparty computation of a plogeq

where the message contained is a concatenation of the coin identifier andthe client’s public key. During the computation, the bank does not learnthe coin identifier and The discrete logarithm for which the plogeq is gen-erated is the bank’s private key b. Coins exist as a tuple of a coin identi-fier, the withdrawer’s public key, a pklog that the withdrawer knows somewithdrawal parameters, the plogeq relative to the coin id concatenated tothe client’s public key. This combination proves the validity of the coin andits withdrawal, as well as provide information for coin tracing.

Protocol 12. Untraceable withdrawal protocolThe client obtains a set of n coins consisting of blindly generated proofs of validity

by the bank. Refer to figure 7 for the protocol’s outline.

It can be shown that the the proof Cb is a valid plogeq with respect to b.First observe that given elements A, b · A ∈ G, we can show that:

(r + γ) · A + δ · bA =

= (s′ + c′ · b + γ) · A + δ · bA

= (s′ + γ) · A + c′ · b · A + δ · bA

= (s′ + γ) · A + c′ · bA + δ · bA

= (s′ + γ) · A + (c′ + δ) · bA

= s · A + c · bA

Next, we can observe that as B = b · P we have:

G = G′ + γ · P + δ · B= r · P + γ · P + δ · B= (r + γ) · P + δ · B= s · P + c · B

and as V = b · Z we have:

H = α · H′ + γ ·V + δ · Z= α · r ·W + γ ·V + δ · Z= r ·V + γ ·V + δ · Z= (r + γ) ·V + δ · Z= s ·V + c · Z

Which shows that the values G and H included in the plogeq satisfy itsverification equations.

62

Client Bank〈G, q, P, P1, P2, J, u, U, Sig, n〉〈G, q, P, P1, P2, J, b, B, Sig〉

Withdrawal request−−−−−−−−−−→µ ∈R Z

µ←−a = Sigu(account id‖µ‖n)For i ∈ 0, . . . , n− 1compute Γi = 〈W, D,Pα〉 wherec# ∈R Z

α ∈R ZqW = α−1 · P1 + P2D = α · JWα = PLOGEQ(∅, P1, W − P2, D, J)

account id,a,Γ0,...,Γn−1−−−−−−−−−−−−→Fetch associated U

Verify a with UFor every received Γi

compute ∆i = 〈W ′, G′, H′〉 whereVerify and storeWα

Store DW ′ = b ·W

r ∈R ZqG′ = r · P

H′ = r ·W∆0,...,∆n−1←−−−−−−

For every ∆iγ, δ ∈R Zqcompute c′i = c− δ (mod q) whereV = α ·WZ = α ·W ′G = G′ + γ · P + δ · BH = α · H′ + γ ·V + δ · Zc = H(c#‖U‖P‖V‖B‖Z‖G‖H)

c′0,...,c′n−1−−−−−→s′i = ri − c′ib (mod q)

s′0,...,s′n−1←−−−−−For every s′i computecoini = 〈c#, V, Z, Cα, Cb〉 wheres = s′ + γ (mod q)Create Cα = PKLOG(P2, V − P1)Make Cb = 〈c#, P, B, V, Z, c, s〉(= PLOGEQ(c#, P, B, V, Z))

Figure 7: The untraceable withdrawal protocol

63

Protocol 13. Untraceable deposit protocolAs the deposit protocol in P2PPay-Essential, but with the bank’s coin verificationconsisting of checking the validity of the proofs Cα and Cb with respect to the bank’spublic key.

Protocol 14. Untraceable payment protocolAs the payment protocol in P2PPay-Essential, but with the payee’s coin verifica-tion consisting of checking the validity of the proofs Cα and Cb with respect to thebank’s public key.

The judge has not been involved in any of the protocols above, but in thewithdrawal protocol the client has generated information that allows thebank to selectively reveal the identity of users. It can do so in two differentways.

The first is by using the stored revocation parameter D. Using the judge’sprivate key j the judge can compute the V value associated with each coinby the equation

P1 + j−1 · D = P1 + α · P2 = V

This method allows the bank to put the found V values on a blacklist tocheck against for deposits.

The second is by finding the revocation parameter associated with a cer-tain V value observed in a deposit.

j · (V − P1) = α · j · P2 = D

Since the revocation parameter is associated with a client, this allows thebank to find the client associated with a payment.

Protocol 15. Judge coin tracing - transaction blacklistingThe bank submits a withdrawal associated value D to the judge. The judge replieswith the computed value V = P1 + j−1 · D, and the bank blacklists coins with thevalue V.

Protocol 16. Judge coin tracing - revealing identityThe bank submits a coin associated value V to the judge. The judge replies with thecomputed value D = j · (V − P1), and the bank finds the user associated with thisparameter D stored in its revocation parameter database.

8.4 the multibank protocol

A limitation of the previous two protocols is the fact that payees were depen-dent on having a knowledge about the banks’ keys that proved the validityof the coins. This is untenable in scenario in which multiple parties want toprovide payment services in a mutually compatible system. In this section,we will investigate ways in which this limitation may be removed.

8.4.1 Possible solution 1: key predistribution

There is a trivial way to remove such the limitation of knowing just onepublic key; predistributing more public keys . The public keys of all banksin the system may be predistributed in the mobile bank application: notonly is the bank’s own public key distributed with the application, so arethe public keys of all other banks participating in the system. Coins canthen be validated by including a small value identifying which public keyshould be chosen to verify coins.

64

We call this protocol P2PPay-Multi-Predistrib or Predistrib for short.The protocol is exactly the same as the Untraceable protocol except thatthe client’s application additionaly is distributed with N public keys B1, B2, . . . , BNof the N other banks that are participants to the system. Every partici-pating bank in the system is also aware of each other’s public key, andthere exist no pair of banks i, j for which either bank knows logBi

Bj. Afurther modification is made to the format of the coins. A coin is now a tu-ple 〈c#, V, Z, Cα, Cbk

, k〉 with an additional identifier k indicating to verifierswhich public key must be used to validate the coin.

An additional modification must be made in the detection of doublespending. To prevent double spending of a single coin at two differentbanks, banks must upload which coins have been spent to a shared database.This database may be made public without loss of privacy.

8.4.2 Possible solution 2: group signatures

A cryptographic construct exists to solve the problem of having a group signmessages uniformly so that they can be universally verified. They are groupsignatures, and are discussed in section 4.8.

If group signatures are adopted to address the problem of universal coinverification, a new party called the group owner would be required. Thegroup owner would generate a group signature scheme Gsig(x) and dis-tribute group keys among participating banks. The banks would sign coinsusing signatures in a similar fashion as the Essential protocol employedregular signatures.

8.4.3 Possible solution 3: bank certificates

Key distribution can be solved in the same way it was solved for payer-payeeauthentication - through the distribution of certificates. These certificates arenow called bank certificates as they prove that the bank is allowed to engagein money withdrawals. Certificates are distributed from a central authorityto the banks, which in turn distribute them to clients. This distribution ofcertificates allows the coin issuing to be done by a very small set of authori-ties, or perhaps just one.

We propose a new trusted third party - the coin authority. This partypossesses a private key t and a public key T. Using the private key t andthe system’s signature scheme Sig the coin authority issues certificates tobanks which distributes them further to clients. A certificate is a valuecertB = 〈B, τ, Sigt(B‖τ)〉 issued to a bank with public key B for a validityperiod τ. It signifies that coins spent which have signature on them verifiablewith public key B are valid coins when they are validated during the validityperiod τ on the certificate.

The bank distributes its application with the coin authority’s public key C,the certificate certB, set of revoked certificates and a means for their clients toverify the validity of C. During payment, the payer may present its bank’sbank certificate to the payee. The certificate will provide the payee withboth the public key with which the coins in the payment may be verified,as well as demonstrating the bank’s capability for signing these coins. Apayee validates the certificate with the predistributed public key T, andrejects if the presented certificate is in its revocation set, the validity of thecertificate has expired or if the signature on the certificate fails. The payeesubsequently validates the coins with the included public key.

65

The above modifications are made to the Untraceable protocol to pro-duce the P2PPay-Multi-Cert protocol. The responsibilities of the systemsetup are moved from the bank to the certificate authority. We introduce anew phase - the bank setup phase, in which the bank sets up its own param-eters and performs app distribution. There are also minor changes to thepayment protocol to facilitate the transfer of the bank’s certificate.

Protocol 17. Multicert authority setup phaseThe coin authority chooses an additive group G of prime order q in which the discretelogarithm problem is hard. From this group, the coin authority picks a generatorP ∈ G. The bank furthermore chooses a digital signature scheme with generatingfunction Sigkey(message). The coin authority generates a public-private key pairby choosing a secret t ∈R Zq and computing its public key T = t · P. The coinauthority publishes G, P, Sig and T.

In the case of multiple coin authorities, they mutually agree to G, P, and Sig andeach authority publishes its own public key T.

Protocol 18. Multicert bank setup protocolThe bank chooses a coin authority to authorize itself with, and obtains G, P, Sigand T. The bank computes private key b ∈R Zq and computes public key B = b · Pobtains a certificate certB = 〈B, τ, Sigt(B‖τ)〉 from the coin authority.

The bank distributes the parameters G, q, P, B, T and certB in a mobile appli-cation. Optionally, it also includes an additional set of other certificate authorities{T1, T2, . . .} so that clients may receive coins from the coin authorities associatedwith those public keys, and a set of revoked certificates { ˜cert1, ˜cert2, . . .} that shouldnot be accepted.

Protocol 19. Multicert payment protocolAs the Untraceable payment protocol, with the addition that the payer sends thepayee its banks certificate during the protocol after a secure channel has been set up.The payee then uses the public key included in the certificate as the bank’s publickey for the remainder of the payment.

All other protocols are identical to their respective Untraceable counter-parts, except that coin verification is accompanied by checking the validityof the presented certificate.

8.4.4 Comparison and discussion

Since the multi-predistrib scheme requires predistribution of keys, it comeswith several disadvantages. Such predistribution of public keys yields aninherently static payment system. It requires broad agreement between theseveral participating banks to agree who participates in the system. Afterall, each bank decides which list of public banks itself and the applicationuse for coin verification and the individual banks may differ in which listof public keys they keep. Furthermore, such a payment system itself is notstatic: participating banks may join or leave and keys may need replace-ment because of keys become compromized or vulnerable in the light ad-vancements in cryptanalysis and computational power. Such changes in thesystem require regular maintenance by all participating banks.

The staticness of such a system might not be problematic. Dependingon the scale at which such an application is distributed the requirementof agreement and mutual maintenance might be achievable. For example,one can consider the Dutch banking market in which the number of banks

66

operating is small, and the market is regulated to such a degree that mutualagreement on which banks exist within the market is easily achievable.

Group signatures were considered for this second version, but provedproblematic as an extension of the previous singatures. Group signaturessuch as Boneh et al.’s scheme have a private key that is not merely an in-teger, but is a proof that a group member knows a limited amount of in-formation on the group’s master key. Since the method to generate fairblind signatures presented in the previous section is dependent on the in-teger property of the bank’s secret key, the zero-knowledge proofs in theUntraceable protocol cannot be used in this new signature scheme. A de-scription of fair blind group signatures is presented by [? ]; we howeverargue that this scheme is not efficient for mobile use. First, this is because? ’s scheme requires additional roundtrips of the coins during the paymentprocess, which will be a strain on whatever communication method is em-ployed. Second, their scheme requires a large amount of group operationsand modular arithmetic to happen during both withdrawal and payment.Third, we will show later that other group signature schemes do not per-form well enough on mobile phones to be used in such a scheme. Wewill therefore not present a group signature based variety of our paymentscheme.

Some characteristics of group signatures are difficult to apply to paymentsystem in the mobile context. In particular, signer anonymity is often con-sidered an advantage of group signatures. A coin signed with a groupsignature would be untraceable back to the issuing bank without help ofthe group master. We argue that this is in fact a disadvantage in the contextof our mobile payment application: anonymity in between payer and payeeis not a design goal of our system. Indeed, mobile payments discussed sofar happen face-to-face and are mutually authenticated out of band. We con-tend that knowing which bank signed the coins received in a payment bythe payee would strengthen the payee’s trust in a succesful payment, at nosignificant cost of privacy of the payer. Furthermore, the indistinguishabilityof group signatures makes handling of revocation more difficult, althoughverifier-local signature verification is shown to be solvable in principle [].

We believe that the Multicert variety of this protocol provides a goodcompromise between group signatures and the predistributed key. The scal-ability problems that exist with predistribution are migitated by a broaderand less challengeable agreement of a smaller set of coin authorities. Orga-nizations with responsibilities similar to the coin authority currently exist inthe form of national and supranational mints and central banks which arecurrently already responsible and trusted for managing currencies. The pro-jected advantages this system has over group signatures are lower projectedcomputational requirements, lower communication overhead, and lack ofsigner anonymity.

8.4.5 Distribution of trust: sharing judge responsibilities

In the process of going from the Essential protocol to the Multicert pro-tocol, we have introduced two additional trusted parties - the coin authorityand the judge. In the previous section we have already argued that the coinauthority is a role that can be assumed by existing parties. The same doesnot hold for judges; money tracing is currently accomplished by a widevariety of methods wholly dependent on the employed payment method.We are not aware of an existing deployed payment method where a similar

67

anonymity revoker is held by a seperate organization. The problem of find-ing a party suitable for anonymity revoking becomes enlarged because theparty must be trusted by both the client (to protect the user’s anonymity)and the banks (to cooperate in the case anonymity revocation is ).

We argue that this trust problem can be improved by distributing thepower to revoke anonymity among multiple parties using secret sharing. Thesharing of this secrecy guarantees that the cooporation of multiple partiesis necessary to revoke anonymity. As an example scenario, the secret maybe shared among the national bank, the bank itself and a court with juris-diction on anonymity revocation, and each parties part in the computationof the anonymity revocation would mean their approval of the revocation.In this scenario, the compromise of several parties is necessary to performanonymity revocation which is less likely to happen than a single responsi-ble party.

In this section we present a method for multiple parties to partially computea piece in the anonymity revocation. Observe that in the Untraceable andsubsequent protocols, anonymity revocation is possible because a coin with-drawer associates a revocation parameter D with a withdrawal with his/heridentity and associates a coin value V with his/her withdrawal. These as-sociations are encrypted by a judge public key J and can be decrypted witha secret key j and an inverse of that secret j−1. These secrets can be secretshared among multiple parties.

Any method for secret sharing may be used for this protocol. We usesecret sharing based on the general Chinese Remainder Theorem in thissection for mathematical and implementation simplicity. Recall that the Chi-nese Remainder theorem states that given a series of modular congruenceswith distinct pairwise coprime moduli m1, . . . , mk:

j ≡ j1 (mod m1)

j ≡ j2 (mod m2)

. . .

j ≡ jk (mod mk)

the value of j is given by the equality j = ∑ki=1 jiei where ei is a multiple

of m/mi that solves the equation ri · ji + ei = 1. Therefore, as long as ji and miare known for all 1 ≤ i ≤ k, the value j can be computed. If the componentsji are distributed along with the moduli mi among k parties, then those kparties together can recompute the value j.

We extend the P2PPay-Multi-Cert protocol to a protocol P2PPay-Shared

by modifying the judge setup phase in such a way that the judge distributesits private key among multiple parties by the Chinese remainder theorem.The parties among which the secret is shared will be named revokers. Allrevokers together can then use their shared secrets to perform partial com-putations using their shared secret key which can then be added togetherby the Chinese Remainder Theorem to result in a complete secret key oper-ation. The judge party is only part of the protocol during setup; all revokerscan cooporate on secret key operations during the protocol’s operation afterthe setup phase is completed.

68

Protocol 20. Shared judge setupThe system parameter is k, the amount of revokers among which revocation capabil-ity is shared. The judge selects and computes the following values:

• A secret j ∈R Zq and its inverse j′ ≡ j−1 (mod q)

• A set of moduli m1, m2, . . . , mk with the properties:

– They are uniformly selected from Zq

– Every pair mu, mv is coprime (gcd(mu, mv) = 1)

– Every element mu is smaller than j (mu < j)

– The product of the sequence is larger than j (m1 ·m2 · . . . ·mk > j)

• Another set m′1, m′2, . . . , m′k with the properties:

– They are uniformly selected from Zq

– Every pair m′u, mv is coprime (gcd(m′u, m′v) = 1)

– Every element m′u is smaller than j′ (m′u < j′)

– The product of the sequence is larger than j′ (m′1 ·m′2 · . . . ·m′k > j′)The sets can be selected by repeatedly selecting random small coprime sequences

from Zq until a set is produced of which the product is larger than respectively j orj′.

For every ith revoker in the protocol, the judge then computes that revokers secretshare in the following way:

1. Compute ji ≡ j (mod mi)

2. Solve Bezout’s identity r · mi + s · m/mi = 1 for some r, s ∈ Zq using theExtended Euclidean Algorithm. Let ei = s · m/mi.

3. Let εi = ji · ei

The judge also computes shared secret ε′i by running the above algorithm but sub-stituting j′ for j and m′i for mi. Every ith revoker obtains two shared secrets: εi andε′i .

The judge finally publishes the public key J = j · P and the products m =m1 · . . . ·mk and m′ = m′1 · . . . ·m′k. After this has been successfully completed, thejudge deletes its records and removes itself from the protocol.

Observe that by the Chinese Remainder Theorem, and since m > q, thedistributed values ji and the auxiliary values ei sum together to the secretkey:

j =k

∑i=1

ji · ei =k

∑i=1

εi

Likewise, the key inverse can be obtained by

j−1 = j′ =k

∑i=1

j′i · e′i =k

∑i=1

ε′i

.We will use this fact to share computations involving the judge secret keys

among the revokers in the following two protocols.

Protocol 21. Shared coin tracing - transaction blacklistingA bank needing to find a coin associated with a revocation parameter Dcomputesthe coin’s associated value V. The bank sends a request for a partial coin parameterVi to k revokers. Any ith complying revoker will provide the bank with a computedvalue Vi = ε′i · D. The bank then computes the sum V = P1 + V1 + . . . + Vk, anduses V to observe associated payments.

69

The fact that V identifies a coin associated with revocation paramater Dis shown by:

V = P1 +k

∑i=1

Vi

= P1 +k

∑i=1

ε′i · D

= P1 +

(k

∑i=1

j′i · e′i

)· D

= P1 + j−1 · D = P1 + α · P2

Which is what V was computed to be during withdrawal.

Protocol 22. Shared coin tracing - revealing identityA bank needing to trace the original withdrawer of a coin associated with value V byfinding the associated D value. The bank sends a request for partial the revocationparameter to k revokers in the system. Any ith complying revoker will providethe bank with a computed value Di = εi · (V − P1). The bank computes the sumD = D1 + . . . + Dk, and looks up which user is associated with a withdrawal D inits revocation parameter database.

The fact that D is the correct revocation parameter associated with V canbe seen from the following equality:

D =k

∑i=1

Di

=k

∑i=1

(εi · (V − P1))

=

(N

∑i=1

εi

)· (V − P1)

= j · (V − P1)

= α · j · P2 = α · J

Which is same value as D was originally computed in the withdrawal pro-tocol.

70

9

P R O T O T Y P E

To show the practicality of a mobile payment system, we developed a pro-totype mobile application that implemented a simple payment system. Ourgoals with developing this application were to show basic functionality ofa mobile wallet in which coins could be transferred by some peer-to-peermedium. The development of this prototype was hoped to provide lessonsin implementation issues, a consideration of the wireless medium to be used,and an investigation of the internal structure of such a program. As part ofthe prototype, we built three components:

1. A client console application

2. A client Android application

3. A server application that represents banking services

This chapter describes this prototype and what choices were technologychoices were made to develop it.

9.1 basic technology choices

When choosing a platform for our prototype, one must choose a mobiledevice platform for which to develop it. At the time of the developmentof this application, the three major operating systems on the market wereiOS, developed by Apple; Windows Phone, developed by Microsoft; andAndroid, developed by Google and various device vendors. We chose todevelop our application for the Android platform for several reasons.

First, it was anticipated that our prototype would make use of NFC func-tionality of mobile devices. Apple’s iOS did not run on devices with suchfunctionality at the time, and Apple’s platform did not (and does not at thetime of writing) support development of applications that support interac-tion with NFC hardware. Both Android and Windows Phone do supporthardware with NFC antennae and applications that make use of that hard-ware.

In the anticipation of running a benchmarks (described in chapter 10) us-ing code developed with the prototype, a popularity choice was made in theavailable diversity of available hardware. Not only is there a greater diver-sity in Android devices, allowing a more complete picture of performanceon different classes of mobile hardware, a large set of those devices wereavailable to us for our benchmark application. With this in consideration,the app was built for the Android platform.

Although Java is the programming language of choice for the Androidplatform, we chose to use the Scala programming language for our proto-type. The Scala language provides excellent integration with the Java systemthat Android provides, but is a more expressive language that was expected

71

to allow faster implementation. Moreover, it was thought that certain Scala-specific libraries would aid the development of the server component of ourprototype (with which code was shared) and a stateful network protocol.We will detail these libraries in the next section.

9.2 libraries

Our prototype application was built using the following libraries to providemany of the aspects required of a mobile wallet application.

bouncycastle This library1is widely used as a Java library for imple-menting cryptographic constructs including primitives, signature schemes,cryptographic hashes and ciphers both symmetric and assymetric. Thislibrary was used to provide the ECDSA signature scheme, which is notavailable from Android’s system libraries. It is also used for its SHA-implementations, and for its implementation of elliptic curves and itsarithmetic.

akka The Akka library2is a library that provides common functionality todevelop programs that follow the actor model. Briefly, the actor modelis a software abstraction to write concurrent programs in which stateis maintained in program units called actors that maintain their ownstate internally and only interact with other components by messagepassing. Although this is of primary interest in concurrent software,it also fits well with the conceptual model of actors that interact bycommunicating over a network protocol. The notions of state andmessage passing of actors are used to make the implementation of aconceptual network protocol more obvious in the code.

In addition to this support for a conceptual model, Akka also providedtools that support extending message passing over an IP-based net-work, additional tools to make actors function as finite state machines,and several concurrency features which were used in our prototype.

sbinary A network protocol implementation must exchange messages insome serialization format. We used the SBinary library to the map thedata representation of our protocol messages onto a custom format ofbinary data. Using the SBinary library, we were able to compress theinformation contained within protocol messages to a compact binaryformat.

android system library The native Android system library was usedfor drawing the application’s user interface, and to to use the plat-form’s Wi-Fi connectivity.

h2 database For persistent storage of data on the bank system, we em-ployed the H2 database management system3. H2 is an implementa-tion of an SQL-based relational database in pure Java, and as such isa popular choice among Java-compatible languages. This library waschosen because it allows storing a relational database in simple files,making it particularly suitable for fast prototyping.

1 http://bouncycastle.org/ - For technical reasons we will not detail here, to use BouncyCas-tle on the Android platform, one must use an alias named SpongyCastle which is identical inall purposes but name. We will continue to refer to this library as BouncyCastle nonetheless.

2 http://akka.io/

3 http://www.h2database.com/

72

http://bouncycastle.org/

http://akka.io/

http://www.h2database.com/

Figure 8: A confirmation screen was presented to the user upon each datatransmission

9.3 mobile connectivity

We investigated three popular ways to transmit data between mobile de-vices as a medium for our payment protocol. We will describe these andassociated conclusions in this section.

near-field communication Near-field communication on Android op-erates in two ways. There are two types of near-field communicationone can use when developing NFC applications for the operating sys-tem. The first is an API used to read smartcards from the device. Thesecond is a proper NFC peer-to-peer API. This API is often referredto with the name Android Beam, and is a message-oriented API usedfor quick, unidirectional transfer of information between devices. Theintended use case appears to be quick sharing of small bits of informa-tion, such as URLs, pictures and other small quantities of data.

The Android Beam API would appear as a good candidate to developan application for, but it does not translate well to a bidirectionalpayment protocol. For every message that is sent over NFC by thismethod, the user must confirm a dialog to send the message (seefigure 8). As described, payment interaction may take up to threeprotocol exchanges, making the required confirmations cumbersome.We implemented a partial solution to use the Android Beam for ourprototype, but it was quickly abandoned when we encountered theseusability problems.

The card emulation API would in fact suit a bidirectional protocol bet-ter; there are APIs for an Android to communicate with wireless smart-card, and since version 4.4, also methods by which an Android devicescan emulate such a smartcard. Such an implementation would requireadditional work to manage the abstraction of smartcards. It would

73

also need to oscillate between card-reading mode and card-emulationmode. We chose not to investigate these paths because the difficul-ties of implementing these card abstractions would still be disadvan-tageous when compared to the solution we found later.

bluetooth Android, as of version 4.4, only allows a device to initiate aconnection. It is not possible to receive a connection on an Androidphone - there is no way to register a listener for Bluetooth connectionevents in the system. This is part of a profile in the Bluetooth stan-dard named the Message Access Profile4. This means that Androiddevices cannot set up peer to peer connections in between them usingBluetooth.

We note that a APIs is for devices to accept Bluetooth connections areavailable on the iOS platform5. Bidirectional Bluetooth connectivity istherefore a problem of current Android phones, not of current smart-phones or the Bluetooth hardware these devices use, and is perhaps aviable medium for use in other projects.

wi-fi peer to peer connections It is possible to use a phone’s Wi-Fiantenna to initiate and receive connections. Various names are usedto describe this functionality in different contexts, but in Android theemployed term is Wi-Fi Direct6.

On Android, APIs are available which allows phones to discover ser-vices on one another using this local Wi-Fi connection and the Zero-conf protocol. Connection specifics are then determined when connec-tions are initiated; one device is a group owner signifying that it is thecentral hub in the connection - like a regular wireless access point itperforms DHCP and wireless security. One or more other devices canconnect to this group owner and set up a connection with this device.

Wi-Fi Direct has important advantages over the other presented tech-nologies. Firstly, the connection is the least restricted of all these meth-ods - it provides bidirectional communication and a large bandwidth.Secondly, it is the most widespread among current mobile devices- software support exists in most phones running iOS, Android andWindows Phone. Lastly, it uses the same network stack as non peer-to-peer connections, meaning that one can rely on the connection man-agement of TCP and IP.

Based on these analyses, it was chosen to develop a demonstration appli-cation built upon a Wi-Fi peer to peer connection. It was the only feasiblesolution for setting up a bidirectional connection. Moreover, we assert thateven without the practical difficulties of the other media used, Wi-Fi Di-rect presents the best option in general for our payment protocol given itsbandwidth and included connection management.

9.4 protocol implementation

In implementing the protocol, our goal was to make an implementation ofthe Essential protocol as described in chapter 8. In this chapter we detail

4 https://developer.bluetooth.org/TechnologyOverview/Pages/MAP.aspx5 http://support.apple.com/kb/ht3647

6 This type of connection is also named ”Wi-Fi P2P” or ”Multipeer Connectivity”, but these arenot terms given by the Wi-Fi Alliance

74

id amount signature

Figure 9: An example of the binary representation of a withdrawal requestmessage in the Essential protocol consisting of a single-byte mes-sage identifier; a four-byte withdrawal amount; and a 32-byte sig-nature

the implementation details of this protocol, but we will first describe someof our preliminary work in implementing the more expanded protocol.

Our first goal was to demonstrate that a payment protocol would workin principle. We therefore ignored our formal designs, and worked on ademo application that passed messages around ’akin’ to how coins wouldbe passed around in a payment protocol. This was a simplified protocol inwhich the client would still withdraw and deposit coins with the bank, andclients would still exchange coins. This protocol was not formally specifiednor was it secure by the definitions of chapter 2, however. We continued toadd features to this simple protocol in an ad-hoc fashion for it to resemblea real peer-to-peer payment protocol, such as digital signatures, paymentvalidation, and payer authentication. We will not detail this protocol in thisthesis.

Our protocol messages were represented in code as simple data containerstermed case classes and case objects in Scala7. All of these message data con-tainers are simple - they do not encapsulate others and are only composedfrom a small set of primitives, integer, character string and byte string types,or types that are easily transformed to such a primitive, such as coin rep-resentations and elliptic curve points. Case classes cannot be sent over theclient-bank and client-client network connections as-is; a method to serializeand deserialize these messages is necessary. We used the SBinary library toaccomplish just that; the data containers are serialized to a binary format.This is accomplished by assigning a small integer flag for each message typein the protocol. Then all of the primitive types of which the messages arecomposed of are serialized to byte data representing these primitives, andappended to the flag. Upon deserialization, the flag is read to determinewhich format must be deserialized, and the bytes corresponding to theirprimitives are read into the appropriate data fields. An example of a binaryrepresentation of a protocol message is given in figure 9. An overview of allthe message types that exist in the Essential protocol are found in table 5.

There are three advantages to such a custom binary protocol implemen-tation. Firstly, it negates a considerable overhead in message size on thewire that would be the result of using a different data format such as XMLor JSON. XML and JSON are further superfluous for a protocol in which atmost 6 or 7 primitives are sent over the wire at the same time. The second

7 For familiar readers unfamiliar with Scala, these concepts are analagous to algebraic data typesin Haskell, and can also be thought off as simplified regular Java or C++ classes.

75

Name ComponentsSubscription request Public keySubscription response Certificate, account balence (integer)Subscription failure noneAuth. challenge request CertificateAuth. challenge challenge (byte string), signature (byte

string)Withdrawal request amount (integer), signature (byte string)Withdrawal response coins (coin set), new balance (integer)Withdrawal failure noneDeposit request coins (coin set), receipt challenge (byte

string), signature (byte string)Payment deposit request coins (coin set), receipt challenge (byte

string), payer identity (public key), signa-ture (byte string)

Deposit response receipt, new balance (integer)Deposit failure nonePayment key exch. init key exchange (public key)Payment key exch. response key exchange (public key)Payment auth. init certificate, payer challenge (byte string)Payment auth. response certificate, payee challenge (byte string),

signature (byte string)Payment coin transfer coins (coin set), receipt challenge (byte

string), signature (byte string)Payment confirmation receipt, signature (byte string)

Table 5: An overview of the message in the implementation of the Essential

protocol

advantage to this is that (de)serialization is fast; it just consists of a sim-ple mapping of binary data to data primitives, and there is no generatingor parsing of format syntax. The last advantage is that it is typesafe; theScala compiler itself validates whether the internal data representation andthe format on the wire are compatible, ensuring that the (de)serializationmatches specification.

9.5 prototype organization

Our prototype is organized on the concept of message-passing actors8. Theactor model was chosen for both the suitability of its focus on message pass-ing for modelling network communication, as well as the fact that Akka’simplementation of actors allows for easy asynchronous message processingin our prototype. The prototype consists of a collection of client actors con-suming bank services, a collection of server actors providing bank services,and actors specific to either the console and Android client for platform-specific UI and connectivity functionality. An overview of the actors andtheir interactions within our prototype is given in figure 10.

8 The actor model is a pattern in software engineering in which state is encapsulated in messagepassing objects called actors. Actor possess a state privately from the outside world and onlychange state based on receiving messages, and only influence the outside world by sendingmessages. Actor model theory itself is associated with a large body of literature that woulddistract from the rest of this thesis. We refer the reader to Hewitt [60] and Reynolds [103] foran introduction.

76

Bank server

App clientConsole client

Network connection actor

Client actor

Bank actor

Network actor

Clerk actor

Client actor

Clerk actor

Clerk actor

Bank connection actor

Console UI actor

Android UI actor

P2P Payments Receive actor

P2P Payments Send actor

Storage

User

User

Other client

Other app client

Other console client

Client connection actor Client connection

actor

Client connection actor

Figure 10: An overview of actors and components in our prototype and their inter-actions. Thick black lines denote internal message passing among actors;dashed lines denote message passing over TCP over a regular networkconnection; dashed-dotted lines denote message passing over TCP usingWi-Fi Direct.

9.5.1 Bank system

The bank system manages the accounts of various clients by keeping trackof how much money each has in its account. It also performs coin validationby checking whether a coin has been spent before.

bank actor This actor’s main task is doing the accounting of the bank’sclients. It keeps track of bank accounts and their balances by storingthis data into a connected storage. In our prototype, this storage con-sists of an H2 relational database. The bank actor receives internalmessages requesting information of these clients, or processes mes-sages to update information about clients. The bank actor is also theonly place where the bank’s private key exists.

network actor The network actor listens to incoming network message.It responds to to messages made by clients wishing to interact withthe bank. For every such request, the network actor creates a session

77

by creating a client connection actor for every incoming client, anddelegating the communication with the client to this actor.

clerk actors The clerk actor implements the behaviour specified for thebank in chapter 8. It takes requests from the client, validates them,and requests information or actions from the bank actor. It is imple-mented as a finite state machine, receiving messages and changingstate according to the contexts of the payment protocol. The clerk ac-tor replies to the client actor with, data or success or failure messagesthrough the client connection actor.

client connection actors One of these actors is associated with ev-ery clerk actor and with every client session opened with the server.It does not maintain any state of its own, but is assigned to a TCPsession and translates the binary protocol received over it into inter-nal messages, and conversely translates internal messages to binaryrepresent to send over the network.

9.5.2 Console client

The console client was designed as a testbed for the client actor. It comeswith a simple command-line interface in which the entered commands aretranslated to input messages for the client actor. This client can also performpayments, but does so using the local network infrastructure as opposed toa direct interface.

client actor This actor implements the client message handling. Likethe clerk actors in the bank system, this actor ”speaks” the protocolsdescribed in chapter 8 and is fed messages corresponding to protocolmessages. It is implemented as a finite state machine, that keeps aspart of its state its wallet and keys with which it participates in theprotocols with the bank and with other clients.

network connection actor The network connection actor maintainstwo roles within the console application; it translates internal mes-sages from the client into binary messages for the bank, and it alsodoes this for other clients. The network connection actor thereforecommunicates with the bank’s client connection actor for authenti-cation, withdrawal and deposit, and with other network connectionactors for payments.

console ui actor This actor is responsible for translating a class inter-nal messages called UI events to output of a console application. Whenthe client actor achieves certain states, it may send a message to con-sole actor which updates the application’s text to notify the user.

9.5.3 App client

The actors in the app client share the same client actor as the console appli-cation, but it communicates internally with actors specific for the Androiduser interface, as well as different actors tasked with sending and receivingpayments.

client actor The code of the client actor in the app client is shared withthe console client. This is the same finite state machine implementingthe client behaviour as described in chapter 8.

78

bank connection actor The bank connection actor initiates connec-tions to the bank, and maintains an open TCP connection with a clientconnection actor of the bank’s system. It receives protocol messages ininternal representation from the client actor and translates these to abinary presentation, and conversely sends received protocol messagesin binary representation to the client actor in internal representation.In contrast to the console clients’ network actor, this actor is not in-volved in payments.

android ui actor This actor performs the logic for updating the appli-cation’s user interface using Android’s system libraries. It responds toUI events by scheduling user interface changes on the system’s userinterface rendering thread.

payment receive actor The payment receive actor listens to a TCP portopened on the systems’ Wi-Fi Direct interface. This connection listensto incoming binary messages, attempts to deserialize them to the inter-nal reprentation of protocol messages, and relays them to the client ac-tor. The client actor will then respond with protocol messages, whichthe payment receive actor will transmit to the payer in binary form.

payment send actor Upon the command of the client actor, the pay-ment send actor opens a connection to another client using the Wi-FiDirect interface. The payee’s payment receive actor will receive thisconnection initiation, after which the payment send actor will trans-late binary messages to internal representation for the remainder ofthe payment protocol.

9.6 storage security notes

In the prototype, coin data and private keys are stored in the prototype’sapplication’s private memory. Private memory is a term for a feature of An-droid’s data storage facilities, in which data is stored in an area that isprotected from other apps by the operating system. Although it prevents il-licit reading of this information by other apps on the device, it is not securein any way. Nonetheless, to our knowledge there is no storage with moresecurity guarantees generally available to Android developers.

In the Essential protocol, coins themselves do not have to be securedin a more advanced way if the private key is secured properly. Should thecoins be copied by malware, the coins are tied to a public key of which theuser must proof of possession of the private key to both the bank and otherclients. Therefore, the problem of secure storage is reduced to securing theprivate key. This is not the case for Untraceable and Multibank protocols,since coins are not tied to a public key for anonymity.

Secure storage of private keys is becoming available on some Androiddevices. We found that Android devices employing recent Qualcomm Snap-dragon processors make available a hidden API allowing the developer toprogram the devices’ secure element. There were three restrictions to theuse of such an API in our prototype. The first is that this secure elementis not generally available on Android devices, and only appears usable onthe subset of Android devices that use a suitable chip. Secondly, the pro-posed API is undocumented and unstable - the only public documentationexists in reverse engineered descriptions9. Lastly, the cryptographic primi-

79

tives supported by the secure element appear to be limited to RSA and DSAbased primitives.

The secure element API describes an interface to manage store a privatekey secret a hardware-based ”master key” in a specific area in a devices’hardware. This is an implementation of a wider specification called ARMTrustZone. It allows the import and secure generation of a secret key andmethods to use the secret key to sign and verify data, but not methods toread this secret key into memory, as this key is protected by the hardware’smaster key. As such, cryptographic operations are delegated to the CPUand not developer code. The goal of this approach is to make it very hardto obtain the secret key from a pure software perspective, although all ofthe system’s keys are compromised should the hardware master key becompromised.

Although a very limited interface to this system is exposed in recent ver-sions of Android, this provides no guarantees for hardware assisted securestorage. We tried to implement a basic form of hardware encryption supportin our prototype, but found that the unstable APIs had changed in Android4.4.4 on a Nexus 4, causing calling of this APIs to raise exceptions in ourapplication. Given the scope of our research was not to investigate securitystorage options, and the fact that if we succeeded, the resulting constructswere not compatible with the constructs chosen in our prototype (and withthose in our protocol design), we did not investigate this matter further.

9.7 user interface

In this section, we will briefly discuss the user interface chosen for our pro-totype application. We make no claim about the appropriateness of thisparticular user interface for a payment application; the interface was de-signed to serve its need pragmatically in the prototype, and has not beenmade to look like an application for end users. This section is intended toinform the reader of the general operation of our prototype instead.

We developed a basic interface for a digital wallet application that isbacked by a bank account. The main view in the application is that ofthe digital wallet, and can be seen in figure 11. The top bar shows theclient’s randomly generated account number. The bank keeps track of theclient’s balance, but this is also kept track of on the client’s side. In addition,the client maintains a count of the coins in its own wallet. The interfacepresents two action buttons to withdraw and deposit, which respectivelyrun the withdrawal and deposit protocols for a single coin. Additionally, alist of nearby devices which broadcast the capability of receiving paymentsis shown, but it is empty in this example.

Some prototype specific features should also be noted. The ’X’ buttonis a ”clear alll” button for prototyping purposes, which clears storage andremoves account information from the application. This reveals the applica-tion’s initial, on which he/she can enter a server address for the bank andconnect to it. Upon a new connection, a new account is created for that user,with an account balance of 5 coins.

An demonstration of a payment is given in figure 12. We see (12a) asmartphone with a balance of 1 coin and 3 coins in its wallet, and a tablet

9 The only publicly available information on this API is a reversed engineereddescription by Nikolay Elenkov, which has been used as source material forthis section. It can be found at http://nelenkov.blogspot.com/2013/08/

credential-storage-enhancements-android-43.html

80

http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html

http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html

Figure 11: The main view of the prototype, showing basic information andactions

with a balance of 4 coins and 3 coins in its wallet. We are going to makea payment from the smartphone to the tablet which, for the purpose ofdemonstration, is not immediately deposited. Both devices can see thatthe other device advertises it is capable of receiving payment, and this issignified by the list of ”nearby devices” being populated on both devices.On the smartphone, we tap (12b) the tablet’s entry in this list to make aWi-Fi Direct connection and initiate a payment. A new dialog pops upin which the user can select (12c) the payment amount, which can be anarbitrary positive value and is 2 in the example. The user confirms, thepayment protocol is run between the two devices on the local connection.Finally, the payment has completed succesfully (12d), and the tablet finisheswith 5 coins in its wallet.

81

(a) Overview

(b) Peer selection

(c) Enter payment amount

(d) Payment complete

Figure 12: A demonstration of a payment between devices

82

Part III

R E S U LT S

10B E N C H M A R K S

To address the last research question concerning the performance of thecryptographic constructs on mobile devices, we implemented a set of bench-marks to run on various mobile devices. In this chapter, we will describe thebenchmarks that were run, the devices on which they were run, and presenttheir results.

10.1 description

We are interested in evaluating the capabilities of mobile devices assumingthe role of clients in payment protocols. In chapter 8 we discussed thedesign of payment protocols. From these protocols, we may identify whichcomputations run on client devices. The cryptographic primitives used inthe construction of these protocols are the following:

• Cryptographic hashes

• Group arithmetic

Cryptographic hashes are used as a base construct of all proof of knowl-edges used by the client. Group arithmetic and the associated Diffie-Helmanassumption are used to generate unforgeable group elements in digital sig-natures and other proofs-of-knowledge. In the remainder of this benchmark,we will use certain specific elliptic curves to fulfill the role of these groups.These primitives are used to compute the following proofs of knowledge:

• Regular digital signatures

• Proof of discrete logarithm (pklog and plogeq)

If we look at when these computations occur in the protocols we designed,we may observe that in all three of the Essential, Untraceable and Multi-bank protocols, this occurs in the withdrawal and payment phases. Notethat the Untraceable and Multibank phases are almost identical with re-spect to computational burden on the client; the only modification in theprotocol is a single certificate verification during the receiving of a payment.Because of this minute difference, we will therefore not consider the differ-ences between these two varieties in this benchmark. Instead, we will focuson the computations that are necessary for handling coins in each of the pro-tocols; since coins will be exchanged in larger numbers, these parts of theprotocols will require repeated computations of cryptographic constructs.These parts can be listed as:

• Essential coin receive

• Untraceable withdrawal phase 1


85

/ / Returns t h e amounts o f n a n o s e c o n d s t h i s c o m p u t a t i o n t o o kdef run ( ) : Long = {

/ / P r e p a r e i n p u t p a r a m e t e r s f o r benchmark c o m p u t a t i o nval basePoint = spec . getG . mult iply (new B i g I n t e g e r ( 1 2 8 , rand ) )val benchmarks = f i l l {

basePoint . mult iply (new B i g I n t e g e r ( 1 2 8 , rand ) )}/ / Time t h e c o m p u t a t i o n and r e t u r n t h e d u r a t i o ntime {

for ( point <− benchmarks ) basePoint . add ( point )}

}

Figure 13: Benchmark structure explained using simple benchmark code


We note that ”receiving coins” denotes receiving a withdrawal and receiv-ing a payment, as they comprise solely the checking of signatures on thesecoins. The untraceable withdrawal exists in three phases; each of them withdifferent computations being performed.

Benchmarks were written for every mentioned item in this section. Dur-ing the programming of the benchmarks, we encountered a possible per-formance issue with the digital signature library that we had been usingduring the creation of the demo. Although our concerns later turned outto be false, we also implemented a custom implementation of the digitalsignature algorithm and evaluated the performance of that as well.

In addition to the mentioned benchmarks, we also verified the perfor-mance of certain group signatures. This is not an implementation thatwe wrote ourselves; instead we used an available Java implementation ofa group signature scheme previously evaluated on a limited number of mo-bile devices by Potzmader et al. [99].

10.2 methodology

We developed an Android application to run these benchmarks on mobiledevices. Like the prototype application, this Android application was writ-ten in Scala using the BouncyCastle library to provide cryptographic con-structs. In particular, BouncyCastle was used to provide a stock implemen-tation of the digital signature algorithm and used to provide elliptic curvesand means to perform arithmetic on them. Benchmarks were written forthe items described in the previous section, and will be discussed further intheir respective results sections later this chapter.

We wrote a small program for each computation we wished to benchmark.Many benchmarks required the selection and computation of previous data.After that, we invoked the desired computation a repeated amount of timeswith different input values within a timer function. The amount of rep-etitions we varied per benchmark based on required computationol power.The timer function reads the system timer for the current amount of nanosec-onds that have passed since last boot both before and after the computa-tion. The difference between these values is the amount of nanoseconds

86

that has passed since the beginning of the computation according to thesystem clock.

Each benchmark was then repeated three times with different inputs. Thiswas done to collect results on a large number of iterations, and at the sametime prevent the benchmarks from consuming a large amount of memoryfor precomputed parameters. We noted that memory consumption affectedperformance on devices with a small amount of memory. The average ofthese three benchmark runs is then taken as authoritive for the performance.The average amount of time taken for each benchmark is then normalizedinto the number of computations per second.

10.3 devices

We ran this benchmark on 30 devices. The relevant details of these deviceare documented in table 6. As was expected, not every phone could com-plete every benchmark. We encountered various issues that mostly involveunexpected behaviour of hardware and software that prevented the com-pletion of the benchmarks. This means that some of the more advancedbenchmarks are unfortunately not available for a subset of devices.

The devices comprise a large selection of mobile phones and tablets, withmany selected for their popularity on the Dutch consumer market. The de-vices span release dates from 2010 to 2014, as well as a variety of vendorsof the system-on-a-chip housing the devices’ CPU. Samsung is the majoritydevice vendor, and Qualcomm is the majority CPU vendor, as both haveobtained large marketshare on the Dutch market. Besides tablets and smart-phones, the LG G Watch, a recently released smartwatch running a modifiedversion of Android was also included in the tests as it was capable of com-pleting the benchmark without issues. We included two versions of theLG Nexus 4: although versions released in 2012 appear identical to thosereleased in 2014, we are expecting different performance characteristics be-cause of cooling problems in the former model.

It was noteworthy that many devices did not seem to be able to run testsin which BouncyCastle’s built-in digital signature algorithm was used. Wesuspect that this is due to problems in vendor software; the way BouncyCas-tle’s digital signature functionality is requested from the system requirescommunication with the system’s libraries where the other tested mecha-nisms were self-contained within the benchmark application. Since vendorsmay modify these system libraries, we hypothesize a bug was encounteredwhen running these benchmarks. The problem mostly affected older Sam-sung devices. We also encountered this on the LG Optimus 2X, which didnot implement a native library call required by the group signature library.

As of Android version 4.4, devices are capable of running a new appli-cation runtime environment. Older Android versions run apps from aninterpreted bytecode format, with a just-in-time compiler for all versions ofAndroid tested in this benchmark. Beginning with version 4.4 devices mayuse a runtime called Android Runtime (or ART), which performs ahead-of-time compilation of this bytecode into machine code native for the platformand is designed to increase performance. This runtime will be the defaultruntime for Android in the future, and we tested devices with both theseruntimes when possible. Measurements obtained with the ART runtime aredenoted with the suffix ”(A)” in the graphs of the next sections.

87

Vendor Model CPU Version YearLG Optimus 2X Tegra 2 AP20H 2.2 2011 1

Sony Xperia Arc SnapdragonMSM8255

2.2 2011

Samsung Galaxy S Plus SnapdragonMSM8255T

2.3 2011

Samsung Galaxy Nexus OMAP4430 4.2 2011

Samsung Galaxy Txt BCM21553 2.3 2011 2

Samsung Nexus S Exynos 3 4.0 2010

Samsung Galaxy Note 10.1 Exynos 4412 4.2 2012

HTC One X Tegra 3 4.2 2012 2

Samsung Galaxy S3 Exynos 4412 4.3 2012 2

Samsung Galaxy Note II Exynos 4412 4.3 2012 2

Asus Transformer PadTF300T

Tegra 3 4.2 2012 2

Samsung Galaxy Note Exynos 4210 4.0 2011 2

Samsung Galaxy Tab 3 10.1 Atom Z2560 4.2 2013 2

Samsung Galaxy S4 Mini Snapdragon 400 4.4 2013

LG Nexus 5 Snapdragon 800 4.4 2013 3

Samsung Galaxy S5 Snapdragon 801 4.4 2014 3

HTC One (M8) Snapdragon 801 4.4 2014 3

Samsung Galaxy Note Pro12.2

Exynos 5 Octa5420

4.4 2014

LG G Watch Snapdragon 400 4.4W 2014

Samsung Galaxy Tab Exynos 3 4.4 2010

Samsung Galaxy S2 Exynos 4210 4.2 2011

Motorola Moto G Snapdragon 400 4.4 2013

LG Nexus 4 (2014 revi-sion)

Snapdragon S4

Pro4.4 2012 4

HTC Sensation SnapdragonMSM8260

4.4 2011 4

HP Touchpad SnapdragonAPQ8064

4.4 2011 4

Samsung Galaxy Ace II Novathor U8500 4.4 2012

Jiayu G4 MT6859 4.2 2013 2

Sony Xperia Z2 Snapdragon 801 4.4 2014

LG Nexus 4 (2012 revi-sion)

Snapdragon S4

Pro4.4 2012 3

Table 6: The devices tested in the benchmark

1: Could not run group signatures2: Could not run BouncyCastle digital signatures3: Tested with both Dalvik and ART4. Tested with ART onlyChip manufacturers Qualcomm (Snapdragon), Samsung (Exynos), Nvidia (Tegra),Texas Instruments (OMAP), Broadcom (BCM21533), Intel (Atom), ST-Ericsson (No-vathor) and Mediatek (MT6859) are represented.

88

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

LG Op,mus 2X

Sony Ericsson Xperia Arc

Samsung Galaxy S Plus

Samsung Galaxy Nexus

Samsung Galaxy Txt

Samsung Nexus S

Samsung Galaxy Note 10.1

HTC One X

Samsung Galaxy S3

Samsung Galaxy Note II

Asus Transformer Pad TF300T

Samsung Galaxy Note

Samsung Galaxy Tab 3 10.1

Samsung Galaxy S4 Mini

LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5

Samsung Galaxy S5 (A)

HTC One (M8)

HTC One (M8) (A)

Samsung Galaxy Note Pro 12.2

Samsung Galaxy Ace II

Samsung Galaxy Tab (A)

Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa,on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

SHA224

SHA256

SHA384

SHA512

Figure 14: Cryptographic hash performance (generated hashes per second)

10.4 cryptographic constructs

10.4.1 Hashes

Although there are many known cryptographic hashes, the family of hashesthat makes up the SHA-2 standard is the most popular based on speed andsecurity. The SHA-256 standard is specified for various sizes. We testedthe SHA-224, SHA-256, SHA-384 and SHA-512 hashes on all devices. Theresults can be seen in figure 14.

Note the slow performance of the SHA-224 hashing algorithm, especiallyin comparison with the others. We hypothesize that this is due to byte-leveloptimization of the other algorithms in the family, in which a large amountof bit-shifting and other bit level operations are executed, which might notoptimize well for SHA-224 on a Java virtual machine. The LG Optimus 2Xreports spurious results for the hashing functions - reporting a significantlyfaster result for the SHA-224 algorithm when compared to far slower SHA-384 and SHA-512 results.

SHA-256 reports the fastest results; reaching over 5000 hashes each secondfor every device and even over 40000 for the Galaxy Note Pro 12.2. Thelarger hashes also performed quite quicly, and appear not to carry largetradeoffs in terms of speed when compared to the 256-bit output size.

10.4.2 Elliptic curve arithmetic

We tested four different elliptic curves. The first is the secp256k1 curve,which is also used as the elliptic curve for signatures in the Bitcoin proto-col Nakamoto [88]. This curve was designed for efficient computation [30].The other curves that we benchmarked were chosen as ”standard” choicesfor various public key sizes, to test the influence of key size on performance.They are the NIST curves P-192, P-256 and P-384 curves NIST [93].

The benchmarks comprise that of addition, subtraction and multiplication ofa randomly generated elliptic curve point with another elliptic curve pointthat is fixed for each benchmark run. The results for addition and substrac-tion are shown in figures 15 and 16.

89

0

5000

10000

15000

20000

25000

30000

35000

LG Op+mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa+on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

secp256k1

P-‐192

P-‐256

P-‐384

Figure 15: Elliptic curve performance (additions per second)

0

5000

10000

15000

20000

25000

30000

LG Op+mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa+on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

secp256k1

P-‐192

P-‐256

P-‐384

Figure 16: Elliptic curve performance (subtractions per second)

90

0

50

100

150

200

250

300

350

LG Op+mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa+on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

secp256k1

P-‐192

P-‐256

P-‐384

Figure 17: Elliptic curve performance (multiplications per second)

It appears the performance figures for addition and subtraction are inagreement. This is no surprise; like subtraction in additive integer groups,subtraction in elliptic curves is defined as addition with the negation of theother point. Since negation in elliptic curve fields is a cheap operation, bothoperations show similar performance characteristics.

On most devices, it can be seen that with increasing elliptic curve elementsize, addition and subtraction slow down. Operations on curves P-192 andP-256 are quite close, with the P-192 curve being generally faster, but thereis a significant drop off in addition and subtraction performance wheneverthe P-384 curve is used. It should be noted that the size of the ellipticcurve field changes increases by 50% in this case, but the drop off in perfor-mance is much more. When comparing secpk256k1, we can see that it hasvery different performance characteristics to the NIST curves. It can be bestcompared to the P-256 curve, sometimes even outperforms the P-192 curve.Nonetheless, there does not seem to be a significant performance advantageof this curve over the others with respect to addition.

All devices except for the Galaxy Txt and the G Watch are capable ofperforming more than 1000 elliptic curve additions per second. High enddevices perform well over 10,000 operations per second. Clearly, ellipticcurve addition and subtraction are quite fast on mobile devices if the rightcurve is chosen.

The results for elliptic curve multiplication are given in figure 17. The firstthing to remark when seeing this graph is that the scale of this graph is verydifferent to the previous ones. Ellipticcurve multiplication is on the orderof 100 times slower than addition and subtraction. Whereas the Galaxy TabPro 12.2 achieved more than 120000 additions on P-192 in a second, it canonly achieve 120 multiplications per second on the same curve.

Performance of elliptic curves is more predictable for multiplication. Thesmall group of P-192 clearly yields the most performance for these devices;it is the fastest option for any device except the G Watch. Of further note isthat the secpk256k1 curve is consistently outperformed by the NIST curve ofthe same size. Finally, the large P-384 drops off multiplication performanceaccording to the same ratio as it did for addition and subtraction.

91

0

20

40

60

80

100

120

140

160

180

LG Op,mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa,on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 18: Library provided ECDSA (signatures per second)

10.5 proofs of knowledge

10.5.1 Digital signatures

The next benchmark is the standard elliptic curve digital signature providedby the BouncyCastle library. We chose the default ECDSA curve and param-eters, as well as the SHA256 cryptographic hash. As previously mentioned,not all devices were able to complete this benchmark, but the results ofsignature generation and verification are given in figures 18 and 18.

All newer devices are capable of generating more than 50 digital signa-tures per second. The highest end devices are not able to do more than150 signatures. Performance is generally better for signature verification;verification runs at nearly twice the speed of signature generation.

10.5.2 Custom implementation of digital signatures

As a point of comparison, we implemented our own version of the ECDSAalgorithm using BouncyCastle’s elliptic curve arithmetic libraries. The ad-vantage of this approach is that it can put BouncyCastle’s own implemen-tation in perspeective, and this benchmark was also able to run on moredevices for comparison. Like in the elliptic curve arithmetic benchmarks,we used the secp256k1, P-192, P-256 and P-384 curves. These were all com-bined with the SHA-256 cryptographic hash to generate the signature. Theresults of signature generation and verification are shown in figures 20 and21.

Comparing the graphs of the two styles of digital signatures, we can notethat the signature performance of our custom implementation slightly out-performs the library provided one. The custom verification technique nowis not twice the speed of signature generation, but half that speed. The latteris somewhat unsurprising as signature verification requires two curve pointmultiplications, and generation requires only one. We have no explanationfor the apparent speed of BouncyCastle’s implementation.

92

0

50

100

150

200

250

300

LG Op+mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa+on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 19: Library provided ECDSA (verifications per second)

0

50

100

150

200

250

LG Op*mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa*on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

secp256k1

P-‐192

P-‐256

P-‐384

Figure 20: Custom ECDSA implementation (signatures per second)

93

0

20

40

60

80

100

120

LG Op,mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa,on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

secp256k1

P-‐192

P-‐256

P-‐384

Figure 21: Custom ECDSA implementation (verifications per second)

It is also remarkable that the performance of digital signatures on thesecp256k1 curve rivals the performance of the smaller P-192 curve, despitehaving the increased security of larger group elements. The NIST curves allperform in order, but curve choice appears to make a big difference in thegeneration of these signatures.

10.5.3 Proof of discrete logarithm

The generation of discrete logarithm proofs-of-knowledge is important inthe Untraceable varieties of our payment protocols. A random grouppoint and secret key was chosen for each benchmark, and proofs usingthese parameters were generated. They are implemented in a similar fash-ion as the custom digital signature benchmarks, but all computations usethe secp256k1 curve and the SHA-256 hash function. The results are infigures 22 and 23.

An interesting observation from comparing the two graphs is that verifi-cation happens at almost exactly half the speed when compared to gener-ation. This is consistent with the amount of elliptic curve multiplicationsthat occur during both computations; one for the generation of the proof,and two for the verification. What is more, there appears to be a doublingof performance among multiple devices when compared to random ellipticcurve multiplications. We hypothesize that the multiplication performanceof fixed points is quicker than that of random parameters.

10.5.4 Proof of discrete logarithm equality

An extension of the previous computation, this constructs proves to a veri-fier that the generator knows two pairs of points are set to the same discretelogarithm. Furthermore, this proof is tied to some string message. Thestring message was fixed for the benchmark, and the elliptic curve pointsand secret keys were picked randomly like in the previous benchmark. Theresults can be seen in figures 24 and 25.

94

0

20

40

60

80

100

120

140

160

180

LG Op,mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa,on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 22: Proof-of-knowledge performance (generations per second)

0

10

20

30

40

50

60

70

80

90

LG Op0mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa0on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 23: Proof-of-knowledge performance (verifications per second)

95

0

10

20

30

40

50

60

70

80

LG Op/mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa/on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 24: Proof-of-knowledge equality performance (generations per sec-ond)

0

5

10

15

20

25

30

35

40

LG Op,mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa,on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 25: Proof-of-knowledge equality performance (verifications per sec-ond)

96

Again, the performance of generation and verification is in line with theperformed elliptic curve multiplications - two in the case per generation, andfour in the case of verification - resulting in half the performance during ver-ification versus generation. It is noteworthy that we are getting into territoryin which mobile devices are not able to keep up with these computations:the Samsung Galaxy Txt can verify just under one proof-of-logarithm equal-ity per second. The performance of higher-end devices is also fading rapidly,with the best devices just barely hitting over 30 verifications per second.

10.6 group signatures

The following benchmarks extensively use code written by Potzmader et al.[99]. They made implementations of several group signature schemes foruse in Java programs and Android devices. Although we have not supplieda formal design of a payment protocol utilizing group signatures, we havemade the assumption that in such a protocol client devices only would haveto perform verification on signatures. The reason for this is that in such ascenario, coins would be validated by the presentation of a group signatureon their coin identifier. This signature would be generated by a bank; itwould be up to the clients to check the validity of these coins. Therefore,only the verification speed of group signatures on mobile devices was tested.

Potzmader et al. provide three different mechanisms for group signaturesin their library. The authors chose these schemes because of their inclusionin the ISO20008 group signature standard. We will use their terminology,and describe these schemes in the next few sections.

10.6.1 Mechanism 1

Mechanism 1 is an implementation of a signature scheme originally devisedby Canard and Schoenmakers [26]. It is specifically designed for anyone inthe system to check whether a party has signed a message twice, without theinvolvement of the group manager, by requiring an addition of a tag to everymessage. Such a group signature scheme is called a list signature scheme bythe authors. As a consequence, each group member has its own public key,and the group public key is a concatenation of the entire set. The scheme’ssecurity is based on the strong RSA assumption and the decisional Diffie-Hellman assumption; the public keys are taken from multiplicative integergroups.

The benchmarks consist of generating a number of signed messages, andthen timing the verification of the message. The results are in figure 26. Theverification was tested with both 512-bit and 1024-bit public keys.

The results show that the verification of group signatures is much closerin performance across devices than the other benchmarks are; all devicesstruggle to achieve good performance, and achieve 3 to 7 verifications persecond for 512 bit public keys. The results are even more prominently equal-ized for 1024-bit keys; with the exception of the Samsung Galaxy Txt (whichregistered 0,2 and 0,02 verifications per second, respectively). None of thedevices is able to make 2 verifications per second, with performance gener-ally varying between 0.5 to 1.5 signature verification per second.

It should be noted that 512-bit and 1024-bit keys likely do not even repre-sent sufficient security; Canard and Schoenmakers describe public keys thatare the equivalent of public keys in the ElGamal cryptosystem, for which2048-bit public keys are recommended at the time of writing.

97

0

1

2

3

4

5

6

7

8

9

LG Op0mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa0on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

512-‐bit

1024-‐bit

Figure 26: Group signature performance (Mechanism 1 verifications per sec-ond)

10.6.2 Mechanism 4

Mechanism 4 is an implementation of the ECC-DAA (Direct AnonymousAttestation) scheme as originally described by Brickell and Li [21]. Thisgroup signature scheme was devised to run on small devices that need tobe able to sign group signatures. It is specifically designed so that group sig-natures can be signed by small hardware devices that are assisted partiallyin their computation by more powerful systems. It should be noted that thedesign of this scheme aims for the opposite of what a group signature basedpayment scheme would be; signatures would be generated by computation-ally restricted devices, and verification would happen on less constrainedsytems.

This mechanism parametrized with certain runtime details. We chose theparameters that the authors of the library found most performant [99]. Theresults are given in figure 27.

We can see that the performance of verification in this scheme is roughlyequivalent to the 1024-bit version of Mechanism 1. All but the most con-strained devices exhibit performance between 0.5 to 1.5 signature verifica-tions per second, with the Galaxy Tab Pro 12.2 again performing the fastestwith 1.77 signatures per second.

10.6.3 Mechanism 5

This mechanism is based on the description of a group signature schemeby Isshiki et al. [63]. It is an RSA-based group signature designed for iden-tity management systems, with elliptic curve cryptography used for certaingroup administrator tasks. It is distinctive from other group signature sys-tems by this fact; the group master holds distinct secret keys for admittinggroup members and signer identification. The results of the benchmark for1024-bit public keys are found in figure 28.

Performance characteristis for this final mechanism are roughly the sameas the previous group signature verifications. This scheme runs a bit more

98

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

LG Op-mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa-on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)


0

1

2

3

4

5

6

LG Op-mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa-on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)


99

0

50

100

150

200

250

300

LG Op+mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa+on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 29: Essential protocol performance (coin validations per second)

efficiently when compared to the 1024-bit version of Mechanism 1 and Mech-anism 4, with most devices capable of 1.5 to 3 verifications per second. TheSamsung Galaxy Txt is the most constrained device, but is generally morecapable of keeping up with the other devices in this particular benchmark.

10.7 payment and withdrawal simulations

In this section, we will execute parts of cryptopgraphy required for certaincomputationally demanding parts of the designed payment protocols. All ofthese computationally demanding parts deal with obtaining coins, whetherthrough payment or through withdrawal.

10.7.1 Essential coin validation

This benchmark simulates the receiving of coins in the Essential bench-mark. Coins in the Essential protocol are verified by a digital signaturecheck. This benchmark is therefore comparable to the digital signature ver-ification benchmark - the difference being that there is some serializationand public key comparison logic added to the computation. The resultsof the benchmark are given in figure 29. Note that since we use the sameBouncyCastle digital signature algorithm as in our previous benchmark, thesame devices were not capable of running this benchmark. A comparisonof this graph with figure 19 shows essentially the same performance as thepure digital signature benchmark; the additional overhead of serializationand equality is clearly negligible.

10.7.2 Essential coin validation (with custom signatures)

The same workload was also benchmarked with our custom implementa-tion of digitial signatures. Again, we chose secp256k1 and SHA-256 as ourparameters, and ran the benchmark on messages that were serializations ofcoin data. The results are given in figure 30.

100

0

10

20

30

40

50

60

70

80

90

LG Op0mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa0on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 30: Essential protocol performance with custom signatures (coin val-idations per second)

Like the benchmark using stock digital signatures, we can also see thesimilarity between figures 30 and 21. Again, there is a considerable increasein performance to be gained by using the library provided implementationwhen compared to the custom implemenation: where the top performingdevice can validate 80 coins per second using this method, the same devicecan validate over 250 coins in the previous.

10.7.3 Untraceable coin validation

Validating Untraceable coins when receiving payments requires the vali-dation of one pklog proof and one plogeq proof contained within the coin.We again chose the curve secp256k1 and SHA-256 as our cryptographicprimitives. Figure 31 shows the results.

It is clear that Untraceable coin validation requires strong computa-tional performance. The Samsung Galaxy Txt is the lowest performer andcan verify 1.9 coins per second. The fastest devices, the Galaxy S5 runningthe ART runtime and the Galaxy Tab 12.2, can validate 23.9 and 22.1 coinsper second respectively.

10.7.4 Untraceable withdrawal

Recall from section 8.3 that untraceable withdrawal occurs in three steps.First, the client proves knowledge of a coin-withdrawal-specific values to thebank. This is step 1 of the withdrawal. The bank then replies with crypto-graphic parameters based on these session-specific parameters and its ownprivate key. The client determines a coin identifier and generates blindedcoins based on the given parameters. This is step 2. After the blinded coinsare sent to the bank, the bank returns the signature information to the client.As the final step, the client unblinds the coins. Step 1 requires the genera-tion of plogeq and an addition elliptic curve multiplication, step 2 requirestwo elliptic curve multiplications, and the final step involves the generationof a pklog.

101

0

5

10

15

20

25

30

LG Op+mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa+on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Figure 31: Untraceable protocol performance (coin validations per second)

Choosing secp256k1 and SHA-256 as the primitives, we ran these bench-marks on all devices. The results are found in figure 32.

It is clear that step 1 and 2 are the most computationally intensive steps.Step 3 in comparison is far less intensive, with many devices capable ofreaching 200 iterations per second. The cumulative measure indicates thatdevices are generally capable of withdrawing 15 to 40 coins per second,excluding the most extreme performers.

102

0

100

200

300

400

500

600

700

800

LG Op/mus 2X




Samsung Galaxy Txt

Samsung Nexus S


HTC One X

Samsung Galaxy S3



Samsung Galaxy Note



LG Nexus 5

LG Nexus 5 (A)

Samsung Galaxy S5


HTC One (M8)

HTC One (M8) (A)




Samsung Galaxy S2

Motorola Moto G (A)

LG Nexus 4 (2014) (A)

HTC Sensa/on (A)

HP Touchpad (A)

LG G Watch

Jiayu G4

Sony Xperia Z2

LG Nexus 4 (2012)

LG Nexus 4 (2012) (A)

Step 1

Step 2

Step 3

Cumula/ve

Figure 32: Untraceable withdrawal performance (coins per second)

103

11D I S C U S S I O N & C O N C L U S I O N S

With the design and results of our work described, we will use this chapterto reflect on the findings made in this thesis, and what to conclude fromthem. Let us briefly reiterate the work presented:

• The design and cryptography of three peer-to-peer payment protocolswith different features

• A prototype that demonstrates a simplified payment system on mobiledevices

• A set of benchmarks that evaluate the performance of the crypto-graphic constructs used in the protocol design

11.1 a comparison with fiat money

We must begin with noting that in the design of the protocols, we havefailed our initial mission - the mission of creating a true analogue of cashfor mobile devices. It was soon realized that the metaphor of fiat money is auseful analogy in the design of payment protocols, but the nature of digitalsystems break down a perfect metaphor; a digital equivalent of banknotesand minted coins does not exist. It is further exacerbarated by the contextof the real world; whereas in the real world currency is dealt by a mostlyimpartial and uninterested authority (the mint), a digital payment systemhas no such authority to rely upon.

The protocols presented in chapter 8 are attempts to make the best of thisflawed analogy. How can a digital payment protocol work similarily to fiatmoney, within the context of digital an mobile systems? We believe we havemostly succeeded in this; we have demonstrated systems that enables offlinepayments (the Essential protocol), enables a similar degree of anonymity(the Untraceable protocol), and enables a large degree of interopability(the Multi-Cert protocol).

The notions of ’offline’, ’anonymity’ and ’interopability’ do have a differ-ent flavour when compared with fiat money. These deviations are causedby the context of the mobile device, and even moreso by the simple contextof a digital system.

First of all - the system is offline to a more limited degree. It is true thatpayers may stay offline at all times in our protocol - provided they havewithdrawn a sufficient amount of money and their authentication certifi-cates do not expire. Some regular communication with the bank is necessaryto maintain the value of the money stored. Given the internet and automa-tion capabilities of mobile devices, this weakening of the notion of offline islikely not a problem. The notion of an offline payment protocol is weakenedmore with the lack of an offline payee, at least in the default case. As previ-ously discussed, the inherent copyability of digital coins means that a payeemust trust the payer not to fool him or her with previously spent money;

105

if the payee does not have this trust he/she must verify the validity of thereceived coins using a connection to the bank.

Secondly - the notion of payment anonymity is slightly different. Fiatmoney achieves its anonymity by its transferability; although a bank canabsolutely trace which banknotes are withdrawn by whom and which onesare deposited by whom, the bank has no knowledge of what happened tothese banknotes when they were in circulation. If, on the other hand, a bankobserves the withdrawal of a banknote by Alice and a deposit of the samebanknote by Bob on the same day, the bank can be reasonably sure that Al-ice spent her money at one of Bob’s products of services. The transferabilityproperty is untenable in digital money, as previously noted: a coin is trans-fered once, and then immediately deposited. Therefore, we have needed toinvoke a stronger notion of anonymity. A bank cannot know which coinshave been spent where even if the transfer happens instantaneously. Thisnotion of payment anonymity is stronger, for it is a feature of the protocoland not a consequence of practicalities.

Anonymity in this system is also different in the sense that it can be re-voked by design as opposed to a consequence of practicalities. Anonymityrevocation of criminal activity with cash money is achieved through mark-ing, security cameras and other sorts of ways to detect the practical mattersof dealing with cash. By contrast, anonymity revocation is a fixed procedurein our Untraceable and Multi-Cert systems, and requires the trust in asingle judge or a predetermined group of judges (in the case of the sharedjudge setup). Although this makes the trust of anonymous payments ex-plicit for users of such a system, the mere definition of a trust-revokingprocedure weakens anonymity.

Lastly, interopability among banks is also not completely equivalent tocash. Banknotes and coins are physical goods of limited supply, whichhave tradeable value even without the existence of banks. This is not so forour payment protocol; banks must exist for money to be exchanged, andusers must be clients of those banks. Banks must further maintain an infras-tructure and create a mobile app to participate in this protocol, and mustparticipate in information sharing on spent coins and obtain certificates forissuing coins.

Considering the above comparisons, it is clear that our digital money facesdifferent challenges than fiat money. Digital payment systems can mimiccash, but for them to be like cash, a big effort is required.

11.2 cryptography

In chapter 8, we have shown that digital payment systems can be made froma small amount of cryptographical building blocks. They are the following:

1. Cryptographic hash functions

2. Standard elliptic curves and operations on them

3. Symmetric ciphers

4. Optionally; the Chinese Remainder Theorem

The first two building blocks are used to generate digital signatures andcompute proofs of knowledge, which in turn are used to give value to coins.

From a cryptographic implementation perspective, the designs presentedin chapter 8 are quite simple. Suitable cryptographic hash functions are

106

widely used already; furthermore the elliptic curve groups used are thesame that are used widely in digital signatures. Unless some of the worksreviewed in the first few chapters, there is no reliance on bilinear pairings,special subgroup choices, or additional Diffie-Hellman assumptions beyondthe widely trusted computational assumption.

This result is significant for the practicality of the proposed protocols. Re-lying solely on well-tested, well-known constructs, one can build a paymentprotocol that mimics fiat money as good as any other digital protocol could.

11.3 prototype

The main results from building the prototype were lessons when it comesto communication technology and secure storage. In the area of commu-nication technology, we have learnt that NFC is not a viable option forcomplex protocols which require many mutual responses. We have notinvestigated the option to use Bluetooth for this because of software restric-tions. Nonetheless, Wi-Fi Direct was found to be the perfect solution for thisproblem in many ways.

The medium of Wi-Fi Direct is a promising feature of mobile devices, notjust for payment applications, but for any application that requires directcommunication with other phones. The medium is fast, allows for high-bandwidth, high-roundtrip protocols, and provides the user of the mediumwith connection management features equivalent to regular internet connec-tions.

Other ideas developed during the prototype is the use of the secure ele-ment for private key storage. Unfortunately, the current state of secure ele-ment storage was not compatible with our scheme, and even then requiredthe use of undocumented APIs that only worked on a limited amount ofdevices. Nonetheless, this area is promising for future applications.

11.4 performance

The most extensive results were obtained from benchmarking the crypto-graphic operations on mobile devices. Refer to chapter 10 for a descriptionof the benchmarks and the results.

The first observation is that cryptographic hash functions are not a bigproblem. Since the SHA hash family is designed for speed, this was ex-pected. Elliptic curve addition and subtraction were also found to be per-formant; over a thousand of those operations could be done per second. Itis elliptic curve multiplication that has turned out to be the bottleneck; it isroughly two orders of magnitude slower than addition and subtraction, andlimited to 50 multiplications per second.

Upfront it was well-known that elliptic curve exponentiation would not bea fast operation, but this result has surprised us. As a result of slow ellipticcurve exponentiation, constructs based on it and essential to the paymentprotocols are slow as well. The proofs of discrete logarithm that underlinethe Untraceable protocol are slower as well. Elliptic curve multiplicationis the the clear bottleneck, with operations speed scaling predictively by thenumber of point multiplications that occur during the computation.

It is also noteworthy that the BouncyCastle library’s digital signature al-gorithm performs much quicker than our own custom implementation ofthis algorithm. It should not come as a surprise that a dedicated library hasa more optimized version than a textbook implementation, but the stock

107

Device Operation Monetary value per secondname per sec e0.01 e0.05 e0.10 e0.50 e1.00

Sony Xpe-ria Arc

Essential

receive15.51 e0.16 e0.78 e1.55 e7.76 e15,51

Untraceable

receive4.07 e0.04 e0.20 e0.41 e2.04 e4.07

Untraceable

with-drawal

13.54 e0.14 e0.68 e1.36 e6.77 e13.54

LG Nexus4 (2012)

Essential

receive28.08 e0.28 e1.40 e2.81 e14.04 e28.08

Untraceable

receive6.31 e0.06 e0.32 e0.63 e3.15 e6.31

Untraceable

with-drawal

16.41 e0.16 e0.82 e1.64 e8.21 e16.41

SamsungGalaxyTab Pro12.2

Essential

receive254,89 e2.55 e12.74 e25.49 e127.45 e254.89

Untraceable

receive12.91 e0.13 e0.65 e1.29 e6.46 e12.91

Untraceable

with-drawal

37.15 e0.37 e1.86 e3.72 e18.58 e37.15

Table 7: Examination of different denomination values

implementation did not appear to be bottlenecked in quite the same way byelliptic curve multiplications as our own. Indeed, verification was quickerthan signature generation. This is likely due to BouncyCastle’s stateful sig-nature implementation that likely omitted repeated computations that werenot avoided by our own stateless implementation. Since our own imple-mentation was similar in style to our implementations of pklog and plogeq

implementations, it suggests that performance can also be increased by re-vising the implementation.

But exactly how many elliptic curve multiplications are necessary in apractical payment system? So far, we have discussed the amount of compu-tations per second, or, the amount of coins that can be processed by a clientsystem per second. But how many of those computations are necessary fora practical payment system?

The amount of computations needed per second is dependant on theamount of monetary value every such computation represents. In otherwords, if a mobile device can process N coins per second, how much mon-etary value do these N coins represent? What is the denomination of asingle coin? The payment protocols of chapter 8 do not assume a specificdenomination - it is an implicit system parameter.

An overview of the impact of the system performance is given in table 7.We have taken the example of three classes of devices; the Sony Xperia Arcas an older, obsolete phone, the 2012 version of the LG Nexus 4 running theDalvik virtual machine as a medium performer, and the Samsung GalaxyTab Pro 12.2 as the device that offered the best performance in most of thebenchmarks. We have set out the performance of these devices in three im-portant benchmarks; Essential coin validation, which gauges performanceof coin validation upon coin withdrawal or the receiving of coins in the Es-sential protocol; Untraceable receive, which tests coin verification uponcoin receiving in payment in the Untraceable protocol; and finally Un-

108

traceable withdrawal, which tests the total performance of the withdrawalsteps in the Untraceable protocol.

We have not made an investigation about how many euros per second isacceptable for a payment protocol. For the sake of the discussion, we willmake the assumptions that most fiat payments are under e25, and that amobile device users tend not to want to wait longer for their devices for5 seconds, which leaves a value of e5 per second. Observing the values intable 7 we see that for the most part, the smaller three denominations do notprovide good matches with this treshold value. Choosing a denominationof e0.50 per coin does put all devices into the range of being able to process5 per second. Only the slowest operation - the withdrawal of coins in theUntraceable protocol, is below this treshold value, but not by much.

The conclusion is that small denominations are out of the question, andthat coins should represent a value of about 0.50 to be in a practical range. Ifthe assumptions for this conclusion hold, then we have established anotherassymetry with fiat money. It is not inconceivable that a practical paymentsystem deals with only coins valued at 0.50, but it does not pose a goodanalogue of the flexibility of cash or even that of debit and credit cards.

We must note that we have not extracted the most optimal performanceout of the devices in the benchmark. All benchmarks were written usingthe BouncyCastle library running in Android’s native virtual machine, andeach computation was timed on a single threaded machine.

Firstly, running cryptography on a managed runtime such as the Dalvikvirtual machine or even ART does not present optimal performance Dalvikand ART are managed runtimes, where object creation is automatic andgenerally less performant than when memory is managed manually. Dalvikfurthermore has to perform a bytecode interpretation step upon executionof code. Choosing a more native implementation of elliptic curve arithmetichas the potential to speed up these computations by a substantial percent-age. One such ”low-level” implementation of elliptic curves is the popularOpenSSL library.

Secondly, we have not made use of a potential optimization in using thetwo or four cores most mobile devices have available. All computationspresented are executed on a single core of every mobile device. Since thesecomputations are based upon repeated cryptographic operations on arraysof different cryptogaphic values, we hypothesize the work of these compu-tations can be freely distributed among these cores. With quadcore mobiledevices becoming increasingly commonplace on the market, this could pro-vide a potential speedup of nearly 4 times.

11.5 concluding remarks

We have presented a payment protocol that is a reasonably close analogy tofiat money. It presents features of being offline, anonymous, and scalable,and it allows for the same payments to be done as using fiat cash. We havealso noted what the differences are between these two systems; the notionsof being offline, being anonymous and system interopability are somewhatdifferent, and our digital payment protocol does not offer as much flexibilityin denominations as fiat money does.

Does this come together as practical payment system? Since fiat cash isconsidered a practical payment system, and we have made a good analogyof it by digital means, we believe this is the case. It is not without its caveats

109

- especially performance is a concern - but we have no problems in recom-mending further developments in this area.

110

12R E C O M M E N D AT I O N S

As is clear from the conclusion, the work in peer-to-peer protocols by nomeans finished. The following areas of research can be remarked as furtherimprovements to the current state of offline peer-to-peer payments. Improve-ments can be made both in implementation work as well as new academicdirections.

12.1 secure element

A critical component of a mobile payment system is the private key eachclient has. It’s what it uses to authenticate to the bank for coin withdrawal;it’s what it uses to authenticate to other users; it’s what is used to encryptthe coins when stored on mobile devices. Possession of a private key wouldallow an adversary to imitate a user completely. We have not made a propo-sition as to how this secret must be secured - in our prototype, the keylived in memory of only limited security. Despite this, we are aware of newdevelopments in the use of secure elements.

Other mobile payment systems make use of the secure element to storesensitive data. We have previously used the example of some Android basedapplications such as Google Wallet that have enjoyed privileged access tofeatures of this security chip, but we have also noted that this functionalityis becoming available to other developers as well. Of particular interest isthe Apple Pay payment system, which uses the secure element to privatelystore several authenticity tokens of other payment information within themobile devices’ processor, with access to the secure element protected bybiometric authentication.

The use of a secure element to perform cryptography would enhancesecurity by disabling read access to the private key. This private key wouldstill be available for writing digital signatures, but the secure element itselfwould execute these operations and the key would not be read into memoryaccesible to other software. We hypothesize that the Essential protocolcould be modified to work with such a secure element that supports digitalsignatures.

The Untraceable and Multi protocols in their present form would notwork with this protocol; presently secure elements do not appear to allowfor lower level computations such as group element multiplication1. Furtherresearch is needed to qualify the capabilities of secure elements and whetheran anonymous payment system can be built from the primitives it offers.Since the secure element performs cryptographic computations seperatelyfrom the main application processor, a new performance assessment wouldalso be necessary.

1 We are not hopeful that secure element processors or their platform APIs will provide accessto such lower level cryptographic operations. The purpose of secure element processors isto enhance the security of already frequently used cryptographic constructs, not facilitate thedevelopment and security of new ones.

111

12.2 usability research

This thesis was mainly focused on the details of the involved cryptographyand their implementation details. Several unrelated questions often croppedup during our implementation and during the interpretation of our results.These questions dealt with what factors constrain the practicality of mo-bile payment system. The practicality of a payment system is not just con-strained by its security features or its speed; it is also constrained with howusable these features are. But what makes a usable payment system?

What would a mobile payment application look like? What metaphorswould it use, if any? How would such security features as secret storageand authentication translate to a user interface? What transaction speedsconstitute a payment system that is pleasant to use? These questions areunaddressed in this thesis, but of incredible importance to complete thepicture of a truly practical payment system.

12.3 implementation improvements

As noted in the conclusions, we believe there is room for performance im-provements for cryptography on mobile devices. Although our current im-plementation provides insight into the performance characteristics of theused cryptographic constructs, and does so within the context of a popularlibrary used for this implementation, there is still more knowledge that canbe gained for this. Using an elliptic curve implementation that uses a morelow-level approach might provide a performance to elliptic curve perfor-mance by removing some of the overhead incurred by the choices presentedin this thesis. We would recommend future work to assess custom imple-mentations or the features and performance of such libraries like OpenSSL2.

Further investigations in implementation improvements should also focuson parallelizing the cryptography work. This was not attempted in thisthesis, but we hypothesize that this should guarantee a relatively simplefour-times speedup on modern mobile devices with four CPU cores.

12.4 lattice-based cryptography

Throughout this work, we have used elliptic curves as the basis for our cryp-tographic operations. The choice for elliptic curves was a practical choice -at the time of writing there are three categories of public key cryptography:those based on the hardness of the prime factorization problem, those basedon the hardness of the discrete logarithm problem in integer groups of primeorder, and those based on the hardness of the discrete logarithm problemin certain groups of elliptic curve points. Of these three, elliptic curves pro-vide an advantage that certain algorithms that weaken the security of theothers are thought unapplicable to elliptic curves. As such, elliptic curvespresent smaller public key sizes. Combined with a plethora of choices forhigh-performance curves, elliptic curves are becoming the default choice inboth practice and academia.

Although elliptic curves may present a good choice from this subset, theylikely do not represent the best choice for a payment system in general.A better mathematical construct may have already been discovered: lattices.Briefly, a lattice L is a group of points within the n-dimensional space Rn that

2 http://openssl.org

112

is represented by a finite set of linearly independent vectors. For example,Z2 is a lattice in R2 represented by vectors (0, 1) and (1, 0). A lattice that isa subgroup of Rn is itself an infinite subgroup, but one can also define finitelattices as subgroups of finite fields instead of the infinite field R.

Lattice-based cryptography is based upon two problems known to behard. The Shortest Vector Problem is the task of finding the shortest vec-tor in a given lattice, and the Closest Vector Problem is the task of finding avector in a lattice that is closest to a given vector. Without extra information,these problems are known to be NP-complete [83].

Lattice-based cryptography has some interesting properties when com-pared to conventional cryptosystems. Firstly, the trapdoor function uponwhich it is based is proven to be hard, whereas the other cryptosystems’trapdoors are assumed to be. Secondly, it is known that quantum comput-ers can be used to break conventional cryptosystems, but this is not knownfor lattice-based cryptosystems. Thirdly, lattice systems have been used toenable fully homomorphic cryptosystems [50], which has potential as a ba-sis for fundamentally different and divisable payment systems. Lastly, andmost importantly within the context of this work, signature systems basedon lattices allow for very fast verification [61, 53].

The reason verification of lattice-based signatures is so fast is that onlyvery simple algorithms on matrices of small numbers are needed to performa verification. Computations on matrices tend to be embarassingly parallel,many processor cores or GPU cores can be used to speed up verification.Since proof-of-knowledge verification speed is the weak point of the workpresented in this thesis, a lattice-based variety of the computations in thisthesis may present a good way forward in performance.

113

B I B L I O G R A P H Y

[1] Wi-Fi CERTIFIED Wi-Fi Direct : Personal , portable Wi-Fi technology.Technical Report September, 2014.

[2] Ben Adida, M Bond, J Clulow, and Amerson Lin. On the secu-rity of the EMV secure messaging API. Security Protocols, pages1–14, 2010. URL http://link.springer.com/chapter/10.1007/

978-3-642-17773-6_17.

[3] SS Al-Riyami and KG Paterson. Certificateless public key cryptog-raphy. Advances in Cryptology-ASIACRYPT 2003, 2003. URL http:

//link.springer.com/chapter/10.1007/978-3-540-40061-5_29.

[4] C Asmuth and J Bloom. A modular approach to key safeguarding.IEEE Transactions on Information Theory, 1983. URL http://cat.inist.

fr/?aModele=afficheN&cpsidt=9428331.

[5] MH Au, W Susilo, and Y Mu. Practical anonymous divisible e-cash from bounded accumulators. Financial Cryptography and DataSecurity, 2008. URL http://link.springer.com/chapter/10.1007/

978-3-540-85230-8_26.

[6] M Baddeley. Using e-cash in the new economy: An economic analy-sis of micro-payment systems. Journal of Electronic Commerce Research,2004. URL http://www.jecr.org/sites/default/files/05_4_p03_

0.pdf.

[7] L Bahack. Theoretical Bitcoin Attacks with less than Half of the Com-putational Power (draft). arXiv preprint arXiv:1312.7013, 2013. URLhttp://arxiv.org/abs/1312.7013.

[8] Rajesh Krishna Balan, Narayan Ramasubbu, Komsit Prakobphol,Nicolas Christin, and Jason Hong. mFerio: The Design and Eval-uation of a Peer-to-Peer Mobile Payment System. In Proceedingsof the 7th international conference on Mobile systems, applications, andservices, page 291, New York, New York, USA, June 2009. ACMPress. ISBN 9781605585666. doi: 10.1145/1555816.1555846. URLhttp://dl.acm.org/citation.cfm?id=1555816.1555846.

[9] D Balfanz, DK Smetters, P Stewart, and HC Wong. Talking toStrangers: Authentication in Ad-Hoc Wireless Networks. In NDSS,2002. URL ftp://ftp.ccs.neu.edu/.snapshot/charn(0142233589)

_sv_narnia_services_listarchives-src.0/pub/people/crista/

publications/ndss02/ndss02.pdf.

[10] N Ben-Asher, N Kirschnick, and H Sieger. On the need for differentsecurity methods on mobile phones. Proceedings of the 13th Interna-tional Conference on Human Computer Interaction with Mobile Devices andServices, 2011. URL http://dl.acm.org/citation.cfm?id=2037442.

[11] Berg Insight. Mobile Wallet Services. Technical report,2013. URL http://www.berginsight.com/ReportPDF/ProductSheet/

bi-mobilewallet-ps.pdf.

115

http://link.springer.com/chapter/10.1007/978-3-642-17773-6_17




http://cat.inist.fr/?aModele=afficheN&cpsidt=9428331

http://cat.inist.fr/?aModele=afficheN&cpsidt=9428331



http://www.jecr.org/sites/default/files/05_4_p03_0.pdf

http://www.jecr.org/sites/default/files/05_4_p03_0.pdf

http://arxiv.org/abs/1312.7013

http://dl.acm.org/citation.cfm?id=1555816.1555846

ftp://ftp.ccs.neu.edu/.snapshot/charn(0142233589)_sv_narnia_services_listarchives-src.0/pub/people/crista/publications/ndss02/ndss02.pdf



http://dl.acm.org/citation.cfm?id=2037442

http://www.berginsight.com/ReportPDF/ProductSheet/bi-mobilewallet-ps.pdf

http://www.berginsight.com/ReportPDF/ProductSheet/bi-mobilewallet-ps.pdf

[12] DJ Bernstein and Peter Schwabe. NEON crypto. In Emmanuel Prouffand Patrick Schaumont, editors, Cryptographic Hardware and Embed-ded Systems - CHES 2012, pages 320–339. Springer-Verlag Berlin Hei-delberg, 2012. URL http://link.springer.com/chapter/10.1007/

978-3-642-33027-8_19.

[13] JP Berrut and LN Trefethen. Barycentric lagrange interpolation.Siam Review, 2004. URL http://epubs.siam.org/doi/abs/10.1137/

S0036144502417715.

[14] K Bhargavan and C Fournet. Verified interoperable implementationsof security protocols. 19th IEEE Computer Security Foundations Work-shop (CSFW’06), 2007. URL http://ieeexplore.ieee.org/xpls/abs_

all.jsp?arnumber=1648714.

[15] Bruno Blanchet and Ben Smyth. ProVerif: Automatic Crypto-graphic Protocol Verifier User Manual & Tutorial. 2013. URLhttp://scholar.google.com/scholar?hl=en&btnG=Search&q=

intitle:Automatic+Cryptographic+Protocol+Verifier+,+User+

Manual+and+Tutorial#0.

[16] O Blazy, S Canard, and G Fuchsbauer. Achieving optimal anonymityin transferable e-cash with a judge. In Progress in CryptologyAFRICACRYPT 2011, pages 206–223, 2011. URL http://link.

springer.com/chapter/10.1007/978-3-642-21969-6_13.

[17] Bluetooth SIG. Specification of the Bluetooth System, volume 0. 2010.URL https://www.bluetooth.org/docman/handlers/downloaddoc.

ashx?doc_id=229737.

[18] D Boneh. The decision diffie-hellman problem. Algorithmic num-ber theory, 1998. URL http://link.springer.com/chapter/10.1007/

BFb0054851.

[19] D Boneh and M Franklin. Identity-based encryption from the Weilpairing. Advances in CryptologyCRYPTO 2001, 2001. URL http://link.

springer.com/chapter/10.1007/3-540-44647-8_13.

[20] Dan Boneh, Xavier Boyen, and Hovav Shacham. Short Group Sig-natures. In Matt Franklin, editor, Advances in Cryptology - CRYPTO2004, volume 3152 of Lecture Notes in Computer Science, pages 227–242. Springer Berlin / Heidelberg, 2004. ISBN 978-3-540-22668-0. doi:10.1007/978-3-540-28628-8\ 3.

[21] E Brickell and J Li. Enhanced privacy ID: A direct anonymous at-testation scheme with enhanced revocation capabilities. In 6th ACMWorkshop on Privacy in the Electronic Society, pages 21–30, 2007. URLhttp://dl.acm.org/citation.cfm?id=1314337.

[22] Holger Burk and Andreas Pfitzmann. Digital payment systemsenabling security and unobservability. Computers & Security, 1989.URL http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.

1.34.8580http://www.sciencedirect.com/science/article/pii/

0167404889900229.

[23] J Camenisch, JM Piveteau, and M Stadler. An efficient fair paymentsystem. CCS ’96 Proceedings of the 3rd ACM conference on Computerand communications security, 1996. URL http://dl.acm.org/citation.

cfm?id=238193.

116



http://epubs.siam.org/doi/abs/10.1137/S0036144502417715

http://epubs.siam.org/doi/abs/10.1137/S0036144502417715

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1648714


http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:Automatic+Cryptographic+Protocol+Verifier+,+User+Manual+and+Tutorial#0





https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

http://link.springer.com/chapter/10.1007/BFb0054851


http://link.springer.com/chapter/10.1007/3-540-44647-8_13



http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.8580 http://www.sciencedirect.com/science/article/pii/0167404889900229





[24] J Camenisch, U Maurer, and M Stadler. Digital payment sys-tems with passive anonymity-revoking trustees. Journal of Com-puter Security, 1997. URL http://iospress.metapress.com/index/

D33843104R669577.pdf.

[25] S Canard and N Desmoulins. On the implementation of a pairing-based cryptographic protocol in a constrained device. Lecture Notesin Computer Science, 7708:210–217, 2013. URL http://link.springer.

com/chapter/10.1007/978-3-642-36334-4_14.

[26] S Canard and B Schoenmakers. List signature schemes. Dis-crete Applied Mathematics, 154:189–201, 2006. URL http://www.

sciencedirect.com/science/article/pii/S0166218X05002283.

[27] S Canard, C Delerablee, and A Gouget. Fair E-cash: Be Compact,Spend Faster. Information Security, 5735:294–309, 2009. URL http:

//link.springer.com/chapter/10.1007/978-3-642-04474-8_24.

[28] R Canetti and H Krawczyk. Analysis of key-exchange protocols andtheir use for building secure channels. Advances in CryptologyEU-ROCRYPT 2001, 2001. URL http://link.springer.com/chapter/10.

1007/3-540-44987-6_28.

[29] R Canetti, O Goldreich, and S Halevi. The random oracle methodol-ogy, revisited. Journal of the ACM (JACM), 2004. URL http://dl.acm.

org/citation.cfm?id=1008734.

[30] Certicom. Standards for Efficient Cryptography (SEC), 2000.URL http://csrc.nist.gov/groups/ST/toolkit/documents/dss/

NISTReCur.pdf.

[31] R Chang and V Shmatikov. Formal analysis of authen-tication in bluetooth device pairing. FCS-ARSPA07, 2007.URL http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.

1.128.986&rep=rep1&type=pdf#page=45.

[32] D Chaum. Blind Signatures for Untraceable Payments.Crypto, 1982. URL http://sce.uhcl.edu/yang/teaching/

csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF.

[33] D Chaum. Achieving electronic privacy. Scientific American, (August):96–101, 1992. URL http://books.google.com/books?hl=en&lr=

&id=xI_Um3dTTeYC&oi=fnd&pg=PA225&dq=Achieving+electronic+

privacy&ots=iVP9-soO7i&sig=FRc-yS4kr9kWqaMmrgHlwijWPSMhttp:

//books.google.com/books?hl=en&lr=&id=xI_Um3dTTeYC&oi=fnd&

pg=PA225&dq=Achieving+electronic+privacy&ots=iVP9-soO7q&

sig=0r3uPX-Jyu3nHlEBX5nfI0Q6fAs.

[34] D Chaum and E Van Heyst. Group signatures. Advances in Cryptolo-gyEUROCRYPT’91, 1991. URL http://link.springer.com/content/

pdf/10.1007/3-540-46416-6_22.pdf.

[35] D Chaum, C Crepeau, and I Damgard. Multiparty unconditionallysecure protocols. Proceedings of the twentieth annual ACM symposiumon Theory of computing, pages 11–19, 1988. URL http://dl.acm.org/

citation.cfm?id=62214.

117

http://iospress.metapress.com/index/D33843104R669577.pdf

http://iospress.metapress.com/index/D33843104R669577.pdf



http://www.sciencedirect.com/science/article/pii/S0166218X05002283

http://www.sciencedirect.com/science/article/pii/S0166218X05002283







http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf

http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.986&rep=rep1&type=pdf#page=45

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.986&rep=rep1&type=pdf#page=45

http://sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF

http://sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF

http://books.google.com/books?hl=en&lr=&id=xI_Um3dTTeYC&oi=fnd&pg=PA225&dq=Achieving+electronic+privacy&ots=iVP9-soO7i&sig=FRc-yS4kr9kWqaMmrgHlwijWPSM http://books.google.com/books?hl=en&lr=&id=xI_Um3dTTeYC&oi=fnd&pg=PA225&dq=Achieving+electronic+privacy&ots=iVP9-soO7q&sig=0r3uPX-Jyu3nHlEBX5nfI0Q6fAs






http://link.springer.com/content/pdf/10.1007/3-540-46416-6_22.pdf




[36] D Chaum, A Fiat, and M Naor. Untraceable electronic cash.Advances in CryptologyCRYPTO’88, 403, December 1990. doi:10.1007/0-387-34799-2. URL http://www.springerlink.com/index/

10.1007/0-387-34799-2http://link.springer.com/chapter/10.

1007/0-387-34799-2_25.

[37] G Davida, Y Frankel, Y Tsiounis, and M Yung. Anonymity controlin e-cash systems. Financial Cryptography, 1997. URL http://link.

springer.com/chapter/10.1007/3-540-63594-7_63.

[38] A Demirguc-Kunt and L Klapper. Measuring Financial Inclusion:The Global Findex Database. 2012. URL https://openknowledge.

worldbank.org/handle/10986/6042.

[39] T. Dierks and E. Rescorla. RFC5246: The Transport Layer Security(TLS) Protocol. Technical report, 2008. URL http://tools.ietf.org/

html/rfc5246.

[40] W Diffie and ME Hellman. New directions in cryptography. IEEETransactions on Information Theory, 22(6):644 – 654, 1976. doi: 10.1109/TIT.1976.1055638. URL http://ieeexplore.ieee.org/xpls/abs_all.

jsp?arnumber=1055638.

[41] T ElGamal. A public key cryptosystem and a signature scheme basedon discrete logarithms. Advances in Cryptology, 1985. URL http://

link.springer.com/chapter/10.1007/3-540-39568-7_2.

[42] EMV Alliance. EMV Integrated Circuit Card Specifications for Pay-ment Systems - Book 1, Version 4.3. (November), 2011.

[43] EMV Alliance. EMV Contactless Specifications for Payment Systems.Book D(February), 2013.

[44] N Ferguson. Single term off-line coins. In Advances in CryptologyEU-ROCRYPT’93, 1994. URL http://link.springer.com/chapter/10.

1007/3-540-48285-7_28.

[45] Y Frankel, Y Tsiounis, and M Yung. ”Indirect Discourse Proofs”Achieving Efficient Fair Off-Line E-cash. In Advances in Cryptolo-gyASIACRYPT’96, 1996. URL http://link.springer.com/chapter/

10.1007/BFb0034855.

[46] G Fuchsbauer, D Pointcheval, and D Vergnaud. Transferableconstant-size fair e-cash. Cryptology and Network Security, 5888:226–247, 2009. URL http://link.springer.com/chapter/10.1007/

978-3-642-10433-6_15.

[47] V Gaglio, A De Paola, M Ortolani, and G Lo Re. A TRNG exploitingmulti-source physical data. Proceedings of the 6th ACM workshop on QoSand security for wireless and mobile networks, 2010. URL http://dl.acm.

org/citation.cfm?id=1868646.

[48] M Gaud and J Traore. On the anonymity of fair offline e-cash sys-tems. Financial Cryptography, 2003. URL http://link.springer.com/

chapter/10.1007/978-3-540-45126-6_3.

[49] C Gehrmann, CJ Mitchell, and K Nyberg. Manual authen-tication for wireless devices. RSA Cryptobytes, 2004. URLhttp://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.

1.63.7144&rep=rep1&type=pdf.

118

http://www.springerlink.com/index/10.1007/0-387-34799-2 http://link.springer.com/chapter/10.1007/0-387-34799-2_25





https://openknowledge.worldbank.org/handle/10986/6042

https://openknowledge.worldbank.org/handle/10986/6042

http://tools.ietf.org/html/rfc5246

http://tools.ietf.org/html/rfc5246















http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.7144&rep=rep1&type=pdf


[50] C Gentry. A fully homomorphic encryption scheme. PhD thesis, 2009.URL http://cs.au.dk/~stm/local-cache/gentry-thesis.pdf.

[51] Joseph Gillian. Contemporary Abstract Algerbra. 2012.

[52] M Girault. Self-certified public keys. In Advances in CryptologyEU-ROCRYPT’91, 1991. URL http://link.springer.com/chapter/10.

1007/3-540-46416-6_42.

[53] T Guneysu and T Oder. Software speed records for lattice-based signa-tures. Post-Quantum Cryptography, 2013. URL http://link.springer.

com/chapter/10.1007/978-3-642-38616-9_5.

[54] D Hankerson, S Vanstone, and AJ Menezes. Guide to elliptic curvecryptography. 2004. URL http://books.google.com/books?hl=en&

lr=&id=bhMPt3I3J_UC&oi=fnd&pg=PR12&dq=Guide+to+Elliptic+

Curve+Cryptography&ots=NkcWBOI7Yg&sig=Uu1RLyFHQQVtP1hEITj_

jRcqJ-A.

[55] Hany Harb, Hassan Farahat, and Mohamed Ezz. SecureSMSPay:Secure SMS Mobile Payment model. In 2008 2nd International Con-ference on Anti-counterfeiting, Security and Identification, pages 11–17. IEEE, 2008. ISBN 978-1-4244-2584-6. doi: 10.1109/IWASID.2008.4688346. URL http://ieeexplore.ieee.org/lpdocs/epic03/

wrapper.htm?arnumber=4688346.

[56] L Harn, J Ren, and C Lin. Design of DL-based certificateless digitalsignatures. Journal of Systems and Software, 2009. URL http://www.

sciencedirect.com/science/article/pii/S0164121208002616.

[57] E Haselsteiner and K Breitfuß. Security in near field communication(NFC). Workshop on RFID Security RFIDSec, 2006. URL http://ece.

wpi.edu/~dchasaki/papers/SecurityinNFC.pdf.

[58] L. (De Nederlandsche Bank) Hernandez and J.C.M. (De Nederland-sche Bank) Kosse. Cash payments counted in 2012. Technical re-port, De Nederlandsche Bank, 2012. URL http://www.dnb.nl/en/

binaries/FactsheetEN_web_tcm47-292820.pdf.

[59] Els Van Herreweghen and Uta Wille. Risks and potentials ofusing EMV for internet payments. USENIX Workshop on Smart-card . . . , 1999. URL http://static.usenix.org/publications/

library/proceedings/smartcard99/full_papers/herreweghen/

herreweghen.pdf.

[60] C Hewitt. Viewing control structures as patterns of passing mes-sages. Artificial intelligence, 1977. URL http://www.sciencedirect.

com/science/article/pii/0004370277900339.

[61] J Hoffstein, J Pipher, and JH Silverman. NSS: An NTRU Lattice-Based Signature Scheme. Advances in CryptologyEUROCRYPT2001, 2001. URL http://link.springer.com/chapter/10.1007/

3-540-44987-6_14.

[62] E Hufschmitt and J Traore. Fair blind signatures revisited. Pairing-Based CryptographyPairing 2007, 2007. URL http://link.springer.

com/chapter/10.1007/978-3-540-73489-5_14.

119

http://cs.au.dk/~stm/local-cache/gentry-thesis.pdf





http://books.google.com/books?hl=en&lr=&id=bhMPt3I3J_UC&oi=fnd&pg=PR12&dq=Guide+to+Elliptic+Curve+Cryptography&ots=NkcWBOI7Yg&sig=Uu1RLyFHQQVtP1hEITj_jRcqJ-A




http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4688346


http://www.sciencedirect.com/science/article/pii/S0164121208002616


http://ece.wpi.edu/~dchasaki/papers/Security in NFC.pdf

http://ece.wpi.edu/~dchasaki/papers/Security in NFC.pdf

http://www.dnb.nl/en/binaries/FactsheetEN_web_tcm47-292820.pdf

http://www.dnb.nl/en/binaries/FactsheetEN_web_tcm47-292820.pdf

http://static.usenix.org/publications/library/proceedings/smartcard99/full_papers/herreweghen/herreweghen.pdf



http://www.sciencedirect.com/science/article/pii/0004370277900339

http://www.sciencedirect.com/science/article/pii/0004370277900339





[63] T Isshiki, K Mori, and K Sako. Using group signatures for identitymanagement and its implementation. 2nd ACM workshop on DigitalIdentity Management, pages 73–78, 2006. URL http://dl.acm.org/

citation.cfm?id=1179541.

[64] R Kainda, I Flechais, and AW Roscoe. Usability and security of out-of-band channels in secure device pairing protocols. In Proceedingsof the 5th Symposium on Usable Privacy and Security, 2009. URL http:

//dl.acm.org/citation.cfm?id=1572547.

[65] BG Kang, JH Park, and SG Hahn. A certificate-based signaturescheme. Topics in CryptologyCT-RSA 2004, 2004. URL http://link.


[66] GO Karame, E Androulaki, and S Capkun. Double-spending fastpayments in bitcoin. Proceedings of the 2012 ACM conference on Com-puter and communications security, pages 906–917, 2012. URL http:


[67] T. Kasper, D. Oswald, and C. Paar. Wireless security threats: Eaves-dropping and detecting of active RFIDs and remote controls in thewild, 2011.

[68] A Kate and I Goldberg. Distributed private-key generators foridentity-based cryptography. Security and Cryptography for Net-works, 2010. URL http://link.springer.com/chapter/10.1007/

978-3-642-15317-4_27.

[69] Neal Koblitz, A Menezes, and S Vanstone. The state of ellipticcurve cryptography. . . . -Century of Public Key Cryptography, 193:173–193, 2000. URL http://link.springer.com/chapter/10.1007/

978-1-4757-6856-5_5.

[70] LM Kohnfelder. Towards a practical public-key cryptosystem. PhD the-sis, MIT, 1978. URL http://groups.csail.mit.edu/cis/theses/

kohnfelder-bs.pdf.

[71] Nina Kreyer, Key Pousttchi, and Klaus Turowski. Characteristicsof Mobile Payment Procedures. In W.-J. Maamar, Z.; Mansoor, W.;van den Heuvel, editor, Proceedings of the ISMIS 2002 Workshop onM-Services, 2002. URL http://citeseerx.ist.psu.edu/viewdoc/

summary?doi=10.1.1.10.437.

[72] A Kumar, N Saxena, G Tsudik, and E Uzun. A comparative studyof secure device pairing methods. Pervasive and Mobile Computing,2009. URL http://www.sciencedirect.com/science/article/pii/

S1574119209000650.

[73] S Laur and K Nyberg. Efficient mutual data authentication using man-ually authenticated strings. Cryptology and Network Security, 2006. URLhttp://link.springer.com/chapter/10.1007/11935070_6.

[74] L Law, S Sabett, and J Solinas. How to make a mint:the cryptography of anonymous electronic cash. Am. UL Rev.,1996. URL http://heinonlinebackup.com/hol-cgi-bin/get_pdf.

cgi?handle=hein.journals/aulr46&section=38.

120













http://groups.csail.mit.edu/cis/theses/kohnfelder-bs.pdf

http://groups.csail.mit.edu/cis/theses/kohnfelder-bs.pdf

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.437

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.437



http://link.springer.com/chapter/10.1007/11935070_6

http://heinonlinebackup.com/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/aulr46&section=38

http://heinonlinebackup.com/hol-cgi-bin/get_pdf.cgi?handle=hein.journals/aulr46&section=38

[75] L Law, A Menezes, and M Qu. An efficient protocol for authen-ticated key agreement. Designs, Codes and . . . , 2003. URL http:

//link.springer.com/article/10.1023/A:1022595222606.

[76] Renaud Lifchitz. Hacking the NFC credit cards for fun and debit. InHackito Ergo Sum, 2012.

[77] Yehuda Lindell and Benny Pinkas. Secure two-party computation viacut-and-choose oblivious transfer. pages 329–346, March 2011. URLhttp://dl.acm.org/citation.cfm?id=1987260.1987287.

[78] JK Liu, J Baek, W Susilo, and J Zhou. Certificate-Based SignatureSchemes without Pairings or Random Oracles. Information Security,5222:285–297, 2008. URL http://link.springer.com/chapter/10.

1007/978-3-540-85886-7_20.

[79] Z Luo, X Cai, J Pang, and Y Deng. Analyzing an electronic cashprotocol using applied pi calculus. In ACNS ’07 Proceedings of the 5thinternational conference on Applied Cryptography and Network Security,pages 87–103, 2007. URL http://link.springer.com/chapter/10.

1007/978-3-540-72738-5_6.

[80] A Lysyanskaya and Z Ramzan. Group blind digital signatures: Ascalable solution to electronic cash. Financial Cryptography, 1465:184–197, 1998. URL http://link.springer.com/chapter/10.1007/

BFb0055483.

[81] G Maitland and C Boyd. Fair electronic cash based on agroup signature scheme. Information and Communications Secu-rity, 2001. URL http://link.springer.com/content/pdf/10.1007/

3-540-45600-7_51.pdf.

[82] D McGrew and J Viega. The Galois/Counter mode of operation(GCM). Submission to NIST Modes of Operation Process, 2004. URLhttp://siswg.net/docs/gcm_spec.pdf.

[83] Daniele Miccancio and Oded Regev. No Title. In DJ Bern-stein, Johannes Buchmann, and Erik Dahmen, editors, Post-QuantumCryptography, pages 147–191. 2009. ISBN 978-3-540-88701-0. doi:10.1007/978-3-540-88702-7\ 5. URL http://dx.doi.org/10.1007/

978-3-540-88702-7_5.

[84] Maurice Mignotte. How to share a secret. In Cryptography, volume149, pages 371–375. 1983. URL http://dl.acm.org/citation.cfm?

id=359176.

[85] VS Miller. Use of Elliptic Curves in Cryptography. Advances in Cryptol-ogyCRYPTO’85 Proceedings, 1986. URL http://link.springer.com/

chapter/10.1007/3-540-39799-X_31.

[86] Sebastian Modersheim and Catuscia Palamidessi, editors. Theoryof Security and Applications, volume 6993 of Lecture Notes in Com-puter Science. Springer Berlin Heidelberg, Berlin, Heidelberg, 2012.ISBN 978-3-642-27374-2. doi: 10.1007/978-3-642-27375-9. URL http:

//www.springerlink.com/index/10.1007/978-3-642-27375-9.

[87] Steven J. Murdoch, Saar Drimer, Ross Anderson, and Mike Bond. Chipand PIN is Broken. 2010 IEEE Symposium on Security and Privacy, pages

121

http://link.springer.com/article/10.1023/A:1022595222606

http://link.springer.com/article/10.1023/A:1022595222606

http://dl.acm.org/citation.cfm?id=1987260.1987287









http://siswg.net/docs/gcm_spec.pdf

http://dx.doi.org/10.1007/978-3-540-88702-7_5

http://dx.doi.org/10.1007/978-3-540-88702-7_5



http://link.springer.com/chapter/10.1007/3-540-39799-X_31


http://www.springerlink.com/index/10.1007/978-3-642-27375-9

http://www.springerlink.com/index/10.1007/978-3-642-27375-9

433–446, 2010. doi: 10.1109/SP.2010.33. URL http://ieeexplore.

ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5504801.

[88] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system.Consulted, pages 1–9, 2008. URL http://www.vsewiki.cz/images/

archive/8/89/20110124151146!Bitcoin.pdf.

[89] T Nakanishi and Y Sugiyama. Unlinkable divisible electronic cash. In-formation Security, 2000. URL http://link.springer.com/chapter/

10.1007/3-540-44456-4_10.

[90] M Naor and M Yung. Universal one-way hash functions and theircryptographic applications. Proceedings of the twenty-first annual ACMsymposium on Theory of computing, pages 33–43, 1989. URL http://dl.

acm.org/citation.cfm?id=73011.

[91] M Naor and M Yung. Universal one-way hash functions and theircryptographic applications. In STOC ’89 Proceedings of the twenty-firstannual ACM symposium on Theory of computing, pages 33–43, 1989. URLhttp://dl.acm.org/citation.cfm?id=73011.

[92] NFC Alliance. Information technology – Telecommunications and in-formation exchange between systems – Near Field Communication –Interface and Protocol (NFCIP-1), 2013.

[93] NIST. Recommended elliptic curves for federal government use, 1999.

[94] T Okamoto. An efficient divisible electronic cash scheme. In Ad-vances in CryptologyCRYPT0’95, 1995. URL http://link.springer.

com/chapter/10.1007/3-540-44750-4_35.

[95] Christof Paar and Jan Pelzl. Understanding Cryptography. SpringerBerlin Heidelberg, Berlin, Heidelberg, 2010. ISBN 978-3-642-04100-6.doi: 10.1007/978-3-642-04101-3. URL http://link.springer.com/

10.1007/978-3-642-04101-3.

[96] DG Park, C Boyd, and SJ Moon. Forward secrecy and its applicationto future mobile communications security. Lecture Notes in ComputerScience, 1751(2000):433–445, 2000. URL http://link.springer.com/

chapter/10.1007/978-3-540-46588-1_29.

[97] M Pasquet. Secure payment with nfc mobile phone in the smarttouchproject. . . . and Systems, 2008. CTS . . . , pages 121–126, 2008. URL http:

//ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4543921.

[98] C Percival and S Josefsson. The scrypt Password-Based KeyDerivation Function. 2012. URL http://tools.ietf.org/html/

josefsson-scrypt-kdf-00.txt.

[99] K Potzmader, J Winter, and D Hein. Group Signatures on Mo-bile Devices: Practical Experiences. Trust and Trustworthy Com-puting, 2013. URL http://link.springer.com/chapter/10.1007/

978-3-642-38908-5_4.

[100] Key Pousttchi. Conditions for acceptance and usage of mobile pay-ment procedures. MPRA Paper, 2003. URL http://ideas.repec.org/

p/pra/mprapa/2912.html.

122



http://www.vsewiki.cz/images/archive/8/89/20110124151146!Bitcoin.pdf

http://www.vsewiki.cz/images/archive/8/89/20110124151146!Bitcoin.pdf








http://link.springer.com/10.1007/978-3-642-04101-3

http://link.springer.com/10.1007/978-3-642-04101-3





http://tools.ietf.org/html/josefsson-scrypt-kdf-00.txt

http://tools.ietf.org/html/josefsson-scrypt-kdf-00.txt



http://ideas.repec.org/p/pra/mprapa/2912.html

http://ideas.repec.org/p/pra/mprapa/2912.html

[101] N Provos and D Mazieres. Bcrypt Algorithm. static.usenix.org,1999. URL http://static.usenix.org/events/usenix99/provos/

provos_html/node5.html.

[102] M Reveilhac and M Pasquet. Promising secure element alternativesfor NFC technology. In First International Workshop on Near Field Com-munication, 2009. NFC ’09., 2009. URL http://ieeexplore.ieee.org/

xpls/abs_all.jsp?arnumber=5190421.

[103] CW Reynolds. Flocks, herds and schools: A distributed behavioralmodel. ACM SIGGRAPH Computer Graphics, 1987. URL http://dl.

acm.org/citation.cfm?id=37406.

[104] RL Rivest, A Shamir, and L Adleman. A method for obtaining dig-ital signatures and public-key cryptosystems. Communications of theACM, 21(2):120–126, 1978. URL http://dl.acm.org/citation.cfm?

id=359342.

[105] AW Roscoe, C Bangdao, and L Nguyen. Reverse authenticationin financial transactions. In Proceeding of the second InternationalWorkshop on Security and Privacy in Spontaneous Interaction and Mo-bile Device Use, 2010. URL http://www.cs.ox.ac.uk/publications/

publication4043-abstract.html.

[106] Joeri De Ruiter and Erik Poll. Formal analysis of the EMV protocolsuite. Theory of Security and Applications, 2012. URL http://link.


[107] CP Schnorr. Efficient signature generation by smart cards. Jour-nal of cryptology, 1991. URL http://link.springer.com/article/10.

1007/BF00196725.

[108] A Shamir. How to share a secret. Communications of the ACM, 1979.URL http://dl.acm.org/citation.cfm?id=359176.

[109] Adi Shamir. Identity-based cryptosystems and signature schemes. Ad-vances in cryptology, 1985. URL http://link.springer.com/chapter/

10.1007/3-540-39568-7_5.

[110] JH Silverman and J Suzuki. Elliptic curve discrete logarithms andthe index calculus. Advances in CryptologyASIACRYPT’98, 1998. URLhttp://link.springer.com/chapter/10.1007/3-540-49649-1_10.

[111] Smart Card Alliance. EMV and NFC: Complementary Technologiesthat Deliver Secure Payments and Value- Added Functionality, 2012.

[112] M Stadler. Publicly verifiable secret sharing. Advances in Cryptolo-gyEUROCRYPT’96, 1996. URL http://link.springer.com/chapter/

10.1007/3-540-68339-9_17.

[113] M Stadler, JM Piveteau, and J Camenisch. Fair blind signatures.Advances in Cryptology . . . , 1995. URL http://link.springer.com/

chapter/10.1007/3-540-49264-X_17.

[114] Diego Suarez, Joaquin Torres, Mildrey Carbonell, and Jesus Tellez.A new domain-based payment model for emerging mobile com-merce scenarios. In 18th International Conference on Database andExpert Systems Applications (DEXA 2007), pages 713–717. IEEE,

123

http://static.usenix.org/events/usenix99/provos/provos_html/node5.html

http://static.usenix.org/events/usenix99/provos/provos_html/node5.html







http://www.cs.ox.ac.uk/publications/publication4043-abstract.html

http://www.cs.ox.ac.uk/publications/publication4043-abstract.html



http://link.springer.com/article/10.1007/BF00196725

http://link.springer.com/article/10.1007/BF00196725









September 2007. ISBN 0-7695-2932-1. doi: 10.1109/DEXA.2007.127. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.

htm?arnumber=4312987.

[115] GE Suh and S Devadas. Physical unclonable functions for deviceauthentication and secret key generation. In Proceedings of the 44thannual Design Automation Conference, pages 9–14, 2007. URL http:


[116] Gerard Tel. Cryptografie : Van DES tot Chipknip. Technical report,1998. URL http://dspace.library.uu.nl/handle/1874/18938.

[117] YS Tsiounis. Efficient electronic cash: new notions and techniques. PhD the-sis, 1997. URL http://citeseerx.ist.psu.edu/viewdoc/download?

doi=10.1.1.68.160&rep=rep1&type=pdf.

[118] S von Solms and D Naccache. On blind signatures and perfect crimes.Computers & Security, 1992. URL http://www.sciencedirect.com/

science/article/pii/016740489290193U.

[119] B Skoric, P Tuyls, and W Ophey. Robust key extraction from physicaluncloneable functions. Applied Cryptography and Network Security, 3531:407–422, 2005. URL http://link.springer.com/chapter/10.1007/

11496137_28.

[120] CJ Wang, Y Tang, and Q Li. ID-based fair off-line electronic cashsystem with multiple banks. Journal of Computer Science and Technol-ogy, 22(3):487–493, 2007. URL http://link.springer.com/article/

10.1007/s11390-007-9055-1.

[121] Andrew Chi-Chih Yao. How to generate and exchange secrets.In 27th Annual Symposium on Foundations of Computer Science (sfcs1986), pages 162–167. IEEE, October 1986. ISBN 0-8186-0740-8. doi:10.1109/SFCS.1986.25. URL http://ieeexplore.ieee.org/lpdocs/

epic03/wrapper.htm?arnumber=4568207.

[122] T. Ylonen and E. Lonvink. RFC4254: The Secure Shell (SSH) Con-nection Protocol. Technical report, 2006. URL http://www.ietf.org/

rfc/rfc4254.txt.

[123] TH Yuen, W Susilo, and Y Mu. How to construct identity-based sig-natures without the key escrow problem. International Journal of Infor-mation Security, 2010. URL http://link.springer.com/article/10.

1007/s10207-010-0110-5.

[124] F Zhang and K Kim. ID-based blind signature and ring signaturefrom pairings. Advances in cryptologyASIACRYPT 2002, 2002. URLhttp://link.springer.com/chapter/10.1007/3-540-36178-2_33.

124





http://dspace.library.uu.nl/handle/1874/18938



http://www.sciencedirect.com/science/article/pii/016740489290193U

http://www.sciencedirect.com/science/article/pii/016740489290193U



http://link.springer.com/article/10.1007/s11390-007-9055-1




http://www.ietf.org/rfc/rfc4254.txt

http://www.ietf.org/rfc/rfc4254.txt




Documents

DESIGN AND FEASIBILITY OF PEER-TO-PEER MOBILE PAYMENT SYSTEMSessay.utwente.nl/66418/1/thesis.pdf · OF PEER-TO-PEER MOBILE PAYMENT SYSTEMS rick van galen [email protected]