Design and feasibility of mobile peer to peer payment systems

131  Download (0)

Full text

(1)

D E S I G N A N D F E A S I B I L I T Y

O 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

(2)

m a s t e r’s t h e s i s:

Rick van Galen: Design and Feasibility of Peer-to-Peer Mobile Payment Systems

University of Twente - department of Computer Science Research work was performed at ING Bank N.V., Amsterdam © November2014

s u p e r v i s o r s:

(3)

To Dora.

(4)

A B S T R A C T

Digital payment methods are becoming increasingly popular. The advent of Bitcoin and Apple Pay is an indication that digital payment systems are relevant today and even moreso in the future. However, these payment sys-tems firmly rely on central infrastructures. Many also only bring payments to digital platforms, but lack the possibility for people tobe paidwithout ad-ditional infrastructure. Lastly, privacy for payers is rarely achieved in most current commercial payment systems.

In this thesis, we investigate a novel design of digital payments especially targeted at smartphones and tablets to address the above shortcomings. We name this system apeer-to-peerpayment system because it transfers digital coins from device to device. This design choice enables two distinguishing features: offline payments the sending of payments without a third party -and receiving payments. In this thesis, we represent three protocol designs for such mobile peer-to-peer payment systems, as well as a novel contribu-tion by introducing a method for sharing the responsibility of anonymity protection 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 and assessed technical choices that can be made. It was found that from the available local communication methods, the newly available Wi-Fi Direct medium was preferable to NFC and Bluetooth. The prototype application shows that the right technology is currently available to succesfully imple-ment peer-to-peer payimple-ment 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 to still be very demanding of these mobile devices’ computational power. We wrote a benchmarking application and tested over30Android devices on

their performance in cryptographic computations and payment protocol sce-narios. It was found that the computational performance at present leads to 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 payments without 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 responsibility of payer anonymization

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

(5)
(6)

C O N T E N T S

i b a c k g r o u n d 1

1 i n t r o d u c t i o n 3

2 d 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 5 2.1 Parties and communication 5

2.2 Security properties 6

3 p r o t o c o l p r i n c i p l e s 9 3.1 Online payments 10

3.2 Offline payments 11

4 c r y p t o g r a p h i c p r i n c i p l e s 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 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 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 e l e c t r o n i c c a s h p r o t o c o l s 41

6.1 Chaum’s untraceable electronic cash 41

6.2 Gaud & Traor´e’s payment protocol 42 6.3 Scalable group signatures 44

6.4 Divisible coins 47 6.5 Transferable coins 47

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 49

7.1 EMV 49

7.2 Wireless EMV applications 51 7.3 Proton 51

7.4 Cryptocurrencies 51

ii e x p e r i m e n t 53

8 p r o t o c o l d e s i g n 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 p r o t o t y p e 71

9.1 Basic technology choices 71 9.2 Libraries 72

(7)

9.5 Prototype organization 76 9.6 Storage security notes 79 9.7 User interface 80

iii r e s u lt s 83

10 b e n c h m a r k s 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 d i s c u s s i o n &c o n c l u s i o n s 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 r e c o m m e n d at i o n s 111 12.1 Secure element 111 12.2 Usability research 112

12.3 Implementation improvements 112 12.4 Lattice-based cryptography 112

(8)

Part I

(9)
(10)

1

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

Electronic payments systems have existed for decades. Originally employed as payment methods in telephony cards since the1980s, many banks have

introduced digital smart cards to serve as alternative payment methods. Adoption of electronic payment has sharply increased over the years, and the number of cash payments has corresponingly been dropping for many years [58].

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

Current mobile payment initiatives use the wireless capabilities of mobile devices to communicate payment information. Phones connect to a mobile network, which allows use of SMS and mobile internet services. Further-more, mobile devices can connect to other mobile devices using Bluetooth and 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 dede-vices or purpose-made service technology. In addition, the Bluetooth4.0and Wi-Fi

Direct standards allow for a similar mode of operation for direct commu-nication between mobile devices [17, 1]. There appear to be a plethora of

media available for mobile payments, but few if any systems take advantage of this.

As of November2014, popular application markets show some adoption

of these new wireless communication technologies, in accordance with some predictions that mobile payments will be the biggest impactor in payment business in the coming years [11]. None of the initiatives presently available

in the Netherlands is a complete payment system however; they are prepaid services that do not manage actual money. Nor are we aware of popular payment systems in other countries. This is inconvenient from a user’s perspective; firstly a user needs to manage accounts as well as a cash source for independent payment services, and secondly independent service do not readily 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 on

(11)

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 the category of devices that many people increasingly carry along - and there-fore have readily available to use in payment transactions. We definemobile payment technologyormobile payment systemsas technology enabling digital payments 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 paypay-ment system consists of a descrip-tion of communicadescrip-tion, along with a set of cryptographic computadescrip-tions that facilitate security features. The presented system in this thesis is the result of 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 need to possess?

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

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

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

This thesis is structured into three parts. The preliminarybackgroundpart serves as an introduction to the concepts of digital payment systems: sec-tion2 deals with identification of parties and responsibilities in payments

and section3 provides the reader with conceptual details of payment

sys-tems. The next chapters explore literature that allows us to fill in details of digital payment protocols; generally necessary cryptographic techniques to construct them in section4and other techniques suitable for use in the

mo-bile context in chapter5. We will then see applications of these techniques

in payment systems; those from literature in chapter6 and those currently

on the market in chapter 7. We will then present the design and

consid-erations of our protocol and experiments in system in theexperiment part, in which we will present a chapter on the design of different peer-to-peer payment protocols (chapter8) and a chapter detailing the implementation

