UNIDENTIFIABILITY AND ACCOUNTABILITY IN ELECTRONIC TRANSACTIONS

KATHOLIEKE UNIVERSITEIT LEUVEN 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 Oktober 2004

KATHOLIEKE UNIVERSITEIT LEUVEN 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écom, 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 U.D.C. 681.3*I21 Oktober 2004

c Katholieke Universiteit Leuven Faculteit Toegepaste Wetenschappen 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. All rights reserved. No part of the publication may be reproduced in any form by print, photoprint, microfilm or any other means without written permission from the publisher. D/2004/7515/63 ISBN 90-5682-525-9

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 Rannenberg 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 like Idemix 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à was the best support I could imagine. i

ii

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 accountablity with the ikp 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 preserving or even improving accountability. We introduce the notion of liability-enhanced public-key infrastructure 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 introduce Idemix, an anonymous 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 various Idemix building blocks and illustrate how to use these descriptions in analyzing security and unidentifiability features of larger Idemix-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. iii

iv

Contents 1 Introduction 1 1.1 Introduction............................................ 1 1.2 Terminology............................................ 2 1.2.1 Identity-Based vs. Attribute-Based Authentication and Authorization....... 2 1.2.2 Certificates and Credentials............................... 3 1.2.3 Belief, Provability, Accountability and Liability.................... 3 1.2.4 Pseudonymity, Anonymity, Linkability and (Un-)Identifiability........... 5 1.3 Accountability in Public-Key Based Systems......................... 6 1.3.1 Protocol Design: Authentication vs. Accountability.................. 6 1.3.2 Overall System Design for Accountability....................... 7 1.3.3 Liabilities and Guarantees................................ 8 1.4 Authentication and Accountability in Anonymous Transactions............... 8 1.4.1 Attribute-Based Authorization............................. 9 1.4.2 Avoiding Linkability of Transactions.......................... 9 1.4.3 Re-Identification..................................... 9 1.4.4 Prevention vs. Detection of Fraud and Misuse..................... 10 1.4.5 Anonymous Credentials................................. 10 1.5 Incentives and Disincentives for Accountability and Unidentifiability............ 11 1.5.1 Accountability...................................... 11 1.5.2 Privacy and Unidentifiability.............................. 13 1.6 Goal and Scope of This Work.................................. 14 1.7 Notation.............................................. 15 2 A Secure Account-Based Electronic Payment System 17 Preamble................................................ 17 2.1 Introduction and Overview................................... 19 2.2 History and Related Work.................................... 21 2.3 Payment Model.......................................... 22 2.4 Security Requirements...................................... 24 2.5 The ikp Protocol Family.................................... 26 2.5.1 1KP............................................ 28 v

vi Contents 2.5.2 2KP............................................ 33 2.5.3 3KP............................................ 35 2.5.4 Comparison of the Protocols.............................. 35 2.6 ZiP: Implementation and Deployment............................. 38 2.6.1 Protocol scenarios.................................... 38 2.6.2 Implementation Rationales and Explanations..................... 40 2.6.3 Architecture....................................... 41 2.6.4 Deployment........................................ 42 Postscript................................................ 43 3 Accountability and Dispute Handling in Payment Systems 45 Preamble................................................ 45 3.1 Introduction............................................ 47 3.1.1 Importance of Dispute Handling in Electronic Commerce.............. 47 3.1.2 Handling Disputes.................................... 47 3.2 Expressing Dispute Claims................................... 49 3.2.1 What to Dispute?.................................... 49 3.2.2 Value Transfers as Primitive Transactions....................... 50 3.2.3 Statements of Dispute Claims.............................. 51 3.3 Supporting Claims with Evidence................................ 56 3.3.1 Architecture for Dispute Handling........................... 56 3.3.2 Evidence and Trust................................... 58 3.3.3 An Example: Evidence Tokens in ikp......................... 60 3.4 Summary and Conclusion.................................... 64 Postscript................................................ 65 4 Analysis of Accountability Features in SET and ikp 67 Preamble................................................ 67 4.1 Introduction............................................ 69 4.2 High-Level Payment Protocol Description........................... 70 4.3 Proving Authorizations of Primitive Transactions....................... 71 4.4 SET................................................ 73 4.4.1 SET Protocol Overview................................. 73 4.4.2 Evidence of Authorizations............................... 74 4.4.3 Discussion......................................... 76 4.4.4 Recommendations.................................... 77 4.5 ikp................................................ 78 4.5.1 ikp Protocol Overview................................. 78 4.5.2 Evidence of Authorizations............................... 79 4.5.3 Discussion......................................... 80

Contents vii 4.6 Summary............................................. 80 Postscript................................................ 82 5 Secure Anonymous Signature-Based Transactions 85 Preamble................................................ 85 5.1 Introduction............................................ 87 5.2 Pseudonymizing a Generic Payment System.......................... 88 5.2.1 The Generic Payment Protocol............................. 88 5.2.2 Requirements for a Secure Pseudonymized Version.................. 89 5.2.3 Design for Maximum Security: PS On-line, CERT P Linked to Transaction.... 90 5.2.4 Alternative Design: Off-Line PS............................ 92 5.2.5 Discussion......................................... 94 5.3 Generalized Signatures and Liabilities............................. 94 5.3.1 Liability-Aware Certificates............................... 95 5.4 A Generic Pseudonym Server.................................. 96 5.4.1 CERT REQ, CERT RES................................ 96 5.4.2 The Liabilities in CERT P................................ 97 5.4.3 Example: Auction.................................... 98 5.5 Related and Future Work.................................... 98 5.6 Conclusion............................................ 99 PostScript................................................ 100 6 An Anonymous Credential System 103 Preamble................................................ 103 6.1 Introduction............................................ 105 6.2 Idemix Protocols, Pseudonyms and Credentials........................ 106 6.2.1 Basic Credential Protocols................................ 106 6.2.2 Credential Options and Attributes........................... 107 6.2.3 Parameters of the Show Protocol............................ 108 6.3 Credential System Primitives.................................. 109 6.3.1 Pseudonyms........................................ 109 6.3.2 Credentials........................................ 110 6.3.3 CredShowFeatures.................................... 110 6.3.4 Protocol Primitives.................................... 110 6.4 The Idemix Prototype...................................... 111 6.4.1 OrgNymSystem and UserNymSystem Token-Based Interfaces............ 112 6.4.2 UserSyncNymSystem and OrgSyncNymSystem Synchronous Interfaces....... 113 6.4.3 DeAnOrgNymSystem.................................. 113 6.4.4 Communication...................................... 113 6.4.5 Persistent Data Storage................................. 113

viii Contents 6.4.6 Building Applications: Granting and Processing Requests.............. 115 6.5 An Example Scenario: An Anonymous Subscription to the New York Times........ 117 6.5.1 Creating and Configuring the User and Organizations................ 117 6.5.2 User Credential Manager and Browser Plug-In.................... 117 6.6 Deployment Considerations................................... 118 6.6.1 Idemix as a Generic Attribute-Based Authentication System............ 118 6.6.2 The Role of Authenticated Communication in Linking Transactions Based on Idemix Authentication.................................. 118 6.6.3 Deploying Idemix as a Privacy-Enhanced Public-Key Infrastructure with External Certification....................................... 118 6.6.4 Infrastructural Issues: User Registration and Organization Updates........ 119 6.7 Conclusions and Future Work.................................. 119 Postscript................................................ 120 7 Designing Applications Using Idemix Anonymous Credentials 121 7.1 Introduction............................................ 121 7.2 Primitives and Parameters of the Anonymous Credential System.............. 122 7.2.1 Basic primitives..................................... 122 7.2.2 Signed Nym Registration................................ 126 7.2.3 Root Nym Registration................................. 127 7.3 Assertions on Nyms, Credentials and Transcripts Resulting from Interactive Protocols.. 128 7.3.1 Nym Registration.................................... 129 7.3.2 Signed Nym Registration................................ 129 7.3.3 Root Nym Registration................................. 129 7.3.4 Credential Issuing.................................... 130 7.3.5 Showing a Credential Not Relative to a Nym................... 130 7.3.6 Showing a Credential Relative to a Nym...................... 131 7.4 Local Operations on Transcripts................................ 131 7.4.1 Local De-Anonymization................................ 131 7.4.2 Global De-Anonymization................................ 132 7.4.3 Double-Spending Detection............................... 135 7.5 Assertions on Linkability..................................... 135 7.5.1 Anonymity, Linkability and Identifiability....................... 135 7.5.2 Nym Registration.................................... 138 7.5.3 Signed Nym Registration................................ 138 7.5.4 Root Nym Registration................................. 138 7.5.5 Issuing of a Non-Unique Credential........................... 138 7.5.6 Issuing of a Unique Credential............................. 139 7.5.7 Unconditionally Unidentifable Showing of a Credential................ 139 7.5.8 Showing a Credential with Unique Parameters.................... 139

Contents ix 7.5.9 Showing a Credential Relative to a Nym........................ 139 7.5.10 Showing a Credential with De-Anonymizaton..................... 140 7.5.11 Showing a One-Show Credential............................ 140 7.6 Additional Procedures and Functionality............................ 140 7.6.1 More On Global De-Anonymization.......................... 140 7.6.2 Revocation........................................ 142 7.6.3 Certification....................................... 143 7.7 Designing an Application.................................... 143 7.7.1 Introducing the LostFound Application........................ 144 7.7.2 Key Material, External Certificates and Idemix Certificates............. 144 7.7.3 Security of the Communication Channels....................... 146 7.7.4 Protocols for Registration and Service Access..................... 148 7.7.5 Verifying Organizations Accountability Requirements................ 152 7.7.6 Verifying User Unidentifiability Requirements..................... 154 7.8 Trust, Accountability, Liability and Certification....................... 156 7.8.1 Trust by Users and Organizations in De-Anonymization............... 156 7.8.2 Trust by Organizations in the System......................... 158 7.8.3 Certificates, Liabilities and Contracts......................... 159 7.8.4 A Scenario Illustrating Trust in Accountability and Unidentifiability........ 161 7.9 Conclusion............................................ 163 8 Certificate- and Credential-Based Anonymous Payments 165 8.1 Introduction............................................ 165 8.2 Payment Protocols Based on Certificates............................ 166 8.2.1 Non-Pseudonymous Account-Based Payment Protocol Based on Certificates.... 166 8.2.2 Pseudonymous Account-Based Payment Protocol Based on Certificates...... 170 8.3 Payment Systems Based on Anonymous Credentials..................... 173 8.3.1 Account-Based Payment Protocol Based on Anonymous Credentials........ 173 8.3.2 Pre-Paid Payment Protocol Based on Anonymous Credentials............ 178 8.4 Analysis of Accountability and Unidentifiability of the Various Payment Protocols.... 183 8.4.1 Non-Pseudonymous Account-Based Payment Protocol Based on Certificates.... 183 8.4.2 Pseudonymous Account-Based Payment Protocol Based on Certificates...... 184 8.4.3 Account-Based Payment Protocol Based on Anonymous Credentials........ 185 8.4.4 Pre-Paid Payment Protocol Based on Anonymous Credentials............ 190 8.4.5 Additional Remarks on the Use of Certificates vs. Anonymous Credentials..... 192 8.4.6 Risks Related to a Breakdown of the Credential System or Compromise of Secrets 193 8.5 Conclusion............................................ 194 9 From Identity-Based to Risk-Driven Design 195 9.1 Non-Anonymous Applications Based On Anonymous Credentials.............. 195

x Contents 9.1.1 An Example Application Based on Certificates.................... 196 9.1.2 The Example Application Based on Credentials.................... 199 9.1.3 Conclusion........................................ 202 9.2 Risk-Driven Design........................................ 203 9.2.1 The Principles Revisited................................. 204 9.2.2 Risk-Driven Application Design: An Example..................... 206 9.2.3 Risk-Driven Application Design: General Method Description............ 212 9.2.4 Risk-Driven Application Design And Design Principles for Accountability and Unidentifiability..................................... 213 9.3 Conclusion............................................ 214 10 Related Research 217 11 Conclusions 221 11.1 Summary of Contributions.................................... 221 11.2 Summary of Conclusions..................................... 222 11.3 Avenues for Future Work.................................... 224 Bibliography 225 List of Publications 233 Biography 235 A Summary in Dutch i

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 of ikp Protocols.................................. 29 2.5 1KP Protocol........................................... 30 2.6 2KP Protocol........................................... 34 2.7 3KP Protocol........................................... 36 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 Simplified ikp Protocol..................................... 61 3.6 Global States in ikp....................................... 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

xii List of Figures 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 and I 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 for L................................... 207 9.4 LostFound Application Design................................. 211

List of Tables 2.1 Comparison of the ikp 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 Completed ikp Transaction................... 60 3.4 Mapping Evidence to Dispute Statements in ikp....................... 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 xiii

xiv List of Tables

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 certification 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 signature (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 document to later successfully repudiate having signed that document. Throughout this work, we will rather use the term accountability, 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 environments 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. 1

2 Chapter 1. Introduction 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 enabling 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 authentication corroborate the identity of an entity (e.g., a person, a computer, etc.) associated with a communication 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 a pseudonym as defined in the next section. In identity-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 called relying party) V can be achieved using a digital certificate certifying the linking between A s public key and his identity; this linking is certified (signed) by a trusted entity such as a certification authority CA. A can now convince V 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 party A convinces a verifying party V of the fact that A owns 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 that A 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 with A s secret. As with certificates, A can then prove ownership of an attribute certified in a credential by proving knowledge of this secret. Attribute-based authorization will then allow A to 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

1.2. Terminology 3 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 attributebased. 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 authority CA. It binds the identity or name of a certified entity (A) and possibly additional relevant information (attributes) pertaining to A to the public key corresponding to a private key owned by A and known only to A. The certified key can be a public encryption key: in this case, information encrypted with A s public key can be decrypted only using A s private decryption key. Most often, we will talk about certificates certifying public signature keys: in this case, A authenticates to V (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 in A s certificate. In order to verify the authenticity of this certificate (and of A s public key), V needs an authentic copy of the CA s public key. In real life, public-key infrastructures often consist of many CA s organized in a hierarchical or flat manner; for V to obtain an authentic copy of the public key of the CA certifying A, that public key may need to be certified by an entity (another CA) 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 a pseudonym (see also Section 1.2.4); a certificate certifying it is called a pseudonym 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 to believe a statement if he is convinced of that statement; and a proof of a statement x is a set of statements that can collectively convey the

4 Chapter 1. Introduction validity of x to 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 the CA. In order to believe that the message is signed by A, V needs to successfully verify the signature on the message with the public key in A s certificate, and also has to verify the authenticity of A s certificate; the latter verification is done using an authentic copy of the CA s public key. For V to trust that a message signed with A s private key (more precisely: verified using A s public key) can indeed be attributed to A, V also needs to trust the CA as well as the overall certificate infrastructure (see also Sections 1.3.2 and 1.3.3). The message signed by A may also provide evidence to a third party if this party also trusts the CA and the certificate infrastructure. I.e., using the signed message, V is able to prove to a third party that A made the statement contained in the message, or: A is 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 the liability value associated 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 use liability also as a short form for liability 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.

1.2. Terminology 5 Liability applies to legal 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 A pseudonym is 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 be anonymous towards another entity in a particular transaction if his identity in that transaction is concealed from that other entity. Anonymity of an entity A is 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 remains unidentifiable to 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 term anonymity towards 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. Identifiability is thus a property of a transaction which can evolve over time and takes these transaction

6 Chapter 1. Introduction parameters, linkabilities, participants behaviors and system parameters into account. Thus, an anonymous 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 concrete 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, anonymity, 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.

1.3. Accountability in Public-Key Based Systems 7 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 the ikp [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. Other factors relate to the security of various other procedures in the public-key infrastructure, such as

8 Chapter 1. Introduction 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 the P ersonalsign 3 T M version requires a physical appearance of the certificate holder at a registration authority; the P ersonalsign 2 T 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 it X s real identity used by the impersonator Y 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.

1.4. Authentication and Accountability in Anonymous Transactions 9 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 unlimited 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

10 Chapter 1. Introduction 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 deanonymization (also called anonymity 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 owner A of a credential proves ownership of some certified attributes to a verifier V without V ever actually seeing the credential; A can thus authenticate (provide such a proof) multiple times without V being able to link the various authentications to each other. The credential system described by Camenisch et al. [31] is an example of an anonymous 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

1.5. Incentives and Disincentives for Accountability and Unidentifiability 11 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 deanonymization 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 Unidentifiability 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 to weak (digital) evidence as 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 transaction participants being the primary motivation. E.g., digital receipts (of purchases, charity donations) 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

12 Chapter 1. Introduction of the system in securely storing their secrets and possibly transaction data while remaining mobile. In the above examples, the incentive to introduce public-key infrastructures and accountability can be expected to come from a collection of parties who expect to save cost and to increase efficiency and security of their processes. Various parties see (or are offered) benefits and together have the power to indeed put this infrastructure in place. Large-scale introduction of public-key infrasctructures in the financial sector has so far not been successful; the failure of SET (Secure Electronic Transactions [104]) illustrates that. SET is a three-party protocol between a customer (payer), merchant (payee) and an acquirer which is a gateway into the existing financial network. In SET, all three parties digitally sign their transaction authorization. One factor impeding the success of SET seems to have been the fact that its introduction was largely promoted by credit card companies (Visa, MasterCard) while the buy-in of many more parties (merchants and mostly banks) was required. A clear exploitation path with appropriate incentives for the various parties to install the necessary SET infrastructure was missing. In addition, SET was meant to provide a scalable solution to reduce fraud in online credit card payments and did not claim accountability towards third parties. The protocols may have been too heavy with respect to the security goals they were asked to fulfill. The customer wallet implementation had a large footprint and even implementing its absolute mimimum (core cryptographic operations using the user s secret) on a smart card was not feasible at the time. Don t banks and credit card companies need accountability in transactions with customers? As many of the examples in the following chapters are situated in this area, we briefly elaborate on this issue. Financial organizations have long-term relationships with their customers and often enjoy a fair amount of trust by those customers. Customers may then not need strong evidence of every transaction and weak receipts together with periodic statements of accounts may suffice. In addition, these relationships are characterized by strong asymmetries in power. Financial organizations power to stipulate the terms of the contracts with their customers, their position of trust in society and their elaborate risk management procedures may make accountability unnecessary or unwanted. This position of power and trust allows them to choose whether they want to issue receipts containing strong evidence and why would they? It also enables them to shape contracts and risk management procedures such that accountability (again, towards the outside) of transaction authorizations by their customers is not needed. In the smallprint of a homebanking agreement with a customer, a bank is likely to waive any responsability for fraudulous transactions (in other words, any transaction disputed by the customer). Not surprisingly, the internet payment mechanisms which remained or became popular have no claims of accountability. For credit card payments, SSL [58]/TLS [51] are used for encrypting credit card details between customer and merchant. While providing less strong guarantees of security, this method is compatible with existing merchant clearing infrastructures while requiring no specialized software (other than a standard web browser) on the customer side. Another widely used internet payment method is PayPal (http://www.paypal.com). PayPal enables any individual or business to create a PayPal account from which to make or receive payments. PayPal s service builds on the existing financial infrastructure of bank accounts and credit cards. Both registration to PayPal as payments using PayPal use SSL for encrypting an account holder s financial or commitment information. In the specific setting of internet payments, existing systems seem to work without accountability infrastructures. Yet, many of the examples in the following chapters deal with accountability in internet payment systems. Are they merely theoretical examples without a business need or value? We believe not, because accountability, and strong security in general, is likely to be in everyone s interest. Firstly, it seems reasonable to expect that the long-term total cost balance of the implementation of accountability and strong security be positive, as the cost of complex risk management mechanisms and disputes related to insufficiently authenticated processes can be reduced. However, analyzing medium- to long-term benefits of investment in securely designed systems is known to be hard. Secondly, systems currently do not work for everyone. We live in a world where people are being held responsible for actions they did not commit. Identity theft, the crime of impersonating an individual and spending money on his behalf (using an existing or newly opened account) is becoming more important.

1.5. Incentives and Disincentives for Accountability and Unidentifiability 13 The Privacy Rights Clearinghouse s fact sheet on identity theft [112] states: Even though victims are usually not saddled with paying their imposters bills, they are often left with a bad credit report and must spend months and even years regaining their financial health. In the meantime, they have difficulty getting credit, obtaining loans, renting apartments, and even getting hired. Victims of identity theft find little help from the authorities as they attempt to untangle the web of deception that has allowed another person to impersonate them. Identity theft stories such as the ones by Garfinkel [59] illustrate the truth of this statement. Identity theft is usually presented as being a privacy-related crime or problem; the criminal action is performed by the identity thief. The fundamental problem, however, is one of a painful lack of security in the processes to obtain credit cards or open accounts. Knowing someone s Social Security Number (SSN), or having access to someone s physical mailbox containing a credit card application form, may suffice to obtain a credit card in someone s name and, as stated above, cause a lot of damage to that person s credit rating and thus to his life. One can then ask the question whether financial institutions and credit rating agencies should not be held accountable (and liable) for these damages. If this were the case, risk management calculations of those institutions may reveal more business incentives for strong security and accountability of all parties. 1.5.2 Privacy and Unidentifiability Individuals are steadily loosing the ability to control the ways information about them is collected and used. This tendency is illustrated in various works, e.g., [59]. Yet, it is often said that users are not willing to pay for privacy; even, that they are willing to give up privacy in return for some advantages such as rebates, personalized services or loyalty points. This statement, even if true, should not be an argument for laissez-faire behavior with respect to users privacy. Firstly, the right to privacy is a fundamental human right, laid out in Article 8 of the European Convention for the Protection of Human Rights and Fundamental Freedoms [44]: Everyone has the right to respect for his private and family life, his home and his correspondence. There shall be no interference by a public authority with the exercise of this right except such as is in accordance with the law and is necessary in a democratic society in the interests of national security, public safety or the economic well-being of the country, for the prevention of disorder or crime, for the protection of health or morals, or for the protection of the rights and freedoms of others. An important aspect of the right to privacy is the right to control the way personal data about oneself is collected and used. The directive 95/46/EC of the European parliament and of the council on the protection of individuals with regard to the processing of personal data and on the free movement of such data [109] creates a legal framework to be followed by member states of the European Union. Secondly, users cannot be expected, or simply do not have the means, to have a full understanding of the privacy impact of releasing certain data about themselves. The introduction of a privacy policy language such as P3P [48], with which web servers can specify which data they are collecting from customers and what that data will be used for, underlined this problem rather than solving it [76]. Ongoing efforts to clarify presentation of P3P elements to end users in the P3P1.1 Working Group [47] may address some of these problems. They may provide the user with a view of the privacy-related practices of the enterprise collecting data. They do not, however, provide the user with a full view of potential future use and aggregation of the data revealed in the event of acquisitions and mergers. Let us now look at the case for or against anonymity in particular. There are good reasons to be found for defending anonymity. Anonymity protects our freedom of speech and thought. It protects people against the oppression by governments and against mobbing and discrimination by an intolerant majority. The possibility to voice our thoughts and criticisms without fear for repercussion and punishment is fundamental for safeguarding our personal freedom and the democratic workings of our society. Anonymity is also often seen as a vehicle encouraging and allowing criminal behavior. While anonymity may make certain criminal actions easier, this cannot be considered a good reason for the massive and systematic gathering and processing of personal data. To quote a pseudonymous web forum posting [94]:

14 Chapter 1. Introduction There is no way for a citizenry deprived of privacy and anonymity to effect change in a corrupt government. In a system with a transparent government and anonymous citizenry though, institutions and practices can be put into place to reduce abuses of the system, but the inverse does not exist in the latter scenario. So while it may at first glance appear that removing anonymity from society, be it in banking, travel, lodging, communications, or anything else improves our security by depriving criminals of opportunities, this change also deprives the citizenry of many freedoms, it creates a system full of risk to the future of the populace by removing the accountability of the government to the people... The potential for abuse persists in both systems, but only the system that preserves freedom and privacy (this is all anonymity is) is capable of overseeing itself. Whether one sees this as a desirable system in its own right or the lesser of two evils, it is clear that anonymity in private life and transparency in public governance are essential to freedom, liberty, and the life that we are supposedly fighting for. As of today, enterprises and financial institutions typically target compliance with the privacy regulations and good privacy practices governing their specific industry sector; such compliance does not aim at maximal user privacy. Incentives for businesses and financial institutions to use state-of-the-art technology, such as anonymous credential systems, to protect users privacy while preserving the security guarantees of relying parties, are hard to find. In fact, privacy, or at least unlinkability, go against loyalty schemes and price discrimination schemes which are used by enterprises to increase and optimize revenue [95]. Even if these considerations do not play a role in some of the more short-lived relationships between users and enterprises, it seems that a business case for privacy is hard to make. Should we give up on privacy or should we fix the business case calculation? As with the issue of identity theft, it may be the case that enterprises are currently not held accountable for collectively eroding our privacy. We see it as an important challenge for our democratic governments and public institutions to strongly enforce basic principles of minimal data collection, disclosure and retention. Also, as a step towards exploiting state-of-the-art privacy-enhancing technologies, their secure use can be demonstrated by public institutions and government, e.g., in e-government applications. 1.6 Goal and Scope of This Work The goal of this work is to demonstrate compatibility of unidentifiability and accountability. One part of this work analyzes the general notion of accountability on the level of the individual transaction protocol. Using some existing public-key based payment protocols, we illustrate issues and potential problems related to protocol design for accountability. Another part of this work deals with introducing anonymity and unidentifiability in electronic transactions while preserving or even improving on accountability. By introducing explicit liabilities for certifying as well as for certified entities in public-key infrastructures, we allow relying parties to derive better accountability guarantees, even in the case of anonymous transactions. In this accountability-improved environment, we show the potential and limitations of achieving anonymity and unidentifiability through attribute-based pseudonymous authorization based on conventional certificates. We also introduce infrastructures based on anonymous credentials and show that also these systems can meet every accountability requirement, while offering a higher level of unidentifiability to users. In addition, users need less trust in the infrastructure: firstly, re-identification (or de-anonymization) can be on a per-transaction basis; secondly, the fairness of de-anonymization can be made verifiable; finally, for some applications, it can be securely enforced that de-anonymization is possible only in case of misuse; in such a case, trustworthiness of a de-anonymizing organization is of no concern. An example is an e-coin application based on anonymous credentials: misuse in the form of double-spending is a necessary requirement for deanoymization of the payment transaction by the credential issuer to be technically feasible; thus, even an untrustworthy credential issuer cannot de-anonymize the payment of an e-coin which is not double-spent. The remainder of this work is organized as follows. Chapter 2 introduces ikp, a secure account-based electronic payment system, as an illustration of protocol design for accountability. Chapter 3 describes a language and framework for supporting accountability and dispute claims in payment systems; the ikp protocols are used to illustrate the mapping between claims in this language and the payment system s

1.7. Notation 15 evidence tokens. Chapter 4 then applies the same accountability reasoning to compare the ikp and SET [104] electronic payment protocols w.r.t. their accountability features. This analysis illustrates some of the issues and pitfalls related to protocol design for accountability discussed in Section 1.3.1. Chapter 5 introduces an accountability-improved public-key infrastructure. In such an infrastructure, liability-aware certificates carry an issuer s liability for transactions made with, or data certified in, the certificate; and also certificate holders take liabilities towards certifiers for actions and signatures made with their certificate. We describe a number of pseudonymous applications based on this infrastructure; we show that the liability certificates provide the same or better liability guarantees to relying parties than certificates in typical non-pseudonymous systems. The level of unidentifiability that users can enjoy is, however, limited, as different uses of the same pseudonym certificate are linked. Chapter 6 describes the Idemix anonymous credential system based on work by Camenisch et al. [31] and introduced in Section 1.4.5. It defines high-level primitives for the Idemix protocols, describes the design of the Idemix prototype and illustrates the use of the prototype for anonymous transactions using attribute-based authorization. Chapter 7 then takes a more rigourous approach towards designing authenticated and accountable yet anonymous applications based on these anonymous credentials. It revisits the Idemix protocols and describes them in the form of basic abstract building blocks; these building blocks, or combinations thereof, can be attributed certain accountability and unlinkability properties; therefore, they allow us to easily describe complex systems based on Idemix and to design Idemix applications based on their authentication, accountability and unidentifiability requirements. Chapter 8 applies this design for authentication, accountability and unidentifiability to a subset of the applications discussed in Chapter 5; a higher level of unidentifiability can be achieved, with less requirements of trust by users in re-identifying or de-anonymizing organizations. Chapter 9 provides further recommendations for the secure deployment of anonymous credentials under various privacy regimes. We first address the issue of compatibility with identity-based systems: we illustrate that, given the correct use of options, anonymous credentials can securely support identity-based authorization. We then address the issue of finding a general methodology for designing applications with maximal user unidentifiability based on anonymous credentials; and describe and illustrate the potential of a risk-driven design approach to guide such privacy-friendly design. Chapter 10 describes related research. Chapter 11 concludes and describes potential for future work. The chapters 2 through 6 contain published work. Except for some minor reformatting, the text was left unchanged; a Preamble section was added to the chapter placing its contents in the broader context of this work. Each of these chapters also contains a Postscript section. In Chapters 2, 3 and 6, which are based on multi-author publications, the Postscript clarifies my contribution. In Chapters 4 and 5, the Postscript section contains additional material which was not part of the original publication. 1.7 Notation In the following, we will frequently discuss formats and contents of certificates, signatures and keys. This section introduces various notations used and points the reader to detailed definitions. Chapters 2, 3 and 4 use a traditional certificate format and notation. In a certificate Cert X, certification authority CA certifies a public key PK X of party X by signing the pair (X, PK X ) possibly together with additional information (attributes). The key pairs (private or secret key SK X and corresponding public key PK X ) are typically used for signing and signature verification. Both ikp (Chapters 2, 3, 4) and SET (Chapter 4) protocols also use publickey encryption/decryption; however, we do not introduce a specific distinctive notation for signature key pairs vs. encryption key pairs. 1 Each of these chapters also provides its own definition of application- 1 In both ikp and SET, the payment gateway (acquirer) is the only party for/by whom public-key encryption/decryption is used. While the original description of the ikp protocols assumes (on page 23) the use of the same key pair for both purposes, the actual ZiP implementation described in detail in the Appendix of Van Herreweghen et al. [16] uses different key pairs for encryption/decryption than for signing/signature verification. As for SET, its protocol specification specifies

16 Chapter 1. Introduction specific cryptographic operations (such as signatures, encryption functions and hash functions); we do not capture these definitions in this section as they are specific to the relevant chapter (and to the corresponding publication). Chapter 5 then uses a similar notation for keys and certificates, but introduces new elements in certificates related to liability of issuing parties. In order to facilitate further changes to certificate contents discussed in subsequent chapters, the Postscript section of Chapter 5 then introduces a generalized certificate format; this generalized format also defines notations for signatures and keys used in those following chapters. We invite the reader to refer that section, and the overview of definitions in Table 5.1, for notations related to certificates, keys and signatures used from Chapter 5 onward. the use of different key pairs; its high-level description in Chapter 4 does not explicitly mention this as it is not relevant to the discussion of accountability in that chapter.

Chapter 2 A Secure Account-Based Electronic Payment System Preamble In this chapter, we present ikp, a secure credit card based electronic payment system. As will be explained in Section 2.1, ikp actually stands for a family of three protocols with varying levels of security. The 3KP variant is the more secure version in that each of the three participants in a payment (buyer, seller and acquiring gateway) receives digitally signed evidence tokens of both other participants authorization of the transaction. 1KP and 2KP offer less security but require less pervasive public-key infrastructures; their security features as well as weaknesses will be discussed in detail. The ikp protocols illustrate a protocol design based on explicit goals of provability: the claims that various protocol participants need to be able to prove are informally described, and protocol messages are constructed based on their use as evidence proving these claims. Also, the design is guided by a number of privacy concerns: the protocols allow anonymity (but not unlinkability) of the buyer s payment towards the seller; and order information is not shared with the payment system provider. A distinction is made between strong evidence (evidence based on a digital signature) and weak evidence (evidence based on shared-key information). (The original paper [16] uses the terms non-repudiable proof and weak proof. For consistency of terminology with other chapters, we prefer the terms weak evidence and strong evidence.) The design illustrates the gradual introduction of strong evidence depending on which of the participants in the protocol are in possession of a public-key certificate and associated private signature key. By focusing security requirements on evidence, the ikp protocols represent an important reference point for protocol design based on accountability requirements. They have served as test material for the work on accountability and dispute resolution in Chapter 3; in Chapter 4, this framework serves as a basis for comparison of accountability features between ikp and SET [104], a protocol partially derived from ikp; this comparison provides some insights in the principles of designing protocols with goals of provability and accountability. Also the payment protocols based on pseudonymous certificates and anonymous credentials presented in Chapters 5 and 8 are inspired by the ikp protocols. This chapter contains the main body of the following paper [16]: M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik, E. Van Herreweghen, and M. Waidner. Design, implementation and deployment of the ikp secure electronic payment system. IEEE Journal on Selected Areas in Communications (JSAC), 18(4):611 627, 2000. The Appendix section containing detailed protocol specifications was not included here; references to it were modified accordingly. 17

18 Chapter 2. A Secure Account-Based Electronic Payment System The ikp protocols restrict the use of encryption to data related to the security of the payment itself, i.e. the payment slip containing the credit card number and price. Information not related to the payment, such as goods description, is integrity-protected but not encrypted. At the time of design of the protocols, this choice had the advantage of complying with the United States restrictions on the export of cryptographic products and tools; these advantages are referred to in the following chapter. Since then, U.S. crypto export regulations were relaxed (see, e.g., their current version [116] and a comprehensive description of policy changes in the 1998-2000 timeframe [34]); encryption of the full order information would not violate current export regulations. Section 2.2 refers to a 1997 survey of electronic payment systems. For more recent surveys we refer the reader to O Mahony et al. [96] and background papers from the European Institute for Prospective Technological Studies (e.g., [71, 72]).

Design, Implementation and Deployment of a Secure Account-Based Electronic Payment System Abstract This paper discusses the design, implementation and deployment of a secure and practical payment system for electronic commerce on the Internet. The system is based on the ikp family of protocols ikp (i = 1, 2, 3) developed at IBM Research. The protocols implement credit card-based transactions between buyers and merchants while the existing financial network is used for payment clearing and authorization. The protocols are extensible and can be readily applied to other account-based payment models such as debit cards. They are based on careful and minimal use of public-key cryptography and can be implemented in either software or hardware. Individual protocols differ in both complexity and degree of security. In addition to being both a pre-cursor and a direct ancestor of the well-known SET standard, ikp-based payment systems have been in continuous operation on the Internet since mid-1996. This longevity as well as the security and relative simplicity of the underlying mechanisms make our experience with ikp unique. For this reason, this paper also reports on, and addresses, a number of practical issues arising in the course of implementation and real-world deployment of a secure payment system. 2.1 Introduction and Overview At this day and age it is hardly necessary to justify, or stress the importance of, electronic commerce. Suffice it to say that it has been rapidly gaining momentum since early nineties, and has been equally appealing to on-line merchants, consumers and payment providers. There is a widespread agreement that to enable electronic commerce one needs the means for secure electronic payments. Indeed, the appeal of electronic commerce without electronic payment is limited. Moreover, insecure electronic payment methods are more likely to impede, than to promote, electronic commerce. Thus we begin with the premise that security for electronic payment is of the utmost importance. In this paper we present and discuss a family of secure electronic payment protocols ikp (i-key- Protocol, i = 1, 2, 3). These protocols are compatible with the existing card-based business models and payment system infrastructure. They involve three parties: the buyer (who makes the actual payment), the merchant (who will receive the payment) and the acquirer gateway (who acts as an intermediary between the electronic payment world and the existing payment infrastructure, and authorizes transactions by using the latter). Hereafter, we will refer to the acquirer gateway as simply the acquirer. 19

20 Chapter 2. A Secure Account-Based Electronic Payment System Within this framework we focus on the credit card payment model since it has been the most popular thus far and likely to remain so in the near future. However, note that other account-based payment models such as debit cards don t really differ from the credit card model from a technical viewpoint, and are easily supported by ikp. All ikp protocols are based on public-key cryptography, but they vary in the number of parties (out of the three involved) that possess individual public key pairs and hence can create digital signatures. This number is reflected in the name of the individual protocols: 1KP, 2KP, and 3KP. The ikp protocols offer increasing levels of security and sophistication as the number of parties who possess own public key pairs increases. The simplest protocol, 1KP, requires only the acquirer to possess a public key-pair. Buyers and merchants only need to have authentic copies of the acquirer s public key, reflected in a public key certificate. This involves a minimal public key infrastructure (PKI) to provide certificates for a small number of entities, namely, the acquirers. Such an infrastructure can be operated, for example, by a large credit card company. In the 1KP setting, buyers are authenticated on the basis of their credit card numbers, and possibly associated secret PINs. Payments are authenticated by communicating the credit card number and PIN, appropriately encrypted under the acquirer s public key, and properly bound to relevant information (purchase amount, identities, etc.). This prevents fraudulent merchants from collecting credit card numbers and creating phony payments. 1 1KP does not digitally sign messages sent by buyers and merchants. This means that disputes about the authenticity of payment orders are not unambiguoulsy resolvable within the digital system. 2 2KP demands that merchants, in addition to acquirers, hold public key-pairs and public key certificates. Messages originated by merchants are digitally signed. Additionally, 2KP enables buyers to authenticate merchants by checking their certificates, without any on-line contact with a third party. As in 1KP, payment orders are authenticated via the buyer s credit card number and PIN, encrypted before transmission. 3KP further assumes that buyers have their own public key-pairs and public key certificates, and thus messages by all parties involved are digitally signed. Payment orders are authenticated by the combination of credit card number, optionally a PIN, and a digital signature of the buyer. This makes the forging of payment orders computationally infeasible. Additionally, 3KP enables merchants to authenticate buyers on-line. This requires a full public key infrastructure covering all parties involved. The reason for designing these three variants was to enable gradual deployment: 1KP requires only a minimal PKI and would have been suitable for immediate deployment at the time it was proposed. 2KP requires a PKI covering all merchants, 3KP one covering all merchants and all card holders. The way how ikp and its successor, SET, are deployed showed that there was actually no need for 1KP. All ikp protocols can be implemented in either software or hardware. In fact, in 1KP and 2KP the buyer does not even need a personalized payment device: only credit card data and the PIN (if present) must be entered to complete a payment. However, for the sake of increased security, it is obviously desirable to use a tamper-resistant device to protect the PIN and in case of 3KP the secret key of the buyer. We emphasize that the goal of ikp is to enable payments. It is not concerned with any aspect of the determination of the order; it assumes that the order, including price, have already been decided on between buyer and merchant. It does, however, securely link order information into the payment to enable effective dispute handling. The ikp protocols do not explicitly provide encryption of the order information. Such protection is assumed to be provided by other existing mechanisms, e.g., SSL [58]. The decoupling of order encryption from the electronic payment protocol is an important design principle of ikp which supports 1 Strictly speaking, one cannot consider a number that is given to any restaurant waiter or receptionist a valuable secret, in any sense. But even if the buyer is not liable, knowing his or her credit card number is sufficient to commit certain frauds, and thus overall system security is improved if this number is protected. 2 From a legal point of view such ambiguities are not necessarily a problem provided there are fixed rules how to resolve them, and all parties are aware of these rules. Some consequences of systems where those rules were not appropriately designed are illustrated by Anderson [2].

2.2. History and Related Work 21 compatibility with different underlying browsing and privacy-protecting mechanisms. It also adds to the simplicity, modularity, and ease of analysis of the protocols. An additional advantage is freeing ikp from US export restrictions related to the use of bulk encryption. 3 Nonetheless, if desired, the ikp family (especially, 2KP and 3KP) can be easily extended to generate shared keys between buyer and merchant for protection of browsing and order information. The rest of this paper is organized as follows: Section 2.2 provides a brief summary of the history of ikp and its relation to the current credit card payment standard, SET. The different roles buyer, merchant, acquirer are introduced in Section 2.3, and their different security requirements are analyzed in Section 2.4. The ikp family is described and analyzed in Section 2.5, and an implementation architecture for it is proposed in Section 2.6. The actually implemented protocols are specified in detail in the Appendix of Van Herreweghen et al. [16]. 2.2 History and Related Work ikp was developed in early 1995 by a group of researchers at the IBM Research labs in Yorktown Heights and Zürich. Right from the beginning our goal was to work towards an open industry standard. We distributed the ikp protocols in the Internet Draft form, invited comments from the scientific community, and presented our design at the Internet Engineering Task Force meeting in Summer of 1995. Subsequently ikp was incorporated into the Secure Electronic Payment Protocols (SEPP), a short-lived standardization effort by IBM, MasterCard, Europay and Netscape. SEPP, in turn, was a key starting point for Secure Electronic Payments (SET), the joint VISA/MasterCard standard for credit card payments [104]. In fact, SET still retains some of the ikp-esque features. Other important ancestors of SET are the CyberCash Credit Card Protocol by CyberCash, and the Secure Transaction Technology (STT) by Microsoft and VISA. All these ancestors were proposed independently of each other but used more or less the same type of cryptographic protocols. From 1994 to 1996 an almost countless number of payment protocols for all kinds of payment models were proposed (see Asokan et al. [5] for a survey). One important difference between ikp and most of these proposals is that ikp was not just a paper design: The Zurich ikp Prototype (ZiP) is a fully operational prototype of 2KP and 3KP. Although ZiP never became a commercial product, it has been successfully deployed in a number of business trials in Europe and Japan since mid-1996. In 1998, Interpay Nederland was using ZiP in their I-Pay system, supporting 80 online merchants and 17000 card holders. Another important difference between ikp and other credit card payment protocols is its simplicity and to the extent the following term can be used elegance: We designed ikp from a small, well-defined set of security requirements (see Section 2.4), which resulted in a multi-party secure scheme where no party is forced to trust other parties unnecessarily. We focused on the core payment functionality and deliberately omitted all non-payment functionality that could be easily added on top of ikp, such as secrecy of order information or fair delivery of goods. Finally we designed ikp as a family of protocols, allowing for a gradual deployment. Today only two approaches for secure credit card payments over the Internet are practically relevant: SET, and encryption of credit card data via SSL [58], respectively TLS [51]. 4 SET and its ancestor ikp, in particular 3KP, are very similar. The main difference is in their complexity: ikp was designed as a lightweight protocol that provides the core payment functionality only, and is therefore relatively simple to understand and to analyze. SET was designed to support all options that exist in today s credit card operation and is therefore semantically much richer than ikp, but also much more difficult to analyze. SSL is the de facto standard for secure (i.e., encrypted and integrity-protected) client-server communication in the world wide web, and is integrated in virtually all web browsers and servers. SSL uses 3 We refer to the Preamble of this chapter for a discussion about the current status of such restrictions. 4 See also Section 1.5 for a discussion of payment mechanisms currently in use.

22 Chapter 2. A Secure Account-Based Electronic Payment System Payment System Provider Issuer Clearing Acquirer Buyer Payment Seller Figure 2.1: Generic Model of a Payment System public-key cryptography, like SET and ikp, but typically only servers (i.e., merchants) have public-key certificates while clients (i.e., buyers) are anonymous. Encrypting credit card data with SSL is certainly better than sending them in the clear, but the gain in payment security is very limited: For the acquirer the use of SSL is completely transparent no messages are signed and thus the merchant does not gain any security. SSL does not hide the credit card number or anything else from the merchant. Thus, it cannot be used for PIN-based authorization. Unlike SET or ZiP, SSL does not mandate any specific public-key infrastructure. Thus there is no guarantee that a buyer can verify the merchant s public-key certificate, and even if the certificate can be verified the semantics of such a certificate is not clear. Most types of payment systems, not just credit and debit cards, exist in the digital world. Typically each model requires its own type of protocols, i.e., one cannot expect that ikp can be applied to payment models that are very different to the credit card model. We refer to Asokan et al. [5] for a survey of other payment models and protocols. 2.3 Payment Model Parties. All ikp protocols are based on the existing credit card payment system. The parties in the payment system are shown in Figure 2.1. The payment system is operated by a payment system provider who has fixed business relations with certain banks who act as issuers of credit cards to buyers, or as acquirers of payment records from merchants (sellers). Each issuer has a Bank Identification Number, BIN, which it receives at the time it signs up with a payment system provider, and which is embossed on each credit card issued as part of the credit card number. The BIN also identifies the payment system provider. A buyer receives a credit card from an issuer, and is in possession of a PIN as is common in current systems. In 1KP and 2KP, payments will be authenticated only by means of the credit card number and this PIN (both suitably encrypted!), while in 3KP a digital signature is used, in addition to the credit card number.

2.3. Payment Model 23 It is assumed (as can be expected for electronic payment) that the buyer is using a computer to execute the payment protocol. Since this computer must receive the buyer s PIN or secret signature key, it must be a trustworthy device. We caution that even a buyer-owned computer is vulnerable: it may be used by several people and it may contain a Trojan horse or a virus that could steal PINs and secret keys. The best payment device would be a secure isolated computer, e.g., a tamper-resistant smartcard, connected to the computer used for shopping via a buyer-owned smartcard reader with its own keyboard and display. (This is often called an electronic wallet.) Technically, 1KP and 2KP can be used with any kind of payment device, while for 3KP the buyers need personal devices that store their secret signature keys and certificates. A seller signs up with the payment system provider and with a specific bank, called an acquirer, to accept deposits. Like a buyer, a seller needs a secure device that stores the seller s secret keys and performs the payment protocol. Clearing between acquirers and issuers is done using the existing financial networks. The ikp protocols deal with the payment transaction only (i.e., the solid lines in Figure 2.1), and therefore involve only three parties, called B Buyer, S Seller, and A Acquirer (gateway). Recall that A is not the acquirer in the financial sense, but a gateway to the existing credit card clearing/authorization network. In other words, the function of A is to serve as a front-end to the current infrastructure that remains unchanged. The protocols presented describe the core of a payment system only. Besides this, additional mechanisms are needed, e.g., for providing statements of account. Public Keys and Certification. Since all ikp protocols are based on public-key cryptography, we need a mechanism to authenticate these public keys. We assume a certification authority, CA, which has a secret key, SK CA. Its public counterpart, PK CA, is held by all other parties. CA will certify a public key of party X by signing the pair (X, PK X ) consisting of the identity of X and X s public key. (The signature is computed under SK CA.) Note that PK CA must be conveyed in an authenticated manner to every party. This will be typically done out-of-band, via any of a number of well-known mechanisms. For simplicity s sake, the following discussions assume that there is only one certification authority. However it is easy to extend the protocols to support multiple certification authorities, e.g., such that the payment system provider at the top-level authority issues certificates to its constituent issuers and acquirers, while these, in turn, issue certificates to their buyers and sellers. The implementation described in Section 2.6.3 indeed supports this hierarchical model. In all ikp protocols, an acquirer A has a secret key, SK A, which enables signing and decryption. Its public counterpart, PK A, (which enables signature verification and encryption) is held by each accredited seller together with its corresponding CA s certificate. As in current operation, acquirers receive the buyer s credit card numbers and PINs, and are trusted to keep these values confidential. In 2KP, each seller, and in 3KP also each buyer, has a secret/public key-pair. They are denoted by (SK S, PK S ) and (SK B, PK B ), respectively. Both public keys are included in certificates issued by CA. Adversaries and Threats. We consider three different adversaries: Eavesdropper who listens to messages and tries to learn secrets (e.g., credit card numbers, PIN s) Active attacker who introduces forged messages in an attempt to cause the system to misbehave (e.g., to send him goods instead of to the buyer) Insider who either is some legitimate party or learns that party s secrets. dishonest seller who tries to get paid without the buyer s authorization.) (One example is a Before listing the security requirements in Section 2.4, we briefly discuss common threats and attacks. The Internet is a decentralized, heterogeneous network, without single ownership of the network resources and functions. In particular, one cannot exclude the possibility that messages between the legitimate

24 Chapter 2. A Secure Account-Based Electronic Payment System parties would pass through a maliciously controlled computer. Furthermore, the routing mechanisms in the Internet are not designed to protect against malicious attacks. Therefore, it is folly to assume either confidentiality or authentication for messages sent over the Internet, unless proper cryptographic mechanisms are employed. To summarize, it is easy to steal information off the Internet. Therefore, at least credit card numbers and PINs must not be sent in the clear. In addition, one must be concerned about the trustworthiness of the sellers providing Internet service. The kind of business that is expected in the Internet includes the so-called cottage industry small sellers. It is very easy for an adversary to set up a shop and put up a fake electronic storefront in order to get buyers credit card numbers. This implies that the credit card number should travel from buyer to seller without being revealed to the seller (who needs only the BIN which can be provided separately.) Obviously, a good deal of care must be taken to protect the keys of acquirers. One of the biggest concerns is that of an adversary breaking into an acquirer computer through the Internet connection. Therefore, the acquirer s computer must be protected with the utmost care; including a very limited Internet connection using advanced firewall technology (e.g., [42, 41].) Furthermore, the trust in the acquirer s computer must be limited, so that a break-in would have a limited effect only. 2.4 Security Requirements In this section we consider a range of potential requirements for each party involved in the payment process: issuer/acquirer, merchant, and buyer. They range from mandatory security requirements to optional features. Issuer/Acquirer Requirements. The issuer and the acquirer are assumed to enjoy some degree of mutual trust. Moreover, an infrastructure enabling secure communication between these parties is already in place. Therefore, we join the requirements of the issuer and the acquirer. A1 Evidence of Transaction Authorization by Buyer. When the acquirer debits a certain credit card account by a certain amount, the acquirer must be in possession of unforgeable evidence that the owner of the credit card has authorized this payment. This evidence must not be replayable, or usable as evidence for some other transaction. This means it must certify at least the amount, currency, goods description, seller identification, and delivery address, and be obtained in such a way that replay is not possible. (We use a combination of time stamps and nonces for this purpose). Note also that in this context the seller may be an adversary, and even such a seller must not be able to generate a fake debit. We distinguish between: (a) Weak Evidence, which authenticates the buyer to the acquirer but does not serve as evidence for third parties, and (b) Strong Evidence is based on public-key signatures and can be used to resolve disputes between the buyer and the payment system provider. The same distinction will be made for all subsequently required pieces of evidence. A2 Evidence of Transaction Authorization by Seller. When the acquirer authorizes a payment to a certain seller, the acquirer must be in possession of unforgeable evidence that this seller has asked that this payment be made to him. Seller Requirements. We ask for two guarantees for the seller. S1 Evidence of Transaction Authorization by Acquirer. The seller needs unforgeable evidence that the acquirer has authorized the payment. This includes certification and authentication of the

2.4. Security Requirements 25 acquirer, so that the seller knows he is dealing with the real acquirer, and certification of the actual authorization information. Note that again the amount and currency, the time and date, and information to identify the transaction must be certified. We also distinguish between (a) Weak evidence and (b) strong evidence. S2 Evidence of Transaction Authorization by Buyer. Even before the seller receives the transaction authorization from the acquirer, the seller might need unforgeable evidence that the buyer has authenticated it. Again we distinguish between (a) Weak Evidence and (b) Strong Evidence. This requirement is necessary to provide for off-line authorization. Buyer Requirements. We ask for the following guarantees to the buyer who is making the payment. B1 Unauthorized Payment is Impossible. It must not be possible to charge something to a buyer s credit card without possession of the credit card number, PIN, and in case of 3KP, the buyer s secret signature key. Thus, neither Internet rogues nor malicious sellers must be able to generate spurious transactions which end up approved by the acquirer. This must remain the case even if the buyer has engaged in many prior legitimate transactions. In other words, information sent in one (legitimate) transaction must not enable a later spurious transaction. So in particular the PIN must not be sent in the clear, and not even be subject to guessing attacks! Similar to the two types of evidence of transactions, we distinguish between: (a) Impossibility, which means that unauthorized payments are impossible provided the acquirer is honest and its secret key is not available to the adversary, and (b) Disputability, which means that even if the acquirer s secret key is available to the adversary (e.g., because the adversary co-operates with an insider), the buyer can prove that he/she did not authorize the payment. In fact, these two requirements are typically met by meeting the corresponding acquirer requirements A1.a and A1.b, respectively. B2 Evidence of Transaction Authorization by Acquirer. The buyer would like to be in possession of evidence that the acquirer authorized the transaction. This receipt from the acquirer is not of paramount importance, but is convenient to have. Again, we distinguish between (a) Weak Evidence and (b) Strong Evidence. B3 Certification and Authentication of Seller. The buyer needs evidence that the seller is accredited at an acquirer (which could be considered as some guarantee for the trustworthiness of the seller). B4 Receipt from Seller. The buyer wants evidence that the seller who has made the offer has received payment and promised to deliver the goods. This takes the form of a digitally signed receipt. 2KP and 3KP will satisfy this requirement, but will not ensure fairness [7, 4]: The seller can always refuse sending this receipt while already having received the authorization message from the acquirer. In this case, the buyer must take the next statement of account as a replacement for this receipt. Additional possible buyer requirements. The following requirements (B5 B6) may also be desirable. Here we shortly discuss their relation to ikp; however, they are not explicitly addressed by the ikp protocols. B5 Privacy. Buyers want privacy of their order and payment information. For example a businessman may be purchasing the latest information on certain stocks and may not want competitors to know which stocks he is interested in. The privacy of order information and amount of payment

26 Chapter 2. A Secure Account-Based Electronic Payment System should be implemented independently of the payment protocol, e.g., based on SSL [58]. ikp does provide some privacy: it does not reveal order information to any other party than the seller, at least as long as there is no dispute. But it does not include encryption of these data. Obviously, credit card number and PIN must be protected carefully, which is achieved within ikp by encrypting them with the acquirer s public key. This is the only application of encryption in ikp. B6 Anonymity. Besides confidentiality of order and payment information, buyers may want anonymity from eavesdroppers and (optionally) also from the seller. It is also conceivable that the buyer may even want anonymity with respect to the payment system provider. ikp doesn t focus on anonymity and in particular does offer no anonymity from the payment system provider. This might be desirable for systems that aim to imitate cash, but is not essential for protocols, like ikp, that follow the credit card-based payment model. ikp tries however to minimize the exposure of the buyer s identity towards the outside and the seller. 2.5 The ikp Protocol Family In this section we present the three ikp protocols, i {1, 2, 3}. We first describe the cryptographic primitives used by the protocols, as well as their general structure. In the presentation, enough information (e.g., atomic and composite fields) is included in the protocol flows so as to show how the protocols satisfy the security requirements listed in the previous section. A complete description of this information is given in the protocol specification section, Section 2.6. Primitives and keys. Figure 2.2 summarizes the notation for the cryptographic keys held by the various parties, and the cryptographic primitives we will be using. While A s key pair must enable signature and encryption, all other key pairs need to enable signatures only. 5 Note that signing and encryption are independent operations; in particular, E X (S X (α)) α. The encryption function should be highly secure. Formally, the primitive we want is an encryption function which is secure against adaptive chosen ciphertext attacks [99]. This notion is known to be equivalent to the notion of non-malleability, which ensures that, given a ciphertext, it is computationally infeasible to generate a different ciphertext such that the respective plaintexts are related in a known manner. Two practical yet provably secure schemes to achieve this are OAEP + [105] and Cramer- Shoup [46]. 6 These schemes also provide message integrity, i.e., tampering with an encrypted value can be detected. While such encryption does not provide authentication in the manner of a signature, it can be made to provide an authentication-like capability between parties sharing a key (such as the BAN or PIN). We note that the encryption function is necessarily randomized: E X invoked upon message m will use, to compute its output, some randomizer, so that each encryption is different from previous ones. The hash function H( ) is used to compute a unique fingerprint of the transaction; by requiring that it be collision-free, we ensure that evidence tokens generated during the transaction can be unambiguously correlated with a specific transaction. The keyed hash function H k (K, ) is used to blind sensitive values such as the order description and the buyer s account number. The prototype implementation described in Section 2.6 uses RSA with key length 1024 for signature, and for the basis of the encryption; it also uses MD5 [101] as a hash function. Figure 2.3 is a list of quantities that will occur in the protocols. Their meaning and usage will be further explained as we go along. 5 For simplicity of exposition, we will be assuming in this section that each party has only one pair of keys; the prototype discussed in Section 2.6 uses dedicated pairs for encryption and signature. 6 The prototype implementation uses Bellare and Rogaway s original Optimal Asymmetric Encryption Padding, OAEP [18]. The proof of its security was shown to be incorrect by Shoup [105].

2.5. The ikp Protocol Family 27 Keys: PK X, SK X Public and secret key of Party X (X = Certification Authority CA, Buyer B, Seller S, Acquirer A). CERT X Public key certificate of Party X, issued by CA. We assume it includes X, PK X and CA s signature on X, PK X. All protocols assume A has a public key, and any party needing it has PK CA. 1KP assumes no other keys; 2KP additionally assumes S has a public key; 3KP further assumes B also has a public key. Cryptographic primitives: H( ) H k (K, ) E X( ) S X( ) A strong collision-resistant one-way hash function: it is computationally infeasible to find two inputs that map to the same hash value. (Example: SHA-1 [93]). a This one-way hash function requires in addition to collision-resistance that no information is leaked about the other arguments if its first argument K is chosen at random. I.e., H k (K, ) should behave like a family of pseudorandom functions. (Examples: HMAC [14, 81]). Public-key encryption using PK X. The encryption function is secure against adaptive chosen-ciphertext attacks and provides message integrity. Signature with respect to SK X. Note the signature of message M does NOT include M. We assume the signature function hashes the message before signing. a MD5 [101] was used in the actual prototype implementation of the ikp protocols. Today, MD5 is no longer considered collision-resistant. Brute-force collision search attacks have been shown to be feasible [120]; and collisions have been found for the compression function used in MD5 [52]. Figure 2.2: Keys and Cryptograhic Primitives Used in ikp Protocols Framework of ikp protocols. The protocols have a common framework. Figure 2.4 illustrates the flows at a very high level. Before the protocol begins, each party X {A, B, S} has some starting information represented by ST-INF X. The buyer starts with the public key PK CA of the certification authority. The seller has the certificate CERT A of the acquirer, and the acquirer has his own certificate CERT A plus the corresponding secret key SK A. They may each also have other information, which differs depending on whether we are in 1KP, 2KP or 3KP, and will be specified at the appropriate time. It is assumed that before the protocol starts, the buyer and the seller have agreed on the description and price of the items to buy. The functionality required to shop and agree on the item and price are to be provided by other means (e.g., the browser), not by ikp. 7 Thus, DESC and PRICE are part of the starting information of seller and buyer. The basic protocol consists of five flows. 8 The exact content of these flows depends on the protocol: they are different in 1KP, 2KP and 3KP. At a high level, however, there is a common structure. The buyer starts with an Initiate flow. The seller responds by providing the Invoice. The buyer then makes the Payment which the seller uses to send an authorization request Auth-Request to the acquirer. The 7 Indeed, the consensus nowadays is that functions that are beyond payment, such as price negotiation, should be separated, and standardized; e.g., JEPI [43], SEMPER [121]. 8 Later, in Section 2.6, we will be adding some additional flows to provide for the cancellation of a transaction, payment clearance, and inquiry of status of a specific payment.

28 Chapter 2. A Secure Account-Based Electronic Payment System Quantities occuring in all three protocols: SALT B PRICE DATE NONCE S ID S TID S DESC BAN R B ID B Y/N Text j Random number generated by B. Used to salt DESC and thus ensure privacy of order information (DESC) on the S to A link; also used to provide freshness of signatures (SIG S and SIG A). Amount and currency Seller s date/time stamp, used for coarse grained replay protection of a payment Seller s nonce (random number) used for more fine grained replay protection of a payment Seller id. This identifies seller to acquirer. Transaction ID. This is an identifier chosen by the seller which uniquely identifies the context. Description of purchase/goods, and delivery address. Includes payment information such as credit card name, bank identification number, and currency. Defines the agreement between buyer and seller as to what is being paid for in this payment transaction. Buyer s Account Number (e.g., credit card no.). Includes expiration date. Random number chosen by buyer to form ID B. It must be random (not just unique) in order to serve as evidence that the seller agreed to the payment. A buyer pseudo-id which ID B = H k (R B, BAN). Response from the clearing network: YES/NO or authorization code. For j = 0, 1, 2,.... This is optional information that can accompany the flows. For example, can be used to carry context identifiers. Quantities occuring in some of the protocols: PIN V Buyer PIN which, if present, can optionally be used in 1KP and 2KP to enhance the security. Random number generated by seller in 2KP and 3KP for use as evidence that seller has accepted payment (i.e., to bind Confirm and Invoice messages). Figure 2.3: Definitions of Atomic Fields Used in ikp Protocols acquirer goes through the financial network to obtain the authorization and returns an authorization response Auth-Response to the seller. The latter processes this to produce a confirmation flow Confirm for the buyer. The main difference between 1KP, 2KP and 3KP is the increasing use of digital signatures as more of the parties involved possess a public/private key pair. 2.5.1 1KP Protocol 1KP, illustrated in Figure 2.5, represents the initial step in the gradual introduction of a publickey infrastructure. Although it requires the use of public-key operations by all parties, only the acquirer, A, needs to possess and distribute its own public-key certificate, CERT A. In particular, the total number

2.5. The ikp Protocol Family 29 of certificates to be issued by the certification authority is small as it depends only on the number of acquirers. As mentioned in Section 2.3, all members of the ikp Family assume a public-key infrastructure with all parties holding an authentic copy of the certification authority s public key, PK CA. A buyer B has an account number BAN (e.g., a credit card number) known to the acquirer. It may also have a secret PIN which is known to the payment system (but not to the sellers!). Every seller has to know the certificate of the corresponding acquirer, CERT A. 1KP does not require A to keep a state per buyer. Instead, the buyer s PIN is verified using the existing authorization infrastructure (which uses tamper-resistant technology for processing and verification of PIN s). All parties in 1KP must perform certain public-key computations. Encryption is only applied once, for sending account data (and PIN) from the buyer to the acquirer securely. Therefore, public-key encryption is required from B only, while decryption is required from A only (this is true also for 2KP and 3KP). In 1KP, only A has to sign some data, which must be verified by B and S. We now provide the flow by flow actions of the parties. In the protocol, Common is the information held in common by all parties, and Clear is the information transmitted in the clear. Initiate: The buyer forms ID B by generating random number R B and computing ID B = H k (R B, BAN). Generates another random number SALT B to be used for salting the hash of merchandise description (DESC) in subsequent flows. Sets Text 0 to include desired protocol options (if any) and/or DESC. Sends Initiate. Invoice: The computation of the second flow, Invoice, takes place as follows. The seller retrieves SALT B and ID B from Initiate. Chooses/obtains DATE this is a time stamp, and indicates, say the hour as well. Generates nonce NONCE S. The combination of DATE and NONCE S will be used later by A to uniquely identify this order: the nonce disambiguates payments with a common DATE. Chooses transaction id TID S which identifies the context. Computes H k (SALT B, DESC). Forms Common as defined in Figure 2.5 and computes H(Common). (Note: Seller does not need to additionally salt H(Common) because it contains the already-salted H k (SALT B, DESC).) Composes Text 1. (If B did not already have CERT A then it could go here. Or this could include a context pointer for the buyer.) Finally sends Invoice. Buyer (ST-INF B) Seller (ST-INF S) Acquirer (ST-INF A) Initiate Invoice Payment Confirm Goods and Services Auth-Request Auth-Response Figure 2.4: Framework of ikp Protocols

30 Chapter 2. A Secure Account-Based Electronic Payment System Composite Fields: Common Clear SLIP EncSlip PRICE, ID S, TID S, DATE, NONCE S, ID B, H k (SALT B, DESC) ID S, TID S, DATE, NONCE S, H(Common) PRICE, H(Common), BAN, R B, [PIN] E A(SLIP) Starting information of parties: ST-INF B ST-INF S ST-INF A DESC, BAN, PK CA, [PIN] DESC, PK CA, CERT A SK A, CERT A Protocol Flows: SALTB, IDB, [Text0] Initiate: B S Clear { }} { ID S, TID S, DATE, NONCE S, H(Common), CERT A, [Text 1] Invoice: B S EncSlip { }} { Payment: B E A(SLIP), [Text 2] S Auth-Request: S Clear, H k(salt B, DESC), EncSlip, [Text 3] A SIG A { }} { Auth-Response: S Y/N, S A(Y/N, H(Common)), [Text 4] A Y/N, SIGA, [Text5] Confirm: B S Figure 2.5: 1KP Protocol

2.5. The ikp Protocol Family 31 Payment: Buyer retrieves Clear from Invoice. He retrieves ID S, DATE, TID S and NONCE S. He validates DATE within a certain time skew. He computes H k (SALT B, DESC); he already has PRICE and ID B, so that he can now form Common. He computes H(Common) and checks that this matches the value in Clear. He then forms the SLIP as defined in Figure 2.5. (It includes the price, the buyer s account number (credit card number), and H(Common). It also includes the salt R B used to form the ID B, and optionally the PIN if present.) The slip is now encrypted under the acquirer public key: he sets EncSlip = E A (SLIP). This, along with the optional Text 2, is the Payment flow sent to the seller. Auth-Request: The seller will now ask that the acquirer authorizes the payment. He forwards EncSlip. He also sends Clear and H k (SALT B, DESC), and optional Text 3. Auth-Response: The acquirer extracts Clear, H k (SALT B, DESC) and EncSlip from Auth-Request. It then does the following: (1) Extracts from Clear the following ID S, TID S, DATE, NONCE S and the value h 1 which is supposed to be H(Common). It now checks for replays. That is, it makes sure that there is no previously processed request with these values of ID S, TID S, DATE and NONCE S. (2) Now it decrypts EncSlip. If the decryption fails, then tampering with EncSlip (by an adversary or by S) is detected and the transaction is invalid. 9 If not, A gets SLIP. Now A extracts PRICE, the value h 2 which is supposed to be H(Common), BAN, R B, and, if present, the PIN from SLIP. (3) It checks that h 1 = h 2 this ensures that buyer and seller agree on the order information (price, identity of seller, etc). (4) It re-forms Common. (It has PRICE from SLIP. It has ID S, TID S, DATE, and NONCE S from Clear. It can compute ID B = H k (R B, BAN) because it has R B and BAN from SLIP. Finally it has H k (SALT B, DESC) from Auth-Request. These put together yield Common.) It then computes H(Common) and checks if this equals the value h 1 (= h 2 ) above. (5) Now it uses the credit card organization s existing clearing and authorization system to on-line authorize the payment: for this, it will forward BAN, PIN if present, the price, etc., as dictated by the authorization system. Upon receipt of a response Y/N from the authorization system, A computes a signature, using the function S A, on Y/N and H(Common). Finally it sends Auth-Response and possibly Text 4. The latter could include TID S so that the seller can easily recover the context. Confirm: The seller receives Auth-Response. He extracts Y/N and the acquirer signature. He already has H(Common). Now he checks that the acquirer sent a valid signature of Y/N, H(Common). He then forwards Y/N to the buyer. He also forwards the acquirer signature so that the buyer may check it. There are some final checks by the buyer: for example, he may want to check the acquirer s signature. We stress here that the use of H(Common) in the signature (as opposed to using the explicit values amount, currency, etc.), is done in order to protect the privacy of these data when transmitted to seller and buyer. We now look at which requirements 1KP satisfies. A1(a) Evidence of Transaction Authorization by Buyer. SLIP includes the BAN and the PIN. (The latter, if present, is known only to the buyer and payment system and is the basis of the security. If it is not present, one must assume the BAN is not known to an adversary.) Since B knows PK CA and verifies CERT A, it is ensured that B does not unwittingly send the BAN and PIN to a non-authorized party. 9 Chosen ciphertext attacks exist on RSA [22] and RSA-OAEP [88] that exploit an adversary s knowledge of the validity of a ciphertext. An encryption scheme which is secure against adaptive chosen ciphertext attacks is not vulnerable to such attacks. Care should, however, be taken that the implementation does not leak information about the specific reason for a decryption failure.

32 Chapter 2. A Secure Account-Based Electronic Payment System A decrypts and checks that the BAN and PIN are correct. The non-malleability of the encryption (see beginning of Section 2.5) implies that SLIP originated with the BAN and PIN holder. An adversary not knowing the BAN or PIN can neither create a fake SLIP nor modify the encryption of a legitimate one to his advantage. Replay of a SLIP by a dishonest seller will be detected by the combination of the DATE and NONCE S. There is an acceptable delay period T delay. Slips containing a particular DATE are kept until for T delay more time than that indicated by DATE. (For example, DATE could be the date and hour, and the delay period a day, meaning slips are kept for a day more than the DATE marked on them.) Within a particular value of DATE, different slips are disambiguated by the nonces. The security of the encryption (and in particular the fact that it is randomized) implies also security against dictionary-attacks. If the attacker knows all data in SLIP except PIN, he could compute encryptions E A (SLIP) for all possible values of PIN. With a deterministic encryption function, he could easily determine the correct PIN by comparing all encryptions with the one produced by C. Therefore, the encryption is randomized: every time SLIP is encrypted, a different ciphertext is produced, which excludes this type of attack. Note that PIN-based authentication provides weak evidence only. Signature-based authentication as used in 3KP provides digitally signed evidence. Moreover, the probability of guessing the correct PIN is much higher than the probability of guessing a valid-looking signature. It is important to stress that the transaction of which we want evidence includes the item description, and in particular the delivery address. It should not be possible for an adversary to divert a legitimate payment by changing the delivery address. The inclusion of H(Common) in A s authorization is to prevent such attacks. In particular it prevents a certain kind of person-in-the-middle attack that we now describe. An attacker that impersonates a seller can get the agreement of the buyer to buy something for a given amount. The adversary gets from the buyer an encrypted slip authorizing the payment. The adversary now impersonates the buyer to the seller, but this time the adversary buys for the same amount a (possibly) different merchandise with different delivery address and pays for it with the buyer s slip. Notice, however, that in this case there will be a mismatch between the view of the order by the real buyer and the seller, and, consequently, a mismatch in the value of H(Common). S1(b): Evidence of Transaction Authorization by Acquirer. The unforgeable, strong evidence is the digitally-signed message sent by A. The inclusion of H(Common) prevents the replay of authorization messages which would result in fake authorization of buyer s orders. Since the seller knows Common in advance, the signature would indicate any tampering in the information sent from seller to acquirer, and any disagreement between buyer and seller on the payment data. The inclusion of H(Common) both in the buyer-generated SLIP and directly in Auth-Request by the seller enables A to detect a disagreement between seller and buyer with respect to the order contents (even before submitting the transaction to the clearing network). B1(a): Unauthorized Payment is Impossible. This is a direct consequence of the achievement of A1(a). B2(b): Evidence of Transaction Authorization by Acquirer. As for S1(b). B5: Privacy. Some partial privacy is provided. Specifically, the acquirer is not given DESC, but rather H k (SALT B, DESC). Furthermore, the acquirer, or an eavesdropper on the acquirer-to-seller link, cannot obtain DESC via a dictionary attack, as we now explain. In a dictionary attack, the attacker has some small set of possible values of DESC, and want to see whether one of them is what the buyer is ordering. Had we not used the salt, but just sent H(DESC), the attacker could easily make the check by evaluating H on his values and seeing whether one of the results matches the value H(DESC) in the flow. But assuming he doesn t know SALT B then by salting DESC in H k (SALT B, DESC) all possible description DESC will will have the same likelihood due to

2.5. The ikp Protocol Family 33 the pseudo-random nature of H k (). Of course, if he was powerful enough to obtain SALT B of the buyerto-seller link (where it was transmitted in the clear) he would be able to do the dictionary attack, but that he can eavesdrop like that on both links is not too likely. Also, if privacy is really a concern, the buyer-to-seller communication may be protected by alternative means (e.g., SSL [58]). We stress that provision of privacy is not a primary concern of a payment protocol. However, we wish at least to not give anything away that should not be, and took the chance to add whatever privacy we could add without much cost. The last flow from seller to buyer in which the signed authorization by the acquirer is transmitted is optional. It only serves as a receipt for the buyer but is not needed for the security of the payment protocol. To summarize, 1KP is a simple and efficient protocol whose main achievement was (at the time of its design, circa 1995) to get a secure electronic payment system with as little modification as possible to the existing infrastructure. Its main weaknesses are: 1) the buyer authenticates itself via the acquirer and only using an account number and PIN (as opposed to a strong authentication via a digital signature); 2) the seller does not directly authenticate itself to the buyer or acquirer (there is some level of indirect authentication via the buyer s SLIP and the authorization by the acquirer); and 3) neither seller nor buyer provide strong evidence for the transaction. Upgrading 1KP to provide these missing features results in the protocols described in the next two subsections, namely, 2KP and 3KP. 2.5.2 2KP The second protocol, 2KP, is illustrated in Figure 2.6. The basic difference with respect to 1KP is that, in addition to A, each seller S needs to possess a public key with a matching secret key, and distribute its own public key, with its certificate, CERT S. We now describe the additions to the flows and actions. There are two new elements in Invoice. The first is that the seller chooses a random value V and puts H(V ) in Invoice. (The inclusion of V in Confirm will later serve as a (one-time) signature thereby saving the seller one signature computation. See below.) This value will be added to Common for what follows. Second, the seller signs (using SK S ) the pair of strings H(Common) and H(V ) and includes this signature SIG S in Invoice too. Furthermore the seller includes CERT S so that the buyer can check his signature. Upon receipt of Invoice the buyer checks the seller s signature, and then proceeds as before to generate Payment. Auth-Request is augmented by the seller to include the same signature SIG S he sent to the buyer earlier, together with CERT S. The acquirer checks this signature before authorizing payment. Finally, the value V is included by the seller in Confirm. The buyer computes H(V ) and checks that it matches the value sent earlier in Invoice. 2KP satisfies all the requirements addressed by 1KP as well as: A2: Evidence of Transaction Authorization by Seller. This is achieved by the inclusion of the seller s signature SIG S and certificate CERT S, and the acquirer s verification of these. B3: Certification and Authentication of Seller. Similarly achieved by inclusion of signature of seller and its check by buyer. B4: Receipt from Seller. This is achieved by the combination of S s signed message sent to A, A s signed authorization message, and the value V sent in Confirm. V assures the buyer (and any third party) that the seller has accepted the authorization response. (This is the payment if Y/N is yes, and the statement of rejection otherwise.) This is because no other party is capable of finding V. (It would require inverting the one-way function H on the point H(V ).) Note it is important here that the buyer check SIG A else an adversary can flip Y/N after the seller sends Y/N and V. Thus, the combination of SIG S, V and SIG A give the buyer strong evidence of the seller s agreement to the transaction s outcome (whether positive or negative). The same could be achieved by S signing A s authorization message, but at the cost of an additional signature. Clearly, the evidence value of V is linked to the value and contents

34 Chapter 2. A Secure Account-Based Electronic Payment System Composite Fields: Common PRICE, ID S, TID S, DATE, NONCE S, ID B, H k (SALT B, DESC), H(V ), H(V C) Clear SLIP EncSlip SIG S ID S, TID S, DATE, NONCE S, H(V ), H(V C), H(Common) PRICE, H(Common), BAN, R B, [PIN] E A(SLIP) S S(H(Common), H(V ), H(V C)) Starting information of parties: ST-INF B ST-INF S ST-INF A DESC, BAN, PK CA, [PIN] DESC, PK CA, CERT A, SK S, CERT S PK CA, SK A, CERT A Protocol Flows: SALTB, IDB, [Text0] Initiate: B S { Clear }} { ID S, TID S, DATE, NONCE S, H(V ), H(V C), H(Common), { SIG S }} { Invoice: B S S(H(Common), H(V ), H(V C)), CERT S, CERT A, [Text 1] S EncSlip { }} { Payment: B E A(SLIP), [Text 2] S Auth-Request: S Clear, H k(salt B, DESC), EncSlip, SIG S, CERT S, [Text 3] A SIG A { }} { Auth-Response: S Y/N, S A(Y/N, H(Common)), [Text 4] A Y/N, V/V C, SIGA, [Text5] Confirm: B S Figure 2.6: 2KP Protocol

2.5. The ikp Protocol Family 35 of SIG A and could be disputed as strong evidence. In the actual implementation (Section 2.6.2), this dependency is avoided by the seller signing two different committing values (V and V C) in SIG S and, in Confirm, revealing only the value corresponding to his view of the transaction outcome (positive or negative). Obviously, S can refuse forwarding A s authorization message to the buyer and sending its last message. In this case, B does not know whether the transaction was aborted or finalized (this must be handled based on the next statement of account). 2.5.3 3KP As can be expected, in the last protocol 3KP all protocol participants, including buyers, possess a public key, with the associated secret key and certificate. As illustrated in Figure 2.7, all parties are now able to generate and provide strong evidence. The CERT B sent to the seller may not only contain the buyer s public key and ID, but also further data. This further data is included in the certificate in salted hashed form using H k (). This allows to open the information only on demand and doesn t leak information to unauthorized users. For instance, CERT B might include the hash of the buyer s physical address, and if ordered goods should be sent to B s home address, B can reveal Buyer s physical address and the corresponding salt to the seller who can verify it based on CERT B. Similarly CERT B can securely link the BAN to the signing key. This allows the acquirer to efficiently verify that the payer has the necessary authority over BAN contained in the SLIP. See Krawczyk [81] for a more indepth study of this issue. The buyer s signature serves as strong evidence of transaction (A1.b), and enables disputability (B1.b). On the other hand, the sellers can link all payments of the buyer with CERT B and B s signature, i.e., the buyer loses some of the privacy compared to 1KP and 2KP. One way to avoid this is by encrypting CERT B and the signature with A s public key. Notice that in 3KP PIN numbers can still be used, but only for compatibility with the existing infrastructure. Except for that reason, PINs shared between buyer and the payment system can be safely omitted since the level of authentication provided by the buyer s signature is significantly superior to that provided by a PIN. Of course, the buyer can still use a local PIN or password to protect access to his signature key and account data. 3KP satisfies all the requirements addressed by 2KP, as well as: A1(b): Strong Evidence of Transaction Authorization by Buyer. The buyer signs the SLIP using a secret key SK B known to B only. S2(b): Evidence of Transaction Authorization by Buyer. Based on B s signature, S can verify that SLIP was signed by B. S cannot verify the correctness of the contents of SLIP, especially not of the PIN. B1(b): Unauthorized Payment is Impossible. Follows from A1.b. 2.5.4 Comparison of the Protocols The ikp protocols presented above vary in the degree of both protection and complexity. They proceed in an incremental path towards electronic payment with strong security features with respect to all parties involved. Practically speaking, it was envisaged at the time of the design that 1KP would represent a short-term, interim step towards payment protocols with stronger security guarantees. Thereafter, 2KP and 3KP could be gradually phased in. Table 2.1 presents a comparison of the ikp protocols. The ikp family can fulfill all stated requirements and, in particular, provide digitally signed receipts from the acquirer to the seller/buyer, and from the seller to the buyer. In case that the buyer also possesses a signature key pair (3KP), also the buyer s transaction authorization towards seller/acquirer

36 Chapter 2. A Secure Account-Based Electronic Payment System Composite Fields: Common PRICE, ID S, TID S, DATE, NONCE S, ID B, H k (SALT B, DESC), H(V ) Clear ID S, TID S, DATE, NONCE S, H(V ), H(Common) SLIP PRICE, H(Common), BAN, R B, [PIN] EncSlip E A(SLIP) SIG S S S(H(Common), H(V )) SIG B S B(EncSlip, H(Common)) Starting information of parties: ST-INF B ST-INF S ST-INF A DESC, BAN, PK CA, SK B, CERT B, [PIN] DESC, PK CA, CERT A, SK S, CERT S PK CA, SK A, CERT A Protocol Flows: SALTB, IDB, CERTB, [Text0] Initiate: B S { Clear }} { ID S, TID S, DATE, NONCE S, H(V ), H(Common), { SIG S }} { Invoice: B S S(H(Common), H(V )), CERT S, CERT A, [Text 1] S EncSlip SIG B { }} { { }} { E A(SLIP), S B(EncSlip, H(Common)), [Text 2] Payment: B S Auth-Request: S Clear, H k(salt B, DESC), EncSlip, SIG S, CERT S, SIG B, [Text 3] A SIG A { }} { Auth-Response: S Y/N, S A(Y/N, H(Common)), [Text 4] A Y/N, V, SIGA, [Text5] Confirm: B S Figure 2.7: 3KP Protocol

2.5. The ikp Protocol Family 37 Table 2.1: Comparison of the ikp Payment Protocols REQUIREMENTS/PROTOCOLS : satisfied based on weak evidence 1KP 2KP 3KP : satisfied based on strong evidence Issuer/Acquirer A1. Evidence of Transaction Authorization by Buyer A2. Evidence of Transaction Authorization by Seller Seller S1. Evidence of Transaction Authorization by Acquirer S2. Evidence of Transaction Authorization by Buyer Buyer B1. Unauthorized Payment is Impossible B2. Evidence of Transaction Authorization by Acquirer B3. Certification and Authentication of Seller B4. Receipt from Seller is based on a digital signature. Anonymity is not a focus of ikp but 1KP and 2KP provides nevertheless complete anonymity of the buyer to the seller (and the outside): the buyer uses a pseudo-identity ID B which is different in each transaction and therefore making the buyer s transactions pseudonymous as well as unlinkable. 3KP clearly leaks identity information through the certificates but through the use of pseudonyms buyers transactions can stay at least pseudonymous if not unlinkable. Note also that special care has to be taken when hiding the BAN information in the certificate. Order privacy against eavesdroppers could be achieved by applying a secure communication protocol (e.g., SSL [58]): such measure would not hide the URL being visited but would hide the transaction contents from eavesdroppers. Or, if desired, the ikp protocols themselves could be extended to provide that protection. Since ikp aims at credit-card-like payments, no anonymity against the payment system is provided. As will be shown in the next section the ikp protocols can easily be extended to support batch processing of payments from the same buyer by the seller, or to guarantee amounts as commonly done, for example, in the case of car rentals. Another avenue for extensions are micro-payments: the relatively high cost of credit card transactions makes ikp not directly suitable for payments of very small amounts. However, Hauser et al. [69] show how ikp can be extended to support micro-payments without loosing strong multi-party security. 10 The ikp protocols (more specifically, 2KP and 3KP or a combination thereof) were implemented at the IBM Zürich Research Lab. In the next chapter we turn to a more detailed description of the protocols as they were actually implemented and deployed. 10 Note that most other micro-payment protocols such as Millicent [60] and NetBill [45] gain their efficiency through the use of shared-key cryptosystems and therefore require complete trust in the payment system provider.

38 Chapter 2. A Secure Account-Based Electronic Payment System 2.6 ZiP: Implementation and Deployment 2.6.1 Protocol scenarios The 2KP and 3KP protocols described in the previous section form the payment authorization core of the ZiP implementation. Additional functionality was added during design and implementation as a result of users requests. This section focuses on the functionality of the implemented protocols; the Appendix of the full paper [16] contains their detailed specification. The final ZiP protocol suite includes four protocol scenarios which are summarized below: 1. Payment Authorization (2KP and 3KP augmented with cancellation option) 2. Payment Clearance (Capture) 11 3. Refunds 4. Inquiry Payment Authorization. This is the basic payment scenario described in Section 2.5 and Figure 2.4. The ZiP implementation, however, is augmented with an optional Cancel flow from the seller to the buyer after the Payment flow. The combined protocol flags set jointly by Buyer and Seller are listed in Table 2.2. The seller may choose (PFLAGS:CLRN) to combine payment authorization with payment clearing in which case the present protocol suffices. Alternatively, the seller may decide to only authorize payment and perform a separate clearance/capture function (described below) at some later time. If requested by the buyer (PFLAGS:CONFIRM), the seller sends a Confirm to the buyer (optionally containing SIG A if PFLAGS:SIG A was set) regardless of the acquirer s decision (positive or negative) in Auth-Response. If the seller chooses to (or is forced to) delay contacting the acquirer, he can send a Status flow (see below) to the buyer after receiving Payment. This is to keep the buyer abreast of the transaction status. Alternatively, the seller can elect to take the risk and send a Confirm to the buyer without having any real contact with the acquirer. In the event that the seller is unable or unwilling, for some reason, to process the buyer s payment, the payment authorization protocol may be truncated (terminated) with a Cancel flow before trying to contact the acquirer. The payment authorization protocol may also be suspended by the Buyer after the second (Invoice) flow. This abbreviated version can be used for gathering SIG S s (i.e., signed invoices) from multiple sellers for the purpose of browsing and comparative shopping. The abbreviated protocol run can be resumed at a later time provided that SIG S is still timely/valid. Separate Payment Clearance/Capture. The protocol is shown in Figure 2.8. At the discretion of the seller, payment clearance may be performed either as part of authorization (described above) or postponed until later. This protocol supports delayed/separate clearance. (Of course, an acquirer may dictate its policy on this subject to all constituent sellers.) The seller is allowed to perform multiple clearance transactions against the same payment authorization until the amount authorized by the acquirer is reached. The clearance flows are further distinguished by a sequence number (CLRN-SEQ). Refunds. Sellers may issue refunds for previously cleared payments. Although it is understood that refunds are typically triggered by consumers/buyers, the interaction between buyer and seller that leads to an eventual refund is assumed to take place off-line (i.e., outside ikp/zip.) 11 The terms clearance and capture are used interchangeably.

2.6. ZiP: Implementation and Deployment 39 Table 2.2: Protocol Flags Used in ZiP PFLAGS:SIG B PFLAGS:SIG S PFLAGS:CONFIRM PFLAGS:SIG A PFLAGS:CLRN PFLAGS:noEnc Buyer s signature SIG B in Payment and Auth-Request. While this option is at the discretion of the buyer, a seller can refuse to issue an Invoice if it is the seller s policy to always require SIG B and the buyer is not able to provide it. IMPORTANT: PFLAGS:SIG B must be fixed for a given buyer-account combination. In other words, a buyer who has the ability to generate signatures must always do so. However, it is ultimately the acquirer s responsibility to make sure that a buyer with a signature capability always uses PFLAGS:SIG B. Sellers s signature SIG S in Invoice. This option is set by the buyer but, as before, a given seller can refuse to comply because, for example, it is not interested in giving out signed offers for buyers that aren t ready to pay. Indicates that Confirm is requested. It is set by the buyer; it is envisaged that every seller should support this option. SIG A is requested in Confirm. It is set by the buyer. NOTE: this option can only be used in conjunction with the PFLAGS:CONFIRM option. Authorization and clearance (capture) are performed together. This option is set by the seller. While a buyer may, in principle, refuse it, it is not likely. The buyer does NOT use encryption; SLIP is sent in the clear. This flag is set by the buyer. Sellers have no say over this option. The purpose of this option is to avoid the expense of encryption in cases when BAN s are not treated as secret or sensitive information. NOTE: this option can only be used in conjunction with the PFLAGS:SIG B option. Within ikp/zip, a refund transaction for all practical purposes is equivalent to (and treated as) a clearance/capture transaction. This is mainly because a refund is, essentially, a clearance with the lower amount. The difference between a refund and a clearance manifests itself only within the domain of the financial clearing network. Inquiry. The buyer can ask the seller about the status of a specific payment. The protocol is shown in Figure 2.9. The buyer may transmit Inquiry at any time after submitting a Payment flow. The seller Buyer Seller Acquirer (after previous auth.) Clrn-Request Clrn-Response Figure 2.8: The Payment Clearance/Capture Scenario

40 Chapter 2. A Secure Account-Based Electronic Payment System Buyer Seller Acquirer Inquiry Status, Confirm or Cancel Figure 2.9: The Status Inquiry Scenario must be able to respond for some time after the payment transaction is completed; the exact time period is the choice of the seller or may be specified by the financial institutions. 2.6.2 Implementation Rationales and Explanations This section explains some of the features of the ZiP protocol design. For the detailed ZiP protocol specifications, we refer to the Appendix of the full paper [16]. Opaque Fields. Some protocol fields are treated opaquely by ZiP. Opaque in this context means that these flows are not carried within the protocol messages. At the same time, these fields are authenticated and integrity-protected by ZiP. Some of these fields may (and sometimes have to) be tacked on by the higher-layer software. These fields are: DESC. Purchase details (e.g., merchandise description) may have to be explicitly transmitted between buyers and sellers. However, it is not recommended for transmission to the acquirer. TID S and TID B. 12 Seller s and buyer s transaction identifiers are generated outside of ZiP (by the higher-layer software). By virtue of being part of Common they are integrity-protected by ZiP. Details of their transport is left unspecified. Since both values serve as input to the hash H(Common), association management and replay detection by the Transaction Layer (see Section 2.6.3) will largely be based on H(Common). (An exception is Initiate: since this flow doesn t contain H(Common), TID B is used as the replay detection key for this flow.) All fields of the form OPT-SIG Z are (as the name suggests) optional. Like the Text i fields in Section 2.5 they carry optional data; unlike Text i, OPT-SIG Z fields are included in the respective SIG Z signatures. For example, they can be used to carry credentials/certificates of various entities (hence their absence from the ZiP protocol flows), or other optional data like periodic account statements. Receipt from Seller. The protocols in Section 2.5 only have one committing value V whereby the Seller commits to whatever outcome is signaled by the Acquirer in SIG A. In ZiP, there are two different committing values: V (used for positive Confirm messages) and V C (negative Confirm and Cancel). Thus, the combination of SIG S and V provides the buyer with a digitally signed receipt of the payment; while the combination of SIG S and V C is evidence for the buyer that the seller committed to never capturing this payment. Note that by using different values (V, V C) for positive and negative confirms (as opposed to the 2KP/3KP protocols in Section 2.5), these values now commit the Seller to a unique transacton outcome without linking with a SIG A. This allows for a cleaner decoupling of the payment receipt (SIG S, V or SIG S, V C) by the Seller from the transaction authorization (SIG A ) by the Acquirer. It also explains why a Confirm(PFLAGS:CONFIRM) without 12 In the ZiP implementation, a buyer transaction identifier TID B was added to Common in order to allow for input by the Buyer in the set of transaction identifiers (TID S, TID B ) used for association management and replay detection.

Certificate Library 2.6. ZiP: Implementation and Deployment 41 SIG A (PFLAGS:SIG A) does have a value as a receipt.) Typing of Message Fields. Every signature type generated in ZiP is assigned a unique signature identifier. Every signature operation (generation/verification) automatically includes a signature identifier for a specific signature type. The same holds for all hash function computations. The following distinct signature types are identified: SIG B, SIG S, SIG A, SigClrn S, SigClrn A. The following hash function computations are uniquely identified: H(Common), H(V ), H(V C), H k (R B, BAN) and H k (SALT B, DESC). Performance. Cryptographic operations such as computation/verification of public-key signatures and en/de-cryption are computationally expensive. The use of RSA signatures with exponent 3 limits this performance overhead; ikp and ZiP are designed to further improve performance by minimizing the number of cryptographic operations. Adherence to Export Regulations. The protocol is designed to minimize the amount of data encrypted, in order to satisfy the export control rules of the U.S. government. As described in the Appendix of the full paper [16], only SLIP is encrypted, and the data therein is limited to financial information. 2.6.3 Architecture Glue Buyer / Seller / Acquirer Application Comm Transaction Manager Buyer Seller Acquirer ikp Library Safe Storage Crypto Crypto Library (BSAFE) Figure 2.10: ZiP Implementation Architecture Figure 2.10 shows the architecture of ZiP. Buyer, Seller and Acquirer applications, residing on different network nodes, access the ikp functionality through the Transaction Layer interface. The Transaction Layer provides the payment applications with a high-level (C++) interface using simple payment objects, such as a BuyerTransaction class with methods Initiate(), Pay(), Inquiry(). The Transaction Layer takes care of association management, audit and configuration. The assocation management finds transactions matching incoming messages based on transaction ids (or H(Common), as described in Section 2.6.1). It detects duplicate messages and unexpected messages, i.e., those not corresponding to an outstanding or

42 Chapter 2. A Secure Account-Based Electronic Payment System recorded transaction. Unexpected requests are acknowledged with an error message, unexpected replays are ignored. The Transaction Layer realizes robustness of the ZiP protocols in the presence of failures. It keeps transaction state in persistent storage and recovers from system crashes. To overcome unreliable communication, the Transaction Layer tries retransmitting after appropriate timeouts. The replay detection in the Transaction Layer will catch this and correspondingly resend the previous reply. Messages are idempotent, i.e., applying the same message a second time does not change a participant s state. The Comm module sends ikp messages between different ZiP users. transport mechanisms such as HTTP, Internet e-mail, TCP/IP. It supports several underlying Glue is an optional part that glues the network-independent buyer application to a user application such as a WWW browser [68], a CD-ROM catalog, etc. Payment applications, Transaction Layer, Glue, Comm and Safe Storage are all implemented in C++. The lower layers, consisting of the ikp, certificate and crypto libraries, are written in C. The ikp Library [115] provides the core functionality for composing and verifying ikp protocol messages, using Certificate Library for verifying certificates and Crypto for accessing cryptographic primitives. The ikp Library allows Buyer, Seller and Acquirer applications to verify received ikp messages against a context kept by the Transaction Layer, and to compose ikp messages to be sent. It returns an updated state to the Transaction Layer after each successful verification or composition. Crypto separates the ikp protocol functionality from the cryptographic functionality, and allows support for different cryptographic toolkits. The Crypto API consists of methods for signature generation and verification, encryption and decryption, hashing and key handling (generation, destruction). The ZiP Crypto module is based on the RSA and MD5 functions of the RSA BSAFE 2.1 library. It provides the SLIP encryption function based on RSA-OAEP with MD5. It also provides an interface for seeding the random number generator and implements seed collection combining various sources of randomness such as network traffic and inter-keystroke intervals of user-provided data. ZiP also implements a dummy Crypto module which allows for non-export-controlled and platformindependent testing, and serves as an example for implementors of new crypto modules. The Certificate Library implements a simple certificate issuing and verification functionality for certificates and certificate chains in a hierarchical model. The content of the certificates is taken from the X.509 v.2 [73] certificate format. 2.6.4 Deployment At Europay s Annual Members Meeting in Seville, Spain, in June 1996, Europay and IBM jointly ran a small-scale trial allowing visitors to the conference to use their pre-loaded Europay CLIP purse card to make secure internet payments from a card reader-equipped terminal. The payment scheme used was an integration of CLIP card payment functionality with ZiP-3KP, resulting in a secure scheme for Internet payments from pre-loaded purses. From April 1997 till February 1998, the EMP (Electronic Market Place) project in Japan, funded by MITI (Ministry of International Trade and Industry), deployed ZiP-3KP in a trial with 5 on-line merchants and 2000 users. Each user received a smart card storing his/her ZiP account (keys and certificates), allowing secure Internet purchases from public kiosks and terminals. ZiP was also the payment technology behind the I-Pay payment product offered by Interpay Nederland and the Dutch banks. I-Pay was launched as a trial in June 1996, offering debit-type purchases from initially twenty on-line shops, using ZiP-3KP. Later, Eurocard/Mastercard credit card payments were added to the I-Pay brand. In 1998, I-Pay was accepted by 80 on-line merchants and has a user base of 17000 users. In line with initial plans to use ikp only for the initial trial and to move to the more standardized SET [104] technology once available and accepted, ZiP technology was replaced with SET technology in 1999.

Postscript 43 Postscript This chapter discussed the design, implementation and deployment of the ikp payment protocol. It illustrates a protocol design based on requirements of provability; the protocols are used in the following chapters as a reference point for testing and illustrating provability features of electronic transaction protocols. My contribution to the full paper [16] this chapter is based on has been mainly in the fine-tuning, extensions and detailed specifications of the protocols in Section 2.6 that enabled their realization in the ZiP prototype; also, I have contributed to the development of the architecture and the implementation of the prototype, and to the installation and operation of the prototype and demonstrators at various sites. ikp is not anymore in use. As mentioned in Section 2.6.4, ikp was meant to be used only for trials and to be replaced by the more standardized SET [104, 70] protocol once SET technology was available. This was the case for the I-Pay pilot in the Netherlands. However, also SET never made it to large-scale deployment. In 2001, Visa and MasterCard, the two credit card companies behind SET, formed a new corporate entity called SET Secure Electronic Transaction LLC SETCo. The goal was to provide a structure that would govern and direct the future development of the SET Secure Electronic Transaction protocol, as well as other key functions required to support the implementation of the standard. SETCo managed the SET specification [104], oversaw software compliance testing and coordinated efforts related to the adoption of SET as the global payment standard. As of today, SETCo s website (http://www.setco.org) has disappeared from the web. In Section 1.5, we discussed a number of possible reasons for the failure of SET and compared with payment mechanisms currently in use.

44 Chapter 2. A Secure Account-Based Electronic Payment System

Chapter 3 Accountability and Dispute Handling in Payment Systems Preamble In this chapter, a framework is proposed for supporting accountability and dispute handling in payment systems. A payment system-independent language is presented in which accountability or dispute claims can be stated. Statements in this claim language do not refer to specific protocols or service primitives but are about primitive transactions which map to partial value transfers of the overall payment transaction involving a payer, a payee and a bank; these primitive transactions are payment between payer and payee, value subtraction between payer and bank, and value claim between payee and bank. By using these primitive transactions as a basis for the claim language, it supports disputes between each pairwise set of players, regardless of the actual payment system or model (account-based, pre-paid). For a specific choice of payment system, claims in this language are then supported by payment system-specific evidence tokens. A simplified version of the ikp payment protocols, introduced in the previous chapter, is used to illustrate this claim-evidence mapping. The original claim language developed in this chapter allows basic statements about completed primitive transactions (payer A paid amount X to payee B, payer A subtracted amount Y from bank C) as well as modal statements about the possibility or impossibility of certain transactions being brought to completion. Modal statements take into account reversal of transactions as well as intermediate protocol states in which a party could (but not necessarily did) complete a transaction. Subsequent chapters use this language and framework as a basis for reasoning about how transaction protocols support accountability by specifying a mapping between provable claims or statements on the one hand, and evidence needed to prove these claims on the other hand. In Chapter 4, we analyze accountability features of SET and ikp; as we do not consider intermediate protocol states or reversible transactions, we only use a subset of the claim language corresponding to the basic statements; this suffices to describe the most important accountability features of the protocols. In Chapter 5, the payment protocol used as a starting point for pseudonymization is again derived from the requirements for disputable payment protocols laid out in this chapter; the pseudonym server translating the user s non-pseudonymous payments into pseudonymous ones limits his risk by comparing the evidence value of evidence tokens in the non-pseudonymous vs. the pseudonymous transaction. In the same chapter, there is also a strong focus on the evidence value of certificates; this evidence value is discussed informally and we do not develop a new or extended claim language for it. Reasoning about the evidence value of certificates is necessary in order to provide accountability and guarantees of liability (by the user or by the certificate issuer) towards relying parties especially in anonymous transactions. With this reasoning, the evidence value of a token in a transaction (e.g., a payer s signature 45

46 Chapter 3. Accountability and Dispute Handling in Payment Systems in a payment transaction) is combined with the evidence value of the certificate (chain) certifying the signer s (payer s) public key in order to determine guarantees towards the relying party (the payee). Depending on certificate registration procedures, this can be a guarantee by the payer s bank, or a guarantee of liability of a legal entity behind the payer s potentially pseudonymous identity. Chapter 7 uses this reasoning also in the environment of anonymous credentials; we again determine the evidence value of evidence tokens in the anonymous credential system, and complement it with the evidence value of certificates in the surrounding certificate infrastructure in order to make statements about guarantees towards relying parties. Chapter 8 carries this reasoning further by comparing the evidence value of evidence tokens in similar payment applications of which some use conventional certificates, and some use anonymous credentials. Also in Chapter 9, the equivalence between accountability features of a certificate- and a credential-based protocol is discussed by comparing evidence tokens and claims they can support. This chapter contains the following paper [8]: N. Asokan, E. Van Herreweghen, and M. Steiner. Towards a framework for handling disputes in payment systems. In Proc. 1998 USENIX Workshop on Electronic Commerce, pages 187 202. USENIX Association, Sept. 1998. Minor editoral changes have been made in order to provide consistency of terminology with other parts in this work. References to non-repudiation were replaced with accountability; non-repudiation tokens were renamed evidence tokens. Note that, from here on, we do not make a distinction between strong and weak evidence tokens evidence tokens by default will be strong.

Towards A Framework for Handling Disputes in Payment Systems Abstract The ability to support disputes is an important, but often neglected aspect of payment systems. In this paper, we present a language for expressing dispute claims in a unified manner, independent of any specific payment system. We illustrate how to support claims made in this language with evidence tokens from an example payment system. We also describe an architecture for dispute handling. Our approach may be generalised to other services where accountability is a requirement. 3.1 Introduction 3.1.1 Importance of Dispute Handling in Electronic Commerce Services in an electronic commerce system involve more than one player. An effective system guarantees that if all players behave correctly ( honestly ) according to some pre-defined protocol, each player obtains the services it expects. A system with integrity [98] guarantees that, in addition, honest players are also protected against the incorrect behaviour of other players they do not trust. For example, in a payment system, an integrity requirement of an honest payer is that the payee receives at most the amount of value authorised by the payer. Sometimes practical considerations may render it desirable to settle for a weaker form of integrity the integrity requirement is modified as follows: even if the system is not able to prevent a dishonest player from causing harmful effects to the honest player(s), it must allow the honest player(s) to later prove the behaviour of the dishonest player. Standing order payments is an example. The payer instructs his bank to allow periodic value transfers requested by the payee (e.g., for paying utility bills). While the payer cannot prevent the payee from requesting more money than necessary (e.g., more than the amount of the monthly bill), he can prove the amount transferred by obtaining a statement from the bank. Furthermore, electronic commerce transactions typically have legal significance in the real world. This means that even if a transaction is concluded successfully, there may be subsequent disputes about what happened during the transaction (or whether in fact an alleged transaction took place). Thus, the ability of an honest player to win any dispute about a past or current transaction is often an important requirement. 3.1.2 Handling Disputes Even those systems which have accountability as one of their major goals (signature systems such as RSA [102], payment systems such as SET [104], or integrated electronic purchase systems such as Net- 47

48 Chapter 3. Accountability and Dispute Handling in Payment Systems Bill [45]), usually limit themselves to the generation and collection of evidence. Analysis of these systems may include proofs which demonstrate that the collected evidence is enough to win any disputes. It is assumed that such evidence can be used in some dispute resolution procedure external to the system. Obviously, this is not practical: it excludes the possibility of the system making its own decisions based on the outcome of disputes, or internally trying to recover from errors or failures (e.g., caused by loss of a network connection). Moreover, evidence tokens are essentially part of the internal structure of the system; their structure and raw contents are not relevant outside the system. For instance, a payment receipt in the form of a digital signature is outwardly just a string of bits. Even if the receipt is in a format which allows anyone to securely verify who signed it, and when it was sent or received, the semantics to the evidence have to be added by the system itself. Outside the system (that is, from the point of view of the user of a system), what is necessary is to know what the evidence means, and how it can be used in disputes. Thus, a system providing a primary service (e.g., a payment service) should also support a dispute service. The dispute service specifies how to initiate and resolve disputes for the given primary service. In a dispute, there is a set of (one or more) players called initiators who start the dispute and another set of players called responders who participate in it. A special player called the verifier or arbiter makes, or helps in the making of, the final decision regarding disputes, according to some well-defined procedures which can be verified by anyone. The initiator(s) try to convince the verifier of a claim. Initiators may support their claims by producing evidence or engaging in some sort of a proof protocol. Responders may attempt to disprove the claims. The verifier analyzes the claims made and the evidence presented. This analysis may lead to a judgment as to whether a dispute claim is valid or not. Completely automated dispute resolution may not always be feasible or even desirable. Our dispute handling service should instead be used as a tool in human-driven dispute resolution. For example, it can be used by an expert witness in court in order to support his testimony. Or, it can be used by an entity like the Online Ombuds Service [77] which is not a legally competent authority but helps players resolve their disputes. In these cases, the verifier does not make a final decision. Instead, it presents an analysis of the evidence to a human judge. The verifier may even be one of the players themselves, trying to settle a dispute in a friendly way without going to court, or trying to convince itself of which disputes it can win. The first step in developing a coherent approach to dispute handling is to figure out how to define a dispute handling service given the description of some primary service. To keep the problem tractable, we focus on handling disputes in payment systems we will however attempt to stay general as far as possible so that the approach outlined here has the potential of being applicable to other types of generic service definitions as well. Our goal is to stay independent of any specific payment system. This approach is consistent with existing efforts to define generic payment services [1, 108] which enable users (human users or applications acting on their behalf) to invoke payment services in a system-independent fashion. In trying to preserve the same generality in the definition of the dispute service, we aim at developing a unified framework integrating both payment and dispute services. In Section 3.2, the problem of how to express dispute claims is studied. In Section 3.3, the problem of how to map evidence tokens to dispute claims is investigated. This mapping is payment system-specific and needs to be done internally in every payment system. As an example, we will use a simplified version of the ikp (Chapter 2) payment protocol. 1 An overall architecture for dispute handling, including a general dispute resolution protocol, is also described. 1 SET is the proposed standard for credit card payments on the Internet. However, we will use ikp here since its simplicity helps illustrate the approach more clearly.

3.2. Expressing Dispute Claims 49 3.2 Expressing Dispute Claims 3.2.1 What to Dispute? Consider a payment system which implements the services defined by a generic payment service (e.g., the one described by Abad-Peiro et al. [1]). The primary purpose of the generic payment service is the transfer of value from payer to payee. To make a value transfer, the payer tells the system who the payee is, what amount is to be transferred, and certain other parameters. pay $200 to BobAir ( #434: for flight 822 on Jan 19 ). In a generic payment service, and using the ISO-OSI approach of modelling a distributed system [84], this may be represented by a service primitive pay which could take the following pieces of information as parameters: payee, amount and ref (an external reference string enabling the payment transaction to be linked to an external context). In order to complete the value transfer, the payee invokes a receive primitive with input parameter ref (optionally also payer and amount) and output parameters payer, amount. Figure 3.1 illustrates the interface events during a payment. Alice pay (BobAir,$200,ref,..) paid() BobAir receive(ref) received(alice,$200,..) payment protocol Figure 3.1: An Example Payment Transaction Before formally defining a language to express dispute claims, let us attempt to get an idea of the kinds of claims that need to be expressed. What sorts of disputes, related to the above value transfer, does the payer (Alice) expect to be able to initiate and win? For example, Alice may want to claim that she paid $200 to BobAir (perhaps because BobAir refused to send the tickets claiming no payment was made), or her payment was made before Jan 12 (perhaps because there was a deadline). Some disputes may be about negative claims: for example, BobAir may want to prove that BobAir did not receive $200 from Alice. In other words, dispute claims are statements about the characteristics of value transfer. These characteristics are determined by the service primitives used, together with their parameters, and additional contextual information (such as the time of value transfer).

50 Chapter 3. Accountability and Dispute Handling in Payment Systems In addition to the payer and payee, a financial institution may be involved in creating a digital representation of money or converting it back to real value. Thus the value transfer may involve two or more sub-protocols involving different pairs of players. For example, in a cheque-like [1] model, the payer sends a form (e.g., a cheque or a credit card slip) to the payee using a payment protocol and the payee may use a deposit or capture protocol to claim the real money. This leads to two other types of dispute claims. Suppose BobAir makes an offer to Alice for a cheap ticket if she made the payment before Jan 12. Alice goes through the steps of the payment protocol (e.g., sending a credit card slip). However, BobAir changes his mind after receiving the credit card slip he does not capture Alice s payment. Alice cannot of course prove that the value transfer took place. But if she has a signed acknowledgement from BobAir, she can prove that the value transfer could have taken place without further help from Alice, if BobAir had wanted. Suppose Alice pays $200 to BobAir using a debit card. Later, she finds an entry in her monthly statement indicating a debit of $300. Alice may now want to start a dispute with the bank claiming that she approved a debit of only $200. In other words, a single original transaction could lead to two different types of disputes: one involving the payer and the payee, and the other involving the payer and the bank. 3.2.2 Value Transfers as Primitive Transactions Users expect a system to provide a certain service. Therefore, disputes in the system are about an instance of the service that was or could be provided. The primary service provided by the generic payment service is value transfer from one player to another. The model by Abad-Peiro et al. [1] assumes four types of players involved in value transfer: the payer, the payee, the issuer, and the acquirer. Value transfers between the issuer and acquirer are carried out over traditional banking systems; this transfer is outside the scope of the generic payment service. Thus, for the purpose of our disputes, we will consider the issuer and acquirer as a single entity, called the bank. As shown above, we also need to express and conduct disputes about transfers between payer or payee and bank. This requirement leads us to follow the approach taken by Abad-Peiro et al. [1] of defining three different types of value transfer as shown in Figure 3.2. Bank value subtraction value claim payment Payer Payee Transfer of "real" value Figure 3.2: Value Transfer Transactions In value subtraction, a user allows the bank to remove real value from the user; this implies the user s right to spend electronic value.

3.2. Expressing Dispute Claims 51 In value claim, a user requests that the bank gives real value to the user. In payment, the payer transfers value to the payee. We now define a primitive transaction as an instance of one of these value transfers. transaction represents a partial view of a subset of the players on the overall transaction. A primitive In some cases, a primitive transaction actually corresponds to a protocol run of the underlying payment system. For example, a withdrawal protocol run in a cash-like system is a value subtraction primitive transaction. Thus, value subtraction completes independently of and before the actual payment. The payment and value claim complete after the actual cash payment protocol is run and the payee has deposited the coins with the bank. In other cases, the primitive transaction is a purely virtual one and represents only the view of a subset of the players. For instance, a payment protocol run in a cheque-like payment system is seen by the set {payer, bank} as a value subtraction primitive transaction while it is seen by the set {payer, payee} as a payment primitive transaction. Given the definition of a generic payment service, one can make a mapping between its service primitives on the one hand, and the primitive transactions (payment, value subtraction, value claim) effectuated by those primitives on the other hand. We refer to Van Herreweghen et al. [9] for a description of such a mapping for the generic payment service described by Abad-Peiro et al. [1]. Rather than referring to specific protocols or service primitives, we will state dispute claims in terms of whether or not the service defined by a primitive transaction did (or could) take place. If a value transfer is reversed (e.g., the payee refunded the payer), it is equivalent to the value transfer not having taken place at all. However, it must still be possible to express a claim like Alice did pay $200 to BobAir in the past which must be true, even if the payment was later refunded by BobAir. 3.2.3 Statements of Dispute Claims Syntax We express a statement of dispute claim as a formula in a first-order logic with certain modal extensions. The language of the logic consists of the following symbols: logical connectives, typed variables, typed constants, and relational connectives (which are functions of variables/constants of the appropriate type). There are three types of variables: primitive transaction (pt), roles, and attributes. The pt variable can take its value from a well-defined enumerated set. In the case of the payment service, this set consists of payment, value subtraction, and value claim. Each primitive transaction has a set of well-defined role variables associated with it. For example, payment has payer and payee as associated role variables. The role variables belong to a type called id val, which represents distinguished names according to some well-defined naming scheme (e.g., account numbers or certified e-mail addresses). Each primitive transaction also has a well-defined set of attribute variables associated with it. For simplicity, we assume that all value transfer primitive transactions have the same set of attribute variables: amount, time, 2 and ref. The attribute variables are typed they take their values from the appropriate domains. In the case of the payment service, we assume that amount, time, and ref take values from domains named amount val, time val, and ref val respectively. Each attribute, depending on its type, has a finite set of relational operators associated with it. Table 3.1 lists the variables in the generic payment service, their domains, and applicable relational operators. We also allow two logical connectives: (conjunction) and (negation), a parenthetical operator for specifying precedence, and modal operators called can without, could without, once, always and never. A comma indicates concatenation. The rules to construct valid dispute claim statements are described in the grammar specifications shown in Table 3.2. Note that this grammar is only payment specific in its concretisation of possible values for 2 There may be several different timestamps involved; for simplicity, we assume that there is only one instant at which the transaction is considered to have taken place.

52 Chapter 3. Accountability and Dispute Handling in Payment Systems pts, roles, attributes and relops, and as such represents one instantiation of a family of grammars, each instantiation of which defines a grammar for dispute statements related to a specific service (payment, notarization, etc.). From now on, we will simply write primitive transaction name to denote the predicate pt=primitive transaction name. Also, when a conjunction ( ) is obvious, we omit it. For example, payment payer =Alice payee =BobAir is shorthand for pt=payment payer =Alice payee =BobAir. Table 3.1: Attributes and Operators of Primitive Transactions variable domain relational operators pt {payment, value subtraction, value claim} = <role> id val = amount amount val < = > time time val < = > ref ref val = Table 3.2: Grammar for the Payment Dispute Claim Language claim ::= role claims claim stmt claim stmt ::= modal stmt modal stmt (modal stmt) modal stmt modal stmt modal stmt ::= possibility stmt certainty stmt basic stmt certainty stmt ::= always basic stmt never basic stmt possibility stmt ::= role set could without role set basic stmt role set can without role set basic stmt once basic stmt role set ::= role role, role set basic stmt ::= role part attr part role part ::= pt=payment payer=id val payee=id val pt=value claim user=id val bank=id val pt=value subtraction user=id val bank=id val attr part ::= true attr val pair attr part attr val pair ::= amount relop amount val time relop time val ref=ref val relop ::= < = > role ::= payer payee user bank Semantics First, let us try to capture the intuitive semantics of our dispute claim language. During the execution of a protocol, the system as a whole goes through a series of well-defined global states. The global state consists of the initial secrets (e.g., private keys) of all the players involved, all message exchanges up to that point, and all sources of randomness. Therefore it has enough information to assign values to all the variables that can possibly appear in a dispute claim phrased in our claim language. Given a dispute claim phrased in our claim language, a verifier who knows the entire global state can decide with

3.2. Expressing Dispute Claims 53 certainty if the claim is true or not. However, it is extremely unlikely that any verifier can know the entire global state (e.g., private keys of other players). The goal of dispute resolution is for the verifier to attempt to partially reconstruct the sequence of global states (along with as much of their contents as possible or necessary) the system has gone through, arriving at the current state. A verifier can do this using the evidence presented to it. Based on interpretation of the evidence (which is a payment systemspecific function), the verifier can assign values to some of the variables. Such a partial assignment may be contingent on the trustworthiness of the entities involved in the creation of the evidence. The claim is evaluated with respect to the current state, and/or the sequence of states traversed so far. Once a sufficiently complete interpretation of a state is available, the verifier can determine if a given basic stmt s is true in that state. The meanings of the modal operators are intuitive. The statement always s is true at a state S if s is true in S as well as in every state reachable from S. The meaning of never s is analogous. The statement P can without Q s is true in S if there is a state S where s is true, and it is possible for P to cause the first in a series of transitions from S to S without any action from Q. Given a path p = {S 0,... S n }, the statement P could without Q s is true in p if the following two conditions are satisfied: (a) P can without Q s is true at some state S in p, and (b) if, at some later state in p, it was no longer possible to reach a state where s is true, then P was responsible for this change. Given p = {S 0,... S n }, once s is true in p if s was true in a state S in p. Now, let us try to define the semantics more formally. Our model consists of a set of states S, a set of roles R, a set of transitions T S S, and an interpretation L which assigns a value of the appropriate type to variables in the language. A role uniquely identifies a service access point (e.g., payer). We assume that there is an infrastructure that enables a verifier to unambiguously identify and authenticate the identity of a player (which is some value from the domain id val) playing any given role. We assume that a multi-party protocol can be described by a directed acyclic graph (DAG), the edges of which correspond to message transmissions between the players, and the nodes correspond to internal global states. We can capture this property by defining that each state has a cardinality, defined by the function card() : S N, where N is the set of natural numbers. The cardinality is used to impose a partial temporal order over S. If (S 1, S 2 ) T, then card(s 2 ) > card(s 1 ). If the protocol is specified in the form of local finite state machines, they can first be unwound into a set of DAGs which can then be combined into a single DAG. Replays of protocol messages, when detected and rejected by the receiver, do not influence the global state and therefore do not affect the DAG. If a protocol allows different messages with the same message type to be sent several times during a protocol execution, the different occurrences are represented as separate transitions in the DAG. The sender of a message is the agent associated with the edge that represents the message in the DAG. A function agent() : T R identifies the role associated with a given transition. (Recall that an interpretation will associate an id val with a role, thereby associating an id val with each transition as well.) Given a path p, in the form of a sequence of states {S 0, S 1,..., S n }, the function agents(p) returns the union of agent(s i, S i+1 ), for i = 0... n 1. The verifier has a payment system-specific evaluation function which can be used to associate a partial assignment with a given state. The relational operators have the usual semantics. Thus, given a sufficiently complete partial assignment, and a proposition involving an attribute, a relational operator, and a value, it is possible to evaluate if the proposition is true. Given a global state S with a partial assignment, and a basic stmt s of the form role part attr part (where role part and attr part are conjunctions of propositions as described in the previous section), s is true in S, if role part and attr part evaluate to true after the partial assignment is made. Since the assignment is partial, the verifier may not always be able to decide whether a claim is true or not, for example, if the evidence supplied is incomplete. Figure 3.3 illustrates the semantics of the modal operators. The figure shows the DAG description of a protocol, including the states where a certain basic stmt s is true. 1. If the statement always s is true in a state (e.g., S 100 ), then s (as well as always s ) is true in that state and in all states reachable from it, in all possible paths. Similarly, if never s is true in a state (e.g., S 3, S 201 ), then not s (as well as never s ) is true in that state and in all states

54 Chapter 3. Accountability and Dispute Handling in Payment Systems States where never s is true States where s is true PSfrag replacements S 201 S 3 P 1 S 200 Time S 110 P 3 P 3 S 100 S 2 P 2 P 2 P 2 P 2 could without P 1 s is - true in path {S 0, S 1, S 110 } - false in path {S 0, S 1, S 2, S 3 } - false in path {S 0, S 1, S 2, S 200, S 201 } P 2 can without P 1 s is - true in S 1 - false in S 0, S 3 and S 201 once s is - true in {S 0, S 1, S 2, S 200 } - true in {S 0, S 1, S 2, S 200, S 201 } S 1 S 0 P 1 States where always s is true LEGEND States where s is true States where never s is true Figure 3.3: Semantics of Dispute Statements reachable from it. 2. The statement P 2 can without P 1 s is true in S 1 because P 2 can cause the transfer to S 100. 3. The statement P 2 could without P 1 s is true in the path {S 0, S 1 } because of 2. It is also true in the path {S 0, S 1, S 110 } even though s itself cannot be true in S 110 or any state reachable from S 110. This is because, in S 1 it was still possible to reach a state where s would have been true (S 100 ) and it was P 2 which chose not to effect that transition. 4. Given a path, the statement once s has the usual meaning in linear temporal logic for example, once s is true in {S 0, S 1, S 2, S 200 } and {S 0, S 1, S 2, S 200, S 201 }. We now define the semantics of modal operators more formally. We first define a valid path as: For a path p = {S 0, S 1,... S n }, valid path(p) iff (S i, S i+1 ) T, 0 i n 1 In the following definitions, paths are implicitly assumed to be valid paths. is the negation operator; S i s stands for s holds in S i. The semantics of the can without operator are now defined as follows: S PSET can without QSET s, iff

3.2. Expressing Dispute Claims 55 S n such that S n s p = {S 0 = S, S 1,... S n } such that agent(s, S 1 ) PSET QSET agents(p) = φ That is, given a state S, if there is a valid path p leading to a state S n, such that s is true in S n, and the first transition in p can be made by a member of PSET and no one from QSET is required to make any transition in p, then the statement PSET can without QSET s is true in S. The can without operator is used to make a statement about the possible future states of the system. In contrast, the could without operator is more general. It is defined with respect to a path (more precisely, with respect to a state and a specific path leading to that state). It can be used to make a statement about the system at the end of the path about where it can go in the future, as well as where it could have gone in the past. The semantics of the could without operator can be defined in terms of the can without operator: For a path p = {S 0, S 1,... S n = S}, p PSET could without QSET s, iff S PSET can without QSET s S i p, 0 i n 1 such that S i s S i+1 s agent(s i, S i+1 ) PSET S i p, 0 i n 1 such that S i PSET can without QSET s S j p, i + 1 j n 1 such that S j ALL can without QSET s S j+1 ALL can without QSET s agent(s j, S j+1 ) PSET The set ALL represents the set of all roles for the primitive transaction referred to in s. The rule identifies three disjunctive conditions to evaluate the truth of the statement s could =PSET could without QSET s with respect to a path p. The first disjunction says s could is true if s can =PSET can without QSET s is true in the last state of p. The second disjunction says that if s was true at some state in p, but not at the state immediately following it, and the transition was caused by someone in PSET, then s could is true with respect to p. The third disjunction is a little more complicated. The intent is to capture the following case. Sometime in the past, it was possible to reach a state where s is true (i.e., there was a non-empty path, say p from some state S i in p, making s can true at S i ). The agents of p consist of some members of PSET but none from QSET. It may also consist of other entities, not in either of the above sets. The statement (PSET agents(p )) can without QSET s should therefore hold at every state in p subsequent to S j. If it fails to hold after a certain transition, and that transition was caused by a member of PSET, then we can assert that s could is true in p. In the interest of simplicity, we relax the definition a little by using the set of all roles (ALL) instead of (PSET agents(p )). The last disjunction captures this property. Similarly, p once s, iff S p such that S s S 0 always s, iff p = {S 0,...}, p s S 0 never s, iff p = {S 0,...}, p s The notation p s has the usual meaning in linear temporal logic: in the sequence of states p, the

56 Chapter 3. Accountability and Dispute Handling in Payment Systems formula s holds true in every state. In Section 3.3.3, we will look at an example payment system to see how we can build a global state transition diagram. The claim language described above constitutes the set of symbols and grammar rules necessary for specifying dispute claims in the generic payment service. The language constructs allow multiple timelines. Therefore, it belongs to the family of branching temporal logics [55]. It does not include all possible temporal logic constructs: for example, the until operator. We have only included the constructs that seemed necessary to express the claims described earlier. However, we have included constructs like can without and could without, which are not standard branching temporal logic constructs. The language can be extended as needed. In Section 3.3.2 below, we describe how the claim language can be extended to derive the language describing the messages in a generic dispute protocol between the verifier and the player. The inference mechanisms used by the verifier constitute a logic over the claim language described. Proving soundness and completeness of this logic with respect to a given payment system actually means proving the payment system correct. Our approach has rather been to add dispute handling to existing payment systems, most of which do not fulfill these correctness requirements. Therefore, we consider the main contribution of this work to be in the problem definition and the development of the claim language; not in the development of the logic. Examples The five dispute claims mentioned in Section 3.2.1 correspond to the following statements in our language: payment payer=alice payee=bobair amount=$200 payment payer=alice payee=bobair amount=$200 time < Jan12 payment payer=alice payee=bobair amount=$200 payee could without payer payment payer=alice payee=bobair amount=$200 time < Jan12 value subtraction payer=alice bank=carolbank amount=$300 ref = #434: for flight 822 on Jan 19:payment to BobAir If players have evidence proving that a certain value transfer transaction has reached a guaranteed final state, they may choose to make stronger claims, using the always or never operators. For example, if Alice has a receipt for the payment made using a payment system which does not support refunds, she may claim always payment payer=alice payee=bobair amount=200 instead. 3.3 Supporting Claims with Evidence 3.3.1 Architecture for Dispute Handling Overview Recall that there are three types of players in a dispute: the initiator who starts the dispute by making a claim, the verifier who co-ordinates the dispute handling and possibly makes, or helps make, the final decision about the validity of the claim, and a set of responders who may be asked by the verifier to participate in the process. At the access point of each player, there is a user part (which may be the human user, or an application program acting on his behalf) and a system part (which is an implementation of the dispute service: e.g., an ikp implementation of the generic payment dispute service). The verifier s system has two parts: the inference engine receives a claim, and associated evidence tokens, analyzes them, and determines the

3.3. Supporting Claims with Evidence 57 conditions under which the claim is true, and the conditions under which it is false; the policy engine uses the result of the first part to make a final decision. The policy engine may be a human arbiter, external to the dispute handling service. It needs to use trust assumptions. In the simplest case, this may be in the form of a blacklist of untrusted principals. It is possible that the trust assumptions require a more elaborate representation (for example, as in PolicyMaker [21]). Indeed, one and the same party may be more or less trusted depending on which statement related to which type of transaction it is asserting to. A policy engine may also determine the risk or likelihood of collusion between the specific parties and assign corresponding trust values to pieces of evidence. Initiator Verifier Responder User Inference Policy User System User System constructclaim() claim claim map(claim) (player,statement)* prove(statement1) prove(statement2) prove(statement1) evidence token prove(statement2) evidence token evidence tokens (proof protocol) analyse(claim, (player,statement, token)*) (statement,yes set,no set,cheaters set)* decide(statement, yes set,no set)* decision decision decision Figure 3.4: Basic Dispute Protocol Figure 3.4 illustrates the various interactions during a dispute transaction. The initiator constructs a dispute claim and sends it to the verifier. The verifier s inference part decides which players and informs the players systems of the statements they are required to prove. Each player s system then engages in a proof protocol with the verifier s system. Recall that during the dispute protocol, the verifier s goal is to determine both the current state of the payment system, and the sequence of states through which it has progressed, and that the validity of the claim should be evaluated with respect to this state and sequence. At the end of the protocol, the verifier s system returns an analysis of the claim. The analysis consists of a likely decision (yes or no) as well as the set of players who were witnesses to the decision and the set who were against it. If there is insufficient evidence, the verifier s system may throw an exception. The policy engine makes the final decision by

58 Chapter 3. Accountability and Dispute Handling in Payment Systems combining this analysis with his trust assumptions. This leads to the following requirements on the design: The verifier needs the following service primitives: map: Takes a claim as input and returns a list of (player, statement) pairs. Each player is required to prove the corresponding statement. As explained in Section 3.3.2, statements typically correspond to assertions by players in the protocol about their view of a protocol state and its partial assignment. analyze: Takes a claim, a set of players, and the statements they need to prove as input, engages in some proof protocol (maybe as simple as receiving one or more evidence tokens, interpreting them, and making an inference on the statements proved), and returns the set of players according to which the claim is true, the set of players according to which it is false, and the set of players who have been found to be cheating. decide: Takes a claim, and two sets of players (yes-set, no-set) as input, and returns one of yes, no, or cannot-decide, based on the verifier s trust relationships as output. This is the result of the dispute. Each player needs the following primitives: constructclaim: which allows the user to construct a claim, and prove: which takes a statement as input and attempts to prove it (maybe as simple as retrieving the pieces of evidence and returning them to the caller). A concrete design of a dispute service for the generic payment service [1] is described by Van Herreweghen et al. [9]. Lost and Withheld Evidence In some scenarios, a claimant may need to rely on another party to help prove a certain claim. This may be because the claimant lost parts of the necessary evidence; it may also be an inherent property of the payment system; e.g., in a payment system where the payer never gets signed receipts from the payee, the payer may not be able to win a payment dispute without cooperation from his bank. In either case, the other party could decide to withhold the necessary evidence. This problem cannot be dealt with except in the case where it can be shown that the other party should indeed possess or have possessed the evidence. It is up to the specific payment system to define the actions to be taken in such a case. Enhancements We have limited ourselves to disputes in a generic payment service where there is only one service boundary. The system is below the boundary and the user or his application is above the boundary. Comprehensive electronic commerce frameworks such as SEMPER [121] are structured into multiple layers. A payment usually takes place in the context of a higher layer transaction (e.g., a fair exchange) which in turn may take place in the context of a transaction in the layer above (e.g., an instance of an on-line purchase application). A dispute claim made in a higher layer needs to be suitably mapped to corresponding claims in the lower layers. The running of the dispute protocol needs to be co-ordinated among the different levels. This is left as an open problem. 3.3.2 Evidence and Trust During a dispute, players have to support dispute claims by proving certain statements to the verifier. The ability to prove statements comes from pieces of evidence (evidence tokens) accumulated during

3.3. Supporting Claims with Evidence 59 a transaction of the primary service. The simplest form of evidence is an evidence token that can be verified by anyone who has the necessary public keys, certificates, certificate revocation lists etc. The proof protocol in this case simply consists of presenting the token to the verifier. There can be more involved proof protocols, such as in undeniable signature schemes [38]. In the following, we will assume only simple proof protocols consisting of the presentation of evidence tokens. Often, evidence tokens cannot substantiate an absolute statement. In general, an evidence token corresponds to an assertion by one or more players that they believed the protocol reached a certain state (with an associated partial assignment). Such an assertion is a witnessed statement. During the dispute protocol, the verifier asks various players to prove witnessed statements (in the evidence token request messages in the dispute protocol of Figure 3.4). We define the language for these witnessed statements by building on our claim language in Section 3.2.3 and extending it with the following rule. witnessed stmt ::= role witnessed asserted stmt asserted stmt ::= basic stmt certainty stmt The witnessed operator takes two parameters: an asserted stmt s, and a role P. The statement P witnessed s is true if P has accountably asserted that the transaction reached a certain state, with an associated partial assignment in which s evaluates to true. The ability to prove and verify such an accountable assertion itself assumes a lower layer dispute service. The verifier s analyze method, after having collected the evidence tokens proving the witnessed statements, returns a result of the form: {[ ] <claim stmt> yes={...}, no={...}}, cheating={... } Each component of the disjunction contains either the original statement in the claim or its negation, and two optional sets of players: the set of players whose statements are in agreement with the conclusion and the set of players whose statements are contrary to the conclusion. The verifier will pick one of these disjunctions, depending on the set of players he trusts. If the evidence presented is insufficient to decide one way or the other, the system may raise an exception. Further, it may also be able to detect if some player has cheated (for example, if the same player has witnessed a certain statement and its exact opposite, it may imply that the player had cheated). Note that a carefully designed, secure, payment system can be rendered insecure if the inference engine used by the verifier is wrong. It is important to make sure that the inference engine does not degrade the security of the protocol. Consider as an example a dispute claim discussed earlier: Alice claims to have made a payment of $200 to BobAir. There is no way to say with absolute certainty whether the transaction actually took place. A receipt from BobAir proves the statement Whether a verifier can infer BobAir witnessed payment payer=alice payee=bobair amount=$200 payment payer=alice payee=bobair amount=$200 depends on the context, the trust assumptions of the verifier, and even on the actual payment system allegedly used for the value transfer. For example, in a dispute against BobAir, the verifier could accept a signed receipt from BobAir as sufficient evidence to conclude that the latter claim is true. However, if BobAir and Alice are in collusion and want to convince a third party (say the tax authorities) that a certain payment happened, BobAir s signed receipt alone is not sufficient. In this case, if the verifier trusts the bank, it can accept a signed statement from the bank as sufficient evidence. Thus an analyze result of the form:

60 Chapter 3. Accountability and Dispute Handling in Payment Systems payment <role part> <attr part> yes={bank} no={} may allow the verifier to reach a final positive decision, whereas a result of the form: payment <role part> <attr part> yes={payer,payee} no={} cannot exclude collusion of payer and payee in trying to prove a payment. Now, in Section 3.3.3, we will look at a simplified version of the ikp protocol to see (a) how statements can be supported with evidence and (b) how to derive system specific inference rules. 3.3.3 An Example: Evidence Tokens in ikp ikp was designed as a solution for securing credit card payments over open networks. The original protocol was described by Bellare et al. [17]. Van Herreweghen et al. [16] contains a more detailed definition with some improvements. In this section, we present a simplified version of the 3-party ikp (3KP) where all three players are assumed to have signature key pairs. We will see how the receipts gathered during an ikp protocol run can be mapped to dispute statements defined in Section 3.2.3 for the generic payment service. Protocol Description Table 3.3: Information of Players in a Completed ikp Transaction Initial Information payer payee bank desc, price, CHI desc, price, TID, date, v, vc Collected Information payer payee bank com, H(v), Sig M, [Sig A ], v vc com, Enc, Sig C, [Sig A ], [Sig refund A ] [com, Enc, CHI, Sig M, [Sig refund M ], Sig C ] In our simplified version of ikp, there are three players: Customer (Payer), Merchant (Payee), and Acquirer (Bank). Before the transaction begins, the customer and merchant agree about the amount of payment ( price ) and the description ( desc ) of what the payment is for. The first half of Table 3.3 depicts the initial information of each player. To begin the transaction, the payee: generates two random nonces v and vc; these nonces will later be used as part of the receipt(s) from the payee, collects the common information ( com ). The common information consists of all the pieces of information that will be known to all the parties at the end of the transaction, 3 and 3 One item in the common information is a randomized hash of the description (H R (desc)). The payer and payee already know the description. The randomized hash allows the bank to confirm that the payer and payee agree on the description without the bank having to know the actual text of the description.

3.3. Supporting Claims with Evidence 61 Data Functions M Merchant (payee) H() A one-way hash function C Customer (payer) H R (m) A randomized one-way hash of m A Acquirer (bank) EX(m) R A randomized encryption TID Transaction ID of m with the public key of X date Time stamp S X(m) Signature of X on m price Amount information desc Description of payment v Confirmation Authenticator vc Cancellation Authenticator CHI Card-holder Information com Common information (M, C, price, TID, date, H R (desc), H(v)) Invoice : C Payment : C Auth-Request : M Auth-Response : M Confirm : C Payment TID, date, H(v), Sig M = S M(H(com), H(v), H(vc)) Enc = E A R(price, H(com), CHI), Sig C = S C (Enc, H(com)) TID, date, H(v), H(com), HR (desc), Enc, Sig M, Sig C yes no, Sig A = S A(yes no, H(com)) (v, yes) (vc, no), Sig A M M A A M Cancel : C Cancellation vc M Refund-Request : M Refund-Response : M Sigrefund M Refund = S M (H(com), price, refund ) A = S A (H(com), price, refund ) Sigrefund A A Figure 3.5: Simplified ikp Protocol

62 Chapter 3. Accountability and Dispute Handling in Payment Systems Table 3.4: Mapping Evidence to Dispute Statements in ikp Role Evidence Statement Possible witness Primitive Transaction Counter payer 1. Sig M, v, com payee payment 8 2. Sig A, yes, com bank value subtraction 10 3. Sig A, no, com bank never value subtraction 4. Sig M, vc, com payee never payment 11 payee 5. Sig C, com, Enc payer payment 3, 4, 10 6. Sig A, yes, com bank value claim 10 7. Sig A, no, com bank never value claim 8. Sig refund A, com bank never value claim bank 9. Sig M, Sig C, com payee value claim 8 10. Sig refund M, com payee never value claim 11. Sig C, com, CHI payer value subtraction 3, 4 generates a signature Sig M containing hashes of the data items mentioned above and sends the signature along with any necessary information to the payer. This is the signed Invoice from the merchant. The evidence value of this signature is not relevant to our discussion. The payer then sends a Payment message. This is the authorisation by the customer to make the payment. It is a signature Sig C of the payer on two pieces of information, H(com), and an encryption of the price, the card-holder information ( CHI ) 4 and H(com). The payee forwards the Payment along with the Invoice to the acquirer requesting authorisation. The acquirer replies indicating whether the authorisation succeeded or not. For simplicity, let us assume that the acquirer immediately transfers the money from payer to payee if the authorisation is successful. The authorisation response Sig A from the acquirer is signed. Once the payee receives the authorisation response, he will send a confirmation to the payer. Confirm contains the acquirer s authorisation response and the authenticator v. The pair (Sig M, v) constitutes a receipt by the payee that he received the payment. If a payee decides to cancel a payment, he can issue a cancellation receipt to the payer by sending him vc. If the payer possesses the pair (Sig M, vc), it provides evidence that the payee agreed to cancel the payment. If the payee cancels an already authorised payment, he can contact the acquirer and arrange for a refund. The second half of Table 3.3 lists the pieces of information that are collected by the players at the end of a successful protocol run. Again, items within square parentheses are available only under certain circumstances. Note that instead of using v and vc, the confirm and cancel flows from the payee to payer can be signed by the payee. The use of v and vc avoids the payee having to make two or more signatures by allowing the original signature to be extended. 4 Part of the card-holder information is considered secret information (e.g., like a credit card number). The encryption in the order can be opened only by the bank thus, the payee will not be able to determine CHI.

3.3. Supporting Claims with Evidence 63 payer :4 S 8 payee LEGEND s = PAYMENT payer, payee States where s is true payee :8 S 7 S 700 States where never s is true bank bank S m P :n State S m was reached, if P produces evidence no. n bank :10 S 6 PSfrag replacements payer :1 or 2 S 5 payee S 401 payer :3 and 4 payee payee payee :6 S 4 S 400 payee :7 bank bank payer :4 S 300 S 3 bank :9 or 11 payee payee payee :5 S 2 payer S 1 payee S 0 Figure 3.6: Global States in ikp Mapping ikp Receipts to Dispute Statements Table 3.3 lists the pieces of information known to each player at the end of a successful transaction. We can now try to extract evidence tokens from these pieces and identify the dispute claims they can support. In the actual ikp protocol, the acquirer transfers the money from the customer to the merchant during a capture transaction. The merchant can also capture a different (lower) amount than was previously authorised. The refund transaction is essentially a negative capture. Depending on the policies of the players, some of the receipts may be omitted. All these variations are not relevant to our discussion. Therefore they are left out from our simplified version. With the information in Table 3.4 and Figure 3.5, we can represent the global states in a run of the ikp payment protocol in the form of a DAG as in Figure 3.6. In ikp, all three primitive transactions are completed at the same time. The states where the primitive transactions are succesfully completed are marked with a circle. The states where never s is true (s is a basic stmt with any of the primitive transactions e.g., payment payer, payee ) are marked with a thick broken circle. Notice how the verifier can use this graph to implement the analyze method (Section 3.3.1): while payment rest of the claim is false in S 300, S 400, and S 7, the statement payee could without payer payment rest of the claim is true in S 300 and S 7 (but not in S 400 ).

64 Chapter 3. Accountability and Dispute Handling in Payment Systems 3.4 Summary and Conclusion We have shown why a generic dispute service is needed for payment systems. We developed a language to express dispute claims and applied it to an example payment system. Finally, we described a generic dispute handling protocol in the context of an architecture for dispute handling. A crucial part of the dispute handling framework is the verifier s inference engine. When a new payment system is adapted to the framework, the critical step is to identify the inference rules applicable to that system. In general, the process of deriving the inference rules is equivalent to proving the payment system correct. Ideally, derivation of inference rules should be an integral part of the design process of the payment system. On the other hand, the aim is not complete automation of dispute resolution. Thus, even with an incomplete set of inference rules, a payment system can be incorporated into the framework. The most trivial inference rule is ask the human user!

Postscript 65 Postscript In this chapter, we proposed a language for expressing accountability and dispute claims in payment systems, and an architecture and framework for supporting such claims with evidence tokens generated by the payment system. I have contributed to the claim language and semantics, as well as to the architecture and the application to ikp. The discussion in this chapter has not taken into account issues of revocation of certificates and trusted timestamping of evidence tokens. As discussed in Section 1.2.3, both the ability to invalidate and revoke a signature key at a certain point in time and the ability to provably attach a time value to the generation of a digital signature are needed for associating a person s accountability with digital signatures. In the type of disputes discussed in this chapter, it is most probably up to the party relying on a digital signature to make sure that the signature key is not revoked at the time of the transaction, as well as to be able to convince an arbiter of this fact later on. Proving validity of a signature at the time it was made requires the collection of additional evidence in a signature validity service. This service may be provided by one or more trusted entities (revocation, timestamping) and provides the relying party with the necessary evidence. A simplified realization would be a trusted certificate validation server (e.g., as in the Simple Certificate Validation Protocol [87]) to which a relying party can submit a public key (or certificate) as well as a fingerprint of the signature, and returning a signed revocation status including this fingerprint. If the service is trusted to correctly attest to a certificate status, this provides evidence that the signature existed at a point in time when the certificate was not revoked.

66 Chapter 3. Accountability and Dispute Handling in Payment Systems

Chapter 4 Analysis of Accountability Features in SET and ikp Preamble In this chapter, we discuss accountability features of the payment protocols SET and ikp by analyzing the provability, using the payment system s evidence tokens, of basic statements in the payment claim language developed in the previous chapter. ikp was both a precursor and a direct ancestor of SET; yet the analysis reveals some interesting differences w.r.t. the suitability of their evidence tokens for supporting these claims. Most importantly, the results of this analysis allow us to formulate some basic recommendations for designing protocols with accountability goals. This chapter contains the following paper [119]: E. Van Herreweghen. Non-repudiation in SET: Open issues. In Y. Frankel, editor, Proc. 2000 International Conference on Financial Cryptography, volume 1962 of Lecture Notes in Computer Science, pages 140 156, 2001. We have again made minor editorial changes in order to preserve consistency of terminology with other chapters. E.g., we us evidence and accountability instead of proof and non-repudiation. The Research Report [9] on which this publication is based contains additional material on fairness considerations and their relationship to accountability. We included some of this material in the Postscript section of this chapter. 67

68 Chapter 4. Analysis of Accountability Features in SET and ikp

Accountability in SET: Open Issues Abstract The SET payment protocol uses digital signatures to authenticate messages and authorize transactions. It is assumed that these digital signatures allow to convince a third-party verifier of the respective parties authorizations. In this paper, we evaluate which claims can be supported with the digital signatures in SET. The analysis shows that even a successful and completed SET protocol run does not give the parties enough evidence to convince a third party of certain important transaction features. A comparison with the similarly-structured ikp protocol shows a number of advantages of ikp as opposed to SET with respect to the use of its signatures as evidence tokens. It is shown that accountability requires more than digitally signing authorization messages. Most importantly, protocols claiming accountability should explicitly specify the rules to be used for deriving authorization statements from digitally signed messages. 4.1 Introduction Digital signatures in the ikp [17] payment protocol are intended, by design, to ensure accountability of the various messages exchanged between customer, merchant and bank. The SET [104] protocols are similar in design to ikp; though the SET specifications do not claim accountability related to the SET signatures, press releases and public opinion tend to attach this feature to them. In this paper, we investigate the value of SET digital signatures as evidence towards an external verifier. A verifier may be a subsystem of a third-party dispute handler arbitrating payment disputes, or an online ombuds service as described by Katsch [77]. Alternatively, it can be a standalone system used by a company s accounting department or a national tax department to verify digital receipts submitted as evidence of transactions. The latter use illustrates the need for digital receipts to be self-contained; they should be usable as valid transaction receipts, without the need for additional evidence collected from semi-trusted parties such as banks. A fair amount of work has been done recently on formal specification and verification of e-commerce protocols [75, 78, 23, 90, 26]. Both Kailar [75] and Kessler and Neumann [78] focus on accountability, by introducing authentication logics modified with predicates of the form A can prove X to B. The statements X in both logics are payment system dependent; Kessler et al. [78] apply their logic to SET and prove the following: a Merchant M, having received a PReq (Payment Request) message from Customer C with Order Instructions OI, can derive that M believes M canprove (C said OI) to J, where J is an independent verifier. In this paper, we define a number of concrete, protocol-independent assertions that parties participating in a payment protocol may want to prove; we evaluate the evidence collected by SET as to its usability in proving those statements; and compare SET with ikp. We do not prove the protocols to be secure, in the sense of resistance against outsider and replay attacks. Rather, we focus on the presence of evidence allowing to prove the respective authorizations to an external verifier. In Section 4.2, we introduce a high-level protocol, representing protocols such as SET or ikp. In Sec- 69

70 Chapter 4. Analysis of Accountability Features in SET and ikp tion 4.3, we describe what kind of statements each participant in this payment protocol may want to prove, using the evidence collected during a payment run. The statements form a subset of the generic payment claim language described in Chapter 3. In Section 4.4, we describe the actual SET protocol, and evaluate its evidence tokens against the requirements described in Section 4.3. We show that some authorizations cannot be proved, even with evidence collected from a correct SET transaction. For example, a customer has no secure receipt after a successfully completed SET protocol run. Section 4.4 then concludes with a number of recommendations for constructing payment protocols with accountability. Section 4.5 illustrates how ikp differs from SET with respect to some of the accountability requirements. Firstly, the evidence tokens in ikp are more powerful (more authorizations can be proved). Secondly, ikp, more than SET, is designed with the principal of minimal information disclosure in mind: individual payment parameters (such as the payment amount) can be proved without having to reveal other data (such as a description of goods purchased). Section 4.6 summarizes our findings. Secure authorization using digital signatures does not guarantee that the authorization and its parameters can be proved. Therefore, it is recommended that protocols claiming accountability explicitly specify the rules for deriving authorization statements from digitally signed messages. 4.2 High-Level Payment Protocol Description Customer (C) Merchant (M) Acquirer (A) Initiate Invoice Pay-Request Pay-Response(Confirm) Goods and Services Auth-Request Auth-Response Figure 4.1: Generic Credit Card Payment Protocol The SET and ikp protocols both can be represented by the high-level protocol depicted in Figure 4.1. Before the start of the actual payment protocol, Customer and Merchant have agreed on a description and price of the goods. In an optional Initiate - Invoice exchange, Customer and Merchant exchange variables, options and randomizers needed in the ensuing payment messages. The Customer then sends a Pay-Request message to the Merchant which the Merchant uses to produce an Auth-Request asking authorization from the Acquirer. The Acquirer goes through the financial network to obtain payment authorization and returns an Auth-Response to the Merchant, indicating success or failure, and optionally the actually captured amount. The Merchant then produces a Pay-Response (Confirm) message and sends it to the Customer. SET, as well as ikp, represents different protocol versions depending on which parties (all, only Merchant and Acquirer, only Acquirer) digitally sign messages. This paper aims at analyzing the evidence collected in the most secure versions, i.e. the protocol variants where all parties digitally sign messages. A protocol option set by Merchant (eventually also Customer) determines whether the Auth-Request

4.3. Proving Authorizations of Primitive Transactions 71 Auth-Response exchange results in the actual transfer of money (simultaneous authorization and capture) or whether an ensuing Cap-Request Cap-Response exchange between Merchant and Acquirer completes the actual transaction (separate authorization and capture). To simplify the analysis, we will assume the former scenario, i.e. simultaneous authorization and capture. For the same reason, we will not consider reversal or refund of payments. 4.3 Proving Authorizations of Primitive Transactions In Chapter 3, a language was presented to express claims (or provable statements) that participants in a payment protocol may want to be able to prove. This language is derived from the generic payment service definition by Abad-Peiro et al. [1] and is independent of the payment model (stored-value, accountbased). A payment transaction involves Customer (C), Merchant (M) and Acquirer (A) and consists of three types of primitive transactions, each representing the view of a subset of players on a payment transaction: Bank value subtraction value claim payment Payer Payee Transfer of "real" value Figure 4.2: Value Transfer Transactions In value subtraction, C allows A 1 to remove real value from C s account; this implies C s right to spend electronic value. In value claim, M requests that A deposits real value to M s account. In payment, C transfers value to M. In stored-value (electronic purse) systems, value subtraction, payment and value claim may be separate transactions, taking place at different points in time. In the account-based protocol in Figure 4.1, where the Acquirer is involved online and authorization and capture occur simultaneously, value subtraction, payment and value claim complete at the same time and cannot be separated. Distinguishing between the three primitive transactions, however, enables us to formulate disputes between each subset of players: it allows us to reason about the bank s behaviour as well, as it receives and sends authorization messages to the other parties. After completion of the payment protocol in Figure 4.1, each of the parties (C, M and A) ideally has evidence of transaction authorization by the two other parties. Using a notation similar to the one used in Chapter 3, following requirements are then fulfilled: 1 actually: C s own issuing bank through A

72 Chapter 4. Analysis of Accountability Features in SET and ikp M can prove C authorized payment (C, M, Amount, Date, Ref). Ref stands for a set of reference parameters which may be protocol specific, such as transaction identifiers or description of the goods purchased. We will further abbreviate the statement C authorized payment (... ) to Auth(C-M). C can prove M authorized payment (C, M, Amount, Date, Ref), or: Auth(M-C). A can prove C authorized value subtraction (C, A, Amount, Date, Ref), or: Auth(C-A). C can prove A authorized value subtraction (C, A, Amount, Date, Ref), or: Auth(A-C). A can prove M authorized value claim (M, A, Amount, Date, Ref), or: Auth(M-A). M can prove A authorized value claim (M, A, Amount, Date, Ref), or: Auth(A-M). For a protocol following the scheme in Figure 4.1, Pay-Request must then contain evidence of Auth(C- M) and Auth(C-A); Auth-Request contains evidence of Auth(M-A) and forwards evidence of Auth(C-A); Auth-Response contains evidence of Auth(A-M) and Auth(A-C); Pay-Response, finally, contains evidence of Auth(M-C) and forwards evidence of Auth(A-C). Thus, after receiving Pay-Request, M can prove Auth(C- M); after receiving Auth-Request, A can prove Auth(C-A) and Auth(M-A); after receiving Auth-Response, M can prove Auth(A-M) (in addition to Auth(C-M)); and after receiving Pay-Response, C can prove Auth(A-C) and Auth(M-C). If all of the above requirements are fulfilled, all the parties in a completed transaction have sufficient evidence to convince a verifier of their view of the primitive transactions in which they were involved. The absence of one of these evidence tokens of authorization need not make the payment protocol insecure; but it may make disputes between the parties involved in the specific primitive transaction more difficult (e.g., having to rely on evidence provided by other parties) or even impossible without resorting to off-line means (e.g., an account statement proving a debit and thereby a payment). In the following, we highlight the importance of the respective authorizations: Auth(M-C) is equivalent to a receipt of payment by M. In its absence, C cannot prove the payment to M without involving evidence collected by A, or without resorting to off-line means (e.g., account statement). Auth(A-C) is equivalent to a receipt by A of the amount deducted from C s account and can eventually be replaced by an off-line account statement. It allows C to verify that the amount deducted by A and the amount in M s receipt are equal. Auth(C-M) is obviously important if M delays the actual authorization/capture and makes certain decisions (such as shipping goods, or reserving stock) based on Auth(C-M) before contacting A. This authorization may seem less important in the case where M directly captures the money and therefore does not need Auth(C-M) as a payment guarantee. However, Auth(C-M) still has its value as evidence of terms and conditions of the payment, such as description of the goods (which, in case of disagreement, M may otherwise not be able to prove). Auth(C-A) is A s evidence that C entitled A (or its own issuing bank through A) to deduct money from C s account. Auth(M-A) is A s evidence that M asked the payment to be made to him. Auth(A-M) is M s evidence that A transferred (or committed to transfer) the money to M s account. When analyzing SET in Section 4.4, we will analyze for each of the above authorizations whether the interested party has the evidence needed to prove it; whether it needs other parties to cooperate in giving evidence; or whether the statement cannot be proved at all. In SET, some of the authorizations cannot be proved, or can only be proved with the help of evidence collected by other parties. ikp, as discussed in Section 4.5, gives each party enough evidence to prove the other parties authorizations.

4.4. SET 73 4.4 SET 4.4.1 SET Protocol Overview The basic SET protocol follows the model of Figure 4.1. For reasons of simplicity, we do not consider additional SET options, such as separation of authorization and clearing, refunds or credit, or the splitting of a single payment transaction into multiple authorization threads. For further simplification, we omit a number of fields which are optional or not relevant to verifiability, such as thumbprints, bank identification numbers, language identifiers, request-response pair identifiers (RRPIDs), and optional extensions. Table 4.1 represents the atomic and composite fields used in SET; Figure 4.3 shows the protocol messages. A number of SET messages are encrypted using the public key of the recipient. Depending on the security requirements of the message, and depending on whether or not certain parts of the message are already in encrypted form, different types of encryption are used. From an evidence point of view, however, these different types of encryption are equivalent, since the actual evidence to an external verifier necessarily Table 4.1: SET Atomic and Composite Fields H(Msg) E X(Msg) Signed X (Msg) S X (Msg) E X(Signed Y (Msg, baggage)) TIDs LID Z Chall Z XID HOD HODContents OD MID AuthReqX, X=Amt Date AuthX, X=Code Amt Date CompletionCode CapRatio PANData PI HOIData HPIData OIData PIData PIHead image of Msg under a strong collision-resistant one-way hash function message Msg, encrypted under X s public encryption key message Msg, signed with X s private signature key (includes Msg) signature-only of Msg with X s private signature key (does not include Msg) simplified notation for {S Y (Msg, baggage), E X(Msg), baggage}; baggage is already encrypted and is signed together with encrypted Msg LID C, LID M, XID, PReqDate, Language local ID of Z challenge of Z globally unique ID H(HODContents) OD, PurchAmt, ODSalt Order Description Merchant ID amount, date in AuthReq code, amount, date in AuthRes Merchant s completion code ratio of AuthAmt:PurchAmt PAN (Private Account Number), CardExpiry, PANSecret, EXNonce S C(HOIData, HPIData), E A(PIHead, HOIData, PANData) H(OIData) H(PIData) TIDs, Chall C, HOD, ODSalt, Chall M PIHead, PANData TIDs, HOD, PurchAmt, MID

74 Chapter 4. Analysis of Accountability Features in SET and ikp PinitReq: C LIDC, LIDM, ChallC PinitRes: C Signed M (TIDs, ChallC, ChallM) PReq: C OIData, HPIData, PI AuthReq: M EA(Signed M (TIDs, AuthReqAmt, AuthReqDate, HOIData, HOD, PI)) AuthRes: M EM(Signed A (TIDs, AuthCode, AuthAmt, AuthDate)) PRes: C Signed M (TIDs, ChallC, CompletionCode, AuthCode, AuthDate, CapRatio) M M M A A M Figure 4.3: SET Payment with On-Line Authorization consists of the decrypted message. Therefore, we simplify the encryption notation: E X (M) stands for a message encrypted using X s public encryption key PK X from which X can retrieve M by decryption. In most cases, M (or a part of M) is encrypted using a symmetric (DES-) key 2, which is (part of) the actual data encrypted with PK X. In the following sections, we describe which pieces of evidence can prove the statements described in Section 4.3. We do so by formulating rules which a verifier V, when presented with pieces of SET evidence, can use to infer conclusions about those statements. A rule of the form evidence (Evidence1, Evidence2,...), verify (Statement1, Statement2,...) conclusion expresses that, if V is given the pieces of evidence in evidence, and if V also can verify statements (equalities, cryptographic relationships) in verify, then V will arrive to conclusion (or, equivalently: then conclusion can be proved to V). The rules used are not rules in any logic; rather, we use them as a convenient intuitive notation for deriving assertions from signed messages. In the following analysis, we make abstraction of the linking between keys and entities: if message Msg is signed with a secret key K s of which the public counterpart K p is certified by a trusted Certification Authority as belonging to entity E, then Msg is signed by E. We also make abstraction of distribution, verification and revocation of the certificates certifying and carrying the K p s; in the following, when V can convince itself that P signed message Msg at time T, V was presented with a certificate for P s public key K p which was valid at time T. 4.4.2 Evidence of Authorizations M Proving Auth(C-M) After receiving PReq, M can use the non-encrypted part (OIData, PI, HPIData) to prove Auth(C-M). 3 Since PurchAmt is only present in OIData in hashed (HOD) form, V also needs HODContents to verify the PurchAmt in PReq. M thus has to reveal OD to V in order to prove Auth(C-M) for a certain PurchAmt. The verifications (verify) performed on the evidence convince V that C authorized the payment. In the first statement (:=), V calculates a candidate HOIData from the values he received. The second and 2 Import/export restrictions (see also the Preamble of Chapter 2) and law enforcement needs may have played a role in the decision to use weak 56-bit DES encryption. 3 composite-field[component-fields] denotes a composite field (e.g., OIData) with its individual components

4.4. SET 75 third statement (=?=) represent verifications. With the second statement, V verifies that HOD is a valid hash over HODContents including PurchAmt and OD; in the third statement, V verifies that Sig C is a signature by C over the calculated HOIData as well as HPIData. Ref() is an unordered list of additional reference data about the payment.signed a valid hash HOIData over the elements in OIData, including HOD. evidence (OIData [TIDs, Chall C, HOD, ODSalt, Chall M ], HPIData, PI [Sig C,... ], HODContents [OD, PurchAmt, ODSalt ]), verify (HOIData:= H(OIData), HOD =?= H(OD, PurchAmt, ODSalt), Sig C =?= S C (HOIData, HPIData)) C authorized payment (C, M=?, PurchAmt, TIDs.PReqDate, Ref(TIDs, HOD, OD)). Note that, with PReq and HODContents together, M cannot prove the payment was made to him. Only A can prove that by revealing the decrypted and signed PI (including MID). However, PReq and HODContents can still be used as evidence of terms and conditions of the payment agreed to by C, as discussed in Section 4.3. C Proving Auth(M-C) C can try to use the receipt PRes to prove Auth(M-C). PRes includes a CapRatio (ratio of captured amount CapAmt to authorized amount PurchAmt), but does not include HOD, PurchAmt or C s identity. Thus, PRes alone cannot be used as a receipt for a certain CapAmt. evidence a (Signed M (TIDs, Chall C, CompletionCode, AuthCode, AuthDate, CapRatio)) M authorized payment (C=?, M, Amt=?, AuthDate, Ref(TIDs, CapRatio)). a evidence (Signed X (Msg)) is used as a short form for: evidence (Sig X, Msg), verify (Sig X =?= S X (Msg)). What if C additionally provides PReq and HODContents to V, proving C s identity and PurchAmt associated with this TIDs? Unfortunately, this does not exclude a dishonest C from making up a PReq on the spot containing PurchAmt and identity C wants to prove. Or, from a PReq proving C authorized payment (C, M, PurchAmt, AuthDate, Ref(TIDs)) and a PRes proving M authorized payment (C, M, Amt=?, AuthDate, Ref(TIDs, CapRatio)) V cannot conclude M authorized payment (C, M, PurchAmt *CapRatio, AuthDate, Ref(TIDs))) unless C can prove to V that it was indeed that specific PReq (C and PurchAmt) M replied to. In the full report [117], additional rules are formulated taking extra evidence from M or A into account to convince V of the OIData agreed to by C and M in the actual transaction. However, C, with only the evidence collected in a correct protocol run, has no secure receipt of the transaction. Practical consequences are described in more detail in Section 4.4.3. A Proving Auth(C-A) To prove authorization by C, A can use S C (HOIData, HPIData) in AuthReq. Since A, without explicit cooperation from M, does not possess OIData, A tries to prove that HPIData = H(PIData), with PIData

76 Chapter 4. Analysis of Accountability Features in SET and ikp mapping the authorization data to be proved. This assumes revealing PIData, and thus the cleartext PANData to the verifier: evidence (Sig C, PIHead [TIDs, HOD, PurchAmt, MID ], HOIData, PANData [PAN, CardExpiry, PANSecret, EXNonce ]), verify (HPIData:= H(PIHead, PANData), Sig C =?= S C (HOIData, HPIData)) C authorized value subtraction (C, A=?, PurchAmt, TIDs.PReqDate, Ref(TIDs, HOD)). Revealing PANData can only be avoided if A is able to obtain OIData and HODContents (e.g., from M, see the full report [117]). However, with the evidence collected by A alone, A has to reveal PANData to V in order to prove Auth(C-A). C Proving Auth(A-C) C never receives evidence of A s authorization. C can prove value subtraction only when Acquirer or Merchant cooperate and the verifier accepts an Auth-Response (targeted at M) as evidence of value subtraction (see the full report [117]). But, with the evidence collected by C alone, C cannot prove Auth(A-C). A Proving Auth(M-A) and M proving Auth(A-M) These respective authorizations can be derived in a straightforward way from the AuthReq, respectively AuthRes messages, as shown in the full report [117]. 4.4.3 Discussion Problems Related to Missing Authorizations M, after receiving a valid PReq, cannot prove the payment was made to him, and has no guarantee that PI contains the correct MID (M s identifier). It can reasonably be argued that this is of minor importance in the assumed on-line authorization scenario, since M immediately gets a payment guarantee from A. It is important to see, however, that delayed processing of PReqs would be problematic. A more severe problem is this: the Customer has secure receipts from neither Merchant (Auth(M-C)) nor Acquirer (Auth(A-C)). One may argue that PRes, in combination with PReq, may be treated by V as a valid receipt, and that cheating by C (by providing a false PReq) is likely to be detected. However, it remains an important point that, in the absence of other evidence provided by M or A, a Customer providing PRes in combination with a false PReq may cheat a verifier. The consequences of these missing authorizations depend on the default behaviour of a verifier presented by C with a (PReq, PRes) pair as evidence of a payment. Consider a company optimizing its expense account processing by accepting electronic (SET) receipts from its employees for business-related expenses. The company s accounting department can take three different approaches to verifying these receipts: Since current SET implementations do not come with the necessary mechanisms to verify transaction records after the fact, the company simply trusts the employee to claim the correct amount, and ignores the actual SET transaction record. This obviously allows errors and fraudulent claims. The accounting department decides to invest in verification software that extracts SET receipts (in this case, PRes and PReq) from the employees transaction records and verifies them. Still, this leaves opportunities for fraud by employees which are able to tamper with their SET software and make it produce different PReq s for the same TIDs. Suppose an employee buys an airline ticket

4.4. SET 77 for US$ 200 (PReq with PurchAmt = 200, PRes with CapRatio = 1). The employee then produces another PReq for the same TIDs, but with PurchAmt = 1000. With the second PReq and the PRes, the employee now proves to the accounting department s verifier that she bought a ticket for US$ 1000. The accounting department can, for every claim, ask for additional statements or SET evidence from the bank. But this approach is costly and certainly does not fulfill the original goal of optimization. The example above shows how a dishonest Customer can cheat a verifier, if the verifier accepts incomplete evidence. The lacking evidence of authorization can of course work in C s disadvantage as well. Consider a Customer who pays US$100 for a certain item described in OD, and considers the receipt of PRes as valid evidence of payment for this item. If the goods delivered do not match the negotiated terms (OD), or C s account is debited with another amount than expected, C has to rely on additional evidence provided by A or M. This may be a costly procedure; or, it may turn out to be impossible if M or A s payment systems do not support the dispute handling mechanisms required for collecting this evidence. Revealing Data Since the goods description OD is hashed together with PurchAmt in HOD, neither C nor M can prove authorization of payment for a specific PurchAmt without revealing OD to V. More data than necessary is also revealed when A proves Auth(C-A): to prove C s authorization of value subtraction with only the evidence in its possession, A needs to reveal the whole contents of PIData, including PANData, to V. This could be avoided by an extra level of hashing, such that only a hash H(PANData) is revealed together with PIHead in order for V to re-compose HPIData (and thus verify PI without needing PANData). The length of PANData is 65 bytes, 40 of which consist of a secret and a nonce. Its length should suffice to protect such a hash against brute-force guessing attacks. 4.4.4 Recommendations From the previous discussion we now derive a set of recommendations for the design of payment protocols with accountability: Protocols claiming accountability should specify what exactly is proved with certain pieces of evidence: The fact that PReq does not allow M to prove that C made a payment to M, need not make the SET protocol insecure. Rather, it is important to know what can be proved and what not, and use the protocol accordingly. Secure authorization using digital signatures does not guarantee provability of this authorization to an external verifier, unless the authorization message is sufficiently self-contained: C knows which are the PurchAmt and HOD in the PReq received by M; with PRes (and the CapRatio in it), C can convince itself which HOD and final amount were approved by M. In addition, C knows that M cannot prove otherwise. M, in its turn, holds C s authorization of HOD and PurchAmt, and knows C cannot repudiate those. The problem lies in the fact that PReq and PRes are linked only by TIDs, and that C cannot prove to an external verifier which PReq was received by M. This problem would not occur if PRes contained the necessary data HOD and PurchAmt, i.e., if PRes were sufficiently self-contained. Hashing can be used to selectively reveal sensitive data: This principle is illustrated when discussing the ikp protocols in Section 4.5. In SET, by hashing PANData before using it in the calculation of HPIData one would avoid having to reveal PANData to prove Auth(C-A).

78 Chapter 4. Analysis of Accountability Features in SET and ikp 4.5 ikp In this section, we discuss and analyze ikp, with a special focus on the differences between SET and ikp with respect to accountability. 4.5.1 ikp Protocol Overview Table 4.2 and Figure 4.4 show the most complete version of the ikp protocols as implemented in the ZiP [15] prototype: 3KP with mandatory Confirm message containing the Acquirer s signature Sig A. 4 For reasons of simplicity, we make abstraction of the optional OPTSIG X parameters that parties can include in their respective signatures. Figure 4.4 represents the protocol option where no signature by M is present in Invoice. (In Section 4.5.3, we will discuss the case where Sig M is present also in Invoice.) Public-key certificates are transported outside of the ikp messages. The Cancel message is used if the Merchant decides not to go ahead with payment authorization and may not be used if the Merchant has sent an Auth-Request. For further details, we refer to chapter 2 and [15]. 4 Chapter 2 uses the terms Buyer and Seller. We changed the ikp notation to be consistent with our (Customer, Merchant) notation. SALT D SALT C PRICE Table 4.2: ikp Atomic and Composite Fields Random number generated by C, used to salt DESC. Random number used to salt the account number in C s certificate. (In the ZiP-3KP implementation [16], SALT C replaces PIN in SLIP and EncSlip.) Amount and currency INV-EXP Invoice (offer) expiration specified by M. DATE M s date/time stamp, used for coarse grained replay protection. NONCE M M s nonce (random number) used for more fine grained replay protection. ID M Merchant id. This identifies M to A. TID Z DESC CAN Transaction ID assigned by each party to an ikp transaction. Generated at a layer above ikp and not explicitly carried in ikp messages. Description of purchase/goods. C s Account Number (e.g., credit card no.). Includes expiration date. ID C C s randomized pseudo-id. ID C=H(R C, CAN) with R C a random number chosen by C. RESPCODE Authorization response from A. Can also be set by M in the case of a cancellation. AUTHTIME Authorization time set by the A. V VC Random number generated by M. The combined (Sig M, V) are evidence to C that M has accepted payment. Random number generated by M. The combined (Sig M, VC) are evidence to C that M has not accepted payment. Common TID M, TID C, PFLAGS, PRICE, ID M, DATE, INV-EXP, NONCE M, ID C, H(DESC, SALT D), H(V), H(VC) Clear PFLAGS, ID M, DATE, NONCE M, H(Common), INV-EXP, H(V), H(VC) EncSlip E A(PRICE, H(Common), CAN, R C, SALT C) Sig M S M(H(Common) ) Sig C S C(EncSlip,H(Common) ) Sig A S A(RESPCODE, AUTHTIME, H(Common)

4.5. ikp 79 Initiate: C PFLAGS, SALTD, IDC Invoice: C Clear Payment: C EncSlip, Sig C Cancel: C RESPCODE, VC, Sig M Auth-Request: M Clear, H(DESC, SALTD), EncSlip, Sig M, Sig C Auth-Response: M RESPCODE, AUTHTIME, Sig A Confirm: C RESPCODE (=positive), AUTHTIME, V, Sig M, Sig A OR Confirm: C RESPCODE (=negative), AUTHTIME, VC, Sig M, Sig A M M M M A A M M Figure 4.4: 3KP Payment with On-Line Authorization 4.5.2 Evidence of Authorizations The rules for deriving respective authorizations from ikp evidence are described in the full report [117]. As a general finding, ikp provides each of the parties with sufficient evidence to prove the other parties authorizations. In this section, we focus on some of the differences between ikp and SET. M Proving Auth(C-M) After receiving Payment, M can use the contents of Payment together with Common to prove Auth(C-M). M can do so without revealing DESC, the goods description, to V. This is an illustration of an ikp design goal, namely to disclose a minimal amount of data to provide certain evidence. However, since DESC is present in hashed form (HDESC = H(DESC, SALT D )) in Common, M can prove DESC if it needs to, by revealing DESC and SALT D. In SET, the goods description OD and amount PurchAmt were represented in the same hash HOD in PReq. Therefore, it was not possible to prove PurchAmt without revealing OD. C Proving Auth(M-C) After receiving a positive Confirm (V), C can prove M s payment authorization of PRICE. Similarly, with a negative Confirm (VC), C can prove authorization denial (authorization with amount = 0). In both cases, DESC associated with the authorized payment need not but can be revealed and proved in a similar way as in Section 4.5.2. The ikp Confirm message can thus be used as a valid and secure payment receipt. The ikp Confirm message is thus self-contained: its combined (Sig M, V) signature includes all the necessary data (H(Common)) to be proved, as opposed to the SET PRes message (which does not contain HOIData). A Proving Auth(C-A) A can prove Auth(C-A) by providing AuthReq and Common to V. An interesting difference can be mentioned between ikp and SET. In ikp, EncSlip allows A to retrieve necessary values (such as PRICE) to rebuild Common, but its contents (credit card number... ) need not be revealed to V in order to prove Auth(C-A). In SET, A needs to reveal the decrypted contents of

80 Chapter 4. Analysis of Accountability Features in SET and ikp PI to V in order to show Auth(C-A). The reason is that A does not possess OIData and therefore needs to rely on proving the relationship between (decrypted) PIData and Sig C. C Proving Auth(A-C) With a Confirm with positive (negative) RESPCODE, C can prove A s positive (amount = PRICE) or negative (amount = 0) authorization of value subtraction. In SET, PRes does not contain a signature by A and thus the evidence collected by C does not allow C to prove Auth(A-C). A Proving Auth(M-A) With Auth-Request and the reconstructed Common (using values from the decrypted EncSlip), A can prove M s authorization of value claim. As mentioned in Section 4.5.1, in a variant of the 3KP protocol, Sig M is sent already in Invoice, representing a signed offer. The use of this protocol option deserves a cautionary note: Sig M, included in Invoice, can be used by the Customer (or an intruder intercepting Payment) to compose a valid Auth-Request without awareness or consent by the Merchant. This may lead to scenarios where an honest Merchant M cancelled a payment but a dishonest party may make it seem that M authorized it at the same time. (Remember that M is not allowed to send both Cancel and Auth-Request.) This can be addressed in one of the following ways. The protocol can be changed such that M s signature in AuthReq is a different one than in Invoice; or, dispute handling rules specify explicitly that M s signature in Invoice also authorizes a value claim. In the latter case, M cannot issue a Cancel after having issued an Invoice if he does not want to be accused of cheating. M Proving Auth(A-M) With a positive Auth-Response (RESPCODE positive), M can prove A s authorization of value claim; a negative RESPCODE proves A s denying value claim authorization. 4.5.3 Discussion In 3KP, each of the parties obtains the evidence needed for proving the other parties authorizations. Proving authorizations also reveals less sensitive data than in SET: DESC, the description of the goods, need not be revealed unless it explicitly needs to be proved; similarly, the encrypted credit card slip need not be revealed to the verifier to prove B s authorization of value subtraction. A comment can be made about the value of signing a hash or hash tree. As shown above, all three parties sign H(Common), and their signatures commit them to all the values in H(Common). All three parties thus sign H(DESC, SALT D ). However, only C and M know DESC thus only C and M commit themselves to DESC when signing H(DESC, SALT D ): for A, signing H(DESC, SALT D ) does not entail signing its constituent parts. Such a distinction should be pointed out in the definition of the protocol and its provability rules. 4.6 Summary In this paper, we formulated a number of provability requirements for payment protocols. Our starting assumption was that every honest participant should collect enough evidence to prove its transaction views without relying on evidence provided by other parties. First of all, this is needed to use digital receipts as self-contained pieces of evidence in off-line verification scenarios. Furthermore, relying on other parties to give evidence requires trust in those parties. Also, it assumes that these other parties payment systems are enhanced with interoperable dispute handling and evidence collection mechanisms.

4.6. Summary 81 This is realistic only if those mechanisms are standardized to the same level as the payment system itself, and if they become a mandatory part of it. We validated the most secure version (all parties digitally signing messages) of SET against these provability requirements, and concluded that some important assertions cannot be derived from evidence collected during a correct protocol run. Specifically, the Customer in a SET transaction has no secure receipt of payment. A comparison shows the equivalent version of ikp to provide more complete evidence than SET. Some of the findings led to general recommendations for constructing payment protocols with accountability. One example is the use of hash trees, constructed such that sensitive data can be revealed selectively. Another, more important, general finding is the following: secure authorization using digital signatures does not guarantee provability of the authorization to an external verifier, unless the message is sufficiently self-contained. In conclusion, we recommend that protocols claiming accountability explicitly specify the rules to be used for deriving authorization statements from digitally signed messages.

82 Chapter 4. Analysis of Accountability Features in SET and ikp Postscript: Fairness and Provability of Claims Fairness Considerations The generic protocol in Figure 4.1, representing SET and ikp, defines C to be the initiator of the payment, i.e., C authorizes payment before M (the payment responder) does. C also is the initiator in value subtraction, and M is the initiator in value claim. This inherent asymmetry is a possible source of unfairness: if the initiator of a primitive transaction does not receive a reply, it may not know whether its message arrived, whether it arrived but will not be replied to or followed up on, or whether the responder followed up on the payment but refuses to issue a response. Consider the example of C having sent Pay-Request with a certain validity duration, and not receiving any response. Without resorting to off-line mechanisms, such as calling its bank, C has no way to determine whether M captured the payment. Even if the bank confirms the payment, this evidence is not equivalent to a formal receipt by the Merchant, since C cannot consider it as sufficient evidence in a dispute with M: M can always claim the bank made a mistake. Moreover, if C knows the payment was not captured, it does not know whether M will still capture it within the validity time of the Pay-Request. Therefore, C does not know whether it should place the same order with another merchant, or to place a new order with the same M (possibly now to different conditions). Unfairness due to network failures can be avoided by building fault tolerance mechanisms into the payment system, allowing parties on the initiating side of an exchange (C in Pay-Request, M in Auth-Request) to keep polling for a reply. Unfairness due to dishonest parties can be partially compensated for in an infrastructure for dispute handling. The following paragraphs describe some different, complementary, mechanisms. Forced transaction termination In the presence of a dispute handling or arbitration infrastructure, C, when uncertain about the outcome of the transaction, may contact the arbitrator and ask the arbitrator to extort a (positive or negative) receipt from M. This can be a protocol-compliant receipt, or a signed statement from M that M has no record of the transaction. If M states to have no record of the transaction, the arbitrator composes an affidavit stating the payment did not occur. This is a mechanism similar to the one described by Asokan et al. [6]. Forced termination of a transaction is a mechanism outside of the payment protocol; we do not discuss it with specific reference to SET or ikp. Replacement receipts Another, complementary, mechanism for limiting unfairness is to define which pieces of evidence can be used as a replacement receipt for a specific authorization. In the case of C not receiving Pay-Response, the arbitrator may ask evidence from A. The arbitrator may conclude that a valid Auth-Request Auth-Response pair provided by A is sufficient evidence to prove M s authorization of the payment, and that these pieces of evidence are equivalent to Auth(M-C). As a general rule, an arbitrator can derive Auth(M-C) from Auth(M-A) and Auth(A-M). The applicability of the rule depends on the provability of the latter statements. Proving receipt of authorizations In some cases, the sender of an authorization may simply want to prove that another party received its authorization. This may be the case if the receiver did not execute the protocol as agreed or required: C may want to prove that M received and was able to verify C s payment authorization: M received (C authorized payment (C,M,Amount,Date,Ref)).

Postscript 83 M may want to prove that A received and was able to verify M s value claim authorization: A received (M authorized value claim (M,A,Amount,Date,Ref)). C may want to prove that A received and was able to verify C s value subtraction authorization: A received (C authorized value subtraction)). Proving these statements may help the claimer in proving higher-level claims in the language defined in Chapter 3 about what parties could have done. Consider, as an example, the case where C initiated a payment based on a special offer by M, and M didn t reply to this payment. C can try to prove that M received (C authorized payment (C,M,Amount,Date,Ref), and thus M could have captured C s payment. In order to prove receipt of a certain payment message, one may consider involving third-party services, such as certified e-mail or fair exchange services [6]. These can provide the sender of a payment message with a signed receipt (by the receiver) of the message, proving that the recipient received this specific message. It is sometimes assumed that such a signed receipt also suffices to prove that the recipient could continue the protocol. Applied to the above example, one could assume that a signed receipt by M of C s valid Pay-Request message proves that M received (C authorized payment (... )). Using signed message receipts to prove receipt of authorizations poses certain requirements on the payment protocol. In the following paragraphs, we will investigate, for SET and ikp, whether a signed receipt of a certain message indeed proves that the recipient had all the necessary data to verify the message (and thus was able to continue a normal protocol run). Evidence of Received Authorizations in SET We now want to investigate whether a signed receipt of a correctly formed SET message suffices to prove that the recipient was able to verify the message (and continue the protocol). The examples in SET where this may apply are: C proving M received (C authorized payment (... )). Even if it can be proved that M issued a valid PinitRes and received a valid PReq, it cannot be concluded that M knew all the necessary data (PurchAmt, ODSalt, OD) to verify PReq. Even if M issues a negative PRes, it cannot be proved that M had (or agreed with) the necessary data to authorize the payment (since PRes does not contain HOD). M proving A received (M authorized value claim (... )). If it can be proved that A received a valid AuthReq, one cannot prove that PIData was acceptable to A unless C wants to cooperate by revealing all the contents of PIData (including PANData). A similar reasoning holds for C proving A received (C authorized value subtraction (... )). As can be seen from these examples, proving that a party (M or A) received a valid SET message does not prove that the party could verify the message. Evidence of Received Authorizations in ikp Also for ikp, we investigate whether proving receipt of a valid protocol message allows to conclude that the recipient had enough information to continue the protocol: C proving M received (C authorized payment (... )). It needs to be proved that M received a valid Payment and knew all the data necessary to verify it, i.e. Common. It can only be proved that M knows Common if M signed Invoice, which is not the case for the simplified version presented in Figure 4.4.

84 Chapter 4. Analysis of Accountability Features in SET and ikp In the version presented in Chapter 2, M optionally signs Invoice; one can thus claim that the use of this option allows to prove the statement. In the actual implementation [16], however, parties may, in their signatures, include data which is communicated out-of-band; these are the OPTSIG X parameters also mentioned in Section 4.5.1. The relevant data in this case is OPTSIG C, which is included in C s signature in the Payment message. Proving that M could verify Payment then requires proving M s knowledge of OPTSIG C as well. Thus, unless the mechanism transporting the out-of-band data uses signed receipts as well, and Sig M was part of Invoice, the statement cannot be proved. M proving A received (M authorized value claim (... )). It needs to be proved that A received a valid Auth-Request and knew all the data necessary to verify it. This requires proving that, in addition to the contents of Auth-Request, A knows the transaction identifiers TID C and TID M ; these are again communicated out-of-band. A similar reasoning holds for C proving A received (C authorized value subtraction (... )). Thus, also in ikp, evidence that a party received a valid protocol message does not allow to prove that the party could continue execution of the protocol. Conclusion The previous paragraphs discussed the issue of fairness, and how it influences what parties can prove in a transaction. If a party fails to continue a protocol as expected, other parties are in a disadvantage w.r.t. proving the current state of a protocol. Termination can be enforced by a third party or by taking into account evidence by other parties in the protocol. Proving that a party received a correctly formed protocol message may allow to prove certain modal statements (could without, can without) in the dispute language defined in Chapter 3. However, this requires that one can also prove the ability of this party to verify the correctness of the message; we showed that this is not the case for the example scenarios investigated for SET and ikp.

Chapter 5 Secure Anonymous Signature-Based Transactions Preamble In this chapter, we create a pseudonymized (or anonymized) version of an ikp- or SET-like payment protocol. The basic protocol is certificate-based and its exact format is derived from the requirements for accountability discussed in Chapters 3 and 4. The concept used is that of a pseudonym server acting as an anonymizing service for the user. The pseudonym server is independent from (and transparent for) the actual payment infrastructure where payment certificate issuers issue non-pseudonymous certificates and capture payments based on these certificates. This chapter introduces the concept of a liability-enhanced certificate infrastructure where certificate issuers as well as certificate holders commit to liabilities for (the use of keys certified in) various certificates; this is needed in order to analyze the security of any of the proposed solutions and the risk incurred by the different parties in the system. This concept will be reused throughout the remainder of this work as a basis for accountability and security in anonymous systems. In this chapter, we also discuss some of the limitations of using certificate-based systems for providing unidentifiability. An important limitation is the fact that, even if a certificate is pseudonymous, all its uses can be linked. Avoiding this linkability within a certificate-based infrastructure requires single-use certificates; a better solution will be offered by anonymous credentials as introduced in Chapter 6. This chapter contains the following paper [118]: E. Van Herreweghen. Secure anonymous signature-based transactions. In F. Cuppens, Y. Deswarte, D. Gollmann, and M. Waidner, editors, Proc. 2000 European Symposium on Research in Computer Security (ESORICS), volume 1895 of Lecture Notes in Computer Science, pages 55 71. Springer-Verlag, 2000. 85

86 Chapter 5. Secure Anonymous Signature-Based Transactions

Secure Anonymous Signature-Based Transactions Abstract Electronic commerce protocols often require users to reveal their identities and other information not necessary for reasons of security. Some applications such as contract signing are often argued to require a signer s authenticated identity; but this authentication may give the recipient a false feeling of security if certificate registration procedures do not guarantee a mapping to a liable person, or correctness of certificate data. In this paper, we propose a separation of identity from liability. Liability-aware certificates allow a certificate issuer to make explicit which liabilities it takes with respect to the transaction, the certificate data or the signer s identity. We illustrate their use in the design of a pseudonym service providing pseudonym certificates for secure anonymous transactions. 5.1 Introduction Many electronic commerce services and protocols are not designed with the goal of protecting the privacy or anonymity of end users. In fact, they often require the user to give a lot of information not strictly necessary for reasons of security. Such information can be present in the certificates certifying the user s public key. As the collection and exploitation of information becomes more of a concern, users are less willing to give out information. It is therefore desirable to re-examine the need for giving out certain information items as part of business processes. Necessary is only the information from which the recipient of a digital signature (representing a payment, an auction bid, a contract) derives trust that the payment is valid, that the bidder will pay upon winning the bid, that the signer is liable to execute the contract. Most often, this trust is not based on the signer s identity. Rather, it is based on the identity and trustworthiness of the authority certifying the signer s key, thereby implicitly or explicitly vouching for transactions made with that key. Also, the liability of certification authorities with respect to certificate registration procedures is often unclear. When a party relying on a signature requires that it be made by a certified real identity, there may be an assumption but no guarantee that a legal person can be held liable for this signature. Rather than receiving a signature by an authenticated real identity certified under uncertain liability rules, it would be more useful for the relying party to have the certifier s guarantee that a legal person can be held liable for the signature. In this paper, we demonstrate a separation of identity from liability and certification. We transform a number of signature-based protocols into pseudonymized versions. We show how to provide maximal security for the relying party by including issuers liabilities into signers certificates. We distinguish between liability for data in the certificate, liability for transactions made with the certificate, and liability to reveal a signer s real identity under specified conditions. 87

88 Chapter 5. Secure Anonymous Signature-Based Transactions C M A Customer Merchant Acquirer Sig C { }} { S C(C, M, A, amount, ref) Sig2 M { }} { S M(C, M, A, amount, ref), Sig A Sig1 M { }} { S M(M, A, C, amount, ref), Sig C Sig A { }} { S A(M, A, C, amount, ref) Figure 5.1: Generic Payment Protocol The outline of the paper is as follows. In Section 5.2, we introduce the concept by describing a pseudonym server transforming certificates in a generic account-based payment system into single-use pseudonym certificates. We show that it is possible for the payment recipient to have a guarantee of payment, without affecting the protocol, and without introducing any liability for the pseudonym server. In Section 5.3, we discuss the value of certificates and signatures for more general applications, and introduce a liabilityaware certificate format. In Section 5.4, this certificate format is used in the design of a generic pseudonym server, issuing pseudonym certificates for a potentially large set of applications. Section 5.5 discusses related work and suggestions for future research; Section 5.6 concludes the paper. 5.2 Pseudonymizing a Generic Payment System The generic payment protocol in Figure 5.1 follows the model of the ikp [17, 16] and SET [104] protocols. Its exact format, however, is derived from the requirements for disputable payment protocols in Van Herreweghen et al. [8]. After presenting the protocol, we analyze its implicit guarantees and liabilities. We then introduce a pseudonym server (PS) into this system and design a pseudonymized version of the payment protocol. The goal is to preserve existing payment guarantees for the relying party while minimizing the pseudonym server s liability. 5.2.1 The Generic Payment Protocol The participants in the protocol are C (Customer), M (Merchant) and A (Acquirer). C s certificate Cert C is issued by I (Issuer) and specifies I s liability for payments made using Cert C ; I s certificate Cert I is assumed to be issued by a root certification authority. We refer to Figure 2.1 for a clarification of I s role; Buyer and Seller in Figure 2.1 correspond to C (Customer) and M (Merchant) in this discussion. We use the following notation: SK X, PK X : X s private signature key and public key in a digital signature scheme. S X (M): Signature with SK X over message M does not include M. E Y (M): Encryption of M under Y s public encryption key.

5.2. Pseudonymizing a Generic Payment System 89 Cert X : X s public-key certificate (certifying PK X ). role: Role in the payment system ( customer, merchant, issuer, acquirer ). With Sig C, C authorizes a payment to M, who then adds its own signature Sig1 M to form an authorization request. Sig A constitutes A s authorization response. M creates a payment receipt Sig2 M and sends this together with Sig A to C. The parameter ref contains at least a transaction identifier trx id and a transaction time, possibly also a goods description or a hash thereof. We only represent the actual signatures; which of the components of a signature are actually sent as part of the protocol messages, or as part of a previous negotiation protocol, is not relevant to this discussion: it is assumed that the verifier of a signature possesses the data constituting the signed message (including the necessary certificates to verify them). M may verify Sig C to validate the correctness of transaction data. M s payment guarantee, however, is derived from A s authorization Sig A. A s authorization, in turn, is based on the validity of Sig C, the contents of Cert C and Cert I, and the terms of the contract between A and I. The combination of Cert C, Cert I and this contract provide A with a guarantee such as I will honor validly constructed payments verifiable with PK C up to an amount of $1000 subject to the condition that Cert C nor Cert I were on a revocation list accessible by A at the time A authorized the transaction. As I may not be able to verify exactly when A authorized the payment, I may allow a maximum processing delay :... were on a revocation list 12 hours before A presents the transaction to I for clearance. Liabilities or revocation conditions may not actually be part of existing certificates; rather, they are part of contracts, implicit agreements or implicit procedures and are thus implicitly present in a certificate. We can then represent a certificate Cert X, issued by Y: 1 Cert X = S Y (role, X, PK X, Y, L = {amount, condition}) where L stands for Y s liability for transactions verifiable with PK X. possibly the conditions related to revocation. In the example above, assuming that I is directly certified by a root authority: L consists of an amount and Cert C = S I(customer, C, PK C, I, L = {amount=$1000, maxdelay = 12 hrs}) Cert I = S root(issuer, I, PK I, root, L = {amount=$10,000, maxdelay = 12 hrs}) 5.2.2 Requirements for a Secure Pseudonymized Version We now develop a pseudonymized version of the above generic payment protocol. C, possessing a longterm payment certificate Cert C, can obtain one-time pseudonym certificates Cert P from a pseudonym server PS, allowing C to make payments under the pseudonym P and remain anonymous towards M and A. (We assume that we cannot change the existing payment infrastructure and thus that the interface between C and I, such as registration, account definition and payment processing, is fixed. In this infrastructure, C has a non-anonymous account with I, and I expects a valid payment order to be linked to that account. Therefore, we do not consider anonymity of C towards I. However, the constructions introduced to anonymize C towards M and A can also be applied to anonymize C towards I if we relax the previous assumption and allow a change to the interface between C and I.) PS, of course, needs to be a recognized issuer in the specific payment system in order for Cert P to be considered a valid certificate by the relying party. We first list the different criteria against which we will measure the pseudonymized version. 1 The notation for liability is intuitive and does not define a specific format or language. The certificate format is merely a symbolic representation; additional information such as expiration time, attributes etc. are represented only when relevant to the discussion.

90 Chapter 5. Secure Anonymous Signature-Based Transactions Guarantees Towards Relying Party (A). A valid signature Sig P over a transaction has the same guarantee of payment as a valid signature Sig C over the same transaction. For general signature-based protocols (as discussed in Sections 5.3 and 5.4), a relying party may want the pseudonym certificate to express the conditions (e.g., fraudulent behaviour) under which it can obtain a real identity of the signer. In the specific case of a payment protocol, however, we assume that only the guarantee of payment is relevant to the relying party. It should therefore be unnecessary to ever reveal the real identity of even a dishonest or fraudulent C to A (or M). No Extra Risk for I. I wants evidence of C s payment authorization even if the payment is made under pseudonym P: if I does not trust PS, I has no reason to debit C s account for pseudonymous payments under a pseudonym P which allegedly represents C. Even if I trusts PS (e.g., I operates PS as a service), I may need to prove C s authorization to a third party, e.g., in order to protect itself against repudiation by C. Minimal Trust by C in PS. PS should protect C s privacy and not give away information about C, or reveal the linking between C and the pseudonyms it uses. PS may publish privacy policies stating to which end, under which conditions and to whom PS may reveal which information about C. As mentioned in the first requirement, PS should never have to reveal any information about C to M or A. (Of course, if PS ever has a dispute with C, PS may need to reveal C s identity to a third party.) It is difficult to enforce and verify PS s compliance with its privacy policies; C has to trust PS to adhere to them. This requirement holds for the various pseudonym server scenarios in this paper, and we will not repeat it when discussing their security. Another of C s requirements is for PS not to be able to frame C. This requirement seems easy to fulfill if C is allowed to issue its own pseudonym private keys. We will see, however, that PS may have an interest in issuing the pseudonym private keys if it wants to limit its own risk. Minimal Risk for PS. PS is liable for transactions made with certificates it issued. PS can rigorously limit that liability, e.g., by issuing single-use Cert P only after receiving a valid Sig C from C. Then, when PS is held liable for a payment (Cert P, Sig P ), it can show (to I or a to a third party) a payment (Cert C, Sig C ) for which I is liable. Still, revocation issues need to be taken into account: for PS to assume no liability at all, the possibility should be excluded that Cert P can be valid after Cert C has been revoked. In the following sections, we investigate different possibilities for pseudonymizing the previous protocol, with different impact on liability of PS, on efficiency, and on PS s infrastructure requirements for revocation. 5.2.3 Design for Maximum Security: PS On-line, CERT P Linked to Transaction In this first design, PS issues a different pseudonym key pair (PK P, SK P ), pseudonym certificate (Cert P ) and signature Sig P for C for each transaction. PS is thus always on-line and participates in the transaction. The pseudonym certificate is linked to the specific transaction; this guarantees that it can be used only once.

5.2. Pseudonymizing a Generic Payment System 91 Description of the Protocol. The P-M-A transaction in the pseudonymized protocol is the same as the C-M-A transaction in the original protocol, with C s identity, signature and certificate replaced by P s identity, signature and certificate. M and A see P as customer; and PS as the issuer of P s certificate: Sig P = S P (P,M,A,time,amount,ref) Sig1 M = S M (M,A,P,time,amount,ref) Sig A = S A (M,A,P,time,amount,ref) Sig2 M = S M (P,M,A, time,amount,ref) PS issues Sig P only after having received and validated a transaction signature Sig C from C. Sig C is PS s evidence of C s commitment to the transaction. PS includes Sig C in Cert P, allowing I to check Sig C : this protects PS against repudiation by C and protects C against framing by PS. New certificates introduced in the system are then: Cert P S is a root-issued issuer certificate: Cert P S = S root (issuer, PS, PK P S, root, L root ). Cert P = S P S (customer, P, PK P, PS, L P S, issuer data) with issuer data = E I (Sig C, C), the encryption of C s identity and transaction signature. It can only be decrypted by I and provides I with evidence of C s authorization. The resulting protocol is depicted in Figure 5.2. To highlight the difference with the original version, we also show the transport of certificates belonging to C (and I) and P (and PS). C PS M A Sig C, Cert C, Cert I generates P, SK P, PK P Sig P, Cert P, Cert P S Sig1 M, Sig P, Cert P, Cert P S SIG A, SIG2 M SIG A, SIG2 M Sig A Figure 5.2: Pseudonymized Payment Protocol: On-Line PS, One-Time Pseudonym Certificate The settlement between A and I (not shown in the figure) may be done at a later point in time. Depending on A s awareness of pseudoymized certificates, A may initiate a settlement with PS by sending {Sig P, Cert P } to PS and PS sending issuer data to I. Alternatively, A directly sends issuer data to I. To hide the linking between C and P also towards outsiders, the channel between C and PS additionally needs to be encrypted. Also, traffic anonymizers or Mixes [3, 67, 97] used on the C-PS and C-M channels

92 Chapter 5. Secure Anonymous Signature-Based Transactions can help to unlink the pseudonym request from the pseudonym use, and to hide the linking of C or P to a network address. These extensions apply to the different pseudonym server designs in this paper but are not discussed here. The receipts Sig2 M and Sig A don t include C s identity; C may thus not be able to use them as transaction receipts. One could allow C to prove the linking between C and P by including this linking (e.g., a hash H(C,P,ref)) in Cert P and by PS returning Cert P to C together with Sig A and Sig2 M. Still, this solution requires C to reveal its real identity when proving its participation in the transaction. This can only be avoided by changing the way receipts are used. E.g., C could prove ownership of a receipt Sig2 M or Sig A, not by proving a linking between C and P but by dynamically proving knowledge of a secret associated with P while showing the receipt. Such a secret could be SK P or another secret key associated with P, and would be securely communicated by PS to C. This alternative is a topic for future research. Security Analysis We now analyze the above protocol in terms of the requirements in Section 5.2.2. Guarantees towards relying party (A). We define a valid (Sig P, Cert P, Cert P S ) to constitute the same payment guarantee as in the original system, i.e., PS is liable to honor a valid Sig P under the condition of Cert P and Cert P S not being revoked. I only clears payments based on a valid Sig C, evidence of C s transaction commit- No extra risk for I. ment. Minimal trust by C in PS. PS cannot frame C, as I only accepts payments containing a valid Sig C. Minimal risk for PS. PS does not take any risk at all as long as it only issues Cert P for a valid Sig C and checks that Cert C is not on any revocation list. This ensures that any valid Sig P is based on a valid Sig C, i.e., any payment which is acceptable to A will be honored by I, and thus PS can transfer any liability to I. PS only increases its risk (up to the amount in L P S of Cert P ) by not acting honestly or correctly. The absence of risk for PS strongly depends on PS issuing the pseudonym key pair. If C were allowed to issue his own (SK P, PK P ), it would be possible for C to generate a Sig P inconsistent with Sig C, causing liabilities for PS not covered by I. Discussion The model of PS issuing pseudonym keys and certificates for every new transaction provides maximum security to all the parties, and a total absence of risk for the PS. For reasons of efficiency, however, it may be desirable for C to obtain pseudonym certificates ahead of time, such as to avoid contacting PS for every transaction. The next section describes such an alternative solution and its security features. 5.2.4 Alternative Design: Off-Line PS Allowing C to obtain certificates ahead of time has two direct consequences. First, the pseudonym certificate can no longer be linked to a specific transaction, and thus has to be valid for a certain amount of time. Second, as C makes the actual pseudonym payment without PS s involvement, C has to issue the pseudonym key pair. This introduces major risks:

5.2. Pseudonymizing a Generic Payment System 93 1. PS cannot enforce a linking between Sig C and Sig P. Or, PS cannot enforce that P s payment valid for A contains C s payment acceptable to I. 2. After issuing Cert P, Cert C can be revoked, which leaves PS with the liability for payments with Cert P until Cert P is revoked or no longer valid. The second problem can be addressed in either of the following ways: PS issues very short-lived pseudonym certificates (e.g., Cert P lifetime is smaller than the revocation delay of Cert C ). Then, even if Cert C is revoked, any outstanding Cert P will be invalid by the time I refuses payments with Cert C. This solution, however, defeats the purpose of C obtaining certificates some time before the actual transaction. PS revokes pseudonym certificates by posting Certificate Revocation Lists (CRLs) to the appropriate CRL directories. It should then frequently verify revocation status of parent certificates Cert C of outstanding pseudonym certificates Cert P, and revoke pseudonym certificates as needed. In order to address the first problem, PS has to take the role of an insurer, resort to risk management strategies, and charge for the service accordingly. Alternatively, PS may require a deposit or guarantee from C equal to PS s liability for the pseudonym certificate. Neither solution, however, gives I or a third party evidence of the transaction by C. The protocol in Figure 5.3 constructs such evidence by C committing to the pseudonym (keys) as part of the pseudonym retrieval procedure; this commitment S C (Cert C, PK P,... ) may be encrypted for I and included in Cert P, in a way similar to Sig C in the protocol in Figure 5.2. Such a scenario changes the dispute handling rules of the protocol: with the combination of Sig P and the commitment, I as well as an external verifier should conclude that C authorized the payment. It may also solve the first problem: if PS includes the same liability in Cert P as in Cert C, PS again can transfer liability to I for every payment valid to A. 1. Pseudonym Retrieval Procedure C generates P, SK P, PK P CertC, PKP, SC(CertC, PKP, P, expirationa ) CertP = SPS(customer, P, PKP, PS, L, EI(C, SC(CertC,...))) 2. Actual Transaction C M A Sig P, Cert P, Cert P S Sig1 M, Sig P, Cert P, Cert P S SIGA, SIG2M SIGA PS a C may also want to limit its liability for Cert P Figure 5.3: Pseudonymized Payment Protocol: Off-line PS

94 Chapter 5. Secure Anonymous Signature-Based Transactions Security Features Guarantees towards relying party (A). We define, as in the previous solution, a valid (Sig P, Cert P, Cert P S ) to represent a payment guarantee for A, on condition that Cert P or Cert P S are not revoked. No extra risk for I. From Cert P and the encrypted commitment, I can derive C s identity and commitment to P and PK P ; from Sig P, P s authorization of the transaction. Thus I takes no extra risk on condition that a potential external verifier applies the same verification rules. Minimal trust by C in PS. PS cannot frame C, as C generates the pseudonym keys. Minimal risk for PS. If PS takes care of the revocation problem (immediately revoking Cert P in case of a revoked Cert C ) and makes sure not to take more liability in Cert P than I takes in Cert C, PS again limits its liability. 5.2.5 Discussion The designs in Sections 5.2.3 and 5.2.4 both provide equal guarantees towards the relying party but show some tradeoffs between PS s liability, and changes of infrastructure and efficiency. An off-line PS serving pseudonym certificates ahead of time may be a more efficient solution. In this case, PS has to limit its liability by taking care of timely revocation of pseudonym certificates, and by requiring that the user commit to the pseudonym key. This commitment has to be recognized by an external verifier in order for I to prove the user s authorization through P. An on-line PS issuing transaction-linked certificates is a less efficient solution but allows PS to rigorously minimize its liability without requiring any changes in verification and dispute handling infrastructure, and without requiring PS to handle revocation issues. 5.3 Generalized Signatures and Liabilities The pseudonym server designs in the previous section are specific for the payment protocol and assume that the user already has a long-term certificate for use in this protocol. When dealing with more general signatures, such as digitally signed contracts, it may no longer be possible to attach a fixed value to the transaction, as we did in the case of payments. The party relying on a signed contract may also attach a value to the guarantee that the signer is a liable person whose identity will be revealed under certain conditions, or to the correctness of certain attributes in the signer s certificate. A generic digital signature (with corresponding certificate) can be represented as: with CERT S = S I (Pid, role, S, PK S, I, attrs), SIG S = S S (trx data, trx id) Pid, role: the protocol identifier and S s role; S: the signer (of the contract, auction bid, payment,... ); I: the certificate issuer certifying PK S ; trx data: describing the type and contents of the transaction; trx id: a unique transaction identifier (similar to the ref parameter).

5.3. Generalized Signatures and Liabilities 95 Sig S expresses S s commitment either to the correctness of trx data, or to the execution of some action described in trx data, such as payment or contractual obligation. A verifier V can hold S (or, I through Cert S ) liable for this commitment. In order to determine the potential value of such a liability, we describe the different damages to V that can be incurred: V may suffer loss if attrs in Cert S are not correct; e.g., attrs specify a quality label of S as a registered construction company and SIGs represents a bid for constructing a building. V may suffer loss if data in trx data is incorrect; this may be relevant if S s commitment is a commitment to data rather than to an action or contract. If trx data represents an action or contractual obligation, V suffers loss if the promise (contract) expressed in trx data is not kept (executed). In the special case of the contract being a payment, it can be the value of the payment. In order to express I s or S s liability for data (attrs or trx data), it should be possible to attach a value to their correctness. Also, their correctness should be publicly verifiable, or, it should be specified which third party or arbiter can judge this. 5.3.1 Liability-Aware Certificates The possible losses described above can be covered by liabilities included into certificates: Cert S = S I (Pid, role, S, PK S, I, attrs, L) L, the issuer s liability, consists of a set (0 or more) of individual components, each of which have one of the following types: Ld (related to data liability), Lt (related to transaction liability) and Li (related to identity liability). Other than a type, each component has an amount, a condition for liability, and an indication of which party can evaluate the condition. Some examples of individual liability components are: a liability {type = Ld, amount = $1000, condition = attrs, verifier = Arbiter} indicates that the certificate issuer takes a liability of $1000 for any certificate attributes which are found to be incorrect by Arbiter. a liability {type = Ld, amount = $1000, condition = trx data, verifier = Arbiter} indicates that the certificate issuer takes a liability of $1000 for any trx data signed by the certificate holder which are found to be incorrect by Arbiter. a liability {type = Lt, amount = $1000, condition = any, verifier = Arbiter} indicates that the certificate issuer takes a liability of $1000 if Arbiter evaluates the transaction (e.g., the contract execution) as failed. a liability {type = Li, amount = $10000, condition = trx data, verifier = Arbiter} indicates that the certificate issuer is liable for revealing the real identity of a signer (who is a liable person) if Arbiter evaluates trx data to be false or not executed. Failure to reliably reveal a real identity makes the issuer liable to compensate $10000. Following are some additional examples of the use of liabilities in specific applications: A liability in a user certificate for a SET-like payment system could look as follows: L = {{type=lt, amount=$1000, condition=(revocation delay=12hrs), verifier=arbiter}}. Here, the only liability taken by the issuer is to honor payments up to $1000 as long as the revocation condition is fulfilled. The issuer does not take any liability for attributes or for revealing a signer s identity.

96 Chapter 5. Secure Anonymous Signature-Based Transactions A liability in a certificate of a construction company used for contract signing could be: L = {{type=ld, amount=$1000, condition=attrs, verifier=arbiter}, {type=li, amount=$10000, condition=trx data, verifier=arbiter}}. The issuer takes no liability for the transaction (or its execution); it takes a liability of $1000 for any false attributes, and guarantees, with a penalty of $10000, to reveal the real name of a signer if the contract is not executed as asserted by the verifier. The above examples are meant to demonstrate the concept; in a detailed design, the expression of individual liabilities and conditions may require more complex statements. In the following section, we now describe the design of the pseudonym server. We use the liability-aware notation for long-term and pseudonym certificates. 5.4 A Generic Pseudonym Server We would like a generic pseudonym server to fulfill following requirements: 1. The pseudonym server issues certificates that can be used in a set of different protocols, such as contract signing, auction, payment. 2. The pseudonym server can serve certificates in a protocol-independent manner, i.e., does not play an active role in composing protocol-specific signatures. 3. The pseudonym certificates are not necessarily linked to a specific transaction, allowing for pseudonym certificates to be acquired ahead of time. 4. The one-time user of a pseudonymous service or protocol need not have a long-term certificate for that protocol, i.e., a user registered with the pseudonym server may request one-time pseudonym certificates for a number of protocols. E.g., the PS could be a service provided by a user s Internet Service Provider (ISP) and the user can obtain a one-time SET certificate for a specific payment. A user S of such a pseudonym service has a long-term certificate Cert S recognized by or issued by PS, and can obtain pseudonym certificates from PS for different protocols and transactions. Figure 5.4 shows such a pseudonymized transaction. The CERT REQ CERT RES exchange constitutes the core PS functionality. The other flows illustrate the possible use of pseudonymized certificates within a specific transaction: in an optional CERT PROP flow, the verifier V sends to S the proposed certificate format; the last flow containing Sig P is S s actual transaction commitment using pseudonym P. 5.4.1 CERT REQ, CERT RES We now describe the message and certificate formats in more detail; the design choices are then clarified when analyzing the security of the pseudonymous transaction. Cert S = S I (pid S, role S, S, PK S, I, attrs S, L I S ) with L I S the set of liabilities I takes for data in Cert S and transactions with Cert S. Cert P = S P S (pid P, role P, P, PK P, PS, attrs P, L PS P ) with L PS P the set of liabilities PS takes for data in and transactions with Cert P. Cert P may be linked to a specific transaction by specifying a transaction identifier as part of the various liability conditions. This limits the risk taken by PS, and may make it unnecessary for PS to have to deal with revoking Cert P. Note that PS can be the same entity as I, in which case S simply has a long-term account with PS. This can be the case if the PS service is offered by a ISP. CERT REQ = S C (CERT REQ, pid P, role P, P, PK P, PS, attrs P, L PS P ), Cert S

5.4. A Generic Pseudonym Server 97 S(igner) PS V(erifier) generates P, SKp, PKp CERT PROP CERT REQ CERT RES SIG P { }} { S P(trx data, trx id), Cert P CERT RES = Cert P Figure 5.4: Generic Pseudonym Server With CERT REQ, S communicates the desired certificate contents to PS, and at the same time commits to signatures made with SKp in the context of the requested Cert P. It can thus be seen as a secure registration procedure where S takes liability for PK P and the Cert P not yet received, in a way provable by PS. PS s decision to issue Cert P depends on its evaluation of risk. This depends on the liabilities in the requested Cert P, whether it is valid for only one or more transactions, the contract terms between S and PS, whether or not S has an account with PS, etc. The processing of CERT REQ, therefore, may involve additional communication between S and PS, such as PS asking for some guarantee or deposit. 5.4.2 The Liabilities in CERT P In some cases, the expected liabilities in Cert P can be derived by V and/or S from transaction features, such as the amount of a payment or auction bid. More complex liabilities may be determined by V on a per-transaction basis. V may have to explicitly communicate expected liabilities to S, as shown with the CERT PROP flow in Figure 5.4. Such a message could have a similar format as a CERT REQ and can be signed by V: S V (CERT PROP,...,L) in which case it may be a binding commitment, part of the contract between S (P) and V. Security Features We now analyze the CERT REQ CERT RES flows with respect to the security features listed in Section 5.2.2, omitting the issuer-specific requirement which was specific for the payment system. Guarantees towards relying party V. The relying party V receiving a signature Sig P in a transaction has a guarantee of PS s liabilities in Cert P, thus of receiving liability amounts or the real identity of the signer. Minimal trust of S in PS. As S generates pseudonym keys and commits to them using its private signature key SK S, PS is not able to frame S.

98 Chapter 5. Secure Anonymous Signature-Based Transactions PS absorbs minimal risk. In case of a dispute, PS can prove S s commitment to a pseudonym key, and thus S s involvement in a transaction with that key. The remaining risk depends on the possibilities for PS to recover liabilities from I or S. This depends on contracts between S and PS (or between S and I). 5.4.3 Example: Auction We illustrate the above principles with one more example. In this example, an ISP plays the role of PS for its registered users, billing them for this service through the existing billing relationship. Registered users have a limited liability credit with the PS. A user S, registered with the ISP, wants a pseudonym certificate to bid on a last minute vacation offer with an auction service. The auction service accepts anonymous or pseudonymous bids under the condition that payment is guaranteed, the bidder s age is above 18, and the winning bidder s identity will be revealed to the auction service. S has a long-term certificate Cert S and private key SK S with which to authenticate to the ISP/PS. This long-term certificate may contain values of (or references to) maximum liabilities PS is willing to take for this user, attributes of the user (such as age) which PS has verified upon registration and is willing to vouch in a pseudonym certificate. The pseudonym certificate (and, similarly, CERT REQ) could look as follows: Cert P = S P S (e-auction, bidder, P, PK P, PS, attrs={{age>18}}, L={{Ld, $100, attrs, Arbiter},{Lt, $300, none, Arbiter}, {Li, $300, cond(auction id), Arbiter}}). This expresses that PS takes a liability of $100 for the correctness of age, gives a payment guarantee of $300 for the transaction, and guarantees to reveal S s identity on condition of winning the auction with identifier auction id. Assuming that PS can prove S s age to be over 18 to Arbiter, and PS has evidence of S s real identity, the risk taken by PS is limited to the transaction amount ($300), which may be below S s credit limit, in which case PS doesn t need additional deposits or guarantees from S. 5.5 Related and Future Work In this paper, we focused on existing systems based on X.509 [74] or similar certificates, on introducing explicit liability statements into these certificates, and on optimal control of the pseudonym server over its liabilities. Though the pseudonym server cannot frame users, it still has to be trusted with a large amount of information about users, their transactions, and the linking of their pseudonyms. Pseudonym systems based on blind signatures [39, 85]) can provide stronger anonymity guarantees and require less trust in the pseudonym server than the designs presented in this paper. They can provide protection against specific forms of user misbehaviour (such as double-spending a coin [37]) through cryptographic constructs that cause the identity of a misbehaving user to be revealed. It is interesting to investigate to which extent such pseudonym systems can support the functionality we provided in this paper. The potential complexity of liability conditions (such as the ones for revealing identities), however, seems to suggest the existence of a trusted party evaluating them, which does not fit with blind signature schemes. Also, blind signatures may make it much harder for an issuer or pseudonym server to control the usage of a pseudonym certificate and thus its liability. This paper has introduced a concept rather than a full design, and leaves several topics open for investigation. The liability types may need to be refined as more complex electronic negotiations and transactions are defined. Expressing liability contents, such as conditions and verifiers, was done using an intuitive notation; a language and notation need to be developed. The choice to use pseudonyms as identifiers in certificates was made for reasons of compatibility with the existing certificate formats. It would be possible to remove also those pseudonyms from certificates and use strictly anonymous certificates. It should also further be investigated how to use traffic anonymizers (such as Anonymizer [3]) or Mixes [67, 97] to provide unlinkability between the request for and the actual use of a pseudonym.

5.6. Conclusion 99 5.6 Conclusion In this paper, we have separated the notion of identity from liability, by suggesting that certificates explicitly specify liabilities needed by the party relying on a digital signature. We have illustrated this principle by introducing a pseudonym server that acts as an intermediate certificate issuer in existing certificate-based systems. The pseudonym certificates provide a relying party with clear guarantees, while the pseudonym server itself can calculate its own risk and minimize it through appropriate contracts with or deposits from requesting users. We demonstrated the separation of identity from liability by applying it to the anonymization of existing transactions. It is, however, equally applicable in non-anonymous systems, where the presence of a certified identity may cause relying parties to make incorrect assumptions about liability guarantees. Also in these cases, making certifiers liabilities explicit may help clarify objective guarantees, avoid unexpected liability gaps, and enhance trust.

100 Chapter 5. Secure Anonymous Signature-Based Transactions Postscript: A Generalized Certificate Notation In this chapter, we introduced liabilities as explicit contents of certificates. In following chapters, we will introduce more elements and new uses of certificates: Chapter 7 introduces self-signed certificates; with a self-signed certificate, an organization (e.g., a certificate or credential issuing organization) uses a master signature key to certify one or more keys used for specific purposes (e.g., for issuing credentials, for securing communication). Thus, a certificate can certify more than one key, and different key types need to be distinguished. Chapter 8 introduces certificates carrying only public keys and attributes, but no identities. In Chapters 8 and 9, a certificate request is treated as a special type of certificate. The certificate requests defined in those chapters will carry two types of liabilities: one is the desired issuer liability in the requested certificate (such as L PS P introduced in Section 5.4.1); a second type of liability is the liability taken by the requestor for the public key on which he is requesting a certificate. The latter liability was not discussed in this chapter but is used to quantify user liability based on the certificate request. In order to provide a unified representation for all certificates, certificate requests and self-signed certificates, we define a new notation to be used throughout the remainder of this work. Note that the certificate notation presented here merely serves to facilitate our discussion and does not claim to be a general all-purpose format (e.g., the key and certificate types discussed are limited to the ones used in this work). The notation is shown in Table 5.1. Naming of certificate fields and values is kept intuitive; e.g., Attrs Y X is the value of the field Attrs in the certificate Cert Y X. An entity Y signing a message can do so with any of a number of keys certified for him. As only signatures with master keys and (credential- or certificate-) issuing keys are relevant to the further discussion, we introduce a simple notation which allows us to distinguish between these different signatures: S Y (Msg) and Cert Y X are signed with Y s master signature key; while S Yi (Msg) and Cert Yi X are signed with Y s special-purpose issuing key (private key ISKey Y with public counterpart IPKey Y ). Issuing and other special-purpose keys, such as keys for verification, de-anonymization (re-identification) and securing communication, are introduced in Section 7.2.1 for credential issuers, and in Section 9.1.1 for certificate issuers. In a certificate Cert Y X (Cert Yi X), an entity Y certifies, by a signature with a master signature key SSKey Y (issuing key ISKey Y ) a key or set of keys CertdKeys Y X (CertdKeys Yi X ) belonging to entity X together with a set of attributes Attrs Y X (Attrs Yi X). Depending on the relationship between entities Y and X, Cert Y X (or Cert Yi X) represents different types of certificates: Y = X. With Cert X X, an entity (organization) X self-certifies special-purpose public keys using a master signature key. This type of certificate is introduced in Section 7.8.3. Y and X are different identities belonging to the same user, such as C and P (for a customer s real and pseudonym identity) as used in this chapter. Such a certificate is the equivalent of the CERT REQ earlier in this chapter: it is at the same time a request for a certificate as a selfcertification by C of a public key (and attributes) for P. Cert U C and Cert C P in the applications in Chapter 8 are of this type: with Cert U C, a user U requests a certificate on SPKey C which is, e.g., associated with a bank account; with the associated private key SSKey C, the user may then sign a certificate request Cert C P for a pseudonym certificate on SPKey P. Y and X belong to different entities. This is the case of a traditional certificate where an entity Y certifies a key or set of keys for another entity X.

Postscript 101 Cert Y X Cert Yi X X, Y Table 5.1: Generic Certificate Format certificate certifying X s public key(s), signed with Y s master signature key =S Y (CertdKeys = CertdKeys Y X, Attrs = Attrs Y X) certificate certifying X s public key(s), signed with Y s issuing key =S Yi (CertdKeys = CertdKeys Yi X, Attrs = Attrs Yi X) identifiers (names) of entities Y i entity Y in its credential or certificate issuing role (signing with its issuing key ISKey Y ) Z SPKey Y, SSKey Y stands for either Y or Y i Y s (master) signature public/private key pair IPKey Y, ISKey Y Y s public/private key pair for issuing certificates or credentials (Sections 7.2.1 and 9.1.1) VPKey Y, VSKey Y Y s public/private key pair for verifying credentials (Section 7.2.1) DPKey Y, DSKey Y Y s public/private key pair for de-anonymizing (Section 7.2.1) CPKey Y, CSKey Y Y s public/private key pair for securing communication (Sections 7.2.1 and 9.1.1) S Y (Msg) signature on Msg with SSKey Y (corresponding to signature public key SPKey Y ) S Yi (Msg) signature on Msg with ISKey Y (corresponding to issuing public key IPKey Y ) CertTp CERT CERTREQ SELFCERT CERT CERTREQ SELFCERT certificate type for traditional certificate certificate type for certificate request certificate type for self-signed certificate CertdKeys Z X Attrs Z X Ld Lt Li LiabAmount LiabCond LiabVerifier Liab Z X LiabReq Z X CertrKeyReq Z X X s (public) keys certified in Cert Z X = {[SPKey = SPKey X ], [IPKey = IPKey X ], [VPKey = VPKey X ], [DPKey = DPKey X ], [CPKey = CPKey X ]} attributes in Cert Z X = {CertTp = CertTp Z X, [Liab = Liab Z X], [LiabReq = LiabReq Z X ], [CertrKeyReq = CertrKeyReq Z X ],...} liability type for data liability liability type for transaction liability liability type for identity liability amount of a liability item condition under which a liability item becomes effective identifier of entity trusted to verify a LiabCond liability taken by the certifier; consists of zero or more liability items as defined in Section 5.3.1 ={{LiabTp = {Ld Lt Li}, LiabAmount =..., LiabCond =..., LiabVerifier =...} } (in Cert Z X of type CERTREQ) liability requested by the certifier of Cert Z X to be present in the requested certificate; same structure as Liab Z X (in Cert Z X of type CERTREQ) public issuing key of requested certificate

102 Chapter 5. Secure Anonymous Signature-Based Transactions CertdKeys Z X (Z standing for Y or Y i ) may thus contain a signature public key SPKey X associated with entity X, or any special-purpose keys. Note that also public encryption keys could go here; they are however not used in the remainder. Attrs Z X contains all the attributes and liabilities associated with Cert Z X. The only mandatory element in Attrs Z X is a field CertTp indicating whether Cert Z X is a traditional certificate (CertTp=CERT), a certificate request (CertTp=CERTREQ) or a self-signed certificate (CertTp=SELFCERT); other fields are optional and their presence may depend on this CertTp. The names (identities) of certifying entity and certified entity may also belong in Attrs Z X. In the following chapters, we will however assume that public keys can be considered to be (pseudonym) identities; we will thus not explicitly mention identities in certificates. Also protocol and role identifiers are not anymore explicitly mentioned; they can be assumed to be captured by the combination of key types and liability conditions. Other attributes may be defined on a per-application basis. E.g., in the example in Section 7.8.3, credential issuing organizations include addressing information, access control rules and contract information as attributes in their self-signed certificates. In Section 8.2.2, the issuer of pseudonym certificates includes information linking the certificate to the user s identity. Liab Z X is the liability taken by the certificate issuer for the certified key(s). In case the certificate is of type CERTREQ, the issuer (signer) of a certificate request is the user requesting the certificate, and Liab Z X is the liability of the user for the public key on which he requests a certificate of type CERT. In that same case, LiabReq Z X may indicate the desired liability in the requested certificate; and CertrKeyReq Z X indicates the desired issuing public key (and implicit issuer s identity) of the requested certificate. Mapping the certificates and certificate requests defined in this chapter to this new notation is straightforward. We illustrate with the mapping for the certificates and certificate requests of Section 5.4: Cert S maps to Cert I S = S I (CertdKeys I S, Attrs I S ) Cert P maps to Cert P S P = S P S (CertdKeys P S P, Attrs P S P ) CERT REQ maps to Cert S P = S S (CertdKeys S P, Attrs S P ) and CertdKeys I S = {SPKey =PK S } Attrs I S = {CertTp = CERT, Liab = L I S,...} CertdKeys P S P = {SPKey =PK P } with... standing for any other attributes contained in Cert S.attrs S Attrs P S P = {CertTp = CERT, Liab = L PS P,...} CertdKeys S P = {SPKey =PK P } with... standing for any other attributes contained in Cert P.attrs P Attrs S P = {CertTp = CERTREQ, LiabReq = L PS P, CertrKeyReq =PK P S,...} with... standing for any other attributes contained in CERT REQ.attrs P

Chapter 6 An Anonymous Credential System Preamble Anonymous credential systems allow anonymous and unlinkable attribute authentication; the feature of unlinkability of transactions with the same credential makes them ideally suited for achieving securely authorized transactions which are anonymous and unlinkable. In addition, Idemix features of conditional re-identification by trusted parties allow to fulfill any requirements of accountability. In this chapter, we introduce the Idemix protocols and prototype; we show, with an application scenario, how the Idemix prototype supports anonymity and unlinkability in secure transactions based on attribute-based authorization. In subsequent chapters, we will use the Idemix system as an advanced example of an anonymous credential system for designing anonymous yet accountable applications. In Chapter 7, we take a rigourous approach towards such a design by defining authentication, accountability and unlinkability features of the various Idemix protocol building blocks, and using these features to design applications based on their authentication, accountability and unidentifiability requirements. In Chapters 8 and 9, some Idemix-based applications are compared with similar certificate-based ones. This chapter contains the following paper [33]: J. Camenisch and E. Van Herreweghen. Design and implementation of the Idemix anonymous credential system. In Proc. 2002 ACM Conference on Computer and Communications Security, pages 21 30. ACM Press, 2002. The notation of keys in this chapter differs from the new notation introduced in the previous chapter s Postscript (Table 5.1). The type and use of keys is, however, clear from the context. (PK X, SK X ) is a key pair belonging to organization O X ; O I is an issuing organization and its key pair (PK I, SK I ) corresponds to (IPKey OI, ISKey OI ) in our new notation; O V is a verifying organization and its key pair (PK V, SK V ) corresponds to (VPKey OV, VSKey OV ); and O D is a de-anonymizing organization whose key pair (PK D, SK D ) corresponds to (DPKey OD, DSKey OD ). 103

104 Chapter 6. An Anonymous Credential System

Design and Implementation of the Idemix Anonymous Credential System Abstract Anonymous credential systems [39, 36, 40, 49, 86] allow anonymous yet authenticated and accountable transactions between users and service providers. As such, they represent a powerful technique for protecting users privacy when conducting Internet transactions. In this paper, we describe the design and implementation of an anonymous credential system based on the protocols developed by Camenisch and Lysyanskaya [31]. The system is based on new high-level primitives and interfaces allowing reasoning about the protocols while hiding their diversity and complexity. The prototype was realized in java. We demonstrate its use and some deployment issues with the description of an operational demonstration scenario. 6.1 Introduction The protection of users privacy when performing Internet or web-based transactions is an important factor in the acceptance and use of Internet and web services. Solutions for minimizing release of personal information can be based on one of many proposed techniques for anonymizing the transport medium used between users and service providers, e.g., [97, 66, 100]. This may anonymize the user towards outsiders and, if desired, towards the service provider. Service providers may require authentication (e.g., for controlling access to resources) or accountability of users actions, in which case users need to prove their identity, or at least possession of a certificate or capability of a certain type. Such a certificate may contain a pseudonymous identity of the user, or contain only the necessary attributes required for accessing a certain service. However, when using certificates as defined by X.509 [74] or SPKI [54], or even certificates specifically constructed for conveying policy or authorization information as in the KeyNote [20] trust management system, different uses of the same certificate still remain linkable to each other. They can eventually identify a user through a combination of context and addressing information from one or a series of transactions. This linkability can be avoided by using an anonymous credential system (also called pseudonym system) [39, 36, 40, 49, 86]. In such a system, the organizations (service providers and credential issuers) know the users only by pseudonyms. Different pseudonyms of the same 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 him by a different pseudonym), without revealing anything more than the fact that the user owns such a credential. In this paper, we describe the design and prototype implementation of the credential system described by Camenisch and Lysyanskaya [31]. We describe the Idemix (short for identity mix) functionality using 105

106 Chapter 6. An Anonymous Credential System high-level primitives. These primitives allow reasoning about security and privacy features, while hiding the complexity of the cryptographic protocols, as well as the differences between actual protocols realizing the same primitive. We also developed additional functionality for service providers and credential issuers to configure and enforce resource access control and credential issuing decisions. This allows the use of the prototype as a vehicle in developing actual applications based on concepts of anonymous and attribute-based authentication and access control. After describing the functionality of the credential system protocols in Section 6.2, we describe in Section 6.3 the high-level primitives. Section 6.4 describes the architecture and implementation of the prototype implementing these protocols, as well as the additional modules developed to support easy configuration, creation, management and deployment of Idemix-based applications. The use of the prototype is demonstrated with an implemented scenario. Section 6.6 raises security and infrastructure management issues related to the deployment of Idemix. Section 6.7 states conclusions and lists future work. 6.2 Idemix Protocols, Pseudonyms and Credentials In this section we describe the functionality of the credential system. The basic protocols for issuing and showing credentials are described in Section 6.2.1; Sections 6.2.2 and 6.2.3 describe optional features of protocols and credentials. 6.2.1 Basic Credential Protocols The core of the Idemix system consists of the protocols described by Camenisch and Lysyanskaya [31]. This section describes these protocols in terms of parametrized primitives of which functionality can be easily explained and mapped to system interfaces. The entities in the system are users, who obtain and show credentials, and organizations issuing and verifying credentials. Another type of organization, de-anonymizing organization, is discussed in Section 6.2.3 1. Thus, a user U can obtain a credential C from an (issuing) organization O I ; and then show the credential C to another (verifying) organization O V. A credential is always issued on a pseudonym N under which U is registered with (or known by) the issuing organization O I. A credential may have certain attributes (attr). When showing a credential, the user can choose which of the credential s attributes shall be revealed. Pseudonym registration, credential issuing and credential verification are interactive protocols between the user and the specific organization. A user U has a (single) master secret S U, which is linked to all the pseudonyms and credentials issued to that user. Issuing and verifying organizations all have a public/private key pair. The organization issuing a credential uses its private key to generate the credential; the credential can then be verified using the issuing organization s public key, either by the user when receiving the credential, or later on by any organization to which the user shows the credential. When showing a credential, the user uses the public key of the verifying organization which, in turn, needs its private key in the protocol. Obtaining a credential from O I and showing it to O V works as follows (cf. Figure 6.1). First, U constacts O I and establishes a pseudonym N with O I. If O I agrees to issue a credential on pseudonym N with an attribute attr, O I produces a credential C by signing a statement containing attr and N and sends C to U. Now U can to show this credential to O V. That is, using a zero-knowledge proof, U convinces O V of (1) possessing a signature generated by O I on a statement containing attr and N, and (2) knowing the master secret key S U related to N. We stress that U does not reveal any other information to O V. In particular, U does not send O V the actual credential. This way of showing a credential together with the zero-knowledge property of the proof ensures the unlinkability of different showings of a credential and 1 In the remainder of the text, organization is used for credential issuing and/or verifying organizations. Unless explicitly mentioned, it does not include de-anonymizing organizations.

6.2. Idemix Protocols, Pseudonyms and Credentials 107 U (S U ) cred(n, O I, attr) O I (PK I, SK I ) show(o I, attr ) O V (PK V, SK V ) Figure 6.1: Basic Credential System Protocols also the unlinkability of a showing of a credential to the pseudonym to which the credential was issued. This means that U can show C to O V (or any other verifier) an unlimited number of times, without these credential shows becoming linkable to each other or to a pseudonym. (Exceptions are one-show credentials, which are discussed in Section 6.2.2). This unlinkability is maintained even if O V and O I are the same organization (or pool their data). Note that from this unlinkability property it follows that the user is anonymous towards the verifying organization. Of course, this property of the pseudonym system can only provide real anonymity to the user if the communication channel used for the credential showing protocol supports anonymity [35, 66, 97, 100]. While, in general, this approach to showing a credential is not very efficient, the special signature scheme used by the credential system [31] allows for an efficient realization of the zero-knowledge proof described above. In fact, the computational complexity for both the user and the verifying organization executing the protocol for showing a credential corresponds to generating a small number of signatures in the standard RSA signature scheme. As all of a user s credentials are linked to his master secret, sharing a credential would imply also giving away one s master secret, users are discouraged from sharing their pseudonyms and credentials. Additional discouraging measures have been proposed, such as PKI-assured non-transferability. That is, sharing a credential implies also sharing a particular, valuable secret key from outside the system (e.g., the secret key that gives access to the user s bank account) [53, 65, 86]. However, such a valuable key does not always exist. An alternative, novel way of achieving this is all-or-nothing non-transferability, as described by Camenisch and Lysyanskaya [31]. Here, sharing just one pseudonym or credential implies sharing all of the user s other credentials and pseudonyms in the system, i.e., sharing all of the user s secret keys inside the system. Using the so-called Fiat-Shamir heuristic [57], the protocol for showing a credential can also be turned into a signature scheme. The meaning of a signature will then be a person possessing a credential issued by O I has signed this message. Both all-or-nothing non-transferability as well as the signature functionality will only be implemented in a future version of the prototype. 6.2.2 Credential Options and Attributes Credentials can have options (such as one-show, or multi-show) and attributes. The one-show credentials incorporate an off-line double-spending test [37]: when showing a one-show credential twice (to the same or different organizations), this results in show transcripts which, when given to the issuing organization,

108 Chapter 6. An Anonymous Credential System show(o I, attr, EV D (N)) U (S U ) O V (PK V, SK V ) de-anonymize(transcript) N O D (PK D, SK D ) Figure 6.2: De-Anonymization identify the pseudonym N on which it was issued. Examples of credential attributes can be an expiration date, the user s age, a credential subtype. When showing a credential, the user can choose which attribute(s) to prove something about, and what to prove about them. E.g., when showing a credential that has attributes (exp-date = "2002-05-19", age = 55), the user can decide to prove only that age > 18. 6.2.3 Parameters of the Show Protocol De-Anonymizible Show of a Credential De-anonymization mechanisms allow to reveal the identity of a user (global de-anonymization, also called global anonymity revocation) or to reveal a user s pseudonym with an issuing organization (local deanonymization or local anonymity revocation). Global de-anonymization allows for global accountability of transactions (e.g., for identifying a user performing illegal transactions); local anonymity revocation can be applied by the issuing organization to take measures when a user misuses his credential. Both types of de-anonymization are optional and require U s cooperation when showing a credential. They require the existence of a designated third party, a de-anonymizing organization O D (see Figure 6.2). O D has a public-private encryption-decryption key pair (PK D, SK D ). Using this variant of the show protocol, U encrypts N with O D s public encryption key. This encryption is verifiable (denoted EV D (N)), which means that O V has proof that O D can decrypt and reveal the relevant N from O V s show protocol transcript. There may be several de-anonymizing organizations in the system, from which U may be able to choose. By including also a de-anonymization condition, U can decide under which condition he consents to the transcript being de-anonymized. Later, when deemed necessary by O V, O V can send the transcript to O D. O D can then decide whether this condition is fulfilled and, if so, de-anonymize the transcript and return N (local de-anonymization). Global de-anonymization uses essentially the same technique. It requires, in addition, the existence of a special credential issuing organization, a Root Pseudonym Authority, which only issues credentials on pseudonyms of which it knows the mapping with a real user identity. A user typically has one pseudonym (root pseudonym) with the Root Pseudonym Authority, and one credential (root credential) on that root pseudonym (additional pseudonyms or credentials with the Root Pseudonym Authority would anyway be linkable to the user). Showing a Credential Relative to a Pseudonym Using this option, U, who has obtained a credential C by O I on N I, and who is known under pseudonym N V to O V, proves possession of C to O V, while also proving that the pseudonym to which C was issued

6.3. Credential System Primitives 109 belongs to the same user as does N V. More precisely, the user proves that the same master secret key S U that is linked to N V is also linked to the credential C and the pseudonym (N I ) the credential C is issued on. This option is mandatory for U to convince O V of possession of several credentials. Without using the option, two users each possessing a different credential could each show their credential to O V and fool into believing that it talked to a single user possessing both credentials. O V Furthermore, this option is also mandatory if showing of a credential is a precondition for a user to get another credential. Let us assume that U wants to obtain a credential from O V I ; O V I, in order to issue such a credential, requires U to show a credential by O I. If U has such a credential, he first registers a pseudonym N V I with O V I, and then shows the credential issued by O I to O V I, upon which O V I considers the precondition to be satisfied and issues the new credential on N V I. If U has no such credential, he can try to collaborate with U (who does own the credential) by asking U to perform the second step (showing the credential from O I to O V I ). And indeed, if O V I does not require U to show the O I credential relative to a specific pseudonym, U will obtain the credential from O V I without fulfilling the precondition. By requiring to show the O I credential relative to N V I, O V I enforces that the same user who showed the O I credential gets the new O V I credential. 6.3 Credential System Primitives In this section, we start out by describing representations for pseudonyms and credentials, and then define representations of credential attributes and protocol options. Subsequently, we describe the high-level primitives of the pseudonym system. 6.3.1 Pseudonyms A pseudonym N of user U with O I cannot be mapped to a data representation shared by U and O I : U has a secret value (other than the user s master secret) attached to each pseudonym N knowledge of this secret value is required to make any operation with pseudonym N, such as obtaining a credential. Thus, an implementation of the credential system needs different representations (or data types) for a pseudonym, depending on the role of the actor (user or organization). Let Nym(N, Ns, U, O, X) represent a pseudonym of user U, registered with O. N is common to U and O and uniquely identifies the pseudonym to both U and O. Ns is the secret value associated by the user with the pseudonym. X is a statement or set of statements which O attaches to N: information obtained during registration (e.g., a real user identity in the case of root pseudonym registration) as well as up-to-date information about credentials issued to N. 2 Nym(N, Ns, U, O, X) thus expresses a relationship between two sets of information: UserNym(N, Ns, O), and OrgNym(N, X). 3 Note that the user s master secret S U, though essential in using the UserNym, is common to all a user s pseudonyms and is not considered part of the U sern ym representation. Note also that the statement X is application-specific, and is not explicitly supported by the core of the pseudonym system as it is introduced in Section 6.4. O does not authenticate to U during pseudonym registration. While this is not a security threat, as the registration does not reveal any information about U, S U or Ns, the registration of a pseudonym with 2 Nym(N, Ns, U, O, X) is the equivalent of following statement: The value N is known by U and O to be a valid pseudonym according to the credential system specification. This means that there has been a pseudonym registration procedure between U and O, during which both U and O contributed to the value of the pseudonym, and during which O verified that N is based on a well-formed secret S U. During that registration procedure, O associated X with N. U s contribution is linked to U s master secret S U as well as to the new pseudonym-specific user secret Ns in a way that credentials issued on N are linked to these secrets. 3 The term DataType(Field1, Field2,...) informally defines the contents of a data set of type DataType.

110 Chapter 6. An Anonymous Credential System an O impersonator can lead to denial of service when U then tries to obtain a credential on N from O. For this and other reasons discussed in Section 6.6, we assume every O to have a certificate with which to authenticate communication with users. 6.3.2 Credentials Also for a credential, we need a different representation at the user than at the organization side: when a credential C is issued by O I on N, user and organization get to store different values associated with it. Cred(N, Ns, U, O I, C, T ) represents a credential, issued by organization O I on pseudonym N of user U. T represents the credential s type (CredentialInfo), including the specific issuing key (PK I ) options and attributes: CredentialInfo(PK I, MultiShow, Expiration, Subtype, Age,...). Using a similar reasoning as for pseudonyms, Cred(N, Ns, U, O I, C, T ) expresses a relationship between UserCred(UserNym, C, T, O I ) and OrgCred(OrgNym, T ). 6.3.3 CredShowFeatures The parameters of a credential showing are expressed in a CredShowFeatures parameter array. The parameter RelNym indicates whether the show is relative to a pseudonym known to the verifying organization (in which case an additional argument N V of the credential show will indicate this pseudonym). The parameter PK V contains the public key of the verifying organization 4. The other parameters contain de-anonymization information specifying whether, under which condition and by which de-anonymization organization O D (or which public key PK D ) the show transcript will be de-anonymizable (local or global de-anonymization): CredShowFeatures(RelNym, PK V 4, [PK D, ConditionLocal], [PK D, ConditionGlobal]) 6.3.4 Protocol Primitives We can now describe the basic protocol primitives for registering pseudonyms, issuing and verifying credentials, verifying doublespending of one-show credentials, and de-anonymizing. Primitives invoked by a user (respectively org, de-anonymizing org) carry the prefix User (Org, DeAnOrg). Not all of the CredentialInfo T associated with a credential is proved upon a credential showing: the CredentialInfo parameter in the UserShowCredential() and OrgVerifyCredential() primitives specifies what exactly is proved or verified during a credential show; this CredentialInfo parameter (say, T ) need not be the same as the CredentialInfo parameter (T ) that is part of the UserCred. T expresses what the caller wants to prove about specific attributes in T : T is probably determined by a requirement from the verifying organization. For specific attributes, T can specify an interval or range instead of an exact value. E.g., if T.age = 55 and T.age = >18, then the show protocol will only prove T.age to be >18. Before executing the show protocol, the calling application can verify whether canfulfill(t, T ) holds. The identifier of the targeted organization (O I, O V ) in the user primitives is not listed as parameters in UserRegister(), UserGetCredential() and UserShowCredential(): it is assumed that the application calling the user primitives has set up a communication channel with the correct organization, using addressing information obtained at application level. The organization (Org) versions of these primitives result in a Transcript of the protocol which, among the cryptographic transcript and other application data, includes also the newly established OrgNym or 4 PK V was (erroneously) absent in Camenisch and Van Herreweghen [33].

6.4. The Idemix Prototype 111 OrgCred. The calling application is responsible for extracting this information and store it in appropriate persistent storage. The de-anonymization primitive does not check the condition for de-anonymization (which is included in the transcript to be de-anonymized): this is assumed to be the application s responsibility. Registration UserRegisterNym(UserSecret) returns UserNym OrgRegisterNym() returns Transcript (including OrgNym) Credential Issuing UserGetCredential(UserSecret, UserNym, CredentialInfo) returns UserCred OrgIssueCredential(OrgKeys, OrgNym, CredentialInfo) returns Transcript (including OrgCred) Credential Showing UserShowCredential(UserSecret, UserCred, CredentialInfo, CredShowFeatures, [UserNym]) returns void OrgVerifyCredential(OrgKeys, CredentialInfo, CredShowFeatures, [OrgNym]) returns Transcript Verifying Doublespending OrgVerifyDoubleSpending(OrgKeys, Transcript, Transcript) returns OrgNym De-Anonymizing DeAnOrgDeAnonymize(DeAnOrgKeys, Transcript) returns OrgNym Additional primitives, such as for generating parties key pairs and master secrets (and extracting the public information from them), are described in the next section. 6.4 The Idemix Prototype In this section, we describe design and implementation (java) of the Idemix prototype. The core of the Idemix system is the NymSystem package as described by Bove [25] implementing the UserNymSystem, OrgNymSystem 5 and DeAnOrgNymSystem components in Figure 6.3. Each of these components offers functionality related to the specific cryptographic operations executed by the different entities, as well as methods to create a new instance of the entity by generating cryptographic key material (user master secret, organization s public/private key pair, de-anonymizing organization s public/private encryption key pair). The following paragraphs shortly discuss the different interfaces. 5 NymSystem does not distinguish between verifying and issuing organizations. A distinction can be made only by not enabling an organization to issue credentials using the RequestGranter (Section 6.4.6) functionality.

112 Chapter 6. An Anonymous Credential System User App Org App DeAnOrg App User Persistent UserSync NymSystem Org Persistent OrgSync NymSystem DeAnOrg Persistent User NymSystem Comm Org NymSystem Comm DeAnOrg NymSystem Comm User Protocol Org Protocol Figure 6.3: User, Org, and DeAnOrg Components 6.4.1 OrgNymSystem and UserNymSystem Token-Based Interfaces UserNymSystem and OrgNymSystem contain the user and organization s methods to compose and analyze the cryptographic tokens exchanged in the nym registration, credential issuing and credential show protocols. OrgNymSystem, in addition, contains a method for verifying whether two show transcripts result from the doublespending of a one-show credential, and if so, extract the pseudonym the credential was issued on. It is the calling application s responsibility to call this method when deemed appropriate. Each of the interactive user-organization protocols is implemented by a user (in UserNymSystem) and organization (in OrgNymSystem) state machine (encapsulated in a UserProtocol or OrgProtocol) which the calling application initializes (e.g., initregprotocol) and can then drive using the state machine s getnextmsg() method (processes an incoming message passed as parameter and returns the next outgoing message) and a communication channel. Newly established pseudonyms or credentials can be retrieved from the respective state machines: a new OrgNym or OrgCred can be retrieved from OrgProtocol; a new UserNym or UserCred can be retrieved from UserProtocol. The advantage of this token-based interface is that the protocols can be used asynchronously or in non-interactive or signature mode (not yet implemented). For easier programming of synchronous applications, synchronous interfaces (UserSyncNymSystem and OrgSyncNymSystem) (see Section 6.4.2) were implemented hiding the protocol state machines and the transport of cryptographic tokens from the calling application. The NymSystem library is stateless and consists of static methods: i.e., the calling application is responsible for providing all the cryptographic information (including system parameters, such as key lengths, and the actual key material) when calling the library methods 6. E.g., when a user master secret is generated using createuser(), the result (UserNymSysData) contains the master secret as well as the system parameters, and is a parameter to any of the cryptographic protocols. For ease of application programming and to avoid repeated file access for key material by UserApp and OrgApp, we gave the synchronous extensions in Section 6.4.2 a non-persistent state: the classes implementing them contain static variables with handles to system parameters and key material. The organization s public key can be extracted from the OrgNymSysData (and distributed to users upon system setup or update). 6 This differs slightly from the earlier version described by Bove [25], where NymSystem was parametrized with file locations of secret keys.

6.4. The Idemix Prototype 113 6.4.2 UserSyncNymSystem and OrgSyncNymSystem Synchronous Interfaces The token-based interfaces of UserNymSystem and OrgNymSystem leave the task of driving the protocols to the calling application. It is also the calling application s responsibility to communicate the metainformation that allows user and organizations to initialize their respective protocol state machines; e.g., it is up to the calling user application to communicate to the organization which kind of credentials and with which options/features it wants to prove possesion of, or what type of credential or data it wants to get. To enable easy programming of synchronous applications on top of this token-based interface, the synchronous interfaces (Figure 6.4) UserSyncNymSystem and OrgSyncNymSystem take care of the signalling of meta-information as well as of driving the protocol state machines. They require the respective User- App and OrgApp to pass a communication (ClientCommSession, ServerCommSession) object. This allows the calling application to decide whether to create a new communication session for the exchange, or to re-use a communication channel in use by the application; it also allows the calling application to decide which protocols are run within the same communication session. This allows maximal flexibility when hooking Idemix as an authentication mechanism into an existing application. 6.4.3 DeAnOrgNymSystem As a de-anonymizing organization s DeAnOrgNymSystem does not carry out interactive protocols, and may be operating in batch or asynchronous mode, it only has an asynchronous interface (Figure 6.4) that provides methods for creation, and for de-anonymizing a transcript. Also here, the public key in DeAnOrgNymSysData (resulting from the createdeanorg()) can be extracted in order to be distributed to users. 6.4.4 Communication ClientCommSession and ServerCommSession are defined as interfaces, offering generic read and write methods, implemented by the communication objects passed by the calling application. Use of encrypted or authenticated channels (e.g., using SSL) is allowed but not mandatory; the security of the communication channel is discussed in more detail in Section 6.6. Our prototype SSLClientCommSession and SSLServerCommSession implementation of these interfaces use a proprietary java SSL implementation. Organizations address and SSL information is part of the public information created by an organization s initialization program, distributed to the users and stored in the users persistent storage (see Section 6.4.5 ). Communication is authenticated (organization to user) and encrypted, and the user can check the certificate using the getpeercertificate() method of the SSLClientCommSession. 6.4.5 Persistent Data Storage Credentials, pseudonyms, master secrets, organizations keys, system parameters, and address information have to be stored persistently to have a workable prototype. We defined interfaces allowing the various entities to store and retrieve this information. These interfaces, the search keys used for retrieving information about credentials, organizations, pseudonyms etc., and how the persistent information is organized (one or several databases, password-protection, etc.) ultimately depend on how the application will use the system, and are not the focus of this work. Each of the interfaces used in our prototype (UserPersistent, OrgPersistent, DeAnOrgPersistent) combine access methods to the appropriate data sets for each entity. The example scenario in Section 6.5 illustrates how our example applications use the persistent data.

114 Chapter 6. An Anonymous Credential System A. Token-Based User and Org NymSystem Interfaces UserNymSystem createuser(systemparameters): UserNymSysData initregprotocol(usernymsysdata): UserProtocol initcredprotocol(usernymsysdata, UserNym, CredentialInfo): UserProtocol initshowprotocol(usernymsysdata, UserCred, UserNym, CredentialInfo, CredShowFeatures): UserProtocol OrgNymSystem createorg(systemparameters): OrgNymSysData initregprotocol(orgnymsysdata): OrgProtocol initcredprotocol(orgnymsysdata, OrgNym, CredentialInfo): OrgProtocol initshowprotocol(orgnymsysdata, OrgNym, CredentialInfo, CredShowFeatures): OrgProtocol checkdoublespending(orgnymsysdata, Transcript, Transcript): OrgNym UserProtocol retrieveusernym(): UserNym retrieveusercred(): UserCred getnextmsg(string): String issuccessful(): boolean geterrormsg(): String OrgProtocol retrievetranscript(): Transcript getnextmsg(string): String issuccessful(): boolean geterrormsg(): String B. Synchronous User and Org NymSystem Interfaces UserSyncNymSystem createuser(systemparameters): UserNymSysData initializeuser(usernymsysdata): void registernym(clientcommsession): UserNym getcredential(clientcommsession, UserNym, CredentialInfo): UserCred showcredential(clientcommsession, UserCred, UserNym, CredentialInfo, CredShowFeatures): void OrgSyncNymSystem createorg(systemparameters): OrgNymSysData initializeorg(orgnymsysdata): void handleregrequest(servercommsession, ServiceRequest): Transcript handlecredrequest(servercommsession, ServiceRequest): Transcript handleshowrequest(servercommsession, ServiceRequest): Transcript C. DeAnOrg NymSystem Interfaces DeAnOrgNymSystem createdeanorg(systemparameters): DeAnOrgNymSysData deanonymize(deanorgnymsysdata, Transcript): OrgNym Figure 6.4: User, Org and DeAnOrg Token-Based and Synchronous Interfaces

6.4. The Idemix Prototype 115 OrgSyncNymSystem OrgRequestProcessor handleextresourcerequest() handleshowrequest() handlecredrequest() handleregrequest() handleshowextrequest() RequestGranter isgrantedextresourcerequest() isgrantedcredrequest() isgrantedshowrequest() isgrantedregrequest() geterrormessage() isgrantedshowextrequest() isfulfilledextcondt() MyRequestProcessor handleextresourcerequest() handleshowextrequest() MyRequestGranter isfulfilledextcond() MyOrgPersistent MyOrgPersistent() OrgSession addtranscript() OrgApp main(args : String[]) : void Figure 6.5: An Organization Application 6.4.6 Building Applications: Granting and Processing Requests When building real applications, we have to link application with the NymSystem. As granting requests for credentials or data can both depend on whether a user has priorly shown one or several credentials, granting and processing of credentials and other resource requests are both treated here as actions dependent on access control conditions. In this section we give an overview of how we defined the rules governing the organizations access control conditions, and how we defined the modules granting and processing service requests. This was done in such a way that they can be tailored to a specific application, and that processing conditions and resources not known to the Idemix system can be added and linked to the Idemix-specific ones. In the following discussion, we refer to Figure 6.5, where OrgApp stands for an organization application receiving and processing requests. MyOrgPersistent allows OrgApp to store and retrieve its key material OrgNymSysData (input parameter to OrgSyncNymSystem methods), to the organization s Rules (input parameter to the RequestGranter), to the organization s Transcripts file (where the credential protocol transcripts, resulting from the OrgRequestProcessor, are stored persistently). An OrgApp may have one or more OrgSession threads which accumulate the Transcript information on a specific communication session with a user.

116 Chapter 6. An Anonymous Credential System Organizations Access Rules An organization has to specify which condition or conditions a user has to fulfill in order to get access to data or to get a credential. A Condition can require to show a credential: ShowCondition(CredentialInfo, CredShowFeatures) expresses what type of credential U needs to show, and using which options or parameters. It can be used by UserApp and OrgApp to parametrize a NymSystem credential show. Alternatively, a Condition can be an Idemix-external fact, expressed in an ExternalCondition: Condition(ShowCondition ExternalCondition) The format of an ExternalCondition is defined by the application, and its fulfillment is verified using an application-provided method (see RequestGranter and extensions in the following paragraphs). E.g., an OrgApp may grant an anonymous newspaper subscription credential based on a (non-anonymous) proof of credit card payment. The checking of this proof is a condition out of the scope of Idemix and has to be implemented by the application programmer in an extension of the RequestGranter class. An organization Rules set is a collection of Rule entries relating to Conditions on resources. A ResourceDescription can describe a credential or an external resource ([] is used as an array notation); an external resource (ExternalResource) has an application-defined format. Granting a pseudonym or verifying a proof are currently defined to be unprotected resources (no access control conditions attached); the ResourceDescription could easily be extended to make also these requests subject to conditions. Rules(Rule[]) Rule(ResourceDescription, Condition[]) ResourceDescription(CredentialInfo ExternalResource) In an operational system, rules and conditions can be communicated dynamically (as a result of a resource request) from OrgApp to UserApp; or it can be part of the organization s publicly distributed information (e.g., the organization s certificate) and stored by the users (as described in Section 6.4.5). They parameterize the granting decision of the organization s RequestGranter (Section 6.4.6). RequestGranter An extendable RequestGranter class contains default implementations of the methods that grant different requests. Calls to the RequestGranter class are parametrized with the Rules set, the persistent Transcript storage (Which credentials did the user owning this nym show in the past?) and with non-persistent OrgSession storage (Which credentials did the user show in this session?) The default RequestGranter cannot evaluate ExternalConditions and will consider them unfulfilled by default. An application can provide additional methods in its own extension of RequestGranter (MyRequestGranter in Figure 6.5), overriding the isfulfilledextcond() method of RequestGranter. OrgRequestProcessor A default OrgRequestProcessor module, extending OrgSyncNymSystem, deals with incoming requests and extracts the appropriate arguments for the OrgSyncNymSys methods. This default OrgRequest- Processor does not know how to handle application-specific resource requests or requests that deal with fulfilling an ExternalCondition (e.g., showing a credit card receipt). An application-specific extension (MyOrgRequestProcessor) can override the (by default failing) handleextresourcerequest() and handleshowextrequest() methods.

6.5. An Example Scenario: An Anonymous Subscription to the New York Times 117 6.5 An Example Scenario: An Anonymous Subscription to the New York Times In this section, we demonstrate the use of the prototype by user and organization applications. We define four organizations: a Root Pseudonym Authority (PA), a bank (ARGENTIX), the New York Times news subscription service (KIOSK), and the New York Times news service (NYT). NYT serves items in its cartoons section only upon verification of a subscription credential issued by KIOSK; KIOSK, in turn, issues such a credential upon verification of a (one-show) $10 credential; ARGENTIX issues such a credential based on proof of an (non-anonymous, Idemix-external) payment, combined with the verification of a PA root credential. PA unconditionally grants root pseudonyms and credentials (In a more realistic scenario, a user could be required to show an external certificate when registering a root credential, as discussed in Section 6.6.4). 6.5.1 Creating and Configuring the User and Organizations A demo setup program uses the NymSystem user and organization creation facilities to create one user and four organizations. It assigns IP addresses and port numbers to the four organizations, as well as SSL Certificates which are created using the KeyMan [79] PKI management tool. It also creates rules for the three organizations (see below). The initialization program creates persistent data sets for each of the four entities, and initializes each of the organization s data sets with its own OrgNymSystemData key material. The user s data set is initialized with the user s UserNymSysData key information, as well as all the organizations public information (Idemix public key, addresses, SSL certificates, rules). PA and KIOSK use the default RequestGranter and OrgRequestProcessor as they do not deal with ExternalConditions or ExternalResources; ARGENTIX implements its own ArgentixRequestGranter defining the verification of the credit card receipt; NYT, finally, implements its own NYTRequestProcessor with handleextresourcerequest() mapping a resource request (URL) into the actual contents of a web page. 6.5.2 User Credential Manager and Browser Plug-In Based on the Idemix prototype, Mathys [89] describes the design and implementation of a Credential Manager implemented as a plug-in to a WBI [122] browser proxy. Figure 6.6 shows an instance of the Credential Manager in a scenario with the four organizations initialized as described above. This Credential Manager popped up after a user entering a http://www.nyt.com/cartoons URL in his browser URL window. The Credential Manager then allows the user to view the relevant condition tree applying to the request, the conditions for which he has the necessary credential or external proof (tick-off symbol) and the credentials he already owns in his credentials purse. E.g., he already has a credential from PA. The two conditions by ARGENTIX are related to (1) a ShowCondition: showing the credential from the PA, and (2) an ExternalCondition giving a reference to a credit-card payment. This reference is implemented by, e.g., a serial number of the payment. The ExternalCondition shows up in the condition tree; but as the payment reference is not an Idemix credential, there is no corresponding credential in the credentials purse. When clicking on a condition in the tree, the details are shown in the selected condition window, e.g., the KIOSK requires a one-show credential (multi-show = false) issued by ARGENTIX with subtype = 10. It also allows the user to chose local identifiers (e.g., kiosknym ) for the pseudonyms he establishes with the different organizations, and to GET and SHOW credentials. After fulfilling all the conditions, the requested contents (cartoons page) show up in the browser window.

118 Chapter 6. An Anonymous Credential System condition tree nym identifier selected condition credentials purse Figure 6.6: UserCredential Manager 6.6 Deployment Considerations In this section, we discuss some issues related to the deployment of Idemix. 6.6.1 Idemix as a Generic Attribute-Based Authentication System The organization s request-granting and request-processing infrastructure as described in Section 6.4.6 merely serves as an example of how access to resources can be configured in a prototype application environment. Idemix, as an attribute-based authentication system, can be hooked into any attributebased access control system, by using the output parameters of Idemix credential-show protocols as input into the access control system s access decision engine. 6.6.2 The Role of Authenticated Communication in Linking Transactions Based on Idemix Authentication Authenticated communication (e.g., using SSL server authentication) allows users to authenticate organizations with which they register a pseudonym, to which they show a credential or from which they obtain a credential. When several protocol executions (including application-level resource requests) are linked by an authenticated communication channel, this also allows servers to securely link Idemix authentication (who showed the correct credential) with the resource granted (who gets the data). 6.6.3 Deploying Idemix as a Privacy-Enhanced Public-Key Infrastructure with External Certification In an operational system, public information about organizations (whether or not regularly updated) needs to be certified: users need authenticated information about where to get or show a credential,

6.7. Conclusions and Future Work 119 what is the Idemix public key of an organization, and what is its SSL certificate. Also, a real Root Pseudonym Authority can only guarantee total accountability (global anonymity revocation) if a user s real-world information was authenticated upon registering the root pseudonym. A deployment environment using Idemix credentials as a (privacy-enhanced) Public-Key Infrastructure needs to provide hooks for an external Public-Key infrastructure (PKI). In this external PKI, users and organizations have public-key certificates issued by a Certification Authority. We call this authority Certifix, although it may be an existing Certification Authority; the only requirement being that it can issue organizations Idemix certificates certifying the whole set of an Idemix organization s authenticated information. Depending on implementation and deployment choices, such an organization s Idemix certificate may contain Idemix keys, address and SSL information, and access rules. Users also have Certifix certificates and use them to authenticate real-world information during root pseudonym registration. 6.6.4 Infrastructural Issues: User Registration and Organization Updates In a real deployment environment, users and organizations dynamically join the system, and organizations may periodically update public information such as rules, public keys, addresses, or SSL information (their Idemix certificates). A user joining the system may not only need to authenticate using his real-world certificate when registering a root pseudonym with the root pseudonym authority; he may also have to prove registration (or payment of a license). This may be realized by the Root Pseudonym Authority checking an additional condition. Also, organizations Idemix certificates need to be distributed and updated in an efficient way. A separate InfoServer entity may serve as a central repository for up-to-date organizations Idemix certificates. Organizations post their Idemix certificates to the InfoServer; a certificate update may update whole or part (e.g., only new rules set) of an organization s Idemix information. Revocation issues may be dealt with by Certificate Revocation Lists (CRLs) issued by the InfoServer; or avoided by issuing short-lived Idemix certificates. 6.7 Conclusions and Future Work In this paper, we have presented the design and implementation of the Idemix anonymous credential system. The high-level primitives that were introduced to define the system s interfaces are easy to use and understand, and easy to extend to include new options and features. We also presented an example infrastructure for applications to exploit Idemix authentication in an access control infrastructure. The Idemix system as implemented and presented here, does not yet include features such as all-ornothing non-transferability, or use for signature generation. Since then, the NymSystem library was modified to allow for signature generation. As of today (mid-2004), all-or-nothing transferability is not yet implemented. Deployment of Idemix as a privacy-enhanced PKI also requires features supported by the core NymSystem, such as changing of organizations public Idemix keys, or for efficient revocation of credentials. We are currently developing the protocols supporting these features.

120 Chapter 6. An Anonymous Credential System Postscript This chapter discussed the design and implementation of the Idemix anonymous credential system. I have not contributed to the development of any of the Idemix protocols. One main contribution has been the capturing of these complex interactive protocols with many protocol variants and long parameter lists in a limited number of easy-to-understand service primitives with few parameters and options, each of which may call any of a number of protocol variants or sub-protocols. These results have also influenced compact descriptions of credential types and credential show options in a later protocol specification [30]. I also designed the Idemix prototype, including the application scenarios and the organization access control logic (Rules, RequestGranter, OrgRequestProcessor), and coordinated and participated in its implementation.

Chapter 7 Designing Applications Using Idemix Anonymous Credentials 7.1 Introduction In this chapter, we design applications using Idemix anonymous credentials, based on security and privacy requirements from organizations and users. The interfaces to the Idemix system were already introduced in the previous chapter. In this chapter, we focus on a description of the Idemix protocols that enables a reasoning about authentication, accountability and (un)linkability features of the protocols and of applications based on them. This will, in turn, facilitate the design of Idemix-based applications based on authentication (and authorization), accountability and unlinkability (and unidentifiability) requirements. The chapter is structured as follows. In Section 7.2, we first describe the Idemix interfaces in more detail. These are the basic primitives described in Chapter 6 as well as signed variants of nym registration. Signed nym registration procedures allow a user to sign a nym using a (non-idemix) signature key. They provide the basis for user accountability by generating evidence of the linking between a nym and the Idemix-external certificate of a user. Section 7.3 captures the result of each of the interactive protocols (nym registration, credential issuing and showing) in an assertion defining a relationship between both participating parties input and output values. E.g., an assertion about nym registration captures the following: After a successful run of a nym registration protocol between a user and an organization, their respective nym values are related to each other as well as to the user s secret. These assertions about the system s building blocks allow us to concisely describe an application consisting of Idemix interactive protocol invocations. We also specify which assertions are provable. Section 7.4 then specifies the result of local operations on transcripts (de-anonymization and double-spending detection) as a function of the assertions about the transcripts they are invoked on. We capture relationships such as: If a transcript is the result of a credential show protocol invocation with a local de-anonymization parameter set, then de-anonymization with the correct de-anonymization key will reveal the nym the credential shown was issued on. These local operations can produce transcripts with which the results of their correctness can be proved; we can thus define provable assertions also about the results of de-anonymization and double-spending detection. The definitions in Sections 7.3 and 7.4 thus allow us to reason about authentication (which credential was shown?) and provability (what can be proved with the various signatures and transcripts produced?) As a user s identity can be provably linked to a nym through the signed nym registration procedures, the provability of actions based on such a nym and on the credentials issued on it allows to fulfill requirements of user accountability. Section 7.5 re-visits the various protocols from the viewpoint of the user s unidentifiability and the 121

122 Chapter 7. Designing Applications Using Idemix Anonymous Credentials unlinkability of his actions; it examines which values (identities, nyms, credentials) become linkable by a user executing a certain protocol. By associating linkability assertions with individual Idemix protocol executions, we can then reason about the effect of a sequence of protocol steps on the linkability of a user s actions, and on the linkability between his actions and his identity. Section 7.6 completes the detailed description of the Idemix system by defining additional functions needed or helpful in describing real applications. These are additional implementations of global deanonymization, as well as functions such as revocation and certification. In Section 7.7, the previous detailed description of Idemix functionality is used to design an application. The example shows how the assertions described in Sections 7.2 to 7.5 can be used to design an application based on authentication and accountability requirements from organizations on the one hand, and unidentifiability and unlinkability requirements from users on the other hand. In Section 7.8, we discuss issues of trust related to user accountability and unidentifiability, accountability and liability of organizations, and certification. Section 7.9 concludes the chapter. 7.2 Primitives and Parameters of the Anonymous Credential System 7.2.1 Basic primitives In this section, we discuss in more detail the Idemix primitives introduced in Chapter 6. Figure 7.1 presents an overview of the protocol primitives. The various credential protocols and methods are illustrated using four participants: user (U ), credential issuer (I ), credential verifier (V ), and de-anonymizer (D). These participants represent the four possible roles that entities can take in the system (a special type of issuer, the Root Authority, is introduced in Section 7.2.3). An actual operational system may of course have multiple instantiations of each role; and some entities may take two roles at a time. E.g., the same organization can both issue and verify credentials. Nym registration, credential issuing and credential showing are interactive protocols, and are represented in Figure 7.1 by double-headed arrows with the main protocol output for each participant drawn above the corresponding end of the arrow (minor output parameters such as error or success codes are not represented). Deanonymization and double-spending detection are non-interactive, local operations (by D and I, respectively); the information (transcripts) on which they operate is obtained from the respective verifiers through any synchronous or asynchronous communication medium, represented by broken single-headed arrows. The protocols are briefly described in the next paragraphs; differences with the specifications in Chapter 6 are pointed out and motivated subsequently. Nym registration between U and I consists of U and I calling the respective primitives URegNym() and ORegNym(), resulting in I obtaining OrgNym UI and U obtaining UserNym UI. I issuing a credential to U consists of U and I calling UGetCred() and OIssueCred(), respectively, which results in U obtaining UserCred UI ; I has no real protocol output but a successful protocol execution provides him with the information that a credential of type CredInfo UI has been issued to OrgNym UI. When U shows a credential to V, U and V call UShowCred() and OVerifyCred(), respectively, resulting in V obtaining a Transcript UV of the show protocol. If the local or global de-anonymization option, with de-anonymizer D, was used as an option in the credential show, the verifier can send the transcript Transcript UV for de-anonymization to D. D then calls DODeAnonLocal(), revealing the nym OrgNym UI the credential was issued on, respectively DODeAnonGlobal(), revealing the user s nym OrgNym UR with a Root Authority (in case of global de-anonymization). When calling OCheckDblSp() on two transcripts (from V 1 and V 2, which can be the same or different verifiers) which result from showing the same one-show credential, the result reveals the nym on which the credential was issued. Camenisch and Lysyanskaya [31] describe both on-line and off-line double-

7.2. Primitives and Parameters of the Anonymous Credential System 123 Participants: U(ser), I(ssuer), V(erifier), D(eanonymizer) Nym Registration: U : URegNym() UserNym UI OrgNym UI I : ORegNym() Credential Issuing: U : UGetCred() UserCredUI I : OIssueCred() I stores {OrgNym UI, CredInfo UI} Credential Showing: Transcript UV U : UShowCred() V : OVerifyCred() DeAnonymization: Transcript UV V : D : DODeAnonLocal() D : DODeAnonGlobal() or Double-Spending Detection: Transcript UV1 V 1 : Transcript UV2 V 2 : I : OCheckDblSp() Figure 7.1: Anonymous Credential System: Overview of Basic Primitives spending detection. With on-line double-spending detection, every credential verification by V is checked for double-spending by I during the show protocol execution, i.e. the execution of the show protocol fails if the credential is double-spent. With off-line double-spending detection, the actual show protocol execution succeeds even if the credential is double-spent, and I verifies transcripts after the fact. Here, we have represented only off-line double-spending detection. Double-spending of a one-show credential results in two transcripts sharing a unique value. I only needs to call OCheckDblSp() on such matching transcripts if they indeed relate to the same credential, OCheckDblSp() reveals the nym of the doublespending user. Figures 7.2 and 7.3 then show the key material (user secret, public and private keys) used in the system, as well as the parameters and parameter contents of each primitive. For ease of reading, parameter instance and type names are distinguished only by subscripts, e.g., UserSecret U is U s parameter of type UserSecret; Comm UI is a parameter of type Comm used by U and I in the current protocol instance. [Par XY ] is an optional parameter of type Par used in a protocol execution between X and Y. DSKey, DPKey are a de-anonymization private and public key; ISKey, IPKey are an issuing private and public key; and VSKey, VPKey represent a verification private and public key. When a credential is issued, it is verified by the user receiving it; when it is shown, it is verified by another organization. In both cases, the public key of the issuing organization is necessary for verification; it is, however, not visible as an individual parameter as it is part of a larger parameter structure. In UGetCred(), the IPKey field in the CredInfo parameter contains the public credential issuing key needed by the user to verify the credential received. Likewise, in OVerifyCred(), the IPKey field in the

124 Chapter 7. Designing Applications Using Idemix Anonymous Credentials Key Material: U: UserSecret U, I: IssuerKeys I, V: VerifierKeys V, D: DeAnOrgKeys D Parametrized Primitives URegNym(Comm UI, UserSecret U) returns UserNym UI ORegNym(Comm UI) returns OrgNym UI UGetCred(Comm UI, UserSecret U, UserNym UI, CredInfo UI) returns UserCred UI OIssueCred(Comm UI, IssuerKeys I, OrgNym UI, CredInfo UI) returns void UShowCred(Comm UV, UserSecret U, UserCred UI, CredShowInfo UV, CredShowFeatures UV, [UserNym UV ], [Msg UV ]) returns void OVerifyCred(Comm UV, VerifierKeys V, CredShowInfo UV, CredShowFeatures UV, [OrgNym UV ], [Msg UV ]) returns Transcript UV DODeAnonLocal(DeAnOrgKeys D, Transcript UV ) returns OrgNym UI DODeAnonGlobal(DeAnOrgKeys D, Transcript UV ) returns OrgNym UR OCheckDblSp(IssuerKeys I, Transcript UV1, Transcript UV2 ) returns OrgNym UI Figure 7.2: Anonymous Credential System: Key Material and Parametrized Primitives Contents of Composed Parameter Types UserNym {OrgNym, UserNymSecret} CredInfo {IPKey, MultiShow, [Expiration], [CredAttrs]} CredAttrs {{AttrName, AttrValue},...} Transcript {CryptoTrscr, CredShowInfo, CredShowFeatures, [OrgNym], [Msg]} CredShowInfo {IPKey, MultiShow, [Expiration], [CredAttrs]} CredShowFeatures {RelNym, VPKey, [LocalDeAnData], [GlobalDeAnData]} LocalDeAnData {DPKey, DeAnCondition} GlobalDeAnData {DPKey, DeAnCondition} IssuerKeys {ISKey, IPKey} VerifierKeys {VSKey, VPKey} DeAnOrgKeys {DSKey, DPKey} Non-Cryptographic Primitive Types Expiration, AttrName, AttrValue, DeAnCondition, Msg MultiShow, RelNym String (null: none) Boolean Figure 7.3: Anonymous Credential System: Parameter Types and Contents

7.2. Primitives and Parameters of the Anonymous Credential System 125 CredShowInfo parameter (the use of this new parameter is explained in subsequent paragraphs) contains the public credential issuing key needed by the verifier to verify the credential shown. In both cases, it is up to the verifying party (the user receiving the credential, respectively the organization verifying the credential) to ensure that the public key in CredInfo or CredShowInfo indeed belongs to the issuer he expects the credential to be issued by; this can be done by matching the public key against the issuer s public issuing key certificate (see Section 7.6.3). Similarly, the user showing a credential needs the public verification key of the organization verifying the credential. This public key is part of the CredShowFeatures parameter of the UShowCred() primitive; it is the user s responsibility to verify the correctness of this key before invoking UShowCred(). The primitives parameters and their contents are fundamentally the same as discussed in Chapter 6. Following are some minor differences: In Section 6.3.4, we already discussed that expiration times or attributes that are (dynamically) shown or proved about a credential may include ranges of values, while the (static) expiration times or attributes of a credential are point values. Here, we have made this fact more explicit by the introduction of a new parameter type, CredShowInfo, which is used instead of CredInfo to express which of a credential s features are actually shown or verified in the UShowCred() and OVerifyCred() primitives. From an implementation perspective, we consider CredInfo to extend the CredShowInfo type by restricting ranges to point values; we can thus assign a variable of type CredInfo to a variable of type CredShowInfo. In Chapter 6, no explicit distinction was made between the key types for issuing and verification ( OrgKeys in the parameter lists of the respective primitives). Here, we make the description more general by introducing different key types; this does not exclude the use of the same key for both purposes by an organization both issuing and verifying credentials. As discussed in Chapter 6, the credential show protocol can be used to produce a signature, optionally over an additional message. In the following, we will assume this use of the show protocol, which will allow the verifier to prove the showing of a credential after the fact. We have provided for the signing of an additional message by modifying UShowCred() and OVerifyCred() to include an optional Msg argument, representing the message being signed. We will sometimes refer to the signing of a message as part of showing a credential as signing the message with the credential. In order to hide implementation details, we do not explicitly mention system parameters. It is assumed that all the parties in the system call the various primitives (including the primitives to initialize key material, which are not discussed here) using the same system-wide set of system parameters. Therefore, previous parameters UserNymSysData, OrgNymSysData, DeAnOrgNymSysData, which included entities keys as well as system parameters, were renamed UserSecret, IssuerKeys or VerifierKeys, DeAnOrgKeys. As discussed in Chapter 6, the primitives involving interactive protocols (nym registration, credential issuing and showing) rely on a communication channel being set up between the parties involved in the protocol, based on addressing information obtained at application level. In order to reason about the results of a protocol execution, we now explicitly include these communication channels in the primitives parameter list. A communication channel Comm is a global entity with a finite duration, and with a client (originator) and a server (receiver) interface; intuitively, a user and an issuer calling URegNym(), respectively ORegNym(), with the same Comm parameter, are communicating with each other. Whereas anonymity of credentials and of credential shows preserves the anonymity of the user at the application level, this anonymity has to be supported by anonymity of the user at the communication level. Without this sender anonymity, the organization the user is communicating with, as well as an external observer, could derive the identity of the user by tracing the communication. Many methods have been proposed for anonymizing communication; some examples are

126 Chapter 7. Designing Applications Using Idemix Anonymous Credentials Crowds [100], anonymizers [3], Onion Routing [66] and Mix networks [67, 97]. When designing Idemix applications, we assume the presence of sender anonymity using one of these methods. In Chapter 6, we did not make a distinction between application-level transcripts and cryptographic transcripts. Here, we want to more strictly separate information used and generated by the interactive protocols from application-level information the calling application may want to store; we therefore modified return value types of some of the operations as follows. Our definition of protocol transcript is now limited to the transcript Transcript UV returned by credential verification OVerifyCred(). This transcript contains cryptographic information CryptoTrscr generated by the credential verification; it also contains protocol parameters (CredShowInfo UV, CredShowFeatures UV, OrgNym UV and Msg UV ) that may be needed by an after-the fact verifier of the transaction, or a transaction de-anonymizer, to extract public keys, de-anonymization conditions and other arguments. ORegNym() now only returns an OrgNym the issuer application may of course choose to store additional information (previously called X) in an application-level transcript. OIssueCred() has no return value; the issuer may store application-level information indicating what type of credential was issued on which nym (the {OrgNym UI, CredInfo UI } information in Figure 7.1, previously called OrgCred ), or referring to additional cryptographic and/or application-level transcripts related to this credential issuing (e.g., the transcripts of the credential shows that were necessary in order for the issuer to issue the new credential). 7.2.2 Signed Nym Registration Participants and Key Material: User (U): Issuer (I): UserSecret U, SSKey U, Cert CA U IssuerKeys I Signed Nym Registration: U : URegSignedNym() UserNym UI OrgNym UI, Sig UI I : ORegSignedNym() I stores {OrgNym UI, Sig UI, Cert CA U, [Msg UI ]} Parametrized Primitives URegSignedNym(Comm UI, UserSecret U, SSKey U, Cert CA U, [Msg UI ]) returns UserNym UI ORegSignedNym(Comm UI, Cert CA U, [Msg UI ]) returns OrgNym UI, Sig UI Additional Inputs and Outputs SSKey U, Cert CA U Sig UI U s signature secret key and public-key certificate (certifying the public key SPKey U ) in an external PKI A signature (using SSKey U ) on OrgNym UI [and Msg UI ], allowing I to prove the linking between Cert CA U and OrgNym UI [and Msg UI ] Figure 7.4: Anonymous Credential System: Signed Nym Registration During registration of a nym, a user U can additionally authenticate to the nym issuer using a signature. This signature uses a signature key the public part of which is certified by certification authority CA in a certificate Cert CA U external to the Idemix system. The signature provides the issuer of the nym with a provable linking between the nym and the external certificate. The protocol in Figure 7.4 shows such

7.2. Primitives and Parameters of the Anonymous Credential System 127 a signed nym registration procedure between a user U and an issuer I. The provable linking between the nym and the external certificate is represented by U s signature Sig UI on OrgNym UI. An optional Msg argument allows the user to sign (and the nym issuer to verify) the additional message and link it to Cert CA U and OrgNym UI. This can be trivially realized by adding a hash of the Msg as argument to the user s signature and the organization s signature verification function in the signed nym registration protocol. Signed nym registration is most typically applied for the registration of a specially formed root nym with the Root Authority. The registration of such a root nym is a prerequisite for global de-anonymization; it is introduced in the following section and its use is illustrated in the example application in Section 7.7. Signed nym registration can, however, be requested by any organization other than the Root Authority in order to obtain a provable linking between a normal nym and an external certificate. We will illustrate also this use of signed nym registration in the example applications in Sections 8.3.1 and 8.3.2 of the next chapter. In those examples, users are required to sign their responsibilities (or liabilities) for actions during nym registration. 7.2.3 Root Nym Registration Root nym registration (Figure 7.5) uses signed nym registration to register a root nym, which is a nym with special features. Root nym registration is a prerequisite for enabling global de-anonymization, as discussed in Section 7.4.2. If root nym registration is applied, it is provided by a dedicated organization, which we will call the Root Authority R; R enforces that every user registers exactly one root nym. A root nym can be used in the same way as an ordinary nym; e.g., R can issue a credential on it. A credential issued by R on a root nym is called a root credential. Root nym registration enables global de-anonymization because of following features of the root nym, the external certificate and the registration process: Participants and Key Material: User (U): Root Authority (R): Root Nym Registration: UserSecret U, SSKey U, Cert CA U IssuerKeys R U : URegRootNym() UserNym UR OrgNym UR, Sig UR R : ORegRootNym() R stores {OrgNym UR, Sig UR, Cert CA U, [Msg UR ]} Parametrized Primitives URegRootNym(Comm UR, UserSecret U, SSKey U, Cert CA U, [Msg UR ]) returns UserNym UR ORegRootNym(Comm UR, Cert CA U, [Msg UR ]) returns OrgNym UR, Sig UR Additional Inputs and Outputs SSKey U, Cert CA U Sig UR U s signature secret key and public-key certificate (certifying the public key SPKey U in an external PKI A signature (using SSKey U ) on OrgNym UR [and Msg UR ], allowing R to prove the linking between Cert CA U and OrgNym UR [and Msg UR ] Figure 7.5: Anonymous Credential System: Root Nym Registration

128 Chapter 7. Designing Applications Using Idemix Anonymous Credentials The root nym is formed in a special way such that it is a component of all the other nyms of the same user (related to the same UserSecret U ). This feature is a result of the root nym depending only on the user s secret UserSecret U and public system parameters. It ensures that global deanonymization of any credential show transaction by the same user (of any credential issued on any nym) will reveal the user s root nym. Of course, mechanisms have to be in place to ensure that a user s nyms indeed are formed correctly, i.e., that they are properly linked to the user s root nym. The mechanism to verify that a new nym is correctly linked to a user s root nym is the verification of that user s root credential relative to this new nym. Showing a credential relative to a nym is discussed in Section 7.3.6; how it is applied to global de-anonymization is discussed in Section 7.4.2. The use of the signed nym registration procedure (as part of root nym registration) ensures that R has a provable linking between the root nym and an external certificate Cert CA U. This external certificate is issued by a Certificate Authority CA trusted with guaranteeing a unique linking between Cert CA U and a legal entity. (In further discussion, we often assume that U is a human user; note, however, that U could be another type of legal entity, such as a company.). This guarantee is necessary to provide a real means of recourse in case of, e.g., criminal misuse of a credential. Figure 7.5 shows the root nym registration process. Inputs and outputs of the root nym registration primitives (URegRootNym() and ORegRootNym()) are identical to the ones of their counterparts for signed nym registration (URegSignedNym() and ORegSignedNym()). The fact that UserNym UR and OrgNym UR now represent a root nym will, however, result in a different assertion about the result of the protocol execution; this is shown in Section 7.3.3. The goal of the external authentication in signed and root nym registration is a (provable) linking of a nym with a legal entity. One could also achieve this using a paper passport or other means of identification (as opposed to Cert CA U ) combined with a handwritten signature. On the one hand, this would obviate the need for prior registration of U with an external CA; but, on the other hand, it would require a more elaborate registration procedure by the organization (I or R) registering the nym. When designing applications using signed and root nym registration, we will always assume that the external authentication is done as depicted in Figures 7.4 and 7.5, i.e., using Cert CA U and a signature (Sig UI or Sig UR ) with SSKey U. 7.3 Assertions on Nyms, Credentials and Transcripts Resulting from Interactive Protocols After successful execution of an interactive protocol, both participants protocol outputs are related; e.g., UserNym and OrgNym are related. As each participant s output depends on both participants invocation parameters, such a relationship is global; it typically cannot be expressed as a relationship between parameters of one participant s primitive invocations alone. Here, we try to express these global relationships between, on the one hand, instances of primitive invocations and their parameters and, on the other hand, the contents of the nyms, credentials and transcripts established. They take the form of postconditions, called assertions, on protocol inputs and outputs from successful primitive invocations. The choice of representing protocol executions using such a global view will enable us to represent an interactive protocol execution with one statement or assertion; this will facilitate the description of applications. We will also specify which of the assertions are provable; e.g., the signature resulting from a signed nym registration procedure proves a relationship between an external certificate and a nym; the transcript from a credential show with certain parameters proves that a credential was shown with these parameters. When the provability of an assertion is important in describing applications, we will make it explicit by its naming. E.g., after signed nym registration, the issuing organization can prove the linking be-

7.3. Assertions on Nyms, Credentials and Transcripts Resulting from Interactive Protocols 129 tween the newly registered nym and the user s external certificate; the resulting assertion is called SignedNymProof(). Provability, together with the possibility to link nyms (and actions based on them) to external certificates, and thus to real users, form the basis for user accountability in the Idemix system. 7.3.1 Nym Registration URegNym(Comm UI, UserSecret U ) returns UserNym UI, ORegNym(Comm UI ) returns OrgNym UI Nym(UserSecret U, OrgNym UI, UserNym UI ). If a user and an issuer invoke URegNym() and ORegNym() on the same Comm UI channel with inputs as indicated, then the respective outputs UserNym UI and OrgNym UI are linked by the resulting Nym assertion. Nym is an assertion about a global relationship between values. It can informally be expressed as: OrgNym UI and UserNym UI are the issuer s and user s representation of the same nym, and are related to the user s UserSecret U. 7.3.2 Signed Nym Registration URegSignedNym(Comm UI, UserSecret U, SSKey U, Cert CA U, Msg UI ) returns UserNym UI, ORegSignedNym(Comm UI, Msg UI ) returns OrgNym UI, Cert CA U, Sig UI, Msg UI Nym(UserSecret U, OrgNym UI, UserNym UI ), SignedNymProof(Sig UI, Cert CA U, OrgNym UI, Msg UI ). A signed nym registration results in both Nym() and SignedNymProof() assertions. SignedNymProof() expresses the existence of evidence, in Sig UI, that OrgNym UI and Msg UI are signed with the private key the public counterpart of which is certified in Cert CA U. As the values in SignedNymProof() are all known to I, I can prove this signed linking. Msg UI in the above may be null; this will generally be the case for parameters indicated as being optional in Figures 7.2 to 7.5, unless their value is explicitly used in any of the preconditions. 7.3.3 Root Nym Registration URegRootNym(Comm UR, UserSecret U, SSKey U, Cert CA U, Msg UR ) returns UserNym UR, ORegRootNym(Comm UR, Msg UR ) returns OrgNym UR, Cert CA U, Sig UR, Msg UR RootNym(UserSecret U, OrgNym UR, UserNym UR ), SignedNymProof(Sig UR, Cert CA U, OrgNym UR, Msg UR ). The RootNym() assertion indicates that the nym is of this special root nym type; the SignedNymProof() assertion, as with signed nym registration, expresses the provable linking between the nym and the message with the external public key and certificate. Moreover, a root nym is also a nym: RootNym(UserSecret U, OrgNym UR, UserNym UR ) Nym(UserSecret U, OrgNym UR, UserNym UR ).

130 Chapter 7. Designing Applications Using Idemix Anonymous Credentials 7.3.4 Credential Issuing Nym(UserSecret U, OrgNym UI, UserNym UI ), CredInfo UI.IPKey = IssuerKeys I.IPKey, UGetCred(Comm UI, UserSecret U, UserNym UI, CredInfo UI ) returns UserCred UI, OIssueCred(Comm UI, IssuerKeys I, OrgNym UI, CredInfo UI ) Cred(OrgNym UI, UserCred UI, CredInfo UI ). If OrgNym UI and UserNym UI are U s nym with I related to UserSecret U, and U and I invoke UGetCred() and OIssueCred() on the same Comm UI channel to issue a credential on OrgNym UI, and the IPKey in the requested CredInfo is indeed the public credential issuing key IPKey I in the IssuerKeys used by I for credential issuing, then the invocation by U and I of UGetCred() and OIssueCred() with inputs as indicated results in a UserCred UI about which we can make the resulting Cred assertion: UserCred UI is a valid credential of type CredInfo UI (including IPKey I ) on OrgNym UI. Note that the condition CredInfo UI.IPKey = IssuerKeys I.IPKey is actually a precondition for the success of the respective UGetCred() and OIssueCred() invocations; this is not captured in our notation. As our focus is on representing the relationship between successful invocations (with specific parameter values) and resulting assertions, this does not pose a problem. 7.3.5 Showing a Credential Not Relative to a Nym Cred(OrgNym UI, UserCred UI, CredInfo UI ), Nym(UserSecret U, OrgNym UI, UserNym UI ), Fulfills(CredInfo UI, CredShowInfo UV ), CredShowFeatures UV.RelNym = false, CredShowFeatures UV.VPKey = VerifierKeys V.VPKey, UShowCred(Comm UV, UserSecret U, UserCred UI, CredShowInfo UV, CredShowFeatures UV, null 1, Msg UV ), OVerifyCred(Comm UV, VerifierKeys V, CredShowInfo UV, CredShowFeatures UV, null 1, Msg UV ) returns Transcript UV WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, null, Msg UV ). If UserCred UI is a valid credential of type CredInfo UI (including IPKey I ) on UserNym UI, UserNym UI is related to UserSecret U and OrgNym UI, the credential features CredInfo UI fulfill the CredShowInfo UV features that U wants to show to V in this particular UShowCred() invocation, and the verification key of V matches the verification key VPKey in CredShowFeatures UV, then an invocation by U and V of UShowCred() and OVerifyCred() on the same Comm UV channel with inputs as indicated results in a Transcript UV about which the resulting WasShown assertion holds. As the credential show is not relative to a pseudonym shared with V (CredShowFeatures.RelNym = false), UserNym in UShowCred(), OrgNym in OVerifyCred(), and OrgNym in the WasShown assertion are null 1. WasShown is a global assertion linking UserCred UI to the show protocol parameters and the transcript. In Section 7.2.1, we assumed that the credential show protocol results in a transcript providing evidence. We can state this as follows: WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, null, Msg UV ) SigProof(Transcript UV, CredShowInfo UV, CredShowFeatures UV, null, Msg UV ). The SigProof() assertion expresses that, with Transcript UV, V can prove that: the credential specified in CredShowInfo UV was shown with CredShowFeatures UV ; the optional Msg UV was signed together with it ( was signed with the credential ). 1 The value of the UserNym (OrgNym) parameter in UShowCred() (OVerifyCred()) should be null; one can however assume that even non-null input values are not taken into account in the protocol if CredShowFeatures.RelNym = false.

7.4. Local Operations on Transcripts 131 7.3.6 Showing a Credential Relative to a Nym Cred(OrgNym UI, UserCred UI, CredInfo UI ), Nym(UserSecret U, OrgNym UI, UserNym UI ), Fulfills(CredInfo UI, CredShowInfo UV ), CredShowFeatures UV.RelNym = true, CredShowFeatures UV.VPKey = VerifierKeys V.VPKey, Nym(UserSecret U, OrgNym UV, UserNym UV ), UShowCred(Comm UV, UserSecret U, UserCred UI, CredShowInfo UV, CredShowFeatures UV, UserNym UV, Msg UV ), OVerifyCred(Comm UV, VerifierKeys V, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ) returns Transcript UV WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ). As the credential is shown relative to a pseudonym shared with V (CredShowFeatures.RelNym = true), UShowCred(), OVerifyCred() and the WasShown() assertion have UserNym UV, respectively OrgNym UV as parameters; in addition, UserNym UV and OrgNym UV have to be linked by a Nym assertion in order for the credential show protocol to succeed. We can again state an assertion about provability: WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ) SigProof(Transcript UV, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ). The SigProof() assertion now expresses that, with Transcript UV, V can prove that: the credential specified in CredShowInfo UV was shown with CredShowFeatures UV ; the optional Msg UV was signed together with it; OrgNym UV was the signer s nym with V. 7.4 Local Operations on Transcripts Using assertions on nyms, credentials and transcripts as preconditions, we can now describe the results of the methods for de-anonymization and double-spending detection in terms of the inputs and outputs of the interactive protocols. 7.4.1 Local De-Anonymization Nym(UserSecret U, OrgNym UI, UserNym UI ), Cred(OrgNym UI, UserCred UI, CredInfo UI ), WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ), CredShowFeatures UV.LocalDeAnData.DPKey = DeAnOrgKeys D.DPKey CanLDeAn(DeAnOrgKeys D, Transcript UV, OrgNym UI ). If a transcript Transcript UV was generated during a credential show with local de-anonymization using a de-anonymizer s DPKey D, then the CanLDeAn() assertion holds. The CanLDeAn() assertion expresses the following relationship between DeAnOrgKeys D, Transcript UV and OrgNym UI : if DODeAnonLocal() is called on Transcript UV with DeAnOrgKeys D, it will return OrgNym UI, the nym on which the credential was issued. Note that the de-anonymization condition LocalDeAnData.DeAnCondition is not taken into account. The approach taken, for local as well as for global de-anonymization, is that the invocation, not the outcome of the de-anonymization operation, should depend on the de-anonymization condition being

132 Chapter 7. Designing Applications Using Idemix Anonymous Credentials fulfilled. Thus, D can (but should not) successfully invoke DODeAnonLocal() even if the de-anonymization condition is not fulfilled. By showing UserCred UI with local de-anonymization using DPKey D, the resulting Transcript UV contains an encryption EV D (OrgNym UI ) of U s nym with I, verifiably encrypted with D s public deanonymization key DPKey D (actually, the encrypted value is not the nym itself but a validating tag which I can associate with OrgNym UI ; in this discussion, we will not make this distinction). V can verify that the encrypted nym is indeed the nym the credential was issued on. V trusts D to decrypt this information if the de-anonymization condition is fulfilled; as OrgNym UI has no meaning to V, V has to rely on I to take appropriate action or provide other information associated with OrgNym UI. Local De-Anonymization with Proof of Correctness A de-anonymizing organization can prove the correctness of a de-anonymization, i.e., can prove that the resulting OrgNym is indeed the one encrypted in the de-anonymized transcript. This can be done interactively or non-interactively. As this proof is a valuable feature in building secure applications, we will define also specific primitives for de-anonymizations producing such a proof. For local de-anonymization, we define a new operation DODeAnonLocalWProof() which returns a deanonymization transcript DeAnTranscript rather than only a nym. The de-anonymization transcript contains the nym as well as a (non-interactive) proof of correctness of the de-anonymization. We also define an assertion LDeAnProof() capturing what is proved by the de-anonymization transcript. We can state that, if the transcript is de-anonymizable: then an invocation of CanLDeAn(DeAnOrgKeys D, Transcript UV, OrgNym UI ) DODeAnonLocalWProof(DeAnOrgKeys D, Transcript UV ) will return a de-anonymization transcript DeAnTranscript DUV satisfying LDeAnProof(DeAnTranscript DUV, Transcript UV, OrgNym UI ). The latter implies that, with DeAnTranscript DUV, any party can be convinced that Transcript UV indeed contained the encryption of OrgNym UI contained in Transcript UV. The double-subscript notation in DeAnTranscript DUV indicates that D de-anonymizes a transcript Transcript UV. 7.4.2 Global De-Anonymization Global de-anonymization works quite differently than local de-anonymization. It is based on the fact that U carried out a root nym registration with Root Authority R. We assume that the identity (or, at least, the credential issuing public key) of R is known to all the organizations in the system, e.g., by making it part of the system parameters. Alternatively, R s issuing public key can be made an additional parameter of the GlobalDeAnData structure. Consider the case where V verifies a credential Cred UI issued by I with global de-anonymization enabled. If the verification is successful, the resulting transcript Transcript UV should contain EV D (OrgNym UR ), a verifiable encryption of U s registered root nym with D s public de-anonymization key DPKey D. If U s nym with R is indeed a root nym of which R knows a provable mapping to an external certificate, and U s nym with I is correctly linked to that root nym (is related to the same UserSecret U ), this is indeed the case. We can represent this as follows:

7.4. Local Operations on Transcripts 133 RootNym(UserSecret U, OrgNym UR, UserNym UR ), Nym(UserSecret U, OrgNym UI, UserNym UI ), Cred(OrgNym UI, UserCred UI, CredInfo UI ), WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ), CredShowFeatures UVI.GlobalDeAnData.DPKey = DeAnOrgKeys D.DPKey CanGDeAn(DeAnOrgKeys D, Transcript UV, OrgNym UR ). The CanGDeAn() assertion expresses that, if DODeAnonGlobal() is called on Transcript UV with the correct keys DeAnOrgKeys D, it will return OrgNym UR. Of course, in order to then derive an external identity from OrgNym UR, the root nym also should have been registered using the external authentication: SignedNymProof(Sig UR, Cert CA U, OrgNym UR, Msg UR ) The above set of assertions could, in principle, be realized by the corresponding protocol executions: root nym registration (RootNym() and SignedNymProof() assertions), nym registration with I (Nym()), credential issuing by I (Cred()) and showing of the latter credential (WasShown()). However, the result of DODeAnonGlobal() depends on OrgNym UI being formed correctly w.r.t. OrgNym UR ; neither I nor V can rely on this relationship without the issuing and verification of a root credential. The following series of exchanges then realizes the above assertions while also verifying the relationship between OrgNym UR and OrgNym UI. In this example, we directly represent the execution of an interactive protocol by means of the resulting assertion, and introduce shorthand notations for individual assertions. E.g., RootNym UR is a shorthand notation for a RootNym assertion resulting from a root nym registration between U and R. U R : RootNym UR = RootNym(UserSecret U, OrgNym UR, UserNym UR ); SignedNymProof(Sig UR, Cert CA U, OrgNym UR, Msg UR ); R stores {OrgNym UR, Sig UR, Cert CA U, Msg UR } U R : Cred UR = Cred(OrgNym UR, UserCred UR, CredInfo UR ) U I : Nym UI = Nym(UserSecret U, OrgNym UI, UserNym UI ) U I : WasShown UIR = WasShown(Transcript UIR, UserCred UR, CredShowInfo UIR, with CredShowFeatures UIR.RelNym = true and CredShowInfo UIR.IPKey= IPKey R U I : Cred UI = Cred(OrgNym UI, UserCred UI, CredInfo UI ) CredShowFeatures UIR, OrgNym UI, Msg UIR ), U V : WasShown UVI = WasShown(Transcript UVI, UserCred UI, CredShowInfo UVI, CredShowFeatures UVI, null, Msg UVI ), with CredShowFeatures UVI.GlobalDeAnData.DPKey = DPKey D In a first exchange with R, U registers a root nym with R, resulting in the RootNym() and SignedNymProof() assertions; R stores the {Sig UR, Cert CA U, OrgNym UR, Msg UR } relationship. In a second exchange with R, U then establishes a root credential Cred UR that will allow him to convince I of the linking between a valid root nym and the nym it will later share with I. In the following two exchanges with I, U establishes a nym Nym UI with I and shows his root credential relative to the newly established Nym UI (the double-subscript notation WasShown UIR captures the fact that U shows to I a credential issued by R). This convinces I that Nym UI is related to the nym on which the root credential was issued; if it was a correctly formed root nym, then Nym UI is derived from it. In the third exchange with I, U then obtains a credential Cred UI on Nym UI. U finally shows the latter credential to V, using global de-anonymization

134 Chapter 7. Designing Applications Using Idemix Anonymous Credentials with DPKey D. In the above scenario, V only directly verifies the credential Cred UI ; V cannot verify that U has a well-formed root nym with R and that the nym that U shares with I is correctly derived from that root nym. V thus has to rely on I and R for the following: V relies on R for issuing a root credential only on a well-formed root nym (of which it knows a provable mapping with an external legal entity); in case R issues credentials other than such root credentials, one expects R to use a dedicated key ISKey R for issuing root credentials (on root nyms) and (an)other key(s) ISKey R for other credentials; V relies on I to verify that U has registered a nym with R, and that the nym Nym UI on which I will issue Cred UI is derived from that (root) nym; I does this by verifying the root credential relative to Nym UI in WasShown UIR. Alternatively, V can choose not to trust I for verifying the linking between the nyms, and to verify the linking itself. This now requires that U share a nym with V, and that U shows both credentials (Cred UR and Cred UI ) to V relative to this nym: U R : RootNym UR = RootNym(UserSecret U, OrgNym UR, UserNym UR ); SignedNymProof(Sig UR, Cert CA U, OrgNym UR, Msg UR ); R stores {OrgNym UR, Sig UR, Cert CA U, Msg UR } U R : Cred UR = Cred(OrgNym UR, UserCred UR, CredInfo UR ) U I : Nym UI = Nym(UserSecret U, OrgNym UI, UserNym UI ) U I : Cred UI = Cred(OrgNym UI, UserCred UI, CredInfo UI ) U V : Nym UV = Nym(UserSecret U, OrgNym UV, UserNym UV ) U V : WasShown UVR = WasShown(Transcript UVR, UserCred UR, CredShowInfo UVR, CredShowFeatures UVR, OrgNym UV, Msg UVR ) U V : WasShown UVI = WasShown(Transcript UVI, UserCred UI, CredShowInfo UVI, CredShowFeatures UVI, OrgNym UV, Msg UVI ), with CredShowFeatures UVI.GlobalDeAnData.DPKey = DPKey D We have assumed that I does not have its own requirement to verify a root credential before issuing Cred UI ; if such a verification is a condition, an additional show of Cred UR to I is necessary. By verifying both credentials relative to OrgNym UV, V verifies that the nyms on which the credentials are issued are related. V now only has to rely on R to issue root credentials only on correctly formed root nyms. Global De-Anonymization with Proof of Correctness Similar as for local de-anonymization, we can define a new operation DODeAnonGlobalWProof() and a new assertion GDeAnProof(): If a transcript is globally de-anonymizable: then an invocation of CanGDeAn(DeAnOrgKeys D, Transcript UV, OrgNym UR )

7.5. Assertions on Linkability 135 DODeAnonGlobalWProof(DeAnOrgKeys D, Transcript UV ) will return a de-anonymization transcript DeAnTranscript DUV satisfying GDeAnProof(DeAnTranscript DUV, Transcript UV, OrgNym UR ). The GDeAnProof() assertion implies that DeAnTranscript DUV not only contains the result of the deanonymization (OrgNym UR ) but also a proof of correctness of the de-anonymization. 7.4.3 Double-Spending Detection WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ), Cred(OrgNym UI, UserCred UI, CredInfo UI ), CredInfo UI.MultiShow = false, CanDlbSpDetect(OrgNym UI, UserCred UI, Transcript UV ). Showing a one-show credential results in a CanDlbSpDetect() assertion; this assertion implies that a second show of the same credential UserCred UI causes OCheckDblSp(), when called on both transcripts with the correct issuer keys, to reveal OrgNym UI on which UserCred UI is issued. Double-Spending Detection with Proof of Correctness Also a result of double-spending detection can be proved correct, in this case by the issuer who detects double-spending, using the primitive OCheckDblSpWProof(). If a one-show credential issued by I was shown twice: CredInfo UI.IPKey = IssuerKeys I.IPKey, CanDlbSpDetect(OrgNym UI, UserCred UI, Transcript UV1 ), CanDlbSpDetect(OrgNym UI, UserCred UI, Transcript UV2 ) then an invocation of OCheckDblSpWProof(IssuerKeys I, Transcript UV1, Transcript UV2 ) will return a transcript DblSpTranscript IUI satisfying DblSpProof(DblSpTranscript IUI, Transcript UV1, Transcript UV2, OrgNym UI ). DblSpTranscript IUI is the transcript of the double-spending detection; it includes OrgNym UI. The double-subscript notation in DblSpTranscript IUI implies that I verifies double-spending of a credential Cred UI. 7.5 Assertions on Linkability 7.5.1 Anonymity, Linkability and Identifiability In the previous sections, we have focused on a description and features of the Idemix protocols which allows to show fulfillment of an organization s requirements. Assertions on credential shows can fulfill requirements of authentication (what was proved?); provable assertions about credential shows, deanonymization and double-spending detection, together with the provability of the relationship between a nym and a user through signed or root nym registration, can fulfill requirements of user accountability.

136 Chapter 7. Designing Applications Using Idemix Anonymous Credentials When designing applications, an important requirement by the user is also unidentifiability, realized through anonymity and unlinkability of his actions. If a user requires that a certain action requiring a credential show be unconditionally unidentifiable, this clearly excludes a credential show with a global de-anonymization option. In Section 1.2.4, we defined anonymity as being a protocol-intrinsic property, and unidentifiability to result from anonymity in the absence of factors causing linkability with an identity. However, when discussing a specific system such as Idemix, we have to concretely define anonymity properties of its protocols. E.g., signed nym registration can certainly be considered to be an identifiable action, if the key and certificate used for signing are identifiable. However, even if our discussions of accountability assume Cert CA U to be identifiable, one can consider scenarios where signed nym registration uses a pseudonym certificate. Do we then define the signed nym registration protocol to be anonymous or not? For the sake of clarity and consistency, we define all the Idemix interactive protocols to be intrinsically anonymous. According to this definition, also signed and root nym registration are anonymous; identifiability of the user s certificate and signature key then makes the registered nym identifiable by introducing a linking between the nym and the certificate. Similarly, showing a credential, even with the global de-anonymization option set, is anonymous; identifiability results if global de-anonymization is applied and the user s external certificate is identifiable. In this section, we describe assertions about linkability of nyms, credentials and credential shows related to executions of the various primitives; these allow to reason about the identifiability of a user s actions as a consequence of a linkability to identifiable items. For each of the Idemix protocols in Section 7.3, we define its linkability characteristics by expressing whether nyms or the user s identity are linkable to the result of the protocol execution; this linkability can be towards the organization involved in the protocol (e.g., issuing or verifying organization) or towards another organization (e.g., a de-anonymizing organization). We define a new assertion: Linked(Org, Cond, Value 1, Value 2 ) expressing that Org can link the values Value 1 and Value 2. Cond is a condition that may restrict Org s right to do so. E.g., Org may be a de-anonymizing organization that is able to link a transcript to a nym but should only do so under a certain condition. Intuitively, if two organizations each have their own linkability knowledge, then a collaborating set of both organizations combines that knowledge: Linked(Org 1, Cond 1, Value 11, Value 12 ), Linked(Org 2, Cond 2, Value 21, Value 22 ) Linked({Org 1 AND Org 2 }, Cond 1, Value 11, Value 12 ), Linked({Org 1 AND Org 2 }, Cond 2, Value 21, Value 22 ). Also, linkability is symmetric: Linked(Org, Cond 1, Value 1, Value 2 ) Linked(Org, Cond 1, Value 2, Value 1 ). and transitive: Linked(Org, Cond 1, Value 1, Value 2 ), Linked(Org, Cond 2, Value 2, Value 3 ) Linked(Org, {Cond 1 AND Cond 2 }, Value 1, Value 3 ). The linkabilities we can express are the ones related to the choice of protocol and its options. Some examples:

7.5. Assertions on Linkability 137 A credential show relative to a nym obviously links the transcript to this nym; A de-anonymizable credential show makes a later linking possible of the transcript to a nym by the de-anonymizing organization; Showing of a one-show credential makes a linking possible of the transcript to a nym by the credential issuer, if a second show transcript of the same credential exists; As part of showing a credential, a user may sign a message which is unique; this message may identify the user or make the credential show linkable to another transaction linked to the same message; A credential may have a unique attribute which the issuer can link to the nym it was issued on; in Section 8.3, we will discuss examples of such an intentional linkability. Showing a credential, even if not relative to a nym and not de-anonymizable, may thus become fully or partially identifiable if only one or a small set of users has this type of credential. One reason can be that the issuer purposely gave it some unique attribute, as discussed above. Another reason can be that the set of users owning and using a credential of the same type is (still) too small. In the first case, the identifiability is feature inherent in the credential and protocol definition and we will define its effect on linkability. In the second case, the linkability is dynamic and is a result of how the system is actually used; this cannot be predicted by knowledge of the protocols used. Thus, there are hidden linkabilities which we cannot capture with our reasoning. The small user set owning a specific type of credential is one example; another example is traceability of communication which may identify a user in an otherwize unidentifiable Idemix transaction. A hidden linkability may also exist if a user signs an identifying message which he believes not to be identifying. The linkability factors that are not related to the choice of Idemix protocols and their parameters have to be taken into account by good system design and deployment as well as user education. Anonymous communication should be available and used; a credential of a specific type should not be used unless the group of users owning and using such a credential is large enough; and user agents as well as organizations should help users to avoid including identifiable information in messages if this identifiability is not a design feature of the system; if, on the contrary, it is an intended feature, this should be visible to users. Thus, using good system design and deployment, hidden linkabilities may be excluded. In such a system, linkability assertions as we discuss here are a meaningful way of expressing or discovering potential identifiability factors. In the following paragraphs, we now derive linkability assertions for each of the Idemix protocols. When designing a specific application, we can then translate unidentifiability requirements into requirements about the absence of linkabilities. We will illustrate this with our example application in Section 7.7. We do not attempt to develop a logic of linkability; the linkability assertions as we define them are merely intended to help us expressing, in an intuitive way, direct traceability of a user s identity or nyms through various Idemix protocol executions. Also, we do not attempt to make any probabilistic statements about linkability; e.g., a credential attribute is either unique or not; in the former case, its showing can be linked to its issuing; in the latter case, it cannot (however large or small the set of users using a credential with this attribute). A statement about unconditional unidentifiability of an action or set of actions thus only claims that according to the associated linkability assertions as defined in the following, no linkability to an identifiable item exists. Note that the Linked() assertion does not distinguish between linkabilities which are provable and linkabilities which are not. Although most Linked() assertions will be related to provable assertions, we also want to capture linkabilities which are not provable. E.g., if a credential was shown relative to a nym, then the fact that the show transcript is linked to this nym is provable. But, if an organization can link a credential to a nym because the credential type (CredInfo) is unique, this linkability is not provable according to any of our provable assertions. Whether or not the linking can be proved to a third party depends on the organization being able to convince a third party that no other credential with the same CredInfo was issued.

138 Chapter 7. Designing Applications Using Idemix Anonymous Credentials 7.5.2 Nym Registration From establishment of the Nym() assertion as a result of the protocol execution in Section 7.3.1, I s only result is OrgNym UI and no linkability towards I results: Nym(UserSecret U, OrgNym UI, UserNym UI ). 7.5.3 Signed Nym Registration Signed nym registration as in Section 7.3.2 results in a Nym as well as a SignedNymProof() assertion. The SignedNymProof() assertion creates a linkability, by I, between the established nym and the certificate used for signing: SignedNymProof(Sig UI, Cert CA U, OrgNym UI, Msg UI ) Linked(I, null, OrgNym UI, Cert CA U ). Cert CA U here stands for the identity of the user: when something is linked to Cert CA U, we will say that it is linked to the user. If Msg UI is a generic message signed by all the users obtaining this type of nym with I, this is the only resulting linkability. However, if Msg is a message unique to this instance of the nym registration protocol, an additional linkability results. The assertion Unique() expresses the fact that a value is unique: SignedNymProof(Sig UI, Cert CA U, OrgNym UI, Msg UI ), Unique(Msg UI ) Linked(I, null, OrgNym UI, Cert CA U ), Linked(I, null, Msg UI, Cert CA U ). By transitivity, also a linking between Msg UI and OrgNym UI can be derived. 7.5.4 Root Nym Registration Root nym registration results in RootNym and SignedNymProof assertions. The linkability effect of SignedNymProof is the one described in Section 7.5.3; RootNym, as Nym, does not result in any linkability: RootNym(UserSecret U, OrgNym UR, UserNym UR ). 7.5.5 Issuing of a Non-Unique Credential Anonymous credential issuing assumes that CredInfo UI is a generic credential type issued on a large set of different nyms. In this case, it is still important for I to know he issued a credential of type CredInfo UI on OrgNym UI (e.g., for revocation purposes); however, as there are many credentials of the same type, the credential issuing does not result in any linkability information, i.e., a later use of the credential cannot be linked back to the specific issuing instance (and the nym OrgNym UI ) it was issued on: Cred(OrgNym UI, UserCred UI, CredInfo UI ), Unique(CredInfo UI ).

7.5. Assertions on Linkability 139 7.5.6 Issuing of a Unique Credential If the CredInfo type of a credential is unique, then the linking between the nym and the type (CredInfo) is relevant: Cred(OrgNym UI, UserCred UI, CredInfo UI ), Unique(CredInfo UI ) Linked(I, null, OrgNym UI, CredInfo UI ). In Section 8.3, we will present an example where a credential issued is unique, and therefore linkable to the nym it was issued on. 7.5.7 Unconditionally Unidentifable Showing of a Credential We refer to the protocol discussed in Section 7.3.5. If the credential is not shown relative to a nym, then Transcript UV may not contain any identifiable parameters. However, linkability can still be introduced by the use of either: local or global de-anonymization (Section 7.5.10); a unique parameter such as a unique CredShowInfo, allowing to link the show transcript to a specific credential with a matching CredInfo; or a unique Msg, allowing to link the show transcript to another exchange related to Msg (Section 7.5.8). If neither CredShowInfo UV nor Msg UV are unique, a credential can be shown in an unconditionally unidentifable way if the show is neither relative to a nym nor de-anonymizable: WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, null, Msg UV ), Unique(CredShowInfo UV ), Unique(Msg UV ), CredShowFeatures UV = {false, null, null}. 7.5.8 Showing a Credential with Unique Parameters If either CredShowInfo UV or Msg UV is unique, this has to be taken into account by an additional linkability. However, this is relevant only if the unique feature in CredShowInfo UV (or Msg UV ) also occurs in another linkability statement. WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ), Unique(CredShowInfo UV ) Linked(V, null, Transcript UV, CredShowInfo UV ). WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ), Unique(Msg UV ) Linked(V, null, Transcript UV, Msg UV ). This linkability effect has to be combined with any other linkablities resulting from showing a credential relative to a nym, showing a credential in a de-anonymizable way, or showing a one-show credential. 7.5.9 Showing a Credential Relative to a Nym Showing a transcript relative to a nym makes the nym and the transcript linkable towards the verifier: WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, OrgNym UV, Msg UV ), CredShowFeatures UV.RelNym = true Linked(V, null, Transcript UV, OrgNym UV ).

140 Chapter 7. Designing Applications Using Idemix Anonymous Credentials 7.5.10 Showing a Credential with De-Anonymizaton For all previous types of showing a credential, additional linking assertions result from the use of a de-anonymization option: For local de-anonymization: CanLDeAn(DeAnOrgKeys D, Transcript UV, OrgNym UI ), Transcript UV.CredShowFeatures.LocalDeAnData.DPKey = DeAnOrgKeys D.dpkey, Transcript UV.CredShowFeatures.LocalDeAnData.DeAnCondition = DeAnCondition UV Linked(D, DeAnCondition UV, OrgNym UI, Transcript UV ). For global de-anonymization: CanGDeAn(DeAnOrgKeys D, Transcript UV, OrgNym UR ), Transcript UV.CredShowFeatures.GlobalDeAnData.DPKey = DeAnOrgKeys D.dpkey, Transcript UV.CredShowFeatures.GlobalDeAnData.DeAnCondition = DeAnCondition UV Linked(D, DeAnCondition UV, OrgNym UR, Transcript UV ). 7.5.11 Showing a One-Show Credential When a one-show credential is shown, the transcript is conditionally linked to the nym on which the credential was issued the condition being double-spending of the credential: CanDlbSpDetect(OrgNym UI, UserCred UI, Transcript UV1 ), CredInfo UI.IPKey = IssuerKeys I.IPKey Linked(I, dblspent, OrgNym UI, Transcript UV ). The dblspent condition indicates that the presence of another transcript Transcript UV CanDlbSpDetect() assertion will materialize the linking towards I. satisfying the 7.6 Additional Procedures and Functionality 7.6.1 More On Global De-Anonymization In Section 7.4.2, we described how global de-anonymization can be realized using a specific option in the credential show protocol together with the showing of the root credential. Here, we discuss two additional possibilities for achieving a similar functionality by using only the local de-anonymization protocol option. We refer again to an exchange such as the one in Section 7.4.2. In order for a verifier V to have a guarantee of obtaining Cert CA U under condition DeAnCondition UVI, other possiblities exist: It can be achieved by cooperation between V and I both requiring local de-anonymization in subsequent show protocols, as shown in the exchange in Figure 7.6. When verifying Cred UI in the last exchange, V requires only local de-anonymization (with DPKey D and DeAnCondition UVI ), and trusts I to have verified Cred UR before issuing Cred UI. This verification (WasShown UIR ) was also done using local de-anonymization, probably with the same DPKey D and a related condition DeAnCondition UIR ; and was relative to OrgNym UI. If DeAnCondition UVI is fulfilled, WasShown UVI can be (locally) de-anonymized by D to reveal OrgNym UI : DODeAnonLocal(DeAnOrgKeys D, Transcript UVI ) returns OrgNym UI

7.6. Additional Procedures and Functionality 141 U R : RootNym UR = RootNym(UserSecret U, OrgNym UR, UserNym UR ); SignedNymProof(Sig UR, Cert CA U, OrgNym UR, Msg UR ); R stores{orgnym UR, Sig UR, Cert CA U, Msg UR } U R : Cred UR = Cred(OrgNym UR, UserCred UR, CredInfo UR ) U I : Nym UI = Nym(UserSecret U, OrgNym UI, UserNym UI ) U I : WasShown UIR = WasShown(Transcript UIR, UserCred UR, CredShowInfo UIR, CredShowFeatures UIR, OrgNym UI, Msg UIR ) with CredShowFeatures UIR.LocalDeAnData = {DPKey D, DeAnCondition UIR } and CredShowFeatures UIR.RelNym = true; I stores {OrgNym UI, Transcript UIR } U I : Cred UI = Cred(OrgNym UI, UserCred UI, CredInfo UI ) U V : WasShown UVI = WasShown(Transcript UVI, UserCred UI, CredShowInfo UVI, CredShowFeatures UVI, null, Msg UVI ), with CredShowFeatures UVI.LocalDeAnData = {DPKey D, DeAnCondition UVI } Figure 7.6: Global De-Anonymization Using Local De-Anonymization: V and I Cooperating U R : RootNym UR = RootNym(UserSecret U, OrgNym UR, UserNym UR ); SignedNymProof(Sig UR, Cert CA U, OrgNym UR, Msg UR ); R stores{orgnym UR, Cert CA U,, Msg UR } U R : Cred UR = Cred(OrgNym UR, UserCred UR, CredInfo UR ) U I : Nym UI = Nym(UserSecret U, OrgNym UI, UserNym UI ) U I : Cred UI = Cred(OrgNym UI, UserCred UI, CredInfo UI ) U V : Nym UV = Nym(UserSecret U, OrgNym UV, UserNym UV ) U V : WasShown UVR = WasShown(Transcript UVR, UserCred UR, CredShowInfo UVR, CredShowFeatures UVR, OrgNym UV, Msg UVR ) with CredShowFeatures UVR.LocalDeAnData = {DPKey D, DeAnCondition UVR } U V : WasShown UVI = WasShown(Transcript UVI, UserCred UI, CredShowInfo UVI, CredShowFeatures UVI, OrgNym UV, Msg UVI ) Figure 7.7: Global De-Anonymization Using Local De-Anonymization: V Verifying Linking of Nyms

142 Chapter 7. Designing Applications Using Idemix Anonymous Credentials The fact that WasShown UIR was relative to OrgNym UI ensures to I (and allows I to prove) that Transcript UIR is related to OrgNym UI. SigProof(Transcript UIR, CredShowInfo UIR, CredShowFeatures UIR, OrgNym UI, Msg UIR ) Thus, with cooperation from I, who can link OrgNym UI to Transcript UIR,Transcript UIR be (locally) de-anonymized by D to reveal OrgNym UR : can then DODeAnonLocal(DeAnOrgKeys D, Transcript UIR ) returns OrgNym UR For the latter de-anonymization to be enabled upon V s de-anonymization condition being fulfilled, DeAnCondition UIR and DeAnCondition UVI should be related: DeAnCondition UIR has to be fulfilled if DeAnCondition UVI is fulfilled. It can be realized by V alone: V itself demands a locally de-anonymizable show WasShown UVR of Cred UR in addition to a show WasShown UVI of Cred UI. For V to verify the linking, WasShown UVR then has to be relative to a nym shared between U and V. Consequently, this requires an additional nym registration between U and V. Figure 7.7 illustrates the procedure. By verifying that both Cred UR and Cred UI can be shown relative to OrgNym UV, V verifies that the nyms on which both credentials are issued are related to the same UserSecret. Consequently, V is assured that decryption by D of WasShown UVR wil reveal the OrgNym UR of the user who showed both credentials. When de-anonymization of WasShown UVI is required, V now only has to ask D for (local) de-anonymization of WasShown UVR : DODeAnonLocal(DeAnOrgKeys D, Transcript UVR ) returns OrgNym UR 7.6.2 Revocation Traditional methods for certificate revocation are based on the fact that the relying party (the signature verifier) can compare a certificate s serial number or public key with items in a list of revoked (or, alternatively, valid) certificates. In an anonymous credential system, this type of revocation is impossible: the relying party has no way of distinguishing one user s credential from another user s credential of the same type. Two methods can be considered for realizing revocation in the anonymous credential system. Using the first method ( [11, 10]), when I wants to revoke a credential it issued on a nym OrgNym IU, I simply changes its issuing public key IPKey I to IPKey I, and advertises this change to relying parties and owners of credentials based on IPKey I. All the credentials based on the old IPKey I are now invalid, and each owner of a credential based on IPKey I has to go through an interactive re-issuing protocol with the issuer to have their credential re-issued with the new key IPKey I. I simply does not re-issue the revoked credential. Revocation of a credential thus involves that the issuer revokes and replaces his issuing key; and information of a relying party does not consist of revocation lists but of the latest issuing organization s IPKey. In terms of efficiency for relying parties, this is quite advantageous, as they only need to keep track of this valid IPKey. In terms of efficiency for the issuer and other users in the system, the interactive re-issuing is quite inefficient. One can optimize the process for the other users. E.g., if U s credential based on IPKey I was revoked, the other users need not be notified but are made aware of the revocation at the moment they want to show their own (invalidated) credential. At that point, they obtain the new issuer key (either from the verifier or from the issuer) and initiate the re-issuing process. A second method is based on dynamic accumulators [32]. Using this method, an issuer revoking a credential also changes its public key, by changing a dynamic accumulator list of valid credentials, which is part of the public key. The new public key is again distributed to users and relying parties; every user can update (re-validate) their (invalidated) credential in a non-interactive computation, based on the information in the accumulator. As the revoked credential is not anymore part of the accumulator, the revoked credential cannot be re-validated.

7.7. Designing an Application 143 Both methods assume that each credential issuer keeps track of which credentials it issued with which key and on which OrgNym. The second method can be realized more efficiently than the first method, especially because it does not involve an interactive re-issuing of credentials. In following sections, when discussing applications based on anonymous credentials, we will assume that one of the two mechanisms for revocation is in place. We assume the existence of a high-level primitive. ORevokeCred(IssuerKeys, OrgNym, CredInfo) As mentioned in Section 7.2, a party relying on verification of a credential is responsible for verifying the correctness of the issuer s public key IPKey I in the CredShowInfo parameter of the OVerifyCred() invocation; the relying party should also verify that IPKey I has not been revoked. This implies the existence of the appropriate mechanisms for relying parties to verify an issuer key s good (non-revoked) state. 7.6.3 Certification In Sections 7.2.2 and 7.2.3, we described how users can use an external certificate to securely link their root or other nym to an externally validated identity. Organizations, as well, need to link their Idemix keys to an external certification infrastructure. For organizations, several levels of certification exist: the organization, as a business entity (e.g., an on-line merchant), may have an externally certified public signature key, the private key of which it uses to issue self-certified Idemix certificates for the keys needed in various transaction and communication roles. E.g., the on-line merchant may self-certify Idemix public issuing and/or verification keys (IPKey and/or VPKey) corresponding to the ISKey/VSKey with which he issues/verifies Idemix credentials; he may selfcertify another signature key to realize authentication and key exchange for protecting communication channels used in Idemix as well as non-idemix exchanges. Certification of organizations Idemix keys and other keys in the system is necessary in order for relying parties (users and other organizations) to trust their authenticity and origin; it is also necessary for relying parties to be able to derive liabilities or accountability based on transactions and credentials with these keys. In the following section, we introduce an example application based on anonymous credentials; Section 7.8 illustrates the details of its certificate infrastructure and how it defines the liabilities and accountabilities of the various parties. 7.7 Designing an Application When designing an actual application scenario, we start with various sets of requirements. Requirements of authentication related to an organization s authorization decisions (called Rules in Chapter 6), can be translated into requirements on (assertions on) show transcripts ; by their relationship with the protocol primitives, these will in part determine which Idemix credentials need to be shown in order to fulfill organizations authentication requirements. Requirements of user accountability determine various other options such as signed or root nym registrations and de-anonymization. Users unidentifiability requirements then further narrow down the set of acceptable solutions. Of course, a user may have unidentifiability requirements which collide with an organization s accountability requirements; in practice, we will assume that a user using a organization s service accepts this service s accountability requirements. Fulfilling the user s requirements then consists of making sure that these accountability requirements are fulfilled with minimal linkabilities. This section describes an application using the various Idemix protocols. We show the design of the application based on its authentication, accountability and unidentifiability requirements using the assertions developed in Sections 7.3 to 7.5. Details of the linking of organizations and users key material to an external public-key infrastructure are discussed in Section 7.8 as part of a more general discussion on trust and certification.

144 Chapter 7. Designing Applications Using Idemix Anonymous Credentials 7.7.1 Introducing the LostFound Application LostFound is an online service where items can be traded on-line. Users can use LostFound to advertise and search for items, and can remain unidentifiable while doing so. All items should be traded for free, and users are not allowed to use the service for commercial purposes. Users pay a small fee for accessing the service during a certain amount of time; we allow for this fee to be paid by a non-anonymous bank transfer as long as the actual use of the service later on is unidentifiable. It is assumed that users cannot misuse the service when only searching for items. Thus, as long as users only retrieve information, access can be unconditionally unidentifiable. When users advertise (post) items, however, they can misuse the service by posting commercial or even illegal (e.g., drugs) advertisements. In the latter case, the misuse is considered criminal and the real identity of the user has to be provided to authorities. In the former case, LostFound simply wants to be able to revoke the user s subscription credential. De-anonymization is thus a clear requirement in the system: revealing an identity behind a transaction implies the need for global de-anonymization in posting transactions; revoking a credential implies local de-anonymization. We want to protect both users as well as organizations or authorities against uncorrect or unfair functioning of the de-anonymization process. Thus, we should give de-anonymization rights to a dedicated entity, a de-anonymizing organization, which is independent as well from users as from organizations or authorities in the system. From the above description of high-level requirements, we can already derive which are the organizations playing a role in the system, and what are the main interactions between users and organizations, as well as between organizations. LostFound is providing the actual service; a Root Authority (Root) ensures the external certification of users and issues the root credentials necessary for supporting the global de-anonymization process; a de-anonymization organization (DOrg) performs local and global de-anonymization. We also introduce a Kiosk organization implementing the function of verifying a bank payment or transfer and in return issuing an anonymous subscription credential for accessing LostFound. We make this choice in order to separate this functionality more clearly from the functionality of actually delivering the Lost- Found service; however, Kiosk and LostFound can be operated by the same business entity, and the unidentifiability of users should be preserved also if they share their user data. Figure 7.8 introduces the participants in the protocols with their various keys and certificates, and shows the protocol flows for registering with Root and Kiosk; Figure 7.9 shows the protocol flows related to accessing LostFound. Table 7.1 shows detailed assertions and primitive invocation parameters related to the exchanges in Figures 7.8 and 7.9. The reasoning behind the design of the actual protocol flows will be discussed in Section 7.7.4. First, we discuss the various organizations key material and certificates, and the general security requirements of the communication channels. 7.7.2 Key Material, External Certificates and Idemix Certificates Root (R) and Kiosk (K ) will issue Idemix credentials and thus need IssuerKeys; Kiosk and LostFound (L) will verify credentials and need VerifierKeys; DOrg (D) needs DeAnOrgKeys; and all organizations need keys for secure communication (see also Section 7.7.3). The user (U ), of course, has a UserSecret. As discussed in Section 7.6.3, all parties (users as well as organizations) have signature private keys SSKey X and corresponding public-key certificates Cert CA X in an external Public-Key Infrastructure certified by a Certification Authority CA. U uses this certificate, Cert CA U, for root nym registration with R; the organizations use their signature key pairs and certificates to self-certify their Idemix certificates (Cert R R, Cert K K, Cert L L and Cert D D ) containing their Idemix issuing, verification and de-anonymization public keys as well as communication public keys. Detailed contents of these certificates will be discussed and motivated in Section 7.8.3.

7.7. Designing an Application 145 Key Material: U (User): {SSKey U, Cert CA U }, UserSecret U R (Root): {SSKey R, Cert CA R}, {ISKey R, CSKey R, Cert R R} K (Kiosk): {SSKey K, Cert CA K}, {ISKey K, VSKey K, CSKey K, Cert K K} L (LostFound): {SSKey L, Cert CA L}, {VSKey L, CSKey L, Cert L L} D (DOrg): {SSKey D, Cert CA D}, {DSKey D, CSKey Dc, Cert D D} Root Nym Registration and Obtaining Root Credential: U : URegRootNym() Comm UR1 : RootNym UR, SignedNymProof UR R : ORegRootNym() R stores{orgnym UR, Sig UR, Cert CA U } U : UGetCred() Comm UR2 : Cred UR R : OIssueCred() R updates{orgnym UR, Sig UR, Cert CA U, CredInfo UR} Payment and Obtaining Kiosk Credential: U : URegNym() U : UShowCred() Comm UK1 : Nym UK Comm UK2 : WasShown UKR K : ORegNym() K : OVerifyCred() K stores {OrgNym UK, Transcript UKR } U : Send() U : UGetCred() Comm UK3 : Payment Comm UK3 : Cred UK K : Receive() K : OIssueCred() K updates {OrgNym UK, Transcript UKR, CredInfo UK} Figure 7.8: Example Application: Key Material and Registration Showing Credential To LostFound and Retrieving Data: U : UShowCred() U : Get() U : Get() Comm UL : WasShown ULK (Get) Comm UL : RetrievedData 1 Comm UL : RetrievedData 2 L : OVerifyCred() L : Process() L : Process() Showing Credential To LostFound and Posting Data: U : UShowCred() Comm UL : WasShown ULK (P ost) L : OVerifyCred() L stores Transcript ULK (P ost) Figure 7.9: Example Application: Accessing LostFound

146 Chapter 7. Designing Applications Using Idemix Anonymous Credentials Table 7.1: Example Application: Parameters of Assertions and Primitives RootNym UR RootNym(UserSecret U, OrgNym UR, UserNym UR ) SignedNymProof UR Cred UR SignedNymProof(Sig UR, Cert CA U, OrgNym UR, null) Cred(OrgNym UR, UserCred UR, CredInfo UR) Nym UK Nym(UserSecret U, OrgNym UK, UserNym UK ) WasShown UKR WasShown(Transcript UKR, UserCred UR, CredShowInfo UKR, CredShowFeatures UKR, OrgNym UK, null) Cred UK Cred(OrgNym UK, UserCred UK, CredInfo UK) WasShown ULK (Get) WasShown(Transcript ULK (Get), UserCred UK, CredShowInfo ULK, CredShowFeatures ULK (Get), null, null) WasShown ULK (P ost) WasShown(Transcript ULK (P ost), UserCredUK, CredShowInfoUL K, CredShowFeatures ULK (P ost), null, PostedMessage) CredInfo UR CredShowInfo UKR CredShowFeatures UKR CredInfo UK CredShowInfo ULK CredShowFeatures ULK (Get) CredShowFeatures ULK (P ost) {IPKey R, true, Expiration UR, null} {IPKey R, any, Expiration UKR, any} {true, VPKey K, {DPKey D, CriminalMisuseCond}, null} {IPKey K, true, Expiration UK, null} {IPKey K, any, Expiration ULK, any} {false, VPKey L, null, null} {false, VPKey L, {DPKey D, CriminalMisuseCond OtherMisuseCond}, null} 7.7.3 Security of the Communication Channels Authentication, Integrity and Confidentiality In Figures 7.8 and 7.9, a communication channel between parties X and Y is represented as Comm XY[i] ; the optional subscript indicates the sequence number in case X and Y execute multiple exchanges over potentially different communication channels. All communication channels are at least one-way authenticated (Y to X, indicated by underlining Y in Comm XY i ) and integrity-protected. This can be realized by an SSL-type server authentication (with CSKey Y ) and session key establishment, and consecutive integrity-protection of the communication using the established session key. The authentication and integrity-protection allow the originator X to make sure it is communicating with the correct (issuing, verifying or de-anonymizing) organization Y. We state this requirement in order to avoid denial-of-service situations such as a user establishing a nym with another organization than the intended one, or a user showing a credential to another organization than the one from which he expects a service. The need for confidentiality-protection depends on the data being exchanged on the communication channel. The communication channels transporting only Idemix protocols carry the cryptographic Idemix protocol exchanges, as well as meta-information exchanged by the state machines driving those cryptographic protocols. The cryptographic exchanges themselves do not exchange any information from which secrets can be derived. Meta-information consists of information such as which credential is requested and issued on which nym, or which credential is shown relative to which nym. The following lists, for the various Idemix protocols between a user and an organization, the information which can be derived

7.7. Designing an Application 147 by an observer of the exchange. The use of subscripts to indicate parameter instances is the same as in Figures 7.1, 7.4 and 7.5. URegNym() ORegNym(): OrgNym UI The exchange during a nym registration procedure allows any observer to derive the resulting OrgNym; URegSignedNym() ORegSignedNym(): OrgNym UI, Cert CA U, Sig UI, [Msg UI ] When registering a signed nym, the user additionally sends the external certificate, the signature, and the message to be signed; this meta-information is visible also to an observer; URegRootNym() ORegRootNym(): OrgNym UR, Cert CA U, Sig UR, [Msg UR ] With a root nym registration, an observer acquires the same information as with a normal signed nym registration; UGetCred() OIssueCred(): OrgNym UI, CredInfo UI During a credential issuing exchange, the user has to send meta-information to the issuer indicating on which nym he wants which type of credential. This meta-information is visible to an observer of the communication; UShowCred() OVerifyCred(): CredShowInfo UV, CredShowFeatures UV, [OrgNym UV ], [Msg UV ] When showing a credential, the user sends meta-information to the issuer indicating what he wants to show about the credential, the specific protocol options and possible parameters for deanonymization, (optionally) the nym relative to which the credential is shows, and (optionally) a message to be signed. This meta-information is visible to observers. Thus, with exception of the potential linkabilities towards de-anonymizers or credential issuers resulting from de-anonymization or showing a one-show credential (see Sections 7.5.10 and 7.5.11), an observer acquires the same linkability information as the organization(s) participating in the exchanges. This is not a problem, as the Idemix protocols are designed exactly to protect a user s unidentifiability also towards these organizations. The communication channels carrying Idemix protocols need thus not be confidentiality-protected as long as the communication channel provides sender anonymity. The only reason, then, for protecting the confidentiality of data transmitted over these communication channels would be that the organization considers the exchanges to be business-sensitive information: e.g., the organization does not want observers to know how many credentials of a certain type he issued, or how many times he verified a certain type of credential to authorize service access. We can thus conclude that the user s unidentifiability does not depend on the confidentiality-protection of his Idemix exchanges; again, as long as the sender anonymity of the communication channel is protected. As to the need for confidentiality-protection of communication channels transporting application data, we can state the following: The data retrieved from and posted to L is publicized at some point. Thus, as long as the user retrieving or posting it remains unidentifiable, encrypting this information does not additionally protect the user s privacy. Again, confidentiality-protection may be more in the interest of L, who may want to make sure that only paying customers can look at the data posted or retrieved. Another type of application data is the data exchanged for the non-idemix payment. As the user does not expect this payment to be anonymous, a simple account or user identifier in the payment may not need confidentiality-protection. Of course, if sensitive information such as a credit card number is exchanged, it would need appropriate confidentiality-protection; this should be taken care of by the payment protocol used.

148 Chapter 7. Designing Applications Using Idemix Anonymous Credentials Sender Anonymity As discussed in Section 7.2.1, anonymity at the application level has to be supported also by anonymity of the user at the communication level. We assume the use of one of the methods mentioned for anonymyzing the user in a communication; some of these methods provide their own integrity- or confidentialityprotection. Linking In some cases, a sequence of several exchanges (such as showing a credential and receiving a new credential) have to be securely linked in one authenticated communication session in order to ensure the desired application-level security. These cases will be discussed on an individual basis. 7.7.4 Protocols for Registration and Service Access We now derive the protocols satisfying the various requirements. By discussing the requirements from organizations and users for specific exchanges (e.g., posting application data), we will derive the exact protocol flows as depicted in Figures 7.8 and 7.9, as well as the contents of their parameters in Table 7.1. For each exchange, we will analyze the following requirements: Organization requirements: which condition(s) has (have) to be fulfilled: the receipt of a payment (an Idemix-external condition), or the verification of an Idemix credential; Idemix linkability and de-anonymization requirements: e.g., an Idemix transaction has to be securely linked to a nym, or to another Idemix transaction; or, it has to be de-anonymizable; application linkability requirements: e.g., an Idemix transaction has to be securely linked to an actual application action (e.g., obtaining the actual service or data has to be linked to showing the necessary credential). The first two sets of requirements define the Idemix access rules as defined in Chapter 6; in case of a credential show condition, they define the CredShowInfo and CredShowFeatures for the credential show invocation. The third set of requirements will define whether a secure communication channel has to link an Idemix transaction to an application action. User requirements: whether the transaction may or may not be linkable in a certain way to a user s identity or nyms. Requirements such as de-anonymization are related to the final application between U and L; they create requirements for the exchanges between U and K ; these will in turn show the need for a root credential and root nym registration. Thus, we will start the analysis with the final exchange which is the actual application: retrieving data from, or posting data to, LostFound. Retrieving Data from LostFound Organization Requirements U may retrieve (Get()) application data (RetrievedData) from L on condition of having paid for the service; payment for the service can be proved by a credential from K (with an appropriate expiration). There is no need for U to sign an additional message in the show transcript. Thus, a WasShown ULK (Get) is required with:

7.7. Designing an Application 149 CredShowInfo ULK = (IPKey K, any, Expiration ULK, any), WasShown ULK (Get).Msg = null The use of any means that so far there is no requirement by L on the value of the parameter or field. The access need not be identifiable; thus, no linkability with a nym or de-anonymization is required; this means there are no requirements on CredShowFeatures ULK(Get) other than the specification of L (VPKey L ) as verifier: CredShowFeatures ULK(Get) = {any, VPKey L, any, any} Showing the credential and retrieving the data should be linked by the same communication channel in order to make sure that the data is delivered to the user who showed the credential. User Requirements To fulfill the access condition, U will show a credential with CredInfo UK fulfilling CredShowInfo ULK. I.e., CredInfo UK = {IPKey K, any, Expiration UK, any}, with Expiration UK Expiration ULK U requires the access to be unconditionally unidentifiable, and thus unlinkable to any nym or identity. Neither CredShowInfo ULK nor WasShown ULK(Get).Msg is unique (we do not consider the expiration date in CredShowInfo as an attribute that makes a credential show unique); according to Section 7.5.7, the credential show is unconditionally unidentifiable if it is neither relative to a nym, nor de-anonymizable, regardless of the number of accesses: Thus, U also chooses CredShowFeatures ULK(Get) = {false, VPKey L, null, null}, CredInfo UK.MultiShow = CredShowInfo ULK.MultiShow = true WasShown ULK(Get).OrgNym = null Also, as L does not require any specific attribute for the kiosk credential: U may prefer that to avoid any identifiability through attributes. CredShowInfo ULK.Attrs = any, CredInfo UK.Attrs = null Figure 7.9 shows the user retrieving data after showing the credential. After WasShown ULK (Get), U can perform a number of Get() operations within the same secured communication session Comm UL, fulfilling the organization s requirement to link the showing of the credential to the retrieval of the data; L processes them but need not store any transcripts. Posting Data to LostFound Organization Requirements

150 Chapter 7. Designing Applications Using Idemix Anonymous Credentials U may post application data (PostedMessage) to L on condition of having paid for the service; payment for the service can be proved by a credential from K of the same type as for retrieving data. Thus, a WasShown ULK(P ost) is required with the same CredShowInfo as for data retrieval: CredShowInfo ULK = {IPKey K, any, Expiration ULK, any} The transaction needs both global and local de-anonymization, depending on criminal or other misuse. As K and L belong to the same business entity, the issuer (K ) of the credential can be assumed to be cooperating with the verifier (L) and can guarantee the global de-anonymization. E.g., using the technique in Section 7.6.1, L then needs to implement only local de-anonymization in order to also allow global de-anonymization in case of criminal misuse. De-anonymization is the responsability of the dedicated de-anonymization organization D: CredShowFeatures ULK(P ost) = {any, VPKey L, {DPKey D, CriminalMisuseCond OtherMisuseCond}, any} In designing our application, we have assumed the presence of a Root organization R; we will refer to the nyms and credentials it issues as root nyms and root credentials. However, by choosing to realize global de-anonymization using local de-anonymization, we will not actually exploit the specific fact that the nyms R registers are root nyms (RootNym()). However, we do rely on R to ensure a linking between the nyms it registers and external certificates; we will, thus, exploit the fact that R registers signed nyms. To be precise, we rely on R to only issue a credential (as accepted by K ) on a nym which was registered in a signed nym registration procedure using a signature key and certificate for which a user can be held accountable. L has another requirement: if ever de-anonymization occurs, it does not suffice to prove the linking between U and the credential show; the linking between the user and the posted message must also be provable to a third party in order to guarantee U s accountability for the posted information. This cannot be achieved by linking the credential show and the posting through a secure communication channel, as such a linking cannot be proved to other parties. A provable linking can only be achieved if the posted message is also signed with the credential: WasShown ULK(P ost).msg = PostedMessage As the PostedMessage application data is already linked to the credential show, no additional application linking is needed. User Requirements U requires the access to be unlinkable to any nym or identity unless one of the above specified conditions for de-anonymization is fulfilled. WasShown ULK(P ost).msg is unique but does not occur in any other transaction; we do not consider CredShowInfo ULK unique (verification of the expiration date should not make a credential show unique); from Sections 7.5.7 to 7.5.11, we then conclude that the user requirement is fulfilled if there are no other ways of de-anonymizing, and if the show is not relative to a nym: CredShowFeatures ULK(P ost).globaldeandata = null, CredShowFeatures ULK(P ost).relnym = false, and thus also WasShown ULK(P ost).orgnym = null Figure 7.9 shows the posting of data. L processes the request and stores Transcript ULK(P ost). In case of misuse, this will ensure that L and K can perform the necessary de-anonymization to take measures, as discussed in Section 7.7.5.

7.7. Designing an Application 151 Obtaining the Credential from Kiosk In this procedure, K issues the credential to access L on condition of having received the appropriate payment. The payment can be any form of electronic payment and need not be anonymous (e.g., it can be a secure credit-card payment). Organization Requirements K issues a credential only on the nym of a user who paid. Thus, either the credential issuing or the nym registration has to be securely linked to the payment. Also, K issues a credential on a nym only if K knows it can retrieve the user s root nym if the global de-anonymization condition is fulfilled. We decided earlier that local de-anonymization of a root credential show suffices for this. Thus, the procedure involves a Nym UK establishment (necessary to issue the credential Cred UK on), a locally de-anonymizable root credential show WasShown UKR, a payment, and the credential issuing Cred UK. The root credential show can be securely linked to Nym UK by making it relative to Nym UK. The payment can be securely linked to the credential issuing by a secure communication channel. Cred UK s CredInfo UK was already specified in the previous paragraphs. As for WasShown UKR, it requires a credential issued by R with a certain expiration limit and no specific attributes, local de-anonymization (in case of criminal misuse only) and a showing relative to Nym UK and verifiable by K : User Requirements CredShowInfo UKR = {IPKey R, any, Expiration UKR, any}, CredShowFeatures UKR = {true, VPKey K, {DPKey D, CriminalMisuseCond}, any}, WasShown UKR.OrgNym = Nym UK. To fulfill WasShown UKR, U shows a credential with CredInfo UR fulfilling CredShowInfo UKR. Thus, CredInfo UR = {IPKey R, any, Expiration UR, any} with Expiration UR Expiration UKR WasShown UKR is directly linked to Nym UK. U s requirement is that the link between Nym UK and a root nym or real identity is revealed only when the local de-anonymization condition is fulfilled, and that there are no other ways of de-anonymizing (regardless of the number of uses of the root credential). As CredShowInfo UKR is not unique (except for the expiration, which we do not consider an identifying factor), and WasShown UKR.Msg = null, it follows that Also, as the user may prefer that CredShowFeatures UKR.GlobalDeAnData = null CredInfo UR.MultiShow = true CredShowInfo UKR.Attrs = any, CredInfo UR.Attrs = null to avoid any identifiability through attributes in the root credential. Figure 7.8 shows the protocol flows. The payment and the issuing of the credential both use the same secure communication channel Comm UK3, fulfilling K s requirement for linking these two exchanges.

152 Chapter 7. Designing Applications Using Idemix Anonymous Credentials Note that the order of the exchanges could be changed, as long as K has the same guarantees: namely, that the credential is issued to someone who paid, and on a nym that can be linked with a root nym. This guarantee could also be achieved by securely linking the payment with Nym UK establishment in Comm UK1, instead of linking it with the Cred UK issuing in Comm UK3. Registering to Root The goal of this procedure is for U to obtain the root credential needed to prove registration with R and therefore a linking with an external certificate. U will have to show this credential in order to obtain a subscription credential from Kiosk. As mentioned before, the fact that R issues root nyms (RootNym()) as opposed to regular nyms (Nym()) is strictly speaking not exploited by our choice of de-anonymization procedure; we could thus replace the root nym registration with a signed nym registration procedure. Root nym registration and root credential issuing are standard procedures: R requires that it knows a provable linking between the root nym with an external certificate before issuing the root credential on it; the contents of Cred UR were discussed in previous paragraphs. The user knows that his root nym and root credential (the latter if shown in a de-anonymizable way) are linkable to his external certificate Cert CA U. One parameter option still to be chosen is the contents of Msg UR during root nym registration (SignedNymProof UR ): as Root needs no other evidence than the linking with Cert CA U, we can conclude that SignedNymProof UR.Msg = null. Figure 7.8 shows the root nym registration and root credential issuing. After the root nym registration, R stores the mapping between OrgNym UR and Cert CA U (and the evidence Sig UR of this mapping). After issuing the root credential, R updates this information with CredInfo UR. Note that absence of authentication of R to U on Comm UR1 would allow another organization to impersonate R. The impersonator would know a linking between U s real identity and the established nym, and U would assume the nym is shared with R. However, the impersonator could not issue a root credential on the nym, as this credential issuing would require the knowledge of IssuerKeys R. The user would not be able to perform any operations with the nym. The only threat is thus one of denial of service. Absence of authentication of R to U on Comm UR2 poses no threat as the issuing of the credential includes an authentication of R using its IssuerKeys R. 7.7.5 Verifying Organizations Accountability Requirements In this Section, we now verify that our design satisfies our accountability goals. I.e., we verify that, after a message posting, L and K have the appropriate information to, together, locally or globally de-anonymize the transaction. We illustrate the correctness of the de-anonymization results by applying the derivation rules in Section 7.4 to the actual parameters of this transaction. Figure 7.10 shows the de-anonymization steps in a possible scenario. We have assumed de-anonymization with proof: this will allow any party relying on the de-anonymization result to verify its correctness; but also, to hold D accountable for the de-anonymization (see also Section 7.8.1). After any message posting, the assertions RootNym UR, SignedNymProof UR, Cred UR, Nym UK, WasShown UKR, Cred UK, and WasShown ULK(P ost) hold, with the respective parameters as in Table 7.1. When the content PostedMessage of a data posting transcript shows misuse, L can send the associated Transcript ULK(P ost) to D with the request to de-anonymize it; this de-anonymization returns OrgNym UK and the correctness proof DeAnTranscript DUL. This can be derived as follows: From Table 7.1: Nym(UserSecret U, OrgNym UK, UserNym UK ), Cred(OrgNym UK, UserCred UK, CredInfo UK ),

7.7. Designing an Application 153 WasShown(Transcript ULK(P ost), UserCred UK, CredShowInfo ULK, CredShowFeatures ULK(P ost), null, PostedMessage), CredShowFeatures ULK(P ost).localdeandata.dpkey = DPKey D. From Section 7.4.1, it follows that an invocation of DODeAnonLocalWProof({DSKey D, DPKey D }, Transcript ULK(P ost) ) will return DeAnTranscript DUL with LDeAnProof(DeAnTranscript DUL, Transcript ULK(P ost), OrgNym UK ) Based on OrgNym UK and the data posting transcript with PostedMessage provided by L, K can decide whether or not to revoke Cred UK. In case of misuse motivating global de-anonymization, the second de-anonymization step will also be executed in order to provide for global de-anonymization of WasShown ULK(P ost). K then retrieves the stored {OrgNym UK, Transcript UKR, CredInfo UK }. From Table 7.1: WasShown(Transcript UKR, UserCred UR, CredShowInfo UKR, CredShowFeatures UKR, OrgNym UK, null) From Section 7.3.6, it follows: SigProof(Transcript UKR, CredShowInfo UKR, CredShowFeatures UKR, OrgNym UK, null) Thus, K can prove the relationship between Transcript UKR and OrgNym UK. K then asks D for local de-anonymization of Transcript UKR to obtain OrgNym UR (and DeAnTranscript DUK ): From Table 7.1: Step 1: De-anonymization to retrieve OrgNym UK L : Send() L : Receive() Comm LD1 : Transcript ULK (P ost) Comm LD1 : OrgNym UK, DeAnTranscript DUL D : Receive() D : DODeAnonLocalWProof() D : Send() Step 2: De-anonymization to retrieve OrgNym UR K : Send() K : Receive() Comm KD1 : Transcript UKR Comm KD1 : OrgNym UR, DeAnTranscript DUK D : Receive() D : DODeAnonLocalWProof() D : Send() Figure 7.10: Example Application: Local and Global De-Anonymization

154 Chapter 7. Designing Applications Using Idemix Anonymous Credentials WasShown(Transcript UKR, UserCred UR, CredShowInfo UKR, CredShowFeatures UKR, OrgNym UK, null), CredShowFeatures UKR.LocalDeAnData.DPKey = DPKey D From Section 7.4.1, it follows that an invocation of DODeAnonLocalWProof({DSKey D, DPKey D }, Transcript UKR ) returns DeAnTranscript DUK with LDeAnProof(DeAnTranscript DUK, Transcript UKR, OrgNym UR ) With OrgNym UR, K can obtain the associated Cert CA U from R, who has stored {OrgNym UR, Cert CA U, Sig UR, CredInfo UR }. Note that the linking between OrgNym UR and Cert CA U is also a provable linking according to (from Table 7.1): SignedNymProof(Sig UR, Cert CA U, OrgNym UR, null) Thus, from a post transcript, D can locally de-anonymize Transcript ULK(P ost) to obtain OrgNym UK ; K can link OrgNym UK to a Transcript UKR, D can de-anonymize Transcript UKR to obtain OrgNym UR, and R can link OrgNym UR to Cert CA U. Each of the linkings is provable, as can be seen from the framed statements. We now discuss the security requirements on the communication channels used, and other requirements related to authentication in the de-anonymization exchanges. Also here, we assume at least one-way (D to L and D to K ) authentication in order to protect against denial-of-service attacks, and to prevent sending sensitive information to a non-authorized party. As the de-anonymization result is sensitive information, it is important that in both cases D s response is sent only to the requestor of the deanonymization. This can be achieved by ensuring that the response is sent over the same secured (integrity-and confidentiality-protected) communication channel. Most likely, D also wants to authenticate the sender of the request: first, D does not want to be used as a de-anonymization oracle; second, it is probable that the requesting organization has to be authenticated in order to securely verify the de-anonymization condition. Authentication by the requestor can be achieved by using also client-side authentication in the communication channel using CSKey L, resp. CSKey K. Such a two-way authenticated communication channel is depicted in Figure 7.10 as Comm KD. Alternatively, L and K could sign the requests to D using their signature key (SSKey L, resp. SSKey K ). This makes L, resp. K, accountable for the de-anonymization request itself. This may be preferable, e.g., if D, when having de-anonymized a transcript, needs to be able to prove that the de-anonymization indeed was requested by the specific organization. Note that DeAnTranscript DUK (DeAnTranscript DUL ) also includes the equivalent of a signature (with DSKey D ) and therefore is also implicitly authenticated by D. This is a stronger authentication than the authentication on the communication channel, as it also makes D accountable for the de-anonymization of the transcript itself as discussed in Section 7.8.1. 7.7.6 Verifying User Unidentifiability Requirements In this section, we verify that the user s unidentifiability requirements are met. According to Section 7.5, we can derive following linkability assertions from the credential, nym and transcript assertions that hold after registration and payment.

7.7. Designing an Application 155 RootNym UR. SignedNymProof UR (1) Linked(R, null, OrgNym UR, Cert CA U ). As SignedNymProof UR.Msg = null, no additional linking results from SignedNymProof UR. Cred UR, Unique(CredInfo UR ). As CredInfo UR is generic (not unique for the credential instance), no linking results from Cred UR. Nym UK. WasShown UKR, CredShowFeatures UKR.RelNym = true (2) Linked(K, null, Transcript UKR, OrgNym UK ). WasShown UKR, CredShowFeatures UKR.LocalDeAnData.DPKey = DPKey D, Cred UR, Nym UR (3) Linked(D, CriminalMisuseCond, OrgNym UR, Transcript UKR ). As neither CredShowInfo UKR nor WasShown UKR.Msg (= null) are unique, no other linkabilities result from WasShown UKR. With the Cred UK credential obtained, U can now retrieve data or post messages; these transactions may add additional linkability information. Data Retrieval Data retrieval is not relative to a nym, has no de-anonymization option and no unique parameters and thus does not result in linkability information. Data retrieval is thus unconditionally unidentifiable, which is consistent with requirements. WasShown ULK(Get). Message Posting Message posting results in an additional WasShown ULK(P ost) assertion. WasShown ULK(P ost).msg (= PostedMessage) is unique, but does not occur in any other transaction. Thus, the only linkability follows from de-anonymization: WasShown ULK(P ost), CredShowFeatures ULK(P ost).localdeandata.dpkey = DPKey D, Cred(OrgNym UK, UserCred UK, CredInfo UK ), Nym(UserSecret U, OrgNym UK, UserNym UK ) (4) Linked(D, {CriminalMisuseCond OtherMisuseCond}, OrgNym UK, Transcript ULK ). The user can conclude that only OrgNym UK can be linked to the post transcript, and only in case of one of the misuses mentioned. From (2), OrgNym UK can directly be linked to Transcript UKR and, from (3), Transcript UKR to OrgNym UR in case of criminal misuse. From (1), OrgNym UR can directly be linked

156 Chapter 7. Designing Applications Using Idemix Anonymous Credentials to the user s identity in Cert CA U. This is consistent with requirements. 7.8 Trust, Accountability, Liability and Certification This section deals with measures needed to create a system where users can trust the correct application of mechanisms protecting their unidentifiability, and organizations can trust the correct functioning of mechanisms guaranteeing user accountability. We use the Lostfound application developed in Section 7.7 to illustrate the challenges as well as the solutions. Users fundamentally mistrust organizations: they expect organizations to collaborate with each other and to combine their knowledge; any unconditional linkability, as well as any conditional linkability of which the condition is fulfilled, can be considered public. E.g., the linking of a user s external certificate to his root nym is public; unidentifiability is threatened only when a user executes an action which is traceable to that root nym. From the linkabilities described in Section 7.5, the ones resulting from de-anonymization and doublespending are the only conditional ones. As for double-spending, the user can control the fulfillment of the condition; in addition, the linkability is technically unfeasible if the condition is not met. The case is different for de-anonymization: the user may have less control over the fulfillment of the condition (e.g., because it is subject to interpretation); in addition, we assume de-anonymization to be technically feasible even if the condition is not fulfilled. De-anonymization thus takes a special place in a discussion about trust: it can have a far-reaching (negative) effect on users unidentifiability; while at the same time being the only process where trust by users is required. In Section 7.8.1, we investigate trust required specifically in the de-anonymization process. As many of the issues are relevant to both users and organizations, we discuss trust in de-anonymization from both users and organizations point of view. We discuss how accountability and verifiability of the de-anonymization process can help safeguarding fairness. These measures limit the need for blind trust by at least exposing and proving untrustworthy behaviour. Section 7.8.2 then specifically discusses trust required by organizations in the system. Some issues are similar to the ones discussed for the case of deanomymization; we again discuss measures that expose misbehaviour by other organizations. Exposure of misbehaviour or cheating may discourage such behaviour; it does, however, not provide any guarantees that it is punished. Section 7.8.3 deals with these guarantees through liability-enhanced certification as introduced in Chapter 5. In Section 7.8.1, we then illustrate the concepts introduced in this section using a LostFound de-anonymization scenario. 7.8.1 Trust by Users and Organizations in De-Anonymization In the LostFound application, organizations accountability requirements are fulfilled by the application of local and global de-anonymization, on condition of misuse being shown; from the users perspective, their unidentifiability is unconditionally protected during information retrieval; for information posting, it is conditional on the absence of misuse. In order for the de-anonymization process to work as expected by both users and organizations, the following have to be fulfilled: Conditions under which accountability (de-anonymization) is needed have to be stated in a concrete enough way that D can either evaluate them automatically, or can at least make an evaluation which can be considered fair by both parties (the user and the entity requesting de-anonymization); The de-anonymizer acts correctly, i.e., de-anonymizes if and only if the condition is fairly evaluated to be true.

7.8. Trust, Accountability, Liability and Certification 157 The latter condition requires trust by users, who do not want unmotivated de-anonymization to occur, as well as by the organizations who need to rely on de-anonymization in order to fulfill accountability requirements. In the following paragraphs, we discuss the fairness of condition evaluation and deanonymization, and ways to increase fairness (or decrease the amount of trust) through verifiability. Fairness of Condition Evaluation In fact, the entity evaluating the de-anonymization condition need not be the de-anonymizer D: just as liability conditions in certificates can be subject to evaluation by a trusted Arbiter, de-anonymization conditions may be subject to evaluation by an Arbiter (or multiple Arbiters) other than the de-anonymizer. E.g., in CredShowFeatures UKR, CriminalMisuseCond = {CriminalMisuseDesc, SPKey LE } would indicate that D is allowed to de-anonymize if LE (a Law Enforcement entity) has attested, by a signature using its signature key SSKey LE, that criminal misuse (as described in the description CriminalMisuseDesc) has occurred. OtherMisuseCond = {OtherMisuseDesc, SPKey L, SPKey A } could indicate that D is allowed to de-anonymize if LostFound as well as an arbiter organization A have attested that other misuse (as described in OtherMisuseDesc) has occurred. This separation of responsibilities has the advantage of separating Idemix functionality from high-level application (and possibly human) condition evaluation, and potentially allows to automate the condition evaluation by de-anonymizers; also, it facilitates the definition of conditions that have to be evaluated by multiple Arbiters. The separation between condition evaluation and de-anonymization may also result in an additional distribution of trust. For this to be the case, D s de-anonymization actions should be verifiable, as discussed in the next paragraph. Verifiability of De-Anonymization: Correctness and Accountability Verifiability of the de-anonymizers actions by both users and organizations helps to reduce the level of trust required. It should be verifiable that D performed a certain de-anonymization (accountability), and that the de-anonymization was correct w.r.t. the de-anonymized transcript (correctness). Both accountability and correctness are achieved if de-anonymization is always accompanied by the proof of correctness. Thus, users as well as organizations can verify (and prove to another entity) who performed a de-anonymization, and whether it was correct. User Trust Requirements Related to De-Anonymization Trust requirements by the user in the system are thus minimized through distribution of trust, separation of duties and verifiability of actions. When a user U shows a credential issued by issuer I to verifier V, I and V together can under no condition (unless in case of double-spending of a one-show credential) identify the user or its OrgNym U. This is true even if the credential was shown in a de-anonymizable way: the introduction of a deanonymizing organization D as the only entity to be able to identify the user or OrgNym UI is a first separation of duties (and trust), and protects the user against coalitions of issuers and verifiers. As to the trust in a de-anonymization organization D: if a user has a choice between multiple deanonymizers, this reduces trust requirements; as discussed in the previous paragraphs, the (verifiable)

158 Chapter 7. Designing Applications Using Idemix Anonymous Credentials evaluation of de-anonymization conditions by dedicated (sets of) Arbiters, and the verifiability of the de-anonymization itself, introduces an additional separation of trust. Accountability, verifiability and correctness need of course to be backed by appropriate liability of (in this case) the de-anonymization organization for its actions, or by a liability of the entity certifying D to revoke D s keys in the event of D malfunctioning or misbehaving. These liabilities are discussed in Section 7.8.3. Of course, revocation of keys does not solve (or appropriately punish) a misbehavior or malfunctioning resulting in DSKey D being stolen or even published. In such a case, D has to be held accountable for existing transcripts being de-anonymized without reason. In conclusion, accountability and correctness, together with verifiable fairness of condition evaluation, protect a user from being unfairly accused of actions he did not perform, and of losing his unidentifiability without a valid reason. Organizations Trust Requirements Related to De-Anonymization K and L in our example application, in order to rely on a fair de-anonymization, need to rely on D to de-anonymize transcripts according to evaluated de-anonymization conditions. Verifiable fairness of condition evaluation, together with accountability and correctness of the process of de-anonymization, also provide organizations such as K and L with a guarantee that de-anonymization is done correctly and fairly. However, for organizations, an additional source of unfairness could be that D is not available, or not willing to respond to a request. This type of unfairness can be dealt with by introducing a Fairness-Arbiter in the system: such an arbiter can be used as an intermediary in de-anonymization (and other) requests and can evaluate whether there is a response, and whether it is of the expected form. E.g., in the case of de-anonymization, the Fairness-Arbiter could verify that the response is either a de-anonymization result, or a (signed) motivation why de-anonymization could not be performed, e.g., the absence of a positive condition evaluation. Though K and L (or any entity relying on de-anonymization) need to rely on D for de-anonymization, D s liabilities are concrete and can be high, as explained in the next section. Thus, the trust in the correct functioning of accountability need not be higher than in a conventional PKI. In a conventional PKI, every transaction is linked to the same (non-anonymous) certificate issued by a CA. However, in order to realize accountability for a transaction, CA still may have to cooperate to map an identity in a certificate to a real human identity; in addition, typical CA liabilities for guaranteeing such a mapping are unclear or nonexistent. 7.8.2 Trust by Organizations in the System For relying on correct functioning of the system, organizations have to trust more than only the deanonymization process and de-anonymizing organizations. Firstly, in order for accountability requirements to be fulfilled, they also need to rely on obtaining public information from each other. In the LostFound application (see Section 7.7.5), R needs to be relied on to make available (through publicizing or on request) the linkings between external certificates and root nyms; K has to be relied on to make available root credential show transcripts of all the nyms on which it issued subscription credentials. Secondly, depending on business agreements and contracts, organizations may have obligations to each other subject to certain credentials being shown. E.g., an organization accepting e-coins issued by an e-bank as payment for a service expects that the e-bank will endorse a spent e-coin with real money. Depending on the business relationship between L and K in the LostFound example, K may need to pay the subscription amount paid by a user to L. Fairness of (and thus trust in) all these processes again requires accountability and verifiability of the actions leading to such an obligation. It can be verified that an e-coin issued by a specific e-bank was spent, and it can be verified that the e-bank did (or did not) endorse the e-coin by crediting the receiving

7.8. Trust, Accountability, Liability and Certification 159 Table 7.2: Certificate Contents for the LostFound Example Cert CA U S CA(CertdKeys = {SPKey = SPKey U }, Attrs = {CertTp = CERT, Liab = Liab CA U }) X {R, K, L, D} Cert CA X Cert X X S CA(CertdKeys = {SPKey = SPKey X }, Attrs = {CertTp = CERT, Liab = Liab CA X}) S X(CertdKeys = CertdKeys X X, Attrs = Attrs X X) Attrs X X {CertTp = SELFCERT, Liab = Liab X X, Addr = Addr X, Rules = Rules X, Contr = Contr X} CertdKeys R R {IPKey = IPKey R, CPKey = CPKey R } CertdKeys K K {IPKey = IPKey K, VPKey = VPKey K, CPKey = CPKey K } CertdKeys L L {VPKey = VPKey L, CPKey = CPKey L } CertdKeys D D {DPKey = DPKey D, CPKey = CPKey D } organization s bank account. As mentioned before, verifiability and accountability may discourage but do not prevent misbehaviour; nor do they specify consequences (liabilities or punishments) for the misbehaving party. In the following section, we discuss the application of liability-enhanced certification to users and organization s certificates. 7.8.3 Certificates, Liabilities and Contracts Accountability of organizations or users for any Idemix-related actions needs to be based on appropriate registration and certification procedures for users and organizations in the system; appropriate certification has to involve a liability of the certifier for actions with the certified key: User accountability is based on the enforced use of signed (in this case root) nym registration and the existence of an external certificate Cert CA U, guaranteeing a linking to a legal entity. Accountability of a de-anonymizing organization D is based on the fact that DPKey D is certified by D s signature key; this certification (and liability) has a value because D s signature public key SPKey D itself is certified by an entity, CA, who can make guarantees about or state liability for D (e.g., to revoke D s keys upon misbehaviour or malfunctioning). A credential based on a credential issuing key ISKey I has a value through appropriate selfcertification of IPKey I by I using its signature key SSKey I ; the signature public key SPKey I again is certified by CA, which provides a guarantee for actions or certificates signed with SSKey I. Not only Idemix keys (issuing, verification and de-anonymization) and signature keys have to be certified; also the keys used for communication (e.g., SSL) have to be certified in order to provide secure authentication, integrity and confidentiality of communication channels. We now discuss the certificate infrastructure for our example application described in Section 7.7. Table 7.2 shows the contents of various certificates, using the generalized certificate notation of Table 5.1. Users External Certificates The users external certificate Cert CA U is certified by a certification authority CA; it contains the user s (signature) public key SPKey U as well as Liab CA U, the liabilities of the certifying party. Cert CA U,

160 Chapter 7. Designing Applications Using Idemix Anonymous Credentials as well as the other certificates discussed in the following paragraphs, may contain additional attributes such as expiration time which are not discussed here. The main function of Cert CA U is to guarantee an unconditional linking with a human user. Therefore, Liab CA U carries a high liability for guaranteeing this linking: Liab CA U = {{LiabTp=Li, LiabAmount=$100000, LiabCond=none, LiabVerifier=none}} indicates an unconditional (LiabCond=none, LiabVerifier=none) liability of $100000 for providing, to a party relying on a signature with SSKey U, the identity (LiabTp=Li) of a human user owning the certificate. Organizations External Certificates An organization X s external certificate Cert CA X follows the same format as the user s. Liab CA R, Liab CA K, Liab CA L and Liab CA D probably contain a liability for certain of the attributes Attrs CA X of these organizations. In addition, parties relying on these certificates want a liability for the correctness of these organizations actions. As CA probably cannot take financial liability for these, its liability may be limited to ensuring that behind each of these organizations there is a legal entity that can be held responsible for incorrect actions. This is essentially again a liability of type Li: every organization can be held accountable for its actions. Liab CA X = {{LiabTp=Ld, LiabAmount=$100000, LiabCond= attrs incorrect, LiabVerifier=Arbiter}, {LiabTp=Li, LiabAmount=$100000, LiabCond=none, LiabVerifier=none}} indicates that CA takes a data (LiabTp=Ld) liability of $100000 for correctness of Attrs CA X (as witnessed by Arbiter), and an unconditional identification (Li) liability of $100000 for mapping the entity X to a liable human party or other legal entity. X can now express concrete liabilities for actions in its self-certified Idemix certificates. Alternatively or additionally to this Li liability, CA may express a liability for revoking Cert CA X in certain cases of misbehaviour. Organizations Idemix Certificates Depending on the role of the organization, its Idemix self-signed certificate Cert X X certifies one or more other public keys IPKey X, VPKey X, DPKey X, CPKey X. Rules X in Attrs X X contains access rules as described in Section 6.4.6; Contr X expresses the set of an organization s guarantees or promises towards parties relying on the various certified keys; Liab X X expresses various liabilities taken by X. These may be liabilities for credentials issued by X using ISKey X, for verifications using VSKey X, for de-anonymizations with DSKey X, or for not fulfilling part of the guarantees in Contr X. Examples are: Contr R captures the fact that R should be able to provide an external Cert CA U for a valid root nym OrgNym UR. More precisely, if an OrgNym UR is the de-anonymization result of the show of a root credential, then R has to be able to provide a verifiable linking (Sig UR, Cert CA U, OrgNym UR ). Also for root credentials that are being revoked, R still has to be able to provide this linking during a certain period of time. If contr breach cond R is a condition expressing that the above contract guarantee is not fulfilled, and Arbiter is an entity trusted to verify that the conditions for providing the linking were fulfilled and the guarantee was not honored, then the following expresses R s liability for not providing the linking: Liab R R = {{LiabTp = Lt, LiabAmount = $100000, LiabCond = contr breach cond R, LiabVerifier = Arbiter},...} where the liability type (LiabTp=Lt) indicates that this is a transaction-related liability.

7.8. Trust, Accountability, Liability and Certification 161 Contr D could include the service of de-anonymizing a transaction if and only if the de-anonymization condition is fulfilled. A condition contr breach cond D1 for contract breach could then be a refusal or incapacity to de-anonymize a transaction if the de-anonymization condition is satisfied (as witnessed by the Arbiter in the liability condition); another example of a contract breach condition contr breach cond D2 would be a de-anonymization that was carried out without its de-anonymization condition being fulfilled (again as witnessed by the Arbiter), or without D being able to show that an authorized party requested the de-anonymization. Liab D D = {{LiabTp = Lt, LiabAmount = $100000, LiabCond = contr breach cond D1, LiabVerifier = Arbiter}, {LiabTp = Lt, LiabAmount = $100000, LiabCond = contr breach cond D2, LiabVerifier = Arbiter},...} Contr L captures the fact that L should be able to provide a transcript Transcript ULK(P ost) for every item posted on LostFound. If contr breach cond L is a condition expressing that the above contract guarantee is not fulfilled, and Arbiter is a trusted arbiter for this conditon: Liab L L = {{LiabTp = Lt, LiabAmount = $100000, LiabCond = contr breach cond L, LiabVerifier = Arbiter},...} Contr K captures the fact that K should be able to provide a transcript Transcript UKR for every nym Nym UK registered with K ; this transcript, in itself, bears the proof that it is related to Nym UK. If contr breach cond K is a condition expressing that the above contract guarantee is not fulfilled, and Arbiter is a trusted arbiter for this conditon: Liab K K = {{LiabTp = Lt, LiabAmount = $100000, LiabCond = contr breach cond K, LiabVerifier = Arbiter},...} 7.8.4 A Scenario Illustrating Trust in Accountability and Unidentifiability: Law Enforcement and Credential Revocation With the certificate contents defined above and the definition of transactions and parameters in Figure 7.8, Figure 7.9 and Table 7.1, we now give some concrete illustrations of trust and liability related to certification. We will again consider the accountability and anonymity requirements stated in Section 7.7 and verified in Sections 7.7.5 and 7.7.6; this time, we will analyze them from the point of view of trust needed, by either the organization relying on accountability, or the user relying on unidentifiability. Trusting Accountability and De-anonymization Consider the following scenario: an item posted on LostFound is judged by LE, the law enforcement entity, to represent criminal abuse (e.g., PostedMessage is an illegal drugs advertisement). LE requires that the identity of the user who posted the message be revealed in a provable way. Other organizations involved in this process are L, K, D, R and an Arbiter. Arbiter is essentially a Fairness-Arbiter verifying whether responses to requests are obtained and whether they have the correct format and contents; it also judges the various contract breach conditions listed in Section 7.8.3. Depending on who drives the various processes to obtain nyms, transcripts etc., we can describe multiple de-anonymization scenarios. In one scenario, LE would contact L with the request to de-anonymize the transaction; L would then be responsible for contacting K and D, etc. However, this would make L partially responsible for de-anonymization, which would have to be expressed in its liabilities; L would have to take a liability of another organization on which it depends.

162 Chapter 7. Designing Applications Using Idemix Anonymous Credentials In order to clearly separate liabilities and responsibilities of individual organizations, we assume that LE is driving the de-anonymization process: LE contacts one organization at a time and requests a specific service. The scenario is shown in Figure 7.11. We also assume that, when asking for a linking or deanonymization, LE also receives the evidence of the linking or of the correctness of the de-anonymization result. This evidence allows Arbiter to verify the correctness of the response. The communication channels between LE and each of the organizations it contacts are mutually authenticated and confidentiality-protected. Authentication by LE allows the various organizations to verify that an authenticated entity (LE ) is the one requesting the information; authentication by the organization receiving a request allows LE to verify that it does not send sensitive de-anonymization requests to other than the intended organization; encryption protects the sensitive data (requests as well as responses) from being read by unauthorized parties. The de-anonymization requests by LE will, in addition, be digitally signed: this allows the de-anonymizing organization D serving the request to prove that the actual request occurred. LE L : LE L : request trscr, PostedMessage Transcript ULK(P ost) LE D : LE D : Sig LE (request dean, CriminalMisuseDesc, PostedMessage, Transcript ULK(P ost)) OrgNym UK, DeAnTranscript DUL LE K LE K : request trscr, OrgNym UK Transcript UKR LE D Sig LE (request dean, CriminalMisuseDesc, PostedMessage, Transcript UKR, LE D : OrgNym UK, Transcript ULK (P ost)) OrgNym UR, DeAnTranscript DUK LE R : LE R : request cert, OrgNym UR Cert CA U, Sig UR Figure 7.11: A Scenario Illustrating Trust in Accountability and Unidentifiability In an exchange with L, LE requests and receives the transcript related to the PostedMessage advertisement. Transcript ULK(P ost) in itself carries the proof that it is the transcript related to PostedMessage. Thus, both Arbiter and LE can verify and prove that the response is correct. From D, LE then requests de-anonymization of this transcript. In the signed request, LE includes also CriminalMisuseDesc and PostedMessage: this allows D to prove not only that the de-anonymization request was made by LE, but also fulfills the CriminalMisuseCond as defined in Section 7.8.1 and will allow D to prove this. The response contains OrgNym UK as well as the proof of correctness DeAnTranscript DUL ; again, both LE and Arbiter can verify the correctness of the result. LE then asks K for the root credential show transcript related to OrgNym UK. The transcript returned, Transcript UKR, carries the evidence of being related to OrgNym UK, which can again be verified and proved by LE as well as Arbiter.

7.9. Conclusion 163 In a second exchange with D, LE asks for de-anonymization of Transcript UKR. LE again includes CriminalMisuseDesc and PostedMessage. As Transcript UKR is not related to PostedMessage, LE provides D with evidence of this relationship. This is done by sending along OrgNym UK and Transcript ULK(P ost). D has cached or re-verifies the linking between OrgNym UK and Transcript ULK(P ost); as Transcript UKR can be proved to be related to OrgNym UK, D is convinced that Transcript UKR is indeed generated by the same user who generated the criminal posting. The result of this second de-anonymization consists of OrgNym UR and DeAnTranscript DUK ; also this result can be verified and proved. In a final step, LE requests U s external certificate from R. Once more, including the evidence Sig UR of the linking in the response allows the correctness of this linking to be verified and proved. In each of the above steps, LE requests a service for which the responding organization has taken some responsibilities and liabilities. Concretely, according to our liabilities specification in Section 7.8.3, unfair behaviour in the various steps results in either of the following contract breach conditions being fulfilled: contr breach cond L, if L does not return a correct transcript of the message posting; contr breach cond D1, if D does not respond with a correct de-anonymization result and proof for either de-anonymization request; contr breach cond K, if K does not reply with a correct root credential show transcript; contr breach cond R, if R does not return the correct external certificate. As the presence as well as the correctness of a response can be verified by Arbiter, the relying party (LE in this case) is protected against unfair or uncorrect behaviour by the responding organization according to the (high) liability amounts in the various organizations Idemix certificates. Trusting Anonymity and Unlinkability Let us now look at the above scenario from the user s point of view, who wants to trust that his rights to unidentifiability are respected. Getting Transcript ULK(P ost) from L, or obtaining Transcript UK R from K, is not tied to any condition, and neither Cert K K nor Cert L L contain liabilities for giving away this information without reason. Indeed, this information may as well be considered public as a party receiving it cannot use the transcripts without de-anonymization by D. This is also the reason why we did not require LE to sign these requests: no liability is attached to giving the response without proving an appropriate reason. In order for the user to be unfairly deprived of unidentifiability, at least one of the de-anonymizations must be unfair. If this is the case, it fulfills contr breach cond D2. Clearly, U cannot be unfairly accused of misuse as this would require evidence which does not exist, including de-anonymization transcripts which provably fulfill contr breach cond D2. However, D could collude with LE or another entity to de-anonymize even if the de-anonymization condition is not fulfilled; as long as they do not use the result to accuse U of the stated misbehaviour, this collusion is difficult to prove. One way to protect against this is making all D s actions auditable, e.g., by having Arbiter or another monitor audit all de-anonymizations handled by D. 7.9 Conclusion In this chapter, we have shown how to design secure applications based on the Idemix anonymous credential system. We first described the Idemix protocols at a detailed enough interface level to be able to concretely specify applications based on them. Based on these interfaces, we also were able to define relationships, assertions, between nyms, credentials and credential show transcripts resulting from Idemix interactive protocol executions. These assertions not only represent compact and intuitive building blocks

164 Chapter 7. Designing Applications Using Idemix Anonymous Credentials for describing complex applications using Idemix credentials for attribute-based authorization; they also allow to describe accountability and linkability consequences resulting from Idemix protocol executions. Therefore, they are necessary in order to build applications based on authentication, accountability and unidentifiability requirements of the various parties (users and organizations) in the system. We illustrated these findings with an example application involving a two-step de-anonymization process. We constructed the protocols used by the application based on authentication, accountability and unlinkability requirements of users and organizations, and showed that the resulting application indeed fulfilled these requirements. Correctness of the application protocols, however, is only one step in showing the correct operation of the overall system; it does not give any indication on the correct behaviour of various parties on which users or organizations in the system rely; nor does it stipulate consequences or liabilities related to such misbehaviour. E.g., a de-anonymization organization may behave unfairly towards relying organizations as well as towards users. The last section of this chapter dealt with these issues of fairness and trust. We showed how various organizations behaviour can be made verifiable; and how users and organizations trust in the correct operation of other organizations could be minimized by defining appropriate liabilities in organizations certificates.

Chapter 8 Accountability and Unidentifiability in Certificate- and Credential-Based Anonymous Payments 8.1 Introduction In this chapter, we want to compare security, unidentifiability and accountability features of pseudonymous applications based on traditonal certificates with similar applications based on anonymous credentials. The application used is a payment system as described in Chapter 5. The pseudonym server solution described in Chapter 5 realizes an overlay payment system on top of an existing payment system. The pseudonym server PS issues pseudonym certificates allowing the secure use of pseudonym keys. In a pseudonym certificate, the pseudonym server makes certain transaction guarantees related to a payment made with the pseudonym certificate. Chapter 5 also describes a more generalized version of the pseudonym server, where PS also issues pseudonym certificates for general applications other than payment; in that case, the pseudonym certificate may also need to contain other guarantees or liabilities, or escrowed user data which can be revealed in case of fraud or misbehaviour. In the payment application in Chapter 5, there is a strong focus on preserving the original payment system infrastructure. Of the five parties involved in a payment transaction (Customer C, Merchant M, Acquirer A, Issuer I, and the dedicated pseudonym server PS), only C (or at least, the software agent acting on C s behalf) and PS are aware of the fact that a payment is pseudonymous. I sees the original payment, verifiable with an original certificate/key certified by I himself; while M and A see a pseudonymous payment, verifiable with a certificate/key certified by PS. PS is a certified payment certificate issuer in the payment system and acts as issuer towards M /A and as acquirer towards I ; PS issues pseudonym certificates to C or signs pseudonymous transactions on C s behalf such that a valid pseudonymous payment accepted by M /A (and for which PS has to honor payment to M /A) also corresponds to a valid non-pseudonymous payment (for which I has to honor payment to PS). Because of the overlay construction, invisible to I, M and A, we had to assume that PS would have to take any liability for payments accepted by M /A and not honored by I. The realization with least risk for PS is one where PS is on-line and controls transactions based on the pseudonym certificate. If PS is off-line, it is exposed to several risks. Firstly, it cannot enforce that users sign a non-pseudonymous transaction that will be honored by I. Secondly, I may revoke a user s original certificate after PS has issued one or several pseudonym certificates to this user. PS then has to perfectly synchronize his revocation of pseudonym certificates with I s revocation of original certificates. The pseudonym server solution described in Chapter 5 has thus several limitations: 165

166 Chapter 8. Certificate- and Credential-Based Anonymous Payments The most secure solution is not efficient: PS has to be on-line, and has to issue a one-time-use pseudonym certificate for every transaction; In the case of PS being off-line, the synchronization of revocation is quite cumbersome; PS has to combine the role of checking I s revocations (as an acquirer) with issuing and advertising his own (as an issuer); PS s and C s security are at a trade-off: in the most secure (for PS) realization, PS acts as a proxy for C and owns the pseudonymous keys and certificate; C has no secure receipt of the transaction; i.e., C has to rely on PS s cooperation to prove the payment. These limitations are due to the solution being an overlay solution, i.e., PS and I being distinct entities and PS having to limit his risk. In a pseudonymous payment system without this design requirement, I could issue his own pseudonym certificates and the role of PS would be obsolete, which would overcome these limitations. Therefore, in order to describe the maximum security and unidentifiability achievable with certificates, it makes sense to start from such a simplified payment system. This also facilitates a meaningful comparison with payment systems based on anonymous credentials. In such systems, it is natural to assume that the original certificate (credential) is pseudonymous (an anonymous credential); there is thus no need to define a separate PS. Also, when discussing payment systems based on anonymous credentials, we will make another simplification, namely that an anonymous payment can be deposited directly with the issuer of the anonymous credential, and thus the role of the acquirer becomes superfluous. In order for the comparison between a pseudonymous payment system based on certificates vs. anonymous credentials to be meaningful, we should consider systems where the same parties play the same roles. We will thus first design a simplified payment protocol based on certificates: a non-pseudonymous version without acquirer, and a derived pseudonymous version without pseudonym server; i.e., where I issues his own pseudonym certificates. The pseudonymous version will have none of the overlay scenario limitations; however, payments with the same pseudonym certificates are still linkable towards M ; and, of course, every pseudonymous payment can be linked by I to C. Linkability towards M can be avoided only when using anonymous credentials; linkability towards I can only be avoided in an anonymous credential system if credentials are also pre-paid. We discuss both account-based and pre-paid payment applications based on anonymous credentials. The outline of the chapter is as follows. In Section 8.2, we present the non-pseudonymous and pseudonymous protocols based on certificates. In Section 8.3, we describe account-based and pre-paid payment protocols based on anonymous (Idemix) credentials. Section 8.4 analyzes the security, unidentifiability and accountability features of the various protocols. Section 8.5 concludes the chapter. 8.2 Payment Protocols Based on Certificates 8.2.1 Non-Pseudonymous Account-Based Payment Protocol Based on Certificates In the payment protocol in Chapter 5, M had to query an acquirer A who is an intermediary between M and I in authorizing and capturing (clearing) the payment; this is inherent in the SET [104] and ikp (Chapter 2 and [16]) credit card payment models. In these protocols, the traditional credit-card based system co-exists with the certificate-based system; one of the acquirer s main tasks is the extraction of an electronic credit card slip from the digitally signed payment. When modelling the liabilities and risks of different parties in the protocol, we had to define liabilities related to A s role. We assumed that A could give a payment guarantee to M based on liabilities in Cert CA C or contract terms between I and A, and could do so free of risk as long as it checked revocation of Cert CA C. If we design any account-based payment system from scratch, we can simply associate an account to a

8.2. Payment Protocols Based on Certificates 167 certificate and public key, and need not worry about encrypting semi-public numbers such as credit card numbers. In such a model, any party with access to an authentic copy of I s public key, the liabilities attached to it as well as a recent version of a revocation list of certificates issued by I can determine if a payment by a user U is valid (has to be honored by I). The potential role of an acquirer is now reduced to making these public verifications for M and performing the actual clearing. If we assume that M not only verifies U s signature but also performs these additional checks, M can perform the role of acquirer himself. This is the assumption we made in the following protocols: M is able to decide whether payment is guaranteed and to acknowledge the payment before performing himself the actual capture exchange with I. In case of real deployment, an option could still allow M to perform an on-line authorization with I if desired. Note that in large-scale systems with many issuers, a merchant may not have a relationship with each of the issuers; in that case, an acquirer can be introduced in each of the following protocols. Such an acquirer then takes the issuer s role towards M in the capture process and signs capture responses. The protocols are represented in Figure 8.1 and Table 8.1. Figure 8.1 introduces the various participants with their initial keys and certificates and gives an overview of the protocol flows; Table 8.1 shows the contents and values of various certificates and messages. Its third column indicates in which of the protocol steps a certificate, message or field is (first) used or whether it is part of the initial key and certificate material (key mat.). All certificates and certificate requests are modeled according to the Participants and Key Material: User (U): SSKey U, Cert CA U, Issuer (I) SSKey I, Cert CA I, Merchant (M): SSKey M, Cert CA M, Receipt Verifier (V): Protocol Flows: U I M V Registration: Payment: Capture: Showing Receipt: CertU C CertI C Sig C Sig M Sig C, Sig M Sig I Sig C Figure 8.1: Non-Pseudonymous Account-Based Payment Protocol Based on Certificates

168 Chapter 8. Certificate- and Credential-Based Anonymous Payments Table 8.1: Non-Pseudonymous Account-Based Payment Protocol Based on Certificates item value (first) use Cert CA X S CA(CertdKeys = {SPKey = SPKey X }, key mat. (X {U, I, M, V }) Attrs = {CertTp = CERT, Liab = Liab CA X}) Cert U C S U(CertdKeys = {SPKey = SPKey C }, registr. Attrs = {CertTp = CERTREQ, Liab = Liab U C, LiabReq = Liab I C, CertrKeyReq = SPKey I }) Liab U C {{LiabTp=Lt, LiabAmount=$1000, LiabCond=direct liab U a,... },... } registr. Liab I C {{LiabTp=Lt, LiabAmount=$1000, LiabCond=direct liab I b,... },... } registr. Cert I C S I(CertdKeys = {SPKey = SPKey C }, registr. Attrs = {CertTp = CERT, Liab = Liab I C}) Sig C S C(SPKey C, SPKey M, SPKey I, Trx) payment Trx {Amount, Trxid} payment Sig M S M (SPKey C, SPKey M, SPKey I, Trx) payment Sig M S M (SPKey M, SPKey I, SPKey C, Trx) capture Sig I S I(SPKey M, SPKey I, SPKey C, Trx) capture Sig C S C(N, Sig M ) show.rcpt. N nonce or time value assuring freshness of SIG C to V show.rcpt. a direct liab U = payment verified with key certified in this certificate. b direct liab I = payment verified with key certified in this certificate. generic certificate format of Chapter 5 s Postscript section. The participants are user U, issuer I, merchant M and verifier V. U and M have accounts with I ; I will debit valid payments by U to M from U s account and credit M s account. V is a party relying on a payment receipt issued by M. User U, Issuer I and Merchant M each start with the possession of a signature key (SSKey U, SSKey I, SSKey M ) of which the corresponding public key is certified by CA (in Cert CA U, Cert CA I, Cert CA M ). In a registration flow, U obtains a certificate Cert I C from I ; this step only needs to be executed once after which U can engage in multiple payment transactions based on Cert I C. Payment and capture flows constitute the actual value transfer transaction; U can then show the payment receipt from M to V. In the payment protocols in Chapter 5, C stood for the customer s real identity. Here, we make a distinction between U, which is an externally certified identity and C, an issuer-certified identity; this distinction allows us to model user liability for the use of the key certified in Cert I C. C can be seen as an identifier of U in his capacity of the holder of a the certificate issued by I ; C may be the equivalent of a bank account or a bank card. We exclude nor assume that such identifier is explicitly present in Cert I C ; however, we do not consider Cert I C to be a pseudonym certificate nor the payment to be a pseudonymous payment: we assume that U has only one SPKey C and Cert I C, and may use them also in transactions where he is identifiable. In this and subsequent protocols, we assume that a party verifying a signature or certificate has obtained the appropriate certificate(s) for verification, e.g., through some out-of-band pull or push mechanism (the recipient asking the sender or a centralized server for the necessary certificates, or the sender sending the certificates along with the signature). Thus, when verifying Cert U C, I has Cert CA C ; when verifying

8.2. Payment Protocols Based on Certificates 169 Cert I C, U has Cert CA I ; when verifying Sig C, M has Cert CA I and Cert I C, etc. Of course, all parties have an authentic copy of SPKey CA. Registration The registration defines U s and I s liabilities for payment transactions based on Cert I C. In a certificate request Cert U C, U requests a certificate by I on SPKey C. Cert U C is a request for a certificate to be issued by I (CertrKeyReq=SPKey I ). LiabReq = Liab I C specifies which liability U wants I to take for the requested certificate. In our example, I is requested to take a transaction (LiabTp=Lt) liability of up to $1000 (LiabAmount=$1000) for transactions verifiable with the certified key (SPKey C ) a liability is, of course, valid only if the key to which it applies is not revoked. Cert U C also contains Liab U C, which bootstraps user liability. This component was not part of the certificate requests in the examples of Chapter 5 but was introduced in that chapter s Postscript section. Liab U C expresses the liability U takes for payments verifiable with SPKey C. Through Liab U C, Cert U C grants I the right to subtract money (in our example: also up to $1000 per transaction) from U s account for payments verifiable with SPKey C ; Liab U C could also contain certain measures against U if the account balance does not suffice to debit a payment made by U. We have assumed that U has an external certificate issued by a Certificate Authority CA and uses the private key associated with this certificate to sign Cert U C. As U is a customer of the bank (I ), U may already have a certificate issued by I ; in this case, U s signature on Cert U C may be a signature with the private signature key corresponding to the latter certificate. Also, as SSKey U is used by the user only to sign and take liability for his payment credential, one could replace the signature on Cert U C with a handwritten signature. The actual payment certificate Cert I C, issued by I as part of the registration, then certifies SPKey C together with the requested liability Liab I C ; it will allow relying parties such as M to derive a payment guarantee from transactions that are verifiable with SPKey C. Payment A payment of U (C ) to M now consists in an exchange of signed messages by C and M, representing C s payment authorization and M s receipt. They are similar as in Chapter 5, with following minor differences: Identifiers (of C, M, I ) are replaced by the corresponding public keys (SPKey C, SPKey M, SPKey I ) as discussed in the Postscript of Chapter 5. Consequently, when stating that a message is verified to be signed by a party X, we mean that the message signature can be verified using the corresponding public key SPKey X. As we combined the roles of issuer and acquirer, the acquirer A s identifying data (A) is now replaced by I s identifying data (SPKey I ). The Trx parameter contains at least the amount of the payment and a transaction identifier Trxid; this Trxid may include a hash value of some transaction features important to M. By including a hash value of these features (such as the description of the order) into Trx, M can prove to a third party verifier that U signed those features; while I need not get these details as part of the transaction. Capture Capture flows between M and I are similar to M -A flows in Section 5.2.3. In the latter protocol, Sig A was M s payment guarantee; M thus needed to contact A on-line, i.e., before sending out a payment receipt. A s payment guarantee was then based on the verification of the relevant signatures, his checking of the validity of certificates and his contract with I. Here, we assumed that M takes over A s authorization

170 Chapter 8. Certificate- and Credential-Based Anonymous Payments role; M can thus authorize the transaction based on a payment guarantee derived from a combination of Sig C, his contract with I and his checking Cert I C s revocation status. Thus, M can issue a receipt Sig M to U before contacting I for the actual capture. Showing the Receipt The receipt Sig M may give U the right to obtain goods or a service from a receipt verifier V (V may or may not be the same entity as M ). In the applications in Chapter 5, it was assumed that U could prove his involvement in the payment by sending Sig M to V ; this corresponds to the receipt semantics in SET and ikp. Sig M may prove U s (C s) involvement in the payment; concretely, that the owner of SPKey C executed the payment. However, without an authentication of U (C ) to V, simply sending Sig M to V does not preclude that another party (intercepting the receipt or receiving it from U ) uses the receipt. Such an authentication may be implicit or explicit. Implicit authentication occurs if, e.g., physical goods delivered by V are shipped to an address included in Cert I C, or electronic goods are encrypted with a key included in Cert I C. Explicit authentication may occur if U convinces V of being the owner of Cert I C and the corresponding SSKey C. Here, we have included an explicit authentication: Sig C carries an authentication (using SSKey C ) of U to V. Sig C thus proves to M that the party showing the receipt is the party to whom it was issued. 8.2.2 Pseudonymous Account-Based Payment Protocol Based on Certificates We now derive a pseudonymous version of the above non-pseudonymous account-based payment protocol. As we are no longer restricted to an overlay solution with a Pseudonym Server, we allow I to issue pseudonym certificates for C (U ). While the construction is fairly trivial, it is needed as a reference for later comparison with the payment systems based on anonymous credentials. The protocols are represented in Figure 8.2 and Table 8.2. The various steps described are similar to the ones in the non-pseudonymous protocol; in the pseudonymous protocol, however, the user makes the actual payment with a pseudonym certificate which he obtains in an additional pseudonym registration step. Initial and Pseudonym Registration, Payment and Capture During an initial registration procedure, U again requests and obtains a certificate from I in a Cert U C - Cert I C exchange. The initial certificate Cert I C is not a payment certificate but will allow U to consecutively obtain pseudonymous payment certificates from I, with which he can make pseudonymous payments to M. Every time U wants to obtain a new pseudonym certificate, U generates a pseudonym key pair (SPKey P, SSKey P ) and obtains a pseudonym certificate on SPKey P in a Cert C P - Cert I P pseudonym registration exchange. The actual payment and capture are identical as in the non-pseudonymous protocol with U now using SSKey P and Cert I P instead of SSKey C and Cert I C. The pseudonym certificates I issues carry exactly the same liabilities and risks as the non-pseudonymous certificates in the previous version; thus, a pseudonym certificate can be issued ahead of time, it can be used multiple times if so desired by U, and I need not be on-line during the payment transaction. Also, revocation is much easier than in the overlay scenario. I only has to make sure to keep track of all the outstanding pseudonym certificates issued to U (or C ), as it has to be able to revoke all of them together when necessary. For M, a payment guarantee can be derived from a correctly verified payment message, based on a valid, non-revoked pseudonym certificate. Cert U C and Cert I C are similar to the ones in the non-pseudonymous protocol; however, Liab I C =null,

8.2. Payment Protocols Based on Certificates 171 Participants and Key Material: User (U): SSKey U, Cert CA U, Issuer (I) SSKey I, Cert CA I, Merchant (M): SSKey M, Cert CA M, Receipt Verifier (V): Protocol Flows: U I M V Initial Registration: Pseudonym Registration: Payment: Capture: Showing Receipt: CertU C CertI C CertC P CertI P Sig P Sig M Sig P, Sig M Sig I Sig P Figure 8.2: Pseudonymous Account-Based Payment Protocol Based on Certificates as Cert I C only serves to authenticate C to I when U wants to obtain pseudonym certificates from I ; Liab I C =null represents the fact that Cert I C should not allow U to make any signatures for which I is liable towards another party. Also, Liab U C now is a liability not for payments verified with SPKey C but for payments verified with any key the certification of which can be verified with SPKey C. We assume here that such an indirect liability (LiabCond=indirect liab U ) has to cover at least the amount of an individual liability Liab I P in Cert I P in order for the latter liability to be valid. In this case, as the user wants one single Cert I P for transactions up to $1000, it makes sense to choose the same amount ($1000) for both. Cert C P and Cert I P then are equivalent to Cert U C and Cert I C in the non-pseudonymous protocol; Liab C P and Liab I P are equivalent to Liab U C and Liab I C in the non-pseudonymous version. Showing the Receipt In the pseudonymous payment protocol in Section 5.2.3, we suggested to include a hash H(C, P, ref) in Cert P ; customer C could prove the linking between C (a real identity) and P (the pseudonymous identity) by opening this hash. In the present protocol, we could include a similar value H(SPKey C, SPKey P,...) in Cert I P. A major disadvantage of this solution is the fact that U gives up

172 Chapter 8. Certificate- and Credential-Based Anonymous Payments Table 8.2: Pseudonymous Account-Based Payment Protocol Based on Certificates item value (first) use Cert CA X as in Table 8.1 key mat. Cert U C S U(CertdKeys = {SPKey = SPKey C, init.reg. Attrs = {CertTp = CERTREQ, Liab = Liab U C, LiabReq = null, CertrKeyReq = SPKey I }) Liab U C {{LiabTp=Lt, LiabAmount=$1000, LiabCond=indirect liab U a init.reg. Cert I C S I(CertdKeys = {SPKey = SPKey C }, init.reg. Attrs = {CertTp = CERT, Liab = null}) Cert C P S C(CertdKeys = {SPKey = SPKey P }, pseud.reg. Attrs = {CertTp = CERTREQ, Liab = Liab C P, LiabReq = Liab I P, CertrKeyReq = SPKey I }) Liab C P {{LiabTp=Lt, LiabAmount=$1000, LiabCond=direct liab U b,... },... } pseud.reg. Liab I P {{LiabTp=Lt, LiabAmount=$1000, LiabCond=direct liab I c,... },... } pseud.reg. Cert I P S I(CertdKeys = {SPKey = SPKey P }, pseud.reg. Attrs = {CertTp = CERT, Liab = Liab I P }) Sig P S P (SPKey P, SPKey M, SPKey I, Trx) payment Trx {Amount, Trxid} payment Sig M S M(SPKey P, SPKey M, SPKey I, Trx) payment Sig M S M(SPKey M, SPKey I, SPKey P, Trx) capture Sig I S I(SPKey M, SPKey I, SPKey P, Trx) capture Sig P S P (N, Sig M ) show.rcpt. N nonce or time value assuring freshness of SIG P to V show.rcpt. a indirect liab U = payment verified with key, certification of which can be verified with key certified in this certificate; subject to further liability limitations in individual pseudonym certificate request. b direct liab U = payment verified with key certified in this certificate. c direct liab I = payment verified with key certified in this certificate. anonymity (at least, has to reveal his customer identity SPKey C ) when proving ownership of the receipt. U revealing his identity (or SPKey C ) when showing the receipt may be acceptable if V is a trusted party, e.g., an arbiter in a dispute situation. One can even imagine it to be desirable, e.g., if the usage of the receipt requires an accountability under V s control. However, if we want the receipt to be used anonymously, it is preferable if U can prove ownership of the receipt without proving a linking with C or U. Proving ownership of the receipt can be done by proving knowledge of the secret associated with it, in the same way as was done in the non-pseudonymous protocol. Sig P in Figure 8.2 and Table 8.2 proves ownership of the private key (SSKey P ) corresponding to the public key (SPKey P ) with which the payment was verified and which was included in the receipt. Note that the receipt is linked to a transaction, and thus showing a receipt can always be linked back to the transaction. Also, a receipt can be shown an unlimited number of times. Thus, if a receipt should only be used once (e.g., to receive a piece of music once), the verifier of the receipt has to keep track of the fact the receipt has been shown. As we will show in the next section, we can improve on both features in a system based on anonymous credentials, as we can represent a receipt there as a credential.

8.3. Payment Systems Based on Anonymous Credentials 173 The receipt credential can but need not be linked to the original payment transaction; and a receipt which should only be used once can be realized using a one-show credential, without a need to link it to the payment. 8.3 Payment Systems Based on Anonymous Credentials In the pseudonymous payment system described in Section 8.2.2, payments made with one and the same pseudonym certificate are still linkable. The overhead of issuing short-lived, one-time certificates in order to achieve unlinkability of all payments would be quite large for customers and issuers. By using an anonymous credential system such as Idemix described in Chapters 6 and 7 to implement an accountbased payment system, complete unlinkability of payments towards merchants can be achieved based on multiple-use anonymous credentials. Using anonymous credentials brings additional advantages: receipts need not be linkable to the transaction; despite that, the receipt issuer can enforce that a receipt can only be used once. Moreover, when the payment system is made pre-paid, also anonymity and unlinkability of payments towards the issuer can be achieved. The following sections discuss both an account-based and a pre-paid payment protocol based on anonymous credentials. 8.3.1 Account-Based Payment Protocol Based on Anonymous Credentials Again, user U and merchant M have non-anonymous accounts with I. The requirements on the system are as follows: U wants a payment credential that allows him to anonymously and unlinkably make payments to M ; I has to be able to link an anonymous payment back to U s account and also needs to prove that linking in order to motivate the right to subtract money from U s account; I also needs to be able to prove that U authorized the subtraction of money from his account; For every anonymous payment received, M wants a payment guarantee; In return for a payment, U wants a receipt it can show to any verifier V in an unidentifiable way. We will address these requirements as follows: The issue of linkability towards I whilst preserving anonymity towards M is realized using deanonymization. As I should have the right to de-anonymize every payment transcript without the judgement of any other entity, we allow I to act as de-anonymizer for transcripts based on credentials it issued; this linking (de-anonymization) can be proved; U s authorization to subtract money from his account can be realized by a registration procedure between U and I, where U takes appropriate liabilities for payments based on the anonymous credential; A payment guarantee for M can be achieved if I, in his Idemix self-certified certificate, took liability for payments made with credentials issued by I ; this liability can be complemented or replaced by a liability encoded in the credentials attributes; An anonymous receipt is realized as an anonymous credential issued by M. Note that the requirements on the receipt depend on the application: A receipt can represent a one-time right to receive a service or a good provided by verifier V, in which case it should be usable only once; or, it can represent a multiple-access subscription to V s service, in which case it can be a multi-show credential with a specific expiration date determined by the duration of the subscription;

174 Chapter 8. Certificate- and Credential-Based Anonymous Payments Participants and Key Material: User (U): {SSKey U, Cert CA U}, UserSecret U Issuer (I) {SSKey I, Cert CA I}, {ISKey I, DSKey I, CSKey I, Cert I I} Merchant (M): {SSKey M, Cert CA M }, {ISKey M, VSKey M, CSKey M, Cert M M} Receipt Verifier (V): {SSKey V, Cert CA V }, {VSKey V, CSKey V, Cert V V } Protocol Flows: U I M V Registration: Nym UI, SignedNymProof UI I: stores {OrgNym UI, Sig UI, Cert CA U, Liab U UI} CredUI I: updates {OrgNym UI, Sig UI, Cert CA U, Liab U UI, CredInfo UI} Payment: Nym UM Capture: WasShownUM I CredUM Sig M I: calls DODeAnonLocal(), debits U s account and credits M s account Showing Receipt: Sig I WasShownUV M dbl sp check Figure 8.3: Account-Based Payment Protocol Based on Anonymous Credentials Some applications may need different types of receipts; e.g., the same application may need a oneshow receipt to get the goods paid for, and a multi-show receipt to show to other verifiers such as a tax authority, the accounting department of the user s employer, etc.; A receipt may need to be uniquely linkable to the payment transaction, e.g., because some of the transaction attributes (such as the goods bought) are unique. In other cases, e.g., a subscription to a service, receipts can be completely unlinkable. Note that linkability of a receipt to a payment need not pose a problem to the user s unidentifiability as long as neither receipt nor payment can be linked back to U (see also the discussion of U s unidentifiability in Section 8.4.3).

8.3. Payment Systems Based on Anonymous Credentials 175 Table 8.3: Account-Based Payment Protocol Based on Anonymous Credentials item value (first) use Cert CA X as in Table 8.1 key mat. Cert O O (O {I, M, V }) S X(CertdKeys = CertdKeys O O, Attrs = Attrs O O) key mat. Attrs O O {CertTp = SELFCERT, Liab = Liab O O} key mat. Liab I I {{LiabTp=Lt, LiabAmount=$2000, key mat. LiabCond= indirect liab a I,... },... } CertdKeys I I {IPKey = IPKey I, DPKey = DPKey I, CPKey = CPKey I } key mat. CertdKeys M M {IPKey = IPKey M, VPKey = VPKey M, CPKey = CPKey M } key mat. CertdKeys V V {VPKey = VPKey V, CPKey = CPKey V } key mat. Nym UI Nym(UserSecret U, OrgNym UI, UserNym UI ) registr. SignedNymProof UI SignedNymProof(Sig UI, Cert CA U, OrgNym UI, Liab U UI) registr. Liab U UI {{LiabTp = Lt, LiabAmount = $1000, registr. LiabCond=direct liab b U,...},...} Cred UI Cred(OrgNym UI, UserCred UI, CredInfo UI) registr. CredInfo UI {IPKey I, true, Expiration UI, {MaxAmt = $1000}} registr. Nym UM Nym(UserSecret U, OrgNym UM, UserNym UM ) payment WasShown UMI WasShown(Transcript UMI, UserCred UI, CredShowInfo UMI, payment CredShowFeatures UMI, OrgNym UM, Trx) Trx {SPKey M, Amount, Trxid} payment CredShowInfo UMI {IPKey I, any, Expiration M, {MaxAmt Trx.Amount}} payment CredShowFeatures UMI {true, VPKey M, {DPKey I, null}, null} payment Cred UM Cred(OrgNym UM, UserCred UM, CredInfo UM ) payment CredInfo UM {IPKey M, false, Expiration UM, Attrs UM } payment with Attrs UM = {Trxid} Sig M S M(Transcript UMI, SPKey M, SPKey I, Trx) capture Sig I S I(SPKey, SPKey I, Trx) capture WasShown UVM WasShown(Transcript UVM, UserCred UM, CredShowInfo UVM, show.rcpt. CredShowFeatures UVM, null, null) CredShowInfo UVM {IPKey M, false, Expiration V, {Trxid}} show.rcpt. CredShowFeatures UVM {false, VPKey V, null, null} show.rcpt. a indirect liab I = payment with credential verified with issuing key in this certificate; subject to further liability limitations in MaxAmt attribute of individual credential. b direct liab U = payment with credential issued on nym, signature on which can be verified with key certified in this certificate. For this application, we have chosen the receipt to be usable only once. We will also assume that the receipt needs to be linkable to the payment transaction; this will be done through a transaction identifier. We will discuss how this influences unidentifiability of the user. Figure 8.3 and Table 8.3 represent the account-based payment system based on anonymous credentials.

176 Chapter 8. Certificate- and Credential-Based Anonymous Payments All parties have public/private signature key pairs and signature certificates Cert CA X in an external Public-Key Infrastructure certified by Certification Authority CA. Both I and M have a credential issuing key pair: I for issuing payment credentials, M for issuing receipt credentials. M and V verify credentials and have a verification key pair. I, in addition, has a de-anonymization key pair with which it will de-anonymize payment transcripts in order to provably link them to a specific user account. I, M and V also have key pairs for securing communication. I, M and V have used their respective CA-certified signature keys to self-certify their Idemix issuing, verification and de-anonymization public keys (IPKey, VPKey, DPKey) as well as communication public keys (CPKey). The self-issued certificates contain liabilities for the certified keys (other attributes such as address, contract and rules information as in Section 7.8 may of course be included). E.g., Liab I I may express a maximum payment guarantee for payments based on credentials issued by IPKey I ; it also specifies that a further liability limitation is specified in the MaxAmt attribute of credentials verifiable with IPKey I. As ISKey I is now used to issue credentials for various users with possibly different liability requirements, we have chosen the liability value in Liab I I ($2000) to be higher than the liability value ($1000) taken by U and I for the credential issued to U ; the latter liabilities are introduced in the discussion about the registration process. We did not specify liabilities Liab M M or Liab V V : A liability Liab M M may specify the value of a receipt credential Cred UM towards a receipt verifier V. If M and V are independent business entities, V may need to rely on some actual compensation by M as result of the verification of a Cred UM credential. E.g., V sells its products through an independent reseller M and expects payment from M for every product sold. The fact that we chose Trxid to be the distinguishing attribute in CredInfo UV and CredShowInfo UVM, however, implies some cooperation between M and V. One can imagine that M and V are the sales and distribution branches of the same company and share a common database with information about transactions. In such a case, a specification of Liab M M may not be necessary. In our example, V has no obvious liabilities towards other parties related to actions with the keys it certifies. Registration In the registration process, U obtains an anonymous payment credential. Before issuing this credential, I needs evidence that U signed certain liabilities for this payment credential, and needs to establish the means to link the payments with this payment credential to the correct account. The registration process consists of a signed nym registration procedure (the establishment of Nym UI and SignedNymProof UI ) followed by the issuing of the anonymous payment credential Cred UI. The use of the signed nym registration procedure allows I to provably link the payment credential (and payments made with it) with U s account; Liab U UI, the signed message in SignedNymProof UI, serves the same purpose as Liab U C in the Cert U C certificate request in Section 8.2.2: it allows I to verify and also prove the liabilities U took with respect to the Nym UI, and, more importantly, with respect to Cred UI issued on it. Specifically, Liab U UI authorizes I to subtract money from that account as a consequence of a payment with Cred UI. This authorization may include a maximum value per payment (in our example, up to $1000); it could also specify I s rights when U s account balance does not cover a certain payment. Also, it may specify whether I is allowed to reveal a user s identity to a merchant or a receipt verifier in case of double-spending of a payment receipt; this additional role of I will be discussed in Section 8.4.3. Without Liab U UI, I can prove that a payment transaction was linked to U s account, but not that U was aware of the corresponding liabilities when requesting Cred UI. I then issues Cred UI, the anonymous payment credential. CredInfo UI shows that Cred UI is a multi-show (MultiShow= true) payment credential issued by I (IPKey I ), with an expiration

8.3. Payment Systems Based on Anonymous Credentials 177 time Expiration UI. In CredInfo UI.Attrs.MaxAmt, I limits his risk to the same value as chosen by U. However, in order for the showing of the payment credential to remain unidentifiable, CredInfo UI.Attrs.MaxAmt (or, better, the fact that CredInfo UI.Attrs.MaxAmt Trx.Amount) should not make Cred UI unique; this is discussed in Section 8.4.3. We have assumed that CA has the authority to certify a key SPKey U associated with an account number, and that a signature with the corresponding SSKey U authorizes I to debit U s account as defined by Liab U UI : this allowed us to define a one-step registration process. Whether this assumption can be fulfilled depends on the business and trust relationship between I and CA. It is equally likely that I directly acts as a registration and certification authority for its own customers and issues its own certificate Cert I U for every user account. The user may authorize (non-idemix) transactions with it, as well as use it to register an Idemix payment credential. In this case, the registration process would use Cert I U (and its associated signature key) rather than Cert CA U. Payment In the payment transaction, U now uses his payment credential Cred UI to authorize a payment transaction and gets a receipt in return. U establishes a new nym Nym UM with M, needed to later receive the receipt credential on. In WasShown UMI, U signs (as defined in Section 7.2.1) the transaction data Trx with this payment credential. Note that Trx now represents the complete message signed by U ; therefore, we now include SPKey M in Trx. To enable de-anonymization by I, WasShown UMI uses local revocation with I s de-anonymization key DPKey I (in CredShowFeatures UMI ). The de-anonymization condition (null) indicates that de-anonymization by I is allowed for every transaction. In addition, WasShown UMI is relative to Nym UM : CredShowFeatures UMI.RelNym = true, WasShown UMI.OrgNym = OrgNym UM This allows M to securely link the later issuing of the receipt (on Nym UM ) to the payment (relative to Nym UM ). During verification of the credential show WasShown UMI, M verifies that the MaxAmt in Cred UI covers the transaction amount: MaxAmt Trx.Amount In addition, M verifies that the liability in Cert I I covers the transaction amount: Liab I I.LiabAmount Trx.Amount M also verifies that Cred UI does not expire until the date in CredShowInfo UMI, or that: Expiration M Expiration UI If M s information about DPKey I (revocation information) is up-to-date, a valid Transcript UMI then M s payment guarantee, and no on-line authorization with I is necessary. is Finally, U requests and obtains a receipt credential on Nym UM. This is a one-show credential (CredInfo UM.MultiShow = false) which is linked to the transaction identifier Trxid in Attrs UM.

178 Chapter 8. Certificate- and Credential-Based Anonymous Payments Capture At a later point in time, M captures the payment: The capture request Sig M is similar to the capture request in Section 8.2.2. Sig M includes Transcript UMI, implicitly together with parameters necessary for verification of Transcript UMI by I. I first verifies Transcript UMI which convinces I that a valid payment was made with a credential issued by I. Then, I de-anonymizes Transcript UMI, obtaining OrgNym UM : with DODeAnonLocalWProof(DeAnOrgKeys I, Transcript UMI ) returns DeAnTranscript IUM LDeAnProof(DeAnTranscript IUM, Transcript UMI, OrgNym UI ) I acknowledges the capture success with Sig I amount (in Trx) and credits M s account. to M, debits U s account with the appropriate Showing the Receipt At any point in time after the payment, U may want to show the receipt to a verifier V in WasShown UVM. The showing of the receipt is not de-anonymizable nor relative to a nym (CredShowFeatures UVM = {false, VPKey V, null, null}) but V requests that the receipt credential be a one-show credential (MultiShow= false) and linkable to the transaction(attrs = {Trxid}). V may decide to perform online double-spending detection on the receipt show. This on-line check is optional as represented by the dashed-line exchange between V and M in Figure 8.3: whether or not it should be performed on-line depends on M s ability to take measures against the double-spending user after the fact by cooperation with I. How I can cooperate with M to take measures against a user double-spending a receipt, and the influence on M s and V s risk of this double-spending detection being on-line as opposed to off-line, are discussed in more detail in Section 8.4.3. Security of the Communication Channels As discussed in Section 7.7.3, communication channels between U and any of the organizations with whom it wants to conduct unidentifiable transactions should provide for sender anonymity. These are the communication channels with M and with V. is needed to protect against denial- Authentication of the responding organization X in any Comm UX of-service attacks. None of the protocol flows needs a secure communication channel for the purpose of linking exchanges. In the registration exchange, the credential issuing is securely linked to the signed nym registration through the nym Nym UI ; in the payment exchange, the payment and the receipt are securely linked through the nym Nym UM. In the message exchange for capture, both messages are linked through the signed contents of the transaction. The influence of confidentiality-protection on user unidentifiability will be discussed in Section 8.4.3. 8.3.2 Pre-Paid Payment Protocol Based on Anonymous Credentials Again we assume that U and M have (non-anonymous) accounts with issuer I. U subtracts value from that account by (non anonymously) retrieving payment credentials (e-coins), each of which has a fixed

8.3. Payment Systems Based on Anonymous Credentials 179 Participants and Key Material: User (U): {SSKey U, Cert CA U}, UserSecret U Issuer (I) {SSKey I, Cert CA I}, {ISKey I, CSKey I, Cert I I} Merchant (M): {SSKey M, Cert CA M }, {ISKey M, VSKey M, CSKey M, Cert M M} Receipt Verifier (V): {SSKey V, Cert CA V }, {VSKey V, CSKey V, Cert V V } Protocol Flows: U I M V Retrieval: Payment: Capture: Nym UI, SignedNymProof UI I: stores (OrgNym UI, Sig UI, Cert CA U, Liab U UI) CredUI I: updates (OrgNym UI, Sig UI, Cert CA U, Liab U UI, CredInfo UI) and debits U s account with CoinVal Nym UM WasShownUM I CredUM Sig M I: checks double-spending of e-coin and credits M s account with CoinVal Showing Receipt: Sig I WasShownUV M dbl sp check Figure 8.4: Pre-Paid Payment Protocol Based on Anonymous Credentials value and can be spent only once. The spending of the e-coins is anonymous towards M as well as towards I, and not linkable to U s account. In the account-based protocol, I wanted to be able to prove U s authorization to subtract money from his account. In this protocol, the authorization to subtract money is based on the issuing of an e-coin to U ; also, M wants a payment guarantee; and U wants a receipt from M in return for a payment. Of course, spending an e-coin should not be linkable to its issuing just by its exact value. We assume that e-coins exist in a number of pre-determined values, allowing the user to pay any amount by spending a number of e-coins per payment. This is the most simplistic assumption and it can be realized trivially by encoding the e-coin s value as an attribute in an Idemix one-show credential.

180 Chapter 8. Certificate- and Credential-Based Anonymous Payments Table 8.4: Pre-Paid Payment Protocol Based on Anonymous Credentials item value (first) use Cert CA X as in Table 8.1 key mat. Cert O O (O {I, M, V }) S X(CertdKeys = CertdKeys O O, Attrs = Attrs O O) key mat. Attrs O O {CertTp = SELFCERT, Liab = Liab O O} key mat. Liab I I {{LiabTp=Lt, LiabAmount=$2000, key mat. LiabCond= indirect liab a I,... },... } CertdKeys I I {IPKey = IPKey I, DPKey=DPKey I, CPKey = CPKey I } key mat. CertdKeys M M {IPKey = IPKey M, VPKey = VPKey M, CPKey = CPKey M } key mat. CertdKeys V V {VPKey = VPKey V, CPKey = CPKey V } key mat. Nym UI Nym(UserSecret U, OrgNym UI, UserNym UI ) retrieval SignedNymProof UI SignedNymProof(Sig UI, Cert CA U, OrgNym UI, Liab U UI) retrieval Liab U UI {{LiabTp = Lt, LiabAmount = $1, registr. LiabCond=direct liab b U,...},...} Cred UI Cred(OrgNym UI, UserCred UI, CredInfo UI) retrieval CredInfo UI {IPKey I, false, Expiration UI, {CoinVal = $1}} retrieval Nym UM Nym(UserSecret U, OrgNym UM, UserNym UM ) payment WasShown UMI WasShown(Transcript UMI, UserCred UI, CredShowInfo UMI, payment CredShowFeatures UMI, OrgNym UM, Trx) Trx {SPKey M, Amount, Trxid} payment CredShowInfo UMI {IPKey I, false, Expiration M, {CoinVal = $1}} payment CredShowFeatures UMI {true, VPKey M, null, null} payment Cred UM Cred(OrgNym UM, UserCred UM, CredInfo UM ) payment CredInfo UM {IPKey M, false, Expiration UM, Attrs UM } with Attrs UM = {Trxid} payment Sig M S M(Transcript UMI, SPKey M, SPKey I, Trx) capture Sig I S I(SPKey M, SPKey I, Trx) capture WasShown UVM WasShown(Transcript UVM, UserCred UM, CredShowInfo UVM, show.rcpt. CredShowFeatures UVM, null, null) CredShowInfo UVM {IPKey M, false, Expiration V, {Trxid}} show.rcpt. CredShowFeatures UVM {false, VPKey V, null, null} show.rcpt. a indirect liab I = payment with credential verified with issuing key in this certificate; subject to further liability limitations in CoinVal attribute of individual credential. b direct liab U = payment with credential issued on nym, signature on which can be verified with key certified in this certificate. Figure 8.4 and Table 8.4 represent the pre-paid anonymous payment system. Fields which differ from the ones in the account-based protocol in Table 8.3 are marked with an underline or strikethrough font. As in the account-based protocol, all parties have public/private signature key pairs and signature certificates Cert CA X certified by CA; all organizations have key pairs for securing communication; I and M have issuing key pairs for issuing e-coins and receipts, respectively; M and V have verification

8.3. Payment Systems Based on Anonymous Credentials 181 key pairs. Liabilities in Cert I I and Cert M M are similar as in the account-based system; Liab I I may not need to state a maximum transaction amount if it only issues credentials (e-coins) containing an exact transaction amount. In this setting, I does not need a de-anonymizing key pair. However, U s identity (or, at least, OrgNym UI ) will be revealed if U spends the same e-coin twice. Again, we assumed that a signature with SSKey U authorizes I to subtract money from the account defined by Liab U UI ; this time, money is subtracted at the moment of e-coin issuing. As with the account-based version, we could equally well replace Cert CA U by an I -issued Cert I U. In our pre-paid payment protocol, this certificate would be used in the e-coin retrieval process. Retrieval In the e-coin retrieval process, U obtains an unlinkable e-coin of a certain value. The signed nym registration process provides I with the evidence of U s authorization to subtract the e-coin s value from his account; the authorization and the e-coin value are included in Liab U UI. Liab U UI may also specify I s rights in case of double-spending of an e-coin; e.g., Liab U UI may also authorize I to subtract the e-coin value a second time from U s account as mentioned in the discussion about the payment process; U, of course, should be aware that this makes the payment identifiable towards I. The e-coin, Cred UI, is a one-show (MultiShow= false) e-coin issued by I (IPKey I ), with an expiration time Expiration UI and with its value ($1) encoded in its attributes. Payment In the payment transaction, U spends his e-coin to sign a payment transaction, and again gets an anonymous one-show receipt in return. The procedure is similar as for the account-based payment protocol, with following differences: The e-coin show is not de-anonymizable: as the e-coin is pre-paid, no linking with the account is needed. In case of double-spending, the one-show characteristic of the e-coin will allow I to discover OrgNym UI, and thus to link the e-coin back to a user U and a user liability Liab U UI. In the account-based protocols, the amount of the payment needed to be specified in Trx. In the pre-paid protocol discussed here, the amount of the payment is encoded in the e-coin; including the amount of the payment also in Trx is useful only when the two amounts differ. This could be the case in a modified e-coin scheme where change can be returned. Here, we chose not to include the payment amount as part of Trx. In the account-based protocol, including SPKey M in Sig U or Trx made it impossible for an imposter other than the intended merchant to capture the payment. In the pre-paid version, the capture process is too late a stage to authenticate M, as U has already spent the e-coin. I could refuse to credit M if SPKey M in Trx identity does not match Sig M, and even allow U to re-spend the e-coin without punishing for double-spending. However, even if U does not lose money in this case, potential damage to his anonymity is still done as the two transcripts would link both payments back to Nym UI. Thus, regardless of the presence of SPKey M in Trx, it is mandatory that U authenticate M before spending the e-coin. If multiple e-coins are required for making a single payment, their spending can be linked in one secure communication session, and one receipt can be issued for the total amount. If M s information about IPKey I (revocation information) is up-to-date, a valid Transcript UMI may be a payment guarantee for M, if stipulated as such in the contract between M and I. However, this would mean that I alone takes the risk of granting payments based on double-spent e-coins. Thus, I may refuse to grant such an off-line payment guarantee; in this case, M may decide to take the risk for double-spending himself, or to perform the capturing process on-line before returning the receipt. In practical operational systems, it may be worthwhile to combine efficiency with

182 Chapter 8. Certificate- and Credential-Based Anonymous Payments risk management by performing frequent batch captures of off-line payments. It is likely that at least part of the remaining risk is taken by I : I has a direct customer relationship with the user and holds a provable linking between Cert CA U and the double-spent e-coin; I is thus in a better position than M to take action against the double-spending user and to even recuperate the amount by debiting U s account. The rights of I to subtract a value related to double-spending from U s account may even be specified in Liab U UI as mentioned above. Capture Capturing the payment can thus be done on-line or off-line, depending on risk management and contracts between I and M. Before granting the credit and returning Sig I, I runs a double-spending check on Transcript UMI. If this check reveals double-spending, I can either not grant the capture or debit the amount a second time from U s account. Showing the Receipt The payment receipt and its use are similar as in the account-based protocol. However, in the pre-paid payment protocol, it is not possible for M to, after the fact, take measures against a user double-spending a receipt. Therefore, on-line double-spending detection of receipt shows is mandatory, as represented by the solid-line exchange between V and M in Figure 8.4. This issue is discussed in more detail in Section 8.4.4. Security of the Communication Channels The requirements are identical to the ones mentioned in Section 8.3.1. As discussed in previous paragraphs, authentication of M to U now not only protects against denial of service, but also protects the user against spending an e-coin with an impersonating merchant. Comparison with E-cash Schemes The pre-paid credentials introduced in this Section are similar in use as coins in known e-cash schemes based on blind signatures (e.g., [37]). A similar protocol as the one in this section could be constructed using blind signature-based coins. In this case, user liability should be ensured through an appropriate signature of the user on the blinded coin request. The ESPRIT project CAFE [24] developed digital payment systems providing high security for all parties concerned with minimal requirements for a party to trust other parties (multi-party security). A user can perform an off-line pre-paid payment (of an e-coin obtained from an issuer) using an electronic wallet of the form of a pocket calculator or Personal Digital Assistant; the wallet communicates with a pointof-sale device over an infrared communication channel. The payment is untraceable (unidentifiable and unlinkable to payments by the same user) unless the e-coin is double-spent. The CAFE protocols are based on the system from Brands [27] with some modifications. The system has blind-signature based e-coins and double-spending detection mechanisms. A major difference between the pre-paid credential-based protocols in this chapter and the CAFE protocols is the presence, in the CAFE system, of a double-spending prevention mechanism enforced by a guardian (or observer) located in the wallet. This guardian is trusted by the e-coin issuer and consists of a smartcard chip with a crypto coprocessor placed inside the wallet. The double-spending detection mechanisms of the e-coin scheme provide fall-back security for the e-coin issuer in cases where a guardian is broken. Another feature offered in CAFE is loss and fault tolerance: a user can get back the money corresponding to the unspent e-coins on a stolen, lost or broken wallet. This feature is provided by keeping a backup of the user s electronic money outside the wallet.

8.4. Analysis of Accountability and Unidentifiability of the Various Payment Protocols 183 8.4 Analysis of Accountability and Unidentifiability of the Various Payment Protocols In this section, we now compare unidentifiability and accountability features of the four payment protocols discussed in the previous sections. Accountability will be discussed in terms of which are the perceived or real risks for relying entities in the payment, and whether they can convert them into a provable liability by another party. We assume that money can only be subtracted from a user s account based on evidence that the user signed a certain payment or value subtraction and had given I the appropriate authority to subtract the corresponding amount from his account. Starting from this assumption, we investigate for each of the protocols if we can close the risk and accountability circle by propagating liabilities taken by M and I (accepting or guaranteeing a payment) back to an accountability by the user and to an authorization to subtract money from his account. Concretely, if M accepts a payment and issues a receipt, M wants to have evidence of I s accountability to credit this payment to M s account. I, in turn, wants evidence that he can debit this amount from U s account. In the discussions below, we will discuss risks for M and I ; our main goal is to show that anonymity and unidentifiability need not impact their risk. We will not explicitly address risks for U : as mentioned above, we assume that value cannot be removed from a user s account without appropriate evidence of signatures and liabilities by the user protects the user a Users are, of course, also exposed to risks related to unfairness in the form of not receiving a receipt. In all the account-based protocols, I can verify and attest that a payment from U (C, P) to M occurred; a dispute handling infrastructure as the one discussed in Chapter 3 can then be used in which I provides U with a substitute receipt. Such a substitute receipt can have a similar structure as an original receipt; only, it is issued by I instead of by M. It can thus be as pseudonymous or anonymous as a receipt issued by M. For the pre-paid payment system, however, the unfairness problem is more difficult to solve. Ideally, U would like to get a substitute receipt without losing his anonymity even towards I. This is a topic for further research. Unidentifiability of U towards M and I will be discussed. As stated before, U can only be anonymous towards a certain entity if also the communication channel supports this. However, there will be cases where other security features of the communication channel, such as confidentiality, will have an influence on the unlinkability of U s actions. We will also discuss these. Discussing the difference in receipt semantics in the various protocols is related to accountability as well as unidentifiability. The receipt is an expression of M s liability to provide a service (possibly through V ); thus, whether a receipt can be used multiple times may impact M s risk. On the other hand, the receipts and their use as we defined them for the various payment systems largely differ in the level of unlinkability they offer to the user. 8.4.1 Non-Pseudonymous Account-Based Payment Protocol Based on Certificates Risk for M For M, a first potential risk consists in accepting a payment (and issuing a receipt) for which there is no payment guarantee. After correctly verifying a payment, M can prove the following: Cert CA I proves that I is a legal entity which can be held accountable for guarantees verifiable with SPKey I ;

184 Chapter 8. Certificate- and Credential-Based Anonymous Payments Cert I C proves I s liability for payments verifiable with SPKey C if the certificate is not revoked; and Sig C is a correct payment verifiable with SPKey C. Thus, as long as M verifies the validity (non-revoked status) of the payment certificate, M has a payment guarantee by I, and a guarantee by CA of I s accountability as a legal entity. A second risk for M consists in multiple use of the receipt if this should not be allowed. (Depending on agreements between M and V, this is either V s or M s risk; assuming that the risk is taken by M does not fundamentally change the discussion; in addition, it is unlikely that a verifier V other than M would accept to take that risk.) The receipt Sig M has no inherent use limitation; if a receipt should not be used more than once, then M has to cooperate with any receipt verifier V in keeping track of its use. Risk for I If M presents I with a correctly formed payment (Sig C ) based on a non-revoked certificate Cert I C, I has a liability towards M for crediting the payment amount to M. With this payment signature, together with its associated certificates, I can now prove the following: Cert CA U : CA certifies U as a legal entity which can be held accountable for guarantees verifiable with SPKey U ; Cert U C : with a signature verifiable with SPKey U, U has taken a liability Liab U C for payments verifiable with SPKey C ; Sig C : U has made a payment to M through a signature verifiable with SPKey C. These suffice to prove that I is authorized to subtract the Trx.Amount from U s account, and that I can hold U accountable if this is not possible; ultimately also, that I can hold CA accountable if Cert CA U turns out not to be associated with a legal entity. Anonymity and Unlinkability for U As discussed in Section 8.2.1, we do not consider Cert I C to be a pseudonym certificate, even if explicit identifiers of U were not mentioned to be part of Cert I C. Therefore, we assume payments verifiable with SPKey C to be non-anonymous and easily identifiable. 8.4.2 Pseudonymous Account-Based Payment Protocol Based on Certificates Risk for M After correctly verifying a payment, M can prove the following: Cert CA I proves that I is a legal entity which can be held accountable for actions verifiable with SPKey I ; Cert I P proves I s liability for payments verifiable with SPKey P if the certificate is not revoked; and Sig P is a correct payment verifiable with SPKey P.

8.4. Analysis of Accountability and Unidentifiability of the Various Payment Protocols 185 As in the non-pseudonymous protocol, M has a payment guarantee by a certified legal entity I as long as he respects the revocation checking conditions. Also here, the receipt has no inherent use limitation, and M and V should keep track of its use if the receipt should not be used multiple times. Risk for I For the payments for which I has a liability towards M, I can prove the same as in the previous original protocol, albeit using an extra certification step: Cert CA U : CA certifies U as a legal entity which can be held responsible for actions verifiable with SPKey U ; Cert U C : with a signature verifiable with SPKey U, U has taken a liability Liab U C for payments verifiable with a key for which a liability was accepted using a signature verifiable with SPKey C ; Cert C P ; with a signature verifiable with SPKey C, U has accepted liability for payments verifiable with SSKey P ; Sig P : with a signature verifiable with SPKey P, U has made a payment to M. Anonymity and Unlinkability for U Cert I P is a pseudonym certificate; we can say that a payment verifiable with SPKey P is thus anonymous towards M, and a receipt showing verifiable with SPKey P is anonymous towards V. The pseudonymous certificates can be used exactly as the certificates in the non-pseudonymous protocol. It is up to U to decide how long he wants a pseudonym certificate to be valid, and how many payments he wants to make with one pseudonym certificate; this may depend on how many and which payments U allows to be linkable by M and/or V. The choice of including a transaction identifier in the receipt was made to allow a limitation of its use; this also makes the receipt, and its use, linkable to the payment. Again, as mentioned in Section 7.7.3, anonymity of U towards M (V ), and unlinkability of U s payments towards M (V ), also rely on the communication channels used by U being anonymized. In this case, these are at least the communication channels used between U and M, and between U and V ; also, in order to avoid that M, V or any wiretapper on the U -I channel finds out the relationship between U (Cert CA U ) and SPKey C, or between SPKey C and SPKey P, the U -I communication channel on which certificate requests and responses are exchanged should at least be confidentiality-protected. I, of course, receives the data of payments made by U (at least, the amount and the merchant involved, according to the definition of Sig C and Trx in Section 8.2.1). This is unavoidable in an account-based payment system; it can only be excluded in a pre-paid payment system. 8.4.3 Account-Based Payment Protocol Based on Anonymous Credentials Risk for M After correctly verifying a payment, M can prove the following: Cert CA I certifies I as a legal entity accountable for guarantees verifiable with SPKey I ; With Cert I I, I signs, in a signature verifiable with SPKey I, a liability Liab I I, containing I s payment guarantee for payments (up to a maximum amount per transaction) with non-revoked credentials issued by IPKey I ;

186 Chapter 8. Certificate- and Credential-Based Anonymous Payments From WasShown UMI, it follows: SigProof(Transcript UMI, CredShowInfo UMI, CredShowFeatures UMI, OrgNym UM, {SPKey M, Amount, Trxid}), where CredShowInfo UMI.IPKey = IPKey I ; ; thus, M can prove to have received a correctly formed payment signed with a credential verifiable with IPKey I. Together, these provide evidence of I s liability for crediting the payment amount to M if the payment is based on a non-revoked credential. If a risk is associated with multiple use of the payment receipt, M can exclude that risk by enforcing that the receipt can be shown only once. In case of double-spending, M has Transcript UV1, Transcript UV1 with WasShown(Transcript UV1, UserCred UM, CredShowInfo UV1, CredShowFeatures UV1, null, null), WasShown(Transcript UV2, UserCred UM, CredShowInfo UV2, CredShowFeatures UV2, null, null), Cred(OrgNym UM, UserCred UM, CredInfo UM ), Nym(UserSecret U, OrgNym UM, UserNym UM ), CredInfo UM.MultiShow = false and CredInfo UM.IPKey = IssuerKeys M.IPKey. From this and Section 7.4.3, it follows that: OCheckDblSpWProof(IssuerKeys M, Transcript UV1, Transcript UV2 ) returns OrgNym UM, DblSpTranscript MUM with DblSpProof(DblSpTranscript MUM, Transcript UV1, Transcript UV2, OrgNym UM ). M has no linking between OrgNym UM and U (or OrgNym UI ). M could, however, rely on I for further de-anonymization of the receipt show. M retrieves Transcript UMI, which is provably related to OrgNym UM and asks I to de-anonymize Transcript UMI to reveal OrgNym UI, in the same way as I de-anonymizes any payment Transcript UMI to find out which account to debit. The choice of relying on I for this further de-anonymization in case of receipt double-spending can be motivated as follows: M already has a contractual relationship with I, based on I s guarantee of crediting M for valid payments. It makes sense to extend this relationship such that I would act as global de-anonymizer for payment transactions where the receipt is double-spent. M can prove the double-spending by OrgNym UM to I and can also prove to I the linking between OrgNym UM and Transcript UMI ; from there, I can de-anonymize Transcript UMI to find OrgNym UI and Cert CA U. I can link all U s transactions; thus, U has anyway to trust I not to share this information with M or V. It is thus a realistic requirement that U also trusts I to not unfairly perform this global de-anonymization. We made this choice in order to avoid the extra complexity of additional de-anonymizers. If U or M do not trust I to fulfil the role of global de-anonymizer, or if other reasons exist preventing I from fulfilling that role, two alternatives exist: One can easily extend the payment system with a root authority and a dedicated de-anonymizer supporting this global de-anonymization; One could use on-line double-spending detection of the receipt show. In this case, V verifies on-line whether a receipt is still valid, and can choose not to grant the goods or the service in case it was already spent. This suffices to exclude risk for M and V, but does not allow other measures against the potentially fraudulent user.

8.4. Analysis of Accountability and Unidentifiability of the Various Payment Protocols 187 Risk for I If M presents I with a request for capture containing a valid Transcript UMI credential Cred UI, I can prove the following: based on a non-revoked Cert CA U again proves CA s certification of U as a legal entity which can be held accountable for actions verifiable with SPKey U ; SignedNymProof UI proves that U, by signing Liab U UI with a signature verifiable with SPKey U, authorized I to subtract money from the account associated with Cert CA U for payments with a payment credential issued on OrgNym UI ; WasShown UMI, with CredShowFeatures UMI.LocalDeAnData.DPKey = DeAnOrgKeys I.DPKey enables I to de-anonymize Transcript UMI and obtain OrgNym UI : DODeAnonLocalWProof(DeAnOrgKeys I, Transcript UMI ) returns DeAnTranscript IUM, with LDeAnProof(DeAnTranscript IUM, Transcript UMI, OrgNym UI ). Together with SigProof(Transcript UMI, CredShowInfo UMI, CredShowFeatures UMI, OrgNym UM, {SPKey M, Amount, Trxid}) this allows I to prove that the payment to M specified in Trx was signed with a credential issued on OrgNym UM. Together, these provide evidence of I s authorization to subtract the Trx.Amountfrom U s account; or to take measures against U or CA (as discussed in Section 8.4.1) if the account balance does not suffice. Anonymity and Unlinkability for U We now analyze the anonymity features of the registration, payment and receipt showing protocols using the linkability assertions defined in Section 7.5. We want to analyze linkability in a system state with maximal potential linkability, i.e., where the user has made multiple payments and has shown all receipts. As making all the payments to the same merchant can only increase linkability as opposed to having one payment each to a different merchant, we assume that all the payments are to the same merchant. Following the same reasoning, we assume that all the receipts are shown to the same verifier. Making the merchant also the verifier of his own receipts would even provide for a better case of maximal linkability. We will not make this choice as, in our notation, this would make it hard to distinguish between payment transcripts and receipt show transcripts. Instead, the case where merchant and verifier are the same entity will be included in the analysis by assuming that M and V share data. Thus, we consider the system in a state where U has made multiple (m) payments (WasShown UMI (i), i = 1...m) to M, each resulting in a receipt Cred UM (i). Each Cred UM (i) has been shown once to V (in WasShown UVM (i)). According to Table 8.3, following assertions hold in this state:

188 Chapter 8. Certificate- and Credential-Based Anonymous Payments Nym UI = Nym(UserSecret U, OrgNym UI, UserNym UI ) SignedNymProof UI Cred UI Nym UM (i) WasShown UMI (i) Cred UM(i) WasShown UVM (i) with parameter contents = SignedNymProof(Sig UI, Cert CA U, OrgNym UI, Liab U UI) = Cred(OrgNym UI, UserCred UI, CredInfo UI) = Nym(UserSecret U, OrgNym UM (i), UserNym UM (i)) = WasShown(Transcript UMI (i), UserCred UI, CredShowInfo UMI (i), CredShowFeatures UMI, OrgNym UM (i), Trx(i)) = Cred(OrgNym UM (i), UserCred UM (i), CredInfo UM(i)) = WasShown(Transcript UVM (i), UserCred UM(i), CredShowInfo UVI (i), CredShowFeatures UVM, null, null) CredInfo UI = {IPKey I, true, Expiration UI, {MaxAmt = $1000}} CredShowInfo UMI (i) CredShowFeatures UMI CredInfo UM (i) Trx(i) CredShowInfo UVI (i) CredShowFeatures UVM = {IPKey I, any, Expiration Mi, {MaxAmt Trx(i).Amount}} = {true, VPKey M, {DPKey I, null}, null} = {IPKey M, false, Expiration UM (i), {Trxid(i)}} = {SPKey M, Amount i, Trxid(i)} = {IPKey M, false, Expiration Vi, {Trxid(i)}} = {false, VPKey V, null, null} For each payment WasShown UMI (i) and receipt Cred UM (i), U uses a different nym (Nym UM (i)) to keep the payments from becoming linkable towards M. The different payments have different transaction features Trx(i) and identifiers Trxid(i). The following clarifies our assumptions about the uniqueness of parameters: The CredShowInfo UMI (i) for individual payments may differ in expiration time requirements, as the payments may occur at different times; we do not consider these expiration times to make a credential show identifiable (the credential show only proves that a credential expires after the current date). If we also assume that the MaxAmts are distributed such that payment of a certain Trx.Amount does not identify the credential, the various CredShowInfo UMI (i) are not considered unique for the purpose of reasoning about linkability. In addition to expiration time, various CredShowInfo UVI (i) of receipt shows may have a different Trxid(i); the Trxid(i) makes them unique. CredShowFeatures UMI is the same for all payments; and also CredShowFeatures UVM is the same for all receipt shows. Trxid(i) is included in the receipt s attributes CredInfo UM (i).attrs.trxid, and thus CredInfo UM (i) is different for each receipt. The derivation of the linkability assertions (1) to (8) below can be motivated as follows: As another maximum-linkability assumption, we assume that Liab U UI is unique per user or otherwize identifies the user; hence also assertion (2) resulting from SignedNymProof UI (see Section 7.5.3). WasShown UMI (i) is relative to a nym, is de-anonymizable, and has Trxid(i) in its Msg as unique parameter. Hence, assertions (3), (4) and (5) (see Sections 7.5.7 to 7.5.10). The fact that Trxid(i) is included in the receipt attributes, and makes CredInfo UM (i) unique, results in assertion (6) (see Section 7.5.6).

8.4. Analysis of Accountability and Unidentifiability of the Various Payment Protocols 189 WasShown UVM (i) is not relative to a nym, nor de-anonymizable. It has two linkability assertions resulting from it: (7) results from the fact that Cred UM (i) is a one-show credential (Section 7.5.11), and (8) results from the fact that the unique Trxid(i) is verified as part of the attributes (Section 7.5.8). SignedNymProof UI, Unique(Liab U UI ) (1) Linked(I, null, OrgNym UI, Cert CA U ), (2) Linked(I, null, Liab U UI, Cert CA U ). WasShown UMI (i), CredShowFeatures UMI.RelNym = true, WasShown UMI (i).orgnym = OrgNym UM (i) (3) Linked(M, null, Transcript UMI (i), OrgNym UM (i)). WasShown UMI (i), WasShown UMI (i).msg = {SPKey M, Amount, Trxid(i)}, Unique(Trxid(i)) (4) Linked(M, null, Transcript UMI (i), Trxid(i)). WasShown UMI (i), CredShowFeatures UMI.LocalDeAnData = {DPKey I, null} (5) Linked(I, null, Transcript UMI (i), OrgNym UI ). Cred UM (i), CredInfo UM (i).attrs = {Trxid(i)}, Unique(Trxid(i)) (6) Linked(M, null, OrgNym UM (i), Trxid(i)). WasShown UVM (i), CredInfo UM (i).multishow = false (7) Linked(M, dblspent, OrgNym UM (i), Transcript UVM (i)). WasShown UVM (i), CredShowInfo UVI (i).attrs = {Trxid(i)}, Unique(Trxid(i)) (8) Linked(V, null, Transcript UVM (i), Trxid(i)). (1), (2) and (5) are the linkabilities towards I. We see that, through OrgNym UI, I can link U s real identity Cert CA U and U s signed liabilities Liab U UI to OrgNym UI ; I can also link every payment transaction (Transcript UMI (i)) made by U to OrgNym UI. None of the other linkabilities (towards M or V ) contain OrgNym UI. Thus, it follows that U s anonymity towards M and V is unconditional as long as I does not collude with M or V. Without cooperation from I (e.g., to link a Transcript UMI (i) to OrgNym UI ), the only linkabilities M and V together can derive are between the payment transaction (or the receipt show) and the nym shared between U and M ; this is a nym only used in this transaction, and which M or V cannot link back to OrgNym UI or Cert CA U. Also in case of double-spending, M only gets to know OrgNym UM. As discussed in Section 8.4.3, doublespending of a receipt may convince I to collaborate with M and reveal the associated OrgNym UI and Cert CA U to M ; or, double-spending detection of the receipt could be done on-line. In the latter case, I need not be involved and U even remains anonymous in case of receipt double-spending; the only consequence for U is not receiving the service or goods. As Trxid(i) is linking payment to receipt verification, M and V together can link any receipt verification back to the payment and to OrgNym UM (i), but not to OrgNym UI. This is a design option of our protocol. If this verification of Trxid(i) in the receipt were not required, M and V could not link payment and receipt show, unless in case of double-spending of a receipt. With respect to unidentifiability of U towards I, M and V, we can thus conclude the following: U has no anonymity or unlinkability towards I : I can link all a user s transactions to the user s identity. This is consistent with our system design where we needed I to be able to identify the account to debit, as well as a user to hold accountable. U can use the same payment credential multiple times; his actions towards M and V remain unidenti-

190 Chapter 8. Certificate- and Credential-Based Anonymous Payments fiable on condition that I does not collude to reveal the linking between a payment transcript and the user. In our design, M issues receipts which are unique for a payment transaction, and also V asks for these unique attributes when verifying the receipt. Therefore, M and V can link the showing of the receipt back to the payment transaction and to OrgNym UM (but not to the user). This would not be the case in another application with non-unique receipts. If a receipt is one-show, then showing it multiple times also will allow M and V to discover the nym on which the receipt was issued; in this case, I still needs to collaborate to find the identity of the double-spender. Of course, U s anonymity towards merchants and verifiers needs to be supported by sender anonymity in the communication channels used by U with M and V. As opposed to the systems based on conventional certificates, no confidentiality between U and I is needed; as discussed in Section 7.7.3, this channel does not leak any information linking the issuing of a payment credential to its use. Thus, U s anonymity requires less assumptions on the confidentiality of the communication channel than in the pseudonymous system based on conventional certificates. 8.4.4 Pre-Paid Payment Protocol Based on Anonymous Credentials Risk for M In the pre-paid setting, the e-coin value is encoded in CredInfo UI and verified by M in CredShowInfo UMI. Based on a similar reasoning as in the previous account-based case, Cert CA I, Cert I I and WasShown UMI together provide M with evidence that I is liable for crediting the payment if the e-coin is not revoked. Also here, M can enforce that a receipt be used only once. In case of double-spending of a receipt, M has the same evidence as in the case of the account-based version: DblSpProof(DblSpTranscript MUM, Transcript UV1, Transcript UV2, OrgNym UM ). However, in this case, M cannot count on I to de-anonymize the payment Transcript UMI associated with OrgNym UM : as we will see in the next paragraphs, even I can reveal this linking only in case of double-spending of the e-coin itself. Two alternatives exist allowing M to exclude risk related to double-spending of receipts: On-line double-spending detection of the receipt show (as in Section 8.4.3): V does not deliver the service or goods if a receipt is double-spent. Introduction of a Root Authority and a de-anonymization organization, combined with any of the methods discussed for global de-anonymization. E.g., as in Section 7.6.1, V could verify the root credential as well as the receipt relative to a Nym UV and request the receipt show to be locally de-anonymizable. An additional risk for M could result from accepting e-coins without verifying double-spending on-line. As discussed in Section 8.3.2, risk for I and M related to double-spending of an e-coin can be completely protected against by on-line double-spending detection; in the interest of efficiency, I could allow M to batch-capture e-coin payments and still grant capture of double-spent e-coins if I can compensate for this overspending by debiting the user s account after the fact. Risk for I In the pre-paid case, I cannot link a value subtraction (e-coin issuing) to the corresponding value claim (capture). I thus has to make sure of the following:

8.4. Analysis of Accountability and Unidentifiability of the Various Payment Protocols 191 I only issues e-coins if I can prove it can subtract the corresponding value from the user s account; I only grants capture if it is convinced the capture is related to a unique spending of an e-coin it issued. As to the first requirement, the following holds. I issues electronic money (the e-coin) based on U s value subtraction in SignedNymProof UI. SignedNymProof UI proves that the user owning Cert CA U, with Liab U UI, authorized I to subtract the amount from U s account. Again, Cert CA U completes this guarantee with a liability of a legal entity. Double-spending verification deals with the second requirement. A request for capture contains a wellformed e-coin payment transcript WasShown UMI, from which I can determine if it was already spent. I can exclude all risk by only granting capture for first-spent e-coins; alternatively, I may grant capture of a double-spent e-coin. In the latter case, with the evidence of double-spending, I has appropriate evidence to debit U s account or take other compensation measures as stipulated in Liab U UI. Anonymity and Unlinkability for U We again assume a state where U has retrieved multiple e-coins from I and has made multiple payments to M ; each of the payment receipts has been shown once to V. According to Table 8.4, following assertions now hold: Nym UIi = Nym(UserSecret U, OrgNym UIi, UserNym UIi ) SignedNymProof UIi = SignedNymProof(Sig UIi, Cert CA U, OrgNym UIi, Liab U UIi ) Cred UIi = Cred(OrgNym UIi, UserCred UIi, CredInfo UIi ) Nym UM (i) WasShown UMI (i) Cred UM(i) WasShown UVM (i) with parameter contents CredInfo UIi CredShowInfo UMI (i) CredShowFeatures UMI CredInfo UM (i) Trx(i) CredShowInfo UVI (i) = Nym(UserSecret U, OrgNym UM (i), UserNym UM (i)) = WasShown(Transcript UMI (i), UserCred UIi, CredShowInfo UMI (i), CredShowFeatures UMI, OrgNym UM (i), Trx(i)) = Cred(OrgNym UM (i), UserCred UM(i), CredInfo UM (i)) = WasShown(Transcript UVM (i), UserCred UM (i), CredShowInfo UVI (i), CredShowFeatures UVM, null, null) = {IPKey I, false, Expiration UIi, {CoinVal i}} = {IPKey I, false, Expiration Mi, {CoinVal i}} = {true, VPKey M, null, null} = {IPKey M, false, Expiration UM (i), {Trxid(i)}} = {SPKey M, Trxid(i))} = {IPKey M, false, Expiration Vi, {Trxid(i)}} CredShowFeatures UVM = {false, VPKey V, null, null} As a signed nym registration is needed for each e-coin, each e-coin Cred UIi is issued on a different Nym UIi. We again assume that Liab U UIi has a user-identifying component. However, we assume that there are no unique e-coin values and that many e-coins on each possible value are issued. Therefore, the spending of an e-coin (in a WasShown UMI (i)) with a specific CoinVal i cannot be traced back to a Liab U UIi in an e-coin retrieval. We again derive linkabilities. (2) is related to Liab U UIi being unique. WasShown UMI (i) has linkabilities related to the e-coin being one-show (5), to its Msg containing the unique Trxid(i) (4), and to it being relative to a nym (3). (6) is related to the receipt being unique because of Trxid(i). (7) and (8) are linkabilities resulting from WasShown UVM (i); (7) is related to the receipt being a one-show credential; (8)

192 Chapter 8. Certificate- and Credential-Based Anonymous Payments to the fact that the receipt show has a unique parameter through Trxid(i). SignedNymProof UIi, Unique(Liab U U i ) (1) Linked(I, null, OrgNym UIi, Cert CA U ), (2) Linked(I, null, Liab U UIi, Cert CA U ). WasShown UMI (i), CredShowFeatures UMI.RelNym = true, WasShown UMI (i).orgnym = OrgNym UM (i) (3) Linked(M, null, Transcript UMI (i), OrgNym UM (i)). WasShown UMI (i), WasShown UMI (i).msg = {SPKey M, Trxid(i)}, Unique(Trxid(i)) (4) Linked(M, null, Transcript UMI (i), Trxid(i)). WasShown UMI (i), CredInfo UIi.MultiShow = false (5) Linked(I, dblspent, OrgNym UIi, Transcript UMI (i)). Cred UM (i), CredInfo UM (i).attrs = Trxid(i), Unique(Trxid(i)) (6) Linked(M, null, OrgNym UM (i), Trxid(i)). WasShown UVM (i), CredInfo UM (i).multishow = false (7) Linked(M, dblspent, OrgNym UM (i), Transcript UVM (i)). WasShown UVM (i), CredShowInfo UVI (i).attrs = {Trxid(i)}, Unique(Trxid(i)) (8) Linked(V, null, Transcript UVM (i), Trxid(i)). From (1) and (2), it follows that I knows the values of the e-coins issued to U. This cannot be avoided, as the e-coin values need to be subtracted from U s account. The only further linkability in which OrgNym UIi appears is (5). This linkability by I of OrgNym UIi with Transcript UMI (i) only appears in case of double-spending of the e-coin in WasShown UMI (i). Thus, it follows that a payment Transcript UMI (i) can never be linked back to the user if the e-coin itself is not double-spent; thus a single e-coin spending is unidentifiable towards M, V as well as I. This is regardless of double-spending of the receipt. M can link the use of a receipt to a payment Transcript UMI (i) and its nym OrgNym UM (i) in case of double-spending of the receipt; also, because of the linking through Trxid(i), M and V together can link a receipt verification back to a payment and OrgNym UIi. However, even I cannot link any payment back to the user (OrgNym UIi ) unless the payment itself is also a double-spending of the e-coin. Thus, unless global de-anonymization of the receipt show is introduced, even a user double-spending a receipt remains unidentifiable towards M and V, and can only be punished by not receiving the goods or the service a second time. This is the reason why on-line double-spending of receipts is mandatory in this protocol. As with the account-based payments based on anonymous credentials, the only assumption on the communication channels is sender anonymity in the communication channels between U and M (V ). 8.4.5 Additional Remarks on the Use of Certificates vs. Anonymous Credentials In the above protocols, we have assumed receipts to be usable only once. In protocols based on certificates, double-spending has to be verified by tracking usage of individual receipts between receipt users and receipt verifiers. This mandates that every receipt, and every receipt usage, is linkable to a specific payment transaction and pseudonym (or user). Using anonymous credentials, single usage of receipts can be enforced, or at least double-usage detected, by on-line or off-line double-spending detection; this is possible also if the receipt itself carries no reference

8.4. Analysis of Accountability and Unidentifiability of the Various Payment Protocols 193 to the payment transaction. In our examples based on anonymous credentials, we have chosen to make payment and receipt usage linkable (through Trxid) in order to have the same functionality as in the certificate-based protocols; we also wanted to show that, despite this linkability, each of a user s payments was unlinkable to each other payment or to the user s identity. However, this linkability of receipt to payment was not needed to enforce single-use of the receipt. In other words, a receipt usage need only become linkable to a payment and a nym (and possibly to a user) in case it is double-spent. Thus, only using anonymous credentials, we can realize anonymous and fully unlinkable receipts while at the same time enforcing single use. Let us now consider that our application allows receipts to be used multiple times. A receipt could represent, e.g., an on-line newspaper subscription. Using certificates, all the uses of the same receipt would again be linkable to each other and to the payment. In addition, it is difficult to guarantee that a receipt is used only by the legitimate user: a user may decide to share the receipt together with its signing key SSKey P with a number of friends. The fact that this allows his friends to also make a pseudonymous payment on U s behalf may retain him from doing so; however, U could have made the liabilities in this specific Cert C P low enough (e.g., very small amounts) such that he does not risk all that much. Thus, using certificates, sharing a payment receipt is not very well protected against. Also here, anonymous credentials allow more unidentifiability as well as security. A multi-show receipt credential can be used multiple times, without the different uses being linkable. This is a major improvement as compared to protocols based on certificates. In the credential-based system, users are discouraged from sharing a receipt as such sharing implies sharing UserSecret U ; this is the equivalent of handing over a bank card together with his PIN or password. Of course, honest users should be supported in limiting the risk related to their UserSecret U and credentials being stolen. An electronic credential wallet storing UserSecret U and possibly associated credentials on a tamper-evident device (smartcards, PDAs) can help honest users to keep their secrets and credentials secure; in addition, it is possible for the bank to block the account associated with a stolen wallet when such theft is reported. In both account-based as pre-paid protocols based on credentials, this can prevent further withdrawals and payments from the account. It can, however, not prevent that possible credential-based e-coins remaining in the wallet are spent by the thief. 8.4.6 Risks Related to a Breakdown of the Credential System or Compromise of Secrets Our risk analysis of the above credential-based protocols relies on the basic security properties of the credential system, such as unforgeability of credentials and the correct functioning of de-anonymization and double-spending detection. Of course, it also relies on the assumption that organizations can keep their secret keys secret. We will briefly discuss the risks related to key compromises as they also cover the risks of successful attacks on the underlying cryptographic algorithms. E.g., in the account-based protocol, if an attacker can compromise the bank s issuing key, he can issue credentials on its behalf (credential forging) that are not linked to a real identity; this also breaks de-anonymization. In the pre-paid protocol, if an attacker can compromise the bank s e-coin issuing key, he can again issue e-coins at will. Double-spending detection becomes irrelevant, and even if he double-spenda a self-issued e-coin, the double-spending detection does not reveal a real identity. These risks also exist in public-key based protocols without unidentifiability. E.g., if SET certificates could be forged, merchants and acquirers would accept payment requests with forged certificates as valid. Important is how easily or quickly such attacks or compromises can be detected and which measures can be taken to contain the total damage. Unidentifiability, and specifically the unlinkability of a payment with an account or individual as in our pre-paid system, makes detection and tracing hard. For the development and deployment of real systems, risk containment and efficient revocation will be indispensable.

194 Chapter 8. Certificate- and Credential-Based Anonymous Payments 8.5 Conclusion In this chapter, we have discussed payment protocols based on certificates as well as anonymous credentials, and compared them using criteria of user accountability and user unidentifiability. The protocols most suitable for a direct comparison are the pseudonym certificate-based protocol and the account-based protocol based on credentials. The goals of both protocols are unlinkability and anonymity of a user s payments, and of the related uses of payment receipts towards merchants and receipt verifiers; unidentifiability towards the bank (certificate issuer) was not considered as payments are account-based, and capturing requires identification of the correct account to debit. From the comparison between these protocols, we see that the introduction of anonymous credentials allows for a higher level of unidentifiability without reducing accountability. Unidentifiability, as verified using the linkability assertions defined in Chapter 7, is improved in several respects by the introduction of anonymous credentials. First, the same anonymous payment credential can be used multiple times with the same merchant, without the merchant being able to link the different payments; in the certificate-based protocol, payments made with the same pseudonym certificate are linkable. Second, in the credential-based protocol, the user does not depend on confidentiality of his communications to preserve the unlinkability between his identity and the actions under a pseudonym; whereas in the certificate-based protocol, the communication between a user and the pseudonym certificate issuer would annihilate the user s anonymity towards merchants or verifiers when using the pseudonym certificate. Accountability is not sacrificed by the introduction of anonymous credentials, as we showed in the various risk analyses. Moreover, by using anonymous credentials also for payment receipts, we were able to improve on the security and accountability of receipt use by providing stronger protection against receipt sharing, and by enabling receipts of which single usage could be enforced. A further step in unidentifiability was taken with the introduction of the pre-paid payment protocol based on anonymous credentials. Here, payments become also anonymous towards the bank (issuer of payment certificates or e-coins), again without compromising on security or accountability. In each of the protocols discussed, minimizing or excluding specific risks despite anonymity and unlinkability was achieved by ensuring accountability of various transaction participants. For users, payment certificate issuers as well as merchants, accountability can only be of value if endorsed by well-defined responsabilities and liabilities in the various certificates linking the anonymous credentials infrastructure with an external Public-Key Infrastructure. We illustrated these liabilities and responsabilities in our examples. Despite our optimistic conclusions, financial institutions may be reluctant to introduce unidentifiability in payment transactions. As discussed in Chapter 1, financial or other service providers have little incentive to invest in privacy-enhancing infrastructures. An additional cause for reluctance was discussed in Section 8.4.6 and relates to the difficulty of fraud detection and traceability inherent in systems with a high degree of user unidentifiability, such as our pre-paid payment system. Methods for containing risk in the event of keys being compromised or cryptographic algorithms being broken may need to be developed and put in place before such systems can be widely deployed. Another factor inhibiting deployment of systems with unidentifiability is the need for sender anonymity at the communications layer as discussed in Sections 7.2.1 together with the lack of effective solutions and infrastructures for sender anonymity in real-time communications. The take-off and success of application-level systems providing unidentifiability will depend on the development of such infrastructures.

Chapter 9 Designing Real Applications Based On Anonymous Credentials: From Identity-Based To Risk-Driven Design Certificates are dead, long live anonymous credentials? We certainly hope to have convinced the reader of the fact that using anonymous credentials allows us to design privacy-friendly applications without compromising on security or accountability. However, an IT professional considering introduction and deployment of an anonymous credential system will have to deal with additional practical concerns, two of which we address in this chapter. The first concern is about the usability of anonymous credentials if privacy is not a requirement or even undesirable. This issue can be phrased as a compatibility question: can anonymous credentials provide the same functionality (including linkability and identifiability) as conventional certificates, and thus support identity-based authentication and authorization? This question is dealt with in Section 9.1. The second issue is that of providing a comprehensive approach for designing privacy-friendly and secure applications based on anonymous credentials. In Section 9.2, we propose a risk-driven approach for the design of applications for accountability and unidentifiability using anonymous credentials; we also illustrate the suitability of this approach for applying the principles for accountability and unidentifiability outlined in Chapter 1. Section 9.3 concludes the chapter. 9.1 Non-Anonymous Applications Based On Anonymous Credentials: Supporting Identity-Based Authentication and Authorization As illustrated with the various payment scenarios in Chapter 8, the introduction of anonymous credentials substantially improves the achievable level of unidentifiability that can be offered to users, without reducing security or accountability. In the various scenarios, security and accountability could even be improved as compared to solutions using conventional certificates by the introduction of mechanisms preventing credential sharing and of mechanisms preventing the multiple use of credentials (such as receipts). 195

196 Chapter 9. From Identity-Based to Risk-Driven Design In the examples discussed, the accountability requirements were stated from the point of view of a privacy-friendly application designer, i.e., from a standpoint that identification is undesirable and reidentification should be possible only under well-defined circumstances. We showed that, with anonymous credentials, we could then achieve the required accountability with anonymous credentials with less identifiability than using conventional certificates. So far, we have thus tried to support the claim that we can achieve more (unidentifiability, privacy) with anonymous credentials. We have not, however, addressed the issue whether anonymous credentials can be used for applications where unidentifiability is not a requirement or even undesirable. A convincing case can be made when supporting conventional, i.e., identity-based, authentication and authorization models. The question then becomes: can we achieve exactly the same (not more ) with anonymous credentials? The optional linkabilities and conditional (re-)identification of our anonymous credential system of course allow for such a use, as we will illustrate in the following paragraphs with an example. In Section 9.1.1, we construct a simple application using the various building blocks of a certificate-based system and analyze its accountability, de-anonymization and linkability characteristics. In Section 9.1.2, we construct a similar application based on anonymous credentials and show that it achieves the same accountability, de-anonymization and linkability features. Section 9.1.3 states our findings related to the compatibility issue. 9.1.1 An Example Application Based on Certificates In a conventional certificate infrastructure with liability-enhanced certificates as described in Chapter 5 and applied in Chapter 8, we have used three basic building blocks: signatures, certificates and certificate requests. A typical application should thus ideally use these various building blocks. We also introduce a fourth building block, an issuing organization s self-signed certificate. The introduction of the issuer s self-signed certificate allows for an easier comparison with anonymous credential systems, where we introduced the same concept. Also, it offers the same advantages as in an anonymous credential system: It allows an issuer I to specify the details of his responsibilities and liabilities without these details, or updates and changes thereof, being visible to or needing certification by the certification authority certifying I ; It allows I to take liabilities common for all the certificates issued with ISKey I ; this may not only be more efficient than including liabilities in every certificate issued; it may also be more privacy-friendly, as certificate-specific liabilities could cause distinguishability between otherwize undistinguishable certificates. Figure 9.1 and Table 9.1 show an example application using these building blocks. The participants in the application are: a user U, a certificate issuer I and a relying (verifying) party V. The application consists of U obtaining a (pseudonym) certificate from I and using (the signature key associated with) that pseudonym certificate to engage in a transaction with V. Certificate contents follow the generalized notation from Table 5.1. U s, I s and V s signature public keys are certified by certification authority CA. As motivated before, issuer I has two levels of signature keys; with his master signature private key SSKey I, I signs his self-signed certificate Cert I I certifying the public issuing key IPKey I. The application consists of the following exchanges. In a certificate request/response exchange, U sends a signed (with his master signature key SSKey U ) certificate request Cert U C to I ; I verifies the request and returns the pseudonym certificate Cert Ii C. As introduced in Table 5.1, I i in Cert Ii C stands for I in its role of certificate issuer and indicates that the certificate is signed with ISKey I. U verifies Cert Ii C; he then signs a message Msg UV with the pseudonym signature key corresponding to Cert Ii C and sends the resulting Sig C, the authenticated service request, to V ; upon correct verification of Sig C, V may then grant U access to a service. Msg UV is likely to be a message unique for this transaction:

9.1. Non-Anonymous Applications Based On Anonymous Credentials 197 Participants and Key Material: U (SSKey U, Cert CA U ), I (SSKey I, Cert CA I, ISKey I, Cert I I), V Protocol Flows: U I V Certificate Request/Response: Transaction: CertU C CertI i C Sig C Figure 9.1: Example Certificate-Based Application: Participants, Key Material and Protocol Flows even if it does not contain transaction-specific data, it should contain a timestamp or a nonce allowing V to verify the timeliness of the request. The transport of certificates is not depicted in Figure 9.1. It is assumed that the verifier of a signature (on a certificate, certificate request or another message) has, or receives together with the message containing a signature, the necessary certificates for verifying the signature. Thus, U has Cert CA I and Cert I I ; I has Cert CA U ; V has Cert CA I, Cert I I and Cert Ii C. All parties, of course, have an authentic copy of SPKey CA. The certificate request is the basis for user accountability in the system: a user, using a private digital signature key SSKey U, takes responsibility for actions with another key SSKey C ; the public keys SPKey U and SPKey C can be seen as identities or pseudonyms of the user. Table 9.1: Example Certificate-Based Applicaton: Certificate and Message Contents Cert CA X S CA(CertdKeys = {SPKey = SPKey X }, Attrs = {CertTp = CERT, Liab = Liab CA X}) Cert I I S I(CertdKeys = {IPKey = IPKey I }, Attrs = {CertTp = SELFCERT, Liab = Liab I I, Addr = Addr I, Rules = Rules I, Contr = Contr I}) Cert U C S U (CertdKeys = {SPKey = SPKey C }, Attrs = {CertTp = CERTREQ, Liab = Liab U C, LiabReq = Liab I C, CertrKeyReq = SPKey I }) Cert Ii C S Ii (CertdKeys = {SPKey = SPKey C }, Attrs = {CertTp = CERT, Liab = Liab Ii C}) Sig C S C(Msg UV ) Msg UV service request message

198 Chapter 9. From Identity-Based to Risk-Driven Design Table 9.2: Example Certificate-Based Application: Evidence and Provable Statements Who Evidence Proves fact V Sig C Owner of SPKey C signed Msg UV V Cert CA I Owner of SPKey CA certified (SPKey I, Liab CA I ) V Cert I I Owner of SPKey I self-certified (IPKey I, Liab I I, Addr I, Rules I, Contr I ) V Cert Ii C Owner of IPKey I certified (SPKey C, Liab Ii C) I Cert CA U Owner of SPKey CA certified (SPKey U, Liab CA U ) I Cert U C Owner of SPKey U signed (SPKey C, Liab U C, Liab I C, SPKey I ) We now discuss the provable statements and de-anonymization and linkability features related to U s actions towards I and V. Evidence and Accountability Table 9.2 lists the evidence collected by I and V, and what they can prove with this evidence: With the evidence collected, V can prove the following: Msg UV was signed by the owner of SPKey C, which was certified in Cert Ii C by the owner of IPKey I. The issuer of this certificate took a general liability of Liab I I for certificates issued with IPKey I ; and a specific liability of Liab Ii C for the certificate Cert Ii C and transactions verified with the certified public key SPKey C. The issuer himself is certified by CA who makes certain guarantees and takes certain liabilities in Cert CA I ; I can prove that the owner of SPKey U, certified by CA in Cert CA U together with Liab CA U, took liability Liab U C for SPKey C and requested a certificate issued by I (SPKey I ) with liability Liab I C. De-Anonymization Sig C and Cert Ii C by themselves provide a trivial form of local de-anonymization: Cert Ii C itself contains SPKey C, which is the equivalent of a pseudonym on which Cert Ii C is issued. To achieve the equivalent of global de-anonymization (and user accountability), V may have to rely on I : with Cert U C, I can provide evidence that the user with certificate Cert CA U and public key SPKey U took liability for the public key SPKey C and can thus be held liable for signing Msg UV. We mentioned that V may have to rely on I. In fact, the ability to de-anonymize depends solely on possession of the appropriate certificates and messages sent between U and I and between U and V. Any party intercepting those communications is able to (provably) de-anonymize U s transaction. V may thus not need to rely on I for global de-anonymization if he can obtain Cert U C through other means. Any party, including V, may thus be able to globally de-anonymize U s transactions with Cert I C if communication channels are not confidentiality-protected. Linkability An analysis of linkabilities is straightforward. All uses of the pseudonym certificate (with the same or another verifier V ) are linkable to each other by their linkability to SPKey C :

9.1. Non-Anonymous Applications Based On Anonymous Credentials 199 Linked({V, V }, null, Sig C, Sig C ) Also, any party possessing Cert CA U and Cert U C can link Sig C to SPKey U and Cert CA U. We can express this as follows: Linked(any, possession of Cert CA U and Cert U C, Sig C, Cert CA U ) I and V together can thus certainly link any of C s anonymous signatures to his external certificate: Linked({I, V }, null, Sig C, Cert CA U ) 9.1.2 The Example Application Based on Credentials We now design an application with the same features of (un)identifiability and accountability using anonymous credentials. In short, we want to design an application where a user U authenticates to a verifier V using an anonymous credential issued by an issuer I. We require that all U s uses of this credential are linkable to each other and to the credential issuing (e.g., U s nym with I ). We also require that a provable liability by the user exists for the use of the credential. Figure 9.2 and Table 9.3 show such an application. User U now also owns UserSecret U ; I is a credential issuer and issues the anonymous credential which U uses in the transaction with credential verifier V. G is a special type of de-anonymizer (the choice of his name will become clear in the following paragraphs). I s issuing public key, V s verification public key and G s de-anonymization public key are self-certified in respective self-signed certificates. The certificate request Cert U C by U from the certificate-based application is now replaced by a signed nym registration of OrgNym UI where the user takes liabilitiy Liab U UI for the desired credential (with CredInfo UI ) to be obtained on OrgNym UI ; the certificate response then becomes a credential Cred UI issued by I on the newly registered OrgNym UI. In the transaction with V, U shows Cred UI ; this is the equivalent of Sig C in the certificate-based application. The credential show is unconditionally (locally) de-anonymizable by G. G is a Gossipy De-anonymizer : it accepts nor respects de-anonymization conditions and always replies to de-anonymization requests. Participants and Key Material: U (SSKey U, Cert CA U, UserSecret U), I (SSKey I, Cert CA I, ISKey I, Cert I I), V (SSKey V, Cert CA V, VSKey V, Cert V V ) G (SSKey G, Cert CA G, DSKey G, Cert G G) Protocol Flows: U I V Certificate Request/Response: Transaction: Nym UI, SignedNymProof UI CredUI WasShownUV Figure 9.2: Example Credential-Based Application: Participants, Key Material and Protocol Flows

200 Chapter 9. From Identity-Based to Risk-Driven Design Table 9.3: Example Credential-Based Application: Certificate and Message Contents Cert CA X S CA(CertdKeys = {SPKey = SPKey X }}, Attrs = {CertTp = CERT, Liab = Liab CA X}) Cert I I S I(CertdKeys = {IPKey = IPKey I }, Attrs = {CertTp = SELFCERT, Liab = Liab I I, Addr = Addr I, Rules = Rules I, Contr = Contr I}) Cert V V S I(CertdKeys = {VPKey = VPKey V }, Attrs = {CertTp = SELFCERT, Liab = Liab V V, Addr = Addr V, Rules = Rules V, Contr = Contr V }) Cert G G S G(CertdKeys = {DPKey = DPKey G }, Attrs = {CertTp = SELFCERT, Liab = Liab G G, Addr = Addr G, Rules = Rules G, Contr = Contr G}) Nym UI Nym(UserSecret U, OrgNym UI, UserNym UI ) SignedNymProof UI Cred UI CredInfo UI Attrs UI SignedNymProof(Sig UI, Cert CA U, OrgNym UI, {Liab U UI, CredInfo UI}) Cred(OrgNym UI, UserCred UI, CredInfo UI) {IPKey I, true, Expiration UI, Attrs UI} {Liab I UI} WasShown UV WasShown(Transcript UV, UserCred UI, CredShowInfo UV, CredShowFeatures UV, null, Msg UV ) SigProof UV SigProof(Transcript UV, CredShowInfo UV, CredShowFeatures UV, null, Msg UV ) Msg UV may be null; may also contain transaction-specific data CredShowInfo UV CredShowFeatures UV CredInfo UI (true, VPKey V, (DPKey G, null), null) This unconditional and reliable de-anonymization models the fact that any party in possession of the appropriate evidence can provably de-anonymize the transaction. In fact, it can be realized very easily by considering the de-anonymization key pair as public values in the system, just as other system parameters. In this way, a relying party (such as V ) can perform the de-anonymization himself. Of course, users in the system have to know that G is gossipy, i.e., does not respect de-anonymization conditions. This local de-anonymization provides the same unconditional and provable linkability between OrgNym UI and WasShown UV as was obtained in the certificate-based application between SPKey C and Sig C. Msg UV in the credential-based application may be null as the timeliness of authentication is ensured by the Idemix protocols; it may also contain transaction-specific data, e.g., the details of the service request. Also for this credential-based application, we now analyze the provable statements, de-anonymization features and linkabilities related to U s actions towards I and V. Evidence and Accountability Table 9.4 shows the evidence collected by I and V and what these parties can prove with this evidence: With Transcript UV, through SigProof UV, V can prove that Msg UV was signed using a credential issued by the owner of IPKey I with (from CredShowInfo UV ) credential-specific liability Liab I UI ; IPKey I is certified by the owner of SPKey I with liability Liab I I ; and SPKey I by the owner

9.1. Non-Anonymous Applications Based On Anonymous Credentials 201 Table 9.4: Example Credential-Based Application: Evidence and Provable Statements Who Evidence Proves Fact V Transcript UV Msg UV was signed using a credential issued by the owner of IPKey I and certifying Liab I UI V Transcript UV Transcript UV is related to a credential issued on OrgNym UI (through de-anonymization by G) V Cert CA I Owner of SPKey CA certified (SPKey I, Liab CA I ) V Cert I I Owner of SPKey I self-certified (IPKey I, Liab I I, Addr I, Rules I, Contr I ) I Cert CA U Owner of SPKey CA certified (SPKey U, Liab CA U ) I Sig UI Owner of SPKey U took liability Liab U UI for the use of OrgNym UI of SPKey CA with Liab CA I. With the help of G, V can also unconditionally de-anonymize the transcript and prove that the credential used for signing Msg UV was issued on OrgNym UI ; this proves that the owner of OrgNym UI signed Msg UV. With Sig UI, through SignedNymProof UI, I can prove that the owner of SPKey U, certified by the owner of SPKey CA with Liab CA U, took liability Liab U UI for the credential issued on OrgNym UI. If we consider following equivalences between protocol parameters in the credential-based and the certificate-based application: credential-based Liab I UI Liab U UI OrgNym UI certificate-based Liab I C Liab U C SPKey C we see that V and I can prove exactly the same as in the certificate-based application. De-Anonymization The choice of G (IPKey G ) as local de-anonymizer guarantees local de-anonymization; V thus has evidence of the owner of OrgNym UI having signed Msg UV. As I also has evidence that OrgNym UI belongs to the user with certificate Cert CA U, also global de-anonymization can be achieved in a similar way as in the certificate-based example. Linkability Because of the unconditional local de-anonymization measure, I and V together can again link all U s actions to Cert CA U. Also, all uses of the credential (with the same or different verifiers) can be linked by the verifiers.

202 Chapter 9. From Identity-Based to Risk-Driven Design These linkabilities can be derived by applying the derivation rules for linkability assertions from Chapter 7. From Section 7.5.10, it follows: Linked(G, null, OrgNym UI, Transcript UV ) As G is a reliable de-anonymizer without de-anonymization condition, this is equivalent to any party possessing Transcript UV being able to locally de-anonymize it, thus, certainly: (1) Linked(V, null, OrgNym UI, Transcript UV ) Thus, clearly, uses of the credential can be linked to each other by the verifiers: From Section 7.5.3, we additionally derive that Linked({V, V }, null, Transcript UV, Transcript UV ) (2) Linked(I, null, OrgNym UI, Cert CA U ) From (1) and (2), according to derivation rules in Section 7.5.1, we can derive Linked({I, V }, null, Transcript UV, Cert CA U ) This is equivalent to I and V together being able to link the transaction (Sig C ) to the user s external certificate (Cert CA U ) in the certificate-based application. Discussion The above shows that, if so desired, we can achieve exactly the same linkabilities and identifiabilities with anonymous credentials as with conventional certificates. In fact, the Gossipy De-anonymizer is only one of various ways to ensure such linkabilities and identifiabilities. We could also realize them by using unique credentials: I could have encoded OrgNym UI as an attribute in Cred UI, and V could require showing this attribute. In this case, however, there is no protocol-inherent guarantee that the value encoded as attribute is indeed the nym on which the credential was issued. Modeling unconditional de-anonymization using the Gossipy De-anonymizer provides us with a protocolenforced guarantee that the result of de-anonymization is the nym the credential is issued on. Note that the Gossipy De-anonymizer need not be realized as a real organization servicing de-anonymization requests; it suffices to generate the de-anonymization key pair and distribute it to all parties. 9.1.3 Conclusion In this section, we illustrated that we can achieve the same linkabilities and (re-)identification features in an application based on anonymous credentials as in an equivalent application based on certificates. In the certificate-based system, these linkabilities and identifiabilities are inherent in the secure use of the system s building blocks. In the credential-based system, we introduced them using the concept of the Gossipy De-anonymizer which can be realized by a public and system-wide de-anonymization key pair. Anonymous credentials can thus also be used in applications where unidentifiability is not a requirement or not even desirable; specifically, they can be used to support conventional identity- (or pseudonym-) based authentication and authorization.

9.2. Risk-Driven Design 203 9.2 Risk-Driven Design Of Secure and Privacy-Friendly Applications Based on Anonymous Credentials When developing credential-based examples in Chapters 7 and 8, we directly derived authentication and accountability requirements from a high-level description of the system. Requirements of unidentifiability were meant to ensure that these requirements were dealt with in the most privacy-friendly way. When introducing the LostFound application in Section 7.7.1, we stated that, in case of criminal misuse (an illegal advertisement posting) of the LostFound service, the real identity of the user had to be provided to authorities. This description was then phrased as an accountability requirement which motivated the heavy constructions for global de-anonymization in our application design. In our design, in Section 7.7.4, of the LostFound application, we decided that every posting transaction had to be globally de-anonymizable; we did so without analyzing the exact consequences for L in case an illegal posting could not be de-anonymized. We assumed these consequences were severe enough (liabilities high enough) in order for L to consider de-anonymization as unavoidable. In Section 7.8.3, we then set the value of L s liability (LiabAmount) for not being able to de-anonymize an illegal posting (contr breach cond L ) to be $100000; a value which indeed seems to motivate L s investment in a deanonymization infrastructure. What if we had defined the LiabAmount for contr breach cond L to be much smaller, e.g., $1? Such a small liability may not justify an investment in an expensive de-anonymization infrastructure. What if the LiabAmount were $1000? L may not be willing to risk paying this amount; but, maybe some privacy activists among its users are willing to pay this price for their message posting in order to be unconditionally unidentifiable; in that case, L could never be fined more than it received as payment. What if the consequence of not being able to identify a misbehaving user was L losing its license to operate? In that case, de-anonymization again seems mandatory... unless there is a way for L to prevent illegal messages! The above reasoning presents two issues we did not consider in the original LostFound design: The cost of a risk itself (LiabAmount) has to be weighed against the cost of the design options addressing a risk (the de-anonymization infrastructure, dissatisfied users who prefer unconditional unidentifiability... ); We have decided to address L s risk related to contr breach cond L without considering whether prevention was an option. In this section, we describe and illustrate a risk-driven approach for the design of secure and privacyfriendly applications based on anonymous credentials; this approach weighs risks against cost and unidentifiablity consequences of various design options addressing the risk. In addition, when addressing a risk, prevention of the risk is considered explicitly. This approach also applies our findings and recommendations about the design of applications for accountability and unidentifiability that were presented throughout this work. We illustrate this continuity by showing how the design principles outlined in Chapter 1 are gradually introduced and applied in the various chapters of this work, and how they are applied by the risk-driven design presented in the following. In Section 9.2.1, we thus first re-visit the principles for accountability and unidentifiability, introduced in Chapter 1, and show how they were applied in previous chapters. In Section 9.2.2, we introduce our risk-driven design approach with the design of an example application. Section 9.2.3 generalizes the approach. Section 9.2.4 discusses how this design approach facilitates application of the principles restated in Section 9.2.1.

204 Chapter 9. From Identity-Based to Risk-Driven Design 9.2.1 The Principles Revisited and Illustrated: Designing Applications with Accountability and Unidentifiability Traditional authorization is based on the question what do I need to believe in order to allow this action, or in order to continue with the execution of this transaction or protocol? If accountability of the requester is a requirement, this question is replaced by the question which claims do I need to be able to prove? The design of the ikp payment system in Chapter 2 took this question into account. In Chapter 3, we developed a language for expressing such claims, and a framework in which to define how specific pieces of evidence could make such claims provable. In Chapter 4, we used the same reasoning to analyze two concrete payment protocols w.r.t. the provability of claims by different parties at different stages of the protocol execution. This analysis showed that, when the recipient of an authenticated protocol message acquires an additional belief because of this new message, this belief may not be provable to a third party even if the message was digitally signed by the originator. The analysis thus showed that, as was done for ikp, the protocol design explicitly has to define and take into account the claims that need to be proved by each protocol participant at specific stages of the protocol execution. The resulting protocol specification must then define which pieces of evidence allow proving which claims; it also has to make sure a party indeed can prove the desired claims using the evidence it collected and without having to rely on evidence collected by other parties. Protocol design can also take into account the requirement that proving a claim to a third party should not reveal unnecessary information to that party. Items in signed messages can be revealed selectively by the use of hashes; by carefully selecting the construction of hash trees, individual elements can be revealed and proved without unnecessarily revealing other sensitive data. The selective revealing of data was illustrated in the design of ikp in Chapter 2; an example of the better construction of hashes in ikp as opposed to SET was shown in Chapter 4. In the surrounding certificate or credential infrastructure, accountability needs to be supported by appropriate liabilities taken by certifying entities as well as certificate or credential holders requesting or obtaining certificates. The acceptance of these liabilities should be an explicit part of certificate and credential issuing procedures. Without explicit liabilities of issuers for issued certificates or credentials, relying parties cannot derive appropriate guarantees from verifying signatures based on credentials or public-key certificates; without liabilities taken by certificate or credential holders, issuing parties cannot hold them accountable for any use or misuse of the certificate or credential. Chapter 5 introduced a liability-enhanced certificate infrastructure, where certificates as well as certificate requests contain liabilities of issuer, respectively requester, for the certificate issued or requested. In a signed certificate request, which can be considered as user self-certification, a user commits, towards the certification authority, to liabilities associated with the public key associated with the requested certificate; the certification authority then issues a liability certificate on this key including his own liabilities; these can be liabilities for actions with the certified key, for the correctness of the certified identity or attributes, or, in the case of pseudonymous certificates, for re-identification, under specified conditions, of the legal entity to be held accountable for actions with the certified key. In Chapters 7 and 8, as well as in the credential-based example in Section 9.1.2 of this chapter, we applied the same concepts to the keys, certificates and credentials used in an anonymous credential-based infrastructure. External certification of users, by a conventional external certification authority taking liability for a mapping with a legal entity, was a prerequisite for user accountability; external certification of organizations, again with appropriate CA liabilities, was needed to make also their operation and actions accountable, which motivated users trust in fair and correct operation of the system. We also introduced self-certification of organizations in the system, which allowed them to certify and re-certify their own various operation keys and to take liabilities for their own actions without needing the CA to certify all this individually. An issuer s liabilities for a credential are then determined by both the liability for his issuing key (as expressed in his self-signed certificate) and potential credential-specific liabilities in an individual credential. However, with credential-specific liablities as with other credential attributes, it is recommended to avoid values that are unique for the credential, as this may increase linkability and thus identifiability.

9.2. Risk-Driven Design 205 Also the concept of user self-certification (through signed certificate requests including a user s liabilities) was mapped onto an equivalent construct in the anonymous credential system. In the examples in Chapters 7 and 8, a user requesting a new credential signs the nym on which this credential is obtained using a key associated with an identity or pseudonymous certificate, or using another anonymous credential. Attribute-based authorization is a basic concept allowing the combination of anonymity and secure authorization. It allows authorizations to be granted to anonymous users, based on the secure proof of possession of certain attributes or privileges. In the pseudonymous transactions in Chapter 5, such attributebased authorization was used to grant authorization to (or to accept a payment from) a pseudonymous entity. The applications presented in Chapter 5 were based on conventional certificates. Using conventional certificates, there is no secure mechanism to selectively reveal attributes of the certificate depending on the transaction authorization requirements; also, transactions made with the same pseudonymous certificate were linkable to each other by the relying party or parties. These factors increase the chance of profiling the user and of ultimate identification of the transactions. Unlinkability can only be provided by one-time use of each pseudonymous certificate, causing a lot of overhead in the issuing of such certificates; or by the use of anonymous credentials as introduced in Chapter 6. Anonymous credentials also provide a secure mechanism for selectively revealing attributes. Provable re-identification is an important requirement of relying parties in systems combining anonymity and accountability. Provable re-identification requires that a user once enters the system using an identity certificate; this registration may then provide him with a potentially anonymous credential (or certificate) based on which he can obtain other anonymous or pseudonymous credentials or certificates, or perform anonymous transactions. The identity certificate has to be certified by a certification authority who has the appropriate procedures in place to verify that identities are correct and that certificate holders can be held accountable and liable for actions with credentials and certificates based on the identity certificate. Re-identification is achieved in a straightforward way when using conventional certificates, as the party issuing a pseudonymous certificate either knows the identity of the certificate holder or of another pseudonym closer to the real identity in the certification chain; the issuer of this other pseudonym then knows the real identity of the user, or yet another pseudonym closer to the real identity. Reidentification may thus rely on the cooperation of several pseudonym issuing parties. In order to provide accountability, of course, it does not suffice that intermediate certificate issuers know these links; they also have to be able to prove these mappings. In certificate-based systems, this is achieved using the certificate registration procedures introduced in Chapter 5, where the user provably links a pseudonym or pseudonym public key to his identity (or another pseudonym) by signing a certificate request for the pseudonym key with a key associated with his identity. When using anonymous credentials, re-identification is achieved using a de-anonymization procedure which can be applied to one transaction only, and can be performed by a trusted entity other than the credential issuer; it can also be made subject to specific conditions agreed to by the user. This provides better protection to the user against erroneous or unfair re-identification due to errors or misbehavior by certificate issuers, or to security breaches in their systems. A misbehavior which is impossible need not be detected or accounted for; thus, prevention of misbehavior by users or of misuse of credentials is another principle allowing the secure deployment of anonymity and unlinkability with reduced needs for re-identification or accountability. In the account-based payment protocol based on anonymous credentials in Chapter 8, an offline double-spending check can only be a detection measure; it does not exclude that a user uses his receipt (and gets the associated service or goods) twice; it is thus necessary for M to rely on I for re-identification if this type of misbehavior occurs. An online double-spending check causes more overhead at the time of transaction, but prevents doublespending; re-identification of the user is thus not necessary even if he tries to double-spend. Online double-spending detection thus decreases risk for the merchant, while increasing the anonymity of users; and both online and offline double-spending detection allow honest users to remain unconditionally anonymous.

206 Chapter 9. From Identity-Based to Risk-Driven Design 9.2.2 Risk-Driven Application Design: An Example In this section, we describe an example of risk-driven application design; the example is a variation of the LostFound example first introduced in Section 7.7.1. Because the approach is risk-driven, security measures such as authentication, authorization and reidentification become part of the design only if they directly address a concrete risk for a relying party. With this approach, we ensure that no unnecessary linkabilities and identifiabilities are created. The design process consists of the following steps. In a first step, we provide an initial definition of functional requirements and infrastructure assumptions. In a second step, an initial risk analysis is followed by an iterative process of design option analysis, design decisions and residual risk analysis. This process will gradually refine the protocols, credentials and certificates used in the application. The design option analysis analyzes cost, infrastructure, trust and unidentifiability features of the individual options. This allows us to identify the most privacy-friendly solution within certain boundaries. The above process considers the design for one entity (e.g., the LostFound service) at the time. This entity may use services from other entities, e.g., a root or de-anonymizing organization. When designing a new application such as LostFound, these other entities may pre-exist, in which case their functionality is well-defined. Alternatively, they have to be newly designed as well. In the latter case, design processes of organizations may interleave, as option analysis and design decisions for one organization may depend on choices in the design of another organization. We will illustrate this by interleaving the design of the LostFound application with that of the Kiosk handling the payments. By designing (and considering the risks of) each organizaton separately, we try to assure that trust and liability requirements also among organizations are made explicit. The following paragraphs now describe the risk-driven design of the LostFound application. Step 1. Functional Requirements, Infrastructure Assumptions, Unidentifiability Requirements We design a LostFound application providing essentially the same service as described in Section 7.7. We change some of the original assumptions for reasons of simplicity as well as to provide some variation. Users pay only for posting data, and retrieving data is free of charge; thus, we do not discuss data retrieval in the development of the protocols. The restriction of non-commercial use is lifted, i.e. we consider as misuse only a posting which is considered illegal by the law enforcement entity LE. When such a situation occurs, L is responsible for providing LE with (a means to obtain) the real name of the user; in addition, L has to pay a fine of amount IllegalFine. There is a Kiosk entity present in the system which can provide payment services. Users of the system require maximal unidentifiability of message postings. This implies anonymity and unlinkablity of message postings, as well as absence or strict limitation of re-identification measures. Step 2. Iteration of Risk Analysis, Option Analysis, Design Decisions In this step, we start out by performing a risk analysis for LostFound (L), the entity offering the actual service. As mentioned earlier, a similar analysis will be needed for any other organization (a root entity, a de-anonymizing organization, a kiosk) we need to design as part of the system. In the representation of the LostFound risk and options analysis in Figure 9.3, R stands for risk, O for option. Ri represents the i th first-level risk; RiOj represents design option j addressing risk i; RiOjRk represents residual risk k within design option RiOj, etc.

9.2. Risk-Driven Design 207 R1. Not being paid R1O1. L accepts external payments option discarded: infrastructure, cost R1O2. L accepts e-coins option discarded: infrastructure, cost R1O3. K accepts payment for L R1O3R1. K not paying L R1O3R1O1. L can prove issuing of a posting credential (+ Liabilities by K ) option discarded: cannot be realized R1O3R1O2. L can prove use of new posting credential (+ Liabilities by K ) option discarded: cannot be realized within subscription model Change of assumption: pay-per-subscription pay-per-posting R1O3R1O3. L can prove use of posting credential (+ Liabilities by K ) K s analysis K requires one-show posting credential with double-spending risk for L R1O3R1O3R1. Not being paid for double-spent posting credential R1O3R1O3R1O1. On-line double-spending detection R1O3R1O3R1O2. Off-line double-spending detection R2. Fine for illegal posting R2O1. No check option discarded: cost (fines) R2O2. Check by L option discarded: cost (residual risk of fines) R2O3. Check by LE R2O3O1. Performed by user R2O3O2. Performed by L R3. Suspending operation risk excluded by R2O3O2 Figure 9.3: Risk/Options Analysis for L What are the risks L is exposed to? R1. Not being paid. L could lose money and even go out of business because it is not paid correctly for advertisements (e.g., because there is no secure enforcement of payment for the service). R2. Fine for illegal posting. L could also lose money because of fines for illegal postings (IllegalFine). So far, we have not yet considered the consequences of L not being able to provide a user s real name in case of an illegal message posting. In a real-world system, the investigation of such a consequence could involve an interaction with, or a question to, LE. We assume that the answer is quite severe: if this situation occurs, L has to suspend operation: R3. Suspending operation. After this initial risk analysis, we can already make some conclusions about contents of some certificates in the system. E.g., as L s risks of paying IllegalFine and suspending operation are both related to

208 Chapter 9. From Identity-Based to Risk-Driven Design liabilities towards LE, we can already conclude that L s self-signed certificate will need to state this liability. This can be seen from the definition of Liab L L in Figure 9.4. We now describe the iterative process of design options analysis, design decisions and residual risk analysis which will gradually refine the protocols, messages and certificates used in the system. Design option analysis for Risk R1: Not being paid Obviously, L addresses this risk by not publishing an advertisement without having received a (guarantee of) payment for it; payment (guarantee) and message posting, of course, have to be securely linked. We consider the following options: R1O1. L accepts external payments. L accepts bank transfers, credit card payments etc. from users ( system-external payments); R1O2. L accepts e-coins. There is a bank issuing e-coins in the system, and L accepts these e-coins from customers; R1O3. K accepts payment for L. There is a Kiosk-like entity in the system willing and able to accept external payments and to issue posting credentials which users can then use to post advertisements. Let us now make the following infrastructure assumptions: L prefers not to (or is not capable to) deal with system-external payments; There is no bank in the system; The LostFound service is one of the services offered by a web portal, and can use the services of the payment front-end (Kiosk K ) of the web portal. Because of the absence of a bank and L s preference not to deal with system-external payments, we discard R1O1 and R1O2 and further explore R1O3, the option of delegating payment handling to K. This design decision is represented by underlining design option R1O3 in Figure 9.3. L thus expects payment not directly from users but from K. In the example in Section 7.7, K was a sub-entity or business partner of L. K was defined with the purpose of separating payment (and registration) from service access; there was no value transfer per subscription from K to L. In the current example, we now assume that L and K are different business entities. L has to take into account a remaining risk of K not paying L for every posting credential it issues: R1O3R1. K not paying L (R1O3R1). Thus, L wants to either (provably) control how many posting credentials K issues, or (provably) recognize when a new posting credential is being used by a user. The choices differ in who profits from issued but unused posting credentials: L in the former case, K in the latter. Of course, in both cases such evidence (of issuing or using a posting credential) only translates in a payment guarantee for L if accompanied by appropriate liabilities taken by K, e.g., in a self-signed certificate. The previous reasoning is captured in the options R1O3R1O1 and R1O3R1O2: R1O3R1O1. L can prove issuing of a posting credential (+ Liabilities by K ) R1O3R1O2. L can prove use of new posting credential (+ Liabilities by K )

9.2. Risk-Driven Design 209 R1O3R1O1 cannot be realized as L cannot control K s interactions with users. R1O3R1O2 requires that L can distinguish between multi-use credentials when they are shown, which conflicts with user unidentifiability and unlinkability requirements. Thus, both R1O3R1O1 and R1O3R1O2 are discarded. Getting appropriate (commitment to) payment while respecting users unidentifiability requirements can only be realized in a model where L charges K for every message posting; as K is only a payment intermediary, this naturally translates into a mode where also users pay K per posting (credential) as opposed to per subscription (credential). At this point, we can either backtrack by reconsidering previously discarded options (R1O1 or R1O2) or by changing initial assumptions by investigating the pay-per-posting model: R1O3R1O3: L can prove use of posting credential (+ Liabilities by K ) We assume the pay-per-posting model is acceptable to both L and K and thus choose this option. As the change of assumption does not influence any of the earlier considerations or decisions, there is no need for backtracking. At this point, we have to interleave our discussion with K s independent risk and options analysis. Clearly, K does not accept being charged for each use of a posting credential it issued unless it can limit the use of such a posting credential; K thus agrees to L s conditions but of course decides to issue only one-show posting credentials and to not be liable for postings with a double-spent credential. We now return to L s analysis. L s remaining risk is R1O3R1O3R1. Not being paid for double-spent posting credential L now addresses the risk of loss due to double-spending with on- or off-line double-spending detection: R1O3R1O3R1O1. On-line double-spending detection R1O3R1O3R1O2. Off-line double-spending detection An on-line double-spending check (R1O3R1O2R1O1) is an expensive solution, but the risk for L is reduced to null. (Strictly speaking, the remaining risk for L is K not paying L even if L has evidence of K s liability to pay; this is covered by the same liabilities as already assumed in R1O3R1O2.) An off-line double-spending check (R1O3R1O2R1O2), however, may suffice, as can be argued as follows. If a user double-spends a payment receipt credential, he loses unidentifiability for the resulting message posting, as K would be able to link the nym revealed from double-spending detection to a record of a non-anonymous payment. In addition, as soon as double-spending is detected, L can immediately cancel the publication of the user s message (actually, of both messages paid for with the credential). Thus, a user can lose more than he can gain by double-spending a posting credential. Because of the possibility to withdraw the posting(s) of a double-spending user, L decides to go for the latter option. Then, for every posting credential correctly verified by L, K needs to either pay L or prove it was double-spent. So far, we derived a partial solution to the design of L, taking into account the risk R1 of L not being paid. Of the three ways to address this risk, two were discarded because of infrastructure or cost reasons. Within the remaining option, the subscription model had to be discarded as, within that model, users unidentifiability requirements could not be fulfilled together with L s security requirements; the latter were inspired by assumptions of (lack of) trust by L in K. K s risk and options analysis then allowed K to accept being charged for one-show posting credentials without being liable for their doublespending. Having accepted to go with a pay-per-posting model, we investigated the remaining risk (double-spending) and the various ways of addressing it. Between on-line and off-line double-spending detection, the former is more expensive but excludes remaining risk. We chose, however, to implement the latter because it is less expensive while L has good reasons for accepting the residual risk.

210 Chapter 9. From Identity-Based to Risk-Driven Design We now apply a similar analysis to the remaining initial risk factors. R2 and R3 share a causal event, illegal message posting; R3 s materialization depends in addition on a second event, L s inability to provide the user s name. In order to avoid unnecessary backtracking, we want to start with the risk analysis (R2 or R3) which results in the strongest measure against (or: stronger measures preventing) illegal message posting. If providing the user s name were deemed impossible, R3, being the more severe risk, would lead us to implement stronger measures against illegal message posting; if providing the user s name were trivial or could be realized with no cost to L, R2 would provide us with the stronger measures. In the absence of these assumptions, we start with the analysis of R2. Design option analysis for Risk R2: Fine for illegal posting L can address this risk in various ways: R2O1. No check. L can choose not to address this risk; any message is publicized without screening. This option is discarded because it is deemed too exensive (IllegalFine). R2O2. Check by L. L can prevent illegal messages by screening and approving every message before it is posted. This is expensive and can prevent most illegal postings; however, L has no guarantee that a posting which it considers legal is not considered illegal by LE ; also this residual risk is deemed too high to accept. R2O3. Check by LE. Illegal message posting can be excluded if every message, before being published, is approved by LE himself. This is a very expensive solution but completely excludes L s risk if LE s approval is provable (e.g., by a signature); also, given that excluding illegal messages also excludes any re-identification requirements in the system and thus is attractive to users, LE may consider to charge the extra cost for this solution to the users. R2O3O1. Performed by user. L can require that users only post messages which are approved (with a signature) by LE; R2O3O2. Performed by L. L himself can contact LE for every message posted and charges the extra cost to the user in the form of a higher price per posting. We now assume that users are willing to accept the burden of contacting LE before posting a message to L, as this guarantees them unconditional unidentifiability of the message posting. (Of course, users require the exchange with LE to be unidentifiable as well!) By choosing R2O3O1, we have completely excluded risk R2 as well as R3. Design option analysis for Risk R3: Suspending operation The risk of suspending operation has thus been excluded by excluding illegal message postings. The Resulting LostFound Application Figure 9.4 illustrates L s design; external certificates are not shown and comply with the format in Table 7.2. Liab L L and ContrBreachCond L are determined by legal requirements as illustrated with our initial requirements discussion. CriminalMisuseCond is a condition likely to be defined by LE. The other protocol and certificate options and values are determined as follows. When choosing option R1O3R1O3, we decided that K had to pay PricePerAd to L for every provable credential show of the appropriate credential issued by K for which K cannot prove double-spending. It follows that a liability Liab K K exists stating this obligation or liability by K. It also follows that, for every posted credential, L requires a provable transcript related to that message posting. We have assumed that the linking between credential showing and message posting is done by including PostedMessage as a signed message in WasShown ULK ; as the linking is not related to accountability by a user for the message,

9.2. Risk-Driven Design 211 Certificates, Liabilities, Parameters Liab L L ContrBreachCond L {{Lt, Suspension, ContrBreachCond L, Arbiter}, {Lt, IllegalFine, CriminalMisuseCond, Arbiter},... } CriminalMisuseCond AND Not providing means to identify the user Liab K K {{Lt, PricePerAd, non-doublespent-credentialshow,... },... } WasShown ULK WasShown(Transcript ULK, any, CredShowInfo ULK, CredShowFeatures ULK, null, PostedMessage) CredShowInfo ULK CredShowFeatures ULK PostedMessage ContrBreachCond L (IPKey K, false, Expiration ULK, any) (any, VPKey L, any, any) S LE(Advertisement) (redefined) CriminalMisuseCond AND Not providing means to identify the user AND Not being able to prove approval by LE Showing Credential To LostFound and Posting Data: U : UShowCred() Comm UL : WasShown ULK L : OVerifyCred() Key Material: U (User): {SSKey U, Cert CA U }, UserSecret U K (Kiosk): {SSKey K, Cert CA K}, {ISKey K, CSKey K, Cert K K} L (LostFound): {SSKey L, Cert CA L}, {VSKey L, CSKey L, Cert L L} Figure 9.4: LostFound Application Design linking the showing spending of the credential to the message by using the same authenticated and integrity-protected communication channel Comm UL would be acceptable as well. Requirements on the credential and the credential show are expressed in the CredShowInfo ULK and CredShowFeatures ULK parameters. Clearly, the credential is issued by K (IPKey K ). As K may require L to verify the expiration of the credential, we included Expiration ULK in CredShowInfo ULK. We also specified that the credential is one-show (MultiShow=false); whether or not this is actually verified by L (and therefore relevant in L s protocol definition) depends however on the details of Liab K K. The values of the fields in CredShowFeatures ULK are straightforward: the presence of VPKey L specifies a verification by L. The solutions chosen for addressing risk R2 (and R3) now further refine the protocol. As L decides (R2O3O1) to only accept messages that have been approved by LE, we define PostedMessage accordingly as an advertisement signed (approved) by LE. Also, L can negotiate a redefinition of CriminalMisuseCond to specify an absence of liability in the case of a message approved by LE. Necessary key material can easily be derived from the protocols chosen. Note that, for the purpose of the protocol executions with L, the user does not need an external certificate. The risk-driven design of other applications in the system are likely to require the user to possess and use such a certificate. E.g., the user may use such a certificate and associated secret key when performing the payment to Kiosk.

212 Chapter 9. From Identity-Based to Risk-Driven Design 9.2.3 Risk-Driven Application Design: General Method Description In this section, we now describe the approach for a risk-driven design more generally. Step 1. Functional Requirements, Infrastructure Assumptions, Unidentifiability Requirements In this first step, we describe the application to be designed at a high level. The description tries to capture the core functionality (e.g., the service provided: advertisement publishing), user identifiability wishes or requirements (maximal unidentifiability) as well as access conditions (the service is paid), deanonymization requirements (the name of a user posting an illegal message needs to be revealed) and infrastructure assumptions (presence of the Kiosk) already known at this point. The level of detail we achieve in this step is not strictly defined: design experience with the credential system, experience designing similar applications using the same credential system, or the knowledge of the existing infrastructure may allow us to go in more detail. E.g., as we already know that a Kiosk entity may play a role in providing payment services, we made an assumption about its presence; alternatively, the question about the presence of a Kiosk entity would come up only during the option analysis step. Step 2. Iteration of Risk Analysis, Option Analysis, Design Decisions In this step, we start out by performing a risk analysis for the entity we are designing. Other organizations involved in providing the service (root entities, de-anonymizing organizations, organizations providing other services) perform their own risk and design option analysis. An organization can be exposed to two types of risk: An internal risk is a risk which does not involve liabilities towards other parties. Examples are loss of revenue or data because of incorrect configuration of access control or other badly defined security parameters. L not being paid for the service it provides is an internal risk. An external risk is related to a liability towards a third party. L s risk to have to pay IllegalFine is an external risk; also the risk of having to suspend operation is external. An external risk or liability is typically captured in the organization s external or self-certified certificate, as we showed with Liab L L in our LostFound application design. A risk can be dealt with by a choice between, or a combination of, different countermeasures; each choice of countermeasure(s) typically corresponds to a different design option. Thus, the risk analysis is likely to produce a number of design options. The options analysis then investigates related cost issues, infrastructure requirements, trust assumptions, unidentifiability features and residual risk factors. These different features are then taken into account when choosing one of the design options. Depending on the option chosen, a risk can be addressed in different ways: A risk can be accepted: L accepts the risk of revenue loss because of double-spending by users. A risk can be transformed (delegated) into a liability for another entity: L transforms R1 into a payment liability by K towards L. A risk can be prevented or excluded: a loss of revenue by accepting a posting credential which is being double-spent can be prevented by an on-line double-spending check. Note that, what seems as prevention, may also often be a transformation: with or without on-line double-spending detection, the initial risk of not being paid (by the user) is only transformed into the risk of not being paid by K ; the protocol constructs chosen merely ensure that L can hold K liable in case K refuses to pay L (as expressed with Liab K K ).

9.2. Risk-Driven Design 213 The risk/options analysis is an iterative process as a residual risk leads to a new analysis of design options. Ultimately, the detailed design options will define the details of the protocols and certificates in the system. In the LostFound example, we did not apply backtracking through design options; in fact, the change of assumptions about subscription-based payment allowed us to avoid backtracking through previously discarded design options and thereby to preserve the simplicity of the example. In general, however, the design process tries to optimize a complex function of cost, infrastructure, risk and unidentifiability. A systematic risk/options analysis is therefore likely to involve backtracking; discarding options should be done only if it is certain that they do not lead to an optimized solution. The risk-based design approach presented provides a better conceptual framework than the more ad-hoc design approach of the examples in Chapters 7 and 8. However, the development of a real methodology needs a formalization of the risks, of the options addressing those risks and of the measures for evaluating them: First of all, risks have to be stated in terms of the occurrence of verifiable events. An event can be the existence or absence of a verifiable item (e.g., a signature, a certificate, a payment, the granting of a service). E.g., risk R1 can be stated as the occurrence a service granting without an associated payment. Provability of events plays an important role in the definition of external risks. E.g., risk R2 can be stated as the existence of evidence that ContrBreachCond L holds. According to our analyis, this implies that the existence, on L s web site, of an illegal message posting can be proved. When a risk is stated in terms of verifiable events, options addressing a risk can be stated in terms of minimizing or excluding the occurrence of these events. E.g., L s addressing R2 (and R3) consists of preventing anyone to be able to prove ContrBreachCond L to hold. In addition, the analysis of the various design options has to be done based on measurable criteria. For the unidentifiability criteria, we can use the linkability assertions developed for anonymous credentials. For the other criteria, one may have to develop application-specific evaluation functions. E.g., cost considerations for the various design options in our LostFound example are applicationspecific. 9.2.4 Risk-Driven Application Design And Design Principles for Accountability and Unidentifiability The risk-driven design approach illustrated in the previous paragraphs is ideally suited for designing privacy-friendly applications using anonymous credentials. It ensures that security measures and especially those resulting in linkabilities or potential re-identification are introduced only when necessary in order to address concrete risks by a relying party. Thereby, it facilitates the application of the design principles for accountability and unidentifiability outlined in Section 9.2.1. Attribute-based authorization and unlinkablity come as a default in a design based on the use of anonymous credentials. Identifiability (e.g., through unique credentials), linkability (e.g., by showing a credential relative to a nym) or re-identifiability (through de-anonymization) are nondefault ways in which to use anonymous credentials and are introduced only when needed to address a specific risk by a relying party. Central in our methodology is the assumption that any external risk must be related to a provable liability for a legal entity; and that also the materialization of the liability condition must be provable: L transforms its internal risk of not being paid into K s risk of not being paid; it thus becomes an external risk for K. In order for this transformation to be considered successful, L wants to

214 Chapter 9. From Identity-Based to Risk-Driven Design be able to prove, for every message posted, that K owes L the appropriate amount of money. In addition, L requires that this liability is self-certified by K ; and that, in turn, K s solvency to self-certify such a liability is certified by another trusted entity (CA). L s external risks of paying fines or suspending operation are related to the fact that the publishing of an illegal message on its website is considered to be provable (assuming that CriminalMisuseCond can be verified by one or a set of arbiters) and that L took liability for it. L excludes this risk by making it impossible to prove the materialization of the liability condition. In our design, this is done by changing ContrBreachCond L. This assumption thus ensures appropriate design of protocols and the application of liabilityenhanced certification and self-certification. The fact that each organization performs its own risk analysis ensures that no implicit trust assumptions between organizations are made. Note that, when an internal risk is addressed without a transformation into a liability for another party, there is never an external risk involved; provability may thus not play a role. E.g., if L addresses its risk of not being paid by only posting credentials after having received real value (e.g., cash payment, or a finalized money transfer), no external risk for any party is involved. In this case, provability does not play a role. The concept of stating potential misbehavior in terms of risk incurred to an organization allows us to investigate options preventing or minimizing the likelihood of such misbehavior. In the LostFound example, prevention of misbehavior in the form of LE screening and approving advertisements was a design option because of L s external risk (IllegalFine) related to such misbehavior. Prevention of misbehavior, in our design, allowed us to avoid re-identification measures. In cases where an organization is subject to an internal risk related to users misbehavior, a similar analysis would be made weighing the benefits and cost related to punishment (re-identification) against prevention. If LE had not been able or willing to provide the advertisement approval service, L s risk related to CriminalMisuseCond could not have been excluded. Even if L screens the advertisements himself, he can only minimize but not exclude the chance of misbehavior. In this case, provable reidentification of message postings under strict de-anonymizing conditions (verifiable misuse) would have been L s only way of addressing its risk of suspending operation while maximally preserving unidentifiability of well-behaving users. In that case, user s self-certification in the form of a liability taken when posting a credential would have to allow L to perform such re-identification. The above illustrates the application of the design principles for accountability and unidentifiability. Of course, the level of unidentifiability achieved depends on the final (combination of) design option(s) chosen. The detailed analysis of each of the design options allows us to either choose the most privacypreserving solution; or, when another solution is chosen, to at least recognize a trade-off between privacy and other features such as cost. 9.3 Conclusion In this chapter, we addressed two practical issues that may come up when starting to deploy an anonymous credential systems. The first issue can be seen as a compatibility issue with existing identity-based systems. We showed that, using an anonymous credential system, we can achieve exactly the same accountability and linkability features as using a certificate-based system. The second issue was to propose an attractive and comprehensive design methodology for designing privacy-enhanced and secure applications based on anonymous credentials. We presented a risk-based design approach and illustrated its suitability for applying the principles for accountability and unidentifiability. Both issues were addressed only by example and provide potential for future work.

9.3. Conclusion 215 Proving compatibility of anonymous credential systems with certificate-based systems would require an in-depth comparison and mapping of linkability and accountability features of building blocks (and combinations thereof) in both systems. The risk-based design approach presented provides a better conceptual framework than the examples in Chapters 7 and 8. However, the development of a real methodology needs a formalization of the risks, of the options addressing those risks and of the measures for evaluating them.

216 Chapter 9. From Identity-Based to Risk-Driven Design

Chapter 10 Related Research As already pointed out in the introduction, many other anonymous credential systems were proposed (e.g., [39, 36, 40, 49, 86]). Other recent work by Stubblebine et al. [107] describes a system for allowing secure authentication of attributes with fine-grained control of anonymity and linkability applied specifically to client-merchant interactions and the control of clients over their profiles. Each of these systems have their own specific functionality and building blocks. It should be possible to describe them with security and linkability features as we did for the credential system used in this paper. Trust management systems address the authorization problem in the context of distributed systems. A trust management system consists of a specification language in which authorization and access control policies are defined, as well as algorithms to determine whether a specific request can be authorized. Weeks [123] presents a survey of trust management systems together with a framework for understanding them. Well-known general-purpose trust management systems such as Keynote [20, 19], SPKI [54] and Delegation Logic [82] are based on the notion of delegation. The process of making authorization decisions involves finding a delegation chain from an authority source to a requester. Recent work on certificate (or credential 1 ) chain discovery and collection by Li et al. [83] addresses the problem of finding such a chain in an environment where credentials are distributed. To the extent that trust management systems define access control conditions and policies in terms of properties, attributes and delegated rights, they are related to the concept of attribute-based authorization as we illustrated with the use of anonymous credentials. They still bind authorizations to a subject (principal or public key) in a public-key certificate; whereas our anonymous credentials do not contain such a subject, and our access control conditions (rules) were stated in terms of issuing key, attributes and accountability options. It would be interesting to investigate whether and with which modifications existing trust management systems can be adapted to express such rules in an anonymous credential system. Various approaches to increasing privacy in trust management systems have been described. Aura and Ellison [12] provide a comprehensive overview of privacy issues related to certificate-based trust management systems and discusses techniques to increase privacy; it also discusses how to ensure individual accountability despite anonymity. The first recommendation for enhancing privacy is replacing identity-based certificates and access control with key-oriented access control. Key-oriented access control is access control based on a certificate where the subject is a public key as opposed to a name or identity; such a certificate is the equivalent of our pseudonym certificates where the public key is the pseudonym. The authors identify various remaining privacy problems and risks. They consider the risk of an individual s actions being traceable to his identity, even when based on key-oriented access control; this risk is related to the inherent linkability of certificates and their use. The risk of revealing more information than needed is related to the fact 1 credential, in the context of trust management systems, will be used as a general term for an element (policy item, name or delegation certificate) in such a delegation chain. 217

218 Chapter 10. Related Research that certificates may contain more information (e.g., attributes, rights) than needed for a specific type of service access; also, depending on how certificates are used, the information accumulated in the certificate chain certifying a key certificate may reveal a lot of information about the owner of the key certificate or about the organization of which the user is a member. A further technique discussed is certificate reduction; using this technique, a certificate chain can be reduced to one certificate. This is achieved by the root certifier of the chain issuing a new, reduced, certificate. When used only to shorten a chain, this technique primarily reduces the amount of organizational information leaked by a certificate chain. The technique can also be used by a user to limit the set of privileges or attributes in the final key certificate. Further techniques are temporary and task-specific keys, limiting both the number of uses of the same key certificate as the amount of information (attributes, rights) conveyed in one key certificate. In order to achieve accountability, the authors recommend an escrow agent issuing escrow certificates; such an escrow certificate ensures that the owner of a key has correctly submitted his key for escrow; i.e., the escrow agent knows and can prove the key owner s identity under well-specified conditions listed in the escrow certificate. The authors also discuss the need for being able to hold a key holder (even when identified by the escrow agent) liable for actions with the key. The above work illustrates the certificate-inherent privacy limitiations we outlined in our work; in all the privacy techniques, the issuer of a certificate or reduced certificate has to be trusted with a lot of information; collaborations between issuers and verifiers still enable full traceability of actions. Another approach to increasing privacy in trust management systems is for the entity requesting a service or showing credentials to selectively and gradually release credentials based on trust established in the other party. Yu et al. [124] describe strategies in automated trust negotiation. In their model, credentials and services are subject to access control and disclosure policies. Trust negotiation strategies of interacting parties then allow for an incremental establishment of trust by exchanging credentials and credential requests in an iterative trust negotiation process. They define a set of interoperable strategies, i.e., if two parties each choose a strategy in this set then they are able to negotiate trust. They illustrate the use of some practical strategies within the TrustBuilder architecture and protocol for trust negotiation. More recent work by the same authors [103] specifically focuses on limiting disclosure of the access control policies themselves. Yu and Winslett [125] present a unified scheme, UniPro, modelling protection of resourses, including policies, in trust negotiation. Policies are modeled as other resources, providing fine-grained control over policy disclosure. A clear distinction is made between policy disclosure and policy satisfaction, which gives users more flexibility in expressing their authorization requirements. Recently, several approaches for measuring and modelling anonymity and unlinkability have been proposed. Diaz et al. [50] describe an information theoretic model that allows quantification of the degree of anonymity of anonymous connection schemes in the presence of various types of attacks. The degree of anonymity is based on the probability for an attacker to assign a user as the originator of a message. In their model, the degree of anonymity does not depend on the size of the anonymity set, in order to make statements about the anonymity of a system independently of the number of users using it. Steinbrecher et al. [106] formalise the notion of unlinkability. The degree of unlinkability is based on the probability of items in a set being related, e.g., being sent by the same user. They also refine definitions of anonymity in terms of unlinkability. In our work, we have considered an item (or action) to be anonymous if no linkability exists between this item and an individual s identity. In our model, we focus on non-probabilistic linkabilities resulting from an unambiguous association of values to the same user. We assume that anonymity sets are large and that underlying anonymous communication channels provide flat probability distributions. Nissenbaum [92] discusses the issue of accountability in a computerized society and factors creating barriers to accountability. The authors argue that accountability in a computerized world is becoming eroded because of a combination of several factors: the fact that many hands work together to produce software, the acceptance that bugs are inevitable, the use of computers as scape-goats and the fact that software producers do not take liability for their software. While most of the discussion is about accountability by software and computer system providers for functioning of computerized systems, the use of the computer as a scape-goat also applies to actions by

219 individuals using computerized systems; blaming the computer is all the more attractive if computerized systems are faulty and no accountability is taken for its functioning. The type of individual accountability we mostly discussed in our work cannot be realized when using faulty computer systems for which the owners or producers did not take accountability. While accountability does not guarantee correct functioning, the authors argue that holding people accountable for the harms or risks they bring about provides strong motivation for trying to prevent or minimize them. Accountability can therefore be a powerful tool for motivating better practices. In various parts of this work, we argued in a similar way in favor of accountability and verifiability of trusted parties such as financial institutions (Section 1.5) and de-anonymization organizatons (Section 7.8). Trust and (the need for) accountability do not contradict each other: founded trust in correct functioning of a system or its entities can be realized or enhanced by giving parties providing critical services the correct incentives to act correctly and, consequently, eliminating the need for blind trust.

220 Chapter 10. Related Research

Chapter 11 Conclusions 11.1 Summary of Contributions In this work, I made the following contributions: I contributed to the detailed protocol specification, design and implementation of ZiP, a prototype implementation of the ikp family of account-based payment protocols invented by researchers in IBM Zurich and Watson. The ZiP protocols added functionality to the original ikp protocols and their development was guided by the same principles of accountability as were applied in the development of the original ikp protocols. I contributed to the development of a framework for handling accountability claims in payment systems. The framework consists of a claim language and semantics for general payment systems, and an architecture for claim handling. Its application to the ikp payment system is illustrated by specifying a mapping between provable claims and evidence tokens in ikp. I compared the SET and ikp protocols w.r.t. their accountability features based on the provability of the basic statements of the same accountability claim language. For both payment systems, I discovered some incompleteness in provability of these basic statements, from which I formulated some general recommendations for protocol design for accountability. I designed pseudonymized versions of a generic account-based payment system with the help of a pseudonym server converting non-pseudonymous payment certificates and payments into pseudonymous ones. I showed that, for all the parties involved, the same security could be achieved as in a non-pseudonymous payment by the introduction of a liability-enhanced certification infrastructure. In such an infrastructure, certificate issuers and certificate holders commit to explicit liabilities for certificates. For transactions where conditional (e.g., on misuse) re-identification of a user may be required, such an issuer liability may be the provable re-identification of the user upon fulfillment of the condition. I designed and contributed to the implementation of the Idemix anonymous credential system prototype based on the protocols presented in Camenisch et al. [31]. These protocols allow anonymous and unlinkable attribute authentication with conditional provable third-party re-identification. The design included the representation of the many complex interactive protocols by a small set of highlevel, easy-to-understand primitives. I described a simple rules language for expressing attributebased authorization conditions and designed and implemented an access control extension to the prototype allowing easy configuration and enforcement of organizations access control policies based on such rules. 221

222 Chapter 11. Conclusions I formulated a set of basic Idemix building blocks, each representing a successful execution of an interactive protocol, which can be used to describe an Idemix application. I analyzed authentication, accountability and linkability properties of these building blocks, and showed how to use these properties for designing Idemix-based applications starting from their authentication, accountability and unidentifiability requirements. I described the parameters influencing trust requirements of users in unidentifiability and of relying parties in accountability and liability. I also described a certification framework for the various Idemix keys providing accountability and defining liability of all the parties (users, issuing, verifying and de-anonymizing organizations) in the system. I compared different approaches for anonymizing an account-based payment system: using conventional (pseudonym) certificates and using anonymous credentials. I showed that, with anonymous credentials, the same security and accountability could be achieved with less need for linkability of a user s actions. I also showed the potential of anonymous credentials for achieving unidentifiability of a user s payment transactions also towards his bank by using pre-paid credentials (e-coins). I showed that an anonymous credential system can be used securely in applications where identity- (or pseudonym-) based authorization is required; I described a set of principles for designing systems with accountability and unidentifiability. I recommended the use of anonymous credentials for satisfying security and accountability goals while minimizing linkability and maximizing unidentifiability. I described a risk-based design approach for optimally applying those principles in an application design and illustrated this approach with an application based on anonymous credentials. 11.2 Summary of Conclusions In this work, I investigated the (in)compatibility between accountability and unidentifiability in electronic transactions. The goal was to explore the potential for and limits of unidentifiability of users in systems with high requirements on security and accountability. In the above contributions, I have investigated technological (certificates vs. anonymous credentials) as well as design components of systems with accountability and unidentifiability. From those contributions, I can draw the following conclusions: Accountability and liability require targeted protocol design and registration procedures. When designing application protocols, the design should include a specification of a mapping of accountability claims to the evidence needed to prove these claims; Certificate users should specify appropriate liabilities for actions based on a certificate when requesting the certificate; certificate issuers should specify liabilities in the certificates they issue. Secure authorization need not be identity-based. Attribute-based authorization, if based on certificates or credentials with appropriate issuer and owner liabilities, can give the same assurance to a relying or authorizing party while enabling the user requesting authorization to remain anonymous. It is possible to introduce accountability in anonymous transactions through provable re-identification. Depending on the application and the technology used, a re-identification condition may be weak (interpretation subject to judgement) or strong (re-identification only possible under certain conditions of misuse). Depending on the technology used, the re-identifying entity may be a regular certificate issuer or a dedicated trusted party. Both the strength of the re-identification condition and the choice of re-identifying entity have consequences for users incentive for trusting correctness of such re-identification functionality.

11.2. Summary of Conclusions 223 Re-identification of a transaction based on a certificate can be realized by a (pseudonymous) certificate issuer being able to prove a relation between a real identity and a pseudonymous certificate; the (weak) condition(s) for re-identification may be specified (and signed by the certificate holder) as part of the certificate request procedure or as part of the transaction; Re-identification of a transaction may be realized by a trusted party other than the issuer of the certificate or credential on which the transaction is based. E.g., a de-anonymization organization in our anonymous credential system is the only entity able to de-anonymize (re-identify) a transaction; also here, de-anonymization conditions are weak; Built-in mechanisms such as double-spending detection of anonymous credentials allow for a strong re-identification condition. More authorization checks and on-line verification may obviate the need for accountability and re-identification. Anonymous credential systems offer substantial advantages over conventional certificate systems for realizing unidentifiability and accountability. In a system based on certificates, it is impossible to avoid linkability between certificate issuing and certificate use. In a system based on anonymous credentials, complete unlinkability between certificate issuing and certificate use can be achieved. Anonymous credential systems can be used securely for applications where identity-based authentication and authorization are needed. The design of applications based on an analysis of risks rather than on ad-hoc security requirements allows to identify design options with maximal unidentifiability and to make tradeoffs between different design goals related to costs and unidentifiability explicit. The introduction of more explicit liabilities in public-key infrastructures so far does not seem to happen. While I believe that concrete liability specifications can increase the level of security and assurance for relying parties in existing infrastructures, the incentive for such transformation may be hard to find. In the same way as discussed in Section 1.5 for systems without accountability or good security, we can say that today s systems work in the sense that relying parties are aware of (or are expected to be aware of) the lack of assurance and guarantees given by public-key certificates. As the use of those certificates for e-commerce transactions is likely to increase, identity theft by obtaining a certificate in someone else s name may become more attractive. One could hope that this kind of identity theft will be more difficult than the more classical paper- and card-based identity theft, and that individuals will not be held liable for the use of certificates falsely obtained on their name. The use of privacy-enhancing technologies and systems, whether based on pseudonym certificates or credentials, will make the question about issuer liability more important. With the (hopefully) increased use of such technologies and systems, one can expect that a minimum of information about an issuer s liability for data, transactions or re-identification will be expressed in certificates or associated practice statements. Computational overhead related to the use of Idemix credentials is not negligible. However, recent unpublished optimization results based on pre-computation indicate that it is possible to use Idemix credentials in a way transparent to the user: the user does not notice a delay related to showing the credentials. A more important factor possibly impeding the deployment of anonymous credential systems is the absence of efficient and easily accessible infrastructures providing user anonymity at the communication level. Without these infrastructures, the advantages of anonymous credential systems cannot be fully exploited. However, even in the absence of anonymous communication, anonymous credentials offer privacy advantages compared to today s identity-based systems. Whereas in today s systems linkability of application-level transaction data comes legitimately and for free with identity-based authentication, anonymous credentials require a verifier to actively trace communication when trying to achieve that linkability. One can thus expect that the use of anonymous credentials will reduce linking and identification of users data even in the absence of anonymous communication.

224 Chapter 11. Conclusions Today, Idemix-like credentials are used in the Direct Anonymous Attestation (DAA) feature of the Trusted Platform Module TPM v1.2 Specification [114, 29]. An anonymous credential issued by a DAAissuer compare with the Privacy-CA in Section 1.4.2 allows a TPM-enabled platform to securely attest to parameters of its operational environment without creating any linkability to the credential issuing. It will be interesting to follow the implementation and exploitation of this specification as well as the use of anonymous credentials in other important infrastructures and applications. 11.3 Avenues for Future Work There are several possibilities for extending the research presented in this work. A first avenue for further research is a generalization of our authentication, accountability and linkability concepts to a broader set of certificate- and credential-based systems. Our Idemix-based assertions about authentication, accountability and linkability were specific to the anonymous credential system used. In order to allow a common reasoning about other anonymous credential systems as well as certificate-based systems (or systems using both certificates as credentials), a system-independent language is needed for expressing authentication, accountability and linkability features of certificate- as well as anonymous credential-based systems. Primitive assertions in the various systems (certificates, certificate requests, credential show transcripts... ) then have to be mapped to this system-independent authentication, accountability and linkability language. It also should be investigated how such a language for authentication, accountability and linkability can be used for allowing automatic inferencing about the authentication, accountability and linkability features of an application. A further challenging topic is the formalization of our risk-based application design. A risk can be formally expressed in terms of a (provable) fact and a liability or other consequence; and also costs associated with addressing risks can be expressed more formally than we have presented in our examples. Ideally, a formal definition of risks, combined with an exact quantification of the cost function for addressing risks may lead to an automated or semi-automated derivation of authorization requirements.

Bibliography [1] J. L. Abad-Peiro, N. Asokan, M. Steiner, and M. Waidner. Designing a generic payment service. IBM Systems Journal, 37(1):72 88, Jan. 1998. [2] R. Anderson. Why cryptosystems fail. Communications of the ACM, 37(11):32 40, Nov. 1994. [3] The Anonymizer. http://www.anonymizer.com. [4] N. Asokan. Fairness in Electronic Commerce. PhD thesis, University of Waterloo, May 1998. [5] N. Asokan, P. Janson, M. Steiner, and M. Waidner. The state of the art in electronic payment systems. IEEE Computer, 30(9):28 35, Sept. 1997. [6] N. Asokan, M. Schunter, and M. Waidner. Optimistic protocols for fair exchange. In Proc. 1997 ACM Conference on Computer and Communications Security, pages 7 17. ACM Press, 1997. [7] N. Asokan, V. Shoup, and M. Waidner. Asynchronous protocols for optimistic fair exchange. In Proc. 1998 IEEE Symposium on Research in Security and Privacy, pages 86 99. IEEE Computer Society Press, 1998. [8] N. Asokan, E. Van Herreweghen, and M. Steiner. Towards a framework for handling disputes in payment systems. In Proc. 1998 USENIX Workshop on Electronic Commerce, pages 187 202. USENIX Association, 1998. [9] N. Asokan, E. Van Herreweghen, and M. Steiner. Towards a framework for handling disputes in payment systems. Research Report RZ 2996, IBM Research Division, Mar. 1998. [10] G. Ateniese, D. Song, and G. Tsudik. Quasi-efficient revocation in group signatures. In M. Blaze, editor, Proc. 2002 International Conference on Financial Cryptography, volume 2357 of Lecture Notes in Computer Science, pages 183 197. Springer-Verlag, 2002. [11] G. Ateniese and G. Tsudik. Some open issues and new directions in group signatures. In M. Franklin, editor, Proc. 1999 International Conference on Financial Cryptography, volume 1648 of Lecture Notes in Computer Science, pages 196 211. Springer-Verlag, 1999. [12] T. Aura and C. Ellison. Privacy and accountability in certificate systems. Research Report HUT- TCS-A61, Helsinki University of Technology Laboratory for Theoretical Computer Science, 2000. [13] B. Balacheff, L. Chen, S. Pearson, and G. Proudler. Trusted Computing Platforms: TCPA Technology in Context. Prentice Hall International, 2003. ISBN 0130092207. [14] M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentication. In N. Koblitz, editor, Advances in Cryptology CRYPTO 96, volume 1109 of Lecture Notes in Computer Science, pages 1 15. Springer-Verlag, 1996. [15] M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik, E. Van Herreweghen, and M. Waidner. Design, implementation and deployment of a secure account-based electronic payment system. Research Report RZ 3137, IBM Research Division, June 1999. 225

226 Bibliography [16] M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik, E. Van Herreweghen, and M. Waidner. Design, implementation and deployment of the ikp secure electronic payment system. IEEE Journal on Selected Areas in Communications (JSAC), 18(4):611 627, 2000. [17] M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik, and M. Waidner. ikp A family of secure electronic payment protocols. In Proc. 1995 USENIX Workshop on Electronic Commerce, pages 89 106. USENIX Association, July 1995. [18] M. Bellare and P. Rogaway. Optimal asymmetric encryption how to encrypt with RSA. In A. De Santis, editor, Advances in Cryptology EUROCRYPT 94, volume 950 of Lecture Notes in Computer Science, pages 92 111. Springer-Verlag, 1994. [19] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis. The KeyNote trust-management system version 2. Internet Engineering Taskforce (IETF) Request for Comments 2704, Sept. 1999. [20] M. Blaze, J. Feigenbaum, and A. D. Keromytis. Keynote: Trust management for public-key infrastructures (position paper). In B. Christianson, B. Crispo, W. Harbison, and M. Roe, editors, Proc. 1998 Security Protocols Workshop, volume 1550 of Lecture Notes in Computer Science, pages 59 63. Springer-Verlag, 1998. [21] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. In Proc. 1996 IEEE Symposium on Research in Security and Privacy, pages 164 173. IEEE Computer Society Press, 1996. [22] D. Bleichenbacher. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances in Cryptology CRYPTO 98, volume 1462 of Lecture Notes in Computer Science, pages 1 12. Springer-Verlag, 1998. [23] D. Bolignano. Towards the formal verification of electronic commerce protocols. In Proc. 1997 IEEE Computer Security Foundations Workshop, pages 133 146. IEEE Computer Society Press, 1997. [24] J.-P. Boly, A. Bosselaers, R. Cramer, R. Michelsen, S. Mjølsnes, F. Muller, T. Pedersen, B. Pfitzmann, P. de Rooij, B. Schoenmakers, M. Schunter, L. Vallée, and M. Waidner. The ESPRIT project CAFE high security digital payment systems. In D. Gollmann, editor, Proc. 1994 European Symposium on Research in Computer Security (ESORICS), volume 875 of Lecture Notes in Computer Science, pages 217 230. Springer-Verlag, 1994. [25] M. Bove. Key management, setup and implementation of an anonymous credential system. Master s thesis, Politecnico di Torino, Turin, Italy, June 2001. [26] S. Brackin. Automatic formal analyses of two large commercial protocols. In H. Orman and C. Meadows, editors, DIMACS Workshop on Design and Formal Verification of Security Protocols, Rutgers New Jersey, September 1997. [27] S. Brands. Untraceable off-line electronic cash in wallets with observers. In D. Stinson, editor, Advances in Cryptology CRYPTO 93, volume 773 of Lecture Notes in Computer Science, pages 302 318. Springer-Verlag, 1994. [28] S. Brands. Rethinking Public Key Infrastructures and Digital Certificates. MIT Press, Aug. 2000. ISBN 0262024918. [29] E. Brickell, J. Camenisch, and L. Chen. Direct anonymous attestation. In Proc. 2004 ACM Conference on Computer and Communications Security. ACM Press, 2004. To appear. [30] J. Camenisch. Idemix protocol specification. Unpublished. Partially included in Kohlweiss [80].

Bibliography 227 [31] J. Camenisch and A. Lysyanskaya. Efficient non-transferable anonymous multi-show credential system with optional anonymity revocation. In B. Pfitzmann, editor, Advances in Cryptology EUROCRYPT 01, volume 2045 of Lecture Notes in Computer Science, pages 93 118. Springer- Verlag, 2001. [32] J. Camenisch and A. Lysyanskaya. Dynamic accumulators and application to efficient revocation of anonymous credentials. In M. Yung, editor, Advances in Cryptology CRYPTO 02, volume 2442 of Lecture Notes in Computer Science, pages 61 67. Springer-Verlag, 2002. [33] J. Camenisch and E. Van Herreweghen. Design and implementation of the Idemix anonymous credential system. In Proc. 2002 ACM Conference on Computer and Communications Security, pages 21 30. ACM Press, 2002. [34] Center for Democracy and Technology. Fact sheet: Administration implements updated encryption export policy, Jan. 2000. Available from http://www.cdt.org/crypto. [35] D. Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM, 24(2):84 88, 1981. [36] D. Chaum and J.-H. Evertse. A secure and privacy-protecting protocol for transmitting personal information between organizations. In M. Odlyzko, editor, Advances in Cryptology CRYPTO 86, volume 263 of Lecture Notes in Computer Science, pages 118 167. Springer-Verlag, 1987. [37] D. Chaum, A. Fiat, and M. Naor. Untraceable electronic cash. In S. Goldwasser, editor, Advances in Cryptology CRYPTO 88, volume 403 of Lecture Notes in Computer Science, pages 319 327. Springer-Verlag, 1990. [38] D. Chaum and H. van Antwerpen. Undeniable signatures. In G. Brassard, editor, Advances in Cryptology CRYPTO 89, volume 435 of Lecture Notes in Computer Science, pages 212 217. Springer-Verlag, 1989. [39] D. L. Chaum. Security without identification: transaction systems to make big brother obsolete. Communications of the ACM, 28(10):1030 1044, 1985. [40] L. Chen. Access with pseudonyms. In E. Dawson and J. D. Golic, editors, Proc. Cryptography: Policy and Algorithms, volume 1029 of Lecture Notes in Computer Science, pages 232 243. Springer Verlag, 1995. [41] P.-C. Cheng, J. Garay, A. Herzberg, and H. Krawczyk. A security architecture for the internet protocol. IBM Systems Journal, Special issue on the Internet, 37(1):42 60, 1998. [42] W. R. Cheswick and S. M. Bellovin. Firewalls and Internet Security Repelling the Wily Hacker. Professional Computing Series. Addison-Wesley, 1994. ISBN 0201633574. [43] E.-S. Chung and D. Dardailler. Joint electronic payment initiative (JEPI). White paper, World Wide Web Consortium, May 1997. [44] Council of Europe. Convention for the protection of human rights and fundamental freedoms, Nov. 1950. Available from http://www.echr.coe.int/convention/webconveneng.pdf. [45] B. Cox, J. D. Tygar, and M. Sirbu. NetBill security and transaction protocol. In Proc. 1995 USENIX Workshop on Electronic Commerce, pages 77 88. USENIX Association, July 1995. [46] R. Cramer and V. Shoup. A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack. In H. Krawczyk, editor, Advances in Cryptology CRYPTO 98, volume 1462 of Lecture Notes in Computer Science, pages 13 25. Springer-Verlag, 1998. [47] L. Cranor, B. Dobbs, G. Hogben, J. Humphrey, M. Langheinrich, M. Marchiori, M. Presler- Marshall, J. Reagle, M. Schunter, D. A. Stampley, and R. Wenning. The platform for privacy preferences 1.1 (P3P1.1) specification. Working draft, World Wide Web Consortium, Apr. 2004.

228 Bibliography [48] L. Cranor, M. Langheinrich, M. Marchiori, M. Presler-Marshall, and J. Reagle. The platform for privacy preferences 1.0 (P3P1.0) specification. Recommendation, World Wide Web Consortium, Apr. 2002. [49] I. B. Damgård. Payment systems and credential mechanism with provable security against abuse by individuals. In S. Goldwasser, editor, Advances in Cryptology CRYPTO 88, volume 403 of Lecture Notes in Computer Science, pages 328 335. Springer-Verlag, 1990. [50] C. Diaz, S. Seys, J. Claessens, and B. Preneel. Towards measuring anonymity. In R. Dingledine and P. Syverson, editors, Proc. 2002 Workshop on Privacy Enhancing Technologies, volume 2482 of Lecture Notes in Computer Science, pages 54 68. Springer-Verlag, 2002. [51] T. Dierks and C. Allen. The TLS protocol version 1.0. Internet Engineering Taskforce (IETF) Request for Comments 2246, Jan. 1999. [52] H. Dobbertin. The status of MD5 after a recent attack. Cryptobytes, 2(2):1 6, Summer 1996. [53] C. Dwork, J. Lotspiech, and M. Naor. Digital signets: Self-enforcing protection of digital information. In Proc. 1996 ACM Symposium on Theory of Computing (STOC), pages 489 498, 1996. [54] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. SPKI certificate theory. Internet Engineering Taskforce (IETF) Request for Comments 2693, Sept. 1999. [55] E. A. Emerson. Temporal and modal logic. In Formal Models and Semantics, volume B of Handbook of Theoretical Computer Science, chapter 16, pages 995 1072. Elsevier Science Publishers B.V., 1990. [56] European Telecommunications Standards Institute (ETSI). Electronic signatures and infrastructures working group: Current status and deliverables, 2004. Available from http://portal.etsi. org/esi/. [57] A. Fiat and A. Shamir. How to prove yourself: Practical solution to identification and signature problems. In A. Odlyzko, editor, Advances in Cryptology CRYPTO 86, volume 263 of Lecture Notes in Computer Science, pages 186 194. Springer-Verlag, 1987. [58] A. O. Freier, P. Karlton, and P. C. Kocher. The SSL protocol version 3.0. Internet Engineering Task Force (IETF) Internet Draft, Nov. 1996. [59] S. Garfinkel. Database Nation: The Death of Privacy in the 21st Century. O Reilly & Associates, Inc., 2000. ISBN 1565926536. [60] S. Glassman, M. Manasse, M. Abadi, P. Gauthier, and P. Sobalvarro. The Millicent protocol for inexpensive electronic commerce. In Proc. Fourth International Conference on the World-Wide Web, pages 603 619. O Reilly, Dec. 1995. [61] GlobalSign. GlobalSign Consumer Policy, 1999. Available from http://www.globalsign.net/ repository/. [62] GlobalSign. GlobalSign Relying Parties Agreement Version 4.0, Oct. 2001. Available from http: //www.globalsign.net/repository/. [63] GlobalSign. GlobalSign Certificate Policy Version 1.1, Feb. 2004. Available from http://www. globalsign.net/repository/. [64] GlobalSign. GlobalSign Certification Practice Statement Version 4.3.1, Feb. 2004. Available from http://www.globalsign.net/repository/. [65] O. Goldreich, B. Pfitzmann, and R. Rivest. Self-delegation with controlled propagation or what if you lose your laptop. In H. Krawczyk, editor, Advances in Cryptology CRYPTO 98, volume 1462 of Lecture Notes in Computer Science, pages 153 168. Springer-Verlag, 1998.

Bibliography 229 [66] D. M. Goldschlag, M. G. Reed, and P. F. Syverson. Onion routing for anonymous and private internet connections. Communications of the ACM, 42(2):84 88, 1999. [67] C. Gulcu and G. Tsudik. Mixing e-mail with BABEL. In Proc. 1996 Symposium on Network and Distributed System Security, pages 2 16, San Diego, CA, Feb. 1996. Internet Society. [68] R. Hauser and M. Steiner. Generic extensions of WWW browsers. In Proc. 1995 USENIX Workshop on Electronic Commerce, pages 147 154. USENIX Association, July 1995. [69] R. Hauser, M. Steiner, and M. Waidner. Micro-payments based on ikp. Research Report RZ 2791, IBM Research Division, Feb. 1996. [70] IBM Corporation. Secure Electronic Transactions: Credit card payment on the web in theory and practice. IBM Redbook. Available from http://www.redbooks.ibm.com/abstracts/sg244978. html. [71] Institute for Prospective Technological Studies. epayment systems database - trends & analysis. Electronic Payment Systems Observatory (epso) Background Paper No. 9, Mar. 2002. Available from http://epso.jrc.es/. [72] Institute for Prospective Technological Studies. Integration of electronic payment systems into B2C internet-commerce. Electronic Payment Systems Observatory (epso) Background Paper No. 8, Apr. 2002. Available from http://epso.jrc.es/. [73] International Telecommunication Union. ITU-T recommendation X.509 - the directory: Authentication framework, Nov. 1993. [74] International Telecommunication Union. ITU-T recommendation X.509 - the directory: Public-key and attribute certificate frameworks, Mar. 2000. [75] R. Kailar. Reasoning about accountability in protocols for electronic commerce. In Proc. 1995 IEEE Symposium on Research in Security and Privacy, pages 236 250. IEEE Computer Society Press, 1995. [76] G. Karjoth, M. Schunter, E. Van Herreweghen, and M. Waidner. Amending P3P for clearer privacy promises. In Proc. International Workshop on Database and Expert Systems and Applications (DEXA), pages 445 449, Prague, Sept. 2003. IEEE Computer Society Press. [77] M. E. Katsch. Dispute resolution in cyberspace. In Symposium: Legal Regulation of the Internet, volume 28 of Connecticut Law Review, 1996. [78] V. Kessler and H. Neumann. A sound logic for analysing electronic commerce protocols. In J.-J. Quisquater, Y. Deswarte, C. Meadows, and D. Gollmann, editors, Proc. 1998 European Symposium on Research in Computer Security (ESORICS), volume 1485 of Lecture Notes in Computer Science, pages 345 360. Springer-Verlag, 1998. [79] KeyMan. http://www.alphaworks.ibm.com/tech/keyman. [80] M. Kohlweiss. Towards digital credentials. Master s thesis, Universität Klagenfurt, Fakultät für Wirtschaftwissenschaften und Informatik, Klagenfurt, Austria, Feb. 2003. [81] H. Krawczyk. Blinding of credit card numbers in the SET protocol. In M. Franklin, editor, Proc. 1999 International Conference on Financial Cryptography, volume 1648 of Lecture Notes in Computer Science, pages 17 28. Springer-Verlag, 1999. [82] N. Li, B. Grosof, and J. Feigenbaum. A practically implementable and tractable delegation logic. In Proc. 2000 IEEE Symposium on Research in Security and Privacy, pages 27 42. IEEE Computer Society Press, 2000.

230 Bibliography [83] N. Li, W. H. Winsborough, and J. C. Mitchell. Distributed credential chain discovery in trust management: extended abstract. In Proc. 2001 ACM Conference on Computer and Communications Security, pages 156 165. ACM Press, 2001. [84] P. F. Linington. Fundamentals of the layer service definitions and protocol specifications. Proceedings of the IEEE, 71(12):1341 1345, Dec. 1983. [85] A. Lysyanskaya, R. Rivest, and A. Sahai. Pseudonym systems. Master s thesis, MIT Laboratory for Computer Science, 1999. [86] A. Lysyanskaya, R. Rivest, A. Sahai, and S. Wolf. Pseudonym systems. In H. Heys and C. Adams, editors, Selected Areas in Cryptography, volume 1758 of Lecture Notes in Computer Science, pages 184 199. Springer-Verlag, 1999. [87] A. Malpani, R. Housley, and T. Freeman. The simple certificate validation protocol. Internet Engineering Task Force (IETF) Internet Draft, July 2004. [88] J. Manger. A chosen ciphertext attack on RSA optimal asymmetric encryption padding (OAEP) as standardized in PKCS # 1 v2.0. In J. Kilian, editor, Advances in Cryptology CRYPTO 01, volume 2139 of Lecture Notes in Computer Science, pages 230 238. Springer-Verlag, 2001. [89] R. Mathys. New Idemix client Handbuch. Technical report, Berner Fachhochschule - HTA Biel, Swizerland, December 2001. [90] C. Meadows and P. Syverson. A formal specification of requirements for payment transactions in the SET protocol. In R. Hirschfeld, editor, Proc. 1998 International Conference on Financial Cryptography, volume 1465 of Lecture Notes in Computer Science, pages 122 140. Springer-Verlag, 1998. [91] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone. Handbook of Applied Cryptography. Series on Discrete Mathematics and its Applications. CRC Press, 1996. ISBN 0849385237. [92] H. Nissenbaum. Accountability in a computerized society. Science and Engineering Ethics, 2:25 42, 1996. [93] NIST National Institute of Standards and Technology (Computer Systems Laboratory). Secure hash standard. Federal Information Processing Standards Publication FIPS PUB 180-1, Apr. 1995. [94] Nutrimentia. The need for anonymity. http://www.gusalmighty.com/phpbb2/viewtopic.php? t=545, Mar. 2004. [95] A. M. Odlyzko. Privacy, economics, and price discrimination on the internet. In N. Sadeh, editor, Proc. 2003 International Conference on Electronic Commerce (ICEC 2003), pages 355 366. ACM Press, 2003. [96] D. O Mahony, M. Peirce, and H. Tewari. Electronic Payment Systems for E-Commerce. Computer Security Series. Artech House Publishers, 2nd edition, 2001. ISBN 1580532683. [97] A. Pfitzmann, B. Pfitzmann, and M. Waidner. ISDNMixes: untraceable communication with very small bandwidth overhead. In Proc. Communication in Distributed Systems, number 267 in Informatik-Fachberichte, pages 451 463. Springer-Verlag, 1991. [98] B. Pfitzmann and M. Waidner. Properties of payment systems - general definition sketch and classification. Research Report RZ 2823, IBM Research Division, May 1996. [99] C. Rackoff and D. R. Simon. Noninteractive zero-knowledge proof of knowledge and chosen ciphertext attack. In J. Feigenbaum, editor, Advances in Cryptology CRYPTO 91, volume 576 of Lecture Notes in Computer Science, pages 433 444. Springer-Verlag, 1991.

Bibliography 231 [100] M. K. Reiter and A. D. Rubin. Crowds: anonymity for Web transactions. ACM Transactions on Information and System Security, 1(1):66 92, 1998. [101] R. L. Rivest. The MD5 message-digest algorithm. Internet Engineering Taskforce (IETF) Request for Comments 1321, Apr. 1992. [102] R. L. Rivest, A. Shamir, and L. M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120 126, Feb. 1978. [103] K. Seamons, M. Winslett, and T.Yu. Limiting the disclosure of access control policies during automated trust negotiation. In Proc. 2001 Symposium on Network and Distributed System Security, pages 109 124, San Diego, CA, Apr. 2001. Internet Society. [104] SET Secure Electronic transaction LLC. SET Secure Electronic Transactions Technical Specifications, version 1.0 edition, May 1997. Book One: Business Description, Book Two: Programmer s Guide, Book Three: Formal Protocol Definition. Until early 2004 available from http://www.setco.org/set specifications.html. See also [70]. [105] V. Shoup. OAEP reconsidered (extended abstract). In J. Kilian, editor, Advances in Cryptology CRYPTO 01, volume 2139 of Lecture Notes in Computer Science, pages 239 259. Springer-Verlag, 2001. [106] S. Steinbrecher and S. Köpsell. Modelling unlinkability. In R. Dingledine, editor, Proc. 2003 Workshop on Privacy Enhancing Technologies, volume 2760 of Lecture Notes in Computer Science, pages 32 47. Springer-Verlag, 2003. [107] S. G. Stubblebine and P. F. Syverson. Authentic attributes with fine-grained anonymity protection. In Y. Frankel, editor, Proc. 2000 International Conference on Financial Cryptography, volume 1962 of Lecture Notes in Computer Science, pages 276 294. Springer-Verlag, 2001. [108] Sun Microsystems. The java wallet (TM) architecture white paper, March 1998. Available from http://java.sun.com/products/commerce/docs/. [109] The European Parliament and the Council of the European Union. Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data. Official Journal of the European Communities, (L281):31 50, Oct. 1995. [110] The European Parliament and the Council of the European Union. Directive 1999/93/EC on a community framework for electronic signatures. Official Journal of the European Communities, (L013):12 20, Jan. 2000. [111] The European Parliament and the Council of the European Union. Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector. Official Journal of the European Communities, (L201):37 47, July 2002. [112] The Privacy Rights Clearinghouse. Fact Sheet No. 17: Reducing the risk of identity theft, Feb. 2003. Available from http://www.privacyrights.org. [113] Trusted Computing Group. Trusted Computing Platform Alliance (TCPA) Main Specification v1.1b, Feb. 2002. Available from http://www.trustedcomputinggroup.org. [114] Trusted Computing Group. Trusted Platform Module Main Specification v1.2 Part 1: Design Principles, Oct. 2003. Available from http://www.trustedcomputinggroup.org. [115] G. Tsudik. Zurich ikp prototype: Protocol specification document. Research Report RZ 2792, IBM Research Division, Feb. 1996. [116] United States Department of Commerce. Export administration regulations, category 5 (part 2) - information security. Available from http://www.commerce.gov, May 2004.

232 Bibliography [117] E. Van Herreweghen. Using digital signatures as evidence of authorizations in electronic credit-card payments. Research Report RZ 3156, IBM Research Division, June 1999. [118] E. Van Herreweghen. Secure anonymous signature-based transactions. In F. Cuppens, Y. Deswarte, D. Gollmann, and M. Waidner, editors, Proc. 2000 European Symposium on Research in Computer Security (ESORICS), volume 1895 of Lecture Notes in Computer Science, pages 55 71. Springer- Verlag, 2000. [119] E. Van Herreweghen. Non-repudiation in SET: Open issues. In Y. Frankel, editor, Proc. 2000 International Conference on Financial Cryptography, volume 1962 of Lecture Notes in Computer Science, pages 140 156, 2001. [120] P. van Oorschot and M. Wiener. Parallel collision search with cryptanalytic applications. Journal of Cryptology, 12(1):1 28, 1999. [121] M. Waidner. Development of a secure electronic marketplace for Europe. In E. Bertino, H. Kurth, G. Martella, and E. Montolivo, editors, Proc. 1996 European Symposium on Research in Computer Security (ESORICS), volume 1146 of Lecture Notes in Computer Science, pages 1 14. Springer- Verlag, 1996. [122] Wbi development kit. Available from http://www.almaden.ibm.com/cs/wbi/. [123] S. Weeks. Understanding trust management systems. In Proc. 2001 IEEE Symposium on Security and Privacy, pages 94 105. IEEE Computer Society Press, 2001. [124] T. Yu, X. Ma, and M. Winslett. PRUNES: an efficient and complete strategy for automated trust negotiation over the internet. In Proc. 2000 ACM conference on Computer and Communications Security, pages 210 219. ACM Press, 2000. [125] T. Yu and M. Winslett. A unified scheme for resource protection in automated trust negotiation. In Proc. 2003 IEEE Symposium on Security and Privacy, pages 110 122. IEEE Computer Society Press, 2003.

List of Publications B. De Decker, E. Van Herreweghen, and F. Piessens. Heterogeneous intra-domain authentication. In Proc. UNIX Security III Symposium, pages 285 298. USENIX Association, 1992. R. Molva, G. Tsudik, E. Van Herreweghen, and S. Zatti. KryptoKnight authentication and key distribution system. In Proc. 1992 European Symposium on Research in Computer Security (ES- ORICS), volume 648 of Lecture Notes in Computer Science, pages 155 174. Springer-Verlag, 1992. G. Tsudik and E. Van Herreweghen. Some remarks on protecting weak secrets and poorly-chosen keys from guessing attacks. In Proc. 1993 IEEE Symposium on Reliable Distributed Systems, pages 136 142. IEEE Computer Society Press, 1993. G. Tsudik and E. Van Herreweghen. On simple and secure key distribution. In 1993 ACM Conference on Computer and Communications Security, pages 49 57. ACM Press, 1993. R. Hauser, P. Janson, R. Molva, G. Tsudik, and E. Van Herreweghen. Robust and secure password/key change method. In D. Gollmann, editor, Proc. 1996 European Symposium on Research in Computer Security (ESORICS), volume 875 of Lecture Notes in Computer Science, pages 107 122. Springer-Verlag, 1994. R. Hauser, P. Janson, G. Tsudik, E. Van Herreweghen, and R. Molva. Robust and secure password and key change method. Journal of Computer Security, 4(1):97 111, Sept. 1996. N. Asokan, E. Van Herreweghen, and M. Steiner. Towards a framework for handling disputes in payment systems. In Proc. 1998 USENIX Workshop on Electronic Commerce, pages 187 202, 1998. E. Van Herreweghen and U. Wille. Risks and potentials of using EMV for internet payments. In Proc. 1999 USENIX Workshop on Smartcard Technology (SMARTCARD 99), pages 163 174. USENIX Association, 1999. E. Van Herreweghen and U. Wille. Using EMV for internet payments. In Proc. 2000 European Conference on Information Systems, pages 901 908, Vienna, Austria, July 2000. M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik, E. Van Herreweghen, and M. Waidner. Design, implementation and deployment of the ikp secure electronic payment system. IEEE Journal on Selected Areas in Communications (JSAC), 18(4):611 627, 2000. E. Van Herreweghen. Secure anonymous signature-based transactions. In F. Cuppens, Y. Deswarte, D. Gollmann, and M. Waidner, editors, Proc. 2000 European Symposium on Research in Computer Security (ESORICS), volume 1895 of Lecture Notes in Computer Science, pages 55 71. Springer- Verlag, 2000. E. Van Herreweghen. Non-repudiation in SET: Open issues. In Y. Frankel, editor, Proc. 2000 International Conference on Financial Cryptography, volume 1962 of Lecture Notes in Computer Science, pages 140 156, 2001. 233

234 List of Publications E. Bangerter, J. Camenisch, E. Van Herreweghen, and M. Waidner. Idemix for internet anonymity. In Information Security, number 49 in ERCIM News, page 13. European Research Consortium for Informatics and Mathematics, Apr. 2002. Available from http://www.ercim.org/publication/ Ercim News/enw49/. S. Clauss, A. Pfitzmann, M. Hansen, and E. Van Herreweghen. Privacy-enhancing identity management. In L. Beslay, J.-C. Burgelman, and I. Maghiros, editors, Identity and Privacy, volume 67 of IPTS Report. Institute for Prospective Technological Studies, Sept. 2002. Available from http://www.jrc.es/home/report/report main.html. J. Camenisch and E. Van Herreweghen. Design and implementation of the Idemix anonymous credential system. In Proc. 2002 ACM Conference on Computer and Communications Security, pages 21 30. ACM Press, 2002. G. Karjoth, M. Schunter, and E. Van Herreweghen. Translating privacy practices into privacy promises how to promise what you can keep. In Proc. 2003 IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 03), pages 135 146. IEEE Computer Society Press, 2003. G. Karjoth, M. Schunter, E. Van Herreweghen, and M. Waidner. Amending P3P for clearer privacy promises. In Proc. International Workshop on Database and Expert Systems and Applications (DEXA), pages 445 449, Prague, Sept. 2003. IEEE Computer Society Press. E. Van Herreweghen. A risk-driven approach to designing privacy-enhanced secure applications. In Proc. 2004 IFIP International Information Security Conference (SEC 2004) Embedded Workshop Privacy and Anonymity in Networked and Distributed Systems (I-NetSec 04). Kluwer Academic Publishers, Aug. 2004. To Appear.

Biography Els Van Herreweghen was born on November 11, 1966 in Anderlecht, Belgium. She received Master s degrees in Bio-Engineering (Ir. Scheikunde en Landbouwwetenschappen, 1988) and in Computer Science (Lic. Informatica, aanvullende graad, 2002) from the Katholieke Universiteit Leuven (K.U.Leuven) in Belgium. From 2000 to 2002, she was a research assistant in the DistriNet research group of the K.U.Leuven Computer Science Department. Since 2002, she has been a research staff member at the IBM Research Laboratory in Rüschlikon, Switzerland, working in the field of network and transaction security, identity management and privacy. 235