UNIDENTIFIABILITY AND ACCOUNTABILITY IN ELECTRONIC TRANSACTIONS

(1)

FACULTEIT TOEGEPASTE WETENSCHAPPEN DEPARTEMENT COMPUTERWETENSCHAPPEN Celestijnenlaan 200A, B-3001 Leuven

UNIDENTIFIABILITY AND ACCOUNTABILITY

IN ELECTRONIC TRANSACTIONS

Promotor:

Prof. Dr. ir. B. DE DECKER

Proefschrift voorgedragen tot het behalen van het doctoraat in de toegepaste wetenschappen door

Elsie VAN HERREWEGHEN

(2)

(3)

FACULTEIT TOEGEPASTE WETENSCHAPPEN DEPARTEMENT COMPUTERWETENSCHAPPEN Celestijnenlaan 200A, B-3001 Leuven

UNIDENTIFIABILITY AND ACCOUNTABILITY

IN ELECTRONIC TRANSACTIONS

Jury:

Prof. H. Van Brussel, voorzitter Prof. B. De Decker, promotor Prof. F. Piessens

Prof. B. Preneel Prof. P. Verbaeten Prof. R. Molva

(Institut Eur´ecom, Sophia Antipolis, France) Prof. K. Rannenberg

(Goethe Univ. Frankfurt am Main, Germany)

Proefschrift voorgedragen tot het behalen van het doctoraat in de toegepaste wetenschappen door

Elsie VAN HERREWEGHEN

(4)

Arenbergkasteel, B-3001 Heverlee-Leuven (Belgium)

Alle rechten voorbehouden. Niets uit deze uitgave mag vermenigvuldigd en/of openbaar gemaakt worden door middel van druk, fotocopie, microfilm, elektronisch of op welke andere wijze ook zonder voorafgaande schriftelijke toestemming van de uitgever.

D/2004/7515/63 ISBN 90-5682-525-9

(5)

Acknowledgements

This work has been performed at the IBM Zurich Research Laboratory in cooperation with the Katholieke Universiteit Leuven. I thank my employer, IBM Research, for giving me the opportunity to conduct the research reported on in this work and specifically Michael Waidner, Douglas Dykeman and Matthias Schunter for allowing me to complete part of the final writing ‘on IBM time’.

I am very grateful to Bart De Decker for having accepted to supervise this PhD thesis and for his continuous support, feedback and help. His positive and constructive feedback to my initial PhD plans and proposal contributed to my confidence in this project and helped me take the necessary steps to realize it. I also want to thank him for many fruitful discussions and for his thorough reading of and constructive comments on earlier versions of this work. He also helped me with many practical issues which were difficult for me to deal with remotely. Thank you!

I am grateful to Professors Bart Preneel, Frank Piessens, Pierre Verbaeten, Refik Molva and Kai Rannen-berg who kindly accepted to be members of the jury and to Professor Hendrik Van Brussel for accepting to chair it. I thank Bart Preneel for his in-depth reading and useful comments for improvement of the text and Frank Piessens for advice and help when completing my text.

The following people readily agreed to include co-authored material in this manuscript: Mihir Bellare, Juan Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk, Michael Steiner, Gene Tsudik, Michael Waidner, N. Asokan and Jan Camenisch. I want to thank them for that. Both Asokan and Michael Steiner I want to thank for sharing their initial thoughts on dispute handling with me and for many interesting discussions on the subject. Working with them triggered my interest in fairness and accountability and inspired my later work.

A special word of gratitude goes to Gene Tsudik, with whom I also have had the pleasure to work for a number of years. His encouragement, positive feedback and invitations for cooperation during my first years with IBM have helped me find my way in this international research environment.

Jan Camenisch guided me on the path of anonymous credentials and I am very grateful to him. The Idemix project and our ACM CCS paper have provided me with the inspiration how to extend my earlier work into a PhD. I want to thank him in particular for his readiness, time and patience explaining the workings of a system likeIdemix to a non-cryptographer.

I want to thank many friends and colleagues for lifting my spirits and for motivating words. I cannot list all of them but want to thank in particular Angelo Tosi, Anouschka Van Loon, Anthony Bussani, Klaus Kursawe, Marc Dacier, Muriel Dacier, Liba Svobodova, Marilyne Sousa Petit and Sonja Buchegger. I want to thank my family in Belgium and Indiana — too many names to mention — for their moral support throughout this work, often in emails and phone calls. A special thanks goes to my parents for many years of encouragement and support and for again continuously encouraging me in the course of this particular endeavor.