of a demo application (chapter9). Finally, we will conclude with a results

part, in which we describe benchmarks and present their results in chapter

11, and discuss some recommendations of further work based on this thesis

(12)

2

D 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 what digital payment systems are. We identify the division of responsibilities in a payment protocol and also define what makes such a system secure.

2.1 pa r t i e s a n d c o m m u n i c at i o n

We define two participating entities in a payment called the payer (also known as ’client’ or ’buyer’ in other literature), the entity that commits to paying a sum of money to apayee(’merchant’, ’shop’), some entity willing to receive a payment, usually but not necessarily in exchange for goods. The money transfer between the parties is named thepaymentortransaction. In many cases, the payer’s and payee’s respective financial service providers participate as third and fourth participants in the protocol [114,74,22,55].

In figure 1 the relations between several entities in the protocols are

shown. The issuing bank is the financial service provider who provides services 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 not be separate; indeed, for simplification we will often make the assumption that this is one entity in the remainder of this paper. If both of these service providers are the same, or act behind some trusted broker, this participant is sometimes considered to be atrusted third party. Furthermore, any payer or payee can interchangeably be a payer of payee in another payment. We define any payer or payee using any of the bank’s services to be the bank’s

client.

Observe that there are two methods ofmoney transfer. One is where the payer 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

?

(13)

some services offered by the bank a processed payment system. Note that processed payment systems by necessity are online systems since payer and payee 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-peer payment, the involvement of banks is not necessary. Payers and payees withdraw money from their bank accounts into their own possession at a different time at which payments occur. An example of a peer-to-peer pay-ment system is the fiat money system.

Apayment systemis composed of a set of protocols that accomplish differ-ent phases in the paymdiffer-ent process. These protocols are the following [22, 36,23,55,43]:

1. Setup phase – performed by the bank

The bank publishes information about its own identity and defines cryptographic parameters used in the system. This phase is run only once during the very start of the protocol.

2. Account setup protocol – performed by the client and the bank

The 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 of its services. This can be seen as the digital equivalent of opening an account.

3. Withdrawal protocol – performed by payer and bank

The payer withdraws money from his bank account. The bank pro-vides the payer with the corresponding amount of money, which can be 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 longer validly spend this money.

5. Deposit protocol – performed by payee and bank

The payee sends money from his/her wallet to the bank. The bank verifies the validity of the money, and credits the payee’s account with the corresponding monetary value.

These definitions are made in such a way that the payment system become an 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 istransferableif it is possible for a client to first receive money (as a payee) and immediately spend this money again (as a payer), without having to contact the bank first [6,74]. As we will see in

section6.5, transferability in payment protocols is not easily accomplished

in digital systems. Payment protocols discussed in this paper do not possess the transferability property unless otherwise noted.

2.2 s e c u r i t y p r o p e r t i e s

(14)

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

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

Thirdly, payments should besingular. Once a payment has been commited to by a payer, he cannot commit to a payment that includes a money unit used in a previous payment again.

The final required security service is that ofintegrity: once a payment is transmitted it cannot be modified in such a way that the payment details of payer, payee and amount transferred can be modified. Nor can additional details of the payment be modified, such as time stamps or the number of times the payment can be repeated.

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

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 assecure pay-ment systems. In principle, the features above are defined to guarantee that no user can illegally obtain money that was not explicitly sent to him or her. Although payment traffic can operate normally in secure payment systems under this definition, its properties only ensure proper operation from the perspective of the bank. Ideally however, security properties of the system should also provide security for the usersof the system. This is because of the fact that, in practice, the bank’s status as trusted third party may be questioned. Additional features can be introduced to alleviate the bank of some responsibilities and limit the trust users need to place in the bank’s operations. We list these additional desired features below.

The first such security feature is theconfidentialityof payments when com-municated between payer and payee. Confidentiality is not always used in existing payment systems. For example, the EMV protocol (see section7.1)

does not use cryptography to make payment communication confidential, instead relying on the physical security of contact smartcards [42] to prevent

eavesdropping.

(15)

Features of secure payment systems

Authentication All parties can have proof that they are con-ducting business with the payer, payee and banks they intend.

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

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

Integrity Once committed, a valid payment cannot be

modified into another valid payment.

Additional features of anonymous payment systems

Confidentiality 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 which identities possess which coins in the system.

Table1: Overview of security features necessary for mobile payment

sys-tems

using debit cards. Fiat moneydoes possess the untraceability property, as banks only know the timing, location and serial numbers of withdrawals and 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 ananonymouspayment system. An overview of these features is given in table1. In this thesis, we will focus on the design and

(16)

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 will first introduce some principles in this chapter. This serves as a conceptual overview, and we will fill in the required concepts. High-level descriptions of some important building blocks for payment protocols is given below.

s e c u r e c h a n n e l s [2 8] Secure channels are prepared communication

chan-nels which have the property that data passed through them cannot be modified or eavesdropped. They are usually established by ap-plying some symmetric cipher to the communication, and are used extensively in devices capable of network communication.

o n e-way f u n c t i o n s [9 0] A one-way function is a function f with which

it is easy to compute f(a) =bgiven f anda, but it is computationally infeasible to compute the inverse f−1(b) =agiven f and b. The irre-versibility of this function allows it to act as a trapdoor. An important cryptographic property of the one-way function iscollision resistance -that it is very hard to find distinct function inputs -that result in the same output. It is not known whether one-way functions truly exist, but many hashing algorithms are considered to be one-way in practice.

d i g i ta l s i g nat u r e s[1 0 4] By signing a message with a private key from

