UNIDENTIFIABILITY AND ACCOUNTABILITY IN ELECTRONIC TRANSACTIONS

Transcription

1 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

2

3 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 *I21 Oktober 2004

4 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

5 Acknowledgements This work has been performed at the IBM Zurich Research Laboratory in cooperation with the Katholieke Universiteit Leuven. I thank my employer, IBM Research, for giving me the opportunity to conduct the research reported on in this work and specifically Michael Waidner, Douglas Dykeman and Matthias Schunter for allowing me to complete part of the final writing on IBM time. I am very grateful to Bart De Decker for having accepted to supervise this PhD thesis and for his continuous support, feedback and help. His positive and constructive feedback to my initial PhD plans and proposal contributed to my confidence in this project and helped me take the necessary steps to realize it. I also want to thank him for many fruitful discussions and for his thorough reading of and constructive comments on earlier versions of this work. He also helped me with many practical issues which were difficult for me to deal with remotely. Thank you! I am grateful to Professors Bart Preneel, Frank Piessens, Pierre Verbaeten, Refik Molva and Kai 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 s 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

6 ii

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

8 iv

9 Contents 1 Introduction Introduction Terminology Identity-Based vs. Attribute-Based Authentication and Authorization Certificates and Credentials Belief, Provability, Accountability and Liability Pseudonymity, Anonymity, Linkability and (Un-)Identifiability Accountability in Public-Key Based Systems Protocol Design: Authentication vs. Accountability Overall System Design for Accountability Liabilities and Guarantees Authentication and Accountability in Anonymous Transactions Attribute-Based Authorization Avoiding Linkability of Transactions Re-Identification Prevention vs. Detection of Fraud and Misuse Anonymous Credentials Incentives and Disincentives for Accountability and Unidentifiability Accountability Privacy and Unidentifiability Goal and Scope of This Work Notation A Secure Account-Based Electronic Payment System 17 Preamble Introduction and Overview History and Related Work Payment Model Security Requirements The ikp Protocol Family KP v

10 vi Contents KP KP Comparison of the Protocols ZiP: Implementation and Deployment Protocol scenarios Implementation Rationales and Explanations Architecture Deployment Postscript Accountability and Dispute Handling in Payment Systems 45 Preamble Introduction Importance of Dispute Handling in Electronic Commerce Handling Disputes Expressing Dispute Claims What to Dispute? Value Transfers as Primitive Transactions Statements of Dispute Claims Supporting Claims with Evidence Architecture for Dispute Handling Evidence and Trust An Example: Evidence Tokens in ikp Summary and Conclusion Postscript Analysis of Accountability Features in SET and ikp 67 Preamble Introduction High-Level Payment Protocol Description Proving Authorizations of Primitive Transactions SET SET Protocol Overview Evidence of Authorizations Discussion Recommendations ikp ikp Protocol Overview Evidence of Authorizations Discussion

11 Contents vii 4.6 Summary Postscript Secure Anonymous Signature-Based Transactions 85 Preamble Introduction Pseudonymizing a Generic Payment System The Generic Payment Protocol Requirements for a Secure Pseudonymized Version Design for Maximum Security: PS On-line, CERT P Linked to Transaction Alternative Design: Off-Line PS Discussion Generalized Signatures and Liabilities Liability-Aware Certificates A Generic Pseudonym Server CERT REQ, CERT RES The Liabilities in CERT P Example: Auction Related and Future Work Conclusion PostScript An Anonymous Credential System 103 Preamble Introduction Idemix Protocols, Pseudonyms and Credentials Basic Credential Protocols Credential Options and Attributes Parameters of the Show Protocol Credential System Primitives Pseudonyms Credentials CredShowFeatures Protocol Primitives The Idemix Prototype OrgNymSystem and UserNymSystem Token-Based Interfaces UserSyncNymSystem and OrgSyncNymSystem Synchronous Interfaces DeAnOrgNymSystem Communication Persistent Data Storage

12 viii Contents Building Applications: Granting and Processing Requests An Example Scenario: An Anonymous Subscription to the New York Times Creating and Configuring the User and Organizations User Credential Manager and Browser Plug-In Deployment Considerations Idemix as a Generic Attribute-Based Authentication System The Role of Authenticated Communication in Linking Transactions Based on Idemix Authentication Deploying Idemix as a Privacy-Enhanced Public-Key Infrastructure with External Certification Infrastructural Issues: User Registration and Organization Updates Conclusions and Future Work Postscript Designing Applications Using Idemix Anonymous Credentials Introduction Primitives and Parameters of the Anonymous Credential System Basic primitives Signed Nym Registration Root Nym Registration Assertions on Nyms, Credentials and Transcripts Resulting from Interactive Protocols Nym Registration Signed Nym Registration Root Nym Registration Credential Issuing Showing a Credential Not Relative to a Nym Showing a Credential Relative to a Nym Local Operations on Transcripts Local De-Anonymization Global De-Anonymization Double-Spending Detection Assertions on Linkability Anonymity, Linkability and Identifiability Nym Registration Signed Nym Registration Root Nym Registration Issuing of a Non-Unique Credential Issuing of a Unique Credential Unconditionally Unidentifable Showing of a Credential Showing a Credential with Unique Parameters