A big and very special thanks goes to my husband Paolo for his support and encouragement, for putting up with a summer without real vacations, and for taking care of our son Luca when I was working — he made it possible for me to finish this. Seeing Luca come home happy and smiling after various fun outings with pap`a was the best support I could imagine.

(6)

(7)

Abstract

Accountability, the possibility to hold an individual responsible for his actions, is an important aspect of electronic commerce transactions. Public-key signatures and infrastructures are typical means for achieving accountability: a digital signature which can be verified with a certain public key is attributed to the individual to whom the public key is certified to belong — according to a certificate issued by a trusted certification authority. Accountability thus seems to imply identifiability. On the other hand, privacy concerns of users motivate the demand for systems where they can interact with various services in an unidentifiable way. The goal of this work is to demonstrate compatibility of unidentifiability and accountability.

One part of this work deals with the notion of accountability. We illustrate protocol design for ac-countablity with theiKP payment system for secure credit and debit card payments. We then describe a language and framework for supporting accountability claims in payment systems. Using this claim language, we compare two electronic payment protocols with respect to their accountability features. A second part of this work deals with introducing unidentifiability in electronic transactions while pre-serving or even improving accountability. We introduce the notion of liability-enhanced public-key in-frastructure and liability-enhanced certificates in which users take precise liabilities for the certificates they request and issuers take precise liabilities for the certificates they issue. In such an infrastructure, we show that any level of accountability can be achieved even when users act under pseudonyms, i.e., use certificates issued on pseudonyms rather than user identities.

We then introduceIdemix, ananonymous credential system. Its credentials are issued on pseudonyms; different pseudonyms of the same user cannot be linked to each other or to the user; and different uses of the same credential cannot be linked to each other: when a user ‘shows’ a credential, he only proves possession of a credential with certain attributes. At the same time, Idemix allows for enforcement of accountability through its optional features of identity-based registration and de-anonymization; both processes can be assigned to dedicated and trusted entities other than the regular credential issuers. We describe authentication, accountability and linkability characteristics of the variousIdemix building blocks and illustrate how to use these descriptions in analyzing security and unidentifiability features of largerIdemix-based applications. We formulate recommendations for the design of systems with maximal unidentifiability and show that the potential of unidentifiability can be maximized if authentication and accountability requirements are derived from concrete risks.

(8)

(9)

List of Figures

2.1 Generic Model of a Payment System . . . 22

2.2 Keys and Cryptograhic Primitives Used in iKP Protocols . . . 27

2.3 Definitions of Atomic Fields Used in iKP Protocols . . . 28

2.4 Framework ofiKP Protocols . . . 29

2.5 1KP Protocol . . . 30

2.8 The Payment Clearance/Capture Scenario . . . 39

2.9 The Status Inquiry Scenario . . . 40

2.10 ZiP Implementation Architecture . . . 41

3.1 An Example Payment Transaction . . . 49

3.2 Value Transfer Transactions . . . 50

3.3 Semantics of Dispute Statements . . . 54

3.4 Basic Dispute Protocol . . . 57

3.5 SimplifiediKP Protocol . . . 61

3.6 Global States iniKP . . . 63

4.1 Generic Credit Card Payment Protocol . . . 70

4.2 Value Transfer Transactions . . . 71

4.3 SET Payment with On-Line Authorization . . . 74

4.4 3KP Payment with On-Line Authorization . . . 79

5.1 Generic Payment Protocol . . . 88

5.2 Pseudonymized Payment Protocol: On-Line PS, One-Time Pseudonym Certificate . . . . 91

5.3 Pseudonymized Payment Protocol: Off-line PS . . . 93

5.4 Generic Pseudonym Server . . . 97

6.1 Basic Credential System Protocols . . . 107

6.2 De-Anonymization . . . 108

6.3 User, Org, and DeAnOrg Components . . . 112

6.4 User, Org and DeAnOrg Token-Based and Synchronous Interfaces . . . 114 xi

(16)

6.5 An Organization Application . . . 115

6.6 UserCredential Manager . . . 118

7.1 Anonymous Credential System: Overview of Basic Primitives . . . 123

7.2 Anonymous Credential System: Key Material and Parametrized Primitives . . . 124

7.3 Anonymous Credential System: Parameter Types and Contents . . . 124

7.4 Anonymous Credential System: Signed Nym Registration . . . 126

7.5 Anonymous Credential System: Root Nym Registration . . . 127

7.6 Global De-Anonymization Using Local De-Anonymization: V andI Cooperating . . . 141

7.7 Global De-Anonymization Using Local De-Anonymization: V Verifying Linking of Nyms 141 7.8 Example Application: Key Material and Registration . . . 145

7.9 Example Application: Accessing LostFound . . . 145

7.10 Example Application: Local and Global De-Anonymization . . . 153

7.11 A Scenario Illustrating Trust in Accountability and Unidentifiability . . . 162

8.1 Non-Pseudonymous Account-Based Payment Protocol Based on Certificates . . . 167

8.2 Pseudonymous Account-Based Payment Protocol Based on Certificates . . . 171

8.3 Account-Based Payment Protocol Based on Anonymous Credentials . . . 174

8.4 Pre-Paid Payment Protocol Based on Anonymous Credentials . . . 179

9.1 Example Certificate-Based Application: Participants, Key Material and Protocol Flows . 197 9.2 Example Credential-Based Application: Participants, Key Material and Protocol Flows . 199 9.3 Risk/Options Analysis forL . . . 207

(17)

List of Tables

2.1 Comparison of theiKP Payment Protocols . . . 37

2.2 Protocol Flags Used in ZiP . . . 39

3.1 Attributes and Operators of Primitive Transactions . . . 52

3.2 Grammar for the Payment Dispute Claim Language . . . 52

3.3 Information of Players in a CompletediKP Transaction . . . 60

3.4 Mapping Evidence to Dispute Statements iniKP . . . 62

4.1 SET Atomic and Composite Fields . . . 73

4.2 iKP Atomic and Composite Fields . . . 78

5.1 Generic Certificate Format . . . 101

7.1 Example Application: Parameters of Assertions and Primitives . . . 146

7.2 Certificate Contents for the LostFound Example . . . 159

8.1 Non-Pseudonymous Account-Based Payment Protocol Based on Certificates . . . 168

8.2 Pseudonymous Account-Based Payment Protocol Based on Certificates . . . 172

8.3 Account-Based Payment Protocol Based on Anonymous Credentials . . . 175

8.4 Pre-Paid Payment Protocol Based on Anonymous Credentials . . . 180

9.1 Example Certificate-Based Applicaton: Certificate and Message Contents . . . 197

9.2 Example Certificate-Based Application: Evidence and Provable Statements . . . 198

9.3 Example Credential-Based Application: Certificate and Message Contents . . . 200

9.4 Example Credential-Based Application: Evidence and Provable Statements . . . 201

(18)

(19)

Chapter 1

Introduction

1.1 Introduction

A public-key infrastructure (PKI) can offer a secure and scalable solution for authentication and secure communication in electronic transactions. Using public-key certificates issued by a trustworthy certifi-cation authority, participants in an electronic transaction can authenticate to each other without prior sharing of a secret; this authentication also allows participants to establish communication channels with various security properties such as authentication, integrity-protection and confidentiality-protection of the data exchanged.

An important application of public-key cryptography and public-key infrastructures is the digital sig-nature (short: signature) application. A digital signature is generated using the private signature key belonging to a signer and can be verified using the public key associated with this private signature key. A digitally signed (short: signed) message or other piece of information allows to securely attribute the signed information to one possible originator, namely the unique holder of the private signature key. This feature forms the basis for claims of non-repudiation, the impossibility for the signer of a docu-ment to later successfully repudiate having signed that docudocu-ment. Throughout this work, we will rather use the termaccountability, i.e., the possibility to hold the sender (signer) of a message accountable or responsible for the message and its contents.

Accountability requires identifiability, i.e., the possibility to assign a signature key, and thus a signed message, to a particular individual, organization or company. To this end, conventional public-key certificates bind an identity or name to a public key; this allows the party successfully verifying a signature with this key to assign the signed contents to the entity with that name or identity.

While the cryptographic technology supporting accountability exists, many public-key based applications and infrastructures cannot claim this property. It is indeed far from trivial to design an operational system where actions and messages can be said to be accountable: the supporting public-key infrastructure has to fulfil a number of stringent security and accountability requirements (see Sections 1.2.3, 1.3.2 and 1.3.3). Also, accountability requirements have to be explicitly stated and taken into account in the transaction protocol design.

On the other hand, privacy concerns of users in e-commerce and other electronic transaction environ-ments motivate the demand for protocols and systems where users can interact with various servers and organizations without their identity becoming known. Designing a secure and accountable system where actions can be unidentifiable may then seem like an impossible task, as accountability requires identification of an actor.

This work deals with accountability and unidentifiability in electronic transactions. It discusses the design and analysis of systems based on accountability requirements and explores the potential for unidentifiability in systems with high requirements on security and accountability.

(20)

The remainder of this chapter is organized as follows. In Section 1.2, we first introduce some terminology related to accountability and unidentifiability. Section 1.3 then discusses requirements and challenges related to achieving accountability in electronic transactions. Section 1.4 discusses different concepts and techniques that can introduce unidentifiability in electronic transactions while preserving or en-abling accountability properties. Section 1.5 discusses incentives and disincentives for accountability and unidentifiability. Section 1.6 describes the scope and goal of this work.

1.2 Terminology

In this section, we introduce some terminology and concepts related to unidentifiability and accountability as they will be used in this work.

1.2.1 Identity-Based vs. Attribute-Based Authentication and Authorization

Authentication is a service related to identification. Entity authentication as well as message authenti-cation corroborate the identity of an entity (e.g., a person, a computer, etc.) associated with a commu-nication channel or with a specific piece of information [91].

In traditional systems for access control, an entity’s authorization to perform an action or to act under a certain role is typically derived from such identity authentication. This identity may have a global meaning, or it may only have a meaning to some participants in the system; it may also be apseudonym as defined in the next section. Inidentity-based authorization, the authorization decision is thus based on the authenticated identity or pseudonym; the verifying (and authorizing) party derives necessary access rights from this identity or pseudonym.

Identity authentication of an authenticating party A to a verifying party (also calledrelying party)V can be achieved using a digital certificate certifying the linking betweenA’s public key and his identity; this linking is certified (signed) by a trusted entity such as a certification authority CA. A can now convinceV of his identity by proving knowledge of the associated private key.

In this work, we will also discuss attribute authentication and attribute-based authorization. With attribute authentication, an authenticating partyAconvinces a verifying partyV of the fact thatAowns certain attributes; these attributes may but need not be unique to A and need not correspond to an identity. Examples of attributes are the right to access a certain resource or the age of the attribute holder. We will use the term ‘proving ownership of an attribute’ both for proving the exact value of an attribute (access right, age) as for proving a property of the attribute (e.g., age≥18).

As is the case with identity authentication, the fact thatA owns an attribute needs to be certified by a trusted authority. Using conventional certificates, this certification is realized by including the attributes in A’s certificate. Using credentials as defined in Section 1.2.2, it is realized in a similar way, i.e., by the certificate issuer signing a piece of information including the attributes and a public value associated withA’s secret. As with certificates,Acan then prove ownership of an attribute certified in a credential by proving knowledge of this secret.

Attribute-based authorizationwill then allowAto perform an action, such as accessing a resource, based on the ownership of one or more attributes, rather than on his identity or on access rights derived from it by a relying party.

In the context of attribute-based authorization, the term ‘attribute’ covers more than only the fields in a certificate or credential carrying that name. It may stand for any property of the certificate or credential, other than the identity of the certificate holder, from which the relying party can derive necessary privileges. E.g., the fact that the certificate or credential used for authentication is signed by a certain issuer (i.e., can be verified using a specific public key) may be considered to be an attribute. Also, attribute-based authorization does not exclude that the certificate or credential may contain an identity or pseudonym; only, the authorization decision is not based on it. E.g., in the Secure Electronic Transactions (SET) [104] protocol for credit card payments, the customer’s account number is not visible

(21)

to the merchant receiving the payment; if the merchant’s acceptance of the payment is based only on the certificate being valid and having been issued by a trusted bank, the merchant’s authorization decision (in this case, the decision to grant access to a paid service or to deliver the purchased goods) is attribute-based.

1.2.2 Certificates and Credentials

A public-key certificate (short: certificate) is a piece of information signed by a trusted entity such as a certification authorityCA. It binds the identity or name of a certified entity (A) and possibly additional relevant information (attributes) pertaining toAto the public key corresponding to a private key owned byAand known only toA. The certified key can be a public encryption key: in this case, information encrypted withA’s public key can be decrypted only usingA’s private decryption key. Most often, we will talk about certificates certifying public signature keys: in this case,Aauthenticates toV (convinces a verifier V of his identity and/or of owning certain attributes) by proving ownership of the private signature key, e.g., by digitally signing a piece of information with that private key. V verifies the authentication using the signed information and the public key inA’s certificate. In order to verify the authenticity of this certificate (and ofA’s public key), V needs an authentic copy of the CA’s public key. In real life, public-key infrastructures often consist of manyCA’s organized in a hierarchical or flat manner; forV to obtain an authentic copy of the public key of theCAcertifyingA, that public key may need to be certified by an entity (anotherCA)V trusts.

Rather than a real name or globally meaningful identity, public-key certificates may contain a local identity. A local identity is an identity which has a meaning only to specific parties in the system or is valid only for a short period of time. Some examples of local identities are: an employee number in a certificate issued by an employer; an account number in a certificate issued by a bank; or a temporary login name assigned to an employee allowing the employee to fill out this year’s employee opinion survey. When a local identity is used with the goal to hide the authenticating entity’s real name or global identity from certain parties in the system or from outsiders, we will call the local identity apseudonym(see also Section 1.2.4); a certificate certifying it is called apseudonym certificate. The public key in a pseudonym certificate can be considered to be the pseudonym; a pseudonym certificate may but need not carry an additional identifier.

A pseudonym certificate can be used for identity-based as well as for attribute-based authorization. In the first case, authorization is based on the pseudonym; this requires that the relying party can link the pseudonym to another identity or to privileges. In the latter case, authorization is based on accompanying attributes in the certificate, and the relying party need not have any prior knowledge about the pseudonym. Note that the relying party can link all the transactions with the same pseudonym certificate to each other (and to the pseudonym), even if it cannot link the pseudonym to an identity. Digital credentials can generally be defined as the digital equivalent of paper documents or other objects traditionally used to establish a person’s identity, attributes and privileges [28]. As such, a public-key certificate is a special type of digital credential; we will, however, use the term credential in a more restricted sense. The credentials discussed in this work and introduced in Section 1.4.5 belong to the class of anonymous credentials [39, 36, 40, 49, 86, 31]. Like a certificate, an anonymous credential is a certified piece of information allowing its owner to prove ownership of an identity and/or attributes contained in the certified data. Unlike a certificate, an anonymous credential allows its owner, A, to provide such a proof without the need for the verifier, V, to see or obtain (a copy of) the credential; A can authenticate (provide such a proof) multiple times without V being able to link the various authentications to each other.

1.2.3 Belief, Provability, Accountability and Liability

According to definitions by Kailar [75], an individual is said tobelieve a statement if he is convinced of that statement; and aproof of a statementx is a set of statements that can collectively convey the

(22)

validity ofxto an audience. Accountability is the property whereby the association of a unique originator with an object or an action can be proved to a third party (i.e., a party other than the originator and the prover).

We illustrate these definitions with some examples. A may authenticate (sign) a message to V using the private key corresponding to a public-key certificate issued by theCA. In order to believe that the message is signed byA,V needs to successfully verify the signature on the message with the public key inA’s certificate, and also has to verify the authenticity ofA’s certificate; the latter verification is done using an authentic copy of theCA’s public key. ForV to trust that a message signed with A’s private key (more precisely: verified usingA’s public key) can indeed be attributed toA,V also needs to trust theCAas well as the overall certificate infrastructure (see also Sections 1.3.2 and 1.3.3).

The message signed byAmay also provide evidence to a third party if this party also trusts theCAand the certificate infrastructure. I.e., using the signed message,V is able to prove to a third party thatA made the statement contained in the message, or: Ais accountable for the signed message. Note that a digital signature can prove a fact (‘A’ made the statement) to a third party in the sense of convincing that party of that fact; it does not prove an absolute statement.

The notion of accountability as defined here is related to the property of non-repudiation, which is a service or property preventing the denial of previous commitments or actions [91]. We prefer to use the term accountability because it avoids the connotation of disputes. In fact, accountability is needed in many situations where the ‘accountable’ entity is in principle trusted not to repudiate any of its actions. E.g., the railway company has little incentive in repudiating the fact it sold me a ticket; its accountability for that fact merely helps me to convince my employer’s accounting department to reimburse my travel expenses.

Public-key based digital signatures are often attributed the property of accountability. Indeed, they provide strong evidence of an association between the signature and the public signature key. In order to convince a court or arbiter of a person’s accountability for that signature, it should also be established beyond reasonable doubt that the person to whom the public key is claimed to belong is indeed the only entity who could have made (or triggered the making of) the signature; that this person could verify and understood the contents and meaning of the data being signed; and that he was aware of possible consequences and interpretations of signing these data with this key. For this to be the case, many requirements have to be fulfilled safeguarding the security of the various procedures in the public-key infrastructure, including the generation of public/private keys, the generation of signatures, and the certification and registration of public keys by certification and registration authorities (see also Section 1.3.2). In addition, measures have to be put in place that protect individuals against accountability for signatures with a stolen signature key; this requires services for revoking signature keys. Also, an entity relying on the accountability feature of a digital signature which it receives today wants to be able to prove at any point in the future that the associated signature key was not revoked at the time of signature generation; this requires trusted timestamping or notary services [91].

Liability, or obligation by law, assumes accountability; in our interpretation, the term liability implies a quantification of consequences for certain accountable facts. An individual is liable to perform a certain quantifiable action (such as paying an amount of money) if he can be held accountable for a certain fact, and if the quantifiable action is theliability valueassociated with this fact. The association between the accountable fact and the liability value needs to be known to and accepted by the individual in order for accountability and liability to be fair. The acceptance may be enforced by society, laws or the judicial system; e.g., a detention sentence is a generally accepted liability value for certain criminal behavior. In other cases, the acceptance needs to be more explicit. When registering a digital signature key and obtaining a public-key certificate, a person may accept a certain liability for data or transactions signed with that key (we will useliability also as a short form forliability value). E.g., when the public-key certificate allows the user to sign electronic payments, the user may accept a maximum liability for payments made with this certificate, thereby protecting himself against the consequences of the private key being stolen. When the public-key certificate allows the user to sign electronic contracts, the user’s liability upon digitally signing a contract with that key may consist in being subject to the same dispute resolution procedure in court as is applied for paper-based contracts.

(23)

Liability applies tolegal entities. We consider as a legal entity any entity that can be held accountable and liable before a court. This can be a natural person, an organization or a company.

1.2.4 Pseudonymity, Anonymity, Linkability and (Un-)Identifiability

Apseudonymis an identifier with a local meaning. A user may choose or create his own pseudonym(s); or, organizations issuing certificates or credentials may create pseudonyms for users. Some pseudonyms are created based on inputs both from the user who will act under the pseudonym as from an organization registering the pseudonym [31].

A transaction carried out under a pseudonym (e.g., using a pseudonym certificate) is a pseudonymous transaction. As previously discussed, the use of pseudonyms assumes that it is not trivial, for at least some participants in the system or for outsiders, to derive a real identity from the pseudonym. According to the definition of anonymity in the following paragraph, the user in a pseudonymous transaction is anonymous towards the party or parties that cannot map the pseudonym used to the user’s real identity. An entity can be said to beanonymoustowards another entity in a particular transaction if his identity in that transaction is concealed from that other entity. Anonymity of an entityAis thus always considered and specified with respect to one or more specific other entities in the transaction. E.g., in an electronic payment transaction, a user may act under a pseudonym under which he is known by his bank but which has no meaning to the merchant; in the transaction, which is pseudonymous, the user is anonymous towards the merchant but not towards the bank.

Factors other than the transaction protocol and its use of pseudonyms influence whether a user’s identity indeed remains concealed from a relying party, i.e., whether the user remainsunidentifiableto the relying party. In the above payment example, one can describe many scenarios through which the merchant could obtain the user’s real name associated with a pseudonym. The user may inadvertently fill out his phone number in an optional field of an online form presented by the merchant during the transaction; or, the merchant may be able to derive the user’s real identity from network or addressing information obtained during the transaction. Also, the merchant may recognize the pseudonym from a previous transaction where such identification occurred; or, the bank may collude with the merchant and reveal the real name associated with a pseudonym used. In some cases, the relying party has access to the list of real names of users owning a certain certificate or credential, without being able to map an authentication using such a certificate or credential to a specific user. An example is a voting procedure where the voting server knows the list of voters but another, trusted, entity has issued the anonymous voting credentials to individual users. A user’s vote is of course anonymous only within the (potentially small) set of voters; in the extreme case of the number of voters being only one, the unique user’s vote is fully identifiable despite the use of the anonymous voting process.

In the following, we will use the termanonymitytowards an entity to indicate an intrinsic property of a transaction or protocol; if a transaction is anonymous towards a certain party then it allows the user to remain unidentifiable towards that party in the absence of identifying factors. Examples of identifying factors are a bad choice of parameters (e.g., the user filling out his phone number), possible identification through linking (e.g., the same pseudonym is used in another, identifiable transaction), parties colluding and sharing information (e.g., the bank revealing a customer’s real name to the merchant), or system parameters such as the size of the set of users within which anonymity is achieved (e.g., a very small number of voters in the voting process). In this definition, the voting process with one voter remains anonymous even if the unique user’s vote is identifiable.

Linkability between anonymous actions may thus have a high impact on the identifiability of each of the individual actions. In the payment example, the merchant may not only identify a user through linking with another, identifiable, transaction under the same pseudonym; also, the correlation of items purchased in both transactions together gives the merchant more information about the user’s buying pattern and preferences; when combined with yet more purchasing transactions, such a detailed profile may ultimately identify the user.

(24)

parameters, linkabilities, participants’ behaviors and system parameters into account. Thus, an anony-mous transaction can be identifiable because of transaction or system parameters; it can also become identifiable at a later point in time due to linking with other transactions or information, or because of information sharing between other entities. We cannot define identifiability as a property with a Boolean value, as identifying factors may merely increase a chance of identification; also, we will not claim to have an exact measure of identifiability as we cannot quantify and take into account all of the potential identifying factors associated with a transaction. A transaction’s (level of ) (un)identifiability will be discussed only on a relative scale and implies a comparison with other transactions regarding intrinsic anonymity and taking into account a set of identifying factors which may have a varying impact on the chance of identification. E.g., a transaction allowing identity escrow by a trusted party has a lower level of unidentifiability than a similar transaction without identity escrow. Or, the payment transaction where a user simply has to trust his bank not to reveal the user’s name to the merchant can be claimed to have a lower level of unidentifiability than a similar transaction where only a dedicated trusted entity can de-anonymize a payment. The latter claim is true if that entity is trusted more than the bank with respect to de-anonymization; it certainly holds if the de-anonymization is verifiable and accountable (i.e., the fact that de-anonymization occurred can be proved, and the conditions for de-anonymization are con-crete and verifiable). Also, the payment transaction where the user fills out his street name and postal code has a lower level of unidentifiability than the same transaction without the use of this parameter. The protocols and systems presented in this work heavily build on the notions of pseudonymity, ano-nymity, linkability and unidentifiability.

1.3 Accountability in Public-Key Based Systems

In this section, we discuss a number of issues and challenges related to accountability in public-key based systems and protocols.

1.3.1 Protocol Design: Authentication vs. Accountability

In an electronic commerce transaction, a party receiving a protocol message needs to be able to rely on its authenticity and origin. If the message is authenticated by the originator, this can convince the relying party of a certain fact; typically, this fact brings the protocol to a following state with specific protocol instance values. E.g., a merchant’s confirmation message containing a price of $10 may bring an electronic purchasing protocol to an ‘order confirmed’ state and may convince the buyer that the merchant is willing to ship the order for that price.

If the public-key infrastructure underlying the particpants’ certificates supports accountability (see also Sections 1.3.2 and 1.3.3), it is easily assumed that the use of a digital signature to authenticate the protocol message allows the relying party to prove the same facts to other parties.

Examples have shown that care has to be taken with this assumption. Firstly, the relying party may hold prior beliefs that are necessary to construct the new belief based on the new message; these prior beliefs may be based on the contents or the temporal order of previous protocol messages, or may include other prior knowledge by the relying party; they may however not be shared by, or be provable to, a third party. Thus, in order for a third party to derive the same belief from the digitally signed message, the message should be self-contained.

Let us illustrate this notion with some examples. In a payment protocol, a payer signs a payment message, including a price, a description of the paid goods, and a transaction reference; the payee confirms the payment by sending back a signed message including the transaction reference. Between payer and payee, it is clear which goods were bought and sold at which price, and the payee has evidence of the payer’s commitment to buying the specified goods at the specified price. However, if the payee’s reply does not contain the price or goods description, it does not allow the payer to prove to a third party the payee’s commitment to these features.

(25)

Another example can be found in a payment system allowing refunds. Let us assume that the system allows for the total value of a payment to be modified by more than one (partial) refund, and that each refund is represented by a timestamped message signed by the payee and sent to the payer; with this message, the payer can get the actual refund from the bank. A reasonable expectation is for the payer to be able to convince a third party of the total value, at a specific point in time, of the payment associated with that transaction; this total value is calculated as the difference of the initial payment value and the sum of all the refunds up to that point in time. If a refund message contains only a transaction reference and the amount currently refunded, it is possible for the payer to convince a third party of a higher total amount than actually paid, e.g., by only showing the last refund message and ‘forgetting’ to show earlier ones. Refund messages can be made more self-contained by including the updated total amount in every refund message, as opposed or in addition to the amount of the individual refund; this allows the third party verifier to unambiguously deduce the total amount valid after any specific refund. A weaker form of self-containedness is achieved if refund messages associated with a transaction are numbered such that a third party can verify having seen all refund messages preceding the given refund message claimed to be the latest one. Note that both solutions only allow the third party verifier to establish the total payment value at a specific point in time coinciding with the timestamp in one of the refund messages seen; they do not allow the verifier to establish the total payment amount at a later point in time. Secondly, it may be the case that the relying party can prove the desired fact or statement to a third party only if other parties cooperate, e.g., by contributing evidence or by witnessing certain statements or claims. In some cases, this cannot be avoided. E.g., in the earlier example of the payment with refunds, it is impossible for the payer to convince a third party verifier of a specific refund message being the last existing one without the merchant, or the bank processing the money transfers, witnessing this fact. In other cases, the protocol can be (re)constructed such that the party wanting to prove a fact can do so without the need for other parties to witness a statement or to provide additional evidence. E.g., in the earlier case where a payee’s reply to a payer’s payment message does not contain the price of the transaction, a payer needed the bank to support his claim (e.g., by testifying the value which was transferred from the payer’s to the payee’s account for that transaction) in order to convince a third party of the amount paid. Reconstructing the protocol, e.g., by including the price in the payee’s reply, obviates the need for asking the bank to contribute this testimony.

Finally, proving certain facts (or protocol instance values) to a third party may be possible only by revealing also other facts or values; in some cases this may violate the privacy expectations or goals of the protocol. An example can be found in the SET [104] payment protocol. If the clearing bank needs to convince a third party verifier of the payer’s commitment to a payment of a certain value, it can do so only by either including evidence provided by the payee, or by also revealing secret data associated with the customer’s account to the third party verifier. This example, as well as the previously discussed protocol design issues related to messages being self-contained, will be further illustrated when analyzing and comparing payment protocols w.r.t. accountability in Chapter 4.

In our dispute handling framework ([8] and Chapter 3), we define a language for stating accountability claims in payment systems, and illustrate the semantics of this claim language by a mapping of pieces of evidence to provable claims in theiKP [16] payment system. This work forms the basis for our reasoning about how to support provable claims and accountability with evidence.

1.3.2 Overall System Design for Accountability

Even if the actual transaction protocol is correctly designed to support accountability, many more factors determine whether the digitally signed messages generated by the protocol are indeed accountable. Some of these factors are related to the existence of appropriate liabilities and guarantees by certifying and certified entities: is the name certified in the certificate guaranteed by the certifier to be the name of the person who registered the certificate, and did this person take responsibility for the use of the certificate? These issues are discussed in Section 1.3.3.

(26)

whether the key pair and the signature were generated in a secure way, whether the private key is stored and handled securely, and the availability of trusted timestamping or notary services. In the remainder of this work, we will not further discuss these issues; we refer to the European Union’s directive on electronic signatures [110] for an example of recommendations on the security of various critical procedures; for a more concrete specification of the implementation of the directive, we refer to the standards produced by ETSI’s Electronic Signatures and Infrastructures [56] Working Group.

1.3.3 Liabilities and Guarantees

A relying party in a public-key based system or protocol expects to derive a certain guarantee from a successful signature verification. As a certificate in a typical public-key infrastructure typically binds an identity as well as attributes to a public key, a relying party could expect a guarantee that he can associate a successful signature verification using that public key with an entity with that identity and those attributes; at the very least, he would like to believe that the certification authority issuing the certificate has verified this identity and attributes and is willing to take a liability for their correctness. However, guarantees given by certification authorities vary. The GlobalSign certificate authority [64, 61, 63, 62], as an example, does require a signed photocopy of identity card, drivers license or passport to verify a user’s name and certain attributes before issuing a certificate. But, of the certificates issued for personal use, only theP ersonalSign3T M _{version requires a physical appearance of the certificate holder}

at a registration authority; the P ersonalSign 2T M _{certificate can be obtained without this physical}

appearance.

For neither of the two types of certificates, GlobalSign takes liability for certificate contents other than the name; in fact, “subscribers (certificate holders) are liable for any misrepresentations they make in certificates.” As for the name, GlobalSign accepts an aggregated (to all damaged parties) limited liability for a “false identity in a certificate.” But, is a false identity a non-existing one, or is itX’s real identity used by the impersonatorY in the example above?

1.4 Authentication and Accountability in Anonymous Transactions

Privacy demands by users motivate the need for designing systems in such a way that users enjoy maximum privacy and unidentifiability when performing electronic transactions or accessing electronic services. This is supported by emerging legislation regarding individuals’ rights to privacy; e.g., the European directive on privacy in electronic communications [111] states the objective of using anonymous or pseudonymous data where possible, and of introducing and developing the relevant technologies; it also encourages the development of service options such as alternative payment facilities allowing anonymous access to electronic communications services.

‘Maximum unidentifiability’ is the level of unidentifiability that can be achieved without compromising the security of relying parties. Concretely, if users are allowed to access services or perform transactions in an unidentifiable way, relying parties still need to be able to enforce appropriate access controls and authorization decisions based on securely certified names, privileges or attributes; also, it still has to be possible for relying parties to hold a legal entity accountable in well-defined cases of misuse or fraud. Current public-key based systems do not lend themselves well to anonymous applications: certificates are identity-based, and identity-based authentication is typically used to achieve access control as well as accountability.

Introducing privacy and unidentifiability without compromising on secure authorization can be based on attribute-based authorization and on avoiding linkabilities between transactions. In order to preserve accountability, measures for re-identification are needed; however, the need for such measures may be minimized by preventing, rather than detecting, fraud and misuse.

In the following, we discuss these various concepts as well as the use of anonymous credentials as an advanced technology allowing authentication and accountability in anonymous transactions.

(27)

1.4.1 Attribute-Based Authorization

With attribute-based authorization, a user directly proves possession of the attribute or privilege required for an action to be authorized, rather than proving an identity or name which can then be mapped to the appropriate privileges.

If the user’s authentication is performed based on a pseudonym certificate, the authorized action can thus be anonymous (that is, if the authorizing party cannot identify the pseudonym); however, care has to be taken that the collection of a user’s privileges required for the authorization or present in the certificate does not identify the user. Identification of a user through attribute or privilege sets present in the certificate may be prevented by one of the following measures:

• Hiding the attributes or privileges in certificates. E.g., only a randomized hash of each attribute is present in the certificate, i.e., a hash of the attribute concatenated with a random value known to the certificate owner. Every time the user authenticates using the certificate, he ‘opens’ only the necessary attribute(s); i.e., he presents the relying party with the random value needed for the relying party to verify that the hash of the required attribute(s) is present in the certificate. This does not, however, prevent the relying party, or a colluding set of relying parties, from keeping track of ‘opened’ attributes related to a specific certificate, and thus from finally identifying the user when knowing most or all of the attributes in a certificate.

• Using multiple certificates — one for each non-identifying set of attributes. This is the most secure solution when using conventional certificates.

• Using anonymous credentials (see also Section 1.4.5). In this case, one credential can contain all attributes but the user selects exactly which of the attributes to reveal upon each authentication. As consecutive authentications using the same credential are not linkable by the relying party (or by a collection of relying parties), it is not possible for the relying parties to keep track of attributes belonging to the same credential.

1.4.2 Avoiding Linkability of Transactions

Even when applying attribute-based authorization based on pseudonym certificates, transactions with the same certificate are linkable to each other by the fact that the certificate contains a unique public key, CA signature and possibly serial number. As discussed in Section 1.2.4, this linkability increases the chance of these transactions becoming identifiable.

When using conventional certificates, linkability can be avoided only by minimizing the use of each certificate. E.g., when a user uses a new pseudonym certificate (with a new pseudonym key) for each transaction, the verifying party (or parties) cannot link the user’s transactions.

The issuer of the pseudonym certificates can, of course, link all the pseudonym certificates of, and thus all the transactions by, one user. In the Trusted Computing Group model [113, 13] based on earlier specifications of the Trusted Computing Platform Alliance, a platform owner can request multiple pseudonym certificates (‘identity certificates’) from a chosen Privacy-CA. The Privacy-CA is the only entity that has the information to correlate the different pseudonyms (identities); a platform owner may choose a Privacy-CA whose policy is not to perform such correlations.

Using anonymous credentials as discussed in Section 1.4.5, the same credential can be used in an un-limited number of transactions without those transactions becoming linkable; and one can even achieve unlinkability of those transactions towards the issuer of the credential.

1.4.3 Re-Identification

The use of pseudonym certificates or anonymous credentials is possible also in applications requiring accountability; this requires, however, that a transaction can be re-identified (the transaction or the

(28)

pseudonym is linked back to a real identity) when a certain condition is fulfilled; fraud or the misuse of privileges are examples of such re-identification conditions.

This implies that a trusted entity (e.g., the issuer of the pseudonym certificate) knows this linking and is trusted by the relying parties to reveal it when the necessary conditions (misuse) for re-identification are fulfilled. Of course, this entity also has to be trusted by the users not to reveal this linking when the necessary conditions are not fulfilled.

In anonymous credential systems as discussed in Section 1.4.5, re-identification is provided by de-anonymization(also calledanonymity revocation[31]) or on a per-transaction basis: the re-identification of a transaction does not cause identifiability of other transactions based on the same credential.

1.4.4 Prevention vs. Detection of Fraud and Misuse

A design concept that may increase the achievable unidentifiability in a given system is the prevention of misuse as opposed to its detection.

Today, many business processes allow fraud or misuse to occur; risk management is often based on the fact that misuse can be detected and users can be held accountable, either through identity-based signatures or re-identification. Good protocol and system design preventing fraud and misuse may reduce this need to rely on accountability, and therefore decrease the need for identification or re-identification. Many examples can be found, in electronic as well as non-electronic transactions. If a user orders some goods by mail and is allowed to pay upon receipt, it is natural that the mail order company requests an identity-based signature using an identity certificate issued by an accredited certifier; this allows the company to take legal action in case the user does not pay for the goods. But, if the user chooses or is asked to pre-pay the goods (e.g., using an anonymous payment system or a cash payment at the post office), the mail order company may not need such an identity-based signature on the order.

An electronic payment using a certificate issued by a bank may be anonymous towards the merchant if the certificate carries the appropriate liabilities by the bank that the payment will be honored; if the payment certificate carries a pre-paid value (e.g., an e-coin), the actual payment may even be anonymous towards the bank as the bank need not debit a user account anymore when clearing the amount with the merchant.

Thus, identity-based signatures towards relying parties, as well as the need for re-identification, can be avoided by protocol and system design providing appropriate guarantees to the relying party or parties and by preventing misuse. Building such guarantees into a system not only allows for higher levels of unidentifiability; it also reduces costs for relying parties related to the tracking of users and to the search for compensation in case of fraud and misbehavior.

1.4.5 Anonymous Credentials

In an anonymous credential system (also called pseudonym system) [39, 36, 40, 49, 86, 31], users can obtain anonymous credentials from credential issuing organizations, and show possession of a credential to other organizations such as service providers. Organizations know the users only by pseudonyms, and different pseudonyms of the user cannot be linked. Yet, an organization can issue a credential to a pseudonym, and the corresponding user can prove possession of this credential to another organization (who knows the user by a different pseudonym) without revealing anything more than the fact the user owns such a credential. In such a system, the ownerAof a credential proves ownership of some certified attributes to a verifierV withoutV ever actually ‘seeing’ the credential;Acan thus authenticate (provide such a proof) multiple times withoutV being able to link the various authentications to each other. The credential system described by Camenisch et al. [31] is an example of ananonymous credential system as introduced in Section 1.2.2. It is an ideal vehicle for building anonymous yet accountable transactions. It fully supports anonymous attribute-based authorization: its credentials can carry any number and type of attributes; every time a user authenticates using a given credential, he can choose which attribute(s) of

(29)

the credential to show; and those different authentications (different instances of showing the credential) are not linkable. It also supports a special type of re-identification, called anonymity revocation or de-anonymization which can be done only by a dedicated trusted de-anonymizing organization as agreed to by the user, and is performed on a per-transaction basis. Consequently, de-anonymization of one of a user’s transactions does not cause the other transactions he made with the same credential to be de-anonymized. Thus, less trust is needed by the user in the de-anonymizing organization than in the case where a certificate issuer can simply map a certificate to a user.

1.5 Incentives and Disincentives for Accountability and

Uniden-tifiability

In the following chapters, we will focus on the technical aspects of realizing systems and infrastructures allowing accountability and/or unidentifiability. In this section, we discuss some issues that motivate or impede the realization of such infrastructures. We also discuss their value in safeguarding a democratic and fair society.

1.5.1 Accountability

We first address the issue of accountability-supporting infrastructures. Who benefits from accountability, and who is likely to invest in it?

According to our definition in Section 1.2.3, accountability is the property whereby the association of a unique originator with an object or action can be proved to a third party. In electronic transactions, we define as strong (digital) evidence the evidence created by digitally signing data or by showing an anonymous credential. We will refer toweak (digital) evidenceas evidence created by using a shared key or password.

In the envisaged Information Technology Society of the future, many examples can be found where strong evidence of transactions will be needed. The recipient of a signature on a housing contract or a job offer expects the signer to be accountable for the commitment made. These processes replace existing paper-based processes and the expectations on accountabilty are similar as with handwritten signatures. Strong evidence may be required in many cases without disputes or disagreements between transac-tion participants being the primary motivatransac-tion. E.g., digital receipts (of purchases, charity donatransac-tions) submitted as part of a tax return form should contain strong evidence towards the tax authorities of the purchase or donation made. The same reasoning holds for digital receipts generated by a railway’s sales department and submitted to a company’s accounting department as part of an employee’s travel expense reimbursement claim. Digital medical prescriptions will carry a digital signature by a medical doctor and can be verified by pharmacies as well as medical insurance companies.

The previous examples illustrate the need for accountability, and the generation of strong evidence, in realistic scenarios of electronic transactions. They also illustrate that the need for accountability is not always related to preventing or resolving disputes among transaction participants. Strong evidence as generated by the charity organization, the railway organization’s sales department or the medical doctor entitle the recipient of this evidence to receive a service (tax rebate, reimbursement, medicine).

Also, accountability facilitates the use of electronic and partially automated processing (of tax returns, of reimbursement claims) and can enhance the security of these processes by reducing paper-based fraud. The question of who will or should invest in the public-key infrastructures supporting the generation of strong evidence is related to this cost saving factor. In the medical world, sector-specific accountability infrastructures may be sponsored jointly by associations of medical doctors, medical services and medical insurance companies. In many of the other examples, general-purpose public-key and accountability infrastructures allowing a strong binding between a public key and an individual or enterprise may provide the necessary strong evidence. Smart cards and personal digital assistants (PDAs) support various users