an assymmetric public/private key pair, integrity of the message is preserved. Under the assumptions that the private key is kept secret by the signer and that adversaries cannot otherwise obtain the private key in the employed public-key cryptography scheme, digital 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.

b l i n d i n g[3 2] Blinding is a technique used to implement untraceability

of payments. A payer generates coins during signing, but sends the bank a transformation (called theblindedcoin) of this coin to be signed. The blinded coin is signed by the bank, but the bank does not know which coins it has signed, making payments untraceable. The blinding is done in such a way that the payer can afterwardsunblindthis coin and possess a valid signature on an unblinded coin.

d o u b l e s p e n d i n g d e t e c t i o n [3 5] Double spending detection methods

(17)

Construct Security properties

Secure channels Integrity, confidentiality

One-way functions Integrity

Digital signatures Authentication, integrity, confiden-tiality, non-repudation

Blinding Untraceability

Double spending detection Singularity

Table2: 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 the coin twice.

In addition to these principles, we also need a definition of acoin. In the context of a digital payment protocol, a coin represents the closest analogy of the real-world concept of a coin. It is a piece of data that is indivis-able and unforgeindivis-able, and it corresponds to some monetary value. What data is actually contained in the coin is based on the requirements set by the cryptographic constructs used in the protocol. At bare minimum, the data contained in the coin must uniquely identify each one. In addition to an identifier, a coin will usually consist of cryptographic parameters that help 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 one single 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 Security Agency in1996lists 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, with some additions and modifications. Each protocol describes three subproto-cols: that ofwithdrawalin which the payer obtains money from the bank to spend. Thepaymentpart refers to the transfer of digital money from payer to payee. The deposit protocol defines the process with which the payee redeems received payments at the bank.

3.1 o n l i n e pay m e n t s

The simplest version of a payment protocol with the discussed contructs is one which is fully online, and in which no attempt is being made to obscure any party’s identity. It is described as follows [74]. Please note that in

this and the subsequent sections, we assume the communication channels between payer, payee and bank are secure channels.

Protocol1. Simple online protocol

w i t h d r awa l

1. Payer sends a request for withdrawal to the bank

2. The bank prepares the coin with a digital signature

(18)

pay m e n t a n d d e p o s i t

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 the amount 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 signed receipt 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 the validity of the payments.

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

Protocol2. An untraceable online protocol

w i t h d r awa l

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 amount from the payer’s account

5. The payer unblinds the signed coin pay m e n t a n d d e p o s i t

1. The payer sends the coin to the payee

2. The payee sends the coin to the bank

3. The bank verifies that the coin has not already been sent and that the amount 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 signed receipt to the payee

6. The payee forwards this receipt to the payer

7. Payment is completed

3.2 o f f l i n e pay m e n t s

We can improve protocol2 by transforming it into a protocol that moves

(19)

Protocol3. An untraceable offline protocol w i t h d r awa l

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 amount from the payer’s account

5. The payer unblinds the signed coin pay m e n t

1. The payer sends the coin to the payee

2. The payee verifies the bank’s digital signature

3. Payment is completed d e p o s i t

1. The payee sends the coin to the bank

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

3. The bank registers the coin as spent

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

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

payer.

Protocol4. An anonymous untraceable offline payment protocol

w i t h d r awa l

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 and double spending information

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

5. The bank sends the blinded coin to the payer and withdraws the amount from the payer’s account

6. The payer unblinds the signed coin pay m e n t

1. The payer sends the coin to the payee

2. The payee verifies the bank’s digital signature

3. The payee sends the payer the double spending challenge

(20)

5. The payee verifies the response to the payer to complete the payment d e p o s i t

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 spent coins

(21)
(22)

4

C R Y 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 cryptographic principles can create a secure, offline, anonymous digital payment protocol. However, we have treated the building blocks of these protocols as black boxes. 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 s e c u r e c h a n n e l s

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 traffic through a symmetric cipher (the Advanced Encryption Standard being the most popular choice) using a key exchanged by a predefined key exchange protocol based on public key cryptography. It is also important for their security that the channels are authenticated, for which both protocols also define mechansisms.

In general, a secure channel can be established by first establishing authen-tication, negotiating a secret key. We will discuss authentication in section

5.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 network traffic is the Galois Counter Mode of the Advanced Encryption Standard (AES-GCM) [82]. This method offers both encryption and authentication.

4.2 c r y p t o g r a p h i c a s s u m p t i o n s

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

c r y p t o g r a p h i c h a s h e s a r e o n e-way f u n c t i o n s We assume the role

(23)

Traditionally, the SHA family of hashes is used in integrity checking and as one-way functions. Some concern exists however about the ca-pabilities of modern GPUs or dedicated integrated circuits to process large amounts of hashes to produce hash collisions. Therefore, the

bcrypt[101] andscrypt[98] hashes have been proposed.

r a n d o m o r a c l e m o d e l The random oracle model is often used to prove

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

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

d i s c r e t e l o g a r i t h m p r o b l e m We assume that certain groups exhibit

the 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 (GZ,·), it

is assumed that it is computationally infeasible to find the integer a

given g ∈ Gand ga ∈ G. The discrete logarithm problem is thought to be hard in both multiplicative groups of integers of prime order as well as the additive group of points on certain elliptic curves, amongst others.

c o m p u tat i o na l d i f f i e-h e l l m a n p r o b l e m This assumption states that

there exist cyclic groupsGof orderqfor which holds that, given gen-eratorg∈Gand powersga,gb of that generator, it is computationally infeasible to compute the value for gab as long as a,b ∈ Zq are not known.