13 Contents ix Showing a Credential Relative to a Nym Showing a Credential with De-Anonymizaton Showing a One-Show Credential Additional Procedures and Functionality More On Global De-Anonymization Revocation Certification Designing an Application Introducing the LostFound Application Key Material, External Certificates and Idemix Certificates Security of the Communication Channels Protocols for Registration and Service Access Verifying Organizations Accountability Requirements Verifying User Unidentifiability Requirements Trust, Accountability, Liability and Certification Trust by Users and Organizations in De-Anonymization Trust by Organizations in the System Certificates, Liabilities and Contracts A Scenario Illustrating Trust in Accountability and Unidentifiability Conclusion Certificate- and Credential-Based Anonymous Payments Introduction Payment Protocols Based on Certificates Non-Pseudonymous Account-Based Payment Protocol Based on Certificates Pseudonymous Account-Based Payment Protocol Based on Certificates Payment Systems Based on Anonymous Credentials Account-Based Payment Protocol Based on Anonymous Credentials Pre-Paid Payment Protocol Based on Anonymous Credentials Analysis of Accountability and Unidentifiability of the Various Payment Protocols Non-Pseudonymous Account-Based Payment Protocol Based on Certificates Pseudonymous Account-Based Payment Protocol Based on Certificates Account-Based Payment Protocol Based on Anonymous Credentials Pre-Paid Payment Protocol Based on Anonymous Credentials Additional Remarks on the Use of Certificates vs. Anonymous Credentials Risks Related to a Breakdown of the Credential System or Compromise of Secrets Conclusion From Identity-Based to Risk-Driven Design Non-Anonymous Applications Based On Anonymous Credentials

14 x Contents An Example Application Based on Certificates The Example Application Based on Credentials Conclusion Risk-Driven Design The Principles Revisited Risk-Driven Application Design: An Example Risk-Driven Application Design: General Method Description Risk-Driven Application Design And Design Principles for Accountability and Unidentifiability Conclusion Related Research Conclusions Summary of Contributions Summary of Conclusions Avenues for Future Work Bibliography 225 List of Publications 233 Biography 235 A Summary in Dutch i

15 List of Figures 2.1 Generic Model of a Payment System Keys and Cryptograhic Primitives Used in ikp Protocols Definitions of Atomic Fields Used in ikp Protocols Framework of ikp Protocols KP Protocol KP Protocol KP Protocol The Payment Clearance/Capture Scenario The Status Inquiry Scenario ZiP Implementation Architecture An Example Payment Transaction Value Transfer Transactions Semantics of Dispute Statements Basic Dispute Protocol Simplified ikp Protocol Global States in ikp Generic Credit Card Payment Protocol Value Transfer Transactions SET Payment with On-Line Authorization KP Payment with On-Line Authorization Generic Payment Protocol Pseudonymized Payment Protocol: On-Line PS, One-Time Pseudonym Certificate Pseudonymized Payment Protocol: Off-line PS Generic Pseudonym Server Basic Credential System Protocols De-Anonymization User, Org, and DeAnOrg Components User, Org and DeAnOrg Token-Based and Synchronous Interfaces xi

16 xii List of Figures 6.5 An Organization Application UserCredential Manager Anonymous Credential System: Overview of Basic Primitives Anonymous Credential System: Key Material and Parametrized Primitives Anonymous Credential System: Parameter Types and Contents Anonymous Credential System: Signed Nym Registration Anonymous Credential System: Root Nym Registration Global De-Anonymization Using Local De-Anonymization: V and I Cooperating Global De-Anonymization Using Local De-Anonymization: V Verifying Linking of Nyms Example Application: Key Material and Registration Example Application: Accessing LostFound Example Application: Local and Global De-Anonymization A Scenario Illustrating Trust in Accountability and Unidentifiability Non-Pseudonymous Account-Based Payment Protocol Based on Certificates Pseudonymous Account-Based Payment Protocol Based on Certificates Account-Based Payment Protocol Based on Anonymous Credentials Pre-Paid Payment Protocol Based on Anonymous Credentials Example Certificate-Based Application: Participants, Key Material and Protocol Flows Example Credential-Based Application: Participants, Key Material and Protocol Flows Risk/Options Analysis for L LostFound Application Design

17 List of Tables 2.1 Comparison of the ikp Payment Protocols Protocol Flags Used in ZiP Attributes and Operators of Primitive Transactions Grammar for the Payment Dispute Claim Language Information of Players in a Completed ikp Transaction Mapping Evidence to Dispute Statements in ikp SET Atomic and Composite Fields ikp Atomic and Composite Fields Generic Certificate Format Example Application: Parameters of Assertions and Primitives Certificate Contents for the LostFound Example Non-Pseudonymous Account-Based Payment Protocol Based on Certificates Pseudonymous Account-Based Payment Protocol Based on Certificates Account-Based Payment Protocol Based on Anonymous Credentials Pre-Paid Payment Protocol Based on Anonymous Credentials Example Certificate-Based Applicaton: Certificate and Message Contents Example Certificate-Based Application: Evidence and Provable Statements Example Credential-Based Application: Certificate and Message Contents Example Credential-Based Application: Evidence and Provable Statements xiii

18 xiv List of Tables

19 Chapter 1 Introduction 1.1 Introduction A public-key infrastructure (PKI) can offer a secure and scalable solution for authentication and secure communication in electronic transactions. Using public-key certificates issued by a trustworthy 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, 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

20 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 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