CAFE project Final report volume II: Secure Protocols and Architecture

Cent r um voor Wi sk unde en I nf or ma ti ca

MAS Modelling, Analysis andSimulation

Modelling, Analysis and Simulation CAFE project _ Final report volume II Secure protocols and architecture Edited by A. Bosselaers, R. Carter, R. Hirschfeld, R. Michelsen, S. Mjølsnes REPORT MAS-E0303 FEBRUARY 28, 2003

CWI is the National Research Institute for Mathematics and Computer Science. It is sponsored by the Netherlands Organization for Scientific Research (NWO). CWI is a founding member of ERCIM, the European Research Consortium for Informatics and Mathematics. CWI's research has a theme-oriented structure and is grouped into four clusters. Listed below are the names of the clusters and in parentheses their acronyms. Probability, Networks and Algorithms (PNA) Software Engineering (SEN) Modelling, Analysis and Simulation (MAS) Information Systems (INS)

Copyright © 2001, Stichting Centrum voor Wiskunde en Informatica P.O. Box 94079, 1090 GB Amsterdam (NL) Kruislaan 413, 1098 SJ Amsterdam (NL) Telephone +31 20 592 9333 Telefax +31 20 592 4199 ISSN 1386-3703

CAFE Project − Final Report Volume II Secure Protocols and Architecture Edited by A. Bosselaers, R. Carter, R. Hirschfeld, R. Michelsen, S. Mjølsnes Published by CWI, P.O. Box 94079, 1090 GB Amsterdam, The Netherlands

ABSTRACT This is the final public report of the CAFE project (ESPRIT 7023). CAFE developed a secure conditional access architecture and implemented a multi-currency electronic purse system based on smart cards and infrared wallets. The electronic purse was tested in user trials at the European Commission premises in Brussels. Part I of the report covers background surveys, a simplified functional description of the system, and the operation and results of the user trials. Part II describes in detail the security architecture and the technical protocols developed by the project. 2000 Mathematics Subject Classification: 69C30, 69D56, 69E30, 69M34, 69M55 1998 ACM Computing Classification System: C.3.0, D.4.6, E.3.0, K.4.4, K.6.5 Keywords and Phrases: Conditional access, electronic purse, electronic wallet, smart cards, e-commerce, digital cash, consumer payments, multi-currency Note: Many CAFE project participants contributed to the writing of this report, and it would be impossible to accurately list its authors. The editors listed are those who were involved in the final preparation and editing of the document.

Final Report Volume II

Technical Specications ESPRIT 7023 CAFE Document PTS9364

April, 1996

CAFE Final Report Volume II

ii


Contents List of Figures List of Tables Preface

ix xiii xv

I Overview

1

1 Objectives 2 The System

3 5

2.1 2.2 2.3 2.4 2.5

System Model . . . . . Roles . . . . . . . . . . Transactions . . . . . . The Electronic Wallet . Key Management . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 Features 3.1 3.2 3.3

5 5 6 6 7

9

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

II Architecture

13

4 System Architecture

15

4.1 4.2 4.3 4.4

Requirements Framework . . Roles . . . . . Transactions .

. . . .

. . . .

5 Security Architecture 5.1 5.2 5.3

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

15 16 17 19

27

Security Approaches . . . . . . . . . . . . . . . . . . . . . . . . 27 The Electronic Wallet . . . . . . . . . . . . . . . . . . . . . . . . 28 Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . 31

iii

Contents


III Protocols

33

6 Notation and De nitions 6.1 6.2 6.3 6.4 6.5

Assignment Denitions . . . . . . . Representation of Numbers . . . . . Denitions and Basic Operations . Symbols . . . . . . . . . . . . . . . Stable Storage and Atomic Actions

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 The Basic Cryptographic Primitives 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9

The Schnorr Scheme . . . . . . . . . . . . . . The Basic Proof System . . . . . . . . . . . . The Restrictive Blind Signature Scheme . . . The van Heyst-Pedersen Scheme . . . . . . . . The Randomized Schnorr Signature . . . . . . The RSA Signature Scheme . . . . . . . . . . The One-way Function Encoding Phone Ticks The Pseudo Random Number Generator . . . The Hash Function . . . . . . . . . . . . . . .

8 The Protocols

8.1 Introduction . . . . . . . . . . . . . . . 8.2 reset . . . . . . . . . . . . . . . . . . . 8.3 get info . . . . . . . . . . . . . . . . . 8.4 authenticate . . . . . . . . . . . . . . 8.5 write cu tbl . . . . . . . . . . . . . . 8.6 gen cheque . . . . . . . . . . . . . . . 8.7 load cheque . . . . . . . . . . . . . . . 8.8 show currencies . . . . . . . . . . . . 8.9 payment . . . . . . . . . . . . . . . . . 8.10 transfer . . . . . . . . . . . . . . . . . 8.11 unlock amt . . . . . . . . . . . . . . . 8.12 update . . . . . . . . . . . . . . . . . . 8.13 get certif . . . . . . . . . . . . . . . 8.14 rec payments . . . . . . . . . . . . . . 8.15 recovery . . . . . . . . . . . . . . . . . 8.16 deposit . . . . . . . . . . . . . . . . .

9 The ; Protocols 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8

iv

Introduction . . . reset . . . . . . . get info . . . . . authenticate . . write cu tbl . . gen cheque . . .

. . . . . . show currencies . payment . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

35 35 35 37 41 42

43 43 44 45 45 46 47 48 48 52

61 61 63 63 64 66 69 70 73 73 77 81 82 82 84 84 88

91

. 91 . 93 . 95 . 95 . 98 . 98 . 101 . 102

Contents


9.9 9.10 9.11 9.12 9.13 9.14 9.15

... unlock amt . update . . . . get certif .

. . . . rec payments . recovery . . . . deposit . . . . transfer

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 102 . 106 . 106 . 106 . 109 . 111 . 113

A List of Identi ers in the Protocols

115

B List of Identi ers in the ; Protocols

119

IV Security Evaluation

123

10 Security Evaluation of Basic Primitives

125

11 Security Requirements

137

10.1 Discrete Logarithms . . . . . . . . . . . . . . . . . . . . . . . . . 125 10.2 Primitives Using the Factoring Assumption . . . . . . . . . . . . 132 10.3 Security of the Hash Function . . . . . . . . . . . . . . . . . . . 134 11.1 11.2 11.3 11.4

Assumptions . . . . . Bank's Requirements Payer's Requirements Payee's Requirements

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 137 . 138 . 139 . 140

12 Security in the Protocols

141

13 Integrity in the ; Protocols

151

12.1 Bank's Requirements . . . . . . . . . . . . . . . . . . . . . . . . 141 12.2 Payer's Requirements . . . . . . . . . . . . . . . . . . . . . . . . 147 12.3 Payee's Requirements . . . . . . . . . . . . . . . . . . . . . . . . 148 13.1 13.2 13.3 13.4

Bank's Integrity . . . . . . . . . Payer's Integrity . . . . . . . . . Resilience Against Interruptions Independence of ; Protocols . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 151 . 155 . 161 . 162

V Clearing

169

14 Introduction

171

14.1 14.2 14.3 14.4

Overview . . . . . . . Denitions . . . . . . Requirements . . . . Clearing Architecture

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 171 . 173 . 174 . 176

v

Contents


15 Functional Description

179

15.1 Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 15.2 Some Clearing Issues . . . . . . . . . . . . . . . . . . . . . . . . 180 15.3 Clearing System Procedures . . . . . . . . . . . . . . . . . . . . 183

16 Properties of the Clearing System 16.1 16.2 16.3 16.4

Risk Analysis . . . . . . . . . . . . . . . . Fault Tolerance . . . . . . . . . . . . . . . Capacity . . . . . . . . . . . . . . . . . . . Truncation and Accumulation of Cheques .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

189

. 189 . 190 . 191 . 191

17 Distributed Clearing

193

VI Key Management

197

17.1 Overview of the Model . . . . . . . . . . . . . . . . . . . . . . . 193 17.2 Functional Description . . . . . . . . . . . . . . . . . . . . . . . 194 17.3 Properties of the Generalized Clearing Architecture . . . . . . . 195

18 Introduction 18.1 18.2 18.3 18.4

Overview . . . . . . . . . . Entities and Functionality Certication Hierarchy . . Certicate Classes . . . . .

19.1 19.2 19.3 19.4 19.5 19.6 19.7 19.8 19.9 19.10 19.11 19.12 19.13 19.14

. . . .

199

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 199 . 199 . 202 . 205

Notation . . . . . . . . . . . . . Central Certication . . . . . . Realm Certication . . . . . . . Clearing System Signature . . . Acquirer Signature . . . . . . . Systemwide Crypto Parameters Issuer Authentication . . . . . . Issuer Cheque Signature . . . . Observer Signature . . . . . . . Shared Parameter . . . . . . . . Observer PRSG Parameters . . Purse Blinding . . . . . . . . . . Aliated Observer Signature Non-cryptographic Parameters .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. 209 . 209 . 212 . 214 . 216 . 217 . 220 . 221 . 224 . 226 . 228 . 229 . 232 . 233

19 Parameter Classes

. . . .

209

20 Activation of Entities

237

21 Version management

239

20.1 Wallet Activation . . . . . . . . . . . . . . . . . . . . . . . . . . 237 20.2 Activation of Aliation . . . . . . . . . . . . . . . . . . . . . . . 238

21.1 Overlapping Validity Periods . . . . . . . . . . . . . . . . . . . . 239 21.2 Validity Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 239

vi

Contents


22 Security Properties 22.1 22.2 22.3 22.4 22.5

Types of Attack . . . Forged Certicates . Key Compromisation Acquirer Signature . Clearing Signature .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

23 Key Management for the System 23.1 23.2 23.3 23.4 23.5 23.6 23.7 23.8 23.9 23.10 23.11

Entities . . . . . . . . . . . . . . Certicate Classes . . . . . . . . Central Certication . . . . . . Realm Certication . . . . . . . Systemwide Crypto Parameters Issuer Authentication . . . . . . Issuer Cheque Signature . . . . Wallet Signature . . . . . . . . . Shared Parameter . . . . . . . . Wallet PRSG Parameters . . . . Non-Cryptographic Parameters

. . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

241

. 241 . 241 . 242 . 242 . 243

245

. 245 . 245 . 246 . 246 . 246 . 246 . 246 . 246 . 247 . 247 . 247

VII Extensions

249

24 E ciency Improvements

251

24.1 An Alternative Blind Signature Scheme . . . . . . . . . . . . . . 251 24.2 k-Spendability Extension . . . . . . . . . . . . . . . . . . . . . . 253 24.3 Exploiting Pre- and Post-processing . . . . . . . . . . . . . . . . 259

25 Multi-Currency Payments 25.1 25.2 25.3 25.4 25.5

Introduction . . . . . . . . Multiple Issuers . . . . . . Multiple Currencies . . . . General Requirements . . . Protocols and Procedures .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 265 . 265 . 266 . 267 . 268

Introduction . . . . . . . . . Credential Mechanisms . . . Credential Protocols . . . . Applications of Credentials .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 271 . 272 . 276 . 286

26 Credential Schemes 26.1 26.2 26.3 26.4

265

. . . . .

Bibliography

271

290

vii

Contents

viii



List of Figures 2.1 2.2

Overview of the payment system roles and transactions. . . . . 5 The electronic wallet . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

The abstraction hierarchy. . . . . . . . . An example from the architecture. . . . . Complete payment system architecture . The withdrawal transaction . . . . . . . The and ; payment transaction . . . . The + payment transaction . . . . . . . The transfer transaction . . . . . . . . . The recovery initialization transaction The recovery transaction . . . . . . . . The + or ; recovery transaction . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

16 18 20 21 22 23 24 24 25 25

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8

Schnorr's identication protocol. . . . . . . . . Schnorr's signature protocol. . . . . . . . . . . The basic proof system . . . . . . . . . . . . . The restrictive blind signature scheme . . . . . van Heyst-Pedersen fail-stop signature scheme The randomized Schnorr signature . . . . . . . Outline of compress . . . . . . . . . . . . . . . Outline of hash H . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

44 44 45 46 47 47 56 57

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15

-reset . . . . . . . . . . -get info . . . . . . . . . -authenticate . . . . . . -write cu tbl . . . . . . -gen cheque . . . . . . . -load cheque . . . . . . . -show currencies . . . . -payment of a cheque . . -payment of phone ticks . ; to transfer (part 1) . ; to transfer (part 2) . ; to rollback . . . . . . -unlock amt . . . . . . . -updateP a . . . . . . . . -updateP c . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

63 63 65 67 69 71 73 74 75 78 79 80 81 82 83

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

ix

List of Figures


8.16 8.17 8.18 8.19 8.20

-get certif . . -rec payments . -recovery init -recovery . . . -deposit . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17 9.18

;-reset . . . . . . . . . ;-get info . . . . . . . . ;-authenticate (part 1) ;-authenticate (part 2) ;-write cu tbl . . . . . ;-gen cheque . . . . . . ;-show currencies . . . ;-payment (part 1) . . . ;-payment (part 2) . . . ;-payment (phone ticks) ;-unlock amt . . . . . . ;-updateP a . . . . . . . ;-updateP c . . . . . . . ;-get certif . . . . . . ;-rec payments . . . . . ;-recovery (part 1) . . . ;-recovery (part 2) . . . ;-deposit . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. 94 . 95 . 96 . 97 . 99 . 100 . 101 . 103 . 104 . 105 . 106 . 107 . 108 . 109 . 110 . 111 . 112 . 114

. . . . .

. . . . .

. . . . .

84 85 86 87 89

14.1 Payment system with clearing . . . . . . . . . . . . . . . . . . . 172 14.2 Model for recovery of value in a lost wallet. . . . . . . . . . . . . 173 14.3 The structure of the centralized clearing architecture. . . . . . . 176 17.1 A general node in the clearing hierarchy. . . . . . . . . . . . . . 193 18.1 Structure of the key management certication hierarchy. . . . . 204 18.2 Location of parameter classes in the key certicate hierarchy. . . 207 19.1 19.2 19.3 19.4 19.5 19.6 19.7 19.8 19.9 19.10 19.11 19.12 19.13 19.14 x

Example of a one-to-many distribution. . . . . . . . . . Distribution of the central certicate verication key. . Distribution of the realm certicate verication key. . . Distribution of the clearing system verication key. . . Distribution of the acquirer verication key. . . . . . . Distribution of the systemwide crypto parameters. . . . Distribution of the issuer authentication key. . . . . . . Distribution of the issuer cheque verication key. . . . Distribution of the observer verication key. . . . . . . Distribution of the shared parameter. . . . . . . . . . . Distribution of the observer PRSG parameters. . . . . Protocol for proving validity of blinding key modulus. . Distribution of the purse blinding key. . . . . . . . . . Distribution of the aliated observer verication key. .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. 209 . 211 . 213 . 215 . 217 . 219 . 221 . 223 . 226 . 227 . 229 . 230 . 231 . 233

List of Figures


19.15 Distribution of the max pay and max ticks parameters. . . . . . 235 19.16 Distribution of the max trans parameter. . . . . . . . . . . . . . 235 21.1 Illustration of overlapping key validity periods. . . . . . . . . . . 239 21.2 Dependencies between key validity periods. . . . . . . . . . . . . 240 24.1 24.2 24.3 24.4 24.5

Issuing a Schnorr signature (c r) on a blind message m. . . . . . 252 Protocol to get a blind signature (g c r ) on a blind message m.252 Committing to 21 : : : 2k . . . . . . . . . . . . . . . . . . . . . 255 Critical part of gen cheque . . . . . . . . . . . . . . . . . . . . . 260 Critical part of gen cheque with preprocessing . . . . . . . . . . 261

26.1 26.2 26.3 26.4 26.5 26.6 26.7 26.8 26.9 26.10 26.11 26.12 26.13 26.14

Pseudonyms in organisations . . . . . Identication protocol . . . . . . . . . reg user . . . . . . . . . . . . . . . . get pseudonym . . . . . . . . . . . . reg pseudonym . . . . . . . . . . . . issue credential . . . . . . . . . . show credential . . . . . . . . . . . Issue one-showable credential . . . . . Showing a one-showable credential . . Clearing a credential . . . . . . . . . Issue credential encoding information Show credential encoding information Issue k-showable credential . . . . . . Showing a k-showable credential . . .

0

0

0

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. 273 . 277 . 278 . 279 . 280 . 281 . 282 . 283 . 284 . 285 . 286 . 287 . 288 . 289

xi

List of Figures

xii



List of Tables 4.1 Users, roles and functional entities in the CAFE payment system. 17 10.1 Asymptotic running time for DLP algorithms . . . . . . . . . . . 128 18.1 Users, roles and functional entities in the key management system.200 18.2 Data elements in a parameter certicate. . . . . . . . . . . . . . . 203 18.3 Certicate types. . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 24.1 Computation times for 2-spendable cheques . . . . . . . . . . . . 256 24.2 Complexity of k-spendability . . . . . . . . . . . . . . . . . . . . 258

xiii

List of Tables

xiv



Preface The report describes in detail the technical construction of an open cross-border electronic retail payment system that is fully capable of replacing physical cash and similar paper-based instruments. This fundamentally new currency system is well prepared for the challenges of the information age, by being based completely on digital computer and communications technology. To read and understand the entire report in detail requires in-depth knowledge from the elds of computer science and cryptology. However, Part I gives a fairly brief and comprehensive overview, and should be easy to read without special knowledge. The target audience of this report is people who take part in the technical planning, development, trial and deployment of new payment systems, services, and equipment. Typically, these will be people from banking and nancial organizations, equipment manufacturers, software houses, service providers, merchant chains, and support and consultancy companies. The line of research concerned with constructing cryptographic protocols that can provide the service and security required for digital cash had its start in the early eighties. The single most inuential researcher and motivator over the years has been David Chaum, who also laid the rst stepping stones for the CAFE consortium and served as chairman of the project. The CAFE project was partly funded by the ESPRIT III program during the period from December 1992 through February 1996. Field trials of an implementation started in October 1995 at European Commission sites in Brussels. The overall project was structured into four technical workpackages: Secure Protocols, Architecture, Demonstrator, and Trials & Surveys. This report presents the results of the Secure Protocols and Architecture workpackages. The report is structured into seven parts. Part I, Overview, gives the basic objectives, and outlines the structure of the system, with its functionality and security properties. Part II, Architecture, describes the system and security architecture. Part I and II together will give the reader a good understanding of the concepts and principles involved. Part III, Protocols, contains a complete specication of the essential protocols in the system. The specications are oriented toward the mathematical (cryptographic) computations in the protocols. The prerequisite to interpret the protocol specications is included in the rst chapters of this part. Part IV, Security Evaluation, lists the security requirements and gives arguments for the security of the system. Part V, Clearing, describes the infrastructure for interbank clearing and xv

Preface


settlement, and how the validity of the currency and the integrity of the system operation are maintained. Part VI, Key Management, species how the generation, certication, distribution and revocation of system and security parameters are carried out in the system. Finally, Part VII, Extensions, proposes and discusses additional protocols and applications that can easily be accommodated by the architecture. This report is based on several intermediate project papers and reports, but quite extensively edited by S. Mjlsnes and R. Michelsen. A. Bosselaers, R. Hirschfeld, and R. Carter produced valuable comments on the nal draft versions of the text. The Editors April, 1996

xvi


Part I

Overview

1


Chapter 1

Objectives The CAFE project has developed the concept of an electronic wallet containing currency a pocket sized workstation that lets users undertake cash payments electronically at shops, payphones, vending machines, toll roads and public transportation. An electronic wallet transacts either directly or via computer networks with merchants' tills, service points provided by banks and other organizations, or with wallets held by individuals. For backwards compatibility, the simplest type of wallet was realised in the form of a smart card. The project additionally built more complete wallets. These are self-contained with respect to user interface and external communications. Such features make the wallet more secure and allow application exibility. We envisage that electronic wallets will eventually connect to or be embedded in multi-application pocket workstations. The CAFE results and technology represent a major step forward over any approach to retail electronic currency systems proposed to date. Former approaches, typically employing pre-paid IC cards, are only suited to closed systems with low security. A single national phone card, where the issuer and the service provider is the same, typies such systems. The CAFE technology, on the other hand, is designed to operate in an open and international retail payment system, where high security for all parties is demanded. This report presents the specications of the CAFE system. The report details the security and functional design. Certainly, the aim was to keep the implementation constraints to a minimum, thereby making it easy to adapt to new implementation tools and devices steadily becoming available. Nevertheless, the feasibility of the system has been veried already through implementations CC97b] and a trial site CC97a].

3

Chapter 1: Objectives

4



Chapter 2

The System 2.1 System Model The basic system model is shown in Figure 2.1. It shows the most important roles in the payment system and the transactions executed between these roles.

2.2 Roles The following basic roles can be identied in the CAFE system:

Payer A payer withdraws electronic currency from the issuer by a withdrawal transaction, and pays for services or goods to a payee by a payment transaction.

Payee A payee receives electronic currency from a payer by a payment transaction, and deposits it with the acquirer by a deposit transaction.

Issuer An issuer is a bank organization issuing electronic currency to the payers.

Clearing e e e

% % %

Acquirer

Issuer Withdrawal Payer

Payment

Deposit Payee

Figure 2.1: Overview of the payment system roles and transactions.

5

Chapter 2: The System


Acquirer The acquirer collects the electronic currency from the payee and forwards the cheques to the clearing.

Clearing The clearing checks the validity of electronic currency, accumulates

currency claims from acquirers on issuers, and initiates funds transfers between banks.

The system is designed for an unrestricted number of both payers and payees, issuers and acquirers. The clearing role envisaged may become a distributed, possibly hierarchical structure.

2.3 Transactions The most important transactions in the CAFE payment system are withdrawal, payment and deposit. These transactions realize the key services of the payment system. A more detailed description of these and additional transactions are given in Part II.

Withdrawal This transaction is executed between an issuer and a payer. The issuer debits the payer's bank account by an amount specied by the payer and issues the corresponding amount in electronic currency. The payer may choose his electronic currency from a list of dierent currencies.

Payment The payment transaction is executed between a payer and a payee.

At the payee's request, the payer transfers electronic currency to the payee. The payee veries the validity of the received currency and accepts the payment.

Deposit The payee deposits the electronic currency received by a deposit transaction with an acquirer. The acquirer forwards the deposit record to the clearing system and the payee's account is credited with an amount corresponding to the received electronic currency.

2.4 The Electronic Wallet A key component in the CAFE architecture is the electronic wallet as rst introduced in Cha92]. The functional entities of such an electronic wallet communicating with a service terminal are shown in Figure 2.2. The electronic wallet is an essential element in the balanced security of the proposed CAFE system. It reduces or even eliminates many of the trust relations required in existing electronic payment systems that are based on magnetic stripe or IC cards. The electronic wallet comprises an observer and a purse. The observer is trusted by the issuer and protects the issuer's interest during o-line transactions. The observer restricts the amount of money the payer can spend within the balance stored in the observer itself. Hence, the implementation of the observer must be tamper-resistant. 6

2.5 Key Management


Wallet Observer

Purse

Infrared link Service terminal

Figure 2.2: The electronic wallet constitutes a purse and an observer. It communicates with a service terminal using an infra-red link.

The purse is trusted by the payer. It veries the actions of the observer, and prevents the observer from performing unsolicited actions. In addition, the purse typically contains buttons or a keypad and display for user input and output. For instance, these can be used to lock and unlock the wallet, and to verify requested amounts in payment transactions. A self-contained user interface eliminates the need for a trusted service terminal, which is absolutely necessary in other approaches to electronic retail payments. Section 5.2 gives an extensive description of the CAFE concept of an electronic wallet, the options for implementation, and the implications with respect to trust assumptions.

2.5 Key Management Public keys are certied in a three level certication hierarchy. A central certication authority for system-wide keys, a number of realm certication authorities for keys belonging to roles such as issuer and payer, and the third level for issuers themselves, using digital signatures in the basic transactions. In general, the owner of a key will generate it, have it certied, and distribute it to the roles that need it. However, the payer distributes the issuer's public key certicate to the payees using the wallet.

7

Chapter 2: The System

8



Chapter 3

Features 3.1 Introduction The CAFE payment systems are all following the paradigm of untraceable electronic cash rst proposed by David Chaum (see Cha83]). The model for o-line electronic cash oering both integrity and privacy was introduced in CFN90]. In the same paper also a system was proposed that seems to t that model. Various other systems using basically the same ideas have since then been proposed, like e.g., Ant90, CBH+ 90, FY92, OO90, OO92, Pai93, Fer94a, Fer94b]. In Bra93, Bra94a] the digital signature schemes of CP93b] and HP93] are combined into an untraceable coin system, that served as the starting point for the cheque-based CAFE systems of Part III, that use cheques in combination with one or more balances, an idea that was rst introduced in BC90].

3.2 Functionality Cash Electronic currency value in the CAFE system is pre-paid . Normally,

the payer's bank account is debited at the withdrawal. This takes place in advance of the payment. The payment is analogous to a cash payment in that the money is transferred instantaneously without consulting a bank or other intermediaries. The currency can be deposited with any acquiring bank.

O-line Payment A property of the CAFE security architecture is that the

payment can be made o-line . No connection with the issuer or any other third party is required at payment time, similar to a cash payment. This feature is very important for the cost-eciency of low-value payments. It is also very important in building a system that is robust against failures of central facilities. The payee is able to verify, without help from the issuer, that the received electronic currency is valid. Forged payments are prevented at payment by the payee, but will also be detected when the transaction is cleared. This is similar to current cash. The mechanism used to enable the payee to check the validity is based on public key digital signatures . This is described in some detail in Chapter 5.

Signature Transport The CAFE currency is based on signature transporting

cheques. At withdrawal, cheques are signed by the issuer and transported to the payer's wallet. This guarantees the validity of the cheque and that the payer is a customer of the issuing bank. The issuer's signature is veried by the wallet.

9

Chapter 3: Features


At payment, the payer's wallet adds another signature to the cheque, now lled in with the amount of the payment and the identity of the payee. It is then transported to the payee, who can check the validity of the payment before accepting it. The transcript of the payment are deposited with the acquirer.

Multiple Currencies The CAFE payment system provides the possibility

to pay in foreign currencies in two dierent ways. First, the payer's wallet has several dierent \pockets" for dierent currencies. During withdrawal, the payer chooses which currencies to load. This corresponds to the service of buying foreign currencies at a bank today. The second method is a currency exchange performed at payment. The payee accepts a number of currencies at rates set by the acquirer, and if the payer's wallet has any of these currencies, a payment can be performed. The payer pays using the preferred currency accepted by the payee, the payee deposits the received cheque and is credited in the home currency. CAFE therefore permits payers to prepare themselves for payment abroad by loading foreign currencies in advance, but allows the exibility of paying in an unanticipated currency if the need should arise by using the currency exchange during payment.

Loss Tolerance For payers, loss tolerance is probably the most important

special feature of the CAFE system. If a payer loses physical notes or coins, or they are stolen, the money value is lost. Not so in the CAFE system. Loss tolerance means that the issuer is able to recover the currency from a backup and the deposit transcripts. A backup procedure is carried out in normal operations during withdrawal. If a payer wants to recover lost money he will \reveal" the identity of the cheques stored after the last withdrawal to the issuer. This enables the issuer to trace these cheques to see if they have been spent and refund any remaining value that was left in the wallet

Fault Tolerance The CAFE system tolerates faults and interruptions during transactions without either party losing any money. Interrupted transactions are automatically recovered by the system.

Incremental Payments A complete payment transaction requires two sig-

natures by the wallet. Therefore very fast payments (less than 0.5 seconds) are not feasible in current implementations. The payphone application is an example where incremental payment is required. To provide many fast subsequent payments to one payee, a special extension of the basic payment protocol is used. It allows the payment of a large number of amounts within one payment transaction. The total is not required to be known in advance, enabling ecient pay-as-you-go applications. After an initialization phase, where the value of one tick and the maximum number of ticks to be used is xed, the payer sends subsequent ticks on request. Only the last tick is deposited together with the information received during initialization. For example, within one payment for a phone call, the amount is incremented for each unit spent. Rather than one 10


3.3 Security

payment for each unit, there is one payment for the complete call consisting of several units Ped95, Ped97].

Open Networks The CAFE protocols are designed to be secure over inse-

cure networks, such as public telecommunication networks, Internet, wide and local area networks, including infrared links. This implies that withdrawals, payments and deposits can be undertaken without special requirements to the network carrying the transactions.

3.3 Security Multiparty Security The CAFE protocols achieve multilateral security by ensuring veriability for all roles the issuer, the payer, the payee, and the acquirer. In somewhat simplistic terms we can say that the integrity is maintained under the assumption that the issuer trusts the observer and the reload station, the payer trusts the purse, the payee trusts the till, and the acquirer trusts the acquire station. For example, the payer does not need to rely on the issuer's reload station and the observer for the correctness of the withdrawal. This balanced multiparty security is much more proper for open systems than former approaches to payment security. Privacy If existing electronic payment systems, such as debit and credit

cards, are used for everyday low-value payments, the system operator has access to an extensive prole of the payer's behavior. A payee is forced to identify its customers to maintain security in such systems. Payers may choose to keep on using cash, because it provides untraceability. Cash usage does not require payer identication by the payee or the issuer. Moreover, dierent payments performed by the same payer are unlinkable with respect to the information disseminated in the payments. It is simply not possible for merchants and banks to pick out notes and coins that were spent by the same individual. The basic CAFE system provides the same privacy as cash. The payer is untraceable with respect to payment transactions, if the payer so wishes. Neither the payee nor the issuer will learn the identity of the payer from the payment itself, and dierent payments are unlinkable Cha85]. Blind signatures Cha83] constitute the cryptographic means by which this privacy protection is achieved.

Forgery Protection Currency value in the transaction is represented by

electronic bits, which of course may be easily copied. Potentially, the original and the copy may both be spent (double spending). The payee is not able to decide whether he can accept the oered money, without contacting the acquirer to ask if these bits have already been deposited. This solution will require an online payment, which is not cost ecient for low-value payments in a retail environment. The CAFE system employs two means to counter this threat tamper-resistant observer device and \after-the-fact" detection and tracing of the double spender. 11

Chapter 3: Features


The tamper-resistance of the observer device protects copying and modications to the currency, and makes it infeasible to spend electronic currency twice. The tamper-resistance guarantees the integrity of the issuer to the payee in an oine payment. If the tamper-resistance of an observer device is broken, copying and double spending of currency cannot be prevented. However, double spending will be detected by the clearing, because the CAFE protocols ensure that double spending payments are no longer anonymous transactions. The identity of the observer device will be computed and the forgery can be cryptographically proved from two payment transcripts. This restricts the potential gain of breaking tamper-resistance, because the forger will be traced, and the system will blacklist double spent cheques.

Robbery Protection A merchant (payee) will no longer need to be con-

cerned with cash robberies. The electronic currency accepted in payments is \dedicated" to the payee, and only represents value to the payee. Physical protection of the till is not required. However, the currency value can easily be destroyed due to storage erasure, consequently storage must be suciently protected against this risk.

Audit In common with all existing electronic payment systems, the CAFE ar-

chitecture does not provide anonymity and untraceability to the payee. Hence, all payments received are fully auditable by normal standards. All payments have to be deposited to one or more acquiring banks, and will show in the payee's account entries. This makes it very dicult if not impossible to accept electronic currency as black money without the bank's consent and collusion. Bribery using electronic currency appears unattractive. The payee will run the risk of incrimination by the payer, because the payer is always able to produce cryptographic evidence of the payment. In addition, the payee will have to deposit the bribe to a bank, where it will enter the accounts. The withdrawal transactions are completely auditable by the issuer by standards. The payer can audit the payment transactions completely by normal standards. Withdrawal, payment and deposit transactions can be provably linked if the payer so wishes.

PIN Veri cation The CAFE observer is involved in all transactions. The ob-

server will however not participate in a transaction without being activated by the payer entering a password or -number (PIN). The CAFE system permits the use of two dierent PINs|one for withdrawal (for accessing the account balance) and the other for payments and transfers (for unlocking a payer-specied amount of the wallet balance Det94]). It is possible to use the same PIN, but this represents a small reduction of the system's security.

12


Part II

Architecture

13


Chapter 4

System Architecture 4.1 Requirements The Trials & Surveys workpackage of the project collected user and expert requirements and properties. Here we present a list of important requirements that have a major impact on the technical solutions of the architecture, and which the system satises. Much of the model, requirements, and additional functionality ideas are based on Cha89, BP89, PWP90].

Security The payment system and its applications should oer a high level of

security to all parties, where security means an appropriate combination of integrity, privacy and veriability.

Privacy Payment transactions should protect the privacy of the payer. Low cost Low value payments should be o-line to minimize payment transaction cost.

Loss tolerance If the wallet becomes damaged, stolen or lost, the owner should be able to obtain a complete refund of the lost currency value.

Limited transferability Unlimited transferability may have negative side-

eects such as the black-market activity, money laundering and lost revenues for acquirers. It should however be possible to transfer value if wallet aliation has been prearranged.

Cross border The wallet should be able to contain several currencies, and allow for withdrawal and payment in those currencies. Also, the system should provide for currency exchange and paying with non-local currency.

Reliability There should be no consequences resulting from interrupted transactions when the wallet is used.

Compatibility It should be possible to retrot existing terminal equipment to transact with electronic wallets.

Open It must be possible for banks, merchants, and individuals to enter and leave the system at all times.

Standard The system specications must be open and be capable of becoming an international standard.

15

Chapter 4: System Architecture


Users Roles Functional Entities Devices Figure 4.1: The abstraction hierarchy.

Applications It must be possible to create payment applications for a broad range of services, including network services, payphones, shops, toll, etc.

Scalability The system should be able to scale to an international retail payment system.

Extendibility The system should dynamically be able to include new payment applications.

Fungibility It should be possible to pay anywhere and anytime, provided that

the wallet contains sucient value. That is, the wallet should always be able to pay an exact amount without the problem of no \small change" available.

4.2 Framework The architecture framework that this specication adheres to is an abstraction hierarchy of four levels.

A user that takes on roles

A role owns and is supported by one or more functional entities

A device implements and incorporates one or more of the functional entities.

Figure 4.1 illustrates this hierarchy. The user, role and functional entity types are presented in Table 4.1. Note that this table also illustrates relationships. A bank is a user of the system, and normally will take on the roles of issuer and acquirer, and perhaps clearing. An individual will at least take on the role of a payer, and a merchant will at least take on the role of a payee. In practice, we expect both individuals and merchants to take on both the role of payer and the role of payee. 16

4.3 Roles


Users

Roles

Functional entities Reload station Bank Issuer Recovery station Observer Acquirer Acquire station Clearing Clearing system Individual Payer Purse Merchant Payee Till Table 4.1: Users, roles and functional entities in the CAFE payment system.

The role of issuer is supported by three types of functional entities: reload station, recovery station, and observer. The payer owns and is supported by the purse. The payee is supported by the till. The term terminal is also used in the specications, and denotes a generic functional entity. The specic functional entities will be apparent from the context. Figure 4.2 gives one example of how the framework can describe two users a bank and an individual. This diagram applies the relations interpreted from Table 4.1 and instantiates one possible setting for the CAFE system. In this particular example the individual is acting both as a payer and a payee with a single device implementing both the purse and the till. Many other diagrams can be constructed within this framework. In the \standard" setting often assumed in the CAFE project, the till entity is not implemented by the purse device.

4.3 Roles This section outlines the roles of the CAFE payment systems. Figure 2.1 describes the roles of issuer, payer, payee, acquirer and clearing.

4.3.1 Issuer An issuer exchanges cash, deposits or other kinds of money received from a payer into electronic currency. The payer receives the electronic currency in a withdrawal transaction. The issuer also loads cheques to the wallets. There is no restriction on the number of issuers that can take part in the system. Normally, there will be several issuers. Issuers do not need to trust each other. Obviously, if a single observer supports several issuers, mutual trust must exist. The accreditation of issuers, for instance by the central bank, is technically carried out in the key management system. 17


Users


Bank

Roles

Acquirer

Functional entities

Acquire station

Devices

Individual

Issuer

Payer

Payee

Till

Reload station

Recovery station

Observer

Purse

Bank terminal

Recovery terminal

Smartcard

Purse device

Wallet device

Figure 4.2: An example from the architecture depicting one possible set of relations between users, roles, functional entities and devices. In this particular example the purse and till have been combined into a single device. Also the acquire station and reload station have been combined into a single device.

18


4.4 Transactions

4.3.2 Payer

The payer withdraws electronic currency from the issuer and spends it with payment transactions. The payer is supported by the purse. However, the payer has to use a wallet, consisting of a purse that connects to an observer, to execute withdrawal, payment and recovery transactions. The observer is initialized and provided to the payer by the issuer.

4.3.3 Payee

The payee, supported by the till, gets paid by a payer in a payment transaction. The electronic currency can be deposited and redeemed by any acquirer the payee has a prior agreement with. Both individuals and organizations can take on the role of a payee. For individuals, the till will most conveniently be incorporated in the electronic wallet device. For merchants, the till will be implemented by the cash register.

4.3.4 Acquirer

The acquirer collects electronic currency from the payees by accepting deposit transactions. It is the responsibility of the acquirer to submit the collected currency to the clearing and credit the value to the payee, normally directly to a bank account. A single payee can deposit currency with one or more acquirers. The acquirer may aggregate deposit records over a period of time, then sort and submit for clearing in batches.

4.3.5 Clearing

The clearing receives (batches of) deposit data and checks validity and double spending. It also initiates settlement between dierent issuers and acquirers. The clearing performs other tasks as well, such as distributing black lists. The clearing role is supported by either a centralized or a distributed clearing system.

4.4 Transactions This section describes the payment system transactions. Figure 4.3 shows the functional entities and the transactions that can be executed. In the transaction descriptions we break down each transaction into individual protocols. A detailed description of each protocol can be found in Part III. We choose to view the transactions from the wallet's side, both because the wallet takes part in the most important transactions security-wise, and because this description will reect suciently the actions of other entities. We will have to distinguish the wallet, the + wallet, and the ; wallet. A detailed knowledge about the dierent wallet types is not required in a rst reading of the transaction description in this section. Please refer to Section 5.2 for a description of these distinct types of wallets. 19



Clearing system

! !! , ! , !! ! , !! , !! ,

Reload station

Recovery station @

Recovery @

@ @

Observer

@ @ @ @

Withdrawal Purse

Payment

Acquire station Deposit Till

Transfer Aliated puse Aliated observer

Figure 4.3: Payment system architecture showing all functional entities and transactions.

Although many protocol names are identical in the and the ; system, this does not imply that the specications are identical. Nevertheless, we take the opportunity to exploit this naming practice so that some of the illustrations for and ; can be the same. Of course, we hope that this streamlining does not confuse the reader. We make use of state diagrams to show how the protocols are carried out in a transaction. These diagrams are only intended as a guideline to the detailed protocol specications that appear in the subsequent chapters. So bear in mind that some details have been glossed over in order to make the diagrams comprehensible and simple.

4.4.1 Withdrawal The main goal of the withdrawal transaction is to load currency into the wallet. It involves the issuer, represented by the reload station and the observer, and the 20

4.4 Transactions


X X reset

get info

authenticate

update

write cu tbl

gen cheque

l

gen cheque

Figure 4.4: State diagram showing the compound of protocols in the withdrawal transaction.

payer, represented by the purse. Figure 4.4 shows the composition of protocols in the withdrawal transaction. The following is a somewhat more detailed step-by-step description of what happens between the wallet and the reload station. 1. The wallet is started with the reset protocol. 2. The wallet presents its stored data about its issuer, by executing the get info protocol. If key updating is necessary, the update protocol is executed. 3. The authenticate protocol is executed. Here the reload station proves its identity to the wallet subsequently, the wallet identies itself, and signs all data relevant to the reload station. If one or more payment transactions subsequent to the previous withdrawal session have failed, the rec payments protocol is called and run. This is not shown in Figure 4.4 because the call to rec payments is included in the authenticate protocol specication. Moreover, the protocol write cu tbl is called in the authenticate protocol if the previous execution of write cu tbl was interrupted. The protocol specication includes this in the authenticate protocol specication, but it is not detailed in Figure 4.4. While the user is busy requesting bank services, such as

withdrawal from a bank account, deposit to a bank account, currency exchange of already loaded value, withdrawal and currency exchange, currency exchange and deposit to an account,

the reload station and the wallet can repeatedly execute the gen cheque protocol. If this protocol fails for some reason then authenticate has to be re-executed. 21



get certif

X X

reset

get info

show currencies

unlock amt

l payment

Figure 4.5: State diagram showing the compound of protocols in the payment transaction

The payer may choose to unlock an amount for payment. The wallet, or the reload station in the system, can then run the unlock amt protocol. This may be done at any suitable time, because it has no interaction with the other protocols, and hence is not shown in Figure 4.4. The currencies and amounts are determined in the user interaction, and the reload station will check the acceptability of the requests. For example, the balance of the payer's account must be sucient for the withdrawal, and the new total amount (when converted to home currency with the current rates) must not exceed the maximum wallet balance. The maximum balance limit can be individually assigned. The bank terminal computes a new currency table based upon the withdrawal and exchange amounts and the old currency table. 4. If the new currency table diers from the previous instance, or if money has been transferred using the transfer transaction, then the write cu tbl protocol is carried out. If this protocol fails it reverts to step 3 to undertake an authentication before a new attempt is made. If no change is requested for the currency table, then the transaction terminates without carrying out the write cu tbl protocol. This is not shown in the diagram, but can happen if the payer decides not to reload value. For the wallet, this will also occur if the payer just wants to check the balance, or wants to to unlock a new amount. The gen cheque protocol is executed as many times as required, for instance, until available memory is lled.

4.4.2 Payment The main goal of the payment transaction is to transport value from the wallet of the payer to the till of the payee. Figure 4.5 shows the combination of protocols that the wallet will execute in the payment transaction. This gure is representative both for the and the ; protocols. Figure 4.6 shows the combination of protocols for the + wallet. The difference is the load cheque protocol, which allows the observer to load cheques from the + purse. 22

4.4 Transactions


get certif

X X

reset

get info

show currencies

unlock amt

l payment

load cheque

Figure 4.6: State diagram showing the compound of protocols in the payment transaction for the + wallet

The following is a step-by-step description of what happens between the wallet and the till. 1. The wallet is reset using the reset protocol. 2. The till starts the get info protocol to check if the public keys that will be required are available. If not, the till will start the get certif protocol to retrieve this from the wallet. 3. The show currencies protocol will aid the payer and payee to calculate how the payment can be made. If the unlocked amount is insucient for this payment, the unlocked protocol will provide the unlocking, assisted by the payer. 4. Once this has been done, the actual payment protocol can be started. It distinguishes between ordinary and phone-tick payment types. If several types of currency are involved, the payment protocol is executed for each of the currencies, until the total has been paid.

4.4.3 Deposit The goal of the deposit transaction is for the till to forward all received electronic currency to the acquire station which will credit the payee's account. The deposit transaction consists of the deposit protocol which forwards the payment transcript to the acquire station. The deposit protocol is executed once for each cheque deposited. The acquire station will forward all received cheques to the clearing system for validation, clearing and settlement with the issuer.

4.4.4 Transfer The main goal of the transfer transaction is to transport value from a ; wallet to an aliated wallet. The aliation has to be agreed in advance, by letting the wallet store the public key po of the ; observer, and the ; observer store the public key ps of the wallet. 23



l

X X

reset

transfer

rollback

Figure 4.7: State diagram showing the compound of protocols in the transfer transaction.

X X

reset

l

recovery init

Figure 4.8: State diagram showing the compound of protocols in the rst stage of the recovery transaction for the wallet.

Figure 4.7 shows the diagram compounding three protocols. The wallet always runs the reset protocol rst. If a previous interrupt of transfer has occurred, the rollback protocol needs to be executed to undo the failed transfer. Note that the call to execute the rollback protocol is part of the reset in the protocol specications. The transfer protocol will check that the amount to be transferred as requested by the user is in accordance with the preset transfer constraints.

4.4.5 Recovery

The recovery transaction enables the service of loss-tolerance in the CAFE system. If the wallet becomes damaged, lost or stolen, the unspent value can be refunded using the recovery transaction. We have to distinguish between the and the ; wallet in the description of this transaction. The wallet is not \standalone" with respect to user input and output. So the recovery has to be carried out in two stages. In the rst stage, the user, at his own discretion, initializes an auxiliary wallet employing a trusted terminal. The protocols used in this stage is shown in Figure 4.8. The interaction with the bank is carried out in the second stage. Here the auxiliary wallet is connecting to a recovery station physically distinct from the trusted terminal used in the rst stage. Figure 4.9 shows the protocols used in this stage. The auxiliary + or ; wallet provides a self-contained user interface. So there is no need for a trusted external terminal at the initialization of this type of wallet. Figure 4.10 shows how the protocols are compounded in the recovery transaction for the + or ; wallet. 1. The wallet is initialized with the reset protocol. 2. Recovery seeds are input by the recovery station and by the user, here 24

4.4 Transactions


l update Pa

X X

reset

get info

recovery

Figure 4.9: State diagram showing the compound of protocols in the second part of the recovery transaction for the wallet.

X X

reset

l

recovery init

get info

recovery

update Pa

Figure 4.10: State diagram showing the compound of protocols in the recovery transaction for the + and ; wallet.

denoted by recovery init. 3. The auxiliary wallet must contain the same system parameter version v as the damaged wallet. This is checked by the get info protocol. If it turns out not to be the same then the update Pa protocol must be executed. 4. The recovery protocol regenerates all of the cheques that were stored in the damaged wallet. The auxiliary wallet signs the cheques and sends them to the recovery station.

25


26



Chapter 5

Security Architecture 5.1 Security Approaches The security of the CAFE architecture is based both on public key cryptography and on tamper-resistant devices. In this section we describe how these techniques are combined into a high security system.

5.1.1 Cryptographic Protocols The dierent roles in the payment system interact using cryptographic protocols. Cryptographic techniques are used to protect the integrity of the system by providing:

Authentication of parties Cryptographic identication protocols are used to authenticate peers in a secure way. These protocols are secure against powerful attacks such as replay of authentication information obtained from a previous run of the protocol.

Authentication of messages Digital signatures are used to authenticate messages. Authenticated messages ensure that the sender of a certain message can be established without doubt and also provides non-repudiation of messages and accountability.

Integrity protection of information Cryptographic techniques are used to protect messages sent between peers from being modied.

5.1.2 Tamper-Resistance The CAFE payment system is based on the currency value being represented by a number of balances in electronic wallets held by payers. These balances must be updated only through the execution of well dened transactions supported by cryptographic mechanisms. Modication of balances must not be possible without executing a complete and valid transaction. To protect against unsolicited modication, the balances are maintained by a tamper-resistant device that implements the functionality of an observer entity. In this project, the tamper-resistant device is in the form of a smart card. The observer must change the balance only if a valid withdrawal or payment transaction has been carried out. The tamper-resistance of the smart card chip prevents the payer (and others) from bypassing the cryptographic 27

Chapter 5: Security Architecture


mechanisms and protocols by changing (increasing) the balances with physical and electronical means.

5.1.3 Fall-Back Security It is hard to quantify just how secure a tamper-resistant device is. No integrated circuit tamper-resistance techniques is believed to survive continuous and sustained attacks. The techniques have to keep up with the attacker techniques. If an attacker should succeed to break the tamper-resistance of a device, the CAFE system provides fall-back security based on cryptographic techniques. While the tamper resistant observer device prevents the payer from spending more money than he has withdrawn, the cryptographic fall back security permits identication of counterfeiting payers during the clearing process. The wallet contains cheques in addition to the balances. The cheques are generated and stored in the wallet during the withdrawal transaction. A unique cheque is spent in each payment transaction, and it is the observer's task to prevent that the same cheque is used in two dierent payment transactions. If a payer is able to break the tamper resistance of the observer device and forge the balance, the wallet will soon run out of cheques. If the cheating payer tries to use a cheque twice, he will be identied by the system.

5.2 The Electronic Wallet A key concept in the CAFE architecture is the electronic wallet, which is described in detail in this section.

5.2.1 Introduction In the CAFE project we use the term electronic wallet to denote the functional entity used by payers to interact with other roles during transactions. An electronic wallet comprises an observer and a purse. The observer functionality is trusted by the issuer. The purpose of the observer is to prevent the payer from spending more money than is available in the wallet. Since the observer device is embedded in the wallet, and under physical control of the payer, it has to be tamper resistant. The purse is an entity trusted by the payer. It is responsible for all wallet input/output, such as communication with service terminals and the user interface. The purse also veries the actions of the observer. The purse will detect if the observer performs actions not sanctioned by the payer. The purse will also \reformulate" outgoing messages to prevent that the observer communicates side information. The goal of an observer's deviating actions may be unsolicited payments or leaking of private information. The purse will see to it that this cannot happen. A wallet device consisting of physically distinct observer and purse devices is desirable when considering trust relations. The issuer must trust the observer. The issuer is the only role that has to trust the observer. Therefore an issuer 28


5.2 The Electronic Wallet

may choose an observer device developer and manufacturer that it trusts. Similarly, the payer is the only role that must trust the purse. Therefore a payer can obtain the purse from a manufacturer or retailer that this individual payer trusts. No functional entity has to be trusted by more roles that do not trust each other because of potentially conict of interest. A sketch of an electronic wallet communicating with a service terminal is shown in Figure 2.2. Many dierent implementations of electronic wallets can be envisaged. Although simplistic, the electronic wallet can be realised in the form of smart card where both the observer and the purse functionality are implemented on the same chip. A more user-friendly wallet implement takes on a form similar to a pocket calculator, where display and keypad are included. The observer will typically be implemented in the form of an embedded tamper resistant chip or a smart card inserted into the wallet. The CAFE system is also suitable for payments over open networks, such as Internet. In this case an electronic wallet can be implemented employing a personal computer. Typically, the purse functionality will be realised by a software module running on the computer, while the observer will be implemented by a plug-in PC Card hardware module.

5.2.2

Wallet

Realisation The (alpha) system provides an upgrade path from existing

electronic retail payment systems based on magnetic stripe and chip cards. In the wallet both the purse and the observer can be implemented in a single tamper resistant chip|typically embedded in a smart card. The wallet has limited capabilities. The purse can only communicate with the environment through the card's electrical contacts. The payer has to rely on external equipment for correctness, such as total amount and PIN entry. The wallet device will not always remain under the payer's physical control because it has to be inserted into terminal equipment. The number of cheques will be restricted by a quite strong limit on the storage space in single-chip implementations. This implies a limitation on the number of payment transactions that can be executed before additional cheques are required. In practice the balance is more likely to be spent before the cheque supply is exhausted.

Trust Relations The combination of observer and purse into a single device

means that both the issuer and the payer has to trust this device. The issuer must trust that the wallet limits the spending of the payer according to the wallet balance, and the payer must trust the wallet not to implement hidden features, such as revealing the payer's identity in a payment transaction. The payer must also trust a number of service terminals. The till is typically implemented by a point-of-sale terminal with a display and a keypad used for verication of amount to pay and PIN entry for authorization of the payment transaction. This terminal must be trusted by the payer to display the correct information, not to copy or store PINs and only to execute the specied 29



protocols with the wallet. Similar trust requirements apply for other terminals with which the wallet performs transactions, such as the terminal implementing the reload station.

5.2.3

+

Wallet

Realisation The + wallet is an improvement of the wallet with respect

to user interface. It consists of an wallet extended with with user interface and communication capabilities. The + observer is quite similar to the observer. The + purse functionality is extended with user interface capabilities. The implementation may have some buttons for use by the payer to conrm an action. For instance, acknowledgment of correct amount in a payment transaction. The purse will also contain facilities for communicating without physical contact | typically an infra-red link. The + wallet implementation is not limited to a single chip, so the storage space is not restricted to on-chip memory. This allows for more cheque storage space, which means that more payment transactions can be performed before connecting to the issuer. In summary, the + wallet oers the following improvements to the wallet:

A single user interface for the payer.

Display for stand-alone verication of actions.

A few function-specic buttons for stand-alone PIN entry and user acknowledge of actions.

Extendible storage of cheques.

External communications by an infra-red link enables the payer to have full physical control over the wallet.

Trust Relations The issuer must trust the observer to limit spending to the

balance stored in the observer. Still, the payer cannot check the purse functionality because it is implemented on the same chip as the observer. The purse must be trusted not to contain \hidden" features which may allow the wallet to leak additional information such as the payer's identity. The + wallet nullies the need to trust the service terminals. The payer will not have to hand over the wallet to the payee. PIN entering and verication of amounts will be undertaken locally by the payer, using the display and buttons on the wallet device.

5.2.4

;

Wallet

Realisation The ; (gamma) wallet is a fully functional wallet. It contains

a ; observer, typically implemented by a single tamper resistant chip, and embedded in the ; purse device. The purse has processing capabilities, memory

30


5.3 Key Management

and input/output facilities. A ; wallet will typically take the form of a small pocket device with display, keypad and infra-red link for communicating with service terminals. In summary, the ; wallet oers the following improvements over the + wallet: Better performance because the purse has computing power and can execute parts of the protocols. Signicantly better privacy and security characteristics, because the purse is able to check and verify the actions of the observer. A user interface that can be adapted to the payer's requirements.

Trust Relations The issuer must trust the observer to limit the spending according to the wallet balance. Almost all trust assumptions by the payer with respect to the observer that is needed for the wallet can be removed by employing the ; wallet. The payer still has to trust the ; observer to perform PIN verication, according to the protocol specication. The payer must trust the ; purse to function according to the specication. The purse is responsible for interaction both with the payer and with service terminals. In addition, the purse checks all actions performed by the observer to prevent the observer from releasing unsolicited bits of information to service terminals.

5.3 Key Management This section provides a brief overview of the key management architecture. The complete description of the key management system for the CAFE payment system can be found in Part VI.

5.3.1 Certication Authorities

In every cryptographic system cryptographic keys have to be distributed in a trusted manner. Alice can only validate a digital signature allegedly from Bob if she has access to Bob's public key. If there is any chance that an impostor is able to fool Alice into using a dierent public key, then Alice can't trust signatures allegedly generated by Bob. Alice can only trust Bob's public key if she gets it through a secure channel, for instance directly from Bob in a face-to-face meeting. For an open retail payment system such as CAFE it is clearly impractical to require that all peers exchange public keys in face-to-face meetings. A public key is therefore certied by a certication authority using the certication authority's digital signature. If Alice receives a key certied by an authority, she will trust this key if she has a trusted copy of the certication authority's public key. In this way we have reduced the problem from having to establish a secure channel to every other peer in the system to a single certication authority. 31



5.3.2 Certication Hierarchy

In CAFE the keys are certied in a certication hierarchy. The certication hierarchy is organized in three levels: 1. A single central certication authority constitutes the top of the certication hierarchy. The public key of this role must be available to and trusted by all participants in the system. It is used for certication of global keys and keys of the realm certication authorities. 2. On the second level a number of realm certication authorities are found. These authorities certify keys belonging to roles in the payment system such as issuers and payers within a particular country or area. 3. On the third level are the individual roles of the payment system that use keys during execution of the various transactions.

5.3.3 Key Certicate Transport

The CAFE system will hold both static and dynamic relations between roles. There is, for instance, a static relation between a payer and an issuer. Dynamic relations exist between payer and payee. For static relations, a certied public key is sent directly from the owner of the key to all roles that needs to verify signatures generated by the owner. Payees need access to the public key of the issuer of a payer for validation of a payment transaction. This relation is however dynamic, and with a potentially very large number of issuers, it is unlikely that all payees will get keys directly from all issuers. This problem has been resolved by having payers bring key certicates of issuer keys to payees. In the payment transaction, the payer sends the certied issuer key to the payee on request. The payee veries the key certicate using the certication authority key, and the payment transaction commences.

5.3.4 Generation of Keys

A goal of the CAFE system is that the security of all parties should depend as little as possible on other parties. This means that all parties must be able to generate their own keys.

32


Part III

Protocols

33


Chapter 6

Notation and Denitions The notation and denitions used in the protocol specications are given in this chapter. The description includes the representation of the numbers, and the basic operations and functions. The basic cryptographic primitives are presented in the next chapter (Chapter 7).

6.1 Assignment Denitions The symbol \:=" is used for the assignment of a meaning to a variable or symbol. That is, a := b means that a is dened as \b". The symbol \" is used for assignment of a value to a variable. That is, a b means that the variable a gets the value of the variable b. The equality-sign \=" is used for equality only. That is, it indicates that the two entities on either side are equal. An ellipsis (\. . . ") denotes an implicit enumeration. For example, \i = 0, 1, . . . , n" is meant to represent the sentence \for i = 0, i = 1, and so on, up to i = n".

6.2 Representation of Numbers In this document a byte is dened as an 8-bit quantity. A byte is considered to be a nonnegative integer. That is, it can take on the values 0 through 28 ; 1 = 255. Furthermore, a word is dened as a 32-bit quantity. A word is considered to be a nonnegative integer, hence it takes on the values 0 through 232 ; 1 = 4294967295. A number can be given in decimal, in hexadecimal as well as binary representation. All representations are given with the most signicant digit rst (leftmost). The hexadecimal representation of a number is `0x' followed immediately by its hexadecimal digits, the most signicant one rst. For example, the hexadecimal representation of the number 4023233417 is 0xefcdab89. The binary representation of this same number is 1110 1111 1100 1101 1010 1011 1000 1001: A sequence of 8n bits b0 , b1 , . . . , b8n 1 is interpreted as a sequence of n bytes in the following way. Each group of 8 consecutive bits is considered as a ;

35

Chapter 6: Notation and De nitions


byte Bi , the rst bit of such a group being the most signicant bit of that byte. The bytes are numbered from left to right, starting from 0. Hence, Bi := b8i 27 + b8i+1 26 + + b8i+7 i = 0, 1, . . . , n ; 1 : (6.1) A sequence of 4l bytes B0 , B1 , . . . , B4l 1 is interpreted as a sequence of words W0, W1 , . . . , Wl 1 in the following way. Each group of 4 consecutive bytes is considered as a word Wi , the rst byte of such a word being the most signicant byte of that word. Hence, Wi :=B4i (256)3 +B4i+1 (256)2 +B4i+2(256)+B4i+3 i = 0, 1, . . . , l ; 1 : (6.2) In accordance with the notations above, the bits of a word W are denoted as W = (w0 w1 : : : w31 ) (6.3) where 31 X W = wi 231 i : (6.4) ;

;

;

i=0

A sequence of 8n bits x0 , . . . , xn 1 is interpreted as a number in the following way. First, these 8n bits are interpreted as a sequence of n bytes. These n bytes are interpreted as in (6.2), with the leftmost bytes the most signicant: 8X n 1 X := xi 28n i 1 : (6.5) ;

;

; ;

i=0

(The interpretation of a sequence of bits as a word is a special case of this.) Conversely, a number is written as an 8n-bit string according to this equation. In this chapter and in Chapter 7, words are denoted by uppercase letters and the bits of this word by the corresponding lowercase letter with indices as in Equation (6.3). Likewise, bytes are indicated by uppercase letters and the bits that constitute this byte by lowercase letters with indices as in Equation (6.1). The ordering of bytes in a word or number is given by Equation (6.2), respectively (6.5). Finally, some examples: the number 0xefcdab89 is represented by the 4 bytes B0 = 0xef = 239, B1 = 0xcd = 205, B2 = 0xab = 171, B3 = 0x89 = 137, or the 32-bit string 11101111 11001101 10101011 10001001. (Spaces not included.) Similarly, the number 581593088138417 = 0x210f4b16c1cb1 is represented by the 7 bytes B0 = 0x2 = 2, B1 = 0x10 = 16, B2 = 0xf4 = 244, B3 = 0xb1 = 177, B4 = 0x6c = 108, B5 = 0x1c = 28, B6 = 0xb1 = 177. That is, as the \byte-string" 02 10 f4 b1 6c 1c b1. This is the binary string 00000010 00010000 11110100 10110001 01101100 00011100 10110001.

The binary representation of the same number is

10 0001 0000 1111 0100 1011 0001 0110 1100 0001 1100 1011 0001:

36


6.3 De nitions and Basic Operations

6.3 Denitions and Basic Operations

A string is a sequence of bits.

For a string X the length of X is denoted as jX j. That is, jX j is the number of bits in the string X . If jX j = n, then X is said to be an n-bit string.

For an integer N , the length of N is dened as the length of the shortest binary representation of N . The length of N is denoted as jN j. Note that the same notation j j is used both for strings and numbers.

For a string X of length n > l, the rst l bits x0 , x1 , . . . , xl 1 of X are denoted by X l] .

For a string X of length n > l, the last l bits xn l , xn l+1 , . . . , xn 1 of X are denoted by X l].

For a string X the byte-length of X is denoted as jX j8 . That is, jX j8 is the number of bytes in the string X . If jX j8 = n, then X is said to be an n-byte string.

For an integer N , the byte-length of N is dened as the byte-length of the shortest binary representation of N . The byte-length of N is denoted as jN j8 . Note that the same notation j j8 is used both for strings and numbers.

For an integer N with jN j 8n we say that it is padded to 8n bits (or n bytes) if it is represented by a string of length n. This is done by prexing the binary representation with a sucient number of (leading) zeroes, and representing the result according to (6.5). Equivalently, one can say that the representation of N according to (6.5) is prepended by a sucient number of bytes 0x0. For example, the number 1234567890 has binary representation

;

;

;

;

100 1001 1001 0110 0000 0010 1101 0010 so it is represented by the 32-bit (4 byte) string 0100 1001 1001 0110 0000 0010 1101 0010.

1234567890 padded to 40 bits (5 bytes) is the string 0000 0000 0100 1001 1001 0110 0000 0010 1101 0010.

For the hash function, intermediate padding is sometimes used. That is, the computation of a hash value on (a b c) is sometimes performed as H(a 11 1 b c), where exactly enough bits \1" are inserted to get 37



a multiple of 512 bits. That is, \a 11 1" completely lls an integral number of blocks (as few as possible). This is denoted as H(a ? b c):

For example, if a is 20 bytes long, then \?" represents 44 bytes 0xff if a is 72 bytes long, \?" represents 56 bytes 0xff. The reason for this intermediate padding is implementation-driven: The hash function H needs complete 64-byte blocks the computation of H(a, b, c) therefore may require that all of a, b and c are simultaneously in memory the hash function itself will claim even more memory. If b and c involve computations requiring a lot of memory, this may necessitate writing a away to free some memory, and reading it back later to compute the hash value. The intermediate padding allows discarding of a after it hash been hashed only the intermediate result of the hash function needs to be stored during the computation of b and c.] Obviously, the padding is not stored in memory: if it is stated that x (a ? b c), and x is stored, then only a, b and c are stored. However, if x is involved in a hash, the padding is included. That is, H(w x y ? z ) expands to H(w a ? b c y ? z ). The absolute value of an integer N is denoted as abs(N ). That is, if N 0, abs(N ) := N ;N if N < 0. For two strings X = x0 x1 : : : xn 1 and Y = y0 y1 : : : ym 1 , the (n + m)-bit string W = X kY is dened as the concatenation of the strings X and Y . That is, ;

wi := xi wi+n := yi

;

i = 0, 1, . . . , n ; 1 i = 0, 1, . . . , m ; 1.

For two words X and Y , the words U = X Y , V = X ^Y and W = X _Y are dened as the bitwise XOR, AND and OR of X and Y , respectively. Hence, according to Equation (6.3):

ui := (xi + yi) mod 2 vi := xi yi (i = 0, 1, . . . , 31) : wi := (xi + yi ; xi yi) mod 2

For a word X , the word W = X is dened as the bitwise complement of X , hence W = X := X 0xffffffff or according to Equation (6.3):

wi := (xi + 1) mod 2 i = 0, 1, . . . , 31 : 38


6.3 De nitions and Basic Operations

For a word X and an integer 0 s < 32, the word W = X s is dened as the result of (cyclicly) rotating X over s bits to the left, hence

W = X s := (X 2s + (X div 232 s )) mod 232 : ;

For a nonnegative integer A and a positive integer B , the numbers A div B and A mod B are dened as the nonnegative integers Q, respectively R, such that A = QB + R and 0 R < B: That is, A mod B is the remainder, and A div B is the quotient of an integer division of A by B .

The notation \X Y (mod N )" (X is congruent to Y modulo N ) is used to indicate that X mod N = Y mod N .

The notation \X 6 Y (mod N )" (X is not congruent to Y modulo N ) is used to indicate that X mod N 6= Y mod N .

For two nonzero integers X and Y we say that X divides Y if Y mod X = 0. That is, if Y is a multiple of X .

For two nonnegative integers X and Y , not both zero, the greatest common divisor gcd(X Y ) is dened as the greatest positive integer that divides both X and Y .

A prime is an integer greater than 1 that is divisible only by 1 and by itself.

For any integer N , the set of nonnegative integers smaller than N is denoted ZZN .

For any integer N , the sum of two integers a and b modulo N is a + b mod N their product modulo N is a b mod N . Note that when several operations modulo N are performed, we may perform the operations as usual without reductions modulo N , and reduce the result modulo N only at the end, or more often at convenience. For example, (a + (b c mod N )) mod N = (a + bc) mod N: This fact will be used to keep notation clear. It is left to the implementor to decide which intermediate results are reduced modulo N . (It will in general be faster to reduce as often as possible i.e., abc mod N is computed as (ab mod N )c mod N .) For the result of a computation modulo N , in general jN j bits are required, as it is in the range 0 through N ; 1 (inclusive).

For any prime p, the set of positive integers smaller than p is denoted ZZp.

39


For any prime p, the inverse modulo p of a nonzero integer a is the unique number in ZZp, denoted as a 1 that satises a a 1 1 (mod p). That is, the product modulo p of a and its inverse modulo p is 1. (For non-prime p an integer a such that gcd(a p) 6= 1 has no inverse so this `property' depends on the primality of p.)


;

Exponentiation modulo a prime p obeys the usual rules: for any pair of integers n and m and for any integer a, it holds that an+m an am (mod p) and (an )m anm (mod p). In particular, 8 n copies > > z }| { > > > a a a mod p if n 0, < an mod p := > > abs(n) copies > > { > : z 1 }|1 1 a a a mod p if n < 0. ;

;

;

;

For an integer a and a prime p, the order of a modulo p is the smallest nonnegative integer n such that an 1 (mod p). This order always divides p ; 1. Consequently, it always holds that ap 1 1 (mod p), and ap 2 a 1 (mod p). If the order of an integer a modulo p is prime, we often say that a is a generator . ;

;

;

For a generator g of order q modulo p and an integer a of the unique subgroup of ZZp of order q, the discrete logarithm of a to the base g, denoted as logg a, is an integer x such that gx a (mod p).

A composite is an integer greater than 1 that is not a prime. A composite can uniquely be written as the product of at least two (not necessarily dierent) primes.

A Blum integer is a composite that is the product of exactly two prime factors p and q, with p q 3 (mod 4).

Let D1 and D2 be two nonnegative 16-bit sequence numbers (i.e., 0 D1 D2 < 216 ) that are initialized to zero, and that are regularly incremented by 1. Let V be another nonnegative 16-bit sequence number with a value that both D1 and D2 had less than 216 increments before their current value. Remark that all of D1 D2 V are allowed to wrap, i.e., the value following 216 ; 1 = 65535 is 0. Dene the operation D1 < D2 (mod 216 ) as (D1 ; V ) mod 216 < (D2 ; V ) mod 216 and similarly for > .

For mathematical background we refer to Kob87] for implementation of modular arithmetic and computations with large numbers see Knu81]. 40

6.4 Symbols


6.4 Symbols The following symbols and naming conventions for system parameters and keys are used throughout this document. For a thorough description of all system parameters and keys we refer to Part VI. For a complete list of symbols we refer to Appendix A for the and + systems, and to Appendix B for the ; system.

6.4.1 System Parameters The CAFE system uses the following set of system parameters:

A prime p

A prime q that divides p ; 1

A generator g of order q modulo p

A dierent generator h of order q modulo p

A dierent generator Gc of order q modulo p

A modulus Nphone , the product of two primes

The relative discrete logs of the three generators logg h, logg Gc, and logh Gc should be unknown to the users. (Note that logh Gc = (logg h) 1 logg Gc mod q.) The factorization of Nphone must be kept secret. ;

6.4.2 Keys All secret keys have the form s or S , where ` ' is some index (if possible indicating its purpose). The corresponding public keys have the form p := G s mod p, p := G S mod p, or P := G S mod p, where G is one of fg Gc gc g, which are all generators of order q modulo p. The former two are system parameters, and the latter is dierent for each user. The most important secret keys and corresponding public keys are listed below:

the bank's key set for authentication purposes (Sa Pa := gSa mod p),

the bank's key set for issuing cheques (Sc Pc := GSc c mod p),

the wallet's or ; observer's key set (ss ps := gss mod p). In all but one case it is clear from the context whether or ; keys are meant. In the transfer protocol both and ; keys are involved, and to avoid confusion the ; observer keys are called (so po ) in that protocol. a shared public key between bank and wallet pc := gcSc mod p, where gc := psh mod p = gss h mod p is a generator of order q modulo p containing the identity of the wallet (i.e., its secret key ss). 41



A cheque in the CAFE system can be seen as a set of secret keys and corresponding public keys, that are used to sign the payment specication. A signature by the bank on the public keys of a cheque guarantees its validity. The keys corresponding to a cheque are denoted by lowercase Greek letters for example, the secret keys are denoted and the public keys are .

6.5 Stable Storage and Atomic Actions In the CAFE protocols two assumptions on the nature of actions and variables involved are made. It is possible to have stable storage . That is, even when a protocol is interrupted, the variables in stable storage retain their values. The implementation is up to the implementors. An action enclosed in a box is to be performed atomically. That is, execution of such an action will result in either the old state, or the new state, irrespective of failures, interruption etc. Of course, it would be nice if all parts of a protocol were implemented as an atomic action, but this is not possible in practise, and instead this ideal situation is approximated by implementing critical parts as atomic actions. Again, the implementation of this is up to the implementors. (Note that atomic actions imply usage of stable storage for the variables used.)

42


Chapter 7

The Basic Cryptographic Primitives The protocols of the CAFE system are built from a set of basic cryptographic primitives. This set contains the following items: the Schnorr's identication protocol and the derived signature scheme, the basic proof system, the restrictive blind signature scheme, the van Heyst-Pedersen fail-stop signature scheme, the randomized signature scheme, the RSA signature scheme, the one-way function used in tick payments, the pseudo-random number generator, the hash function. We briey describe each of these primitives.

7.1 The Schnorr Scheme Most protocols are derived from Schnorr's identication protocol Sch91], depicted in Figure 7.1. This protocol allows a prover to prove his identity to a verier it has the following form. The prover picks a commitment at random, and from it he forms an initial witness , which is sent to the verier. The verier returns a (randomly picked) challenge . The prover then computes a response , and sends it back. The verier computes a nal witness from this response, the challenge and the prover's public key, and veries if it equals the initial witness. The notation used is from GUQ92]. From this identication protocol, a signature scheme can be constructed by replacing the challenge by a hash value of the initial witness and the message to be signed, see Figure 7.2. So, the same identiers and corresponding notation of the identication protocol can still be used. The signature consists of the response and the challenge, which is now called initial challenge. The verier constructs the nal witness as in the identication protocol, so that the nal challenge can be computed (apply the hash function to the nal witness and the message) and compared to the initial challenge. 43

Chapter 7: The Basic Cryptographic Primitives


Prover

Veri er

(S P := gS ) Commitment: w2R ZZq Initial witness: a gw mod p Response: r w ; Sc mod q

(P )

a

;;;;;;;;;;; ! ;

c

;;;;;;;;;;;;

r

;;;;;;;;;;; ! ;

Challenge: c2R ZZq

Final witness: a0 gr P c mod p ? Veri cation: a a0 (mod p)

Figure 7.1: Schnorr's identi cation protocol. The public key is P :=gS mod p, where S is the secret key. Signer

Veri er

(S P := gS ) m `message' Commitment: w2R ZZq Initial witness: a gw mod p Initial challenge: c H(m a) Response: r w ; Sc mod q

(P )

m c r

;;;;;;;;;;; ! ;

Final witness: a0 gr P c mod p Final challenge: c0 H(m a0 ) Veri cation: c =? c0

Figure 7.2: Schnorr's signature protocol. The public key is P := gS mod p, where S is the secret key.

7.2 The Basic Proof System The basic proof system is derived from Schnorr's identication protocol CP93b]. The basic proof system works for the unique subgroup of ZZp of order q, denoted as Gq . It allows the signer, with key pair (S P := gS mod p), to interactively sign a message m 2 Gq . The signature on m consists of z := mS mod p and a proof that logg P = logm z . Given m and z , the basic proof system is depicted in Figure 7.3. Let H() be a one-way hash function as in the Fiat-Shamir scheme FS87]. The random challenge c can then be replaced by c H(m z a b), and the signature on m is (z c r). It is correct if

c = H(m z gr P c mod p mr z c mod p): 44

7.3 The Restrictive Blind Signature Scheme


Signer

Verier

(S P := gS )

(P )

w2R ZZq a gw mod p b mw mod p

a b

; ;;;;;;;;;! ; ;

r w ; cS mod q

c

c2RZZq

; ;;;;;;;;;; ;

r

; ;;;;;;;;;! ; ;

a =? gr P c mod p b =? mr zc mod p

Figure 7.3: The basic proof system. It is the starting point from which the blind signature scheme is designed.

7.3 The Restrictive Blind Signature Scheme The blind signature scheme allows the verier to obtain a valid signature (z c r) on the message m, such that the signer can see neither the message nor its signature. Later on, the signer is unable to link a message-signature pair to the particular instance of the signing protocol which generated this pair. However, the blind signature scheme guarantees to the signer that the pair (m z ) is derived, by the verier using a limited set of blinding operations, from the pair (m0 z0 := m0 S ) known to both the signer and verier. In fact, the verier can obtain a blind signature only on a message m that is a random power of m0 . Given (m0 z0 ) the blind signature protocol is depicted in Figure 7.4. In order to achieve unlinkability, the verier in the basic proof system computes the message m, to be signed in a blinded way, as a random power of the message m0 and also computes blinded numbers a b z from a0 b0 z0 . The verier sends a blinded version c0 of the challenge c H(m z a b) to the verier and modies the response r0 , such that the new response r fullls the requirement that (z c r) is a valid signature on m.

7.4 The van Heyst-Pedersen Scheme The van Heyst-Pedersen signature scheme HP93] is an ecient fail-stop signature scheme based on the discrete logarithm assumption. Such a signature scheme provides enhanced security against forgeries by a very powerful adversary. In case a signature is forged, the presumed signer can prove that the signature is a forgery: he can prove that the underlying assumption of the system is broken. The signing and verication process of the van Heyst-Pedersen 45



Signer

w0 2R ZZq a0 gw0 b0 mw0 0

Verier

(S P := gS )

t u v2R ZZq a0 b0

; ;;;;;;;;;! ; ;

r0 w0 ; c0 S mod q

c0

(P )

m m0 t z z0 t a a0 gv P u mod p b (b0 mv0 z0u )t mod p c H(m z a b) c0 c ; u mod q

; ;;;;;;;;;; ;

r0

; ;;;;;;;;;! ; ;

r r0 + v mod q a =? gr P c mod p b =? mr zc mod p

Figure 7.4: The restrictive blind signature scheme

scheme is shown in Figure 7.5. The signature on a message m 2 ZZq with respect to the public key (a b) is the tuple (r1 r2 ). The proof of forgery is logg h: if the presumed signer receives a valid, forged signature (r1 r2 ) 6= (r1 r2 ) on m with respect to the given public key (a b), then he can compute logg h, which is presumed to be unknown to both signer and verier (see Section 6.4.1). Remark that the scheme is a one-time scheme: the signer's secret key (w1 w2 x1 x2 ) can easily be computed if two dierent messages are signed using the same secret key.

0

0

7.5 The Randomized Schnorr Signature Whenever the ; observer and the bank exchange a signed message, the ; purse must randomize the signature in order to prevent that bank and observer send information to each other (i.e., to prevent inow/outow) through the signature. It is assumed that the message to be signed is of the standard form. A randomized signature on such a message, m, with respect to the public key P := gS mod p works as in Figure 7.6. 46

7.6 The RSA Signature Scheme


Signer

Verier

w1 w2 x1 x2 2R ZZq a gw1 hw2 mod p b gx1 hx2 mod p r1 w1 ; x1 m mod q r2 w2 ; x2 m mod q

a b r1 r2

; ;;;;;;;;;! ; ;

ab

? r1 r2 m g h

;

(mod p)

Figure 7.5: The van Heyst-Pedersen fail-stop signature scheme. Signer

Randomizer

(S P := gS ) (P ) w 2R ZZq a a gw mod p ;;;;;;; ! ; ? u u 6= 0 mod q ;;;;;;;;u 2R ZZq w wu mod q a au mod p a au mod p c H(m a ) r w ; cS mod q m r ;;;;;;; ! ; c H(m a ) a =? gr P c mod p

Veri er

(P )

m c r

;;;;;;; ! ;

a gr P c mod p c =? H(m a )

Figure 7.6: The randomized Schnorr signature

7.6 The RSA Signature Scheme The number n is dened as the product of two large primes p and q and is called the modulus. Let (p ; 1)(q ; 1) : (n) := lcm(p ; 1 q ; 1) = gcd( p ; 1 q ; 1) The public exponent e is chosen such that gcd(e (n)) = 1 : The secret exponent d is dened to be the smallest non-negative integer satisfying ed mod (n) = 1 : 47



The public and secret keys are dened as: Public key P : n = pq and e. Secret key S : n, d, and optionally p q . The operations with the public and secret key can take any number m as input, that satises 0 m < n. They produce as output a number in the same range. The public key operation is dened as:

P (m) := me mod n and the secret key operation is dened by:

S (m) := md mod n : It is shown in RSA78] that P () and S () are inverses of each other, i.e.,

P (S (m)) = S (P (m)) = m for all m in the range.

7.7 The One-way Function Encoding Phone Ticks Let Nphone be the product of two primes p and q. The function

f : ZZNphone ! ZZNphone : x 7! x2 mod Nphone is used to encode the amounts paid in phone ticks.

7.8 The Pseudo Random Number Generator The pseudo random sequence generator (PRSG) generates a sequence of bits from a string called the seed . Repeated use of the same seed will reproduce the same sequence. Without knowledge of the seed, the sequence is unpredictable (for the one described below this holds under the assumption that factoring large numbers is hard). The PRSG used for the protocols is from ACGS88] it is described in detail below. Subsequently, it is described how one can construct pseudorandom numbers from the pseudorandom sequence produced by the PRSG.

7.8.1 The Pseudo Random Sequence Generation

Let N be a Blum integer, and let k be a positive integer smaller than jN j. (Typical practical sizes are jN j = 512 and k = 176.) The PRSG uses a function f that maps strings of length (at most) jN j to nonnegative numbers smaller than N . For any string X of length (at most) jN j, the number f (X ) is computed as follows. First, interpret X as an integer (see above). Square this integer modulo N . That is, f (X ) := X 2 mod N . 48

7.8 The Pseudo Random Number Generator


Given a seed S , jS j jN j, the PRSG generates the following sequence fRi j i = 0 1 : : : g of k -bit numbers.

R0 := f (S ) mod 2k R1 := f (f (S )) mod 2k R2 := f (f (f (S ))) mod 2k .. .. .. . . . i +1 Ri := f (S ) mod 2k .. .. .. . . .

where f i (S ) denotes the result of ii+1times applying f to S . That is, Ri is equal to the k least signicant bits of S 2 mod N . This random generator produces a sequence of k-bit pseudorandom chunks. These chunks can be used in two ways: directly, to get a pseudorandom sequence of bits, and indirectly, to get a pseudorandom number. The latter case has two instances: generation of random numbers in ZZq and in ZZNphone .

Generation of n-bit strings for any n > 0. Let t n div k and r

n mod k. Then, given a seed S , the numbers R0 , R1 , . . . , are computed as above, and each interpreted as k-bit strings. If r 6= 0 then the required n-bit

string equals

PRSG(n) := (Rt mod 2r )kRt 1 k kR1 kR0 if r = 0, this amounts to ;

PRSG(n) := Rt 1 k kR1 kR0 : That is, when the output is interpreted as an integer, then R0 is the least signicant part, and the most signicant part consists of the r = n mod k least signicant bits of Rt (if any), followed by Rt 1 . A subsequent call of the PRSG will have seed f t+1 (S ) if r 6= 0 and seed t f (S ) if r = 0. Thus, the rst subsequent bits are the least signicant bits of Rt+1 = f t+2 (S ) mod 2k if r 6= 0 the rst subsequent bits are the least signicant bits of Rt = f t+1 (S ) mod 2k if r = 0. (If r 6= 0, then the unused bits of Rt = f t+1 (S ) mod 2k , are discarded.) An example of pseudorandom bit-strings is the generation of 32 random bits by the POS in payment this is denoted as `2R ZZ232 (see Fig. 8.8). It can (for example) be implemented as an assignment ` PRSG(32)'. ;

;

Generation of numbers in ZZq . This is done as follows. Let l be a (small)

nonnegative integer the larger l, the more accurate is the random distribution of the nal choice. A random choice from ZZq is made by reducing PRSG(jqj + l) modulo q. The assignment of this value to a variable w is denoted as \w2R ZZq ". That is, w PRSG(jqj + l) mod q. Note that in general a random choice w2R ZZq is jqj bits long. There is a (negligible) probability (of 1=q) that a random number

49



generated this way equals 0, which is not a member of ZZq . One caters for this possibility by checking for its occurrence, and returning `1' instead of `0'. Remark that the choice k = jqj + l ensures that one call to the PRSG yields exactly enough bits for one random number in ZZq .

Generation of numbers in ZZNphone . This is done as follows. A random choice PRSG(jNphone j + l) is reduced modulo Nphone . The assignment of this value to a variable is denoted as \ 2R ZZNphone ". That is, PRSG(jNphone j + l) mod Nphone .

7.8.2 The Pseudo Random Number Sequences

The random number generator described above is implemented in the wallet, ; observer, and ; purse as follows. Each entity uses two dierent sequences: one for cheques, and one for all other purposes. (The reason for this is cryptographic separation of the user's security and privacy. This is necessary because in case of recovery of a lost or malfunctioning user device, the user has to reveal part of the pseudorandom sequence used. By this separation, this hurts at most his privacy, not his security.) Each of the sequences will use its own seed both use the same modulus NS . The sequence used for signing cheques is called cheque-sequence and uses seed S . The other sequence is called \sequence 2" and uses seed S2. Random number generation is indicated by \2R ZZq " in the gures. No distinction between to two sequences is made in the pictures, as the rule used to decide which sequence to use is obvious: the one is used for cheques, the other for all other purposes. (Note that for the bank's and till's generator the same symbolism is used these generators need not be implemented in the same way, however.)

The cheque-sequence The cheque-sequence is divided in blocks, each consisting of enough pseudorandom bits to produce one cheque (see gen cheque, Sections 8.6 and 9.6). An index indicates which block is currently in use. The stable variable dist holds the index of the cheque most recently withdrawn. This variable is updated whenever a cheque generation starts. This update must happen atomically to make sure that no block is used twice. Each block consists of k random numbers in ZZq . For the -system k equals 7. E.g., 11 is generated from the rst part of the block, 3 from the last part of the block, see -gen cheque. For the ;-system k equals 5 and 6 for respectively the observer and the purse. For compatibility with the -system it may however be convenient to also let the observer generate 7 random numbers, and discard the two numbers that are not needed. This is why it is assumed in the sequel that the observer needs 7 random numbers for a cheque. The rst such block generated has index 1 the seed used for the generation of this block is S . So the seed for the block with index D is S 2k(D;1) mod NS

50

7.8 The Pseudo Random Number Generator


before starting the generation of the block.kD;Furthermore, the modulus is NS . k 2kD;k+1 kD;1 2 2 The k numbers generated use the seeds S ,S , ..., S mod NS . That is, the wallet and ; observer assign to 11 the value f (S 27D;7 mod NS7)D mod q = (S 27D;6 mod NS ) mod q similarly, 3 is assigned the value (S 2 mod NS ) mod q, where stands for either or ; variables. For the ; purse k equals 6, and hence 11 is assigned the value f (Sp26D;6 mod NSp ) mod q = (Sp26D;5 mod NSp ) mod q similarly, v is assigned the value (S 26D mod NSp ) mod q. It must be guaranteed that no part of a block is used twice how this is guaranteed is an implementation issue. (Interruption is not an issue here, since following an interruption, a subsequent block will be used, not the block that was in use when the interruption occurred.) Finally, note that storage of some intermediate value S 2k(V ;1) mod NS together with the corresponding index value V , rather than using S , k(saves a 2 D;1) = lot kof(V ;computation: the initial seed for the block with index D is S (S 2 1) )2k(D;V ) . This is also necessary to deal with overow of the index D, as explained below.

0

Sequence 2 Sequence 2 uses a similar mechanism with block size 1. The random number generator call for this sequence will therefore do:

Atomically increment dist 2

Call the PRSG once using dist 2 , S2 and NS . Since the initial seed again has index 1, the seed with index dist 2 is S22dist 2 ;1 mod NS . The modulus is NS .

If some intermediate seed S2 (V ) = S22V ;1 mod NS and the corresponding index value V are stored, the seed used can be computed as (S22V ;1 )2dist 2 ;V mod NS . This is also necessary to deal with overow of the index dist2 , i.e., S2 (V ) must be updated at least once every 216 updates of dist2 , to avoid regeneration of the pseudo random sequence after dist2 has wrapped.

Overow of block indices To deal with overow, all block indices in the user's device (dist , min dist , max dist , dist 2 , see Sections 8.4 and 9.4) are allowed to wrap around. This poses no problem in the user's device, as the seed for the block with index D is not calculated from the initial seed S ork(SV 2;,1)but from some intermediate value V ;1 2 2 with index V , respectively S (V ) = S and S2 (V ) = S2 . The seed for the block with index D is then calculated as S (V )2k(D;V ) and S2 (V )2D;V , respectively. Therefore, in the user's device only the relative distance between the block index D and the seed index V is important, not the absolute values of V and D. These relative distances will always be smaller than 216 , which allows for 51



their wrapping around. Whenever two indices are compared with one another, instead of using one of f g, one of the operations f< (mod 216 ) (mod 216 ) > (mod 216 ) (mod 216 )g is used as dened in Section 6.3, p. 40. For the same reason the values of min dist , dist , and max dist stored in the snapshot at the bank are not the block indices' actual values, but their residues modulo 216 . However, to allow for a correct recovery of the user's device the absolute distance of the oldest unspent cheque at the last withdrawal is needed. This absolute distance is equal to the number of times min dist wrapped around times 216 plus the value of min dist as stored in the snapshot at the bank. Therefore, the bank must also keep track of how many times min dist wrapped around. To this end the variable nr wrap is present in the user's snapshot at the bank (see Sections 8.4 and 9.4). It is initialized on zero, and it is incremented each time the newly received value of min dist is smaller than the value stored in the snapshot, for then min dist wrapped around. In recovery (see Sections 8.15 and 9.14) the wallet or ; observer calculate the seed corresponding to the oldest unspent cheque at the last withdrawal as 7(216 nr wrap +min dist ;1) 2 S mod NS .

7.9 The Hash Function This section describes the hash function H used in the and ; systems. It is based on RIPEMD with a dierent nal expansion of the message, and with an expansion of the nal hash-value to 5 words (160 bits). This section is structured as follows. First, the representation of numbers, specic to this section, is given. Next, all functions used in RIPEMD are introduced. Finally, H itself is described.

7.9.1 Representation of Numbers

Important note: the representation of numbers dened below is used in this

section only. It is dierent from the notation used elsewhere! Specically, the order of bytes in the representation of a number is dierent: a 32-bit word has the bytes in order least signicant to most signicant, in contrast to the rest of this specication. For the sake of clarity, also those parts that are identical to the representation of numbers in the rest of this document are repeated below. In this section a byte is dened as an 8-bit quantity and a word as a 32-bit quantity. A byte is considered to be a nonnegative integer. That is, it can take on the values 0 through 28 ; 1 = 255. Likewise, a word is considered to be a nonnegative integer, hence it takes on the values 0 through 232 ; 1 = 4294967295. The value of a word can be given in decimal as well as in hexadecimal form. In the latter case the number is written as `0x' followed immediately by at most 8 hexadecimal digits, the most signicant one rst. For example, the hexadecimal representation of the 32-bit number 4023233417 is 0xefcdab89. 52

7.9 The Hash Function


A sequence of 8n bits b0 , b1 , . . . , b8n 1 is interpreted as a sequence of n bytes in the following way. Each group of 8 consecutive bits is considered as a byte, the rst bit of such a group being the most signicant bit of that byte. Hence, Bi := b8i 27 + b8i+126 + + b8i+7 i = 0, 1, . . . , n ; 1. (7.1) A sequence of 4l bytes B0 , B1 , . . . , B4l 1 is interpreted as a sequence of words W0 , W1 , . . . , Wl 1 in the following way. Each group of 4 consecutive bytes is considered as a word, the rst byte of such a word being the least signicant byte of that word (!). Hence, Wi := B4i+3 (256)3 + B4i+2 (256)2 + B4i+1(256)+ B4i i = 0, 1, . . . , l ; 1. (7.2) Notice the dierence in convention between the notations (7.1) and (7.2). In accordance with the notations above, the bits of a word W are denoted as W = (w0 w1 : : : w31 ) (7.3) where 3 X 7 X W= w8i+j 28i+(7 j) : (7.4) ;

;

;

;

i=0 j =0

In this section words are always denoted by uppercase letters and the bits of this word by the corresponding lowercase letter with indices as in Equation (7.3). Likewise, bytes are indicated by uppercase letters and the bits that constitute this byte by lowercase letters with indices as in Equation (7.1). The ordering of bytes in a word is given by Equation (7.2).

7.9.2 Functions and Operations used in the Hash Function H

RIPEMD uses three basic functions that each map three words onto a word.

These functions are dened as follows. F (X Y Z ) := (X ^ Y ) _ (X ^ Z ) (7.5) G(X Y Z ) := (X ^ Y ) _ (X ^ Z ) _ (Y ^ Z ) (7.6) H (X Y Z ) := X Y Z (7.7) For each bit of X , the function F selects a bit of either Y or Z , depending on the bit of X : if the bit xi is 1, then the corresponding bit yi is selected, else zi is selected (i = 0, 1, . . . , 31). The function G is the bitwise majority of the bits of X , Y and Z : if two or three of the bits xi , yi and zi are 1, then the corresponding bit gi of G(X Y Z ) is 1, else gi = 0. The function H is the bitwise parity (or XOR) of X , Y and Z : a bit hi of H = H (X Y Z ) is 1 if an odd number of the bits xi, yi and zi is 1, else hi = 0. Those three functions are used in six other (higher level) operations. These are used to process a message consisting of 16 words X0 , X1 , . . . , X15 . For words A, B , C and D, and integers 0 k < 16 and 0 s < 32 these operations are dened as follows. 53



FF (A B C D Xk s) denotes the operation A ((A + F (B C D) + Xk ) mod 232 ) s :

GG(A B C D Xk s) denotes the operation A ((A + G(B C D) + Xk + 0x5a827999) mod 232 ) s :

(7.11)

GGG(A B C D Xk s) denotes the operation A ((A + G(B C D) + Xk ) mod 232 ) s :

(7.10)

FFF (A B C D Xk s) denotes the operation A ((A + F (B C D) + Xk + 0x50a28be6) mod 232 ) s :

(7.9)

HH (A B C D Xk s) denotes the operation A ((A + H (B C D) + Xk + 0x6ed9eba1) mod 232 ) s :

(7.8)

(7.12)

HHH (A B C D Xk s) denotes the operation A ((A + H (B C D) + Xk + 0x5c4dd124) mod 232 ) s :

(7.13)

That is, all six functions add the result of an application of F , G or H to (B C D), a message word Xk and possibly a constant to A and rotate the result over s positions to the left. The four constants used are not randomly chosen they p in these p operations p p are the integer part of 230 2, 230 3, 230 3 2 respectively 230 3 3. However, there is no specic reason for this choice.

7.9.3 The Hash Function H

This section describes the hash function H. It is based on the hash function RIPEMD, described in the RIPE report BBB+ 95]. RIPEMD is a hash function that compresses messages of arbitrary length to a 128-bit hash value or hashcode of the message. It is conjectured that it is computationally infeasible to produce two messages having the same hashcode, or to produce any messages having a given pre-specied target hashcode. RIPEMD is an extension of the MD4 message-digest algorithm Riv92a]: it has the same structure, but its compression function consists of two parallel copies of MD4's compression function, identical but for some internal constants. The results of both copies are combined to yield the output of RIPEMD's compression function. The reason for this more complicated design lies in the fact that successful attacks existed on two round versions of MD4 BB91, Mer90]. Because of these attacks, the designers of MD4 proposed a modied version, which is called MD5 Riv92b]. However, there are indications that this redesign 54



has introduced new weaknesses in the algorithm BB93]. The RIPEMD extension of MD4 is from Boe92]. Recent work by Dobbertin Dob97] has found collisions in two round versions of RIPEMD. The design of the RIPEMD algorithm is such that it is very suitable for software implementation on 32-bit machines. Since no substitution tables are used, the algorithm can be coded quite compactly. The basis of the hash function H is identical to RIPEMD, except for the expansion of the message. Furthermore, the nal output is 160 (5 words) long. The rst four of those are the output of RIPEMD with the changed padding, and one extra word is appended.

Global Structure of H

is a hash function that maps a message M consisting of an arbitrary number of bits onto a 160-bit block H(M ). The basis of H is the compression function compress. This function compresses a 20-word input to a 4-word output. This function is used in the following way. First, the message is expanded to an appropriate length and represented by a sequence of words. Then, starting with a 4-word initial vector , the resulting sequence of words is compressed by repeatedly appending sixteen message words and compressing the resulting twenty words to four words by applying compress until the message is exhausted. Thus, a 4-word result can be obtained. Below, this is explained in detail. H

Outline of compress

The compression function compress accepts an input consisting of four words A, B , C , D and sixteen message words X0 , X1, : : :, X15 . It produces four output words denoted as: compress((A B C D) (X0 X1 : : : X15 )) :

(7.14)

The function compress consists of two separate halves, followed by a nal step combining the results of both halves into four words. Each of the halves can be decomposed into three rounds. Each of these rounds consists of sixteen steps. These steps, nally, consist of the application of one of the six operations FF , GG, HH , FFF , GGG and HHH a dierent operation for each round. See also Figure 7.7. In other words: the input is passed to both halves. Both halves then independently transform, in three rounds of sixteen steps each, a copy of the 4-tuple (A B C D). In a nal step, the results of both independent transformations are combined into the result of compress.

Outline of H

Let M = (m0 m1 : : : mn 1 ) be a message consisting of n bits. The hashcode H(M ) of M is computed as follows, see also Figure 7.8. ;

55



ABCD ?

?

-

-

?

-

?

X0 X. 1 ..

.. . X15 X7 X. 4 .. .. . X8 X3 X.10 .. .. . X12

???? - rst round 16 - applic. of FF -

X0 X. 1 ..

.. . X15 ???? X7 X second ... 4 round

16 applic. GG -

of

.. . X8 ???? X3 X.10 third .. round

16 applic. HH -

of

.. . X12

-

???? - rst round 16 - applic. of FFF ???? second round 16 applic. of GGG ???? third round 16 applic. of HHH -

???? ???? - - - - ? ? ? ?

?

?

?

?

????

compress((A B C D) (X0 X1 : : : X15 )) Figure 7.7: Outline of the compression function compress. The input to the right half is identical to that in the left half, only the constants used are dierent. The symbol + denotes addition modulo 232 .

56



(A0 B0 C0 D0 ) ?

compress

.. .

?

compress

.. .

X0 X1 .. . X15 X16 X17 .. .

X31

X16N ;16 X16N ;15

rst message block

second message block

q q q q

?

?

compress

.. .

.. .

N th message block

X16N ;1

?

H(M )

Figure 7.8: Outline of H. The message M is expanded rst to X which is a multiple of 16 words long. Then X is processed as in this picture. The nal result is H(M ).

57



expansion: M is expanded to a message X consisting of 16N words X0 , X1 , n e := ((n ; 1) div 512) + 1. That is, the . . . , X16N 1 , where N = d 512 message is expanded such that it becomes a multiple of 512 bits long. This expansion is not done if the message M already is a multiple of 512 bits long. In RIPEMD it is done even then.] compression: The resulting message X is compressed as follows using the function compress. Dene the words A0 , B0 , C0 , D0 as ;

A0 := 0x67452301 B0 := 0xefcdab89 C0 := 0x98badcfe D0 := 0x10325476 For i = 0 1 : : : N ; 1, the words Ai+1 , Bi+1 , Ci+1 and Di+1 are computed as follows from the words Ai , Bi , Ci and Di and sixteen message words X16i+j , j = 0, 1, . . . , 15: (Ai+1 Bi+1 Ci+1 Di+1 ) compress((Ai Bi Ci Di ) (X16i X16i+1 : : : X16i+15 )) That is, each 16-word message block is used to transform (Ai Bi Ci Di ) into (Ai+1 Bi+1 Ci+1 Di+1 ) for the current value of i. hashcode: The hashcode H(M ) is the concatenation of the four 32-bit strings corresponding to the four words AN , BN , CN and DN , and a fth word EN computed from those four words: H(M ) := AN k BN k CN k DN k EN :

These steps are given in detail in the rest of this section.

Expanding the Message

Let N = ((n ; 1) div 512) + 1. The n-bit message M = (m0 m1 : : : mn 1 ) is expanded to the 16N -word message X = (X0 X1 : : : X16N 1 ) by appending 512N ; n bits with value 1: ;

;

mn := mn+1 := := m512N 1 := 1: ;

That is, append bits \1" until the expanded message is a multiple of 512 bits.

The Compression Function compress

For the 4-word number (A B C D) and the 16-word message X0 , X1 , : : :, X15 , the 4-word function value compress((A B C D) (X0 X1 : : : X15 ))

58

(7.15)



is computed in two parallel sets of three rounds, each round consisting of 16 applications of one of the auxiliary operations dened by Equations (7.8){(7.13). First, two copies of (A B C D) are made. Next, both halves independently transform those copies in three rounds of sixteen applications of one of the operations FF through HHH . Finally, the results of both halves and the initial values of A, B , C and D are combined into one 4-word output, here denoted as (AA BB CC DD). In pseudocode: /* copy (A B C D) for both halves */ aa A bb B cc C dd D aaa A bbb B ccc C ddd D /* Round 1 for both parallel halves */ FF (aa bb cc dd X0 11) FFF (aaa bbb ccc ddd X0 11) FF (dd aa bb cc X1 14) FFF (ddd aaa bbb ccc X1 14) FF (cc dd aa bb X2 15) FFF (ccc ddd aaa bbb X2 15) FF (bb cc dd aa X3 12) FFF (bbb ccc ddd aaa X3 12) FF (aa bb cc dd X4 5) FFF (aaa bbb ccc ddd X4 5) FF (dd aa bb cc X5 8) FFF (ddd aaa bbb ccc X5 8) FF (cc dd aa bb X6 7) FFF (ccc ddd aaa bbb X6 7) FF (bb cc dd aa X7 9) FFF (bbb ccc ddd aaa X7 9) FF (aa bb cc dd X8 11) FFF (aaa bbb ccc ddd X8 11) FF (dd aa bb cc X9 13) FFF (ddd aaa bbb ccc X9 13) FF (cc dd aa bb X10 14) FFF (ccc ddd aaa bbb X10 14) FF (bb cc dd aa X11 15) FFF (bbb ccc ddd aaa X11 15) FF (aa bb cc dd X12 6) FFF (aaa bbb ccc ddd X12 6) FF (dd aa bb cc X13 7) FFF (ddd aaa bbb ccc X13 7) FF (cc dd aa bb X14 9) FFF (ccc ddd aaa bbb X14 9) FF (bb cc dd aa X15 8) FFF (bbb ccc ddd aaa X15 8) /* Round 2 for both parallel halves */ GG(aa bb cc dd X7 7) GGG(aaa bbb ccc ddd X7 7) GG(dd aa bb cc X4 6) GGG(ddd aaa bbb ccc X4 6) GG(cc dd aa bb X13 8) GGG(ccc ddd aaa bbb X13 8) GG(bb cc dd aa X1 13) GGG(bbb ccc ddd aaa X1 13) GG(aa bb cc dd X10 11) GGG(aaa bbb ccc ddd X10 11) GG(dd aa bb cc X6 9) GGG(ddd aaa bbb ccc X6 9) GG(cc dd aa bb X15 7) GGG(ccc ddd aaa bbb X15 7) GG(bb cc dd aa X3 15) GGG(bbb ccc ddd aaa X3 15) GG(aa bb cc dd X12 7) GGG(aaa bbb ccc ddd X12 7) GG(dd aa bb cc X0 12) GGG(ddd aaa bbb ccc X0 12) GG(cc dd aa bb X9 15) GGG(ccc ddd aaa bbb X9 15) GG(bb cc dd aa X5 9) GGG(bbb ccc ddd aaa X5 9) GG(aa bb cc dd X14 7) GGG(aaa bbb ccc ddd X14 7) GG(dd aa bb cc X2 11) GGG(ddd aaa bbb ccc X2 11) GG(cc dd aa bb X11 13) GGG(ccc ddd aaa bbb X11 13) GG(bb cc dd aa X8 12) GGG(bbb ccc ddd aaa X8 12) /* Round 3 for both parallel halves */ HH (aa bb cc dd X3 11) HHH (aaa bbb ccc ddd X3 11) HH (dd aa bb cc X10 13) HHH (ddd aaa bbb ccc X10 13) HH (cc dd aa bb X2 14) HHH (ccc ddd aaa bbb X2 14)

59

Chapter 7: The Basic Cryptographic Primitives HH (bb cc dd aa X4 7) HH (aa bb cc dd X9 14) HH (dd aa bb cc X15 9) HH (cc dd aa bb X8 13) HH (bb cc dd aa X1 15) HH (aa bb cc dd X14 6) HH (dd aa bb cc X7 8) HH (cc dd aa bb X0 13) HH (bb cc dd aa X6 6) HH (aa bb cc dd X11 12) HH (dd aa bb cc X13 5) HH (cc dd aa bb X5 7) HH (bb cc dd aa X12 5)


HHH (bbb ccc ddd aaa X4 7) HHH (aaa bbb ccc ddd X9 14) HHH (ddd aaa bbb ccc X15 9) HHH (ccc ddd aaa bbb X8 13) HHH (bbb ccc ddd aaa X1 15) HHH (aaa bbb ccc ddd X14 6) HHH (ddd aaa bbb ccc X7 8) HHH (ccc ddd aaa bbb X0 13) HHH (bbb ccc ddd aaa X6 6) HHH (aaa bbb ccc ddd X11 12) HHH (ddd aaa bbb ccc X13 5) HHH (ccc ddd aaa bbb X5 7) HHH (bbb ccc ddd aaa X12 5)

/* combination of results into output */ AA (B + cc + ddd) mod 232 BB (C + dd + aaa) mod 232 CC (D + aa + bbb) mod 232 DD (A + bb + ccc) mod 232

The Construction of the Hashcode

The word EN is computed from AN , BN , CN and DN as:

EN ((AN + F (BN CN DN ) + BN + 0x50a28be6) mod 232 ) 7: Note that this is the word resulting from the FFF -function, with the input word Xk replaced by BN and shift s = 7. The hashcode is the 160-bit string H(M ) := AN k BN k CN k DN k EN :

60


Chapter 8

The Protocols 8.1 Introduction This chapter species the protocols, where the wallet is typically realized in the form of a smart card. This implies the observer and the (functionally very little) purse are lumped and implemented with a single chip. Hence, the system can be referred to as the smart-card-only system. The purse can be extended in functionality into an + purse. The CAFE project has implemented this as a two-button wallet. This wallet device provides a display, infra-red communications, smart card slot and two keys for user input. This is called the + -system. The + -system uses the same cryptographic protocols as the -system, but with the added load cheque protocol, which performs reading unspent cheques from the purse's storage into the observer. The specication of the protocols does not include the protocols for PIN handling and the recovery function of atomic actions. The reason for this is that the implementation aspects of these protocols also determine their form to a large extent, and that the implementation of them are not essential from a cryptographic protocol point of view. The order of execution of the protocols, and dependencies between the protocols are described in Section 4.4. The and + -systems include the following protocols: rec atomics performs recovery of atomic actions. An atomic action is an action that can only be interrupted in a well dened manner. Interruption of an atomic update of a variable will for instance always leave either the old value or the new value|never some other undened value. The realization is left to the implementors. reset resets the wallet, and is carried out prior to any other protocol or action at startup. get info forwards public parameter values (key and parameter versions, identity of the bank) to the terminal. This allows the terminal to retrieve the necessary information for execution of subsequent protocols, either from the terminal's database, or from the wallet (on request). The latter is done by the get certif protocol, which allows an issuer to decide to update the wallet if an invalid key set is detected. For this, the update protocol is used. authenticate performs a mutual identication of wallet and issuer. The issuer will update its database about the wallet's state. 61

Chapter 8: The Protocols


allows the bank to provide the wallet with a new currency table. gen cheque generates and stores new cheques into the wallet. load cheque loads a previously generated cheque from a purse into the observer. This requires a special action by the same wallet during the generation with gen cheque by the same observer, see Section 8.7. show currencies forwards balance information from the observer to the terminal. payment performs a payment from the wallet to a till. rec payments performs recovery of interrupted payments. recovery performs recovery of the currency value stored in the wallet. PIN protocol does the management of wallet access control, by verication, changing and unlocking (a wallet becomes locked, for instance after three incorrect PIN entries (to be provided by the implementors). unlock amt performs a PIN-protected unlocking of a payer-specied amount (unlocked ) in the wallet. transfer performs a ; to observer value transfer. rollback recovers from an interrupted transfer protocol. get certif forwards the keys and certicates needed during a payment to the till. update consists of two parts, each updates a specic public key certicate from the issuer. The certicate is checked, and all related keys are also updated. deposit transports the electronic currency from the payee to the acquirer. write cu tbl

62

8.2 reset


8.2

reset

Wallet do rec atomics if pay busy save failed payment nr fail pay nr fail pay + 1 decrease unlocked if pay type = phone payment Ebal Ebal ; tck cnt Epay else Ebal Ebal ; Epay reset pay busy Figure 8.1:

reset.

The reset protocol, shown in Figure 8.1, is always executed as the rst part in a transaction. That is, it is executed before any other protocol.1 The reset protocol rst calls the rec atomics protocol this protocol recovers all atomic actions that have been interrupted. If the pay busy ag is set, the interrupted payment is saved for later processing at a issuer terminal. Furthermore, the balance Ebal used in this payment is decreased by the required amount. Finally, the ag pay busy is reset. The variables Ebal , Epay , pay type and tck cnt are set by the payment protocol, see Section 8.9.

8.3

get info

Wallet

Terminal v vBa vBc ID B

;;;;;;;;;;;;;; ! ;

Figure 8.2:

get info

The get info protocol, shown in Figure 8.2, forwards public information from the wallet to the terminal. This allows the terminal to retrieve the information necessary for subsequent protocols:

if the terminal is a reload station, and the wallet keys are up to date, the terminal retrieves the information necessary for authenticate.

1 It

must be impossible to do anything with the wallet before doing a reset this is one of the assumptions in the security evaluation.

63



if the terminal is a reload station, and the wallet keys are out of date, the terminal provides the wallet with new keys by executing the update protocol before doing an authenticate.

if the terminal is a till, and the public key(s) are unknown to the payee, the get certif protocol is executed before doing the payment protocol.

if the terminal is a till, and the public key(s) are known to the payee, the till retrieves them before doing the payment protocol.

8.4

authenticate

The authenticate protocol, shown in Figure 8.3, performs the mutual authentication between reload station and wallet. The wallet reveals its identity subsequent to the successful authentication of the reload stations identity. The protocol is structured as follows. The wallet sends a challenge to the reload station. The reload station returns a signature of this challenge. The wallet veries the signature, and then signs its current state. This state, the signature and its ID are sent to the reload station, which stores this as a snapshot of the wallet. A snapshot contains the state of the wallet, as far as necessary to recover to a consistent state at any point in time: 1. seq no : a sequence number of the snapshot. 2. cu tbl : the currency table. See Section 8.5 for a description of the currency table. 3. min dist : the block number modulo 216 for the wallet's seed used for regeneration of the oldest unspent cheque. 4. dist : the block number modulo 216 of the seed used for the most recently generated cheque. (Or, during such a cheque generation, of the currently generated cheque.) 5. max dist : an upper bound modulo 216 on the allowed block number of the seed used for generation of new cheques. This is determined by the issuer and updated every time it is used on the basis of min dist and the maximal possible number of cheques on the card. 6. nr wrap : the number of times min dist wrapped around. It is incremented each time the newly received min dist is smaller than the corresponding value of the snapshot. This variable is not needed by the wallet. The state of the wallet further contains the variables: 1. cu tbl valid : a ag indicating the validity of cu tbl in the wallet. 2. trans : the amount transferred by transfer (see Section 8.10) as received by the wallet since the last execution of write cu tbl. The issuer must 64

8.4 authenticate


Wallet

Reload Station

mb 2R ZZq

ab grb Pa cb mod p cb =? H(mb , ? ab )

mb

;;;;;;;;; !

cb rb PIN ;;;;;;;;;;

verify PIN update min dist state (seq no , cu tbl valid , trans , min dist , dist , nr fail pay , ? , cu tbl ) ws 2R ZZq as gws mod p cs H(cb state , ? as ) rs ws ; cs ss mod q

cs , rs , state , ID s ;;;;;;;;! ;

Figure 8.3:

wb 2R ZZq ab gwb mod p cb H(mb , ? ab ) rb wb ; cb Sa mod q

retrieve ps , wallet recovered , snapshot corr. to ID s check seq no store seq no in snapshot not wallet recovered ? as grs ps cs mod p cs =? H(cb state , ? as ) if (nr fail pay > 0) call rec payments if (cu tbl valid ) update snapshot else call write cu tbl using snapshot

authenticate

65



know this in order to compute the net amount transferred from a ; wallet to the aliated wallet. That is, the bank keeps a variable, say &, for each aliation & is initialized to 0, and each time decremented by trans as reported by the ; wallet, and incremented by trans as reported by the wallet. 3. nr fail pay : the number of failed payment transactions that still can be recovered by executing rec payments. For disputability, the bank must store the signature (cs rs ) and cb and the state state (needed to check the signature). This is called a pre-image in the security review.

8.5

write cu tbl

Description of cu tbl The wallet reserves storage space for max curr balances, currency identiers and exchange rates. These data are stored as cu tbl . This is a table with max curr rows (numbered 0, . . . , max curr ; 1) and 3 columns (numbered 0, 1, 2). The entry in row i and column j is denoted cu tbl i j ]. Column 1 determine the currency type. The ISO currency codes are 3 ASCII characters long, but only 3 5 are signicant bits in these codes. The signicant bits are stored in two bytes. The exact implementation is left to the implementors. Column 0 contains the balances for these currencies (24 bits), i.e., the number of units of the currency stated in column 1. Column 2 stores the approximate exchange rates from the given currency to the payer's home currency. The rates are used to provide an estimate in home currency of an amount to be paid in another currency. The rates are also used for the unlocking of amounts. A rate is changed only when the corresponding balance is changed due to an execution of the write cu tbl protocol it is set to 0 when a row is empty. The exact format of the rates is left to the implementors.

Example The wallet of a Dutch payer with ve currency balances may contain a table like this: 0 3297 1000 13 756 4529

1 NLG DEM BEF GBP XEU

2 1.000 1.112 0.057 2.447 2.100

description 3297 Dutch units 1000 German units 1.112 Dutch units apiece 13 Belgian units 0.057 Dutch units apiece 756 English units 2.447 Dutch units apiece 4529 ECU units 2.100 Dutch units apiece

So, for instance, cu tbl 1 0] is in currency cu tbl 1 1] = DEM, which is the ISO code for German Mark. In this example, the balance is cu tbl 1 0] = 1000 German currency units. The exchange rate used in the last exchange into Mark for this payer amounted to 1 DEM unit for 1.112 NLG units. The DEM currency balance amounts to 1000 1:112 = 1112 denominated in NLG currency units. 66

8.5 write cu tbl


Wallet

Reload Station update max dist

wr 2R ZZq ar gwr mod p cr H(seq no ID s (cu tbl ), ? ar ) rr wr ; cr Sa mod q

ar grr Pa cr mod p cr =? H(seq no ID s (cu tbl ), ? ar ) verify PIN reset cu tbl valid trans 0 increment seq no store cu tbl 0 store max dist wz 2R ZZq az gwz mod p cz H(seq no cu tbl 0 , ? az ) rz wz ; cz ss mod q

cr , rr , PIN , cu tbl 0 , max dist ;;;;;;;;;;;;;

cz rz

aw grw Pa cw mod p cw =? H(cz cu tbl 0 max dist , ? aw )

;;;;;;;;;;;; ! ; increment seq no az grz ps cz mod p cz =? H(seq no cu tbl 0 , ? az ) update snapshot & account ww 2R ZZq aw gww mod p cw H(cz cu tbl 0 max dist , ? aw ) cw rw rw ww ; cw Sa mod q ;;;;;;;;;;;;;

set cu tbl valid

Figure 8.4:

write cu tbl

67



An empty row is cleared and set to its initial state during write cu tbl. That is, if a balance in row i 6= 0 is zero, the entries in that row are set to: 0 in column 0 (balance), 0xFFFF in column 1 (ISO currency code), and 0 in column 2 (exchange rate). The home currency row is exempted from this rule, because this currency should always be present in the currency table. If empty its state remains 0 in column 0 (balance), the ISO code for the home currency in column 1 (ISO currency code), and 1 in column 2 (exchange rate).

Description of the write cu tbl protocol

The write cu tbl protocol, shown in Figure 8.4, serves two purposes: if the wallet does not have a valid cu tbl , the reload station nds this out during the authenticate protocol. The value of the cu tbl as stored in the snapshot is loaded into the wallet by means of write cu tbl. if the payer wants to reload the wallet or make a currency exchange, then a new currency table is determined by the reload station (from the old cu tbl and the payers request, taking into account the coding of empty rows mentioned above). This new table is loaded into the wallet by means of write cu tbl. The authenticate protocol needs to be executed prior to the write cu tbl protocol. There are some limitations on the new currency table: it is derived from the old table depending on the requests of the payer, and in accordance with limitations the issuer may set. For example, the net amount withdrawn (converted to home currency using the current rates) must not exceed a predetermined value (depending on how much the payer may overdraw his account). Furthermore, the new total value (converted to home currency using the current rates) stored in the wallet must not exceed max bal . The protocol is structured as follows. Three signatures plus the messages signed (as far as they are not yet known to the receiving party): 1. the bank signs the wallet's ID and seq no , and forwards the new cu tbl and the PIN2 . The signature tells the wallet that the issuer allows it to erase the current cu tbl . So, after verication, the wallet resets the ag cu tbl valid , and stores the cu tbl received. The issuer also signs the old cu tbl . This guarantees that no undetected change can be made between authenticate and write cu tbl| especially, no undetected payment is possible. Including the old cu tbl is done only in case cu tbl valid is set. If it is not set, the issuer and the wallet may have dierent tables, and the wallet cannot change it anyway (as no payment is possible with the ag reset). 0

0

2 This

will be a re-sending of the PIN obtained and used before in authenticate it does make sense to re-check it, as it prevents the bank from the following attack. If no payment was made since the last withdrawal, a found and identied wallet (by means of data printed on the plastic) can be used to do a withdrawal, as the issuer has all data required to do write cu tbl.

68

8.6 gen cheque


2. the wallet signs the new cu tbl . The issuer may store this as proof of the transaction. In any case, the issuer must now update the snapshot and the payer's account to reect this change of state of the wallet. 0

3. The issuer also signs the new cu tbl , together with max dist that provides an upper bound on the number of cheques that may be withdrawn. This signature tells the wallet that the issuer has stored the same cu tbl , so after verication of the signature, it sets the ag cu tbl valid again. 0

0

For non-repudiation, the issuer must store the signature (cz rz ) and seq no and cu tbl (needed to check the signature). This is termed a post-image in the security review. Note that after a failure in this protocol, authenticate has to be re-done rst, before retrying. This makes sure that the issuer uses the correct seq no in the retry. 0

8.6

gen cheque

Wallet

Reload Station

cu tbl valid ? ? dist < max dist (mod 216 ) space for cheque ? increment dist (mod 216 ) 11 , 21 , 12 , 22 , u, v, 3 2R ZZq 21 g11 h21 mod p c1 H(21 ) 22 g12 h22 mod p c2 H(22 ) 1 gc3 mod p 3 pc 3 mod p

a a0 Gvc Pcu mod p b (b0 gcv puc )3 mod p c H(c1 c2 , ? a ab 1 3 ) c0 c ; u mod q r r0 + v mod q ab ? (Gc 1 )r (Pc 3 )c (mod p) store (c r dist )

w0 2R ZZq a0 Gwc 0 mod p b0 gcw0 mod p

a0 b 0

;;;;;;;;;;;;;

c0

;;;;;;;;;;;; ! ;

r0

;;;;;;;;;;;;;

Figure 8.5:

r0 w0 ; c0 Sc mod q

gen cheque

In order to make sure that the clearing system can identify broken wallets 69



spending a cheque too many times, the payer specic generator gc is incorporated in the cheque. However, for privacy reasons the wallet must blind this generator so that it cannot be recognized when cheques are used. This is achieved using the blind signature protocol of CP93b] (see Section 7.3). The gen cheque protocol, shown in Figure 8.5, is repeated as long as the wallet can accept more cheques in its memory. (It may of course also be aborted on the user's request). A cheque consists of

A blinded version 1 of gc which is impossible to link to the wallet or payer (more precisely 1 = gc3 mod p, where 3 is chosen pseudo-randomly by the wallet). This key also serves as cheque identier.

Two auxiliary one-time public keys, 21 and 22 , needed to use the cheques and unknown to the issuer (two keys are needed since the cheque may be spent twice). These keys are of the form

21 = g11 h21 mod p and 22 = g12 h22 mod p where the 's are generated pseudo-randomly by the wallet. A blind signature on gc from the issuer. This signature also binds the wallet to the choice of the two one-time public keys mentioned above.

Secret information consisting of the 's pseudo-randomly generated by the wallet and needed to sign the cheque at payment.

Of these parts only the blind signature (c r) from the issuer is stored in the wallet because the 's can be regenerated as needed. Therefore, a cheque is represented in memory by 43 bytes: 20 each for c and r, 2 for the index in the cheque sequence, and 1 for information on how often it has been spent. The index in the cheque sequence is needed to restart the random number generator at the appropriate point so that the correct 's are regenerated. At the moment of generation, this index is the current value of dist . The last byte is used to determine if the cheque can still be used for payment. Thus, a cheque is fully `self-describing'.

8.7

load cheque

The load cheque protocol allows the observer to access external storage for cheques. That is, cheque storage can be extended to memory outside the chip, rather than being restricted to the the internal stable storage (EEPROM). The rest of the system is not aected by the availability or use of load cheque, so it may or may not be available to an chip. Note that this feature cannot be used fully with one + wallet and several dierent observers: load cheque will fail if another observer then the one used for generating it is inserted the cheque is lost then. The protocol is described here because there is no problem in using it with an + wallet, except for the issue mentioned above. 70

8.7 load cheque


The mechanism is as follows. The wallet keeps track of the number of successfully generated cheques during the withdrawal session. As soon as the + wallet has available space for just one more cheque, the wallet distorts the response r0 from the terminal (e.g., by sending 0 see gen cheque, Fig. 8.5). The + wallet will then abort the gen cheque protocol due to a failing verication ab ? (Gc1 )r (Pc 3 )c (mod p). It will accept another trial to generate another cheque: at a re-execution of gen cheque, it does not abort because of lack of space.3 The wallet must make sure that one cheque slot in the + wallet is kept empty if it wants to be able to load cheques in external storage. That is, it must not ll the last cheque slot in the + wallet with the load cheque protocol.

Observer

+ purse

cu tbl valid ? space for cheque ? ? D max dist (mod 216 ) ? D > min dist (mod 216 ) 11 , 21 , 12 , 22 , u, v, 3 2R ZZq (index D) 21 g11 h21 mod p c1 H(21 ) 22 g12 h22 mod p c2 H(22 ) 1 gc3 mod p 3 pc 3 mod p

a a0 Gvc Pcu mod p b (b0 gcv puc )3 mod p c H(c1 c2 , ? a ab 1 3 ) c0 c ; u mod q r r0 + v mod q ab ? (Gc 1 )r (Pc 3 )c (mod p) store (c r D)

D

;;;;;;;;;;;;;

a0 b0

a0 Grc0 Pcc0 mod p b0 gcr0 pcc0 mod p

;;;;;;;;;;;;;

c0

;;;;;;;;;;;; ! ;

r0

;;;;;;;;;;;;;

Figure 8.6:

received c0 same as stored value?

load cheque

The purse stores the values c0 and r0 , and the value of dist used by the 3 The

issuer must choose a relatively liberal upper bound max dist to enable loading of more cheques.

71



observer. (Note that from c0 and r0 , both a0 and b0 can be recomputed.) Next, the gen cheque protocol is re-executed, and again r0 is incorrectly transmitted to the observer, and (c0 r0 dist ) is stored by the purse. This process is repeated until the external memory is full, or until no more cheques are required. Since the purse possesses (c0 r0 dist ), it is able to feed D = dist , a0 , b0 and r0 back to the observer at a later stage.4 This is sucient information for the card to re-generate the related values of the u and v, and eventually compute the correct cheque (c r). Actually, after checking that D has an allowed value, the observer may do exactly the same as in gen cheque, starting after the increment of dist . Only the computation and transmission of c0 is redundant, and may be discarded. (On the other hand, since it is redundant, it is probably better to do these steps, as it allows re-use of the code for almost the complete gen cheque protocol.) The dierences on the wallet side, compared to the gen cheque protocol are in the \initialization" only, and may be summarized as:

1. It must be veried that D max dist (mod 216 ), rather than verifying that dist < max dist (mod 216 ) 2. D must be loaded as the index to be used in the random generator (cheque sequence), rather than incrementing dist , and then using this value of dist . 3. An extra check is the verication that D > min dist (mod 216 ). This prevents double-spending of a previously spent cheque. The algorithm that locates a cheque to be used in a payment guarantees that if several cheques with the same value of dist (or several copies of one cheque) are present, only one of them is ever used: The verication if D > min dist (mod 216 ) in this protocol guarantees that loading can only happen if all these cheques are completely unspent. Since the algorithm is deterministic, always the same of these possible cheques is chosen for payment, until it is completely spent. As soon as this happens, min dist is incremented. As stated before, the rest of the load cheque protocol is identical to gen cheque, though one may (but need not) skip two steps, if opportune.

Remark on synchronization In gen cheque, the wallet must keep track of the current value of dist at all times. This is no problem as long as the protocol is not aborted. If it is, there are two possibilities: it aborts because of a failed test, or it crashes (for unspecied reasons). In the rst case, the wallet knows exactly where this has happened, or, more precisely, it knows whether or not dist has been incremented. In the second case, the wallet may not know this. The proposed solution is reexecution of authenticate to obtain the correct value of dist again. 72

8.8 show currencies


Observer

+ Purse/Terminal

cu tbl valid ? (delay)

cu tbl , unlocked , payments

!; ;;;;;;;;;;;;; Figure 8.7:

8.8

store/display this

show currencies

show currencies

The show currencies protocol is given in Figure 8.7. Its purpose is showing the user the contents of the wallet. This can happen on the user's request, or it may be necessary to enable the payer to make decisions by which currencies and amounts he wants to spend. A delay may be built in to discourage repeated use of this protocol. Since it infringes on the users privacy, its use must be limited to the cases where either the payer requests it, or the payment will not work without user interaction. The latter are notably payments in currencies other than the local currency, and payments where no single balance is sucient. These cases will be recognized by the users as special cases requiring a longer time than normal unnecessary use will be recognized as such, and may be aborted by the payer. (The delay time should be congurable.) The show currencies protocol can be carried out between the wallet and a bank's or payee's terminal, as well as between the observer and the + purse. If a + wallet is used, the currency information will be displayed by the wallet.

8.9

payment

The payment protocol is shown in Figures 8.8 and 8.9. Besides the basic functionality the payment protocol contains two special features: currency exchange and the possibility to handle phone ticks. These features are described in succession. Currency exchange during a payment is handled as follows. In principle, a payer may choose any currency to pay in that satises the following restraints: 1. The payee has a rate from the currency the payer chooses to the currency of his own choice. 2. Using this rate, the payer has a sucient balance on his card. 4 The

cheque index is called D rather than dist in load cheque, to avoid confusion with the stable variable dist in the observer. D is a local variable, just as in payment.

73


Wallet

cu tbl valid ? cheque (c r D i) available ?


Till

determine pay to , pay fro , cu to , cu fro , pay type pay to , pay fro , pay to ? max pay (cu to ) cu to , cu fro , ID P , pay type , date

if (i = 0) (i j ) (1 2) else (2 1) ;;;;;;;;;;;;;; Ebal suitable balance ? Ebal pay fro pay fro unlocked ? regenerate 11 , 21 , 12 , 22 , u, v, 3 2j g1j h2j mod p cj H(2j ) 2i g1i h2i mod p 3 pc 3 mod p 1 gc3 mod p i, c, r, cj , 2i , 3 , 1 mark cheque as spent i times ;;;;;;;;;;;;; ! ; ? if pay type = phone payment 1 6 1 (mod p) 0 2R ZZNphone a Grc Pcc mod p b 1r 3c mod p T 02T mod Nphone ci H(2i ) tT c =? H(c1 c2 , ? a ab 1 3 ) m H(2i , 1 , pay to , pay fro , ;;;;;;;;;;;;;; 2R ZZ232 cu to , cu fro , ID P , pay type , date , , ? (T )) 1 3 ss ; m1i mod q 2 3 ; m2i mod q Epay pay fro store date if pay type = phone payment: tck cnt 0 (T ) 1 2 if pay type = phone payment set pay busy ;;;;;;;;;;;;; ! ; tT T m H(2i , 1 , pay to , pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) g1 h2 ? 1 2;im (mod p) if pay type = phone payment do phone-ticks \thanks" ;;;;;;;;;;;;;; decrease unlocked if pay type = phone payment Ebal Ebal ; tck cnt Epay store deposit record else Ebal Ebal ; Epay reset pay busy

Figure 8.8:

74

payment:

ith spending of a cheque

8.9 payment


An extra restriction on the payment is suciency of the unlocked amount unlocked . That is, the amount payable must be at most the unlocked amount. If the unlocked amount is insucient, the user can increase this amount by a PIN-protected protocol, the unlock amt-protocol, see Section 8.11. The payment of phone ticks is a special case, because within a short time a large number of small amounts must be paid. Because one does not want to use a cheque for each of these payments, phone ticks are dealt with in the following manner. This solution only uses one cheque per T ticks. Here T is typically in the order of 100 or 200 (to be decided by the system operator since the variables counting ticks are one byte long, T must be at most 255). The function y x2 mod Nphone is a one-way function. The wallet chooses a random seed 0 , and repeatedly applies this function T times to 0 . The resulting value T is incorporated in the signature that is generated with the cheque in the payment protocol. Thus the withdrawal is not inuenced by the phone-ticks. A phone-call is paid for by releasing a pre-image of T after each phone-tick. The public modulus Nphone , the product of two primes, is a public system parameter, which should be chosen by the system operator. The factorization of Nphone should be kept secret. The system parameter T denotes the maximum number of ticks that can be paid for with (one part of) a cheque. A variable pay type is used to distinguish phone tick payments from ordinary ones. The value \phone payment" of pay type indicates that the payment is a phone tick payment. Wallet

Till

\ticks" n

?

tn t t ;tn 02 mod Nphone (tck cnt + n) Epay unlocked ? ? Ebal (tck cnt + n) Epay tck cnt tck cnt + n

;;;;;;;;;;;;;;

;;;;;;;;;;;;; ! ; Figure 8.9:

payment:

0 ? (T ; t + n) pay to max pay (cu to ) ? tn tt;n

0 ? 2n (mod Nphone )

phone ticks. Pay n phone ticks costing Epay each.

Assume that a phone-tick payment is at hand, and that the cheque has already been written out to the phone-company. The wallet pays for the (T ; t)-th tick by releasing the pre-image 02t . This process is ended when 75



the \thanks" message has been received by the wallet. This happens when the phone-call has ended, or the maximum number T of ticks per (part of a) cheque has been reached. Finally, the payee stores the last received pre-image . If the phone call is not nished by the time \thanks" is sent (because the maximum number of ticks has been reached), the entire payment protocol is repeated. Security requires that the balance is debited, irrespective of the success of the payment on the payee's side, as otherwise one may gain money by interrupting payments. (A payment may go wrong after complete processing by the payee, but before the payer has completed, see Figure 8.8.) Therefore, the balance used must be known at the next reset. This information is denoted \Ebal " it consists of sucient information to recover the exact balance. That is, its position in memory. The value of this balance is also addressed as \Ebal ". No confusion seems possible here. In addition, one needs the amount, currency, type and date of the failed payment. A stable variable Epay contains the amount payable pay fro . For the currency cu fro , a special solution may be chosen: one may retrieve it from Ebal at reset. Furthermore, the date of payment (date ) and the payment type pay type are stably stored. Finally, the stable counter tck cnt counts the multiplicity of the payment: for an ordinary payment this is meaningless for a phone tick payment it is the number of ticks (pay tck cnt ticks of pay fro each). Also note that there is the possibility of recovery of a failed payment by the rec payments protocol (see Section 8.14). This is done in two steps. First, at the next execution of reset, the necessary information is saved in a \failedpayment-slot". Next, in the next withdrawal session the rec payments protocol is called to process this information together with the bank. (This recovery is of course only performed in case the payment is interrupted.) This mechanism requires that the following information is available at the next reset (after interruption of a payment): 1. D, i corresponding to the cheque used in the interrupted payment. (They identify the cheque used, and enable its reconstruction.) These are automatically saved, since a cheque is stored in stable storage. One must make sure that it is still known which cheque was used, either by copying D (and i) explicitly in stable storage, or by storing a pointer to this cheque in stable storage. This is denoted as \save D, i in stable storage" the choice between the above implementations is left to the implementors. 2. The amount, currency and date of the interrupted payment. These are saved explicitly in stable storage, as explained above. Note that in principle every payment may be interrupted, as the information required for recovery requires half the space of a cheque. (If the rst payment after a complete lling of the card with cheques is interrupted, this might require deleting the whole cheque used in this payment, depending on how the memory is managed. This would also decrease the number of payments by one.) 76


8.10

8.10 transfer

transfer

The transfer protocol allows the transfer of a value from the `mother' wallet (which is a ;-wallet) to an aliated `daughter' wallet. To distinguish the key pair (ps ss ) of the `mother' observer from the corresponding key pair in the aliated wallet, the former key pair is called (po so ) in this protocol. The following convention is applied throughout this section: observer variables are indexed by an o, purse variables by a p and wallet (smartcard) variables by an s. The transfer service is limited to one aliation. Both mother and daughter keep an extra balance, trans , that holds the cumulative amount transferred. This variable is reset at the next withdrawal session, in write cu tbl. The value of trans is upper bounded by max trans to transfer more money, one must rst reset trans by performing a withdrawal (write cu tbl). Furthermore, a transfer can only be done in home currency. Recall that this currency always is present in the currency table cu tbl . The transfer protocol can only be executed if trans logp = . If this does not hold due to an interruption of a transfer, the rollback protocol needs to be executed to recover from the interrupted transfer. Also note that the previous value of trans logs is overwritten when a transfer is executed. This means that any previously interrupted transfer cannot be recovered anymore after a new transfer has been initiated. Before the actual transfer is performed, both the ; wallet and its alated wallet determine whether the requested amount Xfer may indeed be transferred. Then a chain of signatures follows initiated by the wallet. These signatures are not randomized because there is no external terminal involved. For the same reason there might be no need to let the ; purse check these signatures, but these checks are retained anyway. The wallets connect, and the wallet starts by sending a random value mt to the ; observer. This is followed by a signature of the ; observer on the desired amount. Then follows a signature by the wallet on a commitment y to be used for recovery. Finally, the signature of the wallet is acknowledged by a signature of the ; observer. See Figures 8.10 and 8.11. Note that this sequence of signatures achieves that the wallet will only take part in a transfer with the ; wallet to which it is aliated, which means, for instance, that the value of trans logs will not be overwritten when the wallet is (accidently) connected to another ; wallet. The wallet will not emit signatures to other devices that initiate the transfer protocol. If this was not the case, the privacy of the payer could be broken by any service terminal that the wallet connected to. The rollback protocol allows the ; wallet and aliated wallet to recover if transfer is interrupted (see Figure 8.12). The following cases exist: 1. If trans logp = , then nothing needs to be done. 2. If trans logp 6= and trans logs = , then the ; purse must complete the nal step of transfer, i.e., set trans logp atomically. Then rollback is completed. 77



; Observer

; Purse

Wallet

trans logp =?

determine Xfer ? Xfer + transp max trans Ebal p home curr. bal.? Xfer Ebal p Xfer Xfer unlocked ?

;;;;;;;;; cu tbl valid ? ? Xfer + trans o max trans Ebal o home curr. bal.? Xfer Ebal o trans o Xfer unlocked ? ;;;;;;;; ! ; trans o =? transp

mt

; ;;;;;;;; wt 2R q at gwt mod p ct H(mt Xfer , ? at ) rt wt ; ct so mod q ct rt ZZ

Xfer

cu tbl valid ?

;;;;;;;; !;

mt

?

Xfer + transs max trans Ebal home curr. bal. ? total balance+ Xfer max bal

mt 2R ZZq

;;;;;;;;;

;;;;;;;; ! ;

at grt poct mod p ct =? H(mt Xfer , ? at )

c r

t t ;;;;;;;; !;at grt poct mod p

ca ra y

ct =? H(mt Xfer , ? at) x2R ZZq y H(x) trans logs x wa 2R ZZq aa gwa mod p ca H(ct y, ? aa ) ra wa ; ca ss mod q

;;;;;;;;; Figure 8.10: transfer (part 1): an amount Xfer is transferred from the ; wallet to the aliated wallet.

78

8.10 transfer


; Observer

; Purse

Wallet

aa gra ps ca mod p ca =? H(ct y, ? aa) trans logp (y Xfer ) decrease unlocked aa gra ps ca

mod p ca =? H(ct y, ? aa) trans log o (y Xfer ) decrease unlocked

ca ra y

;;;;;;;;;

Ebal p Ebal p ; Xfer transp transp + Xfer

Ebal o Ebal o ; Xfer trans o trans o + Xfer

wi 2R ZZq ai gwi mod p ci H(ca , ? ai ) ri wi ; ci so mod q

c r

i i ;;;;;;;; !;

ai gri poci mod p ci =? H(ca , ? ai )

c r

i i ;;;;;;;; !;

\OK"

trans logp

ai gri poci mod p ci =? H(ca , ? ai )

;;;;;;;;;

trans logs

increase unlocked Ebal Ebal + Xfer transs transs + Xfer

Figure 8.11: transfer (part 2): an amount Xfer is transferred from the ; wallet to the aliated wallet

79



3. If trans logp 6= and trans logs 6= and trans log o = , then the ; observer does not need to do anything and the ; purse increases its counter when it receives the right value for x. 4. If trans logp 6= and trans logs 6= and trans log o 6= , then the ; observer increases its counter when it receives the right value for x. After this, the ; purse increases its counter too if the value for x is correct. The rollback protocol should take care of all these cases. Note that trans logs and trans log o are not necessarily cleared. Also note that transfer can only be executed if trans logp = , and therefore an interrupted transfer must rst be recovered using rollback. In the rollback protocol, the user may choose to cancel the recovery, for instance if the aliated wallet is not present. In that case, however, the transfer protocol will not be enabled upon completion of reset if trans logs was nonempty before reset. ; Observer

; Purse

Wallet

?

trans logp 6=

insert daughter SC or cancel

x

if (x = ) trans logp

stop

x

x trans logs

;;;;;;;;;

;;;;;;;;;

if (trans log o 6= ) (y Xfer ) trans log o Ebal o home curr. bal. if (x 6= and y = H(x)) trans log o

increase unlocked Ebal o Ebal o + Xfer trans o trans o ; Xfer \OK"

;;;;;;;; !;

(y Xfer ) trans logp Ebal p home curr.bal. if (x 6= and y = H(x)) trans logp

increase unlocked Ebal p Ebal p + Xfer transp transp ; Xfer

Figure 8.12:

rollback

At withdrawal, the issuer receives the current value of trans of the wallet. This allows the issuer to stay informed of the amount transferred since the last withdrawal transaction performed by one of the wallets in the aliation. To this 80

8.11 unlock amt


end, it keeps a variable, say &, for each aliation. This variable is initialized to 0, and decremented by the reported trans in the withdrawal transaction carried out by the mother wallet, and incremented by the reported trans in the withdrawal transaction carried out by the daughter wallet. Thus, If & = &0 < 0, the last withdrawal was by the mother. If furthermore the mother has transferred an amount &1 since the last withdrawal, the daughter has transferred an amount (;&0 ) + &1 since her last withdrawal. (If the daughter did a withdrawal at that moment, she would report trans = (;&0 ) + &1 , and the bank would increment & by this amount, to obtain a new value & = &1 .) If & = &0 > 0, the last withdrawal was by the daughter. If furthermore the daughter has transferred an amount &1 since the last withdrawal, the mother has transferred an amount &0 + &1 since her last withdrawal. (If the mother did a withdrawal at that moment, she would report trans = &0 + &1 , and the issuer would decrement & by this amount, to obtain a new value & = ;&1 .) If & = 0, both mother and daughter have transferred the same amount, say &1 , since their last withdrawal. Note that this hold initially, and will continue to hold subsequently. Furthermore, it holds that ;max trans & max trans , since this holds initially, and 0 trans max trans , and a withdrawal cannot provide an inconsistent state. (Proof: Suppose & = &0 > 0, and the daughter withdraws and reports trans = &1 such that & &0 + &1 > max trans . I.e., if the mother did a withdrawal now, she would report trans = &0 + &1 > max trans , which is impossible. If the mother withdraws when & > 0, the value of & will decrease. So & max trans . The lower bound follows similarly.)

8.11

unlock amt

Wallet

+ Wallet/Terminal PIN U

if U > unlocked verify PIN unlocked U Figure 8.13:

get PIN and amount U to be unlocked from payer

; ;;;;;;;;;; ;

unlock amt:

unlocking of an amount on the wallet.

The unlock amt protocol unlocks a payer-specied amount unlocked on the

wallet. That is, payments are allowed up to an amount of unlocked if the 81



unlocked amount is smaller than the amount payable, the payer rst has to unlock an amount by performing the unlock amt protocol again to make the payment possible. Note that unlocked is not a balance, but just an extra variable counting down for each payment made. (The unlocked amount can be higher than the balance of the wallet this means that even after additional withdrawal, some value will be unlocked.) This mechanism allows the payer to force PIN -entry after spending a specied amount. This can be useful if the wallet is lost: if the PIN is kept secret, only the unlocked amount can be spent by the nder. The rest can be recovered by the recovery protocol.

8.12

update

Wallet

Reload/Recovery Station ?

Pa , vBa , Ea , CPa

Verify certicate CPa with validity period Ea using public key (mN eN ) store new vBa and Pa

vBa (Wallet) < vBa (Issuer)

;;;;;;;;;;;;;

Figure 8.14:

updateP a:

Updating Pa .

The update protocol updates the public keys of the issuer in the wallet. For an explanation of the mechanisms, see Part VI. The protocol consists of two parts, that may be executed separately and independently. The rst part updates the issuer's authentication key Pa . This part is given in Fig. 8.14. The second part updates the issuer's cheque-signing key Pc and the related wallet cheque key pc . This part is given in Fig. 8.15.

8.13

get certif

The get certif protocol is given in Figure 8.16. For an explanation of the mechanisms, we refer to Part VI. The protocol forwards the keys and certicates needed in a payment from the wallet to the till. The till veries the certicates and uses the keys in a subsequent payment. Depending on the location of the till and the realm of the issuer, and preferences of the payee, the key will be stored or discarded afterwards. (E.g., the payee might store the last few keys, only the most frequently used keys (the local ones)). 82

8.13 get certif


Wallet

Reload Station

mu 2R ZZq

mu

;;;;;;;;;;;; ! ;

cu ru

;;;;;;;;;;;;;

au g Pa mod p cu =? H(mu , ? au ) ru

cu

ID s ;;;;;;;;;;;; ! ;

Verify certicate CPc with validity period Ec using public key (mN eN ) av grv Pa cv mod p cv =? H(vBc , ? pc av ) store new vBc and Pc , CPc , pc adapt min dist

Pc , vBc , Ec , CPc , pc, cv , rv

?

vBc (Wallet) < vBc(Issuer) wu 2R ZZq au gwu mod p cu H(mu , ? au ) ru wu ; cu Sa mod q

retrieves ps corr. to ID s gc ps h mod p pc gcSc mod p store gc and pc wv 2R ZZq av gwv mod p cv H(vBc , ? pc av ) rv wv ; cv Sa mod q

;;;;;;;;;;;;;

Figure 8.15:

updateP c:

Updating Pc .

83



Wallet

Till ID B unknown ;;;;;;;;;;;;;;;;; Pc CPc ID NKCC vN ;;;;;;;;;;;;;;;;;! ; ID NKCC unknown ;;;;;;;;;;;;;;;;; mN eN CKN vC ;;;;;;;;;;;;;;;;; !

(ID B vBc ) unknown ?

if (ID NKCC vN ) unknown then Verify certicate CKN using public key (mC eC ) Check validity period of (mN eN )

end if

Verify certicate CPc using public key (mN eN ) Check validity period of Pc Figure 8.16:

8.14

get certif:

retrieving Pc from the wallet.

rec payments

The rec payments protocol, shown in Figure 8.17, initializes the recovery of failed payments. The protocol is executed between the wallet and the recovery station. It is repeated as long as the wallet contains failed payments to be recovered. The recovery station must limit this number to its estimate of the number of possible payments. Moreover, if a wallet creates too many failed payments, the issuer may decide to revoke it and issue a new one to the payer. Due to the reset protocol, the wallet balance has been decreased, even in case of a failed payment. The only thing the rec payments protocol still must do is to forward the data which the issuer needs to recognize the payment if it arrives by normal deposit. If it does, nothing more happens. If it does not arrive within a certain time-span after the date recorded in the payment, the payer is refunded the actual amount in the failed payment transaction. This is allowed, because obviously the payment failed for the payee too. Note that the clearing system must make sure that no double recovery of a failed payment occurs. Since the value of 1 determines the cheque, this is an easy check. (This fact also makes replay of the protocol innocuous it is not protected against by the protocol.) The protocol just makes the wallet sign all necessary data the issuer subsequently signs an acknowledgment. Finally, the wallet releases the memory used for the data.

8.15

recovery

The recovery protocol enables a payer to use an auxilary wallet to recover the value lost if his wallet breaks down or disappears for some reason. It is given 84

8.15 recovery


Wallet

Recovery Station

search failed payment (D, i, Epay , pay type , tck cnt , cu fro , date ) regenerate 3 from D 1 gc3 mod p wp 2R ZZq ap gwp mod p cp H(1 , i, Epay , pay type , tck cnt , cu fro , date ? ap ) rp wp ; cp ss mod q

1 , i, Epay , pay type , tck cnt , cu fro , date , cp , rp

;;;;;;;;;;;;; ! ;

ak grk Pa ck mod p ck =? H(cp , ? ak )

c r

ap grp ps cp mod p cp =? H(1 , i, Epay , pay type , tck cnt , cu fro , date , ? ap ) wk 2R ZZq ak gwk mod p ck H(cp , ? ak ) rk wk ; ck Sa mod q submit the failed payment to clearing for recovery.

k k ;;;;;;;;;;;;; ;

nr fail pay nr fail pay ; 1 remove payment

Figure 8.17:

rec payments

85



in Figure 8.19. Auxilary Wallet

Trusted terminal S 0 S 00 N

S ;;;;;;;;;;;;; ;

reset recovery done S S 0 S 00 store S , NS

Figure 8.18:

read recovery seed S 0 and modulus NS from issuer read recovery seed S 00 from user

recovery init:

initialization of an auxilary wallet.

The auxilary wallet re-generates all cheques that were generated during the last withdrawal session by the lost wallet. It then signs the data needed by the issuer for determining if a certain cheque has been spent. This is similar to rec payments, except that in that case, more data is known, such as amount, date and so on. In a recovery, one only knows the cheque keys. This allows the clearing system to recognize these cheques, so that the issuer can be notied how much was spent using these cheques. From the snapshot acquired in the last withdrawal session, the issuer can determine the balance of the wallet. If the wallet is aliated to a ; wallet, the issuer must also know how much currency was transferred. A lower bound on this is always known to the issuer. Together with the information on the value spent since the last withdrawal, this provides a lower bound on the amount left unspent. This amount can be refunded to the payer. Note that a withdrawal transaction by the mother wallet enables the issuer to compute the exact amount transferred to the daughter wallet this may be worth while to the payer. Also note that a withdrawal by the daughter is required in case of recovery of the mother wallet: if not, the issuer is only able to compute an upper bound on the amount to be refunded. A withdrawal transaction performed by the aliated wallet will allow the issuer to obtain the exact amount. To avoid problems with re-aliation of an òld' daughter (or even several daughters) or mother to a replacement device (replacing the lost mother respectively daughter), the issuer might also revoke the aliated device(s) at recovery of the lost device, possibly coupled with a withdrawal (or even recovery) of the aliated device(s). The recovery protocol need not be in the ROM mask, as the auxilary wallet may be implemented as a special purpose device that is erased after a successful recovery procedure. If so, an auxilary wallet will never have to perform other protocols, nor will an ordinary wallet ever perform a recovery. The recovery protocol consists of two parts. One with a trusted terminal, where the payer enters his part of the recovery seed S and the issuer enters his part of the recovery seed S together with the modulus NS . And one with the bank, where all possible used cheques are re-generated. The seed obtained in the rst part, plus some data obtained in the second 0

00

86

8.15 recovery


Auxilary Wallet

Recovery station

not recovery done ? mq 2R ZZq

mq

obtain ID s of lost wallet from payer retrieve snapshot and hash seed for that wallet wallet recovered ?

;;;;;;;;;;;;; ! ;

aq grq Pa cq mod p cq =? H(mq , hash seed , min dist , max dist , nr wrap , ?, gc aq ) hash seed =? H(S NS ) set recovery done dist min16 dist ; 1 mod 216 S S 27(2 nr wrap +dist ) mod NS

wq 2R ZZq aq gwq mod p hash seed , cq H(mq , hash seed , min dist , min dist , max dist , nr wrap , ?, gc aq ) max dist , rq wq ; cq Sa mod q nr wrap , gc , cq , rq dist min dist ; 1 mod 216 ;;;;;;;;;;;;;;

loop on all possible cheques

loop on all possible cheques

?

?

< max dist (mod 216 ) dist + 1 mod 216

dist < max dist (mod 216 )) dist dist + 1 mod 216

dist dist regenerate 3 2R ZZq 1 gc 3 mod p

w 2R ZZq a gw mod p c H(rq dist , ? 1 a ) r w ; c ss mod q

endloop

1 c r gr ps c mod p ;;;;;;;;;;;;; ! ; a ? c = H(rq dist , ? 1 a ) store endloop 1 credit (part of) value in cu tbl from snapshot to user submit all stored 1 to clearing set wallet recovered

remove S and NS

Figure 8.19:

recovery:

recovery of a crashed or lost wallet.

87



part allow the card to reconstruct the seed used for the generation of cheques. It re-generates those cheques, signs them and sends them to the bank. For this re-generation, the auxilary wallet must have the same system parameters as the lost wallet. That is, it must have the same version number v (for example determined by the get info protocol). Moreover, it must have a valid issuer authentication key Pa . If this is not the case, the update protocol updateP a is executed. The version of all other parameters (vBc , most notably) are inconsequential in this protocol. The correctness of the recovery seed and the modulus is determined by means of hash seed . This is the hash of the seed's initial value and the modulus, hash seed = H(S NS ). It is stored at initialization in the payer's bank account.

8.16

deposit

The deposit protocol forwards the till's stored information about the payment transactions. This includes all information obtained in get info and all messages from the payment itself for phone tick payments, only the last value of is sent. The identity of the aquirer ID B is added. This section gives an outline of the functionality of the clearing and the actions performed by the clearing system. For example, no distinction between the dierent entities in the clearing system is made, nor is the interaction between them mentioned. For a complete specication, see Part V. 0

88

8.16 deposit


Till

Acquire Station ID P , ID 0B , ID B , v , vBc , i, 1 , 2i , 3 , r, c, cj , pay to , pay fro , tck cnt , cu to , cu fro , pay type , date , , (T , ), 1 , 2

;;;;;;;;;;;;;;;;;;;;;;;! ;

Figure 8.20:

deposit:

retrieve parameters corr. to ID B , v , vBc parameters still valid ? deposit timely ? used rate valid ?? tck cnt pay to max pay (cu to ) ? 1 6 1 (mod p) a Grc Pcc mod p b 1r 3c mod p ci H(2i ) c =? H(c1 c2 , ? a ab 1 3 ) if pay type = phone payment 2tck cnt ? T (mod Nphone ) m H(2i , 1 , pay to , pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) g1 h2 ? 1 2;im (mod p) submit (ID p m) to double-deposit check credit tck cnt pay to to account of ID P at bank ID 0B submit (i 1 ) to double-spending check

depositing one payment transaction.

89


90



Chapter 9 The ; Protocols 9.1 Introduction This chapter species the ; protocols, where the wallet is typically realized in the form of small pocket calculator-like device with a display, a keypad, and an infra-red link for communicating with service terminals. This ; wallet contains a ; observer implemented as a single tamper resistant chip. The observer is embedded in the ; purse, which is a pocket workstation with its own memory and processing capabilities, and providing the input/output facilities of the wallet. The purse serves to prevent outow from the observer to external terminals as well as inow in the other direction, whereas the observer sees to it that the purse (i.e., the user) refrains from double-spending. The ; protocols can be viewed as an almost modular extension of the protocols. The extension is achieved by adding the user-controlled purse as a functional entity to the system, while the embedded observer fullls essentially the same role as the wallet in the system. The actions of almost all other functional entities are the same as in the system only the reload and recovery stations dier slightly in that they use randomized signatures in their exchanges with the ; wallet. The specication of the ; protocols does not include the protocols for PIN handling and recovery of atomic actions. The reason for this is that the implementation aspects of these protocols also to a large extent determine their form, and that the ideas to be used to implement them are straightforward from a cryptographic protocol point of view. The order of execution of the protocols, and dependencies between the protocols are described in Section 4.4. The ; system consists of the following protocols: performs recovery of atomic actions. An atomic action is an action that can only be interrupted in a well dened manner. Interruption of an atomic update of a variable will for instance always leave either the old value or the new value|never some other undened value. The actual realization is left to the implementors.

rec atomics

resets both observer and purse, and is carried out before any other protocol or action.

reset

forwards the public info (key and parameter versions, identity of the bank) to the terminal. The purse retrieves the information from the observer and checks its validity before passing it on to the terminal.

get info

91

Chapter 9: The ; Protocols


Based on this information the terminal retrieves the necessary data for execution of subsequent protocols, either from the terminal's database, or from the wallet (on request). The latter is done by the get certif protocol. Moreover, it allows an issuer to decide to update the wallet if an invalid key set is detected. For this, the update protocol is used. authenticate performs a mutual identication of observer and issuer and updates the information regarding the observer's internal state in the issuer's database. The purse blinds the signature exchange between the issuer and the observer and also checks the information related to the state before passing it on to the terminal. write cu tbl allows the issuer to provide the observer with a new currency table. The signature exchange is again randomized by the purse. gen cheque generates new cheques for the wallet. The cheques are randomized by the purse. show currencies forwards the balance information, stored by the observer, to the user. If the wallet has no capability of displaying information to the user, a display on a terminal must be used. payment performs a payment from the wallet to a till. rec payments performs recovery of interrupted payments. recovery performs recovery of the value stored in the wallet. PIN protocols for PIN verication, PIN changing and unlocking of a device after three incorrect PIN entries (to be provided by the implementors). unlock amt performs a PIN-protected unlocking of a payer-specied amount (unlocked ) in the wallet. transfer performs a value transfer from a ; wallet to an wallet. rollback recovers from an interrupted transfer protocol. get certif forwards the keys and certicates needed during a payment to the till. update consists of two parts, each updating a specic public key from the issuer. The certicate is checked, and all related keys are also updated. deposit transports the electronic currency from the payee to the acquirer.

Note on notation In the ; protocols many variables used by the observer are

also recorded by the purse. These so-called shadow variables in the purse do not always contain the same value as the corresponding variables in the observer. We introduce some notation to deal with these variables. To begin with, varp denotes the purse's shadow of the variable var in the observer. Further, the expression eq var] stands for var = varp , and similarly geq var] for var varp . Finally, copy var] abbreviates varp var.

92


9.2

9.2 reset

reset

The reset protocol, shown in Figure 9.1, is automatically executed when the wallet comes alive. Thus it is always executed before any other protocol.1 The reset protocol rst calls the rec atomics protocol this protocol recovers any atomic actions that have been interrupted. If the rem pay ag is set in the purse, recovery of a failed payment with the rec payments protocol has itself been interrupted. The observer possibly already removed the failed payment, but the purse might not have done this yet. In that case the observer's number of failed payments (nr fail pay ) is one less than that of the purse (nr fail pay p ). This can be corrected by letting the purse complete the nal part of rec payments, that is, delete the payment and decrement nr fail pay p. If the pay busy ag is set, a payment has been interrupted. The data of that payment are saved for later processing at an issuer's terminal and the balance Ebal used in that payment is decreased by the required amount. Finally, the ag pay busy is reset. The variables Ebal , Epay and tck cnt are set by the (interrupted) payment, see Section 9.8. There are three possible interruptions of the payment protocol to consider, depending on the state of the pay busy and pay busy p ags (see Figure 9.8): 1. As long as pay busy is reset, purse and observer haven't updated their currency table, and the till didn't accept the payment yet. Hence, no interrupted payment data needs to be stored. 2. Both pay busy and pay busy p are set. Then purse and observer still haven't updated their currency table, but the till might have accepted the payment. Thus both purse and observer must update their currency tables. 3. pay busy is set and pay busy p is reset. There are two possibilities: either the payment failed for the purse and was later saved in an execution of reset, which then failed for the observer, or the purse completed the payment, but it failed for the observer. In either case the purse's currency table has been updated, but in the latter case the purse didn't save the interrupted payment data yet. These cases can be distinguished from each other as in the former case the purse has already incremented nr fail pay p, but the observer has not (hence nr fail pay = nr fail pay p ; 1), while in the latter case neither purse nor observer have incremented their failed payment counter yet (hence nr fail pay = nr fail pay p ). It is assumed that even if the purse completed payment it remembers the data identifying the payment (so that it can check that the observer uses the correct data). These data are: (D i, Epay tck cnt , pay type cu fro date ). The variable n (multiplicity of ticks in phone payments) is needed to verify that the observer uses a correct value of tck cnt . 1 The

reset

security evaluation assumes that it is impossible to do any other protocol before is completed.

93



Observer call rec atomics

Purse nr fail pay , pay busy

call rec atomics

;;;;;;;;;;;; !; if rem pay and

if pay busy

if pay busy save (D i, Epay tck cnt , pay type cu fro date ) nr fail pay nr fail pay + 1 decrease unlocked if pay type = phone payment Ebal Ebal ; tck cnt Epay else Ebal Ebal ; Epay reset pay busy

nr fail pay = nr fail pay p ; 1 nr fail pay p nr fail pay p ; 1 remove payment reset rem pay

D i, Epay , pay type , tck cnt , cu fro , date

;;;;;;;;;;;; !; if nr fail pay = nr fail pay p

eq (D i)]? eq Epay ]? eq pay type ]? if pay type = phone payment ? tck cnt p 2 ftck cnt tck cnt ; ng eq cu fro ]? eq date ]? save (D i, Epay tck cnt , pay type cu fro date ) nr fail pay p nr fail pay p + 1 if pay busy p decrease unlocked if pay type = phone payment Ebal Ebal ; tck cnt Epay else Ebal Ebal ; Epay reset pay busy p

\OK"

;;;;;;;;;;;;;

\OK"

;;;;;;;;;;;; ! ; call rollback

call get info call show currencies

Figure 9.1:

94

reset

9.3 get info


No other entity is involved in this protocol. The following should always be true after reset: nr fail pay = nr fail pay p , purse and observer have updated the currency table in the same way, and they have stored the same data about the payments to be recovered (this is used in rec payments). To recover from interruptions of transfer, the recovery protocol rollback is called. Furthermore, get info and show currencies are called to guarantee that the observer and the purse use the same keys and the same unlocked .

9.3

get info

Observer

Purse v, vBa vBc, ID B

; ;;;;;;; ! ;

Terminal

eq v ]? if (:eq vBa ]) call last part of updateP a

if (:eq vBc ]) call last part of updateP c

eq ID B ]?

v , (vBa )p , (vBc )p , ID B

; ;;;;;;;;;;;! ; ;

Figure 9.2:

get info

The get info protocol, shown in Figure 9.2, forwards all public information in the wallet to the terminal. It is a straightforward adaption of the same protocol in the -system. The information is retrieved from the observer to ensure that the keys send out to the terminal can indeed be used. If the observer's keys are not the same as the ones stored in the purse|due to an interruption of either updateP a or updateP c|the purse re-executes the nal parts of these protocols. The check on ID B is not really necessary, but it is retained for consistency.

9.4

authenticate

The authenticate protocol, shown in Figure 9.3 and 9.4, performs the mutual authentication of issuer and wallet. The protocol is structured as in the system: The wallet identies itself only after the issuer has proven its identity to the purse (as this identication is done for privacy reasons, only the purse needs to verify it|the observer requires a PIN in order to proceed). 95



Observer

Purse ub 2R ZZq ab aub b mod p

c PIN

b ; ;;;;;; ;

cb H(ab ) ab =? grb Pa cb mod p get PIN

Reload station ab wa b 2R ZgZwqb mod p b ;;;;;;; ? ub u = ;;;;;; !; b 6 0 mod q wb wub ub mod q ab ab b mod p cb H(ab ) rb rb wb ; cb Sa mod q ;;;;;;;

verify PIN update min dist if :cu tbl valid cu tbl 0 state (seq no , cu tbl valid , trans , min dist , dist , nr fail pay , ? , cu tbl ) ws 2R ZZwq as as g s mod p ; ;;;;;; ! ? u s us 6= 0 mod q ;;;;;;; us 2R ZZq ws ws us mod q as aus s mod p as aus s mod p cs H(cb state , ? as ) rs ws ; cs ss mod q rs ,state ;;;;;;; ! cs H(cb state , ? as ) as =? grs ps cs mod p

Figure 9.3:

96

authenticate

(part 1)

9.4 authenticate


Observer

Purse

Reload station

update min dist p if cu tbl valid eq seq no ]? eq cu tbl ]? eq trans ]? else ? seq no p 2 fseq no seq no ; 1g cu tbl =? 0 ? trans 2 f0 trans p g copy seq no ] geq min dist ]? copy min dist ] geq dist ]? copy dist ] eq nr fail pay ]?

Figure 9.4:

cs , rs , state , ID s ;;;;;;;;! ;

authenticate

retrieve ps , wallet recovered , snapshot corr. to ID s check seq no store seq no in snapshot not wallet recovered ? as grs ps cs mod p cs =? H(cb state , ? as ) update nr wrap if (nr fail pay > 0) call rec payments if (cu tbl valid ) update snapshot else call write cu tbl using snapshot

(part 2)

97



The purse veries as much as possible the values describing the state of the observer. Here cu tbl seems to be a problem as the purse cannot tell if the observer has stored a table in a previous interrupted execution of write cu tbl. In case the cu tbl is invalid the observer is required to include a blank (all-zero) cu tbl in the state, and the purse checks this. The purse also partially checks the values of dist and min dist . These are hard to check exactly due to possible failures. The issuer also keeps track of the number of times min dist , wrapped around, using the counter nr wrap , which is stored as part of the snapshot. The value of nr wrap is incremented each time the newly received min dist is smaller than the corresponding value of the snapshot.

9.5

write cu tbl

Both purse and observer have (reserved space for) max curr balances, currency identiers and exchange rates. These data are stored in a currency table of the same format as in the -system, see Section 8.5. Again this protocol is similar to the one in the -system except that all signatures between observer and purse, and between purse and till are randomized, and that the purse checks all information sent to and from the observer. Note, that the validity of the cu tbl is determined by the observer only. The protocol is depicted in Figure 9.5.

9.6

gen cheque

The electronic cheques in the ; protocols are essentially the same as in the protocols, except that their generation (and the way they are spent) is now split between the observer and the purse. The role of the purse in the gen cheque-protocol is to blind the cheques that are withdrawn and thus guarantee their untraceability. The role of the observer is to \participate" suciently in the new cheque so as to make sure that the newly withdrawn cheque can only be spent with the consent of the observer. The purse's role thus amounts to blinding the special one-time signature issued by the observer as well as the issuer's signature on it, while the observer withholds enough secret information related to the one-time signature, as to make its presence in the subsequent payment protocol indispensable. The gen cheque protocol is depicted in Figure 9.6 it is repeated as long as the wallet accepts cheques. (It may of course also be aborted on the user's request). When generating the cheques the observer has to know the secret keys corresponding to each cheque (the 's). The purse is not allowed to know these values (because then it could recover the secret key of the observer from the transcript of a payment), but it must ensure that these are chosen at random| otherwise the bank can link the payments if it knows the random choices of the observer. The purse must blind 1 in a deterministic way in order to ensure that the same blinding factor is used in case the cheque must be recovered. This is 98

9.6 gen cheque


Observer

Purse

retrieve PIN

ur 2R ZZq ar aur r mod p

ar grr Pa cr mod p cr =? H(seq no , ID s , (cu tbl ), ? ar ) verify PIN reset cu tbl valid trans 0 increment seq no store cu tbl 0 , max dist wz 2R ZZwq az g z mod p ? uz 6= 0 mod q wz wz uz mod q az auz z mod p cz H(seq no , cu tbl 0 , ? az ) rz wz ; cz ss mod q

Reload station

update max dist ar warr 2R ZgZwqr mod p ;;;;;;;;; ? ur ur 6= 0 mod q ;;;;;;;; !; wr wr ur mod q ar aur r mod p cr H(seq no , ID s , rr , (cu tbl ), ? ar ) cu tbl 0 , rr wr ; cr Sa mod q max dist

display cu tbl 0 ; ;;;;;;;; accept cu tbl 0 ? c H ( seq no , ID , r s cr , rr , (cu tbl ), ? ar ) PIN , ? r c cu tbl 0 , ar = g r Pa r mod p max dist

; ;;;;;;;;

a

z ;;;;;;;; !; uz uz 2R ZZ q ;;;;;;;;; az auz z mod p

r

z ;;;;;;;; !; transp 0

increment seq no cz H(seq no , cu tbl 0 , ? az ) az =? grz pscz mod p store cu tbl 0

cz rz

;;;;;;;; ! ;increment seq no az grz ps cz mod p max dist p max dist cz =? H(seq no , 0

uw 2R ZZq aw auww mod p cw H(cz , cu tbl 0 , max dist , ? aw ) aw =? grw Pacw mod p

cw rw aw grw Pa cw mod p ; ;;;;;;; ; cw =? H(cz , cu tbl 0 , max dist , ? aw ) set cu tbl valid Figure 9.5:

cu tbl , ? az ) update , snapshot, account aw waww 2R ZgZwqw mod p ;;;;;;;;; ? uw uw 6= 0 mod q ;;;;;;;; !; ww ww uw mod q aw auww mod p cw H(cz , cu tbl 0 , max dist , ? aw ) rw rw ww ; cw Sa mod q ;;;;;;;;;

write cu tbl

99



Observer

Purse

cu tbl valid ? space for cheque? ? dist < max dist (mod 216 ) increment dist (mod 216 ) 11 , 21 , 12 , 22 ,

Reload station

space for cheque? ? dist p < max dist p (mod 216 ) 0 0 0 0 11 , 21 , 12 , 22 , u, v2R ZZq

3 2R ZZq 21 g11 h21 mod p 22 g12 h22 mod p 1 gc3 mod p 3 pc 3 mod p dist 21 22 1 3

;;;;;;;;;;;;;;;! ;? 1 62 f0 1g mod p

increment dist p (mod 216 ) geq dist ]? copy dist ] 0 3 H(1 dist p )dp mod Np mod q 21 21 g11 h21 mod p 22 22 g12 h22 mod p a0 b0 ;;;;;;;;; 3 1 1 mod p 3 33 mod p a a0 Gvc Pcu mod p b0 (b0 gcv puc )3 mod p 0

0

0

0

w0 2R ZZq a0 Gwc 0 mod p b0 gcw0 mod p

0 0

b b03 mod p

store (dist 0)

b0 ;;;;;;;;; b

;;;;;;;;!;

\OK"

c1 H(21 ) c2 H(22 ) c H(c1 c2 , ? a ab 1 3 ) c0 c ; u mod q c0 r r0 + v mod q a =? Grc Pcc mod p b ? 1r 3c mod p store (c r dist p ,0)

;;;;;;;; ! ; r0 r0 w0 ; c0 Sc mod q ;;;;;;;;;

;;;;;;;;; Figure 9.6:

100

0

gen cheque:

generate one new cheque

9.7 show currencies


done by using the result of an RSA secret key operation with modulus Np and a exponent pair (ep dp ). The public RSA key (ep Np ) is stored with the user's account during initialisation. The factorization of Np is only known to the user, and hence, it follows that the value of this blinding factor is unpredictable for anyone else. It is on this computational diculty that the user's privacy (the anonymity of the cheques) is based. In order for the RSA public key operation to be a bijective function, the RSA public keys have to be chosen such that gcd(ep (pp ; 1)(qp ; 1)) = 1, where pp and qp are the prime factors of Np . As knowledge of (pp ; 1)(qp ; 1) is equivalent to knowing the factorization of Np, a protocol in which the user proves the validity of the public keys to the bank without revealing the factorization of Np has to be executed during initialisation of the purse (see Part VI, Section 19.12.2). The purse should also ensure that the blinding factors for the blind signature (u and v) are random. As these values may be known to the purse they are chosen by the purse (this also saves computation in the observer). For compatibility with the -system it may however be convenient to also let the observer choose u and v and then just discard these (this is why it is assumed that the observer needs 7 random numbers for a cheque, see also Section 7.8). In the purse, a cheque is represented in memory by 43 bytes: 20 each for c and r, 2 for the index in the cheque sequence and 1 byte indicating how often it has been spent (thus it is initially 0). In the observer only 3 bytes are needed (indicating the index in the cheque sequence and the number of times it has been spent).

9.7

show currencies

The purpose of the show currencies protocol, given in Figure 9.7, is to present the contents of the currency table to the user. If the wallet has sucient display capabilities the information only needs to be sent to the purse otherwise a display on a terminal must be used. The value of payments can only be veried against an upper bound in the purse. If the unlocked amounts of the observer and the purse are dierent, the unlock amt protocol is called to make them equal again. Note that the show currencies protocol can only reach this point if cu tbl valid holds. Observer

Purse cu tbl , unlocked , payments

cu tbl valid ?

;;;;;;;;;;;;; !;

Figure 9.7:

show currencies:

if (:eq unlocked ]) call unlock amt eq cu tbl ]? ? payments payments p display it

show currencies

101


9.8


payment

The payment is shown in Figures 9.8, 9.9 and 9.10. Currency exchange is handled as in the -system except that now the user does not have to send its currency table to the payee. Using the display of the wallet it is possible to make the decision locally. Phone ticks are handled as in the -system by letting the observer and purse generate the -values mutually at random. Security requires that the balance is debited, irrespective of the success of the payment on the till's side, as otherwise one may gain money by interrupting payments. (A payment may go wrong after complete processing by the till, but before the wallet completed it.) Therefore, the balance used must be known at the next reset. This information is denoted \Ebal " it consists of sucient information to recover the exact balance. That is, its position in memory. The value of this balance is also addressed as \Ebal " (so in this case Ebal is the dereferenced pointer). In addition, one needs 1 , the amount, currency and date of the failed payment. A stable variable Epay contains the amount payable pay fro . For the currency cu fro , a special solution may be chosen: one may retrieve it from Ebal at reset (see also Chapter 8). Furthermore, the date of payment (date ) is stably stored. Finally, the stable counter tck cnt counts the multiplicity of the payment: for an ordinary payment this is meaningless for a phone tick payment it is the number of ticks (pay tck cnt ticks of pay fro each). The purse needs the same stable variables plus n, which is needed to check the value of tck cnt during recovery of a failed payment. Recovery of a failed payment is done in two steps. First, at the next execution of reset, the necessary information is saved in a \failed-payment-slot". Then, in the next withdrawal session (see Section 9.4) the rec payments protocol is called to process this information together with the bank. (This recovery is of course only performed in case the payment is interrupted.) This mechanism requires that the following information is available at the next reset (after interruption of a payment): 1. D and i corresponding to the cheque used in the interrupted payment. They identify the cheque used, and enable to reconstruct the observer's part.) These are automatically saved, since a cheque is stored in stable storage. One must make sure that it is still known which cheque was used, either by copying D (and i) explicitly in stable storage, or by storing a pointer to this cheque in stable storage. 2. The amount, currency and date of the interrupted payment. These are saved explicitly in stable storage, as explained above.

9.9

transfer

A user can transfer value from his ; wallet to his aliated wallet by means of the transfer protocol. The description of this protocol is given in Section 8.10 of the protocols. 102

9.9 transfer


Observer

cu tbl valid ? cheque available ? get cheque (D i)

j 3;i Ebal suitable balance ?

Ebal pay fro pay fro unlocked ? regenerate 11 , 21 , 12 , 22 , 3

21 g11 h21 22 g12 h22 1 gc3 mod p 3 pc 3 mod p mark cheque as spent i times

Purse

Till

cheque available ?

determine pay to , pay fro , cu to , cu fro , pay type ? pay to pay to , pay fro , max pay (cu to ) ? i D cu to , cu fro , ;;;;;;;;;;;;; !i 2 f1 2g ID pay type , fread min dist = Dg P , date display payee's info ;;;;;;;;;;;;;; Ebal suitable bal. ? Ebal pay fro pay fro unlocked ? geq min dist ]? copy min dist ] get cheque (c r min dist i) geq i]? copy i] pay to , pay fro , cu to , cu fro , ID P , pay type , date ;;;;;;;;;;;;;;j 3 ; i 0 0 regenerate 11 , 21 , 0 0 12 , 22

2j 2i 3 1

;;;;;;;;;;;; !

mark cheque as spent i times 21 21 g11 h21 22 22 g12 h22 c1 H(21 ) c2 H(22 ) 30 H(1 D)dp mod Np 1 13 mod q mod p 3 33 mod q mod p 0 ? 3 2i p) ;;;;;;;; ; 1 6 1r (mod a Gc Pcc mod p b 1r 3c mod p c =? H(c1 , c2 , ? , a, ab, i, c, r, cj , 2i , 3 , 1 1 , 3 ) 0

0

0

0

0 0

H(01e D) =?

3 p mod Np 3 30 mod q 1 13 mod p 0

0

Figure 9.8:

payment

;;;;;;;;;;;; !

(part 1)

103



Observer

if pay type = phone payment 0 2R ZZNphone T 02T mod Nphone hT H(T ) tT

Purse

if pay type = phone payment

0 2R ZZNphone

T 02T mod Nphone Epay p pay fro store date set pay busy p

?

Till

1 6 1 (mod p) a Grc Pcc mod p b 1r 3c mod p ci H(2i ) c =? H(c1 c2 , ? a ab 1 3 ) 2R ZZ232

;;;;;;;;; ;;;;;;;;; (hT ) ;;;;;;;;; ! ( T ) ;;;;;;;;; if pay type = phone payment T T T mod Nphone if pay type = phone payment m H(2i , 1 , pay to , tck cnt p 0 pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) 01 3 30 ss ; m1i mod q 02 3 30 ; m2i mod q

Epay pay fro store date if pay type = phone payment tck cnt 0 (T ) 01 02 set pay busy ;;;;;;;;; ! ; if pay type = phone payment hT =? H(T ) T T T mod Nphone m H(2i , 1 , pay to , pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) 1 01 ; m10 i mod q 2 02 ; m20 i mod q g1 h2 ? 1 2;im (mod p) (T ) 1 2 ! ; H(2i , 1 , pay to , if pay type = phone payment ;;;;;;;;; m tT pay fro , cu to , cu fro , ID P , T pay type , date , , ? (T )) 1 g h2 ? 1 2;im (mod p) if pay type = phone payment t T T if pay type = phone payment do phone-ticks \OK" ;;;;;;;;; decrease unlocked if pay type = phone payment Ebal Ebal ; tck cnt Epay store deposit record else Ebal Ebal ; Epay reset pay busy p \OK" ;;;;;;;;; decrease unlocked if pay type = phone payment Ebal Ebal ; tck cnt Epay else Ebal Ebal ; Epay reset pay busy Figure 9.9: payment (part 2)

104

9.9 transfer


Observer

Purse 0

ticks n

?

tn t t ;tn 02 mod Nphone (tck cnt + n) Epay unlocked ? ?

Ebal (tck cnt + n) Epay tck cnt tck cnt + n

;;;;;;;;;

;;;;;;;; ! ;

ticks n

store n ? tn t t ;t n

02 mod Nphone (tck cnt p + n) Epay p unlocked ? ? Ebal p (tck cnt p +n) Epay p

payment

;;;;;;;;;

0 ? (T ; t + n) pay to max pay (cu to ) ? tn tt;n

tck cnt p tck cnt p + n

mod p 0 ? 2n (mod Nphone )

Figure 9.10:

Till

;;;;;;;; !;

0 ? 2n (mod Nphone )

(phone ticks): pay n phone ticks costing Epay each

105


9.10


unlock amt

Observer

Purse PIN U

; ;;;;;;;;;; ;

if U > unlocked verify PIN unlocked U Figure 9.11:

unlock amt:

get PIN and amount U to be unlocked from user unlocked U

unlocking an amount on the wallet

The unlock amt protocol unlocks a user-specied amount unlocked in the wallet. It works as in the -system except that it is now done locally (see Figure 9.11).

9.11

update

The update protocol updates the public keys of the issuer in the wallet. For an explanation of the mechanisms, see Part VI. The protocol consists of two parts, that may be executed separately and independently. The rst part updates the issuer's authentication key Pa . This part is given in Figure 9.12. The second part updates the issuer's cheque-signing key Pc and the related wallet cheque key pc. This part is given in Figure 9.13. In both protocols a nal message \OK" indicates that the observer has received the keys. If the purse does not get this acknowledgment the protocol is repeated. Updating Pc requires the identity of the user. Before the wallet is willing to send this, the issuer must identify itself. As this is done for privacy reasons only the observer doesn't need to check this identication. Remark that the observer doesn't need Pc , and hence this key and its certicate are not forwarded to the observer. The randomized signature on pc guarantees that the keys Pa and pc installed in the observer are issued by the same issuer. To ensure that the nal parts of these update protocols between observer and purse can be repeated to recover from interruptions (see the get info protocol), Ea , CPa , and the randomized signature (cv rv ) on pc are also temporarily stored by the purse. Note that if, e.g., updateP a is interrupted before the observer has stored the new value for Pa , then this will be detected during the next reset when get info is executed.

9.12

get certif

The get certif protocol is given in Figure 9.14. For an explanation of the mechanisms, we refer to Part VI. The purse sends the keys and certicates 106

9.12 get certif


Observer

Reload/Recovery station

Purse

?

Pa , vBa , Ea , CPa

Pa , vBa , Ea , CPa

Verify certicate CPa with validity period Ea using public key (mN eN ) store vBa and Pa

vBa (wallet) < vBa (issuer)

;;;;;;;; Verify certicate CPa with validity period Ea using public key (mN eN ) store vBa , Pa , Ea , CPa

;;;;;;;;

\OK" ;;;;;;;! ; Figure 9.12:

updateP a:

updating Pa

107



Observer

Purse

Reload station

mu 2R ZZq

au gru Pacu

m

u ;;;;;;;; ! ;

mod p cu =? H(mu, ? au)

uv 2R ZZq av auv v mod p

c u ru

;;;;;;;;; ID

s ;;;;;;;; ! ;

retrieve ps corr. to ID s gc ps h mod p pc gcSc mod p store gcand pc wv 2R ZZq av ;;;;;;;;; av ? gwv mod p uv ;;;;;;;; ! ; uv 6= 0 mod q wv wv uv mod q av auv v mod p cv H(vBc , ? pc av ) r v Pc , vBc , wv ; cv Sa mod q Ec , CPc , pc, rv

;;;;;;;;;;;;;

av grv Pa cv mod p cv =? H(vBc , ? pc av ) store vBc , pc min dist dist + 1

vBc , pc, cv , rv

Verify certicate CPc with validity period Ec using public key (mN eN ) cv H(vBc , ? pc av ) av =? grv Pa cv mod p store vBc , Pc , CPc , pc, cv , rv min dist dist + 1

;;;;;;;;;

\OK"

;;;;;;;; !; Figure 9.13:

108

updateP c:

?

vBc (wallet) < vBc (issuer) wu 2R ZZq au gwu mod p cu H(mu, ? au ) ru wu ; cu Sa mod q

updating Pc

9.13 rec payments


Purse

Till ID B unknown ;;;;;;;;;;;;;;;;; Pc CPc ID NKCC vN ;;;;;;;;;;;;;;;;;! ; ID NKCC unknown ;;;;;;;;;;;;;;;;; mN eN CKN vC ;;;;;;;;;;;;;;;;; !

(ID B vBc) unknown ?

if (ID NKCC vN ) unknown then Verify certicate CKN using public key (mC eC ) Check validity period of (mN eN )

end if

Verify certicate CPc using public key (mN eN ) Check validity period of Pc Figure 9.14:

get certif:

retrieving Pc from the purse

needed in a payment to the till. The till veries these exactly as in the system. This protocol does not involve the observer.

9.13

rec payments

The rec payments protocol, shown in Figure 9.15, recovers failed payments. By the properties of reset the purse and observer have the same information about these payments. If one of the executions fails, reset must be executed before another attempt is made (in order to restore the consistency). The protocol is executed by the wallet and the issuer's reload station. It is repeated as long as the wallet contains failed payments that have to be recovered. The issuer must limit this number to its estimate of the number of possible payments. Moreover, if a wallet has too many failed payments, the issuer may decide to revoke it and issue a new one to the user. Due to the reset protocol, the observer balance has been decreased, even in case of a failed payment. The rec payments protocol must forward the information the bank needs to recognise the payment if it arrives due to deposit. If it does, nothing more happens if it does not arrive within a certain timespan after the date recorded in the payment, the user of the wallet is credited on his bank account for the amount in the payment. This is allowed, because obviously the payment failed for the payee too. The protocol just makes the observer sign all necessary data (by the special blinding or 1 the observer knows that it signs the correct data). The bank subsequently signs an acknowledgement. Finally, the wallet releases the memory used for the data. 109



Observer

Purse

Reload station

search failed payment (D i, Epay tck cnt , pay type cu fro date ) regenerate 3 from D 1 D i ? 1 gc3 mod p ;;;;;;;; ! ;1 62 f0 1g mod p search failed payment (D i, Epay tck cnt , pay type cu fro date ) 30 30 H(1 D)dp mod Np ;;;;;;;;;30 30 mod q H0(1 D0 ) =? 30 ep mod Np 3 3 mod q 1 13 mod p 1 13 mod p wp 2R ZZq ap ap gwp mod p ; ;;;;;;; ! ; ? up up 6= 0 mod q ;;;;;;;;;up 2R ZZq wp wup up mod q ap aup p mod p ap ap p mod p cp H(1 , i, Epay , pay type , tck cnt , cu fro , date , ? ap ) rp rp wp ; cp ss mod q ;;;;;;;; ! ;cp H(1 , i, Epay , pay type , tck cnt , cu fro , date , ? ap ) 1 , i, Epay , ap =? grp ps cp mod p pay type , tck cnt , cu fro , date , cp , rp ;;;;;;;;;;;;;;!; rp cp ap g ps mod p cp =? H(1 , i, Epay , pay type , tck cnt , cu fro , date , ? ap ) submit failed payment to clearing for recovery w 2 Z Z R k q ak a gwk mod p ;;;;;;;; ;k? u k uk 2R ZZq ;;;;;;;; ! ;uk 6= 0 mod q wk wuk uk mod q ak auk k mod p ak ak k mod p ck H(cp , ? ak ) rk rk wk ; ck Sa mod q ;;;;;;;;; ck H(cp , ? ak ) ? rk ck ak = g Pa mod p set rem pay c r k k ;;;;;;;; ; ak grk Pa ck mod p ck =? H(cp , ? ak ) nr fail pay nr fail pay ; 1 remove payment \OK" ;;;;;;;; ! ; nr fail pay nr fail pay ; 1 remove payment reset rem pay Figure 9.15: rec payments 0

0

110

9.14 recovery


9.14

recovery

Observer

Purse

Recovery station obtain ID s of lost wallet from user retrieve S NS for this wallet

S N

S ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

store S , NS reset recovery done not recovery done ? mq 2R ZZq

read dp from user

mq

mq

;;;;;;;; !;

min dist , max dist , nr wrap , ep, Np , gc , cq , rq

;;;;;;;; !;

aq wq 2R ZZwqq ;;;;;;;;;aq ? g mod p uq uq 2R ZZq ;;;;;;;; !;uq 6= 0 mod q wq wuq uq mod q aq auq q mod p aq aq q mod p cq H(mq , min dist ,max dist , nr wrap , ep , ? , Np , gc aq ) r q min dist , wq ; cq Sa mod q max dist , nr wrap , ep , Np , gc , rq cq H(mq , min dist , ;;;;;;;;; max dist , nr wrap , ep , ? , Np , gc aq ) aq =? grq Pa cq mod p

;;;;;;;; ;

aq grq Pa cq mod p ps gch;1 mod p ? dist min dist ; 1 cq = H(mq , min dist , max dist , nr wrap , ep , ? , Np , gc aq ) set recovery done dist min16 dist ; 1 S S 27(2 nr wrap +dist ) mod NS Figure 9.16:

retrieve snapshot, ep Np for this wallet wallet recovered ?

recovery

dist min dist ; 1

(part 1): recovering lost/broken wallet

The recovery protocol enables a user to use a new (replacement) wallet to recover money that was lost due to breakdown or loss of the old wallet. The protocol in Figures 9.16 and 9.17 can be used if both purse and observer must be recovered. In case it is easy to insert a new observer into a wallet this 111



Observer loop: all cheques

Purse loop: all cheques

?

dist < max dist (mod 216 ) dist dist + 1 mod 216 regenerate 3 2R ZZq 1 gc3 mod p

?

?

dist < max dist (mod 216 ) dist dist + 1 mod 216

1 ;;;;;;;; ! ;

0

H(1e dist ) =?

Reload station loop: all cheques

?

1 62 f0 1g mod p 30 H(1 dist )dp modNp

3 ;;;;;;;; ;

p

dist < max dist (mod 216 ) dist dist + 1 mod 216

30 30 mod q 1 13 mod p

3 mod Np 30 30 mod q 1 13 mod p w 2R ZZwq a a g mod p ;;;;;;;; ! ; ? u u 6= 0 mod q ;;;;;;;;;u 2R ZZq w w u mod q a au mod p a au mod p c H(rq , dist , ? , 1 a ) r w ; c ss mod q r ;;;;;;;; ! ; c H(rq , dist , ? , 1 a ) a =? gr ps c mod p c r 1 0

0

0

;;;;;;;; !;

endloop

endloop

112

endloop

credit (part of) value in cu tbl from snapshot to user submit all stored 1 to clearing set wallet recovered

remove S and NS

Figure 9.17:

a gr ps c mod p c =? H(rq dist , ? 1 a ) store 1

recovery

(part 2): submitting recovered cheques to clearing


9.15 deposit

protocol also works in case only the observer breaks down. If only the purse breaks down it is probably easiest to just use the protocol as if both parts must be recovered. The new wallet re-generates all cheques that might have been generated during the last withdrawal session. It then signs the data relevant to the bank for determining if a certain cheque has been spent. This is similar to rec payments, except that in that case, more data is known, such as amount, date and so on. In a recovery, one only knows the cheque keys. This allows the clearing system to recognise these cheques, so that the bank can be notied how much was spent using these cheques. Using the snapshot from the last withdrawal session, one can then determine how much money is left unspent in the wallet. If a wallet is going to be recovered, the associated `daughter' wallet must run authenticate in order to tell the bank how much money it has received from the wallet. If the wallet is not presented, the bank recovers both the and the ; wallet. The recovery protocol consists of two parts. First, the issuer installs the recovery seed S and modulus NS as stored with the user's bank account at initialization in the recovery observer prior to installation of the latter in the recovery wallet. Next, the recovery purse reads the secret RSA-exponent dp from the user. In the second part, the recovery wallet re-generates the relevant cheques, signs them and sends them to the bank. The new wallet must have the same system parameters as the old one. That is, it must have the same version number v . The wallet (i.e., observer and purse) must have a valid bank authentication key Pa . If this is not the case, the update protocol updateP a is executed (see also Section 4.4). The version of all other parameters (vBc most notably) are inconsequential in this protocol. There is no need to randomise the initial challenge, mq , as the new observer has no information to leak. If this protocol is interrupted, it is probably easiest to just restart the entire procedure.

9.15

deposit

The deposit protocol has not been changed with respect to that of Section 8.16. It is included for completeness in Figure 9.18. For a complete specication, see Part V.

113



Till

Acquire station ID P , ID 0B , ID B , v , vBc , i, 1 , 2i , 3 , r , c, cj , pay to , pay fro , tck cnt , cu to , cu fro , pay type , date , , (T , ), 1 , 2

;;;;;;;;;;;;;;;;;;;;;;;!;

Figure 9.18:

114

retrieve parameters corr. to ID B , v , vBc parameters still valid ? deposit timely ? used rate valid ?? tck cnt pay to max pay (cu to ) ? 1 6 1 (mod p) a Grc Pcc mod p b 1r 3c mod p ci H(2i ) c =? H(c1 c2 , ? a ab 1 3 ) if pay type = phone payment 2tck cnt ? T (mod Nphone ) m H(2i , 1 , pay to , pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) g1 h2 ? 1 2;im (mod p) submit (ID p m) to double-deposit check credit tck cnt pay to to account of ID P at bank ID 0B submit (i 1 ) to double-spending check

deposit:

depositing one payment


Appendix A

List of Identiers in the Protocols identier

nr of bytes meaning

p q g h Gc gc pc ps ss po so Pa Sa Pc Sc Nphone mC eC dC mN eN dN ID s ID B ID P ID NKCC ID CKCC

|system parameters, keys, ID's| 64, 20 large primes such that q j p ; 1 64, 64 generators 64, 64, 64 generators used for cheques 64, 20 key pair of wallet 64, 20 key pair of ; `mother' wallet 64, 20 bank's authentication key pair 64, 20 bank's cheque issuing key pair 64 modulus used in phone tick payments 64, 1, 64 central certication centre's keys, eC = 5 64, 1, 64 realm certication centre's keys, eN = 3 8, 8, 8 identities of wallet, issuer, till 8, 8 identities of realm and central key certication centres

v vBa vBc vC vN

1 1 1 1 1

NS S S2

64 64, 64 2 1 2 2 2 20

min dist nr wrap

D

dist max dist hash seed

|version numbers (see Part VI)| { of system parameters p, q, g, h, Gc , Nphone { of bank's authentication key set { of bank's cheque issuing key set { of central certication centre's key set { of realm certication centre's key set |PRSG| modulus for the wallet's PRSG seeds for the wallet's PRSG index of oldest (partly) unspent cheque (cf. 8.4) number of times min dist wrapped around index of cheque currently used or loaded index of last generated cheque (cf. 8.4) upper bound on dist (cf. 8.4) hash of seed's S initial value and of NS

115

Appendix A: List of Identi ers in the Protocols


identier

nr of bytes

meaning

pay busy pay type nr fail pay tck cnt Ebal max bal Epay unlocked

1 1 1 1 3 3 3 3

|reset| !ag: is a payment going on? indicates type of payment number of failed payments number of phone ticks balance, see 8.9 maximal allowable balance, see 4.4, 8.10 amount payable, see 8.9 unlocked amount, see 8.11

mb wb ab cb rb

20 20, 64, 20, 20 2 2 8 max curr 1 3 11 + 8max curr

PIN seq no cu tbl cu tbl valid trans state

ws as cs rs

20, 64, 20, 20 wallet recovered 1

wr ar cr rr

20, 64, 20, 20

wz az cz rz

20, 64, 20, 20

ww aw cw rw

20, 64, 20, 20

|authenticate| random number selected by wallet signature by bank using Sa on \mb, ?" PIN entered by the user number of transactions at the bank currency table, see 8.5 !ag: the validity of cu tbl the total amount transferred by transfer (seq no , cu tbl valid , trans , min dist , dist , nr fail pay , ?, cu tbl ) signature by wallet using ss on \cb , state , ?" !ag: has wallet already been recovered? |write cu tbl| signature by bank using Sa on \seq no , ID s , (cu tbl ), ?" signature by wallet using ss on \seq no , cu tbl 0 , ?" signature by bank using Sa on \cz , cu tbl 0 , max dist , ?" |gen cheque|

w0 (a0 b0 ) c0 r0 20, (64, 64), 20, 20 two signatures on a cheque by bank using bases (Gc gc) and secret key Sc 11 21 20, 20 secret cheque keys corresp. to 21 12 22 20, 20 secret cheque keys corresp. to 22 3 20 secret cheque key corresp. to 1 , 3 u v 20, 20 random numbers that blind c and r 1 21 22 64, 64, 64 2-spendable cheque 3 64 part of signature on a cheque 3 = 1Sc c1 c2 20, 20 hash values of 21 , 22 (a b) c r (64, 64), 20, 20 blinded versions of (a0 b0 ) c0 r0

116

List of Identi ers in the Protocols


identier

nr of bytes meaning

payments

2

|show currencies| number of possible payments by wallet

pay to pay fro cu to cu fro pay type date max pay (cu )

Nphone

0 T T t n

3 3 2 2 1 3 3 1 1 64 64 20 20 4 20, 20, 20 1 1 64 64, 64, 64 1 1 1

|payment| amount payable in payee's currency amount payable in payer's currency ISO code for the payee's currency ISO code for the payer's currency indicates type of payment date maximum allowed amount payable for currency cu indicates ith spending of cheque complement of i (j = 3 ; i) part of cheque used in ith spending part of cheque not used in ith spending hash value of 2i hash value of 2j random input for challenge m one-time signature on (1 2i ) maximum number of currencies in the wallet value of pay type that indicates a phone tick payment modulus for one-way function See 8.9 maximum number of phone ticks per payment See 8.9 number of ticks paid at once, cf. 8.9

trans o

3

trans p trans s max trans Xfer trans log o trans log p trans log s

3 3 3 3 23 23 20 20

i j 2i 2j ci cj m 1 2

max curr

phone payment

mt

|transfer| the cumul. amount transferred by transfer as stored in the `mother' ; observer trans of `mother' ; purse trans of `daughter' wallet upper bound to trans value transferred in transfer logging of transfer of ; observer: (y Xfer ) or logging of transfer of ; purse: (y Xfer ) or logging of transfer of wallet: x or challenge

117

Appendix A: List of Identi ers in the Protocols


identier

nr of bytes meaning

y x wt at ct rt wa aa ca ra wi ai ci ri

20 20 20, 64, 20, 20 20, 64, 20, 20 20, 64, 20, 20

commitment by wallet value committed to by wallet (y = H(x)) signature by ; observer using so on \mt , Xfer , ?" signature by wallet using ss on \ct , y, ?" signature by ; observer using so on \ca , ?"

unlocked

U

3 3

|unlock amt| unlocked amount, see 8.11 proposal for new unlocked -value

CPa Ea

64 6

|update| certicate of Pa validity period of Pa

mu wu au cu ru CPc Ec wv av cv rv

20 20, 64, 20, 20 64 6 20, 64, 20, 20

random number selected by wallet signature by bank using Sa on \mu , ?" certicate of Pc validity period of Pc and pc signature by bank using Sa on \vBc, ?, pc "

CKN

64

|get certif| certicate on realm certication centre's key set by central certication centre |rec payments|

wp ap cp rp 20, 64, 20, 20 signature by wallet using ss on \1 , i, Epay , pay type , tck cnt , cu fro , date , ?" wk ak ck rk 20, 64, 20, 20 signature by bank using Sa on \cp , ?" |recovery| recovery done 1 !ag: has a recovery taken place? mq 20 random number selected by wallet wq aq cq rq 20, 64, 20, 20 signature by bank using Sa on \mq , hash seed , min dist , max dist , nr wrap , ?, gc " w a c r 20, 64, 20, 20 signature by wallet using ss on \rq , dist , ?, 1 "

118


Appendix B

List of Identiers in the ; Protocols identier

nr of bytes meaning

p q g h Gc gc pc ps ss Np ep dp Pa Sa Pc Sc Nphone mC eC dC mN eN dN ID s ID B ID P ID NKCC ID CKCC

|system parameters, keys, ID's| 64, 20 large primes such that q j p ; 1 64, 64 generators 64, 64, 64 generators used for cheques 64, 20 key pair of observer 64, 1, 64 RSA modulus and key pair of purse 64, 20 bank's authentication key pair 64, 20 bank's cheque issuing key pair 64 RSA modulus for phone tick payments 64, 1, 64 central certication centre's keys, eC = 5 64, 1, 64 realm certication centre's keys, eN = 3 8, 8, 8 identities of wallet, issuer, till 8, 8 identities of realm and central key certication centres

v vBa vBc vC vN

1 1 1 1 1

NS S S2

64 64, 64 2 1 2 2 2

min dist nr wrap

D

dist max dist

|version numbers (see Part VI)| { of system parameters p, q, g, h, Gc , Nphone { of bank's authentication key set { of bank's cheque issuing key set { of central certication centre's key set { of realm certication centre's key set |PRSG| modulus for the observer's PRSG seeds for the observer's PRSG index of oldest (partly) unspent cheque (cf. 9.4) number of times min dist wrapped around index of cheque currently used or loaded index of last generated cheque (cf. 9.4) upper bound on dist (cf. 9.4)

119

Appendix B: List of Identi ers in the ; Protocols


identier

nr of bytes

meaning

pay busy pay type nr fail pay tck cnt tck cnt p Ebal max bal Epay unlocked rem pay

1 1 1 1 1 3 3 3 3 1

|reset| !ag: is a payment going on? indicates type of payment number of failed payments number of phone ticks number of phone ticks as recorded by purse balance, see 9.8 maximal allowable balance, see 4.4, 8.10 amount payable, see 9.8 unlocked amount, see 9.10 !ag: a payment is being removed, see 9.13

wb ab ub cb rb PIN seq no cu tbl cu tbl valid trans state

ws as us cs rs wallet recovered

|authenticate| 20, 64, 20, 20, 20 randomized signature by bank using Sa on the empty message 2 PIN entered by the user 2 number of transactions at the bank 8 max curr currency table, see 9.5 1 !ag: the validity of cu tbl 3 the total amount transferred by transfer 11 + 8max curr (seq no , cu tbl valid , trans , min dist , dist , nr fail pay , ?, cu tbl ) 20, 64, 20, 20, 20 randomized signature by observer using ss on \cb , state , ?" 1 !ag: has wallet been recovered?

|write cu tbl| 20, 64, 20, 20, 20 randomized signature by bank using Sa on \seq no , ID s , (cu tbl ), ?" wz az uz cz rz 20, 64, 20, 20, 20 randomized signature by observer using ss on \seq no , cu tbl 0 , ?" ww aw uw cw rw 20, 64, 20, 20, 20 randomized signature by bank using Sa on \cz , cu tbl 0 , max dist , ?"

wr ar ur cr rr

|gen cheque|

w0 (a0 b0 ) c0 r0 20, (64, 64), 20, 20 two signatures on a cheque by bank using bases (Gc gc) and secret key Sc 11 21 20, 20 secret cheque keys of observer corresp. to 21 12 22 20, 20 secret cheque keys of observer corresp. to 22 0 0 11 20, 20 blinding by purse of 21 21 0 0 12 20, 20 blinding by purse of 22 22 3 20 blinding by purse of 1 , 3 u v 20, 20 random numbers that blind c and r 1 21 22 64, 64, 64 2-spendable cheque 3 64 part of signature on a cheque 3 = 1Sc

120

List of Identi ers in the ; Protocols


identier

nr of bytes

c1 c2 (a b) c r

20, 20 hash values of 21 , 22 (64, 64), 20, 20 blinded versions of (a0 b0) c0 r0

payments payments p

2 2

|show currencies| number of possible payments by observer number of possible payments as recorded by purse

pay to pay fro cu to cu fro pay type date max pay (cu )

Nphone

0 T 0 T T t n

3 3 2 2 1 3 3 1 1 64 64 20 20 4 20, 20, 20 20, 20 1 1 64 64, 64, 64 64, 64, 64 1 1 1

|payment| amount payable in payee's currency amount payable in payer's currency ISO code for the payee's currency ISO code for the payer's currency indicates type of payment date maximum allowed amount payable for currency cu indicates ith spending of cheque complement of i (j = 3 ; i) part of cheque used in ith spending part of cheque not used in ith spending hash value of 2i hash value of 2j random input for challenge m fail-stop signature on (1 2i ) observer's contribution to fail-stop signature maximum number of currencies in the wallet value of pay type that indicates a phone tick payment modulus for one-way function See 9.8 See 9.8 maximum number of phone ticks per payment See 9.8 number of ticks paid at once, cf. 9.8

trans o

3

trans p trans s max trans Xfer trans log o trans log p trans log s

3 3 3 3 23 23 20

i j 2i 2j ci cj m 1 2 01 02

max curr

phone payment

meaning

|transfer| the cumul. amount transferred by transfer as stored in the `mother' ; observer trans of `mother' ; purse trans of `daughter' wallet upper bound to trans value transferred in transfer logging of transfer of observer: (y Xfer ) or logging of transfer of purse: (y Xfer ) or logging of transfer of wallet: x or

121

Appendix B: List of Identi ers in the ; Protocols


identier

nr of bytes

meaning

mt y x wt at ct rt wa aa ca ra wi ai ci ri

20 20 20 20, 64, 20, 20 20, 64, 20, 20 20, 64, 20, 20

challenge commitment by wallet value committed to by wallet (y = H(x)) signature by observer using so on \mt , Xfer , ?" signature by wallet using ss on \ct, y, ?" signature by observer using so on \ca , ?"

unlocked

U

3 3

CPa Ea

64 6

|update| certicate of Pa validity period of Pa

mu wu au cu ru CPc Ec wv av uv cv rv

20 20, 64, 20, 20 64 6 20, 64, 20, 20, 20

random number selected by purse signature by bank using Sa on \mu , ?" certicate of Pc validity period of Pc and pc randomized signature by bank using Sa on \vBc , ?, pc "

CKN

64

|unlock amt| unlocked amount, see 9.10 proposal for new unlocked -value

|get certif| certicate on realm certication centre's key set by central certication centre |rec payments|

wp ap up cp rp 20, 64, 20, 20, 20 randomized signature by observer using ss on \1 , i, Epay , pay type , tck cnt , cu fro , date , ?" wk ak uk ck rk 20, 64, 20, 20, 20 randomized signature by bank using Sa on \cp , ?" |recovery| 1 !ag: has a recovery taken place? mq 20 random number selected by observer wq aq uq cq rq 20, 64, 20, 20, 20 randomized signature by bank using Sa on \mq , min dist , max dist , nr wrap , ep , ?, Np , gc" w a u c r 20, 64, 20, 20, 20 randomized signature by observer using ss on \rq , dist , ?, 1 " recovery done

122


Part IV

Security Evaluation

123


Chapter 10

Security Evaluation of Basic Primitives The application of digital signatures, and in particular blind signatures, is central to the proposed payment systems. This section analyses these signature schemes as well as other cryptographic primitives which are used. More precisely, the security of the following primitives will be investigated: Schnorr signatures. Blind signatures. Randomised Schnorr signatures (used in the ; system). RSA signatures, which are used in certicates and in the ; protocols for unique randomisation of cheques. The one-way function used in tick payments. The pseudo-random bit/number generator The hash function This chapter is organised in three sections. In the rst, the primitives, where the security depends on the discrete logarithm assumption, are analysed (the rst three in the above list), then the following three are investigated in a section dealing with the factoring assumption and nally the security of the hash function is discussed.

10.1 Discrete Logarithms This section rst considers the diculty of computing discrete logarithms and then the three primitives based on this problem are analysed.

10.1.1 The Discrete Logarithm Assumption

Let p be a prime and let g0 be a generator of ZZp . The discrete logarithm assumption (DLA) says that it is hard1 to invert the mapping:

f0 1 : : : p ; 1g ! ZZp

given by x 7! g0x :

1 Here

and in Section 10.2 \hard" means that no algorithm can solve the problem with non-negligible probability in polynomial time in the length of the input numbers.

125

Chapter 10: Security Evaluation of Basic Primitives


The problem of inverting this function will be called the discrete logarithm problem (DLP). The certied discrete logarithm assumption (CDLA) says that this problem remains hard if the factorisation of p ; 1 is also given as input (this problem will be denoted CDLP). As we shall see both of these assumptions require that p ; 1 has a large prime factor. We need another assumption, which in the following will be called the special discrete logarithm assumption (SDLA). Let q be a publicly known, large prime dividing p;1, and let g generate the subgroup of ZZp of order q.2 The assumption says that it is hard to solve the special discrete logarithm problem (SDLP), namely inverting the mapping

f0 1 : : : q ; 1g !

given by x 7! gx :

Relation Between these Problems

Consider the SDLP. Usually q will be the largest prime dividing p ; 1 and in that case the factorisation of p ; 1 can often be computed relatively easy. Therefore when solving an instance of SDLP it can in most cases be assumed that the complete factorisation of p ; 1 is given. SDLP is in such cases not harder than CDLP which again is not harder than DLP. Next, solving CDLP is not harder than solving SDLP for each prime factor p ; 1 (since the solutions for each subgroup can be combined). Hence, assumption CDLA implies that at least for some prime factors of p ; 1 is SDLP a hard problem, and if q is a suciently large prime factor of p ; 1, SDLA is reasonable. Finally, in most cases (depending on the distribution) it is easy to factor p ; 1, and in these cases CDLA is obviously equivalent to DLA. There are exceptions to this however: Brickell and McCurley present in BM92] an identication scheme based on arithmetic modulo a prime, p, for which p ; 1 is hard to factor.

The Di e-Hellman Assumption

Die and Hellman were the rst to use the discrete logarithm assumption (in DH76]). More, precisely, they needed the following assumption: Given p, g0 , g0x and h 2 it is hard to nd hx . This is a stronger assumption than DLA. For primes p for which the factorisation of '(p ; 1) contains only small prime factors (' is Euler's totient function) this assumption is equivalent to DLA (see Boe90]). In Mau94] this proof was generalised to a larger class of primes, but in general it is not known whether the two assumptions are equivalent. In the payment systems we need the corresponding assumption in : Given p, q, g, gx and h 2 it is hard to nd hx . 2 In

this chapter g0 will be assumed to generate ZZp , while g will generate the subgroup of known prime order, q.

126


10.1 Discrete Logarithms

We shall not discuss this assumption further, as it can be considered reasonable under assumption SDLA.

Algorithms for Solving DLP In this section, the most ecient, published algorithms for computing discrete logarithms (solving DLP) are briey reviewed. This is based on the surveys McC90] and Roo91] which consider the following algorithms:

Baby-step, giant-step

Pollard's algorithm

Pohlig-Hellman algorithm

Index calculus method (ICM)

{ { { {

The basic method The linear sieve Gaussian integers The residue list sieve

It is outside the scope of this report to describe these algorithms. The above mentioned reports contain some details plus references to the full descriptions. Table 10.1 summarises the eciency of these algorithms in terms of running time (most of the algorithms also need a lot of storage). The Pohlig-Hellman algorithm and the index-calculus method consist of a pre-processing phase (actually two stages in ICM) used to generate information (only depending on p and g0 ), and an actual computation phase which given h outputs x such that h = g0x. This table shows why p ; 1 must have at least one large prime factor (otherwise the Pohlig-Hellman algorithm would be ecient). It is concluded in Roo91], that these algorithms are not able to solve DLP for primes of length 512 bits in reasonable time, and systems based on such primes will be secure against these algorithms in the near future. However, more ecient algorithms might be possible. E.g., if it is possible to adapt the number eld sieve method for factoring, an algorithm with (heuristic) running time

exp c(ln p1=3 (ln ln p)2=3 ) can be expected. Therefore, to obtain long term security, Odlyzko and LaMacchia suggest using primes of length 1024 (see LO91]).

Solving SDLP No special algorithm for solving SDLP is published in the open literature. Obviously, the algorithms mentioned above solves SDLP. The interesting question is, however, if it is possible to do better given that g generates a subgroup of order q. 127



The giant-step, baby-step algorithm and Pollard's algorithm depend only on the order of the group. Hence, the running time of these algorithms are of the order pq log q. For q 2160 , pq log q is around 287 . Since the asymptotic running times given in Table 10.1 are reasonable for the large numbers used in CAFE, this indicates that these algorithms will not be feasible within the next many years (this also shows why q must be large). The running time of the Pohlig-Hellman algorithm with n = q is of the same order. So the question remains whether the index calculus method, can be improved given that g generates a subgroup of order q. The basic idea of this method (in the general case) is to nd during pre-processing the discrete logarithms of the smallest primes with respect to g0 (by generating a number of equations and solving these). In the computation phase the discrete logarithm of h is computed from these by factoring hg0e (for random choices of e), and then combining the discrete logarithms found in the pre-processing phase according to this factorisation. This will give the required result if all prime factors are small. Very briey, the various algorithms dier in the way the equations are generated in the pre-processing. When trying to use this method in , the rst problem is that some of the primes are not in this group. It might be possible to get around this problem by raising the product to a suitable power (e.g., p q 1 ). However, even if this is possible, it is not clear that the algorithms will run faster. The running time depends on the size of the numbers (because this determines the probability that a random element has only \small" prime divisors). But most of the elements of will be as large as in the general case (i.e., jpj-bits). Thus for the moment we have no reason to believe that an ;

Algorithm Preprocessing Computation

Baby-giant1) O n1=2 log n

Pollard1)3) O n1=2 log n

P P Pohlig-Hellman1)2) O ( log n + pri i log pri i ) O ci (log n + p1i ri (1 + log pri i )) ICM: Basic4) L(p) 2+o(1) L(p)1= 2+o(1) ICM: Linear3)4) L(p)1+o(1) L(p)1=2+o(1) ICM: Gaussian3)4) L(p)1+o(1) L(p)1=2+o(1) 3) 4) 1+ o (1) ICM: Residue L(p) L(p)1=2+o(1) ;

p

Notes: 1) n denotes the order of the generator 2) n = pc11 pckk 0 < ri < 1 for i = 1 2 : : : k. The sums are over i. 3) Heuristic analysis ;p of the complexity 4) L(p) = exp ln p ln ln p Table 10.1: Asymptotic running time for DLP algorithms

128

p



adoption of the ICM will run signicantly faster on instances of SDLP than on instances of DLP. In conclusion we can say that SDLA is reasonable for the following reasons:

An ecient algorithm for solving SDLP would lead to an ecient algorithms for DLP in many practical cases.

No special algorithm solving SDLP has been published, and the existing algorithms for DLP do not seem suciently ecient to solve SDLP.

Previously proposed systems relying on SDLA have not been broken (at least not by solving SDLP), and in particular the security of the Digital Signature Standard proposed by NIST (see DSS94]) has received much attention recently.

Finally, under SDLA it is reasonable to assume that the Die-Hellman problem is hard in subgroups of prime order.

10.1.2 Security of Schnorr Signatures

The digital signatures used for identication and signing updated currency tables are from Sch91]. As these signatures are based on the (presumably secure) proof of knowledge shown in Figure 7.1 (see Sch91]) they can be assumed secure (in the sense of GMR88]) under SDLA if the hash function is collision-free and also has some pseudo random properties. In Section 10.3 it is argued that the hash function used in CAFE, satises these properties. Thus, the following assumption is reasonable:

Assumption 10.1 The Schnorr signature scheme is secure against existential forgery under adaptively chosen message attacks.

10.1.3 The Blind Signature Scheme

The blind signature scheme must have two properties. First, it must be secure against forgeries and, second, the protocol for obtaining blind signatures must not leak any information about the blinded message and signature to the signer (which, in CAFE, is the bank). The blinding in the ; system is somewhat more involved than in the system, since the purse must prevent the observer from sending information to the bank encoded in the blind signature or using the blind signature protocol as a subliminal channel. In the following only the basic blind signature protocol (as depicted in Figure 7.4) is discussed. For the application to the payment systems (in particular the ; system) we refer to Chapter 8 and 9.

Security Against Forgeries The signature scheme is based on the interactive proof of knowledge shown in Figure 7.3 of S satisfying P = gS and z = mS (the basic proof). The triple 129



(z c r) is a valid signature on m if c = H(m z gr P c mr z c): The security of the signature scheme depends on the hash-function, which must be collision-resistant and have some pseudo-random properties (see also FS87]). Since the basic proof is secure in the same sense as that underlying the Schnorr signature scheme it is reasonable to make the following assumption in line with Assumption 10.1 Assumption 10.2 The hash-function, H, can be chosen such that the signature scheme implied by the blind signature scheme (by removing interaction) is secure against existential forgery under adaptively chosen message attacks. However, this assumption is not sucient for the security of the blind signature scheme, since the bank is not only making signatures, it also interacts with the user during this process. Next it is argued that the bank does not reveal any usable information about its secret key allowing forgeries during the blind signature process. Consider the modication of the basic proof system in which the challenge, c, is chosen from a subset A ZZq instead of ZZq . For any such subset an execution of the modied scheme can be simulated perfectly in expected time O(jAj). In particular this simulation is feasible if jAj is polynomial in jqj (given z ). Since this holds for every subset A this shows that there is no particular bad challenge, which would enable the user to learn anything about the bank's secret key during the proof. It is an open question to prove that executions of the protocol are secure, when A equals ZZq , but in light of the above we conjecture that no matter which c 2 ZZq is chosen as challenge, the signer reveals no information but the fact that logg P equals logm z . In particular the signer does not reveal sucient to allow a forger to make a new signature (and hence nd S ). Until now we have argued that the blind signature scheme is secure and that the interaction does not reveal information about the secret key. However, the interaction does allow the user to obtain a signature on a blinded message, m. This raises two questions: Is the user able to blind m dierently? Is it possible to obtain more than on signature during the blind signature protocol? In order to answer these questions the following assumption is used: Assumption 10.3 For all messages m and all correct signatures (z c r) on m the following holds: logg P = logm z: This assumption is reasonable since, by the pseudo randomness of H (see Section 10.3) and the fact that the basic proof is a proof of knowledge, it is infeasible to make a signature (z c r) on m unless logg P = logm z . The next assumption answers the two questions raised above: 130



Assumption 10.4 The receiver can only obtain one signature in the blind sig0 nature protocol. This signature is on a message, m, of the form mt0 gt , where the receiver chooses t t 2 ZZq . 0

Why is this reasonable? First recall that (a0 b0 ) satises

a0 = gr0 P c0

and

b0 = mr00 z0c0 :

Given a signature (z c r) on a message m and the messages (a0 b0 c0 r0 ) from the blind signature protocol we can dene u and v by

u = c ; c0

and

v = r ; r0 :

This pair (u v) satises

a = a0 gv P u = gw+v+Su and hence b = mw+v+Su . The only information Alice has about w when constructing (a b) is gw and mw0 . In order to construct (a b) of this form and be able to nd z = mx , it is0 reasonable to assume that Alice chooses t t 2 ZZq , computes m as m = mt0 gt and then in the blind signature protocol nds 0

a = a0 gv P u

b = (b0 mv0 z0u )t at0

and

z = z0t P t0 :

These arguments also indicates that it does not help several users to execute the withdrawal simultaneously in order to get a signature on a message of a dierent form, because each execution of the withdrawal uses an independently chosen value of w. Assuming that a receiver, Alice, can only obtain a blind signature in this particular way it also follows that she cannot obtain two blind signatures from one execution of the protocol. Namely, suppose she can get a signature (zi ci ri ) on mi for i = 1 2. Then, by the collision-resistance of H it can be assumed c1 6= c2 . Let (ui vi )i=12 , be the (u v)-pair selected by Alice in the two cases. Then it is very likely that c1 ; u1 6= c2 ; u2 in which case it is presumably hard to get both signatures from one execution of the protocol.

Blinding Property During the blind signature protocol the bank gets a view (see GMR89]) consisting of the random coins used, and the messages (a0 b0 c0 r0 ). The following proposition shows that this view does not contain any information about the blinded message-signature pair.

Proposition 10.1 Under Assumption 10.3 the following holds. For every mes-

sage, m, and every possible signature (z c r) on m it is possible that this signature could correspond to a given view of the bank.

131



Proof: Let a view ( a0 b0 c0 r0 ) of the bank be given, where denotes the random bits chosen by the bank. Given (m z c r) we can dene

u = c ; c0 mod q v = r ; r0 mod q t = logm0 m Dene

a = gr P c mod p and b = mr z c mod p: All we have to show is that u, v, a and b satisfy: z = mt a = a0 gv P u mod p and b = (b0 mv0 z0u)t mod p: The requirement related to z is satised due to Assumption 10.3. Since,

a0 = gr0 P r0 mod p the second requirement follows from

a = gr P c = gr0 +v P c0 +u = a0gv P u: The third requirement follows from similar rewritings.

2

10.1.4 Randomised Signatures

In the ; system all signatures passing from the observer to the outside (bank) and vice versa are randomised by the purse as shown in Figure 7.6. The randomisation is included to prevent the signer and receiver from using the signature protocol as a subliminal channel. Two aspects of randomisation are important. First, it should prevent the subliminal channel as mentioned above, and, second, it should not make it easier to forge signatures. First, if (c r) is a signature on the message m with respect to the generators g and P , the randomisation ensures that the number a = gr P s mod p is uniformly distributed in . Note, that even a signer with unlimited computing power cannot enforce any other distribution of a. The numbers c and r are uniquely determined from m, a and the public key. Second, since the security of the signature scheme depends on a being totally random (e.g., if logg a is known the secret key can be found) the randomisation, could be dangerous for the signer. However, the purse can only enforce a nonuniform distribution by trying to guess some bits of w. However, this seems to be just as hard as guessing some bits of the secret key.

10.2 Primitives Using the Factoring Assumption RSA signatures, the pseudo-random generator and the encoding of ticks are all based on the intractability of factoring large integers. This assumption will be discussed very briey rst. 132


10.2 Primitives Using the Factoring Assumption

10.2.1 Factoring Assumption

As noted in Section 10.1.1, the index calculus method exploits the fact that it is possible to factor integers with only small prime factors. However, no general, ecient (polynomial time) algorithm is known for factoring integers with at least two large prime factors. In particular, products of two large primes are considered among the hardest instances. Let p and q denote two large primes, and let n = pq be the product of these. Ecient algorithms are known for factoring, n, if p and q satisfy certain properties. In order to avoid these it is suggested in BBB+ 95] to require that p and q be of approximately the same bit length, but the dierence p ; q should not be less than 275 . p ; 1, p + 1, q ; 1 and q + 1 all have a large prime factor (at least 75 bits). The choice of 275 was made in BBB+ 95] as a threshold for what can be considered possible today (and in the near future). An integer satisfying these requirements will therefore be called a RIPE-composite in the following. Payment for phone ticks makes use of squaring modulo such composites. In order to make sure that this mapping has large order, BBB+ 95] requires that If rp and rq are large prime factors of p;1 and q ;1, respectively, then both rp ; 1 and rq ; 1 should have a large prime factor, tp and tq , respectively, such that the product tp tq is at least 275 and 2(rp 1)=tp 6 1 mod rp ;

and

2(rq 1)=tq 6 1 mod rq : ;

Under these constraints it is reasonable to assume and rely on the factoring assumption: Given n = pq where p and q are both large primes as above, it is computationally infeasible to nd p and q. The question remains how large n (and hence p and q) should be in this assumption. Since the rst application of the factoring assumption (in RSA78]) it has been assumed that 512 bits (155 digits) are sucient for n. Due to hardware constraints, CAFE uses this length of modulus, but it must be expected that in the very near future, it is necessary to use 768 bits or, for long term security, 1024.

10.2.2 RSA Signatures

RSA signatures are used in certicates and to ensure unique randomisation of cheques in the ; system (see gen cheque). The security of RSA signatures has not been proven to follow from the intractability of factoring, but it is widely believed, that it is hard to forge RSA signatures (in combination with a suitable hash function) without factoring the modulus or breaking the hash function. Hence, based on the factoring assumption it is reasonable to assume that certicates cannot be forged. 133



The application to randomisation requires that it is hard to compute the secret RSA function, as argued above a reasonable assumption, and that the this function is one-to-one. In Chapter 19.12.2 it is shown how this property can be ensured.

10.2.3 One-way Function Encoding Phone Ticks

Let Nphone be a RIPE-composite of length 512 bits. The function

f : ZZNphone

! ZZNphone

given by f : x 7! x2 mod Nphone

is used to encode the amounts paid in phone ticks. Inverting this function is equivalent to factoring Nphone (see Rab79]). Thus under the factoring assumption, this mapping is a one-way function.

10.2.4 The Pseudo-Random Generator

The pseudo-random generator depends on the infeasiblity of predicting the last k bits of x given x2 mod N . In ACGS88] it is shown that asymptotically given x2 mod N , the O(log2 log2 N ) least signicant bits of x are simultaneously secure. This means that even if some of these bits are known it is hard to nd the rest essentially better than by guessing at random (unless N can be factored). This result has two consequences: Forward unpredictable: If S is not known the sequence of bits produced by the above method is unpredictable for this value of k. Backward unpredictable: Given f i+1 (S ) for some i it is hard to nd Rj for 0 j i. Thus, f i+1 (S ) can be revealed without compromising previously generated bits. In CAFE k is chosen as k = 176. This gives more bits for each squaring than suggested in ACGS88]. Based on work by Micali and Schnorr (see MS91]), BBB+ 95] argues that it is reasonable to assume that the k least signicant bits of x are still simultaneously secure given x2 mod N . Thus the pseudo-random sequence is both forward and backward unpredictable.

10.3 Security of the Hash Function The hash function, H, is important for the security of the signature schemes (e.g., see Assumption 10.1 and 10.2). As the function is a special mode of RIPEMD BBB+ 95]), the security properties of RIPEMD are described rst. It is then argued that H has the necessary properties.

10.3.1 Security of RIPEMD

In BBB+ 95] the security of RIPEMD is investigated with respect to collisionresistance and statistical properties. 134

10.3 Security of the Hash Function


Collision-Resistance RIPEMD is conjectured to be a one-way, collision resistant hash function:

1. Collision resistance: It is computationally infeasible to compute two distinct messages M1 and M2 such RIPEMD(M1 ) = RIPEMD(M2 ). 2. One-way: It is computationally infeasible, given a message M to compute a dierent message M such that RIPEMD(M ) = RIPEMD(M ). 0

0

Recent work by Dobbertin (Dob97]) has found collisions in two rounds of H. Although the above assumption is still reasonable, it will be necessary to consider alternatives to H. Prime candidates for this replacement are RIPEMD-160 DBP96] and SHA-1 SHS95].

Statistical Evaluation RIPEMD has been tested with respect to the following three properties:

1. The dependence of input and output bits of the function.

Completeness: each output bit depends on all input bits KD79]. Avalanche eect: for each input bit, a change of this single input bit changes on average half of the output bits Fei73]. Strict avalanche criterion: every output bit changes with probability 1 2 whenever one input bit is changed (see WT86]).

2. Possible linear relations between input and output bits of the function. 3. The periodicity properties of the function. No tests have indicated that RIPEMD does not satisfy all these properties. Although this does not imply that RIPEMD is a strong hash function, failure of passing these tests would make it too weak for many applications (more precisely, BBB+ 95] investigates the basic building block of RIPEMD, called compress, but this analysis also gives information about RIPEMD). Therefore we shall make the assumption that RIPEMD has the necessary pseudo-random properties.

10.3.2 Security of H

Based on the assumption that RIPEMD satises the above mentioned properties it is argued that H also satises these. This justies the use of H in CAFE (in particular that Assumption 10.1 and 10.2 are reasonable using H). First, note that the catenation of the fth output word EN is irrelevant for the strength of H:

any collision on the rst four words AN to DN is by denition one on the complete output H(M ), and vice versa. This implies the equivalence of nding collisions for H, or for H without the fth output word EN . 135



any pre-image to a 4-tuple (AN : : : DN ) is by denition a pre-image to the corresponding 5-tuple (AN : : : EN ), and vice versa. This implies the equivalence of nding pre-images to H, or to H without the fth output word EN . Therefore, the fth word is from now on ignored in the evaluation. (The hash value is expanded to 160 bits rather than just keeping 128 bits for implementation reasons only it is felt that 128 bits is sucient for the security.) Next, note that the dierent expansion has no inuence on the statistical properties, since the compression function compress is not aected. (It is this function that is submitted to the statistical tests.) Finally, we argue that the sole purpose of the use of the message length in the expansion of RIPEMD is xing the length of the message. This is done to avoid the \trivial" collisions found by appending part of the padding of a message to a copy of this message | both may produce the same padded message and consequently the same hash value. There is substantial evidence (cf. Dam90]) that collision resistance of the compression function (compress) is sucient for collision resistance of the hash function built from it, apart from these trivial collisions. We may conclude that H has the necessary properties needed in CAFE, with the possible exception of the existence of trivial collisions. However, by the design of the protocols such trivial collisions do not pose problems to the security.

136


Chapter 11

Security Requirements Here we will describe the security requirements of the CAFE payment system. However, the requirements of key management and clearing are not stated here, but included in the respective chapters on this. Although performance requirements are not mentioned explicitly, it is a basic requirement that all protocols can be implemented suciently ecient within acceptable waiting times. For example, generating and verifying a single tick payment must be nished before the next tick is due, whereas the recovery protocol has less demanding time constraints. The security requirements are generally partitioned into requirement types of availability, integrity, and privacy. The requirements are listed separately for the bank, payer, and payee. The bank will represent both the role of issuer and aquirer. The lists cover a wide range of plausible requirements, and should contain at least all basic requirements. A requirement that is not explicitly listed here can probably be reduced to a combination of some of the listed requirements. The security analysis of the protocols with respect to the listed requirements relies on some general assumptions, such as tamper-resistance and trust relations. These assumption are introduced informally in the next section. Ideally, we will also require that protocol interruption does not invalidate any of the listed requirements. However, as will be clear from the security analysis, interruptions can to some extent aect availability and privacy, but not integrity.

11.1 Assumptions There is no special mechanism for enforcing availability, and hence the dierent roles in a transaction must trust each other to be available. For integrity, each role trusts itself only. For privacy, the payer trusts the support of the purse part of the wallet, but not the observer part. It is assumed that the reload and acquire station of the bank, and the till of the payee are reliable. This can be ensured by standard measures in the implementations of the protocols. Furthermore, we assume that the wallet only have crash failures. This means that lower level error detection (e.g., error detecting coding, system self-checking) is sucient for the purse never to deviate from its protocol: If it fails, it stops. We do not treat lower level fault tolerance measures, e.g., attempts at tolerating communication errors on the data link layer or fault-tolerant storage structures|those are a matter of the implementation. The protocol measures start when the lower level measures 137

Chapter 11: Security Requirements


are insucient, and of course, only then do we require that the purse stops if it fails. We also assume that ( and ;) observer devices are tamper-resistant. In particular, unauthorized inspection or manipulation of the contents or functionality of such devices, are assumed to be infeasible. Furthermore, the following assumption is needed to guarantee privacy in the system: All wallets execute the protocols as specied.

11.2 Bank's Requirements The bank requires at least the following: 1. (Authenticity of cheques1 ) In the deposit protocol, the acquirer will only accept cheques that have been correctly issued. 2. (Limitation on value) It is impossible to change max pay (cu) (in deposit the acquirer will only accept an amount a in currency cu if a max pay (cu)). 3. (Conservation of value) If the payee deposits an amount received on a cheque c, then a unique payment transaction has been executed where c was used to pay this amount. 4. (Correctness of exchange rates) The payee can only deposit a cheque to the exchange rate validated by the acquirer. 5. (No double deposits) The acquirer will accept at most one deposit transaction of the same cheque (i.e., the amount received in a given cheque will be credited at most once). 6. (Strong integrity) Assume the observer is tamper-resistant. A payment is only possible, if the currency table is valid, and the payee only receives the money if the currency table is debited appropriately. Similar should hold in the transfer from a ; wallet to an wallet. In withdrawal (transfer) of a units, the observer increases the corresponding balance in the currency table by a and not more. The cooperation of the observer is necessary in payment and transfer, and it must be impossible to coerce the observer into getting a negative value of the balances in the table (thus strong integrity of the ;-system requires that the observer in wallets is tamperresistant). 7. (Forger identication) If a cheque is used in two dierent payments, the issuer must be able to prove the identity of the payer, if both cheques are deposited. A payer should not be able to disavow such a claim. 1 Recall

that a two-spendable cheque actually contains two cheques (which share some attributes, e.g., the signature from the issuer). To avoid confusion \cheque" will in the following mean one part of a two-spendable cheque.

138


11.3 Payer's Requirements

8. (Strong integrity during recovery) If the observers are tamper-resistant, then (by the recovery protocol) a payer cannot recover more money than what actually remained in the wallet. Furthermore, in the recovery of interrupted payments the payer can only get back the amount paid if the payee does not deposit it. 9. (Fall back integrity during recovery) The payer cannot recover (by the recovery transaction) more money than the total balance after the last successful withdrawal. Furthermore, in recovery of an interrupted payment transaction the payer can at most get back the maximal value of the cheque. As long as the assumption of tamper resistance is not broken requirements 3 and 6 together ensure that whenever the bank accepts a cheque, the corresponding amount must previously have been withdrawn from an account.

11.3 Payer's Requirements We rst list some requirements with respect to availability. These requirements are clearly met by the protocols,and therefore not considered in the analysis later on, except for a discussion on the resilience against interruptions. (Withdrawal availability) It is possible to withdraw money if the payer's account contains sucient money and the maximum of the wallet has not been reached. (Exchange availability) During the withdrawal, it is possible to transfer value from one currency balance to another. If a balance is zero this entry can be replaced by another currency type. (Transfer availability) The payer can at any given time transfer any amount from the wallet to an aliated smart card. The balance of the receiver should increase by exactly this amount. (Availability of recovery) Interruption of a protocol must not result in a loss of money for the payer. Furthermore, if the wallet is lost, stolen, or malfunctioning, the payer can recover the money contained in the wallet. (Fungibility) As the maximum number of payments is clearly limited to the number of available cheques, only a limited type of fungibility applies to the CAFE protocols: for some parameter k, determined at withdrawal, a payer can make any nite sequence of k payments of amounts in any currency, as long as the respective balances are not exhausted, and as long as max pay (cu) is not exceeded for any currency cu. In addition, a payer requires at least the following of the payment system: 1. (Authorisation of transactions) No money can be withdrawn from her account without the cooperation of the payer. In case of dispute the issuer must supply a proof that the payer acknowledged a given withdrawal. The 139

Chapter 11: Security Requirements


issuer cannot make a proof without the cooperation of the payer. More generally, any change of amount of money in the wallet should be matched by a corresponding change (debit/credit) of the payer's account. Similarly, exchange only takes place if the payer acknowledges the currencies, rates and amounts. Payment and transfer transactions also need some form of authorisation. That is, to spend money withdrawn by a payer, it must be necessary to know some secret information, so that the payer's money cannot be spent by other. Two types of protection can be distinguished: (a) Some (secret) information stored in the observer is needed in order to spend a cheque. (b) Some secret information held by the payer (e.g., a PIN) or wallet (e.g., a secret key) is needed in order to activate the observer (allowing the observer to spend a cheque and/or decrease the balance). Furthermore, the decrease of the balance should be exactly the amount the payer has agreed to spend. 2. (Absence of framing) It is not feasible to construct a proof of doublespending if this did not occur. 3. (Privacy) In order to allow anonymous payments, which are not necessarily unlinkable, two levels are distinguished: Anonymity The payer can do the payments anonymously. Unlinkability The payer's payment transactions cannot be linked to each other or to the corresponding withdrawals (except the payer). Also, recovery should not aect the privacy of other transactions than those being recovered.

11.4 Payee's Requirements Any payee requires at least the following of the payment system: 1. (Acceptable currencies) The payee can determine the choice of acceptable currencies in a payment transaction. 2. (Ownership of deposit) The value of a payment made to a payee can only be credited to the payee's account. 3. A payee can disavow a false claim of double-depositing.

140


Chapter 12

Security in the Protocols 12.1 Bank's Requirements In the following, it is assumed that the bank follows the protocols. First, we need the following denition.

De nition 12.1 Let (1 2i) 2 Gq Gq and (3 r c c3 i ) 2 Gq ZZq ZZq ZZq , ;

where i 2 f1 2g. A valid cheque is a pair (1 2i ), together with the quadruple (3 r c c3 i ), such that 1 6= 1, c = H(1 3 c1 c2 a b), where ci = H(2i ), a = GrC PCc and b = 1r 3c . ;

In the sequel, we will briey speak of a valid cheque (1 2i ).

12.1.1 Authenticity of Valid Cheques

The authenticity of cheques holds under Assumptions 10.2 and 10.4. It means that if a cheque (1 2i ) is a valid (hence, accepted in payments and deposits), then this cheque has been withdrawn by the wallet with public-key pS such that 1 = (pS h)3 , where the number 3 has been chosen by the observer.

12.1.2 Limitation on Value

The quantity max pay (cu) is a publicly known parameter. The bank will refuse any deposit of a payment exceeding it.

12.1.3 Conservation of Value

The value of a payment is included in the signature that is made by the observer. The messages in the payment protocol between the wallet and the till constitutes the deposit record. More precisely, it consists of a valid cheque (1 2i ), authenticated by (3 r c c3 i ) (as in Denition 12.1), and a triple (m 1 2 ), such that g1 h2 = 1 2im (mod p), where m is a hash value (under H) of data including the identity of the payee and the amount payable. In the following, we will show that it is infeasible for an enemy to produce a valid deposit record for some valid cheque (1 2i ), even if he has already seen a valid record for that cheque. Such a new deposit record can only have two possible forms: Same m, but dierent inputs to the hash function ;

;

Dierent m, from that in the given record. 141

Chapter 12: Security in the Protocols


Assumption 10.1 immediately rules out the rst possibility, since it implies that the hash-function H is collision-resistant. Regarding the second, the following arguments show this is infeasible under SDLA. Let (1 2i ) be a valid cheque, hence withdrawn by some wallet with public key pS , say, that knows 3 such that 1 = (pS h)3 . A conversation in the payment protocol (i.e. a deposit record) does not contain any (Shannon-) information about pS . This holds despite the fact that the rst and the second parts of a two-spendable cheque can be linked together by the authentication (3 r c c3 i ). More precisely, the payment protocol is witness indistinguishable. Using standard techniques, it is easy to show that an attacker who has some probability of completing a new payment with respect to (1 2i ), given at most one correct payment for this cheque, can be turned into an algorithm which solves SDLP. Therefore, the existence of a forger (of -payments) with good probability of success, would contradict SDLA. As SDLA and the collision-resistance of the hash-function H are both implied by Assumption 10.2 we get: ;

Proposition 12.1 Under 10.2 the following holds. Let (1 2i ), (3 r c c3 i ), ;

(m 1 2 ) be a valid deposit record, with amount A. Then it must have been produced by some wallet, that has debited the amount A from the balance stored in the observer. Furthermore, it is infeasible to change the identity of the payee encoded in the cheque. Concerning tick payments, there are two possible attacks: Changing the amount encoded in a tick payment: The amount encoded in such a cheque can easily be decreased by simply squaring the last value of received, whereas increasing it requires the ability to compute a square root (modulo Nphone ). This is hard if the factorisation of Nphone is not known. Converting a cheque used in a normal payment to a cheque used in a tick payment (and vice verse): As the message, m, signed by the wallet in the two types of payments dier both in the identity of the payee and the inclusion of this seems to be just as dicult as changing the amount in a normal payment. Proposition 12.1 shows that this is infeasible. Concerning currency exchange at the bank, note the following. As the currency is included in the message signed by the wallet during payment it is hard to change the amount encoded by changing the currency.

12.1.4 Correctness of Exchange Rates

The equality of the rate in deposit and in payment is assured by the same mechanism as the amount. Actually, the following four entities are signed by the observer: pay fro : the amount payable in the paying currency, pay to : the amount payable in the payee's currency, and cu to and cu fro : the ISO codes of both currencies. These entities together x the exchange rate. 142


12.1 Bank's Requirements

12.1.5 Double Deposits

Satised by the denition of the clearing process.

12.1.6 Strong Integrity

Informally, this means that, under assumption of tamper-resistance of the observer, the amount of money that is deposited does not exceed the withdrawn amount. By the integrity of the -cheques themselves, it is infeasible to forge cheques or change the amount of a payment. As the observer entity is coded to decrement the balance in cu tbl by the amount paid, it suces to show that an observer's counter can only be increased when it does a withdrawal of amount at the issuer, while the increase equals the amount of money that the bank debits from the payer's account. The withdrawal of amount consists of the following three steps. Step 1 Identication of the bank to the wallet. Step 2 Identication of the wallet to the bank. Step 3 Updating the currency table in tamper-resistant observer (this actually requires three signatures). We will rst argue why the signature that makes an update cu tbl can only be acquired in the correct stage. By Assumption 10.1 such a signature can only be obtained in a stage where the bank gives a signature with respect to Pa , as all other keys involved in the system and their corresponding signatures will be dierent by the properties of the key-generation. Note that there are three dierent stages in the protocols, where the bank issues signatures with respect to this key: Identication of the bank to the wallet: The message cb that is signed by the bank in this stage is equal of the form to H(mb ab ), where mb is a challenge chosen from ZZq at random by the wallet. Update the currency table: The challenge cr equals H(seq no (cu tbl ) IDs ar ). Validate update of new currency table: The challenge cu if of the form H(cz cu tbl max dist au ). Here cz is used to link the signature with the previous signature from wallet. As each of these signatures are on dierently structured messages, they cannot be confused with each other. As a result the rst requirement to for strong integrity is satised. Concerning the second requirement observe that the new currency table which the bank signs exactly reects the change (debit/credit) of the payer's account: as the related signatures cannot be changed, the currency table included by the bank cannot be changed. A wallet that receives such a signature only updates its currency table, if the rst signature from the bank contains 0

143



the identity of the payer (together with a sequence number), and the second signature is linked correctly to the previous signature from wallet (through cz ). Therefore, only the wallet that completed Step 2 of the withdrawal of amount will increase its counter. This also explains why replay attacks would fail, as for each new withdrawal cz will be dierent. So requirement 3 for strong integrity is also satised.

12.1.7 Forger Identication

Lemma 12.1 Given a pair (1 2i ) and numbers0 m, m0 , 0with m 6= m . If 1,

2 , 1 and 2 satisfy 1 2im = g1 h2 and 1 2im 0

0

;

;

1 = 2i =

0

0

= g1 h2 . Then

m01 ;m0 1 m02 ;m0 2 g m;m0 h m;m0 1 ;01 2 ;02 g m0 ;m h m0;m :

Proposition 12.2 Under Assumption 10.4 and SDLA the following holds.

Let (1 2i ) be a valid cheque withdrawn by a wallet with public key pS . Suppose we are given two triples (m 1 2 ) and (m 0 1 0 2 ) such that m 6= m , 1 2mi = m1 m . Then a is well-dened and g1 h2 and 1 2mi 0 = g01 h02 . Dene a = m 0 m0 2 2 satises ga = pS . 0

0

0

0

;

;

Corollary 12.1 If a payer double-spends a cheque (which must have been withdrawn), then the bank can trace the payer.

Thus using a part of a cheque more than once leads to identication of the payer that withdrew that cheque. The question remains, however, if the holder of that very wallet is also responsible for this oence. In any case, this mechanism of tracing can be used to demonstrate fraudulent usage of currency (as a result of broken tamperresistance) to, for instance, a court. Furthermore, this mechanism also allows the bank to blacklist the observer, so that no new withdrawals can be made, regardless whether its (honest) holder reports the wallet missing or not. Note that from a cryptographic standpoint, the bank can only show that a part of a cheque was spent at least twice, and can never prove to a third party that it was spent, say, a thousand times.

12.1.8 Strong Integrity During recovery

It is easy to see that loss tolerance does not add anything to the existing protocols that can inuence the bank's security. The only modication is that during initialisation, the payer receives his part of the initial seed used by the wallet to withdraw and spend cheques. However, the bank's part of the initial seed remains unknown to the user, so that the actual seed used in withdrawal and payment of cheques is unknown to the user. Knowledge of the seed would imply knowledge of all random choices made by the wallet, and hence of the wallet's secret key. 144

12.1 Bank's Requirements


Loss tolerance adds one new protocol to the -system: recovery. Thus, assume that this protocol is executed for a specic wallet. During recovery, the bank does not reveal any new information, and the signatures issued by the bank cannot be reused in other protocols, since we assume that messages are typed. To show that a payer cannot receive, by executing recovery with the bank, more money than the payer's wallet contained after the last payment (if the observer device is tamper resistant), consider the last snapshot stored for the wallet, and call the withdrawal during which this snapshot was updated nal withdrawal: All payments of the wallet are based on the currency table that was stored at the bank during that nal withdrawal, since there cannot have been a successful withdrawal after that one (note that in write cu tbl, the wallet terminates only if the reload station terminates). The wallet could have performed at most max dist ; min dist + 1 payments. The cheques used for these payments are generated from a seed, S , for which hash seed = H(S NS ). During recovery, an auxiliary wallet generates max dist ; min dist + 1 cheque identiers using a seed, S , such that hash seed = H(S NS ), where primes are used for the values of the auxiliary wallet. The value of the seed corresponding to the oldest unspent cheque at the last withdrawal is then equal to 16 nr wrap 0 +min dist 0 ;1) 7(2 S2 mod NS , where nr wrap ' and min dist ' are retrieved from the snapshot of the nal withdrawal. (see Section 7.8.2 for an explanation). 0 0 16 Since H is collision-resistant, S 27(2 nr wrap +min dist ;1) mod NS must be the correct seed, i.e., exactly those cheque identiers are generated that could have been used by the wallet since the nal withdrawal. After this, recovery waits until all payments that could have been performed by the wallet must have been deposited (this time can be computed from the life times of parameters as dened by the parameter management). Now it is guaranteed that using the cheque identiers generated during the rst part of recovery, the second part identies all payments that were performed by the wallet and deposited by their payees (based on the list of all deposits). The holder of the wallet receives the dierence between cu tbl and all these payments, which is obviously correct. 0

0

0

0

0

0

0

12.1.9 Fall Back Integrity During Recovery

If the auxiliary wallet which was initialized at recovery is broken, an attacker can easily forward wrong cheque identiers to the bank. This problem can be avoided if the bank keeps the withdrawal transcripts of the cheques present in the wallet at the end of the most recent withdrawal. Note that this diers from storing only the transcripts of the cheques withdrawn during the most recent execution of gen cheques. During recovery one then not just recomputes 1 but the whole cheque information up to c0 , and checks if it ts with the stored withdrawal transcripts. Furthermore, to do this, the withdrawal transcripts of the bank and advancing the wallet's seed must remain synchronized, requiring additional recovery at the beginning of withdrawals. This would make the protocols quite complicated without making much dierence in practice: the additional amount that can be obtained from a broken wallet by declaring it 145



lost is limited by max bal . If the wallet is broken, more eective attacks are enabled anyway.

Security of rec payments Here, we argue that the rec payments protocol, which enables money lost as a result of interruption of the protocols to be recovered by the payer, does not aect the bank's integrity requirements. We have to show that interruptions of the protocols, whether intentional or not, cannot lead a payer to recover more money than he is entitled to. We consider a specic payment. A payment is possible only if cu tbl valid is true, i.e., only if the last write cur tab that changed cu tbl terminated successfully for both parties. The correctness of the system without interruption tolerance implies that at this time, cu tbl was valid. Between the payment considered here and the last successful withdrawal, cu tbl could have been changed by reset (note that Ebal is a pointer into cur tbl) and payment. Now assume that the statement holds for all payments since this last withdrawal. We show that it holds for the payment considered here, too. In a standard payment, the payee receives the cheque only after the wallet has set pay busy. If the payment terminates successfully, then in one atomic action, pay busy is reset and cur tbl is updated correctly. Since pay busy is false after this, reset will not change cur tbl. If the payment is interrupted before pay busy is reset, reset will repeat the atomic update of pay busy and cu tbl until reset terminates successfully (note that no other transaction is possible before reset terminated successfully). Thus, the next transaction starts from a valid cur tbl. In a phone tick payment, the amount paid is not described by the cheque but by the number of pre-images revealed. Since tck cnt is incremented atomically before a new is sent to the payee, tck cnt is never less than the number of ticks consumed (if the payment is interrupted, tck cnt could count one tick more than really consumed). Thus, the amount debited is always sucient. rec payments is safe for the bank: In rec payments, the wallet signs all payment records, thus, the bank considers authentic payment records only. (Replay is not prevented, but it is ensured that each payment record is considered at most once.) A payment record is put into the list of failed payments in reset only. This happens only if pay busy is true, and pay busy is reset if and only if cu tbl is changed according to this payment. Thus, the bank considers only payments which were already debited to cu tbl. Finally, the recovery procedure ensures explicitly that a payment is credited to the payer only if it was not deposited before. Recovering a withdrawal is safe for the bank: The basis for recovery of a withdrawal is cu tbl from snapshot. This cu tbl is always valid at the time snapshot was updated: the new version of cu tbl is signed by the wallet, and in authenticate, this signature contains a challenge chosen by the bank, and in write cu tbl, it contains the unique seq no, i.e., it is linked to the corresponding authenticate. Thus, it suces to show that if withdrawal is recovered, the 146


12.2 Payer's Requirements

wallet could not have made payments or (successful) withdrawals since snapshot was updated the last time: Payments are explicitly prevented (in payment, cu tbl valid is inspected and must be true), and each successful withdrawal updates snapshot). Finally, in rec payments, the bank checks that the number of payments recovered is not greater than the number of cheques that were available after the last withdrawal. Thus, in the worst case, a dishonest payer can claim that each payment was interrupted.

12.2 Payer's Requirements 12.2.1 Withdrawal Authorisation In the -system there is no possibility to check the amount obtained during withdrawal. Therefore a PIN is only used to authorise any withdrawal. To prevent fraud by the reload station putting less amount into the wallet than debited from the payer's account, or not crediting the amount transferred from the wallet, the bank must be able to prove that the amount in a statement of account really matches the changes in the wallet. For this we assume that the reload station stores for each seq no a signed state received during authenticate and a corresponding one during write cu tbl as prescribed by these protocols. The payer has to enter the PIN at every withdrawal transactions.

12.2.2 Payment and Transfer Authorisation The payer can \lock" certain amounts, meaning that payments above a certain amount requires the use of a PIN-code. It is also possible to lock part of the balance. In particular, the payer can choose to unlock no amount. Then all payments will be PIN-protected. In case of loss, the wallet will be reported as missing and will be blacklisted. Only \unlocked" amounts can be spent without the PIN-code. As the PIN-code is in any case required at withdrawal, abuse of the payer's account is prevented. Fault tolerance procedures will cover the holder's loss. Without any wallet or other trusted device to unlock amounts, the PIN only protects the payer from any unauthorised payment. After the payer has entered her PIN into the non-trusted payee's terminal, the shop is able to execute any number of payments of arbitrary amounts. We will not go into ways of resolving this type of problems here we only mention that the recovery protocol could be used for this purpose, again sacricing some privacy.

12.2.3 Disavowal of False Accusations Protection against false accusations of double-spending is not taken into account in the present specication. It can be added however. 147



12.2.4 Privacy In the analysis of the payer's privacy, we do not consider physical identication of the wallet (nor the individual) as may be facilitated by special marks on the wallet, such as embossed information, and the like. In theory, such marks may also be attached by an enemy especially for this purpose. Although this may lead to physical recognition of a wallet when it shows up again during some (payment-) transaction, such an attack is not likely to enable identication of the individual, in general. Note that such an attack requires that the attacker has physical control (to some extent) over the wallet, in order to be able to attach a mark or read it. Therefore, contact-less communication, such as by infra-red, seems to prevent this kind of attack. Other methods, possibly relying on sophisticated technology, can be imagined but are not discussed here. Only payments made with the same cheque can be linked together (at most two, as we are dealing with two-spendable cheques). Furthermore, the accurate use of blind signatures prevents that withdrawals and payments by the same wallet can be linked by the bank and payee. More precisely, the ability to link such transactions implies the ability to distinguish the pseudo-random random bits used by wallet from a truly random sequence of bits. In order to see that the payer's privacy is satised, rst observe that the wallet doesn't identify itself unless it knows that it is dealing with the payer's bank. Therefore, the withdrawal of amount starts with the reload station identifying itself to the wallet, by means of a Schnorr-signature on a random challenge by the wallet (see authenticate). The inclusion of the random challenge in this signature prevents reuse of the very signature. There are attacks conceivable, though, using a fake reload station and the maa fraud (see DGB88]), that will enable an enemy to nd out the observer's identity (i.e., its public key). Implementation of these attacks requires that the proper withdrawal PIN. So, it is unlikely that this attack can be performed at a till.. Furthermore, we have demonstrated that a payment with a cheque does not contain any information about the wallet that withdrew the cheque, nor about the payer unless the cheque is double-spent. Thus, no connection can be established between the identity of a payer and a payment given the bank's and payee's knowledge. If the bank knows the initial state of a wallet's pseudo-random generator, the bank has a good chance of compromising the payer's privacy. This possibility, however, is ruled out by the properties of wallet initialisation.

12.3 Payee's Requirements 12.3.1 Ownership of Deposit In the course of proving that the amount of a payment is preserved, we argued that the message signed by the wallet cannot be changed. Recall that the payee's identity IDP is contained in that message (via the hash-function H). As the bank will only credit the account corresponding to that identity, it follows that the amount of a payment that was made to a payee can only be deposited 148


12.3 Payee's Requirements

to his account. Moreover, to prevent the same cheque from being used at more than one occasion with the same payee, a unique transaction identier given by the payee is included in the (hashed) data signed by the wallet at payment.

12.3.2 Disavowal of False Accusations

Although not specied in the -system, there exists a cryptographic protection against the bank falsely accusing a payee of double-depositing. This works as follows. Let E be a suitable commitment scheme. In the payment protocol, the payee chooses a random r, computes E (r), and sends E (r) to the wallet. The wallet then includes E (r) in the challenge m it has to sign. In the deposit of the payment, the payee presents the payment to the bank and opens the commitment, after the bank has stated that the payment has not been deposited before. In case, the bank falsely rejects the deposit, it is challenged by the payee to open the commitment, an infeasible task. This extension can easily be added to the specication of the -system.

149


150



Chapter 13

Integrity in the ; Protocols The integrity of the main roles (bank (issuer, acquirer), payer, and payee) in the ; protocols is investigated. Also, in a separate section at the end, it is investigated whether integrity can be aected by interruption of the protocols.

13.1 Bank's Integrity 13.1.1 Strong Integrity

The evaluation of strong integrity can be split into two main parts, which are the evaluation of the withdrawal of amounts and the evaluation of payments or transfers of amounts. First we will discuss the integrity of the withdrawal, where we need to show that a balance of an observer can only be increased when the payer does a withdrawal of an amount at the bank, while the increase equals the amount of money that the bank debits from the payer's account. The withdrawal of an amount consists of the following three steps. 1. Identication of the bank to the wallet. 2. Identication of the observer to the bank. 3. Updating the currency table in tamper-resistant observer (this actually requires three signatures).

In order for strong integrity to hold, the withdrawal of an amount should satisfy the following conditions. 1. The type of signature that tells an observer to declare the new cu tbl valid must only be given by the bank in Step 3. 2. Such a signature must only cause the observer that successfully completed Step 2 to update its cu tbl . The net amount of the increase of the balances of the cu tbl must be exactly the amount debited from the corresponding account. 3. Such a signature can only be used once. We will rst argue why the signature that makes an observer update cu tbl can only be acquired in the correct stage. By assumption of the safety of the Schnorr signature scheme such a signature can only be obtained in a stage where the bank gives a signature with respect to Pa , as all other keys involved in the 151

Chapter 13: Integrity in the ; Protocols


system and their corresponding signatures will be dierent by the properties of the key-generation. Note that there are three dierent stages in the protocols, where the bank issues signatures with respect to this key (see authenticate and write cu tbl): Identication of the bank to the wallet: The message cb that is signed by the bank in this stage is of the form to H(ab ), where ab is a challenge, generated mutually at random by the purse and the bank. Update of currency table: Challenge cr equals H(seq no, ID s , (cu tbl ), ?, ar ). Validate update of new currency table: The challenge cw is of the form H(cz cu tbl max dist ? aw ). Here cz is used to link the signature with the previous signature from the observer. From the independence of the Schnorr-signatures used in the protocols proved in Section 13.4, we have that the rst requirement for strong integrity at withdrawal is satised. Concerning the second requirement, observe that the new currency table which the bank signs exactly reects the change (debit/credit) of the payer's account: as the related signatures cannot be changed, the currency table included by the bank cannot be changed. An observer that receives such a signature only updates its currency table, if the rst signature from the bank contains the identity of the payer (together with a sequence number), and the second signature is linked correctly to the previous signature from the observer (through cz ). Therefore, only an observer that completed Step 2 of the withdrawal of amount will increase its counter. This also explains why replay attacks would fail, as for each new withdrawal cz will be dierent. So Requirement 3 for strong integrity at withdrawal is also satised. We will now discuss the strong integrity requirements for payment and transfer. The following four requirements need to be fullled: 1. The payment and transfer should only be possible, if the cu tbl is valid, in order to be sure that a valid withdrawal has taken place. In payment and transfer the validity of the cu tbl is checked by the observer, by checking if the ag cu tbl valid is set. 2. The payee or the wallet may only receive money, if the cu tbl is debited by the proper amount. In payment, the ag pay busy is reset only after the balance has been debited. If the payer tries to avoid debiting, for instance by removing his wallet, pay busy will remain set. Then, at the next time that reset is carried out, the balance will be debited after all. Furthermore, under the assumption of tamper-resistance, the proper amount is debited. In transfer, the amount is rst debited from the balance of the observer and then credited to the balance of the observer.. The amount to be 0

152


13.1 Bank's Integrity

transferred is signed by the observer this signature is checked by the wallet, so the amount can not be altered. 3. The cooperation of the observer must be necessary in payment, transfer and rollback. That cooperation of the observer is necessary in payment has already been demonstrated in Section 12.1.3. Furthermore, a random number from the payee is included in the payment specication. This prevents replay by the payer. Collusion of the payee and the payer where the payee generates the same number several times and the payer carries out replay, will just get the payee several exact copies of the same payment, which are worthless. In transfer, the aliated wallet requires two signatures from the observer. Therefore, the observer's cooperation is necessary. Replay is not possible, because in both signatures the challenge contains a random number (mt respectively ca ), generated by the wallet. Finally, in rollback, the observer will only undo the balance decrease performed in the (unsuccessful) transfer if the correct value of x is provided. (Note that the purse's copies of the balance do not represent any value the observer's copies do.) 4. Negative balances must not be allowed by the observer. Both in the payment and in the transfer the observer carries out an explicit check to see if the balance is suciently high to pay or transfer the chosen amount.

13.1.2 Strong Integrity During Recovery

We distinguish between recovery of failed payments and recovery in case of lost devices, and start with the latter.

Recovery of Lost Wallet This recovery procedure is secure for the bank if the procedure cannot be abused to make the bank reimburse more money than was actually lost. This is the case when all values of 1 that correspond with a payment in the period between the last withdrawal and the execution of the recovery procedure, are present among the list of the 1 generated during the recovery procedure and are in fact received by the bank. This is enforced as follows. The sequence of events in an execution of the withdrawal protocol is the following. 1. 2. 3. 4.

reset authenticate write cu tbl gen cheque

153



Note that rec payments is only executed if any failed payments have occurred between the previous and the present withdrawal. It is in the rst stage, authenticate, that the value of state is communicated to the bank. Its authenticity is established by means of an interactive Schnorr-signature (preventing replay) made by the observer. The value of state describes, among other things, the value of the parameter dist . At any time, the value of this parameter enjoys the property that all unspent cheques can be regenerated from it (and some (xed) data specic for the observer). Combining these facts we get that any payment the observer engages in after its balance has been increased will use a cheque that can be regenerated from the value of dist that was communicated to the bank in the latest execution of the withdrawal protocol. Note that by the fact that the purse's RSA signature for blinding 1 is deterministic, which is proved in a zero-knowledge protocol during initialisation, the list of the 1 as generated in the recovery protocol, will most certainly contain the 1 that correspond to a payment carried out between the last withdrawal and recovery: the value of the purse's signature with respect to (Np ep ) on (1 dist ) is unique. From the values of max dist and min dist , which were communicated during the last withdrawal, the bank knows that at most max dist ; min dist + 1 dierent cheques are to be expected. This prevents the wallet from reclaiming more cheques than withdrawn. From the above, it can be concluded that the recovery information that the bank receives must be stored securely if an intruder were able to adjust the latest value of dist of some wallet, all money that this wallet spent after its latest withdrawal could be recovered. 0

Recovery of Failed Payments By the atomicity of the procedure in which the observer updates its balance in the payment protocol, it will be the case that amounts of payments are deducted from the balance if the observer has sent out the responses 1 and 2 . Therefore, an attacker cannot obtain a valid deposit record while the corresponding amount is not deducted from the observer's balance. The regeneration of the 1 enjoys the same properties as in the recovery of a lost wallet. Thus the only way an attacker can gain from the recovery of failed payments, i.e., in rec payments, is when a deposit-record he submitted (note that an attacker can always have an observer mark a payment as "failed" when in fact a valid deposit record for this payment is at the disposal of the attacker, by interrupting the payment protocol right after the sending out 1 and 2 ), is not submitted by the payee specied in that deposit-record. But then it is just the amount that was deducted from the balance of the observer that he will get back (after the cheque has been cleared), and he has gained nothing. 0

0

0

0

154

0


13.2 Payer's Integrity

13.1.3 Fall Back Integrity During Recovery This is satised by denition of the recovery procedure. If the tamper resistance is broken, an attacker can spend all withdrawn cheques for the maximum amount. He can keep doing this, provided that he goes back to the bank to get new cheques whenever he runs out of unspent cheques. Note that the presence of the recovery of payments procedure allows the attacker to recover (part of) the money he withdraws in this scenario.

13.2 Payer's Integrity For the payer, the main dierence between the and ;-systems is the amount of control the user has over the actions performed. Furthermore, the PIN is protected better as it is now entered through the purse. This makes it easier to hide it when entering it and it is not exposed to supporting terminals that cannot be trusted by the payer.. Briey, the payer's integrity is protected as follows:

Withdrawal authorisation: One needs a secret key (the observer's, in this case) to be able to withdraw money. Furthermore, one needs the user's PIN (checked by the observer). Thus, only the individual can make a withdrawal with his own wallet. Since the purse allows him to view the new cu tbl before sending his PIN (i.e., before pressing ÒK') to the observer (thereby allowing the withdrawal) the user is in full control over the new cu tbl .

Exchange authorisation: Exchange during withdrawal is protected by the same means as a normal withdrawal. Regarding exchange during payment the same protection as for payments apply.

Payment/transfer authorisation: The payer's integrity in payment and transfer is enhanced by the fact that the user can now check amounts and rates before authorising the transaction (by pressing ÒK').

False proofs of double-spending: A proof of double spending requires the secret key of the observer. A correct payment does not allow the key to be computed. The security against such false accusations depend heavily on the key management and initialisation of observers, since anybody knowing this key can make such proofs.

Recovering money requires the help of the bank. Observe, however, that if a payer is entitled to reimbursement as a result of a failed payment, an attacker cannot coerce the observer into deleting the payment before it is submitted for the bank for recovery. This would require forging the bank's signature in the rec payments protocol, which is infeasible. 155



Privacy

The requirements of privacy are split into two main properties anonymity and unlinkability. In the statement of the privacy requirements it is assumed that the payer Alice follows the protocols.

Unlinkability

Not even a collusion between the bank and all payees can identify two payments, made with two dierent cheques, as being made by the same wallet, with probability signicantly greater than random guessing.

Anonymity

Not even a collusion between the bank and all payees can identify a given payment as having been performed by Alice's wallet, with probability signicantly greater than random guessing. As a result of an execution of rec payments, the bank is only able to trace at most one of Alice's payments in addition to the one corresponding to the failed payment. As a result of an execution of recovery, the bank is only able to trace Alice's payments in so far they have been performed after Alice's last withdrawal. The following list contains general assumptions and conditions that we nd necessary and feasible to state and for which no further arguments are provided. More specic assumptions appear where they are needed in the analysis. 1. Linking of transactions by physical identication of the wallet, the wallet or the individual user of the instruments are outside the scope of this analysis. 2. The purse will carry out the protocols correctly, but can be interrupted by the other parties. 3. The observer either alone or in cooperation with any third party communicating through the purse are free to deviate from the specied protocols, for instance in order to achieve informational outow. 4. The purse is initialised correctly for all the parameters. 5. Only the purse and its owner can store the initial and subsequent values of the pseudo random generator employed by the purse. 6. The key certication centres will only issue a single certicate for each public key, for instance the bank's public keys. 7. The protocols show currencies, reset, transfer, rollback, unlock amt and the messages generated from these protocols are not available for execution by outside parties. transfer and rollback communicate with aliated wallet.

156



8. The observer cannot exploit any covert timing channels through the purse's IR-link or through the card reader to the outside. 9. The withdrawal service involves the following protocols utilising the IRlink: get info, update, authenticate, write cu tbl, gen cheque and rec payments. 10. Payment involves the following protocols by the IR-link: get info, get certif and payment. Some of the variables employed in computing the payment messages are assigned in the withdrawal transaction. Any data that is occurring in a payment transaction and that is computationally linkable to or from a withdrawal transaction can help in linking the payment transaction to a specic identity, from the bank's point of view. The remedy against this is the \blind signature mechanism". By the properties of the blind signature scheme there does not exist any eciently computable link between a payment transaction and a withdrawal transaction. Here, we limit the analysis to \the cheque part" of the withdrawal and the payment transactions. When showing that withdrawal and payments are unlinkable, we have to show that anything which the bank sees in some execution of gen cheque can match anything the payee sees in an execution of payment.

Proposition 13.1 Withdrawal and payment transactions accepted by the wal-

let cannot be linked by the payee and bank. The ability to link these implies the ability to compute the pseudo random bits used by the purse, something that is assumed infeasible.

In the above proposition it has been assumed that 3 is chosen (pseudo) randomly by the purse. In the protocol the purse actually computes this value deterministically as an RSA signature on numbers supplied by the observer. However, under the assumption that such signatures are unpredictable the analysis also works in this case. This proposition also implies that the observer cannot use withdrawal and payment to send information to the outside world, which can be used to link these transactions. Furthermore, since the purse checks variables against its own copies and randomises signatures/cheques these possible covert channels are prevented to a large degree. However, sometimes the purse is only able to verify that variables are within an allowed range in which case a small room for outow exists. For assessing anonymity of a payer, we need to identify the set of parametervalues that identify the payer. By inspection of the protocol specication we see that the following data are uniquely linked to a wallet (purse and observer): The identity IDs . The key-pair ps and ss . The RSA-keys ep dp Np . 0

157



The seeds S S . 0

In the following these parameters will be referred to as identity-data.

Proposition 13.2 The wallet does not identify itself explicitly unless it has made sure that it is communicating with the bank in a withdrawal transaction.

This proposition is justied as follows. The holder has to request a withdrawal, so the wallet cannot execute this service \unattended" in connection with other protocols. The bank will always have to authenticate itself to the purse before the wallet identies itself to the bank. The inclusion of the random challenges in the authenticating signature prevents replay attacks. The \Maa fraud" attack is conceivable, if the holder intends to make a withdrawal, but unknowingly uses a fake reload station. This entity will just mediate the messages that constitute the bank's authenticity, the result being that the purse will send IDs .

Proposition 13.3 A run of the get info protocol does not reveal any information about the identity-data.

This proposition is justied as follows. In the get info protocol the parameter sets that will be used during the subsequent execution of the payment protocol are identied. The observer sends v , vBa , vBc and IDB to the payee with some verication by the purse. (vBa is not needed for a payment transaction but is sent anyway.) The values of these variables remain xed for a long time for each payer and, in principle, can be used by the payee to sort payments. However, the information content in the key version numbers relative to identity-data can be assumed to be very low because only a few, ideally only two, sets are in use at any point of time. The information content of the bank identity relative to identity-data depends on the number of payers, the number of banks and the relative size of banks. It is assumed that the number of banks will be very small compared to the number of bank customers, which means information content of IDB relative to identity-data is also very small. The purse performs an exact verication of the variables v and IDB before sending them to the payee. These variables are set during initialisation of the purse and cannot be changed. Thus, the observer is unable to use these variables as a covert channel for sending identity-data.

Proposition 13.4 A run of the get certif protocol does not reveal any information about the identity-data. This proposition is justied as follows. The get certif protocol is executed on request from the payee if the payee doesn't know the bank keys that will be used by the payer. One or two key certicates are sent from the payer to the payee during the execution of this protocol. No additional information about the payer is revealed to the payee by sending the keys and certicates of the issuing bank and certication centre. These 158



keys and the certicates are uniquely given by IDB and vBc and the assumption that a given key will only be certied once. The observer is not involved in this protocol and will not be able to communicate any information to the payee.

Proposition 13.5 A run of the payment protocol does not reveal any information about the identity-data, if Proposition 13.1 of unlinkability holds.

Proof: Since the identity data can be computed from gc which the bank

knows in gen cheque, the ability to compute this data from the payment would lead to a link between gen cheque and payment. This contradicts Proposition 13.1. 2

We now evaluate the rec payments, recovery, update and transfer protocols with respect to privacy. A recovery of a single payment is done by permitting the bank to trace this payment to discover if it was successful or not. Due to the two-spending property of a cheque, the bank will also be able to trace the payment performed with the second part of the recovered cheque. In the rec payments protocol the variables 1 , i, Epay , pay type , tck cnt , cu fro , date , cp , rp and uk are sent from the purse to the bank. The value of 1 is initially chosen by the observer but randomised by the purse using 3 . The protocol specication does explicitly require the purse to verify that 1 is not put to 0 or 1, similar to the payment protocol. The variable i cannot be used for transmitting information to the bank since the purse veries the i received from the observer with the i stored in its own \failed payment" storage. The variables Epay , pay type , tck cnt , cu fro and date are sent from the purse to the bank without any possibility of interference by the observer. The signature (cp rp ) is generated by the observer but randomised by the purse with the value of up, and therefore cannot be used by the observer to send information to the bank. The value of the variable uk is chosen at random by the purse. The above discussion shows that the rec payments protocol itself cannot be used to transmit covert information from the observer to the bank. In this discussion it has however tacitly been assumed that the recovery information stored by the purse is correct. Recovery information is stored in a \failed payment" storage structure during the reset protocol. It turns out that recovery information has to be stored whenever pay busy in the observer is set. The purse is not able to verify this and just stores recovery information about the last spent cheque whenever the observer tells it to. The rec payments protocol is executed automatically when the wallet is in contact with the bank. This means that the observer is able to allow the bank to trace any payments by tricking the purse into believing that these payments have failed during an execution of reset. In the recovery protocol, the pseudo random generator of a replacement observer is set up with the initial state of the observer that is about to be 0

159



recovered. This correct recovery procedure is dependent on having the payer input some secret recovery data S . Neither the bank nor the new wallet is able to reconstruct the observer seed required for the reconstruction of the cheques without the seed S . The bank then sends hash seed , min dist , max dist and gc to the wallet. This information is signed with the bank's authentication key. The wallet regenerates all the cheques in the range specied by min dist and max dist . The bank determines this range at its own discretion. The protocol specied does not allow the purse to verify the range. All cheques in this range will be traced by the bank. This attack is possible even if the observer follows its protocols. The update Protocol updates the bank public key certicates of the wallet. Updating the public key for cheque signing Pc requires the identity of the payer. The protocol requires that the bank will authenticate itself before the purse sends its IDs . The ability to forge an authentication signature for the bank implies the ability the eect the wallet's identity output, but only if this protocol can be run independently of the authentication protocol in the withdrawal service. The ; purse initiates the transfer protocol by request from the holder. Hence it can be assumed that the purse will only give its signature to an wallet that is acknowledged by the owner of the purse. The wallet cannot know in advance which entity is invoking the transfer service. Therefore the ; wallet has to authenticate itself before the wallet does. The wallet will require a correct signature on a random challenge before identifying itself by a signature. The purse does not send any data to the outside world during the rollback protocol. Hence this protocol cannot compromise the payer's privacy. We now draw our conclusion based on the above analysis. The ; protocols full all privacy requirements of the payer, under the computational security assumptions for the cryptographic primitives, in particular the RSA-signature and pseudo random generators of the purse. If a payment protocol is interrupted, then the rec payments protocol will be executed, enabling the bank to trace at most one payment in addition to the payment that the wallet noted as failed (the other part of a two-spendable cheque, if it was spent). If a payer asks the bank to recover an observer, then the recovery protocol enables the bank to link at least all payment transactions after the last withdrawal transaction. The ; protocols oer improved privacy compared to the protocols. When implemented with contact-less communication between the wallet and the outside world physical identication of the payment device is much harder than in the -system. From a privacy point of view, the most important dierence between the ; protocol system and a the protocol system is that the strict functional distinction between purse and observer ensures that privacy is now under control of the payer supported by the purse entity. 0

0

160

13.3 Resilience Against Interruptions


13.3 Resilience Against Interruptions Each time an observer is switched on, it will execute reset rst, particularly the rst time an observer is in operation after an interruption. In the reset protocol, the observer will rst recover atomic operations, if any. We will now argue why interruptions of the payment protocol cannot aect the security. Consider an attacker who aims at causing the observer to issue a cheque while the spent amount will not be (fully) debited from the balance. Of course, the attack should not render new services to be delivered impossible. By the assumption on the tamper resistance of the observer and the cryptographic properties of the cheques, the only way left for an attacker to prevent the observer from updating the balance corresponding to a payment, is to interrupt it. However, before the values 1 and 2 , that complete a payment (and the values in case of phone ticks) are sent out, the ag pay busy is set. This is an atomic operation. It is only after 1 and 2 are communicated to the purse that the balance is updated and the ag pay busy is reset atomically. If the observer is interrupted between the transmission of 1 and 2 and the update of the balance, it will notice the ag pay busy to be still set the next time it is in operation. Consequently, it will carry out the update after all. Note that the current cheque is marked as a failed payment if any interruption occurs after the ag pay busy is set. The amount of a failed payment can only be recovered if the corresponding cheque survives the clearing process, i.e., if a cheque turns out not to have been submitted during a deposit. As the amount will be debited from the balance anyway, an attacker cannot make prot out of forcing a payment to fail and then reclaim the amount in the recovery procedure. Another threat posed by interruptions could be the following. If an attacker were able to prevent the observer from marking cheques spent when they are, this could cause the observer to double-spend a cheque, giving the attacker an opportunity to learn the secret key ss, and thus enabling the attacker to bypass the observer in the gen cheque and payment protocols. This is simply resolved by having the observer mark the cheques atomically. We will now investigate the resilience against interruptions in the case of the withdrawal protocol. Eectively, authenticate consists of giving the bank a snapshot of the current state of the observer. Note that its authenticity is guaranteed by an interactive Schnorr-signature and that the bank will only engage in an execution of write cu tbl if it is preceded by a successful execution of authenticate. Therefore, the bank will have a state of the observer at his disposal, that precedes the state of the observer when it executes write cu tbl. Note that it is possible to interrupt the observer between authenticate and write cu tbl without the bank noticing it, i.e., in the mean time the observer can be used to execute another protocol, after which it can jump back to write cu tbl (the purse just simulates the bank in authenticate). However, if the value of cu tbl is changed during this interruption, the observer will not accept the bank's rst signature in write cu tbl, as it will include the value of cu tbl as communicated during the execution of authenticate 0

0

0

0

0

0

161



before the interruption. For a similar reason, it is infeasible to interrupt the observer right after it has updated the value of seq no (during write cu tbl), and still be able to perform intermediate tasks as above. The only eect of interruptions right before or during the gen cheque protocol is a limitation of the number of cheques that are withdrawn. We conclude that it is of no advantage to an attacker to interrupt the withdrawal protocol. In the transfer protocol, the mother rst communicates the transfer amount to the daughter by means of an interactive Schnorr-signature. The mother observer will only deduct the transfer amount (atomically) if she has received an acknowledgement from the daughter that she agrees on the transfer amount (by use of an interactive Schnorr-signature). Upon receipt of an interactive Schnorr-signature by the \mother" wallet, the aliated \daughter" wallet updates her balance according to the transfer amount. All signatures are linked, so that it is infeasible to quit the protocol (after at least one signature has been exchanged and before the protocol has been completed) and jump back later, without the other noticing it. By the order in which the balances are updated,, it is infeasible to have the daughter update her balance while preventing the mother from updating hers. In the protocols rollback, updateP c, updateP a, rec payments, recovery and deposit, interruptions are potentially only harmful for the payer's integrity. However, by the atomicity of the crucial operations in those protocols, the wallet can recover from interruptions. As a conclusion, interruption of the observer during any of the protocols does not seem to harm the bank's integrity. As to the eect of interruptions on the payer's integrity, note that crucial operations in the payer's wallet and the bank's reload station are performed atomically. If an observer is interrupted, then the wallet can recover from possible loss of value in the rec payments protocol. As the payee only accepts a payment if a valid deposit record has been submitted, there is no threat here for the payee (it is assumed that the till can recover from possible interruptions or break down).

13.4 Independence of ; Protocols A common property of a payment system like CAFE (or of any set of cryptographic protocols, for that matter) is that the protocols are suciently independent. That is, (partial) results obtained from executing one protocol should be useless for later executions of any protocol (including the protocol itself). In many respects this property is easily checked for the CAFE protocols. However, there is one exception which is related to the use of the hash function H. We will consider this for the ; protocols only a similar analysis applies to the protocols. In each of the protocols, every stage that has security aspects consists of the exchange of Schnorr-signatures. It is very important that a signature that is to be produced in some stage, cannot be obtained from another stage. In the ; protocols, it should be the case that the independence of protocols is derived from the independence of Schnorr-signatures as they are required in the various 162


13.4 Independence of ; Protocols

stages of the protocols. As an example consider the signature by which the bank identied itself to the wallet. Suppose this signature were similar enough to the one by which the observer is told to update its balance. Then an attacker could be able to abuse the identication of the bank to load money into the observer, thus creating money. Similarly, the observer's signatures should be independent. It is only here that the \trivial collisions," mentioned in the section on the security of the hash functions may do harm: the substitution of the hash value of one message in stead of the hash value of another is dangerous only if it is part of a signature. In that case one may substitute one signature for the other. And conversely, the substitution of two signatures is only possible if the hash values of the two messages are the same. That is, in case of a collision. However, by Assumption 10.1, which implies the collision-resistance of H, we need only consider the trivial collisions. Below we will consider all such possibilities. First, observe that a trivial collision can do no harm if the hash values are used in signatures using dierent keys. Furthermore, one cannot have a trivial collision if the number of blocks in the messages are dierent. Therefore, we need only consider those pairs of signatures that are made using the same key, and that have the same length. Also the signatures by the bank on cheques (using key Sc) and the cheques themselves may be ignored: they are, respectively, used in exactly one stage in the protocols (Sc is used only for signing cheques) or used exactly once (a pair (1 2i ) for each i can be used only once (in payment) to sign a set of payment data).1 Below, all remaining signatures are classied according to those two criteria.

bank's signatures (secret key Sa ).

We need only consider the bank's security here, as an attacker would obviously not be interested in forging a signature that the bank would be willing to provide.

1 block There is only one one-block signature: the bank signs \ab " in authenticate.

No possibility for trivial collisions. 2 blocks The following two-block messages are signed by the bank: 1. In write cu tbl: \seq no ID s cu tbl , ? ar ". This signature allows the observer to make the currency table with value cu tbl invalid, and overwrite it with the new value cu tbl . (cu tbl valid is true when this signature is issued else the bank issues the signature below.) Forging this signature would not pose any security problems, as no value is directly involved, and indirectly, preservation of value is guaranteed by the recovery procedures. 0

1 Note

that, though the secret key of a cheque is related to the observer's secret key, no information on the latter key can be inferred from the cheque by the security of the signature scheme.

163



Note that this signature will cause the observer to increase its seq no . This is the same situation that arises when the bank does take part in the write cu tbl protocol, but the protocol crashes after the observer increased seq no , but before the bank did so. 2. In write cu tbl: \seq no ID s, ? ar ". This signature allows the observer to overwrite the already invalid cu tbl with the new value cu tbl . (cu tbl valid is false when this signature is issued else the bank issues the signature above.) Forging this signature has no other eect than increasing seq no without the bank knowing this (see above). 3. In write cu tbl: \cz cu tbl max dist , ? aw ". This signature allows the observer to validate the new stored currency table cu tbl , and issues a new value of max dist . Forging this signature would allow the forger to create money. 4. In updateP c: \mu , ? au ". This signature identies the bank to the wallet it prevents impersonation aimed at obtaining ID s. Forging this signature would just allow the forger to obtain the identity ID s . This is not a threat to the bank's security. 5. In rec payments: \cp , ? ak ". This signature acknowledges the receipt of a set of failed payment data, and thereby allows the observer to erase these data from memory. Forging this signature might cause loss of money that would otherwise be recovered. This is no threat to the bank's security. It follows that only case 3 is a threat to the bank's security. We must therefore consider the following possibilities of trivial collisions: substitution of any of the signatures above in case 3. For this purpose, consider the contents (with byte numbers) of the messages above: 1 2 3 10 11 20 21 64 block 2 1 seq no ID s cu tbl , ? ar 2 seq no ID s ? ar 3 cz cu tbl max dist , ? aw 4 mu ? au 5 cp ? ak It is obvious that signatures 1 and 2 cannot be substituted in signature 3, as cz will have its rst 10 bytes equal to \seq no ID s" with negligible probability. A substitution of signature 5 in signature 3 requires cz = cp as these are hash values of dierent length messages, this cannot happen because of collision resistance of the hash function. Substitution of signature 4 in signature 3 nally, will not pose a problem, as this will set the new currency table to hold no value (all currency identiers 0

0

0

0

164



will be 0xff, denoting empty rows). This will obviously only be protable to the bank. 4 blocks There is only one four-block signature: the bank signs \mq , hash seed , min dist , max dist , nr wrap , ep , ? , Np , gc , aq " in recovery. No possibility for trivial collisions. observer's signatures (secret key ss). 2 blocks The following two-block messages are signed by the observer: 6. In write cu tbl: \seq no cu tbl , ? az ". This signature noties the bank that the sequence number has been increased to seq no , and that the value of the currency table is set to cu tbl . (And permission to validate this currency table is requested from the bank.) The bank might want to forge this signature to defraud the payer: using a fraudulent signature, for instance, `prove' that a large amount was withdrawn by a payer, `justifying' a corresponding debit transaction on the payer's account. 7. In transfer: \mt Xfer , ? at ". With this signature, the observer gives permission to commence a transfer of amount Xfer with challenge mt from the aliated wallet.. This signature xes the amount transferred, so forging it may create money. 8. In transfer: \ca , ? ai ". This signature acknowledges that the transfer has been performed successfully. Forging this signature will coerce the aliated wallet into increasing its balance (by amount Xfer as in the preceding part of the protocol). As all three signatures involve value, we must consider all 6 cases of substitution. For this purpose, consider the contents (with byte numbers) of the messages above: 1 2 3 20 21 23 24 64 block 2 6 seq no cu tbl , ? az 7 mt Xfer ? at 8 ca ? ? ai Substitution of message 6 in signature 7 or 8 will not work, as a valid seq no and cu tbl will provide mt respectively ca with negligible probability. Neither will substitution of 7 in 8 or vice versa work, as an all-one amount Xfer (i.e., Xfer = 224 ; 1) will denitely not be accepted. Finally, substitution of 8 in 6 will not work, as ca will not provide the correct seq no and a valid cu tbl . Only a substitution of 7 into 6 will work. Note however that the bank knows on beforehand which cu tbl will be signed by the observer. This implies that a substituted signature will not be accepted, as 0

0

0

0

0

0

165



it is not on the correct message. In other words: the signature is accepted only if the bank approves of cu tbl (and it is correct). So, this cannot benet the payer: the appropriate amount will be debited from his account. Thus, only the bank can benet from this substitution. Furthermore, in order to perform this substitution, one must be in possession of the wallet (as otherwise no transfer will be executed|the payer will not ÒK' this during for example a withdrawal session). So, the wallet is lost if the bank now claims that a large amount is on the wallet and debits it from the account, a recovery will be (demanded and) executed. This recovery will reimburse the payer with the money the bank attempted to defraud him of. That is, the only working substitution does not benet the fraud. 3 blocks The following three-block messages are signed by the observer: 9. In authenticate: \cb state , ? as ". The state is communicated to the bank. Forging this signature might create money, as state contains trans and cu tbl . A false value will produce an incorrect new currency table, or an incorrect amount of reimbursement in case of recovery. 10. In rec payments: \1 , i, Epay , pay type , tck cnt , cu fro , date , ? , ap". The payment data of a failed payment are sent to the bank. Forging this signature might create money: the payer may be reimbursed for an incorrect amount Epay , or (due to an incorrect 1 ) unjustly be reimbursed. (A non-existent 1 will not be detected in the clearing. This will hold even if the actual transaction was successful or if no transaction at all was performed|no reimbursement is needed in either case.) 11. In recovery: \rq dist , ? 1 a ". The data corresponding to a possible payment to be recovered is sent to the bank. Forging this signature might create money, similar to the reasoning above. As all three signatures involve value, we must consider all 6 cases of substitution. For this purpose, consider the contents (with byte numbers) of the messages above, shown in this table: 0

9 10 11

1 20

cb

21 64 seq no , cu tbl valid , , nr fail pay

rq

dist , ?

1

block 2 block 3 cu tbl , ? as i, Epay , , date , ? ap

1

a

Substitution of 10 in 9 will not work, as message 9 starts with 20 random bytes (cb ), determined by the previous actions in the protocol 166



and out of control of the attacker. A correct value of 1 with its rst 20 bytes equal to cb will show up with negligible probability only. Substitution of 11 in 9 will not work, as this requires cb = rq , and a correct value of rq with its rst 20 bytes equal to cb will show up with negligible probability only. Similarly, substitution of message 10 in signature 11 will not work. Substitution of message 9 in signature 11 will not work, as byte 24 of message 9 must be 0xff, as it coincides with the padding in message 11. This forces cu tbl valid = 0xff, which is an invalid value. Thus, a suitable message 9 for substitution in signature 11 will not occur. A substitution in signature 10 will not be successful since the payment data in the second block will not be valid, as is shown below. A substitution of message 11 in signature 10 would need to have a value of the 1 from message 11 ending in a valid date and 49 bytes 0xff, as it coincides with \i Epay : : : date , ? " in message 10. This happens with negligible probability. Finally, substitution of message 9 in signature 10 requires the second block of message 9 to contain at most 11 bytes unequal to 0xff these 11 bytes must be the cu tbl . The rst 8 bytes constitute the rst row. The next three bytes (coinciding with date ) are part of the second row of cu tbl . Since 0x0 is not a valid date, the second row is nonempty. This row then has form: a nonzero balance, followed by a currency identier 0xffff and rate 0xffffff. (The latter two variables coincide with the padding in message 10.) This is not a valid row of a currency table, since the bank will not provide a nonzero amount of an invalid (0xffff) currency. That is, substitution of message 9 in signature 10 requires an ìmpossible' cu tbl . So trivial collisions with three-block messages have negligible probability of success. We conclude that no successful attack based on dependence of protocols in the form of trivial collisions is possible.

167


168



Part V

Clearing

169


Chapter 14

Introduction In the previous chapters a payment system has been described with little regard for the functionality required for clearing of electronic currency between a multitude of issuers and acquirers. In this chapter we describe this functionality.

14.1 Overview So far this document has not focused its attention on the clearing system and mechanisms that must exist in a multi-issuer system for settling of claims acquirers will hold against issuers as a result of accepting electronic currency issued by these issuers. A brief description of such a clearing system was already given by Cha89], and a detailed work-out in the case of the on-line system of Cha89] by Sto88]. In this part we describe the architecture of the clearing infrastructure and the functionality provided by the clearing infrastructure. Figure 14.1 shows the roles and the transactions required for clearing in a multi issuer payment system. In this model the cheque cycle begins with a withdrawal transaction followed by a payment and a deposit just as in the simplied model. However, the issuer involved in the withdrawal and the acquirer involved in deposit will generally be economically distinct. The acquirer will thus be a creditor with respect to the issuer of the cheque. The clearing and the settlement bank is introduced to facilitate settlement of such claims, and a clearing request is added to the cheque cycle. In this part we will describe the actions performed by the clearing in response to clearing requests. The clearing will perform the following actions:

Validation of deposited cheques.

Clearing of cheques.

Request settlement between issuers and acquirers by the settlement bank.

Sometimes the term \clearing" will also be used to denote the combination of these three actions. The clearing cycle shown in Figure 14.1 is not complete in the sense that cheques are not ultimately returned to the issuer. The cheques are truncated by the clearing. This requires the issuer to trust the validation performed by the clearing. In Chapter 17 we will present a generalization of the clearing model which removes this requirement. In this generalized clearing model the 171

Chapter 14: Introduction


Settlement bank .6 . . Request settlement . . Clearing I Clearing request @ @ @

@ @

Acquirer

Issuer Withdrawal

6

Deposit

?

Payer

-

Payment

Payee

Figure 14.1: Generalized payment model with multiple issuers and acquirers and a clearing infrastructure. Solid arrows indicate movement of cheques. Cheques are truncated by the clearing.

172

14.2 De nitions


; ;

;

Clearing

; ; Recovery

protocol

Issuer 6

Recovery protocol

?

Payer Figure 14.2: Model for recovery of value in a lost wallet.

single centralized clearing center indicated in Figure 14.1 will be replaced by a hierarchy of clearing nodes. This generalization will be relatively simple once the centralized clearing model is described. The dotted line from the clearing to the settlement bank is not a part of the cheque cycle. The clearing only requests movement of funds between accounts at the settlement bank|no cheques are sent. The clearing is also involved in the loss recovery procedures when an electronic wallet is lost or destroyed. The clearing accepts a list of cheques from an issuer and returns deposit information about these cheques. This information permits the issuer, in cooperation with the payer, to compute the amount to be restored in the payer's new wallet. A model for the recovery procedure is shown in Figure 14.2.

14.2 Denitions In the brief overview given above, we have already introduced some new terminology to describe the clearing infrastructure. Some denitions follow: Cheque The term \cheque" is sometimes used to denote a \k-spendable cheque" consisting of k parts where each part can be spent once during a payment transaction. The term \cheque" is also used to denote a single such part. In this part we will use the term exclusively to denote such a singlespendable part. Clearing infrastructure The clearing infrastructure comprises all roles involved in the clearing of cheques: the acquirer, the clearing and the settlement bank. Clearing This role is responsible for the administration of the validation of cheques, the clearing and the settlement initialization request. In addition 173



to the normal clearing operation, the clearing is also involved in the loss recovery procedures when an electronic wallet is lost or destroyed.

Issuer This is the role that issues electronic currency in a withdrawal trans-

action. This \currency" is in the form of a number of cheques and an amount that can be spent using these cheques.

Acquirer This is the role that accepts spent electronic currency as a deposit from a payee.

Settlement bank This is the bank performing the settlement between the

participating issuers and acquirers. Each bank operating as an issuer or acquirer (or both) has an account with the settlement bank to settle net claims and debts after clearing of a batch of cheques.

Depositor In this chapter we will often use the term \depositor" instead of \payee".

Validation process This is the process of accepting or rejecting cheques submitted for clearing. Validated cheques are submitted for clearing.

Clearing process This is the process of accumulating the claims (amount

on cheques) on issuers by acquirers, with the aim to compute the net movement of funds needed for settlement between the participating banks. The term \clearing" is also used to denote the combined process of validation, clearing and settlement request.

Settlement process This is the process of transferring funds between bank accounts of issuers and acquirers to settle the net claims.

14.3 Requirements The following assumptions about the properties of the electronic payment system have been used in the design of the clearing architecture:

The payment system supports anonymous payments in the sense that the identity of a payer can't be linked to payment transactions without the payer's cooperation.

The validity of electronic currency (cheques) is restricted to a time period so that the number of cheques \in circulation" does not grow without bounds. This assumption will be used when duplicate checking is described.

A settlement bank exists to settle net debts resulting from a period of clearing of cheques.

A clearing architecture for electronic currency must satisfy the following high level requirements: 174


14.3 Requirements

Validation before clearing and settlement Since electronic currency rep-

resents a claim on the issuer, it must be validated before this claim can be settled between the claimant and the issuer. This validation includes verication of the formatting of the data comprising the electronic currency, verication of the authenticity and integrity of this data, and verication that the claim has not already been validated and cleared. A payment is made by assigning a value to an electronic cheque, signed by the payer and received by the payee. A cheque can't be spent twice as the spending requires the involvement of a tamper resistant device during the payment transaction. This device will refuse to spend the same cheque twice. Since the security of a tamper resistant device can't be proved, a second line of defense against double spending has been incorporated into the system. The clearing infrastructure will detect double spending after the fact and identify the double spender by a special processing of the cheques. Detection of double spending requires all spent cheques to be collected and stored for some limited time. The cheques must be stored in a single, but possible distributed, database.

Acceptable trust relations A clearing architecture must be designed with

well dened and acceptable trust relations for all involved roles. In CAFE parlance this means that no party should be required to trust other parties for correct and complete operation. For the clearing architecture this means that the issuer should be able to verify all claims on itself. The issuer must not be required to trust the validation of electronic currency performed by any other role. Ideally, the nal validation before clearing should be performed by the issuer. A consequence of this is that electronic currency cannot be truncated before it reaches the issuer, that is, deposited currency cannot be aggregated by, say, the acquirer and only the accumulated sum of all claims be forwarded to the issuer. All deposited currency should be returned to the issuer for validation before clearing. All roles in the CAFE payment system are able to verify the validity of electronic currency. For instance, the payee is able to verify that he receives valid electronic currency from the payer. The acquirers supply their patrons with necessary information to enable this verication. Prior agreements between participants and a court system must exist to regulate the behavior in case of dispute.

E ciency and capacity The clearing architecture must have sucient pro-

cessing and communications capacity and should be as ecient as possible. The clearing architecture must be scalable to be able to process an arbitrary number of electronic payment transactions. Communications eciency is somewhat in opposition to the trust requirements described above. Communications eciency can be improved by 175



Clearing 9. Settle

Settlement bank

7. Clearing

Clearing

4. Validation

Validator

8. Settlement request 5. Response 6. Clearing request

3. Validation

Clearing administrator

request

2. Clearing request 6. Response 7. Credit

Issuer

Acquirer

1. Deposit

Figure 14.3: The structure of the centralized clearing architecture.

truncating electronic cheques as early as possible in the deposit or clearing.

14.4 Clearing Architecture We will describe the architecture of the CAFE clearing system in this section. The following sections give a more detailed description of functionality and properties. The structure of the centralized clearing architecture is shown in Figure 14.3. This gure shows the roles involved in the clearing as rectangles. The clearing is split in three entities: the clearing administrator, the cheque validator and the clearing entity. Interactions are indicated by arrows. Circular arrows indicate processing activity performed. The ow of events required for clearing of a single cheque is summarized below. The numbers in the gure corresponds to the items in this list. 1. Initially, an electronic cheque is deposited by the payee at the acquirer. 2. The acquirer will periodically submit a batch of deposited cheques by a request to the clearing. 3. The clearing request is received by the clearing administration entity. The batch of cheques is now sent to the validator, possibly together with cheques received from other acquirers. 176


14.4 Clearing Architecture

4. The validator decides the validity of the received cheques and makes sure they have not been duplicated. 5. The validator sends a response to the clearing administration entity indicating the validity status of each of the submitted cheques. 6. The clearing administration now sends a clearing request for the validated cheques to the clearing entity. A response is also sent to the acquirer indicating the outcome of the validation of each submitted cheque. 7. The clearing entity updates its clearing accounts for the issuer and acquirer of each cheque. For each cheque the amount is credited to the acquirer's account and debited from the issuer's account. The acquirer can credit the depositor's account when the clearing response from the clearing center is received. 8. After some time has elapsed the clearing entity will compute the net claim or debt represented by each clearing account. This information will be sent to the settlement bank and the clearing account will be reset. 9. The settlement bank transfers funds in and out of each bank's account in accordance with the settlement request from the clearing center. The issuer is not active in a normal successful clearing of a cheque. The issuer will however be involved if a cheque is rejected due to broken tamper resistance in a wallet. This is discussed in the section on double spending. The issuer is also involved during the loss recovery procedure for lost or destroyed wallets. The above description indicates batch processing of cheques but this is not required. The architecture permits instant clearing of special \priority deposits", but this is not discussed further in this document.

177


178



Chapter 15

Functional Description In this section we give a functional description of the clearing architecture and the clearing roles. The description is given at a level that will give an idea of how the system works without going into great detail. The description is divided in three parts. First, a description of some database tables used by the clearing infrastructure is given for later reference. Next, some important issues such as double spending and blacklisting are treated. Finally, stepwise descriptions of the clearing infrastructure procedures are given.

15.1 Database Tables Only the major database tables maintained by the clearing infrastructure are described here. Other database tables will exist in the clearing infrastructure, but are not required for this simplied description. ChequeTable This table is used by the acquirer to store all cheques that are currently being processed by the clearing infrastructure. This is the main table storing all information about the deposited cheques. Other tables kept by the acquirer contain only references to this main table. DepositTable In this table the acquirer stores cheques deposited by payees. This table serves as a \input bin" until the acquirer decides to process a batch of cheques. ClearingTable The acquirer keeps a list of cheques that are currently being processed by the clearing in this database table. TransTable After clearing the acquirer moves the cheques into this table where they are kept until depositors' accounts are credited. ClearChequeTable This table is used by the clearing to store all cheques that are currently being processed. This is the main table storing all information about the cheques. Other tables maintained by the clearing contain only references to this master table. DupChequeTable This is the table used by the clearing to detect double spending and double depositing of cheques. The table will hold key information about all cheques that have been deposited until the cheque expires. RejectTable The clearing uses this table to store cheques rejected for some reason during the validation process. 179

Chapter 15: Functional Description


BlackListTable The clearing maintains a list of double spent cheques. This list

is stored in this table.

15.2 Some Clearing Issues In this section some of the key issues that had to be taken into account when designing the clearing architecture, are discussed in some detail.

15.2.1 Clearing and Settlement When a cheque has been validated the claim represented by the cheque must in some way be covered. In the CAFE clearing architecture we have specied a multilateral netting scheme. The clearing maintains clearing accounts for each participating bank. A bank will normally act both as an issuer and an acquirer of cheques. For each cheque submitted for clearing, a transaction record will be added to the issuer's and acquirer's clearing accounts. The amount on the cheque will result in a credit entry in the acquirer's account and a debit entry in the issuer's account. A clearing account will typically contain both credit and debit entries making the net balance less than the gross value of claims and debts. Credit and debit entries will always exist in pairs making the net balance of all clearing accounts zero. Periodically, the clearing will compose a settlement request. This request is composed by balancing each clearing account and consists of a credit or debit transaction for each bank acting as issuer or acquirer. Some banks will be net creditors and some will be net debitors. This settlement request is sent to the settlement bank which credits or debits each bank's account. The clearing of cheques ensure that only a minimum of funds have to be transferred during settlement between two banks since the clearing rst cancels mutual claims. In a multilateral netting scheme all banks are represented at the same time and place by the settlement bank. This permits each bank to settle his net debt or claim by a single transaction.

15.2.2 Double Deposits It is possible that a payee deposits the same cheque several times to the acquirer or to several dierent acquirers. This might be due to a communications problem or a malicious attempt by the depositor to claim the value of a cheque twice. The acquirer might also submit the same cheque twice to the clearing. There is no mechanism in the CAFE protocols described in Part III to prevent such double deposits, so this has to be detected by the clearing before clearing of the cheque. The clearing maintains a database table, DupChequeTable, with necessary information about all cleared cheques. During validation of a cheque, this table is queried to see if the cheque has been cleared earlier. The validator looks in DupChequeTable for a cheque with IBankId, KeyVersion, PayeeId and m corresponding to the cheque currently being validated. Here m can be thought 180


15.2 Some Clearing Issues

of as a \payment transaction identier" which is computed from values encoded in the cheque. If a row with matching attributes is found in DupChequeTable it is known that the cheque currently being cleared has previously been deposited. The cheque is then rejected by the clearing system with a notication to the acquirer.

15.2.3 Double Spending Traditional cash, in the form of coins and notes, have the property that it is very hard to copy. Information stored in a digital computing device can on the other hand be copied very easily. When a bank note is given away, it is gone and can't be spent again. However, when the note is represented as a string of bits, it is hard to prevent the payer from retaining a copy of the note when it is used in a payment. This copy could potentially be used for other payments. The payer must somehow be prevented from using the same notes twice. In the CAFE payment system we primarily rely on a tamper resistant device to prevent copying of electronic currency. The electronic currency is stored in this device and can only be handled by a few well dened functions as dened by the CAFE protocols described in Part III. Specically, the device does not permit the user to spend the same currency twice. Since it is hard to quantify exactly how tamper resistant such a device really is, the CAFE payment system also incorporates a fall back mechanism for detection of copied cheques after the fact in case a device is broken. If someone manages to copy electronic currency, the system should at least be able to detect this.

Detection of Double Spending In a manner similar to detection of double

deposits, the validator will query DupChequeTable to see if a particular cheque being cleared have been spent in another payment transaction. The validator looks in the database for a row with attributes IBankId, KeyVersion, i and 1 matching the cheque being cleared. If such a row is found in DupChequeTable, the validator knows that the cheque has been spent multiple times. The value 1 is a cheque identier while i identies which part of the kspendable cheque that has been spent. When a double spent cheque has been detected, the clearing will follow one of two possible procedures. If the cheque has previously been blacklisted, it will be rejected with a notication to the acquirer. In this case the payee will have to take the loss since he is responsible for checking the blacklist during a payment transaction. Blacklisting of cheques is described below. If the double spent cheque was not blacklisted, the cheque will be cleared just like any other cheque since in this case the payee was not able to distinguish between a valid cheque and a double spent cheque. The issuer will have to take the loss. By combining elements of the two instances of the same cheque the validator is however able to discover the identity of the double spending payer. This identity will be forwarded to the issuer to enable the issuer to take actions against the double spender. The validator will also blacklist the cheque to prevent further spending of it. 181



Blacklisting of Cheques A database table, BlackListTable, of cheques that

have been double spent is maintained by the clearing. This table will be distributed to payees via the acquirers. If the tamper resistant devices are not broken, this table will be empty. The goal of the blacklist is to prevent further spending of a cheque if the clearing has detected that this cheque already has been spent twice. The payees are responsible for checking all received cheques against their local copies of the blacklist during the payment protocol. If a blacklisted cheque is detected, the payee aborts the payment protocol at an early stage. If the payee fails to check received cheques against the blacklist, these cheques will be rejected by the clearing and the payee will have to take the loss. When the clearing detects a double spending, the cheque will immediately be added to the blacklist. Since payees operate o line, it will however take some time before the local copies of the blacklist maintained by each payee are updated. The clearing must allow for this delay when rejecting blacklisted cheques. If a cheque is added to the blacklist at a certain time T , the clearing should not reject clearing of additional copies of this cheque deposited before time T + where is the time required for distribution of the blacklist.

Longevity of Cheques and Database Size There are several reasons for

limiting the longevity of cheques used in the payment system. In this section we will focus our attention on limiting the size of database tables in the clearing. Another reason has to do with loss recovery and refund which is treated in Section 15.3.3. If cheques don expire some tables such as DupChequeTablewill grow without bounds. By limiting the longevity of cheques we can remove expired cheques from these tables and thus limiting their size. Expiration of cheques does not imply that payers run the risk of loosing money. It is not the money that expires|only the cheques. Cheques don't represent value|only the ability to perform payment transaction. This ability can be regained by withdrawing new cheques. This is similar to the situation today with expiring payment card. The card represents the ability to pay and not an intrinsic value. The longevity of cheques is limited by limiting the lifetime of the cryptographic keys used for encoding of the cheques. The key management system for the CAFE payment system is described in Part VI.

15.2.4 Currency Exchange

The CAFE system supports two dierent mechanisms for currency exchange. 1. During a withdrawal transaction an amount in a foreign currency can be withdrawn. Payment transactions can then be performed in the payee's local currency or any other currency withdrawn by the payer as long as this is accepted by the payee. 2. An exchange is performed at payment time. The payee requests payment in his local currency while the payer pays using a dierent currency. 182


15.3 Clearing System Procedures

To perform multicurrency clearing, the clearing will for each issuer or acquirer maintain one clearing account for each currency this role issues or accepts. Credit and debit entries will be added to the clearing accounts corresponding to the currency used in the payment. For the rst method of currency exchange, this is the only required modication to the clearing infrastructure. The issuer will issue (or sell) a foreign currency. Cheques spent by the payer using this currency will later be to debited the issuer's clearing account corresponding to this currency. Exchange during payment requires some additional involvement by the clearing infrastructure. In the payment transaction, the cheque is written out with two amounts and currencies: The amount paid by the payer and the amount received by the payee. Exchange rates for such payments are issued with a certain validity period by the payee's acquirer. When a cheque is deposited, the acquirer will verify that the correct exchange rate is used. The clearing will treat the cheque just like any other cheque with two exceptions. First, the validator will check the validity of the exchange rate. Next, the clearing will be done using the payer amount and currency. The actual exchange is performed by the acquirer after the cheque has been cleared. The acquirer's clearing account has been credited in the payer currency while the payee's account will be credited by the acquirer in the payee currency. The acquirer accepts the risk with this form of currency exchange|when a set of exchange rates are specied, the acquirer commits to buying currencies at these rates at a later time. Exchange during payment can also be realized in a similar manner with exchange rates specied by the payee. Instead of \selling" a currency at an exchange rate predetermined by a particular acquirer, the payee will sell his foreign currency at the current market rate, and he will be able to go to the acquirer oering the best rate as no prior arrangement is required. This exchange method is however not presently specied for the CAFE payment system.

15.3 Clearing System Procedures In this section a sequential description of the procedures performed by the clearing infrastructure is given.

15.3.1 Clearing of Cheques In the following description of the processing activity performed by the clearing infrastructure, each item corresponds roughly to one functional unit in the clearing infrastructure.

Deposit The acquirer receives a batch of cheques in a deposit transaction

from the depositor (the payee). An initial screening of the received cheques is performed to weed out invalid cheques as early as possible. This screening consists of verifying the formatting of the cheques and the values of some elds. Cheques found to be invalid are returned to the depositor. This validation is 183



not strictly required as all aspects of the cheques will be veried later by the validator. The acquirer assigns a unique cheque identication number, CNo, to each cheque before storing them in the database table ChequeTable. The cheques will be kept in ChequeTable until clearing is nished and the depositor's account has been credited. The cheques are also added to DepositTable which is a table of cheques waiting to be sent to the clearing center in a clearing request.

Send clearing request Triggered by some external event, for instance a

signal at the end of the day, the acquirer will collect a batch of cheques from

DepositTable. This batch is identied by a number, SubmissionNo, allocated by the acquirer. Both SubmissionNo and the identity of the acquirer are appended

to each cheque in the batch. The batch is then sent to the clearing in a clearing request. The batch of cheques is removed from DepositTable and inserted into the database table ClearingTable. This database table contains all cheques that have been submitted for clearing. The cheques will be removed from ClearingTable when a response to the clearing request is received from the clearing center.

Send validation request The clearing administration entity receives the

batch of cheques in a clearing request from the acquirer. All cheques together with CNo, SubmissionNo and ABankId are added to a database table, ClearChequeTable, which is the main database table in the clearing. A validation number, ValNo, is assigned by the clearing administration to keep track of this batch. The batch of cheques is nally sent to the validator in a validation request.

Validation The validator receives a batch of cheques in a validation request.

Each cheque will now be handled individually by the validator. Initially the following tests are performed: 1. The formatting and encoding of the information in the cheque is veried. 2. The validity of the exchange rate used during payment is veried. The validator now retrieves the cryptographic keys corresponding to the issuer of the cheque and the key version number. Both the issuer identity and key version number are encoded in the cheque. Now the following tests are performed: 1. It is veried that the cheque has not expired. The validity period of a cheque corresponds to the validity period specied for the cryptographic key used. 2. The cryptographic properties of the cheque are veried. This is basically the same verication as the one specied for the payee during the payment protocol.

184



The validator is now satised that the cheque was issued in a correctly executed withdrawal protocol and that it was spent in a correctly executed payment protocol. It remains to determine if the cheque has been previously cleared. The validator will now search his database table, DupChequeTable, for a cheque matching certain elds in the cheque being validated. If a match is found the validator is able to conclude that this cheque has previously either been deposited by the payee or submitted by the acquirer. The cheque is rejected. If the cheque is not rejected, the validator again searches DupChequeTable, now with a dierent search criteria. If a cheque matching certain elds in the cheque being validated is found, the validator is able to conclude that the cheque has been spent in two dierent payment transactions. This is termed a double spending and indicates that the tamper resistance of the payer's wallet is broken. If a double spent cheque is found, the validator will check the database of blacklisted cheques, BlackListTable, to determine if the cheque is already blacklisted. If the cheque is not found in the blacklist, it is added. The validator will use the two instances of the double spent cheque to compute the identity of the double spender and include this in the validation status. Handling of double spent cheques is discussed in more detail in Section 15.2.3. Finally the cheque being validated is added to DupChequeTable. A message indicating the individual validation results for each cheque in the submitted batch is constructed and returned to the clearing administration.

Receive validation status When the clearing administrator receives the

validation results, all cheques that were either found to be valid or double spent but not previously blacklisted, are stored in a database table, ClearingTable. This table holds cheques until the clearing of the cheques is done. A message is sent to the acquirer with validation information for each cheque. Any double spent cheques not previously blacklisted will carry a validation status of \valid" in this message. Any other invalid cheques will carry a rejection status indicating the reason for the rejection. If double spent but not previously blacklisted cheques are reported, these cheques together with information about the identity of the double spender, is sent to the issuer.

Clearing Triggered by some external event, the clearing entity will take a

batch of cheques from ClearingTable. For each cheque the clearing account of the issuer will be debited while the clearing account of the acquirer will be credited the amount on the cheque. Each bank has one clearing account for each currency used. At the end of the clearing period, the clearing entity will compute the net claim or debt for each clearing account by summation of all transactions recorded in the account. A settlement request is sent to the settlement bank. This request contains one amount for each currency for each participating bank 185



indicating credit or debit to this bank's settlement accounts. The clearing accounts are then reset. Clearing and settlement are discussed in more detail in Section 15.2.1.

Settlement The settlement bank receives the settlement request from the

clearing. It veries the claim or debt by each account holder indicated in the request and that all claims and debts net to zero. The settlement accounts are then updated according to the settlement request.

Receive clearing status The acquirer receives the clearing status from the

clearing. Rejected cheques are stored in a database table, RejectTable, which will later be used to inform the depositor about the clearing status of the cheques. Accepted cheques are transferred to TransTable for later crediting of the depositor's account.

Crediting Triggered by some external event the acquirer will take a batch

of cheques from TransTable and credit the amounts to the account's of the depositors.

15.3.2 Blacklist Distribution

The clearing maintains a blacklist of double spent cheques that have not yet expired. This list is distributed to payees to prevent such cheques to be spent an innite number of times. This section describes the distribution of the blacklist. The blacklist of double spent cheques is maintained by the validator. Triggered by some external event the validator will copy all cheques stored in the table BlackListTable and send this list to all acquirers. This list will be empty if the tamper resistance is reliable. The message will be timestamped and signed by the clearing. The acquirers store the received blacklist with timestamp and signature. This blacklist will then be sent to depositors on request|typically when a deposit is made. When a depositor receives a new copy of the blacklist, any old blacklist stored is deleted.

15.3.3 Loss Recovery and Refund

The CAFE payment system supports recovery of money in a lost or destroyed wallet. For loss recovery the unlucky payer visits the issuer. A protocol is executed between the payer and the issuer to determine the total amount and the cheque identiers, 1 , of all cheques stored in the wallet just after the last withdrawal. This protocol is described in Part III. Using the obtained information about the state of the wallet after the last withdrawal, the issuer can turn to the clearing to obtain information required to nd the current state of the wallet. The cheque identiers, 1 , are sent to the clearing in a recovery request. This request is handled by the validator which stores the received identiers in a database table, RecoveryTable. 186



Triggered by some external event, the validator will start removing expired cheques from DupChequeTable. The removed cheques are kept temporarily in a dierent database table. With the aid of this temporary table and RecoveryTable, the clearing constructs a table of all cheques for which some issuer has requested recovery information. This information is then sent to the requesting issuer in a recovery response message. The recovery information received by the issuer contains the amount for which each cheque has been spent. With this knowledge combined with knowledge of the balance in the wallet after the withdrawal, the issuer is able to compute the remaining value in the wallet. This remaining balance can safely be refunded since the lost wallet now only contains expired cheques that can't be used. The issuer will have to make sure that additional cheques can't be withdrawn using a lost wallet if it is later found. The issuer prevents further withdrawals by removing the wallet public key from it's customer database. A new public key will be added for the wallet replacing the lost wallet.

187


188



Chapter 16

Properties of the Clearing System The previous section has focused on the functionality of the clearing infrastructure. In this section we will look into some of its properties.

16.1 Risk Analysis The following roles constitutes the CAFE payment system:

The issuer.

The acquirer.

The payer.

The payee.

The clearing.

The settlement bank.

In this section we will look into the trust relations between these roles as dened by the clearing architecture and the risks these roles are exposed to. The settlement bank will not be discussed further since it just carries out requests placed by others|it has no interests that have to be protected.

The issuer The issuer has to trust the clearing to perform a correct validation

of cheques and only to clear validated cheques. The issuer also has to trust the clearing to return correct information about spending of cheques for which recovery information have been requested during a loss recovery operation. The generalized clearing architecture described in Section 17 removes this trust requirement from the issuer. The issuer will then be able to pick one \clearing node" out of many or ultimately perform clearing for itself. The issuer is responsible for covering claims represented by double spent cheques that have not yet been blacklisted. The issuer will thus run a signicant risk if the tamper resistant device can be broken. The clearing must be trusted by the issuer to maintain the blacklists correctly to reduce this risk somewhat. 189

Chapter 16: Properties of the Clearing System


The acquirer The acquirer accepts a risk when currency exchange is per-

formed during the payment transaction. The acquirer has to commit to an exchange rate which will be valid for some time. The actual currency exchange will take place later at a slightly dierent rate which will represent either a loss or a gain for the acquirer. The acquirer can reduce the risk by only accepting certain foreign currencies with suciently stable exchange rates or by specifying an exchange rate suciently in the favor of the acquirer to reduce the chance of a loss in case of rate changes.

The Payer The clearing will reveal the identity and secret key of double

spending payers during the validation of a cheque. Such payers will have to trust the clearing not to take advantage of this secret key to embezzle the payer. Knowledge of a payer's secret key permits the clearing to make payments on behalf of this payer. With currency exchange during the withdrawal transaction, the payer must accept the risk of holding foreign currencies. The currency exchange is performed during withdrawal while the payment is performed at a later time. The currency exchange rate is then likely to have changed and this will represent a loss or a gain for the payer.

The payee The payee will have to trust the clearing infrastructure to distribute blacklists in a timely fashion. Without updated blacklists the payee cannot accept payments without risking having the cheques rejected by the clearing due to double spending.

16.2 Fault Tolerance We have seen how the clearing will assist in the loss tolerance in the payment part of the system. In this section we will outline how the clearing handles internal faults. In the clearing the communication between entities takes the form of requests and responses. The depositor requests settlement of a cheque, and the acquirer responds by crediting the depositor's account. The acquirer handles the request by the depositor by requesting clearing from the clearing which responds with clearing between issuer and acquirer, and so on. The fault tolerance strategy of the clearing infrastructure is that all roles are responsible for the completion of a request until a response has been received, that is, all roles must be prepared to resubmit requests for which no response have been received within a certain time. It is ultimately the depositor that will carry the responsibility of having a cheque cleared and settled. The depositor must keep a cheque until he has been credited so that the cheque can be resubmitted in case of a fault somewhere in the clearing infrastructure. This fault tolerance strategy assumes that requests awaiting conrmation are stored in a stable manner. This will be ensured by using standard database 190


16.3 Capacity

mechanisms and is outside the scope of this document.

16.3 Capacity The clearing architecture described here does not scale very well and will suer from capacity problems once the volume of transactions gets suciently large. In Section 17 the generalized clearing architecture will be described. This is a distributed solution where additional \clearing nodes" can be added as the transaction volume grows.

16.4 Truncation and Accumulation of Cheques A payment system that allows the issuer and the acquirer of prepaid cheques to be economically distinct will have to deal with the fact that the issuer will generally not trust the acquirer when the latter presents a claim for settlement of a cheque. The cheque will then have to move through the entire clearing infrastructure and eventually be returned to the issuer for inspection before the claim is settled. Cheque truncation means that cheques does not have to move through the entire clearing infrastructure. A high proportion of the acquired cheques will probably be \on us", that is, the issuer and the acquirer might be dierent branches within the same bank. In this case there exists a trust relation between issuer and acquirer. Generally cheques can be truncated by a role if the issuer can trust this role. To maximize communications, storage and processing eciency it is important to truncate cheques as early as possible. If all cheques were truncated at the acquirer's site, the clearing could be reduced to a minor bookkeeping task between the issuers and acquirers. However, the problem is fundamentally one of mutual trust and integrity. How can the issuer be certain that the claim presented by the acquirer is valid without inspecting the cheque? In the clearing architecture described here cheques are truncated in the clearing. This might not be acceptable in a full scale, real world clearing infrastructure. The generalized clearing architecture discussed in Section 17 is more exible with regards to where cheques are truncated.

191

Chapter 16: Properties of the Clearing System

192



Chapter 17

Distributed Clearing So far we have discussed a centralized clearing architecture where cheques are truncated at the clearing. There are at least two shortcomings to such an architecture. First and foremost, the processing of cheques is centralized. When scaled to a European-wide system, the bottlenecks will certainly manifest itself in the hub of the system. We have to address the problem of scalability. Second, the trust assumptions that have to be acclaimed for a centralized clearing architecture leave much to be wanted in an environment of competing crossborder payment services envisioned by CAFE. We have to address the problem of trust among the roles of the clearing infrastructure. Hence, we provide a generalized architecture for a clearing infrastructure which address these problems. Note that the clearing infrastructure described previously can be considered a special case of the clearing described here.

17.1 Overview of the Model The generalized clearing infrastructure is organized as a tree or hierarchy of clearing nodes. A node in the tree is envisaged in Figure 17.1. A clearing node has a single connector to a parent node, and a number of connectors to child nodes. The top level (root) node does not have a parent connector, and the leaf nodes don't have child connectors. The clearing node can connect to a settlement entity, where it can request the settlement entity to do transfer of funds between any of the child nodes and Higher node

Settlement

Clearing & Validation entity

.............

Accounts database

Cheque database

Clearing accounts

Lower nodes

Figure 17.1: A general node in the clearing hierarchy.

193

Chapter 17: Distributed Clearing


the node itself. A settlement entity can be common for several clearing nodes. The clearing node can also be enabled to carry out cheque validation by connecting to a cheque validation entity. This entity will then be able to perform validation of the cheques issued under its clearing domain. The procedure of validation includes verication of cryptographic properties, and checking for double deposit or spending.

17.2 Functional Description This section outlines one possible procedure for clearing, and specically how a cheque will move through a clearing system consisting of general clearing nodes. We refer to a single cheque in the description, but in practice the cheques will be batched for eciency reasons. We use the terms subtree and common node in the description. The subtree of a node N is the tree of nodes where N is the root node. The subtree of a leaf node will consist of only the leaf itself. A node N is called a common node of N1 and N2 if both node N1 and N2 are in the subtree of node N . The root node is a common node of all nodes in the tree. 1. The cheque will enter a node by a deposit from a depositor to the acquirer represented by this node. 2. The cheque is moved \up" until it reaches a common node of the issuer and the acquirer which has the issuer's clearing entity in its subtree. 3. The cheque is moved \down" towards the issuer until it reaches the node with the issuer's clearing entity. 4. This node checks the cheque and produces a validation response. 5. The validation response is moved in the reverse path until it reaches the common node of the issuer and the acquirer, then \down" to the node where the cheque entered the clearing system. On its way, every node in the path arms the validation received and the clearing entries are made. A settlement request will eventually be produced by a clearing node, requesting settlement of net claims and debts of its child nodes and parent node. So in general, funds are not transferred directly from the issuer to the acquirer, because that will require the settlement entity to maintain a very large number of accounts. Instead, the money will \ow" through all the nodes along the path. We expect that the bulk of payment transactions will be \local" to a single clearing node, so no parent clearing node will be involved. More \exotic" cheques will require a longer clearing path, but this number will be small, with possible exceptions such as special tourist areas and airports. 194

CAFE Final Report Volume II 17.3 Properties of the Generalized Clearing Architecture

17.3 Properties of the Generalized Clearing Architecture The generalized clearing architecture take on the following properties:

Trust relations It is not required anymore that an issuer must trust a cen-

tral or foreign clearing center to validate its cheques. Furthermore, the acquirer will only depend on its association with its clearing node for validation of cheques, because the validation response will be transferred and conrmed through a \validation path" of clearing nodes structured in a hierarchy. Scalability Banks can easily attach or detach from a clearing node and only local updating will be necessary. Additional clearing nodes can be added with only local restructuring needed. The clearing infrastructure will be distributed and not dependent on a single hub. And local transactions can be processed locally, thus avoiding central bottlenecks and providing for optimal transaction processing. Cost-eectiveness The validation of cheques is the single most demanding functionality with respect to storage. In the proposed structure, this will take place in or close to the issuer. Accordingly, it will be easy to identify and place the cost of this on the issuer. As a result, an issuer will incur cost proportional to the size of the issuing, which seems to be quite reasonable.

195

Chapter 17: Distributed Clearing

196



Part VI

Key Management

197


Chapter 18

Introduction 18.1 Overview This part species the architecture of the key managemenet system for the ; system, where purse and observer are implemented as distinct hardware devices. The key management system for the and + systems is specied in Chapter 23. The organization of this specication is centered around the presentation of the parameter classes and their processing and distribution. A graphical notation is used to describe the generation, certication and distribution for each class of parameters. The main components of the architecture are presented in this chapter. Chapter 19 gives specications for each parameter class with an introductory section on the graphical notation used. Chapter 20 presents how wallets are activated. Chapter 21 discusses the management of concurrently valid versions of keys. Chapter 22 runs through a security analysis of the key management system.

18.2 Entities and Functionality The foregoing protocol description uses a somewhat simplied list of roles and entities, but in the discussion of the key management system some more details are required. This is necessary to facilitate descriptions of some subtle relations between these roles and entities, and key management is all about such relations.

18.2.1 Roles and Functional Entities Table 18.1 shows the complete list of roles and functional entities in key management system. This is an extended version of Table 4.1. For the administrators we use the same names for both roles and functional entities due to the one-to-one relationships between roles and entities. A combined observer and purse is denoted a wallet. In addition to the \normal" wallet, we also speak about auxiliary wallets and aliated wallets. Furthermore, the reload station, recovery station and activation station of an issuer is commonly referred to as the issuer station of this issuer. For the administrators the same names are used for both the roles and the corresponding functional entities due to the one-to-one relationship between roles and entities. 199

Chapter 18: Introduction Users Bank


Roles Issuer

Functional entities Reload station Recovery station Activation station Observer Auxiliary observer Aliated observer Acquirer Acquire station Clearing Clearing system Individual Payer Purse Merchant Auxiliary purse Aliated purse Payer station Payee Till Administrator System operator System operator Central certication authority Central certication authority Realm certication authority Realm certication authority Directory Directory Factory Manufacturer Manufacturer Table 18.1: Users, roles and functional entities in the key management system.

Below we briey describe the new roles introduced by the key management system and how the old roles relate to the key management system. System operator A single system operator is responsible for the generation of systemwide parameter values. Central certi cation authority A single central certication authority constitutes the top level of the CAFE certication hierarchy. This authority must be trusted by all other roles to issue certicates only as specied in this description. Realm certi cation authority Multiple realm certication authorities constitute the second level of the CAFE certication hierarchy. These authorities are authorized by the central certication authority and must be trusted by all roles to only issue certicates as specied in this description. Directory A data base for archiving certain public keys and parameters with certicates, to be accessed later by other entities of the key-management system, for instance, for updating or in case of dispute. Issuer Several issuers of electronic currency exist, where each issuer is associated with one and only one realm certication authority. Acquirer Several acquirers of electronic currency exist, where each acquirer is associated with one realm certication authority. 200


18.2 Entities and Functionality

Clearing system The clearing system performs the nal validation of cheques as well as clearing and settlement between the issuers and acquirers.

Some new functional entities have been introduced to reect that the issuer and payer controls dierent kinds of observers and purses respectively. Below we describe how some of the functional entities relate to the key management system.

Purse This is the payer controlled part of the wallet. Each purse is associated

with a single payer, an observer and an issuer. The purse is trusted by the payer. Observer This is the issuer controlled part of the wallet. Each observer is associated with a single purse, a payer and an issuer. The observer is encapsulated in a tamper resistant device trusted by the issuer, typically a smart card chip.

Auxiliary purse This functional entity replaces the payer's original purse dur-

ing a full recovery after loss of a wallet. This entity may be functionally equivalent to a normal purse or it may be a special recovery purse only used during execution of the recovery transaction. This entity is trusted by the payer.

Auxiliary observer This functional entity replaces the payer's original ob-

server during a full recovery after loss of a wallet. This entity may be functionally equivalent to a normal observer or it may be a special recovery observer only used during execution of the recovery transaction. This entity is trusted by the issuer.

A liated purse Each ; wallet can have an aliated wallet. This is the

purse part of this aliated wallet. It is trusted by the payer controlling the wallet. A liated observer This is the observer part of an wallet aliated to a ; wallet. It is trusted by the issuer.

Payer station This functional entity is used by the payer to store wallet-

related information outside the wallet. Till A till can receive payments from a wallet. Each till is associated with a payee and an acquirer. Manufacturer This entity controls the manufacturing of observers.

In the key management system keys and parameters are owned and controlled by functional entities. The distinction between whether keys are owned by entities or roles is only of importance with respect to the observers. An observer is owned by an issuer but under the physical control of a payer. Hence, a payer's purse will prevent the observer from sending any unsolicited information, including key information, to the other entities controlled by the issuer. 201



18.2.2 Functionality

The functional entities identied and listed above provide the functionality of the CAFE key management system. The functionality description of each key management parameter class, found in Chapter 19, is organized according to the following items:

Generation The functional entity responsible for generating and assigning a

value to the parameter instance is specied in this item. A brief description of the type of parameter and how it is generated is also given. Certi cation and registration Keys and parameters values must normally be certied to be trusted by a receiving entity in the CAFE payment system. In a certain sense, a certied key corresponds with the issuing of a credential giving the right to perform certain operations|for instance the right to issue electronic currency. Only registered entities can be granted such rights by certifying the link between the entity's name and the parameter value. Use This item gives a brief description of how and in which protocols the key management parameter is used. Distribution and updating This item describes how the key management parameter is distributed from the generating entity to other functional entities. Archiving Some parameters must be archived for \on demand" distribution and later settlement of disputes that might arise. Revocation Most key management parameter values have a limited validity period assigned, but ad hoc revocation must sometimes also be available. The operations of generation, registration, certication, distribution, and revocation are a subset of the key management operations listed in the standard ISO/IEC 11770-1 ISO96].

18.2.3 Identity Management

In the key management specication we have assumed that each functional entity is associated with an identier. There must exist an entity responsible for creating and managing such identiers. This entitiy and its functionality are outside the scope of this discussion. The directory might be a likely candidate for identity management in the CAFE system.

18.3 Certication Hierarchy 18.3.1 Certicates

An important design goal for the CAFE payment system is to keep to a minimum the need for trust assumptions between entities. Instead, we rely on veriable 202

18.3 Certi cation Hierarchy


transactions by employing many kinds of digital signatures. The integrity and authenticity of the key management parameters themselves are obtained by certication by a hierarchy of common trusted entities. A certication authority will use its digital signature to issue a certicate on a parameter value concatenated with other data, such as the entity names and period of validity. Table 18.2 summarizes the data elements required in a parameter certicate. Table 18.3 shows the dierent types of certicate types. The contents of certicates specied here ts rather well with the X.509 recommendation ISO89]. We use a parameter type identier and a parameter version number in addition to the certicate format specied by X.509. Data item Description type Parameter type identier value Parameter value valid Validity period of the certicate owner The identity of the functional entity having generated the parameter version The version number of this parameter authority The identity of the authority having certied the parameter signature A digital signature generated by the certifying authority on the data in the certicate Table 18.2: Data elements in a parameter certi cate.

Type id

certificate key clearing key system parameter max parameter issuer auth key issuer cheque key observer key purse key acquirer key

Description Realm certicate verication key Clearing system verication key Systemwide crypto parameters Non-cryptographic parameters, values Issuer authentication key Issuer cheque verication key Observer verication key Purse deblinding key Acquirer verication key

maximum

Table 18.3: Certi cate types.

18.3.2 Hierarchy

In an open system such as the CAFE payment system, it is infeasible to require that all functional entities will store all keys and parameters they eventually 203



will need. Many sets of keys and parameters are therefore carried in the form of certicates. An initiator of a transaction will on demand send certicates to other entities participating in the transaction. The CAFE key management system uses a hierarchical certication architecture with entities in three levels, as shown in Figure 18.1. A central certication authority constitutes the top level of the certication hierarchy. This entity certicates systemwide parameters and realm certicate verication keys. The next level contains a number of realm certication authorities. These authorities certify the keys and parameters generated by the principal entities in the payment system, such as issuer stations, observers and purses. The principal entities of the CAFE payment system are found at the bottom level of the certication hierarchy. These entities generate keys and parameters required for the execution of the payment-related protocols, such as authentication of intermediate values and messages.

Central certication authority

S ?S / w

Realm certication authority

S / ?S w

Issuer station, purse, etc

Figure 18.1: Structure of the key management certi cation hierarchy.

The payer's issuer and the payee's acquirer will be within the same realm perhaps for most payment transactions. When this is so, the certicate verication key of the realm certication authority will almost certainly already be stored with the payee's till. If the verication key of the realm certication authority has not been stored locally, then the certicate verication key of the central certication authority is required to verify the certicate of the verication key of the realm. The verication key of the central certication authority is assumed to be loaded in the setup of the entity. The CAFE certication hierarchy is a special case of the certication system specied in recommendation X.509 ISO89]. The standard X.509 permits a general certication structure that can be modelled as a directed graph with entities as nodes and certication relations as edges. This graph reduces to a tree with a specic number of levels in the CAFE key management system. ISO/IEC standard 11770-3 ISO94] describes a key distribution hierarchy along the same lines as used in CAFE.

18.3.3 The Directory The directory will be accessed by other functional entities. The access operation must be controlled with respect to the access rights assigned to the entity in 204


18.4 Certi cate Classes

advance. The registration of entities and the access control is performed by the directory itself. Although this specication refers to a single entity, there is no restriction to implement this as a distributed data base system.

18.3.4 Issuer Certication

The certication of a cheque verication key of an issuer should be interpreted as a certication of the issuer to be a member of the CAFE clearing club in that realm. As such, a payee's verication of the issuer's cheque verication certicate is a test on whether the cheques presented can be expected to clear through the acquirer. Note that this certication does not link the issuer to the right of issuing electronic currency denominated in specic national currencies. For this link to be certied, an extension to the certication hierarchy must be called for. One approach to this would be to introduce another realm authority type, so that the two types will be 1. Banking realm certicate. 2. Currency realm certicate. A certicate of the issuer's cheque verication key must then be able to contain digital signatures of several certication realms, as the need may be.

18.4 Certicate Classes We now present the classes of keys and parameters that are managed by the

CAFE key management system. Some of these classes are introduced by the

payment protocols, while others are a result of the key management system itself.

Central certi cation A single central certication key pair constitutes the

top of the CAFE certication hierarchy. This key pair is used for certication of systemwide keys and the verication keys for the realm certication authorities.

Realm certi cation A number of realm certication key pairs exist consti-

tuting the second level of the certication hierarchy. These keys are used for certication of keys generated by functional entities directly involved in the payment protocols.

Clearing system signature A clearing system key pair exists for signatures on black lists of double spent cheques.

Systemwide crypto parameters A number of systemwide parameters dening certain properties of the cryptographic systems used is required by the payment system.

Issuer authentication An issuer station will use this kind of key pair to enable authentication of identity and messages.

205



Issuer cheque signature An issuer station will use this kind of key pair for

the authentication of valid cheques. Observer signature An observer will use this kind of key pair for authentication of messages sent by the observer. This key is also used to identify the payer associated with a particular observer. Shared parameter A parameter shared between an issuer station and a wallet. This parameters can only be computed after the issuer cheque signature key and the observer signature key are computed. Observer PRSG parameters This type of parameter denes the pseudorandom sequence generator in the observer. Purse blinding The key used by a purse to blind messages sent by the observer and the corresponding public key for verication of proper blinding. A liated card signature Similar to the observer signature key but installed in a smart card aliated to the wallet. Non-cryptographic parameters Various system parameters that do not have cryptographic relevance. These parameters determine various limits, such as the largest value that can be stored in a wallet, or the maximum amount that can be paid in a single payment transaction. Acquirer signature Keys used by the acquirers to commit to a set of currency exchange rates. Figure 18.2 summarizes how values of these parameter classes are certied in the CAFE certication hierarchy. Only parameter classes shown in this gure are certied. The parameters max pay , max ticks and max trans belong to the class of non-cryptographic parameters. The parameter max trans is the only parameter certied on a fourth level in the certication hierarchy. This level also includes a plethora of intermediate values and messages authenticated by third level keys. These are all described in detail in the protocol description and are not shown here.

206

18.4 Certi cate Classes


Central certification

Systemwide crypto params

max_pay max_ticks

Acquirer Issuer cheque signature signature

Realm certification

Issuer authentication

max_trans

Observer signature

Clearing signature

Affiliated Purse wallet signature blinding

Shared parameter

Figure 18.2: Location of parameter classes in the key certi cate hierarchy.

207


208



Chapter 19

Parameter Classes 19.1 Notation We will describe the parameter distribution in the key management system partly by utilizing a graphical notation, where boxes indicate entities and arrows indicate ow of a parameter values. We use the following symbols to indicate the actions performed by various entities on the parameter sets:

Indicates generation of a set of parameters.

Indicates certication of a set of parameters.

2 Indicates storage or use of a set of parameters. A small plus sign (\+") may be put at the pointing end of an arrow to indicate a \one-to-many" ow. An example of this is shown in Figure 19.1. Here data from one entity of type A goes to many dierent entities of type B.

19.2 Central Certication 19.2.1 Generation The single central certication authority constitutes the top of the certication hierarchy. This authority has an RSA type key pair (mC eC dC ) where (mC eC ) is the public central certicate verication key and dC is the corresponding secret signature key. The key pair is uniquely identied by a version number vC . The central certication key is generated by the central certication authority itself. The public exponent is xed eC = 5. Generation of RSA type keys is described in Section 7.6.

A

+

B

Figure 19.1: Example of a one-to-many distribution.

209

Chapter 19: Parameter Classes


19.2.2 Certication and Registration

This key constitutes the top of the certication hierarchy in the CAFE architecture and hence cannot be certied by other mechanisms within the key management system described here. The central certicate verication key can either be certied by an external electronic certication mechanisms based on digital signatures, or it can be \certied" by distributing the key by a scheme which makes it infeasible for an unauthorized entity to convince others to use a forged key. One example of this kind of certication is publishing of the key by several newspapers concurrently. Another would be to continuously publish the key over some broadcasting network.

19.2.3 Use

The central certicate signature key is used by the central certication authority to make certicates of the public keys of the realm certication authorities, the clearing system, the systemwide crypto parameters generated by the system operator, and some of the non-cryptographic parameters. See Figure 18.2. The central certicate verication key is required for verication of these certicates. It is also required by entities performing verication of certicates issued by foreign realm certication authorities due to the hierarchical certication structure. This means that all functional entities involved in the payment system, clearing and key management must have access to the central certicate verication key.

19.2.4 Distribution and Updating

Figure 19.2 summarizes the distribution of the central certicate verication key. The key is generated by the central certication authority and sent to the directory which makes it available for access by issuer stations, acquire stations, manufacturers and the clearing system. Manufacturers install the key in observers. The key is installed in a freely readable area of the observer and can later be veried by the payer. If a sucient number of payers verify their key, a cheating manufacturer will be detected with high probability. The central certicate verication key will not be updated in an observer during its lifetime. Activation stations install the key in purses during the activation process. The key can be veried by the payer by comparing it with the key installed in the observer. A complete reactivation including an update of this key will be performed when a new observer is installed in the purse. The central certicate verication key is installed in tills by acquire stations. Acquire stations keep track of which key versions the till has and sends a new key during the rst deposit transaction following a key update by the central certication authority. Merchants can read the key and verify its validity against the published value. The central certication authority can introduce a new version of the central certicate key pair at any time. This key is distributed to manufacturers, issuer stations and acquire stations in the same way as outlined above. Manufacturers 210

19.2 Central Certi cation


Central Cert

Clearing System

Directory

+

+

+

Issuer Station

Manufacturer

Acquire Station

+ Observer

+

Purse

+

Till

Figure 19.2: Distribution of the central certi cate veri cation key.

will start installing the new key version in new observers. Wallets already activated will not be aected, but activation stations will use the new version in activation of new purses. Acquire stations install the new verication key in tills during the next deposit transaction to enable tills to accept payments from new wallets. Generation and introduction of a new central certication key pair does not require updating of other keys or parameters in the system.

19.2.5 Archiving Each version of the central certicate verication key is sent to the directory for archiving. The key must be certied by an external certication service or through publication in newspapers or similar stored in national or international archives.

19.2.6 Revocation A validity period is specied for the central certicate verication key. The key is invalid after the expiry date is reached. If the secret central certicate signature key is compromised, it must be revoked prior to scheduled expiration. This is accomplished by having a key revocation message published in the same way as the key itself was originally published in the directory. Revocation of a central certicate key pair will render all wallets using this verication key useless. These wallets will have to be returned to their respective issuers for a refund of the stored wallet balance. A new observer must be issued to the payer and the purse must be reactivated. 211



19.3 Realm Certication 19.3.1 Generation

The realm certication authorities of the CAFE system constitute the second level of the certication hierarchy. Each realm certication authority has its own RSA type key pair, denoted (mN eN dN ), where (mN eN ) is the realm certicate verication key and dN is the certicate signature key. The key pair is uniquely identied by the identity of the realm certication authority and a version number vN . Each realm certication authority generates its own certication key. The public exponent is xed for all authorities eN = 3. Generation of RSA type keys is described in Section 7.6.


Having been generated, the realm certicate verication key is sent to the central certication authority for certication. The central certication authority must register the realm certication authority identity and authenticate the submitted key. The means for doing this is not contained in this specication. A certicate of type certificate key is issued by the central certication authority, who returns this to the realm certication authority. Certicates of type certificate key will only be issued to realm certication authorities registered with the central certication authority. The identity of the certication authority is established during authentication by the central certication authority. Registration of realm certication authorities is outside the scope of this description.

19.3.3 Use

A secret realm certicate signature key is used to make certicates for issuer authentication and cheque verication keys, acquirer verication keys, observer verication keys and purse deblinding keys. A wallet needs access to the realm certicate verication key associated with the actual issuer station. This will be used for verication of issuer keys during activation, and in responding to a request from a till that does not have the verication key available. Tills need to be able to acquire certicate verication keys for all realm certication authorities. These keys are used to verify certicates on all issuer cheque verication keys. An wallet aliated with a ; wallet will need the realm certicate verication key for verication of the certicate on the ; observer's verication key. The clearing system needs all realm certicate verication keys for verication of updated issuer cheque verication keys.


Figure 19.3 summarizes how the realm certicate verication key is distributed. The key is generated by the realm certication authority and sent to the central 212

19.3 Realm Certi cation


Clearing Syst

Directory

Realm Cert

Central Cert

+ Issuer Station

+ Purse

+

Till

Observer

Figure 19.3: Distribution of the realm certi cate veri cation key.

certication authority for certication. The returned certicate is forwarded to the clearing system and all issuer stations under this particular realm certication authority. The realm certicate verication key is installed in purses during activation. The purse validates the certicate and forwards it to the observer where it is also validated and stored. The purse will store both the key and the certicate. Realm certicate verication keys will not be updated in activated observers. A till can request the realm certicate verication key from the purse during a payment transaction. The purse forwards the certied key and the till validates and store it. This is done by executing the get certif protocol. A new realm certicate key version can be introduced by a realm certication authority at any time, with the same procedure for certication and distribution as for the rst version. Activation stations will use the new version of the verication key in the activation of new wallets. Wallet already activated are not aected. Generation and distribution of a new realm certicate key pair does not require updating of any other key or parameter in the system.

19.3.5 Archiving The central certication authority will forward each new version of a realm certicate verication key to the directory. 213



19.3.6 Revocation The validity period is encoded in the realm certicate verication key certicate. When the expiry date is reached, the key becomes invalid. This validity check is always part of the verication procedure. If the secret realm certicate signature key is compromised, it must be revoked prior to scheduled expiration. The realm certication authority accomplishes this by requesting a key revocation certicate to be issued by the central certication authority. This revocation certicate is distributed in the same way as the certicate verication key. Revocation of a realm certicate key pair will render all wallets using this key useless. These wallets will have to be returned to their respective issuers for a refund of the stored balance. New observers must be issued, with which the purses must be reactivated. All key certicates signed with a revoked key are invalid. These keys must be submitted for certication using another realm certicate signature key.

19.4 Clearing System Signature 19.4.1 Generation

The clearing system has an RSA type key pair (mD eD dD ) where (mD eD ) is the clearing system verication key and dD is the signature key. The key pair is uniquely identied by a version number vD . This key is generated by the clearing system itself. Generation of RSA type keys is described in Section 7.6.

19.4.2 Certication and Registration The clearing system verication key is sent to the central certication authority for certication. The central certication authority must register the clearing system by identity, and authenticate the submitted key. The means for doing this is not contained in this specication. A certicate of type clearing key is issued by the central certication authority, who returns this to the clearing system.

19.4.3 Use The clearing system signature key is used to sign the (black) list of double spent cheques. This list is distributed to the tills through the acquire stations. This list facilitates tills to repudiate double spent cheques if presented more than twice as payments in the system. Tills need the clearing system verication key for validation of a black list supplied from the clearing system.

19.4.4 Distribution and Updating Figure 19.4 summarizes distribution of the clearing system verication key. After generation by the clearing system, the key is sent to the central certication 214

19.4 Clearing System Signature


Directory

Clearing System

Central Cert

+ Acquire Station

+ Till

Figure 19.4: Distribution of the clearing system veri cation key.

authority for certication. The certied key is returned to the clearing system which forwards it to all acquire stations. The clearing system keeps track of which key version each acquire station has. A new key is sent to acquire stations during the next deposit transaction after a key update. Similarly, each acquire station keeps track of the key version used by each till. A new clearing system verication key is sent to a till during the next deposit transaction after a key update. The certicate is veried by the till using the central certicate verication key. The clearing system can introduce an additional clearing system key version at any time. This key pair will be certied and distributed in the way outlined above. There is however no point in having several versions of this key in use at the same time so introduction of a new key version will probably be connected to the revocation of an older version. Subsequent black lists issued by the clearing system will be signed using the new key version. Updating the clearing system key pair does not require other entities in the system to update any of their keys or parameters.

19.4.5 Archiving Each version of the clearing system verication key is sent to the directory for archiving by the central certication authority.

19.4.6 Revocation A validity period is encoded in the certicate on the clearing system verication key. When the expiry date is reached, the key is revoked. 215



If a clearing system signature key is compromised it must be revoked prior to scheduled expiration. The clearing system accomplishes this by requesting a key revocation certicate to be issued by the central certication authority. This key revocation certicate will be distributed in a manner similar to the clearing system verication key.

19.5 Acquirer Signature 19.5.1 Generation The acquire station has an RSA type key pair for signing of currency exchange rates distributed to tills. This key is denoted (NA eA dA ) where (NA eA ) is the public acquirer verication key and dA is the secret signature key. This key is generated by the acquire station itself. Generation of RSA type keys is described in Section 7.6.

19.5.2 Certication and Registration The acquirer verication key is sent to the realm certication authority for certication. The certication authority authenticates the acquire station and the key. Certicates on acquirer verication keys will only be issued to registered acquire stations. Registration of acquire stations is outside the scope of this description. The realm certication authority issuer a certicate of type acquirer key on the key and returns this to the acquire station.

19.5.3 Use The acquirer signature key is used by acquire stations to sign currency exchange rates sent to tills. The signature is a commitment by the acquirer to accept deposits in all indicated currencies and credit the depositor's account in his home currency using the specied exchange rates. The acquirer verication key is used by tills to validate the currency exchange rates sent by acquire station. Without a valid currency exchange rate, only payments in the till's home currency can be accepted.

Remark The clearing system is treated as one entity in this specication.

In practice, it will be implemented as a distributed system. Hence, in a more detailed structure we will suggest that the payee's acquire station will be responsible for the black list supply, and also signed by the acquire station. This verication key will already be available for other purposes in the till. Then the acquire station will be able to accumulate black lists from several sources (clearing entities), and the tills will relate only to its acquire station. Note that this list will with very high probability have length zero. 216

19.6 Systemwide Crypto Parameters


Directory

Acquire Station

Realm Cert

+ Till

Figure 19.5: Distribution of the acquirer veri cation key.


Distribution of the acquirer verication key is illustrated in Figure 19.5. The key pair is generated, and the acquirer verication key is sent to the realm certication authority for certication. The certicate is returned to the acquire station. The acquire station keeps track of which version of this key is in use by each till. The acquirer verication key is updated in a till during the rst deposit transaction performed by this till following a key update. An acquire station can generate a new version of the acquirer key at any time and distribute this to associated tills. This does not inuence other functional entities in the system.

19.5.5 Archiving

The acquirer verication key is sent to the directory for archiving by the realm certication authority.

19.5.6 Revocation

A validity period is encoded in the certicate on the acquirer verication key. When the expiry date is reached, the key becomes invalid by rule. If the acquirer signature key is compromised, the key can be revoked by requesting a key revocation certicate to be issued by the realm certication authority. This certicate is sent to tills in the same way as the acquirer verication key.

19.6 Systemwide Crypto Parameters 19.6.1 Generation

A single system entity, the system operator, is responsible for the generation of a set of systemwide crypto parameters denoted p q g h Gc and Nphone . A 217



value set of these parameters is uniquely identied by a version number v . The parameters p q g h and Gc are used for generation and verication of Schnorr type digital signatures. Here p and q are primes such that qjp ; 1. Additionally g h and Gc are elements of order q in ZZp . The parameter Nphone determines the one-way function required for tick payments. This is an integer which is the product of two large primes. The factorization must be kept secret by the system operator. This can be done by deletion, because the system operator will never need the factorization of this parameter. Generation of RSA type keys is described in Section 7.6.


The system operator sends the systemwide crypto parameters to the central certication authority for certication. The central certication authority authenticates the sender and the message. This authentication and communications is outside the scope of this description. A certicate of type system parameter is issued by the central certication authority.

19.6.3 Use

Knowledge of the systemwide crypto parameters is required by all functional entities involved in the handling of electronic currency in the payment system. Issuer stations and wallets need the parameters for issuing electronic currency during execution of the authenticate, write cu tbl and gen cheque protocols and for recovery of lost money by executing rec payments (in case of failed payments) or recovery (in case of a lost wallet). Updating of issuer keys in a wallet is done using the update protocol which also utilizes the systemwide crypto parameters. The systemwide crypto parameters are also used during various kinds of payment transactions|in the payment protocol executed between wallet and till and in the transfer protocol executed between a ; wallet and an aliated wallet. The clearing system requires knowledge of the systemwide crypto parameters for validation of deposited cheques.


Figure 19.6 summarizes the distribution of the systemwide crypto parameters. After generation the parameters are sent to the central certication authority for certication. The returned certicate is forwarded by the system operator to the clearing system, the issuer stations and the acquire stations. The activation stations installs the current set of systemwide crypto parameters in observers and purses during activation. The parameters are installed in the observers before they are mounted in purses. The same set of systemwide crypto parameters is also installed in auxiliary observers and purses used during a recovery of a failed or lost wallet. An aliated wallet will also need the same set of systemwide crypto parameters installed during activation. 218

19.6 Systemwide Crypto Parameters


Directory

System Operator

+

Central Cert

+

Issuer Station

Clearing System

Acquire Station

+ Aux Observer

Aux Purse

+

+

+

+

+

Observer

Till

Purse

Affiliated Wallet

Figure 19.6: Distribution of the systemwide crypto parameters.

Systemwide crypto parameters are not updated in an observer during its lifetime. Acquire stations forward the set of systemwide crypto parameters to tills during deposit transactions. Each acquire station keeps track of which set of systemwide crypto parameters is in use by which till and updates the parameters in a till during the rst deposit after an update of the parameter set. The system operator can introduce a new version of the systemwide crypto parameters at any time. A new parameter set will be distributed as outlined above. Activation stations will use the new parameter set in the wallet activation procedure. Wallets already activated will not be aected.

19.6.5 Archiving Each version of the systemwide crypto parameters is sent to the directory by the central certication authority for archiving.

19.6.6 Revocation A validity period is encoded in the certicate on the systemwide crypto parameters. When the expiry date is reached, the parameters are invalidated. 219



19.7 Issuer Authentication 19.7.1 Generation Each issuer station has a key pair (Pa Sa ) for authentication purposes using Schnorr type signatures where Pa is the public issuer authentication key and Sa the secret issuer identity key. The key pair is uniquely identied by the issuer identity and a version number vBa . Each issuer station generates its own authentication key pair. The secret identity key is a random number Sa 2R ZZq . The public authentication key is computed as Pa = gSa mod p. The current set of systemwide crypto parameters is used.

19.7.2 Certication and Registration The issuer station submits the authentication key to a realm certication authority for certication. The realm certication authority will authenticate the issuer station and an integrity protecting channel must be used for communications to prevent certication of keys submitted by an impostor. The authentication and communications between issuer stations and realm certication authorities are outside the scope of this description. A certicate of type issuer auth key is issued by the realm certication authority, who returns this to the issuer station. The realm certication authorities will only issue certicates of this type to registered issuer stations. The identity of the issuer station is established during authentication. Registration of issuer stations is outside the scope of this description.

19.7.3 Use The issuer authentication key is used when issuer stations are authenticated by wallets and for authentication of message sent by the issuer station to the wallet. The issuer authentication key is utilized during the execution of the authenticate, write cu tbl, update, rec payments and recovery protocols. In these protocols only the purse, observer and the issuer station are involved. During execution of the recovery protocol the auxiliary observer and purse may use a dierent issuer authentication key than the one originally installed in the failed or lost wallet.

19.7.4 Distribution and Updating Figure 19.7 summarizes distribution of the issuer authentication key. After generation the authentication key is sent to the realm certication authority for certication. The certicate is returned to the issuer station. The issuer station installs the issuer authentication key in purses and observers during activation by executing the update protocol. This protocol will also be used for subsequent updates of this key. 220

19.8 Issuer Cheque Signature


Directory

Issuer Station

Realm Cert

+ Purse

Observer

Figure 19.7: Distribution of the issuer authentication key.

Each issuer station can decide to change its authentication key at any time| without any synchronization with other issuer stations or other functional entities. The new key is updated in wallets during the rst withdrawal transaction following the key change. No other entities need access to this key.

19.7.5 Archiving

The issuer authentication key is sent to the directory for archiving by the realm certication authority.

19.7.6 Revocation

A validity period is encoded in the certicate on the issuer authentication key. When the expiry date is reached, the key is revoked. Ad hoc revocation of issuer authentication keys is not supported by the CAFE system. This key is only used when the wallet communicates with the issuer station.

19.8 Issuer Cheque Signature 19.8.1 Generation

Each issuer has a key pair (Pc Sc ) for issuing cheques using Schnorr type digital signatures where Pc is the issuer cheque verication key and Sc is the cheque signature key. This key pair is uniquely identied using the issuer identity and the version number vBc . The issuer cheque signature key is generated by each individual issuer station. The secret signature key is a random number Sc 2R ZZq . The public 221



verication key is Pc = GSc c mod p. The current set of systemwide key parameters is used.

19.8.2 Certication and Registration The issuer station sends the cheque verication key to a realm certication authority for certication. The realm certication authority authenticates the issuer station and an integrity protecting channel should be used for communications to prevent certication of keys submitted by an impostor. This is outside the scope of this description. A certicate of type issuer cheque key is issued by the realm certication authority, who returns this to the issuer station. The realm certication authority will only issue certicates of this type to registered issuer stations. The identity of the issuer station is established during authentication by the certication authority. Registration of issuer stations is outside the scope of this description.

19.8.3 Use The issuer cheque signature key is used by the reload station during execution of the gen cheque protocol in a withdrawal transaction. The issuer cheque verication key is required for validation of cheques. Cheques are validated by the purse during execution of the gen cheque protocol. During a payment transaction the cheque is sent to the till and veried in the payment protocol. Finally the cheques are deposited and validated by the clearing system.

19.8.4 Distribution and Updating Figure 19.8 summarizes the distribution of the issuer cheque verication key. After generation the key is sent to the realm certication authority for certication. The certicate is returned to the issuer station which forwards it to the clearing system. The issuer cheque verication key is installed in purses during activation and subsequently updated using the update protocol. Both the key and its certicate are stored by the purse. During a payment transaction the till may request a copy of the cheque verication key for verication of the received cheques. The purse will then send both the key and its certicate to the till by executing the get certif protocol. The till validates the certicate by using the verication key of the issuer station's realm certication authority. This key can also be requested from the purse if it is unknown to the till. An issuer station may generate an additional set of cheque signature keys at any time. It is not necessary to synchronize this with other issuer stations or other functional entities in the system. The new key is distributed to purses, tills and the clearing system as outlined above. 222

19.8 Issuer Cheque Signature


Directory

Issuer Station

Realm Cert

Clearing System

+ Purse

+

Till

Figure 19.8: Distribution of the issuer cheque veri cation key.

19.8.5 Archiving

The issuer cheque verication key is sent to the directory for archiving by the realm certication authority.

19.8.6 Revocation

A validity period is encoded in the certicate on the issuer cheque validation key. When the expiry date is reached, the key is revoked. Ad hoc revocation of this key is not possible without distribution of a revocation list with a listing of all revoked keys, to all tills. This is not presently specied for the CAFE system but can easily be added in the future. Revocation of an issuer cheque signature key invalidates all cheques issued using this key. The balance of a wallet is not aected, but a payer with old cheques run the risk of experiencing a temporary loss of the ability to spend money when cheques expire. This is normally prevented by updating keys and cheques well in advance of a key revocation during a withdrawal transaction. A payer can regain his ability to perform payments by doing a withdrawal transaction which will also update the issuer keys stored in the wallet. When setting the validity period for issuer cheque signature keys, there is a tradeo to be made:

Payers want cheques that don't expire very often. This means long validity periods.

Loss recovery cannot be done until the lost cheques have expired. This means shorter validity periods.

Long validity periods mean that a lot of cheques have to be kept in the 223



clearing centre double spending detection database. This means shorter validity periods. Furthermore it will be advantageous to the size of the clearing system double spending detection database if issuer stations revoked these keys at dierent times.

19.9 Observer Signature 19.9.1 Generation

Each observer has a Schnorr type signature key pair (ps ss ) where ps is the public verication key and ss is the secret signature key. This key is used for authentication of the observer's messages. The observer signature key is generated by the observer itself. The secret part of the key is a random number ss 2R ZZq . The public key is computed as ps = gss mod p.


Previously described key and parameter sets have been sent through a secure channel to a certication authority for certication. Existing banking networks can be used for this. For observer keys no such secure channel exist. It is however of the utmost importance that the issuer station knows that the observer verication key it associates with a particular payer is in fact generated by this payer's observer. The observer generates the signature key pair during activation prior to installation of the observer into the wallet. Activation is performed at the issuer's premises and the observer verication key can then be read directly from the observer by the activation station. Since the observer is trusted by the issuer, he can be sure that the key is genuine. The activation station sends the observer verication key to the realm certication authority for certication. The certication authority authenticates the activation station and communications must go through an integrity protecting channel. The realm certication authority issues a certicate of type observer key and returns this to the activation station. Certicates of type observer key will only be issued to registered activation stations. Registration of entities is outside the scope of this description. This strategy for certication of the observer verication key permits the activation station to certify any key claiming it to belong to a specic observer. This possibility for framing is combated using the directory as will be discussed shortly.

19.9.3 Use

The observer signature key pair is used to authenticate the observer and messages sent by the observer to other functional entities. During a withdrawal transaction the observer signature key is used to sign messages sent from 224


19.9 Observer Signature

the observer to the reload station during execution of the authenticate and write cu tbl protocols. During execution of the transfer protocol the observer signature key is used to authorize an aliated observer to increase it's balance after a similar decrease in the ; observer. During execution of both rec payments and recovery the observer signature key is used to sign messages sent to the issuer station. A special use of the observer signature key is made during execution of the payment protocol. Here the observer encodes the secret part of the key in a cheque in such a way that it can't be extracted unless the same cheque is spent twice. This facilitates detection of double spenders in the payment system. In all protocols the purse veries the signatures made by the observer to prevent the observer from leaking unsolicited information to other functional entities.

19.9.4 Distribution and Updating The distribution of the observer verication key is summarized in Figure 19.9. After generation the public verication key is sent to the activation station prior to installation of the observer in the purse. The activation station forwards the key to the realm certication authority for certication. The returned key certicate is installed in the purse during activation. It is also installed in an aliated wallet during initialization of the aliation link. Note that the purse must only be permitted to learn the public part of the key even though this key in a sense represents the payer by signing commitments for the payer. Knowledge of the secret observer signature key would permit withdrawals and payments without using the observer, and this cannot be permitted. The observer is required to enforce prior restraint of double spending of cheques. The observer signature key pair is not updated during the lifetime of the observer.

19.9.5 Archiving The observer verication key is forwarded to the directory for archiving by the realm certication authority. We have already briey mentioned the potential problem with an activation station registering keys generated by itself claiming them to belong to specic observer. Such keys can be used to frame payers. If a dispute should arise, the payer can demonstrate that his observer does not contain the verication key kept in the directory. Since the observer is trusted by the issuer, the activation station must have registered an incorrect key.

19.9.6 Revocation A validity period is encoded in the certicate on the observer verication key. When the expiry date is reached, the key is revoked. Revocation of an observer 225



Directory

Realm Cert

Issuer Station

Purse

Observer

Affiliated Wallet

Figure 19.9: Distribution of the observer veri cation key.

signature key pair means that further withdrawals can't be performed. Any cheques already withdrawn can however be spent until the cheques expire. Ad hoc revocation of observer signature key pairs is equivalent to revocation of the observer itself. This can be done in two ways: 1. The reload station refuses further withdrawals for the observer. The observer can still spent already withdrawn cheques until they expire. 2. The observer is physically withdrawn by the issuer. Blacklisting of the observer to prevent further payments is impossible since the observer is anonymous during payment transactions.

19.10 Shared Parameter 19.10.1 Generation There exists a parameter pc which is \shared" between the observer and the issuer station. This parameter is shared in the sense that it depends on both the observer and issuer keys. The parameter is computed as pc = (ps h)Sc mod p. Computation of pc can only be done by the issuer station since this requires knowledge of the issuer cheque signature key. 226

19.10 Shared Parameter


Issuer Station

Purse

Aux Purse

Observer

Aux Observer

Figure 19.10: Distribution of the shared parameter.

19.10.2 Certication and Registration The shared parameter is not certied by a certication authority. It is computed by the issuer station and signed using the issuer identity key before distribution to the purse and observer.

19.10.3 Use The shared parameter is used during generation and validation of cheques. During execution of the gen cheque protocol this parameter is used by the observer, purse and the reload station. In the payment and rec payments protocols the observer used this parameter for generation of cheques. The shared parameter is also used by the auxiliary observer and purse during an execution of the recovery protocol, but this parameter is sent to the auxiliary observer and purse by the recovery station as a part of the protocol.

19.10.4 Distribution and Updating The parameter pc is computed by the issuer station and installed in the purse during activation. The purse forwards pc to the observer. Subsequent updates of this parameter are required each time the issuer station updates his cheque signature key and is performed by execution of the update protocol. Distribution of the shared parameter is summarized in Figure 19.10. It is of the utmost importance that the pc installed in an observer has been generated by the same issuer station that installed the issuer authentication key. This is required since the issuer authentication key is used for withdrawal transactions while the shared parameter is used for payments. To ensure installation only of valid shared parameters, the observer requires pc to be signed using the issuer identity key. 227



19.10.5 Archiving

The shared parameters are not archived.

19.10.6 Revocation

A special revocation procedure for these parameters is not required. They are automatically revoked when either the observer signature key or the issuer cheque signature key is revoked.

19.11 Observer PRSG Parameters 19.11.1 Generation

The observer has a special pseudorandom sequence generator (PRSG) which generates sequences of seemingly random numbers and with the special ability to regenerate these sequences later. The PRSG in the observer is dened by the parameter set (NS S S2 ). The parameter NS is a Blum integer. Generation of such integers is very demanding on computational resources and should not be left to the observer. Instead NS is generated by the issuer station since it is used to protect the issuer's interests. Having the purse generate this special integer might enable the payer to reveal the secret observer signature key through observation of output generated by the observer. The parameters S and S2 are random numbers in the range 2 : : : NS used as seeds for the PRSG. These are also generated by the issuer station.

19.11.2 Certication and Registration These parameters are not certied.

19.11.3 Use

The parameters for the PRSG are used by the observer for generating random numbers as specied in the CAFE protocols. The pair (NS S ) is used for generating random numbers for cheques while (NS S2 ) is used for all other random numbers. The pair (NS S ) will have to be loaded in an auxiliary observer during recovery for the auxiliary observer to be able to regenerate all possibly spent cheques since the last withdrawal. This will enable recovery of funds in a lost or failed wallet.


After generation the issuer station installs the parameters NS S and S2 in the observer prior to installing the observer in the purse. The issuer station will also keep a copy of NS and S for use during a wallet recovery. The issuer station will install these parameters in an auxiliary observer prior to installation in the auxiliary purse. 228

19.12 Purse Blinding


Issuer Station

Observer

Aux Observer

+

+

Figure 19.11: Distribution of the PRSG parameters.

Distribution of the PRSG parameters is summarized in Figure 19.11.

19.11.5 Archiving

These parameters are not archived.

19.11.6 Revocation These parameters cannot be revoked.

19.12 Purse Blinding 19.12.1 Generation

The purse requires a pair of purse blinding keys denoted (Np ep dp ) where (Np ep ) is the public deblinding key and dp is the secret blinding key. This is an RSA type key pair used for deterministic blinding of cheques. This key pair is generated by the purse. Generation of RSA type keys is described in Section 7.6. The public exponent is xed ep = 3.


The purse deblinding key is sent by the purse to the issuer station. The issuer station forwards the key to the realm certication authority for certication. The realm certication authority authenticates the issuer station and an integrity protecting channel must be used for communications. The realm certication authority issues a certicate of type purse key and returns this to the purse by way of the issuer station. Only registered issuer stations can request certication of purse deblinding keys. Registration of functional entities is outside the scope of this description. It is of utmost importance to the issuer that the blinding performed by the purse is deterministic. The reason for this is that the exact same blinding 229



Purse

Issuer

x 2R ZZNp a H(x)

a

; ;;;;;;;;;! ; ;

r (xy)dp mod Np

y

y 2R ZZNp

; ;;;;;;;;;; ;

r x

; ;;;;;;;;;! ; ;

a =? H(x) rep =? xy mod Np

Figure 19.12: Protocol for proving validity of blinding key modulus.

must be performed when cheques are regenerated during recovery of a lost or destroyed wallet. A necessary and sucient condition for this is that ep = 3 does not divide '(Np ). The issuer station does not know the factorization of Np and is thus unable to verify this by itself. A protocol is needed for the purse to prove to the issuer station that Np is of the correct form without revealing the factorization of Np . This protocol is based on the following observation: Let n be a non-zero integer, and let H denote the set of cubic residues mod n, that is H is the set of all y 2 ZZn such that y = x3 mod n for some x 2 ZZn . Observe that H is a subgroup of ZZn , and that if 3 6 j'(n), then H = ZZn from the properties of RSA exponentiation RSA78]. If, on the other hand, 3j'(n), then H is a proper subgroup of ZZn . This can easily be proved by letting y 2 H and x 2 ZZn such that y = x3 mod n and the observing that

y

'(n) 3

= (x3 )

'(n) 3

= x'(n) = 1 mod n:

The order of H must thus be a divisor of '(3n) . This shows that if 3j'(n), at most one third of the elements of ZZn are cubic residues mod n. The protocol in Figure 19.12 is executed between the issuer station and the purse to prove the validity of the modulus Np . For each run of the protocol, the probability of success is at most 31 if Np is not of the correct form. The protocol must be repeated a sucient number of times to ensure sucient condence in Np by the issuer station. Repeating the protocol 50 times should provide a sucient level of condence.

19.12.3 Use The purse blinding key is used by the purse for blinding of cheques during the execution of the gen cheque payment and rec payments protocols. The 230

19.12 Purse Blinding


Directory

Payer Station

Aux Purse

Realm Cert

Purse

Observer

Issuer Station

Aux Observer

Figure 19.13: Distribution of the purse blinding and deblinding key pair. The dashed arrows indicate the distribution of the secret blinding key.

same secret key is also used by an auxiliary purse during the execution of the recovery protocol. The blinding is veried by the observer using the purse deblinding key during the execution of the payment and rec payments protocols. The auxiliary observer involved in the recovery protocol will also use the purse deblinding key but gets this key from the recovery station during execution of the protocol.

19.12.4 Distribution and Updating Distribution of the purse blinding key pair is summarized in Figure 19.13. The key pair is generated by the purse during activation. The public part of the key is then sent to the issuer station who forwards it to the realm certication authority for certication. The certicate is returned to the issuer station which forwards this to the purse for installation in the observer. The issuer station will also keep a copy of the certied key for later installation in an auxiliary observer used during wallet recovery. The secret purse blinding key is output by the purse to the payer station which keeps a copy. This secret key is later installed in an auxiliary purse if recovery of the wallet is required. The purse may choose to install a new purse blinding key pair at any time by executing the same procedure with the issuer station. All cheques in the wallet will then be invalidated and a new withdrawal must be done. 231



19.12.5 Archiving The purse deblinding key is sent to the directory by the realm certication authority for archiving.

19.12.6 Revocation The purse blinding key pair is revoked when the payer chooses to update the purse blinding key.

19.13 Aliated Observer Signature 19.13.1 Generation The wallet needs access to the verication key of an aliated observer for the transfer protocol to work. This key is generated in the same way as the ; observer signature key pair as described in Section 19.9. The aliated observer signature key pair is denoted (pw sw ) where pw is the public aliated observer verication key and sw is the secret signature key.

19.13.2 Certication and Registration The aliated observer verication key is certied by the realm certication authority in a way similar to the certication of the ; observer verication key.

19.13.3 Use The aliated observer signature key is used by the aliated observer during the transfer protocol to authenticate the messages sent to the ; wallet. The verication key is used by both the purse and the observer for verication of the aliated observer's identity and the validity of messages sent by the observer.

19.13.4 Distribution and Updating Figure 19.14 summarizes the distribution of the aliated observer verication key. Most of the distribution is similar to the distribution of the ; observer verication key. During initialization of the aliation link between the and the ; wallet, the issuer station installs the certied key in the ; purse. The purse subsequently installs the key in the ; observer. The ; wallet and aliated wallet must have the same set of systemwide crypto parameters installed.

19.13.5 Archiving The aliated observer verication key is archived in the directory in the same way as the ; observer verication key. 232


19.14 Non-cryptographic Parameters

Directory

Realm Cert

Issuer Station

Affiliated Wallet

Purse

Observer

Figure 19.14: Distribution of the aliated observer veri cation key.

19.13.6 Revocation The aliated observer verication key is revoked in the same way as the ; observer verication key.

19.14 Non-cryptographic Parameters 19.14.1 Generation

A number of non-cryptographic parameters that determine aspects of the payment system behaviour must be distributed. These parameters are: max pay This parameter determines the maximum value that can be assigned to a cheque. Cheques spent for larger amounts than max pay are invalid. max bal The maximum balance that can be stored in a wallet. The total balance is the net balance of all currencies stored in the wallet denominated in the home currency of the observer. max curr The maximum number of currencies that can be stored in a wallet. max trans The maximum total that can be transferred from a wallet to an aliated wallet before a new withdrawal transaction must be performed with the issuer. max ticks The maximum number of \ticks" a cheque can be divided in. This parameter is denoted T in the description of the protocols.

233



The issuer station determines the values of parameters max bal , max trans and max curr , and can be distinct between individual wallets within constraints of the implementation. All tills must know max pay and max ticks . Of course, the complexity of the key management system will be somewhat reduced by keeping the values of these parameters as systemwide constants. This practice will also contribute to the payer's privacy. Therefore, the values of max pay and max ticks are set by the system operator.

19.14.2 Certication and Registration The values of max pay and max ticks are sent to the central certication authority for certication, where the authenticity of the message is veried. The central certication authority issues a certicate of type max parameter on the parameters and returns this to the system operator. The parameters max bal , max curr , and max trans , generated by the individual issuer stations, are not certied by the certication hierarchy.

19.14.3 Use The parameters max pay and max ticks are used by tills during execution of the payment protocol. These parameters limit the amount and number of \ticks" for which a single cheque can be spent. The reload stations use max bal and max curr during withdrawal transactions. The reload station will not permit the observer to install a currency table with a total balance exceeding max bal or if it contains more than max curr currencies. The observer, purse and aliated wallet use max trans during execution of the transfer protocol. A transfer will not be permitted if the total amount transferred between two withdrawals exceeds max trans .

19.14.4 Distribution and Updating The parameters max pay and max ticks are generated by the system operator and sent to the central certication authority for certication. The certicates are returned to the system operator, who forwards the certicates to all acquire stations. The acquire stations keep track of which version of these parameters is in use by each till. Updated parameter sets are sent to the till during the rst deposit transaction following a parameter update. Distribution of max pay and max ticks is illustrated in Figure 19.15. The max trans parameter is generated by the issuer station and installed in the purse and aliated wallet during activation of the aliation link. The parameter is certied with signature generated by the issuer identity key. Subsequently, the purse forwards the certied parameter to its observer. This is illustrated in Figure 19.16. 234

19.14 Non-cryptographic Parameters


Directory

System Operator

Central Cert

+ Acquire Station

+ Till

Figure 19.15: Distribution of the max pay and max ticks parameters.

Issuer Station

+ Purse

+ Affiliated Wallet

Observer

Figure 19.16: Distribution of the max trans parameter.

235



19.14.5 Archiving

The parameters max pay and max ticks are sent to the directory for archiving. No other non-cryptographic parameter is archived.

19.14.6 Revocation

The central certication authority encodes a validity period in the certicate of max pay and max ticks . The parameters are revoked when the expiry date occurs.

236


Chapter 20

Activation of Entities 20.1 Wallet Activation This section describes the dierent steps taken during activation of a wallet. The activation begins prior to installation of the observer in the purse. 1. The manufacturer installs the central certicate verication key in the observer. 2. The activation station loads the systemwide crypto parameters in the observer. The observer validates the certicate on these parameters. 3. The activation station loads the PRSG parameters, (NS S S2 ), in the observer. The activation station also inputs a random bitstring for later generation of the observer signing key. 4. The payer inputs a random bitstring in the observer using a trusted input terminal. 5. The observer generates the observer signature key pair by combining the random bitstrings entered by the activation station and the payer. If a source of true randomness is available to the observer, that should be used instead of the data entered by the activation station and the payer. 6. The observer sends the observer verication key to the activation station. 7. The payer or the issuer mounts the observer in the purse. 8. The central certicate verication key is loaded in the purse by the activation station. The payer may compare this with the verication key stored in the observer or with the key in the directory. 9. The activation station sends the realm certicate verication key to the purse. Subsequently the purse supplies this key to the observer. Both purse and observer validates the certicate on this key. 10. The activation station sends the systemwide crypto parameters to the purse, and the purse veries the corresponding certicates. 11. The purse generates the blinding key pair and sends the public part to the activation station. The activation station returns the certied public key which is then veried and forwarded to the observer by the purse. The observer validates the certicate on the key and stores it. 237

Chapter 20: Activation of Entities


12. The purse gets the observer verication key from the activation station and validates the certicate on the key.

20.2 Activation of Aliation This section describes the procedure that establish the aliation link between a ; wallet and an aliated wallet. 1. The activation station checks that both the ; wallet and the aliated wallet contain the same version of the systemwide crypto parameters. 2. The activation station installs the observer verication key in the aliated wallet. The aliated wallet validates the certicate on the key. 3. The activation station supplies the aliated observer verication key to the purse. The purse validates the certicate on the key. 4. The purse sends the aliated observer verication key to the ; observer. The observer validates the certicate on the key.

238


Chapter 21

Version management This section considers some issues with respect to updating of keys and other parameter values.

21.1 Overlapping Validity Periods Keys and parameters will have to be updated from time to time. However, it is infeasible to update keys instantaneously in all involved functional entities in the CAFE system. There may be an arbitrary long delay from the parameter update until a wallet \connects" to an entity that can provide the new parameter value to the wallet. The solution to this problem is to simultaneously use two versions of each key set with overlapping validity periods. The old key version is then still valid while the new version is gradually introduced. This is illustrated in Figure 21.1 The gure shows the validity periods for three dierent versions, A, B and C , of the same key set. From time t1 version B will be the preferred version and will be in the activation of wallets. From time t2 key version C will be the preferred one. Still, key B has half of its validity time left. This means that a key installed just before t2 will be valid for a relatively long period. Due to storage limitations, each wallet will be equipped with a single version of each required key. This implies that issuer stations and tills will have to adapt to the key version used by the wallet.

21.2 Validity Dependencies Some properties of the keys and the key management system place constraints on the validity periods of keys and parameters. These constraints are caused Time

t1

t2

A

t3

-

C B

-

Figure 21.1: Illustration of overlapping key validity periods.

239

Chapter 21: Version management

> Systemwide crypto parameters ZZ ZZ ~


Issuer authentication Issuer cheque signature observer signature

XXXXz :

shared parameter

Figure 21.2: Dependencies between key validity periods.

by: Generation dependencies between key and parameter sets. Constraints on the update frequency of certain keys and parameters. Often, the generation of a parameter value requires other keys or parameters as input. This implies that when the input parameters expire, the generated keys are also invalidated. Such dependencies exist between a few sets of keys and parameters, as illustrated in Figure 21.2. When the systemwide crypto parameters are revoked, both the issuer keys and the observer signature key are invalidated. Similarly, if the issuer cheque signature key or the observer signature key is revoked, the shared parameter is invalidated. The key management specication calls for some parameters to remain constant in a wallet during the lifetime of the observer. We assume that an observer has a xed validity period T after activation. This assumption leads to minimum validity periods for other keys and parameters in the system. The observer signature key and observer PRSG parameters are generated by the observer during activation. Thus, these parameters will have the same validity period T as the observer. The central and realm certicate verication keys and the systemwide crypto parameters are specied to be constant in a wallet during the lifetime of the observer. Due to the use of overlapping validity periods as illustrated in Figure 21.1, these keys and parameters must have a total validity period of 2T . This will accommodate wallets activated just before introduction of a new version of any of these parameters. Other keys and parameters are either not used by the wallet or can be updated through the use of specied protocols. Thus, there are no constraints on these keys and parameters except for dependencies illustrated in Figure 21.2.

240


Chapter 22

Security Properties This section presents some consequences if keys are compromised or forged.

22.1 Types of Attack Keys can be compromised or forged in three dierent ways: 1. A secret key can be compromised either by the owner inadvertedly revealing the secret key or by an impostor computing the secret key from the corresponding public key. The former is prevented by secure storage of keys in tamper resistant hardware. The latter is prevented by using strong public key algorithms with sucient key length. 2. An impostor may be able to obtain a certicate generated by a certication authority on a forged key pair. The certicate indicates that the key belongs to a dierent existing entity in the CAFE system. This is prevented by using strong authentication and secure channels when requesting certication of keys. 3. An impostor may be able to obtain a certicate on a forged key as outlined above except that the key owner identity encoded in the certicate does not correspond to any existing functional entity. For method 2 and 3 above it is also necessary for the impostor to be able to install the forged key in a number of functional entities. This analysis assumes this is feasible.

22.2 Forged Certicates The certication security breaks if either the central certicate signature key or a realm certicate signature keys is compromised. If the central certicate signature key is compromised, most of the keys in the system can be forged as described under method 2 and 3 above. If a realm certicate signature key is compromised then the acquirer signature keys, issuer authentication and cheque signature keys, and purse blinding keys can be forged under the given realm. If an impostor has managed to install a forged central certicate verication key in a subset of functional entities, this will be detected when one of these entities interact with an entity using the correct central certicate verication key, for instance, during a payment transaction when issuer keys and certicates 241

Chapter 22: Security Properties


are exchanged, or when a payer matches the central certicate verication key installed in his wallet against the value stored in the directory. In the case of compromisation of a certicate signature key belonging to either the central certication authority or one of the realm certication authorities, a dispute will eventually arise and the compromisation will be detected. Both central and realm certication keys can be revoked if compromisation is detected.

22.3 Key Compromisation The compromisation of some cryptographic keys in the system will permit counterfeiting of electronic currency. 1. The knowledge of the issuer cheque signature key permits the holder to make valid cheques that are not tied to any authorized activated observer. As a consequence, an unlimited number of payment transactions can be executed without observer hardware and without encoding a valid observer/payer identity in the cheques. 2. The knowledge of the issuer authentication key permits unauthorized updates of the currency table stored in the observer. Cheques must still be withdrawn and payment transactions be executed with the reload station, but the wallet balance can be increased unrestrictedly. 3. The knowledge of the observer signature key permits the holder to simulate observer behaviour. The observer will help withdraw cheques from the reload station, but will not decrease the balance during a payment or transfer transaction. If a cheque signature key has been forged, as described in method 3 above, this is detected when the rst forged cheque fails validation in the clearing system, because the clearing system will detect an unregistered issuer identity encoded in the cheque. It is not possible to use issuer authentication keys or observer signature keys forged using issuer identities not registered. If a forged or compromised key is associated with a registered issuer identity, this might be detected by withdrawal behaviour patterns. For instance, a user withdraws plenty of cheques but little or no currency amount. It will certainly be detected by the issuer as a discrepancy between the issued total and the total claimed by the clearing system. Eective ad hoc revocation of issuer authentication and cheque signature keys is not possible in the current system. A future enhancement with a revocation list of cheque signature keys stored in all tills is possible in principle. Observer signature keys are revoked by collecting the observer hardware.

22.4 Acquirer Signature Knowledge of the acquirer signature key permits forged currency exchange rates to be used by the tills. A payee is able to use this to accept payments in foreign 242


22.5 Clearing Signature

currency with an advantageous exchange rate. This will be detected by the acquire station at the deposit, and the acquirer signature verication key will be revoked.

22.5 Clearing Signature Compromisation of the signature key of the clearing system will permit a forger to create black lists of double spent cheques. This could permit further spending of a cheque already detected as double spent. A double spent cheque implies that the tamper resistant observer has been broken, and a double spender will be detected and identied by the clearing system. So this attack is very unlikely to happen. The clearing system will revoke the key if compromisation is suspected.

243

Chapter 22: Security Properties

244



Chapter 23

Key Management for the System Key management for the ; and /+ systems are almost identical. In this chapter we will outline how the key management for the /+ systems diers from the ; system.

23.1 Entities The functional entities in the ; and systems are almost identical. The main exception is that the observer and purse in the ; system are combined into a single physical device in the system. This is a tamper resistant device, and its functionality is trusted by both the issuer and the payer. Similarly the auxiliary observer and the auxiliary purse are combined into a single auxiliary wallet, similarly trusted by both the issuer and payer. This combination of observer and purse does not go equally far in the + system, but for key management considerations the two systems are equivalent in this respect. There is no aliated wallets in the system in the sense described for the ; system.

23.2 Certicate Classes Neither the purse blinding key nor the aliated observer signature key are used in the system. The observer signature and observer PRSG parameters are replaced by almost similar wallet signature and PRSG parameters. Some of the requirements for the wallet PRSG are dierent than for the ; observer PRSG. Both the issuer and the payer must trust the randomness of the pseudo random sequence generated by wallet. This means that neither the issuer nor the payer must know enough PRSG parameters to reconstruct the sequence. In the ; system the issuer is able to reconstruct the observer PRSG sequence. This dierence in the trust model is caused by the merging of the two entities, the observer and the purse, in the ; system into the single wallet in the system. While the observer, and hence the pseudo-random sequence generated by the observer, in the ; system is only trusted by the issuer, the pseudo-random sequence generated by wallet must be trusted by both the issuer and the payer. We say that a pseudo-random sequence is \trusted" by an 245

Chapter 23: Key Management for the System


entity when the sequence cannot be distinguished from a true random source by any other entity.

23.3 Central Certication The central certicate verication key is installed in a wallet by the manufacturer. The key can be read from the wallet at any time and its validity can thus be veried by the payer. This key is not updated in the wallet during its lifetime.

23.4 Realm Certication The realm certicate verication key is installed in a wallet by the issuer station during activation of the entity. The wallet veries the validity of the certicate on the key before it is accepted. The realm certicate verication key is not updated in the wallet during its lifetime.

23.5 Systemwide Crypto Parameters The systemwide crypto parameters are installed in the wallet during the activation of the entity. The validity of the certicate on these parameters is veried by the wallet before the parameters are accepted. The parameters are not updated in the wallet during its lifetime.

23.6 Issuer Authentication The issuer authentication key is installed and subsequently updated in a wallet by the issuer station using the update protocol. The validity of the certicate on this key is veried by the wallet before the key is accepted.

23.7 Issuer Cheque Signature The issuer cheque verication key is installed and subsequently updated in the wallet by the issuer station using the update protocol. The validity of the certicate on this key is veried by the wallet before the key is accepted. The wallet must keep both the verication key itself and the certicate on this key. The wallet must be ready to send both the key and its certicate to a till during a payment transaction.

23.8 Wallet Signature This signature corresponds to the observer signature in the ; system. It is distributed as in the ; system with the exception that there is no purse and no aliated wallet that need access to the verication key. 246

23.9 Shared Parameter


The secret key must be generated from an internal source of randomness in the wallet or a combination of random input entered by the issuer and the payer. It is of utmost importance that this key cannot be known outside the wallet|both the integrity of the issuer and the payer depend on this.

23.9 Shared Parameter The shared parameter is installed in a wallet and auxiliary wallet during activation, and subsequent updates are performed using the update protocol. In the system it is not required that this parameter is certied because the wallet can easily verify its correctness in, for instance, a withdrawal transaction which typically is executed after an execution of the update protocol.

23.10 Wallet PRSG Parameters The modulus NS is generated and installed in a wallet by the manufacturer that acts as a trusted party in the system. The modulus can be read from the wallet but not modied. The issuer and payer generate two seeds each independently and at random. The issuer generates S and S2 while the payer generates S and S2 . These seeds are input to the wallet using a trusted terminal. The wallet seeds are then computed, S = S S and S2 = S2 S2 , which are stored internally by the wallet. It is possible for the issuer and the payer to collude to compute S and then compute the wallet signature key by observing some payment transactions. The issuer and payer will however have conicting interests since always either the issuer or the payer will have to cover fraud committed by knowledge of this signature key. The issuer station must store NS and S , and the payer must store S for use in the recovery protocol. The wallet computes a value hash seed which must be stored by the issuer station. This value is computed as hash seed = H(NS S ). In case of recovery, the issuer station installs NS and S in the auxiliary wallet. The payer installs S . SC is then ready to regenerate the cheques to be recovered by executing the recovery protocol. The validity of these parameters is ensured by having the issuer station send a signed version of hash seed during execution of the recovery protocol. 0

0

0

00

00

0

00

00

0

00

0

00

23.11 Non-Cryptographic Parameters The max trans parameter is the only non-cryptographic parameter distributed to the wallet in the system. This parameter is installed in the wallet during activation of the aliation to a ; wallet by the issuer station.

247

Chapter 23: Key Management for the System

248



Part VII

Extensions

249


Chapter 24

Eciency Improvements In this chapter we will describe some improvements to enhance the eciency of the CAFE payment system. We will describe an alternative digital signature scheme, the eect of increasing the number of times each cheque can be spent in a payment transactions and we will look into the eects of performing preand post-processing.

24.1 An Alternative Blind Signature Scheme 24.1.1 Introduction The currently specied and implemented CAFE protocols are all based on the same restrictive blind signature scheme, rst presented in CP93a, Bra93, Bra94a]. The central protocol in this respect is the gen cheque protocol, in which the issuer signs a cheque generated by the payer in a blind fashion. In this section we consider an alternative blind signature scheme, which is similar from a security point of view but signicantly more ecient. Incorporating this blind signature scheme not only improves the performance of the gen cheque protocol, but also other protocols and parts of the payment system become simpler and more ecient. In this section we concentrate on the eciency improvements made possible by an alternative blind signature scheme. Security aspects and other issues have been considered elsewhere, see Sch95], and Bra95a, Bra95b, Bra95c, Bra95d] the two main issues are that the resulting payment system is believed to withstand parallel attacks, whereas the comparable system of Bra94b] is known to be vulnerable to this type of attack, and that the protection of a payer against framing by the issuer is not achieved in the same clean way as before. For two alternative immunization techniques against a parallel attack the reader is referred to Bra95c, Bra95d]. For more extensive information on the use of this alternative blind signature scheme in payment protocols the reader is referred to Sch95].

24.1.2 The Scheme The scheme presented here is based on Schnorr's ecient signature scheme based on the diculty of the discrete log problem Sch91]. In this scheme the public key of the signer consists of two large primes p q, where q j p ; 1, and two generators g and h of order q in ZZp. In addition an appropriate hash function H is part of the public key, which we assume here to map its input into a

251

Chapter 24: Eciency Improvements


Signer

Receiver

(h = g x )

w 2R ZZq a gw ;;;;;;a;;;;! c ;; c H(m a) ; ;;;;;;;;;; ; r r ? c r w + xc ;;;;;;;;;;! ; ; g = ah Figure 24.1: Issuing a Schnorr signature (c r) on a blind message m.

Signer

Receiver

(h = g x )

t 2R ZZq u v 2R ZZq w 2R ZZq g gt a v u a gw ;;;;;;;;;;! ; ; a ag h c H(g m a ) c ; ;;;;;;;;;; ; cc +u r r w + xc ;;;;;;;;;;! ; ; r (r + v )=t g r0 =? a hc0

0

0

0

0

0

0

0

0

0

Figure 24.2: Protocol to get a blind signature (g0 c0 r0 ) on a blind message m.

substantial subset of ZZq . The secret key of the signer is the unique number x 2 ZZq satisfying h = gx in ZZp that is, x is equal to the discrete log of h with respect to the base g. A Schnorr signature on a message m is now a pair (c r) satisfying c = H(m gr h c ):

;

Given a message m, the signer can easily compute a Schnorr signature (c r) using the secret key x. In that case, however, the message m will be known to the signer afterwards. For our purposes, we will need to hide the message m from the signer. This can be done by generating the signature in an interactive protocol between signer and receiver. The signature protocol is displayed in Figure 24.1, and is identical to Schnorr's identication scheme Sch91] with the modication that c is computed as a hash value of the initial value a and the message m, instead of choosing c random. In the new blind signature scheme based on the protocol of Figure 24.1, the modications are all on the receiver's side. The protocol is shown in Figure 24.2. Note that a signature now is a triple (g c r ) instead of a pair (c r). A triple (g c r ) is a valid signature on message m if 0

0

0

0

0

0

c = H(g m g r0 h c0 ): 0

252

0

0

;

24.2 k-Spendability Extension


By itself this protocol is not very useful because the signatures can easily be forged by selecting g and a as powers of h. This, however, is no problem in the way we use the protocol in payment systems it is only of importance that it is guaranteed that g is of the form gt or of the form ht , where the receiver knows t, t 6= 0. See, e.g., Sch95] for a more detailed explanation about the design and usefulness of this protocol in this section we only look at its performance. 0

0

24.1.3 Eciency Comparison Using the above blind signature scheme in the CAFE protocols, we get the following obvious improvements. In the gen cheque protocol, the issuer needs to send only one 64 byte number to the payer, instead of two (this also saves one exponentiation for the issuer). A signicant improvement is that the number of exponentiations to be performed by the payer is reduced by four per cheque. Also, the number of 64 byte numbers that have to be handled is reduced by one throughout the whole payment system. The payment protocol improves similarly. Also, the number of system parameters is reduced and in general the complexity of the system is reduced throughout. As will be addressed in Section 24.3, another improvement is that the number of \critical" exponentiations (those that have to be done online, unless one interleaves successive withdrawal sessions, which is infeasible for smart card based systems) is reduced from one to zero.

24.2

k-Spendability

Extension

24.2.1 Introduction In all variations of the CAFE payment system cheques are implemented as 2spendable cheques. This means that each signature from the issuer authenticates a cheque which can be used twice. The payer will only be identied if he passes the tamper-resistant protection of the observer and spends the cheque at least three times. Since the main bulk of the storage of a cheque in the payer's wallet comes from storing the signature of the issuer, the use of 2-spendable cheques enables the payer to do more payments between withdrawals, increasing the applicability of the system. The price for this improvement in eciency is a slight reduction of privacy as pairs of payments (corresponding to the same cheque) can be linked. In this section we rst review the ideas for 2-spendable cheques. Then these ideas are generalised to k-spendability for k = 1 2 3 : : : and the resulting gain in eciency is estimated. In the analysis below only the system is considered since both the ; and + systems can store a sufcient number of cheques using the added memory of the physically separate purse whereas the system is limited to a single-chip implementation of the wallet. The k-spendability extension is inspired by the way fail-stop signatures are extended to provide k messages with a fail-stop signature Hey92, p.76]. 253


24.2.2


k-Spendability

A 2-spendable cheque consists of the issuer's signature (r s) on a number 1 . Included in this signature is a commitment to two values 21 and 22 , where 21 is used in the rst payment of the cheque and 22 in the second payment (see Part III, Sections 8.9 and 9.8). This is done by including ci = H(2i ) for i = 1 2 as arguments to the hash function when computing the challenge c (see the gen cheque protocols in Part III, Sections 8.6 and 9.6) 1 . It is important that the payer is committed to 21 and 22 in this signature since this only leaves two possible ways to spend the cheque (even if the payer passes the tamper resistance of the observer). The only reason for making this commitment through the intermediary hash values c1 and c2 is that that in payments not involving 2i it is sucient to send ci (160 bits) to the payee. Thus both communication during payment and storage requirement of received payments at the payee and the clearing are decreased using the ci 's. The method for 2-spendable cheques can in a straightforward way be extended to k-spendable cheques by simply letting the payer generate k dierent 2i -values and commit himself to these by including ci = H(2i ) in the signature. We consider two possible ways of doing this. 1. c is computed as H(c1 c2 : : : ck a ab 1 3 ) (here means that padding is used so that a multiple of 512 bits is reached). 2. c is compute as H(root a ab 1 3 ), where root is a 512 bit value obtained by hashing the ci 's in a tree-like fashion (e.g., see Figure 24.3 for a ternary tree). Note, that root is obtained by concatenating its sons (and padding to obtain 512 bits). All other intermediary nodes are obtained by hashing the concatenation of its sons. Since one round of the hash function maps 512 bits to 160 bits we only consider binary and ternary trees (hashing four or more previous hash values requires more than one round of H). In the rest of this section d is 2 or 3 depending on whether a binary or ternary tree is considered. The next two subsections describe how the protocols for payment and deposit are aected by each of these possibilities. In these descriptions it is assumed that the cheque is used in the i'th payment (1 i k).

List-Like Hashing If the rst possibility is applied, then the only change to the payment protocol is that the payer must regenerate and send all cj 's for j 6= i to the payee, and the payee must use these values when verifying the blind signature. The payee must store these k ; 1 dierent cj 's and send them to the acquirer during the deposit. Otherwise the deposit protocol is unchanged. 1 The remaining arguments to the hash function a, 3

of the signature.

254

and ab are needed for the verication



Tree-Like Hashing The number of nodes in the path from 2i to root (not counting root) is at most dlogd ke. Thus the payer must send (in the worst case) (d ; 1)dlogd ke intermediary hash values to the payee, in order to let the payee verify that 2i has indeed been committed to. Furthermore, the payee must compute dlogd ke hash values in order to obtain root. Apart from this, the protocol follows the payment protocol. The payee must store these (d ; 1)dlogd ke intermediary hash values and send them to the acquirer during deposit. The acquirer can then verify the cheque as described above. This is the only change to deposit.

24.2.3 Eciency of the Suggestions This section considers the implications for computation, storage and communication by the above suggestions. Independently of the method for committing to 21 22 : : : 2k the most signicant changes to the protocols are

Increased computing time in the wallet for generating cheques during the protocol.

gen cheque

Increased time for regenerating empty cheques in payment.

Increased size of empty cheques. In the -system an empty cheque consists of

i c r cj 2i 1 3 :

The size of this has consequences for the communication in payment and deposit and for the storage requirements at payee and acquirer. root

HHH HH

-

;6 I @ ; @ ; @

-

AK A

-

6

H

;

6 6

;

;@ 6 I

6

HH

@

@

;

6 6

;@ 6 I ; @ 6

@ 6

6 6

21 22 23 24 25 26 27 28 29 210 Figure 24.3: Committing to 21 : : : 2k for k = 10. In order to verify that 22 is contained in the hash value, the nodes marked \ " must be sent together with 22 , and the nodes marked \-" must be computed. Arrows indicate hashing, lines indicate concatenation and padding to 512 bits.

255



Operation Time (msec.) atomic update 50 normal EE write (32 bit) 7 single exponentiation (ab mod n) 50 double exponentiation (ab cd mod n) 70 hash of 512 bit 11 (re)generate sigma pair 40 Table 24.1: Computation times for 2-spendable cheques. The observer smart card is running at 7.14 MHz (twice normal ISO speed). a c n are 512 bits numbers b and d are 160 bits numbers.

Since it may be assumed that payee and acquirer both have suciently computing power, the extra computations of the hash function in the verication of the cheque can be ignored. The analysis of the time is based on the numbers displayed in Table 24.1 showing the computation in the wallet implemented in a smart card of the basic operations. From this table we see that computation of one ci value requires approximately 120 msec (generation of (1i 2i ), one double-exponentiation and one hashing).

Linear Hashing

The wallet needs time to generate 21 22 : : : 2k and some time to compute the hash value, c. The computation of c1 : : : ck takes k 120 msec., and the computation of c takes

k 160 d 512 e + 4 11 < 50 + 5k msec. During gen cheque, the computation of (1 3 ) takes 140 msec, and the rest of the computation for the blind signature takes 260 msec. for the following operations: Computation of a 70 msec Computation of b 120 msec Verication of signature 70 msec Furthermore, storage handling and communication during gen cheque takes approximately 300 msec. Thus the time needed to generate one k-spendable cheque is approximately 750 + k 125 msec. For k = 2 this amounts to 1 sec., which is in line with measurements on the implementation of the -system. During the i'th payment (1 i k) the wallet must regenerate 2i and all cj for j 6= i. This takes (110 + (k ; 1)120) msec. The rest of the computation 256



time for regenerating a cheque is independent of k and will be estimated to 350 msec. (140 msec is required for the regeneration of 1 and 3 and at most 200 msec for storage handling). Thus the computation time is approximately 460 + (k ; 1)120 msec. An empty cheque needed for the i'th payment consists of

i c r (cj )j=i 2i 1 3 : 6

Assuming i can be represented by 1 byte, this requires the communication (and storage at the payee) of 1 + 20 + 20 + (k ; 1)20 + 3 64 = 233 + (k ; 1)20 bytes: With 19.200 baud and 12 bits per character the communication takes approximately: 146 + (k ; 1)17 msec: Thus compared to the computation time, the communication time is not seriously aected by the value of k. Similarly, the increased need for storage at payee and bank is not critical for practical values of k.

Binary and Ternary Trees The number of nodes in the tree (excluding the leaves and root) is roughly 2k ; 2 if the tree is binary and b k2 c + k ; 1 if the tree is binary, or approximately d d 1 k ; 2 in general. Generating a cheque requires the generation of all 2i 's and the computation of root. This takes k 110 + ( d d 1 k ; 2)11 msec. From the analysis above it follows that generating a k-spendable cheque takes time (in msec.) ;

;

Compute root k(110 + d d 1 11) ; 20 Compute c 50 Generate (1 3 ) 140 Computation for blind signature 260 Storage handling 300 Thus, in total the computation time in the wallet when generating a cheque is 730 + k (110 + d d 1 11) msec. During the i'th payment (1 i k) the wallet must regenerate 2i and all internal nodes in the tree except those on the path from 2i to root. Based on the analysis above, regenerating an empty cheque takes Regenerate all 2i 's k 110 d Regenerate internal nodes (( d 1 k ; 2) ; dlogd ke) 11 Regenerate (1 3 ) 140 Storage handling 200 ;

;

;

Thus, in total this the wallet needs 320+ k (110+ d d 1 11) ; dlog d ke) 11 msec. for regenerating a cheque. ;

257



An empty cheque needed for the i'th payment consists of

i c r 2i 1 3 and all internal hash values needed to compute root. In the worst case (d ; 1)dlogd ke such hash values are needed. Thus in total 233 + (d ; 1)dlogd ke 20 bytes are needed. With 19.200 baud and 12 bits per character communication of an empty cheque takes approximately: 146 + (d ; 1)dlogd ke17 msec:

Comparison The three methods are quite similar in complexity, with the binary tree being somewhat slower for (re)generating cheques in gen cheque and payment. However, the binary tree provide the smallest empty cheques, followed by ternary trees and linear hashing. Again, the dierences are quite small and in all systems communication time is dominated by the computation time in the wallet. Thus it will be most ecient to use the method for linear hashing or the ternary tree.

24.2.4 Conclusion

We now consider the eciency of using k-spendable cheques for various values of k if the commitment to 21 : : : 2k is done by linear hashing. Assume the payer should be able to make 100 payments between two withdrawals. This requires N k-spendable cheques where N k = 100. Table 24.2 shows how dierent values of k aects the time for generating the necessary cheques (computation in wallet + communication), the time for regenerating an empty cheque (computation in wallet) and the size of an empty cheque.

N

k generating reg. empty cheque size of empty cheque

50 2 25 4 10 10 4 25

50 sec. 32 sec. 20 sec. 16 sec.

580 msec. 820 msec. 1540 msec. 3340 msec.

253 bytes 293 bytes 413 bytes 713 bytes

Table 24.2: Complexity of k-spendability. The third column is the time for generating N k-spendable cheques, the fourth is the time for regenerating one empty cheque, and the third is the size of an empty cheque|this size has consequences for the communication complexity.

We see that going from 10- to 25-spendable cheques hardly gives any efciency improvement in gen cheque. Thus there is no reason to take larger 258


24.3 Exploiting Pre- and Post-processing

values of k. However, already k = 10 may be too large since payment will take around 2 sec. and relatively many payments can be linked. Thus it will be possible to improve the eciency of gen cheque with a factor of 2 without damaging the rest of the system by using choosing k a little larger than 2 (e.g., k = 6 or k = 8). This gain in speed can either be used to obtain more cheques or to decrease the time needed for withdrawal. If the cheque is regenerated while payer and payee are negotiating the deal as described in Section 24.3 it is not necessary to consider the time for regenerating cheques when choosing the value of k (since the communication time is relatively small even for large values of k). In that case the value of k should be chosen as a tradeo between privacy (unlinkability of payments) and eciency.

24.3 Exploiting Pre- and Post-processing 24.3.1 Introduction

In the performance analyses of the proposed CAFE systems we have mostly ignored the possibility of preprocessing and postprocessing to speed up the online part of various protocols. In this section we will investigate to what extent the eciency of the current systems may be increased by exploiting primarily preprocessing but also postprocessing to rene the protocols. For the sake of our discussion we will view a protocol executed between two functional entities as consisting of three stages: 1. Preprocessing by both functional entities. 2. Exchange of messages between the entities and the necessary computations. 3. Postprocessing by both entities (before storing the results in memory). We will refer to the second stage as the on-line part of the protocol and to the rst and third stage as the o-line part. The on-line part of a protocol consists of the messages exchanged and the computations necessary to complete these message exchanges. As the on-line part usually determines how long both entities have to be connected, the length (in time) of this part is considered critical. There are a lot of factors that inuence the (minimal) length of the on-line part. Clearly, assuming that there is sucient space to store intermediate results, any computation that does not depend on any message can be done in preprocessing, and any computation on which no messages depend can be done in postprocessing. However, also the order in which messages are exchanged and the number of rounds in which they are exchanged aects the length of the on-line part, since both entities must have nished the necessary computations before a message exchange can take place. Given that the intermediate storage of the payer's wallet is usually limited, the order in which the steps of a protocol can be arranged is restricted too, and we are faced with a scheduling problem. The use of o-line processing will be most eective for the ; system, where the payer uses a full-edged wallet with its own power source and computer. 259



As the two-button wallet in the + system also has its own power source, oline processing is interesting in this scenario, too. And even in the smart card only system the possibility of o-line processing cannot be ignored as a smart card is usually longer in the smart card reader than necessary. As noted above, o-line processing should be considered for the other entities in the protocols as well (e.g., reload station, acquire station and till). Similarly, o-line processing plays a role when wallets are personalised although personalisation normally takes place only once in the lifetime of a wallet, it is clearly in the interest of the personalisation entity that this can be done fast (e.g., to limit the connection time with a trusted server such that this does not become a bottleneck of the system). In the remainder of this chapter we will concentrate on the withdrawal and payment protocols for the proposed CAFE system. The goal is to obtain some estimates for possible improvements.

24.3.2 Withdrawal protocol The performance of the withdrawal protocol depends critically on the performance of the gen cheque protocol as this part will be iterated until the desired number of cheques is reached. Other major parts of the withdrawal protocol such as authenticate and write cu tbl are only executed once per withdrawal, so the expected gain of optimizing these parts may be considered marginal (and these parts are pretty much sequential in nature too). We will rst consider the system. Considering a single execution of this protocol in isolation, we see that the critical online part are the computations of the wallet between the rst and the second message exchange (see Figure 8.5 on page 69). This part is depicted in Figure 24.4.

wallet a a0 Gvc Pcu mod p b (b0 gcv puc)3 mod p c H(c1 c2 ? a ab 1 3 ) c0 c ; u mod q

Reload station a0 b0

; ;;;;;;;;;; ;

c0

; ;;;;;;;;;! ; ;

Figure 24.4: Critical part of gen cheque

Because of the additive way the blinding is done, only one of the exponentiations required for the computation of a and b cannot be done in preprocessing (rather than a multiplicative way of blinding as in CP93a], which requires two exponentiations online). More precisely, Gvc Pcu and gcv puc can be precomputed, and only the exponentiation with exponent 3 remains.2 2 An

advantage of the scheme in Section 24.1 is that the critical part doesn't contain a single exponentiation.

260



wallet ::: a Gvc Pcu mod p b gcv puc mod p c H (c1 c2 ?)

Reload station

0

0 0

0

a a0 a mod p b (b0 b )3 mod p c H (c a ab 1 3 ) c0 c ; u mod q 0

a0 b0

; ;;;;;;;;;; ;

0

00

0

c0

; ;;;;;;;;;! ; ;

Figure 24.5: Critical part of gen cheque with preprocessing

Also, the rst part of H(c1 c2 ? a ab 1 3 ) may be precomputed, such that upon completion of the computation of a and ab only the remainder of this computation needs to be done. This approach would be even more eective if 1 and 3 would appear before a and ab but this may degrade other parts of the implementation. This transformation is sketched in Figure 24.5, where H indicates the rst part of the computation of H, and H the continuation of this computation. Also, it should be noted that in case computations can be done while messages are received (because this is handled by dierent parts of the entity's device), it is advantageous to start the computation of a as soon as a0 is received. It may even be advantageous to send b0 rst in that case as the computation of b requires an exponentiation. To make such a revision of gen cheque useful, we have to interleave the executions of the protocol. That is, instead of executing the complete protocol repeatedly in a sequential fashion, we rst execute the preprocessing for each of the executions, then the online part of each execution, followed by the postprocessing parts. In this case, the online parts might be interleaved as well, which amounts to rst sending all a0 b0 -values, then all c0 -values, and nally all r0 values. Clearly, this approach requires quite some intermediate storage, in particular if the number of cheques per withdrawal is high (e.g., for the ; system). However, even for the system these improvements can be done to some extent by observing that once a cheque has been spent successfully, the freed space can be used to store results of the preprocessing stage of the gen cheque protocol.3 The preprocessing can be done whenever the smart card wallet is idle while inserted in a reader. For the + system the preprocessing stage of the gen cheque protocol can be done whenever a payment is completed that freed some space, which results in a speed-up of the withdrawal protocol by a 0

00

3 Only

successfully completed payments free the required space. In case of interrupted payments the space is needed for recovery. In such exceptional cases however the withdrawal is going to take more time anyways.

261



constant factor. If we assume that for the + and ; scenarios sucient space is available to store preprocessed values for gen cheque, the wallet may precompute (anytime it is idle and powered on) values for the gen cheque protocol. Then the only part that remains to be done is the on-line part of Figure 24.5. The time for this part is dominated by the time required for one exponentiation and to a lesser extend the time for the hash. A rough estimate indicates that a speed-up of 80{90% is possible for the withdrawal. With the blind signature scheme of Section 24.1, the speed-up will be even more signicant. To estimate the possible speed-up of the withdrawal protocol for the smart card only system, we consider the following modication. As each second payment frees at least 40 bytes of EEPROM, the idea is to preprocess the computation of c1 and c2 for the gen cheque protocol these numbers are 20 bytes each and can thus be stored in the freed cheque slot. The tag of the cheque slot should then indicate that it contains the preprocessed values instead of a cheque. As the generation of each of the c-values takes about 120 ms (see previous section), it means that each second payment will take about 0.3 seconds extra to compute and (atomically) store these numbers (atomic update takes 50 ms). On the other hand, each execution of gen cheque will take about 0.25 seconds less time. As the total time of gen cheque is estimated to take 1 second (see previous section), the resulting speed-up is 25%. Note that for 2-spendable cheques, the freed storage nicely matches with the space needed for the two 20 byte numbers. For k-spendable cheques with k > 2 this is not true anymore, so the resulting speed-up will be less than 25%.

24.3.3 Payment protocol Also for the payment protocol of the system there is some room for improvement. The way in which the respective messages between wallet and the till are exchanged has not been optimized yet to reduce the idle times of the two entities. For instance, the regeneration of the cheque that is going to be used in the payment, is only performed after the till has supplied the payment information in the rst message exchange of the payment protocol, see Figure 8.8 on page 74. A problem with this approach is that the storage in registers and RAM is rather limited for an smart card. A rough estimate, though, is that it might just t, i.e., that the values cj 2i 1 3 may all be precomputed. Again in case the blind signature scheme of Section 24.1 is used, this will t more easily as it requires one 64 byte number less in this case, precomputing the value of for phone payments may also be considered. The computation of the hash value H(2i , 1 , pay to , pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) is also time consuming. Again, as done in the previous section, the computation of this hash value may be started as soon as the rst blocks of data are available. As the till only supplies , after the (computationally demanding) verication of the cheque has been completed, there may be sucient time for the wallet to complete all of the computation of H(2i , 1 , pay to , pay fro , cu to , cu fro , ID P , pay type , date , , ? (T )) except for the last block. 262



Similarly, the value of in the phone-tick part of the payment protocol (Figure 8.9) can be precomputed to speed up the handling of a tick. Again, for the + and ; systems these techniques will be more eective. As the part of the payment protocol that depends on the till's messages is relatively small, the on-line part of payments may be reduced considerably if + or ; wallets are used.

24.3.4 Conclusion

We have considered some improvements for the withdrawal and payment protocols. The same techniques are applicable to the various recovery protocols, and also to the extended protocols. For the system based on a single chip wallet we have shown that a 25% reduction of the time needed for a withdrawal is possible. For the + and ; systems the speed-up may be as high as 80{90%, provided some memory of the wallet is reserved for the storage of precomputed values. Also, we have shown that the on-line part of the payment protocols may be reduced to the time required for some simple computations and memory operations (no exponentiations have to be done online). The improvements will be even more signicant if k-spendable cheques for other small values of k (larger than 2), as proposed in the previous section, are used and if the blind signature scheme of Section 24.1 is used.

263


264



Chapter 25

Multi-Currency Payments 25.1 Introduction One of the main features to be demonstrated in the eld trial is that of a crossborder electronic wallet. Such a system enables a user to load digital currency into the wallet, and then pay for goods and services in several countries. The CAFE system has been designed to operate in a multicurrency environment. The properties and workings of multicurrency payments are treated here. The structure of this chapter is: Discussion on multiple issuers and multiple currencies. The important cryptographic distinction is the assignment of secret keys to be used when issuing digital currency. The protocols and procedures for using multiple currencies with the wallet, the + wallet, and the ; system with the functional complete wallet.

25.2 Multiple Issuers The issuer and the acquirer are often combined and referred to simply as the bank in the CAFE context. The currency withdrawn from the bank carries the signature of the bank. Every issuer has its own set of signature keys. These keys are kept secret by that bank. The corresponding verication keys will be certied by the realm certication authority, along with the accreditation of the bank to be an issuer of digital currency of that realm. The CAFE withdrawal transaction combines issuing of digital currency with the debiting of the account of the payer, because the identity of the payer must be \imprinted" with the cheque. Hence, the withdrawal transaction must be \online" with the digital currency issuer. This is in contrast to the current cash system, where the central bank is the issuer, both in technical and monetary terms. Currently, the commercial banks operate as distributors of coins and notes. In CAFE the technical issuing procedure is an integral part of the withdrawal transaction. The bank will provide the payer with the certied public verication key of the issuer. At the payee, the certied verication key will either already be available to the till, or it can be requested from the payer, who will bring the issuer's public key stored in the wallet. The key for the verication of the certicate must be installed in the payee's till device prior to normal operation. This is part of the CAFE key management system. 265

Chapter 25: Multi-Currency Payments


25.3 Multiple Currencies Before discussing multiple currencies, we recall that the term home currency is the default unit of account for the payer's wallet. The term local currency is the default unit of account for the payee's till. For the payer, there exists two possibilities for paying where the home currency of the payer is dierent from the local currency of the payee:

Exchange before payment.

Exchange at payment.

Both kinds of currency exchange can coexist in the system.

25.3.1 Exchange Before Payment The exchange will take place at withdrawal time. The issuer will supply digital currency in the foreign currencies requested by the payer. Each currency will have its own balance in the currency table stored in the wallet. Primarily, a bank in the CAFE system will issue digital currency pegged to the domestic currency. Furthermore, an issuer can be enabled technically to issue digital currency pegged to other national currencies. The wallet holds balances in several currencies, and exchange from one currency to another can be requested by the payer during the withdrawal transaction with the reload station. Hence, the CAFE system allows for several issuers, each issuer being able to issue several currencies. To t existing arrangements, this must be conditioned on legal accreditation by the central bank governing the actual currency. For instance, commercial banks can be granted the right to issue a certain amount of foreign money in return for buying bonds from the central bank governing the currency. On the other hand, the multicurrency mechanisms of CAFE can eciently support more liberal monetary agreements.

25.3.2 Exchange At Payment The current economic state of oating currency exchange rates induces a risk by holding a particular currency. The CAFE system can easily adopt to the rule that whoever holds the currency accepts the risk of oating exchange rates. However, the CAFE system can also allow a forward exchange agreement between the payee and the acquiring bank, where the acquiring bank commits to a set of exchange rates. This eliminates the payee's risk of accepting foreign currencies. The payee will accept non-local currency during a payment transaction, anticipating it to be converted by the payee's acquirer to local currency at agreed upon rates. The payee will be credited by the acquirer with the amount requested during payment in local currency, while the payer can spend non-local currency available in his wallet. The exchange rate oered by the payee must be accepted by the payer. The payee presents the amount and the exchange 266


25.4 General Requirements

rate, and the payer's wallet will be able to present the amount denominated in home currency. So in general, the payer will be able to pay with one or more of the currencies in his wallet, conditioned on acceptability by the payee. This practice of accepting multiple currencies can be observed, for instance, at shops in international airports. Here is a more detailed example of how the practice may work. The payee will make an agreement about forward transactions with the acquirer, wherein it is stated the types and maximum amounts of currencies that are acceptable for deposit, and which exchange rates that the acquirer commits to, and the time period the commitment is valid. Then the payee can use \at least" these exchange rates when oered payment in non-local currencies. The payee's price is denominated in local currency, the till will compute the amount in the home currency of the wallet. In addition, the exchange rate oered is presented to the payer. Note that we say \exchange at payment". This is the payer's point of view. If the payer accepts a given exchange rate oered by the payee, it is equivalent to currency exchange. Nevertheless, the payee will receive and hold non-local currency. The actual exchange from the payee's point of view will take place at deposit time. If the payee has an exchange rate commitment from the acquirer, there is no practical dierence. However, if the rate has not been predetermined, the actual currency exchange will take place at deposit time, that is, \exchange after payment".

25.4 General Requirements 25.4.1 Exchange Before Payment These are the requirements of an exchange transaction between the payer and the issuer, typically at withdrawal time. 1. The exchange will only take place if the payer and the issuer agree on the source and target currencies, the amount to be converted and the rate to be used. 2. As long as the wallet does not contain more than max curr dierent currencies, the payer can introduce a new currency into the wallet. The total balance represented by all currencies should not exceed the value max bal. 3. The source currency of the exchange can either be the home currency or a currency already available in the wallet.

25.4.2 Exchange At Payment These are the requirements with respect to payment and deposit transactions when a the payment currency is dierent from the local currency of the payee. 267



1. The payment will only take place if the payer and the payee agree on the source currency (typically home currency), the target currency (typically local currency), and the exchange rate to be used. 2. The payee can restrict the set of acceptable currencies in a payment transaction. 3. The payee can only deposit the spent cheque if the exchange rate used in the payment is accepted by the acquirer. Then the acquirer will credit the payee's account by the value in local currency, whereas the payer currency claim will be submitted to the clearing system. 4. The clearing system will account for claims in all the currencies available in the payment system.

25.5 Protocols and Procedures 25.5.1 The Wallet Protocols

The wallet (typically implemented as a smart card) stores a currency-table, each row containing currency identier, the balance and the exchange rate to home currency. The rst row indicates the home currency of the wallet.

Withdrawal The write cu tbl protocol serves to provide an updated and valid currency-table to the wallet. The reload station will give the payer the following choices which may involve currency exchange: Perform currency exchange of value stored in the wallet. Withdraw from account and store in a specied currency in the wallet. Deposit to account from a specied currency in the wallet. Payment In principle, a payer may choose any currency available in the wal-

let for which the payee has available an exchange rate to his local currency. In general, this allows the payer to cover the total amount by compounding amounts in several currencies. The payment protocol is executed once for every currency, until the total has been paid. The reference implementation of the system admits the total amount charged by the payee to be paid using subtotals of dierent currencies a multicurrency payment. This multicurrency payment is realized by spending one cheque for each currency, ending when the grand total has be reached. The payer is allowed to choose a currency by running the show currencies protocol, where each currency balance is shown, together with the value measured in the home currency and the local currency units. This procedure is skipped if the payer does not have a choice. It is up to the payee (the till) to indicate the local currency, which will be the preferred choice of currency. The wallet will default to its home currency, if not told otherwise. The show currencies protocol can be executed if the 268


25.5 Protocols and Procedures

payer request it. The till can decide which currencies to accept according to prearranged rules. If ambiguity arises then the help of the payer is requested.

25.5.2 The Trial Implementation

In the trial, the wallet is realized in the form of a smart card. Hence, we refer to \card" as the wallet in this subsection. During the rst phase of the trial only Belgian Francs (BEF) will be accepted as tender for value loaded onto the cards. A card can be loaded with value in both BEF (home currency) and ECU. The exchange rate at loading will be identical to the exchange rate at the point of sale, thus nullifying the risk of currency exchange both at loading and payment time. The general rules of multicurrency operation implemented in the trial are as follows: When the home currency matches the local currency and the balance of the card is sucient, the payment will be in local currency. If the local currency is dierent from home currency, or there is insucient home currency then the payment currency will be ECU providing there is sucient balance. The payee will provide the exchange rate that determine the ECU value from local currency value. If neither sucient local currency nor ECU is available in the card then the payment transaction is aborted, even if the compounded value of both currencies is sucient. This implies that in the rst phase the home currency will always match the local currency, which is BEF. Only when the BEF balance on the card is insucient to cover a payment will ECU be spent. The cash register will always display the paid amount in BEF, whereas the payer's receipt and display will show the value in the currency taken from the card.

25.5.3 The + Protocols

The trial includes + wallets, in the form of two-button devices equipped with display, infrared communication, and smart card connector. With the functional complete ; wallet, the user can select which balance to use for a payment, but with the card and the two-button wallet, there is no way to do this, so a set of rules are needed to choose the currency. 1. The currency table of the card is sent to the till. The till rst looks for a balance in its local currency. If there is one, and it is sucient to cover the purchase, it is used. 2. If the local currency balance is insucient, the till searches the currency table row by row, starting with the rst, until it nds a balance that contains sucient value, and for which it has a valid exchange rate. 3. If the search of the currency table does not locate an acceptable row, the payment fails. 269



By convention, the issuer will load home currency in the rst row of the table. Hence the search rule described above will favor home currency after local currency. This will never happen in the trial because tills will have exchange rates only for ECU. In other words, the only acceptable currencies will be BEF and ECU.

Remarks: Cases can be created where the wallet contains sucient value, but

will be prohibited by the above procedure to make a payment. For instance, sufcient value only can be accumulated from several currency balances. Another point to make is that the system operators should be careful about how one currency is preferred with respect to another, because this embed the (static) rules for selecting the preferred currency rather than leave it up to the payer and payee to decide. There is an option to show the payer the total value of all currencies stored in the wallet, counted in the units of the home currency. For this purpose, exchange rates are loaded from the issuer and stored in the wallet. Then an approximation of the current value can be shown, in units of home currency. A similar table can be maintained by the payee, but now exchange rates with respect to the local currency. These exchange rates will be oered in a payment, and presumably have been supplied by the payee's acquirer.

25.5.4 The ; Protocols

Recall that the ; wallet device is realized as a hand-held computer device with keyboard and display, and as such can oer standalone interaction with the payer. The two main functional entities of the wallet are the purse, which is completely payer controlled, and the observer, which is completely issuer controlled. Both purse and observer store a currency table that is of the same format as in the system. The purpose of the show currencies protocol is to present the content of this currency table to the payer through the display of the wallet. Also, the decision of which currency to use in a payment can be made by the payer locally interacting with the purse. During payment, the purse requires user interaction to choose the currency to be used in the payment. Hence, it is not necessary to send the currency table to the payee. The rest of the payment protocol is similar to the system with the purse added. Of course, the default currency is the home currency of the wallet. The payee will return the requested amount in local currency. The wallet may display the amount both in local and home currency and the actual exchange rate. The details of the user interaction with the wallet for currency exchange during withdrawal are not described.

270


Chapter 26

Credential Schemes 26.1 Introduction A credential will be thought of as a signed message stating that a given person has a given right or property and constitutes as such a generalisation of electronic currency. The two fundamental transactions are issuing and showing credentials. A credential will be issued by an organisation to an individual, and the individual will show the credential to one or more organisations. The process of showing a credential should be o-line. Ideally, the same should hold for issuing a credential, but this is of less importance since a credential will be issued once and often shown many times. In these cases issuing only contributes very little to the overall cost of handling the credential. A relatively simple credential scheme can be constructed given any digital signature scheme:

Initialisation

First set up a key management centre. Each organisation and individual selects a key pair for the signature scheme, and gets a certicate on the public key at the key management centre.

Issuing

Organisation O issues a credential to individual I as follows: 1. I proves his identity to O. 2. If O decides to issue the requested credential, a signature on a message containing the public key of I and a description of the credential is made.

Showing

I later shows this credential to organisation, O , by proving his identity and presenting the credential to O . O veries the identication, the 0

0

0

signature on the credential and that the certicate on the public key is correct. This credential scheme requires that the individual is uniquely identied in each transaction. This is necessary in some situations, but in others it may be a nuisance. Therefore, one goal of the credential scheme presented in the following is to allow anonymous use of credentials. Very briey, this means that each individual is only known to organisations under a pseudonym. Organisation O 271

Chapter 26: Credential Schemes


determines whether or not to issue a credential based on the history of this pseudonym within the organisation (i.e., which credentials have been shown to O under this pseudonym). It should be noted that a credential scheme supporting anonymity does not prevent that an organisation requests identication of the individual if needed. Thus credential schemes supporting anonymity provides more generality. However, anonymity also provides a security problem since it will be hard to identify an anonymous individual abusing the system (e.g., showing a credential more times than allowed). As for electronic currency we therefore, add the possibility to identify individuals committing certain frauds. Following previous terminology this will be referred to as fall-back integrity. Section 26.2 gives a more thorough description of credential schemes including the necessary transactions and security aspects. Section 26.3 then presents the technical details of a credential scheme built upon the CAFE kernel used in the payment systems in Part III. The detailed analysis of the proposed scheme is omitted here, but the most important aspects of the security are briey mentioned. The chapter is concluded with a short description of some of the applications of the proposed credentials, which have been considered in CAFE.

26.2 Credential Mechanisms The following describes a general model of credential schemes based on CE87]. The roles in a credential scheme are a number of individuals and organisations. An organisation issues a credential to an individual, and an individual presents the credential to one or more organisations. Thus organisations should be able to issue credentials (possibly of several dierent types) as well as accept credentials issued by other organisations. Each individual has a pseudonym with each organisation which the individual either gets a credential from or presents a credential to (see Figure 26.1). Thus an organisation issues a credential on the individual's pseudonym, and when the individual wants to present the credential to another organisation he rst has to convert it to a credential corresponding to his pseudonym with that organisation. To facilitate constructing such a credential scheme a few additional roles may be needed:

Registration centre One or more centres registering pseudonyms. If an in-

dividual's pseudonym with a given organisation is registered at such a centre, the centre makes a so called validator proving that the pseudonym has been registered correctly. Such a centre must be trusted by the organisations to register pseudonyms correctly.

Issuing centre One or more centres, which help issuing credentials. Again,

such centres must be trusted by the organisations to issue only allowed credentials.

272

26.2 Credential Mechanisms


Ind. O1

I1 I2

In

Organisations

O2 P11 P12 P21 ?

?

Pn2

Ok P1k P2k

Pnk

Figure 26.1: Pseudonyms in organisations (? indicates that an individual has not registered a pseudonym with the organisation).

Representative Each individual may have a representative with each organ-

isation (or more precisely, a representative for each pseudonym). This is useful for privacy reasons as it may be possible to identify/recognise the individual if he gets or shows a credential himself (e.g., by physical appearance or by tracing a communication line). Credential clearing As for o-line payments a clearing infrastructure may be required to detect whether a credential has been used incorrectly (e.g., whether a credential has been used more times than allowed). Furthermore, the credential clearing nalises possible outstanding issues. For simplicity we shall not consider representatives here. Furthermore, it will be assumed that pseudonyms are registered at a registration centre, Z . Thus the concept of validators will be essential.

26.2.1 Required Protocols

For the sake of generality assume that each organisation can issue several types of credentials. For a given credential this is described by the parameter class . The following three protocols are the basic building blocks of a credential scheme. register pseudonyms This protocol allows an individual, I , to register a pseudonym. The result of this protocol is a publicly known validator and a pseudonym, which only the individual gets to know at this point (plus possibly some secret information needed to use the pseudonym). issue credential This protocol allows an organisation (possibly with the help of an issuing centre) to issue a credential described by class on a pseudonym. If the organisation has not registered the pseudonym previously, a validator on the pseudonym should be supplied by the individual requesting the credential. show credential This protocol allows an individual having a credential to present it to an organisation (under the pseudonym with that organisation). 273



In the following we shall be concerned with o-line credential schemes for which detection of abuse after the fact is required. Therefore, the following protocol is required as well: This protocol involves credential clearing and an organisation, which has accepted a credential. It allows the organisation to submit the credential to the credential clearing, and the clearing will investigate whether the credential has been used properly.

deposit cred

For completeness, we mention that a credential scheme may involve other protocols, such as

A protocol for revoking credentials and validators. This is useful in case abuse is detected. In a totally privacy protecting scheme this may not be possible (eventually credentials or validators should expire, though).

Transferring credentials to another individual. This is useful in payment systems, which can be considered a special credential system.

Protocols and measures supporting loss tolerance.

However, these protocols are not used here, and they will not be considered further.

26.2.2 Security Aspects In the following we describe the security requirements that the protocols described above must satisfy. At this informal level only the general principles are described. Since, deposit cred depends on the kind of abuse to be detected it will not be treated at this general level. First, however, the fundamental assumptions about the trust relations between the various roles will be described.

Trust Assumptions At the protocol level, as described in this chapter, only very little trust between the roles is required. Most notably, the individuals trust that Z will help registering them. However, for the registration at organisations, it is up to the organisation whether it wants to register an (anonymous) individual under a given pseudonym. The organisations trusts that Z veries the identity of individuals properly, and that it only issues validated pseudonyms if this verication succeeds. Finally, for anonymity each individual trusts that other individuals are also interested in protecting their privacy. Otherwise, if all individuals but one happily identify themselves in each transaction then implicitly the last one will also be identied. 274


26.2 Credential Mechanisms

Requirements to Availability The protocols register pseudonyms, issue credential and show credential must be complete in the sense that if pseudonyms are registered correctly, a subsequent execution of issue credential will lead to a credential, which will later be accepted in an execution of show credential. A pair (p v) of a pseudonym and a validator is called correct for individual Ij if Ij can later get or show a credential under the pseudonym p. Other aspects of availability, such as the ability to actually execute these protocols depends on the good will of the involved actors (i.e., that they are willing to participate in the protocol).

Requirements to Integrity For register pseudonyms, it must be infeasible to make a pair (p v) of a pseudonym and a validator unless the registration centre is willing to issue such a pair. It must be infeasible to obtain a credential unless the organisation is willing to issue such a credential in an execution of issue credential. Finally, if a credential is issued under a pseudonym of Ij it should be infeasible to show it under a pseudonym of Il if l 6= j .

Requirements to Anonymity In an execution of a protocol between two roles, each role gets a view consisting of the input to the protocol, the random bits used by this party and the messages received (see GMR89] we have included the input in the view for simplicity). The distribution of such a view is induced from the random bits of the other participant in the execution. Assume, that the registration centre has registered n honest individuals for both organisation Os and Ot . It is required that given

the registration centre's view of a registration at Os and a registration at Ot ,

Os's view of issue credential of a credential described by class , and

Ot 's view of show credential of a credential with the same value of class ,

the probability (over the random coins of the individuals) that the views of issue credential and show credential belong to a given individual among these n individuals is n1 . This must remain satised if the registration centre and organisations deviate from the prescribed protocols. This requirement takes into account that the registration centre may know to which organisation an individual is being registered, and that when a credential is shown the recipient knows who issued it. Note that, this requirement implies anonymity of the individuals in issuing and showing of credentials. 275



26.2.3 Existing Schemes

Payment schemes can be considered special credential schemes, but to our knowledge only very few general credential schemes have been suggested in the public literature. In the following we consider two proposals. The most well-known scheme is probably that of Chaum and Evertse in CE87]. This scheme is based on RSA RSA78], and requires a trusted registration centre for registering pseudonyms and an issuing centre for issuing credentials (as pointed out in Cha90] these two centres need not be identical). Once an individual, Ij has received a credential from organisation Os under pseudonym Pjs this credential can be shown to another organisation Ot under the pseudonym Pjt with that organisation without interacting with the centres. This procedure relies on algebraic properties of RSA and can be done without providing any link to the individual's identity or the issuing of the credential or other presentations of the credential. By the algebraic properties of RSA this scheme is very exible, and can be applied to various settings. This is discussed further in Cha90]. Thus, in short, this scheme is very exible and protects the anonymity of the individuals very well, but the security against forgeries relies completely on the centres. In fact, only the centres are able to make signatures in this scheme. Thus if the centre is compromised, all organisations are compromised as well. Another scheme is proposed by Chen in her Ph.D.-thesis Che94]. In this scheme the role of the centres is reduced, but it only allows an individual to show a credential once (more presentations can be linked). A registration centre is needed for registering pseudonyms with each organisations. An organisation issues a credential by making a signature on the pseudonym. The individual blinds this to a signature on an intermediary pseudonym during the credential issuing protocol. Later when the individual wants to present the credential to organisation O the signature on the intermediary pseudonym is shown and the individual proves knowledge of a certain connection between the intermediary pseudonym and the pseudonym with O. The advantage of this scheme is that a trusted centre is only required for setting up pseudonyms. No trusted centre is needed during issue credential. The disadvantage of this scheme is that credentials are inherently \one-show": if a credential is shown more than once all showings can be linked. However, several presentations only harm privacy|not the integrity of the individual.

26.3 Credential Protocols This section describes an extension of the CAFE payment system to credentials in two steps: 1. A variation based on a scheme of Chen Che94]. 2. Enhancement of the functionalities oered by the variation of Chen's scheme. In this chapter we use a similar type of gures as introduced in Part III to describe the protocols. We have however not introduced functional entities 276

26.3 Credential Protocols


for the credential scheme, so protocols will be executed between roles and not between functional entities as in Part III.

26.3.1 Required Keys

As usual p and q denote primes such that q divides p ; 1. The numbers g, h and G are all generators of the subgroup of ZZp of order q. Later two more generators are needed: h0 and h1 . The scheme assumes a registration centre, Z , for registration of pseudonyms. This registration centre has a secret key, x 2 ZZq , and a public key H = Gx . This key-pair is needed for validating pseudonyms. Furthermore, Z must publish gx and hx . Each organisation, Ok has a secret key, xk , and a corresponding public key, Hk = Gxk . This key-pair is used to sign credentials. Furthermore, it is assumed that each organisation, Ok , has published gxk and hxk . In Section 26.3.4 we also need the numbers hik = hxi k for i = 0 1. The authenticity of these keys will be assured through certicates issued by a key management centre.

26.3.2 Blind Signatures and Identication

The credential scheme uses the blind signature protocol shown in Figure 7.4 on page 46. Recall that on input a message m0 the receiver can get a signature on the message mt0 mod p for some t. Furthermore, in the protocols we shall often need that an individual having a public key (pseudonym), P , and a corresponding secret key (u s) such that P = (gu h)s must identify the individual. This is done using the protocol from Oka93] depicted in Figure 26.2. We refer to Oka93] for an analysis of this protocol. The security of the credential scheme depends on the following important property. Proposition 26.1 If an individual, I , is able to make an organisation accept in Figure 26.2, then I \knows" a pair (u s) such that P = (gu h)s . Individual

Organisation

(P = (gu h)s )

w1 w2 2R ZZq a0 gw1 hw2

r1 w1 + cus mod q r2 w2 + cs mod q

a0

; ;;;;;;;;;! ; ;

c

; ;;;;;;;;;; ;

r1 r2

; ;;;;;;;;;! ; ;

c 2R ZZq

gr1 hr2 =? a0 P c

Figure 26.2: Identi cation protocol.

277



Individual Ij

Registration centre

uj 2R ZZq Bj guj h Cj (gx )uj (hx) w 2R ZZq a gw

Bj a

; ;;;;;;;;;! ; ;

r w + cuj

Figure 26.3:

c

; ;;;;;;;;;; ;

r

; ;;;;;;;;;! ; ;

reg user:

Bj fresh ? c 2R ZZq gr =? a(Bj =h)c register Bj for this individual

Registration of a universal pseudonym.

26.3.3 Protocols The scheme to follow is inspired by that of Chen. The main dierence between our suggestion and Chen's scheme resides in the realisation of personal registration numbers (universal pseudonyms in our description). It seems that our suggestion leads to a more ecient protocol and that it facilitates enhanced functionality. From the description it should become clear that this variation can be seen as almost completely constructed from what can be called the CAFE security kernel, i.e., the building block consisting of the blind signature scheme and the mechanism to provide checks based on it. The functionality is exactly the same as in the scheme of Chen.

Getting a Pseudonym

At the registration centre, Z , each individual Ij chooses a universal identier uj at random. The corresponding universal pseudonym is

Bj guj h: After individual Ij has presented Bj to Z , it is checked that Bj is not listed already as a universal pseudonym. If it is fresh, Ij proves knowledge of logg (Bj =h) using the proof underlying Schnorr signatures. Next, Z registers Bj together with the necessary information about the real life identity of individual Ij . See Figure 26.3 for the details. Furthermore, for each organisation Ok , the individual chooses a random value sjk . The pseudonym with organisation Ok will eventually be

Pjk B sjk : 278



Individual Ij

Registration centre

sjk 2R ZsZq Pjk Bj jk Cjk ((gxk )uj hxk )ssjk z Cj jk u v 2R ZZq

a a0 Gv Hs u b b0 Bjv Cju jk c H(Pjk z a b) c0 c + u r r0 + v ? ab = (GPjk )r (Hz ) c

w 2R ZZq a0 b0

a0 Gw b0 Bjw

; ;;;;;;;;;; ;

c0

; ;;;;;;;;;! ; ;

r0

; ;;;;;;;;;; ;

r0 w + c0 x

;

Figure 26.4:

get pseudonym:

Obtaining a validated pseudonym Pjk .

Finally, Z gives a blind signature on Pjk . Here Ij needs Cj = Bjx, which is computed in reg user. The protocol is shown in Figure 26.4. Note that Z knows neither uj nor Pjk . This protocol results in Ij getting a signature (Pjk ) of the form (z c r) on the pseudonym Pjk .

Registration of a Pseudonym Individual Ij later registers with organisation Ok under pseudonym Pjk by simply submitting (Pjk (Pjk )) and proving knowledge of a representation of Pjk with respect to generators g and h using the method in Figure 26.2 (see Figure 26.5 for all details). This identication must repeated each time the individual contacts the organisation in order to prevent that other individuals gets or shows credentials under the pseudonym. This can be done using reg pseudonym, since this protocol only asks for a validator for new pseudonyms. The idea behind this registration procedure is that an individual, Ij , is uniquely identied by uj . By the property of the blind signature scheme (see Assumption 10.4, p. 131) Ij can only get validated pseudonyms of the form 0 t u t j (g h) G for some t t 2 ZZq . Here t = 0, since otherwise the identication in reg pseudonym will fail (by Proposition 26.1). 0

0

279



Individual Ij

Organisation Ok

Pjk

;;;;;;;;;;;;;; !

Request validator ;;;;;;;;;;;;;;; (Pjk

;;;;;;;;;;;;;; !

If Pjk is not registered then verify (Pjk ): Pjk 6= 1

a Gr H c b Pjkr z c c =? H(Pjk z a b) ;

;

Validator OK

;;;;;;;;;;;;;;

w1 w2 2R ZZq a0 gw1 hw2 r1 w1 + cuj sjk r2 w2 + csjk

Figure 26.5:

a0

;;;;;;;;;;;;;; !

c

;;;;;;;;;;;;;;

r1 r2

;;;;;;;;;;;;;; !

reg pseudonym:

endif c 2R ZZq

gr1 hr2 =? a0 Pjkc

Registration of Pjk at organisation Ok .

Issuing a Credential Ok issues a credential to individual Ij by executing the blind signature protocol with message M = Pjk . This results in a signature k of the form (z c r) on Sjk = Pjktjk where tjk is chosen by Ij . During this process Ij needs Cjk = Pjkxk (see Figure 26.6). This number is computed once Ij got her pseudonym with Ok in get pseudonym. The value Sjk together with the blind signature on it corresponds to what Chen calls an \intermediate pseudonym for individual Ij with organisation Ok ". Again the security of issuing depends on the properties of the blind signature protocol.

Showing a Credential Suppose our individual Ij wishes to demonstrate to organisation Ol that he has a credential, Sjk from organisation Ok . Ij is rst identied to Ol under 280



Individual Ij

Organisation Ok

tjk 2R ZZq Sjk Pjktjk z Cjktjk u v 2R ZZq

v u

a va0 Gu Htjkk

b b0 Sjk Cjk c H(Sjk z a b) c0 c + u r r0 + v ? ab = (GSjk )r (Hk z ) c

a0 b0

w 2R ZZq a0 Gw b0 Pjkw

; ;;;;;;;;;; ;

c0

; ;;;;;;;;;! ; ;

r0

; ;;;;;;;;;; ;

r0 w + c0 xk

;

Figure 26.6:

issue credential:

Issue credential Sjk for pseudonym Pjk .

pseudonym Pjl using reg user. The individual then proves knowledge of logPjl Sjk or in other words, that the individual can express the intermediary pseudonym with organisation Ok as a power of the pseudonym Pjl with organisation Ol . If Ok 's signature k on Sjk is accepted, the showing of a credential is completed (see Figure 26.7). Now, why is it dicult to show a credential issued under pseudonym Pjk of Ij under pseudonym Pil of another individual Ii . By the property of the identication in show credential it is guaranteed that the cheater can express Pil as gu hv for some0 u and v. By the property of issue credential, Sjk can be written as Pjkt Gt . Showing the credential under Pil requires knowledge of w such that Sjk = Pilw . In other words Sjk = (gu hv )w : Very briey this implies that Pjk must be of the form

Pjk = (gu hv )w=t since t 6= 0. This again implies Ii and Ij have the same universal identier, which contradicts the registration of universal pseudonyms.

Hardware Platform Observe that, depending on the hardware platform of the individual, the universal identier uj can be chosen by an observer or (in case of wallets with 281



Individual Ij

Organisation Ol

Sjk k (Sjk )

; ;;;;;;;;;! ; ;

verify k (Sjk ): Sjk 6= 1

a Gr H c b Sjkr z c c =? H(Sjk z a b) ;

;

w 2R ZZq a0 Pjlw r w + csjk tjk =sjl

Figure 26.7:

a0

; ;;;;;;;;;! ; ;

c

; ;;;;;;;;;; ;

r

; ;;;;;;;;;! ; ;

show credential:

c 2R ZZq Pjlr =? a0 Sjkc

Show credential Sjk for pseudonym Pjl .

observers) mutually at random by purse and observer. However, all blinding factors u, v, sjk and tjk can be chosen by the purse. This leads to various possibilities, including prior restraint with optimal privacy for the individual CP94].

26.3.4 Enhancement of Functionality Three ways to incorporate potentially desirable requirements for a credential mechanism that are presently not met by Chen's scheme will be described: 1. Fall-back integrity for credentials. 2. Ecient encoding of information in credentials (such as their type). 3. k-Showable credentials. Here, fall-back integrity means here that an individual who shows a credential more than once can be identied (one-show property). As for the second requirement, consider the case that one organisation issues multiple types of credentials. In Chen's scheme as it stands, the organisation would have to choose a dierent key-pair for each type of credential. We will describe a way to make this much more ecient. k-Showable credentials have the property that the identity of the individual becomes known to the organisations if the credential is shown more than k times. Like with k-spendable cheques, one can link the executions of the showing protocol, if the same k-showable credential is used. This could also be done by having an organisation issue k separate one-show credentials for the 282



Individual Ij

Organisation Ok

tjk 2R ZZq Sjk Pjktjk z Cjktjk u v w1 w2 2R ZZq a gw1 hw2

0

v u

a va0 Gu Htjkk

b b0 Sjk Cjk c H(Sjk z a b a ) c0 c + u

a0 b0

w 2R ZZq a0 Gw b0 Pjkw

; ;;;;;;;;;; ;

0

r r0 + v ? ab = (GSjk )r (Hk z ) c

c0

; ;;;;;;;;;! ; ;

r0

; ;;;;;;;;;; ;

r0 w + c0 xk

;

Figure 26.8: Issue one-showable credential Sjk for pseudonym Pjk .

same pseudonym. This is less ecient, however, with respect to time as well as storage. The extensions only aect the issue credential and show credential, whereas the registration remains unchanged.

Fall-back Integrity for Credentials Recall, that whenever an individual shows a credential to an organisation he must rst be identied. Briey, fall-back integrity of a credential S under pseudonym P is obtained by forcing the individual to use the same message a0 (see Figure 26.2 and 26.5) whenever the individual is identied before showing S . By the properties of the identication method the secret key, (u s), such that P = (gu h)s can be obtained if the individual executes this identication protocol twice. In order to enforce this rst message, the individual is required to incorporate it in the blind signature just as 21 and 22 were incorporated in cheques (more specically, the rst message will be a parameter to the hash function). Note that if the rst message of the proof is not in the blind signature as described above, the credential will simply not be accepted. The protocol for issuing such credentials is shown in Figure 26.8 (note that the rst rst message for the identication is now denoted by a ). Showing the credential is much as in Figure 26.7 and is presented in Figure 26.9. The only dierence, is that the identication which was not included in Figure 26.7 (since it only had to be done once in each session) must now be done in each showing, and it is therefore described explicitly in Figure 26.9. 0

283



Individual Ij

w 2R ZZq a0 Pjlw

Organisation Ol

a0 a Sjk k (Sjk ) 0

;;;;;;;;;;;;;; ! ;


a Gr H c b Sjkr z c c =? H(Sjk z a b a ) ;

;

0

c d

r w + csjk tjk =sjl r1 w1 + duj sjl r2 w2 + dsjl

c d 2R ZZq

;;;;;;;;;;;;;;

r r1 r2

;;;;;;;;;;;;;; !

Pjlr =? a0 Sjkc gr1 hr2 =? a Pjld 0

Figure 26.9: Showing a one-showable credential Sjk for pseudonym Pjl .

Now, if the individual abuses the credential and shows it twice, the credential clearing receiving copies of all shown credentials will detect this and be able to compute the universal identier ui . The credential clearing is assumed to keep a database storing (d r1 r2 ) for all received credentials. The protocol for this is shown in Figure 26.10.

E cient Encoding of Type of Credential At the expense of two extra generators h0 and h1 (which are system constants), there is an extension that allows for an organisation Ok to append a short message to a blind signature. Let A ZZq be the set of messages that can be encoded in credentials. In principle, A can contain up to q dierent messages, but for privacy reasons A will often be relatively small (otherwise credentials can be uniquely identied by their encoded message). The idea is now to encode the type of credential as an element of A. So, if Ok issues 2l types of credentials, A could consist of all strings of length l. In the original protocol for getting a credential Ok signs M = Pjk . This is now replaced by M = Pjk h , where h = h0 h1 and 2 A is the message that Ok wishes to append. The individual Ij gets a blind signature on

Sjk (Pjk h )sjk where sjk is chosen by Ij . 284



Organisation Ol

Credential clearing

(Pjl a Sjk k (Sjk )) 0

;;;;;;;;;;;;;;;; ! ;

a0 c d r r1 r2

;;;;;;;;;;;;;;;;! ;


a Gr H c b Sjkr z c c =? H(Sjk z a b a ) ;

;

0

Sjk used before? If no: store Sjk and stop Otherwise, retrieve d r1 r2 0

0

0

for the previous showing. If r2 = r2 stop. 0 Otherwise u rr21 rr210 Output u 0

; ;

Figure 26.10: Clearing a credential.

The resulting protocol is depicted in Figure 26.11. Note that Ij automatically veries whether the correct information is encoded in the credential. Showing a credential to organisation Ol consists of giving Ok 's blind signature on Sjk and demonstrating knowledge of a representation of Sjk with respect to Pjl and h , where h = h0 h1 (see Figure 26.12). Intuitively, changing the encoded information requires the ability to write Sjk both as a power of Pjk h and a power of Pjk h0 for a new value . Very briey, this requires the ability to compute discrete logarithms contradicting SDLA. 0

k-Showable Credentials A k-showable credential has the property that it can be shown at most k times.

If this is violated, the identity of the individual becomes available. Just as for two-spendable cheques the idea is to incorporate into the signature k rst messages for the identication protocol. Obviously, due to the fact that we are dealing with a blind signature in the protocol for getting a credential, the issuing organisation has no control over the data that goes in the hash function. This would mean that an individual can make the credential k -showable for any k . This is prevented by once more invoking the issuer's ability to append a short message to the blind signature (see Section 26.3.4): the message that is appended will now encode the value of k (if needed, can also encode additional information). The protocol for getting a credential is essentially a combination between the protocols resulting from the previous two enhancements: the issuing organ0

0

285



Individual Ij

Organisation Ok

h h0 h1 m Pjk h Cjk Cjk h0k h1k tjk 2R ZZq Sjk mtjk tjk z Cjk u v 2R ZZq

h h0 h1 m Pjk h

a0 Gv Hku a u tjk b b0 Sjkv Cjk c H(Sjk z a b) c0 c + u r r0 + v ? ab = (GSjk )r (Hk z) c

a0 b0

w 2R ZZq a0 Gw b0 mw

; ;;;;;;;;;; ;

c0

; ;;;;;;;;;! ; ;

r0

; ;;;;;;;;;; ;

r0 w + c0 xk

;

Figure 26.11: Issue credential Sjk encoding 2 A for pseudonym Pjk .

isation appends the short message encoding k, and the individual prepares k rst messages for the proof that she knows a representation for Sjk with respect to g, h and h , and incorporates them in the argument of the hash-function in the blind signature protocol. The resulting protocol for issuing a credential is shown in Figure 26.13. The organisation that veries a credential now has to count the number of messages rst that went into the argument of the hash-function. The remaining steps are just combining the protocols resulting from previous two enhancements. See Figure 26.14 for the details regarding showing such a credential. Clearing in this scenario is just as in Section 26.3.4 with the following exception. The credential clearing must store the messages a used in the proofs. Whenever, the same a has been used in two dierent proofs the individual can be identied. 0

0

26.4 Applications of Credentials Credentials as described above have many possible applications. During CAFE the following have been investigated, which, except for the last, all require demonstration of possession of a certain right. E.g., the right to travel a certain distance at a given time the right to exchange or claim warranty for a purchased item the right to obtain the gift in an incentive scheme, and so on. 286

26.4 Applications of Credentials


Individual Ij

h h0 h1

Organisation Ol

Sjk k (Sjk )

; ;;;;;;;;;! ; ;

h h0 h1 verify k (Sjk ): Sjk 6= 1

a Gr H c b Sjkr z c c =? H(Sjk z a b) ;

;

w0 w1 2R ZZq a0 Pjlw0 hw 1 r w0 + csjk tjk =sjl rh w1 + ctjk

a0

; ;;;;;;;;;! ; ;

c

; ;;;;;;;;;; ;

r rh

; ;;;;;;;;;! ; ;

c 2R ZZq

Pjlr hrh =? a0 Sjkc

Figure 26.12: Show credential Sjk encoding 2 A for pseudonym Pjl .

Public Transport Tickets are used to prove that the individual has obtained

the right to use a particular service. Special forms are ticket books and \season tickets". Purchase Receipts are proofs of purchase, possibly with monetary value. Incentive Schemes (also known as as loyalty schemes, bonus programs, discount privileges) work by granting the individual bonus points for some types of transactions. These points can later be exchanged for, for example, a gift, the right to accept special oers or taris, and so on. Physical Access Control works by verifying the right to access a certain space (anonymous or non-anonymous) before granting it. Conditional Pricing is the use of a dierent, usually lower, tari based on group membership. That is, an individual must prove this membership, preferably without revealing his identity. A related application is toll payment: here the individual receives a ticket when entering a service (e.g., parking lot, toll road) and pays on exit, depending on the services used since entry (e.g., parking time, distance travelled). This is a special case of conditional pricing, as the amount due depends on the ticket and the context (place, time) of payment. Medical Prescriptions are in some countries a proof of the right to obtain a certain medicine. It is issued by the physician, and accepted by a pharmacist. 287



Individual Ij

Organisation Ok

encode(k) h h0h1 m Pjk h Cjk Cjk h0k h1k tjk 2R ZZq Sjk mtjk tjk z Cjk u v 2R ZZq wi1 wi2 2R ZZq for i = 1 : : : k ai gwi1 hwi2 for i = 1 : : : k ci H(ai ) for i = 1 : : : k

encode(k) h h0 h1 m Pjk h

v u

a va0 Gu Htjkk

b b0 Sjk Cjk c H(Sjk z a b (ci )i=1:::k ) c0 c + u r r0 + v ? ab = (GSjk )r (Hk z) c

w 2R ZZq a0 Gw b0 mw a0 b0

; ;;;;;;;;;; ;

c0

; ;;;;;;;;;! ; ;

r0

; ;;;;;;;;;; ;

r0 w + c0 xk

;

Figure 26.13: Issue k-showable credential Sjk for pseudonym Pjk .

Prepaid Mobile Communications: This is a special kind of the \phone

tick" payment already implemented. It poses special requirements on timing and communications complexity. These are the rst, preliminary results of cooperation with the race project monet, which investigates the next generation of mobile communications systems. Some of theses rights are once-usable. For example, a train ticket should be used for one trip only. Some are twice-usable. For example, a metro ticket is used at entrance and at exit. Others are \innitely-usable": for example, access control. Although more ecient implementations are possible, our investigations show that the suggested credential scheme can be used to obtain these applications. Thus, although payments have had very high priority in the development of the protocols, the resulting security kernel have many other possible applications. This needs, however, further investigation.

288

26.4 Applications of Credentials


Individual Ij

encode(k) h h0 h1 w 2R ZZq a0 Pjlw

Organisation Ol

encode(k) h h0 h1 a0 an (ci )i=n Sjk k (Sjk ) 6

; ;;;;;;;;;; ! ; ; ;;;;;;;;;; ! ;

cn H(an) Received k values of ci ? verify k (Sjk ): Sjk 6= 1 a Gr H c b Sjkr z c c =? H(Sjk z a b (ci )i ) c d 2R ZZq ;

;

c d

r w + csjk tjk =sjl r1 wn1 + duj sjl r2 wn2 + dsjl

; ;;;;;;;;;; ;

r r1 r2

; ;;;;;;;;;; ! ;

Pjlr =? a0 Sjkc gr1 hr2 =? a Pjld 0

Figure 26.14: Showing a k-showable credential Sjk for the n'th time.

289


290



Bibliography ACGS88] W. Alexi, B. Chor, O. Goldreich, and C. P. Schnorr. RSA and Rabin bits: Some parts are as hard as the whole. SIAM Journal on Computing, 17(2):194{209, 1988. Ant90] H. van Antwerpen. O-line electronic cash. Master's thesis, Eindhoven University of Technology, Department of Mathematics and Computing Science, Eindhoven, The Netherlands, 1990. BB91] B. den Boer and A. Bosselaers. An attack on the last two rounds of MD4. In Advances in Cryptology|CRYPTO '91, volume 576 of Lecture Notes in Computer Science, pages 194{203, Berlin, 1991. Springer-Verlag. BB93] B. den Boer and A. Bosselaers. Collisions for the compression function of MD5. In Advances in Cryptology|EUROCRYPT '93, volume 765 of Lecture Notes in Computer Science, pages 293{304, Berlin, 1993. Springer-Verlag. BBB+ 95] A. Berendschot, B. den Boer, J.-P. Boly, A. Bosselaers, J. Brandt, D. Chaum, I. Damg)ard, M. Dichtl, W. Fumy, M. van der Ham, C.J.A. Jansen, P. Landrock, B. Preneel, G. Roelofsen, P. de Rooij, and J. Vandewalle. Integrity Primitives for Secure Information Systems. Final Report of RACE Integrity Primitives Evaluation (RIPERACE 1040), volume 1007 of Lecture Notes in Computer Science. Springer-Verlag, Berlin, 1995. BC90] J. Bos and D. Chaum. SmartCash: A practical electronic payment system. Report CS-R9035, Centrum voor Wiskunde en Informatica, Amsterdam, August 1990. BM92] E. F. Brickell and K. S. McCurley. An interactive identication scheme based on discrete logarithms and factoring. Journal of Cryptology, 5(1):29{39, 1992. Boe90] B. den Boer. Die-Hellman is as Strong as Discrete Log for Certain Primes. In Advances in Cryptology|CRYPTO '88, volume 403 of Lecture Notes in Computer Science, pages 530{539, Berlin, 1990. Springer-Verlag. Boe92] B. den Boer. Personal communication, March 1992. 291

Bibliography


BP89]

H. B*urk and A. Ptzmann. Digital payment systems enabling security and unobservability. Computers & Security, 8(5):399{416, 1989. S. Brands. An ecient o-line electronic cash system based on the representation problem. Report CS-R9323, Centrum voor Wiskunde en Informatica, Amsterdam, March 1993. S. Brands. Untraceable o-line cash in wallet with observers. In Advances in Cryptology|CRYPTO '93, volume 773 of Lecture Notes in Computer Science, pages 302{318, Berlin, 1994. Springer-Verlag. S. Brands. O-line cash transfer by smart cards. In V. Cordonnier and J.-J. Quisquater, editors, Proceedings First Smart Card Research and Advanced Application Conference, pages 101{117, Lille (F), 1994. Also as report CS-R9455, Centrum voor Wiskunde en Informatica, Amsterdam. S. Brands. Restrictive blinding of secret-key certicates. In Advances in Cryptology|EUROCRYPT '95, volume 921 of Lecture Notes in Computer Science, pages 231{247, Berlin, 1995. SpringerVerlag. Final version as report CS-R9509, Centrum voor Wiskunde en Informatica, Amsterdam. S. Brands. A note on parallel executions of restrictive blind issuing protocols for secret-key certicates. Report CS-R9519, Centrum voor Wiskunde en Informatica, Amsterdam, March 1995. S. Brands. Restrictive blind issuing of secret-key certicates in parallel mode. Report CS-R9523, Centrum voor Wiskunde en Informatica, Amsterdam, March 1995. S. Brands. More on restrictive blind issuing of secret-key certicates in parallel mode. Report CS-R9534, Centrum voor Wiskunde en Informatica, Amsterdam, April 1995. D. Chaum, B. den Boer, E. van Heyst, S. Mjlsnes, and A. Steenbeek. Ecient oine electronic checks. In Advances in Cryptology| EUROCRYPT '89, volume 434 of Lecture Notes in Computer Science, pages 294{301, Berlin, 1990. Springer-Verlag. The CAFE Consortium. CAFE nal report volume I: Trial operation and surveys. Report CS, Centrum voor Wiskunde en Informatica, Amsterdam, 1997. The CAFE Consortium. CAFE nal report volume IIB: Technical specications, devices. Report CS, Centrum voor Wiskunde en Informatica, Amsterdam, 1997. D. Chaum and J.-H. Evertse. A secure and privacy-protecting protocol for transmitting personal information between organizations.

Bra93] Bra94a] Bra94b]

Bra95a]

Bra95b] Bra95c] Bra95d] CBH+ 90]

CC97a] CC97b] CE87]

292


Bibliography

In Advances in Cryptology|CRYPTO '86, volume 263 of Lecture Notes in Computer Science, pages 118{167, Berlin, 1987. SpringerVerlag. CFN90] D. Chaum, A. Fiat, and M. Naor. Untraceable electronic cash. In Advances in Cryptology|CRYPTO '88, volume 403 of Lecture Notes in Computer Science, pages 319{327, Berlin, 1990. Springer-Verlag. Cha83] D. Chaum. Blind signatures for untraceable payments. In Advances in Cryptology|CRYPTO '82, pages 199{203, New York, 1983. Plenum Press. Cha85] D. Chaum. Security without identication: Transaction systems to make big brother obsolete. Communications of the ACM, 28(10):1030{1044, 1985. Cha89] D. Chaum. Privacy protected payments: Unconditional payer and/or payee untraceability. In SMART CARD 2000: The Future of IC Cards, Proceedings of the IFIP WG 11.6 International Conference, pages 69{93, Amsterdam, 1989. North-Holland. Cha90] D. Chaum. Showing credentials without identication: Transferring signatures between unconditionally unlinkable pseudonyms. In Advances in Cryptology|AUSCRYPT '90, volume 453 of Lecture Notes in Computer Science, pages 246{264, Berlin, 1990. SpringerVerlag. Cha92] D. Chaum. Achieving electronic privacy. Scientic American, 267:96{101, August 1992. Che94] L. Chen. Witness Hiding Proofs and Applications. PhD thesis, Aarhus University, Computer Science Department, Aarhus, Denmark, August 1994. CP93a] D. Chaum and T. P. Pedersen. Transferred cash grows in size. In Advances in Cryptology|EUROCRYPT '92, volume 658 of Lecture Notes in Computer Science, pages 390{407, Berlin, 1993. SpringerVerlag. CP93b] D. Chaum and T. P. Pedersen. Wallet databases with observers. In Advances in Cryptology|CRYPTO '92, volume 740 of Lecture Notes in Computer Science, pages 89{105, Berlin, 1993. Springer-Verlag. CP94] R. Cramer and T. P. Pedersen. Improved privacy in wallets with observers. In Advances in Cryptology|EUROCRYPT '93, volume 765 of Lecture Notes in Computer Science, pages 329{343, Berlin, 1994. Springer-Verlag. Dam90] I. B. Damg)ard. A design principle for hash functions. In Advances in Cryptology|CRYPTO '89, volume 435 of Lecture Notes in Computer Science, pages 416{427, Berlin, 1990. Springer-Verlag. 293

Bibliography


DBP96] H. Dobbertin, A. Bosselaers, and B. Preneel. RIPEMD-160: A strengthened version of RIPEMD. In Fast Software Encryption, volume 1039 of Lecture Notes in Computer Science, pages 71{82, Berlin, 1996. Springer-Verlag. Final version available at

ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.

Det94] DGB88]

DH76] Dob97] DSS94] Fei73] Fer94a] Fer94b] FS87]

FY92] GMR88] GMR89]

294

J*urgen Dethlo. 25 Jahre Chipkarten-Technik | R*uckblick und Ausblick. In B. Struif, editor, Tagungsband zum 4. GMD-SmartCard Workshop, 8.-9. Februar 1994, Darmstadt, 1994. GMD. Y. Desmedt, C. Goutier, and S. Bengio. Special uses and abuses of the at-shamir passport protocol. In Advances in Cryptology| CRYPTO '87, volume 293 of Lecture Notes in Computer Science, pages 21{39, Berlin, 1988. Springer-Verlag. W. Die and M. E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 22(6):644{654, 1976. H. Dobbertin. RIPEMD with two-round compress function is not collision-free. Journal of Cryptology, 10(1):51{69, 1997. Digital Signature Standard. Federal Information Processing Standards Publication 186, US Department of Commerce/National Institute for Standards and Technology (NIST), May 19, 1994. H. Feistel. Cryptography and computer privacy. Scientic American, 228:15{23, May 1973. N. T. Ferguson. Single term o-line coins. In Advances in Cryptology|EUROCRYPT '93, volume 765 of Lecture Notes in Computer Science, pages 318{328, Berlin, 1994. Springer-Verlag. N. T. Ferguson. Extensions of single-term coins. In Advances in Cryptology|CRYPTO '93, volume 773 of Lecture Notes in Computer Science, pages 292{301, Berlin, 1994. Springer-Verlag. A. Fiat and A. Shamir. How to prove yourself: Practical solutions to identication and signature problems. In Advances in Cryptology| CRYPTO '86, volume 263 of Lecture Notes in Computer Science, pages 186{194, New York, 1987. Springer-Verlag. M. Franklin and M. Yung. Towards provably secure ecient electronic cash. Technical report CUCS-018-92, Columbia University, Dept. of Computer Science, April 1992. S. Goldwasser, S. Micali, and R. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing, 17(2):281{308, 1988. S. Goldwasser, S. Micali, and C. Racko. The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18:186{ 208, 1989.


Bibliography

GUQ92] L. C. Guillou, M. Ugon, and J.-J. Quisquater. The Smart Card: A standardized security device dedicated to public cryptology. In G. J. Simmons, editor, Contemporary Cryptology: The Science of Information Integrity, pages 561{613, New York, 1992. IEEE Press. Hey92] E. van Heyst. Special Signature Schemes. PhD thesis, Eindhoven University of Technology, Department of Mathematics and Computing Science, Eindhoven, The Netherlands, July 1992. HP93] E. van Heyst and T. P. Pedersen. How to make ecient fail-stop signatures. In Advances in Cryptology|EUROCRYPT '92, volume 658 of Lecture Notes in Computer Science, pages 366{378. SpringerVerlag, 1993. ISO89] The Directory { Authentication Framework, C.C.I.T.T. Recommendation X.509, 1988. ISO/IEC Standard 9594-8, International Standards Organization, Geneva, 1989. ISO94] Information technology { Security techniques { Key management Part 3: Mechanisms Using Asymmetric Techniques. ISO/IEC 117703, International Standards Organization, Geneva, 1994. This standard is still under study. ISO96] Information technology { Security techniques { Key management Part 1: Framework. ISO/IEC 11770-1, rst edition, International Standards Organization, Geneva, 1996. KD79] J.B. Kam and G.I. Davida. Structured design of substitutionpermutation encryption networks. IEEE Transactions on Computers, C{28(10):747{753, 1979. Knu81] D. E. Knuth. The Art of Computer Programming (Vol. 2: Seminumerical Algorithms). Addison Wesley, Reading (MA), 2nd edition, 1981. Kob87] N. Koblitz. A Course in Number Theory and Cryptography, volume 114 of Graduate Texts in Mathematics. Springer-Verlag, New-York, 1987. LO91] B. A. LaMachhia and A. M. Odlyzko. Computation of discrete logarithms in prime elds. Design, Codes and Cryptography, 1(1):47{62, 1991. Mau94] U. Maurer. Towards the Equivalence of Breaking the Die-Hellman Protocol and Computing Discrete Logarithms. In Advances in Cryptology|CRYPTO '94, volume 839 of Lecture Notes in Computer Science, pages 271{281. Springer-Verlag, 1994. McC90] K. McCurley. The discrete logarithm problem. In C. Pomerance, editor, Cryptology and Computational Number Theory, volume 42 of Proceedings of Symposia in Applied Mathematics, pages 49{74, Providence, 1990. American Mathematical Society. 295

Bibliography


Mer90] MS91]

R. C. Merkle. Unpublished result, 1990. See BB91]. S. Micali and C. Schnorr. Ecient perfect polynomial random number generators. Journal of Cryptology, 3(3):157{172, 1991. T. Okamoto. Provably secure and practical identication schemes and corresponding signature schemes. In Advances in Cryptology| CRYPTO '92, volume 740 of Lecture Notes in Computer Science, pages 31{53, Berlin, 1993. Springer-Verlag. T. Okamoto and K. Ohta. Disposable zero-knowledege authentications and their applications to untraceable electronic cash. In Advances in Cryptology|CRYPTO '89, volume 435 of Lecture Notes in Computer Science, pages 481{496, Heidelberg, 1990. SpringerVerlag. T. Okamoto and K. Ohta. Universal electronic cash. In Advances in Cryptology|CRYPTO '91, volume 576 of Lecture Notes in Computer Science, pages 324{337, Berlin, 1992. Springer-Verlag. J. C. Pailles. New protocols for electronic money. In Advances in Cryptology|AUSCRYPT '92, volume 718 of Lecture Notes in Computer Science, pages 263{274, Berlin, 1993. Springer-Verlag. T. P. Pedersen. Electronic payments of small amounts. Technical Report DAIMI PB-495, Aarhus University, Computer Science Department, Aarhus, Denmark, August 1995. T. P. Pedersen. Electronic payments of small amounts. In Security Protocols, volume 1189 of Lecture Notes in Computer Science, pages 59{68, Berlin, 1997. Springer-Verlag. B. Ptzmann, M. Waidner, and A. Ptzmann. Rechtssicherheit trotz Anonymit*at in oenen digitalen Systemen. Datenschutz und Datensicherung DuD, 14(5{6):243{253, 305{315, 1990. M. Rabin. Digital signatures and public key functions as intractable as factoring. Technical Memo TM-212, Laboratory of Computer Science, Massachusetss Institute of Technology, 1979. R. L. Rivest. The MD4 message-digest algorithm. Request for Comments (RFC) 1320, April 1992. R. L. Rivest. The MD5 message-digest algorithm. Request for Comments (RFC) 1321, April 1992. Peter de Rooij. The discrete logarithm problem modulo a prime number. RIPE document Eval-P8.2, PTT Research, July 4, 1991. R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120{126, 1978. Reprinted in 1983 in 26(1):96{99.

Oka93]

OO90]

OO92] Pai93] Ped95] Ped97] PWP90] Rab79] Riv92a] Riv92b] Roo91] RSA78]

296


Sch91] Sch95] SHS95] Sto88]

WT86]

Bibliography

C. P. Schnorr. Ecient signature generation by smart cards. Journal of Cryptology, 4(3):161{174, 1991. B. Schoenmakers. An ecient electronic payment system withstanding parallel attacks. Report CS-R9522, Centrum voor Wiskunde en Informatica, Amsterdam, March 1995. Secure Hash Standard. Federal Information Processing Standards Publication 180-1, US Department of Commerce/National Institute for Standards and Technology (NIST), April 17, 1995. N. Stol. Privacy protected payments: A possible structure for a real implementation and some resource considerations. Technical report STF44 A88024, SINTEF DELAB, N-7034 Trondheim, February 1988. Also published in Securicom'88. A.F. Webster and S.E. Tavares. On the design of S-boxes. In Advances in Cryptology|CRYPTO '85, volume 218 of Lecture Notes in Computer Science, pages 523{534, Berlin, 1986. Springer-Verlag.

297

CAFE project Final report volume II: Secure Protocols and Architecture

CAFE project Final report volume II: Secure Protocols and Architecture

Suggest Documents

Final Report Volume II Vehicle Detector Signal

Safer Internet Project SIC LT II Final Public Report (final)

Final technical report and architecture

project final report - MIROR Project

ucmexus final project report ucmexus final project report - University of ...

Summary Report on Secure Computation Protocols - ecrypt

Summary Report on Secure Computation Protocols - ecrypt

Final Project Report

Masters Project Final Report

Final GIS Project Report

PROJECT FINAL REPORT

Final Report - FAROS Project

Final project report

Final Project Report

Final Project Report

project final report - TECA

Final Project Report

Project Final Report

Final Project Report

project final report - CORDIS

Final Project Report

Final Project Report

project final report - bambi

FINAL PROJECT REPORT