Modelling, Analysis and Simulation - TU/eberry/papers/MAS-E0303.pdf · Centrum voor Wiskunde en...

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

MASModelling, Analysis and Simulation

Modelling, Analysis and Simulation

CAFE project _ Final report volume IISecure 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 InformaticaP.O. Box 94079, 1090 GB Amsterdam (NL)Kruislaan 413, 1098 SJ Amsterdam (NL)Telephone +31 20 592 9333Telefax +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 Speci�cations

ESPRIT �� CAFE

Document PTS��

April� ��

CAFE Final Report Volume II

ii


Contents

List of Figures ix

List of Tables xiii

Preface xv

I Overview �

� Objectives �

� The System �

�� System Model � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Roles � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Transactions � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� The Electronic Wallet � � � � � � � � � � � � � � � � � � � � � � � � �

�� Key Management � � � � � � � � � � � � � � � � � � � � � � � � � � �

� Features �

�� Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Functionality � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Security � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

II Architecture ��

� System Architecture ��

�� Requirements � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Framework � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Roles � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Transactions � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� Security Architecture ��

�� Security Approaches � � � � � � � � � � � � � � � � � � � � � � � � ��

�� The Electronic Wallet � � � � � � � � � � � � � � � � � � � � � � � � �

�� Key Management � � � � � � � � � � � � � � � � � � � � � � � � � � ��

iii

Contents CAFE Final Report Volume II

III Protocols ��

� Notation and Denitions ��

�� Assignment De�nitions � � � � � � � � � � � � � � � � � � � � � � � ��

�� Representation of Numbers � � � � � � � � � � � � � � � � � � � � � ��

�� De�nitions and Basic Operations � � � � � � � � � � � � � � � � � ��

�� Symbols � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Stable Storage and Atomic Actions � � � � � � � � � � � � � � � � ��

� The Basic Cryptographic Primitives ��

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

The � Protocols ��

�� Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� reset � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� get info � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� authenticate � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� write cu tbl � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� gen cheque � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� load cheque � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� show currencies � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� payment � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� transfer � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� unlock amt � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� update � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� get certif � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� rec payments � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� recovery � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� deposit � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� The � Protocols ��

�� Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� reset � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� get info � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� authenticate � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� write cu tbl � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� gen cheque � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� show currencies � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� payment � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

iv

CAFE Final Report Volume II Contents

� transfer � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� unlock amt � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� update � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� get certif � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� rec payments � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� recovery � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� deposit � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

A List of Identiers in the � Protocols ��

B List of Identiers in the � Protocols ��

IV Security Evaluation ��

�� Security Evaluation of Basic Primitives ��

� �� Discrete Logarithms � � � � � � � � � � � � � � � � � � � � � � � � � ��

� �� Primitives Using the Factoring Assumption � � � � � � � � � � � � ��

� �� Security of the Hash Function � � � � � � � � � � � � � � � � � � � ��

�� Security Requirements ��

�� Assumptions � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Bank�s Requirements � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Payer�s Requirements � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Payee�s Requirements � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Security in the � Protocols ��

�� Bank�s Requirements � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Payer�s Requirements � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Payee�s Requirements � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Integrity in the � Protocols ��

�� Bank�s Integrity � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Payer�s Integrity � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Resilience Against Interruptions � � � � � � � � � � � � � � � � � � ��

�� Independence of � Protocols � � � � � � � � � � � � � � � � � � � � ��

V Clearing ��

�� Introduction ��

�� Overview � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� De�nitions � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Requirements � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Clearing Architecture � � � � � � � � � � � � � � � � � � � � � � � � ��

v


�� Functional Description ��

�� Database Tables � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Some Clearing Issues � � � � � � � � � � � � � � � � � � � � � � � � �

�� Clearing System Procedures � � � � � � � � � � � � � � � � � � � � ��

�� Properties of the Clearing System ��

�� Risk Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Fault Tolerance � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Capacity � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Truncation and Accumulation of Cheques � � � � � � � � � � � � � ��

�� Distributed Clearing ��

�� Overview of the Model � � � � � � � � � � � � � � � � � � � � � � � ��

�� Functional Description � � � � � � � � � � � � � � � � � � � � � � � ��

�� Properties of the Generalized Clearing Architecture � � � � � � � ��

VI Key Management ��

� Introduction ��

�� Overview � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Entities and Functionality � � � � � � � � � � � � � � � � � � � � � �

�� Certi�cation Hierarchy � � � � � � � � � � � � � � � � � � � � � � � � �

�� Certi�cate Classes � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Parameter Classes ��

�� Notation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Central Certi�cation � � � � � � � � � � � � � � � � � � � � � � � � �

�� Realm Certi�cation � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Clearing System Signature � � � � � � � � � � � � � � � � � � � � � ��

�� Acquirer Signature � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Systemwide Crypto Parameters � � � � � � � � � � � � � � � � � � ��

�� Issuer Authentication � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Issuer Cheque Signature � � � � � � � � � � � � � � � � � � � � � � ��

�� Observer Signature � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Shared Parameter � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Observer PRSG Parameters � � � � � � � � � � � � � � � � � � � � ��

�� Purse Blinding � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� A�liated � Observer Signature � � � � � � � � � � � � � � � � � � ��

�� Non�cryptographic Parameters � � � � � � � � � � � � � � � � � � � ��

�� Activation of Entities ��

� �� Wallet Activation � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� �� Activation of A�liation � � � � � � � � � � � � � � � � � � � � � � � ��

�� Version management ��

�� Overlapping Validity Periods � � � � � � � � � � � � � � � � � � � � ��

�� Validity Dependencies � � � � � � � � � � � � � � � � � � � � � � � � ��

vi

CAFE Final Report Volume II Contents

�� Security Properties �� Types of Attack � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Forged Certi�cates � � � � � � � � � � � � � � � � � � � � � � � � � �� Key Compromisation � � � � � � � � � � � � � � � � � � � � � � � � �� Acquirer Signature � � � � � � � � � � � � � � � � � � � � � � � � � �� Clearing Signature � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Key Management for the � System �� Entities � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Certi�cate Classes � � � � � � � � � � � � � � � � � � � � � � � � � � �� Central Certi�cation � � � � � � � � � � � � � � � � � � � � � � � � �� Realm Certi�cation � � � � � � � � � � � � � � � � � � � � � � � � � �� Systemwide Crypto Parameters � � � � � � � � � � � � � � � � � � �� Issuer Authentication � � � � � � � � � � � � � � � � � � � � � � � � �� Issuer Cheque Signature � � � � � � � � � � � � � � � � � � � � � � �� Wallet Signature � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Shared Parameter � � � � � � � � � � � � � � � � � � � � � � � � � � �� Wallet PRSG Parameters � � � � � � � � � � � � � � � � � � � � � � �� Non�Cryptographic Parameters � � � � � � � � � � � � � � � � � � ��

VII Extensions ��

�� E�ciency Improvements �� An Alternative Blind Signature Scheme � � � � � � � � � � � � � � �� k�Spendability Extension � � � � � � � � � � � � � � � � � � � � � � �� Exploiting Pre� and Post�processing � � � � � � � � � � � � � � � � ��

�� Multi Currency Payments �� Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Multiple Issuers � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Multiple Currencies � � � � � � � � � � � � � � � � � � � � � � � � � �� General Requirements � � � � � � � � � � � � � � � � � � � � � � � � �� Protocols and Procedures � � � � � � � � � � � � � � � � � � � � � � ��

�� Credential Schemes �� Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Credential Mechanisms � � � � � � � � � � � � � � � � � � � � � � � �� Credential Protocols � � � � � � � � � � � � � � � � � � � � � � � � �� Applications of Credentials � � � � � � � � � � � � � � � � � � � � � ��

Bibliography ��

vii


viii


List of Figures

�� Overview of the payment system roles and transactions� � � � � �� The electronic wallet � � � � � � � � � � � � � � � � � � � � � � � � �

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

�� Schnorr�s identi�cation 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 � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� reset � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� get info � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� authenticate � � � � � � � � � � � � � � � � � � � � � � � � � � � �� write cu tbl � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� gen cheque � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� load cheque � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� show currencies � � � � � � � � � � � � � � � � � � � � � � � � � �� payment of a cheque � � � � � � � � � � � � � � � � � � � � � � � �� payment of phone ticks � � � � � � � � � � � � � � � � � � � � � � ��

�� to � transfer �part �� to � transfer �part ��

�� to � rollback � � � � � � � � � � � � � � � � � � � � � � � � � � � �� unlock amt � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� updateP a � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� updateP c � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

ix

List of Figures CAFE Final Report Volume II

�� get certif � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� rec payments � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� recovery init � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� recovery � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� deposit � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� reset � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� get info � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� authenticate �part ��

�� authenticate �part ��

�� write cu tbl � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� gen cheque � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� show currencies � � � � � � � � � � � � � � � � � � � � � � � � � � �

� ��payment �part ��

� ��payment �part ��

�� payment �phone ticks� � � � � � � � � � � � � � � � � � � � � � � � �

�� unlock amt � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� updateP a � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� updateP c � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� get certif � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� rec payments � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� recovery �part ��

�� recovery �part ��

�� deposit � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Payment system with clearing � � � � � � � � � � � � � � � � � � � ��

�� Model for recovery of value in a lost wallet� � � � � � � � � � � � � ��

�� The structure of the centralized clearing architecture� � � � � � � ��

�� A general node in the clearing hierarchy� � � � � � � � � � � � � � ��

�� Structure of the key management certi�cation hierarchy� � � � � � �

�� Location of parameter classes in the key certi�cate hierarchy� � � � �

�� Example of a one�to�many distribution� � � � � � � � � � � � � � � �

�� Distribution of the central certi�cate veri�cation key� � � � � � � ��

�� Distribution of the realm certi�cate veri�cation key� � � � � � � � ��

�� Distribution of the clearing system veri�cation key� � � � � � � � ��

�� Distribution of the acquirer veri�cation key� � � � � � � � � � � � ��

�� Distribution of the systemwide crypto parameters� � � � � � � � � ��

�� Distribution of the issuer authentication key� � � � � � � � � � � � ��

�� Distribution of the issuer cheque veri�cation key� � � � � � � � � ��

�� Distribution of the observer veri�cation 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 a�liated observer veri�cation key� � � � � � � ��

x

CAFE Final Report Volume II List of Figures

�� Distribution of the max pay and max ticks parameters� � � � � � �� Distribution of the max trans parameter� � � � � � � � � � � � � � ��

�� Illustration of overlapping key validity periods� � � � � � � � � � � �� Dependencies between key validity periods� � � � � � � � � � � � � ��

�� Issuing a Schnorr signature �c� r� on a blind message m� � � � � � �� Protocol to get a blind signature �g�� c�� r�� on a blind message m�� Committing to �� k� � � � � � � � � � � � � � � � � � � � � �� Critical part of gen cheque � � � � � � � � � � � � � � � � � � � � � �� Critical part of gen cheque with preprocessing � � � � � � � � � � ��

�� Pseudonyms in organisations � � � � � � � � � � � � � � � � � � � � �� Identi�cation 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 � � � � � � � � � � � � � � � � � � �

xi

List of Figures CAFE Final Report Volume II

xii


List of Tables

�� Users� roles and functional entities in the CAFE payment system� ��

� �� Asymptotic running time for DLP algorithms � � � � � � � � � � � ��

�� Users� roles and functional entities in the key management system�� Data elements in a parameter certi�cate� � � � � � � � � � � � � � � � �� Certi�cate types� � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Computation times for ��spendable cheques � � � � � � � � � � � � �� Complexity of k�spendability � � � � � � � � � � � � � � � � � � � � ��

xiii

List of Tables CAFE Final Report Volume II

xiv


Preface

The report describes in detail the technical construction of an open cross�borderelectronic retail payment system that is fully capable of replacing physical cashand similar paper�based instruments� This fundamentally new currency sys�tem is well prepared for the challenges of the information age� by being basedcompletely on digital computer and communications technology�

To read and understand the entire report in detail requires in�depth knowl�edge from the �elds of computer science and cryptology� However� Part I givesa fairly brief and comprehensive overview� and should be easy to read withoutspecial knowledge�

The target audience of this report is people who take part in the technicalplanning� development� trial and deployment of new payment systems� services�and equipment� Typically� these will be people from banking and �nancial or�ganizations� equipment manufacturers� software houses� service providers� mer�chant chains� and support and consultancy companies�

The line of research concerned with constructing cryptographic protocolsthat can provide the service and security required for digital cash had its startin the early eighties� The single most in�uential researcher and motivator overthe years has been David Chaum� who also laid the �rst stepping stones for theCAFE consortium and served as chairman of the project�

The CAFE project was partly funded by the ESPRIT III program during theperiod from December �� through February �� Field trials of an imple�mentation started in October �� at European Commission sites in Brussels�

The overall project was structured into four technical workpackages� Se�cure Protocols� Architecture� Demonstrator� and Trials � Surveys� This reportpresents the results of the Secure Protocols and Architecture workpackages�

The report is structured into seven parts� Part I� Overview� gives the basicobjectives� and outlines the structure of the system� with its functionality andsecurity properties� Part II� Architecture� describes the system and securityarchitecture� Part I and II together will give the reader a good understandingof the concepts and principles involved�

Part III� Protocols� contains a complete speci�cation of the essential pro�tocols in the system� The speci�cations are oriented toward the mathematical�cryptographic� computations in the protocols� The prerequisite to interpretthe protocol speci�cations is included in the �rst chapters of this part� Part IV�Security Evaluation� lists the security requirements and gives arguments for thesecurity of the system�

Part V� Clearing� describes the infrastructure for interbank clearing and

xv

Preface CAFE Final Report Volume II

settlement� and how the validity of the currency and the integrity of the sys�tem operation are maintained� Part VI� Key Management� speci�es how thegeneration� certi�cation� distribution and revocation of system and securityparameters are carried out in the system�

Finally� Part VII� Extensions� proposes and discusses additional protocolsand 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� Mj�lsnes and R� Michelsen� A� Bosselaers�R� Hirschfeld� and R� Carter produced valuable comments on the �nal draftversions of the text�

The EditorsApril� ��

xvi


Part I

Overview

�


Chapter �

Objectives

The CAFE project has developed the concept of an electronic wallet containingcurrency� a pocket sized workstation that lets users undertake cash paymentselectronically at shops� payphones� vending machines� toll roads and publictransportation� An electronic wallet transacts either directly or via computernetworks with merchants� tills� service points provided by banks and otherorganizations� or with wallets held by individuals�

For backwards compatibility� the simplest type of wallet was realised in theform of a smart card� The project additionally built more complete wallets�These are self�contained with respect to user interface and external commu�nications� Such features make the wallet more secure and allow application�exibility� We envisage that electronic wallets will eventually connect to or beembedded in multi�application pocket workstations�

The CAFE results and technology represent a major step forward over anyapproach to retail electronic currency systems proposed to date� Former ap�proaches� typically employing pre�paid IC cards� are only suited to closed sys�tems with low security� A single national phone card� where the issuer andthe service provider is the same� typi�es such systems� The CAFE technology�on the other hand� is designed to operate in an open and international retailpayment system� where high security for all parties is demanded�

This report presents the speci�cations of the CAFE system� The report de�tails the security and functional design� Certainly� the aim was to keep theimplementation constraints to a minimum� thereby making it easy to adapt tonew implementation tools and devices steadily becoming available� Neverthe�less� the feasibility of the system has been veri�ed already through implemen�tations �CC�b� and a trial site �CC�a��

�

Chapter �� Objectives CAFE Final Report Volume II

�


Chapter �

The System

�� System Model

The basic system model is shown in Figure �� It shows the most importantroles in the payment system and the transactions executed between these roles�

�� Roles

The following basic roles can be identi�ed in the CAFE system�

Payer A payer withdraws electronic currency from the issuer by a withdrawaltransaction� and pays for services or goods to a payee by a paymenttransaction�

Payee A payee receives electronic currency from a payer by a payment trans�action� and deposits it with the acquirer by a deposit transaction�

Issuer An issuer is a bank organization issuing electronic currency to the pay�ers�

��

eee

Payer Payee

Issuer Acquirer

Clearing

Withdrawal Deposit

Payment

Figure �� Overview of the payment system roles and transactions�

�

Chapter �� The System CAFE Final Report Volume II

Acquirer The acquirer collects the electronic currency from the payee andforwards the cheques to the clearing�

Clearing The clearing checks the validity of electronic currency� accumulatescurrency claims from acquirers on issuers� and initiates funds transfersbetween 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�

�� Transactions

The most important transactions in the CAFE payment system are withdrawal�payment and deposit� These transactions realize the key services of the paymentsystem� A more detailed description of these and additional transactions aregiven in Part II�

Withdrawal This transaction is executed between an issuer and a payer� Theissuer debits the payer�s bank account by an amount speci�ed by the payerand issues the corresponding amount in electronic currency� The payermay choose his electronic currency from a list of di�erent currencies�

Payment The payment transaction is executed between a payer and a payee�At the payee�s request� the payer transfers electronic currency to thepayee� The payee veri�es the validity of the received currency and ac�cepts the payment�

Deposit The payee deposits the electronic currency received by a deposittransaction with an acquirer� The acquirer forwards the deposit record tothe clearing system and the payee�s account is credited with an amountcorresponding to the received electronic currency�

�� The Electronic Wallet

A key component in the CAFE architecture is the electronic wallet as �rst in�troduced in �Cha�� The functional entities of such an electronic wallet com�municating with a service terminal are shown in Figure ��

The electronic wallet is an essential element in the balanced security ofthe proposed CAFE system� It reduces or even eliminates many of the trustrelations required in existing electronic payment systems that are based onmagnetic stripe or IC cards�

The electronic wallet comprises an observer and a purse� The observer istrusted by the issuer and protects the issuer�s interest during o��line transac�tions� The observer restricts the amount of money the payer can spend withinthe balance stored in the observer itself� Hence� the implementation of theobserver must be tamper�resistant�

�

CAFE Final Report Volume II �� Key Management

ObserverService

terminalPurse

Infrared link

Wallet

Figure �� The electronic wallet constitutes a purse and an observer� Itcommunicates with a service terminal using an infra�red link�

The purse is trusted by the payer� It veri�es the actions of the observer�and prevents the observer from performing unsolicited actions� In addition� thepurse typically contains buttons or a keypad and display for user input andoutput� For instance� these can be used to lock and unlock the wallet� andto verify requested amounts in payment transactions� A self�contained userinterface eliminates the need for a trusted service terminal� which is absolutelynecessary in other approaches to electronic retail payments�

Section �� gives an extensive description of the CAFE concept of an elec�tronic wallet� the options for implementation� and the implications with respectto trust assumptions�

�� Key Management

Public keys are certi�ed in a three level certi�cation hierarchy� A central certi��cation authority for system�wide keys� a number of realm certi�cation author�ities for keys belonging to roles such as issuer and payer� and the third level forissuers themselves� using digital signatures in the basic transactions�

In general� the owner of a key will generate it� have it certi�ed� and distributeit to the roles that need it� However� the payer distributes the issuer�s publickey certi�cate to the payees using the wallet�

�

Chapter �� The System CAFE Final Report Volume II


Chapter �

Features

�� Introduction

The CAFE payment systems are all following the paradigm of untraceable elec�tronic cash �rst proposed by David Chaum �see �Cha�� The model for o��lineelectronic cash o�ering both integrity and privacy was introduced in �CFN ��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 pro�posed� like e�g�� Ant � CBH� � FY�� OO � OO�� Pai�� Fer�a� Fer�b��In �Bra�� Bra�a� the digital signature schemes of �CP�b� and �HP�� arecombined into an untraceable coin system� that served as the starting point forthe cheque�based CAFE systems of Part III� that use cheques in combinationwith one or more balances� an idea that was �rst introduced in �BC ��

�� 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 inadvance of the payment� The payment is analogous to a cash payment in thatthe money is transferred instantaneously without consulting a bank or otherintermediaries� The currency can be deposited with any acquiring bank�

O� line Payment A property of the CAFE security architecture is that thepayment can be made o��line� No connection with the issuer or any other thirdparty is required at payment time� similar to a cash payment� This featureis very important for the cost�e�ciency of low�value payments� It is also veryimportant 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 receivedelectronic currency is valid� Forged payments are prevented at payment by thepayee� but will also be detected when the transaction is cleared� This is similarto current cash�

The mechanism used to enable the payee to check the validity is based onpublic key digital signatures� This is described in some detail in Chapter ��

Signature Transport The CAFE currency is based on signature transportingcheques� At withdrawal� cheques are signed by the issuer and transported to thepayer�s wallet� This guarantees the validity of the cheque and that the payer isa customer of the issuing bank� The issuer�s signature is veri�ed by the wallet�

Chapter �� Features CAFE Final Report Volume II

At payment� the payer�s wallet adds another signature to the cheque� now �lledin with the amount of the payment and the identity of the payee� It is thentransported to the payee� who can check the validity of the payment beforeaccepting it� The transcript of the payment are deposited with the acquirer�

Multiple Currencies The CAFE payment system provides the possibilityto pay in foreign currencies in two di�erent ways� First� the payer�s wallethas several di�erent �pockets� for di�erent currencies� During withdrawal� thepayer chooses which currencies to load� This corresponds to the service ofbuying foreign currencies at a bank today�

The second method is a currency exchange performed at payment� Thepayee accepts a number of currencies at rates set by the acquirer� and if thepayer�s wallet has any of these currencies� a payment can be performed� Thepayer pays using the preferred currency accepted by the payee� the payee de�posits the received cheque and is credited in the home currency�

CAFE therefore permits payers to prepare themselves for payment abroad byloading foreign currencies in advance� but allows the �exibility of paying in anunanticipated currency if the need should arise by using the currency exchangeduring payment�

Loss Tolerance For payers� loss tolerance is probably the most importantspecial 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� Losstolerance means that the issuer is able to recover the currency from a backup andthe deposit transcripts� A backup procedure is carried out in normal operationsduring withdrawal� If a payer wants to recover lost money he will �reveal� theidentity of the cheques stored after the last withdrawal to the issuer� Thisenables the issuer to trace these cheques to see if they have been spent andrefund any remaining value that was left in the wallet

Fault Tolerance The CAFE system tolerates faults and interruptions duringtransactions without either party losing any money� Interrupted transactionsare automatically recovered by the system�

Incremental Payments A complete payment transaction requires two sig�natures by the wallet� Therefore very fast payments �less than �� seconds� arenot feasible in current implementations� The payphone application is an exam�ple where incremental payment is required� To provide many fast subsequentpayments to one payee� a special extension of the basic payment protocol isused� It allows the payment of a large number of amounts within one paymenttransaction� The total is not required to be known in advance� enabling e��cient pay�as�you�go applications� After an initialization phase� where the valueof one tick and the maximum number of ticks to be used is �xed� the payer sendssubsequent ticks on request� Only the last tick is deposited together with theinformation received during initialization� For example� within one payment fora phone call� the amount is incremented for each unit spent� Rather than one

�

CAFE Final Report Volume II �� Security

payment for each unit� there is one payment for the complete call consisting ofseveral units �Ped�� Ped��

Open Networks The CAFE protocols are designed to be secure over inse�cure networks� such as public telecommunication networks� Internet� wide andlocal area networks� including infrared links� This implies that withdrawals�payments and deposits can be undertaken without special requirements to thenetwork carrying the transactions�

�� Security

Multiparty Security The CAFE protocols achieve multilateral security byensuring veri�ability for all roles� the issuer� the payer� the payee� and the ac�quirer� In somewhat simplistic terms we can say that the integrity is maintainedunder 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 theacquire station� For example� the payer does not need to rely on the issuer�sreload station and the observer for the correctness of the withdrawal�

This balanced multiparty security is much more proper for open systemsthan former approaches to payment security�

Privacy If existing electronic payment systems� such as debit and creditcards� are used for everyday low�value payments� the system operator has ac�cess to an extensive pro�le of the payer�s behavior� A payee is forced to identifyits customers to maintain security in such systems� Payers may choose to keepon using cash� because it provides untraceability� Cash usage does not requirepayer identi�cation by the payee or the issuer� Moreover� di�erent paymentsperformed by the same payer are unlinkable with respect to the information dis�seminated in the payments� It is simply not possible for merchants and banksto 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 un�traceable with respect to payment transactions� if the payer so wishes� Neitherthe payee nor the issuer will learn the identity of the payer from the paymentitself� and di�erent payments are unlinkable �Cha�� Blind signatures �Cha��constitute the cryptographic means by which this privacy protection is achieved�

Forgery Protection Currency value in the transaction is represented byelectronic bits� which of course may be easily copied� Potentially� the originaland the copy may both be spent �double spending�� The payee is not able todecide whether he can accept the o�ered money� without contacting the acquirerto ask if these bits have already been deposited� This solution will require anonline payment� which is not cost e�cient for low�value payments in a retailenvironment�

The CAFE system employs two means to counter this threat� tamper�resistantobserver device and �after�the�fact� detection and tracing of the double spender�

��

Chapter �� Features CAFE Final Report Volume II

The tamper�resistance of the observer device protects copying and modi��cations to the currency� and makes it infeasible to spend electronic currencytwice� The tamper�resistance guarantees the integrity of the issuer to the payeein an o�ine payment�

If the tamper�resistance of an observer device is broken� copying and dou�ble spending of currency cannot be prevented� However� double spending willbe detected by the clearing� because the CAFE protocols ensure that doublespending payments are no longer anonymous transactions� The identity ofthe observer device will be computed and the forgery can be cryptographicallyproved from two payment transcripts� This restricts the potential gain of break�ing tamper�resistance� because the forger will be traced� and the system willblacklist 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� Physicalprotection of the till is not required� However� the currency value can easilybe destroyed due to storage erasure� consequently storage must be su�cientlyprotected 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 paymentshave to be deposited to one or more acquiring banks� and will show in thepayee�s account entries� This makes it very di�cult if not impossible to acceptelectronic currency as black money without the bank�s consent and collusion�

Bribery using electronic currency appears unattractive� The payee will runthe risk of incrimination by the payer� because the payer is always able toproduce cryptographic evidence of the payment� In addition� the payee willhave to deposit the bribe to a bank� where it will enter the accounts�

The withdrawal transactions are completely auditable by the issuer by stan�dards� The payer can audit the payment transactions completely by normalstandards� Withdrawal� payment and deposit transactions can be provablylinked if the payer so wishes�

PIN Verication The CAFE observer is involved in all transactions� The ob�server will however not participate in a transaction without being activated bythe payer entering a password or �number �PIN�� The CAFE system permits theuse of two di�erent PINs�one for withdrawal �for accessing the account bal�ance� and the other for payments and transfers �for unlocking a payer�speci�edamount of the wallet balance �Det�� It is possible to use the same PIN� butthis represents a small reduction of the system�s security�

��


Part II

Architecture

��


Chapter �

System Architecture

�� Requirements

The Trials � Surveys workpackage of the project collected user and expertrequirements and properties� Here we present a list of important requirementsthat have a major impact on the technical solutions of the architecture� andwhich the system satis�es� Much of the model� requirements� and additionalfunctionality ideas are based on �Cha� BP� PWP ��

Security The payment system and its applications should o�er a high level ofsecurity to all parties� where security means an appropriate combinationof integrity� privacy and veri�ability�

Privacy Payment transactions should protect the privacy of the payer�

Low cost Low value payments should be o��line to minimize payment trans�action cost�

Loss tolerance If the wallet becomes damaged� stolen or lost� the ownershould be able to obtain a complete refund of the lost currency value�

Limited transferability Unlimited transferability may have negative side�e�ects such as the black�market activity� money laundering and lost rev�enues for acquirers� It should however be possible to transfer value ifwallet a�liation has been prearranged�

Cross border The wallet should be able to contain several currencies� andallow for withdrawal and payment in those currencies� Also� the systemshould provide for currency exchange and paying with non�local currency�

Reliability There should be no consequences resulting from interrupted trans�actions when the wallet is used�

Compatibility It should be possible to retro�t existing terminal equipmentto transact with electronic wallets�

Open It must be possible for banks� merchants� and individuals to enter andleave the system at all times�

Standard The system speci�cations must be open and be capable of becomingan international standard�

��

Chapter �� System Architecture CAFE Final Report Volume II

Users

Roles

Functional Entities

Devices

Figure �� The abstraction hierarchy�

Applications It must be possible to create payment applications for a broadrange of services� including network services� payphones� shops� toll� etc�

Scalability The system should be able to scale to an international retail pay�ment system�

Extendibility The system should dynamically be able to include new paymentapplications�

Fungibility It should be possible to pay anywhere and anytime� provided thatthe wallet contains su�cient value� That is� the wallet should always beable to pay an exact amount without the problem of no �small change�available�

�� Framework

The architecture framework that this speci�cation adheres to is an abstractionhierarchy 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 enti�ties�

Figure �� illustrates this hierarchy�

The user� role and functional entity types are presented in Table �� Notethat 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 atleast take on the role of a payee� In practice� we expect both individuals andmerchants to take on both the role of payer and the role of payee�

��

CAFE Final Report Volume II �� Roles

Users Roles Functional entities

Reload stationBank Issuer Recovery station

ObserverAcquirer Acquire stationClearing Clearing system

Individual Payer PurseMerchant Payee Till

Table �� Users� roles and functional entities in the CAFE payment system�

The role of issuer is supported by three types of functional entities� reloadstation� recovery station� and observer� The payer owns and is supported bythe purse� The payee is supported by the till�

The term terminal is also used in the speci�cations� and denotes a genericfunctional entity� The speci�c functional entities will be apparent from thecontext�

Figure �� gives one example of how the framework can describe two users�a bank and an individual� This diagram applies the relations interpreted fromTable �� and instantiates one possible setting for the CAFE system� In thisparticular example the individual is acting both as a payer and a payee with asingle device implementing both the purse and the till� Many other diagramscan be constructed within this framework� In the �standard� setting oftenassumed in the CAFE project� the till entity is not implemented by the pursedevice�

�� Roles

This section outlines the roles of the CAFE payment systems� Figure �� de�scribes the roles of issuer� payer� payee� acquirer and clearing�

�� Issuer

An issuer exchanges cash� deposits or other kinds of money received from apayer into electronic currency� The payer receives the electronic currency in awithdrawal transaction� The issuer also loads cheques to the wallets�

There is no restriction on the number of issuers that can take part in thesystem� Normally� there will be several issuers� Issuers do not need to trusteach other� Obviously� if a single observer supports several issuers� mutual trustmust exist�

The accreditation of issuers� for instance by the central bank� is technicallycarried out in the key management system�

��


Acquirestation

Recoverystation

Reloadstation

Walletdevice

Individual

Payer Payee

TillPurse

Pursedevice

Bankterminal

Recoveryterminal

Functionalentities Observer

Acquirer Issuer

Bank

SmartcardDevices

Users

Roles

Figure �� An example from the architecture depicting one possible set of re�lations between users� roles� functional entities and devices� In this particularexample the purse and till have been combined into a single device� Also theacquire station and reload station have been combined into a single device�

�

CAFE Final Report Volume II �� Transactions

�� Payer

The payer withdraws electronic currency from the issuer and spends it withpayment transactions� The payer is supported by the purse� However� thepayer has to use a wallet� consisting of a purse that connects to an observer� toexecute withdrawal� payment and recovery transactions�

The observer is initialized and provided to the payer by the issuer�

�� 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 thepayee has a prior agreement with�

Both individuals and organizations can take on the role of a payee� Forindividuals� the till will most conveniently be incorporated in the electronicwallet device� For merchants� the till will be implemented by the cash register�

�� Acquirer

The acquirer collects electronic currency from the payees by accepting deposittransactions� It is the responsibility of the acquirer to submit the collectedcurrency to the clearing and credit the value to the payee� normally directly toa bank account�

A single payee can deposit currency with one or more acquirers� The ac�quirer may aggregate deposit records over a period of time� then sort and submitfor clearing in batches�

�� Clearing

The clearing receives �batches of� deposit data and checks validity and doublespending� It also initiates settlement between di�erent 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 clear�ing system�

�� Transactions

This section describes the payment system transactions� Figure �� shows thefunctional entities and the transactions that can be executed�

In the transaction descriptions we break down each transaction into individ�ual 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 thewallet takes part in the most important transactions security�wise� and becausethis description will re�ect su�ciently the actions of other entities�

We will have to distinguish the � wallet� the �� wallet� and the � wallet�A detailed knowledge about the di�erent wallet types is not required in a �rstreading of the transaction description in this section� Please refer to Section ��for a description of these distinct types of wallets�

�


Reloadstation

Acquirestation

Clearingsystem

Recoverystation

Observer

A�liatedpuse

A�liatedobserver

��

��

��

��

��

��

��

��

Purse Till

Withdrawal

Payment

Deposit

Transfer

Recovery

Figure �� Payment system architecture showing all functional entities andtransactions�

Although many protocol names are identical in the � and the � system� thisdoes not imply that the speci�cations are identical� Nevertheless� we take theopportunity 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 notconfuse the reader�

We make use of state diagrams to show how the protocols are carried out ina transaction� These diagrams are only intended as a guideline to the detailedprotocol speci�cations that appear in the subsequent chapters� So bear inmind that some details have been glossed over in order to make the diagramscomprehensible and simple�

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

�


��l

��

��

��

��

��

��XXreset get info authenticate

gen chequeupdate

write cu tblgen cheque

Figure �� State diagram showing the compound of protocols in the with�drawal transaction�

payer� represented by the purse� Figure �� shows the composition of protocolsin the withdrawal transaction�

The following is a somewhat more detailed step�by�step description of whathappens between the wallet and the reload station�

�� The wallet is started with the reset protocol�

�� The wallet presents its stored data about its issuer� by executing theget info protocol� If key updating is necessary� the update protocol isexecuted�

�� The authenticate protocol is executed� Here the reload station provesits identity to the wallet� subsequently� the wallet identi�es itself� andsigns all data relevant to the reload station�

If one or more payment transactions subsequent to the previous with�drawal session have failed� the rec payments protocol is called and run�This is not shown in Figure �� because the call to rec payments is in�cluded in the authenticate protocol speci�cation� Moreover� the proto�col write cu tbl is called in the authenticate protocol if the previousexecution of write cu tbl was interrupted� The protocol speci�cationincludes this in the authenticate protocol speci�cation� but it is notdetailed in Figure ��

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 tobe re�executed�

��


��

��

��

�� l��

��XX

reset get info

get certif

paymentshow currencies

unlock amt

Figure �� State diagram showing the compound of protocols in the paymenttransaction

The payer may choose to unlock an amount for payment� The wallet� orthe 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 withthe other protocols� and hence is not shown in Figure ��

The currencies and amounts are determined in the user interaction� andthe reload station will check the acceptability of the requests� For exam�ple� the balance of the payer�s account must be su�cient for the with�drawal� and the new total amount �when converted to home currencywith 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 with�drawal and exchange amounts and the old currency table�

�� If the new currency table di�ers from the previous instance� or if moneyhas been transferred using the transfer transaction� then the write cu tbl

protocol is carried out� If this protocol fails it reverts to step � to under�take an authentication before a new attempt is made�

If no change is requested for the currency table� then the transactionterminates without carrying out the write cu tbl protocol� This is notshown in the diagram� but can happen if the payer decides not to reloadvalue� For the � wallet� this will also occur if the payer just wants tocheck the balance� or wants to to unlock a new amount�

The gen cheque protocol is executed as many times as required� for in�stance� until available memory is �lled�

�� Payment

The main goal of the payment transaction is to transport value from the walletof the payer to the till of the payee� Figure �� shows the combination ofprotocols that the wallet will execute in the payment transaction� This �gureis representative both for the � and the � protocols�

Figure �� shows the combination of protocols for the �� wallet� The dif�ference is the load cheque protocol� which allows the observer to load chequesfrom the �� purse�

��


��

��

��

��

��l��XX

reset get info

get certif

paymentshow currencies

unlock amt

load cheque

Figure �� State diagram showing the compound of protocols in the paymenttransaction for the �� wallet

The following is a step�by�step description of what happens between thewallet and the till�

�� The wallet is reset using the reset protocol�

�� The till starts the get info protocol to check if the public keys that willbe required are available� If not� the till will start the get certif protocolto retrieve this from the wallet�

�� The show currencies protocol will aid the payer and payee to calculatehow the payment can be made� If the unlocked amount is insu�cient forthis payment� the unlocked protocol will provide the unlocking� assistedby the payer�

�� Once this has been done� the actual payment protocol can be started� Itdistinguishes between ordinary and phone�tick payment types� If severaltypes of currency are involved� the payment protocol is executed for eachof the currencies� until the total has been paid�

�� Deposit

The goal of the deposit transaction is for the till to forward all received electroniccurrency to the acquire station which will credit the payee�s account�

The deposit transaction consists of the deposit protocol which forwards thepayment transcript to the acquire station� The deposit protocol is executedonce for each cheque deposited�

The acquire station will forward all received cheques to the clearing systemfor validation� clearing and settlement with the issuer�

�� Transfer

The main goal of the transfer transaction is to transport value from a � walletto an a�liated � wallet� The a�liation has to be agreed in advance� by lettingthe � wallet store the public key po of the � observer� and the � observer storethe public key ps of the � wallet�

��


��l��

��

��XXreset

rollback

transfer

Figure �� State diagram showing the compound of protocols in the transfertransaction�

��

��

��l��XX

reset recovery init

Figure �� State diagram showing the compound of protocols in the rststage of the recovery transaction for the � wallet�

Figure �� shows the diagram compounding three protocols� The walletalways runs the reset protocol �rst� If a previous interrupt of transfer has oc�curred� 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 theprotocol speci�cations� The transfer protocol will check that the amount tobe transferred as requested by the user is in accordance with the preset transferconstraints�

�� Recovery

The recovery transaction enables the service of loss�tolerance in the CAFE sys�tem� If the wallet becomes damaged� lost or stolen� the unspent value can berefunded using the recovery transaction�

We have to distinguish between the � and the � wallet in the description ofthis transaction� The � wallet is not �standalone� with respect to user inputand output� So the recovery has to be carried out in two stages� In the �rststage� the user� at his own discretion� initializes an auxiliary � wallet employinga trusted terminal� The protocols used in this stage is shown in Figure �� Theinteraction with the bank is carried out in the second stage� Here the auxiliary� wallet is connecting to a recovery station physically distinct from the trustedterminal used in the �rst stage� Figure �� shows the protocols used in thisstage�

The auxiliary �� or � wallet provides a self�contained user interface� Sothere is no need for a trusted external terminal at the initialization of this typeof wallet� Figure �� shows how the protocols are compounded in the recoverytransaction for the �� or � wallet�

�� The wallet is initialized with the reset protocol�

�� Recovery seeds are input by the recovery station and by the user� here

��


��

��

��

��l��XX

reset get info

update Pa

recovery

Figure �� State diagram showing the compound of protocols in the secondpart of the recovery transaction for the � wallet�

��l��

��

��

��

��XXreset recovery init get info

update Pa

recovery

Figure �� State diagram showing the compound of protocols in the recov�ery transaction for the �� and � wallet�

denoted by recovery init�

�� The auxiliary wallet must contain the same system parameter version v�as the damaged wallet� This is checked by the get info protocol� Ifit turns out not to be the same then the update Pa protocol must beexecuted�

�� The recovery protocol regenerates all of the cheques that were storedin the damaged wallet� The auxiliary wallet signs the cheques and sendsthem to the recovery station�

��


��


Chapter �

Security Architecture

�� Security Approaches

The security of the CAFE architecture is based both on public key cryptog�raphy and on tamper�resistant devices� In this section we describe how thesetechniques are combined into a high security system�

�� Cryptographic Protocols

The di�erent roles in the payment system interact using cryptographic proto�cols� Cryptographic techniques are used to protect the integrity of the systemby providing�

Authentication of parties Cryptographic identi�cation protocols are usedto authenticate peers in a secure way� These protocols are secure againstpowerful attacks such as replay of authentication information obtainedfrom a previous run of the protocol�

Authentication of messages Digital signatures are used to authenticate mes�sages� Authenticated messages ensure that the sender of a certain mes�sage can be established without doubt and also provides non�repudiationof messages and accountability�

Integrity protection of information Cryptographic techniques are used toprotect messages sent between peers from being modi�ed�

�� TamperResistance

The CAFE payment system is based on the currency value being represented bya number of balances in electronic wallets held by payers� These balances mustbe updated only through the execution of well de�ned transactions supportedby cryptographic mechanisms� Modi�cation of balances must not be possiblewithout executing a complete and valid transaction�

To protect against unsolicited modi�cation� the balances are maintainedby a tamper�resistant device that implements the functionality of an observerentity� In this project� the tamper�resistant device is in the form of a smartcard�

The observer must change the balance only if a valid withdrawal or pay�ment transaction has been carried out� The tamper�resistance of the smartcard chip prevents the payer �and others� from bypassing the cryptographic

��

Chapter �� Security Architecture CAFE Final Report Volume II

mechanisms and protocols by changing �increasing� the balances with physicaland electronical means�

�� FallBack Security

It is hard to quantify just how secure a tamper�resistant device is� No integratedcircuit tamper�resistance techniques is believed to survive continuous and sus�tained attacks� The techniques have to keep up with the attacker techniques�If an attacker should succeed to break the tamper�resistance of a device� theCAFE system provides fall�back security based on cryptographic techniques�

While the tamper resistant observer device prevents the payer from spend�ing more money than he has withdrawn� the cryptographic fall back securitypermits identi�cation of counterfeiting payers during the clearing process�

The wallet contains cheques in addition to the balances� The cheques aregenerated and stored in the wallet during the withdrawal transaction� A uniquecheque is spent in each payment transaction� and it is the observer�s task toprevent that the same cheque is used in two di�erent payment transactions� Ifa payer is able to break the tamper resistance of the observer device and forgethe balance� the wallet will soon run out of cheques� If the cheating payer triesto use a cheque twice� he will be identi�ed by the system�

�� The Electronic Wallet

A key concept in the CAFE architecture is the electronic wallet� which is de�scribed in detail in this section�

�� Introduction

In the CAFE project we use the term electronic wallet to denote the functionalentity used by payers to interact with other roles during transactions�

An electronic wallet comprises an observer and a purse� The observer func�tionality is trusted by the issuer� The purpose of the observer is to preventthe payer from spending more money than is available in the wallet� Since theobserver device is embedded in the wallet� and under physical control of thepayer� it has to be tamper resistant�

The purse is an entity trusted by the payer� It is responsible for all wal�let input output� such as communication with service terminals and the userinterface� The purse also veri�es the actions of the observer� The purse willdetect if the observer performs actions not sanctioned by the payer� The pursewill also �reformulate� outgoing messages to prevent that the observer commu�nicates side information� The goal of an observer�s deviating actions may beunsolicited payments or leaking of private information� The purse will see to itthat this cannot happen�

A wallet device consisting of physically distinct observer and purse devices isdesirable 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

�

CAFE Final Report Volume II �� The Electronic Wallet

may choose an observer device developer and manufacturer that it trusts� Sim�ilarly� the payer is the only role that must trust the purse� Therefore a payercan obtain the purse from a manufacturer or retailer that this individual payertrusts� No functional entity has to be trusted by more roles that do not trusteach other because of potentially con�ict of interest�

A sketch of an electronic wallet communicating with a service terminal isshown in Figure ��

Many di�erent implementations of electronic wallets can be envisaged� Al�though simplistic� the electronic wallet can be realised in the form of smart cardwhere both the observer and the purse functionality are implemented on thesame chip� A more user�friendly wallet implement takes on a form similar toa pocket calculator� where display and keypad are included� The observer willtypically be implemented in the form of an embedded tamper resistant chip ora smart card inserted into the wallet�

The CAFE system is also suitable for payments over open networks� suchas Internet� In this case an electronic wallet can be implemented employing apersonal computer� Typically� the purse functionality will be realised by a soft�ware module running on the computer� while the observer will be implementedby a plug�in PC Card hardware module�

�� Wallet

Realisation The � �alpha� system provides an upgrade path from existingelectronic retail payment systems based on magnetic stripe and chip cards� Inthe � wallet both the purse and the observer can be implemented in a singletamper resistant chip�typically embedded in a smart card�

The � wallet has limited capabilities� The purse can only communicate withthe environment through the card�s electrical contacts� The payer has to rely onexternal equipment for correctness� such as total amount and PIN entry� Thewallet device will not always remain under the payer�s physical control becauseit has to be inserted into terminal equipment�

The number of cheques will be restricted by a quite strong limit on thestorage space in single�chip implementations� This implies a limitation on thenumber of payment transactions that can be executed before additional chequesare required� In practice the balance is more likely to be spent before the chequesupply is exhausted�

Trust Relations The combination of observer and purse into a single devicemeans that both the issuer and the payer has to trust this device� The issuermust trust that the wallet limits the spending of the payer according to thewallet balance� and the payer must trust the wallet not to implement hiddenfeatures� such as revealing the payer�s identity in a payment transaction�

The payer must also trust a number of service terminals� The till is typicallyimplemented by a point�of�sale terminal with a display and a keypad used forveri�cation of amount to pay and PIN entry for authorization of the paymenttransaction� This terminal must be trusted by the payer to display the cor�rect information� not to copy or store PINs and only to execute the speci�ed

�


protocols with the wallet�

Similar trust requirements apply for other terminals with which the walletperforms transactions� such as the terminal implementing the reload station�

�� Wallet

Realisation The �� wallet is an improvement of the � wallet with respectto user interface� It consists of an � wallet extended with with user interfaceand communication capabilities�

The �� observer is quite similar to the � observer� The �� purse func�tionality is extended with user interface capabilities� The implementation mayhave some buttons for use by the payer to con�rm an action� For instance�acknowledgment of correct amount in a payment transaction� The purse willalso contain facilities for communicating without physical contact � typicallyan infra�red link�

The �� wallet implementation is not limited to a single chip� so the storagespace is not restricted to on�chip memory� This allows for more cheque storagespace� which means that more payment transactions can be performed beforeconnecting to the issuer�

In summary� the �� wallet o�ers the following improvements to the � wallet�

� A single user interface for the payer�

� Display for stand�alone veri�cation of actions�

� A few function�speci�c buttons for stand�alone PIN entry and user ac�knowledge of actions�

� Extendible storage of cheques�

� External communications by an infra�red link enables the payer to havefull physical control over the wallet�

Trust Relations The issuer must trust the observer to limit spending to thebalance stored in the observer�

Still� the payer cannot check the � purse functionality because it is imple�mented on the same chip as the observer� The purse must be trusted not tocontain �hidden� features which may allow the wallet to leak additional infor�mation such as the payer�s identity�

The �� wallet nulli�es the need to trust the service terminals� The payer willnot have to hand over the wallet to the payee� PIN entering and veri�cation ofamounts will be undertaken locally by the payer� using the display and buttonson the wallet device�

�� Wallet

Realisation The � �gamma� wallet is a fully functional wallet� It containsa � observer� typically implemented by a single tamper resistant chip� andembedded in the � purse device� The purse has processing capabilities� memory

�

CAFE Final Report Volume II �� Key Management

and input output facilities� A � wallet will typically take the form of a smallpocket device with display� keypad and infra�red link for communicating withservice terminals�

In summary� the � wallet o�ers the following improvements over the ��

wallet�

� Better performance because the purse has computing power and can ex�ecute parts of the protocols�

� Signi�cantly better privacy and security characteristics� because the purseis 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 spendingaccording to the wallet balance�

Almost all trust assumptions by the payer with respect to the observer thatis needed for the � wallet can be removed by employing the � wallet� The payerstill has to trust the � observer to perform PIN veri�cation� according to theprotocol speci�cation�

The payer must trust the � purse to function according to the speci�cation�The purse is responsible for interaction both with the payer and with serviceterminals� In addition� the purse checks all actions performed by the observerto prevent the observer from releasing unsolicited bits of information to serviceterminals�

�� Key Management

This section provides a brief overview of the key management architecture� Thecomplete description of the key management system for the CAFE paymentsystem can be found in Part VI�

�� Certi�cation Authorities

In every cryptographic system cryptographic keys have to be distributed in atrusted manner� Alice can only validate a digital signature allegedly from Bobif she has access to Bob�s public key� If there is any chance that an impostoris able to fool Alice into using a di�erent public key� then Alice can�t trustsignatures allegedly generated by Bob� Alice can only trust Bob�s public keyif she gets it through a secure channel� for instance directly from Bob in aface�to�face meeting�

For an open retail payment system such as CAFE it is clearly impractical torequire that all peers exchange public keys in face�to�face meetings� A publickey is therefore certi�ed by a certi�cation authority using the certi�cation au�thority�s digital signature� If Alice receives a key certi�ed by an authority� shewill trust this key if she has a trusted copy of the certi�cation authority�s publickey� In this way we have reduced the problem from having to establish a securechannel to every other peer in the system to a single certi�cation authority�

��


�� Certi�cation Hierarchy

In CAFE the keys are certi�ed in a certi�cation hierarchy� The certi�cationhierarchy is organized in three levels�

�� A single central certi�cation authority constitutes the top of the certi��cation hierarchy� The public key of this role must be available to andtrusted by all participants in the system� It is used for certi�cation ofglobal keys and keys of the realm certi�cation authorities�

�� On the second level a number of realm certi�cation authorities are found�These authorities certify keys belonging to roles in the payment systemsuch as issuers and payers within a particular country or area�

�� On the third level are the individual roles of the payment system that usekeys during execution of the various transactions�

�� Key Certi�cate 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� Dynamicrelations exist between payer and payee�

For static relations� a certi�ed public key is sent directly from the owner ofthe 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 apayment transaction� This relation is however dynamic� and with a potentiallyvery large number of issuers� it is unlikely that all payees will get keys directlyfrom all issuers�

This problem has been resolved by having payers bring key certi�cates ofissuer keys to payees� In the payment transaction� the payer sends the certi�edissuer key to the payee on request� The payee veri�es the key certi�cate usingthe certi�cation authority key� and the payment transaction commences�

�� Generation of Keys

A goal of the CAFE system is that the security of all parties should depend aslittle as possible on other parties� This means that all parties must be able togenerate their own keys�

��


Part III

Protocols

��


Chapter �

Notation and De�nitions

The notation and de�nitions used in the protocol speci�cations are given inthis chapter� The description includes the representation of the numbers� andthe basic operations and functions� The basic cryptographic primitives arepresented in the next chapter �Chapter ��

�� Assignment De�nitions

The symbol ��!� is used for the assignment of a meaning to a variable orsymbol� That is� a �! b means that a is de�ned 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 thatthe two entities on either side are equal�

An ellipsis �� denotes an implicit enumeration� For example� �i ! �� n� is meant to represent the sentence �for i ! � i ! �� and so on� up toi ! n��

�� Representation of Numbers

In this document a byte is de�ned as an �bit quantity� A byte is consideredto be a nonnegative integer� That is� it can take on the values through�� ! ��

Furthermore� a word is de�ned as a ��bit quantity� A word is consideredto be a nonnegative integer� hence it takes on the values through �� !��

A number can be given in decimal� in hexadecimal as well as binary rep�resentation� All representations are given with the most signi�cant digit �rst�leftmost�� The hexadecimal representation of a number is " x� followed imme�diately by its hexadecimal digits� the most signi�cant one �rst� For example�the hexadecimal representation of the number � �� is xefcdab�� Thebinary representation of this same number is

��

A sequence of n bits b�� b�� b�n�� is interpreted as a sequence of nbytes in the following way� Each group of consecutive bits is considered as a

��

Chapter �� Notation and Denitions CAFE Final Report Volume II

byte Bi� the �rst bit of such a group being the most signi�cant bit of that byte�The bytes are numbered from left to right� starting from � Hence�

Bi �! b�i�� # b�i��

� # � � � # b�i�� i ! � �� n� � � ��

A sequence of �l bytes B�� B�� Bl�� is interpreted as a sequence of wordsW�� W�� Wl�� in the following way� Each group of � consecutive bytes isconsidered as a wordWi� the �rst byte of such a word being the most signi�cantbyte of that word� Hence�

Wi�!Bi��#Bi��

�#Bi��#Bi�� i ! � �� l � � � ��

In accordance with the notations above� the bits of a word W are denoted as

W ! �w�� w�� w��

where

W !��Xi�

wi��i � ��

A sequence of n bits x�� xn�� is interpreted as a number in the followingway� First� these n bits are interpreted as a sequence of n bytes� These nbytes are interpreted as in �� with the leftmost bytes the most signi�cant�

X �!�n��Xi�

xi��n�i��

�The interpretation of a sequence of bits as a word is a special case of this��Conversely� a number is written as an n�bit string according to this equation�

In this chapter and in Chapter �� words are denoted by uppercase lettersand the bits of this word by the corresponding lowercase letter with indicesas in Equation �� Likewise� bytes are indicated by uppercase letters andthe bits that constitute this byte by lowercase letters with indices as in Equa�tion �� The ordering of bytes in a word or number is given by Equation ��respectively ��

Finally� some examples� the number xefcdab�� is represented by the �bytes B� ! xef ! �� B� ! xcd ! � �� B� ! xab ! �� B� ! x�� !�� or the ��bit string �� Spacesnot included��

Similarly� the number

�� ! x��f�b��c�cb�

is represented by the � bytes B� ! x� ! �� B� ! x�� ! �� B� ! xf� ! ��B� ! xb� ! �� B ! x�c ! � � B� ! x�c ! �� B� ! xb� ! �� Thatis� as the �byte�string� �� f� b� �c �c b�� This is the binary string

��

The binary representation of the same number is

��

��

CAFE Final Report Volume II �� Denitions and Basic Operations

�� De�nitions and Basic Operations

� A string is a sequence of bits�

� For a string X the length of X is denoted as jXj� That is� jXj is thenumber of bits in the string X� If jXj ! n� then X is said to be an n�bitstring�

� For an integer N � the length of N is de�ned as the length of the shortestbinary 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 x�� x�� xl�� of X aredenoted by X�l �

� For a string X of length n � l� the last l bits xn�l� xn�l�� xn�� ofX are denoted by X �l �

� For a string X the byte�length of X is denoted as jXj�� That is� jXj� isthe number of bytes in the string X� If jXj� ! n� then X is said to be ann�byte string�

� For an integer N � the byte�length of N is de�ned as the byte�length of theshortest binary representation of N � The byte�length of N is denoted asjN j��Note that the same notation j � j� is used both for strings and numbers�

� For an integer N with jN j � n we say that it is padded to n bits �or nbytes� if it is represented by a string of length n� This is done by pre�xingthe binary representation with a su�cient number of �leading� zeroes� andrepresenting the result according to �� Equivalently� one can say thatthe representation of N according to �� is prepended by a su�cientnumber of bytes x��

For example� the number �� has binary representation

� � � � � ��

so it is represented by the ��bit �� byte� string

��

�� padded to � bits �� bytes� is the string

��

� For the hash function� intermediate padding is sometimes used� Thatis� the computation of a hash value on �a� b� c� is sometimes performedas H�a� �� b� c�� where exactly enough bits �� are inserted to get

��


a multiple of �� bits� That is� �a� �� completely �lls an integralnumber of blocks �as few as possible�� This is denoted as

H�a� �� b� c��

For example� if a is � bytes long� then �� represents �� bytes xff� if ais �� bytes long� �� represents �� bytes xff�

�The reason for this intermediate padding is implementation�driven� Thehash function H needs complete ��byte blocks� the computation of H�a�b� c� therefore may require that all of a� b and c are simultaneously inmemory� the hash function itself will claim even more memory� If b andc involve computations requiring a lot of memory� this may necessitatewriting a away to free some memory� and reading it back later to computethe hash value� The intermediate padding allows discarding of a after ithash been hashed� only the intermediate result of the hash function needsto 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� ifx 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�

abs�N� �!

�N if N � ��N if N � �

� For two strings X ! x�� x�� xn�� and Y ! y�� y�� ym�� the �n #m��bit string W ! XkY is de�ned as the concatenation of the strings Xand Y � That is�

wi �! xi i ! � �� n� �

wi�n �! yi i ! � �� m� ��

� For two wordsX and Y � the words U ! X�Y � V ! X�Y andW ! XYare de�ned as the bitwise XOR� AND and OR of X and Y � respectively�Hence� according to Equation ��

ui �! �xi # yi� mod �vi �! xiyiwi �! �xi # yi � xiyi� mod �

�i ! � ��

� For a word X� the word W ! X is de�ned as the bitwise complement ofX� hence

W ! X �!X � xffffffff �

or according to Equation ��

wi �! �xi # �� mod �� i ! � ��

�

CAFE Final Report Volume II �� Denitions and Basic Operations

� For a word X and an integer � s � �� the word W ! X s is de�nedas the result of �cyclicly� rotating X over s bits to the left� hence

W ! X s �! �X�s # �X div ��s�� mod ��

� For a nonnegative integer A and a positive integer B� the numbersA div Band A mod B are de�ned as the nonnegative integers Q� respectively R�such that

A ! QB #R and � R � B�

That is� A mod B is the remainder� and A div B is the quotient of aninteger division of A by B�

� The notation �X � Y �mod N�� X is congruent to Y modulo N� isused to indicate that X mod N ! Y mod N �

� The notation �X �� Y �mod N�� X is not congruent to Y modulo N� isused to indicate that X mod N �! Y mod N �

� For two nonzero integers X and Y we say that X divides Y if Y mod X ! � That is� if Y is a multiple of X�

� For two nonnegative integersX and Y � not both zero� the greatest commondivisor gcd�X�Y � is de�ned as the greatest positive integer that dividesboth X and Y �

� A prime is an integer greater than � that is divisible only by � and byitself�

� For any integer N � the set of nonnegative integers smaller than N isdenoted 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 mayperform the operations as usual without reductions moduloN � and reducethe result modulo N only at the end� or more often at convenience� Forexample�

�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 imple�mentor to decide which intermediate results are reduced modulo N � �Itwill in general be faster to reduce as often as possible� i�e�� abc mod N iscomputed as �ab mod N�c mod N ��

For the result of a computation moduloN � in general jN j bits are required�as it is in the range through N � � �inclusive��

� For any prime p� the set of positive integers smaller than p is denoted ZZ�p�

�


� For any prime p� the inverse modulo p of a nonzero integer a is the uniquenumber in ZZ�p� denoted as a�� that satis�es a � a�� mod p�� That is�the product modulo p of a and its inverse modulo p is ��

�For non�prime p an integer a such that gcd�a� p� �! � has no inverse� sothis "property� depends on the primality of p��

� Exponentiation modulo a prime p obeys the usual rules� for any pairof integers n and m and for any integer a� it holds that an�m � anam

�mod p� and �an�m � anm �mod p�� In particular�

an mod p �!

��

n copiesz �� a � a � � � amodp if n � �

abs�n� copiesz �� a�� a�� a�� modp if n � �

� For an integer a and a prime p� the order of a modulo p is the smallestnonnegative integer n such that an � � �mod p�� This order always di�vides p � �� Consequently� it always holds that ap�� mod p�� andap�� a�� mod p��

If the order of an integer a modulo p is prime� we often say that a is agenerator �

� For a generator g of order q modulo p and an integer a of the uniquesubgroup of ZZ�p 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 � that is not a prime� A compositecan uniquely be written as the product of at least two �not necessarilydi�erent� primes�

� A Blum integer is a composite that is the product of exactly two primefactors p and q� with p � q � � �mod ��

� Let D� and D� be two nonnegative ��bit sequence numbers �i�e�� D��D� � �� that are initialized to zero� and that are regularly incre�mented by �� Let V be another nonnegative ��bit sequence number witha value that both D� and D� had less than �� increments before theircurrent value� Remark that all of D��D�� V are allowed to wrap� i�e��the value following �� ! �� is � De�ne the operation D� � D�

�mod �� as

�D� � V � mod �� D� � V � mod ��

and similarly for ��

For mathematical background we refer to �Kob�� for implementation of mod�ular arithmetic and computations with large numbers see �Knu��

�

CAFE Final Report Volume II �� Symbols

�� Symbols

The following symbols and naming conventions for system parameters and keysare used throughout this document� For a thorough description of all systemparameters and keys we refer to Part VI� For a complete list of symbols werefer to Appendix A for the � and �� systems� and to Appendix B for the �system�

�� System Parameters

The CAFE system uses the following set of system parameters�

� A prime p�

� A prime q that divides p� ��

� A generator g of order q modulo p�

� A di�erent generator h of order q modulo p�

� A di�erent 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� loggGc� and loghGc

should be unknown to the users� �Note that loghGc ! �logg h�� loggGc mod

q�� The factorization of Nphone must be kept secret�

�� Keys

All secret keys have the form s� or S�� where " � is some index �if possibleindicating its purpose�� The corresponding public keys have the form p� �!Gs� mod p� p� �! GS� mod p� or P� �! GS� mod p� where G is one of fg�Gc� gcg�which are all generators of order q modulo p� The former two are systemparameters� and the latter is di�erent for each user� The most important secretkeys 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 �!GScc mod p��

� the � wallet�s or � observer�s key set �ss� ps �! gss mod p�� In all but onecase it is clear from the context whether � or � keys are meant� In thetransfer protocol both � and � keys are involved� and to avoid confusionthe � observer keys are called �so� po� in that protocol�

� a shared public key between bank and wallet pc �! gScc mod p� where gc �!psh mod p ! gssh mod p is a generator of order q modulo p containingthe identity of the wallet �i�e�� its secret key ss��

��


A cheque in the CAFE system can be seen as a set of secret keys and cor�responding public keys� that are used to sign the payment speci�cation� Asignature 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� forexample� the secret keys are denoted �� and the public keys are ��

�� Stable Storage and Atomic Actions

In the CAFE protocols two assumptions on the nature of actions and variablesinvolved are made�

� It is possible to have stable storage� That is� even when a protocol isinterrupted� the variables in stable storage retain their values� The im�plementation 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 thenew state� irrespective of failures� interruption etc� Of course� it wouldbe 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 isapproximated by implementing critical parts as atomic actions� Again�the implementation of this is up to the implementors� �Note that atomicactions imply usage of stable storage for the variables used��

��


Chapter �

The Basic Cryptographic

Primitives

The protocols of the CAFE system are built from a set of basic cryptographicprimitives� This set contains the following items�

� the Schnorr�s identi�cation 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 brie�y describe each of these primitives�

�� The Schnorr Scheme

Most protocols are derived from Schnorr�s identi�cation protocol �Sch�� de�picted in Figure �� This protocol allows a prover to prove his identity to averi�er � 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 veri�er� The veri�erreturns a �randomly picked� challenge� The prover then computes a response�and sends it back� The veri�er computes a �nal witness from this response� thechallenge and the prover�s public key� and veri�es if it equals the initial witness�The notation used is from �GUQ��

From this identi�cation protocol� a signature scheme can be constructed byreplacing the challenge by a hash value of the initial witness and the message tobe signed� see Figure �� So� the same identi�ers and corresponding notationof the identi�cation protocol can still be used� The signature consists of theresponse and the challenge� which is now called initial challenge� The veri�erconstructs the �nal witness as in the identi�cation protocol� so that the �nalchallenge can be computed �apply the hash function to the �nal witness andthe message� and compared to the initial challenge�

��

Chapter � The Basic Cryptographic Primitives CAFE Final Report Volume II

Prover Veri er

�S� P �� gS� �P �Commitment� w�RZZ

�

q

Initial witness� a� gw mod p

�a

��Challenge� c�RZZ

�

q

��c

��Response� r � w � Sc mod q

�r

��Final witness� a� � grP c mod p

Veri cation� a�� a� �mod p�

Figure �� 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� �P �m� �message�Commitment� w�RZZ

�

q

Initial witness� a� gw mod pInitial challenge� c� H�m� a�Response� r � w � Sc mod q

�m� c� r

��Final witness� a� � grP c mod pFinal challenge� c� � H�m� a��

Veri cation� c�� c�

Figure �� Schnorr�s signature protocol� The public key is P �� gS mod p�where S is the secret key�

�� The Basic Proof System

The basic proof system is derived from Schnorr�s identi�cation protocol �CP�b��The basic proof system works for the unique subgroup of ZZ�p of order q� denotedas Gq� It allows the signer� with key pair �S� P �! gS mod p�� to interactivelysign a message m � Gq� The signature on m consists of z �!mS mod p and aproof that logg P ! logm z� Given m and z� the basic proof system is depictedin Figure ��

Let H�� be a one�way hash function as in the Fiat�Shamir scheme �FS��The random challenge c can then be replaced by c � H�m� z� a� b�� and thesignature on m is �z� c� r�� It is correct if

c ! H�m� z� grP c mod p�mrzc mod p��

��

CAFE Final Report Volume II �� The Restrictive Blind Signature Scheme

Signer Veri�er

�S� P �! gS� �P �w�RZZ�qa� gw mod pb� mw mod p

�a� b

��c�RZZ�q

�� c��r � w � cS mod q

� r��a

�! grP c mod p

b�! mrzc mod p

Figure �� The basic proof system� It is the starting point from which theblind signature scheme is designed�

�� The Restrictive Blind Signature Scheme

The blind signature scheme allows the veri�er to obtain a valid signature �z� c� r�on the message m� such that the signer can see neither the message nor itssignature� Later on� the signer is unable to link a message�signature pair to theparticular instance of the signing protocol which generated this pair� However�the blind signature scheme guarantees to the signer that the pair �m� z� isderived� by the veri�er using a limited set of blinding operations� from the pair�m�� z� �! m�

S� known to both the signer and veri�er� In fact� the veri�ercan obtain a blind signature only on a message m that is a random power ofm�� Given �m�� z�� the blind signature protocol is depicted in Figure �� Inorder to achieve unlinkability� the veri�er in the basic proof system computes themessage m� to be signed in a blinded way� as a random power of the message m�

and also computes blinded numbers a� b� z from a�� b�� z�� The veri�er sends ablinded version c� of the challenge c� H�m� z� a� b� to the veri�er and modi�esthe response r�� such that the new response r ful�lls the requirement that�z� c� r� is a valid signature on m�

�� The van HeystPedersen Scheme

The van Heyst�Pedersen signature scheme �HP�� is an e�cient fail�stop sig�nature scheme based on the discrete logarithm assumption� Such a signaturescheme provides enhanced security against forgeries by a very powerful adver�sary� In case a signature is forged� the presumed signer can prove that thesignature is a forgery� he can prove that the underlying assumption of the sys�tem is broken� The signing and veri�cation process of the van Heyst�Pedersen

��


Signer Veri�er

�S� P �! gS� �P �w� �R ZZ�qa� � gw�

b� � mw��

t� u� v�RZZq

�a�� b��

m� m�t

z � z�t

a� a�gvP u mod p

b� �b�mv�z

u� �

t mod pc�H�m� z� a� b�c� � c� u mod q

�� c��r� � w� � c�S mod q

� r��r � r� # v mod q

a�! grP c mod p

b�! mrzc mod p

Figure �� The restrictive blind signature scheme

scheme is shown in Figure �� The signature on a messagem � ZZ�q with respectto the public key �a� b� is the tuple �r�� r�� The proof of forgery is logg h� if thepresumed signer receives a valid� forged signature �r�� r

�� ! �r�� r�� on m with

respect to the given public key �a� b�� then he can compute logg h� which is pre�sumed to be unknown to both signer and veri�er �see Section �� Remarkthat the scheme is a one�time scheme� the signer�s secret key �w�� w�� x�� x�� caneasily be computed if two di�erent messages are signed using the same secretkey�

�� The Randomized Schnorr Signature

Whenever the � observer and the bank exchange a signed message� the � pursemust randomize the signature in order to prevent that bank and observer sendinformation to each other �i�e�� to prevent in�ow out�ow� through the signa�ture� It is assumed that the message to be signed is of the standard form� Arandomized signature on such a message� m� with respect to the public keyP �! gS mod p works as in Figure ��

��

CAFE Final Report Volume II �� The RSA Signature Scheme

Signer Veri�er

w�� w�� x�� x��RZZ�qa� gw�hw� mod pb� gx�hx� mod pr� � w� � x�m mod qr� � w� � x�m mod q

�a� b� r�� r��

ab�m�� gr�hr� �mod p�

Figure �� The van Heyst�Pedersen fail�stop signature scheme�

Signer Randomizer Veri er

�S� P �� gS� �P � �P �w�RZZ

�

q

a � gw mod p �a

��

u�

�� mod qw � wu mod qa � au mod pc � H�m� a�r � w � cS mod q

��u

��u�RZZ�

q

a � au mod p

�m� r

��c � H�m� a�

a�� grP c mod p

�m� c� r��

a � grP c mod p

c�� H�m� a�

Figure �� The randomized Schnorr signature

�� The RSA Signature Scheme

The number n is de�ned as the product of two large primes p and q and iscalled the modulus� Let

�n� �! lcm�p� �� q � �� !�p� ��q � ��

gcd�p� �� q � ��

The public exponent e is chosen such that

gcd�e� �n�� ! � �

The secret exponent d is de�ned to be the smallest non�negative integer satis�fying

ed mod �n� ! � �

��


The public and secret keys are de�ned 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 numberm as input�that satis�es � m � n� They produce as output a number in the same range�The public key operation is de�ned as�

P �m� �!me mod n

and the secret key operation is de�ned by�

S�m� �!md mod n �

It is shown in �RSA�� that P �� and S�� are inverses of each other� i�e��

P �S�m�� ! S�P �m�� ! m

for all m in the range�

� The Oneway Function Encoding Phone Ticks

Let Nphone be the product of two primes p and q� The function

f � ZZNphone� ZZNphone

� x �� x� mod Nphone

is used to encode the amounts paid in phone ticks�

�� The Pseudo Random Number Generator

The pseudo random sequence generator �PRSG� generates a sequence of bitsfrom a string called the seed � Repeated use of the same seed will reproduce thesame sequence� Without knowledge of the seed� the sequence is unpredictable�for the one described below this holds under the assumption that factoringlarge numbers is hard�� The PRSG used for the protocols is from �ACGS��it is described in detail below� Subsequently� it is described how one can con�struct pseudorandom numbers from the pseudorandom sequence produced bythe PRSG�

�� 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 ! �� and k ! ��

The PRSG uses a function f that maps strings of length �at most� jN j tononnegative 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� mod N �

�

CAFE Final Report Volume II �� The Pseudo Random Number Generator

Given a seed S� jSj � jN j� the PRSG generates the following sequencefRi j i ! � �� g of k�bit numbers�

R� �! f�S� mod �k

R� �! f�f�S�� mod �k

R� �! f�f�f�S�� mod �k

��

��

Ri �! f i��S� mod �k

��

��

where f i�S� denotes the result of i times applying f to S� That is� Ri is equalto the k least signi�cant bits of S�i�� 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 sequenceof bits� and indirectly� to get a pseudorandom number� The latter case has twoinstances� generation of random numbers in ZZ�q and in ZZNphone

�

Generation of n bit strings for any n � � Let t � n div k and r �n mod k� Then� given a seed S� the numbers R�� R�� are computed asabove� and each interpreted as k�bit strings� If r �! then the required n�bitstring equals

PRSG�n� �! �Rt mod �r�kRt��k � � � kR�kR��

if r ! � this amounts to

PRSG�n� �!Rt��k � � � kR�kR��

That is� when the output is interpreted as an integer� then R� is the leastsigni�cant part� and the most signi�cant part consists of the r ! n mod k leastsigni�cant bits of Rt �if any�� followed by Rt��

A subsequent call of the PRSG will have seed f t��S� if r �! and seedf t�S� if r ! � Thus� the �rst subsequent bits are the least signi�cant bitsof Rt�� ! f t��S� mod �k if r �! � the �rst subsequent bits are the leastsigni�cant bits of Rt ! f t��S� mod �k if r ! � �If r �! � then the unused bitsof Rt ! f t��S� mod �k� are discarded��

An example of pseudorandom bit�strings is the generation of �� random bitsby the POS in payment� this is denoted as "�RZZ�� see Fig� �� It can �forexample� be implemented as an assignment "� PRSG��

Generation of numbers in ZZ�q� This is done as follows� Let l be a �small�nonnegative integer� the larger l� the more accurate is the random distributionof the �nal choice�

A random choice from ZZ�q is made by reducing PRSG�jqj # l� modulo q�The assignment of this value to a variable w is denoted as �w�RZZ�q�� That is�w � PRSG�jqj# l� mod q� Note that in general a random choice w�RZZ�q is jqjbits long� There is a �negligible� probability �of �q� that a random number

�


generated this way equals � which is not a member of ZZ�q� One caters for thispossibility by checking for its occurrence� and returning "�� instead of " ��

Remark that the choice k ! jqj# l ensures that one call to the PRSG yieldsexactly enough bits for one random number in ZZ�q�

Generation of numbers in ZZNphone� This is done as follows� A ran�

dom choice PRSG�jNphone j # l� is reduced modulo Nphone � The assignmentof this value to a variable � is denoted as ��RZZNphone

�� That is� � �PRSG�jNphone j# l� mod Nphone �

�� 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 di�erent sequences� onefor cheques� and one for all other purposes� �The reason for this is cryptographicseparation of the user�s security and privacy� This is necessary because in caseof recovery of a lost or malfunctioning user device� the user has to reveal partof the pseudorandom sequence used� By this separation� this hurts at most hisprivacy� 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 seedS� The other sequence is called �sequence �� and uses seed S��

Random number generation is indicated by ��RZZ�q� in the �gures� Nodistinction between to two sequences is made in the pictures� as the rule usedto decide which sequence to use is obvious� the one is used for cheques� theother 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 pseudoran�dom bits to produce one cheque �see gen cheque� Sections �� and �� Anindex indicates which block is currently in use� The stable variable dist holdsthe index of the cheque most recently withdrawn� This variable is updatedwhenever a cheque generation starts� This update must happen atomically tomake sure that no block is used twice�

Each block consists of k random numbers in ZZ�q � For the ��system k equals�� E�g�� is generated from the �rst part of the block� �� from the last part ofthe block� see ��gen cheque� For the ��system k equals � and � for respectivelythe observer and the purse� For compatibility with the ��system it may howeverbe convenient to also let the observer generate � random numbers� and discardthe two numbers that are not needed� This is why it is assumed in the sequelthat the observer needs � random numbers for a cheque�

The �rst such block generated has index �� the seed used for the generationof this block is S� So the seed for the block with index D is S�k�D��

mod NS

�

CAFE Final Report Volume II �� The Pseudo Random Number Generator

before starting the generation of the block� Furthermore� the modulus is NS �The k numbers generated use the seeds S�kD�k

� S�kD�k�� S�kD��

mod NS �

That is� the � wallet and � observer assign to �� the value f�S��D��

� mod

NS�� mod q ! �S��D�

� mod NS�� mod q� similarly� �� is assigned the value

�S��D� mod NS�� mod q� where stands for either � or � variables� For the �

purse k equals �� and hence �� is assigned the value f�S�D�

p mod NSp� mod

q ! �S�D�

p mod NSp� mod q� similarly� v is assigned the value �S�D modNSp� mod q�

It must be guaranteed that no part of a block is used twice� how this isguaranteed is an implementation issue� �Interruption is not an issue here� sincefollowing an interruption� a subsequent block will be used� not the block thatwas in use when the interruption occurred��

Finally� note that storage of some intermediate value S�k�V��mod NS to�

gether with the corresponding index value V � rather than using S� saves alot of computation� the initial seed for the block with index D is S�k�D��

!�S�k�V��

��k�D�V �

� This is also necessary to deal with over�ow of the index D�as explained below�

Sequence �

Sequence � uses a similar mechanism with block size �� The random numbergenerator call for this sequence will therefore do�

� Atomically increment dist��

� Call the PRSG once using dist�� S� and NS � Since the initial seed again

has index �� the seed with index dist� is S�dist��

� mod NS � The modulusis NS �

If some intermediate seed S��V � ! S�V��

� mod NS and the corresponding index

value V are stored� the seed used can be computed as �S�V��

� ��dist��V mod NS �

This is also necessary to deal with over�ow of the index dist�� i�e�� S��V � mustbe updated at least once every �� updates of dist�� to avoid regeneration ofthe pseudo random sequence after dist� has wrapped�

Over�ow of block indices

To deal with over�ow� all block indices in the user�s device �dist � min dist �max dist � dist�� see Sections �� and �� are allowed to wrap around� Thisposes no problem in the user�s device� as the seed for the block with index D isnot calculated from the initial seed S or S�� but from some intermediate valuewith index V � respectively S�V � ! S�k�V��

and S��V � ! S�V��

� � The seed

for the block with index D is then calculated as S�V ��k�D�V �

and S��V ��D�V

�respectively�

Therefore� in the user�s device only the relative distance between the blockindex D and the seed index V is important� not the absolute values of V andD� These relative distances will always be smaller than �� which allows for

��


their wrapping around� Whenever two indices are compared with one another�instead of using one of f�� g� one of the operations f� �mod ��mod �� mod �� mod ��g is used as de�ned in Section �� p� � �For the same reason the values of min dist � dist � and max dist stored in thesnapshot at the bank are not the block indices� actual values� but their residuesmodulo ��

However� to allow for a correct recovery of the user�s device the absolutedistance of the oldest unspent cheque at the last withdrawal is needed� Thisabsolute distance is equal to the number of times min dist wrapped aroundtimes �� 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�ssnapshot at the bank �see Sections �� and �� It is initialized on zero� andit is incremented each time the newly received value of min dist is smallerthan the value stored in the snapshot� for then min dist wrapped around� Inrecovery �see Sections �� and �� the � wallet or � observer calculatethe seed corresponding to the oldest unspent cheque at the last withdrawal as

S��nr wrap�min dist��

mod NS �

�� The Hash Function

This section describes the hash function H used in the � and � systems� It isbased on RIPEMD with a di�erent �nal expansion of the message� and with anexpansion of the �nal hash�value to � words �� bits��

This section is structured as follows� First� the representation of numbers�speci�c to this section� is given� Next� all functions used in RIPEMD are intro�duced� Finally� H itself is described�

�� Representation of Numbers

Important note� the representation of numbers de�ned below is used in this

section only� It is di�erent from the notation used elsewhere$ Speci�cally� theorder of bytes in the representation of a number is di�erent� a ��bit word hasthe bytes in order least signi�cant to most signi�cant� in contrast to the rest ofthis speci�cation�

For the sake of clarity� also those parts that are identical to the representa�tion of numbers in the rest of this document are repeated below�

In this section a byte is de�ned as an �bit quantity and a word as a ��bitquantity� A byte is considered to be a nonnegative integer� That is� it can takeon the values through �� ! �� Likewise� a word is considered to be a non�negative integer� hence it takes on the values through �� ! ��The value of a word can be given in decimal as well as in hexadecimal form� Inthe latter case the number is written as " x� followed immediately by at most hexadecimal digits� the most signi�cant one �rst� For example� the hexadecimalrepresentation of the ��bit number � �� is xefcdab��

��

CAFE Final Report Volume II �� The Hash Function

A sequence of n bits b�� b�� b�n�� is interpreted as a sequence of nbytes in the following way� Each group of consecutive bits is considered as abyte� the �rst bit of such a group being the most signi�cant bit of that byte�Hence�

Bi �! b�i�� # b�i��

� # � � � # b�i�� i ! � �� n� ��

A sequence of �l bytes B�� B�� Bl�� is interpreted as a sequence of wordsW�� W�� Wl�� in the following way� Each group of � consecutive bytes isconsidered as a word� the �rst byte of such a word being the least signi�cantbyte of that word �$�� Hence�

Wi �!Bi��#Bi��

�#Bi��#Bi� i ! � �� l � ��

Notice the di�erence in convention between the notations �� and ��In accordance with the notations above� the bits of a word W are denoted as

W ! �w�� w�� w��

where

W !�X

i�

�Xj�

w�i�j��i��j��

In this section words are always denoted by uppercase letters and the bits of thisword by the corresponding lowercase letter with indices as in Equation ��Likewise� bytes are indicated by uppercase letters and the bits that constitutethis byte by lowercase letters with indices as in Equation �� The orderingof bytes in a word is given by Equation ��

�� 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 de�ned as follows�

F �X�Y�Z� �! �X � Y � �X � Z� ��

G�X�Y�Z� �! �X � Y � �X � Z� �Y � Z� ��

H�X�Y�Z� �! X � Y � Z ��

For each bit of X� the function F selects a bit of either Y or Z� depending onthe bit of X� if the bit xi is �� then the corresponding bit yi is selected� else ziis selected �i ! � ��

The function G is the bitwise majority of the bits of X� Y and Z� if two orthree of the bits xi� yi and zi are �� then the corresponding bit gi of G�X�Y�Z�is �� else gi ! �

The function H is the bitwise parity �or XOR� of X� Y and Z� a bit hi ofH ! H�X�Y�Z� is � if an odd number of the bits xi� yi and zi is �� else hi ! �

Those three functions are used in six other �higher level� operations� Theseare used to process a message consisting of �� words X�� X�� X�� Forwords A� B� C and D� and integers � k � �� and � s � �� these operationsare de�ned as follows�

��


� FF �A�B�C�D�Xk � s� denotes the operation

A� ��A# F �B�C�D� #Xk� mod �� s � ��

� GG�A�B�C�D�Xk � s� denotes the operation

A� ��A#G�B�C�D� #Xk # xa�� mod �� s � ��

� HH�A�B�C�D�Xk � s� denotes the operation

A� ��A#H�B�C�D� #Xk # x�ed�eba�� mod �� s � ��

� FFF �A�B�C�D�Xk � s� denotes the operation

A� ��A# F �B�C�D� #Xk # x�a��be�� mod �� s � ��

� GGG�A�B�C�D�Xk� s� denotes the operation

A� ��A#G�B�C�D� #Xk� mod �� s � ��

� HHH�A�B�C�D�Xk � s� denotes the operation

A� ��A#H�B�C�D� #Xk # xc�dd�� mod �� s � ��

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 theresult over s positions to the left�

The four constants used in these operations are not randomly chosen� theyare the integer part of ��

p��

p��

p� respectively ��

p�� However� there

is no speci�c reason for this choice�

�� The Hash Function H

This section describes the hash function H� It is based on the hash functionRIPEMD� described in the RIPE report �BBB�� RIPEMD is a hash functionthat compresses messages of arbitrary length to a ��bit hash value or hashcodeof the message� It is conjectured that it is computationally infeasible to producetwo messages having the same hashcode� or to produce any messages having agiven pre�speci�ed target hashcode�

RIPEMD is an extension of the MD� message�digest algorithm �Riv�a��it has the same structure� but its compression function consists of two parallelcopies of MD��s compression function� identical but for some internal constants�The results of both copies are combined to yield the output of RIPEMD�s com�pression function� The reason for this more complicated design lies in the factthat successful attacks existed on two round versions of MD� �BB�� Mer ��Because of these attacks� the designers of MD� proposed a modi�ed version�which is called MD� �Riv�b�� However� there are indications that this redesign

��


has introduced new weaknesses in the algorithm �BB�� The RIPEMD exten�sion of MD� is from �Boe�� Recent work by Dobbertin �Dob�� has foundcollisions in two round versions of RIPEMD�

The design of the RIPEMD algorithm is such that it is very suitable forsoftware implementation on ��bit machines� Since no substitution tables areused� the algorithm can be coded quite compactly�

The basis of the hash function H is identical to RIPEMD� except for theexpansion of the message� Furthermore� the �nal output is �� 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 HH is a hash function that maps a message M consisting of an arbitrary numberof bits onto a �� bit block H�M�� The basis of H is the compression functioncompress� This function compresses a � �word input to a ��word output� Thisfunction is used in the following way�

First� the message is expanded to an appropriate length and represented bya sequence of words� Then� starting with a ��word initial vector � the resultingsequence of words is compressed by repeatedly appending sixteen message wordsand compressing the resulting twenty words to four words by applying compressuntil the message is exhausted� Thus� a ��word result can be obtained� Below�this is explained in detail�

Outline of compress

The compression function compress accepts an input consisting of four words A�B� C� D and sixteen message words X�� X�� X�� It produces four outputwords denoted as�

compress��A�B�C�D�� X� �X�� X��

The function compress consists of two separate halves� followed by a �nal stepcombining the results of both halves into four words� Each of the halves can bedecomposed 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 di�erent operation for each round� See alsoFigure ��

In other words� the input is passed to both halves� Both halves then inde�pendently transform� in three rounds of sixteen steps each� a copy of the ��tuple�A�B�C�D�� In a �nal step� the results of both independent transformationsare combined into the result of compress�

Outline of HLet M ! �m��m�� mn�� be a message consisting of n bits� The hashcodeH�M� of M is computed as follows� see also Figure ��

��


A

�

B

�

C

�

D

�

�

� �

�

� �

�

� �

�

� �

thirdround�

applic� ofHH

��X�

X��

��

X��

��

secondround�

applic� ofGG

��X�

X��

��

X

��

rstround�

applic� ofFF

��X�

X��

��

X�

��

thirdround�

applic� ofHHH

��X�

X��

��

X��

��

secondround�

applic� ofGGG

��X�

X��

��

X

��

rstround�

applic� ofFFF

��X�

X��

��

X�

��

� ��

� ��

��

��

��compress��A�B�C�D� �X�� X�� X��

Figure �� Outline of the compression function compress� The input to theright half is identical to that in the left half� only the constants used aredi�erent� The symbol denotes addition modulo ��

��


�A�� B�� C�� D��

�

compress

X��X�

��

��

X��

�rst message block

�

compress

X��X��

��

��

X��

second message block

�

qqqq

�

compress

X�N��X�N��

��

��

X�N��

Nth message block

�

H�M�

Figure �� Outline of H� The message M is expanded rst to X which is amultiple of � words long� Then X is processed as in this picture� The nalresult is H�M��

��


expansion� M is expanded to a message X consisting of ��N words X�� X�� X��N�� where N ! d n

��e �! ��n � �� div �� # �� That is� themessage is expanded such that it becomes a multiple of �� bits long�This expansion is not done if the message M already is a multiple of ��bits long� �In RIPEMD it is done even then��

compression� The resulting message X is compressed as follows using thefunction compress�

De�ne the words A�� B�� C�� D� as

A� �! x��

B� �! xefcdab��

C� �! x��badcfe

D� �! x��

For i ! � �� N�� the words Ai�� Bi�� Ci�� andDi�� are computedas follows from the words Ai� Bi� Ci and Di and sixteen message wordsX��i�j � j ! � ��

�Ai�� Bi�� Ci��Di��

� compress��Ai� Bi� Ci� Di�� X��i�X��i�� X��i��

That is� each ��word message block is used to transform �Ai� Bi� Ci� Di�into �Ai�� Bi�� Ci��Di�� for the current value of i�

hashcode� The hashcode H�M� is the concatenation of the four ��bit stringscorresponding to the four words AN � BN � CN and DN � and a �fth wordEN 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� �� div �� # �� The n�bit message M ! �m��m�� mn�� isexpanded to the ��N �word message X ! �X��X�� X��N�� by appending��N � n bits with value ��

mn �!mn�� ! � � � �!m��N�� ! ��

That is� append bits �� until the expanded message is a multiple of �� bits�

The Compression Function compress

For the ��word number �A�B�C�D� and the ��word message X�� X�� X��the ��word function value

compress��A�B�C�D�� X� �X�� X��

�


is computed in two parallel sets of three rounds� each round consisting of ��applications of one of the auxiliary operations de�ned by Equations ��%��

First� two copies of �A�B�C�D� are made� Next� both halves independentlytransform those copies in three rounds of sixteen applications of one of theoperations FF through HHH� Finally� the results of both halves and the initialvalues of A� B� C and D are combined into one ��word output� here denotedas �AA�BB�CC�DD��

In pseudocode�

� copy �A�B�C�D� for both halves �aa� A bb� B cc� C dd� Daaa� A bbb� B ccc� C ddd� D

� Round � for both parallel halves �FF �aa� bb� cc� dd�X�� FFF �aaa� bbb� ccc� ddd�X�� FF �dd� aa� bb� cc�X�� FFF �ddd� aaa� bbb� ccc�X�� FF �cc� dd� aa� bb�X�� FFF �ccc� ddd� aaa� bbb�X�� FF �bb� cc� dd� aa�X�� FFF �bbb� ccc� ddd� aaa�X�� FF �aa� bb� cc� dd�X�� FFF �aaa� bbb� ccc� ddd�X�� FF �dd� aa� bb� cc�X� �� FFF �ddd� aaa� bbb� ccc�X� ��FF �cc� dd� aa� bb�X�� FFF �ccc� ddd� aaa� bbb�X�� FF �bb� cc� dd� aa�X�� FFF �bbb� ccc� ddd� aaa�X�� FF �aa� bb� cc� dd�X� �� FFF �aaa� bbb� ccc� ddd�X� ��FF �dd� aa� bb� cc�X�� FFF �ddd� aaa� bbb� ccc�X�� FF �cc� dd� aa� bb�X�� FFF �ccc� ddd� aaa� bbb�X�� FF �bb� cc� dd� aa�X�� FFF �bbb� ccc� ddd� aaa�X�� FF �aa� bb� cc� dd�X�� FFF �aaa� bbb� ccc� ddd�X�� FF �dd� aa� bb� cc�X�� FFF �ddd� aaa� bbb� ccc�X�� FF �cc� dd� aa� bb�X�� FFF �ccc� ddd� aaa� bbb�X�� FF �bb� cc� dd� aa�X�� FFF �bbb� ccc� ddd� aaa�X��

� Round � for both parallel halves �GG�aa� bb� cc� dd�X�� GGG�aaa� bbb� ccc� ddd�X�� GG�dd� aa� bb� cc�X�� GGG�ddd� aaa� bbb� ccc�X�� GG�cc� dd� aa� bb�X�� GGG�ccc� ddd� aaa� bbb�X�� GG�bb� cc� dd� aa�X�� GGG�bbb� ccc� ddd� aaa�X�� GG�aa� bb� cc� dd�X�� GGG�aaa� bbb� ccc� ddd�X�� GG�dd� aa� bb� cc�X�� GGG�ddd� aaa� bbb� ccc�X�� GG�cc� dd� aa� bb�X�� GGG�ccc� ddd� aaa� bbb�X�� GG�bb� cc� dd� aa�X�� GGG�bbb� ccc� ddd� aaa�X�� GG�aa� bb� cc� dd�X�� GGG�aaa� bbb� ccc� ddd�X�� GG�dd� aa� bb� cc�X�� GGG�ddd� aaa� bbb� ccc�X�� GG�cc� dd� aa� bb�X�� GGG�ccc� ddd� aaa� bbb�X�� GG�bb� cc� dd� aa�X� �� GGG�bbb� ccc� ddd� aaa�X� ��GG�aa� bb� cc� dd�X�� GGG�aaa� bbb� ccc� ddd�X�� GG�dd� aa� bb� cc�X�� GGG�ddd� aaa� bbb� ccc�X�� GG�cc� dd� aa� bb�X�� GGG�ccc� ddd� aaa� bbb�X�� GG�bb� cc� dd� aa�X� �� GGG�bbb� ccc� ddd� aaa�X� ��

� Round � for both parallel halves �HH�aa� bb� cc� dd�X�� HHH�aaa� bbb� ccc� ddd�X�� HH�dd� aa� bb� cc�X�� HHH�ddd� aaa� bbb� ccc�X�� HH�cc� dd� aa� bb�X�� HHH�ccc� ddd� aaa� bbb�X��

�


HH�bb� cc� dd� aa�X�� HHH�bbb� ccc� ddd� aaa�X�� HH�aa� bb� cc� dd�X�� HHH�aaa� bbb� ccc� ddd�X�� HH�dd� aa� bb� cc�X�� HHH�ddd� aaa� bbb� ccc�X�� HH�cc� dd� aa� bb�X� �� HHH�ccc� ddd� aaa� bbb�X� ��HH�bb� cc� dd� aa�X�� HHH�bbb� ccc� ddd� aaa�X�� HH�aa� bb� cc� dd�X�� HHH�aaa� bbb� ccc� ddd�X�� HH�dd� aa� bb� cc�X�� HHH�ddd� aaa� bbb� ccc�X�� HH�cc� dd� aa� bb�X�� HHH�ccc� ddd� aaa� bbb�X�� HH�bb� cc� dd� aa�X�� HHH�bbb� ccc� ddd� aaa�X�� HH�aa� bb� cc� dd�X�� HHH�aaa� bbb� ccc� ddd�X�� HH�dd� aa� bb� cc�X�� HHH�ddd� aaa� bbb� ccc�X�� HH�cc� dd� aa� bb�X� �� HHH�ccc� ddd� aaa� bbb�X� ��HH�bb� cc� dd� aa�X�� HHH�bbb� ccc� ddd� aaa�X��

� combination of results into output �AA� �B cc ddd� mod ��BB � �C dd aaa� mod ��CC � �D aa bbb� mod ��DD � �A bb ccc� mod ��

The Construction of the Hashcode

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

EN � ��AN # F �BN � CN � DN � #BN # x�a��be�� mod ��

Note that this is the word resulting from the FFF �function� with the input wordXk replaced by BN and shift s ! �� The hashcode is the �� bit string

H�M� �!AN k BN k CN k DN k EN �

�


Chapter

The � Protocols

�� Introduction

This chapter speci�es the � protocols� where the wallet is typically realized inthe form of a smart card� This implies the observer and the �functionally verylittle� 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 CAFEproject has implemented this as a two�button wallet� This wallet device providesa display� infra�red communications� smart card slot and two keys for user input�This is called the ��system� The ��system uses the same cryptographicprotocols as the ��system� but with the added load cheque protocol� whichperforms reading unspent cheques from the purse�s storage into the observer�

The speci�cation of the � protocols does not include the protocols for PINhandling and the recovery function of atomic actions� The reason for this isthat the implementation aspects of these protocols also determine their formto a large extent� and that the implementation of them are not essential froma cryptographic protocol point of view�

The order of execution of the protocols� and dependencies between the pro�tocols are described in Section �� The � and ��systems include the followingprotocols�

rec atomics performs recovery of atomic actions� An atomic action is an ac�tion that can only be interrupted in a well de�ned manner� Interruptionof an atomic update of a variable will for instance always leave eitherthe old value or the new value�never some other unde�ned value� Therealization is left to the implementors�

reset resets the wallet� and is carried out prior to any other protocol or actionat startup�

get info forwards public parameter values �key and parameter versions� iden�tity of the bank� to the terminal� This allows the terminal to retrievethe necessary information for execution of subsequent protocols� eitherfrom the terminal�s database� or from the wallet �on request�� The latteris done by the get certif protocol� which allows an issuer to decide toupdate the wallet if an invalid key set is detected� For this� the update

protocol is used�

authenticate performs a mutual identi�cation of wallet and issuer� The issuerwill update its database about the wallet�s state�

��

Chapter �� The � Protocols CAFE Final Report Volume II

write cu tbl 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 ob�server� This requires a special action by the same wallet during the gen�eration with gen cheque by the same observer� see Section ��

show currencies forwards balance information from the observer to the ter�minal�

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 veri�cation�changing and unlocking �a wallet becomes locked� for instance after threeincorrect PIN entries �to be provided by the implementors��

unlock amt performs a PIN�protected unlocking of a payer�speci�ed 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 certi�cates needed during a payment to thetill�

update consists of two parts� each updates a speci�c public key certi�cate fromthe issuer� The certi�cate is checked� and all related keys are also updated�

deposit transports the electronic currency from the payee to the acquirer�

��

CAFE Final Report Volume II �� reset

�� reset

Wallet

do rec atomics

if pay busy

save failed paymentnr fail pay � nr fail pay # �decrease unlockedif pay type ! phone payment

Ebal � Ebal � tck cnt � Epayelse

Ebal � Ebal � Epay

reset pay busy

Figure �� reset�

The reset protocol� shown in Figure �� is always executed as the �rstpart in a transaction� That is� it is executed before any other protocol��

The reset protocol �rst calls the rec atomics protocol� this protocol re�covers all atomic actions that have been interrupted�

If the pay busy �ag is set� the interrupted payment is saved for later process�ing at a issuer terminal� Furthermore� the balance Ebal used in this paymentis decreased by the required amount� Finally� the �ag pay busy is reset� Thevariables Ebal � Epay � pay type and tck cnt are set by the payment protocol� seeSection ��

�� get info

Wallet Terminal

�v�� vB�a� vB�c� IDB��

Figure �� get info

The get info protocol� shown in Figure �� forwards public informationfrom the wallet to the terminal� This allows the terminal to retrieve the infor�mation necessary for subsequent protocols�

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

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

��


� 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� thetill retrieves them before doing the payment protocol�

�� authenticate

The authenticate protocol� shown in Figure �� performs the mutual au�thentication between reload station and wallet� The wallet reveals its identitysubsequent to the successful authentication of the reload stations identity�

The protocol is structured as follows� The � wallet sends a challenge tothe reload station� The reload station returns a signature of this challenge�The wallet veri�es 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 asnapshot of the wallet�

A snapshot contains the state of the wallet� as far as necessary to recoverto a consistent state at any point in time�

�� seq no� a sequence number of the snapshot�

�� cu tbl � the currency table� See Section �� for a description of the cur�rency table�

�� min dist � the block number modulo �� for the wallet�s seed used forregeneration of the oldest unspent cheque�

�� dist � the block number modulo �� of the seed used for the most recentlygenerated cheque� �Or� during such a cheque generation� of the currentlygenerated cheque��

�� max dist � an upper bound modulo �� on the allowed block number ofthe seed used for generation of new cheques� This is determined by theissuer and updated every time it is used on the basis of min dist and themaximal possible number of cheques on the card�

�� nr wrap� the number of timesmin dist wrapped around� It is incrementedeach time the newly received min dist is smaller than the correspondingvalue of the snapshot� This variable is not needed by the wallet�

The state of the � wallet further contains the variables�

�� cu tbl valid � a �ag indicating the validity of cu tbl in the wallet�

�� trans� the amount transferred by transfer �see Section �� as receivedby the � wallet since the last execution of write cu tbl� The issuer must

��

CAFE Final Report Volume II �� authenticate

Wallet Reload Station

mb�RZZ�

q

��mb

��wb�RZZ

�

q

ab � gwb mod pcb � H�mb� � � ab�rb � wb � cbSa mod q

��cb� rb�PIN��

ab � grbPacb mod p

cb�� H�mb� � � ab�

verify PIN

update min dist

state � �seq no� cu tbl valid �trans � min dist � dist �nr fail pay � � � cu tbl�

ws�RZZ�

q

as � gws mod pcs � H�cb� state� � � as�rs � ws � csss mod q

�

cs� rs�state� IDs��

retrieve ps� wallet recovered �snapshot corr� to IDs

check seq no

store seq no in snapshot

not wallet recovered �as � grsps

cs mod p

cs�� H�cb� state� � � as�

if �nr fail pay � ��call rec payments

if �cu tbl valid�

update snapshot

elsecall write cu tbl usingsnapshot

Figure �� authenticate

��


know this in order to compute the net amount transferred from a � walletto the a�liated � wallet� That is� the bank keeps a variable� say &� foreach a�liation� & is initialized to � and each time decremented by trans

as reported by the � wallet� and incremented by trans as reported by the� wallet�

�� nr fail pay � the number of failed payment transactions that still can berecovered by executing rec payments�

For disputability� the bank must store the signature �cs� rs� and cb and the statestate �needed to check the signature�� This is called a pre�image in the securityreview�

�� write cu tbl

Description of cu tbl

The wallet reserves storage space for max curr balances� currency identi�ersand exchange rates� These data are stored as cu tbl � This is a table withmax curr rows �numbered � � � � � max curr � �� and � columns �numbered �� The entry in row i and column j is denoted cu tbl �i� j��

Column � determine the currency type� The ISO currency codes are �ASCII characters long� but only � � � are signi�cant bits in these codes� Thesigni�cant bits are stored in two bytes� The exact implementation is left tothe implementors� Column contains the balances for these currencies ��bits�� i�e�� the number of units of the currency stated in column �� Column �stores the approximate exchange rates from the given currency to the payer�shome currency� The rates are used to provide an estimate in home currencyof an amount to be paid in another currency� The rates are also used for theunlocking of amounts� A rate is changed only when the corresponding balanceis changed due to an execution of the write cu tbl protocol� it is set to whena 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 maycontain a table like this�

� � � description

�� NLG �� Dutch units�� DEM �� German units �� Dutch units apiece�� BEF �� Belgian units �� Dutch units apiece�� GBP �� English units �� Dutch units apiece�� XEU �� ECU units �� Dutch units apiece

So� for instance� cu tbl �� is in currency cu tbl �� ! DEM� which is the ISOcode for German Mark� In this example� the balance is cu tbl �� ! � German currency units� The exchange rate used in the last exchange into Markfor this payer amounted to � DEM unit for �� NLG units� The DEM currencybalance amounts to � � �� ! �� denominated in NLG currency units�

��

CAFE Final Report Volume II �� write cu tbl


update max dist

wr�RZZ�

q

ar � gwr mod pcr �H�seq no� IDs� �cu tbl�� ar�

rr � wr � crSa mod q

��

cr� rr�

PIN � cu tbl ��max dist

��ar � grrPa

cr mod p

cr��H�seq no� IDs� �cu tbl�� ar�

verify PIN

reset cu tbl valid

trans � �increment seq no

store cu tbl �

store max dist

wz�RZZ�

q

az � gwz mod pcz � H�seq no� cu tbl �� az�rz � wz � czss mod q

�cz� rz

��increment seq no

az � grzpscz mod p

cz�� H�seq no� cu tbl �� az�

update snapshot � account

ww�RZZ�

q

aw � gww mod pcw �H�cz� cu tbl ��max dist � � � aw�

rw � ww � cwSa mod q

��cw� rw

��aw � grwPa

cw mod p

cw��H�cz� cu tbl ��max dist � � � aw�

set cu tbl valid

Figure �� write cu tbl

��


An empty row is cleared and set to its initial state during write cu tbl�That is� if a balance in row i �! is zero� the entries in that row are set to� incolumn �balance�� xFFFF in column � �ISO currency code�� and in column� �exchange rate�� The home currency row is exempted from this rule� becausethis currency should always be present in the currency table� If empty its stateremains in column �balance�� the ISO code for the home currency in column� �ISO currency code�� and � in column � �exchange rate��

Description of the write cu tbl protocol

The write cu tbl protocol� shown in Figure �� serves two purposes�

� if the wallet does not have a valid cu tbl � the reload station �nds this outduring the authenticate protocol� The value of the cu tbl as stored inthe 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� thena new currency table is determined by the reload station �from the oldcu tbl and the payers request� taking into account the coding of emptyrows mentioned above�� This new table is loaded into the wallet by meansof 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 limita�tions the issuer may set� For example� the net amount withdrawn �converted tohome 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� storedin the wallet must not exceed max bal �

The protocol is structured as follows� Three signatures plus the messagessigned �as far as they are not yet known to the receiving party��

�� the bank signs the wallet�s ID and seq no� and forwards the new cu tbl �

and the PIN�� The signature tells the wallet that the issuer allows it toerase the current cu tbl � So� after veri�cation� the wallet resets the �agcu tbl valid � and stores the cu tbl � received�

The issuer also signs the old cu tbl � This guarantees that no undetectedchange can be made between authenticate and write cu tbl� espe�cially� no undetected payment is possible� Including the old cu tbl is doneonly in case cu tbl valid is set� If it is not set� the issuer and the walletmay have di�erent tables� and the wallet cannot change it anyway �as nopayment is possible with the �ag reset��

�This will be a re�sending of the PIN obtained and used before in authenticate� it doesmake sense to re�check it� as it prevents the bank from the following attack� If no paymentwas made since the last withdrawal� a found and identi�ed wallet �by means of data printedon the plastic can be used to do a withdrawal� as the issuer has all data required to dowrite cu tbl�

�

CAFE Final Report Volume II �� gen cheque

�� the wallet signs the new cu tbl �� The issuer may store this as proof of thetransaction� In any case� the issuer must now update the snapshot andthe payer�s account to re�ect this change of state of the wallet�

�� The issuer also signs the new cu tbl �� together withmax dist that providesan upper bound on the number of cheques that may be withdrawn� Thissignature tells the wallet that the issuer has stored the same cu tbl �� soafter veri�cation of the signature� it sets the �ag cu tbl valid again�

For non�repudiation� the issuer must store the signature �cz� rz� and seq no andcu tbl � �needed to check the signature�� This is termed a post�image in thesecurity 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�

�� gen cheque


cu tbl valid �

dist�

� max dist �mod ��space for cheque �

increment dist �mod ��

�� u� v� ��RZZ�

q

�� g��h�� mod pc� � H�� g��h�� mod pc� � H�� g��c mod p�� p��c mod p

w��RZZ�

q

a� � Gw�c mod p

b� � gw�c mod p

��a�� b�

��a� a�G

vcP

uc mod p

b� �b�gvcp

uc �

�� mod pc� H�c�� c�� a� ab� �� c� � c� u mod q

�c�

��r� � w� � c�Sc mod q

��r�

��r � r� v mod q

ab�� Gc��

r�Pc��c �mod p�

store �c� r� dist�

Figure �� gen cheque

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

�


spending a cheque too many times� the payer speci�c generator gc is incor�porated in the cheque� However� for privacy reasons the wallet must blindthis generator so that it cannot be recognized when cheques are used� This isachieved using the blind signature protocol of �CP�b� �see Section �� Thegen cheque protocol� shown in Figure �� is repeated as long as the wallet canaccept more cheques in its memory� �It may of course also be aborted on theuser�s request��

A cheque consists of

� A blinded version �� of gc which is impossible to link to the wallet or payer�more precisely �� ! g��c mod p� where �� is chosen pseudo�randomly bythe wallet�� This key also serves as cheque identi�er�

� Two auxiliary one�time public keys� �� and �� needed to use the chequesand unknown to the issuer �two keys are needed since the cheque may bespent twice�� These keys are of the form

�� ! g��h�� mod p and �� ! g��h�� mod p�

where the ��s are generated pseudo�randomly by the wallet�

� A blind signature on gc from the issuer� This signature also binds thewallet to the choice of the two one�time public keys mentioned above�

� Secret information consisting of the ��s pseudo�randomly generated bythe wallet and needed to sign the cheque at payment�

Of these parts only the blind signature �c� r� from the issuer is stored in thewallet because the ��s can be regenerated as needed� Therefore� a cheque isrepresented in memory by �� bytes� � each for c and r� � for the index in thecheque sequence� and � for information on how often it has been spent� Theindex in the cheque sequence is needed to restart the random number generatorat the appropriate point so that the correct ��s are regenerated� At the momentof generation� this index is the current value of dist � The last byte is used todetermine if the cheque can still be used for payment� Thus� a cheque is fully"self�describing��

�� load cheque

The load cheque protocol allows the � observer to access external storage forcheques� 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 a�ected by the availability or use of load cheque�so it may or may not be available to an � chip� Note that this feature cannot beused fully with one �� wallet and several di�erent � observers� load cheque

will fail if another observer then the one used for generating it is inserted� thecheque is lost then� The protocol is described here because there is no problemin using it with an �� wallet� except for the issue mentioned above�

�

CAFE Final Report Volume II �� load cheque

The mechanism is as follows� The wallet keeps track of the number ofsuccessfully generated cheques during the withdrawal session� As soon as the��wallet has available space for just one more cheque� the wallet distorts theresponse r� from the terminal �e�g�� by sending � see gen cheque� Fig� �� The�� wallet will then abort the gen cheque protocol due to a failing veri�cation

ab�� Gc��

r�Pc��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 ofspace��

The wallet must make sure that one cheque slot in the ��wallet is keptempty if it wants to be able to load cheques in external storage� That is� itmust not �ll the last cheque slot in the �� wallet with the load cheque protocol�

Observer �� purse

��D

��cu tbl valid �space for cheque �

D�

� max dist �mod ��

D�

� min dist �mod �� u� v� ��RZZ

�

q

�index D�� g��h�� mod pc� � H�� g��h�� mod pc� � H�� g��c mod p�� p��c mod p

a� � Gr�c P

c�c mod p

b� � gr�c pc�c mod p

��a�� b�

��a� a�G

vcP

uc mod p

b� �b�gvcp

uc �

�� mod pc� H�c�� c�� a� ab� �� c� � c� u mod q

�c�

��received c� same as stored value�

��r�

��r � r� v mod q

ab�� Gc��

r�Pc��c �mod p�

store �c� r�D�

Figure �� load cheque

The purse stores the values c� and r�� and the value of dist used by the

�The issuer must choose a relatively liberal upper bound max dist to enable loading ofmore cheques�

��


observer� �Note that from c� and r�� both a� and b� can be recomputed�� Next�the gen cheque protocol is re�executed� and again r� is incorrectly transmittedto the observer� and �c�� r�� dist� is stored by the purse� This process is repeateduntil the external memory is full� or until no more cheques are required�

Since the purse possesses �c�� r�� dist�� it is able to feed D ! dist � a�� b�and r� back to the observer at a later stage� This is su�cient information forthe card to re�generate the related values of the �� u and v� and eventuallycompute the correct cheque �c� r��

Actually� after checking that D has an allowed value� the observer may doexactly the same as in gen cheque� starting after the increment of dist � Onlythe computation and transmission of c� 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 di�erences on the wallet side� compared to the gen cheque protocol arein the �initialization� only� and may be summarized as�

�� It must be veri�ed that D � max dist �mod �� rather than verifyingthat dist � max dist �mod ��

�� D must be loaded as the index to be used in the random generator �chequesequence�� rather than incrementing dist � and then using this value of dist �

�� An extra check is the veri�cation that D � min dist �mod �� Thisprevents double�spending of a previously spent cheque� The algorithmthat locates a cheque to be used in a payment guarantees that if severalcheques with the same value of dist �or several copies of one cheque� arepresent� only one of them is ever used� The veri�cation if D � min dist

�mod �� in this protocol guarantees that loading can only happen if allthese cheques are completely unspent� Since the algorithm is determinis�tic� always the same of these possible cheques is chosen for payment� untilit 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 alltimes� This is no problem as long as the protocol is not aborted� If it is� there aretwo possibilities� it aborts because of a failed test� or it crashes �for unspeci�edreasons�� In the �rst case� the wallet knows exactly where this has happened�or� more precisely� it knows whether or not dist has been incremented� Inthe second case� the wallet may not know this� The proposed solution is re�execution of authenticate to obtain the correct value of dist again�

��

CAFE Final Report Volume II �� show currencies

Observer �� Purse�Terminal

cu tbl valid �delay

�

cu tbl �unlocked �payments

��store�display this

Figure �� show currencies

�� show currencies

The show currencies protocol is given in Figure �� Its purpose is showingthe user the contents of the wallet� This can happen on the user�s request� orit may be necessary to enable the payer to make decisions by which currenciesand amounts he wants to spend�

A delay may be built in to discourage repeated use of this protocol� Since itinfringes on the users privacy� its use must be limited to the cases where eitherthe payer requests it� or the payment will not work without user interaction�The latter are notably payments in currencies other than the local currency� andpayments where no single balance is su�cient� These cases will be recognizedby the users as special cases requiring a longer time than normal� unnecessaryuse will be recognized as such� and may be aborted by the payer� �The delaytime should be con�gurable��

The show currencies protocol can be carried out between the � walletand 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 thewallet�

�� payment

The payment protocol is shown in Figures � and �� Besides the basic func�tionality the payment protocol contains two special features� currency exchangeand the possibility to handle phone ticks� These features are described in suc�cession�

Currency exchange during a payment is handled as follows� In principle� apayer may choose any currency to pay in that satis�es the following restraints�

�� The payee has a rate from the currency the payer chooses to the currencyof his own choice�

�� Using this rate� the payer has a su�cient balance on his card�

�The cheque index is called D rather than dist in load cheque� to avoid confusion withthe stable variable dist in the observer� D is a local variable� just as in payment�

��


Wallet Tillcu tbl valid cheque �c� r�D� i available

determine pay to� pay fro� cu to�cu fro� pay type

pay to�

� max pay�cu to

��

pay to� pay fro�cu to� cu fro�IDP � pay type�

date��

if �i � � �i� j� �� else � � �Ebal � suitable balance

Ebal�

� pay fro

pay fro unlocked regenerate �� u� v� ��j � g��jh��j mod pcj �H��j��i � g��ih��i mod p�� p��c mod p�� g��c mod p

mark cheque as spent i times�

i� c� r� cj ��i� ��

��if pay type � phone payment

��RZZNphone

�T � ��T

� mod Nphonet� T

��

�� mod pa� Gr

cPcc mod p

b� �r��c� mod p

ci � H��i

c�� H�c�� c�� a� ab� ��

��RZZ��

��m�H��i� �� pay to� pay fro�cu to� cu fro� IDP � pay type� date�� T

�� ss �m��i mod q�� m��i mod qEpay � pay fro

store date

if pay type � phone payment�tck cnt � �

set pay busy ��T � ��

�� if pay type � phone payment

t� T

� � �Tm� H��i� �� pay to� pay fro�cu to� cu fro� IDP � pay type� date�� T

g��h��

�m�i �mod p

if pay type � phone payment do phone�ticks

��thanks�

��decrease unlocked

if pay type � phone payment

Ebal � Ebal � tck cnt Epayelse Ebal � Ebal � Epay

reset pay busy

store deposit record

Figure �� payment� ith spending of a cheque

��

CAFE Final Report Volume II �� payment

An extra restriction on the payment is su�ciency of the unlocked amount un�locked � That is� the amount payable must be at most the unlocked amount�If the unlocked amount is insu�cient� the user can increase this amount by aPIN�protected protocol� the unlock amt�protocol� see Section ��

The payment of phone ticks is a special case� because within a short timea large number of small amounts must be paid� Because one does not wantto use a cheque for each of these payments� phone ticks are dealt with in thefollowing manner� This solution only uses one cheque per T ticks� Here T istypically in the order of � or � �to be decided by the system operator� sincethe variables counting ticks are one byte long� T must be at most ��

The function y � x� mod Nphone is a one�way function� The � walletchooses a random seed �� and repeatedly applies this function T times to ��The resulting value �T is incorporated in the signature that is generated withthe cheque in the payment protocol� Thus the withdrawal is not in�uenced bythe phone�ticks� A phone�call is paid for by releasing a pre�image of �T aftereach phone�tick� The public modulus Nphone � the product of two primes� is apublic system parameter� which should be chosen by the system operator� Thefactorization of Nphone should be kept secret� The system parameter T denotesthe 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 ordinaryones� The value �phone payment� of pay type indicates that the payment is aphone tick payment�

� Wallet Till

��

�T � t� n pay to�

� max pay�cu to

t�

� n

t� t� n

��ticks�� n

��

t�

� n

t� t� n

� � ��t

� mod Nphone�tck cnt � n Epay unlocked

Ebal�

� �tck cnt � n Epay

tck cnt � tck cnt � n

��

��

��

n

�mod Nphone

Figure �� payment� phone ticks� Pay n phone ticks costing Epay each�

Assume that a phone�tick payment is at hand� and that the cheque hasalready been written out to the phone�company� The � wallet pays for the�T � t��th tick by releasing the pre�image ��

t

� � This process is ended when

��


the �thanks� message has been received by the wallet� This happens when thephone�call has ended� or the maximum number T of ticks per �part of a� chequehas 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 themaximum number of ticks has been reached�� the entire payment protocol isrepeated�

Security requires that the balance is debited� irrespective of the success ofthe payment on the payee�s side� as otherwise one may gain money by inter�rupting payments� �A payment may go wrong after complete processing bythe payee� but before the payer has completed� see Figure �� Therefore� thebalance used must be known at the next reset� This information is denoted�Ebal�� it consists of su�cient information to recover the exact balance� Thatis� 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 failedpayment� A stable variable Epay contains the amount payable pay fro� Forthe currency cu fro� a special solution may be chosen� one may retrieve it fromEbal at reset� Furthermore� the date of payment �date� and the paymenttype pay type are stably stored� Finally� the stable counter tck cnt counts themultiplicity of the payment� for an ordinary payment this is meaningless� for aphone 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 therec payments protocol �see Section �� This is done in two steps� First� atthe next execution of reset� the necessary information is saved in a �failed�payment�slot�� Next� in the next withdrawal session the rec payments protocolis called to process this information together with the bank� �This recovery isof course only performed in case the payment is interrupted��

This mechanism requires that the following information is available at thenext reset �after interruption of a payment��

�� D� i corresponding to the cheque used in the interrupted payment� �Theyidentify 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� eitherby copying D �and i� explicitly in stable storage� or by storing a pointerto this cheque in stable storage� This is denoted as �save D� i in stablestorage�� the choice between the above implementations is left to theimplementors�

�� 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 informationrequired for recovery requires half the space of a cheque� �If the �rst paymentafter a complete �lling of the card with cheques is interrupted� this might requiredeleting the whole cheque used in this payment� depending on how the memoryis managed� This would also decrease the number of payments by one��

��

CAFE Final Report Volume II �� transfer

�� transfer

The transfer protocol allows the transfer of a value from the "mother� wallet�which is a ��wallet� to an a�liated "daughter� � wallet� To distinguish thekey pair �ps� ss� of the "mother� observer from the corresponding key pair in thea�liated � wallet� the former key pair is called �po� so� in this protocol� Thefollowing convention is applied throughout this section� observer variables areindexed by an o� purse variables by a p and � wallet �smartcard� variables byan s�

The transfer service is limited to one a�liation� Both mother and daughterkeep an extra balance� trans� that holds the cumulative amount transferred�This variable is reset at the next withdrawal session� in write cu tbl� Thevalue of trans is upper bounded bymax trans� to transfer more money� one must�rst reset trans by performing a withdrawal �write cu tbl�� Furthermore� atransfer can only be done in home currency� Recall that this currency alwaysis present in the currency table cu tbl �

The transfer protocol can only be executed if trans logp ! �� If this doesnot hold due to an interruption of a transfer� the rollback protocol needs to beexecuted to recover from the interrupted transfer� Also note that the previousvalue of trans logs is overwritten when a transfer is executed� This means thatany previously interrupted transfer cannot be recovered anymore after a newtransfer has been initiated�

Before the actual transfer is performed� both the � wallet and its a�lated �wallet determine whether the requested amount Xfer may indeed be transferred�Then a chain of signatures follows initiated by the � wallet� These signaturesare not randomized because there is no external terminal involved� For thesame 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 thedesired amount� Then follows a signature by the � wallet on a commitment yto be used for recovery� Finally� the signature of the � wallet is acknowledgedby a signature of the � observer� See Figures �� and ��

Note that this sequence of signatures achieves that the � wallet will onlytake part in a transfer with the � wallet to which it is a�liated� 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 emitsignatures to other devices that initiate the transfer protocol� If this was notthe case� the privacy of the payer could be broken by any service terminal thatthe � wallet connected to�

The rollback protocol allows the � wallet and a�liated � wallet to recoverif transfer is interrupted �see Figure �� The following cases exist�

�� If trans logp ! �� then nothing needs to be done�

�� If trans logp �! � and trans logs ! �� then the � purse must complete the�nal step of transfer� i�e�� set trans logp � � atomically� Then rollback

is completed�

��


� Observer � Purse � Wallet

trans logp��

determine Xfer

Xfer � transp�

�max trans

Ebalp � home curr�bal�

Xfer�

� EbalpXfer unlocked

��Xfer

��cu tbl valid

Xfer � transo�

�max trans

Ebalo � home curr�bal�

Xfer�

� EbaloXfer unlocked �

transo��

transo�� transp cu tbl valid

�Xfer

��Xfer � transs

�

�max trans

Ebal � home curr�bal�

total balance�Xfer�

�max bal

mt�RZZ�

q

��mt

�� mt

��wt�RZZ�

q

at � gwt mod pct �H�mt�Xfer � � � at

rt � wt � ctso mod q�

ct� rt��

at � grtpoct mod p

ct��H�mt�Xfer � � � at

�ct� rt

��at � grtpo

ct mod p

ct��H�mt�Xfer � � � at

x�RZZ�

q

y �H�x

trans logs � x

wa�RZZ�

q

aa � gwa mod pca �H�ct� y� � � aara � wa � cass mod q

��ca� ra� y��

Figure �� transfer �part �� an amount Xfer is transferred from the �wallet to the a�liated � wallet�

�



aa � grapsca mod p

ca�� H�ct� y� � � aa

trans logp � �y�Xferdecrease unlocked

Ebalp � Ebalp �Xfer

transp � transp �Xfer

��ca� ra� y��

aa � grapsca mod p

ca�� H�ct� y� � � aa

trans logo � �y�Xferdecrease unlocked

Ebalo � Ebalo �Xfer

transo � transo �Xfer

wi�RZZ�

q

ai � gwi mod pci �H�ca� � � airi � wi � ciso mod q

�ci� ri

��ai � gripo

ci mod p

ci�� H�ca� � � ai

�ci� ri

��ai � gripo

ci mod p

ci�� H�ca� � � ai

trans logs � increase unlocked

Ebal � Ebal �Xfer

transs � transs �Xfer

��OK�

��

trans logp �

Figure �� transfer �part �� an amount Xfer is transferred from the �wallet to the a�liated � wallet

�


�� If trans logp �! � and trans logs �! � and trans logo ! �� then the �observer does not need to do anything and the � purse increases its counterwhen it receives the right value for x�

�� If trans logp �! � and trans logs �! � and trans logo �! �� then the �observer increases its counter when it receives the right value for x� Afterthis� 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 logsand trans logo are not necessarily cleared� Also note that transfer can onlybe executed if trans logp ! �� and therefore an interrupted transfer must �rstbe recovered using rollback� In the rollback protocol� the user may chooseto cancel the recovery� for instance if the a�liated wallet is not present� In thatcase� however� the transfer protocol will not be enabled upon completion ofreset if trans logs was nonempty before reset�


trans logp�

�� insert daughter SC orcancel

x� trans logs

��x

��if �x �

trans logp � stop

��x

��if �trans logo �� y�Xfer� trans logoEbalo � home curr�bal�

if �x �� andy � H�x

trans logo � increase unlocked

Ebalo � Ebalo �Xfer

transo � transo �Xfer

��OK�

��y�Xfer� trans logpEbalp � home curr�bal�if �x �� and y � H�x

trans logp � increase unlocked

Ebalp � Ebalp �Xfer

transp � transp �Xfer

Figure �� 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 lastwithdrawal transaction performed by one of the wallets in the a�liation� To this

CAFE Final Report Volume II �� unlock amt

end� it keeps a variable� say &� for each a�liation� This variable is initializedto � and decremented by the reported trans in the withdrawal transactioncarried out by the mother wallet� and incremented by the reported trans in thewithdrawal transaction carried out by the daughter wallet� Thus�

� If & ! &� � � the last withdrawal was by the mother� If further�more the mother has transferred an amount &� since the last withdrawal�the daughter has transferred an amount ��&�� # &� since her last with�drawal� �If the daughter did a withdrawal at that moment� she wouldreport trans ! ��&�� # &�� and the bank would increment & by thisamount� to obtain a new value & ! &��

� If & ! &� � � the last withdrawal was by the daughter� If furthermorethe daughter has transferred an amount &� since the last withdrawal� themother has transferred an amount &� #&� since her last withdrawal� �Ifthe mother did a withdrawal at that moment� she would report trans !&� #&�� and the issuer would decrement & by this amount� to obtain anew value & ! �&��

� If & ! � both mother and daughter have transferred the same amount�say &�� since their last withdrawal�

Note that this hold initially� and will continue to hold subsequently� Further�more� it holds that �max trans � & � max trans � since this holds initially� and � trans � max trans � and a withdrawal cannot provide an inconsistent state�

�Proof� Suppose & ! &� � � and the daughter withdraws and reportstrans ! &� such that & � &� # &� � max trans � I�e�� if the mother did awithdrawal now� she would report trans ! &� # &� � max trans � which isimpossible� If the mother withdraws when & � � the value of & will decrease�So & � max trans � The lower bound follows similarly��

�� unlock amt

� Wallet �� Wallet�Terminal

get PIN and amount U to beunlocked from payer

��PIN � U

��if U � unlockedverify PIN

unlocked � U

Figure �� unlock amt� unlocking of an amount on the � wallet�

The unlock amt protocol unlocks a payer�speci�ed amount unlocked on the� wallet� That is� payments are allowed up to an amount of unlocked � if the

�


unlocked amount is smaller than the amount payable� the payer �rst has tounlock an amount by performing the unlock amt protocol again to make thepayment possible� Note that unlocked is not a balance� but just an extra variablecounting down for each payment made� �The unlocked amount can be higherthan 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 spec�i�ed 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 recoveredby the recovery protocol�

�� update

� Wallet Reload�Recovery Station

vB�a�Wallet��

� vB�a�Issuer�

��

Pa� vB�a�

Ea� CPa��

Verify certi�cate CPa withvalidity period Ea using publickey �mN � eN �

store new vB�a and Pa

Figure �� 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 oftwo parts� that may be executed separately and independently� The �rst partupdates the issuer�s authentication key Pa� This part is given in Fig� �� Thesecond part updates the issuer�s cheque�signing key Pc and the related � walletcheque key pc� This part is given in Fig� ��

�� get certif

The get certif protocol is given in Figure �� For an explanation of themechanisms� we refer to Part VI� The protocol forwards the keys and certi�catesneeded in a payment from the � wallet to the till� The till veri�es the certi�catesand uses the keys in a subsequent payment� Depending on the location of thetill and the realm of the issuer� and preferences of the payee� the key will bestored or discarded afterwards� �E�g�� the payee might store the last few keys�only the most frequently used keys �the local ones��

�

CAFE Final Report Volume II �� get certif

� Wallet Reload Station

mu�RZZ�

q

�mu

��

vB�c�Wallet��

� vB�c�Issuer�wu�RZZ

�

q

au � gwu mod pcu � H�mu� � � au�ru � wu � cuSa mod q

��cu� ru

��au � gruPa

cu mod p

cu�� H�mu� � � au�

�IDs

��retrieves ps corr� to IDs

gc � psh mod ppc � gScc mod pstore gc and pcwv�RZZ

�

q

av � gwv mod pcv � H�vB�c� � � pc� av�rv � wv � cvSa mod q

��

Pc� vB�c�

Ec� CPc �pc� cv� rv

��Verify certi�cate CPc with validityperiod Ec using public key�mN � eN �

av � grvPacv mod p

cv�� H�vB�c� � � pc� av�

store new vB�c and Pc� CPc � pcadapt min dist

Figure �� updateP c� Updating Pc�

�


Wallet Till

�IDB � vB�c� unknown �

��IDB unknown��

�Pc� CPc � IDN�KCC � vN��

if �IDN�KCC� vN � unknown then

��IDN�KCC unknown��

��mN � eN � CKN

� vC��

Verify certi�cate CKNusing public key

�mC � eC�Check validity period of �mN � eN �

end ifVerify certi�cate CPc using public key �mN � eN �Check validity period of Pc

Figure �� get certif� retrieving Pc from the � wallet�

�� rec payments

The rec payments protocol� shown in Figure �� initializes the recovery offailed payments� The protocol is executed between the � wallet and the recoverystation� It is repeated as long as the wallet contains failed payments to berecovered� The recovery station must limit this number to its estimate of thenumber of possible payments� Moreover� if a wallet creates too many failedpayments� 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 incase of a failed payment� The only thing the rec payments protocol still mustdo is to forward the data which the issuer needs to recognize the payment ifit arrives by normal deposit� If it does� nothing more happens� If it does notarrive within a certain time�span after the date recorded in the payment� thepayer is refunded the actual amount in the failed payment transaction� This isallowed� because obviously the payment failed for the payee too�

Note that the clearing system must make sure that no double recovery ofa failed payment occurs� Since the value of �� determines the cheque� this isan easy check� �This fact also makes replay of the protocol innocuous� it is notprotected against by the protocol��

The protocol just makes the � wallet sign all necessary data� the issuer sub�sequently signs an acknowledgment� Finally� the � wallet releases the memoryused for the data�

�� recovery

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

�

CAFE Final Report Volume II �� recovery

� Wallet Recovery Station

search failed payment �D� i� Epay �pay type� tck cnt � cu fro� date

regenerate �� from D

�� g��c mod pwp�RZZ

�

q

ap � gwp mod pcp �H�� i� Epay � pay type�tck cnt � cu fro� date � �� ap

rp � wp � cpss mod q

�

�� i�Epay � pay type�

tck cnt �cu fro� date�

cp� rp��

ap � grppscp mod p

cp�� H�� i� Epay � pay type�tck cnt � cu fro� date � � � ap

wk�RZZ�

q

ak � gwk mod pck �H�cp� � � akrk � wk � ckSa mod qsubmit the failed payment toclearing for recovery�

��ck� rk

��ak � grkPa

ck mod p

ck�� H�cp� � � ak

nr fail pay � nr fail pay � �remove payment

Figure �� rec payments

�


in Figure ��

Auxilary Wallet Trusted terminal

read recovery seed S� and modulusNS from issuer

read recovery seed S�� from user

��S�� S�� NS

��reset recovery done

S � S� � S��

store S� NS

Figure �� recovery init� initialization of an auxilary wallet�

The auxilary wallet re�generates all cheques that were generated during thelast withdrawal session by the lost wallet� It then signs the data needed by theissuer for determining if a certain cheque has been spent� This is similar torec 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 allowsthe clearing system to recognize these cheques� so that the issuer can be noti�edhow much was spent using these cheques�

From the snapshot acquired in the last withdrawal session� the issuer candetermine the balance of the wallet� If the � wallet is a�liated to a � wallet� theissuer must also know how much currency was transferred� A lower bound onthis is always known to the issuer� Together with the information on the valuespent since the last withdrawal� this provides a lower bound on the amount leftunspent� This amount can be refunded to the payer�

Note that a withdrawal transaction by the mother wallet enables the issuerto compute the exact amount transferred to the daughter wallet� this may beworth while to the payer� Also note that a withdrawal by the daughter isrequired in case of recovery of the mother wallet� if not� the issuer is only ableto compute an upper bound on the amount to be refunded� A withdrawaltransaction performed by the a�liated wallet will allow the issuer to obtain theexact amount�

To avoid problems with re�a�liation of an "old� daughter �or even severaldaughters� or mother to a replacement device �replacing the lost mother respec�tively daughter�� the issuer might also revoke the a�liated device�s� at recoveryof the lost device� possibly coupled with a withdrawal �or even recovery� of thea�liated device�s��

The recovery protocol need not be in the ROM mask� as the auxilary walletmay be implemented as a special purpose device that is erased after a successfulrecovery procedure� If so� an auxilary wallet will never have to perform otherprotocols� 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 hispart of the recovery seed S�� together with the modulus NS � And one with thebank� where all possible used cheques are re�generated�

The seed obtained in the �rst part� plus some data obtained in the second

�


Auxilary Wallet Recovery station

not recovery done mq�RZZ

�

q

obtain IDs of lost wallet from payerretrieve snapshot and hash seed forthat wallet

wallet recovered

�mq

��wq�RZZ

�

q

aq � gwq mod pcq �H�mq� hash seed � min dist �max dist � nr wrap� �� gc� aq

rq � wq � cqSa mod q

��

hash seed �min dist �max dist �nr wrap�gc� cq � rq

��aq � grqPacq mod p

cq�� H�mq� hash seed � min dist �max dist � nr wrap� �� gc� aq

hash seed�� H�S�NS

set recovery done

dist � min dist � � mod �

S � S��nr wrap�dist

mod NS

dist � min dist � � mod �

loop on all possible cheques

dist� max dist �mod �

dist � dist � � mod �

regenerate ��RZZ�

q

�� gc�� mod p

w��RZZ�

q

a� � gw� mod pc� �H�rq� dist � � � �� a�r� � w� � c�ss mod q

loop on all possible cheques

dist� max dist �mod �

dist � dist � � mod �

endloop

�� c�� r�

�� a� � gr�psc� mod p

c�� H�rq� dist � � � �� a�

store ��endloop

remove S and NS

credit �part of value in cu tbl

from snapshot to usersubmit all stored �� to clearingset wallet recovered

Figure �� recovery� recovery of a crashed or lost � wallet�

�


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� Forthis re�generation� the auxilary wallet must have the same system parametersas the lost wallet� That is� it must have the same version number v� �forexample determined by the get info protocol�� Moreover� it must have avalid issuer authentication key Pa� If this is not the case� the update protocolupdateP a is executed� The version of all other parameters �vB�c� most notably�are inconsequential in this protocol�

The correctness of the recovery seed and the modulus is determined bymeans 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�

�� deposit

The deposit protocol forwards the till�s stored information about the paymenttransactions� This includes all information obtained in get info and all mes�sages 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 betweenthe di�erent entities in the clearing system is made� nor is the interaction be�tween them mentioned� For a complete speci�cation� see Part V�

CAFE Final Report Volume II �� deposit

Till Acquire Station

�

IDP � ID�

B� IDB�v�� vB�c�

i� �� i� ��r� c� cj �

pay to� pay fro� tck cnt �cu to� cu fro� pay type� date�

�� T � ��

��retrieve parameters corr� to IDB� v��vB�c

parameters still valid deposit timely used rate valid

tck cnt pay to�

� max pay�cu to

��

�� mod pa� Gr

cPcc mod p


ci � H��i

c�� H�c�� c�� a� ab� ��


��tck cnt �

� �T �mod Nphone

m�H��i� �� pay to� pay fro�cu to� cu fro� IDP � pay type� date�� T

g��h��

�m�i �mod p

submit �IDp� m to double�depositcheck

credit tck cnt pay to to account ofIDP at bank ID �

B

submit �i� �� to double�spendingcheck

Figure �� deposit� depositing one payment transaction�


Chapter

The � Protocols

�� Introduction

This chapter speci�es the � protocols� where the wallet is typically realizedin the form of small pocket calculator�like device with a display� a keypad�and an infra�red link for communicating with service terminals� This � walletcontains a � observer implemented as a single tamper resistant chip� Theobserver is embedded in the � purse� which is a pocket workstation with its ownmemory and processing capabilities� and providing the input output facilitiesof the wallet� The purse serves to prevent out�ow from the observer to externalterminals as well as in�ow in the other direction� whereas the observer sees toit 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 afunctional entity to the system� while the embedded observer ful�lls essentiallythe same role as the � wallet in the � system� The actions of almost all otherfunctional entities are the same as in the � system� only the reload and recoverystations di�er slightly in that they use randomized signatures in their exchangeswith the � wallet�

The speci�cation of the � protocols does not include the protocols for PINhandling and recovery of atomic actions� The reason for this is that the imple�mentation 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 acryptographic protocol point of view�

The order of execution of the protocols� and dependencies between the pro�tocols are described in Section �� The � system consists of the followingprotocols�

rec atomics performs recovery of atomic actions� An atomic action is an ac�tion that can only be interrupted in a well de�ned manner� Interruptionof an atomic update of a variable will for instance always leave either theold value or the new value�never some other unde�ned value� The actualrealization is left to the implementors�

reset resets both observer and purse� and is carried out before any other pro�tocol or action�

get info forwards the public info �key and parameter versions� identity ofthe bank� to the terminal� The purse retrieves the information fromthe observer and checks its validity before passing it on to the terminal�

�


Based on this information the terminal retrieves the necessary data forexecution 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 ifan invalid key set is detected� For this� the update protocol is used�

authenticate performs a mutual identi�cation of observer and issuer and up�dates the information regarding the observer�s internal state in the issuer�sdatabase� The purse blinds the signature exchange between the issuer andthe observer and also checks the information related to the state beforepassing it on to the terminal�

write cu tbl allows the issuer to provide the observer with a new currencytable� The signature exchange is again randomized by the purse�

gen cheque generates new cheques for the wallet� The cheques are randomizedby the purse�

show currencies forwards the balance information� stored by the observer� tothe user� If the wallet has no capability of displaying information to theuser� 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 veri�cation� PIN changing and unlocking of a deviceafter three incorrect PIN entries �to be provided by the implementors��

unlock amt performs a PIN�protected unlocking of a payer�speci�ed 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 certi�cates needed during a payment to thetill�

update consists of two parts� each updating a speci�c public key from theissuer� The certi�cate 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 arealso recorded by the purse� These so�called shadow variables in the purse do notalways contain the same value as the corresponding variables in the observer�We introduce some notation to deal with these variables� To begin with� varpdenotes the purse�s shadow of the variable var in the observer� Further� theexpression eq �var� stands for var ! varp� and similarly geq �var� for var � varp�Finally� copy �var� abbreviates varp � var�

�

CAFE Final Report Volume II �� reset

�� reset

The reset protocol� shown in Figure �� is automatically executed when thewallet comes alive� Thus it is always executed before any other protocol��

The reset protocol �rst calls the rec atomics protocol� this protocol re�covers any atomic actions that have been interrupted�

If the rem pay �ag is set in the purse� recovery of a failed payment withthe rec payments protocol has itself been interrupted� The observer possiblyalready removed the failed payment� but the purse might not have done thisyet� In that case the observer�s number of failed payments �nr fail pay� is oneless than that of the purse �nr fail payp�� This can be corrected by letting thepurse complete the �nal part of rec payments� that is� delete the payment anddecrement nr fail payp�

If the pay busy �ag is set� a payment has been interrupted� The data of thatpayment are saved for later processing at an issuer�s terminal and the balanceEbal 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 ��

There are three possible interruptions of the payment protocol to consider�depending on the state of the pay busy and pay busyp �ags �see Figure ��

�� As long as pay busy is reset� purse and observer haven�t updated theircurrency table� and the till didn�t accept the payment yet� Hence� nointerrupted payment data needs to be stored�

�� Both pay busy and pay busyp are set� Then purse and observer stillhaven�t updated their currency table� but the till might have acceptedthe payment� Thus both purse and observer must update their currencytables�

�� pay busy is set and pay busyp is reset� There are two possibilities� eitherthe payment failed for the purse and was later saved in an executionof reset� which then failed for the observer� or the purse completed thepayment� but it failed for the observer� In either case the purse�s currencytable has been updated� but in the latter case the purse didn�t save theinterrupted payment data yet� These cases can be distinguished from eachother as in the former case the purse has already incremented nr fail payp�but the observer has not �hence nr fail pay ! nr fail payp � �� while inthe latter case neither purse nor observer have incremented their failedpayment counter yet �hence nr fail pay ! nr fail payp��

It is assumed that even if the purse completed payment it remembers the dataidentifying the payment �so that it can check that the observer uses the correctdata�� These data are� �D� i� Epay � tck cnt � pay type � cu fro� date�� The variablen �multiplicity of ticks in phone payments� is needed to verify that the observeruses a correct value of tck cnt �

�The security evaluation assumes that it is impossible to do any other protocol beforeresetis completed�

�


Observer Purse

call rec atomics call rec atomics

�

nr fail pay �pay busy

��if rem pay andnr fail pay � nr fail payp � �nr fail payp � nr fail payp � �remove paymentreset rem pay

if pay busy �

D� i�Epay �

pay type�tck cnt �cu fro�date

��if nr fail pay � nr fail payp

eq ��D� i�eq �Epay �eq �pay type �if pay type � phone payment

tck cntp��

ftck cnt � tck cnt � ngeq �cu fro�eq �date �save �D� i� Epay � tck cnt �pay type � cu fro� date

nr fail payp � nr fail payp � �if pay busyp

decrease unlocked


Ebal � Ebal � tck cnt Epayelse


reset pay busyp

��OK�

��if pay busy

save �D� i� Epay � tck cnt �pay type � cu fro� date

nr fail pay � nr fail pay � �decrease unlocked




reset pay busy

��OK�

��call rollbackcall get info

call show currencies

Figure �� reset

�

CAFE Final Report Volume II �� get info

No other entity is involved in this protocol� The following should always betrue after reset� nr fail pay ! nr fail payp� purse and observer have updatedthe currency table in the same way� and they have stored the same data aboutthe payments to be recovered �this is used in rec payments��

To recover from interruptions of transfer� the recovery protocol rollbackis called� Furthermore� get info and show currencies are called to guaranteethat the observer and the purse use the same keys and the same unlocked �

�� get info

Observer Purse Terminal

�

v��vB�a� vB�c�

IDB�� eq �v��'if ��eq �vB�a�� call

last part ofupdateP a

if ��eq �vB�c�� calllast part ofupdateP c

eq �IDB �'

�

v��vB�a�p� �vB�c�p�

IDB��

Figure �� get info

The get info protocol� shown in Figure �� forwards all public informationin the wallet to the terminal� It is a straightforward adaption of the sameprotocol in the ��system� The information is retrieved from the observer toensure that the keys send out to the terminal can indeed be used� If theobserver�s keys are not the same as the ones stored in the purse�due to aninterruption of either updateP a or updateP c�the purse re�executes the �nalparts of these protocols� The check on IDB is not really necessary� but it isretained for consistency�

�� authenticate

The authenticate protocol� shown in Figure �� and �� performs the mutualauthentication of issuer and wallet� The protocol is structured as in the ��system� The wallet identi�es itself only after the issuer has proven its identityto the purse �as this identi�cation is done for privacy reasons� only the purseneeds to verify it�the observer requires a PIN in order to proceed��

�


Observer Purse Reload station

wb�RZZ�

q

��ab

�� ab � gwb mod p

ub�RZZ�

q

ab � aubb mod p

�ub

�� ub�

�� mod qwb � wbub mod qab � a

ubb mod p

cb �H�abrb � wb � cbSa mod q

��rb

��cb �H�ab

ab�� grbPa

cb mod p

get PIN

��cb� P IN��

verify PIN

update min dist

if �cu tbl valid

cu tbl � �state � �seq no�cu tbl valid � trans�min dist � dist �nr fail pay � � �cu tbl

ws�RZZ�

q

as � gws mod p �as

��

us�

�� mod qws � wsus mod qas � auss mod pcs �H�cb� state � � � as

rs � ws � csss mod q

��us

�� us�RZZ�

q

as � auss mod p

�rs�state��

cs �H�cb� state � � � as

as�� grsps

cs mod p

Figure �� authenticate �part ��

�

CAFE Final Report Volume II �� authenticate


update min distpif cu tbl valid

eq �seq no��eq �cu tbl ��eq �trans ��

else

seq nop�

�fseq no� seq no � �g

cu tbl��

trans�

� f�� transpgcopy �seq no�

geq �min dist ��copy �min dist �

geq �dist ��copy �dist �

eq �nr fail pay ��

�

cs� rs�state� IDs��

retrieve ps� wallet recovered �snapshot corr� to IDs

check seq no

store seq no in snapshot

not wallet recovered�as � grsps

cs mod p

cs�� H�cb� state� � � as�

update nr wrap

if �nr fail pay � ��call rec payments

if �cu tbl valid�

update snapshot

elsecall write cu tbl usingsnapshot

Figure �� authenticate �part ��

�


The purse veri�es as much as possible the values describing the state ofthe observer� Here cu tbl seems to be a problem as the purse cannot tell if theobserver 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 checksthe values of dist and min dist � These are hard to check exactly due to possiblefailures�

The issuer also keeps track of the number of times min dist � wrappedaround� 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 issmaller than the corresponding value of the snapshot�

�� write cu tbl

Both purse and observer have �reserved space for� max curr balances� currencyidenti�ers and exchange rates� These data are stored in a currency table of thesame format as in the ��system� see Section ��

Again this protocol is similar to the one in the ��system except that allsignatures between observer and purse� and between purse and till are random�ized� 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 ��

�� 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 nowsplit between the observer and the purse�

The role of the purse in the gen cheque�protocol is to blind the chequesthat are withdrawn and thus guarantee their untraceability� The role of theobserver is to �participate� su�ciently in the new cheque so as to make surethat the newly withdrawn cheque can only be spent with the consent of theobserver� The purse�s role thus amounts to blinding the special one�time sig�nature issued by the observer as well as the issuer�s signature on it� while theobserver 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 �� it is repeated as longas the wallet accepts cheques� �It may of course also be aborted on the user�srequest��

When generating the cheques the observer has to know the secret keyscorresponding to each cheque �the ��s�� The purse is not allowed to know thesevalues �because then it could recover the secret key of the observer from thetranscript 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 theobserver� The purse must blind �� in a deterministic way in order to ensure thatthe same blinding factor is used in case the cheque must be recovered� This is

CAFE Final Report Volume II �� gen cheque

Observer Purse Reload stationretrieve PIN update max dist

wr�RZZ�

q

��ar

��ar � gwr mod p

ur�RZZ�

q

ar � aurr mod p

�ur

��ur�

�� mod qwr � wrur mod qar � aurr mod pcr �H�seq no� IDs��cu tbl� � � ar

rr � wr � crSa mod q

��

rr�

cu tbl ��max dist��

display cu tbl �

accept cu tbl �cr �H�seq no� IDs��cu tbl� � � ar

ar�� grrPa

cr mod p

��

cr� rr�PIN �

cu tbl ��max dist��

ar � grrPacr mod p

cr�� H�seq no� IDs��cu tbl� � � ar

verify PIN

reset cu tbl valid

trans � �increment seq no

store cu tbl �� max distwz�RZZ

�

q

az � gwz mod p �az

��

uz�

�� mod qwz � wzuz mod qaz � auzz mod pcz �H�seq no�cu tbl �� az

rz � wz � czss mod q

��uz

��uz�RZZ�

q

az � auzz mod p

�rz

��transp � �increment seq no

cz � H�seq no�cu tbl �� az

az�� grzps

cz mod p �cz� rz

��

store cu tbl �

max distp � max dist

increment seq no

az � grzpscz mod p

cz�� H�seq no�cu tbl �� azupdate �� snapshot� account

ww�RZZ�

q

��aw

��aw � gww mod p

uw�RZZ�

q

aw � auww mod p

�uw

��uw�

�� mod qww � wwuw mod qaw � auww mod pcw �H�cz� cu tbl ��max dist � � � aw

rw � ww�cwSa mod qcw �H�cz� cu tbl ��max dist � � � aw

aw�� grwPa

cw mod p

��rw

��

aw � grwPacw mod p

cw�� H�cz� cu tbl ��max dist � � � aw

set cu tbl valid

��cw� rw

��

Figure �� write cu tbl



cu tbl valid space for cheque

dist� max dist

�mod �

increment dist �mod �� RZZ

�

q

�� g��h�� mod p�� g��h�� mod p�� g��c mod p�� p��c mod p

space for cheque

distp� max distp

�mod ��

�

��

��

�� u�v�RZZ

�

q

�dist � ��

��

�� f�� g mod p

increment distp �mod �

geq �dist �copy �dist �

�� H�� distpdp

modNp modq�� g

��

��h��

�� mod p�� g

��

��h��

�� mod p

w��RZZ�

q

a� � Gw�c mod p

b� � gw�c mod p

��a�� b�

��

��

�� mod p

��

�� mod p

a� a�GvcP

uc mod p

b� ��b�g

vcp

uc

��

� mod p

��b�

��b� b�� mod p

�b

��c� �H��c� �H��c�H�c�� c�� a� ab� ��

c� � c� u mod q�

c��

r� � w� � c�Sc mod q

��r�

��r� r� � v mod q

a�� Gr

cPcc mod p

b�� r��

c� mod p

store �c� r� distp��

��OK�

��store �dist � �

Figure �� gen cheque� generate one new cheque

�

CAFE Final Report Volume II �� show currencies

done by using the result of an RSA secret key operation with modulus Np anda exponent pair �ep� dp�� The public RSA key �ep� Np� is stored with the user�saccount 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 foranyone else� It is on this computational di�culty that the user�s privacy �theanonymity of the cheques� is based� In order for the RSA public key operationto be a bijective function� the RSA public keys have to be chosen such thatgcd�ep� �pp � ��qp � �� ! �� where pp and qp are the prime factors of Np� Asknowledge of �pp � ��qp � �� is equivalent to knowing the factorization of Np�a protocol in which the user proves the validity of the public keys to the bankwithout revealing the factorization of Np has to be executed during initialisationof the purse �see Part VI� Section ��

The purse should also ensure that the blinding factors for the blind signa�ture �u and v� are random� As these values may be known to the purse they arechosen by the purse �this also saves computation in the observer�� For compat�ibility with the ��system it may however be convenient to also let the observerchoose u and v and then just discard these �this is why it is assumed that theobserver needs � random numbers for a cheque� see also Section ��

In the purse� a cheque is represented in memory by �� bytes� � each for cand r� � for the index in the cheque sequence and � byte indicating how oftenit has been spent �thus it is initially �� In the observer only � bytes are needed�indicating the index in the cheque sequence and the number of times it hasbeen spent��

�� show currencies

The purpose of the show currencies protocol� given in Figure �� is to presentthe contents of the currency table to the user� If the wallet has su�cient displaycapabilities the information only needs to be sent to the purse� otherwise adisplay on a terminal must be used� The value of payments can only be veri�edagainst an upper bound in the purse� If the unlocked amounts of the observerand the purse are di�erent� the unlock amt protocol is called to make themequal again� Note that the show currencies protocol can only reach this pointif cu tbl valid holds�

Observer Purse

cu tbl valid �

cu tbl �unlocked �payments

��if ��eq �unlocked � call unlock amt

eq �cu tbl �

payments�

� paymentspdisplay it

Figure �� show currencies� show currencies

� �


�� payment

The payment is shown in Figures �� and �� Currency exchange ishandled as in the ��system except that now the user does not have to send itscurrency table to the payee� Using the display of the wallet it is possible tomake the decision locally�

Phone ticks are handled as in the ��system by letting the observer and pursegenerate the ��values mutually at random�

Security requires that the balance is debited� irrespective of the success ofthe payment on the till�s side� as otherwise one may gain money by interruptingpayments� �A payment may go wrong after complete processing by the till� butbefore the wallet completed it�� Therefore� the balance used must be knownat the next reset� This information is denoted �Ebal�� it consists of su�cientinformation to recover the exact balance� That is� its position in memory� Thevalue of this balance is also addressed as �Ebal� �so in this case Ebal is thedereferenced pointer��

In addition� one needs �� the amount� currency and date of the failedpayment� A stable variable Epay contains the amount payable pay fro� Forthe currency cu fro� a special solution may be chosen� one may retrieve it fromEbal at reset �see also Chapter �� Furthermore� the date of payment �date�is stably stored� Finally� the stable counter tck cnt counts the multiplicity ofthe payment� for an ordinary payment this is meaningless� for a phone tickpayment it is the number of ticks �pay tck cnt ticks of pay fro each�� The purseneeds the same stable variables plus n� which is needed to check the value oftck cnt during recovery of a failed payment�

Recovery of a failed payment is done in two steps� First� at the next exe�cution of reset� the necessary information is saved in a �failed�payment�slot��Then� in the next withdrawal session �see Section �� the rec payments proto�col is called to process this information together with the bank� �This recoveryis of course only performed in case the payment is interrupted�� This mech�anism requires that the following information is available at the next reset

�after interruption of a payment��

�� D and i corresponding to the cheque used in the interrupted payment�They identify the cheque used� and enable to reconstruct the observer�spart�� These are automatically saved� since a cheque is stored in stablestorage� 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 apointer to this cheque in stable storage�

�� The amount� currency and date of the interrupted payment� These aresaved explicitly in stable storage� as explained above�

�� transfer

A user can transfer value from his � wallet to his a�liated � wallet by means ofthe transfer protocol� The description of this protocol is given in Section �� of the � protocols�

� �


Observer Purse Tillcu tbl valid cheque available get cheque �D� i

cheque available determine pay to�pay fro� cu to�cu fro� pay type

pay to�

�max pay�cu to

��


date��

��i� D

��i�� f�� gfread min dist � Dgdisplay payee�s infoEbal � 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�

��


date��j � �� i

Ebal � suitablebalance

Ebal�

� pay fro

pay fro unlocked regenerate ��

�� g��h��

�� g��h��

�� g��c mod p�� p��c mod pmark cheque asspent i times

j � � � i

regenerate ��

��

�

��

��j � ��i� ��

mark cheque asspent i times

�� g��

��h��

��

�� g��

��h��

��

c� � H��c� � H��

�� H�� Ddp mod Np

��

� mod q

� mod p

��

� mod q

� mod p

H�� D��

��ep mod Np

�� mod q

��

�� mod p

�� i��

�

�� mod pa� Gr

cPcc mod p


c�� H�c�� c�� a� ab��

��

i� c� r� cj ��i� ��

Figure �� payment �part ��

� �


Observer Purse Till


��RZZNphone

�T � ��T

� mod NphonehT �H��T t� T


��RZZNphone

T � �T

� mod NphoneEpayp � pay fro

store date

set pay busyp

��

�� mod pa� Gr

cPcc mod p


ci � H��i

c�� H�c�� c�� a� ab� ��

��RZZ��

��

��

��

��hT

��

��T

��if pay type � phone payment

�T � �T T mod Nphonem�H��i� �� pay to�pay fro� cu to� cu fro� IDP �pay type� date� �� T

��

�ss �m��i mod q��

�

� �m��i mod qEpay � pay fro

store date


tck cnt � �set pay busy


tck cntp � �

��T � �

�

��

��


hT�� H��T

�T � �T T mod Nphonem�H��i� �� pay to�pay fro� cu to� cu fro� IDP �pay type� date� �� T

�� m��i mod q�� m��i mod q

g��h��

�m�i �mod p

��T � ��


t� T

� � �T

m�H��i� �� pay to�pay fro� cu to� cu fro� IDP �pay type� date� �� T

g��h��

�m�i �mod p


t� T � � � �Tif pay type � phone payment do phone�ticks

��OK�





reset pay busyp

store deposit record

��OK�





reset pay busy

Figure �� payment �part ��

� �


Observer Purse Till

��

�T � t� n pay to�

�max pay�cu to

t�

� n

t� t� n

��ticks� n��

ticks� n��

t�

� n

t� t� n

� � ��t

� mod Nphone�tck cnt � n Epayunlocked

Ebal�

��tck cnt � n Epay

tck cnt � tck cnt � n

store n

t�

� n

t� t� n

� �t

� mod Nphone�tck cntp � n Epaypunlocked

Ebalp�

��tck cntp�nEpayp

��

��tck cntp � tck cntp � n

� � � mod p

��

n

�mod Nphone

��

��

��

n

�mod Nphone

Figure �� payment �phone ticks�� pay n phone ticks costing Epay each

� �


�� unlock amt

Observer Purse

get PIN and amount U to beunlocked from user

��PIN � U

��if U � unlocked

verify PIN

unlocked � U

unlocked � U

Figure �� unlock amt� unlocking an amount on the wallet

The unlock amt protocol unlocks a user�speci�ed amount unlocked in thewallet� It works as in the ��system except that it is now done locally �seeFigure ��

�� update

The update protocol updates the public keys of the issuer in the wallet� For anexplanation of the mechanisms� see Part VI� The protocol consists of two parts�that may be executed separately and independently� The �rst part updates theissuer�s authentication key Pa� This part is given in Figure �� The secondpart updates the issuer�s cheque�signing key Pc and the related wallet chequekey pc� This part is given in Figure �� In both protocols a �nal message�OK� indicates that the observer has received the keys� If the purse does notget this acknowledgment the protocol is repeated�

Updating Pc requires the identity of the user� Before the wallet is willing tosend this� the issuer must identify itself� As this is done for privacy reasons onlythe observer doesn�t need to check this identi�cation� Remark that the observerdoesn�t need Pc� and hence this key and its certi�cate are not forwarded to theobserver� The randomized signature on pc guarantees that the keys Pa and pcinstalled in the observer are issued by the same issuer�

To ensure that the �nal parts of these update protocols between observerand 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 tem�porarily stored by the purse� Note that if� e�g�� updateP a is interrupted beforethe observer has stored the new value for Pa� then this will be detected duringthe next reset when get info is executed�

�� get certif

The get certif protocol is given in Figure �� For an explanation of themechanisms� we refer to Part VI� The purse sends the keys and certi�cates

� �

CAFE Final Report Volume II �� get certif

Observer Purse

Reload�Recovery

station

vB�a�wallet��

�

vB�a�issuer�

��

Pa� vB�a�

Ea� CPa��

Verify certi�cateCPa with validityperiod Ea usingpublic key�mN � eN �

store vB�a� Pa� Ea� CPa

��

Pa� vB�a�

Ea� CPa��

Verify certi�cateCPa with validityperiod Ea usingpublic key�mN � eN �

store vB�a and Pa

��OK��

Figure �� updateP a� updating Pa

� �



mu�RZZq

�mu

��

vB�c�wallet�

vB�c�issuerwu�RZZ

�

q

au � gwu mod pcu �H�mu� � � auru � wu�cuSa mod q

��cu� ru

��au � gruPa

cu mod p

cu�� H�mu� � � au

�IDs

��retrieve ps corr� toIDs

gc � psh mod ppc � gScc mod pstore gc and pcwv�RZZ

�

q

��av

�� av � gwv mod p

uv�RZZ�

q

av � auvv mod p

�uv

�� uv�

�� mod qwv � wvuv mod qav � auvv mod pcv �H�vB�c� � � pc� av

rv � wv� cvSa mod q

��

Pc� vB�c�

Ec� CPc � pc� rv��

Verify certi�cate CPc

with validity periodEc using public key�mN � eN

cv �H�vB�c� � � pc� av

av�� grvPa

cv mod pstore vB�c� Pc� CPc � pc� cv� rvmin dist � dist � �

��

vB�c�pc� cv� rv��

av � grvPacv mod p

cv��H�vB�c� � � pc� av

store vB�c� pcmin dist � dist � �

��OK�

��

Figure �� updateP c� updating Pc

�

CAFE Final Report Volume II �� rec payments

Purse Till

�IDB � vB�c� unknown �

��IDB unknown��

�Pc� CPc � IDN�KCC� vN��

if �IDN�KCC� vN � unknown then

��IDN�KCC unknown��

��mN � eN � CKN

� vC��

Verify certi�cate CKNusing public key

�mC � eC�Check validity period of �mN � eN�

end ifVerify certi�cate CPc using public key �mN � eN �Check validity period of Pc

Figure �� get certif� retrieving Pc from the purse

needed in a payment to the till� The till veri�es these exactly as in the ��system� This protocol does not involve the observer�

�� rec payments

The rec payments protocol� shown in Figure �� recovers failed payments�By the properties of reset the purse and observer have the same informationabout these payments� If one of the executions fails� reset must be executedbefore another attempt is made �in order to restore the consistency��

The protocol is executed by the wallet and the issuer�s reload station� Itis repeated as long as the wallet contains failed payments that have to berecovered� The issuer must limit this number to its estimate of the number ofpossible payments� Moreover� if a wallet has too many failed payments� theissuer may decide to revoke it and issue a new one to the user�

Due to the reset protocol� the observer balance has been decreased� evenin case of a failed payment� The rec payments protocol must forward theinformation 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 time�span after the date recorded in the payment� the user of the wallet is creditedon his bank account for the amount in the payment� This is allowed� becauseobviously the payment failed for the payee too�

The protocol just makes the observer sign all necessary data �by the specialblinding or �� the observer knows that it signs the correct data�� The bank sub�sequently signs an acknowledgement� Finally� the wallet releases the memoryused for the data�

�


Observer Purse Reload stationsearch failed payment�D� i� Epay � tck cnt �pay type � cu fro� date

regenerate �� from D

�� g��c mod p �� D� i��

�

�� f�� g mod psearch failed payment�D� i� Epay � tck cnt �pay type � cu fro� date

�� H�� Ddp mod Np��

��H�� D

��

ep mod Np

�� mod q

��

�� mod p

�� mod q

��

�� mod p

wp�RZZ�

q

ap � gwp mod p �ap

��

up�

�� mod qwp � wpup mod qap � a

upp mod p

cp �H�� i� Epay �pay type� tck cnt �cu fro� date � � � ap

rp � wp � cpss mod q

��up

��up�RZZ�

q

ap � aupp mod p

�rp

��cp �H�� i� Epay �pay type� tck cnt �cu fro� date � � � ap

ap�� grpps

cp mod p

�

�� i� Epay �pay type� tck cnt �

cu fro� date�cp� rp

��ap � grpps

cp mod p

cp�� H�� i� Epay �pay type� tck cnt �cu fro� date � � � ap

submit failed payment toclearing for recovery

wk�RZZ�

q

��ak

��ak � gwk mod p

uk�RZZ�

q

ak � aukk mod p

�uk

��uk�

�� mod qwk � wkuk mod qak � a

ukk mod p

ck � H�cp� � � akrk � wk � ckSa mod q

��rk

��ck �H�cp� � � ak

ak�� grkPa

ck mod pset rem pay

��ck� rk

��ak � grkPack mod p

ck�� H�cp� � � ak

nr fail pay � nr fail pay � �remove payment

��OK�

��nr fail pay � nr fail pay � �remove paymentreset rem pay

Figure �� rec payments

��


�� recovery

Observer Purse Recovery station

obtain IDs of lostwallet from user

retrieve S�NS for thiswallet

��S�NS

��store S� NS

read dp from user

reset recovery done

not recovery done mq�RZZ

�

q

retrieve snapshot� ep�Np for this wallet

wallet recovered

�mq

�� mq

��wq�RZZ

�

q

��aq

��aq � gwq mod p

uq�RZZ�

q

aq � auqq mod p

�uq

��uq�

�� mod qwq � wquq mod qaq � a

uqq mod p

cq �H�mq�min dist �max dist �nr wrap� ep� � � Np�gc� aq

rq � wq � cqSa mod q

��

min dist �max dist �nr wrap�ep� Np�gc� rq

��cq �H�mq� min dist �max dist � nr wrap�ep� � � Np� gc� aq

aq�� grqPa

cq mod p

��

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

aq � grqPacq mod p

cq�� H�mq� min dist �max dist � nr wrap�ep� � � Np� gc� aqset recovery done

dist � min dist � �

S � S��nr wrap�dist

mod NS

ps � gch�� mod p

dist � min dist � �dist � min dist � �

Figure �� recovery �part �� recovering lost�broken wallet

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

��



loop� all cheques loop� all cheques loop� all cheques

dist� max dist

�mod �dist �dist � � mod �

regenerate ��RZZ�

q

�� g��c mod p

dist� max dist


dist� max dist


��

��

��

�� f�� g mod p

�� H�� distdp

modNp

��

��

H�� dist��

��ep� mod Np

�� mod q

��

�� mod p

�� mod q

��

�� mod p

w��RZZ�

q

a� � gw� mod p �a�

��

u��

�� mod qw� � w�u� mod qa� � au�� mod pc� � H�rq� dist � � �� a�

r� � w�� c�ss mod q

��u�

��u��RZZ�

q

a� � au�� mod p

�r�

��c� �H�rq� dist � � �� a�

a�� gr�ps

c� mod p

�� c�� r��

a� � gr�psc� mod p

c��H�rq� dist � � � �� a�

store ��endloop endloop endloop

remove S and NS

credit �part of value incu tbl from snapshotto user

submit all stored ��to clearing

set wallet recovered

Figure �� recovery �part �� submitting recovered cheques to clearing

��

CAFE Final Report Volume II �� deposit

protocol also works in case only the observer breaks down� If only the pursebreaks down it is probably easiest to just use the protocol as if both parts mustbe recovered�

The new wallet re�generates all cheques that might have been generated dur�ing the last withdrawal session� It then signs the data relevant to the bank fordetermining 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 sys�tem to recognise these cheques� so that the bank can be noti�ed how much wasspent 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 mustrun authenticate in order to tell the bank how much money it has receivedfrom 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 therecovery seed S and modulus NS as stored with the user�s bank account atinitialization in the recovery observer prior to installation of the latter in therecovery wallet� Next� the recovery purse reads the secret RSA�exponent dpfrom 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 samesystem parameters as the old one� That is� it must have the same versionnumber v�� The wallet �i�e�� observer and purse� must have a valid bank au�thentication key Pa� If this is not the case� the update protocol updateP a isexecuted �see also Section �� The version of all other parameters �vB�c mostnotably� are inconsequential in this protocol�

There is no need to randomise the initial challenge� mq� as the new observerhas no information to leak�

If this protocol is interrupted� it is probably easiest to just restart the entireprocedure�

�� deposit

The deposit protocol has not been changed with respect to that of Section ��It is included for completeness in Figure �� For a complete speci�cation� seePart V�

��


Till Acquire station

�

IDP � ID�

B � IDB �v�� vB�c�

i� �� i� ��r� c� cj �

pay to� pay fro� tck cnt �cu to� cu fro� pay type� date�

�� T � ��

��retrieve parameters corr� to IDB � v��vB�c

parameters still valid deposit timely used rate valid

tck cnt pay to�

� max pay�cu to

��

�� mod pa� Gr

cPcc mod p


ci �H��i

c�� H�c�� c�� a� ab� ��


��tck cnt �

� �T �mod Nphone

m�H��i� �� pay to� pay fro�cu to� cu fro� IDP � pay type� date�� T

g��h��

�m�i �mod p

submit �IDp�m to double�depositcheck

credit tck cnt pay to to account ofIDP at bank ID �

B

submit �i� �� to double�spendingcheck

Figure �� deposit� depositing one payment

��


Appendix A

List of Identi�ers in the �

Protocols

identi�er nr of bytes meaning

�system parameters� keys� ID�s�p� q �� large primes such that q j p� �g� h �� generatorsGc� gc� pc �� generators used for chequesps� ss �� key pair of � walletpo� so �� key pair of � �mother� walletPa� Sa �� bank�s authentication key pairPc� Sc �� bank�s cheque issuing key pairNphone �� modulus used in phone tick payments

mC � eC � dC �� central certi�cation centre�s keys� eC � �mN � eN � dN �� realm certi�cation centre�s keys� eN � �IDs� IDB � IDP �� identities of � wallet� issuer� tillIDN�KCC� IDC�KCC �� identities of realm and central key certi�cation centres

�version numbers �see Part VI��v� � of system parameters p� q� g� h� Gc� NphonevB�a � of bank�s authentication key setvB�c � of bank�s cheque issuing key setvC � of central certi�cation centre�s key setvN � of realm certi�cation centre�s key set

�PRSG�NS �� modulus for the � wallet�s PRSGS� S� �� seeds for the � wallet�s PRSGmin dist � index of oldest �partly� unspent cheque �cf� ��nr wrap � number of times min dist wrapped aroundD � index of cheque currently used or loadeddist � index of last generated cheque �cf� ��max dist � upper bound on dist �cf� ��hash seed �� hash of seed�s S initial value and of NS

��

Appendix A� List of Identiers in the � Protocols CAFE Final Report Volume II


�reset�pay busy � !ag� is a payment going on�pay type � indicates type of paymentnr fail pay � number of failed paymentstck cnt � number of phone ticksEbal � balance� see ��max bal � maximal allowable balance� see �� Epay � amount payable� see ��unlocked � unlocked amount� see ��

�authenticate�mb �� random number selected by � walletwb� ab� cb� rb �� signature by bank using Sa on �mb� ��PIN � PIN entered by the userseq no � number of transactions at the bankcu tbl � �max curr currency table� see ��cu tbl valid � !ag� the validity of cu tbl

trans � the total amount transferred by transfer

state �� max curr �seq no� cu tbl valid � trans � min dist �dist � nr fail pay � �� cu tbl�

ws� as� cs� rs �� signature by � wallet using ss on �cb� state� ��wallet recovered � !ag� has � wallet already been recovered�

�write cu tbl�wr� ar� cr� rr �� signature by bank using Sa on �seq no� IDs�

�cu tbl�� wz � az� cz� rz �� signature by � wallet using ss on �seq no� cu tbl ��

��ww� aw� cw� rw �� signature by bank using Sa on �cz� cu tbl ��

max dist � ��

�gen cheque�w�� a�� b�� c�� r� �� two signatures on a cheque by bank using bases

�Gc� gc� and secret key Sc�� secret cheque keys corresp� to �� secret cheque keys corresp� to �� secret cheque key corresp� to �� u� v �� random numbers that blind c and r

�� "spendable cheque

�� part of signature on a cheque �� Sc�c�� c� �� hash values of �� a� b�� c� r �� blinded versions of �a�� b�� c�� r�

��

CAFE Final Report Volume II List of Identiers in the � Protocols


�show currencies�payments � number of possible payments by � wallet

�payment�pay to � amount payable in payee�s currencypay fro � amount payable in payer�s currencycu to � ISO code for the payee�s currencycu fro � ISO code for the payer�s currencypay type � indicates type of paymentdate � datemax pay�cu� � maximum allowed amount payable for currency cu

i � indicates ith spending of chequej � complement of i �j � �� i��i �� part of cheque used in ith spending��j �� part of cheque not used in ith spendingci �� hash value of ��icj �� hash value of ��j� � random input for challenge mm� �� one"time signature on �� i�max curr � maximum number of currencies in the � walletphone payment � value of pay type that indicates a phone tick paymentNphone �� modulus for one"way function

� �� T �� See ��T � maximum number of phone ticks per paymentt � See ��n � number of ticks paid at once� cf� ��

�transfer�transo � the cumul� amount transferred by transfer as stored

in the �mother� � observertransp � trans of �mother� � pursetranss � trans of �daughter� � walletmax trans � upper bound to trans

Xfer � value transferred in transfer

trans logo �� logging of transfer of � observer� �y�Xfer� or trans logp �� logging of transfer of � purse� �y�Xfer� or trans logs �� logging of transfer of � wallet� x or mt �� challenge

��

Appendix A� List of Identiers in the � Protocols CAFE Final Report Volume II


y �� commitment by � walletx �� value committed to by � wallet �y � H�x��wt� at� ct� rt �� signature by � observer using so on �mt� Xfer � ��wa� aa� ca� ra �� signature by � wallet using ss on �ct� y� ��wi� ai� ci� ri �� signature by � observer using so on �ca� ��

�unlock amt�unlocked � unlocked amount� see ��U � proposal for new unlocked "value

�update�CPa �� certi�cate of PaEa � validity period of Pa

mu �� random number selected by � walletwu� au� cu� ru �� signature by bank using Sa on �mu� ��CPc �� certi�cate of PcEc � validity period of Pc and pcwv � av� cv � rv �� signature by bank using Sa on �vB�c� �� pc�

�get certif�CKN

�� certi�cate on realm certi�cation centre�s key set by cen"tral certi�cation centre

�rec payments�wp� ap� cp� rp �� signature by � wallet using ss on �� i� Epay � pay type�

tck cnt � cu fro� date� ��wk� ak� ck� rk �� signature by bank using Sa on �cp� ��

�recovery�recovery done � !ag� has a recovery taken place�mq �� random number selected by � walletwq � aq � cq� rq �� signature by bank using Sa on �mq� hash seed � min dist �

max dist � nr wrap� �� gc�w� � a�� c�� r� �� signature by � wallet using ss on �rq � dist � ��

��


Appendix B

List of Identi�ers in the �

Protocols


�system parameters� keys� ID�s�p� q �� large primes such that q j p� �g� h �� generatorsGc� gc� pc �� generators used for chequesps� ss �� key pair of observerNp� ep� dp �� RSA modulus and key pair of pursePa� Sa �� bank�s authentication key pairPc� Sc �� bank�s cheque issuing key pairNphone �� RSA modulus for phone tick payments

mC � eC � dC �� central certi�cation centre�s keys� eC � �mN � eN � dN �� realm certi�cation centre�s keys� eN � �IDs� IDB � IDP �� identities of wallet� issuer� tillIDN�KCC� IDC�KCC �� identities of realm and central key certi�cation centres

�version numbers �see Part VI��v� � of system parameters p� q� g� h� Gc� NphonevB�a � of bank�s authentication key setvB�c � of bank�s cheque issuing key setvC � of central certi�cation centre�s key setvN � of realm certi�cation centre�s key set

�PRSG�NS �� modulus for the observer�s PRSGS� S� �� seeds for the observer�s PRSGmin dist � index of oldest �partly� unspent cheque �cf� ��nr wrap � number of times min dist wrapped aroundD � index of cheque currently used or loadeddist � index of last generated cheque �cf� ��max dist � upper bound on dist �cf� ��

��

Appendix B� List of Identiers in the � Protocols CAFE Final Report Volume II


�reset�pay busy � !ag� is a payment going on�pay type � indicates type of paymentnr fail pay � number of failed paymentstck cnt � number of phone tickstck cntp � number of phone ticks as recorded by purseEbal � balance� see ��max bal � maximal allowable balance� see �� Epay � amount payable� see ��unlocked � unlocked amount� see ��rem pay � !ag� a payment is being removed� see ��

�authenticate�wb� ab� ub� cb� rb �� randomized signature by bank using Sa on the

empty messagePIN � PIN entered by the userseq no � number of transactions at the bankcu tbl � �max curr currency table� see ��cu tbl valid � !ag� the validity of cu tbl

trans � the total amount transferred by transfer

state �� max curr �seq no� cu tbl valid � trans � min dist �dist � nr fail pay � �� cu tbl�

ws� as� us� cs� rs �� randomized signature by observer using ss on�cb� state� ��

wallet recovered � !ag� has wallet been recovered�

�write cu tbl�wr� ar� ur� cr� rr �� randomized signature by bank using Sa on

�seq no� IDs� �cu tbl�� wz � az� uz� cz� rz �� randomized signature by observer using ss on

�seq no� cu tbl �� ww� aw� uw� cw� rw �� randomized signature by bank using Sa on �cz�

cu tbl �� max dist � ��

�gen cheque�w�� a�� b�� c�� r� �� two signatures on a cheque by bank using bases

�Gc� gc� and secret key Sc�� secret cheque keys of observer corresp� to �� secret cheque keys of observer corresp� to ��

��

�� blinding by purse of ��

��

�� blinding by purse of �� blinding by purse of �� u� v �� random numbers that blind c and r

�� "spendable cheque

�� part of signature on a cheque �� Sc�

��

CAFE Final Report Volume II List of Identiers in the � Protocols


c�� c� �� hash values of �� a� b�� c� r �� blinded versions of �a�� b�� c�� r�

�show currencies�payments � number of possible payments by observerpaymentsp � number of possible payments as recorded by purse

�payment�pay to � amount payable in payee�s currencypay fro � amount payable in payer�s currencycu to � ISO code for the payee�s currencycu fro � ISO code for the payer�s currencypay type � indicates type of paymentdate � datemax pay�cu� � maximum allowed amount payable for currency cu

i � indicates ith spending of chequej � complement of i �j � �� i��i �� part of cheque used in ith spending��j �� part of cheque not used in ith spendingci �� hash value of ��icj �� hash value of ��j� � random input for challenge mm� �� fail"stop signature on �� i��

�

� �� observer�s contribution to fail"stop signaturemax curr � maximum number of currencies in the walletphone payment � value of pay type that indicates a phone tick paymentNphone �� modulus for one"way function

� �� T �� See �� T �� See ��T � maximum number of phone ticks per paymentt � See ��n � number of ticks paid at once� cf� ��

�transfer�transo � the cumul� amount transferred by transfer as stored

in the �mother� � observertransp � trans of �mother� � pursetranss � trans of �daughter� � walletmax trans � upper bound to trans

Xfer � value transferred in transfer

trans logo �� logging of transfer of observer� �y�Xfer� or trans logp �� logging of transfer of purse� �y�Xfer � or trans logs �� logging of transfer of � wallet� x or

��

Appendix B� List of Identiers in the � Protocols CAFE Final Report Volume II


mt �� challengey �� commitment by � walletx �� value committed to by � wallet �y � H�x��wt� at� ct� rt �� signature by observer using so on �mt� Xfer � ��wa� aa� ca� ra �� signature by � wallet using ss on �ct� y� ��wi� ai� ci� ri �� signature by observer using so on �ca� ��

�unlock amt�unlocked � unlocked amount� see ��U � proposal for new unlocked "value

�update�CPa �� certi�cate of PaEa � validity period of Pa

mu �� random number selected by pursewu� au� cu� ru �� signature by bank using Sa on �mu� ��CPc �� certi�cate of PcEc � validity period of Pc and pcwv � av� uv� cv� rv �� randomized signature by bank using Sa on �vB�c�

�� pc�

�get certif�CKN

�� certi�cate on realm certi�cation centre�s key setby central certi�cation centre

�rec payments�wp� ap� up� cp� rp �� randomized signature by observer using ss on ��

i� Epay � pay type� tck cnt � cu fro� date� ��wk� ak� uk� ck� rk �� randomized signature by bank using Sa on �cp�

��

�recovery�recovery done � !ag� has a recovery taken place�mq �� random number selected by observerwq � aq � uq� cq� rq �� randomized signature by bank using Sa on �mq�

min dist � max dist � nr wrap� ep� �� Np� gc�w� � a�� u�� c�� r� �� randomized signature by observer using ss on �rq �

dist � ��

��


Part IV

Security Evaluation

��


Chapter ��

Security Evaluation of Basic

Primitives

The application of digital signatures� and in particular blind signatures� is cen�tral to the proposed payment systems� This section analyses these signatureschemes as well as other cryptographic primitives which are used� More pre�cisely� 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 certi�cates and in the � protocols forunique 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� wherethe security depends on the discrete logarithm assumption� are analysed �the�rst three in the above list�� then the following three are investigated in asection dealing with the factoring assumption and �nally the security of thehash function is discussed�

� �� Discrete Logarithms

This section �rst considers the di�culty of computing discrete logarithms andthen the three primitives based on this problem are analysed�

� �� The Discrete Logarithm Assumption

Let p be a prime and let g� be a generator of ZZ�p� The discrete logarithm

assumption �DLA� says that it is hard� to invert the mapping�

f � �� p� �g � ZZ�p given by x �� gx� �

�Here and in Section �� hard� means that no algorithm can solve the problem withnon�negligible probability in polynomial time in the length of the input numbers�

��

Chapter � � Security Evaluation of Basic Primitives CAFE Final Report Volume II

The problem of inverting this function will be called the discrete logarithm pro�

blem �DLP�� The certi�ed discrete logarithm assumption �CDLA� says thatthis problem remains hard if the factorisation of p � � is also given as input�this problem will be denoted CDLP��

As we shall see both of these assumptions require that p � � has a largeprime factor�

We need another assumption� which in the following will be called the specialdiscrete logarithm assumption �SDLA�� Let q be a publicly known� large primedividing p�� and let g generate the subgroup of ZZ�p of order q�

� The assumptionsays that it is hard to solve the special discrete logarithm problem �SDLP��namely inverting the mapping

f � �� q � �g ��g� given by x �� gx�

Relation Between these Problems

Consider the SDLP� Usually q will be the largest prime dividing p � � andin that case the factorisation of p � � can often be computed relatively easy�Therefore when solving an instance of SDLP it can in most cases be assumedthat the complete factorisation of p � � is given� SDLP is in such cases notharder than CDLP which again is not harder than DLP�

Next� solving CDLP is not harder than solving SDLP for each prime factorp� � �since the solutions for each subgroup can be combined�� Hence� assump�tion CDLA implies that at least for some prime factors of p � � is SDLP ahard problem� and if q is a su�ciently large prime factor of p � �� SDLA isreasonable�

Finally� in most cases �depending on the distribution� it is easy to factorp � �� and in these cases CDLA is obviously equivalent to DLA� There areexceptions to this however� Brickell and McCurley present in �BM�� an identi��cation scheme based on arithmetic modulo a prime� p� for which p� � is hardto factor�

The Di�e Hellman Assumption

Di�e and Hellman were the �rst to use the discrete logarithm assumption �in�DH�� More� precisely� they needed the following assumption�

Given p� g�� gx� and h ��g�� it is hard to �nd hx�

This is a stronger assumption than DLA� For primes p for which the factorisa�tion of ��p�� contains only small prime factors �� is Euler�s totient function�this assumption is equivalent to DLA �see �Boe �� In �Mau�� this proof wasgeneralised to a larger class of primes� but in general it is not known whetherthe two assumptions are equivalent� In the payment systems we need the cor�responding assumption in �g��

Given p� q� g� gx and h ��g� it is hard to �nd hx�

�In this chapter g� will be assumed to generate ZZ�p� while g will generate the subgroupg� of known prime order� q�

��

CAFE Final Report Volume II � �� Discrete Logarithms

We shall not discuss this assumption further� as it can be considered reasonableunder assumption SDLA�

Algorithms for Solving DLP

In this section� the most e�cient� published algorithms for computing discretelogarithms �solving DLP� are brie�y reviewed� This is based on the surveys�McC � and �Roo�� 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 abovementioned reports contain some details plus references to the full descriptions�Table � �� summarises the e�ciency of these algorithms in terms of runningtime �most of the algorithms also need a lot of storage�� The Pohlig�Hellmanalgorithm and the index�calculus method consist of a pre�processing phase �ac�tually two stages in ICM� used to generate information �only depending on pand g�� and an actual computation phase which given h outputs x such thath ! gx� �

This table shows why p� � must have at least one large prime factor �oth�erwise the Pohlig�Hellman algorithm would be e�cient��

It is concluded in �Roo�� that these algorithms are not able to solve DLPfor primes of length �� bits in reasonable time� and systems based on suchprimes will be secure against these algorithms in the near future� However�more e�cient algorithms might be possible� E�g�� if it is possible to adapt thenumber �eld sieve method for factoring� an algorithm with �heuristic� runningtime

expc�ln p��ln ln p��

can be expected� Therefore� to obtain long term security� Odlyzko and LaMac�chia suggest using primes of length � �� see �LO��

Solving SDLP

No special algorithm for solving SDLP is published in the open literature� Ob�viously� the algorithms mentioned above solves SDLP� The interesting questionis� however� if it is possible to do better given that g generates a subgroup oforder q�

��


The giant�step� baby�step algorithm and Pollard�s algorithm depend onlyon the order of the group� Hence� the running time of these algorithms are ofthe order

pq log q� For q � ��

pq log q is around �� Since the asymptotic

running times given in Table � �� are reasonable for the large numbers used inCAFE� this indicates that these algorithms will not be feasible within the nextmany years �this also shows why q must be large��

The running time of the Pohlig�Hellman algorithm with n ! q is of the sameorder�

So the question remains whether the index calculus method� can be im�proved given that g generates a subgroup of order q� The basic idea of thismethod �in the general case� is to �nd during pre�processing the discrete log�arithms of the smallest primes with respect to g� �by generating a number ofequations and solving these�� In the computation phase the discrete logarithmof h is computed from these by factoring hge� �for random choices of e�� and thencombining the discrete logarithms found in the pre�processing phase accordingto this factorisation� This will give the required result if all prime factors aresmall� Very brie�y� the various algorithms di�er in the way the equations aregenerated in the pre�processing�

When trying to use this method in �g�� the �rst problem is that someof the primes are not in this group� It might be possible to get around thisproblem by raising the product to a suitable power �e�g�� p��

q ��

However� even if this is possible� it is not clear that the algorithms willrun faster� The running time depends on the size of the numbers �becausethis determines the probability that a random element has only �small� primedivisors�� But most of the elements of �g� will be as large as in the generalcase �i�e�� jpj�bits�� Thus for the moment we have no reason to believe that an

Algorithm Preprocessing Computation

Baby�giant�� On�� log n

Pollard�� O

n�� log n

Pohlig�Hellman�� O �

Plogn# prii log prii � O

Pci�log n# p��rii �� # log prii ��

ICM� Basic� L�p�

p��o�� L�p��

p��o��

ICM� Linear�� L�p��o�� L�p��o��

ICM� Gaussian�� L�p��o�� L�p��o��

ICM� Residue�� L�p��o�� L�p��o��

Notes� �� n denotes the order of the generator�� n ! pc�� pckk � � ri � � for i ! �� k� The sumsare over i�� Heuristic analysis of the complexity�� L�p� ! exp

�plnp ln ln p

�Table �� Asymptotic running time for DLP algorithms

��


adoption of the ICM will run signi�cantly faster on instances of SDLP than oninstances of DLP�

In conclusion we can say that SDLA is reasonable for the following reasons�

� An e�cient algorithm for solving SDLP would lead to an e�cient algo�rithms for DLP in many practical cases�

� No special algorithm solving SDLP has been published� and the existingalgorithms for DLP do not seem su�ciently e�cient to solve SDLP�

� Previously proposed systems relying on SDLA have not been broken �atleast not by solving SDLP�� and in particular the security of the DigitalSignature Standard proposed by NIST �see �DSS�� has received muchattention recently�

Finally� under SDLA it is reasonable to assume that the Di�e�Hellman problemis hard in subgroups of prime order�

� �� Security of Schnorr Signatures

The digital signatures used for identi�cation and signing updated currency ta�bles are from �Sch�� As these signatures are based on the �presumably secure�proof of knowledge shown in Figure �� see �Sch�� they can be assumed se�cure �in the sense of �GMR�� under SDLA if the hash function is collision�freeand also has some pseudo random properties� In Section � �� it is argued thatthe hash function used in CAFE� satis�es these properties� Thus� the followingassumption is reasonable�

Assumption �� The Schnorr signature scheme is secure against existential

forgery under adaptively chosen message attacks�

� �� The Blind Signature Scheme

The blind signature scheme must have two properties� First� it must be secureagainst forgeries and� second� the protocol for obtaining blind signatures mustnot 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 tothe bank encoded in the blind signature or using the blind signature protocolas a subliminal channel�

In the following only the basic blind signature protocol �as depicted in Fig�ure �� is discussed� For the application to the payment systems �in particularthe � system� we refer to Chapter and �

Security Against Forgeries

The signature scheme is based on the interactive proof of knowledge shown inFigure �� of S satisfying P ! gS and z ! mS �the basic proof�� The triple

��


�z� c� r� is a valid signature on m if

c ! H�m� z� grP c�mrzc��

The security of the signature scheme depends on the hash�function� whichmust be collision�resistant and have some pseudo�random properties �see also�FS��

Since the basic proof is secure in the same sense as that underlying theSchnorr signature scheme it is reasonable to make the following assumption inline with Assumption � ��

Assumption �� The hash�function� H� can be chosen such that the signa�

ture 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 su�cient for the security of the blind signaturescheme� since the bank is not only making signatures� it also interacts with theuser during this process�

Next it is argued that the bank does not reveal any usable information aboutits secret key allowing forgeries during the blind signature process�

Consider the modi�cation of the basic proof system in which the challenge�c� is chosen from a subset A � ZZq instead of ZZq� For any such subset anexecution of the modi�ed scheme can be simulated perfectly in expected timeO�jAj�� In particular this simulation is feasible if jAj is polynomial in jqj �givenz�� Since this holds for every subset A this shows that there is no particularbad challenge� which would enable the user to learn anything about the bank�ssecret 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 whichc � ZZq is chosen as challenge� the signer reveals no information but the factthat logg P equals logm z� In particular the signer does not reveal su�cientto allow a forger to make a new signature �and hence �nd S�� Until now wehave argued that the blind signature scheme is secure and that the interactiondoes not reveal information about the secret key� However� the interaction doesallow the user to obtain a signature on a blinded message� m� This raises twoquestions�

� Is the user able to blind m di�erently'

� Is it possible to obtain more than on signature during the blind signatureprotocol'

In order to answer these questions the following assumption is used�

Assumption �� 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 Sec�tion � �� and the fact that the basic proof is a proof of knowledge� it is infeasibleto make a signature �z� c� r� on m unless logg P ! logm z� The next assumptionanswers the two questions raised above�

��


Assumption �� The receiver can only obtain one signature in the blind sig�

nature protocol� This signature is on a message� m� of the form mt�g

t� � where

the receiver chooses t� t� � ZZq�

Why is this reasonable' First recall that �a�� b�� satis�es

a� ! gr�P c� and b� ! mr�� z

c��

Given a signature �z� c� r� on a message m and the messages �a�� b�� c�� r�� fromthe blind signature protocol we can de�ne u and v by

u ! c� c� and v ! r � r��

This pair �u� v� satis�es

a ! a�gvP u ! gw�v�Su

and hence b ! mw�v�Su� The only information Alice has about w when con�structing �a� b� is gw and mw

� � In order to construct �a� b� of this form and beable to �nd z ! mx� it is reasonable to assume that Alice chooses t� t� � ZZq�computes m as m ! mt

�gt� and then in the blind signature protocol �nds

a ! a�gvP u b ! �b�m

v�z

u� �

t at�

and z ! zt�Pt� �

These arguments also indicates that it does not help several users to executethe withdrawal simultaneously in order to get a signature on a message of adi�erent form� because each execution of the withdrawal uses an independentlychosen value of w�

Assuming that a receiver� Alice� can only obtain a blind signature in thisparticular way it also follows that she cannot obtain two blind signatures fromone execution of the protocol� Namely� suppose she can get a signature �zi� ci� ri�on mi for i ! �� Then� by the collision�resistance of H it can be assumedc� �! c�� Let �ui� vi�i�� be the �u� v��pair selected by Alice in the two cases�Then it is very likely that

c� � u� �! c� � u�

in which case it is presumably hard to get both signatures from one executionof the protocol�

Blinding Property

During the blind signature protocol the bank gets a view �see �GMR�� con�sisting of the random coins used� and the messages �a�� b�� c�� r�� The followingproposition shows that this view does not contain any information about theblinded message�signature pair�

Proposition �� Under Assumption �� the following holds� For every mes�

sage� m� and every possible signature �z� c� r� on m it is possible that this sig�

nature could correspond to a given view of the bank�

��


Proof� Let a view � � a�� b�� c�� r�� of the bank be given� where denotes therandom bits chosen by the bank� Given �m� z� c� r� we can de�ne

u ! c� c� mod q

v ! r � r� mod q

t ! logm�m

De�nea ! grP c mod p and b ! mrzc mod p�

All we have to show is that u� v� a and b satisfy�

z ! mt� a ! a�gvP u mod p and b ! �b�m

v�z

u� �

t mod p�

The requirement related to z is satis�ed due to Assumption � �� Since�

a� ! gr�P r� mod p

the second requirement follows from

a ! grP c ! gr��vP c��u ! a�gvP u�

The third requirement follows from similar rewritings� �

� �� 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 �� The ran�domisation is included to prevent the signer and receiver from using the signa�ture protocol as a subliminal channel�

Two aspects of randomisation are important� First� it should prevent thesubliminal channel as mentioned above� and� second� it should not make iteasier to forge signatures�

First� if �c� r� is a signature on the message m with respect to the generatorsg and P � the randomisation ensures that the number a ! grP s mod p is uni�formly distributed in �g�� Note� that even a signer with unlimited computingpower cannot enforce any other distribution of a� The numbers c and r areuniquely determined from m� a and the public key�

Second� since the security of the signature scheme depends on a being totallyrandom �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 non�uniform distribution by trying to guess some bits of w� However� this seems tobe just as hard as guessing some bits of the secret key�

� �� Primitives Using the Factoring Assumption

RSA signatures� the pseudo�random generator and the encoding of ticks are allbased on the intractability of factoring large integers� This assumption will bediscussed very brie�y �rst�

��

CAFE Final Report Volume II � �� Primitives Using the Factoring Assumption

� �� Factoring Assumption

As noted in Section � �� the index calculus method exploits the fact that it ispossible to factor integers with only small prime factors� However� no general�e�cient �polynomial time� algorithm is known for factoring integers with atleast two large prime factors� In particular� products of two large primes areconsidered among the hardest instances�

Let p and q denote two large primes� and let n ! pq be the product ofthese� E�cient algorithms are known for factoring� n� if p and q satisfy certainproperties� In order to avoid these it is suggested in �BBB�� to require that

� p and q be of approximately the same bit length� but the di�erence p� qshould not be less than ��

� p�� p#�� q�� and q#� all have a large prime factor �at least �� bits��

The choice of �� was made in �BBB�� as a threshold for what can be con�sidered possible today �and in the near future�� An integer satisfying theserequirements will therefore be called a RIPE�composite in the following�

Payment for phone ticks makes use of squaring modulo such composites� Inorder to make sure that this mapping has large order� �BBB�� requires that

� If rp and rq are large prime factors of p�� and q�� respectively� then bothrp� � and rq � � should have a large prime factor� tp and tq� respectively�such that the product tptq is at least �� and

��rp��tp �� mod rp and ��rq��tq �� 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 iscomputationally infeasible to �nd p and q�

The question remains how large n �and hence p and q� should be in this assump�tion� Since the �rst application of the factoring assumption �in �RSA�� it hasbeen assumed that �� bits �� digits� are su�cient for n� Due to hardwareconstraints� CAFE uses this length of modulus� but it must be expected that inthe very near future� it is necessary to use �� bits or� for long term security��

� �� RSA Signatures

RSA signatures are used in certi�cates and to ensure unique randomisation ofcheques in the � system �see gen cheque�� The security of RSA signatures hasnot been proven to follow from the intractability of factoring� but it is widelybelieved� that it is hard to forge RSA signatures �in combination with a suitablehash function� without factoring the modulus or breaking the hash function�

Hence� based on the factoring assumption it is reasonable to assume thatcerti�cates cannot be forged�

��


The application to randomisation requires that it is hard to compute thesecret RSA function� as argued above a reasonable assumption� and that thethis function is one�to�one� In Chapter �� it is shown how this propertycan be ensured�

� �� Oneway Function Encoding Phone Ticks

Let Nphone be a RIPE�composite of length �� bits� The function

f � ZZNphone� ZZNphone

given by f � x �� x� mod Nphone

is used to encode the amounts paid in phone ticks�Inverting this function is equivalent to factoring Nphone �see �Rab�� Thus

under the factoring assumption� this mapping is a one�way function�

� �� The PseudoRandom Generator

The pseudo�random generator depends on the infeasiblity of predicting thelast k bits of x given x� mod N � In �ACGS� it is shown that asymptoticallygiven x� mod N � the O�log� log�N� least signi�cant bits of x are simultaneouslysecure� This means that even if some of these bits are known it is hard to �nd therest 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 isunpredictable for this value of k�

� Backward unpredictable�Given f i��S� for some i it is hard to �nd Rj for � j � i� Thus� f i��S�can be revealed without compromising previously generated bits�

In CAFE k is chosen as k ! �� This gives more bits for each squaring thansuggested in �ACGS�� Based on work by Micali and Schnorr �see �MS��BBB�� argues that it is reasonable to assume that the k least signi�cant bitsof x are still simultaneously secure given x� mod N � Thus the pseudo�randomsequence is both forward and backward unpredictable�

� �� Security of the Hash Function

The hash function� H� is important for the security of the signature schemes�e�g�� see Assumption � �� and � �� As the function is a special mode ofRIPEMD �BBB�� the security properties of RIPEMD are described �rst� Itis then argued that H has the necessary properties�

� �� Security of RIPEMD

In �BBB�� the security of RIPEMD is investigated with respect to collision�resistance and statistical properties�

��

CAFE Final Report Volume II � �� Security of the Hash Function

Collision Resistance

RIPEMD is conjectured to be a one�way� collision resistant hash function�

�� Collision resistance� It is computationally infeasible to compute two dis�tinct messages M� and M� such RIPEMD�M�� ! RIPEMD�M��

�� One�way� It is computationally infeasible� given a message M to computea di�erent message M � such that RIPEMD�M �� ! RIPEMD�M��

Recent work by Dobbertin ��Dob�� has found collisions in two rounds of H�Although the above assumption is still reasonable� it will be necessary to con�sider alternatives toH� Prime candidates for this replacement are RIPEMD�� DBP�� and SHA�� SHS��

Statistical Evaluation

RIPEMD has been tested with respect to the following three properties�

�� The dependence of input and output bits of the function�

� Completeness� each output bit depends on all input bits �KD��

� Avalanche e�ect� for each input bit� a change of this single input bitchanges on average half of the output bits �Fei��

� Strict avalanche criterion� every output bit changes with probability�� whenever one input bit is changed �see �WT��

�� Possible linear relations between input and output bits of the function�

�� 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� failureof passing these tests would make it too weak for many applications �moreprecisely� �BBB�� investigates the basic building block of RIPEMD� calledcompress� but this analysis also gives information about RIPEMD��

Therefore we shall make the assumption that RIPEMD has the necessarypseudo�random properties�

� �� Security of H

Based on the assumption that RIPEMD satis�es the above mentioned propertiesit is argued that H also satis�es these� This justi�es the use of H in CAFE �inparticular that Assumption � �� and � �� are reasonable using H��

First� note that the catenation of the �fth output word EN is irrelevant forthe strength of H�

� any collision on the �rst four words AN to DN is by de�nition one on thecomplete output H�M�� and vice versa� This implies the equivalence of�nding collisions for H� or for H without the �fth output word EN �

��


� any pre�image to a ��tuple �AN � � � � �DN � is by de�nition a pre�image tothe corresponding ��tuple �AN � � � � � EN �� and vice versa� This implies theequivalence of �nding pre�images to H� or to H without the �fth outputword EN �

Therefore� the �fth word is from now on ignored in the evaluation� �The hashvalue is expanded to �� bits rather than just keeping �� bits for implemen�tation reasons only� it is felt that �� bits is su�cient for the security��

Next� note that the di�erent expansion has no in�uence on the statisticalproperties� since the compression function compress is not a�ected� �It is thisfunction that is submitted to the statistical tests��

Finally� we argue that the sole purpose of the use of the message lengthin the expansion of RIPEMD is �xing the length of the message� This is doneto avoid the �trivial� collisions found by appending part of the padding ofa message to a copy of this message � both may produce the same paddedmessage and consequently the same hash value� There is substantial evidence�cf� �Dam �� that collision resistance of the compression function �compress� issu�cient for collision resistance of the hash function built from it� apart fromthese 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� bythe design of the protocols such trivial collisions do not pose problems to thesecurity�

��


Chapter ��

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 require�ments are not mentioned explicitly� it is a basic requirement that all protocolscan be implemented su�ciently e�cient within acceptable waiting times� Forexample� generating and verifying a single tick payment must be �nished be�fore the next tick is due� whereas the recovery protocol has less demanding timeconstraints�

The security requirements are generally partitioned into requirement typesof availability� integrity� and privacy� The requirements are listed separately forthe bank� payer� and payee� The bank will represent both the role of issuer andaquirer�

The lists cover a wide range of plausible requirements� and should containat least all basic requirements� A requirement that is not explicitly listed herecan probably be reduced to a combination of some of the listed requirements�

The security analysis of the protocols with respect to the listed requirementsrelies on some general assumptions� such as tamper�resistance and trust rela�tions� These assumption are introduced informally in the next section� Ideally�we will also require that protocol interruption does not invalidate any of thelisted requirements� However� as will be clear from the security analysis� inter�ruptions can to some extent a�ect availability and privacy� but not integrity�

�� Assumptions

There is no special mechanism for enforcing availability� and hence the di�erentroles in a transaction must trust each other to be available� For integrity� eachrole trusts itself only� For privacy� the payer trusts the support of the pursepart of the wallet� but not the observer part�

It is assumed that the reload and acquire station of the bank� and the tillof the payee are reliable� This can be ensured by standard measures in theimplementations of the protocols� Furthermore� we assume that the walletonly have crash failures� This means that lower level error detection �e�g��error detecting coding� system self�checking� is su�cient for the purse never todeviate from its protocol� If it fails� it stops� We do not treat lower level faulttolerance measures� e�g�� attempts at tolerating communication errors on thedata link layer or fault�tolerant storage structures�those are a matter of theimplementation� The protocol measures start when the lower level measures

��

Chapter �� Security Requirements CAFE Final Report Volume II

are insu�cient� and of course� only then do we require that the purse stops ifit fails�

We also assume that �� and �� observer devices are tamper�resistant� Inparticular� unauthorized inspection or manipulation of the contents or function�ality of such devices� are assumed to be infeasible� Furthermore� the followingassumption is needed to guarantee privacy in the � system� All � wallets exe�cute the protocols as speci�ed�

�� Bank�s Requirements

The bank requires at least the following�

�� Authenticity of cheques�� In the deposit protocol� the acquirer will onlyaccept cheques that have been correctly issued�

�� Limitation on value� It is impossible to change max pay�cu� �in de�posit the acquirer will only accept an amount a in currency cu if a �max pay�cu��

�� Conservation of value� If the payee deposits an amount received on acheque c� then a unique payment transaction has been executed where cwas used to pay this amount�

�� Correctness of exchange rates� The payee can only deposit a cheque tothe exchange rate validated by the acquirer�

�� No double deposits� The acquirer will accept at most one deposit trans�action of the same cheque �i�e�� the amount received in a given cheque willbe credited at most once��

�� Strong integrity� Assume the observer is tamper�resistant� A payment isonly possible� if the currency table is valid� and the payee only receives themoney if the currency table is debited appropriately� Similar should holdin the transfer from a � wallet to an � wallet� In withdrawal �transfer� ofa units� the observer increases the corresponding balance in the currencytable by a and not more� The cooperation of the observer is necessary inpayment and transfer� and it must be impossible to coerce the observerinto getting a negative value of the balances in the table �thus strongintegrity of the ��system requires that the observer in wallets is tamper�resistant��

�� Forger identi�cation� If a cheque is used in two di�erent payments� theissuer must be able to prove the identity of the payer� if both cheques aredeposited� A payer should not be able to disavow such a claim�

�Recall that a two�spendable cheque actually contains two cheques �which share some at�tributes� e�g�� the signature from the issuer� To avoid confusion �cheque� will in the followingmean one part of a two�spendable cheque�

��

CAFE Final Report Volume II �� Payer�s Requirements

� �Strong integrity during recovery� If the observers are tamper�resistant�then �by the recovery protocol� a payer cannot recover more moneythan what actually remained in the wallet� Furthermore� in the recoveryof interrupted payments the payer can only get back the amount paid ifthe payee does not deposit it�

� �Fall back integrity during recovery� The payer cannot recover �by therecovery transaction� more money than the total balance after the lastsuccessful withdrawal� Furthermore� in recovery of an interrupted pay�ment transaction the payer can at most get back the maximal value ofthe cheque�

As long as the assumption of tamper resistance is not broken requirements �and � together ensure that whenever the bank accepts a cheque� the correspond�ing amount must previously have been withdrawn from an account�

�� Payer�s Requirements

We �rst list some requirements with respect to availability� These requirementsare clearly met by the protocols�and therefore not considered in the analysislater on� except for a discussion on the resilience against interruptions�

� �Withdrawal availability� It is possible to withdraw money if the payer�saccount contains su�cient money and the maximum of the wallet has notbeen reached�

� �Exchange availability� During the withdrawal� it is possible to transfervalue from one currency balance to another� If a balance is zero this entrycan be replaced by another currency type�

� �Transfer availability� The payer can at any given time transfer any amountfrom the wallet to an a�liated smart card� The balance of the receivershould increase by exactly this amount�

� �Availability of recovery� Interruption of a protocol must not result in aloss of money for the payer� Furthermore� if the wallet is lost� stolen� ormalfunctioning� the payer can recover the money contained in the wallet�

� �Fungibility� As the maximum number of payments is clearly limited tothe number of available cheques� only a limited type of fungibility appliesto the CAFE protocols� for some parameter k� determined at withdrawal�a payer can make any �nite sequence of k payments of amounts in anycurrency� as long as the respective balances are not exhausted� and aslong as max pay�cu� is not exceeded for any currency cu�

In addition� a payer requires at least the following of the payment system�

�� Authorisation of transactions� No money can be withdrawn from heraccount without the cooperation of the payer� In case of dispute the issuermust supply a proof that the payer acknowledged a given withdrawal� The

��

Chapter �� Security Requirements CAFE Final Report Volume II

issuer cannot make a proof without the cooperation of the payer� Moregenerally� any change of amount of money in the wallet should be matchedby a corresponding change �debit credit� of the payer�s account� Similarly�exchange only takes place if the payer acknowledges the currencies� ratesand amounts� Payment and transfer transactions also need some form ofauthorisation� That is� to spend money withdrawn by a payer� it mustbe necessary to know some secret information� so that the payer�s moneycannot be spent by other� Two types of protection can be distinguished�

�a� Some �secret� information stored in the observer is needed in orderto 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 �allow�ing the observer to spend a cheque and or decrease the balance��

Furthermore� the decrease of the balance should be exactly the amountthe payer has agreed to spend�

�� Absence of framing� It is not feasible to construct a proof of double�spending if this did not occur�

�� Privacy� In order to allow anonymous payments� which are not necessar�ily unlinkable� two levels are distinguished�

Anonymity The payer can do the payments anonymously�

Unlinkability The payer�s payment transactions cannot be linked toeach other or to the corresponding withdrawals �except the payer��

Also� recovery should not a�ect the privacy of other transactions thanthose being recovered�

�� Payee�s Requirements

Any payee requires at least the following of the payment system�

�� Acceptable currencies� The payee can determine the choice of acceptablecurrencies in a payment transaction�

�� Ownership of deposit� The value of a payment made to a payee can onlybe credited to the payee�s account�

�� A payee can disavow a false claim of double�depositing�

��


Chapter ��

Security in the � Protocols

�� Bank�s Requirements

In the following� it is assumed that the bank follows the protocols� First� weneed the following de�nition�

Denition �� Let �� i� � Gq�Gq and �� r� c� c��i� � Gq�ZZq�ZZq�ZZq�where i � f�� g� A valid cheque is a pair �� i�� together with the quadruple

�� r� c� c��i�� such that �� ! �� c ! H�� c�� c�� a� b�� where ci ! H��i��a ! Gr

CPcC and b ! �r��

c��

In the sequel� we will brie�y speak of a valid cheque �� i��

�� Authenticity of Valid Cheques

The authenticity of cheques holds under Assumptions � �� and � �� It meansthat if a cheque �� i� is a valid �hence� accepted in payments and deposits��then this cheque has been withdrawn by the � wallet with public�key pS suchthat �� ! �pSh�

�� where the number �� has been chosen by the observer�

�� Limitation on Value

The quantity max pay�cu� is a publicly known parameter� The bank will refuseany deposit of a payment exceeding it�

�� 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 consti�tutes the deposit record� More precisely� it consists of a valid cheque �� i��authenticated by �� r� c� c��i� �as in De�nition �� and a triple �m� �� such that g��h�� ! ��

�m�i �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 avalid deposit record for some valid cheque �� i�� even if he has already seena valid record for that cheque� Such a new deposit record can only have twopossible forms�

� Same m� but di�erent inputs to the hash function�

� Di�erent m� from that in the given record�

��

Chapter �� Security in the � Protocols CAFE Final Report Volume II

Assumption � �� immediately rules out the �rst possibility� since it impliesthat the hash�function H is collision�resistant� Regarding the second� the fol�lowing arguments show this is infeasible under SDLA�

Let �� i� be a valid cheque� hence withdrawn by some wallet with publickey pS � say� that knows �� such that �� ! �pSh�

�� A conversation in the payment protocol �i�e� a deposit record� does not

contain any �Shannon�� information about pS � This holds despite the fact thatthe �rst and the second parts of a two�spendable cheque can be linked togetherby the authentication �� r� c� c��i�� More precisely� the payment protocol iswitness indistinguishable� Using standard techniques� it is easy to show that anattacker who has some probability of completing a new payment with respectto �� i�� given at most one correct payment for this cheque� can be turnedinto an algorithm which solves SDLP� Therefore� the existence of a forger �of��payments� with good probability of success� would contradict SDLA� AsSDLA and the collision�resistance of the hash�function H are both implied byAssumption � �� we get�

Proposition �� Under �� the following holds� Let �� i�� r� c� c��i��m� �� 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 simplysquaring the last value of � received� whereas increasing it requires theability to compute a square root �modulo Nphone�� This is hard if thefactorisation of Nphone is not known�

� Converting a cheque used in a normal payment to a cheque used in a tickpayment �and vice verse��As the message�m� signed by the wallet in the two types of payments di�erboth in the identity of the payee and the inclusion of � this seems to be justas di�cult as changing the amount in a normal payment� Proposition ��shows that this is infeasible�

Concerning currency exchange at the bank� note the following� As the currencyis included in the message signed by the wallet during payment it is hard tochange the amount encoded by changing the currency�

�� Correctness of Exchange Rates

The equality of the rate in deposit and in payment is assured by the samemechanism as the amount� Actually� the following four entities are signed bythe observer� pay fro� the amount payable in the paying currency� pay to� theamount payable in the payee�s currency� and cu to and cu fro� the ISO codesof both currencies� These entities together �x the exchange rate�

��

CAFE Final Report Volume II �� Bank�s Requirements

�� Double Deposits

Satis�ed by the de�nition of the clearing process�

�� 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 withdrawnamount�

By the integrity of the ��cheques themselves� it is infeasible to forge chequesor change the amount of a payment� As the observer entity is coded to decre�ment the balance in cu tbl by the amount paid� it su�ces to show that an �observer�s counter can only be increased when it does a withdrawal of amountat the issuer� while the increase equals the amount of money that the bankdebits from the payer�s account� The withdrawal of amount consists of thefollowing three steps�

Step � Identi�cation of the bank to the wallet�

Step � Identi�cation of the wallet to the bank�

Step � Updating the currency table in tamper�resistant observer �this actuallyrequires three signatures��

We will �rst argue why the signature that makes an update cu tbl can onlybe acquired in the correct stage� By Assumption � �� such a signature canonly be obtained in a stage where the bank gives a signature with respect toPa� as all other keys involved in the system and their corresponding signatureswill be di�erent by the properties of the key�generation� Note that there arethree di�erent stages in the � protocols� where the bank issues signatures withrespect to this key�

� Identi�cation of the bank to the wallet� The message cb that is signed bythe bank in this stage is equal of the form to H�mb� ab�� where mb is achallenge 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 formH�cz � cu tbl ��max dist � au�� Here cz is used to link the signature with theprevious signature from wallet�

As each of these signatures are on di�erently structured messages� they cannotbe confused with each other� As a result the �rst requirement to for strongintegrity is satis�ed�

Concerning the second requirement observe that the new currency tablewhich the bank signs exactly re�ects the change �debit credit� of the payer�saccount� as the related signatures cannot be changed� the currency table in�cluded by the bank cannot be changed� A wallet that receives such a signatureonly updates its currency table� if the �rst signature from the bank contains

��


the identity of the payer �together with a sequence number�� and the secondsignature is linked correctly to the previous signature from wallet �through cz��Therefore� only the wallet that completed Step � of the withdrawal of amountwill increase its counter�

This also explains why replay attacks would fail� as for each new withdrawalcz will be di�erent� So requirement � for strong integrity is also satis�ed�

�� Forger Identi�cation

Lemma �� Given a pair �� i� and numbers m� m�� with m �! m�� If ��

�� and �� satisfy ��

�m�i ! g��h�� and ��

�m�

�i ! g��

�h��

� � Then

�� ! gm��m

��m�m� h

m��m��

m�m�

��i ! g��

�

�m�

�mh��

�

�m�

�m �

Proposition �� Under Assumption � and SDLA the following holds�

Let �� i� be a valid cheque withdrawn by a wallet with public key pS� Supposewe are given two triples �m� �� and �m��

�� such that m �! m�� m�i !

g��h�� and ��m�

�i ! g��

�h��

� � De�ne a !m��m��m��m��

� Then a is well�de�ned and

satis�es ga ! pS�

Corollary �� If a payer double�spends a cheque �which must have been with�

drawn�� then the bank can trace the payer�

Thus using a part of a cheque more than once leads to identi�cation of thepayer that withdrew that cheque�

The question remains� however� if the holder of that very wallet is alsoresponsible for this o�ence� In any case� this mechanism of tracing can be usedto demonstrate fraudulent usage of currency �as a result of broken tamper�resistance� to� for instance� a court� Furthermore� this mechanism also allowsthe 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 apart of a cheque was spent at least twice� and can never prove to a third partythat it was spent� say� a thousand times�

�� Strong Integrity During recovery

It is easy to see that loss tolerance does not add anything to the existing pro�tocols that can in�uence the bank�s security� The only modi�cation is thatduring initialisation� the payer receives his part of the initial seed used by thewallet to withdraw and spend cheques� However� the bank�s part of the initialseed remains unknown to the user� so that the actual seed used in withdrawaland payment of cheques is unknown to the user� Knowledge of the seed wouldimply knowledge of all random choices made by the wallet� and hence of thewallet�s secret key�

��

CAFE Final Report Volume II �� Bank�s Requirements

Loss tolerance adds one new protocol to the ��system� recovery� Thus�assume that this protocol is executed for a speci�c wallet� During recovery�the bank does not reveal any new information� and the signatures issued by thebank cannot be reused in other protocols� since we assume that messages aretyped�

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 theobserver device is tamper resistant�� consider the last snapshot stored for thewallet� and call the withdrawal during which this snapshot was updated �nal

withdrawal� All payments of the wallet are based on the currency table thatwas stored at the bank during that �nal withdrawal� since there cannot havebeen a successful withdrawal after that one �note that in write cu tbl� thewallet terminates only if the reload station terminates�� The wallet could haveperformed at most max dist �min dist # � payments� The cheques used forthese payments are generated from a seed� S� for which hash seed ! H�S�NS��

During recovery� an auxiliary wallet generates max dist � min dist # �cheque identi�ers using a seed� S�� such that hash seed ! H�S�� N �

S�� whereprimes are used for the values of the auxiliary wallet� The value of the seed cor�responding to the oldest unspent cheque at the last withdrawal is then equal to

S��nr wrap ��min dist ��

mod N �S � where nr wrap� and min dist � are retrieved

from the snapshot of the �nal withdrawal� �see Section �� for an explana�tion��

Since H is collision�resistant� S��nr wrap��min dist ��

mod N �S must be the

correct seed� i�e�� exactly those cheque identi�ers are generated that could havebeen used by the wallet since the �nal withdrawal� After this� recovery waitsuntil all payments that could have been performed by the wallet must havebeen deposited �this time can be computed from the life times of parametersas de�ned by the parameter management�� Now it is guaranteed that using thecheque identi�ers generated during the �rst part of recovery� the second partidenti�es all payments that were performed by the wallet and deposited by theirpayees �based on the list of all deposits�� The holder of the wallet receives thedi�erence between cu tbl and all these payments� which is obviously correct�

�� Fall Back Integrity During Recovery

If the auxiliary wallet which was initialized at recovery is broken� an attackercan easily forward wrong cheque identi�ers to the bank� This problem can beavoided if the bank keeps the withdrawal transcripts of the cheques present inthe wallet at the end of the most recent withdrawal� Note that this di�ers fromstoring only the transcripts of the cheques withdrawn during the most recentexecution of gen cheques� During recovery one then not just recomputes ��but the whole cheque information up to c�� and checks if it �ts with the storedwithdrawal transcripts� Furthermore� to do this� the withdrawal transcripts ofthe bank and advancing the wallet�s seed must remain synchronized� requiringadditional recovery at the beginning of withdrawals� This would make theprotocols quite complicated without making much di�erence in practice� theadditional amount that can be obtained from a broken wallet by declaring it

��


lost is limited by max bal � If the wallet is broken� more e�ective attacks areenabled anyway�

Security of rec payments

Here� we argue that the rec payments protocol� which enables money lost asa result of interruption of the protocols to be recovered by the payer� does nota�ect the bank�s integrity requirements�

We have to show that interruptions of the protocols� whether intentionalor not� cannot lead a payer to recover more money than he is entitled to� Weconsider a speci�c 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 successfullyfor both parties� The correctness of the system without interruption toleranceimplies 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 intocur tbl� and payment�

Now assume that the statement holds for all payments since this last with�drawal� We show that it holds for the payment considered here� too�

In a standard payment� the payee receives the cheque only after the wallethas set pay busy� If the payment terminates successfully� then in one atomicaction� pay busy is reset and cur tbl is updated correctly� Since pay busy is falseafter this� reset will not change cur tbl� If the payment is interrupted beforepay 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 possiblebefore reset terminated successfully�� Thus� the next transaction starts froma valid cur tbl�

In a phone tick payment� the amount paid is not described by the cheque butby the number of pre�images � revealed� Since tck cnt is incremented atomicallybefore a new � is sent to the payee� tck cnt is never less than the number ofticks consumed �if the payment is interrupted� tck cnt could count one tick morethan really consumed�� Thus� the amount debited is always su�cient�

rec payments is safe for the bank� In rec payments� the wallet signs allpayment records� thus� the bank considers authentic payment records only��Replay is not prevented� but it is ensured that each payment record is consid�ered at most once�� A payment record is put into the list of failed payments inreset only� This happens only if pay busy is true� and pay busy is reset if andonly if cu tbl is changed according to this payment� Thus� the bank considersonly payments which were already debited to cu tbl� Finally� the recovery pro�cedure ensures explicitly that a payment is credited to the payer only if it wasnot deposited before�

Recovering a withdrawal is safe for the bank� The basis for recovery of awithdrawal is cu tbl from snapshot� This cu tbl is always valid at the timesnapshot was updated� the new version of cu tbl is signed by the wallet� and inauthenticate� this signature contains a challenge chosen by the bank� and inwrite cu tbl� it contains the unique seq no� i�e�� it is linked to the correspond�ing authenticate� Thus� it su�ces to show that if withdrawal is recovered� the

��

CAFE Final Report Volume II �� Payer�s Requirements

wallet could not have made payments or �successful� withdrawals since snap�

shot was updated the last time� Payments are explicitly prevented �in payment�cu tbl valid is inspected and must be true�� and each successful withdrawal up�dates snapshot��

Finally� in rec payments� the bank checks that the number of paymentsrecovered is not greater than the number of cheques that were available afterthe last withdrawal� Thus� in the worst case� a dishonest payer can claim thateach payment was interrupted�

�� Payer�s Requirements

�� Withdrawal Authorisation

In the ��system there is no possibility to check the amount obtained duringwithdrawal� Therefore a PIN is only used to authorise any withdrawal� To pre�vent fraud by the reload station putting less amount into the wallet than debitedfrom the payer�s account� or not crediting the amount transferred from the wal�let� the bank must be able to prove that the amount in a statement of accountreally matches the changes in the wallet� For this we assume that the reloadstation stores for each seq no a signed state received during authenticate anda corresponding one during write cu tbl as prescribed by these protocols�

The payer has to enter the PIN at every withdrawal transactions�

�� Payment and Transfer Authorisation

The payer can �lock� certain amounts� meaning that payments above a certainamount requires the use of a PIN�code� It is also possible to lock part of thebalance� In particular� the payer can choose to unlock no amount� Then allpayments 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�codeis 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 onlyprotects the payer from any unauthorised payment� After the payer has enteredher PIN into the non�trusted payee�s terminal� the shop is able to execute anynumber of payments of arbitrary amounts� We will not go into ways of resolvingthis type of problems here� we only mention that the recovery protocol couldbe used for this purpose� again sacri�cing some privacy�

�� Disavowal of False Accusations

Protection against false accusations of double�spending is not taken into accountin the present speci�cation� It can be added however�

��


�� Privacy

In the analysis of the payer�s privacy� we do not consider physical identi�cationof the wallet �nor the individual� as may be facilitated by special marks on thewallet� such as embossed information� and the like� In theory� such marks mayalso be attached by an enemy especially for this purpose� Although this maylead to physical recognition of a wallet when it shows up again during some�payment�� transaction� such an attack is not likely to enable identi�cation ofthe individual� in general� Note that such an attack requires that the attackerhas physical control �to some extent� over the wallet� in order to be able toattach a mark or read it� Therefore� contact�less communication� such as byinfra�red� seems to prevent this kind of attack� Other methods� possibly relyingon sophisticated technology� can be imagined but are not discussed here�

Only payments made with the same cheque can be linked together �at mosttwo� as we are dealing with two�spendable cheques�� Furthermore� the accurateuse of blind signatures prevents that withdrawals and payments by the samewallet can be linked by the bank and payee� More precisely� the ability to linksuch transactions implies the ability to distinguish the pseudo�random randombits used by wallet from a truly random sequence of bits�

In order to see that the payer�s privacy is satis�ed� �rst observe that the wal�let 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 identifyingitself to the wallet� by means of a Schnorr�signature on a random challenge bythe wallet �see authenticate�� The inclusion of the random challenge in thissignature prevents reuse of the very signature� There are attacks conceivable�though� using a fake reload station and the ma�a fraud �see �DGB�� thatwill 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 doesnot contain any information about the wallet that withdrew the cheque� norabout the payer unless the cheque is double�spent� Thus� no connection canbe established between the identity of a payer and a payment given the bank�sand payee�s knowledge�

If the bank knows the initial state of a wallet�s pseudo�random generator� thebank has a good chance of compromising the payer�s privacy� This possibility�however� is ruled out by the properties of wallet initialisation�

�� Payee�s Requirements

�� Ownership of Deposit

In the course of proving that the amount of a payment is preserved� we arguedthat the message signed by the � wallet cannot be changed� Recall that thepayee�s identity IDP is contained in that message �via the hash�functionH�� Asthe bank will only credit the account corresponding to that identity� it followsthat the amount of a payment that was made to a payee can only be deposited

��

CAFE Final Report Volume II �� Payee�s Requirements

to his account� Moreover� to prevent the same cheque from being used at morethan one occasion with the same payee� a unique transaction identi�er given bythe payee is included in the �hashed� data signed by the wallet at payment�

�� Disavowal of False Accusations

Although not speci�ed in the ��system� there exists a cryptographic protectionagainst the bank falsely accusing a payee of double�depositing� This works asfollows� 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 depositof the payment� the payee presents the payment to the bank and opens thecommitment� after the bank has stated that the payment has not been depositedbefore� In case� the bank falsely rejects the deposit� it is challenged by the payeeto open the commitment� an infeasible task� This extension can easily be addedto the speci�cation of the ��system�

��


��


Chapter ��

Integrity in the � Protocols

The integrity of the main roles �bank �issuer� acquirer�� payer� and payee� inthe � protocols is investigated� Also� in a separate section at the end� it isinvestigated whether integrity can be a�ected by interruption of the protocols�

�� Bank�s Integrity

�� Strong Integrity

The evaluation of strong integrity can be split into two main parts� which arethe evaluation of the withdrawal of amounts and the evaluation of payments ortransfers of amounts�

First we will discuss the integrity of the withdrawal� where we need to showthat a balance of an observer can only be increased when the payer does awithdrawal of an amount at the bank� while the increase equals the amount ofmoney that the bank debits from the payer�s account� The withdrawal of anamount consists of the following three steps�

�� Identi�cation of the bank to the wallet�

�� Identi�cation of the observer to the bank�

�� Updating the currency table in tamper�resistant observer �this actuallyrequires three signatures��

In order for strong integrity to hold� the withdrawal of an amount should satisfythe following conditions�

�� The type of signature that tells an observer to declare the new cu tbl validmust only be given by the bank in Step ��

�� Such a signature must only cause the observer that successfully completedStep � to update its cu tbl � The net amount of the increase of the balancesof the cu tbl must be exactly the amount debited from the correspondingaccount�

�� 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 theSchnorr signature scheme such a signature can only be obtained in a stage wherethe bank gives a signature with respect to Pa� as all other keys involved in the

��

Chapter �� Integrity in the � Protocols CAFE Final Report Volume II

system and their corresponding signatures will be di�erent by the properties ofthe key�generation� Note that there are three di�erent stages in the protocols�where the bank issues signatures with respect to this key �see authenticate

and write cu tbl��

� Identi�cation of the bank to the wallet� The message cb that is signed bythe 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� IDs� �cu tbl�� ar��

� Validate update of new currency table� The challenge cw is of the formH�cz � cu tbl ��max dist � �� aw�� Here cz is used to link the signature withthe previous signature from the observer�

From the independence of the Schnorr�signatures used in the protocols provedin Section �� we have that the �rst requirement for strong integrity at with�drawal is satis�ed�

Concerning the second requirement� observe that the new currency tablewhich the bank signs exactly re�ects the change �debit credit� of the payer�s ac�count� as the related signatures cannot be changed� the currency table includedby the bank cannot be changed� An observer that receives such a signature onlyupdates its currency table� if the �rst signature from the bank contains the iden�tity of the payer �together with a sequence number�� and the second signatureis linked correctly to the previous signature from the observer �through cz��Therefore� only an observer that completed Step � of the withdrawal of amountwill increase its counter�

This also explains why replay attacks would fail� as for each new withdrawalcz will be di�erent� So Requirement � for strong integrity at withdrawal is alsosatis�ed�

We will now discuss the strong integrity requirements for payment and trans�fer� The following four requirements need to be ful�lled�

�� 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 theobserver� by checking if the �ag cu tbl valid is set�

�� 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 beendebited� If the payer tries to avoid debiting� for instance by removing hiswallet� pay busy will remain set� Then� at the next time that reset iscarried out� the balance will be debited after all� Furthermore� under theassumption of tamper�resistance� the proper amount is debited�

In transfer� the amount is �rst debited from the balance of the observerand then credited to the balance of the � observer�� The amount to be

��

CAFE Final Report Volume II �� Bank�s Integrity

transferred is signed by the observer� this signature is checked by the �wallet� so the amount can not be altered�

�� The cooperation of the observer must be necessary in payment� transfer

and rollback�

That cooperation of the observer is necessary in payment has already beendemonstrated in Section ��

Furthermore� a random number � from the payee is included in the pay�ment speci�cation� This prevents replay by the payer� Collusion of thepayee and the payer where the payee generates the same number � sev�eral times and the payer carries out replay� will just get the payee severalexact copies of the same payment� which are worthless�

In transfer� the a�liated wallet requires two signatures from the ob�server� Therefore� the observer�s cooperation is necessary� Replay is notpossible� because in both signatures the challenge contains a random num�ber �mt respectively ca�� generated by the � wallet�

Finally� in rollback� the observer will only undo the balance decreaseperformed in the �unsuccessful� transfer if the correct value of x is pro�vided� �Note that the purse�s copies of the balance do not represent anyvalue� the observer�s copies do��

�� Negative balances must not be allowed by the observer�

Both in the payment and in the transfer the observer carries out an explicitcheck to see if the balance is su�ciently high to pay or transfer the chosenamount�

�� Strong Integrity During Recovery

We distinguish between recovery of failed payments and recovery in case of lostdevices� and start with the latter�

Recovery of Lost Wallet

This recovery procedure is secure for the bank if the procedure cannot be abusedto make the bank reimburse more money than was actually lost� This is the casewhen all values of �� that correspond with a payment in the period betweenthe last withdrawal and the execution of the recovery procedure� are presentamong the list of the �� generated during the recovery procedure and are infact received by the bank� This is enforced as follows� The sequence of eventsin an execution of the withdrawal protocol is the following�

�� reset

�� authenticate

�� write cu tbl

�� gen cheque

��


Note that rec payments is only executed if any failed payments have occurredbetween the previous and the present withdrawal� It is in the �rst stage�authenticate� that the value of state is communicated to the bank� Its authen�ticity is established by means of an interactive Schnorr�signature �preventingreplay� 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 unspentcheques can be regenerated from it �and some ��xed� data speci�c for theobserver��

Combining these facts we get that any payment the observer engages in afterits balance has been increased will use a cheque that can be regenerated fromthe value of dist that was communicated to the bank in the latest execution ofthe withdrawal protocol�

Note that by the fact that the purse�s RSA signature for blinding �� is deter�ministic� which is proved in a zero�knowledge protocol during initialisation� thelist of the �� as generated in the recovery protocol� will most certainly containthe �� that correspond to a payment carried out between the last withdrawaland recovery� the value of the purse�s signature with respect to �Np� ep� on�� dist� is unique�

From the values of max dist and min dist � which were communicated duringthe last withdrawal� the bank knows that at most max dist � min dist # �di�erent cheques are to be expected� This prevents the wallet from reclaimingmore cheques than withdrawn�

From the above� it can be concluded that the recovery information that thebank receives must be stored securely� if an intruder were able to adjust thelatest value of dist of some wallet� all money that this wallet spent after itslatest withdrawal could be recovered�

Recovery of Failed Payments

By the atomicity of the procedure in which the observer updates its balance inthe payment protocol� it will be the case that amounts of payments are deductedfrom the balance if the observer has sent out the responses �� and

�� Therefore�

an attacker cannot obtain a valid deposit record while the corresponding amountis not deducted from the observer�s balance�

The regeneration of the �� enjoys the same properties as in the recovery of alost wallet� Thus the only way an attacker can gain from the recovery of failedpayments� i�e�� in rec payments� is when a deposit�record he submitted �notethat an attacker can always have an observer mark a payment as �failed� whenin 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 �� and �� isnot submitted by the payee speci�ed in that deposit�record� But then it is justthe amount that was deducted from the balance of the observer that he will getback �after the cheque has been cleared�� and he has gained nothing�

��

CAFE Final Report Volume II �� Payer�s Integrity

�� Fall Back Integrity During Recovery

This is satis�ed by de�nition of the recovery procedure� If the tamper resis�tance is broken� an attacker can spend all withdrawn cheques for the maximumamount� He can keep doing this� provided that he goes back to the bank to getnew cheques whenever he runs out of unspent cheques� Note that the presenceof the recovery of payments procedure allows the attacker to recover �part of�the money he withdraws in this scenario�

�� Payer�s Integrity

For the payer� the main di�erence between the � and ��systems is the amountof control the user has over the actions performed� Furthermore� the PIN isprotected better as it is now entered through the purse� This makes it easierto hide it when entering it and it is not exposed to supporting terminals thatcannot be trusted by the payer�� Brie�y� the payer�s integrity is protected asfollows�

� Withdrawal authorisation�One needs a secret key �the observer�s� in this case� to be able to withdrawmoney� 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 hisPIN �i�e�� before pressing "OK�� to the observer �thereby allowing thewithdrawal� the user is in full control over the new cu tbl �

� Exchange authorisation�Exchange during withdrawal is protected by the same means as a normalwithdrawal� Regarding exchange during payment the same protection asfor payments apply�

� Payment transfer authorisation�The payer�s integrity in payment and transfer is enhanced by the factthat the user can now check amounts and rates before authorising thetransaction �by pressing "OK��

� False proofs of double�spending�A proof of double spending requires the secret key of the observer� Acorrect payment does not allow the key to be computed� The securityagainst such false accusations depend heavily on the key managementand initialisation of observers� since anybody knowing this key can makesuch proofs�

Recovering money requires the help of the bank� Observe� however� that ifa payer is entitled to reimbursement as a result of a failed payment� an attackercannot coerce the observer into deleting the payment before it is submitted forthe bank for recovery� This would require forging the bank�s signature in therec payments protocol� which is infeasible�

��


Privacy

The requirements of privacy are split into two main properties� anonymity andunlinkability� In the statement of the privacy requirements it is assumed thatthe payer Alice follows the protocols�

Unlinkability

� Not even a collusion between the bank and all payees can identify twopayments� made with two di�erent cheques� as being made by the samewallet� with probability signi�cantly greater than random guessing�

Anonymity

� Not even a collusion between the bank and all payees can identify a givenpayment as having been performed by Alice�s wallet� with probabilitysigni�cantly greater than random guessing�

� As a result of an execution of rec payments� the bank is only able to traceat most one of Alice�s payments in addition to the one corresponding tothe failed payment�

� As a result of an execution of recovery� the bank is only able to traceAlice�s payments in so far they have been performed after Alice�s lastwithdrawal�

The following list contains general assumptions and conditions that we �ndnecessary and feasible to state and for which no further arguments are provided�More speci�c assumptions appear where they are needed in the analysis�

�� Linking of transactions by physical identi�cation of the wallet� the walletor the individual user of the instruments are outside the scope of thisanalysis�

�� The purse will carry out the protocols correctly� but can be interruptedby the other parties�

�� The observer either alone or in cooperation with any third party commu�nicating through the purse are free to deviate from the speci�ed protocols�for instance in order to achieve informational out�ow�

�� The purse is initialised correctly for all the parameters�

�� Only the purse and its owner can store the initial and subsequent valuesof the pseudo random generator employed by the purse�

�� The key certi�cation centres will only issue a single certi�cate for eachpublic key� for instance the bank�s public keys�

�� The protocols show currencies� reset� transfer� rollback� unlock amt

and the messages generated from these protocols are not available for ex�ecution by outside parties� transfer and rollback communicate witha�liated wallet�

��


� The observer cannot exploit any covert timing channels through the purse�sIR�link or through the card reader to the outside�

� The withdrawal service involves the following protocols utilising the IR�link� get info� update� authenticate� write cu tbl� gen cheque andrec payments�

� � 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 areassigned in the withdrawal transaction� Any data that is occurring in a pay�ment transaction and that is computationally linkable to or from a withdrawaltransaction can help in linking the payment transaction to a speci�c identity�from the bank�s point of view� The remedy against this is the �blind signa�ture mechanism�� By the properties of the blind signature scheme there doesnot exist any e�ciently computable link between a payment transaction and awithdrawal transaction�

Here� we limit the analysis to �the cheque part� of the withdrawal and thepayment transactions�

When showing that withdrawal and payments are unlinkable� we have toshow that anything which the bank sees in some execution of gen cheque canmatch anything the payee sees in an execution of payment�

Proposition �� 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 �� is chosen �pseudo� ran�domly by the purse� In the protocol the purse actually computes this valuedeterministically as an RSA signature on numbers supplied by the observer�However� under the assumption that such signatures are unpredictable the anal�ysis also works in this case�

This proposition also implies that the observer cannot use withdrawal andpayment to send information to the outside world� which can be used to linkthese transactions� Furthermore� since the purse checks variables against itsown copies and randomises signatures cheques these possible covert channelsare prevented to a large degree� However� sometimes the purse is only able toverify that variables are within an allowed range in which case a small room forout�ow exists�

For assessing anonymity of a payer� we need to identify the set of parameter�values that identify the payer� By inspection of the protocol speci�cation wesee 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�

��


� The seeds S� S��

In the following these parameters will be referred to as identity�data�

Proposition �� 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 justi�ed as follows� The holder has to request a withdrawal�so the wallet cannot execute this service �unattended� in connection with otherprotocols� The bank will always have to authenticate itself to the purse beforethe wallet identi�es itself to the bank� The inclusion of the random challengesin the authenticating signature prevents replay attacks�

The �Ma�a fraud� attack is conceivable� if the holder intends to make awithdrawal� but unknowingly uses a fake reload station� This entity will justmediate the messages that constitute the bank�s authenticity� the result beingthat the purse will send IDs�

Proposition �� A run of the get info protocol does not reveal any infor�

mation about the identity�data�

This proposition is justi�ed as follows� In the get info protocol the parametersets that will be used during the subsequent execution of the payment protocolare identi�ed� The observer sends v�� vB�a� vB�c and IDB to the payee withsome veri�cation by the purse� �vB�a is not needed for a payment transactionbut is sent anyway��

The values of these variables remain �xed for a long time for each payerand� in principle� can be used by the payee to sort payments� However� theinformation content in the key version numbers relative to identity�data can beassumed to be very low because only a few� ideally only two� sets are in useat any point of time� The information content of the bank identity relative toidentity�data depends on the number of payers� the number of banks and therelative size of banks� It is assumed that the number of banks will be very smallcompared to the number of bank customers� which means information contentof IDB relative to identity�data is also very small�

The purse performs an exact veri�cation of the variables v� and IDB beforesending them to the payee� These variables are set during initialisation of thepurse and cannot be changed� Thus� the observer is unable to use these variablesas a covert channel for sending identity�data�

Proposition �� A run of the get certif protocol does not reveal any in�

formation about the identity�data�

This proposition is justi�ed as follows� The get certif protocol is executedon request from the payee if the payee doesn�t know the bank keys that will beused by the payer� One or two key certi�cates are sent from the payer to thepayee during the execution of this protocol�

No additional information about the payer is revealed to the payee by send�ing the keys and certi�cates of the issuing bank and certi�cation centre� These

��


keys and the certi�cates are uniquely given by IDB and vB�c and the assumptionthat a given key will only be certi�ed once�

The observer is not involved in this protocol and will not be able to com�municate any information to the payee�

Proposition �� A run of the payment protocol does not reveal any informa�

tion about the identity�data� if Proposition �� of unlinkability holds�

Proof� Since the identity data can be computed from gc which the bankknows in gen cheque� the ability to compute this data from the payment

would lead to a link between gen cheque and payment� This contradictsProposition ��

We now evaluate the rec payments� recovery� update and transfer pro�tocols with respect to privacy�

A recovery of a single payment is done by permitting the bank to tracethis payment to discover if it was successful or not� Due to the two�spendingproperty of a cheque� the bank will also be able to trace the payment performedwith the second part of the recovered cheque�

In the rec payments protocol the variables �� i� Epay � pay type� tck cnt �cu fro� date� cp� rp and uk are sent from the purse to the bank�

The value of �� is initially chosen by the observer but randomised by thepurse using �� The protocol speci�cation does explicitly require the purse toverify that �� is not put to or �� similar to the payment protocol�

The variable i cannot be used for transmitting information to the bank sincethe purse veri�es 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 thepurse to the bank without any possibility of interference by the observer�

The signature �cp� rp� is generated by the observer but randomised by thepurse with the value of up� and therefore cannot be used by the observer tosend 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 cannotbe used to transmit covert information from the observer to the bank� In thisdiscussion it has however tacitly been assumed that the recovery informationstored by the purse is correct�

Recovery information is stored in a �failed payment� storage structure dur�ing the reset protocol� It turns out that recovery information has to be storedwhenever pay busy in the observer is set� The purse is not able to verify thisand just stores recovery information about the last spent cheque whenever theobserver tells it to� The rec payments protocol is executed automatically whenthe wallet is in contact with the bank� This means that the observer is able toallow the bank to trace any payments by tricking the purse into believing thatthese payments have failed during an execution of reset�

In the recovery protocol� the pseudo random generator of a replacementobserver is set up with the initial state of the observer that is about to be

��


recovered� This correct recovery procedure is dependent on having the payerinput some secret recovery data S�� Neither the bank nor the new wallet is ableto reconstruct the observer seed required for the reconstruction of the chequeswithout 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 speci�ed by min dist andmax dist � The bank determines this range at its own discretion� The protocolspeci�ed does not allow the purse to verify the range� All cheques in this rangewill be traced by the bank� This attack is possible even if the observer followsits protocols�

The update Protocol updates the bank public key certi�cates 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 pursesends its IDs� The ability to forge an authentication signature for the bankimplies the ability the e�ect the wallet�s identity output� but only if this protocolcan be run independently of the authentication protocol in the withdrawalservice�

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 cannotknow in advance which entity is invoking the transfer service� Therefore the� wallet has to authenticate itself before the � wallet does� The � wallet willrequire a correct signature on a random challenge before identifying itself by asignature�

The purse does not send any data to the outside world during the rollbackprotocol� Hence this protocol cannot compromise the payer�s privacy�

We now draw our conclusion based on the above analysis� The � protocolsful�l all privacy requirements of the payer� under the computational securityassumptions for the cryptographic primitives� in particular the RSA�signatureand pseudo random generators of the purse� If a payment protocol is inter�rupted� then the rec payments protocol will be executed� enabling the bank totrace at most one payment in addition to the payment that the wallet noted asfailed �the other part of a two�spendable cheque� if it was spent�� If a payer asksthe bank to recover an observer� then the recovery protocol enables the bankto link at least all payment transactions after the last withdrawal transaction�

The � protocols o�er improved privacy compared to the � protocols� Whenimplemented with contact�less communication between the wallet and the out�side world physical identi�cation of the payment device is much harder thanin the ��system� From a privacy point of view� the most important di�erencebetween the � protocol system and a the � protocol system is that the strictfunctional distinction between purse and observer ensures that privacy is nowunder control of the payer supported by the purse entity�

��

CAFE Final Report Volume II �� Resilience Against Interruptions

�� Resilience Against Interruptions

Each time an observer is switched on� it will execute reset �rst� particularlythe �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 a�ectthe security� Consider an attacker who aims at causing the observer to issue acheque while the spent amount will not be �fully� debited from the balance� Ofcourse� the attack should not render new services to be delivered impossible� Bythe assumption on the tamper resistance of the observer and the cryptographicproperties of the cheques� the only way left for an attacker to prevent theobserver from updating the balance corresponding to a payment� is to interruptit�

However� before the values �� and �� that complete a payment �and thevalues � in case of phone ticks� are sent out� the �ag pay busy is set� This isan atomic operation� It is only after �� and �� are communicated to the pursethat the balance is updated and the �ag pay busy is reset atomically� If theobserver is interrupted between the transmission of �� and �� and the updateof the balance� it will notice the �ag pay busy to be still set the next time it isin operation�

Consequently� it will carry out the update after all� Note that the currentcheque is marked as a failed payment if any interruption occurs after the �agpay busy is set� The amount of a failed payment can only be recovered if thecorresponding cheque survives the clearing process� i�e�� if a cheque turns out notto have been submitted during a deposit� As the amount will be debited fromthe balance anyway� an attacker cannot make pro�t out of forcing a paymentto fail and then reclaim the amount in the recovery procedure�

Another threat posed by interruptions could be the following� If an attackerwere 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 anopportunity to learn the secret key ss� and thus enabling the attacker to bypassthe observer in the gen cheque and payment protocols� This is simply resolvedby having the observer mark the cheques atomically�

We will now investigate the resilience against interruptions in the case ofthe withdrawal protocol� E�ectively� authenticate consists of giving the banka snapshot of the current state of the observer� Note that its authenticity isguaranteed by an interactive Schnorr�signature and that the bank will only en�gage in an execution of write cu tbl if it is preceded by a successful executionof authenticate� Therefore� the bank will have a state of the observer at hisdisposal� 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 theobserver can be used to execute another protocol� after which it can jump backto write cu tbl �the purse just simulates the bank in authenticate��

However� if the value of cu tbl is changed during this interruption� theobserver will not accept the bank�s �rst signature in write cu tbl� as it will in�clude the value of cu tbl as communicated during the execution of authenticate

��


before the interruption� For a similar reason� it is infeasible to interrupt the ob�server 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 e�ect of interruptions right before or during the gen cheque pro�tocol is a limitation of the number of cheques that are withdrawn� We concludethat it is of no advantage to an attacker to interrupt the withdrawal protocol�

In the transfer protocol� the mother �rst communicates the transfer amountto the daughter by means of an interactive Schnorr�signature� The mother ob�server will only deduct the transfer amount �atomically� if she has received anacknowledgement from the daughter that she agrees on the transfer amount�by use of an interactive Schnorr�signature�� Upon receipt of an interactiveSchnorr�signature by the �mother� wallet� the a�liated �daughter� wallet up�dates 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 beenexchanged 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 themother from updating hers�

In the protocols rollback� updateP c� updateP a� rec payments� recoveryand deposit� interruptions are potentially only harmful for the payer�s integrity�However� by the atomicity of the crucial operations in those protocols� the wal�let can recover from interruptions� As a conclusion� interruption of the observerduring any of the protocols does not seem to harm the bank�s integrity�

As to the e�ect of interruptions on the payer�s integrity� note that crucialoperations in the payer�s wallet and the bank�s reload station are performedatomically� If an observer is interrupted� then the wallet can recover frompossible loss of value in the rec payments protocol�

As the payee only accepts a payment if a valid deposit record has beensubmitted� there is no threat here for the payee �it is assumed that the till canrecover from possible interruptions or break down��

�� Independence of � Protocols

A common property of a payment system like CAFE �or of any set of crypto�graphic protocols� for that matter� is that the protocols are su�ciently inde�pendent� That is� �partial� results obtained from executing one protocol shouldbe useless for later executions of any protocol �including the protocol itself�� Inmany 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� Wewill 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 ofthe exchange of Schnorr�signatures� It is very important that a signature thatis 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 derivedfrom the independence of Schnorr�signatures as they are required in the various

��

CAFE Final Report Volume II �� Independence of � Protocols

stages of the protocols�

As an example consider the signature by which the bank identi�ed itself tothe wallet� Suppose this signature were similar enough to the one by which theobserver is told to update its balance� Then an attacker could be able to abusethe identi�cation of the bank to load money into the observer� thus creatingmoney� Similarly� the observer�s signatures should be independent�

It is only here that the �trivial collisions�� mentioned in the section on thesecurity of the hash functions may do harm� the substitution of the hash valueof one message in stead of the hash value of another is dangerous only if it ispart 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 hashvalues of the two messages are the same� That is� in case of a collision� However�by Assumption � �� which implies the collision�resistance of H� we need onlyconsider the trivial collisions� Below we will consider all such possibilities�

First� observe that a trivial collision can do no harm if the hash values areused in signatures using di�erent keys� Furthermore� one cannot have a trivialcollision if the number of blocks in the messages are di�erent� Therefore� weneed 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 chequesthemselves may be ignored� they are� respectively� used in exactly one stage inthe protocols �Sc is used only for signing cheques� or used exactly once �a pair�� i� for each i can be used only once �in payment� to sign a set of paymentdata��

Below� all remaining signatures are classi�ed according to those two criteria�

bank�s signatures �secret key Sa��

We need only consider the bank�s security here� as an attacker wouldobviously not be interested in forging a signature that the bank would bewilling to provide�

� block There is only one one�block signature� the bank signs �ab� inauthenticate� No possibility for trivial collisions�

� blocks The following two�block messages are signed by the bank�

�� In write cu tbl� �seq no� IDs� cu tbl � � � ar��This signature allows the observer to make the currency tablewith value cu tbl invalid� and overwrite it with the new valuecu tbl �� cu tbl valid is true when this signature is issued� elsethe bank issues the signature below��Forging this signature would not pose any security problems�as no value is directly involved� and indirectly� preservation ofvalue is guaranteed by the recovery procedures�

�Note that� though the secret key of a cheque is related to the observer�s secret key� noinformation on the latter key can be inferred from the cheque by the security of the signaturescheme�

��


Note that this signature will cause the observer to increase itsseq no� This is the same situation that arises when the bankdoes take part in the write cu tbl protocol� but the protocolcrashes after the observer increased seq no� but before the bankdid so�

�� In write cu tbl� �seq no� IDs� � � ar��This signature allows the observer to overwrite the already in�valid cu tbl with the new value cu tbl �� cu tbl valid is falsewhen this signature is issued� else the bank issues the signatureabove��Forging this signature has no other e�ect than increasing seq no

without the bank knowing this �see above��

�� In write cu tbl� �cz� cu tbl ��max dist � � � aw��This signature allows the observer to validate the new storedcurrency table cu tbl �� and issues a new value of max dist �Forging this signature would allow the forger to create money�

�� In updateP c� �mu� � � au��This signature identi�es the bank to the wallet� it prevents im�personation aimed at obtaining IDs�Forging this signature would just allow the forger to obtain theidentity IDs� This is not a threat to the bank�s security�

�� In rec payments� �cp� � � ak��This signature acknowledges the receipt of a set of failed pay�ment data� and thereby allows the observer to erase these datafrom memory�Forging this signature might cause loss of money that wouldotherwise be recovered� This is no threat to the bank�s security�

It follows that only case � is a threat to the bank�s security�

We must therefore consider the following possibilities of trivial colli�sions� substitution of any of the signatures above in case �� For thispurpose� consider the contents �with byte numbers� of the messagesabove�

� � � � � � � �� block �

� seq no IDs cu tbl � � ar� seq no IDs � ar� cz cu tbl ��max dist � � aw� mu � au� cp � ak

It is obvious that signatures � and � cannot be substituted in signa�ture �� as cz will have its �rst � bytes equal to �seq no� IDs� withnegligible probability�

A substitution of signature � in signature � requires cz ! cp� as theseare hash values of di�erent length messages� this cannot happenbecause of collision resistance of the hash function� Substitution ofsignature � in signature � �nally� will not pose a problem� as this willset the new currency table to hold no value �all currency identi�ers

��


will be �xff� denoting empty rows�� This will obviously only bepro�table to the bank�

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

� blocks The following two�block messages are signed by the observer�

�� In write cu tbl� �seq no� cu tbl �� az��This signature noti�es the bank that the sequence number hasbeen increased to seq no� and that the value of the currencytable is set to cu tbl �� And permission to validate this currencytable is requested from the bank��The bank might want to forge this signature to defraud thepayer� using a fraudulent signature� for instance� "prove� thata large amount was withdrawn by a payer� "justifying� a corre�sponding debit transaction on the payer�s account�

�� In transfer� �mt�Xfer � � � at��With this signature� the observer gives permission to commencea transfer of amount Xfer with challenge mt from the a�liatedwallet��This signature �xes the amount transferred� so forging it maycreate money�

� In transfer� �ca� � � ai��This signature acknowledges that the transfer has been per�formed successfully�Forging this signature will coerce the a�liated wallet into in�creasing its balance �by amount Xfer as in the preceding partof the protocol��

As all three signatures involve value� we must consider all � casesof substitution� For this purpose� consider the contents �with bytenumbers� of the messages above�

� � � � � � � �� block �

� seq no cu tbl �� az� mt Xfer � at ca � � ai

Substitution of message � in signature � or will not work� as a validseq no and cu tbl � will provide mt respectively ca with negligibleprobability� Neither will substitution of � in or vice versa work� asan all�one amount Xfer �i�e�� Xfer ! �� will de�nitely not beaccepted� Finally� substitution of in � will not work� as ca will notprovide the correct seq no and a valid cu tbl ��Only a substitution of � into � will work� Note however that the bankknows on beforehand which cu tbl � will be signed by the observer�This implies that a substituted signature will not be accepted� as

��


it is not on the correct message� In other words� the signature isaccepted only if the bank approves of cu tbl � �and it is correct��So� this cannot bene�t the payer� the appropriate amount will bedebited from his account� Thus� only the bank can bene�t from thissubstitution� 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 "OK� this during for example awithdrawal session�� So� the wallet is lost� if the bank now claimsthat a large amount is on the wallet and debits it from the account�a recovery will be �demanded and� executed� This recovery willreimburse the payer with the money the bank attempted to defraudhim of� That is� the only working substitution does not bene�t thefraud�

� blocks The following three�block messages are signed by the observer�

� In authenticate� �cb� state � � � as��The state is communicated to the bank�Forging this signature might create money� as state containstrans and cu tbl � A false value will produce an incorrect newcurrency table� or an incorrect amount of reimbursement in caseof recovery�

� � In rec payments� �� 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 bereimbursed for an incorrect amount Epay � or �due to an incor�rect �� unjustly be reimbursed� �A non�existent �� will not bedetected in the clearing� This will hold even if the actual transac�tion was successful or if no transaction at all was performed�noreimbursement is needed in either case��

�� In recovery� �rq� dist � � � �� a��The data corresponding to a possible payment to be recoveredis sent to the bank�Forging this signature might create money� similar to the rea�soning above�

As all three signatures involve value� we must consider all � casesof substitution� For this purpose� consider the contents �with bytenumbers� of the messages above� shown in this table�

� � � � �� block � block �

� cb seq no� cu tbl valid � � � �� nr fail pay cu tbl � � as�� i� Epay � � � �� date � � ap�� rq dist � � �� a�

Substitution of � in will not work� as message starts with � random bytes �cb�� determined by the previous actions in the protocol

��


and out of control of the attacker� A correct value of �� with its�rst � bytes equal to cb will show up with negligible probabilityonly�

Substitution of �� in will not work� as this requires cb ! rq� anda correct value of rq with its �rst � bytes equal to cb will show upwith negligible probability only�

Similarly� substitution of message � in signature �� will not work�Substitution of message in signature �� will not work� as byte ��of message must be �xff� as it coincides with the padding in mes�sage �� This forces cu tbl valid ! xff� which is an invalid value�Thus� a suitable message for substitution in signature �� will notoccur�

A substitution in signature � will not be successful since the pay�ment data in the second block will not be valid� as is shown below�A substitution of message �� in signature � would need to have avalue of the �� from message �� ending in a valid date and � bytes�xff� as it coincides with �i�Epay � � � � � date � � � in message � � Thishappens with negligible probability�

Finally� substitution of message in signature � requires the sec�ond block of message to contain at most �� bytes unequal to �xff�these �� bytes must be the cu tbl � The �rst bytes constitute the�rst row� The next three bytes �coinciding with date� are part of thesecond row of cu tbl � Since �x� is not a valid date� the second row isnonempty� This row then has form� a nonzero balance� followed by acurrency identi�er �xffff and rate �xffffff� �The latter two vari�ables coincide with the padding in message � �� This is not a validrow of a currency table� since the bank will not provide a nonzeroamount of an invalid ��xffff� currency� That is� substitution ofmessage in signature � requires an "impossible� cu tbl �

So trivial collisions with three�block messages have negligible prob�ability of success�

We conclude that no successful attack based on dependence of protocols in theform of trivial collisions is possible�

��


��


Part V

Clearing

��


Chapter ��

Introduction

In the previous chapters a payment system has been described with little re�gard for the functionality required for clearing of electronic currency between amultitude of issuers and acquirers� In this chapter we describe this functionality�

�� Overview

So far this document has not focused its attention on the clearing system andmechanisms that must exist in a multi�issuer system for settling of claims acquir�ers will hold against issuers as a result of accepting electronic currency issuedby these issuers� A brief description of such a clearing system was already givenby �Cha�� and a detailed work�out in the case of the on�line system of �Cha�by �Sto��

In this part we describe the architecture of the clearing infrastructure andthe functionality provided by the clearing infrastructure� Figure �� showsthe roles and the transactions required for clearing in a multi issuer paymentsystem�

In this model the cheque cycle begins with a withdrawal transaction followedby a payment and a deposit just as in the simpli�ed model� However� the issuerinvolved in the withdrawal and the acquirer involved in deposit will generallybe economically distinct� The acquirer will thus be a creditor with respect tothe issuer of the cheque� The clearing and the settlement bank is introducedto facilitate settlement of such claims� and a clearing request is added to thecheque cycle�

In this part we will describe the actions performed by the clearing in re�sponse 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 ofthese three actions�

The clearing cycle shown in Figure �� is not complete in the sense thatcheques are not ultimately returned to the issuer� The cheques are truncated

by the clearing� This requires the issuer to trust the validation performed bythe clearing� In Chapter �� we will present a generalization of the clearingmodel which removes this requirement� In this generalized clearing model the

��

Chapter �� Introduction CAFE Final Report Volume II

�

�

�

��

��

�I

�

��

Clearing

Payer Payee

Issuer

Deposit

Payment

Withdrawal

Settlement bank

Request settlement

Acquirer

Clearing request

Figure �� Generalized payment model with multiple issuers and acquirersand a clearing infrastructure� Solid arrows indicate movement of cheques�Cheques are truncated by the clearing�

��

CAFE Final Report Volume II �� Denitions

�

�

�

Clearing

Payer

Issuer

Recovery protocol

Recovery protocol

Figure �� Model for recovery of value in a lost wallet�

single centralized clearing center indicated in Figure �� will be replaced by ahierarchy of clearing nodes� This generalization will be relatively simple oncethe centralized clearing model is described�

The dotted line from the clearing to the settlement bank is not a part of thecheque cycle� The clearing only requests movement of funds between accountsat the settlement bank�no cheques are sent�

The clearing is also involved in the loss recovery procedures when an elec�tronic wallet is lost or destroyed� The clearing accepts a list of cheques from anissuer and returns deposit information about these cheques� This informationpermits the issuer� in cooperation with the payer� to compute the amount tobe restored in the payer�s new wallet� A model for the recovery procedure isshown in Figure ��

�� De�nitions

In the brief overview given above� we have already introduced some new termi�nology to describe the clearing infrastructure� Some de�nitions 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 paymenttransaction� 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 single�spendable part�

Clearing infrastructure The clearing infrastructure comprises all roles in�volved in the clearing of cheques� the acquirer� the clearing and the set�tlement bank�

Clearing This role is responsible for the administration of the validation ofcheques� the clearing and the settlement initialization request� In addition

��


to the normal clearing operation� the clearing is also involved in the lossrecovery 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 anamount that can be spent using these cheques�

Acquirer This is the role that accepts spent electronic currency as a depositfrom a payee�

Settlement bank This is the bank performing the settlement between theparticipating issuers and acquirers� Each bank operating as an issuer oracquirer �or both� has an account with the settlement bank to settle netclaims 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 sub�mitted for clearing� Validated cheques are submitted for clearing�

Clearing process This is the process of accumulating the claims �amounton cheques� on issuers by acquirers� with the aim to compute the netmovement of funds needed for settlement between the participating banks�

The term �clearing� is also used to denote the combined process of vali�dation� clearing and settlement request�

Settlement process This is the process of transferring funds between bankaccounts of issuers and acquirers to settle the net claims�

�� Requirements

The following assumptions about the properties of the electronic payment sys�tem have been used in the design of the clearing architecture�

� The payment system supports anonymous payments in the sense that theidentity of a payer can�t be linked to payment transactions without thepayer�s cooperation�

� The validity of electronic currency �cheques� is restricted to a time periodso that the number of cheques �in circulation� does not grow withoutbounds� This assumption will be used when duplicate checking is de�scribed�

� A settlement bank exists to settle net debts resulting from a period ofclearing of cheques�

A clearing architecture for electronic currency must satisfy the followinghigh level requirements�

��

CAFE Final Report Volume II �� Requirements

Validation before clearing and settlement Since electronic currency rep�resents a claim on the issuer� it must be validated before this claim can besettled between the claimant and the issuer� This validation includes ver�i�cation of the formatting of the data comprising the electronic currency�veri�cation of the authenticity and integrity of this data� and veri�cationthat the claim has not already been validated and cleared�

A payment is made by assigning a value to an electronic cheque� signed bythe payer and received by the payee� A cheque can�t be spent twice as thespending requires the involvement of a tamper resistant device during thepayment transaction� This device will refuse to spend the same chequetwice� Since the security of a tamper resistant device can�t be proved� asecond line of defense against double spending has been incorporated intothe system� The clearing infrastructure will detect double spending afterthe fact and identify the double spender by a special processing of thecheques�

Detection of double spending requires all spent cheques to be collectedand 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 withwell de�ned and acceptable trust relations for all involved roles� In CAFE

parlance this means that no party should be required to trust other partiesfor correct and complete operation�

For the clearing architecture this means that the issuer should be able toverify all claims on itself� The issuer must not be required to trust thevalidation 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 be�fore it reaches the issuer� that is� deposited currency cannot be aggregatedby� say� the acquirer and only the accumulated sum of all claims be for�warded to the issuer� All deposited currency should be returned to theissuer for validation before clearing�

All roles in the CAFE payment system are able to verify the validity ofelectronic currency� For instance� the payee is able to verify that hereceives valid electronic currency from the payer� The acquirers supplytheir patrons with necessary information to enable this veri�cation� Prioragreements between participants and a court system must exist to regulatethe behavior in case of dispute�

E�ciency and capacity The clearing architecture must have su�cient pro�cessing and communications capacity and should be as e�cient as possi�ble� The clearing architecture must be scalable to be able to process anarbitrary number of electronic payment transactions�

Communications e�ciency is somewhat in opposition to the trust require�ments described above� Communications e�ciency can be improved by

��


Settlement

bank

1. Deposit

2. Clearing request

3. Validation

request

Settlement request

4. Validation

5. Response6. Clearing request

6. Response

7. Clearing

7. Credit

8.

9. Settle

ValidatorClearing

Clearing

Clearing

administrator

Issuer Acquirer

Figure �� The structure of the centralized clearing architecture�

truncating electronic cheques as early as possible in the deposit or clear�ing�

�� 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 andproperties�

The structure of the centralized clearing architecture is shown in Figure ��This �gure shows the roles involved in the clearing as rectangles� The clearing issplit in three entities� the clearing administrator� the cheque validator and theclearing entity� Interactions are indicated by arrows� Circular arrows indicateprocessing activity performed�

The �ow of events required for clearing of a single cheque is summarizedbelow� The numbers in the �gure corresponds to the items in this list�

�� Initially� an electronic cheque is deposited by the payee at the acquirer�

�� The acquirer will periodically submit a batch of deposited cheques by arequest to the clearing�

�� The clearing request is received by the clearing administration entity�The batch of cheques is now sent to the validator� possibly together withcheques received from other acquirers�

��

CAFE Final Report Volume II �� Clearing Architecture

�� The validator decides the validity of the received cheques and makes surethey have not been duplicated�

�� The validator sends a response to the clearing administration entity indi�cating the validity status of each of the submitted cheques�

�� The clearing administration now sends a clearing request for the validatedcheques to the clearing entity� A response is also sent to the acquirerindicating the outcome of the validation of each submitted cheque�

�� The clearing entity updates its clearing accounts for the issuer and ac�quirer of each cheque� For each cheque the amount is credited to theacquirer�s account and debited from the issuer�s account�

The acquirer can credit the depositor�s account when the clearing responsefrom the clearing center is received�

� After some time has elapsed the clearing entity will compute the net claimor debt represented by each clearing account� This information will besent to the settlement bank and the clearing account will be reset�

� The settlement bank transfers funds in and out of each bank�s account inaccordance with the settlement request from the clearing center�

The issuer is not active in a normal successful clearing of a cheque� Theissuer will however be involved if a cheque is rejected due to broken tamperresistance in a wallet� This is discussed in the section on double spending� Theissuer is also involved during the loss recovery procedure for lost or destroyedwallets�

The above description indicates batch processing of cheques but this is notrequired� The architecture permits instant clearing of special �priority de�posits�� but this is not discussed further in this document�

��


��


Chapter ��

Functional Description

In this section we give a functional description of the clearing architecture andthe clearing roles� The description is given at a level that will give an idea ofhow the system works without going into great detail�

The description is divided in three parts� First� a description of somedatabase tables used by the clearing infrastructure is given for later refer�ence� Next� some important issues such as double spending and blacklistingare treated� Finally� stepwise descriptions of the clearing infrastructure proce�dures are given�

�� Database Tables

Only the major database tables maintained by the clearing infrastructure aredescribed here� Other database tables will exist in the clearing infrastructure�but are not required for this simpli�ed description�

ChequeTable This table is used by the acquirer to store all cheques that arecurrently being processed by the clearing infrastructure� This is the maintable storing all information about the deposited cheques� Other tableskept by the acquirer contain only references to this main table�

DepositTable In this table the acquirer stores cheques deposited by payees� Thistable serves as a �input bin� until the acquirer decides to process a batchof cheques�

ClearingTable The acquirer keeps a list of cheques that are currently being pro�cessed by the clearing in this database table�

TransTable After clearing the acquirer moves the cheques into this table wherethey are kept until depositors� accounts are credited�

ClearChequeTable This table is used by the clearing to store all cheques that arecurrently being processed� This is the main table storing all informationabout the cheques� Other tables maintained by the clearing contain onlyreferences to this master table�

DupChequeTable This is the table used by the clearing to detect double spend�ing and double depositing of cheques� The table will hold key informationabout all cheques that have been deposited until the cheque expires�

RejectTable The clearing uses this table to store cheques rejected for some rea�son during the validation process�

��

Chapter �� Functional Description CAFE Final Report Volume II

BlackListTable The clearing maintains a list of double spent cheques� This listis stored in this table�

�� Some Clearing Issues

In this section some of the key issues that had to be taken into account whendesigning the clearing architecture� are discussed in some detail�

�� Clearing and Settlement

When a cheque has been validated the claim represented by the cheque mustin some way be covered� In the CAFE clearing architecture we have speci�ed amultilateral netting scheme�

The clearing maintains clearing accounts for each participating bank� Abank will normally act both as an issuer and an acquirer of cheques� For eachcheque submitted for clearing� a transaction record will be added to the issuer�sand acquirer�s clearing accounts� The amount on the cheque will result in acredit 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 makingthe net balance less than the gross value of claims and debts� Credit and debitentries will always exist in pairs making the net balance of all clearing accountszero�

Periodically� the clearing will compose a settlement request� This request iscomposed by balancing each clearing account and consists of a credit or debittransaction for each bank acting as issuer or acquirer� Some banks will be netcreditors and some will be net debitors� This settlement request is sent to thesettlement bank which credits or debits each bank�s account�

The clearing of cheques ensure that only a minimum of funds have to betransferred during settlement between two banks since the clearing �rst cancelsmutual claims� In a multilateral netting scheme all banks are represented atthe same time and place by the settlement bank� This permits each bank tosettle his net debt or claim by a single transaction�

�� Double Deposits

It is possible that a payee deposits the same cheque several times to the ac�quirer or to several di�erent acquirers� This might be due to a communicationsproblem or a malicious attempt by the depositor to claim the value of a chequetwice� 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 preventsuch double deposits� so this has to be detected by the clearing before clearingof the cheque�

The clearing maintains a database table� DupChequeTable� with necessaryinformation about all cleared cheques� During validation of a cheque� this tableis queried to see if the cheque has been cleared earlier� The validator looksin DupChequeTable for a cheque with IBankId� KeyVersion� PayeeId and mcorresponding to the cheque currently being validated� Here m can be thought

�

CAFE Final Report Volume II �� Some Clearing Issues

of as a �payment transaction identi�er� which is computed from values encodedin the cheque�

If a row with matching attributes is found in DupChequeTable it is knownthat the cheque currently being cleared has previously been deposited� Thecheque is then rejected by the clearing system with a noti�cation to the acquirer�

�� Double Spending

Traditional cash� in the form of coins and notes� have the property that it isvery hard to copy� Information stored in a digital computing device can on theother hand be copied very easily� When a bank note is given away� it is goneand can�t be spent again� However� when the note is represented as a string ofbits� it is hard to prevent the payer from retaining a copy of the note when itis 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 deviceto prevent copying of electronic currency� The electronic currency is stored inthis device and can only be handled by a few well de�ned functions as de�nedby the CAFE protocols described in Part III� Speci�cally� the device does notpermit the user to spend the same currency twice�

Since it is hard to quantify exactly how tamper resistant such a devicereally is� the CAFE payment system also incorporates a fall back mechanismfor detection of copied cheques after the fact in case a device is broken� Ifsomeone manages to copy electronic currency� the system should at least beable to detect this�

Detection of Double Spending In a manner similar to detection of doubledeposits� the validator will query DupChequeTable to see if a particular chequebeing cleared have been spent in another payment transaction� The validatorlooks in the database for a row with attributes IBankId� KeyVersion� i and ��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 �� is a cheque identi�er while i identi�es which part of the k�spendable cheque that has been spent�

When a double spent cheque has been detected� the clearing will follow oneof two possible procedures� If the cheque has previously been blacklisted� itwill be rejected with a noti�cation to the acquirer� In this case the payee willhave to take the loss since he is responsible for checking the blacklist during apayment transaction� Blacklisting of cheques is described below�

If the double spent cheque was not blacklisted� the cheque will be clearedjust like any other cheque since in this case the payee was not able to distinguishbetween a valid cheque and a double spent cheque� The issuer will have to takethe loss� By combining elements of the two instances of the same cheque thevalidator 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 actionsagainst the double spender� The validator will also blacklist the cheque toprevent further spending of it�

��


Blacklisting of Cheques A database table� BlackListTable� of cheques thathave been double spent is maintained by the clearing� This table will be dis�tributed to payees via the acquirers� If the tamper resistant devices are notbroken� this table will be empty� The goal of the blacklist is to prevent furtherspending of a cheque if the clearing has detected that this cheque already hasbeen spent twice�

The payees are responsible for checking all received cheques against theirlocal copies of the blacklist during the payment protocol� If a blacklisted chequeis detected� the payee aborts the payment protocol at an early stage� If thepayee fails to check received cheques against the blacklist� these cheques will berejected by the clearing and the payee will have to take the loss�

When the clearing detects a double spending� the cheque will immediatelybe added to the blacklist� Since payees operate o� line� it will however takesome time before the local copies of the blacklist maintained by each payeeare updated� The clearing must allow for this delay when rejecting blacklistedcheques� If a cheque is added to the blacklist at a certain time T � the clearingshould not reject clearing of additional copies of this cheque deposited beforetime T # � where � is the time required for distribution of the blacklist�

Longevity of Cheques and Database Size There are several reasons forlimiting the longevity of cheques used in the payment system� In this section wewill 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 inSection ��

If cheques don expire some tables such as DupChequeTablewill grow withoutbounds� By limiting the longevity of cheques we can remove expired chequesfrom these tables and thus limiting their size�

Expiration of cheques does not imply that payers run the risk of loosingmoney� It is not the money that expires�only the cheques� Cheques don�trepresent value�only the ability to perform payment transaction� This abilitycan be regained by withdrawing new cheques� This is similar to the situationtoday with expiring payment card� The card represents the ability to pay andnot an intrinsic value�

The longevity of cheques is limited by limiting the lifetime of the crypto�graphic keys used for encoding of the cheques� The key management systemfor the CAFE payment system is described in Part VI�

�� Currency Exchange

The CAFE system supports two di�erent mechanisms for currency exchange�

�� During a withdrawal transaction an amount in a foreign currency can bewithdrawn� Payment transactions can then be performed in the payee�slocal currency or any other currency withdrawn by the payer as long asthis is accepted by the payee�

�� An exchange is performed at payment time� The payee requests paymentin his local currency while the payer pays using a di�erent currency�

��

CAFE Final Report Volume II �� Clearing System Procedures

To perform multicurrency clearing� the clearing will for each issuer or ac�quirer maintain one clearing account for each currency this role issues or accepts�Credit and debit entries will be added to the clearing accounts correspondingto the currency used in the payment�

For the �rst method of currency exchange� this is the only required modi��cation to the clearing infrastructure� The issuer will issue �or sell� a foreigncurrency� Cheques spent by the payer using this currency will later be to debitedthe issuer�s clearing account corresponding to this currency�

Exchange during payment requires some additional involvement by theclearing infrastructure� In the payment transaction� the cheque is written outwith two amounts and currencies� The amount paid by the payer and theamount received by the payee� Exchange rates for such payments are issuedwith a certain validity period by the payee�s acquirer� When a cheque is de�posited� the acquirer will verify that the correct exchange rate is used�

The clearing will treat the cheque just like any other cheque with two ex�ceptions� 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 beencleared� The acquirer�s clearing account has been credited in the payer currencywhile 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 setof exchange rates are speci�ed� the acquirer commits to buying currencies atthese rates at a later time�

Exchange during payment can also be realized in a similar manner withexchange rates speci�ed by the payee� Instead of �selling� a currency at anexchange rate predetermined by a particular acquirer� the payee will sell hisforeign currency at the current market rate� and he will be able to go to the ac�quirer o�ering the best rate as no prior arrangement is required� This exchangemethod is however not presently speci�ed for the CAFE payment system�

�� Clearing System Procedures

In this section a sequential description of the procedures performed by theclearing infrastructure is given�

�� Clearing of Cheques

In the following description of the processing activity performed by the clearinginfrastructure� each item corresponds roughly to one functional unit in theclearing infrastructure�

Deposit The acquirer receives a batch of cheques in a deposit transactionfrom the depositor �the payee�� An initial screening of the received chequesis performed to weed out invalid cheques as early as possible� This screeningconsists 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

��


not strictly required as all aspects of the cheques will be veri�ed later by thevalidator�

The acquirer assigns a unique cheque identi�cation number� CNo� to eachcheque before storing them in the database table ChequeTable� The cheques willbe kept in ChequeTable until clearing is �nished and the depositor�s account hasbeen credited�

The cheques are also added to DepositTable which is a table of chequeswaiting to be sent to the clearing center in a clearing request�

Send clearing request Triggered by some external event� for instance asignal at the end of the day� the acquirer will collect a batch of cheques fromDepositTable� This batch is identi�ed by a number� SubmissionNo� allocated bythe acquirer� Both SubmissionNo and the identity of the acquirer are appendedto each cheque in the batch� The batch is then sent to the clearing in a clearingrequest�

The batch of cheques is removed from DepositTable and inserted into thedatabase table ClearingTable� This database table contains all cheques that havebeen 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 thebatch of cheques in a clearing request from the acquirer� All cheques to�gether with CNo� SubmissionNo and ABankId are added to a database table�ClearChequeTable� which is the main database table in the clearing� A valida�tion number� ValNo� is assigned by the clearing administration to keep track ofthis 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 thefollowing tests are performed�

�� The formatting and encoding of the information in the cheque is veri�ed�

�� The validity of the exchange rate used during payment is veri�ed�

The validator now retrieves the cryptographic keys corresponding to theissuer of the cheque and the key version number� Both the issuer identity andkey version number are encoded in the cheque� Now the following tests areperformed�

�� It is veri�ed that the cheque has not expired� The validity period of acheque corresponds to the validity period speci�ed for the cryptographickey used�

�� The cryptographic properties of the cheque are veri�ed� This is basicallythe same veri�cation as the one speci�ed for the payee during the paymentprotocol�

��


The validator is now satis�ed that the cheque was issued in a correctlyexecuted withdrawal protocol and that it was spent in a correctly executedpayment protocol� It remains to determine if the cheque has been previouslycleared�

The validator will now search his database table� DupChequeTable� for acheque matching certain �elds in the cheque being validated� If a match isfound the validator is able to conclude that this cheque has previously eitherbeen deposited by the payee or submitted by the acquirer� The cheque isrejected�

If the cheque is not rejected� the validator again searches DupChequeTable�now with a di�erent search criteria� If a cheque matching certain �elds inthe cheque being validated is found� the validator is able to conclude that thecheque has been spent in two di�erent payment transactions� This is termed adouble spending and indicates that the tamper resistance of the payer�s walletis broken�

If a double spent cheque is found� the validator will check the databaseof blacklisted cheques� BlackListTable� to determine if the cheque is alreadyblacklisted� If the cheque is not found in the blacklist� it is added� The validatorwill use the two instances of the double spent cheque to compute the identityof the double spender and include this in the validation status� Handling ofdouble spent cheques is discussed in more detail in Section ��

Finally the cheque being validated is added to DupChequeTable� A messageindicating the individual validation results for each cheque in the submittedbatch is constructed and returned to the clearing administration�

Receive validation status When the clearing administrator receives thevalidation results� all cheques that were either found to be valid or double spentbut 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 eachcheque� Any double spent cheques not previously blacklisted will carry a vali�dation status of �valid� in this message� Any other invalid cheques will carry arejection status indicating the reason for the rejection�

If double spent but not previously blacklisted cheques are reported� thesecheques together with information about the identity of the double spender� issent to the issuer�

Clearing Triggered by some external event� the clearing entity will take abatch of cheques from ClearingTable� For each cheque the clearing account ofthe issuer will be debited while the clearing account of the acquirer will becredited the amount on the cheque� Each bank has one clearing account foreach currency used�

At the end of the clearing period� the clearing entity will compute thenet claim or debt for each clearing account by summation of all transactionsrecorded in the account� A settlement request is sent to the settlement bank�This request contains one amount for each currency for each participating bank

��


indicating credit or debit to this bank�s settlement accounts� The clearing ac�counts are then reset�

Clearing and settlement are discussed in more detail in Section ��

Settlement The settlement bank receives the settlement request from theclearing� It veri�es the claim or debt by each account holder indicated in therequest and that all claims and debts net to zero� The settlement accounts arethen updated according to the settlement request�

Receive clearing status The acquirer receives the clearing status from theclearing� Rejected cheques are stored in a database table� RejectTable� whichwill later be used to inform the depositor about the clearing status of thecheques�

Accepted cheques are transferred to TransTable for later crediting of thedepositor�s account�

Crediting Triggered by some external event the acquirer will take a batchof cheques from TransTable and credit the amounts to the account�s of thedepositors�

�� Blacklist Distribution

The clearing maintains a blacklist of double spent cheques that have not yetexpired� This list is distributed to payees to prevent such cheques to be spent anin�nite number of times� This section describes the distribution of the blacklist�

The blacklist of double spent cheques is maintained by the validator� Trig�gered by some external event the validator will copy all cheques stored in thetable BlackListTable and send this list to all acquirers� This list will be empty ifthe tamper resistance is reliable� The message will be timestamped and signedby the clearing�

The acquirers store the received blacklist with timestamp and signature�This blacklist will then be sent to depositors on request�typically when adeposit is made� When a depositor receives a new copy of the blacklist� any oldblacklist stored is deleted�

�� Loss Recovery and Refund

The CAFE payment system supports recovery of money in a lost or destroyedwallet� For loss recovery the unlucky payer visits the issuer� A protocol isexecuted between the payer and the issuer to determine the total amount andthe cheque identi�ers� �� of all cheques stored in the wallet just after the lastwithdrawal� This protocol is described in Part III�

Using the obtained information about the state of the wallet after the lastwithdrawal� the issuer can turn to the clearing to obtain information requiredto �nd the current state of the wallet� The cheque identi�ers� �� are sent to theclearing in a recovery request� This request is handled by the validator whichstores the received identi�ers in a database table� RecoveryTable�

��


Triggered by some external event� the validator will start removing ex�pired cheques from DupChequeTable� The removed cheques are kept temporar�ily in a di�erent database table� With the aid of this temporary table andRecoveryTable� the clearing constructs a table of all cheques for which someissuer has requested recovery information� This information is then sent to therequesting issuer in a recovery response message�

The recovery information received by the issuer contains the amount forwhich each cheque has been spent� With this knowledge combined with knowl�edge of the balance in the wallet after the withdrawal� the issuer is able tocompute the remaining value in the wallet� This remaining balance can safelybe refunded since the lost wallet now only contains expired cheques that can�tbe used�

The issuer will have to make sure that additional cheques can�t be withdrawnusing a lost wallet if it is later found� The issuer prevents further withdrawalsby removing the wallet public key from it�s customer database� A new publickey will be added for the wallet replacing the lost wallet�

��


�


Chapter ��

Properties of the Clearing

System

The previous section has focused on the functionality of the clearing infrastruc�ture� In this section we will look into some of its properties�

�� 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 de�nedby the clearing architecture and the risks these roles are exposed to� Thesettlement bank will not be discussed further since it just carries out requestsplaced by others�it has no interests that have to be protected�

The issuer The issuer has to trust the clearing to perform a correct validationof cheques and only to clear validated cheques� The issuer also has to trust theclearing to return correct information about spending of cheques for whichrecovery information have been requested during a loss recovery operation�

The generalized clearing architecture described in Section �� removes thistrust 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 spentcheques that have not yet been blacklisted� The issuer will thus run a signi�cantrisk if the tamper resistant device can be broken� The clearing must be trustedby the issuer to maintain the blacklists correctly to reduce this risk somewhat�

�

Chapter �� Properties of the Clearing System CAFE Final Report Volume II

The acquirer The acquirer accepts a risk when currency exchange is per�formed during the payment transaction� The acquirer has to commit to anexchange rate which will be valid for some time� The actual currency exchangewill take place later at a slightly di�erent rate which will represent either a lossor a gain for the acquirer�

The acquirer can reduce the risk by only accepting certain foreign curren�cies with su�ciently stable exchange rates or by specifying an exchange ratesu�ciently in the favor of the acquirer to reduce the chance of a loss in case ofrate changes�

The Payer The clearing will reveal the identity and secret key of doublespending payers during the validation of a cheque� Such payers will have totrust 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 onbehalf of this payer�

With currency exchange during the withdrawal transaction� the payer mustaccept the risk of holding foreign currencies� The currency exchange is per�formed during withdrawal while the payment is performed at a later time� Thecurrency exchange rate is then likely to have changed and this will represent aloss or a gain for the payer�

The payee The payee will have to trust the clearing infrastructure to dis�tribute blacklists in a timely fashion� Without updated blacklists the payeecannot accept payments without risking having the cheques rejected by theclearing due to double spending�

�� Fault Tolerance

We have seen how the clearing will assist in the loss tolerance in the paymentpart of the system� In this section we will outline how the clearing handlesinternal faults�

In the clearing the communication between entities takes the form of re�quests and responses� The depositor requests settlement of a cheque� and theacquirer responds by crediting the depositor�s account� The acquirer handlesthe request by the depositor by requesting clearing from the clearing whichresponds with clearing between issuer and acquirer� and so on�

The fault tolerance strategy of the clearing infrastructure is that all roles areresponsible 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 responsehave been received within a certain time�

It is ultimately the depositor that will carry the responsibility of having acheque cleared and settled� The depositor must keep a cheque until he has beencredited so that the cheque can be resubmitted in case of a fault somewhere inthe clearing infrastructure�

This fault tolerance strategy assumes that requests awaiting con�rmationare stored in a stable manner� This will be ensured by using standard database

�

CAFE Final Report Volume II �� Capacity

mechanisms and is outside the scope of this document�

�� Capacity

The clearing architecture described here does not scale very well and will su�erfrom capacity problems once the volume of transactions gets su�ciently large�In Section �� the generalized clearing architecture will be described� This isa distributed solution where additional �clearing nodes� can be added as thetransaction volume grows�

�� Truncation and Accumulation of Cheques

A payment system that allows the issuer and the acquirer of prepaid chequesto be economically distinct will have to deal with the fact that the issuer willgenerally not trust the acquirer when the latter presents a claim for settlementof a cheque� The cheque will then have to move through the entire clearinginfrastructure and eventually be returned to the issuer for inspection before theclaim is settled�

Cheque truncation means that cheques does not have to move through theentire clearing infrastructure� A high proportion of the acquired cheques willprobably be �on us�� that is� the issuer and the acquirer might be di�erentbranches within the same bank� In this case there exists a trust relation betweenissuer and acquirer� Generally cheques can be truncated by a role if the issuercan trust this role�

To maximize communications� storage and processing e�ciency it is impor�tant to truncate cheques as early as possible� If all cheques were truncated atthe acquirer�s site� the clearing could be reduced to a minor bookkeeping taskbetween the issuers and acquirers� However� the problem is fundamentally oneof mutual trust and integrity� How can the issuer be certain that the claimpresented by the acquirer is valid without inspecting the cheque'

In the clearing architecture described here cheques are truncated in theclearing� This might not be acceptable in a full scale� real world clearing infras�tructure� The generalized clearing architecture discussed in Section �� is more�exible with regards to where cheques are truncated�

��

Chapter �� Properties of the Clearing System CAFE Final Report Volume II

��


Chapter ��

Distributed Clearing

So far we have discussed a centralized clearing architecture where cheques aretruncated at the clearing� There are at least two shortcomings to such anarchitecture� First and foremost� the processing of cheques is centralized� Whenscaled to a European�wide system� the bottlenecks will certainly manifest itselfin the hub of the system� We have to address the problem of scalability�

Second� the trust assumptions that have to be acclaimed for a centralizedclearing architecture leave much to be wanted in an environment of compet�ing crossborder payment services envisioned by CAFE� We have to address theproblem of trust among the roles of the clearing infrastructure�

Hence� we provide a generalized architecture for a clearing infrastructurewhich address these problems� Note that the clearing infrastructure describedpreviously can be considered a special case of the clearing described here�

�� Overview of the Model

The generalized clearing infrastructure is organized as a tree or hierarchy ofclearing nodes� A node in the tree is envisaged in Figure ��

A clearing node has a single connector to a parent node� and a number ofconnectors to child nodes� The top level �root� node does not have a parentconnector� and the leaf nodes don�t have child connectors�

The clearing node can connect to a settlement entity� where it can requestthe settlement entity to do transfer of funds between any of the child nodes and

Settlement

Higher node

Lower nodes

Accounts database

Clearing accounts

Cheque database

Validation entityClearing &

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

Figure �� A general node in the clearing hierarchy�

��

Chapter �� Distributed Clearing CAFE Final Report Volume II

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 byconnecting to a cheque validation entity� This entity will then be able to performvalidation of the cheques issued under its clearing domain� The procedure ofvalidation includes veri�cation of cryptographic properties� and checking fordouble deposit or spending�

�� Functional Description

This section outlines one possible procedure for clearing� and speci�cally how acheque 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 willbe batched for e�ciency reasons�

We use the terms subtree and common node in the description� The subtreeof a node N is the tree of nodes where N is the root node� The subtree of aleaf node will consist of only the leaf itself�

A node N is called a common node of N� and N� if both node N� and N�

are in the subtree of node N � The root node is a common node of all nodes inthe tree�

�� The cheque will enter a node by a deposit from a depositor to the acquirerrepresented by this node�

�� The cheque is moved �up� until it reaches a common node of the issuerand the acquirer which has the issuer�s clearing entity in its subtree�

�� The cheque is moved �down� towards the issuer until it reaches the nodewith the issuer�s clearing entity�

�� This node checks the cheque and produces a validation response�

�� The validation response is moved in the reverse path until it reaches thecommon node of the issuer and the acquirer� then �down� to the nodewhere the cheque entered the clearing system� On its way� every node inthe path a�rms the validation received and the clearing entries are made�

A settlement request will eventually be produced by a clearing node� re�questing 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 numberof accounts� Instead� the money will ��ow� through all the nodes along thepath�

We expect that the bulk of payment transactions will be �local� to a sin�gle 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� withpossible exceptions such as special tourist areas and airports�

��

CAFE Final Report Volume II �� Properties of the Generalized Clearing Architecture

�� Properties of the Generalized Clearing Archi

tecture

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� theacquirer will only depend on its association with its clearing node for vali�dation of cheques� because the validation response will be transferred andcon�rmed through a �validation path� of clearing nodes structured in ahierarchy�

Scalability Banks can easily attach or detach from a clearing node and onlylocal updating will be necessary� Additional clearing nodes can be addedwith only local restructuring needed� The clearing infrastructure will bedistributed and not dependent on a single hub� And local transactionscan be processed locally� thus avoiding central bottlenecks and providingfor optimal transaction processing�

Cost e�ectiveness The validation of cheques is the single most demandingfunctionality with respect to storage� In the proposed structure� thiswill take place in or close to the issuer� Accordingly� it will be easy toidentify and place the cost of this on the issuer� As a result� an issuer willincur cost proportional to the size of the issuing� which seems to be quitereasonable�

��

Chapter �� Distributed Clearing CAFE Final Report Volume II

��


Part VI

Key Management

��


Chapter �

Introduction

�� Overview

This part speci�es the architecture of the key managemenet system for the �system� where purse and observer are implemented as distinct hardware de�vices� The key management system for the � and �� systems is speci�ed inChapter ��

The organization of this speci�cation is centered around the presentationof the parameter classes and their processing and distribution� A graphicalnotation is used to describe the generation� certi�cation and distribution foreach class of parameters�

The main components of the architecture are presented in this chapter�Chapter � gives speci�cations for each parameter class with an introductorysection on the graphical notation used� Chapter � presents how wallets areactivated� Chapter �� discusses the management of concurrently valid versionsof keys� Chapter �� runs through a security analysis of the key managementsystem�

�� Entities and Functionality

The foregoing protocol description uses a somewhat simpli�ed list of roles andentities� but in the discussion of the key management system some more detailsare required� This is necessary to facilitate descriptions of some subtle relationsbetween these roles and entities� and key management is all about such relations�

�� Roles and Functional Entities

Table �� shows the complete list of roles and functional entities in key man�agement system� This is an extended version of Table �� For the administra�tors we use the same names for both roles and functional entities due to theone�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 a�liated wallets�Furthermore� the reload station� recovery station and activation station of anissuer is commonly referred to as the issuer station of this issuer�

For the administrators the same names are used for both the roles and thecorresponding functional entities due to the one�to�one relationship betweenroles and entities�

�


Users Roles Functional entities

Bank Issuer Reload stationRecovery stationActivation stationObserverAuxiliary observerA�liated observer

Acquirer Acquire stationClearing Clearing system

Individual Payer PurseMerchant Auxiliary purse

A�liated pursePayer station

Payee Till

Administrator System operator System operatorCentral certi�cation authority Central certi�cation authorityRealm certi�cation authority Realm certi�cation authorityDirectory Directory

Factory Manufacturer Manufacturer

Table �� Users� roles and functional entities in the key management sys�tem�

Below we brie�y describe the new roles introduced by the key managementsystem and how the old roles relate to the key management system�

System operator A single system operator is responsible for the generationof systemwide parameter values�

Central certication authority A single central certi�cation authority con�stitutes the top level of the CAFE certi�cation hierarchy� This authoritymust be trusted by all other roles to issue certi�cates only as speci�ed inthis description�

Realm certication authority Multiple realm certi�cation authorities con�stitute the second level of the CAFE certi�cation hierarchy� These au�thorities are authorized by the central certi�cation authority and must betrusted by all roles to only issue certi�cates as speci�ed in this description�

Directory A data base for archiving certain public keys and parameters withcerti�cates� to be accessed later by other entities of the key�managementsystem� for instance� for updating or in case of dispute�

Issuer Several issuers of electronic currency exist� where each issuer is associ�ated with one and only one realm certi�cation authority�

Acquirer Several acquirers of electronic currency exist� where each acquirer isassociated with one realm certi�cation authority�

�

CAFE Final Report Volume II �� Entities and Functionality

Clearing system The clearing system performs the �nal validation of chequesas well as clearing and settlement between the issuers and acquirers�

Some new functional entities have been introduced to re�ect that the issuerand payer controls di�erent kinds of observers and purses respectively� Belowwe describe how some of the functional entities relate to the key managementsystem�

Purse This is the payer controlled part of the wallet� Each purse is associatedwith a single payer� an observer and an issuer� The purse is trusted bythe payer�

Observer This is the issuer controlled part of the wallet� Each observer isassociated with a single purse� a payer and an issuer� The observer isencapsulated in a tamper resistant device trusted by the issuer� typicallya 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 functionallyequivalent to a normal purse or it may be a special recovery purse onlyused during execution of the recovery transaction� This entity is trustedby 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 befunctionally equivalent to a normal observer or it may be a special recov�ery observer only used during execution of the recovery transaction� Thisentity is trusted by the issuer�

A�liated purse Each � wallet can have an a�liated � wallet� This is thepurse part of this a�liated wallet� It is trusted by the payer controllingthe � wallet�

A�liated observer This is the observer part of an � wallet a�liated 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 apayee and an acquirer�

Manufacturer This entity controls the manufacturing of observers�

In the key management system keys and parameters are owned and con�trolled by functional entities� The distinction between whether keys are ownedby entities or roles is only of importance with respect to the observers� An ob�server 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 informa�tion� including key information� to the other entities controlled by the issuer�

� �


�� Functionality

The functional entities identi�ed and listed above provide the functionality ofthe CAFE key management system� The functionality description of each keymanagement parameter class� found in Chapter �� is organized according tothe following items�

Generation The functional entity responsible for generating and assigning avalue to the parameter instance is speci�ed in this item� A brief descrip�tion of the type of parameter and how it is generated is also given�

Certication and registration Keys and parameters values must normallybe certi�ed to be trusted by a receiving entity in the CAFE paymentsystem� In a certain sense� a certi�ed key corresponds with the issuing ofa credential giving the right to perform certain operations�for instancethe right to issue electronic currency� Only registered entities can begranted such rights by certifying the link between the entity�s name andthe parameter value�

Use This item gives a brief description of how and in which protocols the keymanagement parameter is used�

Distribution and updating This item describes how the key managementparameter is distributed from the generating entity to other functionalentities�

Archiving Some parameters must be archived for �on demand� distributionand later settlement of disputes that might arise�

Revocation Most key management parameter values have a limited validityperiod assigned� but ad hoc revocation must sometimes also be available�

The operations of generation� registration� certi�cation� distribution� andrevocation are a subset of the key management operations listed in the standardISO IEC �� ISO��

�� Identity Management

In the key management speci�cation we have assumed that each functionalentity is associated with an identi�er� There must exist an entity responsiblefor creating and managing such identi�ers� This entitiy and its functionality areoutside the scope of this discussion� The directory might be a likely candidatefor identity management in the CAFE system�

�� Certi�cation Hierarchy

�� Certi�cates

An important design goal for the CAFE payment system is to keep to a minimumthe need for trust assumptions between entities� Instead� we rely on veri�able

� �

CAFE Final Report Volume II �� Certication Hierarchy

transactions by employing many kinds of digital signatures� The integrity andauthenticity of the key management parameters themselves are obtained bycerti�cation by a hierarchy of common trusted entities�

A certi�cation authority will use its digital signature to issue a certi�cateon a parameter value concatenated with other data� such as the entity namesand period of validity� Table �� summarizes the data elements required in aparameter certi�cate� Table �� shows the di�erent types of certi�cate types�

The contents of certi�cates speci�ed here �ts rather well with the X�� recommendation �ISO�� We use a parameter type identi�er and a parameterversion number in addition to the certi�cate format speci�ed by X��

Data item Description

type Parameter type identi�ervalue Parameter valuevalid Validity period of the certi�cateowner The identity of the functional entity having gen�

erated the parameterversion The version number of this parameterauthority The identity of the authority having certi�ed the

parametersignature A digital signature generated by the certifying

authority on the data in the certi�cate

Table �� Data elements in a parameter certi cate�

Type id Description

certificate key Realm certi�cate veri�cation keyclearing key Clearing system veri�cation keysystem parameter Systemwide crypto parametersmax parameter Non�cryptographic parameters� maximum

valuesissuer auth key Issuer authentication keyissuer cheque key Issuer cheque veri�cation keyobserver key Observer veri�cation keypurse key Purse deblinding keyacquirer key Acquirer veri�cation key

Table �� Certi cate types�

�� Hierarchy

In an open system such as the CAFE payment system� it is infeasible to requirethat all functional entities will store all keys and parameters they eventually

� �


will need� Many sets of keys and parameters are therefore carried in the formof certi�cates� An initiator of a transaction will on demand send certi�cates toother entities participating in the transaction�

The CAFE key management system uses a hierarchical certi�cation architec�ture with entities in three levels� as shown in Figure �� A central certi�cationauthority constitutes the top level of the certi�cation hierarchy� This entity cer�ti�cates systemwide parameters and realm certi�cate veri�cation keys�

The next level contains a number of realm certi�cation authorities� Theseauthorities certify the keys and parameters generated by the principal entitiesin the payment system� such as issuer stations� observers and purses�

The principal entities of the CAFE payment system are found at the bottomlevel of the certi�cation hierarchy� These entities generate keys and parametersrequired for the execution of the payment�related protocols� such as authenti�cation of intermediate values and messages�

��

��

��

�SSw

��

�SSw

��

Central certi�cation authority

Realm certi�cation authority

Issuer station� purse� etc

Figure �� Structure of the key management certi cation hierarchy�

The payer�s issuer and the payee�s acquirer will be within the same realmperhaps for most payment transactions� When this is so� the certi�cate veri��cation key of the realm certi�cation authority will almost certainly already bestored with the payee�s till�

If the veri�cation key of the realm certi�cation authority has not been storedlocally� then the certi�cate veri�cation key of the central certi�cation authorityis required to verify the certi�cate of the veri�cation key of the realm� Theveri�cation key of the central certi�cation authority is assumed to be loaded inthe setup of the entity�

The CAFE certi�cation hierarchy is a special case of the certi�cation systemspeci�ed in recommendation X�� ISO�� The standard X�� permits ageneral certi�cation structure that can be modelled as a directed graph withentities as nodes and certi�cation relations as edges� This graph reduces toa tree with a speci�c number of levels in the CAFE key management system�ISO IEC standard �� ISO�� describes a key distribution hierarchy alongthe same lines as used in CAFE�

�� The Directory

The directory will be accessed by other functional entities� The access operationmust be controlled with respect to the access rights assigned to the entity in

� �

CAFE Final Report Volume II �� Certicate Classes

advance� The registration of entities and the access control is performed by thedirectory itself� Although this speci�cation refers to a single entity� there is norestriction to implement this as a distributed data base system�

�� Issuer Certi�cation

The certi�cation of a cheque veri�cation key of an issuer should be interpretedas a certi�cation of the issuer to be a member of the CAFE clearing club inthat realm� As such� a payee�s veri�cation of the issuer�s cheque veri�cationcerti�cate is a test on whether the cheques presented can be expected to clearthrough the acquirer� Note that this certi�cation does not link the issuer to theright of issuing electronic currency denominated in speci�c national currencies�For this link to be certi�ed� an extension to the certi�cation hierarchy must becalled for� One approach to this would be to introduce another realm authoritytype� so that the two types will be

�� Banking realm certi�cate�

�� Currency realm certi�cate�

A certi�cate of the issuer�s cheque veri�cation key must then be able to containdigital signatures of several certi�cation realms� as the need may be�

�� Certi�cate Classes

We now present the classes of keys and parameters that are managed by theCAFE key management system� Some of these classes are introduced by thepayment protocols� while others are a result of the key management systemitself�

Central certication A single central certi�cation key pair constitutes thetop of the CAFE certi�cation hierarchy� This key pair is used for certi�ca�tion of systemwide keys and the veri�cation keys for the realm certi�cationauthorities�

Realm certication A number of realm certi�cation key pairs exist consti�tuting the second level of the certi�cation hierarchy� These keys are usedfor certi�cation of keys generated by functional entities directly involvedin the payment protocols�

Clearing system signature A clearing system key pair exists for signatureson black lists of double spent cheques�

Systemwide crypto parameters A number of systemwide parameters de�n�ing certain properties of the cryptographic systems used is required by thepayment system�

Issuer authentication An issuer station will use this kind of key pair to en�able authentication of identity and messages�

� �


Issuer cheque signature An issuer station will use this kind of key pair forthe authentication of valid cheques�

Observer signature An observer will use this kind of key pair for authenti�cation of messages sent by the observer� This key is also used to identifythe payer associated with a particular observer�

Shared parameter A parameter shared between an issuer station and a wal�let� This parameters can only be computed after the issuer cheque signa�ture key and the observer signature key are computed�

Observer PRSG parameters This type of parameter de�nes the pseudo�random sequence generator in the observer�

Purse blinding The key used by a purse to blind messages sent by the ob�server and the corresponding public key for veri�cation of proper blinding�

A�liated card signature Similar to the observer signature key but installedin a smart card a�liated to the wallet�

Non cryptographic parameters Various system parameters that do not havecryptographic relevance� These parameters determine various limits� suchas the largest value that can be stored in a wallet� or the maximum amountthat can be paid in a single payment transaction�

Acquirer signature Keys used by the acquirers to commit to a set of currencyexchange rates�

Figure �� summarizes how values of these parameter classes are certi�edin the CAFE certi�cation hierarchy� Only parameter classes shown in this �gureare certi�ed�

The parameters max pay � max ticks and max trans belong to the class ofnon�cryptographic parameters� The parameter max trans is the only parametercerti�ed on a fourth level in the certi�cation hierarchy� This level also includes aplethora of intermediate values and messages authenticated by third level keys�These are all described in detail in the protocol description and are not shownhere�

� �

CAFE Final Report Volume II �� Certicate Classes

Systemwidecrypto params

max_paymax_ticks

Realmcertification

Clearingsignature

Issuerauthentication

Observersignature

Purseblinding

Acquirersignature

Issuer chequesignature

Central certification

max_trans Sharedparameter

Affiliatedwallet signature

Figure �� Location of parameter classes in the key certi cate hierarchy�

� �


�


Chapter �

Parameter Classes

�� Notation

We will describe the parameter distribution in the key management systempartly by utilizing a graphical notation� where boxes indicate entities and arrowsindicate �ow of a parameter values� We use the following symbols to indicatethe actions performed by various entities on the parameter sets�

� Indicates generation of a set of parameters�

� Indicates certi�cation of a set of parameters�

� Indicates storage or use of a set of parameters�

A small plus sign ��#�� may be put at the pointing end of an arrow toindicate a �one�to�many� �ow� An example of this is shown in Figure ��Here data from one entity of type A goes to many di�erent entities of type B�

�� Central Certi�cation

�� Generation

The single central certi�cation authority constitutes the top of the certi�ca�tion hierarchy� This authority has an RSA type key pair �mC � eC � dC� where�mC � eC� is the public central certi�cate veri�cation key and dC is the corre�sponding secret signature key� The key pair is uniquely identi�ed by a versionnumber vC �

The central certi�cation key is generated by the central certi�cation author�ity itself� The public exponent is �xed eC ! �� Generation of RSA type keys isdescribed in Section ��

A B+

Figure �� Example of a one�to�many distribution�

�

Chapter �� Parameter Classes CAFE Final Report Volume II

�� Certi�cation and Registration

This key constitutes the top of the certi�cation hierarchy in the CAFE ar�chitecture and hence cannot be certi�ed by other mechanisms within the keymanagement system described here� The central certi�cate veri�cation key caneither be certi�ed by an external electronic certi�cation mechanisms based ondigital signatures� or it can be �certi�ed� by distributing the key by a schemewhich makes it infeasible for an unauthorized entity to convince others to usea forged key� One example of this kind of certi�cation is publishing of the keyby several newspapers concurrently� Another would be to continuously publishthe key over some broadcasting network�

�� Use

The central certi�cate signature key is used by the central certi�cation authorityto make certi�cates of the public keys of the realm certi�cation authorities� theclearing system� the systemwide crypto parameters generated by the systemoperator� and some of the non�cryptographic parameters� See Figure ��

The central certi�cate veri�cation key is required for veri�cation of thesecerti�cates� It is also required by entities performing veri�cation of certi�catesissued by foreign realm certi�cation authorities due to the hierarchical certi�ca�tion structure� This means that all functional entities involved in the paymentsystem� clearing and key management must have access to the central certi�cateveri�cation key�

�� Distribution and Updating

Figure �� summarizes the distribution of the central certi�cate veri�cationkey� The key is generated by the central certi�cation authority and sent to thedirectory 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 freelyreadable area of the observer and can later be veri�ed by the payer� If asu�cient number of payers verify their key� a cheating manufacturer will bedetected with high probability� The central certi�cate veri�cation key will notbe updated in an observer during its lifetime�

Activation stations install the key in purses during the activation process�The key can be veri�ed by the payer by comparing it with the key installed inthe observer� A complete reactivation including an update of this key will beperformed when a new observer is installed in the purse�

The central certi�cate veri�cation key is installed in tills by acquire sta�tions� Acquire stations keep track of which key versions the till has and sends anew key during the �rst deposit transaction following a key update by the cen�tral certi�cation authority� Merchants can read the key and verify its validityagainst the published value�

The central certi�cation authority can introduce a new version of the centralcerti�cate key pair at any time� This key is distributed to manufacturers� issuerstations and acquire stations in the same way as outlined above� Manufacturers

��

CAFE Final Report Volume II �� Central Certication

Manufacturer

TillPurseObserver

Directory

Central Cert

+

+ +

+

++

Issuer Station Acquire Station

Clearing System

Figure �� Distribution of the central certi cate veri cation key�

will start installing the new key version in new observers� Wallets alreadyactivated will not be a�ected� but activation stations will use the new versionin activation of new purses� Acquire stations install the new veri�cation key intills during the next deposit transaction to enable tills to accept payments fromnew wallets�

Generation and introduction of a new central certi�cation key pair does notrequire updating of other keys or parameters in the system�

�� Archiving

Each version of the central certi�cate veri�cation key is sent to the directoryfor archiving� The key must be certi�ed by an external certi�cation service orthrough publication in newspapers or similar stored in national or internationalarchives�

�� Revocation

A validity period is speci�ed for the central certi�cate veri�cation key� The keyis invalid after the expiry date is reached�

If the secret central certi�cate signature key is compromised� it must berevoked prior to scheduled expiration� This is accomplished by having a keyrevocation message published in the same way as the key itself was originallypublished in the directory�

Revocation of a central certi�cate key pair will render all wallets usingthis veri�cation key useless� These wallets will have to be returned to theirrespective issuers for a refund of the stored wallet balance� A new observermust be issued to the payer and the purse must be reactivated�

��


�� Realm Certi�cation

�� Generation

The realm certi�cation authorities of the CAFE system constitute the secondlevel of the certi�cation hierarchy� Each realm certi�cation authority has itsown RSA type key pair� denoted �mN � eN � dN �� where �mN � eN � is the realmcerti�cate veri�cation key and dN is the certi�cate signature key� The key pairis uniquely identi�ed by the identity of the realm certi�cation authority and aversion number vN �

Each realm certi�cation authority generates its own certi�cation key� Thepublic exponent is �xed for all authorities eN ! �� Generation of RSA typekeys is described in Section ��


Having been generated� the realm certi�cate veri�cation key is sent to the cen�tral certi�cation authority for certi�cation� The central certi�cation authoritymust register the realm certi�cation authority identity and authenticate thesubmitted key� The means for doing this is not contained in this speci�cation�

A certi�cate of type certificate key is issued by the central certi�cationauthority� who returns this to the realm certi�cation authority�

Certi�cates of type certificate key will only be issued to realm certi�ca�tion authorities registered with the central certi�cation authority� The identityof the certi�cation authority is established during authentication by the centralcerti�cation authority� Registration of realm certi�cation authorities is outsidethe scope of this description�

�� Use

A secret realm certi�cate signature key is used to make certi�cates for issuerauthentication and cheque veri�cation keys� acquirer veri�cation keys� obserververi�cation keys and purse deblinding keys�

A wallet needs access to the realm certi�cate veri�cation key associatedwith the actual issuer station� This will be used for veri�cation of issuer keysduring activation� and in responding to a request from a till that does nothave the veri�cation key available� Tills need to be able to acquire certi�cateveri�cation keys for all realm certi�cation authorities� These keys are used toverify certi�cates on all issuer cheque veri�cation keys�

An � wallet a�liated with a � wallet will need the realm certi�cate ver�i�cation key for veri�cation of the certi�cate on the � observer�s veri�cationkey�

The clearing system needs all realm certi�cate veri�cation keys for veri�ca�tion of updated issuer cheque veri�cation keys�


Figure �� summarizes how the realm certi�cate veri�cation key is distributed�The key is generated by the realm certi�cation authority and sent to the central

��

CAFE Final Report Volume II �� Realm Certication

Central Cert

Directory

TillPurse

Observer

+

+

+

Realm Cert

Clearing Syst

Issuer Station

Figure �� Distribution of the realm certi cate veri cation key�

certi�cation authority for certi�cation� The returned certi�cate is forwarded tothe clearing system and all issuer stations under this particular realm certi�ca�tion authority�

The realm certi�cate veri�cation key is installed in purses during activation�The purse validates the certi�cate and forwards it to the observer where it isalso validated and stored� The purse will store both the key and the certi�cate�Realm certi�cate veri�cation keys will not be updated in activated observers�

A till can request the realm certi�cate veri�cation key from the purse dur�ing a payment transaction� The purse forwards the certi�ed key and the tillvalidates and store it� This is done by executing the get certif protocol�

A new realm certi�cate key version can be introduced by a realm certi��cation authority at any time� with the same procedure for certi�cation anddistribution as for the �rst version� Activation stations will use the new versionof the veri�cation key in the activation of new wallets� Wallet already activatedare not a�ected�

Generation and distribution of a new realm certi�cate key pair does notrequire updating of any other key or parameter in the system�

�� Archiving

The central certi�cation authority will forward each new version of a realmcerti�cate veri�cation key to the directory�

��


�� Revocation

The validity period is encoded in the realm certi�cate veri�cation key certi�cate�When the expiry date is reached� the key becomes invalid� This validity checkis always part of the veri�cation procedure�

If the secret realm certi�cate signature key is compromised� it must berevoked prior to scheduled expiration� The realm certi�cation authority ac�complishes this by requesting a key revocation certi�cate to be issued by thecentral certi�cation authority� This revocation certi�cate is distributed in thesame way as the certi�cate veri�cation key�

Revocation of a realm certi�cate key pair will render all wallets using thiskey useless� These wallets will have to be returned to their respective issuersfor a refund of the stored balance� New observers must be issued� with whichthe purses must be reactivated�

All key certi�cates signed with a revoked key are invalid� These keys mustbe submitted for certi�cation using another realm certi�cate signature key�

�� Clearing System Signature

�� Generation

The clearing system has an RSA type key pair �mD� eD� dD� where �mD� eD� isthe clearing system veri�cation key and dD is the signature key� The key pairis uniquely identi�ed by a version number vD� This key is generated by theclearing system itself� Generation of RSA type keys is described in Section ��


The clearing system veri�cation key is sent to the central certi�cation authorityfor certi�cation� The central certi�cation authority must register the clearingsystem by identity� and authenticate the submitted key� The means for doingthis is not contained in this speci�cation�

A certi�cate of type clearing key is issued by the central certi�cationauthority� who returns this to the clearing system�

�� Use

The clearing system signature key is used to sign the �black� list of double spentcheques� This list is distributed to the tills through the acquire stations� Thislist facilitates tills to repudiate double spent cheques if presented more thantwice as payments in the system�

Tills need the clearing system veri�cation key for validation of a black listsupplied from the clearing system�


Figure �� summarizes distribution of the clearing system veri�cation key� Af�ter generation by the clearing system� the key is sent to the central certi�cation

��

CAFE Final Report Volume II �� Clearing System Signature

Directory

Central Cert

Till

+

+

Clearing System

Acquire Station

Figure �� Distribution of the clearing system veri cation key�

authority for certi�cation� The certi�ed key is returned to the clearing systemwhich forwards it to all acquire stations�

The clearing system keeps track of which key version each acquire stationhas� A new key is sent to acquire stations during the next deposit transactionafter a key update�

Similarly� each acquire station keeps track of the key version used by eachtill� A new clearing system veri�cation key is sent to a till during the nextdeposit transaction after a key update� The certi�cate is veri�ed by the tillusing the central certi�cate veri�cation key�

The clearing system can introduce an additional clearing system key versionat any time� This key pair will be certi�ed and distributed in the way outlinedabove� There is however no point in having several versions of this key in use atthe same time so introduction of a new key version will probably be connectedto the revocation of an older version� Subsequent black lists issued by theclearing system will be signed using the new key version�

Updating the clearing system key pair does not require other entities in thesystem to update any of their keys or parameters�

�� Archiving

Each version of the clearing system veri�cation key is sent to the directory forarchiving by the central certi�cation authority�

�� Revocation

A validity period is encoded in the certi�cate on the clearing system veri�cationkey� When the expiry date is reached� the key is revoked�

��


If a clearing system signature key is compromised it must be revoked priorto scheduled expiration� The clearing system accomplishes this by requestinga key revocation certi�cate to be issued by the central certi�cation authority�This key revocation certi�cate will be distributed in a manner similar to theclearing system veri�cation key�

�� Acquirer Signature

�� Generation

The acquire station has an RSA type key pair for signing of currency exchangerates distributed to tills� This key is denoted �NA� eA� dA� where �NA� eA� isthe public acquirer veri�cation key and dA is the secret signature key� Thiskey is generated by the acquire station itself� Generation of RSA type keys isdescribed in Section ��


The acquirer veri�cation key is sent to the realm certi�cation authority for cer�ti�cation� The certi�cation authority authenticates the acquire station and thekey� Certi�cates on acquirer veri�cation keys will only be issued to registeredacquire stations� Registration of acquire stations is outside the scope of thisdescription�

The realm certi�cation authority issuer a certi�cate of type acquirer key

on the key and returns this to the acquire station�

�� Use

The acquirer signature key is used by acquire stations to sign currency exchangerates sent to tills� The signature is a commitment by the acquirer to acceptdeposits in all indicated currencies and credit the depositor�s account in hishome currency using the speci�ed exchange rates�

The acquirer veri�cation key is used by tills to validate the currency ex�change 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 speci�cation�In practice� it will be implemented as a distributed system� Hence� in a moredetailed structure we will suggest that the payee�s acquire station will be re�sponsible for the black list supply� and also signed by the acquire station� Thisveri�cation key will already be available for other purposes in the till� Thenthe 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 thatthis list will with very high probability have length zero�

��

CAFE Final Report Volume II �� Systemwide Crypto Parameters

Directory

Till

Realm Cert

+

Acquire Station

Figure �� Distribution of the acquirer veri cation key�


Distribution of the acquirer veri�cation key is illustrated in Figure �� Thekey pair is generated� and the acquirer veri�cation key is sent to the realmcerti�cation authority for certi�cation� The certi�cate is returned to the acquirestation�

The acquire station keeps track of which version of this key is in use by eachtill� The acquirer veri�cation key is updated in a till during the �rst deposittransaction performed by this till following a key update�

An acquire station can generate a new version of the acquirer key at any timeand distribute this to associated tills� This does not in�uence other functionalentities in the system�

�� Archiving

The acquirer veri�cation key is sent to the directory for archiving by the realmcerti�cation authority�

�� Revocation

A validity period is encoded in the certi�cate on the acquirer veri�cation 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 byrequesting a key revocation certi�cate to be issued by the realm certi�cationauthority� This certi�cate is sent to tills in the same way as the acquirer veri��cation key�

�� Systemwide Crypto Parameters

�� Generation

A single system entity� the system operator� is responsible for the generationof a set of systemwide crypto parameters denoted p� q� g� h�Gc and Nphone� A

��


value set of these parameters is uniquely identi�ed by a version number v��

The parameters p� q� g� h and Gc are used for generation and veri�cation ofSchnorr type digital signatures� Here p and q are primes such that qjp � ��Additionally g� h and Gc are elements of order q in ZZ�p�

The parameter Nphone determines the one�way function required for tickpayments� This is an integer which is the product of two large primes� Thefactorization must be kept secret by the system operator� This can be done bydeletion� because the system operator will never need the factorization of thisparameter� Generation of RSA type keys is described in Section ��


The system operator sends the systemwide crypto parameters to the central cer�ti�cation authority for certi�cation� The central certi�cation authority authen�ticates the sender and the message� This authentication and communicationsis outside the scope of this description�

A certi�cate of type system parameter is issued by the central certi�cationauthority�

�� Use

Knowledge of the systemwide crypto parameters is required by all functionalentities involved in the handling of electronic currency in the payment system�

Issuer stations and wallets need the parameters for issuing electronic cur�rency during execution of the authenticate� write cu tbl and gen cheque

protocols and for recovery of lost money by executing rec payments �in case offailed payments� or recovery �in case of a lost wallet�� Updating of issuer keysin a wallet is done using the update protocol which also utilizes the systemwidecrypto parameters�

The systemwide crypto parameters are also used during various kinds ofpayment transactions�in the payment protocol executed between wallet andtill and in the transfer protocol executed between a � wallet and an a�liated� wallet�

The clearing system requires knowledge of the systemwide crypto parame�ters for validation of deposited cheques�


Figure �� summarizes the distribution of the systemwide crypto parameters�After generation the parameters are sent to the central certi�cation authorityfor certi�cation� The returned certi�cate is forwarded by the system operatorto the clearing system� the issuer stations and the acquire stations�

The activation stations installs the current set of systemwide crypto param�eters in observers and purses during activation� The parameters are installed inthe observers before they are mounted in purses� The same set of systemwidecrypto parameters is also installed in auxiliary observers and purses used duringa recovery of a failed or lost wallet� An a�liated � wallet will also need thesame set of systemwide crypto parameters installed during activation�

��

CAFE Final Report Volume II �� Systemwide Crypto Parameters

Aux Observer

Aux Purse

Observer

Purse

Till

Directory

System Operator Central Cert

+

+

+ +

+

+

+

+

Issuer Station Clearing System

Affiliated Wallet

Acquire Station

Figure �� Distribution of the systemwide crypto parameters�

Systemwide crypto parameters are not updated in an observer during itslifetime�

Acquire stations forward the set of systemwide crypto parameters to tillsduring deposit transactions� Each acquire station keeps track of which set ofsystemwide crypto parameters is in use by which till and updates the parametersin a till during the �rst deposit after an update of the parameter set�

The system operator can introduce a new version of the systemwide cryptoparameters at any time� A new parameter set will be distributed as outlinedabove� Activation stations will use the new parameter set in the wallet activa�tion procedure� Wallets already activated will not be a�ected�

�� Archiving

Each version of the systemwide crypto parameters is sent to the directory bythe central certi�cation authority for archiving�

�� Revocation

A validity period is encoded in the certi�cate on the systemwide crypto param�eters� When the expiry date is reached� the parameters are invalidated�

��


�� Issuer Authentication

�� Generation

Each issuer station has a key pair �Pa� Sa� for authentication purposes usingSchnorr type signatures where Pa is the public issuer authentication key and Sathe secret issuer identity key� The key pair is uniquely identi�ed by the issueridentity and a version number vB�a�

Each issuer station generates its own authentication key pair� The secretidentity key is a random number Sa �R ZZq� The public authentication key iscomputed as Pa ! gSa mod p� The current set of systemwide crypto parametersis used�


The issuer station submits the authentication key to a realm certi�cation au�thority for certi�cation� The realm certi�cation authority will authenticatethe issuer station and an integrity protecting channel must be used for com�munications to prevent certi�cation of keys submitted by an impostor� Theauthentication and communications between issuer stations and realm certi��cation authorities are outside the scope of this description�

A certi�cate of type issuer auth key is issued by the realm certi�cationauthority� who returns this to the issuer station�

The realm certi�cation authorities will only issue certi�cates of this typeto registered issuer stations� The identity of the issuer station is establishedduring authentication� Registration of issuer stations is outside the scope ofthis description�

�� Use

The issuer authentication key is used when issuer stations are authenticatedby wallets and for authentication of message sent by the issuer station to thewallet� The issuer authentication key is utilized during the execution of theauthenticate� 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 pursemay use a di�erent issuer authentication key than the one originally installedin the failed or lost wallet�


Figure �� summarizes distribution of the issuer authentication key� Aftergeneration the authentication key is sent to the realm certi�cation authorityfor certi�cation� The certi�cate is returned to the issuer station�

The issuer station installs the issuer authentication key in purses and ob�servers during activation by executing the update protocol� This protocol willalso be used for subsequent updates of this key�

��

CAFE Final Report Volume II �� Issuer Cheque Signature

Directory

Purse

Observer

+

Realm CertIssuer Station

Figure �� 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 enti�ties� The new key is updated in wallets during the �rst withdrawal transactionfollowing the key change� No other entities need access to this key�

�� Archiving

The issuer authentication key is sent to the directory for archiving by the realmcerti�cation authority�

�� Revocation

A validity period is encoded in the certi�cate 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 theCAFE system� This key is only used when the wallet communicates with theissuer station�

�� Issuer Cheque Signature

�� Generation

Each issuer has a key pair �Pc� Sc� for issuing cheques using Schnorr type digitalsignatures where Pc is the issuer cheque veri�cation key and Sc is the chequesignature key� This key pair is uniquely identi�ed using the issuer identity andthe version number vB�c�

The issuer cheque signature key is generated by each individual issuer sta�tion� The secret signature key is a random number Sc �R ZZq� The public

��


veri�cation key is Pc ! GScc mod p� The current set of systemwide key param�

eters is used�


The issuer station sends the cheque veri�cation key to a realm certi�cationauthority for certi�cation� The realm certi�cation authority authenticates theissuer station and an integrity protecting channel should be used for commu�nications to prevent certi�cation of keys submitted by an impostor� This isoutside the scope of this description�

A certi�cate of type issuer cheque key is issued by the realm certi�cationauthority� who returns this to the issuer station�

The realm certi�cation authority will only issue certi�cates of this type toregistered issuer stations� The identity of the issuer station is established duringauthentication by the certi�cation authority� Registration of issuer stations isoutside the scope of this description�

�� Use

The issuer cheque signature key is used by the reload station during executionof the gen cheque protocol in a withdrawal transaction�

The issuer cheque veri�cation key is required for validation of cheques�Cheques are validated by the purse during execution of the gen cheque proto�col� During a payment transaction the cheque is sent to the till and veri�ed inthe payment protocol� Finally the cheques are deposited and validated by theclearing system�


Figure �� summarizes the distribution of the issuer cheque veri�cation key�After generation the key is sent to the realm certi�cation authority for certi��cation� The certi�cate is returned to the issuer station which forwards it to theclearing system�

The issuer cheque veri�cation key is installed in purses during activationand subsequently updated using the update protocol� Both the key and itscerti�cate are stored by the purse�

During a payment transaction the till may request a copy of the chequeveri�cation key for veri�cation of the received cheques� The purse will thensend both the key and its certi�cate to the till by executing the get certif

protocol� The till validates the certi�cate by using the veri�cation key of theissuer station�s realm certi�cation authority� This key can also be requestedfrom the purse if it is unknown to the till�

An issuer station may generate an additional set of cheque signature keysat any time� It is not necessary to synchronize this with other issuer stationsor other functional entities in the system� The new key is distributed to purses�tills and the clearing system as outlined above�

��

CAFE Final Report Volume II �� Issuer Cheque Signature

Directory

TillPurse

+

+

Realm CertIssuer Station

Clearing System

Figure �� Distribution of the issuer cheque veri cation key�

�� Archiving

The issuer cheque veri�cation key is sent to the directory for archiving by therealm certi�cation authority�

�� Revocation

A validity period is encoded in the certi�cate on the issuer cheque validationkey� When the expiry date is reached� the key is revoked�

Ad hoc revocation of this key is not possible without distribution of a revo�cation list with a listing of all revoked keys� to all tills� This is not presentlyspeci�ed for the CAFE system but can easily be added in the future�

Revocation of an issuer cheque signature key invalidates all cheques issuedusing this key� The balance of a wallet is not a�ected� but a payer with oldcheques run the risk of experiencing a temporary loss of the ability to spendmoney when cheques expire� This is normally prevented by updating keys andcheques well in advance of a key revocation during a withdrawal transaction�A payer can regain his ability to perform payments by doing a withdrawaltransaction which will also update the issuer keys stored in the wallet�

When setting the validity period for issuer cheque signature keys� there is atradeo� to be made�

� Payers want cheques that don�t expire very often� This means long validityperiods�

� Loss recovery cannot be done until the lost cheques have expired� Thismeans shorter validity periods�

� Long validity periods mean that a lot of cheques have to be kept in the

��


clearing centre double spending detection database� This means shortervalidity periods�

Furthermore it will be advantageous to the size of the clearing system doublespending detection database if issuer stations revoked these keys at di�erenttimes�

�� Observer Signature

�� Generation

Each observer has a Schnorr type signature key pair �ps� ss� where ps is thepublic veri�cation key and ss is the secret signature key� This key is used forauthentication of the observer�s messages�

The observer signature key is generated by the observer itself� The secretpart of the key is a random number ss �R ZZq� The public key is computed asps ! gss mod p�


Previously described key and parameter sets have been sent through a securechannel to a certi�cation authority for certi�cation� Existing banking networkscan be used for this� For observer keys no such secure channel exist� It is how�ever of the utmost importance that the issuer station knows that the obserververi�cation key it associates with a particular payer is in fact generated by thispayer�s observer�

The observer generates the signature key pair during activation prior toinstallation of the observer into the wallet� Activation is performed at theissuer�s premises and the observer veri�cation key can then be read directlyfrom the observer by the activation station� Since the observer is trusted bythe issuer� he can be sure that the key is genuine�

The activation station sends the observer veri�cation key to the realm cer�ti�cation authority for certi�cation� The certi�cation authority authenticatesthe activation station and communications must go through an integrity pro�tecting channel� The realm certi�cation authority issues a certi�cate of typeobserver key and returns this to the activation station�

Certi�cates of type observer key will only be issued to registered activationstations� Registration of entities is outside the scope of this description�

This strategy for certi�cation of the observer veri�cation key permits theactivation station to certify any key claiming it to belong to a speci�c observer�This possibility for framing is combated using the directory as will be discussedshortly�

�� Use

The observer signature key pair is used to authenticate the observer and mes�sages sent by the observer to other functional entities� During a withdrawaltransaction the observer signature key is used to sign messages sent from

��

CAFE Final Report Volume II �� Observer Signature

the observer to the reload station during execution of the authenticate andwrite cu tbl protocols�

During execution of the transfer protocol the observer signature key isused to authorize an a�liated � observer to increase it�s balance after a similardecrease in the � observer�

During execution of both rec payments and recovery the observer signa�ture key is used to sign messages sent to the issuer station�

A special use of the observer signature key is made during execution of thepayment protocol� Here the observer encodes the secret part of the key in acheque in such a way that it can�t be extracted unless the same cheque is spenttwice� This facilitates detection of double spenders in the payment system�

In all protocols the purse veri�es the signatures made by the observer toprevent the observer from leaking unsolicited information to other functionalentities�


The distribution of the observer veri�cation key is summarized in Figure ��After generation the public veri�cation key is sent to the activation station priorto installation of the observer in the purse� The activation station forwards thekey to the realm certi�cation authority for certi�cation�

The returned key certi�cate is installed in the purse during activation� It isalso installed in an a�liated � wallet during initialization of the a�liation link�

Note that the purse must only be permitted to learn the public part of thekey even though this key in a sense represents the payer by signing commit�ments for the payer� Knowledge of the secret observer signature key wouldpermit withdrawals and payments without using the observer� and this can�not be permitted� The observer is required to enforce prior restraint of doublespending of cheques�

The observer signature key pair is not updated during the lifetime of theobserver�

�� Archiving

The observer veri�cation key is forwarded to the directory for archiving by therealm certi�cation authority�

We have already brie�y mentioned the potential problem with an activationstation registering keys generated by itself claiming them to belong to speci�cobserver� Such keys can be used to frame payers� If a dispute should arise� thepayer can demonstrate that his observer does not contain the veri�cation keykept in the directory� Since the observer is trusted by the issuer� the activationstation must have registered an incorrect key�

�� Revocation

A validity period is encoded in the certi�cate on the observer veri�cation key�When the expiry date is reached� the key is revoked� Revocation of an observer

��


Observer

Directory

Purse

Realm Cert

Issuer Station

Affiliated Wallet

Figure �� Distribution of the observer veri cation key�

signature key pair means that further withdrawals can�t be performed� Anycheques already withdrawn can however be spent until the cheques expire�

Ad hoc revocation of observer signature key pairs is equivalent to revocationof the observer itself� This can be done in two ways�

�� The reload station refuses further withdrawals for the observer� The ob�server can still spent already withdrawn cheques until they expire�

�� The observer is physically withdrawn by the issuer�

Blacklisting of the observer to prevent further payments is impossible since theobserver is anonymous during payment transactions�

�� Shared Parameter

�� Generation

There exists a parameter pc which is �shared� between the observer and theissuer station� This parameter is shared in the sense that it depends on boththe observer and issuer keys�

The parameter is computed as pc ! �psh�Sc mod p� Computation of pc can

only be done by the issuer station since this requires knowledge of the issuercheque signature key�

��

CAFE Final Report Volume II �� Shared Parameter

Purse

Observer

Issuer Station

Aux Purse

Aux Observer

Figure �� Distribution of the shared parameter�


The shared parameter is not certi�ed by a certi�cation authority� It is computedby the issuer station and signed using the issuer identity key before distributionto the purse and observer�

�� Use

The shared parameter is used during generation and validation of cheques�During execution of the gen cheque protocol this parameter is used by theobserver� purse and the reload station�

In the payment and rec payments protocols the observer used this param�eter for generation of cheques�

The shared parameter is also used by the auxiliary observer and purse dur�ing an execution of the recovery protocol� but this parameter is sent to theauxiliary observer and purse by the recovery station as a part of the protocol�


The parameter pc is computed by the issuer station and installed in the purseduring activation� The purse forwards pc to the observer� Subsequent updatesof this parameter are required each time the issuer station updates his chequesignature key and is performed by execution of the update protocol�

Distribution of the shared parameter is summarized in Figure ��

It is of the utmost importance that the pc installed in an observer has beengenerated by the same issuer station that installed the issuer authenticationkey� This is required since the issuer authentication key is used for withdrawaltransactions while the shared parameter is used for payments�

To ensure installation only of valid shared parameters� the observer requirespc to be signed using the issuer identity key�

��


�� Archiving

The shared parameters are not archived�

�� Revocation

A special revocation procedure for these parameters is not required� Theyare automatically revoked when either the observer signature key or the issuercheque signature key is revoked�

�� Observer PRSG Parameters

�� Generation

The observer has a special pseudorandom sequence generator �PRSG� whichgenerates sequences of seemingly random numbers and with the special abilityto regenerate these sequences later� The PRSG in the observer is de�ned bythe parameter set �NS � S� S��

The parameter NS is a Blum integer� Generation of such integers is verydemanding 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 theissuer�s interests� Having the purse generate this special integer might enablethe payer to reveal the secret observer signature key through observation ofoutput generated by the observer�

The parameters S and S� are random numbers in the range � � � � NS usedas seeds for the PRSG� These are also generated by the issuer station�


These parameters are not certi�ed�

�� Use

The parameters for the PRSG are used by the observer for generating randomnumbers as speci�ed in the CAFE protocols� The pair �NS � S� is used for gener�ating random numbers for cheques while �NS � S�� is used for all other randomnumbers�

The pair �NS � S� will have to be loaded in an auxiliary observer duringrecovery for the auxiliary observer to be able to regenerate all possibly spentcheques since the last withdrawal� This will enable recovery of funds in a lostor failed wallet�


After generation the issuer station installs the parameters NS� S and S� in theobserver prior to installing the observer in the purse� The issuer station willalso keep a copy of NS and S for use during a wallet recovery� The issuer stationwill install these parameters in an auxiliary observer prior to installation in theauxiliary purse�

��

CAFE Final Report Volume II �� Purse Blinding

Issuer Station

Aux Observer

Observer

+

+

Figure �� Distribution of the PRSG parameters�

Distribution of the PRSG parameters is summarized in Figure ��

�� Archiving

These parameters are not archived�

�� Revocation

These parameters cannot be revoked�

�� Purse Blinding

�� 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� Thisis an RSA type key pair used for deterministic blinding of cheques� This keypair is generated by the purse� Generation of RSA type keys is described inSection �� The public exponent is �xed ep ! ��


The purse deblinding key is sent by the purse to the issuer station� The issuerstation forwards the key to the realm certi�cation authority for certi�cation�The realm certi�cation authority authenticates the issuer station and an in�tegrity protecting channel must be used for communications�

The realm certi�cation authority issues a certi�cate of type purse key andreturns this to the purse by way of the issuer station�

Only registered issuer stations can request certi�cation of purse deblindingkeys� Registration of functional entities is outside the scope of this description�

It is of utmost importance to the issuer that the blinding performed bythe purse is deterministic� The reason for this is that the exact same blinding

��


Purse Issuer

x �R ZZ�Np

a�H�x�

� a��y �R ZZ�Np

��y

��r� �xy�dp mod Np

�r� x

��a

�! H�x�

rep�! xy mod Np

Figure �� Protocol for proving validity of blinding key modulus�

must be performed when cheques are regenerated during recovery of a lost ordestroyed wallet� A necessary and su�cient condition for this is that ep ! �does not divide ��Np�� The issuer station does not know the factorization ofNp and is thus unable to verify this by itself� A protocol is needed for the purseto prove to the issuer station that Np is of the correct form without revealingthe factorization of Np�

This protocol is based on the following observation� Let n be a non�zerointeger� and let H denote the set of cubic residues mod n� that is H is the setof all y � ZZ�n such that y ! x� mod n for some x � ZZ�n�

Observe that H is a subgroup of ZZ�n� and that if � � j��n�� then H ! ZZ�n fromthe properties of RSA exponentiation �RSA�� If� on the other hand� �j��n��then H is a proper subgroup of ZZ�n� This can easily be proved by letting y � Hand x � ZZ�n such that y ! x� mod n and the observing that

y��n�� ! �x��

��n�� ! x��n� ! � mod n�

The order of H must thus be a divisor of ��n�� This shows that if �j��n�� at

most one third of the elements of ZZ�n are cubic residues mod n�

The protocol in Figure �� is executed between the issuer station and thepurse to prove the validity of the modulus Np� For each run of the protocol� theprobability of success is at most �

� if Np is not of the correct form� The protocolmust be repeated a su�cient number of times to ensure su�cient con�dencein Np by the issuer station� Repeating the protocol � times should provide asu�cient level of con�dence�

�� Use

The purse blinding key is used by the purse for blinding of cheques duringthe execution of the gen cheque payment and rec payments protocols� The

��

CAFE Final Report Volume II �� Purse Blinding

Directory

PurseAux Purse

Observer Aux Observer

Realm Cert

Issuer Station

Payer Station

Figure �� Distribution of the purse blinding and deblinding key pair� Thedashed arrows indicate the distribution of the secret blinding key�

same secret key is also used by an auxiliary purse during the execution of therecovery protocol�

The blinding is veri�ed by the observer using the purse deblinding key dur�ing the execution of the payment and rec payments protocols� The auxiliaryobserver involved in the recovery protocol will also use the purse deblindingkey but gets this key from the recovery station during execution of the protocol�


Distribution of the purse blinding key pair is summarized in Figure �� Thekey pair is generated by the purse during activation� The public part of thekey is then sent to the issuer station who forwards it to the realm certi�cationauthority for certi�cation�

The certi�cate is returned to the issuer station which forwards this to thepurse for installation in the observer� The issuer station will also keep a copyof the certi�ed key for later installation in an auxiliary observer used duringwallet recovery�

The secret purse blinding key is output by the purse to the payer stationwhich keeps a copy� This secret key is later installed in an auxiliary purse ifrecovery of the wallet is required�

The purse may choose to install a new purse blinding key pair at any timeby executing the same procedure with the issuer station� All cheques in thewallet will then be invalidated and a new withdrawal must be done�

��


�� Archiving

The purse deblinding key is sent to the directory by the realm certi�cationauthority for archiving�

�� Revocation

The purse blinding key pair is revoked when the payer chooses to update thepurse blinding key�

�� A�liated � Observer Signature

�� Generation

The wallet needs access to the veri�cation key of an a�liated � observer forthe transfer protocol to work� This key is generated in the same way as the �observer signature key pair as described in Section �� The a�liated observersignature key pair is denoted �pw� sw� where pw is the public a�liated obserververi�cation key and sw is the secret signature key�


The a�liated observer veri�cation key is certi�ed by the realm certi�cationauthority in a way similar to the certi�cation of the � observer veri�cation key�

�� Use

The a�liated � observer signature key is used by the a�liated observer duringthe transfer protocol to authenticate the messages sent to the � wallet�

The veri�cation key is used by both the purse and the observer for veri��cation of the a�liated observer�s identity and the validity of messages sent bythe observer�


Figure �� summarizes the distribution of the a�liated observer veri�cationkey� Most of the distribution is similar to the distribution of the � obserververi�cation key� During initialization of the a�liation link between the � andthe � wallet� the issuer station installs the certi�ed key in the � purse� Thepurse subsequently installs the key in the � observer�

The � wallet and a�liated � wallet must have the same set of systemwidecrypto parameters installed�

�� Archiving

The a�liated observer veri�cation key is archived in the directory in the sameway as the � observer veri�cation key�

��

CAFE Final Report Volume II �� Non�cryptographic Parameters

Directory

Purse

Observer

Realm Cert

Issuer Station

Affiliated Wallet

Figure �� Distribution of the a�liated observer veri cation key�

�� Revocation

The a�liated observer veri�cation key is revoked in the same way as the �observer veri�cation key�

�� Noncryptographic Parameters

�� Generation

A number of non�cryptographic parameters that determine aspects of the pay�ment system behaviour must be distributed� These parameters are�

max pay This parameter determines the maximum value that can be assignedto 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 bal�ance is the net balance of all currencies stored in the wallet denominatedin 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 ana�liated � wallet before a new withdrawal transaction must be performedwith the issuer�

max ticks The maximum number of �ticks� a cheque can be divided in� Thisparameter is denoted T in the description of the protocols�

��


The issuer station determines the values of parameters max bal � max trans

andmax curr � and can be distinct between individual wallets within constraintsof the implementation�

All tills must know max pay and max ticks� Of course� the complexity ofthe key management system will be somewhat reduced by keeping the valuesof these parameters as systemwide constants� This practice will also contributeto the payer�s privacy� Therefore� the values of max pay and max ticks are setby the system operator�


The values of max pay and max ticks are sent to the central certi�cation au�thority for certi�cation� where the authenticity of the message is veri�ed� Thecentral certi�cation authority issues a certi�cate of type max parameter on theparameters and returns this to the system operator�

The parameters max bal � max curr � and max trans� generated by the indi�vidual issuer stations� are not certi�ed by the certi�cation hierarchy�

�� Use

The parameters max pay and max ticks are used by tills during execution of thepayment 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 transac�tions� The reload station will not permit the observer to install a currency tablewith a total balance exceeding max bal or if it contains more than max curr

currencies�

The observer� purse and a�liated wallet use max trans during execution ofthe transfer protocol� A transfer will not be permitted if the total amounttransferred between two withdrawals exceeds max trans�


The parameters max pay and max ticks are generated by the system operatorand sent to the central certi�cation authority for certi�cation� The certi�catesare returned to the system operator� who forwards the certi�cates to all acquirestations�

The acquire stations keep track of which version of these parameters is inuse by each till� Updated parameter sets are sent to the till during the �rstdeposit transaction following a parameter update�

Distribution of max pay and max ticks is illustrated in Figure ��

The max trans parameter is generated by the issuer station and installedin the purse and a�liated � wallet during activation of the a�liation link�The parameter is certi�ed with signature generated by the issuer identity key�Subsequently� the purse forwards the certi�ed parameter to its observer� Thisis illustrated in Figure ��

��

CAFE Final Report Volume II �� Non�cryptographic Parameters

System Operator

Directory

Central Cert

Till

+

+

Acquire Station

Figure �� Distribution of the max pay and max ticks parameters�

Purse

Observer

+ +

Issuer Station

Affiliated Wallet

Figure �� Distribution of the max trans parameter�

��


�� Archiving

The parameters max pay and max ticks are sent to the directory for archiving�No other non�cryptographic parameter is archived�

�� Revocation

The central certi�cation authority encodes a validity period in the certi�cateof max pay and max ticks� The parameters are revoked when the expiry dateoccurs�

��


Chapter ��

Activation of Entities

� �� Wallet Activation

This section describes the di�erent steps taken during activation of a wallet�The activation begins prior to installation of the observer in the purse�

�� The manufacturer installs the central certi�cate veri�cation key in theobserver�

�� The activation station loads the systemwide crypto parameters in theobserver� The observer validates the certi�cate on these parameters�

�� The activation station loads the PRSG parameters� �NS � S� S�� in theobserver� The activation station also inputs a random bitstring for latergeneration of the observer signing key�

�� The payer inputs a random bitstring in the observer using a trusted inputterminal�

�� The observer generates the observer signature key pair by combining therandom bitstrings entered by the activation station and the payer� If asource of true randomness is available to the observer� that should be usedinstead of the data entered by the activation station and the payer�

�� The observer sends the observer veri�cation key to the activation station�

�� The payer or the issuer mounts the observer in the purse�

� The central certi�cate veri�cation key is loaded in the purse by the ac�tivation station� The payer may compare this with the veri�cation keystored in the observer or with the key in the directory�

� The activation station sends the realm certi�cate veri�cation key to thepurse� Subsequently the purse supplies this key to the observer� Bothpurse and observer validates the certi�cate on this key�

� � The activation station sends the systemwide crypto parameters to thepurse� and the purse veri�es the corresponding certi�cates�

�� The purse generates the blinding key pair and sends the public part tothe activation station� The activation station returns the certi�ed publickey which is then veri�ed and forwarded to the observer by the purse�The observer validates the certi�cate on the key and stores it�

��

Chapter � � Activation of Entities CAFE Final Report Volume II

�� The purse gets the observer veri�cation key from the activation stationand validates the certi�cate on the key�

� �� Activation of A�liation

This section describes the procedure that establish the a�liation link betweena � wallet and an a�liated � wallet�

�� The activation station checks that both the � wallet and the a�liated �wallet contain the same version of the systemwide crypto parameters�

�� The activation station installs the observer veri�cation key in the a�liatedwallet� The a�liated wallet validates the certi�cate on the key�

�� The activation station supplies the a�liated observer veri�cation key tothe purse� The purse validates the certi�cate on the key�

�� The purse sends the a�liated observer veri�cation key to the � observer�The observer validates the certi�cate on the key�

��


Chapter ��

Version management

This section considers some issues with respect to updating of keys and otherparameter values�

�� Overlapping Validity Periods

Keys and parameters will have to be updated from time to time� However� it isinfeasible to update keys instantaneously in all involved functional entities in theCAFE system� There may be an arbitrary long delay from the parameter updateuntil a wallet �connects� to an entity that can provide the new parameter valueto the wallet�

The solution to this problem is to simultaneously use two versions of eachkey set with overlapping validity periods� The old key version is then still validwhile the new version is gradually introduced� This is illustrated in Figure ��

The �gure shows the validity periods for three di�erent versions� A� B andC� of the same key set� From time t� version B will be the preferred versionand will be in the activation of wallets� From time t� key version C will be thepreferred one� Still� key B has half of its validity time left� This means that akey installed just before t� will be valid for a relatively long period�

Due to storage limitations� each wallet will be equipped with a single versionof each required key� This implies that issuer stations and tills will have to adaptto the key version used by the wallet�

�� Validity Dependencies

Some properties of the keys and the key management system place constraintson the validity periods of keys and parameters� These constraints are caused

��

� �Timet� t�t�

A

B

C

Figure �� Illustration of overlapping key validity periods�

��

Chapter �� Version management CAFE Final Report Volume II

Systemwide crypto

parameters�

��

ZZZZ�

XXXXz

��

Issuer cheque signature

Issuer authentication

observer signature

shared parameter

Figure �� 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 parametersas input� This implies that when the input parameters expire� the generatedkeys are also invalidated� Such dependencies exist between a few sets of keysand parameters� as illustrated in Figure �� When the systemwide cryptoparameters are revoked� both the issuer keys and the observer signature keyare invalidated� Similarly� if the issuer cheque signature key or the observersignature key is revoked� the shared parameter is invalidated�

The key management speci�cation calls for some parameters to remain con�stant in a wallet during the lifetime of the observer� We assume that an observerhas a �xed validity period T after activation� This assumption leads to mini�mum validity periods for other keys and parameters in the system�

The observer signature key and observer PRSG parameters are generatedby the observer during activation� Thus� these parameters will have the samevalidity period T as the observer�

The central and realm certi�cate veri�cation keys and the systemwide cryptoparameters are speci�ed to be constant in a wallet during the lifetime of theobserver� Due to the use of overlapping validity periods as illustrated in Fig�ure �� these keys and parameters must have a total validity period of �T �This will accommodate wallets activated just before introduction of a new ver�sion of any of these parameters�

Other keys and parameters are either not used by the wallet or can beupdated through the use of speci�ed protocols� Thus� there are no constraintson these keys and parameters except for dependencies illustrated in Figure ��

��


Chapter ��

Security Properties

This section presents some consequences if keys are compromised or forged�

�� Types of Attack

Keys can be compromised or forged in three di�erent ways�

�� A secret key can be compromised either by the owner inadvertedly re�vealing the secret key or by an impostor computing the secret key fromthe corresponding public key� The former is prevented by secure storageof keys in tamper resistant hardware� The latter is prevented by usingstrong public key algorithms with su�cient key length�

�� An impostor may be able to obtain a certi�cate generated by a certi��cation authority on a forged key pair� The certi�cate indicates that thekey belongs to a di�erent existing entity in the CAFE system� This isprevented by using strong authentication and secure channels when re�questing certi�cation of keys�

�� An impostor may be able to obtain a certi�cate on a forged key as outlinedabove except that the key owner identity encoded in the certi�cate doesnot correspond to any existing functional entity�

For method � and � above it is also necessary for the impostor to be able toinstall the forged key in a number of functional entities� This analysis assumesthis is feasible�

�� Forged Certi�cates

The certi�cation security breaks if either the central certi�cate signature keyor a realm certi�cate signature keys is compromised�

If the central certi�cate signature key is compromised� most of the keysin the system can be forged as described under method � and � above� If arealm certi�cate signature key is compromised then the acquirer signature keys�issuer authentication and cheque signature keys� and purse blinding keys canbe forged under the given realm�

If an impostor has managed to install a forged central certi�cate veri�cationkey in a subset of functional entities� this will be detected when one of theseentities interact with an entity using the correct central certi�cate veri�cationkey� for instance� during a payment transaction when issuer keys and certi�cates

��

Chapter �� Security Properties CAFE Final Report Volume II

are exchanged� or when a payer matches the central certi�cate veri�cation keyinstalled in his wallet against the value stored in the directory�

In the case of compromisation of a certi�cate signature key belonging to ei�ther the central certi�cation authority or one of the realm certi�cation author�ities� a dispute will eventually arise and the compromisation will be detected�Both central and realm certi�cation keys can be revoked if compromisation isdetected�

�� Key Compromisation

The compromisation of some cryptographic keys in the system will permit coun�terfeiting of electronic currency�

�� The knowledge of the issuer cheque signature key permits the holder tomake valid cheques that are not tied to any authorized activated observer�As a consequence� an unlimited number of payment transactions can beexecuted without observer hardware and without encoding a valid ob�server payer identity in the cheques�

�� The knowledge of the issuer authentication key permits unauthorized up�dates of the currency table stored in the observer� Cheques must still bewithdrawn and payment transactions be executed with the reload station�but the wallet balance can be increased unrestrictedly�

�� The knowledge of the observer signature key permits the holder to sim�ulate observer behaviour� The observer will help withdraw cheques fromthe reload station� but will not decrease the balance during a payment ortransfer transaction�

If a cheque signature key has been forged� as described in method � above�this is detected when the �rst forged cheque fails validation in the clearingsystem� because the clearing system will detect an unregistered issuer identityencoded in the cheque� It is not possible to use issuer authentication keys orobserver 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 userwithdraws plenty of cheques but little or no currency amount� It will certainlybe detected by the issuer as a discrepancy between the issued total and thetotal claimed by the clearing system�

E�ective ad hoc revocation of issuer authentication and cheque signaturekeys is not possible in the current system� A future enhancement with a re�vocation list of cheque signature keys stored in all tills is possible in principle�Observer signature keys are revoked by collecting the observer hardware�

�� Acquirer Signature

Knowledge of the acquirer signature key permits forged currency exchange ratesto be used by the tills� A payee is able to use this to accept payments in foreign

��

CAFE Final Report Volume II �� Clearing Signature

currency with an advantageous exchange rate� This will be detected by theacquire station at the deposit� and the acquirer signature veri�cation key willbe revoked�

�� Clearing Signature

Compromisation of the signature key of the clearing system will permit a forgerto create black lists of double spent cheques� This could permit further spendingof a cheque already detected as double spent�

A double spent cheque implies that the tamper resistant observer has beenbroken� and a double spender will be detected and identi�ed by the clearingsystem� So this attack is very unlikely to happen� The clearing system willrevoke the key if compromisation is suspected�

��

Chapter �� Security Properties CAFE Final Report Volume II

��


Chapter ��

Key Management for the �

System

Key management for the � and � �� systems are almost identical� In thischapter we will outline how the key management for the � �� systems di�ersfrom the � system�

�� Entities

The functional entities in the � and � systems are almost identical� The mainexception is that the observer and purse in the � system are combined into asingle physical device in the � system� This is a tamper resistant device� and itsfunctionality is trusted by both the issuer and the payer� Similarly the auxiliaryobserver and the auxiliary purse are combined into a single auxiliary wallet�similarly trusted by both the issuer and payer� This combination of observerand purse does not go equally far in the �� system� but for key managementconsiderations the two systems are equivalent in this respect�

There is no a�liated wallets in the � system in the sense described for the� system�

�� Certi�cate Classes

Neither the purse blinding key nor the a�liated observer signature key are usedin the � system�

The observer signature and observer PRSG parameters are replaced by al�most similar � wallet signature and PRSG parameters� Some of the require�ments for the � wallet PRSG are di�erent than for the � observer PRSG� Boththe issuer and the payer must trust the randomness of the pseudo random se�quence generated by � wallet� This means that neither the issuer nor the payermust know enough PRSG parameters to reconstruct the sequence� In the �system the issuer is able to reconstruct the observer PRSG sequence�

This di�erence in the trust model is caused by the merging of the twoentities� the observer and the purse� in the � system into the single wallet inthe � system� While the observer� and hence the pseudo�random sequencegenerated by the observer� in the � system is only trusted by the issuer� thepseudo�random sequence generated by � wallet must be trusted by both theissuer and the payer� We say that a pseudo�random sequence is �trusted� by an

��

Chapter �� Key Management for the � System CAFE Final Report Volume II

entity when the sequence cannot be distinguished from a true random sourceby any other entity�

�� Central Certi�cation

The central certi�cate veri�cation key is installed in a wallet by the manufac�turer� The key can be read from the wallet at any time and its validity canthus be veri�ed by the payer� This key is not updated in the wallet during itslifetime�

�� Realm Certi�cation

The realm certi�cate veri�cation key is installed in a wallet by the issuer stationduring activation of the entity� The wallet veri�es the validity of the certi�cateon the key before it is accepted� The realm certi�cate veri�cation key is notupdated in the wallet during its lifetime�

�� Systemwide Crypto Parameters

The systemwide crypto parameters are installed in the wallet during the ac�tivation of the entity� The validity of the certi�cate on these parameters isveri�ed by the wallet before the parameters are accepted� The parameters arenot updated in the wallet during its lifetime�

�� Issuer Authentication

The issuer authentication key is installed and subsequently updated in a walletby the issuer station using the update protocol� The validity of the certi�cateon this key is veri�ed by the wallet before the key is accepted�

�� Issuer Cheque Signature

The issuer cheque veri�cation key is installed and subsequently updated in thewallet by the issuer station using the update protocol� The validity of thecerti�cate on this key is veri�ed by the wallet before the key is accepted�

The wallet must keep both the veri�cation key itself and the certi�cate onthis key� The wallet must be ready to send both the key and its certi�cate toa till during a payment transaction�

�� Wallet Signature

This signature corresponds to the observer signature in the � system� It isdistributed as in the � system with the exception that there is no purse and noa�liated wallet that need access to the veri�cation key�

��

CAFE Final Report Volume II �� Shared Parameter

The secret key must be generated from an internal source of randomnessin the wallet or a combination of random input entered by the issuer and thepayer� It is of utmost importance that this key cannot be known outside thewallet�both the integrity of the issuer and the payer depend on this�

�� Shared Parameter

The shared parameter is installed in a wallet and auxiliary wallet during activa�tion� and subsequent updates are performed using the update protocol� In the� system it is not required that this parameter is certi�ed because the walletcan easily verify its correctness in� for instance� a withdrawal transaction whichtypically is executed after an execution of the update protocol�

�� Wallet PRSG Parameters

The modulus NS is generated and installed in a wallet by the manufacturerthat acts as a trusted party in the � system� The modulus can be read fromthe wallet but not modi�ed�

The issuer and payer generate two seeds each independently and at random�The issuer generates S� and S�� while the payer generates S�� and S�� Theseseeds are input to the wallet using a trusted terminal� The wallet seeds arethen computed� S ! S� � S�� and S� ! S�� S�� which are stored internally bythe wallet�

It is possible for the issuer and the payer to collude to compute S and thencompute the wallet signature key by observing some payment transactions� Theissuer and payer will however have con�icting interests since always either theissuer or the payer will have to cover fraud committed by knowledge of thissignature key�

The issuer station must store NS and S�� and the payer must store S�� foruse in the recovery protocol�

The wallet computes a value hash seed which must be stored by the issuerstation� This value is computed as hash seed ! H�NS � S��

In case of recovery� the issuer station installs NS and S� in the auxiliarywallet� The payer installs S�� SC is then ready to regenerate the cheques to berecovered by executing the recovery protocol� The validity of these parametersis ensured by having the issuer station send a signed version of hash seed duringexecution of the recovery protocol�

�� NonCryptographic Parameters

The max trans parameter is the only non�cryptographic parameter distributedto the wallet in the � system� This parameter is installed in the wallet duringactivation of the a�liation to a � wallet by the issuer station�

��

Chapter �� Key Management for the � System CAFE Final Report Volume II

��


Part VII

Extensions

��


Chapter ��

E�ciency Improvements

In this chapter we will describe some improvements to enhance the e�ciencyof the CAFE payment system� We will describe an alternative digital signaturescheme� the e�ect of increasing the number of times each cheque can be spentin a payment transactions and we will look into the e�ects of performing pre�and post�processing�

�� An Alternative Blind Signature Scheme

�� Introduction

The currently speci�ed and implemented CAFE protocols are all based onthe same restrictive blind signature scheme� �rst presented in �CP�a� Bra��Bra�a�� The central protocol in this respect is the gen cheque protocol� inwhich the issuer signs a cheque generated by the payer in a blind fashion� Inthis section we consider an alternative blind signature scheme� which is similarfrom a security point of view but signi�cantly more e�cient� Incorporating thisblind signature scheme not only improves the performance of the gen cheque

protocol� but also other protocols and parts of the payment system becomesimpler and more e�cient�

In this section we concentrate on the e�ciency improvements made possibleby an alternative blind signature scheme� Security aspects and other issues havebeen considered elsewhere� see �Sch�� and �Bra�a� Bra�b� Bra�c� Bra�d��the two main issues are that the resulting payment system is believed to with�stand parallel attacks� whereas the comparable system of �Bra�b� is known tobe vulnerable to this type of attack� and that the protection of a payer againstframing by the issuer is not achieved in the same clean way as before� Fortwo alternative immunization techniques against a parallel attack the reader isreferred to �Bra�c� Bra�d�� For more extensive information on the use of thisalternative blind signature scheme in payment protocols the reader is referredto �Sch��

�� The Scheme

The scheme presented here is based on Schnorr�s e�cient signature schemebased on the di�culty of the discrete log problem �Sch�� In this scheme thepublic key of the signer consists of two large primes p� q� where q j p�� and twogenerators g and h of order q in ZZ�p� In addition an appropriate hash functionH is part of the public key� which we assume here to map its input into a

��

Chapter �� E�ciency Improvements CAFE Final Report Volume II

Signer Receiver

�h ! gx�

w �R ZZq

a� gw � a�� c�� c�H�m�a�

r � w # xc � r�� gr�! ahc

Figure �� Issuing a Schnorr signature �c� r� on a blind message m�

Signer Receiver

�h ! gx�t �R ZZ�qu� v �R ZZq

w �R ZZq g� � gt

a� gw � a�� a� � agvhu

c� �H�g��m� a��

�� c�� c� c� # u

r � w # xc � r�� r� � �r # v�t

g�r� �! a�hc

�

Figure �� Protocol to get a blind signature �g�� c�� r�� on a blind messagem�

substantial subset of ZZq� The secret key of the signer is the unique numberx � ZZq satisfying h ! gx in ZZ�p� that is� x is equal to the discrete log of h withrespect to the base g� A Schnorr signature on a message m is now a pair �c� r�satisfying

c ! H�m� grh�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 tothe signer afterwards� For our purposes� we will need to hide the message mfrom the signer� This can be done by generating the signature in an interactiveprotocol between signer and receiver� The signature protocol is displayed inFigure �� and is identical to Schnorr�s identi�cation scheme �Sch�� with themodi�cation that c is computed as a hash value of the initial value a and themessage m� instead of choosing c random�

In the new blind signature scheme based on the protocol of Figure �� themodi�cations are all on the receiver�s side� The protocol is shown in Figure ��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

c� ! H�g��m� g�r�

h�c�

��

��

CAFE Final Report Volume II �� k�Spendability Extension

By itself this protocol is not very useful because the signatures can easily beforged by selecting g� and a as powers of h� This� however� is no problem in theway we use the protocol in payment systems� it is only of importance that it isguaranteed that g� is of the form gt or of the form ht� where the receiver knowst� t �! � See� e�g�� Sch�� for a more detailed explanation about the design andusefulness of this protocol� in this section we only look at its performance�

�� E�ciency Comparison

Using the above blind signature scheme in the CAFE protocols� we get thefollowing obvious improvements� In the gen cheque protocol� the issuer needsto send only one �� byte number to the payer� instead of two �this also saves oneexponentiation for the issuer�� A signi�cant improvement is that the numberof exponentiations to be performed by the payer is reduced by four per cheque�Also� the number of �� byte numbers that have to be handled is reduced byone throughout the whole payment system� The payment protocol improvessimilarly� Also� the number of system parameters is reduced and in general thecomplexity of the system is reduced throughout�

As will be addressed in Section �� another improvement is that the num�ber of �critical� exponentiations �those that have to be done online� unless oneinterleaves successive withdrawal sessions� which is infeasible for smart cardbased systems� is reduced from one to zero�

�� kSpendability Extension

�� Introduction

In all variations of the CAFE payment system cheques are implemented as ��spendable cheques� This means that each signature from the issuer authenti�cates a cheque which can be used twice� The payer will only be identi�ed if hepasses the tamper�resistant protection of the observer and spends the cheque atleast three times� Since the main bulk of the storage of a cheque in the payer�swallet comes from storing the signature of the issuer� the use of ��spendablecheques enables the payer to do more payments between withdrawals� increas�ing the applicability of the system� The price for this improvement in e�ciencyis a slight reduction of privacy as pairs of payments �corresponding to the samecheque� can be linked� In this section we �rst review the ideas for ��spendablecheques� Then these ideas are generalised to k�spendability for k ! �� and the resulting gain in e�ciency is estimated� In the analysis below onlythe � system is considered since both the � and �� systems can store a suf��cient number of cheques using the added memory of the physically separatepurse whereas the � system is limited to a single�chip implementation of thewallet� The k�spendability extension is inspired by the way fail�stop signaturesare extended to provide k messages with a fail�stop signature �Hey�� p��

��


�� kSpendability

A ��spendable cheque consists of the issuer�s signature �r� s� on a number ��Included in this signature is a commitment to two values �� and �� where�� is used in the �rst payment of the cheque and �� in the second payment�see Part III� Sections � and �� This is done by including ci ! H��i� fori ! �� as arguments to the hash function when computing the challenge c �seethe gen cheque protocols in Part III� Sections �� and ��

It is important that the payer is committed to �� and �� in this signaturesince this only leaves two possible ways to spend the cheque �even if the payerpasses the tamper resistance of the observer�� The only reason for making thiscommitment through the intermediary hash values c� and c� is that that inpayments not involving ��i it is su�cient to send ci �� bits� to the payee�Thus both communication during payment and storage requirement of receivedpayments at the payee and the clearing are decreased using the ci�s�

The method for ��spendable cheques can in a straightforward way be ex�tended to k�spendable cheques by simply letting the payer generate k di�erent��i�values and commit himself to these by including ci ! H��i� in the signa�ture� We consider two possible ways of doing this�

�� c is computed asH�c�� c�� ck� � a� ab� �� here means that paddingis used so that a multiple of �� bits is reached��

�� c is compute asH�root� a� ab� �� where root is a �� bit value obtainedby hashing the ci�s in a tree�like fashion �e�g�� see Figure �� for a ternarytree�� Note� that root is obtained by concatenating its sons �and paddingto obtain �� bits�� All other intermediary nodes are obtained by hashingthe concatenation of its sons� Since one round of the hash function maps�� bits to �� bits we only consider binary and ternary trees �hashingfour or more previous hash values requires more than one round of H��In the rest of this section d is � or � depending on whether a binary orternary tree is considered�

The next two subsections describe how the protocols for payment and de�posit are a�ected by each of these possibilities� In these descriptions it is as�sumed that the cheque is used in the i�th payment �� i � k��

List Like Hashing

If the �rst possibility is applied� then the only change to the payment protocolis that the payer must regenerate and send all cj �s for j �! i to the payee� andthe payee must use these values when verifying the blind signature�

The payee must store these k�� di�erent cj �s and send them to the acquirerduring the deposit� Otherwise the deposit protocol is unchanged�

�The remaining arguments to the hash function a� �� and ab are needed for the veri�cationof the signature�

��


Tree Like Hashing

The number of nodes in the path from ��i to root �not counting root� is atmost dlogd ke� Thus the payer must send �in the worst case� �d � ��dlogd keintermediary hash values to the payee� in order to let the payee verify that ��ihas indeed been committed to� Furthermore� the payee must compute dlogd kehash values in order to obtain root� Apart from this� the protocol follows thepayment protocol�

The payee must store these �d � ��dlogd ke intermediary hash values andsend them to the acquirer during deposit� The acquirer can then verify thecheque as described above� This is the only change to deposit�

�� E�ciency of the Suggestions

This section considers the implications for computation� storage and communi�cation by the above suggestions� Independently of the method for committingto �� k the most signi�cant changes to the protocols are

� Increased computing time in the wallet for generating cheques during thegen cheque protocol�

� Increased time for regenerating empty cheques in payment�

� Increased size of empty cheques� In the ��system an empty cheque consistsof

i� c� r� cj � ��i� ��

The size of this has consequences for the communication in payment anddeposit and for the storage requirements at payee and acquirer�

root

�

�

�

��

��

HHHH

HHHH

�

�

��

��

�I

��

�I

��

�I

��AAK

� �

� ��

��

Figure �� Committing to �� k for k � �� In order to verifythat �� is contained in the hash value� the nodes marked �� must be senttogether with �� and the nodes marked �� must be computed� Arrowsindicate hashing� lines indicate concatenation and padding to �� bits�

��


Operation Time �msec��

atomic update �

normal EE write �� bit� �

single exponentiation �ab mod n� �

double exponentiation �abcd mod n� �

hash of �� bit ��

�re�generate sigma pair �

Table �� Computation times for ��spendable cheques� The observer smartcard is running at �� MHz �twice normal ISO speed�� a� c� n are �� bitsnumbers� b and d are �� bits numbers�

Since it may be assumed that payee and acquirer both have su�ciently com�puting power� the extra computations of the hash function in the veri�cationof the cheque can be ignored�

The analysis of the time is based on the numbers displayed in Table ��showing the computation in the wallet implemented in a smart card of the basicoperations�

From this table we see that computation of one ci value requires approxi�mately �� msec �generation of ��i� ��i�� one double�exponentiation and onehashing��

Linear Hashing

The wallet needs time to generate �� k and some time to computethe hash value� c� The computation of c�� ck takes k �� msec�� and thecomputation of c takes

dk ��

��e# �

�� # �k msec�

During gen cheque� the computation of �� takes �� msec� and the restof the computation for the blind signature takes �� msec� for the followingoperations�

Computation of a � msecComputation of b �� msecVeri�cation of signature � msec

Furthermore� storage handling and communication during gen cheque takesapproximately � msec� Thus the time needed to generate one k�spendablecheque is approximately

�� # k �� msec�

For k ! � this amounts to � sec�� which is in line with measurements on theimplementation of the ��system�

During the i�th payment �� i � k� the wallet must regenerate ��i and allcj for j �! i� This takes �� # �k � �� msec� The rest of the computation

��


time for regenerating a cheque is independent of k and will be estimated to �� msec� �� msec is required for the regeneration of �� and �� and at most � msec for storage handling�� Thus the computation time is approximately

�� # �k � �� msec�

An empty cheque needed for the i�th payment consists of

i� c� r� �cj �j �i� ��i� ��

Assuming i can be represented by � byte� this requires the communication �andstorage at the payee� of

� # � # � # �k � �� # � �� ! �� # �k � �� bytes�

With �� baud and �� bits per character the communication takes approxi�mately�

�� # �k � �� msec�

Thus compared to the computation time� the communication time is not seri�ously a�ected by the value of k� Similarly� the increased need for storage atpayee 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�k�� if the tree is binary and bk� c#k�� if the tree is binary� or approximatelyd

d��k � � in general�Generating a cheque requires the generation of all ��i�s and the computation

of root� This takes k �� # � dd��k � �� msec� From the analysis above it

follows that generating a k�spendable cheque takes time �in msec��

Compute root k�� # dd��

Compute c � Generate �� Computation for blind signature �� Storage handling �

Thus� in total the computation time in the wallet when generating a cheque is�� # k �� # d

d�� msec�During the i�th payment �� i � k� the wallet must regenerate ��i and all

internal nodes in the tree except those on the path from ��i to root� Based onthe analysis above� regenerating an empty cheque takes

Regenerate all ��i�s k �� Regenerate internal nodes �� d

d��k � �� dlogd ke� ��Regenerate �� Storage handling �

Thus� in total this the wallet needs �� #k �� # dd��dlogd ke� �� msec�

for regenerating a cheque�

��


An empty cheque needed for the i�th payment consists of

i� c� r� ��i� ��

and all internal hash values needed to compute root� In the worst case �d ��dlogd ke such hash values are needed� Thus in total

�� # �d� ��dlogd ke � bytes

are needed� With �� baud and �� bits per character communication of anempty cheque takes approximately�

�� # �d� ��dlogd ke�� msec�

Comparison

The three methods are quite similar in complexity� with the binary tree beingsomewhat slower for �re�generating cheques in gen cheque and payment�

However� the binary tree provide the smallest empty cheques� followed byternary trees and linear hashing� Again� the di�erences are quite small and inall systems communication time is dominated by the computation time in thewallet� Thus it will be most e�cient to use the method for linear hashing orthe ternary tree�

�� Conclusion

We now consider the e�ciency of using k�spendable cheques for various values ofk if the commitment to �� k is done by linear hashing� Assume the payershould be able to make � payments between two withdrawals� This requiresNk�spendable cheques where N k ! � � Table �� shows how di�erent valuesof k a�ects the time for generating the necessary cheques �computation in wallet# communication�� the time for regenerating an empty cheque �computationin wallet� and the size of an empty cheque�

N k generating reg� empty cheque size of empty cheque

� � � sec� � msec� �� bytes

�� sec� � msec� �� bytes

� � � sec� �� msec� �� bytes

� �� sec� �� msec� �� bytes

Table �� Complexity of k�spendability� The third column is the time forgenerating N k�spendable cheques� the fourth is the time for regeneratingone empty cheque� and the third is the size of an empty cheque�this sizehas consequences for the communication complexity�

We see that going from � � to ��spendable cheques hardly gives any ef��ciency improvement in gen cheque� Thus there is no reason to take larger

��

CAFE Final Report Volume II �� Exploiting Pre� and Post�processing

values of k� However� already k ! � may be too large since payment will takearound � sec� and relatively many payments can be linked�

Thus it will be possible to improve the e�ciency of gen cheque with a factorof � without damaging the rest of the system by using choosing k a little largerthan � �e�g�� k ! � or k ! �� This gain in speed can either be used to obtainmore cheques or to decrease the time needed for withdrawal�

If the cheque is regenerated while payer and payee are negotiating the deal asdescribed in Section �� it is not necessary to consider the time for regeneratingcheques when choosing the value of k �since the communication time is relativelysmall even for large values of k�� In that case the value of k should be chosenas a tradeo� between privacy �unlinkability of payments� and e�ciency�

�� Exploiting Pre and Postprocessing

�� Introduction

In the performance analyses of the proposed CAFE systems we have mostlyignored the possibility of preprocessing and postprocessing to speed up the on�line part of various protocols� In this section we will investigate to what extentthe e�ciency of the current systems may be increased by exploiting primarilypreprocessing but also postprocessing to re�ne the protocols�

For the sake of our discussion we will view a protocol executed between twofunctional entities as consisting of three stages�

�� Preprocessing by both functional entities�

�� Exchange of messages between the entities and the necessary computa�tions�

�� 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 thecomputations necessary to complete these message exchanges� As the on�linepart 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 thatin�uence the �minimal� length of the on�line part� Clearly� assuming that thereis su�cient space to store intermediate results� any computation that does notdepend on any message can be done in preprocessing� and any computationon which no messages depend can be done in postprocessing� However� alsothe order in which messages are exchanged and the number of rounds in whichthey are exchanged a�ects the length of the on�line part� since both entitiesmust have �nished the necessary computations before a message exchange cantake place� Given that the intermediate storage of the payer�s wallet is usuallylimited� the order in which the steps of a protocol can be arranged is restrictedtoo� and we are faced with a scheduling problem�

The use of o��line processing will be most e�ective for the � system� wherethe payer uses a full��edged wallet with its own power source and computer�

��


As the two�button wallet in the �� system also has its own power source� o��line processing is interesting in this scenario� too� And even in the smart cardonly � system the possibility of o��line processing cannot be ignored as a smartcard 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 aswell �e�g�� reload station� acquire station and till�� Similarly� o��line processingplays a role when wallets are personalised� although personalisation normallytakes place only once in the lifetime of a wallet� it is clearly in the interest of thepersonalisation entity that this can be done fast �e�g�� to limit the connectiontime with a trusted server such that this does not become a bottleneck of thesystem��

In the remainder of this chapter we will concentrate on the withdrawal andpayment protocols for the proposed CAFE system� The goal is to obtain someestimates for possible improvements�

�� Withdrawal protocol

The performance of the withdrawal protocol depends critically on the per�formance of the gen cheque protocol as this part will be iterated until thedesired number of cheques is reached� Other major parts of the withdrawalprotocol such as authenticate and write cu tbl are only executed once perwithdrawal� so the expected gain of optimizing these parts may be consideredmarginal �and these parts are pretty much sequential in nature too��

We will �rst consider the � system� Considering a single execution of thisprotocol in isolation� we see that the critical online part are the computations ofthe � wallet between the �rst and the second message exchange �see Figure ��on page �� This part is depicted in Figure ��

� wallet Reload station

��a�� b��

a� a�GvcP

uc mod p

b� �b�gvcp

uc �

�� mod pc�H�c�� c�� a� ab� �� c� � c� u mod q

� c��

Figure �� Critical part of gen cheque

Because of the additive way the blinding is done� only one of the exponenti�ations required for the computation of a and b cannot be done in preprocessing�rather than a multiplicative way of blinding as in �CP�a�� which requires twoexponentiations online�� More precisely� Gv

cPuc and gvcp

uc can be precomputed�

and only the exponentiation with exponent �� remains��

�An advantage of the scheme in Section �� is that the critical part doesn�t contain asingle exponentiation�

��


� wallet Reload station

� � �a� � Gv

cPuc mod p

b� � gvcpuc mod p

c� �H��c�� c��

��a�� b��

a� a�a� mod p

b� �b�b�� mod p

c�H��c�� a� ab� �� c� � c� u mod q

� c��

Figure �� Critical part of gen cheque with preprocessing

Also� the �rst part of H�c�� c�� a� ab� �� may be precomputed� suchthat upon completion of the computation of a and ab only the remainder of thiscomputation needs to be done� This approach would be even more e�ective if�� and �� would appear before a and ab but this may degrade other parts ofthe implementation� This transformation is sketched in Figure �� where H�

indicates the �rst part of the computation of H� and H�� the continuation ofthis computation�

Also� it should be noted that in case computations can be done while mes�sages are received �because this is handled by di�erent parts of the entity�s de�vice�� it is advantageous to start the computation of a as soon as a� is received�It may even be advantageous to send b� �rst in that case as the computationof b requires an exponentiation�

To make such a revision of gen cheque useful� we have to interleave theexecutions of the protocol� That is� instead of executing the complete protocolrepeatedly in a sequential fashion� we �rst execute the preprocessing for eachof the executions� then the online part of each execution� followed by the post�processing parts� In this case� the online parts might be interleaved as well�which amounts to �rst sending all a�� b��values� then all c��values� and �nallyall r� values� Clearly� this approach requires quite some intermediate storage�in particular if the number of cheques per withdrawal is high �e�g�� for the � sys�tem�� However� even for the � system these improvements can be done to someextent by observing that once a cheque has been spent successfully� the freedspace can be used to store results of the preprocessing stage of the gen cheque

protocol�� The preprocessing can be done whenever the smart card wallet isidle while inserted in a reader� For the �� system the preprocessing stage ofthe gen cheque protocol can be done whenever a payment is completed thatfreed some space� which results in a speed�up of the withdrawal protocol by a

�Only successfully completed payments free the required space� In case of interruptedpayments the space is needed for recovery� In such exceptional cases however the withdrawalis going to take more time anyways�

��


constant factor�

If we assume that for the �� and � scenarios su�cient space is available tostore preprocessed values for gen cheque� the wallet may precompute �anytimeit is idle and powered on� values for the gen cheque protocol� Then the onlypart that remains to be done is the on�line part of Figure �� The time forthis part is dominated by the time required for one exponentiation and to alesser extend the time for the hash� A rough estimate indicates that a speed�upof % ( is possible for the withdrawal� With the blind signature scheme ofSection �� the speed�up will be even more signi�cant�

To estimate the possible speed�up of the withdrawal protocol for the smartcard only � system� we consider the following modi�cation� As each secondpayment frees at least � bytes of EEPROM� the idea is to preprocess thecomputation of c� and c� for the gen cheque protocol� these numbers are � bytes each and can thus be stored in the freed cheque slot� The tag of thecheque slot should then indicate that it contains the preprocessed values insteadof a cheque� As the generation of each of the c�values takes about �� ms �seeprevious section�� it means that each second payment will take about �� secondsextra to compute and �atomically� store these numbers �atomic update takes� ms�� On the other hand� each execution of gen cheque will take about ��seconds less time� As the total time of gen cheque is estimated to take � second�see previous section�� the resulting speed�up is ��(�

Note that for ��spendable cheques� the freed storage nicely matches withthe space needed for the two � byte numbers� For k�spendable cheques withk � � this is not true anymore� so the resulting speed�up will be less than ��(�

�� Payment protocol

Also for the payment protocol of the � system there is some room for improve�ment� The way in which the respective messages between wallet and the tillare exchanged has not been optimized yet to reduce the idle times of the twoentities� For instance� the regeneration of the cheque that is going to be usedin the payment� is only performed after the till has supplied the payment infor�mation in the �rst message exchange of the payment protocol� see Figure �on page �� A problem with this approach is that the storage in registers andRAM is rather limited for an � smart card� A rough estimate� though� is that itmight just �t� i�e�� that the values cj � ��i� �� may all be precomputed� Againin case the blind signature scheme of Section �� is used� this will �t moreeasily as it requires one �� byte number less� in this case� precomputing thevalue of � for phone payments may also be considered�

The computation of the hash value H��i� �� pay to� pay fro� cu to� cu fro�IDP � pay type� date� �� T �� is also time consuming� Again� as done in theprevious section� the computation of this hash value may be started as soonas the �rst blocks of data are available� As the till only supplies �� after the�computationally demanding� veri�cation of the cheque has been completed�there may be su�cient time for the wallet to complete all of the computationof H��i� �� pay to� pay fro� cu to� cu fro� IDP � pay type� date� �� T ��except for the last block�

��


Similarly� the value of � in the phone�tick part of the payment protocol�Figure �� can be precomputed to speed up the handling of a tick�

Again� for the �� and � systems these techniques will be more e�ective�As the part of the payment protocol that depends on the till�s messages isrelatively small� the on�line part of payments may be reduced considerably if�� or � wallets are used�

�� Conclusion

We have considered some improvements for the withdrawal and payment pro�tocols� 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 ��(reduction of the time needed for a withdrawal is possible� For the �� and �systems the speed�up may be as high as % (� provided some memory of thewallet is reserved for the storage of precomputed values� Also� we have shownthat the on�line part of the payment protocols may be reduced to the timerequired for some simple computations and memory operations �no exponenti�ations have to be done online��

The improvements will be even more signi�cant if k�spendable cheques forother small values of k �larger than �� as proposed in the previous section� areused and if the blind signature scheme of Section �� is used�

��


��


Chapter ��

Multi�Currency Payments

�� Introduction

One of the main features to be demonstrated in the �eld trial is that of a cross�border electronic wallet� Such a system enables a user to load digital currencyinto the wallet� and then pay for goods and services in several countries�

The CAFE system has been designed to operate in a multicurrency envi�ronment� The properties and workings of multicurrency payments are treatedhere� The structure of this chapter is�

� Discussion on multiple issuers and multiple currencies� The importantcryptographic distinction is the assignment of secret keys to be used whenissuing digital currency�

� The protocols and procedures for using multiple currencies with the �wallet� the �� wallet� and the � system with the functional completewallet�

�� Multiple Issuers

The issuer and the acquirer are often combined and referred to simply as thebank in the CAFE context� The currency withdrawn from the bank carries thesignature of the bank� Every issuer has its own set of signature keys� Thesekeys are kept secret by that bank� The corresponding veri�cation keys will becerti�ed by the realm certi�cation authority� along with the accreditation ofthe bank to be an issuer of digital currency of that realm�

The CAFE withdrawal transaction combines issuing of digital currency withthe debiting of the account of the payer� because the identity of the payer mustbe �imprinted� with the cheque� Hence� the withdrawal transaction must be�online� with the digital currency issuer� This is in contrast to the currentcash system� where the central bank is the issuer� both in technical and mon�etary terms� Currently� the commercial banks operate as distributors of coinsand notes� In CAFE the technical issuing procedure is an integral part of thewithdrawal transaction�

The bank will provide the payer with the certi�ed public veri�cation keyof the issuer� At the payee� the certi�ed veri�cation key will either alreadybe available to the till� or it can be requested from the payer� who will bringthe issuer�s public key stored in the wallet� The key for the veri�cation of thecerti�cate must be installed in the payee�s till device prior to normal operation�This is part of the CAFE key management system�

��

Chapter �� Multi�Currency Payments CAFE Final Report Volume II

�� Multiple Currencies

Before discussing multiple currencies� we recall that the term home currency isthe default unit of account for the payer�s wallet� The term local currency isthe default unit of account for the payee�s till�

For the payer� there exists two possibilities for paying where the home cur�rency of the payer is di�erent from the local currency of the payee�

� Exchange before payment�

� Exchange at payment�

Both kinds of currency exchange can coexist in the system�

�� Exchange Before Payment

The exchange will take place at withdrawal time� The issuer will supply digitalcurrency in the foreign currencies requested by the payer� Each currency willhave its own balance in the currency table stored in the wallet�

Primarily� a bank in the CAFE system will issue digital currency pegged tothe domestic currency� Furthermore� an issuer can be enabled technically toissue digital currency pegged to other national currencies� The wallet holdsbalances in several currencies� and exchange from one currency to another canbe requested by the payer during the withdrawal transaction with the reloadstation�

Hence� the CAFE system allows for several issuers� each issuer being able toissue several currencies� To �t existing arrangements� this must be conditionedon legal accreditation by the central bank governing the actual currency� Forinstance� commercial banks can be granted the right to issue a certain amountof foreign money in return for buying bonds from the central bank governingthe currency� On the other hand� the multicurrency mechanisms of CAFE cane�ciently support more liberal monetary agreements�

�� Exchange At Payment

The current economic state of �oating currency exchange rates induces a risk byholding a particular currency� The CAFE system can easily adopt to the rulethat whoever holds the currency accepts the risk of �oating exchange rates�However� the CAFE system can also allow a forward exchange agreement be�tween the payee and the acquiring bank� where the acquiring bank commits toa set of exchange rates� This eliminates the payee�s risk of accepting foreigncurrencies�

The payee will accept non�local currency during a payment transaction�anticipating it to be converted by the payee�s acquirer to local currency atagreed upon rates� The payee will be credited by the acquirer with the amountrequested during payment in local currency� while the payer can spend non�localcurrency available in his wallet� The exchange rate o�ered by the payee mustbe accepted by the payer� The payee presents the amount and the exchange

��

CAFE Final Report Volume II �� General Requirements

rate� and the payer�s wallet will be able to present the amount denominated inhome currency�

So in general� the payer will be able to pay with one or more of the currenciesin his wallet� conditioned on acceptability by the payee� This practice of accept�ing multiple currencies can be observed� for instance� at shops in internationalairports�

Here is a more detailed example of how the practice may work� The payeewill make an agreement about forward transactions with the acquirer� whereinit is stated the types and maximum amounts of currencies that are acceptablefor deposit� and which exchange rates that the acquirer commits to� and thetime period the commitment is valid� Then the payee can use �at least� theseexchange rates when o�ered payment in non�local currencies� The payee�s priceis denominated in local currency� the till will compute the amount in the homecurrency of the wallet� In addition� the exchange rate o�ered is presented tothe payer�

Note that we say �exchange at payment�� This is the payer�s point of view�If the payer accepts a given exchange rate o�ered by the payee� it is equivalentto currency exchange� Nevertheless� the payee will receive and hold non�localcurrency� The actual exchange from the payee�s point of view will take place atdeposit time� If the payee has an exchange rate commitment from the acquirer�there is no practical di�erence� However� if the rate has not been predetermined�the actual currency exchange will take place at deposit time� that is� �exchangeafter payment��

�� General Requirements

�� Exchange Before Payment

These are the requirements of an exchange transaction between the payer andthe issuer� typically at withdrawal time�

�� The exchange will only take place if the payer and the issuer agree on thesource and target currencies� the amount to be converted and the rate tobe used�

�� As long as the wallet does not contain more than max curr di�erent cur�rencies� the payer can introduce a new currency into the wallet� The totalbalance represented by all currencies should not exceed the value max bal�

�� The source currency of the exchange can either be the home currency ora currency already available in the wallet�

�� Exchange At Payment

These are the requirements with respect to payment and deposit transactionswhen a the payment currency is di�erent from the local currency of the payee�

��


�� The payment will only take place if the payer and the payee agree on thesource currency �typically home currency�� the target currency �typicallylocal currency�� and the exchange rate to be used�

�� The payee can restrict the set of acceptable currencies in a payment trans�action�

�� The payee can only deposit the spent cheque if the exchange rate used inthe payment is accepted by the acquirer� Then the acquirer will credit thepayee�s account by the value in local currency� whereas the payer currencyclaim will be submitted to the clearing system�

�� The clearing system will account for claims in all the currencies availablein the payment system�

�� Protocols and Procedures

�� The � Wallet Protocols

The � wallet �typically implemented as a smart card� stores a currency�table�each row containing currency identi�er� the balance and the exchange rate tohome currency� The �rst row indicates the home currency of the wallet�

Withdrawal The write cu tbl protocol serves to provide an updated andvalid currency�table to the wallet� The reload station will give the payer thefollowing choices which may involve currency exchange�

� Perform currency exchange of value stored in the wallet�

� Withdraw from account and store in a speci�ed currency in the wallet�

� Deposit to account from a speci�ed 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 compoundingamounts in several currencies� The payment protocol is executed once for everycurrency� until the total has been paid� The reference implementation of the �system admits the total amount charged by the payee to be paid using subtotalsof di�erent currencies� a multicurrency payment� This multicurrency paymentis realized by spending one cheque for each currency� ending when the grandtotal 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 mea�sured in the home currency and the local currency units� This procedure isskipped if the payer does not have a choice�

It is up to the payee �the till� to indicate the local currency� which will bethe 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

��

CAFE Final Report Volume II �� Protocols and Procedures

payer request it� The till can decide which currencies to accept according toprearranged rules� If ambiguity arises then the help of the payer is requested�

�� The Trial Implementation

In the trial� the � wallet is realized in the form of a smart card� Hence� we referto �card� as the � wallet in this subsection�

During the �rst phase of the trial only Belgian Francs �BEF� will be acceptedas tender for value loaded onto the cards� A card can be loaded with value inboth BEF �home currency� and ECU� The exchange rate at loading will beidentical to the exchange rate at the point of sale� thus nullifying the risk ofcurrency exchange both at loading and payment time�

The general rules of multicurrency operation implemented in the trial areas follows�

� When the home currency matches the local currency and the balance ofthe card is su�cient� the payment will be in local currency�

� If the local currency is di�erent from home currency� or there is insu��cient home currency then the payment currency will be ECU providingthere is su�cient balance� The payee will provide the exchange rate thatdetermine the ECU value from local currency value�

� If neither su�cient local currency nor ECU is available in the card thenthe payment transaction is aborted� even if the compounded value of bothcurrencies is su�cient�

This implies that in the �rst phase the home currency will always matchthe local currency� which is BEF� Only when the BEF balance on the card isinsu�cient to cover a payment will ECU be spent� The cash register will alwaysdisplay the paid amount in BEF� whereas the payer�s receipt and display willshow the value in the currency taken from the card�

�� The �� Protocols

The trial includes �� wallets� in the form of two�button devices equipped withdisplay� infrared communication� and smart card connector� With the func�tional 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 aset of rules are needed to choose the currency�

�� The currency table of the card is sent to the till� The till �rst looks for abalance in its local currency� If there is one� and it is su�cient to coverthe purchase� it is used�

�� If the local currency balance is insu�cient� the till searches the currencytable row by row� starting with the �rst� until it �nds a balance thatcontains su�cient value� and for which it has a valid exchange rate�

�� If the search of the currency table does not locate an acceptable row� thepayment fails�

��


By convention� the issuer will load home currency in the �rst row of thetable� Hence the search rule described above will favor home currency after localcurrency� This will never happen in the trial because tills will have exchangerates only for ECU� In other words� the only acceptable currencies will be BEFand ECU�

Remarks� Cases can be created where the wallet contains su�cient value� butwill be prohibited by the above procedure to make a payment� For instance� suf��cient value only can be accumulated from several currency balances� Anotherpoint to make is that the system operators should be careful about how onecurrency is preferred with respect to another� because this embed the �static�rules for selecting the preferred currency rather than leave it up to the payerand payee to decide�

There is an option to show the payer the total value of all currencies storedin 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 anapproximation 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 withrespect to the local currency� These exchange rates will be o�ered in a payment�and presumably have been supplied by the payee�s acquirer�

�� The � Protocols

Recall that the � wallet device is realized as a hand�held computer device withkeyboard and display� and as such can o�er standalone interaction with thepayer� The two main functional entities of the wallet are the purse� whichis completely payer controlled� and the observer� which is completely issuercontrolled� Both purse and observer store a currency table that is of the sameformat as in the � system�

The purpose of the show currencies protocol is to present the content ofthis currency table to the payer through the display of the wallet� Also� thedecision of which currency to use in a payment can be made by the payer locallyinteracting with the purse� During payment� the purse requires user interactionto choose the currency to be used in the payment� Hence� it is not necessaryto send the currency table to the payee� The rest of the payment protocol issimilar to the � system with the purse added� Of course� the default currencyis the home currency of the wallet� The payee will return the requested amountin local currency� The wallet may display the amount both in local and homecurrency and the actual exchange rate�

The details of the user interaction with the wallet for currency exchangeduring withdrawal are not described�

��


Chapter ��

Credential Schemes

�� Introduction

A credential will be thought of as a signed message stating that a given per�son has a given right or property and constitutes as such a generalisation ofelectronic currency� The two fundamental transactions are issuing and showing

credentials� A credential will be issued by an organisation to an individual� andthe individual will show the credential to one or more organisations�

The process of showing a credential should be o��line� Ideally� the sameshould hold for issuing a credential� but this is of less importance since a cre�dential will be issued once and often shown many times� In these cases issuingonly contributes very little to the overall cost of handling the credential�

A relatively simple credential scheme can be constructed given any digitalsignature scheme�

InitialisationFirst set up a key management centre�

Each organisation and individual selects a key pair for the signaturescheme� and gets a certi�cate on the public key at the key managementcentre�

IssuingOrganisation O issues a credential to individual I as follows�

�� I proves his identity to O�

�� If O decides to issue the requested credential� a signature on a mes�sage containing the public key of I and a description of the credentialis made�

ShowingI later shows this credential to organisation� O�� by proving his identityand presenting the credential to O�� O� veri�es the identi�cation� thesignature on the credential and that the certi�cate on the public key iscorrect�

This credential scheme requires that the individual is uniquely identi�ed ineach transaction� This is necessary in some situations� but in others it may bea nuisance�

Therefore� one goal of the credential scheme presented in the following isto allow anonymous use of credentials� Very brie�y� this means that each in�dividual is only known to organisations under a pseudonym� Organisation O

��

Chapter �� Credential Schemes CAFE Final Report Volume II

determines whether or not to issue a credential based on the history of thispseudonym within the organisation �i�e�� which credentials have been shown toO under this pseudonym��

It should be noted that a credential scheme supporting anonymity does notprevent that an organisation requests identi�cation 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 toidentify an anonymous individual abusing the system �e�g�� showing a credentialmore times than allowed�� As for electronic currency we therefore� add thepossibility to identify individuals committing certain frauds� Following previousterminology this will be referred to as fall�back integrity�

Section �� gives a more thorough description of credential schemes includ�ing the necessary transactions and security aspects� Section �� then presentsthe technical details of a credential scheme built upon the CAFE kernel usedin the payment systems in Part III� The detailed analysis of the proposedscheme is omitted here� but the most important aspects of the security arebrie�y mentioned� The chapter is concluded with a short description of someof the applications of the proposed credentials� which have been considered inCAFE�

�� Credential Mechanisms

The following describes a general model of credential schemes based on �CE��The roles in a credential scheme are a number of individuals and organisations�An organisation issues a credential to an individual� and an individual presentsthe credential to one or more organisations� Thus organisations should beable to issue credentials �possibly of several di�erent types� as well as acceptcredentials issued by other organisations�

Each individual has a pseudonym with each organisation which the individ�ual either gets a credential from or presents a credential to �see Figure ��Thus an organisation issues a credential on the individual�s pseudonym� andwhen the individual wants to present the credential to another organisation he�rst has to convert it to a credential corresponding to his pseudonym with thatorganisation�

To facilitate constructing such a credential scheme a few additional rolesmay be needed�

Registration centre One or more centres registering pseudonyms� If an in�dividual�s pseudonym with a given organisation is registered at such acentre� the centre makes a so called validator proving that the pseudo�nym has been registered correctly� Such a centre must be trusted by theorganisations 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 allowedcredentials�

��

CAFE Final Report Volume II �� Credential Mechanisms

OrganisationsInd� O� O� � � � Ok

I� P�� P�� P�k

I� P�� P�k

� � � �� In � Pn� � � � Pnk

Figure �� Pseudonyms in organisations �� indicates that an individual hasnot 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�� Thisis useful for privacy reasons as it may be possible to identify recognisethe individual if he gets or shows a credential himself �e�g�� by physicalappearance or by tracing a communication line��

Credential clearing As for o��line payments a clearing infrastructure maybe required to detect whether a credential has been used incorrectly �e�g��whether a credential has been used more times than allowed�� Further�more� the credential clearing �nalises possible outstanding issues�

For simplicity we shall not consider representatives here� Furthermore� itwill be assumed that pseudonyms are registered at a registration centre� Z�Thus the concept of validators will be essential�

�� Required Protocols

For the sake of generality assume that each organisation can issue severaltypes of credentials� For a given credential this is described by the param�eter class� The following three protocols are the basic building blocks of acredential scheme�

register pseudonyms This protocol allows an individual� I� to register a pseu�donym� The result of this protocol is a publicly known validator and apseudonym� which only the individual gets to know at this point �pluspossibly some secret information needed to use the pseudonym��

issue credential This protocol allows an organisation �possibly with the helpof an issuing centre� to issue a credential described by class on a pseudo�nym� If the organisation has not registered the pseudonym previously� avalidator on the pseudonym should be supplied by the individual request�ing the credential�

show credential This protocol allows an individual having a credential topresent it to an organisation �under the pseudonym with that organisa�tion��

��


In the following we shall be concerned with o��line credential schemes forwhich detection of abuse after the fact is required� Therefore� the followingprotocol is required as well�

deposit cred This protocol involves credential clearing and an organisation�which has accepted a credential� It allows the organisation to submitthe credential to the credential clearing� and the clearing will investigatewhether the credential has been used properly�

For completeness� we mention that a credential scheme may involve otherprotocols� such as

� A protocol for revoking credentials and validators� This is useful in caseabuse is detected� In a totally privacy protecting scheme this may not bepossible �eventually credentials or validators should expire� though��

� Transferring credentials to another individual� This is useful in paymentsystems� 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 consideredfurther�

�� Security Aspects

In the following we describe the security requirements that the protocols de�scribed above must satisfy� At this informal level only the general principles aredescribed� Since� deposit cred depends on the kind of abuse to be detectedit will not be treated at this general level� First� however� the fundamental as�sumptions 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 betweenthe roles is required� Most notably� the individuals trust that Z will helpregistering them� However� for the registration at organisations� it is up to theorganisation whether it wants to register an �anonymous� individual under agiven pseudonym�

The organisations trusts that Z veri�es the identity of individuals properly�and that it only issues validated pseudonyms if this veri�cation succeeds�

Finally� for anonymity each individual trusts that other individuals are alsointerested in protecting their privacy� Otherwise� if all individuals but onehappily identify themselves in each transaction then implicitly the last one willalso be identi�ed�

��

CAFE Final Report Volume II �� 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� asubsequent execution of issue credential will lead to a credential� which willlater be accepted in an execution of show credential�

A pair �p� v� of a pseudonym and a validator is called correct for individualIj if Ij can later get or show a credential under the pseudonym p�

Other aspects of availability� such as the ability to actually execute theseprotocols depends on the good will of the involved actors �i�e�� that they arewilling to participate in the protocol��

Requirements to Integrity

For register pseudonyms� it must be infeasible to make a pair �p� v� of apseudonym and a validator unless the registration centre is willing to issuesuch a pair�

It must be infeasible to obtain a credential unless the organisation is willingto issue such a credential in an execution of issue credential�

Finally� if a credential is issued under a pseudonym of Ij it should be infea�sible to show it under a pseudonym of Il if l �! j�

Requirements to Anonymity

In an execution of a protocol between two roles� each role gets a view consistingof the input to the protocol� the random bits used by this party and the messagesreceived �see �GMR�� we have included the input in the view for simplicity��The distribution of such a view is induced from the random bits of the otherparticipant in the execution�

Assume� that the registration centre has registered n honest individuals forboth organisation Os and Ot� It is required that given

� the registration centre�s view of a registration at Os and a registration atOt�

� 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 ofissue credential and show credential belong to a given individual amongthese n individuals is �

n � This must remain satis�ed if the registration centreand organisations deviate from the prescribed protocols�

This requirement takes into account that the registration centre may knowto which organisation an individual is being registered� and that when a cre�dential is shown the recipient knows who issued it� Note that� this requirementimplies anonymity of the individuals in issuing and showing of credentials�

��


�� Existing Schemes

Payment schemes can be considered special credential schemes� but to our know�ledge only very few general credential schemes have been suggested in the publicliterature� In the following we consider two proposals�

The most well�known scheme is probably that of Chaum and Evertse in�CE�� This scheme is based on RSA �RSA�� and requires a trusted reg�istration centre for registering pseudonyms and an issuing centre for issuingcredentials �as pointed out in �Cha � these two centres need not be identical��Once an individual� Ij has received a credential from organisation Os underpseudonym Pjs this credential can be shown to another organisation Ot underthe pseudonym Pjt with that organisation without interacting with the centres�This procedure relies on algebraic properties of RSA and can be done withoutproviding any link to the individual�s identity or the issuing of the credential orother presentations of the credential� By the algebraic properties of RSA thisscheme is very �exible� and can be applied to various settings� This is discussedfurther in �Cha ��

Thus� in short� this scheme is very �exible and protects the anonymity ofthe individuals very well� but the security against forgeries relies completely onthe 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 �Che�� In thisscheme the role of the centres is reduced� but it only allows an individual toshow a credential once �more presentations can be linked�� A registration centreis 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 duringthe credential issuing protocol� Later when the individual wants to present thecredential to organisation O the signature on the intermediary pseudonym isshown and the individual proves knowledge of a certain connection between theintermediary pseudonym and the pseudonym with O�

The advantage of this scheme is that a trusted centre is only required forsetting 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�

�� Credential Protocols

This section describes an extension of the CAFE payment system to credentialsin two steps�

�� A variation based on a scheme of Chen �Che��

�� Enhancement of the functionalities o�ered by the variation of Chen�s sche�me�

In this chapter we use a similar type of �gures as introduced in Part IIIto describe the protocols� We have however not introduced functional entities

��

CAFE Final Report Volume II �� Credential Protocols

for the credential scheme� so protocols will be executed between roles and notbetween functional entities as in Part III�

�� Required Keys

As usual p and q denote primes such that q divides p � �� The numbers g�h and G are all generators of the subgroup of ZZ�p of order q� Later two moregenerators are needed� h� and h��

The scheme assumes a registration centre� Z� for registration of pseudonyms�This registration centre has a secret key� x � ZZq� and a public keyH ! Gx� Thiskey�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 assumedthat each organisation� Ok� has published g

xkand hxk � In Section �� we alsoneed the numbers hi�k ! hxki for i ! � ��

The authenticity of these keys will be assured through certi�cates issued bya key management centre�

�� Blind Signatures and Identi�cation

The credential scheme uses the blind signature protocol shown in Figure �� onpage �� Recall that on input a message m� the receiver can get a signature onthe message mt

� 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 thatP ! �guh�s must identify the individual� This is done using the protocolfrom �Oka�� depicted in Figure �� We refer to �Oka�� for an analysisof this protocol� The security of the credential scheme depends on the followingimportant property�

Proposition �� If an individual� I� is able to make an organisation accept

in Figure �� then I �knows� a pair �u� s� such that P ! �guh�s�

Individual Organisation

�P ! �guh�s�

w�� w� �R ZZqa� � gw�hw�

� a��c �R ZZq

�� c��r� � w� # cus mod qr� � w� # cs mod q

�r�� r��

gr�hr��! a�P

c

Figure �� Identi cation protocol�

��


Individual Ij Registration centre

uj �R ZZqBj � gujh

Cj � �gx�uj �hx�w �R ZZqa� gw

�Bj � a��

Bj fresh 'c �R ZZq

�� c��r � w # cuj

� r��gr

�! a�Bjh�

c

register Bj for this individual

Figure �� reg user� Registration of a universal pseudonym�

�� Protocols

The scheme to follow is inspired by that of Chen� The main di�erence betweenour suggestion and Chen�s scheme resides in the realisation of personal regis�tration numbers �universal pseudonyms in our description�� It seems that oursuggestion leads to a more e�cient protocol and that it facilitates enhancedfunctionality�

From the description it should become clear that this variation can be seenas almost completely constructed from what can be called the CAFE securitykernel� i�e�� the building block consisting of the blind signature scheme and themechanism to provide checks based on it� The functionality is exactly the sameas in the scheme of Chen�

Getting a Pseudonym

At the registration centre� Z� each individual Ij chooses a universal identi�eruj at random� The corresponding universal pseudonym is

Bj � gujh�

After individual Ij has presented Bj to Z� it is checked that Bj is not listed al�ready as a universal pseudonym� If it is fresh� Ij proves knowledge of logg�Bjh�using the proof underlying Schnorr signatures� Next� Z registers Bj togetherwith the necessary information about the real life identity of individual Ij � SeeFigure �� for the details�

Furthermore� for each organisation Ok� the individual chooses a randomvalue sjk� The pseudonym with organisation Ok will eventually be

Pjk � Bsjk �

��


Individual Ij Registration centre

sjk �R ZZ�qPjk � B

sjkj w �R ZZq

Cjk � ��gxk�ujhxk�sjk

z � Csjkj a� � Gw

u� v �R ZZq b� � Bwj

��a�� b��

a� a�GvHu

b�b�B

vjC

uj

sjkc�H�Pjk� z� a� b�

c� � c# u

� c��r� � w # c�x

�� r��r � r� # v

ab�! �GPjk�

r�Hz��c

Figure �� get pseudonym� Obtaining a validated pseudonym Pjk �

Finally� Z gives a blind signature � on Pjk� Here Ij needs Cj ! Bxj � which

is computed in reg user� The protocol is shown in Figure �� Note that Zknows neither uj nor Pjk�

This protocol results in Ij getting a signature ��Pjk� of the form �z� c� r� onthe pseudonym Pjk�

Registration of a Pseudonym

Individual Ij later registers with organisation Ok under pseudonym Pjk bysimply submitting �Pjk� ��Pjk�� and proving knowledge of a representation ofPjk with respect to generators g and h using the method in Figure �� seeFigure �� for all details��

This identi�cation must repeated each time the individual contacts the or�ganisation in order to prevent that other individuals gets or shows credentialsunder the pseudonym� This can be done using reg pseudonym� since this pro�tocol only asks for a validator for new pseudonyms�

The idea behind this registration procedure is that an individual� Ij� isuniquely identi�ed by uj� By the property of the blind signature scheme �seeAssumption � �� p� �� Ij can only get validated pseudonyms of the form�gujh�tGt� for some t� t� � ZZq� Here t� ! � since otherwise the identi�cation inreg pseudonym will fail �by Proposition ��

��


Individual Ij Organisation Ok

��Pjk��

If Pjk is not registered then

��Request validator��

��Pjk��verify ��Pjk��Pjk �! �a� GrH�c

b� P rjkz

�c

c�! H�Pjk� z� a� b�

��Validator OK��endif

w�� w� �R ZZqa� � gw�hw�

�� a��c �R ZZq

�� c��r� � w� # cujsjkr� � w� # csjk

��r�� r��

gr�hr��! a�P

cjk

Figure �� reg pseudonym� Registration of Pjk at organisation Ok�

Issuing a Credential

Ok issues a credential to individual Ij by executing the blind signature protocolwith message M ! Pjk� This results in a signature �k of the form �z� c� r� on

Sjk ! Ptjkjk where tjk is chosen by Ij � During this process Ij needs Cjk ! P xk

jk

�see Figure �� This number is computed once Ij got her pseudonym withOk in get pseudonym�

The value Sjk together with the blind signature on it corresponds to whatChen calls an �intermediate pseudonym for individual Ij with organisation Ok��

Again the security of issuing depends on the properties of the blind signatureprotocol�

Showing a Credential

Suppose our individual Ij wishes to demonstrate to organisation Ol that hehas a credential� Sjk from organisation Ok� Ij is �rst identi�ed to Ol under

�



tjk �R ZZ�qSjk � P

tjkjk w �R ZZq

z � Ctjkjk a� � Gw

u� v �R ZZq b� � Pwjk

��a�� b��

a� a�GvHu

k

b�b�S

vjkC

ujk

tjkc� H�Sjk� z� a� b�

c� � c# u

� c��r� � w # c�xk

�� r��r � r� # v

ab�! �GSjk�

r�Hkz��c

Figure �� 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 pseudonymwith organisation Ok as a power of the pseudonym Pjl with organisation Ol� IfOk�s signature �k on Sjk is accepted� the showing of a credential is completed�see Figure ��

Now� why is it di�cult to show a credential issued under pseudonym Pjkof Ij under pseudonym Pil of another individual Ii� By the property of theidenti�cation in show credential it is guaranteed that the cheater can expressPil as g

uhv for some u and v� By the property of issue credential� Sjk canbe written as P t

jkGt� � Showing the credential under Pil requires knowledge of

w such that Sjk ! Pwil � In other words

Sjk ! �guhv�w �

Very brie�y this implies that Pjk must be of the form

Pjk ! �guhv�w�t

since t �! � This again implies Ii and Ij have the same universal identi�er�which contradicts the registration of universal pseudonyms�

Hardware Platform

Observe that� depending on the hardware platform of the individual� the uni�versal identi�er uj can be chosen by an observer or �in case of wallets with

��


Individual Ij Organisation Ol

�Sjk� �k�Sjk��

verify �k�Sjk��Sjk �! �a� GrH�c

b� Srjkz�c

c�! H�Sjk� z� a� b�

w �R ZZqa� � Pw

jl


�� c��r � w # csjktjksjl

� r��P rjl

�! a�S

cjk

Figure �� show credential� Show credential Sjk for pseudonym Pjl�

observers� mutually at random by purse and observer� However� all blindingfactors u� v� sjk and tjk can be chosen by the purse� This leads to variouspossibilities� including prior restraint with optimal privacy for the individual�CP��

�� Enhancement of Functionality

Three ways to incorporate potentially desirable requirements for a credentialmechanism that are presently not met by Chen�s scheme will be described�

�� Fall�back integrity for credentials�

�� E�cient encoding of information in credentials �such as their type��

�� k�Showable credentials�

Here� fall�back integrity means here that an individual who shows a credentialmore than once can be identi�ed �one�show property��

As for the second requirement� consider the case that one organisation issuesmultiple types of credentials� In Chen�s scheme as it stands� the organisationwould have to choose a di�erent key�pair for each type of credential� We willdescribe a way to make this much more e�cient�

k�Showable credentials have the property that the identity of the individ�ual becomes known to the organisations if the credential is shown more thank times� Like with k�spendable cheques� one can link the executions of theshowing protocol� if the same k�showable credential is used� This could also bedone by having an organisation issue k separate one�show credentials for the

��



tjk �R ZZ�qSjk � P

tjkjk w �R ZZq

z � Ctjkjk a� � Gw

u� v� w�� w� �R ZZq b� � Pwjk

a� � gw�hw�

��a�� b��

a� a�GvHu

k

b�b�S

vjkC

ujk

tjkc�H�Sjk� z� a� b� a

��c� � c# u

� c��r� � w # c�xk

�� r��r � r� # v

ab�! �GSjk�

r�Hkz��c

Figure �� Issue one�showable credential Sjk for pseudonym Pjk �

same pseudonym� This is less e�cient� however� with respect to time as well asstorage�

The extensions only a�ect 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 hemust �rst be identi�ed� Brie�y� fall�back integrity of a credential S underpseudonym P is obtained by forcing the individual to use the same message a��see Figure �� and �� whenever the individual is identi�ed before showingS� By the properties of the identi�cation method the secret key� �u� s�� suchthat P ! �guh�s can be obtained if the individual executes this identi�cationprotocol twice�

In order to enforce this �rst message� the individual is required to incorpo�rate it in the blind signature just as �� and �� were incorporated in cheques�more speci�cally� 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 asdescribed above� the credential will simply not be accepted� The protocol forissuing such credentials is shown in Figure �� note that the �rst �rst messagefor the identi�cation is now denoted by a�� Showing the credential is much asin Figure �� and is presented in Figure �� The only di�erence� is that theidenti�cation which was not included in Figure �� since it only had to bedone once in each session� must now be done in each showing� and it is thereforedescribed explicitly in Figure ��

��




jl

�a�� a

�� Sjk� �k�Sjk��verify �k�Sjk��

Sjk �! �a� GrH�c

b� Srjkz�c

c�! H�Sjk� z� a� b� a

��c� d �R ZZq

��c� d

��r � w # csjktjksjlr� � w� # dujsjlr� � w� # dsjl

��r� r�� r��

P rjl

�! a�S

cjk

gr�hr��! a�P d

jl

Figure �� Showing a one�showable credential Sjk for pseudonym Pjl�

Now� if the individual abuses the credential and shows it twice� the credentialclearing receiving copies of all shown credentials will detect this and be able tocompute the universal identi�er ui� The credential clearing is assumed to keepa database storing �d� r�� r�� for all received credentials� The protocol for thisis shown in Figure ��

E�cient Encoding of Type of Credential

At the expense of two extra generators h� and h� �which are system constants��there is an extension that allows for an organisation Ok to append a shortmessage to a blind signature� Let A � ZZq be the set of messages that can beencoded in credentials� In principle� A can contain up to q di�erent messages�but for privacy reasons A will often be relatively small �otherwise credentialscan be uniquely identi�ed by their encoded message�� The idea is now to encodethe type of credential as an element of A� So� if Ok issues �l 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 isnow replaced by M ! Pjkh�� where h� ! h�h

�� and � � A is the message that

Ok wishes to append� The individual Ij gets a blind signature on

Sjk � �Pjkh��sjk �

where sjk is chosen by Ij�

��


Organisation Ol Credential clearing

��Pjl� a

�� Sjk� �k�Sjk��

a�� c� d� r� r�� r��verify �k�Sjk��


b� Srjkz�c

c�! H�Sjk� z� a� b� a

��Sjk used before'If no� store Sjk and stopOtherwise� retrieve d�� r�� r

��

for the previous showing�If r� ! r�� stop�

Otherwise u� r��r��r��r��

Output u

Figure �� Clearing a credential�

The resulting protocol is depicted in Figure �� Note that Ij automati�cally veri�es whether the correct information is encoded in the credential�

Showing a credential to organisation Ol consists of giving Ok�s blind sig�nature on Sjk and demonstrating knowledge of a representation of Sjk withrespect to Pjl and h�� where h� ! h�h

�� see Figure ��

Intuitively� changing the encoded information requires the ability to writeSjk both as a power of Pjkh� and a power of Pjkh�� for a new value �� Verybrie�y� this requires the ability to compute discrete logarithms contradictingSDLA�

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 signa�ture k �rst messages for the identi�cation protocol�

Obviously� due to the fact that we are dealing with a blind signature in theprotocol for getting a credential� the issuing organisation has no control overthe data that goes in the hash function� This would mean that an individualcan make the credential k��showable for any k�� This is prevented by once moreinvoking the issuer�s ability to append a short message to the blind signature�see Section �� the message � that is appended will now encode the valueof k �if needed� � can also encode additional information��

The protocol for getting a credential is essentially a combination betweenthe protocols resulting from the previous two enhancements� the issuing organ�

��



h� � h�h�� h� � h�h

��

m� Pjkh� m� Pjkh�Cjk�� Cjkh��kh

��k

tjk �R ZZ�qSjk � mtjk w �R ZZq

z � Ctjkjk�� a� � Gw

u� v �R ZZq b� � mw

��a�� b��

a� a�GvHu

k

b�b�S

vjkC

ujk��

tjkc�H�Sjk� z� a� b�

c� � c# u

� c��r� � w # c�xk

�� r��r � r� # v

ab�! �GSjk�

r�Hkz��c

Figure �� Issue credential Sjk encoding � � 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 respectto g� h and h�� and incorporates them in the argument of the hash�function inthe blind signature protocol� The resulting protocol for issuing a credential isshown in Figure ��

The organisation that veri�es a credential now has to count the number ofmessages �rst that went into the argument of the hash�function� The remainingsteps are just combining the protocols resulting from previous two enhance�ments� See Figure �� for the details regarding showing such a credential�

Clearing in this scenario is just as in Section �� with the following ex�ception� The credential clearing must store the messages a� used in the proofs�Whenever� the same a� has been used in two di�erent proofs the individual canbe identi�ed�

�� Applications of Credentials

Credentials as described above have many possible applications� During CAFE

the following have been investigated� which� except for the last� all requiredemonstration of possession of a certain right� E�g�� the right to travel a certaindistance at a given time� the right to exchange or claim warranty for a purchaseditem� the right to obtain the gift in an incentive scheme� and so on�

��

CAFE Final Report Volume II �� Applications of Credentials


h� � h�h�� h� � h�h

��

�Sjk� �k�Sjk��

verify �k�Sjk��Sjk �! �a� GrH�c

b� Srjkz�c

c�! H�Sjk� z� a� b�

w�� w� �R ZZqa� � Pw�

jl hw��


�� c��r� w� # csjktjksjl

rh � w� # ctjk�

r� rh��P rjlh

rh�

�! a�S

cjk

Figure �� Show credential Sjk encoding � � A for pseudonym Pjl�

Public Transport Tickets are used to prove that the individual has obtainedthe 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� dis�count privileges� work by granting the individual bonus points for sometypes of transactions� These points can later be exchanged for� for exam�ple� a gift� the right to accept special o�ers or tari�s� and so on�

Physical Access Control works by verifying the right to access a certainspace �anonymous or non�anonymous� before granting it�

Conditional Pricing is the use of a di�erent� usually lower� tari� based ongroup 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 ticketwhen entering a service �e�g�� parking lot� toll road� and pays on exit�depending on the services used since entry �e�g�� parking time� distancetravelled�� This is a special case of conditional pricing� as the amount duedepends on the ticket and the context �place� time� of payment�

Medical Prescriptions are in some countries a proof of the right to obtaina certain medicine� It is issued by the physician� and accepted by apharmacist�

��



�� encode�k� �� encode�k�h� � h�h

�� h� � h�h

��

m� Pjkh� m� Pjkh�Cjk�� Cjkh��kh

��k

tjk �R ZZ�qSjk � mtjk w �R ZZq

z � Ctjkjk�� a� � Gw

u� v �R ZZq b� � mw

wi�� wi� �R ZZq for i ! �� kai � gwi�hwi� for i ! �� kci �H�ai� for i ! �� k

��a�� b��

a� a�GvHu

k

b�b�S

vjkC

ujk

tjkc�H�Sjk� z� a� b� �ci�i��k�

c� � c# u

� c��r� � w # c�xk

�� r��r � r� # v

ab�! �GSjk�

r�Hkz��c

Figure �� Issue k�showable credential Sjk for pseudonym Pjk �

Prepaid Mobile Communications� This is a special kind of the �phonetick� payment already implemented� It poses special requirements ontiming and communications complexity� These are the �rst� preliminaryresults of cooperation with the race project monet� which investigatesthe next generation of mobile communications systems�

Some of theses rights are once�usable� For example� a train ticket should beused for one trip only� Some are twice�usable� For example� a metro ticket isused at entrance and at exit� Others are �in�nitely�usable�� for example� accesscontrol�

Although more e�cient implementations are possible� our investigationsshow that the suggested credential scheme can be used to obtain these applica�tions� Thus� although payments have had very high priority in the developmentof the protocols� the resulting security kernel have many other possible appli�cations� This needs� however� further investigation�

�

CAFE Final Report Volume II �� Applications of Credentials


�� encode�k� �� encode�k�h� � h�h

�� h� � h�h

��


jl

�a�� an� �ci�i�n��Sjk� �k�Sjk��

cn �H�an�Received k values of ci'verify �k�Sjk��


b� Srjkz�c

c�! H�Sjk� z� a� b� �ci�i�

c� d �R ZZq

��c� d

��r � w # csjktjksjlr� � wn� # dujsjlr� � wn� # dsjl

�r� r�� r��

P rjl

�! a�S

cjk

gr�hr��! a�P d

jl

Figure �� Showing a k�showable credential Sjk for the n�th time�

�


�


Bibliography

�ACGS� W� Alexi� B� Chor� O� Goldreich� and C� P� Schnorr� RSA andRabin bits� Some parts are as hard as the whole� SIAM Journal on

Computing� ��%� � ��

�Ant � H� van Antwerpen� O��line electronic cash� Master�s thesis� Eind�hoven University of Technology� Department of Mathematics andComputing Science� Eindhoven� The Netherlands� � �

�BB�� B� den Boer and A� Bosselaers� An attack on the last two roundsof MD�� In Advances in Cryptology�CRYPTO �� volume �� ofLecture Notes in Computer Science� pages ��%� �� Berlin� ��Springer�Verlag�

�BB�� B� den Boer and A� Bosselaers� Collisions for the compressionfunction of MD�� In Advances in Cryptology�EUROCRYPT ��volume �� of Lecture Notes in Computer Science� pages ��%� ��Berlin� �� Springer�Verlag�

�BBB�� 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 Sys�

tems� Final Report of RACE Integrity Primitives Evaluation �RIPE�

RACE �� volume � � of Lecture Notes in Computer Science�Springer�Verlag� Berlin� ��

�BC � J� Bos and D� Chaum� SmartCash� A practical electronic paymentsystem� Report CS�R �� Centrum voor Wiskunde en Informatica�Amsterdam� August � �

�BM�� E� F� Brickell and K� S� McCurley� An interactive identi�cationscheme based on discrete logarithms and factoring� Journal of Cryp�tology� ��%��

�Boe � B� den Boer� Di�e�Hellman is as Strong as Discrete Log for CertainPrimes� In Advances in Cryptology�CRYPTO �� volume � � ofLecture Notes in Computer Science� pages �� %�� Berlin� � �Springer�Verlag�

�Boe�� B� den Boer� Personal communication� March ��

��

Bibliography CAFE Final Report Volume II

�BP� H� B*urk and A� P�tzmann� Digital payment systems enabling se�curity and unobservability� Computers � Security� ��%��

�Bra�� S� Brands� An e�cient o��line electronic cash system based on therepresentation problem� Report CS�R�� Centrum voor Wiskundeen Informatica� Amsterdam� March ��

�Bra�a� S� Brands� Untraceable o��line cash in wallet with observers� InAdvances in Cryptology�CRYPTO �� volume �� of Lecture Notesin Computer Science� pages � �%�� Berlin� �� Springer�Verlag�

�Bra�b� S� Brands� O��line cash transfer by smart cards� In V� Cordon�nier and J��J� Quisquater� editors� Proceedings First Smart Card Re�search and Advanced Application Conference� pages � �%�� Lille�F�� Also as report CS�R�� Centrum voor Wiskunde enInformatica� Amsterdam�

�Bra�a� S� Brands� Restrictive blinding of secret�key certi�cates� In Ad�

vances in Cryptology�EUROCRYPT �� volume �� of LectureNotes in Computer Science� pages ��%�� Berlin� �� Springer�Verlag� Final version as report CS�R� � Centrum voor Wiskundeen Informatica� Amsterdam�

�Bra�b� S� Brands� A note on parallel executions of restrictive blind issuingprotocols for secret�key certi�cates� Report CS�R�� Centrumvoor Wiskunde en Informatica� Amsterdam� March ��

�Bra�c� S� Brands� Restrictive blind issuing of secret�key certi�cates in par�allel mode� Report CS�R�� Centrum voor Wiskunde en Infor�matica� Amsterdam� March ��

�Bra�d� S� Brands� More on restrictive blind issuing of secret�key certi�catesin parallel mode� Report CS�R�� Centrum voor Wiskunde enInformatica� Amsterdam� April ��

�CBH� � D� Chaum� B� den Boer� E� van Heyst� S� Mj�lsnes� and A� Steen�beek� E�cient o�ine electronic checks� In Advances in Cryptology�

EUROCRYPT �� volume �� of Lecture Notes in Computer Sci�

ence� pages ��%� �� Berlin� � � Springer�Verlag�

�CC�a� The CAFE Consortium� CAFE �nal report volume I� Trial operationand surveys� Report CS� Centrum voor Wiskunde en Informatica�Amsterdam� ��

�CC�b� The CAFE Consortium� CAFE �nal report volume IIB� Techni�cal speci�cations� devices� Report CS� Centrum voor Wiskunde enInformatica� Amsterdam� ��

�CE�� D� Chaum and J��H� Evertse� A secure and privacy�protecting pro�tocol for transmitting personal information between organizations�

��

CAFE Final Report Volume II Bibliography

In Advances in Cryptology�CRYPTO �� volume �� of LectureNotes in Computer Science� pages ��%�� Berlin� �� Springer�Verlag�

�CFN � D� Chaum� A� Fiat� and M� Naor� Untraceable electronic cash� InAdvances in Cryptology�CRYPTO �� volume � � of Lecture Notesin Computer Science� pages ��%�� Berlin� � � Springer�Verlag�

�Cha�� D� Chaum� Blind signatures for untraceable payments� In Ad�vances in Cryptology�CRYPTO �� pages �%� �� New York�� Plenum Press�

�Cha�� D� Chaum� Security without identi�cation� Transaction systemsto make big brother obsolete� Communications of the ACM�� %� ��

�Cha� D� Chaum� Privacy protected payments� Unconditional payerand or payee untraceability� In SMART CARD �� The Futureof IC Cards� Proceedings of the IFIP WG �� International Con�

ference� pages �%�� Amsterdam� �� North�Holland�

�Cha � D� Chaum� Showing credentials without identi�cation� Transfer�ring signatures between unconditionally unlinkable pseudonyms� InAdvances in Cryptology�AUSCRYPT �� volume �� of LectureNotes in Computer Science� pages ��%�� Berlin� � � Springer�Verlag�

�Cha�� D� Chaum� Achieving electronic privacy� Scienti�c American��%� �� August ��

�Che�� L� Chen� Witness Hiding Proofs and Applications� PhD thesis�Aarhus University� Computer Science Department� Aarhus� Den�mark� August ��

�CP�a� D� Chaum and T� P� Pedersen� Transferred cash grows in size� InAdvances in Cryptology�EUROCRYPT �� volume �� of LectureNotes in Computer Science� pages � %� �� Berlin� �� Springer�Verlag�

�CP�b� D� Chaum and T� P� Pedersen� Wallet databases with observers� InAdvances in Cryptology�CRYPTO �� volume �� of Lecture Notesin Computer Science� pages %� �� Berlin� �� Springer�Verlag�

�CP�� R� Cramer and T� P� Pedersen� Improved privacy in wallets withobservers� In Advances in Cryptology�EUROCRYPT �� volume�� of Lecture Notes in Computer Science� pages ��%�� Berlin�� Springer�Verlag�

�Dam � I� B� Damg)ard� A design principle for hash functions� In Advances

in Cryptology�CRYPTO �� volume �� of Lecture Notes in Com�

puter Science� pages ��%�� Berlin� � � Springer�Verlag�

��


�DBP�� H� Dobbertin� A� Bosselaers� and B� Preneel� RIPEMD�� A strengthened version of RIPEMD� In Fast Software Encryp�

tion� volume � � of Lecture Notes in Computer Science� pages��%�� Berlin� �� Springer�Verlag� Final version available atftp� ftp�esat�kuleuven�ac�be pub COSIC bosselae ripemd �

�Det�� J*urgen Dethlo�� Jahre Chipkarten�Technik � R*uckblick undAusblick� In B� Struif� editor� Tagungsband zum � GMD�SmartCardWorkshop� �� Februar �� Darmstadt� �� GMD�

�DGB� Y� Desmedt� C� Goutier� and S� Bengio� Special uses and abusesof the �at�shamir passport protocol� In Advances in Cryptology�

CRYPTO �� volume �� of Lecture Notes in Computer Science�pages ��%�� Berlin� �� Springer�Verlag�

�DH�� W� Di�e and M� E� Hellman� New directions in cryptography� IEEETransactions on Information Theory� ��%��

�Dob�� H� Dobbertin� RIPEMD with two�round compress function is notcollision�free� Journal of Cryptology� � ��%��

�DSS�� Digital Signature Standard� Federal Information Processing Stan�dards Publication �� US Department of Commerce National In�stitute for Standards and Technology �NIST�� May ��

�Fei�� H� Feistel� Cryptography and computer privacy� Scienti�c Ameri�

can� ��%�� May ��

�Fer�a� N� T� Ferguson� Single term o��line coins� In Advances in

Cryptology�EUROCRYPT �� volume �� of Lecture Notes in

Computer Science� pages ��%�� Berlin� �� Springer�Verlag�

�Fer�b� N� T� Ferguson� Extensions of single�term coins� In Advances in

Cryptology�CRYPTO �� volume �� of Lecture Notes in Com�puter Science� pages ��%� �� Berlin� �� Springer�Verlag�

�FS�� A� Fiat and A� Shamir� How to prove yourself� Practical solutions toidenti�cation and signature problems� In Advances in Cryptology�

CRYPTO �� volume �� of Lecture Notes in Computer Science�pages ��%�� New York� �� Springer�Verlag�

�FY�� M� Franklin and M� Yung� Towards provably secure e�cient elec�tronic cash� Technical report CUCS� �� Columbia University�Dept� of Computer Science� April ��

�GMR� S� Goldwasser� S� Micali� and R� Rivest� A digital signature schemesecure against adaptive chosen�message attacks� SIAM Journal on

Computing� ��%� � ��

�GMR� S� Goldwasser� S� Micali� and C� Racko�� The knowledge complexityof interactive proof systems� SIAM Journal on Computing� ��%� � ��

��


�GUQ�� L� C� Guillou� M� Ugon� and J��J� Quisquater� The Smart Card�A standardized security device dedicated to public cryptology� InG� J� Simmons� editor� Contemporary Cryptology� The Science of

Information Integrity� pages ��%�� New York� �� IEEE Press�

�Hey�� E� van Heyst� Special Signature Schemes� PhD thesis� EindhovenUniversity of Technology� Department of Mathematics and Comput�ing Science� Eindhoven� The Netherlands� July ��

�HP�� E� van Heyst and T� P� Pedersen� How to make e�cient fail�stopsignatures� In Advances in Cryptology�EUROCRYPT �� volume�� of Lecture Notes in Computer Science� pages ��%�� Springer�Verlag� ��

�ISO� The Directory % Authentication Framework� C�C�I�T�T� Recommen�dation X�� ISO IEC Standard �� International Stan�dards Organization� Geneva� ��

�ISO�� Information technology % Security techniques % Key management�Part �� Mechanisms Using Asymmetric Techniques� ISO IEC �� International Standards Organization� Geneva� �� This stan�dard is still under study�

�ISO�� Information technology % Security techniques % Key management�Part �� Framework� ISO IEC �� rst edition� InternationalStandards Organization� Geneva� ��

�KD�� J�B� Kam and G�I� Davida� Structured design of substitution�permutation encryption networks� IEEE Transactions on Comput�

ers� C%�� %��

�Knu�� D� E� Knuth� The Art of Computer Programming �Vol� �� Seminu�

merical Algorithms�� Addison Wesley� Reading �MA�� nd edition��

�Kob�� N� Koblitz� A Course in Number Theory and Cryptography� volume�� of Graduate Texts in Mathematics� Springer�Verlag� New�York��

�LO�� B� A� LaMachhia and A� M� Odlyzko� Computation of discrete loga�rithms in prime �elds� Design� Codes and Cryptography� ��%��

�Mau�� U� Maurer� Towards the Equivalence of Breaking the Di�e�HellmanProtocol and Computing Discrete Logarithms� In Advances in

Cryptology�CRYPTO �� volume � of Lecture Notes in Com�

puter Science� pages ��%�� Springer�Verlag� ��

�McC � K� McCurley� The discrete logarithm problem� In C� Pomerance�editor� Cryptology and Computational Number Theory� volume ��of Proceedings of Symposia in Applied Mathematics� pages �%��Providence� � � American Mathematical Society�

��


�Mer � R� C� Merkle� Unpublished result� � � See �BB��

�MS�� S� Micali and C� Schnorr� E�cient perfect polynomial random num�ber generators� Journal of Cryptology� ��%��

�Oka�� T� Okamoto� Provably secure and practical identi�cation schemesand corresponding signature schemes� In Advances in Cryptology�

CRYPTO �� volume �� of Lecture Notes in Computer Science�pages ��%�� Berlin� �� Springer�Verlag�

�OO � T� Okamoto and K� Ohta� Disposable zero�knowledege authentica�tions and their applications to untraceable electronic cash� In Ad�

vances in Cryptology�CRYPTO �� volume �� of Lecture Notes

in Computer Science� pages ��%�� Heidelberg� � � Springer�Verlag�

�OO�� T� Okamoto and K� Ohta� Universal electronic cash� In Advances

in Cryptology�CRYPTO �� volume �� of Lecture Notes in Com�

puter Science� pages ��%�� Berlin� �� Springer�Verlag�

�Pai�� J� C� Pailles� New protocols for electronic money� In Advances

in Cryptology�AUSCRYPT �� volume �� of Lecture Notes in

Computer Science� pages ��%�� Berlin� �� Springer�Verlag�

�Ped�� T� P� Pedersen� Electronic payments of small amounts� TechnicalReport DAIMI PB�� Aarhus University� Computer Science De�partment� Aarhus� Denmark� August ��

�Ped�� T� P� Pedersen� Electronic payments of small amounts� In SecurityProtocols� volume �� of Lecture Notes in Computer Science� pages�%�� Berlin� �� Springer�Verlag�

�PWP � B� P�tzmann� M� Waidner� and A� P�tzmann� Rechtssicherheittrotz Anonymit*at in o�enen digitalen Systemen� Datenschutz und

Datensicherung DuD� ��%��%�� %��

�Rab�� M� Rabin� Digital signatures and public key functions as intractableas factoring� Technical Memo TM�� Laboratory of ComputerScience� Massachusetss Institute of Technology� ��

�Riv�a� R� L� Rivest� The MD� message�digest algorithm� Request for Com�ments �RFC� �� April ��

�Riv�b� R� L� Rivest� The MD� message�digest algorithm� Request for Com�ments �RFC� �� April ��

�Roo�� Peter de Rooij� The discrete logarithm problem modulo a primenumber� RIPE document Eval�P�� PTT Research� July ��

�RSA�� R� L� Rivest� A� Shamir� and L� Adleman� A method for obtainingdigital signatures and public�key cryptosystems� Communications

of the ACM� �� %�� Reprinted in �� in ��%�

��


�Sch�� C� P� Schnorr� E�cient signature generation by smart cards� Journalof Cryptology� ��%��

�Sch�� B� Schoenmakers� An e�cient electronic payment system withstand�ing parallel attacks� Report CS�R�� Centrum voor Wiskunde enInformatica� Amsterdam� March ��

�SHS�� Secure Hash Standard� Federal Information Processing StandardsPublication � �� US Department of Commerce National Institutefor Standards and Technology �NIST�� April ��

�Sto� N� Stol� Privacy protected payments� A possible structure for areal implementation and some resource considerations� Technicalreport STF�� A �� SINTEF DELAB� N�� Trondheim� Febru�ary �� Also published in Securicom��

�WT�� A�F� Webster and S�E� Tavares� On the design of S�boxes� In Ad�

vances in Cryptology�CRYPTO �� volume �� of Lecture Notes

in Computer Science� pages ��%�� Berlin� �� Springer�Verlag�

��

Modelling, Analysis and Simulation - TU/eberry/papers/MAS-E0303.pdf · Centrum voor Wiskunde en...

Documents

Transcript of Modelling, Analysis and Simulation - TU/eberry/papers/MAS-E0303.pdf · Centrum voor Wiskunde en...