d e c i s i o na l d i f f i e-h e l l m a n p r o b l e m There exist cyclic groupsG of

order q for which holds that, given a generator g ∈ G and three el-ements ga,gb,gc, it is computationally infeasible to decide whether

c≡a·bmodqfor any unknowna,b,c∈Zq[18].

4.3 p u b l i c k e y c r y p t o g r a p h y

An encryption scheme is said to be a public key cryptography scheme if it seperates encryption and decryption capabilities in seperate (but related) keys named the public and private key. The public key is freely distributed to anyone, and the private key is kept secret. This division allows the holder of the private key to be the only one capable of decrypting messages that have been encrypted using a private key, or conversely be the only one able to encrypt messages that can be decrypted by anyone. This last property can 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 in

(24)

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

-3 -2 -1 1 2 3

(a)y2=x32x

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

-3 -2 -1 1 2 3

(b)y2=x32x+2

Figure2:Plots of two Weierstrass equations overR. The left plot shows a discontinuous

curve, and therefore its equation is not an elliptic curve. The continuous curve in the 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 the

nature of the operations on elliptic curves, this approach allows for a more efficient keyspace distribution yielding smaller keys for similar security [69].

Furthermore, elliptic curves have long resisted methods that can ease solv-ing simpler versions of competsolv-ing cryptographic schemes [85, 110]. This

is because the most efficient integer factorization and discrete logarithm al-gorithms depend on the notion of primality of integers, and no equivalent notion exists for the points on elliptic curves. Because of these advantages over the more traditional RSA and ElGamal-derived schemes, elliptic curve cryptography has become increasingly popular.

4.4 e l l i p t i c c u r v e a r i t h m e t i c

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

An elliptic curve overRcan be defined1

as the (infinite) set of points that1)

satisfy the equationy2=x3+ax+band2) of which the plot of this function

in the(x,y)-plane contains all points within one curve and there are no gaps between two points. See figure?? for an illustration. This defining elliptic curve equation is called theWeierstrass equation; different elliptic curves can be obtained by filling in different constants for a and b. An elliptic curve over afieldFpof prime size pis defined in the exact same way as an elliptic curve overR; the only additional constraint is that thexandysolutions are elements ofFp, and thus the set of elliptic curve points becomes a finite set

E.

An elliptic curveEdefined over of over a finite fieldFpbecomes an addi-tive groupG= (E,+)under a certain definition of addition. This definition

1 The definition chosen in this section is a simplified one for pedagogical purposes, though

(25)

-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

Figure3: Illustration of elliptic curve addition

of addition requires the introduction of the the ”point at infinity”; any point that lies at an infinitey coordinate in this plot satisfies this definition. We then set this point at infinity to be theadditive identity0 of the group. Ad-dition of three pointsP, Q,Ron an elliptic curve is then defined as in the following way:

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

SinceP+Q+R=0 we haveP+Q=−R, or, the addition of two points on an elliptic curve becomes the inverse of the third point on the curve defined by those two points. The inverse of an elliptic curve point is defined as the elliptic curve point mirrored in thex-axis. See figure3. We refer the reader

to other work for proofs that these definitions of a set and addition indeed forms a cyclic abelian group [54,95]. IfRis the addition of two pointsPand Qwith coordinates (xP,yP) and(xQ,yQ) its coordinates can be computed

by 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 integerkand elliptic curve point we define:

k·P=P+P+. . .+P+P

| {z }

ktimes

It is thought that a version of the discrete logarithm assumption holds for elliptic curve multiplication on at leastsomeelliptic curves. The elliptic curve discrete logarithm states that given an elliptic curve pointsPand R, where

(26)

The name ”discrete logarithm problem” becomes somewhat of a mis-nomer when applied to elliptic curves since the operation thought to be hard is not the taking of a discrete logarithm, but the division of curve points. The term is derived from the analagous discrete logarithm problem in groups of integers modulon. This is because cryptosystems based on el-liptic curve arithmetic and those based on multiplicative arithmetic modulo

n are both varieties of the ElGamal cryptosystem [41]. Since the ElGamal

cryptosystem was first described based on the hardness of the discrete log-arithm problem in integer groups, the same term is used for the division problem in elliptic curve groups.

4.5 d o u b l e s p e n d i n g p r e v e n t i o n

We introduced the concept of double spending prevention in section?? as a means to include identifying information to coins that is only revealed when a coin is spent twice. Identifying information satisfy the properties that a single transaction does not reveal information about the coin or the user, but that a double transaction using a single coin reveals the full identiy of 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 simply incapable of copying coin information, and are extremely difficult to be tampered with. Indeed, Chaum [33] originally proposed equipping

pay-ment devices with so-calledobservers; hardware devices which guaranteed copying would be prevented or would otherwise be noticeable by other par-ties. Since observers are not generally available in mobile devices, we will not consider such solutions in this thesis.

4.5.1 The division method

This is the method used in several electronic cash proposals [48,120] and

was originally proposed by Ferguson [44]. We assume a payment system

that gives users a user identityuthat is representable as a unique integer for each user. Each coin signed by the bank is associated with a bank-verified coin identityiduring the withdrawal phase. The trick is to have a payer gen-erated coin spending message generation depend on some independently checkable variable, such as a timestampτ. This timestamp is included with other transaction information using some cryptographic hash that maps ar-bitrary strings onto the integers H : {0, 1} → Z. This requires a user to compute the double spending informationc:

c=H(other informationkikτ)

Which is then sent to the payee, which can verify the timestamp and other information to be correct. Then, another variableris introduced that couples this cut-and-choose information to a number u representing the spender’s identity.

