• No results found

Design and feasibility of mobile peer-to-peer payment systems

N/A
N/A
Protected

Academic year: 2021

Share "Design and feasibility of mobile peer-to-peer payment systems"

Copied!
131
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(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

r i c k va n g a l e n

p.f.h.vangalen@student.utwente.nl

(2)

m a s t e r ’s thesis:

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

© November 2014

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

Dr. Andreas Peter (UT)

Dr. Maarten Everts (UT)

Roderick Simons (ING)

(3)

To Dora.

For all her love and words of motivation.

(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 to be paid without 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 a peer-to-peer payment 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 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 to still be very demanding of these mobile devices’ computational power. We wrote a benchmarking application and tested over 30 Android 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

• Benchmark results of a large number of Android devices on crypto-

graphic operations used in the presented payment protocols

(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

9 .3 Mobile connectivity 73

9 .4 Protocol implementation 74

(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 & 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 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

References 115

(8)

Part I

B A C K G R O U N D

(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 the 1980s, 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 devices or purpose-made service technology. In addition, the Bluetooth 4.0 and 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 November 2014, 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

sendingpayments only, and receiving payments is rarely a design goal. Often

special equipment and fees are necessary to receive payments, which halves

the 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 protocol

where receiving payments is just as accessible as sending them.

(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 define mobile payment technology or mobile payment systems as 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 payment system consists of a descrip- tion of communication, along with a set of cryptographic computations 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 preliminary background part

serves as an introduction to the concepts of digital payment systems: sec-

tion 2 deals with identification of parties and responsibilities in payments

and section 3 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 section 4 and other techniques suitable for use in the mo-

bile context in chapter 5. We will then see applications of these techniques

in payment systems; those from literature in chapter 6 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 the experiment part,

in which we will present a chapter on the design of different peer-to-peer

payment protocols (chapter 8) and a chapter detailing the implementation

of a demo application (chapter 9). 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

in chapter 12.

(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 a payee (’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 the payment or transaction. 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 a trusted 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 of money 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

?

Figure 1: A representation of the payment model

(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.

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 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 is transferable if 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 section 6.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

The first security service necessary is authentication between payer and payee,

and both of these parties with the trusted third party. A payer desires to

make 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

(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 be singular. 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 of integrity: 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 as secure 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 users of 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 the confidentiality of payments when com- municated between payer and payee. Confidentiality is not always used in existing 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 prevent eavesdropping.

Another security feature is untraceability. Untraceability decouples trans-

action information from the identity of the payer. A bank can see that one of

its clients withdraws money, but cannot identify which units of money are in

the possession of their clients. This makes it impossible for involved banks

to track payments executed within the system as only the payee knows

about 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 by

which client. This property provides protection for payers in the system in

case the bank is compromised or cannot be trusted. As an example, note that

debit cards do not have untraceability, as issuing and acquiring bank pos-

sess knowledge of the location and timing of payments made and received

(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.

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

using debit cards. Fiat money does 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 an anonymous payment system. An overview of these features

is 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 and

an anonymous payment system.

(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 [28] 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 functions [90] A one-way function is a function f with which it is easy to compute f ( a ) = b given f and a, but it is computationally infeasible 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 important cryptographic property of the one-way function is collision 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 [104] 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 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.

b l i n d i n g [32] Blinding is a technique used to implement untraceability of payments. A payer generates coins during signing, but sends the bank 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 know which coins it has signed, making payments untraceable. The blinding is done in such a way that the payer can afterwards unblind this 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 [35] Double spending detection methods allow a bank to see when a coin has been doubly spent. This is done by cryptographically adding information to payments that will keep secret the identity of the payer the first time it is spent, but will reveal the identity of the payer if a single coin is used in more payments.

Usually, this included information is randomized by a challenge sent to

the payer by the payee during payment. If the bank receives different

(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

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

In addition to these principles, we also need a definition of a coin. 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 unforgeable, 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 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, with some additions and modifications. Each protocol describes three subproto- cols: that of withdrawal in which the payer obtains money from the bank to spend. The payment part 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.

Protocol 1. 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

3. The bank sends the coin to the payer and withdraws the amount from

the payer’s account

(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].

Protocol 2. 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 protocol 2 by transforming it into a protocol that moves

out communication with the bank out of the payment process. Since only

communication between payer and payee is required in this stage, we call

this an offline payment [74].

(19)

Protocol 3. 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.

Protocol 4. 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

4. The payer sends the response

(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

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

(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 are hard 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 functions We assume the role

of one-way functions can be fulfilled by cryptographic hashes. Crypto-

graphic hashes are algorithms that accept an arbitrary amount of data

to generate another, distinct, bit string. This generation has the prop-

erty that, given a hash function application h ( a ) = b, it is easy to

compute h ( a ) , that given b it is infeasible to compute a and infeasible

to compute a distinct a 0 so that h ( a 0 ) = b [91].

(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] and scrypt [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 oracle is 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 the random 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 ∈ G and g aG. 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 -hellman problem This assumption states that there exist cyclic groups G of order q for which holds that, given gen- erator g ∈ G and powers g a , g b of that generator, it is computationally infeasible to compute the value for g ab as long as a, b ∈ Z q are not known.

d e c i s i o na l d i f f i e -hellman problem There exist cyclic groups G of order q for which holds that, given a generator g ∈ G and three el- ements g a , g b , g c , it is computationally infeasible to decide whether c ≡ a · b mod q for any unknown a, b, c ∈ Z q [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

multiplicative integer groups (ElGamal [41]). Increasingly, the public key

(24)

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

-3 -2 -1 1 2 3

(a) y

2

= x

3

− 2x

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

-3 -2 -1 1 2 3

(b) y

2

= x

3

− 2x + 2

Figure 2: Plots of two Weierstrass equations over

R. 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 competing 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 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 defined 1 as the (infinite) set of points that 1) satisfy the equation y 2 = x 3 + ax + b and 2) 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 the Weierstrass equation; different elliptic curves can be obtained by filling in different constants for a and b. An elliptic curve over a field F p of prime size p is defined in the exact same way as an elliptic curve over R; the only additional constraint is that the x and y solutions are elements of F p , and thus the set of elliptic curve points becomes a finite set E.

An elliptic curve E defined over of over a finite field F p 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, though

sufficient for our needs in this thesis.

(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 Figure 3: Illustration of elliptic curve addition

of addition requires the introduction of the the ”point at infinity”; any point that lies at an infinite y coordinate in this plot satisfies this definition. We then 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 the following 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 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 the x-axis. See figure 3. 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]. If R is the addition of two points P and Q with coordinates ( x P , y P ) and ( x Q , y Q ) its coordinates can be computed by the following formulae:

s = y P − y Q

x P − x Q x R = s 2 − x P − x Q

y R = y P + s ( x R − x P )

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

| {z }

k times

It is thought that a version of the discrete logarithm assumption holds for elliptic curve multiplication on at least some elliptic curves. The elliptic curve discrete logarithm states that given an elliptic curve points P and R, where R = 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 some

elliptic curves is computationally infeasible.

(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 modulo n. 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-called observers; 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 identity u that is representable as a unique integer for each user. Each coin signed by the bank is associated with a bank-verified coin identity i during 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 information c:

c = H( other information k i k τ )

Which is then sent to the payee, which can verify the timestamp and other information to be correct. Then, another variable r is 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 { c 1 , r 1 }

and { c 2 , r 2 } . Because both c 1 and c 2 are dependent on the cryptographic

hash of the timestamp the payment was made, these two sets are distinct

(27)

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

r 1 − r 2

c 2 − c 1

= ( i − c 1 u ) − ( i − c 2 u ) c 2 − c 1

= c 2 u − c 1 u c 2 − c 1

= 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 large number k is 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 values a 1 , a 2 , ..., a kZ.

c = Sig sk

payer

(H( a 1 ) , H( a 2 ) , . . . , H( a k ))

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

c 0 =

*( a 1 z 1 = 0 a 1 ⊕ u z 1 = 1 ,

( a 2 z 2 = 0 a 2 ⊕ u z 2 = 1 , . . . ,

( a k z k = 0 a k ⊕ u z k = 1

+

The payee verifies the correctness of this information, and eventually sends it to the bank. If k is large enough, there is a large chance that the bank ends up with a pair of a i and a i ⊕ u, from which it can extract the user u. The bank then has a signature on the hash of this value, proving that u has used the 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 that the bank ends up with a pair of complementary values in this hash and k 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 in 1982 in 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 key d and the payer is 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 payer

wants to have signed by the bank. First, the payer generates the number r

which we call the blinding factor. r must be chosen to be relatively prime

to N. The payer then generates a different message C 0 by computing C 0

(28)

C · r e ( mod N ) which he/she then sends to the bank. We call C 0 the blinded message.

The bank then signs the blinded message using the usual RSA signature scheme, generating a blind signature s 0 ≡ ( C 0 ) d ( mod N ) and returns this to the payer. Now note that s 0 is the result of a permutation of the original message; it is a reversible operation. From the blind signature, the payee can obtain the normal signature s ≡ s 0 · r −1 ( mod N ) . Since s ≡ C ( mod N ) we have a valid signature for the message C while 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 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 system 2 . Since a protocol between both parties cannot be both anonymous and optionally traceable, a mutually trusted third party called a judge is introduced into the payment system [113]. The judge and bank can then run an additional pro- tocol, the link detection protocol, that ties transactions to identities. The term for generating blind signatures using this trusted mutual party is called fair 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.

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

(29)

• Type I: Coin tracing The 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 tracing The 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: G is a multiplicative group of prime order q for which it is hard to compute discrete logarithms; a publicly known element g ∈ G; y = g x , with y and x being the bank’s public and private keys respectively; a function Sig j which represents the judge’s signature scheme, and a function H, a cryptographically secure hash.

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

1 . The payer sends the judge a registration request

2 . The judge chooses a random A ∈ G and αZ q , and computes A 0 = A

α

. A and A 0 represent the two payer’s identities, and the judge stores both. The judge sends two messages h A, Sig j ( A || 0 )i , h α, Sig j ( A || 1 )i to the payer.

3 . The payer computes A 0 = A

α

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

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

2 . The bank verifies the signature and computes z = A x and sends the result to the payer.

3 . The payer computes z 0 = z

α

.

4 . The bank chooses some r ∈ Z q and computes t 1 = g r , t 2 = A r , both of which are sent to the payer.

5 . The payer chooses random β, γZ q . With this, he/she computes the following. t 0 1 = t

β

1 g

γ

; t 0 2 = t

α

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

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

the payer.

(30)

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

The resulting signature is the tuple h A 0 , Sig j ( A 0 || 1 ) , z 0 , t 0 1 , t 0 2 , s 0 i of which the validity can be verified with the judge’s public key on Sig j ( A 0 || 1 ) , and the equivalences g s = t 0 1 y c

0

and A 0s

0

= t 0 2 z 0c

0

. The coupling of identities for A and A 0 by 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 h h p , z p i ; a proof W that this pair is related by z p = h x p with x the bank’s signing key; a second proof V that anonymity revocation is possible. The proof W is computed blindly by the bank: it is computed on a different pair h h w , z w i 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 h h p , z p i and h h w , z w i , thus revoking coin anonymity.

Let G be a cyclic group of prime order q with three elements g, g 1 , g 2G.

Let H be a cryptographic hash function that maps arbitrary strings onto ele- ments of G. The bank chooses a secret xZ q , computes the corresponding public key y = g x , and publishes all parameters but its secret key. The judge chooses a secret key j ∈ Z q and publishes public key y j = g 2 j . The client and bank then run the protocol shown in figure 4 to create two unlinked pairs h h p , z p i and h h w , z w i .

Given a coin h t g , h p , z p , W i , the judge can trace the original revocation parameter d by 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 parameter d, computing

g 1 d j

1

= g 1 g

α

2 = h p

which reveals the coin generated in the withdrawal associated with d.

With each payment, the client associates a proof V that shows h p = g 1 g

α

2 . Since each coin is associated with the value t g = g k (where k ≡ ˜r · γ · δ · x ( mod q )) , the payee can request a value l ≡ k − ( 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 h l, c i , h l 0 , c 0 i for the same coin he can compute α

l

l0

/

c0

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 Traor´e [48].

(31)

Client Bank Authenticate

←−−−−−−−−→

αR Z q Choose unlink factor

h w ← g

α

1

1

g 2

d ← y

α

j the ’revocation parameter’

Proof log

yj

d=− log

g1hw

/

g2

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

Store d

Bank has h h

w

, z

w

i z w ← h w x

Choose nonce ˜r ← R Z q

˜t g ← g ˜r

˜t h ← h w ˜r z w , ˜t g , ˜t h

←−−−−−

γ, δR Z q

h p ← h

α

w Unlink h

p

from h

w

z p ← z

α

w Unlink z

p

from z

w

t g ← ˜tg

γ

y

δ

Proof of knowledge γ, δ (1)

t h ← ˜th

γ

p , z

δ

p Proof of knowledge γ, δ (2)

c ← H ( t g k g k h p k y k z p k t g k t h ) Create coin info

˜c ← c − δ ( mod q ) Blind coin info

− → ˜c

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

← − ˜s

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

W ← h c, s i

coin = h t g , h p , z p , W i Debit client’s account

Figure 4: 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 allow any party within a group to 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 which group 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 a group 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 to disavow 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,

employs a bilinear pairing to gain control of signature output. Its security

(32)

is based on the Strong Diffie-Hellman Assumption, which states that there exist groups G 1 , G 2 with generators g 1 ∈ G 1 and g 2 ∈ G 2 so that it is computationally infeasible given the tuple h g 1 , g 2 , g

γ

2 , g 2

2

) , ..., g 2

q

) i of size q + 2 for an attacker to find a pair h x, g 1

1

/

γ + x

i with x ∈ 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 pair G 1 , G 2 with an isomorphism ψ : G 1 → G 2 and bilinear map e : G 1 × G 1 → G 2 that are both computable.

Select generator g 2 ∈ G 2 and g 1 = ψ ( g 2 ) ∈ G 1 . Randomly select an element h ∈ G 1 \{ 1 } and numbers ξ 1 , ξ 2Z as well as secret γZ.

Set u, v ∈ G 1 so that u

ξ1

= v

ξ2

= h, and set w = g

γ

2 . Finally, define a cryptographic hash function H which maps arbitrary strings onto the integers.

For every ith member in a group of size n, select x i ∈ Z randomly, and set A i = g 1/(γ+x 1

i

) .

Publish the public key h g 1 , g 2 , h, u, v, w i and set every ith user’s group signing key to h A i , x i i . The group manager stores h ξ 1 , ξ 2 i as the master key.

p r o o f -of-knowledge protocol This protocol proves that a group signer knows the pair h A, x i so that A = g

1

1 /

x + γ

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

T 1 = u

α

, T 2 = v

β

, T 3 = Ah

α+β

, δ 1 = x · α, δ 2 = x · β

are computed. Then, blinding parameters r

α

, r

β

, r x , r

δ1

, r

δ2

Z for all these values are chosen. The blinded parameters are computed as follows:

R 1 = u r

α

, R 2 = v r

β

, R 3 = e ( T 3 , g 2 ) 4

x

· e ( h, w ) −r

α

−r

β

· e ( h, g 2 ) −rδ

1

−rδ

2

R 4 = T 1 r

x

· u −r

δ1

, R 5 = T 2 r

x

· v −r

δ2

]

The first part of the proof of knowledge is the tuple h T 1 , T 2 , T 3 , R 1 , R 2 , R 3 , R 4 , R 5 i . An interested verifier responds with randomly chosen challenge c ∈ Z.

The signer computes the values

s

α

= r

α

+ cα, s

β

= r

β

+ cβ, s x = r x + cx, s

δ1

= r

δ1

+ 1 , s

δ2

= r

δ2

+ 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, T 1 , T 2 , T 3 , R 1 , R 2 , R 3 , R 4 , R 5 ) . The signature is provided by the result of the proof: its form is h T 1 , T 2 , T 3 , c, s

α

, s

β

, s x , s

δ1

, s

δ2

i . 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 the R values:

R ˜ 1 = u s

α

· T 1 −c , ˜ R 2 = v s

β

· T 2 −c , ˜ R 4 = T 1 s

x

· u −sδ

1

, ˜ R 5 = T 2 s

x

· v −s

δ2

and ˜ R 3 = e ( T 3 , g 2 ) s

x

· e ( h, w ) −s

α

−s

β

· e ( h, g 2 ) −s

δ1

−s

δ2

·  e ( T 3 , w ) e ( g 1 , g 2 )

 c

The signature is accepted if and only if c = H ( M, T 1 , T 2 , T 3 , ˜ R 1 , ˜ R 2 , ˜ R 3 , ˜ R 4 , ˜ R 5 ) .

Referenties

GERELATEERDE DOCUMENTEN

Zoals vermeld in het artikel 'Rijden onder invloed en politietoezicht' doet de SWOV in samenwerking met de Werkgroep Veiligheid van de Rijksuniversiteit Leiden onderzoek

In conclusion, this prospective questionnaire study identified the factor ‘having a family member affected by PDAC < 50 years of age’ to be associated with cancer worries in the

Een lage voerfrequentie en niet gelijktijdig verstrekken van calcium en fosfor met de rest van het voer kunnen een negatief effect hebben op de P-retentie.. Een hogere

de voerhopper was vrijwel altijd gevuld en wanneer het voer in de hopper onder een bepaald nivo kwam dan werd deze weer bijgevuld.. Verder waren de voerproppen altijd

Bij de moderatiehypothese werd verwacht dat participanten, die in een minder groene omgeving woonachtig zijn, meer positieve invloed van een wandeling door de natuur zouden hebben

This thesis engages with the concept of European Union (EU) member state-building, focusing on issues of internal sovereignty with the case study of Bosnia and Herzegovina

In order to investigate the implementation of servitization, this research will concentrate on paradoxical tensions within the strategical fields of organizational

Specifically, we look at three military ISAF operations: operation ‘Perth’ 5 in July 2006; ‘Spin Ghar’ (White Mountain) in October 2007; and ‘Tura Ghar’ (Sable Mountain)