r=i−cu

A pair of c and r values is included with every payment. Given two seperate payments to process, the bank obtains two sets of values {c1,r1}

and {c2,r2}. Because both c1 and c2 are dependent on the cryptographic

(27)

values with overhelming probability. However, both payments include the same coin informationi. 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 namedcut-and-choosewas used in the original e-cash paper [36]

for double spending detection. We present a simplified version here. A large numberkis defined as well as a cryptographic hash function H : ZZ

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

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

The bank storesc. During a payment, the payee sends the payerkrandomly chosen bits. For each of thekbits sent, the payer sends the following infor-mation to the payee.

c0 =

*(

a1 z1=0

a1⊕u z1=1

, (

a2 z2=0

a2⊕u z2=1

, . . . , (

ak zk=0

ak⊕u zk=1

+

The payee verifies the correctness of this information, and eventually sends it to the bank. Ifkis large enough, there is a large chance that the bank ends up with a pair of ai and ai⊕u, from which it can extract the user u. The

bank then has a signature on the hash of this value, proving thatuhas used the coin twice.

It should be noted that this method carries potentially prohibitive limita-tions with it in practice. khas to be chosen large enough to guarantee that the bank ends up with a pair of complementary values in this hash andk

random numbers need to be generated and stored by the bank. This creates a considerable amount of data for any coin withdrawn in the system, which needs to be stored on the server or by the user for every coin in his/her wallet.

4.6 b l i n d s i g nat u r e s

Blind signatures are a concept that allows some authority to sign messages, without that authority obtaining any information about the message that needs to be signed. As described above, we use blind signatures to have the trusted third party sign coins to be valid, without giving the authority the ability to sign these messages. Blind signatures were introduced by David Chaum in1982in the context of digital payments [32]. His example of blind

signatures using the RSA signature scheme is discussed here.

Suppose the bank is in possession of an RSA private keydand the payer is in possession of the corresponding public keyeand the productd·e=N. Further, the payer has generated a coin transfer messageC, which the payer wants to have signed by the bank. First, the payer generates the numberr

(28)

C·re(modN) which he/she then sends to the bank. We callC0 theblinded message.

The bank then signs the blinded message using the usual RSA signature scheme, generating a blind signatures0 ≡(C0)d(modN)and returns this to the payer. Now note that s0 is the result of a permutation of the original message; it is areversibleoperation. From the blind signature, the payee can obtain the normal signatures≡s0·r−1 (mod N). Sinces≡C (mod N)we have a valid signature for the messageCwhile the bank has no information about the actual coin that is to be spent.

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

4.7 f a i r b l i n d s i g nat u r e s

Blind signatures were conceived by Chaum [32] in the original proposition

for digital cash. Although many works still use blind signatures in the original way, practical implications of blind signatures could cause many problems for a real-world money system. Money, digital or not, is inherently subject in many illegal transactions and crime. Current cash systems can be considered untraceable, since no additional party is involved when cash is exchanged. Nonetheless, authorities and banks can provide some insight when criminal activities end up requiring the use of bank services in the case of money withdrawal or deposit. Blind signatures effectively remove the 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 signatures

would have hypothetically prevented law enforcement to capture a criminal in the example of a Japanese kidnapping case. The perpetrator had max-imized his anonymity as much as was possible, but still had to physically withdraw money from the bank account he had set up to receive the ransom money. The perpetrator’s identity was revealed by security cameras regis-tering his withdrawal from the flagged bank account at an ATM. Should the victim have had access to banking services that dealed with digital cash using blind signatures, the money in his account would be fully untraceable to anyone, and his identity would have remained secret. It is reasonable to fear that should such a fully untraceable payment system be widely avail-able, it would enable (and therefore motivate) many criminal activities that are otherwise not undertaken because of the larger risks involved.

We therefore conclude that a further requirement for a payment system is the ability to selectively reveal the identities of payers in the system2

. Since a protocol between both parties cannot be both anonymous and optionally traceable, a mutually trusted third party called ajudgeis introduced into the payment system [113]. The judge and bank can then run an additional

pro-tocol, thelink detection protocol, that ties transactions to identities. The term for generating blind signatures using this trusted mutual party is calledfair blind signatures. Different requirement sets exist for what features a protocol like this should implement [113]. Stadler et al. [113] and Davida et al. [37]

distinguish two tracing types that may be provided by fair blind signature schemes.

(29)

Type I: Coin tracingThe judge provides the bank with information to efficiently recognize a coin once it is spent. This allows authorities to recognize the target of a transaction.

Type II: Owner tracingThe judge provides the bank with information

to efficiently find the identity of a coin owner. This allows authori-ties to recognize who withdrew a certain piece of cash from his/her account.

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

Fair blind signatures build upon standard blind signatures, and encode additional 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 section

6.

4.7.1 Stadler et al.’s protocol

This scheme is a derivative of Chaum’s original protocol. The following system parameters are chosen: Gis a multiplicative group of prime order

q for which it is hard to compute discrete logarithms; a publicly known elementg ∈ G; y = gx, with y and x being the bank’s public and private keys respectively; a function Sigj which represents the judge’s signature

scheme, and a functionH, a cryptographically secure hash.

A payer registerswith the judge to obtain two identities in the following way.

1. The payer sends the judge a registration request

2. The judge chooses a randomA∈ GandαZq, and computes A0 = Aα. AandA0represent the two payer’s identities, and the judge stores

both. The judge sends two messageshA,Sigj(A||0)i,hα,Sigj(A||1)ito

the payer.

3. The payer computesA0 =Aα

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

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

2. The bank verifies the signature and computesz = Ax and sends the

result to the payer.

3. The payer computesz0 =zα.

4. The bank chooses somer∈Zqand computest1=gr,t2=Ar, both of

which are sent to the payer.

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

the following. t01= tβ1gγ;t0

2=tα2A0γ; the hashc0 =H(m||A0||z0||t01||t02)

where m is a coin message. The payer finally computes the blinded coinc≡β/c0 (mod q)and sends it to the bank.

6. The bank computes the signatures≡r+cx (modq)and returns it to

(30)

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

The resulting signature is the tuplehA0,Sigj(A0||1),z0,t01,t02,s0iof which the

validity can be verified with the judge’s public key onSigj(A0||1), and the

equivalences gs = t01yc0 and A0s0 = t02z0c0. The coupling of identities for A

and A0by the judge to the bank is sufficient for revealing the identity of the signer of coins.

4.7.2 Passive judge protocols

A downside of Stadler et al.’s protocol is that the introduction of a judge in the withdrawal protocol is unpractical. Schemes were found that omitted the judge’s involvement in the withdrawal process, and made the judge a

passive actor, which only needs to be contacted afterwards. Here we present two ways to achieve fair blind signatures on electronic cash with a passive judge.

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 idea

of their proposal is to have three components associated with coins: a pair of group members hhp,zpi; a proof W that this pair is related by zp = hxp

withx the bank’s signing key; a second proofVthat anonymity revocation is possible. The proofWis computed blindly by the bank: it is computed on adifferentpairhhw,zwiand transformed by the client in the appropriate pair.

The proofVis computed entirely by the client. The judge is granted the ca-pability tolinkthe pairshhp,zpiandhhw,zwi, thus revoking coin anonymity.

LetGbe a cyclic group of prime orderqwith three elementsg,g1,g2∈G.

LetHbe a cryptographic hash function that maps arbitrary strings onto ele-ments ofG. The bank chooses a secretx∈Zq, computes the corresponding public keyy=gx, and publishes all parameters but its secret key. The judge chooses a secret keyj∈Zq and publishes public keyyj =g2j. The client and

bank then run the protocol shown in figure4 to create two unlinked pairs

hhp,zpiandhhw,zwi.

Given a coin htg,hp,zp,Wi, the judge can trace the original revocation

parameterdby computing

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

which the bank has stored during coin generation, revealing the original withdrawer of the coin. The judge performs coin tracing by, given a revoca-tion parameterd, computing

g1dj

−1

=g1gα2 =hp

which reveals the coin generated in the withdrawal associated withd. With each payment, the client associates a proofVthat showshp =g1gα2.

Since each coin is associated with the value tg = gk (where k≡ r˜·γ·δ·x

(mod q)), the payee can request a valuel ≡k−cα (modq)from the payer, wherecis an integer based on a unique value like a timestamp or a counter. If the bank obtains two distinct pairshl,ci,hl0,c0ifor the same coin he can computeα≡l−l0/c0c (modq)and compute the revocation parameterd=

yα

j.

(31)

Client Bank

Authenticate

←−−−−−−−−→

α←RZ∗q Choose unlink factor

hw←gα

−1

1 g2

d←yα

j the ’revocation parameter’

Proof log

yjd=−logg1hw/g2=α

−−−−−−−−−−−−−−−−→

Stored

Bank hashhw,zwi zw←hwx

Choose nonce ˜r←RZq

˜

tg←gr˜

˜

th←hrw˜

zw, ˜tg, ˜th ←−−−−−

γ,δ←RZq

hp←hαw Unlinkhpfromhw

zp←zαw Unlinkzpfromzw

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

th←th˜ γp,zδp Proof of knowledgeγ,δ(2)

c←H(tgkgkhpkykzpktgkth) Create coin info

˜

c←c−δ (modq) Blind coin info

˜

c

−→

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

˜

s

←−

s←s˜+γ (modq) Obtain unblinded signature

W← hc,si

coin=htg,hp,zp,Wi Debit client’s account

Figure4: Camenisch et al.’s withdrawal protocol

4.8 g r o u p s i g nat u r e s

Group signatures are a modification of regular digital signatures. Digital signatures allow a single party to sign a message that can be verified by anyone. Group signatures allowany party within a groupto sign a message, of which anyone can verify that this message was signed by a member of this group. In addition, group signatures do not allow a verifier to recognize

whichgroup member signed the original message [34].

The group manager is a party that possesses a master key. The master key 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 member needs to deny signing a message that another group member has signed. The master private key corresponds to agroup public key. Every group mem-ber’s private key is derived from the master key and can be used to sign a message that can pass verification against the group public key. In addi-tion, there is a way for group members todisavow the creation of a group signature, 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,

(32)

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

computationally infeasible given the tuple hg1,g2,gγ2,g

(γ2)

2 , ...,g

(γq)

2 i of size

q+2 for an attacker to find a pairhx,g1/γ+x

1 iwithx∈Z. The authors define

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

s e t u p Define a bilinear group pairG1,G2with an isomorphismψ:G1

G2 and bilinear map e : G1×G1G2 that are both computable. Select generator g2 ∈ G2 and g1 = ψ(g2) ∈ G1. Randomly select an

elementh ∈ G1\{1}and numbersξ1,ξ2∈ Zas well as secret γZ. Setu,v ∈G1 so thatuξ1 = vξ2 =h, and setw =gγ

2. Finally, define a

cryptographic hash functionHwhich maps arbitrary strings onto the integers.

For everyith member in a group of size n, select xi ∈ Z∗ randomly,

and setAi=g1/1 (γ+xi).

Publish the public keyhg1,g2,h,u,v,wiand set everyith user’s group

signing key tohAi,xii. The group manager storeshξ1,ξ2ias the master

key.

p r o o f-o f-k n o w l e d g e p r o t o c o l This protocol proves that a group signer

knows the pairhA,xiso that A=g1/x+γ

1 . Exponentsα,βZare

cho-sen, and the values

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

are computed. Then, blinding parametersrα,rβ,rx,rδ1,rδ2 ∈ Zfor all these values are chosen. The blinded parameters are computed as follows:

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

R4=Tr

x

1 ·u

−rδ1,R

5=T2rx·v

−rδ2]

The first part of the proof of knowledge is the tuplehT1,T2,T3,R1,R2,R3,R4,R5i.

An interested verifier responds with randomly chosen challengec∈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.

s i g n A message M ∈ {0, 1}∗ is signed as follows. The signer executes

above proof-of-knowledge protocol with itself, taking the challenge to be c = H(M,T1,T2,T3,R1,R2,R3,R4,R5). The signature is provided

by the result of the proof: its form ishT1,T2,T3,c,sα,sβ,sx,sδ1,sδ2i.

v e r i f y The verifier is given of the message M, the group public key and

the signature as above. He/she rederives theRvalues: ˜

R1=usα·T1−c, ˜R2=vsβ·T2−c, ˜R4=T1sx·u−sδ1, ˜R5=T2sx·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

(33)

d i s av o wa l The group manager can, given the group’s public key, the

mas-ter key, a message and its signature, checkwhichgroup member signed the message. This makes use of the fact that the value T3 is a linear

encryption of A, T1 and T2. If the signature is valid, the manager

computes Ai=T3/Tξ1

1 ·T

ξ2

2 to reveal the original signer.

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

4.9 s e c r e t s h a r i n g

The technique of secret sharingwas first proposed by Shamir [108] to

dis-tribute a secret among multiple parties in such a way that no information about 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 secretsinto partss1,s2, . . . ,sk, . . . ,snwith the properties that:

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

• If a party obtains at least k parts of the secret, then this party can efficiently compute the original secrets.

A scheme in which k secret shares are shared among n parties, where

k≤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 polynopolyno-mial form

f(x) = a0+a1·x+a2·x2+. . .ak·xk one can find the value for every ai

by performing regression analysis onkpoints on that polynomial3

. There-fore, one can distribute a secret s by constructing a polynomial f(x) =

s+a1·x+a2·x2+. . .+ak·xk witha1. . .ak are randomly chosen integers.

Next, for everyith party to which a secret share is to be distributed, com-pute the pointSi= (i,f(i))on the polynomial, and send this secret share to

the party.

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

4.9.1 The Chinese Remainder Theorem

The Chinese Remainder Theorem states that given a sequence of moduli n1,n2, . . . ,nkwhich are pairwise coprime, and a sequence of integersa1,a2, . . . ,ak,

3 Informally: two points are required to define a line; three points are required to define a

(34)

there is a unique positive integer awhich is a solution to the sequence of modular congruences:

a≡a1 (mod n1)

a≡a2 (mod n2)

. . .

a≡ak (mod nk)

More specifically,acan be computed in the following way:

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

2. For everyni, solve B´ezout’s identityr·ni+s·N

ni =1 for integersrand susing the Extended Euclidean Algorithm. Letei = sn·Ni .

3. Computea=a1·e1+a2·e2+. . .+ak·ek.

The reader is referred to Gillian [51] for more information on the Chinese

Remainder Theorem and proofs of the theorem statement and presented algorithm.

Interpreted in reverse, the Chinese Remainder Theorem states that the in-formation of a positive integeracan besharedin the description ofkmodular congruences. Therefore, the Chinese Remainder Theorem presents a way to divide a secret sinto a (n,k)-treshold scheme by distributing the informa-tion about modular congruences. Several methods to accomplish this have been proposed in literature [4,84]; we will discuss the method presented by

Asmuth and Bloom [4] here.

A (k,n)-treshold Asmuth and Bloom secret sharing scheme is defined by integers 2 ≤ k ≤ n in which k is the amount of shares required to recompute the original secret and n is the total amount of shares to be generated. Pick a sequence of numbers w < m1 < . . . < mn such that

w·(mn·mn−1·...·mn−k+2)> m1·m2·. . .·mk. More specifically, given the

products of sequencesπlowerandπloweras in

m1·m2. . .·mk

| {z }

πlower

·. . .·mn

m1·. . .·mn−k+2·. . .·mn−1·mn

| {z }

πupper

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

Define the product M = m1·. . .·mn. A secret S is then chosen from

(35)

S+α·w> M. Letx =S+α·wand compute the sequences1, . . . ,sk using

the following system of congruences:

x ≡s1 (mod m1)

x ≡s2 (mod m2)

. . .

x≡sk (mod mk)

The secret shares are the tuples hs1,m1i, . . . ,hsk,mki. The value wis

(36)

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 payment protocols. 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 o f f l i n e au t h e n t i c at i o n

During mobile payments, both payer and payeeauthenticatemutually before establishing a secure channel over which to transfer money. The authentica-tion is a necessity because to assure both parties that their transacauthentica-tion occurs between 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 connectivity on 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 ties a payment’s system context too strictly to devices with internet connections and prohibits other point-of-sale devices from functioning as a payee. For a payment system to function reliably and scale better, authentication must not require an internet connection and workofflineinstead.

Public key cryptography is most often employed for authentication. An example is the Schnorr [107] identification scheme, which performs

authen-tication by proving to the other party the possession of some private key corresponding to a previously interchanged public key. The interchange and authentication of this public key for identification is the crucial prop-erty of any authentication system. In online systems, this key is placed in some public directory, or, certificated by a set of predetermined and prede-ployed certificate authorities [70]. In an offline system, users themselves are

responsible for authentication of the public key.

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

5.1.1 Out-of-band authentication methods

Out-of-band authenticationis an authentication mechanism that uses available communication methods outside of the channel that needs to be authenti-cated [9]. In the mobile context, users set up their secure channel in

(37)

For example, suppose that two users perform a key exchange using the Diffie-Hellman protocol [40]. The result is a mutually shared secret, but

based on channel communication alone, the authors cannot verify whether the communication was subject to man-in-the-middle attack by which an adversary has placed him/herself in the middle of the key exchange and acts as a proxy of the communication. To lift this uncertainty, mobile device users can simply manually confirm whether they have agreed to the same key. This model was proposed by Laur and Nyberg [73] and proven secure

in 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 pairing

protocol derived all key entropy from the entered 4-digit PIN code, and

are not considered secure. This is despite the fact that formal verification revealed that the protocol is reasonably secure [31]. The Bluetooth

specifica-tion has since then been updated to proceed with pairing using ephemeral keys 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 or one 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 note

thatsecurity failuresare a problem when it comes to authentication methods where the user simply needs to confirm a value. Security failures occur when a user erroneously rejects an agreed upon value. Kumar et al. con-clude that comparison of numeric values combines high user preference with 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 as visual 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 extra channels (which had low user preference).

5.1.2 Secret exchange mechanisms

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

d i f f i e-h e l l m a n k e y e x c h a n g e[4 0] The Diffie-Hellman key exchange

is a simple secure two-party computation to secretly generate a mutually shared secret based on the computational Diffie-Hellman assumption1

. This assumption is used to exchange a secret as follows:

(38)

Alice Bob choose primeq,

Gof orderq,g∈G

a←RZq

q,G,g,A=ga

−−−−−−−−−−→

b←RZq

B=gb

←−−−−−

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

Where←denotes assignment, and ←Rdenotes a random choice. After

the key is established, it can be used to symmetrically encrypt subsequent communication. Each encrypted subsequent message is implicitly authenti-cated with the knowledge that only both parties possess knowledge of the key.

s e c u r e h a s h c o m m i t m e n t b e f o r e k n o w l e d g e [6 4] [1 0 5] An

al-ternative method is the SHCBK-check protocol. The idea is have one party compute a secret and sending its cryptographic hash to the other party along with acommitmentto the secret value, in the form of a cryptographic hash of another random value. The other party makes a similar commitment to 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 messages originated from the right parties. Finally, the secret value is then transferred encrypted by the public key.

We assume Alice and Bob possess a cryptographic hash function Hand Bob possesses a public/private key pairhpk,ski. Encryption using the pub-lic key of some messagemis denoted{[m]}pk.

Alice Bob

a←RZ,

k←RZ

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

b←RZ

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 unlikely event as the communication without confidentiality or integrity measure-ments in place. After the protocol has completed succesfully, both parties have agreed upon the secret valuek.

Figure

FigureFigure 2   NFC specific Key AgreementThe two devices now discard all bits, where both devices sent the same value and  5: An illustration of how interference creates an unintelligible signalfor an external observer

FigureFigure 2

NFC specific Key AgreementThe two devices now discard all bits, where both devices sent the same value and 5: An illustration of how interference creates an unintelligible signalfor an external observer p.39

References

  1. uses
  2. Android,
  3. Windows Phone
  4. iOS http://resources.infosecinstitute.com/ios-application-security-part-20-local-data-storage-nsuserdefaults-coredata-sqlite-plist-files/
  5. http://bouncycastle.org/
  6. http://akka.io/
  7. http://www.h2database.com/
  8. http://nelenkov.blogspot.com/2013/08/credential-storage-enhancements-android-43.html
  9. http://link.springer.com/chapter/10.1007/978-3-642-17773-6_17
  10. http://link.springer.com/chapter/10.1007/978-3-540-40061-5_29
  11. http://cat.inist.fr/?aModele=afficheN&cpsidt=9428331
  12. http://link.springer.com/chapter/10.1007/978-3-540-85230-8_26
  13. http://www.jecr.org/sites/default/files/05_4_p03_0.pdf
  14. http://arxiv.org/abs/1312.7013.
  15. http://dl.acm.org/citation.cfm?id=1555816.1555846.
  16. ftp://ftp.ccs.neu.edu/.snapshot/charn(0142233589)_sv_narnia_services_listarchives-src.0/pub/people/crista/
  17. http://dl.acm.org/citation.cfm?id=2037442.
  18. http://www.berginsight.com/ReportPDF/ProductSheet/bi-mobilewallet-ps.pdf
  19. http://link.springer.com/chapter/10.1007/978-3-642-33027-8_19
  20. http://epubs.siam.org/doi/abs/10.1137/S0036144502417715
  21. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1648714
  22. http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:Automatic+Cryptographic+Protocol+Verifier+,+User+
  23. http://link.springer.com/chapter/10.1007/978-3-642-21969-6_13
  24. https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737
  25. http://link.springer.com/chapter/10.1007/BFb0054851
  26. http://link.springer.com/chapter/10.1007/3-540-44647-8_13
  27. http://dl.acm.org/citation.cfm?id=1314337.
  28. 0167404889900229.
  29. http://dl.acm.org/citation.cfm?id=238193
  30. http://iospress.metapress.com/index/D33843104R669577.pdf