Security Protocols: International Workshop Cambridge, United Kingdom April 10-12, 1996 Proceedings (Lecture Notes in Computer Science)

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis and J. van Leeuwen Advisory Board: W. Brauer

D. Gries

J. Stoer

1189

Mark Lomas (Ed.)

Security Protocols International Workshop Cambridge, United Kingdom April 10-12, 1996 Proceedings

Springer

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editor Mark Lomas University of Cambridge, Computer Laboratory New Museums Site, Pembroke Street Cambridge, CB2 3QG, United Kingdom E-mail: Mark.Lomas @cl.cam.ac.uk Cataloging-in-Publication data applied for

Die Deutsche B i b l i o t h e k - C I P - E i n h e i t s a u f n a h m e

Security protocols : international workshop, Cambridge, U n i t e d Kingdom, April 1996 ; proceedings / Mark Lomas (ed.). - Berlin ; Heidelberg ; N e w Y o r k ; Barcelona ; Budapest ; H o n g Kong ; L o n d o n ; Milan ; Paris ; Santa Clara ; Singapore ; Tokyo : Springer, 1997 (Lecture notes in computer science ; 1189) ISBN 3-540-62494-5 NE: Lomas, Mark [Hrsg.]; GT

CR Subject Classification (1991): E.3-4,F.2.1-2, C.2, K.6.5, J.1 1991 Mathematics Subject Classifications: 94A60, 11T71, llYXX, 68P20, 68Q20, 68Q25 ISSN 0302-9743 ISBN 3-540-62494-5 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer -Verlag. Violations are liable for prosecution under the German Copyright Law. 9 Springer-Verlag Berlin Heidelberg 1997 Printed in Germany Typesetting: Camera-ready by author SPIN 10549917 06/3142 - 5 4 3 2 1 0

Printed on acid-free paper

Preface

In 1978 Roger Needham and Michael Schroeder wrote a seminal paper on authentication in distributed systems. Unfortunately, when the paper was published nobody noticed that the protocols that they suggested could be attacked. This gave the authors the opportunity to revise their protocols and publish a subsequent paper; again the protocols were subject to attack. Perhaps it is not so easy to design secure cryptographic protocols as some people have assumed. Three years ago I chaired our first workshop on cryptographic protocols. Our aim was to bring together researchers in the field to discuss both their designs and their design failures. It is often instructive to learn from failure. Our first three workshops were informal affairs, where the intention was to facilitate useful and interesting discussion. Many people complained, quite rightly, that we did not make proceedings available to those who were unable to attend. Some twenty-one years ago Whitfield Diffie and Martin Hellman introduced the idea of public-key cryptography. This was a revelation in that it facilitated all manner of applications, and many new types of protocol for us to break. To celebrate this coming of age we especially encouraged papers on public-key based protocols; also, Whitfield DiNe kindly agreed to give a keynote address. We also note that this year we accepted no less than six papers related to electronic commerce. We would like to think that this change of emphasis shows that cryptographic protocols are at, last finding commercial application. I'd like to thank Bruno Crispo for converting the submissions into the form that we requested fi'om the authors. Mark Lomas Cambridge, October 1996

Contents On Cryptographic Techniques for On-line Bankcard Payment Transactions Using Open Networks Wenbo M a o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

A Certification Scheme for Elect.ronic Commerce B r u n o Crispo, M a r k L o m a s

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

19

Practical Escrow Cash System Eiichiro Fujisaki, Tatsuaki O k a m o t o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

NetCard - A Practical Electronic-Cash System Ross Anderson, Clm'ralampos Manifavas and Chris ,_qutherland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

Electronic Payments of Small Amounts Torben P. Pedersen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

PayWord and MicroMint: Two Simple Micropayment Schemes Ronald L. Rivest, Adi S h a m i r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

Transactions Using Bets David Wheeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

Protocol Failures for RSA-Like Functions Using Lucas Sequences and Elliptic Curves Marc Joy< Jean>Jacques Quisquoter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

Efficient and Provable Secure Amplifications R o n a l d Cramer, Ivan D a m g d l d and Torben P. Pedersen

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

101

A Comparison of RSA and the Naccache-Stern Public-Key Cryptosystem T h o m a s W. Cusiek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

111

IEEE P1363: A Standard for IqSA, Diffie-Helhnan and Elliptic-Curve Cryptography [Abstract] B u r t o n S. Kaliski Jr.

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

117

Efficient and Secure Conference-I,2ey Distribution Mike B u r m e s t e r ,

Yvo G, D e s m e d t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119

Directed Signatures and Application to Threshold Cryptosystems Chae Hoon L.im, Pil Yoong Lee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

131

VIII Key Escrow in Mutually Mistrusting Domains Liq'un Chen, Dieter Gollm.ann a~d Ch.ris J. Mitchell . . . . . . . . . . . . . . . . . . .

139

Automatic Event-Stream Notarization Using Digital Signatures Bruce Schneier, John [(elseg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

155

Why Isn't Trust Transitive? Bruce Christianson, William 5'. Harbison . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Securing Residential Asynchronous Tra.nsfer Mode Networks Shaw-Che~g Chuang, David Greaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

171

177

Visual Cryptogra.phy II: Improving the Contrast Via. the Cover Ba.se Moni Naori, Adi Shamir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Author Index ..........................................................

197 203

On Cryptographic Techniques for On-line Bankcard Payment Transactions Using Open Networks Wenbo Mao Hewlett-Packard Laboratories Filton Road, Stoke Gifford Bristol BS12 6QZ United Kingdom wm~hplb, hpl. hp. corn

A b s t r a c t . Recently, two major bankcard payment instrument operators VISA and MasterCard published specifications for securing bankcard payment transactions on open networks for open scrutiny. (VISA: Secure Transaction Technology, STT; MasterCard: Secure Electronic Payment Protocol, SEPP.) Based on their success in operating the existing on-line payment systems, both proposals use advanced cryptographic technologies to supply some security services that are well-understood to be inadequate in open networks, and otherwise specify systems similar to today's private-network versions. In this paper we reason that when an open network is used for underlying electronic commerce some subtle vulnerabilities will emerge and the two specifications are seen not in anticipation of them. A number of weaknesses are found as a result of missing and misuse of security services. Missing and misused services include: authentication, non-repudiation, integrity, and timeliness. We identify problems and devise solutions while trying to keep the current successful working style of financial institutions being respected.

1

Introduction

Many of t o d a y ' s on-line bankcard payments are transacted using private communication networks linking merchants and banks, and some of these transactions are initiated by mail orders or telephone orders (MOTO) from buyers to merchants. It is foreseeable that moving the existing on-line bankcard payment transactions onto the Internet can reduce the transaction cost because of the economy of the Internet communications, and also add difficulty for defrauding due to the readiness to use advanced cryptographic algorithms. Quite a number of cryptographic protocols for securing on-line bankcard p a y m e n t transactions on the Internet have been proposed. Published proposals include CyberCash [1], NetBitl [10], NetCheque [8], N e t e h e x [4], Open Market [5], iKP [6], Millicent [7], S T T [3], and SEPP [2]. Each of these proposals has its own virtues and all contribute to a better understanding of the area of study. A m o n g these proposals, S T T and S E P P are two specifications published by two of t o d a y ' s largest operators of bankcard payment instruments: VISA and

MasterCard, respectively. Apparent advantages can be expected from these two proposals due to their natural use of well-established and specialised financial institutions as system operators: transaction costs can be minimised because of the minimised need of employing extra operators; also they can lead to a ready use in the worldwide area as these two reputable payment-system suppliers have already established a worldwide infrastructure of buyers, merchants and banks. The two proposals specify open network versions of on-line bankcard payment systems and use advanced cryptographic technologies to supply some security services that are well understood to be inadequate in open networks; the specified systems are otherwise similar to today's MOTO versions running on relatively closed private networks. In this paper we report our study of these two specifications. The study shows that, moving things onto open networks with the use of advanced cryptographic algorithms does not necessarily lead to successful open-network-version systems even if the original systems run successfully on private networks. As a result of using conventional ways to enhance network security, the two specifications are seen to have not been in anticipation of some subtle vulnerabilities in open networks. We will reveal a number of weaknesses in the two proposals and discuss their causes. These include: a easy room for malicious users to defraud due to lack of a non-repudiation service, a poor system fault-tolerance prone to disputes due to missing of an integrity service, and a low system performance in on-line authorising payment transactions due to misuse of some cryptographic mechanisms. We have noticed that both S T T and SEPP clearly indicates a working style of the financial institution who on-line authorises payment transaction requests (called the acquiring bank, or the acquirer), and believe that this working style forms a key element for today's on-line bankcard payment instruments to be successful. The working style can be referred to as: the acquirer only processes at most o n e on-line request for each payment transaction. It is our understanding that if more than one on-line requests can be accepted for each payment transaction, then the acquirer can employ a simple challenge-response mechanism and then most of the absent services can rea.dily be added (will become clear with our technical presentation). Unfortunately, it, is unacceptable and unrealistic to demand the financial institutions change their well-developed and successful working style. Fortunately, the problems to be identified in S T T and SEPP can readily be fixed. VV'ewill propose a unconventional use of challenge-response mechanism, in which the challenger, i.e., the principal who creates and sends a challenge, is not an on-line verifier of an expected response; the on-line verification job will be carried out by a different principal. Using this idea to revise S T T and SEPP, it is to let the acquirer create a challenge to the buyer but let the seller verify the correctness of an on-line response. The seller, though can do the verification job, cannot himself respond to the challenge. Thus, a correct response can be used as a payment commitment while there is no need of making more-than-one on-line visits to the acquirer for each payment transaction. Our method models today's face-to-face payment instruments using paper slips: if the buyer does not sign an

buyer

I

seller

acquirer

I

Initiate (only in SEPP) Invoice ,I

Order (to seller) PI (to acquirer) ~'

Auth-Request

P.O.Inquiry (optional in SEPP) D-

P.O.Response (optional in SEPP) q

Auth-Response Confirmation

4

Fig. 1. On-line bankcard payment schemes used in STT and SEPP

invoice slip, the transacted payment will eventually be reversed (of course, the purchase is unsuccessful too). We thus believe that there will be little conflict between our solutions and the successful working style of the existing financial infrastructure. An important achievement due to the novel use of challenge-response mechanism can be referred to as that the acquirer is now able to safely delay major time-consuming computations to an off-line time. Message replay detection and public-key certificate validating are two of such time-consuming processes: the former requires real-time maintenance of a big database and the latter requires communications to other parties (e.g., certificate revocation lists, CRL's). Being able to off-line process these jobs, as to be featured in our solutions, will significantly increase the payment system's on-line performance. The remainder of this paper is organised as follows. Section 2 is a close study of problems in STT and SEPP. In Section 3 presents our revision that tackles the identified problems. Section 4 analyses why and how the problems are solved. Finally, Section 5 forms our conclusion. Throughout the rest of this paper we shall be describing payment mechanisrns in which "buyers", "sellers" and "banks" are principals. When banks' rote in a transaction is specific, they will be denoted by that role, for example, "(bankcard) issuer" or "(transaction) aequirer". In our revision, the aequirer will often be referred to as "(payment) gateway" as in most cases when we mention this principal we mean its computer systems that face the open networks, receive, process and send protocol messages for the acquirer. Also for convenience, we will frequently use "she", "he" and "it" to refer to a buyer, a seller and a bank, respectively, where she and he are also called "end-users".

2

Problem

Analysis

Figure 1 illustrates on-line bankcard payment schemes used in STT and SEPP. For presentation simplicity, we have unified some message names which are different in STT and SEPP but have the same semantics. Those worth mentioning are "Invoice" and "Confirmation": In STT, "Invoice" is called "Merchant Credential" and "Confirmation" is called "Order Acknowledgement". In both protocols, the buyer will first get "Invoice" from the sellen In SEPP, this message is personalised because the seller sends it as a response to "Initiate". In STT, this message (i.e., "Merchant Credential") is non-personalised and is assumed to come to the buyer due to her action of searching (on-line, off-line) the seller's sales catalog. Both protocols use public-key cryptography, but SEPP also allows early stage versions in which the buyer, and even the seller, can use conventional cryptography based on personal identification numbers (PINs). We focus on analysing the version in which all parties are equipped with public-key/private-key pairs, as most of the revealed problems apply to other versions, too. Our analysis will discuss the use of cryptographic mechanisms in these two protocols, though coding formulae are not concerned in the analysis. In Section 3 when we devise the proposed revision to these two protocols, we will present cryptographie formulae and explain the essential differences between the revision and these two previous specifications in using cryptography. The message "Invoice" will contain the seller's and the acquirer's public-key information (keys and certificates). When the buyer decides to start a purchase, she sends a combined message "Order" and "PI" t.o the seller together with her public-key information. The message part "Order" is intended for the seller while the part :~PI" ("Payment Instruction") for the acquirer. The bankcard number is treated as a piece of confidential data and will be encrypted in "PI" under the acquirer's public key. The seller will make a request for authorising the payment by sending the message "Auth-l%equest" to the acquirer. After the payment is authorised by the acquirer, the seller will be notified by the message "Auth-Response". He will then send the final protocol message "Confirmation" to the buyer and deliver the goods/services purchased. The Inessage "Confirmation" includes the seller's signature and thus the final message is intended to also function as a receipt. In SEPP, during the time of on-line authorisation (period between the buyer sending "Order" and receiving "Confirmation"), the buyer can make, as many as she wish, inquiries on the status of her purchase order ("P.O.Inquiry") and for each enquiry message, the seller will reply with a response ("P.O.Response"). In these payment schemes, far before a protocol run terminates, the seller obtains all of the needed materiM to effect a real transfer of money (crediting his account and debiting the buyer's). This is true even regardless of whether or not a protocol run will terminate successfully. We believe that the following problems will emerge when such a scheme is used over the Internet (or any open network). We identify problems and sketch solutions.

2.1

Missing security services: non-repudiation and integrity

In general, communications on open networks (e.g., the Internet) are in good quality. However, there is no guarantee that a given node is always accessible or reachable. Communication delay in the Internet is a frequent phenomenon and is particularly noticeable during the time of high network traffic. As a result, messages sent to the Internet may not reach the recipient in time. If a message corrupted or delayed en route is one after (including) "Auth-Response", then it may become a nuisance for the buyer: either she has to wait patiently, or has to re-dial to the seller for inquiry ("P.O.Inquiry", an option in SEPP). In the case when the communication link between the buyer and the seller corrupts, re-dialing usually makes little sense. So it is more likely that the buyer has to buy the same item again from a different shop. This is an obviously undesirable situation because the buyer has actually paid the seller and a charge-back (refund) transaction must be made in a later time for compensation. It is understood that charge-back transactions form one of the major elements to rise the system's per-transaction fee. Perhaps, the real problem is not the imperfection of the Internet in its own right, it may be that the imperfection, however slight, can be amplified by a malicious user, either the buyer or the merchant, to achieve undeserved gain. For instance, the seller can promote sales figure by advertising goods even when the goods are temporarily out of stock. By delaying sending out "Confirmation's" for a period of time needed for replenishing the warehouse while falsely claiming communication failures in the link from the acquirer to him (only claiming so when asked), many patient buyers can be deceived. There are various other electronic commerce applications particularly suitable for using the Internet due to their nature of non-physical delivery of servicesl Information-document selling, instant-insurance covering, gambling-ticket selling or airline-ticket reservation are a few examples. (It is our belief that these services will be among the first activities in a full-fledged Internet electronic commerce.) These circumstances are more prone to disputes with S T T and SEPP like payment schemes. For instance, by falsely claiming communication failure in the link from the seller to her, the buyer can reject an airline ticket booking without need of paying a cancellation charge only because later she finds a better offer. On the other hand, the ticket seller can demand charging at least a cancellation fee by falsely claiming having sent the message "Confirmation" whereas the true situation is that there wasn't ticket available at all during the time when he received the message "Order". (One can imagine other situations such as insurance or lottery-ticket selling). Here we see that the two specifications have not supplied the service of nonrepudiation on proof of message receipt. To be malicious in these ways does not require any sophisticated technique. We should note that disputes are not necessarily the result of fraudulent actions; they can be resulted from genuine communication failures or delays. The communication failures or delays rise the volume of charge-back transactions, while the malicious users add bigger loss to the system due to their demands on compensations or additional work for

resolving disputes. Together, these rise the cost of the whole payment system. Since a consequence of malicious actions or of network failures is expensive, we can further regard that S T T and SEPP do not serve a proper integrity protection. An integrity protection on a secure communication system (e.g., a security protocol) running over an open network is a service to detect any toss of, alteration on, or damage to the sensitive data. passing along the network. An integrity service usually includes a. faltback measure which will be used to fix an integrity failure. A proper integrity service should protect the system with a trivial cost (therefore the fallback measure must be cheap), whereas should cost an adversary dearly should (s)he achieve a gain from damaging the integrity. S T T and SEPP do not provide a proper integrity service because they allow trivially easy ways (no cost at all) for the adversaries to gain various advantages by damaging the integrity, whereas they cost the system dearly in running fallback measures after the system discovers an integrity failure. A simple solution is to delay sending the message that constitutes a payment commitment. If a payment is received in the final step of on-line communication, then no one can deny having received any other on-line messages (including the final one if the buyer really wants to get paid). If it is a genuine communication failure or for any other reason that has caused a message not reaching the recipient, then no one is hurt because no one has been paid and no goods/services will be delivered. Such a delayed sending of payment does not mean a need of more-than-one on-line visits to the acquirer for each payment transaction. The idea is to let the acquirer create a challenge to the buyer and let the seller have a method to verify the correctness of an on-line response. A correct response constitutes a payment commitment and needn't be sent to the acquirer in any on-line way.

2.2

Low performance: a consequence of misusing crypto-mechanisms

When we speak of the performance of a communication system, we focus on studying the performance of a critical principal whose bandwidth limits the bandwidth of the whole system. In on-line bankcard payment systems, the a.cquirer is such a principal. In today's bankcard payment systems. The acquirer performs some basic security checking routines. For instance, it validates the message genuineness. The the relatively closed communication links between the acquirer and the seller mean that the validation is mainly in terms of detecting and correcting transmission errors. These routines are simple and in general not time-consuming. However when things are moved onto the Internet, in addition t.o the expected increasement in the volume of on-line payment transactions, more thorough security checking routines become necessary. A major time-consuming element in S T T and SEPP is, in our belief, a result of misuse of cryptographic algorithms chosen for the acquirer to process messages during the on-line transaction authorisation time. The two specifications have unfortunately overlooked an important fact: the acquirer and the seller are

two parties who maintain a long-term business relationship. Instead of employing this useful relationship, they have unreasonably designated the acquirer to process frequent session messages received from a long-term business partner using public-key cryptography. In fact, a symmet,ric technique based on shared eryptographic keys will suffice to provide the same security services with a much better performance. For instance, authentication by checking signature in the RSA algorithm is about 100 times slower than that using shared keys, and deerypting an RSA message can be somewhat 1,000 to 10,000 times slower than that using a symmetric technique [9]. Perhaps, their intention is to produce a strong proof of message origin. We should point out the conceptional difference between authentication and non-repudiation as security services. The former is to convince oneself the genuineness of an object whereas the latter is to prove it to a third party. It is our understanding that during the time of on-line authorising a payment transaction, the service really needed by the acquirer is authentication rather than non-repudiation. A non-repudiatable proof should be available only when a dispute occurs. Undoubtedly, during the on-line run time of these two protocols, such a proof is by no means needed because there is no any dispute regarding the transaction occurring yet. A worse problem as a result of dismissing the acquirer-seller relationship is that, the acquirer has to also on-line verify the buyer's signature which includes validating her key certificate. Frequently, the latter job requires additional con> munications to certificate revocation lists (CRL's). Compared to local computations even in slow public-key cryptography, we believe that communications to remote nodes will be much more time-consuming. It is very unwise to centralise these communications to the acquirer. A further time-consuming routine with the acquirer is to on-line check the uniqueness of the message ~'PI" (or a number mapped from "PI") in order to prevent multiple charges to the buyer (e.g., the seller has an incentive to replay this message). This is to on-line, ~'eal-timely maintain a database that records all valid "PI's" (or related numbers) for a period of time. The database must be sorted in a real-time way so that each incoming ~'PI" can readily be checked against replay. The capacity of the real-time maintaining the database crucially effects the on-line performance of the whole payment system. The complexity of the on-line database maintenance can be high considering that the volume of "PI's" is proportional to that of the goods/services sold system-wide. Also, the on-line real-time maintenance of the database makes the safe backup copies of the database expensive. The heavy on-line workload and the exposed position of the acquirer invite a so-called mass-dialing attack. Such an attack can easily be mounted over an open computer network. The attack is to send a large quantity of data. to a chosen node with the goal of jamming the communication traffic with the node. It is particularly rewarding to target a service node (that's why the attack is also called a denial-of-service attack). In the payment schemes illustrated in Figure 1, the message "PI" is encrypted under the acquirer!s public key and is therefore a piece of gibberish to the seller. An attacker can send a large volume of recorded

buyer

]

[ seller

acquirer

Sales-Info q

Purchase (Order, PI)

Auth-Request Auth-Response

Confirmation

Payment ,

Fig. 2. On-line message flows in the proposed revision to STT and SEPP "PI's" to the seller together with valid "Orders". Upon receipt of the combined message "Order" and "PI", the seller will find that "Order" is in good order but does not know that "PI" is a piece of replayed data and will forward it to the acquirer. It is not very difficult to achieve this in SEPP by sending "Initiate" which is in eleartext and free for the attacker to manufacture [2] and then feeding the seller with recorded "PI". It is even easier to achieve this in STT because there is not an "Initiate" message sending from the buyer to the seller [3] and the seller should not perform replay detection on "Order" since a legitimate user should be allowed to replay that message in order to conveniently repeat the same purchase. The consequence: a massive number of duplicated "PI's", each with a valid format and nested inside a valid "Auth-Request", come to the acquirer for on-line, real-time checking against replay. The novel use of challenge-response mechanism to be proposed will minimise the on-line use of slow public-key cryptography and totally avoid communications to remote CRL's during the on-line time, as well as eliminate the need of on-line detection of message replay. Message replay detection can safely be delayed to an off-line time. The on-line authorisation process needn't wait for the result of replay detection. The system performance in on-line authorising payments will be evidently improved and various mass-dialing attacks will become unrewarding and uninteresting. 3

The Proposed

Revision

Figure 2 illustrates the message flows of the proposed revision to STT and SEPP. For convenience, we will call STT and SEPP the previous work, and our work the revision. Viewed from transaction structures, the revision is different from the previous work mainly in that, now it is the seller who receives ttie final message and terminates a protocol run. This is the message Payment in Figure 2. We should point out that with this seemingly additional message, the revision does not add complexity to the previous work. Firstly, compared with SEPP, the message Payment here does not form a real additional message; with this message,

S E P P no longer needs its first message "Initiate" and the message "Invoice" (see Figure 1) becomes non-personalised which comes to the buyer as a result of her (on-line or off-line) catalog searching. Next, compared with STT, the added final payment step does form an additional message. However, such an additional message from the buyer to the seller seems to be indispensable as otherwise (i.e., in STT), there is no way for the seller to use any "context-sensitive" means to detect a message replay and it is entirely unjustified to centralise this detection job from a netwide area to the acquirer whose on-line capacity determines the the system on-line performance and who processes a high volume of specialised services that no other principals in the system can do for it. Later we will see further simplicity in the revision in the following two aspects: (i) the delayed payment message can be automised if the buyer's system finds everything in order, (ii) there will be no any need for the buyer and the seller to communicate status inquiry/response messages ("P.O.Inquiry"/P.O.Respouse" in SEPP). In the following two subsections we devise solutions to problems in the previous work. After having presented our solutions, we will further be able to define the timeliness of on-line messages (Section 3.3). A precisely accountable measurement for determining the timeliness of on-line messages is another important service but missed in the previous work. 3.1

Revision

Let B, S, A denote the buyer, the seller and the acquirer (gateway) respectively; {message}Kx, an encryption of message using the public key of X; Signx (message), a signature oil message created by X; Certx, a public-key certificate issued by a well-known certification authority (CA) to the principal X (i.e., it is a signature of CA combining the public key and the identity of X); H(message), a one-way hashed value of message; and finally {message}gx~, be a.n encryption of message using a symmetric crypto-algorithm where the key fixY is shared between X and Y (the symmetric crypto-algorithm can simply be a keyed one-way transformation serving as a checksum, if the privacy of message is not a concern). The presentation mainly focuses on ideas of improving the previous work. Therefore we may omit some useful, business oriented redundant information. S a l e s - I n f o . This message is resulted from the buyer's shopping action. It will include the seller's and the acqairer's public keys and respective certificates. Let Offer be goods/services offered by the seller. It suffices to describe S a l e s - I n 2 o as the following message:

Offer, Carts,

Cart A

It is reasonable for the seller to distribute CertA since he maintains a long-term business relationship with the acquirer. Note that unlike "Invoice" in SEPP, here S a l e s - I n f o needn't be a personalised message; when sending it to the buyer, there is no state change with the seller. This is quite a true circumstance for the

10

buyer shopping from viewing the seller's off-line catalog or on-line web pages. Purchase. The buyer starts a purchase by sending Purchase to the seller. In most cases (e.g., absence of communication failures or delays), the effect of sending this message will result in a payment transaction as in the previous work. In this message, there is a part intended for the acquirer (PI, for Payment. Instruction) and a part for the seller (Order). The part PI can be as follows: PI = {CardNo, B, Amount, Date, NS}Ka Here, the data parts CardNo, B, Amount, Date are the buyer's card number, identity, the amount to pay and the date of transaction, respectively; NB is a secret number generated by the buyer; we will further describe the usage of NB in a moment. Let PurchaseForm be a purchase form filled by the buyer; it may include the services/goods to buy, quantity and delivery information. The part Order can be as follows: Order = { Purchase Form, Date } i~s (Note that, the public-key cryptography specified in PI and Order does not mean the direct use of public-key algorithms to encrypt bulk-data.) The whole message Purchase will include these two parts plus the following digital signature and the buyer's (and perhaps her bank's, i.e., the issuer's) public-key information.

Purchase=SignB(Order , pI), Certs For performance considerations, this signature will only be verified by the seller during the protocol run. In Section 3.2 we will specify the gateway's off-line verification duty on the buyer's signature and certificate. Auth-Request. This step requests for on-line financial services such as the credit worthiness or debit status of the buyer. Note that unlike in the previous work where the communication channel from the seller to the gateway is protected by public-key erypto-techniques, in the revision, symmetric cryptoalgorithms based on shared keys will provide any needed protection (authentication and privacy). These two principals can renew a shared key (KSA below) in a given period of time (e.g., once a day) by running a key agreement protocol (e.g. using public key cryptography). The message Auth-Reqnest is as follows: Auth-Request : {PI, B, Amount, Date, TID}Ksa Here, T I D is called transaction identifier, a nonce generated by the seller to uniquely identify the transaction. A u t h - R e s p o n s e . In this step, the acquirer will a.uthorise the payment transaction using the information available from the existing financial network. Assuming that Auth-Request has a valid format and a valid date (easy to check using symmetric crypto-techniques), and that everything with the buyer's financial status is OK, then the transaction will be approveed and the message

11 Auth-Response sent to the seller. (We only consider the case of approval; also note that it is purely the acquirer's business on whether the seller's account should be credited immediately or not). The gateway will create a challenge to the buyer, a method for the seller to verify the buyer's on-line response, and deposit a piece of data. The challenge to the buyer can be:

Challenge = SignA (NA, TSD, H(NB)) Here, NA is the acquirer's nonce. The method for the seller to verify the buyer's on-line response is a message called Authenticator:

Authenticator = SignA (TI D, H (K), TA) Here, K is called pagment-key, coded as follows:

z( = ~ (TZD, NB, NA) The payment-key is the hashed value of the buyer's secret number and the other two principals' nonces. Since it includes the buyer's secret number NB, the gateway expects that, by challenging with NA and TID, only the buyer is able to respond with a correctly K (assuming NB is sufficiently large). Finally, the piece of data deposited in the gateway database will be called GatewayData:

GatewayData = TID, Amount, H(K), TA, CertB The values in GatewayData will be used in several off-line processes. By saying "off-line processes", we mean that the gateway will not process these values during the time of on-line authorising the payment transaction; it will not wait for any result computed from these values as decision-making material in approving or declining a payment transaction. In Section 3.2 we will define the gateway system's off-line processes using the values in GatewayData. The message Auth-Response is as follows:

Auth-Response = Authenticator, Challenge Besides necessary entity and message authentication, the seller should also check against message replay. Any message which is not a proper response to a pending A u t h - R e q u e s t (denoted by TID) should be discarded. Since here the seller is awaiting for an expected message, it is easy to defeat any data replay" or manipulation. C o n f i r m a t i o n . This message contains the data part Challenge. At this moment, this message forms a confirmation to the buyer that her message P u r c h a s e has been received and the payment authorisation approved, if later the seller receives a correct response (containing the payment key K), then the response will constitute not only a payment commitment, but also a proof that the buyer has received the message C o n f i r m a t i o n . Thus, C o n f i r m a t i o n will indeed function as a valid receipt for the payment; the buyer cannot deny having received it. (On the contrary, C o n f i r m a t i o n in the previous work cannot be regarded as a

12 real receipt because the seller cannot prove the message has been received by the buyer). Confirmation = Signs (Challenge) P a y m e n t . This message contains the payment-key K which forms a response to the data part Challenge created by the gateway. However the on-line response is not directly sent to the original challenger, but to, and to be verified by, the seller. The message Payment can be as follows: Payment =

SignB (TID, K, Ts }

Here, the buyer's timestamp TB indicates the message sending time (its usage will be specified in Section 3.3). The buyer's signature on the payment-key is necessary (otherwise, the buyer can be masqueraded by someone else). The seller will verify this signature. (The gateway will also verify the signature upon its arrival, to be specified in Section 3.2). Besides necessary entity aud message authentication, the buyer should also check against message replay. Any message which is not a proper response to a pending Purchase (denoted by Ne) should be discarded. Since here the buyer is awaiting for an expected message, it is easy to defeat any data. replay and manipulation. We point out that this final step of message sending can be implemented to execute automatically such that it will not ask for the buyer's intervention if everything is checked to be OK. Thus, viewed by the buyer, the revision is simpler than the previous work. T e r m i n a t i o n . Upon receipt of the message Payment, the seller can verify the correctness of the response by checking if the payment-key K can be hashed to the hashed value received fl'om the gateway. He should also check the buyer's signature. Handing in incorrectly signed payment-key may put him at various risks ranging from repudia.tion of payments to other penalties. If everything is OK, then the protocol run terminates successfully and the seller knows that it is indeed the buyer who has committed to pay the purchase. Services or goods purchased can safely be delivered at this time. ']?he seller must tirnestamp the payment key; namely, generate a digital signature Signs (TID, K, ~ ) where Ts states the receiving time of the message Payment. The time interval between the two timestamps (TB,TS) will be used to determine the timeliness of the final on-line message Payment. In Section 3.3 we will define the timeliness of this message. 3.2

Off-line processes

The values in GatewayData will be used for several off-line processes. An offline process regarding an approved payment transaction is t.o be performed after the transaction has been approved. Off-line processes are intended to effectively add the payment systems' on-line authorisation speed and capacity without relying on adding hareware equipment. Below we describe several ca.ses of off-line processes using the values in GatewayData.

13 First of all, each Auth-Request should be checked against replay. This is to check duplication against the value TID. We assume that there is another database (call it TID-archive) that archives all previous TID's with valid dates. If the TID in a GatewayData is also found in the TID-archive, then a message replay has been detected. The gateway knows that the seller had aborted the protocol run because he is required to perform the on-line replay detection against the duplication of TID. Therefore, an automatic reverse transaction for the approved transaction should be performed and the GatewayData deleted. In absence of replay, the value TID will be put into the TID-archive. Now, the gateway waits for either of the following two events to occur. (i) the arrival of the payment-key K, or (ii) the occurrence of a "bad-data-time-out" event. In the case (i), the gateway system can verify the buyer's signature on the payment-key by using CertB in GatewayData (the CertB will also be validated at this time). If the verification passes, then the GatewayData will be deleted. A correct signature supported by a valid certificate guarantees that unauthorised payment is impossible. On the other hand, if the verification fails, then it is the seller who has not properly verified the buyer's signature and therefore should be held responsible for any related loss. In this situation, the approved transaction should be reversed. If the payment-key does not arrive within a specified length of time, the system will signal a "bad-data-time-out" event regarding the GatewayData. This event indicates a system integrity failure: for whatever reason, the protocol run had not reached a successful termination. The approved transaction should be reversed. Finally we point out that the specified method for message replay detection does not detect a possible replay of the buyer's message PI. This is because we consider a convenient use of the system for the buyer: she may occasionally replay this message in order to purchase the same thing for more than once. (The buyer's system must be designed to be very simple and convenient to use). Note that because the gateway will always use different nonces NA'S in different transactions, so the payment-key, as a hashed value mapped from NA and other data, will unpredictably change in different transactions and only the buyer can correctly anticipate the change. Thus, it will be fruitless for any other principal to replay PI. 3.3

Timeliness of on-line messages

As a general requirement in cryptographical protocols, the timeliness of each online message should be defined. This is particularly true for protocols securing on-line bankcard payment transactions. One of the reasons for today's on-line bankcard payment systems to be successful is their speediness. In order to keep this legacy, the timeliness of on-line messages in a payment protocol must be clearly defined. For instance, the seller should be prevented or discouraged from deiaying goods/services delivery. Usual methods to determine message freshness can be summarised as follows. For a recipient, the standard timestamp technique in conjunction with a message

~4

lifetime can define the timeliness of messages received. Further, if the message received is a response to a challenge sent in the same protocol run, then the standard chMlenge-response mechanism can also allow the recipient to locally determine the timeliness. For a sender, if a message sent is one to be responded in the same protocol run, then upon receipt of the response, a challenge-response mechanism will also allow the sender to figure out whether the message sent has been received by the intended recipient in time. The only exceptional case that has not been covered by the usual methods described above is when a sender of the final protocol message wants to determine if the message will arrive at the recipient in time. In the previous work, no any feasible mechanism is available for achieving this knowledge: the sender of the final protocol message, i.e., the seller, has no way to determine whether the message C o n f i r m a t i o n will arrive at the buyer in time. The consequence: it is easy for the buyer to repudiate a payment by falsely claiming ~'time-out". Moreover, because of this unaccountability, the seller can deliberately delay sending out the final message in order to achieve undeserved gain. In the revision, we have included a simple method to let the buyer determine whether the final message will be received by the seller in time. The method provides an accountable mechanism for the payment system operator to spot a seller who delays goods/services delivery. It is to use timestamps integrated in the payment-key K. We have specified that the payment-key K is timestamped with a sending time TB (stamped by the buyer), and with a receiving time Ts (stamped by the seller). Thus, the time interval (TB,Ts) will be used to determine the timeliness of this final on-line message. When off-line checking the payment-key, the gateway will verify its timeliness by checking if Ts - TB exceeds an allowed value. Of course, the end-users can manipulate their timestamping procedures. For instance, if the seller finds that Ts produced by his system's timestamping procedure results in an invalid payment-key (i.e., Z) - TB exceeds the allowed value; this may be a result of a heavy network traffic), then it is his immediate interest to forge an earlier time T~, and uses it to turn the payment-key back to be valid. Either this will not be very harmful if the goods/service delivery time is consistent with the forged time T); namely, T) should not be far too earler than Ts, or else it will be a matter of breach of contract which will easily be discovered by the buyer because the value ~Time-of-receiving - TB" is evidently bigger than an allowed value. Rather than to manipulate the timestamping procedure with a risk of being detected, a safe alternative for the seller is to ask the buyer for re-sending Payment. The buyer can also manipulate her timestamp, e.g. to forge a T~ earlier than TB produced by her system's timestamping procedure. The intention of this manipulation is not very clear; perhaps it is in order to let the seller deliver goods/services earlier. The room for this manipulation is limited because T~ cannot be earlier (or significantly earlier) than TA which is known to the seller (integrated in Authenticator). The intention of forging a T~ later than the real system time TB is even less clear and seemingly harmless to the system.

15

4

Features

Now we look at how the revision solves the identified problems in the previous work.

4.1

R e s i s t a n c e to f r a u d a n d c o m m u n i c a t i o n f a i l u r e s

We begin with assuming a communication failure occurring in any stage in a protocol run. Then the seller will either not receive the final message Payment, or receive it as invalid (stale). If the communication failure takes place after the gateway has sent Auth-Response, a "bad-data-time-out" event will be signaled within a specified time and an automatic reverse transaction will be performed to compensate the payment in question. Thus, no real payment will be made and no goods/services will be delivered. Since communication failures do not give any party a clear advantage, to falsely claim communication failure will be fruitless. The buyer will not deny receipt of C o n f i r m a t i o n if she wants to get the purchase and cannot deny it after having sent Payment, and the seller will not deny receipt of Payment if he wants to get paid. In fact, if a communication failure has only corrupted the final message Payment, then it can be re-sent upon the seller's request. With duplicated Payment's, the seller cannot get multiple payments because the usage of the payment-key is merely for the gateway to delete GatewayData and so to prevent an automatic reverse transaction upon the "bad-data-time-ouC event. Of course, if the issuer had been contacted during the protocol run, a communication failure may cause the buyer to suffer the unavailability of funds for a period of time similar to the length of "bad-data-time-out". Also, an advanced external attacker can inconvenience a given buyer by intercepting Conf i r m a t ion sent to her, or Payment sent from her. These attacks may temporarily restrict the funds available to the buyer (again only in the case when the issuer had been contacted), but do not allow the attacker the use of these funds. We believe that these circumstances are rare because (i) the adversary needs sophisticated technique to attack without being detected, and (ii) the attack does not let the adversary gain a clear advantage. They are certainly much ra'rer than the fraudulent possibilities in the previous work where the legitimate end-users may have an incentive to falsely claim communication failures and need no advanced technique to do so. For instance, as we have discussed in Section 2.1, it is sometimes worthwhile (and always trivially easy) for both legitimate end-users to defraud each other in the previous work.

4.2

I m p r o v e d s y s t e m on-llne capacity

We begin with analysing the gateway's on-line computation load in public-key cryptography.

16

In each transaction, the gateway on-line computes one decryption (PI) and generates two signatures (Auth-Response). These computations use the acquirer's own private key(s). Specially designed hardware containing private keys can be used to speed up these computations. An important advantage of using no end-users' (in particular, the buyer's) public keys during the on-line time is the avoidance of validating their key certificates, which usually requires on-line communications to remote nodes (CRL's). On the contrary, in the previous work, the gateway has to on-line verify the both end-users' signatures and validate at lease the buyer's key certificate (assuming it caches the seller's certificate). Besides the need of communications to CRL's, the latter job also means additional computations in public-key cryptography (depending on the depth of the certification hierarchy). Next, we also know that the new use of challenge-response mechanism in the revision turns the gateway's message-replay-detection job into an off-line process. This is another important achievement. On-line message-replay detection is very time-consuming because it resorts to real-time sorting and checking through a huge database. Note that, in off-line replay detection, speed is no longer a requirement; therefore the database (TID-archive) needn't be sorted in realtime; the safe backup copies can also be tape-based cheap ones. The significantly reduced gateway on-line workload turn various mass-dialing attacks into less-rewarding and non-interesting actions. Each time when the gateway receives an Auth-l~equest message from the Internet, it can compute a simple checksum using efficient shared-key techniques to validate the message format (no need of signature verification, certificate validation, or communications to CRL's during the on-line time). Thus, sending gibberish to the gateway will not consume much of the ga.teway's on-line computing time. In order to effectively reduce the gateway's on-line capacity, the attacker should replay recorded messages with a valid tbrmat. For replayed messages with a valid format, the gateway will simply serve as usual. It will later detect them in its off-line detection process and make correspondent reverse transactions as corrections (still an off-line process). Thanks to the end-users' on-line detecting message replay: any replayed message will be discarded by either of the end-users and this is equivalent to aborting the attacking run using that message. 'Thus the gateway is able to safely delay the replay-detection job to an off-line time. The issuer is less likely to become a target of mass-dialing attacks. This is because, each seller-acquirer pair corresponds to many issuers; collecting data from the communication links leading to a given seller or a given acquirer limits the volume of usable data. To increase the volume of usable data. by collecting them from various points over the network is a difficult job.

5

Conclusion

We have studied two current important cryptographie technologies for securing on-line bankcard payment transactions over open networks and revealed a num-

17 bet of subtle problems in them. The causes of these problems are identified as missing and misuse of various security services. A whole package of solutions are then devised and analysed to be effective in countering the problems revealed. The solutions are based on a novel use of challenge-response mechanism which itself constitutes a contribution to the study of cryptographical protocols.

Acknowledgements I would like to thank Stefek Zaba and Miranda Mowbray of HP Labs., Bristol for their helpful comments on drafts of this paper.

References 1. The CyberCash(tm) System How it Works. h t t p ://www. cybercash, com/cybercash/cyber2 .html. 2. Secure :Electronic Payment Protocol, Draft Version 1.2. November 3, 1995. http://w~w, mast ercard, com/Sepp/seppt oc .htm.

3. Secure Transaction Technology Specifications, version 1.0. September 26 1995. http ://www. visa. com/visa-st t/index, html. 4. Totally Secure On-line Checking. http ://wwwl.primenet. com/~rhm/index.html.

5. D. Gifford, L. Stewart, A. Payme, and G. Treese. Payment Switches for Open Net.works. h t t p : / /ww~. o p e n m a r k e t . c o m / a b o u t / t e c h n i c a l / c o m p c o n 9 5 . p s 6. M. Linehan and G. Tsudik. Internet Keyed Payments Protocol (iKP). June 30 1995. http ://www. zurich, ibm. com/Technology/Security/extern/ecommerce/spec.

7. M.S. Manasse.

The

millicent

protocols

for

electronic

commerce.

http ://www. research, digit alcom/SRe/people/Mark_Manasse/bio, html.

8. B.C. Neuman and G. Medvinsky. Requirements for Network Payment: The NetCheque(TM) Perspective. Proceedings of IEEE Compcon'95, San Francisco, March 1995. 9. R.L. Rivest and A. Shamir. Payword and micromint: two simple micropayment schemes, http://theory.lcs,mit.edu/-rivest/publications.html~

t0. M. Sirbu and J.D. Tygar. NetBill: An Internet http ://www. ini. cmu. edu/netbill/CompCon, html.

Commerce

System.

A Certification

Scheme

for Electronic

Commerce

Bruno Crispo and Mark Lomas University of Cambridge - Computer Laboratory, New Museum Site, Pembroke Street, Cambridge CB2 3QG. U.K. e-mail: {Bruno. Crispo,Mark.Lomas}@cl.cam.ac.uk

ABSTRACT

This paper examines trust in distributed systems. The particular example that we choose is that of key certification, although the techniques have more general application. Existing system do n o t provide sufficient evidence to help to resolve disputes. We address this problem. K e y w o r d s : Trust, certification, revocation, key management, evidence, authentication

1

Introduction

Most people reading this paper will be regular users of distributed systems. When you use such a system, how do you authenticate yourself to remote machines? In a seminal paper Needham and Schroeder,[9] described trusted third parties that they called authentication servers. Such servers are trusted in the sense that they can masquerade as one of their clients but it can be extremely difficult for a client to prove that this has happened. Needham and Schroeder appear to assume that this does not happen. Another approach is for each client to choose a pair of keys (one public and one private) and for a certification authority to certify the public keys. Many such schemes, however, still allow the authority to masquerade as one of its clients while making it difficult for the client to prove that this has happened. We shall give examples of such misbehaviour later in this paper. Our paper describes a family of services that together provide a key certification and revocation facility. These services are unusual in that none are trusted.

2

Trust

and

Evidence

By "trusted" we mean a component that can violate the security policy (in this case by masquerading as a client) without leaving evidence of its misbehaviour. We should note that if we trust a system component then we are implicitly trusting the management of that component. In this sense, and by contrast, ITU

20

recommendation X.509,[1], [2] assumes that a certification authority is trusted, even though it does not know the clients' private keys. Let us restate the problem in terms of an example: Alice and Bob wish to communicate securely. Perhaps they are engaged in an electronic commerce transaction. For a variety of reasons they enlist the help of a third party, Sue, to introduce them. We require that the protocol that they agree to use does not allow Sue to masquerade as either Alice or Bob without leaving evidence that may be used to show that Sue has misbehaved. In the context of Needham and Schroeder's paper, Sue might be the authentication service. If Alice and Sue share a symmetric key for the purpose of authenticating Alice then Sue can forge any message that Alice might have sent. If Alice and Sue are subsequently in dispute - Alice claims that Sue misbehaved - it is difficult for an arbitrator to determine whether Sue or Alice created the disputed message. For this reason we did not consider any protocols that rely entirely upon symmetric keys. If Sue instead acts as a certification authority then her possible misbehaviour must be more subtle. Since Sue, presumably, does not have access to Alice's private key she cannot forge a message signed under that key (this is not strictly true - poor use of public-key cryptosystems can allow forgery, but we assume that suitable precautions have been taken [5]). However if Bob has never communicated with Alice he may not know her public key; in particular he is unlikely to have the public key certificate, signed by Sue, certifying Alice's public key. Sue can create a new certificate claiming that Alice has a different key and using this and the corresponding private key can sign messages appearing to come from Alice. Alternatively if Bob wishes to communicate confidentiMly with Alice, Sue may use this new certificate to convince Bob to seal the message using the wrong key; Sue then unseals this message using the (wrong) priva.te key. Proponents of certification authorities might claim that Sue would be foolish to behave as described because if Bob does have Alice's certificate he can notice the misbehaviour. We note however that any well designed certification scheme has to take into account the possibility that a certificate may need to be revoked perhaps Alice has lost her private key and wishes to choose a new key, or worse still, her private key may have become public in which case she neither wants to be held responsible for messages signed under that key nor should confidential messages be sent to her sealed under the corresponding public key. Imagine a court case. The plaintive, Alice, claims that the defendant, Sue, forged a new key certificate and then used this to impersonate Alice; she even has evidence in the form of conflicting certificates, one for the correct key and one for the new fraudulent key. Sue counters by saying that she did indeed issue both certificates, but at Alice's request.: "Alice claimed to have lost her private key and so I issued a revocation certificate [exhibit C]; she then asked for a certificate for her new key". How might such a dispute be resolved? Meanwhile, the proprietor of Bob's Baubles doesn't know whether Alice or Sue signed for a consignment of diamonds. In the "real world" we might expect to find a p~per audit trails; we are seeking an analogue to this.

21

Our primary goal is to help arbitrators, including courts, to resolve such disputes. We say "help" since if sufficiently many participants collude to forge evidence then the dispute might be resolved incorrectly. By following the principle of separation of duty we hope to discourage such collusion- we assume that the more people required to collude in a fraud the greater the chance that they will be caught. A lesson we should learn from the examples above is that where data may be presented to an arbitrator as evidence we should try to ensure that there is only one reasonable explanation for that evidence. Sharing of keys usually breaches this requirelnent. We might rephrase this requirement slightly: where data may be presented as evidence, one entity should be responsible for that data. By responsible we mean "held responsible for the consequences" rather than 'qs responsible for maintaining a copy". We encourage the case where several (preferably many) parties keep copies of evidence since this makes it harder to subvert (destroy, corrupt, or create after the event). We choose to put an onus on participants in our protocols. The system aims to provide a useful service to participants - in particular it aims to provide key certification and revocation facilities that may be used to authenticate those participants. In return, clients are expected to keep a log of certain parts of the messages that make up the prot~ocol (keeping a log of all messages satisfies this requirement but is unnecessary). These logs will be useful in the event of a dispute. Failure to keep sufficient logs may mean that a client cannot have a dispute resolved in his or her favour. This is like saying that a company that fails to keep proper accounts may suffer as a result - we deem this to be acceptable. Our rule may be restated more succinctly: if you wish to participate in our protocols then you are required to keep a proper audit trail. The sanction is that disputes will be resolved against you.

3

Assumptions

So far we have spoken in general terms. Let us consider our assumptions more carefully. -

-

Participants all have unique names and unique authentication information (private keys) associated with them. If a component is replicated for some reason and keys are shared, despite our recommendation that this be avoided, then a single entity shall be responsible for the consequences. Private keys are not shared. In particular, security-critical components such a.s the servers themselves should never learn, or be able to derive, the keys of their clients. Let us emphasise this by saying that even when a key pair is first generated our servers should not have access to the private key. This implies that clients must have their own facility to generate keys. Specifically, clients should not expect the certification authority to generate their keys,

22 nor should the authority be willing to do t.his. If the authority never learns my key then I cannot accuse it of abusing that knowledge. It may be necessary for some clients to trust a third party to generate their keys for them [12], but they should realise that these third parties might abuse their position of trust and we cannot resolve a dispute between a client and somebody he or she trusted to generate keys. We have to rely upon certain assumptions about, the strength of cryptosysterns and hash functions. If the security of either is breached then security of our systems is breached. Further, if this happens then we can no longer resolve a dispute to determine who is responsible (other than the designer of the cryptosystem or hash function that failed). We have already said that we avoid the use of symmetric-key cryptosystems, or at least they are not relied upon for authentication or non-repudiation. Instead we rely upon asymmetric cryptography, specifically the RSA, [13] cryptosystem in combination with the MD5 hash function, for reasons of efficiency, which for our purposes we assume to be collision-free [11]. - We do not intend to prevent, or even examine, denial-of-service attacks. We know that some of the participants can deny service either directly or indirectly. Further, such denial of service cannot (easily) be distinguished from an external attack or even from simple failure of parts of the network. Participants have access to sufficient long-term memory to store the required audit-trail entries. Some participants may choose to rely upon a third party to store such information- in particular they might choose to archive old entries and store them somewhere presumed secure, such as a. bank vault. It is important, however, that these entries are maintained for as long as necessary to resolve any possible disputes. - The managers of our security services must be able to use conventional methods of authentication. For example, if you wish to register with our certification authority then you will be asked for your passport or driver's licence and required to sign a letter of authority. The security of our system (and of any security system) is no better than the methods used to authenticate its users. We are not concerned with confidentiality of transactions or the audit trail entries concerned with those transactions. In environments where confidentiality is of concern, it may be necessary to change both the protocols and the audit trails. -

-

-

4

Overview

We should perhaps contrast our scheme with an existing scheme to show the difference in approach. In particular, we would like to contrast our approach with that of X.509. We have explicit rules for the creation and processing of audit trails. Specifically, we have rules that describe how an arbitrator is intended to process these

23 audit trails. It is possible for our rules to result in a miscarriage of justice, which might seem worrying, however this can only happen if at least two parties collude (or are incompetent). It is not possible for a single participant, not even the certification authority, to make it appear that one of the other participants has misbehaved. We separate the functions of certification and revocation. This requirement is necessary in order to enforce the safeguard described above. If the certification and revocation services were to be combined- and X.509 seems to imply this - then it is relatively easy to persuade somebody to act upon a fraudulent certificate. In particular by revoking a certificate and then issuing a replacement these services can make it appear that a client has a new key. X.509 is relatively secure against external attack (assuming that the changes suggested by Burrows, Abadi, and Needham, [3] have been incorporated) but is, we suggest, insecure against internal attack - particularly by the certification authority itself. Our separation of duty rule means that such an attack would require the collusion of the certification and revocation authorities. In order to enforce this there is a security rule that we cannot incorporate into the protocol - instead it is a requirement that should be enforced by the management structure. This rule is that the manager in charge of the security of one of these services must not be responsible for the security of the other. Ideally certification and revocation would take place on distinct machines in distinct domains, under the supervision of distinct managers. In a real-life environment such as The Computer Laboratory here in Cambridge we have distinct machines locked in distinct rooms, managed by the occupants of those rooms, sharing only the network. Such separation requires careful planning. If the machines both boot from the same boot server (or from two or more servers under the same management) then they are almost as insecure as before (we say "almost" since Lomas and Christianson's paper [7] shows one method of booting from an untrusted server). Provided the security managers (note the use of the plural) know this, however, they should be able to ensure independence between their two machines. Let us return to the idea of "trust". Different people mean different things when they use this word so we wish to make clear what we mean by a trusted component or system. We define a trusted component as any component that is capable of violating the declared security policy. This is typically because users of the system rely upon the good behavionr of that component for the security of their transactions; they delegate certain security-critical functions to that component. Sometimes the users might not choose to do so, but cannot avoid such delegation because of the structure of the system - what is a user to do if she does not trust the only certification authority within her local domain? Even if the user does trust the component this is usually a matter of opinion rather than a matter of fact: a component can be trusted but untrustworthy (it can also be untrusted but trustworthy, but that is another matter). Such an opinion might be influenced by knowledge of the security manager ("I've known

24 Fred for y e a r s - he won't try to cheat me"), or because they (possibly naively) believe that the past behaviour of the component, is a. good indication of its future behaviour. Often the trust is institutional: see how far yon get with your bank if you suggest that you don't trust them with the PIN that authenticates your ATM card, and that you would rather use a third party who you consider more trustworthy. Misbehaviour of a trusted component can sometimes be detected, but often cannot be proven. \u are reminded of the difference between authentication protocols and non-repudiation protocols. Just because you are convinced that you are communicating with a particular person does not mean that you can convince somebody else. It is possible to design protocols that allow you to convince somebody else, but this has to be an explicit design goal. We have a requirement that you should be able to convince somebody else of the misbehaviour of somebody you have communicated with. We have already suggested that systems such as I(erberos [8], [4] and X.509 rely upon trusted third parties. It can be argued that an X.509 server is less trusted than a Kerberos server, since it does not know its clients' keys. Indeed, one of the justifications for using X.509, or similar protocols, for authentication is that compromise of the server's key database does not lead to catastrophic failure of the security of the protocol. However, although X.509 is more secure in this regard, it is still far from perfect. We wish to minimise the extent of trust in our system. One way of doing this is for participants to verify the behaviour of components to which task are delegated. Sometimes the clients cannot by themselves validate the behaviour of another component, but they should still maintain audit-trail entries to allow others to validate that behaviour. We are, reluctantly, forced to accept the fact that a trusted component may breach the security policy briefly, although we shall be able to prove this later. We are primarily concerned with allowing insiders to prove their innocence, quickly and convincingly. When a client communicates with the certification authority it relies upon the behaviour of that authority to ensure the security of a subsequent transaction. If Alice asks Sue for Bob's certificate and Sue forges a certificate appearing to be Bob's then Alice may not be able immediately to detect the misbehaviour. However, Alice should, as a matter of routine, store this certificate in the audit trail just in case the transaction is later disputed. We mentioned above that systems secure against external attack might not be immune to internal attack. Some types of attack are difficult., if not. impossible, to prevent. For example a user can revoke his own key certificate before sending a signed message to somebody he knows is unlikely to check the revocation list. A different attack: the revocation authority (in our case distinct from the certification authority, but in many systems they are one and the same) can create an unwanted revocation certificate saying that a client, claimed to have lost his private key (please note that the key is claimed to be lost rather than

25 compromised, because in the latter case it would still suffice to sign a revocation request). In our system it is the combination of the audit trail entries with the use of a s y m m e t r i c cryptography that allows us to resolve most internal attacks. Since the audit trails are critical to this resolution it is important that they be held in a t a m p e r - p r o o f form. Audit trail entries have to be signed and, where confidentiality is considered necessary, they may also be encrypted. In the case of a signed message there will be at least two signatures in the audit trail - the signature of the sender, and the signature of the entity maintaining t h e audit trail. These signatures allow us to determine who was responsible for creating the message and who for logging that message. In addition to the signatures we require entries to be bound together in a way that makes it difficult to insert new entries after the event or to reorder entries. One reason this might be important is that if a user compromises her own private key, she should not be able to benefit by (falsely) claiming that an audit trail entry signed under her key was created after the key compromise. To do so would frustrate the use of non-repudiation protocols. Responsibility for the various audit trails is distributed amongst the participants. It is in the interests of honest participants to maintain these logs since they provide evidence of honesty. Dishonest participants have no such incentive but in this case disputes will be ruled against them. This does not mean that lack of an audit trail entry is proof of dishonesty but our dispute resolution procedure penalises incompetent participants no more leniently than dishonest participants. This combination of rules and responsibility provides robustness that is not apparent in existing networks. Such robustness is, we believe, a fundamental requirement of applications such as E F T (Electronic Funds Transfer) or electronic commerce. The public will expect such applications to provide safeguards against fraud.

5

Separation

of Duty

The principle of "separation of duty" is well known. If one person has complete control over the security of a system then he or she might abuse that control - it m a y also be difficult to prove such abuse. For example, in a well-managed bank there is no one person with access to the vault. Instead two or more people must collude to open the vault door. Such a security measure is both in the interest of the bank, making it more secure, but also in the interest of the bank employees an employee who cannot open the vault door will not be threatened into doing SO.

We split the functions of certification and revocation into two distinct services. Different managers are responsible for the security of each server. In a high security environment we could envisage splitting even these duties, for example by locking the servers in rooms with two locks so that two managers must be present to open the two locks.

26 In fact we split the certification service further - into two (or more) distinct servers, as we shall explain. However, these servers may be controlled by the same managers.

6

Certification

A

B

J .........

f ......

......

I I

t ............

I 1

CA

RA

on-line

I

I

t I I I I I

I I

xx x x

xx

I

if-line x xx

I x % t

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

x, 4

Fig. 1. Logical Structure

The certification process is divided into an on-line and an off-line component, (Fig.l). The off-line certification authority (CA off-line) is the server that in other systems would have to be trusted - it is this that "signs" key certificates. The on-line server is completely untrusted; it has no access to the authority's signing key and so, in a sense, the name "CA on-line" is misleading. CA on-line acts as a repository for key certificates signed by CA off-line. Failure of the online server prevents access to the certificates but cannot, on its own, convince a competent third party to act upon a fraudulent certificate. Our system is not unusual in splitting the certification process from the database that clients use

27

to retrieve these certificates - many existing systems, including X.509 implementations, already do this. Now we shall describe our certification procedure: Users send electronic key registration requests to the on-line server; these requests are stored in a file for later use. It is important that a request, signed under the private key of the requestor, contains the public key of the certification authority. Periodically the file of requests is transferred to the off-line server. Assuming that the user can satisfy the manager responsible that the request is authorised (and signs to this effect) the off-line server signs a key certificate. Such certificates may then be transferred back to the on-line server. The certificates contain no confidential information and so there is no requirement to keep the file confidential. The certificates also contain a (hopefully unforgeable) digital signature and so tampering can be detected; it is not vital, therefore, that the file be protected against tampering, but this is desirable. When we say "satisfy the manager" we envisage a procedure in which the manager checks identity documents such as a passport or driving licenee. It would be a sensible precaution to record information such as the serial number from this identification or even a photocopy. It is important, also, to keep the requestor's signature on a letter of authorisation - this also contains proof of the value of the key to be certified, probably in the form of a hash of the key. Users may request copies of their certificates from the on-line server but, as a matter of convenience, we allow the option of sending an e-mail (electronic mail) address along with the registration request; a copy of the certificate will be returned to this address. It is in the interest of the user to keep a copy of the certificate both for convenience (to reduce subsequent message traffic) and in case it is later required to help resolve a dispute. Certificates contain the following information: - V e r s i o n - to allow for subsequent changes to the format of a certificate. -

-

-

-

-

I s s u e r N a m e - a Fully Distinguished Name (FDN) showing which authority was responsible for the certificate. This may also be used to determine which public key should be used to validate the certificate. S u b j e c t N a m e - another FDN identifying the owner of the key that this certificate certifies. V a l i d i t y P e r i o d - two date and time pairs spanning the period that the certificate is intended to be valid. Note that a revocation certificate may countermand this period. S u b j e c t P u b l i c K e y - the purpose of the certificate is to bind the subject name to this particular key (or hash). S i g n a t u r e - t h i s specifies the rameters, to allow support, for signature, using that algorithm authority, applied to all of the

signature algorithm and any necessary pavariant algorithms. It also contains a digital and the private key of the off-line certification other fields in the certificate.

28 7

Revocation

A significant feature of our system is that the certification authority (neither server) is not responsible for maintaining a revocation list. This is because of our "separation of duty" requirement, that we discussed earlier. Instead we rely upon another on-line server that we call a "revocation authority". If a user wishes to change his or her public key then this necessitates contacting both the revocation and certification services. This may seem inconvenient, however this requirement makes it more difficult for a dishonest or incompetent certification authority to forge a key certificate. To replace an existing certificate you mus~ convince both authorities to cooperate. A dishonest certification authority might still issue a conflicting certificate but without the corresponding revocation certificate this is prima facie evidence of misbehaviour. The revocation authority both signs certificates and responds to requests for copies of the certificate. Unlike the certification authority the revocation authority is entirely on-line in order that it can respond quickly to requests. Slow response could lead to a breach of security, while stow response to a registra.tion request is merely inconvenient. To a security manager, slow response to a registration request may even be desirable. There are several forms of revocation request. The preferred form of request is signed using the key that corresponds to the certificate that the user wishes revoked. If you sign a revocation request with your own private key then the request will be acted upon automatically. If you have lost your private key, however, then this is more problematic. A user may sign a letter of authority, similar to that when he or she first requested a key certificate. In this case the manager responsible for the revocation authority has to instruct the server to issue a certificate. Finally, although this is to be discouraged, the user may generate a new public-private key pair, sign a revocation request for the old certificate using the new key, and present this along with the new registration request. The certification authority must not issue conflicting certificates (certificates for which the subject names match and the validity periods intersect) unless it has proof that at most one has not been revoked, (see section 9 for details). Revocation requests contain:

-

- Identification information showing that this is a revocation request. Timestamp - Certificate to be revoked (not just an identifier or partial content of the certificate, unlike X.509) - Signature for the preceding fields under the private key of the certificate owner.

29 Revocation certificates contain: A hash of the previous entry, to prevent tampering with the list (re-ordering, insertion, deletion, etc.) - A copy of the revocation request. - A randomly chosen "confounder" (currently 64 bits) chosen to protect against certain attacks on the signature scheme [6]. - Signature for the preceding fields under the private key of the revocation authority. -

It is important to understand how the entry will be verified. First the revocation authority's signature should be checked. Assuming that this is correct, the signature within the revocation request should be checked. Our revocation certificates illustrate an important principle: the signature in the request (if it is correct) protects the revocation authority against an accusation of misbehaviour; the authority's signature protects the person requesting the certificate, as it proves that the request was made and acted upon. Information that may be recalled as evidence would usually have at least one countersignature (i.e. two or more signatures). We should be careful when interpreting such evidence however since one reason for revoking a certificate is that the corresponding private key may have been compromised. Signatures under this key may have been forged after the event. This may make it appear that all old signatures are invalidated by the revelation of the signing key. This, however might allow a dishonest client to repudiate genuine signatures by revealing his or her key. Countersignatures help solve this problem. In particular, the use of a notarisation authority [10] may be advisable.

8

Chaining

X.509 recommends that revocation list entries contain the following: Serial Number - Subject Name - Timestamp Signature of the preceding fields under the private key of the revocation authority. -

Unfortunately this allows a certain form of undetectable misbehaviour on the part of the authority: entries can be re-ordered or replaced provided no witness has kept a copy of the entries that. will be tampered with. In particular, let us imagine that the revocation authority wishes to fraudulent.ly backdate a revocation request. It suffices to find an existing entry, perhaps already created for the purpose, then replace this with a new entry with the same serial number.

30

/ f i

i {Serial#,CAName,Time2j V i IKRA L . . . . . . . . . . . . . . . . . . . . . . .

2.__

a {Serial#'User2Name'Time3lKl~_ !

{Serial #, Userl Name.Timel} KRA_

Timel

Time2: Timel< Time2< Time3

Time3

Apparent Time F i g . 2.

Instead we m a i n t a i n a chain of entries by storing a hash of the previous entry within the current entry. We also store the signed revocation request itself as proof t h a t the revocation was authorised. T h e hash is necessary to protect against the possibility t h a t after a key has been c o m p r o m i s e d , the revocation request is fraudulently backdated to an earlier date. This also gives us some protection in the case that the revocation a u t h o r i t y ' s own private key is comp r o m i s e d - provided we have an entry t h a t preda.tes the c o m p r o m i s e we can determine Whether a p u r p o r t e d entry also predates the compromise.

9

Audit

Trails

A "good citizen" in our system maintains an audit trail. Recipients of secure messages should log these in case they are needed to resolve a subsequent dispute. If a participant fails to log an entry then she m a y h a r m her own defence in a subsequent dispute, but such failure would not implicate (falsely) another party.

31 Who is the most likely to be blamed

Evidence T w o c e r t i f i c a t e s i s s u e d f o r the s a m e U s e r f o r the s a m e public k e y s i g n e d b y C A , w i t h o u t a c o r r e s p o n d i n g r e v o c a t i o n certificate

CA

R e v o c a t i o n r e q u e s t f o r U s e r l ' s certificate s i g n e d by U s e r l h i m s e l f . E n t r y in the R C L for User1 ' s certificate inserted in the list a f t e r the a b o v e r e q u e s t and s i g n e d by R A T r a n s a c t i o n s i g n e d b y User1 w i t h the private k e y that m a t c h e s the r e v o k e d one. R e v o c a t i o n r e q u e s t f o r User1 ' s certificate s i g n e d b y U s e r l h i m s e l f . E n t r y in the R C L f o r U s e r l "s certificate inserted in the list after the a b o v e r e q u e s t and s i g n e d b y R A R C L i s s u e d after the a b o v e r e q u e s t s i g n e d by R A not c o n t a i n i n g the above RCL entry

Receiver

RA

Certificate signed by CA without corresponding paperwork request s i g n e d b y o w n e r ' s certificate

CA

R e v o c a t i o n certificate s i g n e d b y R A w i t h o u t c o r r e s p o n d i n g r e v o c a t i o n r e q u e s t s i g n e d b y o w n e r ' s certificate

RA

Transaction performed by Userl involving verification's signature using U s e r 2 " s p u b l i c k e y w i t h o u t appropriate R C L { H ( . . . . . { H ( { U s e r l ' s log file} Kuserlvs { H ( . , . . . { H ( { U s e r l ' s log file}

Kuser2 -

)} Kwimessl- """)} ) } Kwitnessl 2''''')}

KwimesssN KwitnessM-

Userl

Suspect situation that needs more investigations

F i g . 3. E x a m p l e s of D i s p u t e R e s o l u t i o n

Messages without signatures seldom constitute proof. Those with signatures should be countersigned by the recipient so that he or she can check for subsequent tampering. It is advisable for these also to be countersigned by a third party as proof of an upper bound on their time of origin. While the recipient could forge the date and time on his own signature he, presumably, cannot do so on the countersignature without collusion.

References 1. Recommendation X.509 Information Technology - Open Systems Interconnection. The Directory: Authentication Framework. Geneva June 1995. 2. Draft Technical Corrigendum to Rec. X.509. Geneva December 1995. 3. M. Burrows, M. Abadi, and R.M. Needham A logic of authentication Technical Report 39, DEC SRC, Pale Alto, CA., Feb 1989 4. S.M. Bellovin, M. Merritt Limitations of the Kerberos Authentication System Computer Communication Review Vol.20 No.5, Oct. 1990 5. Y. Desmedt, M. Yung Weaknesses of Undeniable Signature Schemes Advances in Cryptology:Eurocrypt 91 Brighton, UK, Apr. 1991 Proceedings Springer-Verlag

32 6. W. De Jonge, D. Chaum Attac~s on some RSA Signature Advances in Cryptology:Crypto 85~ Santa Barbara Cal. U.S.A Aug. 1985 Proceedings Springer-Verlag N.Y. 1986 7. T.M.A. Lomas, B. Christianson To Whom am ISpeaking ? IEEE Computer Vol.44 No.I, Jan 1995 8. S.P. Miller, B.C. Neumann, J.I Schiller,J.H. Saltzer Section E.2.1: Kerberos Authentication and Authorization System MIT Project At.hena Cambridge, Mass. Dec 1987 9. R.M. Needham, M.D. Schroeder Using Encryption .for Authentication in Large Network of Computers Communications of ACM, Vol.21 No.12, Dec 1978 10. G.J. Popek, C.S. Kline Encryption and Secure Computer Networks Computing Surveys Vo1.11 No.4, Dec 1979 11. R. Rivest The MD5 Message Digest Algorithm RFC 1321 1992 12. M. Roe PASSWORD - R2.5: Certification Authority Requirements Technical Report Nov. 1992 13. R. Rives% A. Shamir, and L. Adlemam A Method ]'or Obtaining Digital Signatures and Public-key Cryptosystems. Communications of the ACM, 21, 1978.

Practical Escrow Cash Systems Eiichiro Fujisaki

Tatsuaki Okamoto

NTT Laboratories 1-2356 Take, Yokosuka-shi, 238-03 Japan Email: [email protected], [email protected]

A b s t r a c t . This paper proposes practical e s c r o w cash schemes with the following properties: The privacy of users is preserved, unless all (or a certain portion) of the trustees collaborate. - If all (or a certain portion) of the trustees collaborate (for law enforcement or crime prevention), the collaboration can trace the payment history from the payer's (i.e., criminal's) name, and they can also trace the payer's (i.e., criminal's) name from a payment history. - Extortion attacks can be partially technically prevented. - Each coin is divisible under an off-fine payment condition.

1

Introduction

1.1

Escrow

cash systems

Electronic cash has been attracting the attention of m a n y people in various fields such as business, economy, engineering and science. Many untraceable electronic cash schemes were proposed in [1, 9, 15, 17, 22, 23, 31], and they guarantee "unconditional" privacy. However, as pointed out by yon Solms and Naccache [30], such unconditionally anonymous cash schemes make it much easier for people to engage in criminal activities such as money laundering and kidnapping than traditional paper transactions. Therefore, governmental and financial institutes m a y unwilling to adopt an unconditionally anonymous system. On the other hand, the privacy of a user who is not a criminal should be protected. T h a t is, a cash scheme is required that strikes a balance between privacy and social safety. (Hereafter, we call this type of cash scheme the "escrow cash scheme".) The requirements for the escrow cash scheme are as follows: -

Escrow:

9 ( P r i v a c y p r o t e c t i o n ) The privacy of users should be preserved, unless at least a certain portion of the trustees collaborate. (i.e., when a user does not violate a rule or law, the user's privacy should be preserved unless more than a number of trustees illegally collaborate.) 9 ( C r i m e p r e v e n t i o n 1) If a certain portion of the trustees collaborate for law enforcement or crime prevention (i.e., under a court order), given the criminal's identity (name), the collaboration should be able to trace the p a y m e n t histories of this criminal.

34

-

1.2

| ( C r i m e p r e v e n t i o n 2) If a certain portion of the trustees collaborate for law enforcement or crime prevention, given a payment history related to a crime, the collaboration should be able to trace the payer's identity of this payment. 9 ( C r i m e p r e v e n t i o n 3) Extortion attacks, in which a criminal forces banks or trustees to issue coins or reveal secret keys to the criminal through kidnapping etc., should be technically prevented [30]. S e c u r e off-llne d i v i s i b l e cash: | ( S e c u r i t y : N o o v e r - s p e n d i n g , n o f o r g e r y a n d n o s w i n d l i n g ) If a user over-spends a coin, a bank should be able to obtain the evidence of the user's over-spending, and to trace the identity of the user. Here, no party other than the user should be able to forge the evidence of over-spending. In addition, a coin or deposit information shouldn't be forged. | ( D i v i s i b i l i t y ) Each coin should be divisible. | ( O f f - l i n e ) Payment should be executed in an off-line manner. 9 ( T r a n s f e r a b i l i t y ) A divided sub-coin should be transferred between users. Previous results

Recently some "escrow" (or "fair") schemes were proposed to reach compromise between privacy and social safety. B r i c k e l L G e m m e l l a n d K r a v i t z [3] proposed a cash scheme in which user's privacy is guaranteed except for when two trustees cooperate to trace user's spending. C a m e n i s c h , P i v e t e a u a n d S t a d l e r [11] proposed a cash scheme by using their blind signature scheme ("fair" blind signature scheme) [28], in which a blindly signed message is anonymous except for when a trustee helps the signer to trace a blindly signed message. However, these previous schemes have the following problems: -

-

In the B r i c k e l l - G e m m e l l - K r a v i t z scheme [3], given the criminal's identity (name), the trustees can trace the payment histories of this criminal (i.e., C r i m e p r e v e n t i o n 1). However, given a payment history, the trustees cannot efficiently trace the payer's identity of this payment history (i.e., N o c r i m e p r e v e n t i o n 2). If trustees do many trials exhaustively to obtain the correct identity, they can trace the payer's identity from the payment history, but the trustees also get the private information of many users other than the targeted user through this exhaustive trial procedure. If a secure computation protocol is used [4, 5, 19, 20], a protocol that reveals no additional information can be constructed, but it is very inefficient. in the C a m e n i s c h - P i v e t e a u - S t a d l e r scheme [11], the number of trustees is just one. Although the extension of their scheme to a multi-trustee type may be easy, the property of our schemes in their paper [11] does not seem to be preserved (i.e., N o c r i m e p r e v e n t i o n 2). T h a t is, a cash scheme based on the multi-trustee version of their scheme seems to have the same problem as the above-mentioned problem of the Brickell-Gemmell-Kravitz scheme.

35

-

In the B r i c k e l l - G e m m e l l - K r a v i t z scheme, all trustees should be honest. If at least one trustee does not collaborate in tracing user's privacy, they can trace nothing (i.e., No robustness in C r i m e p r e v e n t i o n 1). - The B r l c k e l l - G e m m e l l - K r a v i t z scheme has no divisibility property under off-line payment condition (i.e., No divisibility). Both B r l c k e l l - G e m m e l l - K r a v i t z and C a m e n i s e h - P i v e t e a u - S t a d l e r schemes do not technically protect against extortion attacks [30] (i.e., No C r i m e p r e v e n t i o n 3).

1.3

Our results

This paper proposes two practical escrow cash schemes, Type I and Type II, with the following properties: - ( P r i v a c y p r o t e c t i o n ) In Type I, the privacy of users is preserved, unless all trustees collaborate. In Type II, the privacy of users is preserved, unless a certain portion of the trustees collaborate. (Note that partial privacy information may leak and the amount of leakage is in proportion to the number of collaborated trustees.) ( C r i m e p r e v e n t i o n 1) In Type I, if all trustees collaborate (for law enforcement or crime prevention), given the criminal's identity (name), the collaboration can trace the payment histories of this criminal. In type II, if a certain portion of trustees collaborate, given the criminal's identity (name), the collaboration can trace the payment histories of this criminal. ( C r i m e p r e v e n t i o n 2) In Type I, if all trustees collaborate (for law enforcement or crime prevention), given a payment history, the collaboration can trace the identity of this payer. In Type II, if a certain portion of the trustees collaborate, given a payment history, the collaboration can trace the identity of this payer. ( C r i m e p r e v e n t i o n 3) In both Types I and II, partial technical protection against extortion attacks is possible. ( S e c u r e off-line d i v i s i b l e cash) In both Types I and II, each coin is divisible under the off-line payment condition, although sub-coins divided from the same coin are linkable. (Note that each coin and sub-coin are anonymous i.e., untraceable.) -

-

1.4

Our techniques

The previous "escrow" cash schemes are all constructed by incorporating the key-escrow concept into the already-known anonymous cash schemes (the keyescrow concept is originally to force each user to share his (secret) key into the multi-trustees and, if necessary, to restore the (secret) key from the user's name). Those combined schemes use the mathematical mechanism to trace overspenders and use the key-escrow mechanism to realize Crime prevention 1.

36 In our paper, some techniques are introduced to realize Crime preventions, 1 and 2, simultaneously (roughly two types of technique, sequential and parallel approaches). These techniques can also be utilized to detect over-spenders (the techniques against Crime 2 and against over-spending can be shared). Then, we can much more easily construct an escrow cash scheme because we don't have to make any complicated number-theoretical mechanism to trace over-spenders. Moreover, divisibility and transferability can be very easily realized in our approach, while a lot of mathematical techniques are required in the previous approach. In order to realize Crime prevention 3, we require each customer to register a cash identifier to multiple centers in a secret sharing manner. The registered identifier can be used to recognize legal coins from illegally obtained coins.

1.5

Organization of this paper

In Section 2, we introduce a naive escrow cash scheme constructed by applying Pedersen's VSS scheme [26] to an unconditionally anonymous cash scheme[24], and also show the problems this scheme has. In Section 3, we describe a basic framework of our two proposed schemes, Types I and II. These two schemes share a withdrawal, a payment, a deposit and a transferring protocol in the basic framework, but the registration protocols are specified differently. In Section 4 and 5, two registration protocols are proposed: Type I is a sequential execution version of multiple trustees, and Type II is a parallel execution one. In Section 6, we consider the efficiency. In Section 7, we give some open problems.

2

A Naive C o n s t r u c t i o n Using VSS

In this section, we will show that a naive escrow cash scheme can be easily constructed by incorporating Pedersen's "Verified Secret Sharing" [26] into [24], and that such a naive system has some shortcomings.

2.1

The Protocol

In [24], customer U must register gP(modt/), and gQ(mo&]), where P Q = N, on the list of bank B ( If over-spending occurs, 29 can compute the factorization of N using the mathematical properties behind it, and identify U by calculating gP and gQ). Our naive construction institutes t trustees, T1, 9 Tt, and before "the opening protocol" described as in [24], the registration protocol runs among a customer and trustees for the purpose of secret-sharing P and Q in the manner of Pedersen's VSS[26].

37 The actual protocol is as follows: 1. Customer U selects two polynomials of degree k over prime field Zr, p(x) and q(x), such that p( x ) = P + pl z + . . . + p k - l x k - t rood r q(x) = Q + qlx + . . . + qk-lX k-1 mod r, where r > P, Q, k __
(mod ~])

gq(i) = (gO)(gq~)i...(gq~_~)i k-~

(mod~).

Trustees accept that P and Q are surely secret-shared among them if they all succeed in the verifications, If so, they send gP and g0 to B with their signatures. 3. B permits U to execute :'the opening protocol" using gP and 9 0. Given the criminal's identity, i.e. {gP, g0}, from the property of secret sharing, the trustees can trace his payment history if and only if more than k trustees cooperate. 2.2

Shortcomings

This scheme is almost as efficient as [24], but it has two problems as escrow cash system. 1. As with the Brickell-Gemmell-Kravitz scheme [3], given a payment history, the trustees cannot efficiently trace the payer's identity (i.e., No crime prevention 2). 2. If an illegal payment occurs such as over-spending, it is impossible for a third party to judge whether either case is true; the suspected user actually overspent or the false payment was created by trustees' conspiracy, because the collaboration of more than k trustees can extract user's secret key {P, Q}. In the following sections, we will show that our proposed schemes, Types I and II, overcome these problems.

3

The

Basic

Framework

In this section, we describe the common basic framework of our proposed schemes, Types I and II. The basic framework consists of r e g i s t r a t i o n , w i t h d r a w a l , p a y m e n t , dep o s i t , and t r a n s f e r r i n g protocols. In the r e g i s t r a t i o n p r o t o c o l , customer U secretly generates the RSA modulus, N, and the corresponding secret exponent d, and then U registers N to

38 multiple trustees, T = (Tz,..., Tt), and gets license, L, from T. (Of course, the relation between customer U and his RSA modulus N must be secretly preserved unless at least a certain portion of trustees collaborate.) In the w i t h d r a w a l protoeol, customer U withdraws coin C from bank B. Customer U pays coin C along with (N, L) at shop V through the p a y m e n t protocol. Finally, shop V deposits the payment to bank B (the deposit protocol). In addition, customer U1 can transfer coin C to another customer U2 by using the t r a n s f e r r i n g protocol. Trustees' signature of message N, ST(N), is a kind of the multiple signature by multiple trustees, T. S is a "valid" trustees' signature for message N if and only if VT(N, S) = 1, where VT (., .) is the signature verification procedure. (ew, n~) denotes a RSA public key of bank B, which corresponds to w dollars. (e, N) corresponds to the customer's public key, although N is kept secret by the customer (e is assumed to be commonly shared in the system). (Ei('), Di (')) denotes a public-key cryptosystem of Ti. E~ o Ej(N) denotes E~(ES(N)). Notation:

R e m a r k : The trustees' signature scheme (ST,VT) is an arbitrary signature scheme in Type I and the RSA scheme in Type II. This paper uses the RSA blind signature scheme [7] for the bank's signature but it is possible to substitute any other blind signature scheme (See [22]). We also adopt the RSA scheme for customer's signature, but it can be replaced with any other signature scheme. 3.1

The Registration Protocol

Customer U secretly generates the RSA modulus, N, and the corresponding secret exponent, d, then, registers N to multiple trustees, T = (Tz,..., Tt), and gets license, L, from T. Speaking more about this, in Type I, U anonymously sends N to Tt through T1,..., Tt-1 by using Mix net scheme [6], and gets Tt's signature, Lt, by using Mix in the converse direction. And, in Type II, U gives shares bl, 9 9 bt of N to T z , . . . , Tt, and obtains all trustees' signature L1, ..., Lt. In case of Type I, L = Lt and L = (L1,..., Lt) in case of Type II. In Section 4 and 5, we will describe these protocols in further detail. 3.2

The Withdrawal Protocol

When customer U wants to withdraw Sw from his account, U may obtain electronic coin C worth Sw by executing the withdrawal protocol with bank B. In the withdrawal protocol, B issues a blind signature to U for U's public key, N, and the coin number, )~, the disjoint parts of which are registered in all trustees by using the standard sharing technique [27]. 1. U chooses random value A, and selects a polynomial, A(x), of degree k over the prime field Fr, such that A(x) = ),+ Azx + . . . + Ak-lx k-z mod r, where 0 < A < r and k _< t. U computes EI(A(1)),...,Et(A(t)).

39 U then forms and sends Z ~.o B with El(A(1)),..., Et(k(t)):

Z = 7 ~ H ( N 11A) mod n~,, where 7 E Zn~ is a random integer. 2. B gives W = Z 1/~ mod n~ to U and charges U's account Sw. Moreover, B sends Ei(A(i)) along with the withdrawal value, Sw, to T~. 3. U can then extract the electronic coin

C : W/7 mod n~, : (H(N II/~))l/ev~ rood n~. 4. Each T~ stores A(i) along with w in their database (A-Database) after deciphering Ei(a(i)). N o t e 1: Ei(A(i)) can be sent to Ti in an off.line manner. ( e.g. once a day. ) N o t e 2: A is used for Crime prevention 3 ( See 3.6 ). 3.3

The Payment Protocol

Assume that customer U spends Sy (_< w) at shop V through the payment protocol. The payment protocol consists of two stages: authentication and user's signature. 1. U sends (y, N, L, A, C) to V. 2. V checks y _< w, and verifies the validity of the signatures, L and C, such that VT(N,L) = 1 and C ~ = H(N I] A) (mod n~). If they are all valid, V sends time, r, and V's identity, IDv, to U. Otherwise, V halts. 3. U computes and sends V a signature S corresponding N such that

S = H(y II IDv I] r) d mod N. 4. V accepts (y II IDv I1 r) and S, as a valid Sy payment if the following equation holds:

Sr 3.4

[Iv)

(moaN).

The Deposit Protocol

Shop V sends the payment transcript, (y, N, L,A, C, IDv,r, ,5'), to bank B in order to deposit $y. If U over-spends coin C, bank B should receive transcripts, (yi, N, L, A, C, IDi, r.i, Si)'s, where ~ i Yi > W. Then B requests trustee T to reveal the dishonest customer behind N by showing the transcripts as evidence. For more detail of revealing the dishonest customer, see 4.2 in Type I, and 5.2 in Type II. Here note that such transcripts that U over-spent C cannot be forged by anyone other than U.

40 3.5

The Transferring Protocol

When customer U1 wants to transfer $9 (_< w) to customer U2, U1 executes the transferring protocol with U2. The protocol is the same as the payment protocol except for substituting a shop's ID, VID, by U2's public key, N2. The transferred coin is (y, N1, L1,11, C, N2, rl, $1). $1 is the signature which shows that an anonymous customer N1 transferred $ y to an anonymous customer N~. When U~ pays $ z to V using the transferred coin, before V gets the signature of Nu, S; =- tt(z II IDv II r) d= rood IV2, V checks the validity of (y, N2, rt, $1) in addition to the annual check of (N,, L~, A~, C). V accepts (y, Nu, q , ,51) if y _< w

and 3.6

=_ g ( y II N2 II n) rood T h e D e t e c t i o n P r o t o c o l ( C r i m e p r e v e n t i o n 3)

If trustees' or bank's secret keys are forced to be revealed to a criminal through extortion or kidnapping, then trustees can collaborate to recover A values (coin numbers) of all issued coins ( if more than k trustees are honest, the recovering succeed ). These recovered values are stored in A-Database. Then an on-line check procedure must be executed in addition to the usual payment protocol. In this additional on-line check procedure, all the A values sent from shop V are checked whether they are already stored in A-Database or not. If a A of a coin, C, is not stored in ),-Database, it is rejected as a forged coin (i.e. the payer may be arrested). If a coin is fully spent, the corresponding A-value is removed from ),-Database. Such an on-line check procedure is a temporary emergency measure, and is executed with a limited term (emergent key-replacement term) before almost all coins are replaced by those with new bank's (and trustees') keys. After the emergent key-replacement term, new coins with new bank keys can be spent in an off-line manner, but old coins with old bank keys are still required to be spent in an on-line manner. N o t e : Even if customer U sends invalid shares of t to trustees in the withdrawal protocol, it is to U's disadvantage and there is no merit for U. Therefore, it is not necessary to check the validity of the shares of t.

4

Proposed

Escrow

Cash

Scheme,

Type

I

In this section, we propose the Type I cash scheme. We only show the registration protocol of Type I because the other protocols of it have already been described in Section 3. This registration protocol of Type I is a kind of bi-Mix net: U anonymously sends a secret N to Tt through 7'1,...,Tt-1 by using Mix net scheme [6], and gets Tt's signature, Lt, by using Mix in the converse direction. Notation:

(gk('), Dk(-)) denotes

a

cryptosystem for the secret-key k.

41

4.1

The Registration Protocol

Customer U secretly generates the RSA modulus, N, and the corresponding secret exponent d. The registration protocol between U and (T1,..., Tt) is the following: 1. U picks (kl,...,kt), and reeursively computes ct such that, for 1 < i < t, c~ = E ~ ( k ~ l l c ~ - l ) , where co := IDu (IDu means U's identification). U also computes C1 = E1 o . . . o Et(Nllct). U sends C1 with U's signature to T1. 2. For 1 < i < t, T/ checks the Ti_l'S signature and deciphers Ci+l = Di(Ci), where To := U. T/ sends Ci+l with Ti's signature to T/+I. 3. Tt checks the Tt-l's signature and obtains N, kt, and ct-1, since (Nllct) = Dt(Ct), a n d (kt[lct-1) = Dt(ct). Tt calculates the signature, L, for N and sets Et = s Tt sends (ct-~, Et) with Tt's a signature to Tt-1. 4. In case that 1 < i _< t - 1, Ti checks the T/+l's signature and deciphers (kiltci-1) = Di(ci). Ti calculates Ei = gk~(Ei+l) and sends (ci-1, El) with T/'s a signature to T~._1. 5. T1 checks the T2's signature and deciphers (kl[llDu) = D1 (cl). T1 calculates E1 = gk~ (EB) and sends E1 with Tl's a signature to U. 6. U computes and obtains L =/?k~ o...o~gk~ (~1) (since ~1 = gk~ o...og~(L) ) after checking the Tl's signature.

4.2 T h e D e t e c t i o n P r o t o c o l ( O v e r - s p e n d e r d e t e c t i o n , C r i m e p r e v e n t i o n s , 1 a n d 2) Obviously, through the collaboration of all the trustees, they can trace the criminal's identity from a payment history and vice versa..

5

Proposed

Escrow

Cash

Scheme,

Type

II

In this section, we propose the Type II cash scheme. We only show the registration protocol of Type II because the other protocols of it have already been described in Section 3. The outline of the registration protocol is the following: Customer U sends each trustee T~ a part of knowledge of N, hi(= 9 N modpi), where N can be specified if a certain portion of {bi}~=l is collected, and requests the trustees to give a blind signature of N, after proving that customer's public key N is surely behind the blinded object, Nr 3, and bi. In the following subsections, we present our proposed registration protocol between U and T~-, and we present how to trace the payer's identity ( or the payment history ) from the payment history ( or the payer's identity ), through the collaboration of the trustees.

42 5.1

T h e Registration P r o t o c o l

In this registration protocol, we use the Bit Commitment Scheme introduced in [24]. Let rj, C, G, and g be those defined in Appendix A. (3, Hi, ai) and (di, Hi) are respectively RSA public and secret keys of trustee T/ (1 < i <_ t), where 21nil + 6 < for any i. In addition, each trustee T/ has the pair (gi,Pi), where p/ is a prime, and gi be a element of small order, 61, (e.g. several bits) in the multiplicative group Z~,; g~ -- 1 (rood pd. Customer U executes the registration protocol with all of trustees, T1, .., Tt, in order to get license L, which is a set of trustees' signatures (L1,... Lt), such that Li = (N + ai) di mod nl. The registration protocol between U and Ti is as follows: 1. U generates random numbers in Zr ~N, (r, ~", ~ " and r. U computes and sends T/ all the following numbers: =

r

rood

r" =

r

mod

x =

BC

(

N, N ) ,

y =

y' =

BCg(~,, r'), y" = BCg(~,,, r"), s = (N + ai)r a mod Hi, bl = g N m o d p i , and SigH(hi), where Sigh is U's signature. 2. U executes the CHECK MOD-MULT protocol with T~ for (y, y', n~,[n~, 2n~]) to prove the relation of the committed numbers r and r ~, such that

r ' = r ~ ( m o d n i ) a n d r , r rE[0,3ni]. 3. U executes the CHECK MOD-MULT protocol with T~ for (y, y', y", n~,[n~, 2n~]) to prove the relation of the committed numbers r, r ~ and r ' , such that

r" =_ rr'

(rood ni) and r, r', r" E [0, 3nil.

4. U executes the CHECK MOD-MULT protocol with T~ for (xg ~ , y", BCg(O, s), ni,[ni, 2nil) to prove the relation of the committed numbers N and r ' , such that s= (N§ ( m o d n i ) a n d s , r H , ( N + a i ) E[O,3ni]. 5. U executes the COMP. DIFF. ORDER. protocol (see below) with T/ for (x, bi,[(1/4)ni, (1/2)ni]) to prove the following relation of the committed number N: b~ = gN mod Pi and N E [0, (3/4)ni]. T~ stores (b~, Sigu(b~)) as U's shared identity in his secret list. 6. Ti computes O = s 1/a mod ni and sends to U. 7. U obtains Li = (N + al) 1/a rood ni by calculating O / r rood ni. Protocol: C O M P . D I F F . O R D E R . Let the commitment BCg(., .), I, and e be those defined in Appendix A, and (9i,Pi) be the same as that in 5.1. C o m m o n i n p u t : x, bi and (rl, G, g, Pi, 9i, I). W h a t to prove: U knows (/t, N) such that x = BUg(R, N), b~ = gin mod p~ and s E I:t: e.

43 Execute the following k times: 1. U chooses tl uniformly in [0, e], and sets t2 = tl - e. U sends to V the unordered pair of commitments (T1, T~), (T2, T~), where each component of the pair is ordered and (Tj, %') = (BCg($j,tj),g~ j mod pi). 2. V selects a bit t3 C {0, 1} and sends it to U. 3. U sends to V one of the following: (a) if fl is 0, opening of both (T~, T{) and (T~, T~), i.e. $1, $2, t~, t2. (b) if/3 is 1, opening of x . 2r) rood q and x' 9 T3~.mod Pi (J E {1, 2)), i.e. y j ( = N + tj), R j ( = R + @), such that N + tj E l . 4. V checks the correctness of U's messages. 5.2 T h e D e t e c t i o n P r o t o c o l ( O v e r - s p e n d e r d e t e c t i o n , C r i m e p r e v e n t i o n s , 1 a n d 2) In case of tracing the payment history from the criminal's identity, e.g. Alice (Crime prevention 1), trustees reveal Alice's shared identity bi respectively, and can search all the payment transcripts stored in bank B using the relation of bi = g N rood pi ( C r i m e p r e v e n t i o n 1). In the opposite case, that is, tracing a criminal from the payment history ( O v e r - s p e n d e r d e t e c t i o n a n d C r i m e p r e v e n t i o n 2), the following protocol runs for all suspects: T h e M u l t i P a r t y Version: Let 2P~ be a subset of T with c trustees (say T~ = {TI,...,T~}, where c < t. Trustees draw lots and decide 2F~ in advance. 1. T~ computes bi = gN rood pi from N in the payment history, sets xi = 1 if Alice's shared identity is bi, and sets xi = 0, otherwise. Next, T/ divides the bit xi(E Z2) assigned to Alice into c pieces, such that x~ = x(i,1) + " " + x(i,~)

(rood 2),

where x(i,l) E Z2, and sends each one bit x(i,l) to each trustee Tl (1 < l < c). This is done by all trustees {T/}~=I and each T/ obtains (x(1,i),..., x(~,r 2. They can calculate, x l A . . . , \ x~ = l~I ~ x ( k , l ) rood 2, k----1 /----1

but never reveal any more information of x(k,l) except for the result of the calculation, by using the secure computation protocol described as in [4, 5, 19, 20]. (See pp.14V-153 in [20].) This protocol is repeatedly used for other suspects. N o t e : Let v~ = I]i=15i, and s be the number of suspects. - Suppose that vr >> s. Then, this protocol by 55~ outputs '1' if Alice is the target, and outputs '0' with the probability P = (1-1/vr ~ ~ 1 - s / v r otherwise. Here, this estimation is clone under the assumption that b = gN rood p distributes uniformly over the subset, {g~ rood p ] 0 < x < ord(g)}.

44 - If some trustees are dishonest, the output may be false. However, since the correctness of the result can be checked later, the correct result can be obtained with high probability by selecting an appropriate 2r~ if the number of honest trustees is more than c. - Example: if s = 220 , t = 20, c = 10, and 5i ~ 2a then v~ ~ 23o and P = (1 - 1 / 2 3 ~

1 - 1/21~

The protocol mentioned above is efficient for one suspect, but if the number of the suspects is large, the total amount of the computationM and communication complexity is fairly large. In the following, we show a practicM modification of this procedure to improve the efficiency. T h e Practical Version: First, trustees decide the group, 2~, and a collector Tj by lots. Then, every Ti in 3~, prepares a list of suspects, ( @ ) , . . . , b}~)), where a j of bi (j) points a same suspect in common with each ~ .

1. Ti E 2~ picks a cyclic permutation, ~rl, at random and computes bi = g N mod Pi. Then, Ti makes the row, Xi = ( x l t ) , . . . , xl~)), where xl j) = l if the shared identity, blj) , is equal to b.i and x~j) = 0 otherwise. 2. Ti calculates zri(Xi) and sends it to Ti+l. It returns to Ti when all of 2r~ permute once. Of course, T~: also permute for others by 7ri. 3. Ti sends it to the collector, Tj. 4. Tj calculates l-[~=l 7rl o . - . o ~r~(Xi). Then, Tj randomly sends the result to 5. T~ selected by Tj operates the inverse permutation, zri-1 on the result and sends it to ~+1. It returns to Tt when all of 5~ do the inverse permutation once.

6. Tz publishes the result of inverse permutations. 6

Consideration

Comparing two schemes, Type I is obviously more effcient than Type II. Moreover, Type I can be constructed by only using an arbitrary signature, an arbitrary public-key cryptosystem, and an arbitrary blind signature scheme (see also [22] that shows other blind signature schemes than RSA). However, Type II has two good properties Type I doesn't have: If a.t most one of the trustee refuse to collaborate in the detection protocol, trustees couldn't trace anything in Type I (No robustness in Crime preventions, 1 and 2) . Type II doesn't have a threshold but a certain portion of the collaboration of trustees could trace the relation between a criminal and a payment history. In addition, in Type II, every trustee has an equal chance to play every role, while~ in Type I, the trustees, T1 and Tt, always play the special roles. Our proposed schemes, especially Type I, would be the most efficient and simple even if comparing with any previous escrow cash scheme[3, 28] or any unconditionally anonymous scheme [1, 9, 15, 17, 22, 23, 31].

45

7

Conclusion and Open Problems

This paper proposed two practical escrow cash schemes, Types I and II, that overcome the problems of the previous and the naive escrow cash schemes. There remain several open problems below: - Introduce the threshold property in the number of collaborating trustees in Type I. - Improve the efficiency of the tracing procedure by the collaboration of trustees in Type II. Find a fully technical protection against extortion attacks. - Realize unlinkability among sub-coins divided from the same coin. -

References l. Brands, S., "Untraceable Off-line Cash in Wallet with Observers", Proceedings of Crypto 93, pp.302-318 (1994). 2. Brands, S., "Restrictive Blinding of Secret-Key Certificates", Proceedings of Eu_rocrypt 95, pp.231-247 (1995). 3. Brickell, E., Gemmell, P., and Kravitz, D., "Trustee-based Tracing Extensions to Anonymous Cash and the Making of Anonymous Change", Proceedings of SODA95, pp. 457-466. 4. Ben-Or, M., Goldwasser, S., and Wigderson, A., "Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation", Proceeding of STOC88, pp 11 17. 5. Chaum, D., Crepeau, C., and Damgs I., "Multiparty Unconditionally Secure Protocol", Proceeding of STOC88, pp 1-10. 6. Chaum, D., "Untraceable Electronic Mail, Return Address, and Digital Pseudonyms", Comm. of the ACM, 24, 2, pp.84-88 (1981). 7. Chaum, D., "Blind Signatures for Untraceable Payments", Proceedings of Crypto 92, pp.199-203. (1992). 8. Chaum, D., "Security without Identification: Transaction Systems to Make Big Brother Obsolete," Comm. of the ACM, 28, 10, pp.1030-1044 (1985). 9. Chaum, D., Fiat, A., and Naor, M., "Untraceable Electronic Cash," Proceedings of Crypto 88, pp.319-327 (1990). 10. Camenisch, J., Piveteau, J., and Stadler, M., "Blind Signatures Based on the Discrete Logarithm Problem", Proceedings of Eurocrypt 94, pp. 428432 (1994). 11. Camenisch, J., Piveteau, J., and Stadler, M., "An Efficient Fair Payment System", Proceedings of 3rd ACM Conference on Computer Communications Security (1996). 12. Damgs I., "Practical and Provably Secure Release of a Secret and Exchange of Signatures," Proceedings of Euroerypt 93 (1993). 13. D'amingo, S. and Di Crescenzo, G., "Methodology for Digital Money based on General Cryptographic Tools", to appear in the Proceedings of Eurocrypt 94. 14. De Santis, A. and Persiano, G., "Communication Efficient Zero-Knowledge Proofs of Knowledge (with Applications to Electronic Cash)" Proceedings of STACS 92, pp. 449-460 (1992).

46 15. Eng, T. and Okamoto, T. "Single-Term Divisible Coins," to appear in the Proceedings of Eurocrypt 94. 16. Ferguson, N., "Single Term Off-line Coins", Proceedings of Eurocrypt 93, pp.318-328 (1994). 17. Franklin, M. and Yung, M., "Secure and Efficien~ Off-Line Digital Money", Proceedings of ICALP 93, pp. 449-460 (1993). 18. Goldwasser, S., Micali, S. and Rivest, R., "A Digital Signature Scheme Secure Against Adaptive Chosen-Message Attacks," SIAM J. Comput., 17, 2, pp.281-308 (1988). 19. Goldreich, O., Micali, S. and Wiederson, A., "How to play any mental game", Proceedings of STOC87, pp. 218-229. 20. Goldreich, O., "Foundations of Cryptography", Class Notes, Spring 1989. 21. Hayes, B., "Anonymous One-Time Signatures and Flexible Untraceable Electronic Cash," Proceedings of Auscrypt 90, pp.294-305 (1990). 22. Okamoto, T., and Ohta, K., "Disposable Zero-Knowledge Authentication and Their Applications to Untraceable Electronic Cash", Proceedings of Crypto 89, pp. 481-496 (1990). 23. Okamoto, T., and Ohta, K., "Universal Electronic Cash", Proceedings of Crypto 91, pp. 324-337 (1992). 24. Okamoto, T., "An Efficient Divisible Electronic Cash Scheme", Proceedings of Crypto 95, pp. 438-451 (1995). 25. Pailles, J.C., "New Protocols for Electronic Money", Proceedings of Auscrypt 92, pp. 263-274 (1993). 26. Pedersen, T. P., "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing", Proceedings of Crypto 91, pp. 129-140 (1992). 27. Shamir, A., "How to share a secret '~, Communications of the ACM, v.24, n.ll, Nov 1979, pp. 612-613. 28. Stadler, M., Piveteau, J., and Camenisch, J., "Fair Blind Signature", Proceedings of Eurocrypt 95, pp. 209-219 (1995). 29. Vaudenay, S., "One-Time Identification with Low Memory," Eurocodes 92 (1992). 30. yon Solms, S., and Naccaehe, D., "On Blind Signatures and Perfect Crimes". Computer and Security, 11 (1992) pp 581-583. 31. Yacobi, Y., "Efficient electronic money", to appe&r in the Proceedings of Asiacrypt 94.

47

A

Bit Commitment

Protocol

This protocol was proposed in [24I. V sets up the commitment scheme and U commits to a number. Finally U proves to V that a value is correctly generated without revealing committed information, by using some protocols to be described later. To set up the commitment scheme, V generates prime r; satisfying ~ - 1 = 2.r (r is a prime number), and G and 9 whose orders in the multiplicative group Z~ are r V sends r;, G and g. U checks whether r = (~? - 1)/2 is a prime by a probabilistic primality (or composite) test, and whether the orders of G and g are ~ by checking that they are not 1 and G r - 1 ( m o d e ) and gr = 1 (mod r;). U can commit to any integer s E Zr by choosing R uniformly at random in Z C and computing the commitment

BCg(R, s) = GRg ~ rood r]. This is called base-g commitment. A commitment is opened by revealing/{ and S.

U can prove to V in a zero-knowledge manner that a committed value is in an interval, and that two committed values are equivalent. Let the interval be [ = [a,b] (= {xla <_ x <_ b}), e = b - a, and I • e =

[a-e,b+e]. Protocol: C H E C K C O M M I T M E N T C o m m o n input: x and (~7,G, g, I). W h a t t o p r o v e : U knows (R, s) such that x = BCg (R, s) and s E I =t=e. Execute the following k times: 1. U chooses tl uniformly in [0, e], and sets t2 = tx - e. U sends to V the unordered pair of commitments T1 = BCg(Sx, tl), l) = BCg(S2, t2). 2. V selects a bit/9 E {0, 1} and sends it to U. 3. U sends to V one of the following: (a) if/9 is 0, opening of both T1 and T2 (b) if/9 is 1, opening o f x . T / m o d ~ (i C {1,2}), such that, s + t i C I. 4. V checks the correctness of U's messages.

Protocol: C O M P A R E C O M M I T M E N T S Let h be a element in Z~ with the order C. C o m m o n input: x, x ~ and (~],G,g,h, f). W h a t t o p r o v e : U knows (R, R', s) such that x = BCg(R, s), x' = BCh(R', s) and s E 1-4- e. Execute the following k times: 1. U chooses tl uniformly in [0, el, and sets t2 = tl - e. U sends to V the unordered pair of commitments (T1, T~), (T2, T~), where each component of the pair is ordered and (T/, T/~) = (BCg(Si, ti), BCh(S~, ti)).

48 2. V selects a bit/~ E {0, 1} and sends it to U. 3. U sends to V one of the following: (a) if/? is 0, opening of both (T~, T~) and (T2, 2T~) (b) if/3 is 1, opening of x . T / r o o d 77 and x ' . T[ rood ~ (i E {1, 2}), such that s+tiE

I.

4. V checks the correctness of U's messages. Protocol: CHECK MOD-MULT C o m m o n i n p u t : x, y, z, n and (~, a , g , z = In, 2hi). (l(il >_ 2tnt + 6) W h a t t o p r o v e : U knows (R, .R',/~", s, t, c~) such t h a t x = BCg (I~, s), y = B C g ( R ' , t ) , z = B C g ( R " , a ) , c~ - st (mod n), and s , t , a E [0, 3n](= [ 4-n). 1. U uses the C H E C K C O M M I T M E N T protocol with I = In, 2n] to prove t h a t U knows how to open x to reveal a value in [0, 3n] (= 1 4- n). 2. U sends v = B C x ( R ' " , t ) = B C g ( R ' " + t R , st), and uses the C O M P A R E C O M M I T M E N T S protocol with I to prove that U knows how to open y = B C g ( R , t ) and v : B C x ( ~ ' " , t ) .

3. U sends u = B C g ( R ' " ' , d ) , where d is defined by st = a + dn, c~ =_ st (rood n), and s, t, c~ E I. 4. U uses the C H E C K C O M M I T M E N T protocol with In - 1, 4n - 1] to prove t h a t U knows how to open ~ to reveal a value in [ - 2 n - 1 , 7 n - 1] (= In - 1, 4n - 1] 4- 3n). U uses the C H E C K C O M M I T M E N T protocol with I to prove that U knows how to open z to reveal a value in 1 4- n. 5. U opens (as a base-g commitment) the product zunv -1 rood rj to reveal a 0 (i.e., reveals R* such that B C g ( R * , O) = zu~v - : rood rt).

NetCard

--

A Practical Electronic-Cash

System

Ross Anderson, Charalampos Manifavas and Chris Sutherland Compu~;er Laboratory, Pembroke Street, Cambridge CB2 3QG

1

Introduction

Over the last ten years or so, there have been a number of proposals for electronic cash systems, which let a customer make a payment to a merchant over a computer network by sending messages called 'digital coins' w h i c h t h e merchant can redeem for value (see, e.g. [8], [9]. These coins m a y be managed using a t a m p e r resistant 'electronic wallet': such systems have already been introduced in a number of countries to meet specific local requirements [1]. Recently, a likely international standard has emerged from VISA and MasterCard; their Secure Electronic Transaction [SET] protocol will facilitate credit card transactions on the Internet. However, an electronic credit card system, such as SET, will suffer from relatively high transaction costs. Not only is the system overlaid on the existing credit card legacy infrastructure, but it will also function in the same commercial framework. Banks worldwide have developed an intricate system of contractual relationships that determine how much money will be paid for processing each transaction, and these costs are geared to transactions in the tens to hundreds of dollars. Thus although SET will be economic for payments in this range, it will be less so for the smaller payments needed for m a n y network services. The digital analogues of stamps and phone tokens - ' m i c r o p a y m e n t s ' - - will need different treatment, and we discuss some options here. The application that first motivated us was electronic publishing. When we wish to read an article from a journal that is not in the local libraries, we currently have to buy an annual subscription. This is usually so expensive that we explore alternatives, such as writing to the author for a preprint. It would probably be much better for all concerned if we could just buy the pages of interest. So we set out to provide a mechanism whereby journals could be sold electronically, with a page charge as an alternative to an annual subscription. Other examples are video-on-demand, other fast network services, computer facilities, road tolls and utility meters [AB]. In all of these applications, a customer makes a series of small payments to the same vendor. As time passes, more complex applications will emerge. For example, we m a y wish to rent a video from a shop in Los Angeles to watch in Cambridge. This could involve simultaneous payments to the video store for the content, and to a network service provider to pay for the bandwidth. However the principle is the same; we are still making a series of low value payments to a merchant. We are simply running two such processes at once.

50 We therefore set out to design a system for repeated small payments. We did not want to force either the customer or the merchant to buy expensive hardware, and we did not want to add significant extra load to the existing legacy banking systems, as computing and network costs typically make up the largest part of a bank's non-interest expenditure. We believed, when the project started in Jnne 1995, that we would have to support the same levels of offline operation as in existing cheque and credit card systems.

2

Concept

In many previously proposed electronic cash systems, the customer purchases a number of electronic coins from a bank and spends them with one or more merchants. The merchants can then redeem the coins with the bank. The coins typically involve some kind of digital signature, which means that at least one modular exponentiation is required to process each coin. Our key innovation is that, instead of having to do a digital signature each time she spends a coin, the customer can sign a whole stick of coins at the same time. She can then pull the coins off the stick one by one and present them to the merchant, who is able to check that each coin was one of the stick signed by the customer. He only has to perform one signature verification per customer, even when she spends a whole lot of coins. In the first version of our system, which we shall describe next, the coins are still generated by the bank. However this requirement can be relaxed, and some or all of the coins generated by the customer, which gives additional benefits - - for example, she can create coins in any denomination, and indeed in any currency, that she requires. These protocols, and their security properties, will be described in succeeding sections. Finally, we shall discuss the lessons learned about the relationships between local and global trust.

3

Initial Design Assumptions

The first protocol was designed on the assumption that in order to control ne~work and processing costs, small transactions would not be authorised online to the bank. One of the lessons learned from current online payment systems is that maintaining the 99.99% availability needed by retail customers is very expensive. It means not just multiple redundant backup of computer and communications facilities, but also sizing systems for peak traffic - - typically l p m on the Saturday before Christmas. But if stand-in processing is possible, then outages and traffic peaks can be dealt with by placing some traffic ofttine at a fairly predictable cost in fraudulent and over-limit transactions. In this scenario, however, there needs to be a mechanism to prevent double spending by customers. The approach adopted in the UEPS system [And1] was

51

to issue each customer with a smartcard based electronic wallet, and in our first protocol we assumed that this would be favoured by the industry. The problem with srnarteards is that one can either have a universal secret that is present at least in merchants' cards, or use public key cryptography. In the former case, criminals might reverse engineer the card [BFLAR] and extract the keys using chip testing techniques [Wie]. Systems such as UEPS control this risk by having centralised reconciliation and fraud detection systems, together with a fali-back processing mode similar to current credit card operations. The effect is that a capable motivated opponent would be better off spending his resources attacking the legacy credit card system. We set out to follow the second route and use public key crypto. An important reason for this was that the second and third authors are funded by the NetCard project, a D T I / E P S R C initiative to develop payment mechanisms for high speed networks, and one of our industrial partners in the project is developing a publickey capable smartcard. However we still want the smarteard to do as little public key crypto as possible - - at most one signature for each series of transactions between a customer and a merchant.

4

First

Protocol

In our first protocol, the customer first chooses a pseudonym P and generates a pair of keys with K P - 1 being her private key and K P her public key. The bank then creates a certificate with its name B, an expiry date e, the customer's credit limit $, her pseudonym P and her public key K P , all signed using the bank's key K B -1. Using the symbolism of [AN]:

C P = {B, e, $, P, KP}KB-1

(1)

For simplicity's sake we will first consider that the digital coins are all for the same amount. They are 64 bit strings constructed by encrypting a serial number and some redundancy under a secret key selected by the bank. Different keys are chosen for each customer pseudonym P, and these keys are kept in a secure hardware device such as a VISA security module [VSM] at the bank. They are not disclosed to any third party (except possibly to a court in the case of later dispute). The customer may now purchase digital coins in sticks which in our prototype system contain 100 coins each. The j-th stick of coins will have C~ = {i, j, B}KB,

(2)

where the bank's name B is used to provide redundancy. Each stick of coins is digitally signed by the bank. Again, the bank's name is inserted to provide redundancy, as is the issue date t, and the coin stick is then encrypted and supplied to the customer as

52 CS-- {C1,C2,...,C100,{B,t, CI, C2, o-.,C100}KB-1}Kp

(3)

The signature protects the customer against fraud by the bank or its employees; if the bank later fails to honour a coin or even wrongfully accuses her of having passed an invalid coin, she can produce the stick signature in her defenee. When the customer wishes to make a purchase from a merchant, she first certifies the genuineness of the coins which she is about to spend. She may not be able to tell in advance how many coins will be used, as she may not know how many pages of a learned journal she will have time to read, or how much of an online video she will watch. So she may vouch for a whole stick of them. She does this by hashing the coins C 1 , . . . , C100 recursively as follows. Firstly, she creates a set of common data CD that is shared between her and the merchant and that specifies the transaction completely (this will include both their names, the date, sequence numbers and whatever else is relevant; the details are not so important as the uniqueness of the value CD). Then the last coin value is hashed with CD to give hi00 = h(CD, Cloo), and each of the coins is hashed into this value in turn: For i = 99 to 1 step -1

hi = h(CD, Ci,hi+l);

(4)

Finally the customer signs hi together with the common data C D and sends this to the merchant, together with her public key certificate CP:

S = {hz, CD}Kp-~

(5)

The effect of her signature S, which will be made explicit in her service contract, is that she vouches for the coins: she claims they were properly issued by a bank and not spent elsewhere in the meantime. The fact that the coins are kept, and her signature issued, by a tamper-resistant device protects honest custom.ers against accidental double spending (in a software implementation, accidental double spending could occur if a hard disk were restored from a backup). The merchant checks the signature against the certificate, and if these verify he signals her to begin the transaction. To spend the first coin, she sends the merchant the values Cz and h2. If hi = h(C1, h~) he accepts the coin as valid. To spend the second coin, she sends C2 and ha, and so on. In order to redeem the coins, the merchant presents to the bank the customer's signature S, the coins C 1 , . . . , C'~ actually spent by the customer and the corresponding hash values h i , . . . , h,~. The bank checks the coins, verifies that none of them has been spent before, and credits the merchant's account. The bank may guarantee the transaction so long as the signatures and hashes are consistent, and the total value spent does not exceed the customer's credit limit (otherwise the validity of the coins could be checked online as with credit card transactions over the merchant's floor limit).

53 If there are multiple coin issuers in a system, then the merchant m a y use a different bank from that which issued the coins. In this case, an interbank settlement mechanism is constructed in the traditional way; the information presented by the merchant {CD, S, C1,...,C,~,hl,...,h,~+I} is treated as a cheque and sent to the bank B through a clearing house. During the third and fourth quarters of 1995, we implemented a version of this protocol. We found that handling m a n y coins at the bank was tiresome, and set out to streamline the system. We were inspired by two comments and a business development. The business development was the issue by VISA and MasterCard of the SET specification, which specifies (inter alia) that customer electronic banking applications m a y be software-only and that all transactions would be authorised online: S E T is a zero floor limit protocol. We had not anticipated this, because of the increased processing costs for banks. However, Spanish banks' move to online-only eftpos in 1988 had reduced card fraud from 0.21% of turnover in 1988 to 0.008% in 1991 [BABE], and this may have persuaded US banks, with their much higher fraud rates, that online operation was worth adopting. The first comment, from Bruce Christianson, was that only one coin in each stick need be supplied by the bank. The others coins could simply be counters so long as both bank and customer signatures were present and the hash function was strong. The second comment, fl'om Jan Camenisch, was that one might as well have the customer generate the coins.

5

Second

Protocol

Before the reader concludes that this arrangement is impossibly favourable for the customer, let us outline the basic transaction flow by means of an example. 1. The customer, Alice, decides ~o purchase some service from an online provider. To take a concrete example, a customer in San Francisco decides to purchase a number of pages from an academic journal published by Bernd whose firm is in Germany. The page price is 37 pfennigs. 2. Alice does not know how m a n y pages she will want to purchase, but thinks she is unlikely to need more than t00. So she creates 100 coins for 37 pfennigs each and sends a signature on them to Bernd together with her credit card details. 3. Bernd goes to his bank and gets a pre-authorisation for 37 Deutschmarks. This validates the coins and lie sends a message to Alice saying that she can now download pages at one coin each. 4. Alice now downloads 22 pages; for each of them she sends Bernd one of the coins, whose validity he can easily check. 5. She signals the end of the transaction, whereupon Bernd sends a capture message to his bank which files a debit of DM 8,14 to Alice's account. The capture message contains a short string that proves that he received the 22

54 coins that he claims to have received; he is not able to defraud Alice by claiming for coins that he did not in fact receive. 6. The system is also secure in that all disputes can be resolved. All parties to the transaction - - Alice, Bernd and their bankers - - have authenticated evidence of the actions of the other parties. The formal details are as follows. When a customer wishes to use m digital coins for denomination 5 in a transaction with merchant B, she first generates the common data CD that are unique to the transaction. She then generates a random nonce NA and calculates the last coin, C,~, as

= h(CD,

(6)

Next, the rest of the coins in the stick are generated in reverse order by hashing the previous coin with the common data and the index of the coin in the stick: for i = m-1 to 0 step -1

= h ( C D , i,

(7)

Finally she signs h0, the coin denomination 5, the number of coins m and the common d a t a CD, and sends these to the merchant. This can be thought of as a prepayment transaction of the type used to provide deposits for rental cars and hotel reservations; the merchant makes an authorisation request for the m a x i m u m amount, namely m6, with the SET S a l e I n d flag set to false so that the credit card network treats it as a preauthorisation rather than as an immediate sale. Given a positive authorisation response, he sends a signed acknowledgement to the customer. She can now spend the coins C1, C2 and so on, and the merchant can verify them by a simple hashing operation. Once the transaction is complete, and the merchant has received coins C1 ... Ck, the merchant sends the bank Ck plus the total amount claimed. The bank can check the transaction by dividing the amount claimed by the coin denomination 5 to get the number of coins spent, and work back through that m a n y rounds of hashing to check that the result is the same Co that appeared in the original authorisation request.

6

Third

Protocol

The second, more lightweight, protocol has a number of advantages over the first version. It lets customers to make small transactions in any currency they choose, with electronic coins of whatever denomination is convenient. It is made possible by the fact that all SET transactions are authorised online against the customer's current available balance. So long as this is an effective control on double spending, the second protocol appears safe.

55 A variant will be needed in the interim to work with the first version of SET. This draft does not explicitly support micropayments; there is no room in the message formats for the coins, and the customer does not sign anything for the merchant. Nonetheless, we can still bootstrap micropayments on top of SET compliant systems. The customer can generate another signature to sign the coins for the merchant, and he in turn can simply keep this together with the coins as evidence that she did indeed spend k5 with him. This is directly comparable to the way in which current terminal draft capture systems print out. a draft that is signed by the customer, and retained by him against the possibility of a disputed transaction. However it would be simpler if the micropayment system were supported in SET or its successors. Assuming that this comes to pass, what would the ideal protocol look like?

7

Fourth

Protocol

Neither .the first version of SET nor the second version of our protocol has much room for error. Online authorisation could fail because of attacks on the underlying legacy systems; alternatively, there might be a systematic failure of the public-key front end that SET bolts on to them (e.g., a leak or false revocation of a root certification key). Regardless of the cryptographic sophistication, real world systems inevitably have bugs in their design, implementation and operation. Such bugs account for the majority of actual frauds on banking systems in the past, and recovering security has in some cases been very expensive because it was not a design requirement [And2]. So it is prudent to minimise the number of single points of failure, and enable security to be recovered after unexpected failures (insofar as this is possible). How can such resilience be built into a micropayment system? Our suggestion is that instead of moving all the way from the first protocol to the second by letting the customer manufacture the coins, we retain the requirement that the bank supply at least one coin in each stick, which we will call the root coin. The customer will be issued with a limited supply of root coins, and may have a smartcard or other tamper-resistant device that performs part of the protocol and thus makes double spending difficult. The resulting protocol is similar to the second protocol but with the nonce NA replaced by a root coin Cj supplied by the bank. In addition, instead of signing h0 and sending it to the merchant, the customer will sign and reveal h(ho). This improves substantially on the second protocol since, in the event of a failure of other security mechanisms, banks can move to a fully online system in which transactions are checked online by the card issuing bank wherever fraud rises above the level at which this becomes economic. As the issuing bank knows Cj, it can calculate and return ha as an authorisation response through VISA and the acquiring bank to the acquirer gateway (which provides the guarantee to the merchant).

56 Of course, precautions may have to be taken to prevent a false host attack in which customers collude in real time with someone doing an active wiretap on the legacy systems between the aequirer gateway and the card issuer. There are a number of options: the issuing bank could sign h0. However, this would not protect against a catastrophic failure of the certification authority structure; the issuing bank could return h0 encrypted under the issuer working key used in the current legacy systems. However this would not protect against a catastrophic failure of the legacy infrastructure, such as if organised criminals build a DES keysearch machine to break zone control master keys; - one might even ignore the problem, arguing that legacy systems have been vulnerable to message manipulation for decades; that there have been no significant attacks; and that if any materialised, they could be dealt with piecemeal by installing line encryptors and other ad hoc controls. -

-

Whatever the engineering details, this fourth protocol can clearly give us a low cost security recovery mechanism. Its independence of most of the SET and legacy system processing suggests that it could help us to recover after many of the unpredictable failures that experience shows to be inevitable.

8

Conclusion

Our recursive hashing technique greatly reduces the computational complexity in applications where a series of low value payments are made to the same merchant. We have shown how it can be used in simple payment schemes based on both the smartcard and the online processing models of electronic commerce, and can also provide some novel and valuable features, such as a security recovery facility that does not depend on either the legacy systems or the SET protocols. It is an open problem whether hashing techniques can be combined with the more complex anonymous cash schemes. In December 1995, we learned that three other groups had independently developed micropayment systems that are rather similar to our second protocol. These are the ~Tick Payments' of Torben Pedersen of the CAFE project, the ~PayWords' of Ron Rivest and Adi Shamir [RS], and a scheme from the iKP team at IBM Ziirich [HSW]. From the scientific point of view, one of the more interesting lessons learned from implementing our first protocol and developing the others from it has been that local and global trust interact in interesting and often unexpected ways. The details of this will be the subject of a future paper; the high order bit appears to be that the global trust has to go somewhere. In a payment system, the global mechanism to prevent double spending can be a centralised system of online authorisation, authorisation using end-to-end authentication, tamper resistant objects or (more realistically) some combination of these. Moving the

57 p r i m a r y locus of trust, even slightly, can have profound effects; and very small design changes can greatly improve the system's resilience and robustness. A c k n o w l e d g e m e n t : The first author is grateful to the Isaac Newton Institute for hospitality while this paper was being written. The second and third authors were supported by the D T I funded NetCard project. All three authors acknowledge the help of Mike Roe and other colleagues at the security group at Cambridge University in tweaking bugs in early versions of this protocol.

References 1. "UEPS - - A Second Generation Electronic Wallet", RJ Anderson, in Computer Security - - ESORICS 92, Springer LNCS v 648 pp 411-418 2. RJ Anderson, "Wily Cryptosystems Fail", in Communications of the A C M v 37 no 11 (November 1994) pp 32 - 4o 3. "Cryptographic Credit Control in Pre-payment Metering Systems", RJ Anderson, SJ Bezuidenhout, Proceedings, 1995 IEEE Symposium on Security and Privacy pp 15-23 4, "Programming Satan's Computer", RJ Anderson and RM Needham, in Springer Lecture Notes in Computer Science volume 1000 5. "Fast Server-Aided RSA Signatures Secure Against Active Attacks", P B4gnin, JJ Quisquater, Advances in Cryptology - C R Y P T O 95, Springer LNCS 963 pp 57-69 6. "Card Fraud: Banking's Boom Sector", in Banking Automation Bulletin for Europe (Mar 92) pp 1-5 7. S Blythe, B Fraboni, S Lall, H Ahmed, U de Riu, "Layout Reconstruction of Complex Silicon Chips", in [EEE J. of Solid-State Circuits v 28 no 2 (Feb 93) pp 138-145 8. "Achieving Electronic Privacy", D Chaum, Scientific American (August 92) pp 96-101 9. "The ESPRIT Project CAFE - - High Security Digital Payment Systems", JP Boly, A Bosselaers, R Cramer, R Michelsen, S Mj~alsnes, F Muller, T Pedersen, B Pfitzmann, P de Rooij, B Schoenmakers, M Schunter, L Vallde, M Waidner, in Computer Security -- ESORICS 94, Springer Lecture Notes on Computer Science volume 875 pp 217-230 10. "Micro-Payments based on iKP", R Hanser, M Steiner, M Waidner, preprint, IBM Zfirich, January 16th 1996 11. "Electronic Payments of Small Amounts", TP Pedersen, Aarhus University Technical Report DAIMI PB-495, August 1995 12. "Pay~Vord and MicroMint-Two Simple Micropayment Schemes", RL Rivest, A Shamir, preprint, MIT, Jamlary 26, 1996 13. Secure Electronic Transactions, VISA and MasterCard 1996 14. VISA Security Module Operations Manual, VISA, 1986 15. "Electro-optic sampling of high-speed devices and integrated circuits", JM Wiesenfeld, I B M Journal of Research and Development v 34 no 2/3 (Mar/May 90) pp 141-161

Electronic Payments of Small Amounts Torben P. Pedersen Cryptomathic, Denmark e-mail : tppOcryptomathic, aau. dk This note considers the application of electronic cash to transactions in which many small amounts must be paid to the same payee and in which it is not possible to just pay the total amount afterwards. The most notable example of such a transaction is payment for phone calls. If currently published electronic cash systems are used and a full payment protocol is executed for each of the small amounts, the overall complexity of the system will be prohibitively large (time~ storage and communication). This note describes how such payments can be handled in a wide class of payment systems. The solution is very easy to adapt as it only influences the payment and deposit transactions involving such payments. Furthermore, making and verifying each small payment requires very little computation and communication, and the total complexity of both transactions is comparable to that of a payment of a fixed amount. Abstract.

1

Introduction

The introduction of public key crypto-systems and digital signatures ([9] and [21]) has led to the construction of many different types of payment systems. During payment at least one and often more digital signatures must be created and verified. This has the advantage that it can often be argued (although not always formally proved) that the payment system is as secure as the digital signature system. However, it also has the disadvantage that the efficiency of the payment system depends on the efficiency of the signature scheme. In particular, the time to perform a payment transaction is closely related to that of making and verifying a signature and the storage requirements depend on the length of signatures. Often the computations on the users side must be performed by small devices with relatively little computation power such as smart cards or electronic wallets (see [11] and [8] for two different types of wallets) in which case it is important that the user's part of all transactions can be done very efficiently. Although recent research has improved the efficiency of (privacy protecting) electronic payment systems, they are still too inefficient in certain applications. One such application is phone calls. Here the total amount to be paid is composed of many payments of smM1 amounts, and each of these small amounts must be paid in real time upon receipt of a tick. Depending on the type of phone call (local, long distance, etc.) these ticks may come with relatively short time interval. The timing requirements imposed by this cannot possibly be met by

60 publicly suggested payment systems if each tick is paid for by executing a payment transaction. Furthermore, such an approach would require quite a lot of storage at the recipient side increasing linearly in the number of ticks during the phone call. Although this may not be a serious problem considering todays cheap storage media, it does increase the cost of the payment system and it implies a large communication overhead. Other settings where similar payments could be useful include parking and access to electronic services. We shall in general denote such payments by tick payments. This note describes a method for adding tick payments to systems in which the payer during payment makes (something like) a signature on a message describing the recipient and the amount to be paid. The method is most easily explained as an application of Lamport's password scheme (see [14]) to encode amounts in payments. An earlier application of repeated computat.ions of oneway functions is described in [16] and attributed to Winternitz (1979). In relation to payment systems a similar idea is used in [4] to encode amounts. The encoding suggested in the following is a simplification of that in [4] specifically designed for tick payments and can be used in many different systems. The proposed solution is very easily applicable since only payment and deposit transactions involving tick payments are affected. A tick payment initially requires the same as a normal payment. For a certain parameter, T, the payment of the i'th tick requires at most T - i computations of an easily computable function. Verification of each tick only requires one computation of this function. After the required number of ticks have been paid only a few hundred bits more than in a normal payment must be stored (the exact number depends on the actual choice of the function mentioned above). 1.1

Related Work

The method presented in this paper has also been described in [18]. Similar methods developed independently of the one presented in this paper has also been proposed in [1, 20, t3]. 1.2

Contents

The next section describes the general payment system considered and relates it to other proposed systems. Section 3 then presents the solution, and Section 4 describes a few simple variations. 2 2.1

Electronic

Payment

Systems

T h e General System

VV'econsider an electronic payment system in which an execution of the payment protocol can be described by a triple (v, m, ~r(m)). Here .m E {0, 1}* and o-(rn) are special messages, and v denote all other messages exchanged during the payment. The message, rn, must describe the amount to be paid and it may contain

61

additional information such as a description of the recipient and some bits chosen at random by the recipient. No part of v may depend on the amount paid. In most situations o'(m) is a signature corresponding to a public key, which is either certified as part of v or can be recognised by other means. The verification of such a payment involves the verification that rn contains the required information and that or(m) is correct with respect to m and v. The assumption that m E {0, 1}* is reasonable since a hash value of m and not rn itself is normally used to compute cr(m). In order to be credited the received amount the payee must show (m, ~r(m)) and possibly v to her bank. This can either be done during the payment transaction or in a later deposit transaction. Thus no assumption is made whether the system is on- or off-line. Furthermore, such payment systems can be used in both pre- and post-paid systems. Examples of such schemes are - Cheque-like systems, where the payer signs a message transferring the signed amount from the payer to the payee (see [11] for such an off-line system). Anonymous cheques with counters. In such systems the payer gets during withdrawal a number of cheques and a permission to spend a certain amount (by setting a counter). During payment the payer fills out the cheque, and the payee may be credited the amount. In pre-paid systems this can be done anonymously, i.e., without revealing the anonymity of the payer. See [4, 3, 6] for examples of such systems. The security of payment systems following this model depends on the infeasibility of creating a false pair (m, c@n)) which will be accepted by tile bank. This would enable the receiver to get extra money, and in pre-paid systems it would enable a payer to spend money that he didn't withdraw. 2.2

Different Systems

Other types of off-line electronic payment systems have been proposed in the literature. In an electronic coin system, the user gets during withdrawal a number of electronic coins with fixed denominations (guaranteed by a signature from the issuer). During payment the user must spend a number of coins whose values add up to the required amount (e.g., see [7, 12, 5] for off-line systems and [i0] for an on-line example). As this often requires a large number of coins in a payment, leading to inefficiency with respect to time, storage and communication, electronic cheques with refund were proposed in [7]. Here, the user obtains (buys) a number of cheques during withdrawal. Each cheque has an upper limit and can be spent for any amount up to this limit. A possibly remaining amount of a cheque can later be refunded. This is obviously more flexible than coin based systems, but still less practical than encoding amounts as described in Section 2.1 since the user must contact the bank in order to convert "refundable" money to "spendable" money. Another proposal, in [17], is to use so called divisible coins. Here the user can split a coin arbitrarily (i.e., fhis is much like a cheque with refund, where

62 the refund can be spend). These systems offer more flexibility than cheques with refund, but they have not been obtained with the same level of privacy protection. and the proposed systems seem to be too inefficient for practical purposes. In the pre-paid, off-line systems mentioned above a tamper resistant device (trusted by the issuer) is used to prevent that the user spends more money than allowed. Furthermore, even in payment systems protecting the anonymity of the user it is possible to identify persons who break this tamper resistant device and spend too much money. Very briefly, the price we have to pay for the greater flexibility implied by including the amount in rn is less fall-back security when the tamper resistant protection is passed.

2.3

Limitation of the Systems

As noted above the enhanced flexibility is the main reason for encoding the amount in m. Furthermore, such a scheme can be relatively efficient since its complexity depends on the complexity of creating and verifying c,(rn). However, in the application to tick payments this is not sufficient, because if a full payment is done for each tick then - The user has to create and the payee has to verify and store a large number of pairs (rn, ~(rn)). - The time needed to make and verify a payment may exceed the time interval allowed. Thus the main advantage of these systems vanishes when it comes to tick payments.

3

Adding Tick Payments

In the following we shall denote the security parameter of the payment scheme by k. It will be assumed that T is polynomial in h. Another security parameter n = n ( k ) will depend on k in such a way that n and k are polynomiMly related (e.g., n = k ~ for some constant c > 0). 3.1

T h e Idea

This section shows how a payment system as described above can be adapted to handle tick payments. Let f be a length preserving function {0, 1}* --+ {0, 1}* (i.e., f maps n-bit strings to n-bit strings for all n E IN). Let fi denote i evaluations of f for i E IN. Thus, f0 is the identity and fi = f o r i-1 for i = 1 , 2 , . . . . For the moment f can be any efficiently computable function, but. later we shall impose some restrictions on f for security reasons (one-way in a certain sense). Let a payment system as described in Section 2.1 be given. In the following the system is extended to provide for efficient tick payments. This is done by providing a new way of encoding amounts in the message, rn. In case of normal

63 p a y m e n t s the encoding of amounts is unchanged. For tick paylnents the amount is encoded as follows. The message, m is computed as before except that it encodes the amount 0. Then a new message m ' is computed as m ' = mllT[Io~o, where II denotes concatenation, T is a possibly fixed parameter, and a0 C {0, 1} '~ is c o m p u t e d by the payer as a0 = f T ( a ) , where a is chosen at random in {0, 1} '~ (recall t h a t the message can be an arbitrary string of bits). In case of prepaid systems, where a t a m p e r resistant device manages a counter defining the amounts t h a t m a y be spent, this device must do the computation of a0 (see also Section 4). The payer then computes o'(m') and sends (m', o'(m')). This pair is verified as in a normal payment. Until now the payee has not received payment of any ticks. In order to get payment for the i'th tick (i = 1, 2, 3, ...) the following takes place: 1. The payer sends ai = fT-i(a) to the recipient. 2. The recipient verifies that f(ai) = a i - 1 (ai-1 was received in the previous round, and a0 was received in m'). This can continue for payment of at least T ticks. Thus an amount corresponding to t ticks is encoded as at C {0, 1} '~ satisfying ft(at) = a0. Only a0 (which is part of m) and the last received value, at, need to be remembered. A simple variation of this scheme allows a combination of normal payments and tick payments, by just encoding a non-zero amount in rn as described above. Furthermore, if one tick corresponds to one unit in the given currency, then u units can be paid in the i'th round by sending ai+(~-l) instead of ai.

3.2

Security of the Solution

It is now shown that if f is one-way in a certain sense then it is not feasible to obtain a larger amount than that received in the payment. As mentioned in Section 2.1 the payment systems in question can be used in two ways. If the bank can identify the payer from the payment, it can always hold the payer responsible for the paid amount. In this case the main security concern is whether it is possible for a dishonest payee to change (increase) the encoded amount after the payer executed the payment transaction properly (i.e., following the given protocol). In case the bank is not able to identify the payer, a t a m p e r resistant unit trusted by the bank and used by the payer must decrement a counter corresponding to the amount in the payment. In this case, the main security concern is whether it is possible to encode a different amount than that used by the t a m p e r resistant device, under the assumption that the t a m p e r resistant device does its part of the protocol properly. Thus it can in both cases be assumed that a0 is has been computed correctly. The security of the extended system depends on the security of the given p a y m e n t system and the properties of f. Consider the following property of a p a y m e n t system as described in Section 2.1:

64

D e f i n i t i o n l . Let a payment system with security parameter k be given. The system is said to be unchatTgeable if whenever a. payee receives payment (v, ra, er(~n)) from a device properly following the payment protocol she cannot deposit it as if she received a payment encoding rn ~ ~ rn from that. device except with negligible 1 probability in k. This probability is over all random choices during payment and deposit. Unchangeability ensures that amounts and other information encoded in m cannot be changed. The function f must be one-way on its iterates (see also [1.5]): D e f i n i t i o n 2 . Let f : {0, 1}* --+ {0, 1}* be a length preserving function, f is said to be one-way on T iterates if for every probabilistic polynomial time algorithm, A, the probability that for a randomly chosen x ~ {0, 1} ~, A given y = ft (x) and t for 1 < t < T outputs z such that f(z) = y is negligible in n (the probability is over the choice of x and the random coins of A). The assumption that A also gets t as input is not important as it might as well guess this value whenever T is polynomial in k. Given a length preserving function, f, consider the following game between two polynomially bounded parties A and B: 1. A chooses a: E {0, 1} ~ at random, computes f T ( a ) and sends it to B. 2. For i = T - 1, T - 2 , . . . until B decides to stop (B must do this at latest when i = 1): A sends f i ( x ) to B. 3. Assume ft(x) was the last v a h e B received, where t E { 1 , . . . T } . Then B outputs y E {0, 1} ~. 4. B wins if .f(y) = ft (a). L e m m a 3. If f is one-way on T iterates (T is polynomial in n), then the prob-

ability that B wins is negligible in "n and hence in k (the probability is over the choice of x and the rar~dorn choices of B). P r o o f Assume that there is a polynomially bounded B, which is able to win with probability at least n -~ for some c > 0 and infinitely many values of ~.. There is a to such that the probability that B outputs a pre-image of fro (z) with non-negligible probability (over the choice of a and the random choices of B) is at least n -d for some d and infinitely many values of n (since T is polynomial in rt). Consider such n's. Now consider the.following machine for finding a pre-image of ~] = ft(x), given y and t: 1. 2. 3. 4.

First compute z = F - t ( x ) . Simulate the above game. If B stops for a value of i different from t, the algorithm outputs fails. Otherwise if B stops for i = t and outputs YB, then the algorithm outputs

YB. A function g : IN --+ IR is negligible if for all c > 0 and k sufficiently large Ig(k)l <_k-%

65 For t = to the algorithm outputs YB satisfying f(YB) = Y with probability at least n -d. This contradict the assumption that f is one-way on T iterates. [] From this technical lemma it is not hard to see that the encoding of amounts is secure if f is one-way on T-iterates. The details are given in the following proposition. P r o p o s i t i o n 4 . If the given payment system satisfies Definition 1, and if f is one-way on T iterates then the following holds except with negligible probability in k: If a payee receives the amount, a, in a payment transaction then, except with negligible probability in k, she can at most obtain an amount a during deposit. P r o o f A payment in the new system can either be a normal or a tick payment. In the first case the claim follows immediately from the assumption that the original system satisfies Definition 1. Now assume that after N tick payment transactions a payee has been able to cash a payment received for t ticks as t' > t ticks with non-negligible probability. Then it is possible to construct a machine which wins in the above game, by simply simulating a payment system and using this payee to obtain the required pre-image. This machine for interacting with A in the above game works as follows: 1. Setup and simulate the entire payment system by selecting all keys and perform all protocols as described acting both as payer, payee and bank. Furthermore choose l C {1, 2 , . . . , N} at random. 2. Whenever a normal payment is performed follow the payment with the given dishonest payee). 3. If the payment is a tick payment and this is the l'th tick payment, then use the value fir (x) received from A as a0. Furthermore, interact with A to get payment for the required number of ticks. Assume this payment is for t ticks. 4. If the payment is another tick payment then make this payment correctly (using the dishonest payee). 5. After all payments have been performed, the payee tries to deposit one of the received tick payments for more ticks than received. If the payee is able to get money for t' > t ticks for the l'th payment, then from the messages sent it is possible to find z such that o~{~= ft' (z), where c~ in contained in rn' corresponding to the l'th payment. The machine outputs = ft'-t-l(z). Otherwise, the machine loses the game to A. The machine will output u in the last step with non-negligible probability since 1 was chosen at random (and N is polynomial in k). By the property of unchangeability, a~ = s0, except with negligible probability, and hence the machine will output a number u winning the game against A. By Lemma 3 this contradicts that f is one-way on T iterates. [] This proposition shows that the recipient cannot increase the received amount. Of course she can decrement it (corresponding to losing coins from a purse), but that should not be of her interest. Thus the extended system is not unchangeable, but still secure.

66 4

Variations

4.1

Possible Choices of f

In the previous section it was shown that if f is one-way on its iterates then the solution for tick payments is secure. In practice f could be derived from a hash function {0, 1}* --+ {0, 1} ~ by restricting the input to n-bit strings (e.g., [19, 22, 2]). Such a function would be efficient and it often comes for free in the sense that it is needed anyways in the implementation of the payment system. If the hash function distributes its input sufficiently randomly it can be assumed to be one-way on its iterates for practical values of T. Alternatively, a one-way permutation can be used. Such a function is one-way on T iterates whenever T is polynomial in k since y in Definition 2 is uniformly distributed. This again leads to the possibility of choosing f as a trapdoor permutation. If only (the tamper resistant device of) the payer knows the trapdoor information (i.e., the secret key needed to compute f - l ) , then the payer can avoid T and have ao = a. If ai-~ has been used to pay for tick (i - 1), then ai = f - ~ ( a i - 1 ) can be used to pay for the i'th tick. This has the advantage that, a priori, no upper limit on the number of ticks must be determined. Furthermore, it could lead to better efficiency although this is not clear if f is the RSA function with small public exponent and T is at most a few hundreds (see also [14] for some suggestions for speeding up the repeated computations of the one-way function). Finally, we mention that if {0, 1} n is replaced by a group A~ (with group operation, say, Q) a one-way homomorphism: An -+ An could be a good choice in wallets with observers (again the RSA function is a candidate). In that case observer and user could choose a E AN mutually at random as follows 1. Observer chooses fl E An at random and sends a commitment to/3o = f~r(fl) to the user. 2. The user chooses 7 C An at random and sends fT(7) to the observer. 3. ']?he observer opens the commitment to f T (fl) 4. The observer and user compute as = f T (fl) Q f T (7) and include it in m'. To pay for the i'th tick the observer s e n d s / 3 / = f r - i (/3) to the user and the user verifies that f(fli) = fli-1 and sends c~i = ,8i G f T - i ( 7 ) to the recipient. The advantage of this approach is that the observer can control the number of ticks paid and the user can blind the numbers sent for each tick. 4.2

V a r i a t i o n s in O n - l i n e S y s t e m s

If the proposed method is applied to on-line systems, two alternatives are possible: 1. (v, m', o'(m')) is verified on-line, but the payment for each tick is verified off-line.

67 2. (v, .rn', c~(rn')) as well as the payment for each tick is verified on-line. Here the first alternative is most attractive as it obtains the advantage of online security while keeping the communication requirements independent of the number of ticks paid.

5

Conclusion

It has been shown that tick payments can be done very efficiently for payment systems where amounts are encoded in a special message during payment. It seems to be contradictory to the notion of coins to obtain the same property for coin based systems, but it is an interesting question if a similar hack can be used for cheque systems with refund as described in [7].

6

Acknowledgements

I would like to thank all members in the protocol group of the E S P R I T project C A F E for discussions about this method. In particular, Ronald Cramer for showing how an initial suggestion could be made independent of withdrawal, and both Ronald Cramer and Berry Schoenmakers for their cooperation on the extension to the wallet with observer setting.

References 1. R. Andersonn, H. Manifavas and C. Sutherland. A Practical Electronic Cash System. Manuscript 1995. 2. Integrity primitives for Secure Information Systems. Lecture Notes in Computer Science, volume 1007. Eds. A. Bosselaers and B. Preneel. 3. J.-P. Boly, A. Bosselars, R. Cramer, R. Miehelsen, S. Mjr F. Muller, B. Pfitzmarm, P. de Rooij, B. Schoenmakers, M. Schunter, L. Vall6, and M. Waidner. The ESPRIT Project CAFE - - High Security Digital Payment Systems. In Computer Security - - ESORICS'9~, volume 875 of Lecture Notes in Computer Science. Springer-Verlag, 1994. 4. J. Bos and D. Chaum. SmartCash: A Practical Electronic Payment System. Technical Report C5-R9035, CWI, August 1990. 5. S. Brands. Untraceable Off-line Cash in Wallet with Observers. In Advances in Cryptology - proceedings of C R Y P T O 93, Lecture Notes in Computer Science, pages 302 -318. Springer-Verlag, 1994. 6. S. Brands. Off-Line Electronic Cash Based on Secret-Key Certificates. In Proceedings of LATIN'95, 1995. Also available as CWI technical report, CS-R9506. 7. D. Chaum, A. Fiat, and M. Naor. Untraceable Electronic Cash. In Advances in Cryptology--CRYPTO '88, volume 403 of Lecture Notes in Computer Science, pages 319-327, Berlin, 1990. Springer-Verlag. 8. D. Chaum. Achieving Electronic Privacy. Scientific American, pages 96101, August 1992.

68 9. W. Diffie and M. E. Hellman. New Directions in Cryptography. I R E S Trans. Inform. Theory, IT-22(6):644 654, November 1976. 10. DigiCash. See http:/www.digicash.com/ecash/. 11. S. Even and O. Goldreich. Electronic Wallet. In Advances in Cryptology proceedings of C R Y P T O 88, pages 383 - 386. Plenum Press, 1984. 12. N. Ferguson. Single Term Off-Line Coins. In Advances in Cryptology proceedings of E U R O C R Y P T 93, Lecture Notes in Computer Science, pages 318-328. Springer-Verlag, 1993. 13. R. Hauser, M. Steiner and M. Waidner. Micro-Payments Based on iKP. January 1996 14. L. Lamport. Password Authentication with Insecure Communication. Communications of the ACM, 24(11):770-772, 1981. 15. L. A. Levin. One-Way Function and Pseudorandom Generators. In Proceedings of the 17th Annual A C M Symposium. on the Theory of Computing, pages 363 - 365, 1985. 16. R. C. Merkle. A Certified Digital Signature. In Advances in Cryptology - proceedings of C R Y P T O 89, volume 435 of Lecture Notes in Computer Science, pages 218-238. Springer-Verlag, 1990. 17. T. Okamoto and K. Ohta. Universal Electronic Cash. In Advances in Cryptology--CRYPTO '91, volume 576 of Lecture Notes in Computer Science, pages 324--337, Berlin, 1992. Springer-Verlag. 18. T. Pedersen. Electronic Payments of Small Amounts. Technical Report, DAIMI PD - 495~ Aarhus University, August 1995. 19. R. L. Rivest. The MD4 Message Digest Algorithm. In Advances in Cryptology - proceedings of C R Y P T O 90, volume 537 of Lecture Notes in Computer Science, pages 303-311. Springer-Verlag, 1991. 20. R. Rivest and A. Shamir. PayWord and MicroMint: Two Simple Micropayment Schemes. Manuscript, November 7~ 1995 21. R. Rivest, A. Shamir, and L. Adleman. A Method for Obtaining Digital Signatures and Public-key Cryptosystems. Communications of the A CM, 21, 1978. 22. Specifications for a Secure Hash Standard. Federal Information Processing Standards Publication, 1992.

PayWord and MicroMint: Two Simple Micropayment Schemes

Ronald L. Rivest 1 and Adi Shamir 2 1 MIT Laboratory for Computer Science, 545 Technology Square, Cambridge, Mass. 02139, rivest @theory.lcs.mit.edu 2 Weizmann Institute of Science, Applied Mathematics Department, Rehovot, Israel, [email protected]

1

Introduction

~Ve present two simple micropayment schemes, "PayWord" and :'MicroMint," for making small purchases over the Internet. We were inspired to work on this problem by DEC's "Millicent" scheme[10]. Surveys of some electronic payment schemes can be found in Hallam-Baker [6], Schneier[16], and Wayner[18]. Our main goal is to minimize the number of public-key operations required per payment, using hash operations instead whenever possible. As a rough guide, hash functions are about 100 times faster than RSA signature verification, and about 10,000 times faster than RSA signature generation: on a typical workstation, one can sign two messages per second, verify 200 signatures per second, and compute 20,000 hash function values per second. To support micropayments, exceptional efficiency is required, otherwise the cost of the mechanism will exceed the value of the payments. As a consequence, our micropayment schemes are light-weight compared to full macropayment schemes. We "don't sweat the small stuff": a user who loses a micropayment is similar to someone who loses a nickel in a candy machine. Similarly, candy machines aren't built with expensive mechanisms for detecting forged coins, and yet they work well in practice, and the overall level of abuse is low. Large-scale a n d / o r persistent fraud must be detected and eliminated, but if the scheme delivers a volume of payments to the right parties that is roughly correct, we're happy. In our schemes the players are brokers, users, and vendors. Brokers authorize users to make micropayments to vendors, and redeem the payments collected by the vendors. While user-vendor relationships are transient, broker-user and broker-vendor relationships are long-term. In a typical transaction a vendor sells access to a World-Wide Web page for one cent. Since a user may access only a few pages before moving on, standard credit-card arrangements incur unacceptably high overheads. The first scheme, "PayWord," is a credit-based scheme, based on chains of "paywords" (hash values). Similar chains have been previously proposed for different purposes: by Lamport [9] and Haller (in S/Key) for access control [7], and by Winternitz [11] as a one-time signature scheme. The application of this

Y0 idea for micropayments has also been independently discovered by Anderson et al. [2] and by Pederson [14], as we learned after distributing the initial draft of this paper. We discuss these related proposals further in Section 5. The user authenticates a complete chain to the vendor with a single public-key signature, and then successively reveals each payword in the chain to the vendor to make micropayments. The incremental cost of a payment is thus one hash function computation per party. PayWord is optimized for sequences of micropayments, but is secure and flexible enough to support larger variable-value payments as well. The second scheme, "MicroMint," was designed to eliminate public-key operations altogether. It has lower security but higher speed. It introduces a new paradigm of representing coins by k-way hash-function collisicms. Just as for a real mint, a broker's "economy of scale" allows him to produce large quantities of such coins at very low cost per coin, while small-scale forgery attempts can only produce coins at a cost exceeding their value.

2

G e n e r a l i t i e s and N o t a t i o n

We use public-key cryptography (e.g. RSA with a short public exponent). The public keys of the broker B, user U, and vendor V are denoted PKB, PKu, and PKv, respectively; their secret keys are denoted SKB, SKu, and S K y . A message M with its digital signature produced by secret key SK is denoted {M}sK. This signature can be verified using the corresponding public key PK. We let h denote a cryptographically strong hash function, such as MD5115] or SHAll3]. The output (nominally 128 or 160 bits) may be truncated to shorter lengths as described later. The important property of h is its one-wayness and collision-resistance; a very large search should be required to find a single input producing a given output, or to find two inputs producing the same output. The input length may, in some cases, be equal to the output length.

3

PayWord

PayWord is credit-based. The user establishes an account with a broker, who issues her a digitally-signed PayWord Certificate containing the broker's name, the user's name and IP-address, the user's public key, the expiration date, and other information. The certificate has to be renewed by the broker (e.g. monthly), who will do so if the user's account is in good standing. This certificate authorizes the user to make Payword chains, and assures vendors that the user's paywords are redeemable by the broker. We assume in this paper that each payword is worth exactly one cent (this could be varied). In our typical application, when U clicks on a link to a vendor V's non-free web page, his browser determines whether this is the first request to V that day. For a first request, U computes and signs a "commitment" to a new userspecific and vendor-specific chain of paywords wl, w2, . . . , w~. The user creates

71 the payword chain in reverse order by picking the last payword w= at random, and then computing

~i

=

h(wi+i)

for i = n - 1, n - 2, . . . , 0. Here w0 is the root of the payword chain, and is not a payword itself. The commitment contains the root w0, but not any payword wi for i > 0. Then U provides this commitment and her certificate to V, who verifies their signatures. The i-th payment (for i = 1, 2 , . . . ) from U to V consists of the pair (w~, i), which the vendor can verify using wi-1. Each such payment requires no calculations by U, and only a single hash operation by V. At the end of each day, V reports to B the last (highest-indexed) payment (wt, l) received from each user that day, together with each corresponding commitment. B charges U's account 1 cents and pays l cents into V's account. (The broker might also charge subscription a n d / o r transaction fees, which we ignore here.) A fundamental design goat of PayWord is to minimize communication (particularly on-line communication) with the broker. We imagine that there will be only a few nationwide brokers; to prevent them from becoming a bottleneck, it is important that their computational burden be both reasonable and "off-line." PayWord is an "off-line" scheme: V does not need to interact with B when U first contacts V, nor does V need to interact with B as each payment is made. Note that B does not even receive every payword spent, but only the last payword spent by each user each day at each vendor. PayWord is thus extremely efficient when a user makes repeated requests from the same vendor, but is quite effective in any case. The public-key operations required by V are only signature verifications, which are relatively efficient. We note that Shamir's probabilistic signature screening techniques[17] can be used here to reduce the computational load on the vendor even further. Another application where PayWord is well-suited is the purchase of pay-per-view movies; the user can pay a few cents for each minute of viewing time. This completes our overview; we now give some technical details. 3.1

User-Broker relationship and certificates

User U begins a relationship with broker B by requesting an account and a PayWord Certificate. She gives B over a secure authenticated channel: her creditcard number, her public key PKu, and her "delivery address" Au. Her aggregated PayWord charges will be charged to her credit-card account. Her delivery address is her Internet/email or her U.S. mail address; her certificate will only authorize payments by U for purchases to be delivered to Au. The user's certificate has an expiration date E. Certificates might expire monthly, for example. Users who don't pay their bills won't be issued new certificates. The broker may also give other (possibly user-specific) information Iu in the certificate, such as: a certificate serial number, credit limits to be applied

72 per vendor, information on how to contact the broker, broker/vendor terms and conditions, etc. The user's certificate C~ thus has the form:

Cu = {B, U, Au, PKu, E, I v } s K , The PayWord certificate is a statement by B to any vendor that B will redeem authentic paywords produced by U turned in before the given expiration date (plus a day's grace). PayWord is not intended to provide user anonymity. Although certificates could contain user account numbers instead of user names, the inclusion of Au effectively destroys U's anonymity. However, some privacy is provided, since there is no record kept as to which documents were purchased. If U loses her secret key she should report it at once to B. Her liability should be limited in such cases, as it is for credit-card loss. However, if she does so repeatedly the broker may refuse her further service. The broker may also keep a "hot list" of certificates whose users have reported lost keys, or which are otherwise problematic. As an alternative to hot-lists, one can use hash-chains in a different manner as proposed by Mieali [12] to provide daily authentication of the user's certificate. The user's certificate would additionally contain the root w~ of a hash chain of length 31. On day j - 1 of the month, the broker will send the user (e.g. via email) the value w~ if and only if the user's account is still in good standing. Vendors will then demand of each user the appropriate w ~ Value before accepting payment.

3.2

User-Vendor relationships and payments

User-vendor relationships are transient. A user may visit a web site, purchase ten pages, and then move on elsewhere. Commitments When U is about to contact a new vendor V, she computes a fresh payword chain wl, . . . , w, with root w0. Here n is chosen at the user's convenience; it could be ten or ten thousand. She then computes her commitment for that chain: M = {I~ Cu, wo, D, IM}SKv- . Here V iden~ifies the vendor, Cu is U's certificate, w0 is the root of the payword chain, D is the current date, and IM is any additional information that may be desired (such as the length n of the payword chain). M is signed by U and given to V. (Since this signature is necessarily "on-line," as it contains the vendor's name, the user might consider using an "on-line/off-line" signature scheme[5].) This commitment authorizes B to pay V for any of the paywords wl, . . . , w,~ that V redeems with B before date D (plus a day's grace). Note that paywords are vendor-specific and user-specific; they are of no value to another vendor. Note that U must sign a commitment for each vendor she pays. tf she rapidly switches between vendors, the cost of doing so may become noticeable. However,

73 this is PayWord's only significant computational requirement, and the security it provides makes PayWord usable even for larger "macropayments" (e.g. software selling at $19.99). The vendor verifies U's signature on M and the broker's signature on C~ (contained within M), and checks expiration dates. The vendor V should cache verified commitments until they expire at the end of the day. Otherwise, if he redeemed (and forgot) paywords received before ~he expiration date of the commitment, U could cheat V by replaying earlier commitments and paywords. (Actually, to defeat this attack, V need store only a short hash of each commitment he has reported to B already today.) The user should preferably also cache her commitment until she believes that she is finished ordering information from V, or until the commitment expires. She can always generate a fresh commitment if she re-visits a vendor whose commitment she has deleted.

Payments The user and vendor need to agree on the amount to be paid. In our exemplary application, the price of a web page is typically one cent, but could be some other amount. A web page should presumably be free if the user has already purchased it that day, and is just requesting it again because it was flushed from his cache of pages. A payment P from U to V consists of a payword and its index: P = (wl, i) .

The payment is short: only twenLy or thirty bytes long. (The first payment to V that day would normally accompany U's corresponding commitment; later payments are just the payword and its index, unless the previous chain is exhausted and a new chain must be committed to.) The payment is not signed by U, since it is self-authenticating (using the commitment). The user spends her paywords in order: wl first, then w2, and so on. If each payword is worth one cent, and each web page costs one cent, then she discloses wi to V when she orders her i-th web page from V that day. This leads to the PayWord payment policy: for each commitment a vendor V is paid l cents, where (wt,l) is the corresponding payment received with the largest index. This means that V needs to store only one payment from each user: the one with the highest index. Once a user spends wi, she can not spend wj for j < i. The broker can confirm the value to be paid for w~ by determining how many applications of h are required to map wt into wo. P a y W o r d supports variable-size payments in a simple and natural manner. If U skips paywords, and gives w7 after giving w~, she is giving V a nickel instead of a penny. When U skips paywords, during verification V need only apply h a number of times proportional to the value of the payment made. A payment does not specify what item it is payment for. The vendor may cheat U by sending him nothing, or the wrong item, in return. The user bears the risk of losing the payment, just as if he had put a penny in the mail. Vendors who so cheat their customers will be shunned. This risk can be moved to V, if

74 V specifies payment after the document has been delivered. If U doesn't pay, V can notify B and/or refuse U further service. For micropayments, users and vendors might find either approach workable.

3.3

Vendor-Broker relationships and redemption

A vendor V needn't have a prior relationship with B, but does need to obtain PKB in an authenticated manner, so he can authenticate certificates signed by B. He also needs to establish a way for B to pay V for paywords redeemed. (Brokers pay vendors by means outside the PayWord system.) At the end of each day (or other suitable period), V sends B a redemption message giving, for each of B's users who have paid V that day (1) the commitment Co- received from U, (2) the last payment P = (w~,t) received from U. The broker then needs to (1) verify each commitment received (he only needs to verify user signatures, since he can recognize his own certificates), including checking of dates, etc., and (2) verify each payment (w~,l) (this requires l hash function applications). We assume that B normally honors all valid redemption requests. Since hash function computations are cheap, and signature verifications ~re only moderately expensive, B's computational burden should be reasonable, particularly since it is more-o>less proportional to the payment volume he is supporting; B can charge transaction or subscription fees adequate to cover his computation costs. We also note that B never needs to respond in real-time; he can batch up his computations and perform them off-line overnight.

3.4

Efficiency

We summarize PayWord's computational and storage requirements: - The broker needs to sign each user certificate, verify each user commitment, and perform one hash function application per payment. (All these computations are off-line.) The broker stores copies of user certificates and maintains accounts for users and vendors. The user needs to verify his certificates, sign each of his commitments, and perform one hash function application per payword committed to. (Only signing commitments is an on-line computation.) He needs to store his secret key SKu, his active commitments, the corresponding payword chains, and his current position in each chain. The vendor verifies all certificates and commitments received, and performs one hash function application per payword received or skipped over. (All his computations are on-line.) The vendor needs to store all commitments and the last payment received per commitment each day. -

-

75 3.5

Variations and Extensions

In one variation, h(.)is replaced by h~(.) = h(s, .), where s is a "salt" (random value) specified in the commitment. Salting may enable the use of faster hash functions or hash functions with a shorter output length (perhaps as short as 64-80 bits). The value of each payword might be fixed at one cent, or might be specified in Cu or M. In a variation, M might authenticate several chains, whose paywords have different values (for penny paywords, nickel paywords, etc.). The user name may also need to be specified in a payment if it is not clear from context. If U has more than one payword chain authorized for V, then the payment should specify which is relevant. Paywords could be sold on a debit basis, rather than a credit basis, but only if the user interacts with the broker to produce each commitment: the certificate could require that the broker, rather than the user, sign each commitment. The broker can automatically refund the user for unused paywords, once the vendor has redeemed the paywords given to him. In some cases, for macropayments, it might be useful to have the "commitment" act like an electronic credit card order or check without, paywords being used at all. The commitment would specify the vendor and the amount to be paid. The broker may specify in user certificates other terms and conditions to limit his risk. For example, B may limit the amount that U can spend per day at any vendor. Or, B may refuse payment if U's name is on B's "hot list" at the beginning of the day. (Vendors can down-load B's hot-list each morning.) Or, B may refuse to pay if U's total expenditures over all vendors exceeds a specified limit per day. This protects B from extensive liability if SKu is stolen and abused. (Although again, since Cu only authorizes delivery to Au, risk is reduced.) In these cases vendors share the risk with B. Instead of using payword chains, another method we considered for improving efficiency was to have V probabilistically select payments for redemption. We couldn't make this idea work out, and leave this approach as an open problem.

4

MicroMint

MieroMint is designed to provide reasonable security at very low cost, and is optimized for unrelated low-value payments. MicroMint uses no public-key operations at all. MicroMint "coins" are produced by a broker, who sells them to users. Users give these coins to vendors as payments. Vendors return coins to the broker in return for payment by other means. A coin is a bit-string whose validity can be easily checked by anyone, but which is hard to produce. This is similar to the requirements for a public-key signature, whose complexity makes it an overkill for a transaction whose value is one cent. (PayWord uses signatures, but not on every transaction.)

76 MicroMint has the property that generating many coins is very much cheaper, per coin generated, than generating few coins. A large initial investment is required to generate the first coin, but then generating additional coins can be made progressively cheaper. This is similar to the economics for a regular mint: which invests in a lot of expensive machinery to make coins economically. (It makes no sense for a forger to produce coins in a way that costs more per coin produced than its value.) The broker will typically issue new coins at the beginning of each month; the validity of these coins will expire at the end of the month. Unused coins are returned to the broker at the end of each month, and new coins can be purchased at the beginning of each month. Vendors can return the coins they collect to the broker at their convenience (e.g. at the end of each day). We now describe the "basic" variant of MicroMint. Many extensions and variations are possible on this theme; we describe some of them in section 4.2.

Hash Function Collisions MieroMint coins are represented by hash function collisions, for some specified one-way hash function h mapping m-bit strings x to n-bit strings y. We say that x is a pro-image of y if h(x) = y. A pair of distinct m-bit strings (xs, x2) is called a (2-way) collision if h(x~) = h(x2) = y, for some n-bit string y. If h acts ':randomly," the only way to produce even one acceptable 2-way collision is to hash about ~ = 2~/2 x-values and search for repeated outputs. This is essentially the "birthday paradox." (We ignore small constants in our analyses.) Hashing c times as many x-values as are needed to produce the first collision results in approximately c 2 as many collisions, for 1 < e < 2 ~/2, so producing collisions can be done increasingly efficiently, per coin generated, once the threshold for finding collisions has been passed. Coins as k - w a y collisions A problem with 2-way collisions is that choosing a value of n small enough to make the broker's work feasible results in a situation where coins can be forged a bit too easily by an a.dversary. To raise the threshold further against would-be forgers, we propose using k-way collisions instead of 2-way collisions. A k-way collision is a set of k distinct a-values xl, x,., . . . , xk that have the same hash value y. The number of x-values that must be examined before one expects to see the first k-way collision is then approximately 2 "(k-1)/k. If one examines e time~ this many ~-values, for 1 <_ e < 2n/k, one expects to see about ck k-way collisions. Choosing k > 2 has the dual effect of delaying the threshold where the first collision is seen, and also accelerating the rate of collision generation, once the threshold is passed. We thus let a k-way collision ( x l , . . . , x k ) represent a coin. The validity of this coin can be ea.sily verified by anyone by checking that the xi's are distinct and that h(x~) = h(x~) . . . . = h(xk) = y for some n-string y.

77

Minting coins The process of computing h(x) = y is analogous to tossing a bail (x) at r a n d o m into one of 2 ~ bins; the bin that ball x ends up in is t h e one with index y. A coin is thus a set of k balls that have been tossed into the same bin. Getting k balls into the same bin requires tossing a substantial number of balls altogether, since balls can not be "aimed" at a particular bin. To mint coins, the broker will create 2 n bins, toss approximately k2 ~ balls, and create one coin from each bin that now contains at least k balls. With this choice of parameters each ball has a chance of roughly 1/2 of being part of a coin. Whenever one of the 2 ~ bins has k or more balls in it, k of those balls can be extracted to form a coin. Note that if a bin has more than k balls in it, the broker can in principle extract k-subsets in multiple ways to produce several coins. However, an adversary who obtains two different coins from the same bin could combine t h e m to produce muttiple new coins. Therefore, we recommend that a MicroMint broker should produce at most one coin from each bin. Following this rule also simplifies the Broker's task of detecting multiply-spent coins, since he needs to allocate a table of only 2 n bits to indicate whether a coin with a particular n-bit hash value has already been redeemed. A small problem in this basic picture, however, is that computation is much cheaper than storage. The number of balls that can be tossed into bins in a month-long computation far exceeds both the number of balls that can be m e m orized on a reasonable number of hard disks and the number of coins that the broker might realistically need to mint. One could a t t e m p t to balance the computation and m e m o r y requirements by utilizing a very slow hash algorithm, such as DES iterated m a n y times. Unfortunately, this approach also slows down the verification process. A better approach, which we adopt, is to make most balls unusable for the purpose of minting coins. To do so, we say that a ball is "good" if the high-order bits of the hash value y have a value z specified by the broker. More precisely, let n = t + u for some specified nonnegative integers t and u. If the high-order t bits of y are equal to the specified value z then the value g is called "good, " and the low-order u bits of y determine the index of the bin into which the (good) ball x is tossed. (General x values are referred to merely as "balls," and those that are not good can be thought of as having been conceptually tossed into nonexistent virtual bins that are "out of range.") A proper choice of t enables us to balance the computational and storage requirements of the broker, without slowing down the verification process. It slows down the generation process by a factor of 2 t, while limiting the storage requirements of the broker to a small multiple of the number of coins to be generated. The broker thus tosses approximately k2 '~ balls, memorizes about k2 ~ good balls that he tosses into the 2 ~ bins, and generates from them approximately (1/2) - T' valid coins. Remark: We note that with standard hash functions, such as MD5 and DES, the number of ouput bits produced m a y exceed the number n of bits specified in the broker's parameters. A suitable hash function for the broker can be obtained

78 by discarding all but the low-order n bits of the standard hash function output. This discarding of bits other than the low-order n bits is a different process than that of specifying a particular value for the high-order t bits out of the n that was described above. A detailed scenario Here is a detailed sketch of how a typical broker might proceed to choose parameters for his minting operating for a given month. The calculations are approximate (values are typically rounded to the nearest power of two), but instructive; they can be easily modified for other assumptions. The broker wilt invest in substantial hardware that gives him a computational advantage over would-be forgers, and run this hardware continuously for a month to compute coins valid for the next month. This hardware is likely to include many special-purpose chips for computing h efficiently. We suppose that the broker wishes to have a net profit of 81 million per month (approximately 227 cents/inonth). He charges a brokerage fee of 10%. T h a t is, for every coin worth one cent that he sells, he only gives the vendor 0.9 cents when it is redeemed. Thus, the broker needs to sell one billion, coins per month (approximately 23o coins/month) to collect his $1M fee. If an average user buys 2500 ($25.00) coins per month, he will need to have a customer base of 500,000 customers. The broker chooses k = 4; a coin will be a good 4-way collision. To create 230 coins, the broker chooses u = 31, so that he creates an array of 231 (approximately two billion) bins, each of which can hold up to 4 x-values that hash to an n-bit value that is the concantenation of a fixed t-bit pattern z and the u-bit index of the bin. The broker will toss an average of 4 bails into each bin. T h a t is, the broker will generate 4 - 23* = 2aa (approximately" eight billion) x-values that produce good :y-values. When he does so, the probability that a bin then contains 4 or more xvalues (and thus can yield a coin) is about 1/2. (Using a Poisson approximation, it. can be calculated that the correct value is approximately 0.56.) Since each of the 2al bins produces a coin with probability 1/2, the number of coins produced is 2 a~ as desired. In order to maximize his advantage over an adversary who wishes to forge coins, the broker invests in special-purpose hardware that allows him to compute hash values very quickly. This will allow him to choose a relatively large value of t, so that good hash values are relatively rare. This increases the work factor for an adversary (and for the broker) by a factor of 2 t. The broker chooses his hash function h as the low-order n bits of the encryption of some fixed value v0 with key x under the Data Encryption Standard (DES): h(x)

=

[DU&(v0)],...,, .

The broker purchases a number of field-programmable gate array (FPGA) chips, each of which is capable of hashing approximately 225 (approximately 30 million) x-vMues per second. (See [3].) Each such chip costs about $200; we estimate that the broker's actual cost per chip might be closer to $400 per chip

79 when engineering, support, and associated hardware are also considered. The broker purchases 2 s (= 256) of these chips, which costs him about $100,000. These chips can collectively hash 2 aa (approximately 8.6 billion) values per second. Since there are roughly 2 ~1 (two million) seconds in a month, they can hash about 254 (approximately 18 million billion) values per month. Based on these estimates the broker chooses n = 52 and t = 21 and runs his minting operation for one month. Of the k2 ~ = 254 hash values computed, only one in 221 will be good, so that approximately 2 a3 good x-values are found, as necessary to produce 2a~ coins. Storing a good (x, h(x)) pair takes less than 16 bytes. The total storage required for all good pairs is less than 2 a7 bytes (128 Gigabytes). Using standard magnetic hard disk technology costing approximately $300 per Gigabyte, the total cost for storage is less than $40,000. The total cost for the broker's hardware is thus less than $150,000, which is less than 15% of the first month's profit. Rather than actually writing each pair into a randomly-accessible bin, the broker can write the 233 good pairs sequentially to the disk array, and then sort them into increasing order by y value, to determine which are in the same bin. With a reasonable sorting algorithm, the sorting time should be under one day. S e l l i n g coins Towards the end of each month, the broker begins selling coins to users for the next month. At the beginning of each month, B reveals the new validity criterion for coins to be used that month. Such sales can either be on a debit basis or a credit basis, since B will be able to recognize coins when they are returned to him for redemption. In a typical purchase, a user might buy $25.00 worth of coins (2500 coins), and charge the purchase to his credit card. The broker keeps a record of which coins each user bought. Unused coins are returned to the broker at the end of each month.

Making payments Each time a user purchases a web page, he gives the vendor a previously unspent coin (xl, x2,..., xk). (This might be handled automatica.lly by the user's web browser when the user clicks on a link that has a declared fee.) The vendor verifies that it is indeed a good k-way collision by computing h(xi) for 1 < i _< k, and checking that the values are equal and good. Note that while the broker's minting process was intentionally slowed down by a factor of 2 ~, the vendor's task of verifying a coin remains extremely efficient, requiring only k hash computations and a few comparisons (in our proposed scenario, k = 4).

Redemptions The vendor returns the coins lie has collected to the broker at the end of each day. The broker checks each coin to see if it has been previously returned, and if not, pays the vendor one cent (minus his brokerage fee) for each coin. We propose that if the broker receives a specific coin more than once, he does not pay more than once. Which vendor gets paid can be decided arbitrarily or randomly by the broker. This may penalize vendors, but eliminates any financial motivation a vendor might have had to cheat by redistributing coins he has collected to other vendors.

80 4.1

Security Properties

We distinguish between small-scale attacks and large-scale attacks. We believe that users and vendors will have little motivation to cheat in order to gain only a few cents; even if they do, the consequences are of no great concern. This is similar to the way ordinary change is handled: many people don't even bother to count their change following a purchase. Our security mechanisms are thus primarily designed to discourage large-scale attacks, such as massive forgery or persistent double-spending. Forgery Small-scale forgery is too expensive to be of interest to an adversary: with the recommended choice of/~ = 4, n = 54, and u = 31, the generation of the first forged coin requires about 245 hash operations. Since a standard work-station can perform only 214 hash operations per second, a typical user will need 231 seconds (about. 80 years) to generate just one forged coin on his workstation. Large-scale forgery can be detected and countered as follows: - All forged coins automatically become invalid at the end of the month. - Forged coins can not be generated until after the broker announces the new monthly coin validity criterion at the beginning of the month. - The use of hidden predicates (described below) gives a finer time resolution for rejecting forged coins without affecting the validity of legal coins already in circulation. - The broker can detect the presence of a forger by noting when he receives coins correspondings to bins that he did not produce coins from. This works well in our scenario since only about half of the bins produce coins. To implement this the broker need only work with a bit-array ha.xring one bit per bin. - The broker can at any time declare the current period to be over, recall all coins for the current period, and issue new coins using a new validation procedure. - The broker can simultaneously generate coins for several future months in a longer computation, as described below; this makes it harder for a forger to catch up with the broker.

Theft of coins If theft of coins is .judged to be a problem during initial distribution to users or during redemption by vendors, it is easy to transmit coins in encrypted form during these operations. User/broker and vendor/broker relationships are relatively stable, and long-term encryption keys can be arranged between them. To protect coins as they are being transferred over the Internet from user to vendor, one can of course use public-key techniques to provide secure communication. However, in keeping with our desire to minimize or eliminate public-key operations, we propose below another mechanism, which makes coins user-specific. This does not require public-key cryptography, and makes it harder to re-use stolen coins.

81 Another concern is that two vendors m a y collude so that both a t t e m p t to redeem the same coins. The recommended solution is that a broker redeem a coin at m o s t once, as discussed earlier. Since this m a y penalize honest vendors who receive stolen coins, we can make coins vendor-specific as well as user-specific, as described below.

Double-spending Since the MicroMint scheme is not anonymous, the broker can detect a doubly-spent coin, and can identify which vendors he received the two instances from. He also knows which user the coin was issued to. With the vendors' honest cooperation, he can also identify which users spent each instance of that coin. Based on all this information, the broker can keep track of how m a n y doublyspent coins are asssociated with each user and vendor. A large-scale cheater (either user or vendor) can be identified by the large number of duplicate coins associated with his purchases or redemptions; the broker can then drop a largescale cheater from the system. A small-scale cheater may be hard to identify, but, due to the low value of individual coins, it is not so i m p o r t a n t if he escapes identification. MicroMint does not provide any mechanism for preventing purely malicious framing (with no financial benefit to the framer). We believe that the known mechanisms for protecting against such behavior are too cumbersome for a light-weight m i c r o p a y m e n t scheme. Since MicroMint does not use real digital signatures, it m a y be hard to legally prove who is guilty of duplicating coins. Thus, a broker will not be able to pursue a cheater in court, but can always drop a suspected cheater from the system. 4.2

Variations

U s e r - s p e c l f i c coins We describe two proposals for making coins that are user-specific in a way that can be easily checked by vendors. Such coins, if stolen, are of no value to most other users. This greatly reduces the motivation for theft of coins. In the first proposal, the broker splits the users into "groups," and gives each user coins whose validity depends on the identity of the group. For example, the broker can give user U coins that satisfy the additional condition h'(xl, x 2 , . . . , xk) = h'(U), where hash function h' produces short (e.g. 16-bit) output values that indicate U's group. A vendor can easily cheek this condition, and reject a coin that is not tendered by a member of the correct group. The problem with this approach is that if the groups are too large, then a thief can easily find users of the appropriate group who might be willing to buy stolen coins. On the other hand, if the groups are too small (e.g. by placing each user is in his own group), the broker m a y be forced to precompute a large excess of coins, just to ensure that he has a large enough supply to satisfy each user's unpredictable needs. In the second proposal, we generalize the notion of a "collision" to more complicated combinatorial structures. Formally, a coin ( x l , . . . , xk) will be valid

82 for a user U if the images Yl = h ( x l ) , Y2 = h(x2), . . . , yk = h(xk) satisfy the condition Yi+l Yi = di (mod 2 u) -

fori=

1, 2 , . . . , k - 1 ,

-

where (dl, d 2 , . . . , dk-1) .= h*(U)

for a suitable auxiliary hash function h t. (The original proposal for representing coins as collisions can be viewed as the special case where all the distances di's between the f bins are zero.) To mint coins of this form, the broker fills up most of his bins by randomly tossing bails into them, except that now it is not necessary to have more than one ball per bin. We emphasize that this pre-computation is not. user-specific, and the broker does not need to have any prior knowledge of the number of coins that will be requested by each user, since each good ball can be used in a coin for any user. After this lengthy pre-computation, the broker can quickly create a coin for any user U by Computing ( d , , . . . , d~-l) = h'(U). Picking a random bin index Yl. (This bin should have been previously unused as a Yl for another coin, so that Yl can be used as the "identity" of the coin when the broker uses a bit-array to determine which coins have already been redeemed.) - Computing yi+i = yi + di (mod 2 ~) for i = 1, 2 . . . . . k - 1, - Taking a ball Xl out of bin Yl, and taking a copy of one ball out of each bin Y2, . . . , Yk. (If any bin Yi is empty, start over with a new Yl-) Note that balls m a y be re-used in this scheme. - Producing the ordered k-tuple ( x l , . . . , xk) as the output coin. -

A convenient feature of this scheme is that it is easy to produce a large number of coins for a given user even when the broker's storage device is a magnetic disk with a relatively slow seek time. The idea is based on the observation that if the Yl values for successive coins are consecutive, then so also will be the y~ values for each i, 1 < i <_ k. Therefore, a request for 2500 new coins with k = 4 requires only four disk seeks, rather than 10,000 seeks: at 10 milliseconds per seek, this reduces the total seek time from 100 seconds to only 40 milliseconds. Note that in principle coins produced for different users could re-use the same ball x~. Conceivably, someone could forge a new coin by combining pieces of other coins he has seen. However, he is unlikely to achieve much success by this route unless he sees balls from a significant fraction of all the bins. For example, suppose that there are 2 al bins, of which the forger has seen a fraction 2 - l ~ (i.e., he has collected 22* balls from coins spent by other users). Then the expected number of coins he can piece together from these bails that satisfy the condition of being a good coin for himself is only 23'(2-s~ 3 = 2. (Even if he had 1000 customers for these coins, he would expect to make only 2000 coins total, or two coins per customer on the average.) Thus, we are not too concerned about this sort of "cut-and-paste" forgery.

83

Vendor-specific coins To further reduce the likelihood that coins will be stolen, the user can give coins to vendors in such a way that each coin can be redeemed only by a small fl'action of the vendors. This technique makes a stolen coin less desirable, since it is unlikely to be accepted by a vendor other than the one where it was originally spent. The additional check of validity can be carried out both by the vendor and by the broker. (Having vendor-specific coins is also a m a j o r feature of the Millicent [10] scheme.) The obvious difficulty is that neither the broker nor the user can predict ahead of time which vendors the user will patronize, and it is unreasonable to force the user to purchase in advance coins specific for each possible vendor. Millicent adopts the alternative strategy whereby the user must contact the broker in real-time whenever the user needs coins for a new vendor. (He also needs to contact the broker to return excess unused coins that are specific to that vendor.) We can overcome these problems with an extension of the user-specific scheme described above, in which the user purchases a block of "successive" MicroMint coins. Intuitively, the idea is the following. Choose a value v (e.g. 1024) less than u. Let a u-bit bin-index y be divided into a u - v-bit upper part y' and a v-bit lower part y ' . We consider that y' specifies a "superbin" index and that y" specifies a bin within that superbin. A user now purchases balls in bulk and makes his own coins. He purchases balls by the superbin, obtaining 2 ~ bails per superbin with one ball in each bin of the superbin. He buy k superbins of balls for 2" cents. A coin from user U is valid for redemption by vendor V if: Y~+I = y ~ + d ~

(mod2 "-~)fori=l,...,k-1,

and "

Yi+l

=

"

Yi

q-di

"

( m o d 2 ~) f o r i

=

1,

...,

k

-

1..

where h'(u)

=

(4,

..

, d ~' _ l )

...,

d k"_ l )

and h"(V) = (4',

.

The broker chooses the next available superbin as the first superbin to give the user; the other superbins are then uniquely determined by the differences {d~} defined by the user's identity and the choice of the first superbin. Analogously, to make a coin for a particular vendor the user chooses a ball fl'om the next bin from his first superbin, and must use balls from bins in the other superbins that are then uniquely determined by the differences {d~'} defined by the vendor's identity and the choice of the first bin. Note that balls from the first superbin are used only once, to permit detection of double-spending, whereas balls from the other superbins m a y appear more than once (in coins paid to different vendors), or not at all. It m a y be difficult for a broker to create superbins that are perfectly full even if he throws more balls. He might sell superbins that are almost full,

84 but then a user may have diff• producing some coins for some vendors. To compensate, the broker can reduce the price by one cent for each empty bin sold. S i m u l t a n e o u s l y g e n e r a t i n g balls f o r m u l t i p l e m o n t h s Our major line of defense against large-scale forgery is the fact that the broker can compute coins in advanc% whereas a forgery attempt can only be started once the new validity condition for the current month is announced. We now describe a technique whereby computing the balls for a single month's coins takes eight months, but the broker doesn't fall behind because he can generate balls for eight future months concurrently. The forger wilt thus have the dual problems of starting late and being too slow, even if he uses the same computational resources as the reM broker. In this method, the broker changes the monthly validity criterion, not by changing the hash function h, but by announcing each month a new value z such that ball x is good when the high-order t bits of h(x) are equal to z. The broker randomly and secretly chooses in advance the values z that will be used for each of the next eight months. Tossing a ball still means performing one hash function computation, but the tossed ball is potentially ~!good" for any of the next eight months, and it, is trivial for the broker to determine if this is the case. In contrast, the forger only knows the current value of z, and can not afford to memorize all the balls he tosses, since memory is relatively expensive and only a tiny fraction (e.g., 2 -21 in our running example) of the bails are considered "good" at any given month. We now describe a convenient way of carrying out this calcule~tion. Assume that at the beginning of the month j, the broker has all of the balls needed for month j, 7/8 of the balls needed for month j + 1, 6/8 of the balls needed for month j + 2, ..., and 1/8 of the balls needed in for month j + 7. During month j, the broker tosses balls by randomly picking x values, calculating y = h(x), and checking whether the top-most t bits of y are equal to any of the z values to be used in months j + 1, . . . , j + 8. To slow the rate at which he generates good balls for each upcoming month, he increases n and t each by three. After the month-long computation, we expect him to have all the coins he needs for month j + 1, 7/8 of the coins he needs for month j + 2, and so on; this is the desired "steady-state" situation. 'The broker needs four times as much storage to hold the balls generated for future months, but balls for fllture months can be temporarily stored on inexpensive magnetic tapes because he doesn't need to respond quickly to user requests for those coins yet. Hidden Predicates The "hidden predicate" technique for defeating forgers works as follows. We choose rn > n, and require each m-bit pre-image to satisfy a number of hidden predicates. The hidden predicates should be such that generating pre-images satisfying the predicates is easy (if you know the predicate). To generate an xi, one can pick its last n bits randomly, and define the j-th bit of xi, for j = r n - n , . . . , 1, to be the j-th hidden predicate applied to bits j + 1 , . . . , m of xi. The hidden predicates must be balanced and difficult to learn from random examples. Suggestions of hard-to-learn predicates exist, in the learning-theory

85 literature. For example the parity/majority functions of Blum et at.[4] (which are the exclusive-or of some of the input bits together with the majority function on a disjoint set of input bits) are interesting, although slightly more complicated functions may be appropriate in this application when word lengths are short. With rn - n = 32, the broker can have one hidden predicate for each day of the month. He could reveal a new predicate each day, and ask vendors to check that the coins they receive satisfy these predicates (otherwise the coins will not be accepted by the broker). This would not affect the validity of legitimate coins already in circulation, but makes forgery extremely difficult, since the wouldbe forger would have to discard much of his precomputation work as each new predicate is revealed. We feel that such techniques are strongly advisable in MicroMint. Other Extensions Peter Wayner (private communication) has suggested a variation on MicroMint in which coins of different values are distinguished by publicly-known predicates on the x-values.

5

Relationship

to Other

Micropayment

Schemes

In this section we compare our proposals to the Millicent[10], NetBill [1], NetCard [2], and Pederson [14] micropayment schemes. NetBill offers a number of advanced features (such as electronic purchase orders and encryption of purchased information), but it is relative expensive: digital signatures are heavily used and the NetBill server is involved in each payment. Millicent uses hash functions extensively, but the broker must be on-line whenever the user wishes to interact with a new vendor. The user buys vendorspecific scrip from the broker. For applications such as web browsing, where new user-vendor relationships are continually being created, Millicent can place a heavy real-time burden on the broker. Compared to Millicent, both PayWord and MicroMint enable the user to generate vendor-specific "scrip" without any interaction with the broker, and without the overhead required in returning unused vendor-specific scrip. Also, PayWord is a credit rather than debit scheme. Anderson, Manifavas, and Sutherland [2] have developed a micropayment system, "NetCard," which is very similar to PayWord in that it uses chains of hash values with a digitally signed root. (The way hash chains are created differs in a minor way.) However, in their proposal, it is the bank rather than the user who prepares the chain and signs the root, which adds to the overall burden of the bank. This approach prevents the user from creating new chains, although a NetCard user could spend a single chain many times. Compared to PayWord, NetCard is debit-based, rather than credit-based. We have heard that a patent has been applied for on the NetCard system. Torben Pedersen outlines a mieropayment proposal[14] that is also based on hash chains. His motivating application was for incremental payment of telephone charges. His paper does not provide much detail on many points (e.g.

86 whether the system is credit or debit-based, how to handle exceptions, whether chains are vendor-specific, and other auxiliary security-related matters). The C A F E project has filed for a patent on what we believe is an elaboration of Pedersen's idea. (The details off the CAFE scheme are not available to us.) Similarly following Pedersen's exposition, the iKP developers Hauser, Steiner, and Waidner have independently adopted a similar approach [8].

6

Conclusions and Discussion

We have presented two new micropayment schemes which are exceptionally economical in terms of the number of public-key operations employed. Furthermore, both schemes are @ l i n e from the broker's point of view.

References i. The NetBill Electronic Commerce Project, 1995. http ://www. ini. cmu/NETBILL/home, html. 2. Ross Anderson, t-larry Manifavas, and Chris Sutherland. A practical electronic cash system, 1995. Available from author: Ross. Anderson@cl. cam. ac.uk. 3. Matt Blaze, Whitfield Diffie, Ronald L. Rivest, Bruce Schneier, Tsutomu Shimomura, Eric Thompson, and Michael Wiener. Minimal key lengths for symmetric ciphers to provide adequate commercial security: A report by an ad hoc group of cryptographers and computer scientists, Jmmary 1996. Available at http : //www. bsa. org. 4. Avrim Bhim, Merrick Purst, Michael Kearns, and Richard J. Lipton. Cryptographic primitives based on hard learning problems. In Douglas R. Stinson, editor, Proc. CRYPTO 93, pages 278-291. Springer, 1994. Lecture Notes in Computer Science No. 773. 5. Shimon Even, Oded Goldreich, and Silvio Micali. On-line/off-fine digital signatures. In G. Brassard, editor, Proc. CRYPTO 89, pages 263-277. Springer-Verlag, 1990. Lecture Notes in Computer Science No. 435. 6. Phillip Hallam-Baker. W3C payments resources, 1995. http ://www. w3. org/hypert ext/WWW/Payment s/overview, html. 7. Nell M. Hailer. The S/KEY one-time password system. In ISOC, 1994. 8. Ralf Hauser, Michael Steiner, and Michael Waidner. Micro-Payments based on iKP, December 17, 1995. Available from authors, s t i 0 z u r i c h , ibm.com. 9. Leslie Lamport. Password authentication with insecure communication. Communications of the A CM, 24(11):770-771, November 1981. 10. Mark S. Manasse. Millicent (electronic microcommerce), 1995. http ://www.research, digital, com/SRC/pers onal/Mark3~anasse/uncommon/ucom, html. I1. Ralph C. Merkle. A certified digital signature. In G. Brassard, editor, Proc. CRYPTO 89, pages 218-238. Springer-Verlag, 1990. Lecture Notes in Computer Science Noo 435. 12. Silvio Micali. Efficient certificate revocation. Technical Report TM-542b, MIT Laboratory for Computer Science, March 22, 1996. 13. National Institute of Standards and Technology (NIST). F/PS Publication 180: Secure Hash Standard (SHS), May 11, 1993.

87 14. Torben P. Pedersen. Electronic payments of small amounts. Technical Report DAIMI PB-495, Aarhus University, Computer Science Department, ~rhus, Denmark, August 1995. 15. Ronald L. Rivest. The MD5 message-digest algorithm. Internet Request for Comrnents, April 1992. RFC 1321. 16. Bruce Schneier. Applied Cryptography (Second Edition). John Wiley & Sons, 1996. 17. Adi Shamir. Fast signature screening. CRYPTO '95 rump session talk; to appear in RSA Laboratories' CryptoBytes. 18. Peter Wayner. Digital Cash: Commerce on the Net. Academic Press, 1996.

Transactions Using Bets David Wheeler Computer Laboratory, University of Cambridge, England; email djw30cl, cam. ac .uk

Abstract. Small cash transactions, electronic or otherwise, can have their overhead costs reduced by Transactions Using Bets ( TUB ), using probablistic expectation (betting) as a component. Other types of protocols may also benefit from this idea.

Introduction In small cash p a y m e n t systems there is a need to keep the various transaction costs to a minimum. This can be done by using betting as a component of the p a y m e n t protocol. We first show the principle with physical money where it also has advantages and then consider how it can be used to enhance electronic p a y m e n t systems.

Real M o n e y Consider a p a y m e n t of 37 cents. For it to take place a m i n i m u m of four coins must be transferred. Consider how the payment can take place if the payer and seller have only dollar bills. It is assumed for simplicity we have a fair hundred sided dice, numbered 1 to 100. After the participants have agreed on the transaction, the dice is thrown. If the result is 1-37 the payer gives the seller one dollar, otherwise he gives him nothing. If the transaction is repeated m a n y times the average cost is 37/100 of a dollar, which is correct and unbiased. There are well known ways of ensuring the dice is unbiased, but we will not discuss them here. Hundred sided dice are a little difficult to obtain, but 20 sided dice numbered 0-9 twice over quite easy to obtain. To use one in the example above, we just throw the dice once, if it has values 0-2 the payment is made, if the value is three we throw the dice again and pay up if it has the value 0-6. The number of times the dice has to be thrown is not much more than once. The average number of extra throws is about 1/9 even for complicated values such as 3.14159265 cents. This transaction is just if both parties agree, and if they make m a n y such transactions the chance of gaining or losing much is quite small.

90 In one hundred such transactions with the costs being 1-100 the chance of being more than 3 cents per transaction out is about i / 3 and chance of winning or losing equal. The chance of being more than 6 cents out is about 1/22. Statistics show that as the number of transactions increase, the total gain or loss is likely to increase but the gain or loss per transaction will decrease.

probability of one in transactions prices unit 6.3 44 740 31000 for gain or loss per transaction to exceed 1 1-I00 100 4 1-!00 100 10 1-100 100 10 100 1~100 100 3 6 1000 1-100 100 1 2 3 10000 1-100 100 .3 .6 .9 100,000 1-100 100 .1 .2 .3 .4 1-100 100 .03.06 .09 .12 1000,000 Table showing approximate loss or gain probabilities. Thus if we abolish small value coins and accept the fun of betting, we can save some transaction costs. The scheme has obvious advantages for bus fares, simplifying coin machines, etc. even if we do not eliminate most coins and save the government from coining them. In some cases more benefits can be obtained. Consider toll collection on highways and bridges. If the cost is say 50 cents, we could have one collection booth with a notice such as "toll $10 or zero, average 50 cents". Then there is almost no slowing caused by giving change. We can improve the situation by arranging traffic deflection into one of two lanes according to a "dice". In this case 19/20ths of the traffic would not have to stop, with obvious benefits to drivers feeling, fuel consumption, number of toll booths needed etc. A few old style collection booths would be needed as well, so the customer had a choice. As in any transaction, a few obvious precautions should be taken to avoid fraud by either of the parties. User Reaction Whether the users will like the fun introduced into transactions is difficult to say. It ought to add interest to life like other random events, weather, lotteries etc. However, although there is a gambling element, as the number of transactions increase, the gamble becomes smaller. Bookies do not ( or do not need to ) gamble, because the statistics protect them. In the same way the users become protected as the system is used more and more.

91

There are presentation issues which we will not discuss. For example, should the promoter share the saving with the buyer by giving a "betting discount", perhaps better phrased as a "No Change Discount"? An electronic betting protocol step The purpose of this paper is not to design complete protocols but to give some component steps which can be incorporated in many protocols to their advantage. In cash payment protocols, after the transaction is agreed, one step is to transfer a number of ~coins' from the buyer to the seller. In many such protocols, in order to avoid the overheads of splitting coins or giving change, the payment is made as the transfer of a large number of coins, each of which is a number with properties which allow the detection of coin duplication etc. Such a step or steps can be replaced by a betting protocol such as the steps given below. 1) the seller sends r=h(R), the hash of a random number to the buyer. 2) the buyer sends the coin "number" to the seller. 3) the seller sends R to the buyer. 4) the buyer checks that r=h(R). 5) the buyer and seller work out R+number-cost, determine whether the charge is the coin or nothing, and take action accordingly. The above assumes the coin number, or parts of it, are sufficiently unpredictable to be used as a random number, otherwise the the buyer can also generate a random number and send it adjoined to the coin number. The hash is assumed to be a suitable one way function and the necessary scaling factors needed to convert the random numbers into the appropriate numbers for the transaction are also assumed. If the above is completed satisfactorily, the modes of failure will not have increased for the protocol in which these steps replace the payment step. There is the possibility of either party duplicating the coin, but this possibility existed before. The transaction can be aborted before step 2, which is the commitment step. If the coin is found to be faulty in step 2 then the original protocol will presumably take the proper action. There is an apparent extra mode of failure. The seller can send a faulty R or fail to send any R at all. These cases correspond in the original protocol for the sending of the coin to be half done or incomplete at the receiver. Thus the original protocol should be able to cope. Thus we can make the slightly exaggerated assertion that no new modes of failure have been introduced. However, their probabilities will have been altered. But when the new steps are introduced into the protocol, the optimisation and checking of the design will need to be done again, so coping with the altered probabilities will be part of that design process.

92 Alternative protocols

There are many variations of the given protocol. For example, the buyer could send the coin only if necessary. In the delightful protocol given for Micromint by Ron Rivest and Adi Shamir [1] we can arrange to send 3/4 of a coin which is sufficient to verify it but not cash it, and complete the protocol by sending the last quarter of the coin if it is necessary after the "dice" is examined. A simpler alternative is to assume auditing will cause the seller to be honest. This was implied in the toll payment system given in the introduction. The steps become 1) The buyer sends the coin number. 2) The seller sends the result of the random discrimination to the buyer. 3) One party nullifies the coin.

Protocol Extension

The method illustrated above will allow protocol extensions. Using the Micromint example, instead of buying 37 pages by 37 one cent coins or 37 one hundredth separate chances of a dollar, we can now pay for them all by a single betting transaction using a dollar coin. A further possibility exists that we could now arrange for a page to be charged at 1.1 cents with almost no increase in the costs of the transactions. In fact the need for multiple coins in a transaction could almost be eliminated. If a buyer does not care about the fluctuations in the average, he might prefer a larger coin. The use of 100 dollar coins would almost eliminate the need for multiple coin transactions, and allow the costs of the transactions to be kept very low, although the fraud precautions may have to be increased:

Conclusions Zero average loss betting can often improve small cash transactions by reducing the costs. As one component of a protocol design it will require different optimisations to the basic design, but is likely to give improvements. This is true for both physical and electronic coins. References 1. Micromint, Ronald L. Rivest and Adi Shamir, This Volume. 2. "Heads I win, tails you lose", Economist June 13 1992 p84.

Protocol Failures for RSA-Like Functions Using Lucas Sequences and Elliptic Curves Marc Joye 1 and Jean-Jacques Quisquater 2 1 UCL Crypto Group, Drip. de Mathdmatique, Universit~ de Louvain Chemin du Cyclotron, 2, B-1348 Louvain-la-Neuve (Belgium) E-mail: j [email protected], ac. be 2 UCL Crypto Group, D@. d'Electricit~, Universit~ de Louvain Place du Levant, 3, B-1348 Louvain-la-Neuve (Belgium) E-mail: j [email protected], ac.be URL:

ht tp ://www. dice. ucl. ac. b e / c r y p t o/crypt o. html

A b s t r a c t . We show that the cryptosystems based on Lucas sequences and on elliptic curves o v e r a ring are insecure when a linear relation is known between two plaintexts that are encrypted with a "small" public exponent. This attack is already known for the classical RSA system, but the proofs and the results here are different.

1

I n t r o d u c t i o n

In numerous situations, the difference between two plaintexts is known, as for example, - texts differing only from their date of compilation; letters sent to different destinators; retransmission of a message with a new ID number due to an error;

On the other hand, the security of public-key cryptosystems relies on trapdoor one-way functions. A trapdoor one-way function is a function easy to compute but infeasible to invert unless the trapdoor is known 9 Many trapdoor one-way functions are using a polynomial in a given algebraic structure (think about RSA). Recently, some researchers [9, 25, 5, 6] were able to exploit such a structure to mount a new attack against well-known protocols. Here, we show that this attack is of very general nature and not specific to RSA. The paper is organized as follows. First, we review the cryptosystems based on Lucas sequences and on elliptic curves over a ring. Next, we review the attack on the RSA. Finally, we show how to generalize it and give a short analysis.

2

RSA-like functions

Two years after the introduction of the concept of public-key cryptography [8], Rivest, Shamir and Adleman [29] presented the RSA cryptosystem. After this

94 breakthrough, many generalizations were presented (e.g. using polynomials), and broken. Recently, it has been adapted to work with other structures. In [16], Koyama, Maurer, Okamoto and V~nstone, and, later Demytko [7] pointed out the existence of new one-way trapdoor functions similar to the RSA on elliptic curves defined over a ring. In 1993, the system proposed by Miiller and NSbauer [22], in 1981, re-emerged to construct the LUC cryptosystem [32]. This latter system uses a special type of Lueas sequences, and is an alternative to the RSA. In what follows, we shall describe the RSA-like functions used with Lucas sequences and on elliptic curves. The reader who is not familiar with these structures is invited to consult references [3, 27, 28] for Lucas sequences and [4, 11, 21, 30] for elliptic curves. 2.1

LUC function

Each user chooses two secret and "random" large primes p and q, and publishes their product n = pq. Next, he chooses a public encryption key e which is relatively prime to (p - 1), (p + 1), (q - 1) and (q + 1). To send a message M to Bob, Alice looks to Bob's public key e, and using the Lucas sequence {ld}, she forms the ciphertext C = V~(M, 1) mod n. Since Bob knows the factors p and q, he is able to compute the secret decryption key d according to ed - 1 (rood ~(n)), where ~(n) = lcm(p - (D/p), q - (D/q)) and D = M 2 - 4 . * Therefore, Bob can recover the message M by computing Vd(V~(M, 1), 1) - V~a moa~(~)(M, 1) = VI(M, 1) =- M (rood ~).

2.2

K M O V * * / D e m y t k o ' s functions

Before presenting these systems, we show a na/ve trapdoor one-way function using elliptic curves over a ring. Similarly, each user chooses two large primes p and q. Moreover, he chooses two parameters a and b such that gcd(4a a + 27b~,n) = 1, where n = pq. Next, he computes the order of the elliptic curves Ep(a, b) and Eq(a, b). He chooses a public encryption key e relatively prime to -J/:Ep(a, b) and #Eq(a, b), and computes the secret decryption key d such that ed - 1 (mod N~.), where N~ = lcm(~:Ep(a, b), •Eq(a, b) ). The public parameters are n, e, a and b. Before doing, the message M must be associated to a point M = (m~, my) on the curve En(a, b). For this, in a publicly known way, redundancy is introduced to M so that m,:3 + am~ + b is a quadratic residue modulo n. To sign the message M" with her secret key d, Alice computes C E E~ (a, b) according to C = dM. To verify the signature, Bob checks that eC is equal to M.

* (D/p) denotes the Legendre symboI and is equal to 1 or - 1 whether D is a quadratic residue modulo p or not. ** From the last names of inventors Koyama, Maurer, Okamoto and Vanstone.

95 This function may only be used in a digital signature scheme, because the trapdoor is required to associate a point of E,~(a, b) to M. Moreover, the signature is twice as long as the message M. To overcome these shortcomings, new one-way trapdoors functions were proposed. K M O V f u n c t i o n In that system, the primes p and q are both congruent to 2 modulo 3, and the parameter a is equal to 0. In that case, N~ = lcm(#Ep(0, b), #Eq(O, b)) = lcm(p + 1, q + 1). Since N,~ does not depend on b, the parameter b is chosen according to b --

rr~ 2

-

3 rood n.

m x

Remarks. 1) The minimum possible value of the public key e is 5, because 6 divides N~ and e must be relatively prime to N~. 2) It is also possible to work on the elliptic curve E~(a, 0), if one chooses p and q congruent to 3 modulo 4. D e m y t k o ' s f u n c t i o n The parameters n, a, b and e are chosen as before. To encrypt M = (m~, my), Alice computes C = (c,, cy) = eM. To decrypt the ciphertext C, Bob computes diC = diem = M, where the deeryption key is chosen so that edi - 1 (rood Nn,i) (i = 1 , . . . , 4 ) ,

with

{

N~,I = l c m ( # E p (a, b), @Eq(a, b)) N,~,2 l c m ( # E p (a, b), #Eq(a, b)) N~,a lcm(#Ep(a,b),#pEq(a,b))

N~,4

lcm(#Ep(a, b), #Eq(a, b))

if if if if

(w/p) (w/p) (w/p) (w/p)

= 1 and (w/q) = 1 = 1 and (w/q) ~k 1 • 1 and (w/q) = 1' • 1 and (w/q) r 1

3

and w = % + ac~ + b mod n.***

Remarks. 1) It is possible to construct a message independent cryptosystem by choosing p and q so that # E v ( a , b) = p + 1 and ~:Eq(a, b) = q + 1. 2) The computation of the second coordinate can be avoided if the algorithm described in [3] is used. 3

Description

At the rump session failure for RSA with extended by Patarin this kind of attack to

of the

attack

of Cryp~o '95, Franklin and Reiter [9] showed a progocol a public encryption exponent equal to 3. This was later [25, 6] for exponents up to _~ 32 bits. We shall generalize protocols based on LUC and on elliptic curves over a ring.

*** Ep(a, b) denotes the complementary group of Ep(a, b).

96 3.1

Review of the attack

Suppose that two plaintexts M1 and M2 satisfy the known linear relation M2 = MI + A, and are encrypted with the same RSA function to produce the corresponding ciphertexts C1 = M[ mod n and C2 = M~ mod n, respectively. An intruder can recover M1 (and M2) from C1, C2 and A as follows. 1. Let 7) and Q be the polynomials in the indeterm}nate x defined by 7)(x)=x ~-C1

and

Q(x)=(x4-z&) r

(modn).

2. Since M1 is a root of P and of Q, the message ~/I1 will be a root of

= gcd(P, Q). Solving the polynomial 7~, that is of degree 1 with a very high probability, will give the value of the plaintext M1. Example i. With exponent e = 3, the plaintext M1 is given by M1 = A(2C1 4- C2 - Aa) mod n, - C 1 4- C2 4- 2A 3 andM2=Ml+A. 3.2

Extension to Lucas sequences

Let M1 and M2 ----- M1 4- z~ be two plaintexts encrypted by a LUC system to produce the ciphertexts C1 = Vr mod n and C2 = Vr 1) rood n, respectively. Unlike RSA, the polynomial relation between the plaintext and the ciphertext is not explicitly given. We need the following proposition. P r o p o s i t i o n 1 . Let {Vk} be the Lucas sequence with parameters P and Q = 1. Then i= l

i odd

"-~/

So, it is possible to express recursively Vk (P, 1) as a polynomial of degree k in the indeterminate P. Consequently, the previous attack applies with P(x) = V ~ ( x , 1 ) - C 1 and Q ( x ) = V~(x 4- A , 1 ) - C 2 (modn). Example2. With a public encryption exponent e = 3, the plaintext M1 can be recovered from C1, C2 and A by M1 = A(2C1 + C2 -- A3 -4- 3A) mod n, -C1 4- C2 4- 2A 3 - 6A and M2 = M1 4- A.

97 3.3

E x t e n s i o n to elliptic c u r v e s

To extend the attack to elliptic curves, we need to introduce the division polynomials (see [30]). They allow to compute the multiple of a point in terms of the first coordinate. D e f i n i t l o n 2 . The division polynomials k~,~ E Z[a,b,x,y], are inductively defined by k~l = 1, ~ 2 = 2 y , ~ 3 = 3 x 4 + 6 a x ~ + 1 2 b x - a 2, ~4 = 4Y(X 6 + 5a x4 -]- 20bx 3 - 5aBx 2 - 4abx - 8b 2 - a3),

~+1

= ~ . ~ + 2 ~ - ~-1~m~+1

2y~2rn = ~m(~rn+2ktTr2

(-~ > 2),

1 -- ~ r a _ 2 ~ 2 + 1 )

( m ~ 2).

P r o p o s i t i o n 3 . Let E~(a,b) be an elliptic curve over the ring Z~. Define the polynomials ~k and wk by

4yw~ = k~'k+2lF~_ 1 -- k//k_2k~t:+ 1 . (a) ~k, ~k, Y - l ~ k (fork odd) and (2y)-l~k, ~k, ~k (fork even) are polynomials in Z[a, b, x, y2]. Hence, by replacing y2 by x3-l-ax2-l-b, they will be considered as polynomials in Z[a, b, x]. (b) As polynomials in x, ~k (x) = x k~ + lower order terms, ~Pk(x) 2 = k2 x k;-1 + lower order terms are relatively prime polynomials. wk(P)

N

(e) If p ~ E~(a,~), the~ kP = \,~k(p)~, ~,~(p)~ )

(mod n).

To illustrate the attack, we shall only focus on the first coordinate. Let rnl,~ and rn2,~ = ml,~ + A be the first coordinates of two plaintexts M1 and M2, and let c1,~ and cB,~ be the first coordinates of the two corresponding ciphertexts C1 = eM1 and C2 = eM2, respectively. By the previous proposition, we have ~e(mi,x) - ci,xgte(rni,~) 2 - 0

(rood n)

(i E {1, 2)).

This relation allows to construct the following attack. 1. Let P and Q be the polynomials in the indeterminate x of degree e 2, defined by

p(~) = ~ ( ~ ) - e l , ~ ( ~ )

~ a~d c~(~) = ~ o ( ~ + Z ) - e ~ , ~ ( ~ + Z ) :

(mod

~).

2, We compute T~ = gcd(7), Q), which is with a very high probability, a polynomial of degree 1. Solving the polynomial 7~ in x will give the value of ml,x.

98 3.4

Analysis of the new attack

In [25], Patarin considered that, for the RSA, this attack applies with a public encryption exponent e up to typically 32 bits. From proposition 1, the same conclusion holds for LUC. However, this is not true for elliptic curves, since the polynomial relation ~P(x) is of order e 2 instead of e. It means that for the same modulus n, a public exponent e of length f on elliptic curves will be as secure as a public exponent e of length 2g for RSA or LUC. On the other hand, from the polynomials P ( x ) and Q(x) defined as above, we can form the polynomial

~o(A) = Resultantx(P(x), Q(x))

(mod 'n),

which is a univariate polynomial in zl. As showed by Coppersmith in [5], if we call 5 the degree of •(A), then it is possible to solve the polynomial ~ as long as there is a solution less than about n 1/~. So, if the length of A is less than t / 5 times the length of the modulus n, then the technique of Coppersmith enables to recover M1 (and M2) even if the difference A between the two plaintexts M1 and M2 is unknown. Since 5 = e ~ for the RSA and the LUC functions, and 5 = e 4 for the K M O V / D e m y t k o ' s functions, the cryptosystems based on elliptic curves are more resistant against the attack of Coppersmith.

4

Conclusion

We have generalized a known attack for the RSA system, in the following way: "If a cryptosystem enables to exhibit ~ non-trivial polynomial relationship, then we can f o r m two polynomials f r o m two related unknown ruessages to recover them."

We have illustrated this attack on cryptosystems based on Lucas sequences and on elliptic curves over a ring. A c k n o w l e d g m e n t s The authors are grateful to Daniel Bleichenbacher and to Richard Pinch for providing informations about the implementation and the security of the Lucas-based cryptosystems. Many thanks also to Don Coppersmith for showing how to solve a polynomial equation (modulo n).

References 1. Alfred V. Aho, John E. Hopcropft, and Jeffrey D. Ullman. The design and analysis of computer programming. Addison-Wesley, 1974. 2. Daniel Bleichenbacher, Wieb Bosma, and Arjen K. Lenstra. Some remarks on Lucas-based cryptosystems. In D. Coppersmith, editor, Advances in Uryptology Crypto '95, vol. 963 of Lectures Notes in Computer Science, pp. 386-396, SpringerVerlag, 1995.

99 3. David M. Bressoud. Factoriza~ion and priraality testing. Undergraduate Texts in Mathematics, Springer-Verlag, 1989. 4. Henri Cohen. A course in computational algebraic number theory. Number 138 in Graduate Texts in Mathematics. Springer-Verlag, 1993. 5. Don Coppersmith. Finding a small root of an univariate modular equation. IBM Research Report, RC 20223, Nov. 1995. 6. Don Coppersmith, Matthew Franldin, Jacques Patarin, and Michael Reiter. Low exponent RSA with related messages. To appear in Eurocrypt '96. 7. N. Demytko. A new elliptic curve based analogue of RSA. In T. Helleseth, editor, Advances in Cryptology - Eurocrypt '95, volume 765 of Lectures Notes in Computer Science pages 40 49. Springer-Verlag, 1993. 8. Whitfield Diffie, and Martin E. Hellman. New directions in Cryptography. IEEE Trans. on Information Theory, vol. IT-26, no. 6, pp. 644-654, Nov. 1976. 9. Matthew K. Franklin, and Michael K. Reiter. A linear protocol failure for RSA with exponent three. Preliminary note for Crypto '95 rump session. 10. Johan H&stad. On using RSA with low exponent in a public key network, tn H.C. Williams, editor, Advances in Cryptology Crypto '85, vol. 218 of Lectures Notes in Computer Science, pp. 404-408, Springer-Verlag, 1986. 11. Dale HusemSller. Elliptic curves. Number 111 in Graduate Texts in Mathematics. Springer-Verlag, 1987. 12. Marc Joye, and Jean-Jacques Quisquater. Protocol failures for RSA-like functions using Lucas sequences and elliptic curves. UCL Crypto Group Technical Report, CG-1995/4, Dec. 1995. 13. Burton S. Kaliski, Jr. A chosen attack on Demytko's elliptic curve cryptosystem. To appear in Journal of Cryptology. 14. Donald E. Knuth. The art of computer programming: Volume 2//Seminumerical algorithms. 2nd ed., Reading, MA, Addison-Wesley Publishing Company, 1981. 15. Neal Koblitz. A course in number theory and Cryptography. Number 114 in Graduate Texts in Mathematics. Springer-Verlag, 2nd edition, 1994. 16. Kenji Koyama, Ueli M. Maurer, Tatsuaki Okamoto, and Scott A. Vanstone. New public-key schemes based on elliptic curves over the ring ZT~. In J. Feigenbaum, editor, Advances in Cryptology - Crypto '9I, volume 576 of Lectures Notes in Computer Science, pages 252-266. Springer-Verlag, 1991. 17. H. Kuwakado, and K. Koyama. Security of RSA-type cryptosystems over elliptic curves against H&stad attack. Electronics Letters, vo]. 30, no. 22, pp. 1843-1844, Oct. 1994. i8. C.-S. Laih, F-K. Tu, and W.-C. Tai. Remarks on LUC public key system. Electronics Letters, vol. 30, no. 2, pp. 123-124, Jan. 1994. 19. Chi-Sung Laih, Fu-Kuan Tu, and Wen-Chung Tai. On the security of the Lucas function, fnformations Processing Letters 53, pp. 243-247, 1995. 20. Alfred Menezes, Minghua Qu, a n d Scott Vanstone. Standard for RSA, DiffieHellman and related public-key cryptography. Working draft of IEEE P1363 Standard, chapter 6, April 1995. 21. Alfred J. Menezes. Elliptic curve public key Cryptosystems. Kluwer Academic Publishers, 1993. 22. Winfried B. Miiller, and Rupert Ngbauer. Some remarks on public-key cryptosysterns. Sci. Math. Hungar., vol. 16, pp. 71-76, 1981. 23. Winfried B. Miiller, and Rupert N6bauer. Cryptanalysis of the Dickson-scheme. In F. Pichler, editor, Advances in Cryptology - Eurorypt '85, vol. 219 of Lectures Notes in Computer Science, pp. 50-61, Springer-Verlag, 1986.

100

24. S. Murphy. Remarks on the LUC public key system. Electronics Letters, vol. 30, no, 7, pp. 558-559, March 1994. 25. Jacques Patarin. Some serious protocol failures for RSA with exponent e of less than _~ 32 bits. Presented at the conference of cryptography, CIRM Luminy, France, 25-29 Sept. 1995. 26. R.G.E. Pinch. Extending the Hgstad attack to LUC. Electronics Letters, vot. 31, no. 21, pp. 1827-1828, Oct. 1995. 27. Paulo Ribenboim. The little book of big primes. Springe>Verlag, 1991. 28. Hans Riesel. Prime numbers and computers methods.for factorization. Progress in Mathematics, vot. 57, Birkhguser, 1985. 29. R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Commun. A C M 21, pp. 120-126, 1978. 30. Joseph H. Silverman. The arithmetic of elliptic curves. Number 106 in Graduate Texts in Mathematics. Springer-Verlag, 1986. 31. Peter J. Smith, and Michael J. J. Lennon. LUC: A new public key system. In E. G. Douglas, editor~ Ninth IFIP Symposium on Computer Security, pp. 103-117, Elsevier Science Publishers, 1993. 32. Peter Smith. LUC public-key encryption. Dr. Dobb's Journal, pp. 44-49, Jaal. 1993.

Efficient and Provable Security Amplifications R o n a l d C r a m e r ([email protected]) Ivan D a m g s ([email protected]) T o r b e n Pedersen ( t o r b e n p @ d a i m i . a a u . d k CWI, P.O. Box 94079, NL-1090 GB Amsterdam, The Netherlands Aarhus University, Ny Munkegade, DK-8000 Aarhus C, Denmark CryptoMathic, Gustav Wiedsvej 10, 8000 Aarhus C, Denmark

Even, Goldreich and Micali showed at Crypto'89 that the existence of signature schemes secure against known message attacks implies the existence of schemes secure against adaptively chosen message attacks. Unfortunately, this transformation leads to a rather impractical scheme. We exhibit a similar security amplification, which takes the given scheme to a new signature scheme that is not even existentially forgeable under adaptively chosen message attacks. Additionally, however, our transformation will be practical: The complexity of the resulting scheme is twice that of the original scheme. The principles of both transformations carry over to block encryption systems. It is shown how they can be used to convert a block encryption system secure against known ptaintext attacks to a system secure against chosen plalntext attacks. For both schemes it is shown that if the transformed scheme can be broken given a number, T, of encryptions of adaptively chosen plaintexts, then the original scheme can be broken given eneryptions of T uniformly chosen plaintexts. In this case, however, the application of the technique of Even, Goldreich and Micali leads to the more efficient scheme. The transformed scheme has the same key length as the original, and ciphertexts are doubled in length. As an example, when applied to DES the transformed scheme is secure against differential cryptanalysis, which relies on the ability to get encryptions of plaintext pairs with proper differences. Abstract.

102

1

Introduction

Goldwasser, Micali and Rivest [5] distinguish between several levels of security for digital signature schemes. Any such level, is defined by the extent to which an attacker has access to a true signer and the goal of the attacker. A digital signature scheme is said to have a given security level, if the scheme is secure against the corresponding attacker. In the strongest level of security described in [5], the attacker is allowed to first use a true signer as an oracle, i.e., he can obtain a signature on any message of his choice. The attacker's goal is to generate a signature on some new message, i.e., a message he hasn't requested the oracle to sign. A digital signature scheme that is secure against such an attacker is called not existentially foTyeable under adaptively chosen message attacks. This attacker has the weakest possible goal while having the strongest possible access to the signer. Therefore, this level of security is thought to be the most desirable. In [5], a scheme is exhibited with this level of security, under the assumption that a family of claw-free oneway trapdoor permutations exists. After [1], [8] and [10], the matter of secure signature schemes is, at least theoretically, settled: the existence of one-way functions is a sufficient and necessary condition for the existence of signature schemes with this security level. It must be noted, however, that these theoretical schemes have, by their impracticality, little value in real life. We will consider schemes that are not existentially fo~yeable under known plaintext attacks. Here, an attacker has only passive access to the signature oracle. More precisely, the attacker receives signatures on messages that are chosen uniformly at random, after which he has to produce a tbrgery on a new message. Our goal will be to transform a signature scheme that is secure against such an attacker into a signature scheme that is not existentially forgeable under adaptively chosen message attacks. Furthermore, we will demand that the complexity of the resulting scheme is almost the same as that of the original scheme. The resulting transformation is presented in Section 2. In the context of, so-called, on-line/off-line signatures, Even, Goldreich and Mieali gave (in [3]) a transformation whose effect is the same security amplification, but with a loss of efficiency that would make the resulting scheme impractical for most applications where the signer is not able to perform off-line computations. As in [5], and in many other cryptographic schemes, their approach works with two independently generated instances of the signature scheme Z that is given as input. The resulting keys constitute the keys for the instance of ~. Given a message m of length n that is to be signed. The first instance is used to authenticate the concatenation of 2n bit-strings, chosen uniformly at randora by the signer. Bit-wise, the message m is used to select n of these strings which are finally authenticated, one-by-one, using the second instance of Z. For each new message, this procedure is repeated. As a result of this bit-wise signing technique, the complexity of the transformed scheme becomes, roughly, the complexity of Z times the number of bits that are signed. Therefore the transformation from [3] is not suitable to serve as a basis for security amplifications of practical signature schemes.

103

Interestingly, both the technique of [3] and the one used in this paper can also be applied to conventional encryption schemes. As shown in Section 3 this will yield, given an encryption scheme secure against known plaintext attacks, a new scheme secure against chosen plaintext attacks. More precisely, for both transformations it is shown that if the new scheme can be broken (i.e., a given ciphertext is decrypted or the key is recovered) given the encryptions of T chosen plaintexts, then the original scheme can be broken given the encryptions of T randomly chosen plaintexts. Furthermore, if the transformation is based on the principles of [3], then the transformed scheme has the same key space as the original scheme and encryption of one message block requires just one application of the given scheme (plus access to a number of random bits). In particular this implies that attacks on the transformed scheme based on differential cryptanalysis, which require the ability to get encryptions of pairs of plaintexts with proper differences (see [2]), will not be more efficient than attacks, where the plaintexts are chosen uniformly at random. Furthermore, it is shown that the new schemes are not more vulnerable against chosen ciphertext attack that the given scheme.

2

Security

Amplification

of Signatures

A signature scheme, ~, is defined by a tuple (k, M, G, a, V}, where k is the security parameter, M the message space, G a key generation algorithm, o" a signature algorithm and V a verification algorithm. All algorithms are polynomial time in k, and k determines the length of messages that can be signed (see [5] for further details). Let Z be any such signature scheme and let M(k) denote the message space and ]M(k)[ its size corresponding to k. Moreover we assume that M(k) = {0, 1} t(k), where t(k) is some non-constant polynomial in k. Let M(k) denote a subset of M(k) that consists of a negligible 1 large fraction p(k) of M(k). For instance, ~-/(k) could consist of all bit-strings of length t, with the last t/2 bits set to zero. Using 5 as a building block, a new scheme = (k, M, G, -g, V) is constructed as follows:

Message s p a e e The message space for security parameter, k, is M(k) as defined above.

Initialisation Let the security parameter k be given. To generate an instance of ~ , the signer runs G twice, yielding two key-pairs (pkl, skl) and (pkB, sk2). The public-key pk for the instance of Z will be (pkl, pk2), and the secret key sk will be (ski, sk2).

Signing Let m E M(k) be the message to be signed. The signer chooses a random * A non-negative function f : IN --+ IR is negligible iff Vc > 0 3n0 E 1NVn E IN : n > no ~ f ( n ) <

-~

104

pair (rn~, m2), with ml, rn2 E M(k), such that rn, | rn~ = m, and computes cr~(m~) for i = 1, 2, where cr~(rn;) denotes a signature in 2', with respect to the key-pair (pki, ski). The signature, ~(rn), in 5 is (rnl, rn2, (rl(rnl), ~r2(m2)).

Verification To verify a. signature g(m.) on m E M(k) with respect to pk, the receiver checks whether rnl | rn2 • rn, and whether cri(mi) is a valid signature in s with respect to pki for i = 1, 2. It is now shown that if 27 is secure against a known message attack, then Z is secure against a chosen message attack. We first need a lemma which says that it is very unlikely that erl (ml)__and cr2(rnl) corresponding to signatures on two different messages, m, m' E M ( k ) , can be combined to a valid signature in Z. Consider the following game involving two players A and B. Player B submits any member m 1 E 3T(k) to A, and A returns a random pair (ml,m~), with m~, m~ ~ M ( k ) , such that m~ | rn~ = m I. They repeat this procedure, say, r times. This results in a sequence

(m 1, m~, rn~), . .., (rn~, rn~, m~), such that rn{ | rn~ = m j for j = 1 ... r. B is allowed to choose the values of mJ adaptively. B wins if he can find a pair ( ~ ( t u1, m~) such that rn~ @ rn~ E M(k) a n d u : f i v and l _ < u , v _ < r . L e i n m a 2.1 In the game described above, B's probability of losing the game is at least 1 - r(r - 1)p(k). P r o o f Define for 1 < u,v __< r and u ~ v, the stochastic variable X~,~ = m~ | m~. The probability that X~,~ E M(k) is clearly fully determined by A's uniform coin flips, and therefore equal to p(k). As there are r ( r - 1) pairs (u, v), B will win with probability at most r(r - 1)p(k) and hence lose the game with the claimed probability. Now consider the signature scheme Z described above. Let A be any probabilistic polynomial time algorithm that executes an adaptively chosen message attack on Z , and let A's signature requests be on messages

m 1, . . . , m ~(~) ~ ~ ( k ) , with r(k) polynomially bounded. The signer then returns

as required. P r o p o s i t i o n 2.2 If the signature scheme Z is not existentially forgeable under known message attacks, the attacker A has only negligible probability of outputting a signature ~(Fn) in ~ , where Fn # m Ji f o r i = l , .. . , r(k), a n d a ( , ~ ) is a valid signature with respect to pki, with i = 1 or i = 2.

105

P r o o f By standard simulation techniques. Suppose M's probability of success is non-negligible (in k). Let, a signer S in Z, with public key pk, be given. We will use the attacker ~4 to conduct a successful known message attack on signer ,9, thus contradicting the assumption on 2,. Generate an instance (pk', sk') in 2'. Choose i at random in {1,2}, and put pk = pki and pk r = pk3-i. Now present the resulting key (pkl, pk2) for Z to the attacker. The signer S with public key pki, used as a subroutine in the simulation, will output signatures on randomly chosen messages. More specifically, the simulation works as follows. 1. Receive message rn E M ( k ) from the attacker. 2. Receive a signature ~ri(rn~) from S, where S chooses rnr E M(k) uniformly at random. 3. Compute rn3_i = mi | m and o'a-i(rna-i). Forward g(rn) to the attacker. As the attacker cannot distinguish this simulation from a true signer in E, the probability that &(rh) is a forgery of S's signature is halfA's success probability. This is still non-negligible. [] T h e o r e m 2.3 Let ~ be any signature scheme that is not existentially forgeable under known message attacks. Then the signature scheme Z is not existentially forgeable under adaptively chosen message attacks P r o o f Let rh ~ M(k) and let 5"(~) = (rnj,m~,o'l(rnl),C~2(rno)) be a forgery in 2, on a new message, obtained after an adaptively chosen message attack. By Proposition 2.2, except with negligible probability O'l(ml) = cr~(rn~), and cr2(rn2) = ~2(m~), for some u,v with 1 _< u,v < r(k) and u r v (notation as in Proposition 2.2). So we must have that m~ | m~ = rh. However, by Lemma 2.1, this has only negligible probability. [] 3

Symmetric

Encryption

Schemes

Let an encryption scheme with key space, K, plaintext space, M, and eiphertext space, C, be given. Eneryption of m E M under key k E K is denoted by Ek(m) and decryption of e E C under k is denoted by Dk(c). Such a scheme will be denoted by (E, D, K, M, C). As for signature schemes it is possible to classify attacks against an encryption scheme in terms of the goal of the attack and the amount of information, which is available to the attacker. Usually two goals are distinguished: Decrypting a given ciphertext, c E C. - Finding the key. -

Other goals could be to find some information about the key or to find an alternative algorithm for decrypting (corresponding to "universal break" of signatures; see [5]). Of these two goals it is clearly harder to find the secret key than to just decrypt a given eiphertext. Four types of attacks can be distinguished:

106

- Given just the knowledge of the encryption scheme; - Given a number of pairs (m, Ek(m)), where rn is chosen by the owner of k according to some distribution; - Chosen plaintext attack: The attacker may choose adaptively a number of plaintexts, ml, m 2 , . . , and get Ek(rnl), E~(rn2),.. ~. - Chosen ciphertext attack: The attacker may choose adaptively a number of ciphertexts Cl, c 2 , . . , and get Dk(rnl), D~ ( m j , . . . . The last two attack are similar in many situations. Based on these definitions the highest security level of an eneryption scheme is security against getting the key under a chosen plaintext or ciphertext attack. In the following it is shown how the principie used in the previous section can be used to turn a scheme, secure against known plaintext attack where the messages are chosen uniformly at random, into a scheme which is secure against a chosen plaintext attack. This transformation requires twice as iong key and the ciphertext is doubled. This may make the transformed system inadequate for many applications. Therefore, the construction is improved in Section 3.2, where a similar transformation is given which does not double the key size.

3.1

Applying the Basic Method

In the following it will be assumed that M = {0, 1}n for some parameter n, but the construction works for any message space for which - There is a binary operator, Q, on M and a neutral element rn0 E M for this operator such that (M, .69,m0) is a group. - Efficient algorithms for selecting elements in M and computing both ~ and its inverse exist. Given an encryption scheme (E, D, K, M, C) , a new scheme (E(1), D 0 ) , KO), M(1), C(1)) is defined as follows: -

K (I) = K

-

M

-

C(0

x K.

(I) = M . = C

x C.

- E kl,k2 (I) (m) = (Ek~(ml), Ek2(rn2)) where ml is chosen uniformly at random i n M andrn2 = m | -- Igkl,k2~Cl,C2) = Ok,(Cl) @ Dk2(C2).

T h e o r e m 3.1 If (E, D, K, M, C) is secure against known plaintext attacks af-

ter getting T E IN encryptions of uniformly chosen plaintexts. Then (E(1),D(1),KO),M(1),C(1)) is secure against chosen plaintext attacks where the attacker is allowed to choose T plaintexts adaptively. Furthermore, if (E (1), D (1), K (1), M(1)~ CO)) can be broken in a chosen ciphertext attack given decryptions o f T ciphertexts, then (E, D, K, M, C) can be broken in a similar attack also requiring T decryptions.

107

P r o o f The proof goes along the lines of the proof of Proposition 2.2, but is somewhat simpler. First consider a chosen plaintext attack aiming at decrypting a given ciphertext (cx, c2). Then a given ciphertext c can be decrypted in the original system in a known message attack as follows. If k is the (unknown) key in this system we select a key-pair for the new system by choosing i E {1, 2, } at random and letting ki = k and choosing ks-i E K at random. Construct a ciphertext as ci = c and c3-i = Eka_,(m') where m' E M is chosen at random. The chosen plaintext attack can now be simulated in the same way as the adaptively chosen message attack on ~ in the proof of Proposition 2.2. in the end we will get a plaintext rn" corresponding to (cl, c2) and finally output m = rn' | m" as the plaintext corresponding to c. The simulated attack will construct ciphertexts with the same distribution as the real attack. Thus, it will output the plaintext corresponding to (c1, c2) with the same probability, and by the definition of the new scheme the decryption of c is derived correctly. Next consider attack aiming at recovering the secret key. This situation is as above, except that we don't have to generate (Cl, c2). If the attack outputs the entire key, then we can get k as ki. If the attack only outputs one of the two keys we will get k with probability 3' 12 Finally, a chosen ciphertext attack against (E(1), D(1), K(1), M(1), C(1)) can be simulated given a chosen ciphertext attack against. (E, D, K, M, C) in such a way that each decryption in the new scheme requires one decryption in the old scheme. [] An advantage of (E(I), D(Z), K(z), M(1), C(1)) is that if known plaintext attacks against (E, D, t<, M, C) require time linear in IKI (the size of I<), no chosen plaintext attack can be better. A disadvantage is that, although the key length is doubled, exhaustive key search in (E(1),D(1),K(1),M(1),C(Z)) can still be done in time linear in II
3.2

Improving the Security

As mentioned above, the security bound of (E(z), D(Z), K(1), M (1), C(1)) is not satisfactory, and furthermore, it might be too inetficient to use two encryptions in ( E , D , K, M, C) in order to encrypt a single message block. In the following another construction is given, which improves on both of these deficiencies, while keeping the security amplification. This construction can be seen as an application of the principles of [3] to encryption schemes: use the given system (signature or encryption) to instantiate a one-time system (by signing the public key/encrypting the key) and use the one-time system on the input 2 The proof of this case is the reason for choosing k = k~ with probability 89- - in the proofs of the other claims it would have been sufficient to let k = kl with probability 1.

108

(message/plaintext). The new scheme (E(2) , D (2), K(u), M (u), C (2)) is defined as follows: -

K(2) = K.

-

M

-

C (2) :

(2) =

M. C

x C.

=

-

where

is chosen uniformb

at random in M

and ru2 = m 9 ml.

T h e o r e m 3.2 If (E, D, K, M, C) is secure against known pIaintext attacks af-

ter getting T E IN encryptions of uniformly chosen plaintezts. Then (E(2), D (2), K (~), M (2), C (2)) is secure against chosen plaintext attacks where the attacker is allowed to choose T plaintez'ts adaptively. Furthermore, if (E(2), D(2), Kt~), M(2) C(2)) can be broken in a chosen ciphertext attack given decryptions of T ciphertexts, then (E, D, K, M, C) can be broken in a similar attack also requiring T decryptions. P r o o f The proof follows the previous quite closely. Whenever, the attacker against (E(2), D(2), K(2), M (2), C (2)) asks for an encryption of m, the simulator gets a pair (ml,Cl) = (ml,Ek(ml)) for a randomly chosen rnl E M from the owner of k and returns (el, ml | m). This simulator constructs ciphertexts with the same distribution as if they were obtained by proper encryptions in (E(2), D(2), K(2), M(2), C(~)). If the attack aims at decrypting a ciphertext (cl, c2) in (E(2),D(2),K(2),M(2),C (~)) then a ciphertext, c in ( E , D , [ r can be decrypted by choosing el = c and c2 at random and then using the method sketched above to simulate the chosen plaintext attack. If m is the plaintext corresponding to (cl, c2) then m | c2 is the plaintext corresponding to c. If the attack outputs information about the key in (E (2), D (2) , K (9"),M (2), C (2)) , then the same information is obtained about the key in (E, D, K, M, C) as they are equal. Agai11, a chosen ciphertext attack against (E (2) , D (~) , K (2) , M (% , C (2)) can easily be simulated given a chosen ciphertext attack against (E, D, K, M, C) []

4

Other

Applications

The techniques desribed in this paper immediately carry over to message authenticity codes (MAC's) based on pseudo-random functions. We describe this application only briefly, and leave it to the reader to complete the details. Given a family of pseudo-random functions that is secure against known plaintext attacks, we construct a MAC with two independent functions fl and f2 from the family. The message space for the MAC is defined as in our application to signature schemes, i.e., superpolynomiM in the size of the security parameter, but a negligible fraction of the domain of the functions. Splitting a message is also done in the same way. Given a message m and a random splitting ml, m2,

109

the MAC is now computed as ( s f2(rn2). This MAC is then secure against adaptively chosen plaintext attacks. In the context of a special class of proofs of knowledge, "split-and-divert" techniques similar to those employed in this paper, have been used for efficient transformations fi'om honest verifier zero knowledge protocols to witness hiding protocols in [4].

References 1. M. Bellare, S. Micali: How to Sign Given Any Trapdoor Function. Proceedings of STOC '88, pp.32-42. 2. E. Biham, A. Shamir: Differential Cryptanalysis of DES-like Cryptosystems. Proceedings of Crypto'90, pp. 2-21. 3. S. Even, O. Goldreich and S. Micali: On-Line/Off-Line Digital Signatures. Proceedings of Crypto '89, pp.263-275. 4. R. Cramer, I. Damgs B. Schoenmakers, : "Proofs of Partial Knowledge and Simplified Design of Witness Hiding Protocols", Proceedings of Crypto '94, pp.174187. 5. S. Goldwasser, S. Micali and R. Rivest: A Digital Signature Scheme Secure Against Chosen Message Attacks. SlAM Journal on Computing, 17(2): 281-308, 1988. 6. L.R. Knudsen. Personal communication. 7. M. Naor, C. Dwork: An Efficient Existentially Unfo~yeable Signature Scheme and its Applications. Proceedings of Crypto '94, pp.234-246. 8. M. Naor, M. Yung: Universal One Way Hash functions and their Cryptographic Applications. Proceedings of STOC '89, pp.33-43. 9. National Bureau of Standards. Data encryption standard. Federal Information Processing Standard (FIPS), Publication 46, National Bttreau of standards, U.S. De, partment of Commerce, Washington DC, January 1977. 10. J. Rompel: One I/Vay Functions are Necessary and Sufficient for signatures. Proceedings of STOC '90, pp.387-394.

A Comparison of RSA and the Naccache-Stern Public-Key Cryptosystem T h o m a s W. Cusick Department of Mathematics State University of New York at Buffalo 106 Diefendorf Hall Buffalo, NY 14214-3093

Abstract. In September 1995, David Naccache and Jacques Stern proposed a new public key cryptosystem. We give an analysis of this cryptosystem and we make a comparison with the well-known RSA system.

1

The

Naccache-Stern

public

key cryptosystem

In September 1995, David Naccache and Jacques Stern [5] proposed a new public key cryptosystem, which can be described as follows: Let P i (i --= 1, 2,...) denote the i-th prime and let p be a large prime (size 1024 bits is suggested) which is public. The secret key is a large s (size 160 bits is suggested), relatively prime to p - 1. The public key is a labelled set { r l , . . . , r~}, where r i is the least nonnegative residue m o d p of the s-th root of pi. Here n is chosen as large as n

possible subject to l-I Pi < p. i=1

A message block M = ( m l , . . . , rn~) made up of n bits is encrypted to a ciphertext C given by r~

C = least nonnegatwe residue of I I rimi m o d p. The ciphertext C is decrypted by computing

D = least nonnegative residue of C s =~ 1-I P~i rood p i=1

and gcd(D, pi) for i = 1, 2 , . . . until all of the primes Pi dividing D have been recovered. This determines the bits in the message block M. C o m p u t a t i o n shows that we can take n = 75 i f p has 512 bits and n = 13l if p has 1024 bits. From here on, we will refer to tlle above cryptosystem as the NS system. In the final section of the paper, we will give a detailed comparison of the RSA and NS systems from various perspectives.

112

2

Connections

with

well known

difficult

problems

It is well known that the security of the RSA cryptosystem rests on the assumption that factoring large integers cannot be done very efficiently. Similarly, we can show that the security of the NS system relies on the assumption that some other computational tasks cannot be carried out very efficiently. P r o p o s i t i o n 1. If discrete logarithms rood p can be computed very efficiently, then the NS system is not secure. P r o o f . We simply solve any one of the congruences p{ - r[~ rood p for the secret integer s. The present state of the art for the discrete logarithms mod p is that the largest prime p for which the discrete logarithm problem has been solved (using a few years of idle time distributed on a network of about 130 workstations) is of size 215 bits [7]. P r o p o s i t i o n 2, If a certain special knapsack-type problem can be solved very efficiently, then the NS system is not secure. P r o o f . Given p, r l , . . . , r , ~ and a ciphertext block C, we want to find a subset T of { 1 , . . . , n } such that (1)

H r'i - C mod p. lET

Then we can immediately decrypt C. Finding such a subset T is a kind of knapsack problem. Congruence (1) is a disguised version of the easy knapsack-type problem of finding a subset T of { 1 , . . . , n} such that (2)

H Pl =- C ~ mod p, IET

which we solve by computing gcd(C~,pi) for i = 1, 2,.... If the prime p is chosen too small, then, as pointed out by Naccache and Stern [51, one can solve the knapsack problem (1) by a "birthday attack" as follows: Suppose, for example, that p has only 512 bits, so that we take n = 75. Let C be a ciphertext block to be decrypted. We choose a set of about 40 of the integers ri (take i in a fixed set A of about 40 elements, for example A = { 1 , . . . , 40}), and we compute all possible products U(B) = C H r~-l' where B is a subset of iEB

A. Let A* denote the set such that A U A* = { 1 , . . . , 75}. We test each of the products U(B) to see if any of them has the form H r i ' where B* is a subset iEB*

of A*. if so, we have a solution of congruence (1) and so we can decrypt C. It does not appear that the NS system can be easily broken by using the factorization of p - 1. In fact, Naccache and Stern [5] suggest choosing the public prime p so that p = 2q -F 1 with q prime, in order to avoid leakage of bits of information about the message by the following argument: Given a message block M, the associated ciphertext block C is a product of ri's, so the Legendre

113

symbol of C m o d p leaks one bit of information about M, namely the parity of the number of quadratic nonresidues among the ri's in the product for C. This bit leakage can be extended to any small prime factor of p - 1, so it m a y be desirable to avoid having any such small prime factors except the inevitable 2. There is one situation in which a factorization of p - 1 leads to a break of the NS system: P r o p o s i t i o n 3. If all of the prime factors of p - 1 are small (say < log c p for some constant c), then the NS system is not secure. P r o o f . Under the hypothesis, discrete logarithms mod p can be computed in polynomial time by the Pohlig-Helhnan technique [3]. Thus the NS system is not secure by Proposition 1. It is worth remarking that it is possible but not obvious that knowing a primitive root m o d p would be useful in trying to break the NS system. It is known [6] that, if the Extended Riemann Hypothesis is assumed, then a primitive root rood p can be computed in polynomial time if all of the prime factors of p - 1 are small. It m a y be that a primitive root rood p still can be efficiently computed if the condition that all the prime factors of p - 1 are small is removed. Hence the factorization of p - 1 might be useful in attacks on the NS system even if we do not have a fast algorithm for discrete logarithms m o d p.

3

Chosen

ciphertext

attacks

Any public key system in which encryption in multiplicative is subject to chosen ciphertext attacks of simple kind. Both the RSA and NS systems are in this category. For example, in the NS system if we wish to decipher a ciphertext block C whose encryption is given by (1) for some unknown set T and we know that A and A C are legitimate ciphertexts (a trivial choice is A = ~- for some rj such that j is not in T), then we can use A and A C as chosen ciphertexts. Once we are given the associated plaintexts A s m o d p and ( A C ) s m o d p, we recover C 8 by computing C s =_ ( A C ) S A -s rood p. The same kind of attack can be made on the RSA system. Since an attacker must obtain decryptions of chosen ciphertexts for each block of ciphertext that he wants to decipher, this type of chosen ciphertext attack does not represent a serious threat to either the RSA or NS systems. In [2], there is a different kind of chosen ciphertext attack against RSA, but this attack is not applicable for the NS system. There is one substantial difference between the RSA and NS systems with respect to chosen ciphertext attacks. In the RSA system, almost any choice of ciphertext block C will correspond to some message block M. In particular, if n is the public modulus and e satisfying ged(e, 5(n)) = 1 is the public encrypting exponent for the RSA system, then the set {M m o d n : gcd(M, r = 1} has r elements, and the ratio r is nearly 1. The situation is very different for the NS system. As we saw in Section 1 above, if the prime p in the NS system is chosen to have 1024 bits, then the message blocks M have 131 bits and each such block encrypts to some ciphertext C which is a residue m o d p. Thus we are

!14

using 1024 bits to send a ciphertext block C which gives only 131 message bits, and we have: P r o p o s i t i o n 4. If the NS system is used with a 1024 bit prime iv, then about 7.8 ciphertext bits are needed to obtain each message bit. Thus a random choice of an integer rood p in the NS system is not likely to actually be a possible ciphertext, which complicates the implementation of any chosen ciphertext attack. However, if the cryptanalyst has access to a device which will reveal whether a given integer rood p is a legitimate ciphertext or not, then the NS system i s n o t secure. It is not even necessary to obtain the message corresponding to a given ciphertext block, as the following proposition shows! P r o p o s i t i o n 5. If a cryptanalyst can use an oracle which will reveal whether given integers mod p are legitimate ciphertexts or not, then the NS system is not secure. P r o o f . If we have a ciphertext block C, then we present the integers t i c m o d p (i = 1, 2, . . . , n) to the oracle. If tiC is a legitimate ciphertext, then ahnost certainly rl does not appear in the product which corresponds to C in (1). If rig is not a legitimate ciphertext, then almost certainly r i does appear in the product which corresponds to C in (1). Thus after at most n appeals to the oracle, the cryptanalyst almost certainly obtains the set T in (1) and so can decipher C.

4

Unconcealed

messages

We shall say that a message block represented by an integer M in the RSA system with public modulus n is an unconcealed m.essage if M e _= M m o d n for any odd integer e. This means that the integer M is unchanged after encryption by any odd public encryption exponent e. Elementary number theory arguments [1],[4] prove that any RSA system has at least 9 unconcealed messages and that in general one would expect no more than 9 such messages. For some special choices of the modulus n [4], a knowledge of these unconcealed messages can be used to break the RSA system. However, for almost all choices of n the unconcealed messages present no threat to the system. We shall say that a message block represented by an integer M in the NS system is an unconcealed message if the corresponding ciphertext block C can be decrypted trivially because the product of the ri's in (1) is less than p. The message blocks made up of a single 1-bit and n - 1 0-bits are always unconcealed, because the corresponding products are just ri (i = 1 , . . . , n). The number of unconcealed messages in an NS system depends on the number of small ri's, where ~'small" in this context means less than p112 or p113, etc. Having a large number of unconcealed messages is clearly undesirable, though their number cannot be reduced below n (as we saw in Section 1, this means at least 131 unconcealed messages i f p has 1024 bits). The designer of an NS system m a y a t t e m p t to minimize the number of unconcealed messages by choosing s so that none of the ri are < pl/2. Little is known about the distribution of the

115

residues m o d p of the s-th roots, but such a choice of s should be easy via a r a n d o m search. However, it is possible for a cryptanalyst to increase the number of unconcealed messages in an NS system, no matter what value of s is chosen, by the following attack: The cryptanalyst searches for an integer u such that the set {r~ - uri m o d p : i = 1 , . . . , n} contains as m a n y small integers as possible. Given a ciphertext block C, we know that C satisfies (1) for some unknown set T of subscripts. If T has k elements, we have the congruence

u k 1-~ ri = 1-[ r: = u k C m o d p.

(3)

iET

iET

If the set T happens to correspond to an unconcealed message, then we can decrypt the eiphertext block u k C and hence also the ciphertext block C. Of course the cryptanalyst does not know the size k of the set T, but he can simply try each k = 1, 2 , . . . , up to the largest k which is possible in a.n unconcealed message corresponding to a product of the integers r~'. It is very easy to test whether any integer u k C corresponds to an unconcealed message (we simply compute gcd(ukC, r~') for suitable choices of r*), so the cryptanalyst can quickly find any such ciphertext blocks C. In order to decide how much of a threat this attack on the NS system represents, the following questions need to be analyzed: - How m a n y small integers r~ can we expect to produce by a,n optimal choice of the multiplier u? How easy is it to find such an optimal choice of u?

5

Comparison

of RSA

and

NS

With respect to ease of implementation, the RSA system is certainly superior to the NS one. The public key for RSA is just two integers, the modulus n and the encrypting exponent e, whereas NS requires the prime p and r l , . . . , r~, which uses m a n y more bits. Decryption of an RSA block involves a single modular exponentiation, whereas decryption of an NS block C involves a modular exponentiation (to find C ~ rood p) plus various computations of gcd(C ~, ri). On the other hand, encryption of an RSA block requires a modular exponentiation but encryption of an NS block does not. The RSA system is more efficient in transmitting information. Each ciphertext bit in RSA gives one bit of message, but (Proposition 4 above) in NS one needs about 7.8 ciphertext bits for each message bit. One advantage of the NS system is that it appears that the discovery of a very fast algorithm for factoring integers would not break the system, unlike the situation for RSA. On the other hand, there are possible attacks on the NS system (in particular, the oracle attack in Proposition 5 above and the attacks based on exploiting unconcealed messages in Section 4 above) which have no counterpart for RSA.

!16

In summary, the RSA system is generally superior to the NS system except with regard to susceptibility to attack by fast algorithms for integer fa.ctoring.

References 1. G. R. Blakley and I. Borosh, Rivest-Shamir-Adleman public-key cryptosystems do no~ always conceal messages, Comput. Math. with Applic. 5 (1979), 169-178. 2. Y. Desmedt and A. M. Odlyzko, A chosen text attack on the RSA cryptosystern and some discrete logarithm problems, Advances in Crgptology-CRYPTO'85 Proceedings (Springer Lecture Notes in Computer Science 218, 1986), 516-522. 3. S. C. Pohlig and M. E. Hellman, An improved algorithm for computing logarithms in GF(p) and its cryptographic significance, IEEE Trans. fnfo. Theory 24 (1978), 106-111. 4. D. B. Smith and J. T. Palmer, Universal fixed messages and the Rivest-ShamirAdleman cryptosystem, Mathematika 26 (1979), 44-52. 5. D. Naccache and J. Stern, A new public-key encryption scheme, presentation at Luminy, September 1995. 6. J. yon zur Gathen, Factoring polynomials and primitive elements for special primes, Theoret. Comput. Sci. 52 (1987), 77-89. 7. D. Weber, Discrete logarithms rood p, e-mail announcement, Oceober 1995.

IEEE P1363" A Standard for RSA, Ditfie-Hellman, and Elliptic-Curve Cryptography (Abstract) Burton S. Kaliski Jr. RSA Laboratories 100 Marine Parkway, Suite 500 Redwood City, CA 94065-1031 USA [email protected] The IEEE P1363 working group is developing standards for public-key cryptography based on RSA and Diffle-Hellman algorithm families and on elliptic curve systems. This paper summarizes the current activities of that group. Abstract.

1

Introduction

Standardization of public-key cryptography is needed in several areas. The P1363 project, initiated in 1993 by IEEE's Microprocessor Standards Committee, is developing a standard that facilitates interoperable security based on several families of public-key techniques. The families include the widely implemented RSA [7] and Difl:ie-Hellman [1] systems, and related public-key cryptography, subsequently taken to include the E1Gamal [2] and elliptic curve systems [4, 6]. While there is some existing standardization for each of these systems, no comprehensive treatment covers all of the main techniques, hence the motivation for the P1363 project. The standard is planned to cover a range of aspects of each of these systems, from key generation and representation to mechanisms for public-key encryption, digital signatures, and key establishment. 2

Status

As of this writing (May 1996), draft sections of the standard are currently being integrated into a single document for editorial review. The sections include common mathematical conventions and definitions of elliptic curve systems, as well as the standard introductory material. Appendices of the standard cover rationale for the choices in the standard, security considerations, compliance definitions, mathematical background, numbertheoretic algorithms, and syntax for representing keys and identifying mechanisms, among other topics. The current elliptic curve systems are variants of E1Gamal's public-key encryption and digital signature schemes, the Digital Signature Algorithm [3], and a key establishment mechanism proposed by Menezes, Qu and Vanstone [5].

118

Mechanisms based on the P~SA, Diffie-Hellman, and E1Gamal systems are scheduled to be added to the document later this year.

3

Further information

Meetings of the P1363 working group, held quarterly, are open to the public; participation is encouraged. Drafts and meeting information m a y be obtained via anonymous F T P from the I E E E SPASystem server, s t d s b b s , i e e e . org, in the p u b / p t 3 6 3 directory. The working group's mailing list is < s t d s - p 1 3 6 3 O m a i l . • org> - - to join, send a request to <stds-p1363-request~mail. ieee. org>.

Acknowledgement Part of this work was performed while the author was visiting the Isaac Newton Institute for Mathematical Sciences at the University of Cambridge.

References 1. W. Diffie and M.E. Hellman, New directions in cryptography, [EEE Transactions on Information Theory, vol. IT-22 (1976), pp. 644-654. 2. T. E1Gamal, A public key cryptosystem and a signature scheme based on discrete logarithms, IEEE Transactions on Information Theory, vol. 31 (1985), pp. 469-472. 3. F / P S P U B 186: Digital Signature Standard, National Institute of Standards and Technology, 1994. 4. N. Koblitz, Elliptic curve cryptosystems, Mathematics of Computation, vol. 48 (1987), pp. 203-209. 5. A.J. Menezes, M. Qu, and S.A. Vanstone, Some new key agreement protocols providing implicit authentication, Presented at SAC '95, Carleton University, Ottawa, May 18-19, 1995, Revised manuscript available from authors, September 25, 1995. 6. V.S. Miller, Use of elliptic curves in cryptography, in H.C. Williams, editor, Advances in Cryptology - - Crypto '85, Springer-Ver]ag, New York, 1986, pp. 417-426. 7. R.L. Rivest, A. Shamir, and L. Adleman, A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM, vol. 21, no. 2 (1978), pp. 120-126.

Efficient and Secure Conference-Key Distribution* Mike B u r m e s t e r I a n d Yvo G. D e s m e d t 2,** 1 Information Security Group, Department of Mathematics, Royal Holloway, University of London, Egham, Surrey TW20 OEX, U.K., emaih m.burmester~vms.rhbnc.ac.uk 2 Department of Electrical Engineering and Computer Science, University of Wisconsin-Milwaukee, WI 53201-0784, U.S.A., e-mail: [email protected]

A b s t r a c t . Key distribution is a major cryptographic component for secure communication. For privacy data must be encrypted with keys which are distributed securely. In this paper we focus on conference key distribution. Our approach is to use a two-party key distribution system as an underlying cryptographic primitive and extend it to a conference system. We consider three different models: an unconditionally secure model, a provably secure model, and a model whose security is based on the difficulty of breaking the Diffie-Hellman problem. For each of these we present a conference key distribution system which is as secure as the primitive. These extend and generalize our conference scheme presented at Eurocrypt '94. In particular, (i) we are not restricted to any specific network or primitive and, (ii) our system based on the Diffie-Hellman key exchange is more efficient.

1

Introduction

D a t a s e c u r i t y in c o m p u t e r networks is b e c o m i n g increasingly i m p o r t a n t due to t h e e x p a n d i n g use of d i s t r i b u t e d c o m p u t a t i o n a n d d a t a b a s e s , a n d to t h e use of t e l e c o m m u n i c a t i o n a p p l i c a t i o n s over insecure channels. For p r i v a c y d a t a m u s t b e e n c r y p t e d w i t h keys which are d i s t r i b u t e d securely. M o s t of the research on key d i s t r i b u t i o n has c o n c e n t r a t e d on designing efficient a n d secure t w o - p a r t y key d i s t r i b u t i o n s y s t e m s . In this p a p e r we focus on conference key d i s t r i b u t i o n , in which a key is d i s t r i b u t e d p r i v a t e l y to m a n y users. O u r a p p r o a c h is to use a t w o - p a r t y key d i s t r i b u t i o n s y s t e m as u n d e r l y i n g c r y p t o g r a p h i c p r i m i t i v e a n d to e x t e n d it to a conference s y s t e m which is as secure as the t w o - p a r t y s y s t e m . We c o n s i d e r t h r e e different m o d e l s : an u n c o n d i t i o n a l l y secure m o d e l , a p r o v a b l y secure m o d e l a n d a m o d e l whose security is b a s e d on t h e difficulty of b r e a k i n g t h e D i f f i e - H e l l m a n p r o b l e m [5]. For each of these we present a conference key * This paper is an improvement of the Enrocrypt '94 paper. The research on privacy was done while Mike Burmester visited Yvo Desmedt in April 1995, the part on authenticity in April and May 1996. ** Supported in part by NSF Grant NCR-9106327.

120

distribution system. Security depends on the model used. In the strongest case there is no restriction on the computational power of the adversary and we have unconditional security. For the other models the adversary is polynomially bounded and we have provable security. The scheme we present extends and generalizes our conference scheme presented at gurocrypt '94 [4]. In particular, it is not restricted to a n y specific network or primitive. Furthermore, our practical scheme based on the DiffieHellman key exchange is more efficient. Our conference scheme can be described briefly as follows. We identify a conference 6' with a graph whose vertices are the nodes of C and whose edges correspond to secure paths. We call this the secure-path graph. One entity in C acts as a chair. The chair selects a conference key with an appropriate distribution. To get this key each entity (vertex) in C first exchanges a key with its adjacent entities in an appropriate subgraph of the secure-path graph by using the two-p~rty key distribution primitive. Then, starting with the chair, each entity sends to some of its adjacent nodes information which links the conference key with the exchanged key. Using this information, the entities can then compute the conference key. The strength of our scheme relies on the difficulty of getting the conference key from the information sent by the entities: for some of our schemes this is as hard as getting the key of the underlying primitive. In this paper we give no proofs. We are mainly concerned with the case when insiders are honest. In the full paper [9] we include proofs and consider the general case, allowing for a limited number of dishonest insiders. R e m a r k : If the communication network is not reliable then we cannot prevent messages from being deleted. Therefore it is impossible to know who is actually in the conference (e.g. some acknowledgements may be deleted) [1, pp. 33-34].

2

The

security

of conference

schemes

In general, in a strong cryptographic scenario, the setting for authenticity with conferences is much more complex than with the two-party case. We must Mlow for an adversary who is both passive and active, and who may conspire with corrupted insiders. There is no cryptographic way to deal with insiders who will reveal the conference key to outsiders. We shall therefore assume that other means may be used in such cases. However we must deal with insiders who may substitute the conference key for another key, or delete messages, so as to exclude some entities from the conference. Some of the main threats come from delays and deletions in the communication network. The adversary may delay transmitted messages, delete messages, or destroy nodes and links. A corrupted insider can also delete messages, but even worse, he can authenticate substituted keys. We must allow for such attacks in our general model. However we observe that in many cases the threat posed by such attacks may not be too serious. As an illustration, and to show which security aspects must be addressed in the general model, we now briefly discuss various scenaria in which different levels of cryptographic security apply.

121

Our first scenario is Pay-TV. In this case there may be no need for the messages to be authenticated. In general, whenever all entities in a conference other than the chair are receivers, and not senders, then messages may not have to be authenticated. With Pay-TV, subscribers (the entities in the "conference") do not need to know the secure-path graph; indeed some may wish to be anonymous. In this scenario a corrupted insider may be tolerated, and can be dealt with by other non cryptographic means. In a Hierarchical Command conference the chair (e.g. the President) may not know all the participants (the conference C), but his commands must be authenticated. If the secure-path graph is not a complete graph (e.g. if signatures are not used) then the authentication has to be delegated. In this case a corrupted insider who substitutes the conference key may cause considerable damage. However this is in the nature of hierarchical commands. We must also allow for the possibility that the chair is dishonest. Such a chair may distribute different conference keys, thus creating subconferences. If this is of consequence, then all entities who accept the conference key as authentic should know that they have accepted the same key. In an Emergency conference this may introduce unacceptable delays and one may wish to trade reliability for security. Indeed saboteurs may prevent even subconferences from taking place. Another possibility is that the conference is initiated by several entities independently. In this case there may be less trust in the chair. In the full paper [9] we formalize the requirements for authenticity. As mentioned in the introduction, if the communication network is unreliable then we cannot prevent messages from being deleted. We therefore must allow for subconferences. We distinguish two types of delegated authentication. The first requires that if an entity accepts a distributed key as authentic, then this key must be authentic, i.e. originate from the chair. The second is stronger and requires that, if an entity accepts a distributed key as authentic, then all entities who accept some key as authentic, accept the same key. If the chair is honest, then both definitions are equivalent. The second definition addresses the case when the chair is dishonest, and requires that such chairs should not be able to break up a conference into subconferences, without being detected.

2.1

The setting

In our scheme we use a two-party key distribution system as a primitive. If two entities Ui, Uj can exchange securely a private or authenticated key using this primitive then we say that there is a secure path between Ui and Uj. For example, if the primitive employs symmetric keys (as in [2, 11]), then there is a secure path between Ui and Uj if both share a key. If the Diffie-Hellman private key exchange [5] is used then there is a secure path between any two entities, since with this scheme any two entities can exchange a private key. We shall assume that the key space of the two-party key distribution system is a group with respect to an appropriate operation "," (e.g., bitwise exclusive-or) and that the keys are selected according to a distribution which can be sampled.

122

Let F be a (weighted) graph whose vertices U1, U2,..., Ul~ are the entities and whose edges correspond to secure paths. We call F the secure-path graph. If F is weighted then the weights correspond to the communication costs. Let C = {Uil, Ui~,..., Ui,} be a subset of the vertex set o f F . A conference of C is a connected subgraph Fc of s whose vertex set is C. A formal definition of secure conference key distribution for several scenaria will be given in the full paper. Before describing our conference key distribution system (CKDS) in detail we illustrate it by considering a simple four-party conference.

3

An e x a m p l e

Let U1, U2, [/3, U4 be the entities in a conference with U1 the chair. 3.1

The secure-path graph

Suppose thae the secure-path graph is as in Fig. 1. In this example we assume that the secure-path graph has been authenticated to all entities in the conference. U1

Fig. 1. A secure-path graph for a four-party conference. 3,2

Privacy

Let Tc be a minimum spanning tree a of Fc - see Fig. 2a. U1 selects the conference key K with an appropriate distribution (e.g. uniform). Then, using the two-party key distribution system, U~, U2 exchange the key KI~, U1, Ua exchange the key K13, and [/3, [/4 exchange the key K34 (Eq = Kj~, as with all two-party key exchanges). To make it possible for U2, U3 and U4 to compute K, a The complexity of finding Tc is O(N 2) using Kruskal's algorithm, or O(NM) using Prim's algorithm (N is the number of vertices and M the number of edges of F) [6].

123

U1

U1 /

"

"

X12 = K * I

U2

x Y

~

= K * K~31

U2 1(34

(a)

U4

X34 = 1( * [f~41

~

(b)

U4

Fig. 2. A four-party conference for a private key distribution.

U1 sends U2 the string 4 X12 = K * K~-21 U1 sends U3 the string X13 ~ K * K 13 -1 and U3 sends U4 the string )234 = If * I~-41 - Fig. 2b. Since U~ knows the key 1,21~ it can compute the conference key K by 'multiplying' XI~ by [Q2. Similarly, U3 and U4 can compute the conference key. Observe that the chair could use the key K12 (or /(13) as conference key, instead of K, which gives us a slight optimization.

3.3

Authenticity

First assume that the spanning tree in Fig. 2a is used, and that the chair is honest. Then Uz directly authenticates to U2 the key K using a two-party primitive authentication scheme (in some cases this step is included in the two party authenticated key exchange - see the discussion before Theorem 2). Similarly UI authenticates K to U3. Then Us authenticates K to U4. Observe that if U3 is not honest, then he may not authenticate it( to U4, or even worse, he may authenticate a key h "t ~ K to 574. To reduce the threat of dishonest delegated authentication, U2 could also authenticate K to U4 - see Fig. 1. Then U4 would accept a key as authentic only if both U2 and U3 authenticate the same key. Provided that U) and U3 are not both dishonest, {-74 will not accept the wrong key. However an adversary could always remove an entity from the conference, for example entity U4, by jamming any of the links from U1 to U4 (i.e., (U1, U2), (U1, U3), (U2, U4), (U3, U4)). In this paper we focus on conference schemes in which all insiders are honest. In the full paper we will address the general case by exploiting the topology of the secure-path graph (i.e., ( u + 1)-connectivity or (2u + 1)-connectivity, where u is an upper bound on the number of dishonest insiders), allowing for a dishonest. chair. We also will discuss the impact of the reliability of the communication network. 4 If the group operation is bitwise exclusive-or of binary strings then K ~ 1 is/(12.

124

4 4.1

General

case for privacy

The generic protocol

The chair selects a conference key K wit.h an appropriate probability distribution. The following protocol distributes K privately to all the entities in the conference. We denote the parent of a vertex U~, which is not a chair, by Up~r(~), and the height, of the spanning tree Tc by height(T). A l g o r i t h m 1 The CI(DS: sequential version

Let Ui~,..., Ui~ be a conference with spanning tree Tc. 1. Each vertex Ui C Tc, exchanges a key with its adjacent vertices. Let ]~ be the conference keg selected with an appropriate distribution by the chair, and let Kab be the key exchanged by U~ and Ub. 2. From level l = 0 of the spanning tree 5 to height(T) do: (a) At level l of Tc, each non-leaf Ua sends to each of its children Ub in Ti the string X~b = K * t(ab 1. (b) At level l r 0 of To, each Ua computes K = Xp~r(~),~ * Kpar(a),a. Although Step 1 can be executed in parallel, the computation of the Xab induces a delay in computing the conference key K which is proportional to the level of the vertex. We now discuss a variant in which the vertices multieast (broadcast) their encrypted keys to all their descendants. We use the same spanning tree, only this time the messages sent by a vertex are broadcast to all its descendants. A l g o r i t h m 2 The Ct(DS: multicast version

Let U ~ , . . . , Ui~ be a conference with spanning tree To. 1. In parallel, each vertex Ui C Tc~ exchanges a key with its adjacent vertices. Let K be the conference key selected with an appropriate distribution by the chair, and let I
X~ab =

i K * N~bI Kp~r(a),a * K-~b1

if a is the root, otherwise.

3. In parallel, each Ub~ E To, at level s > 0 computes the conference keg I
R e m a r k . If no active eavesdropper is present then all entities compute the same key: I~2b~ _ (K * [,~-1 "%1b~) -1 . * "'" * (I
125

4.2

Efficiency

Let deg(Ua) be the degree of U~ and level(Ua) be the level of Ua in the spanning tree. Also, let memory(2), interactions(2) and bandwidth(2) be the memory, the number of interactions and the bandwidth, respectively, of the two-party key distribution, and let IEI be the binary length of the key exchanged. Finally, let delay K be the delay associated with the two-party key distribution and delay x the delay induced by the computation of X~b plus the delay to receive it from the sender. We assume that in the sequential version as much parallelism as possible is used. If not, it is easy to adjust the figures. Then we have: Q o m p u t a t i o n a n d C o m m u n i c a t i o n C o m p l e x i t y for Ua. The number of keys Ksb and strings Xsb that have to be computed or sent by Ua is deg(Us) and d e g ( U s ) - 1 respectively. Furthermore, Ua computes one extra group operation in the sequential case and level(Ua) group operations in the multicast case.

T h e m e m o r y c o m p l e x i t y for U~ is at most deg(Us). (memory(2) + 2. [t,21) in the sequential case and deg(Us) 9 (memory(2) + 2. IKI) + level(Us) 9 IKI in the multicast case (minor improvements are possible). T h e n u m b e r o f i n t e r a c t i o n s for Ua is: interactions(2) + 1. T h e d e l a y for Us is: delay K +level(Ua). delayx, in the sequential case. In the multicast case it is reduced to: delay K + delay-x . T h e B a n d w i d t h r e q u i r e d by Us with its neighbors in the sequential case is at most max(bandwidth(2), IKI), and max(bandwidth(2), level(Us). IKI)in the multicast case.

5

Particular

systems,

their

security

and

efficiency

In this section we describe informally various security models and state our result for each one of these without proofs. Proofs and formal definitions for these models are given in the full paper [9]. There are basically four approaches which are currently used in cryptography to address security issues. The first one is the unconditionally secure approach in which the adversary has unlimited resources. This is based on Information Theory [15, 7, 18]. The second one is the proven secure approach which is based on pseudorandom functions and indistinguishability [8]. With this the adversary is assumed to have only limited resources. The third approach is heuristic. With this there is no formal proof of security, only convincing evidence. Several well-known cryptographic schemes are heuristic, e.g. the RSA [14] encryplion/signature scheme, the DES [17] and the Diffie-Hellman [5] key exchange. The fourth approach bridges the heuristic and the proven secure models: a new scheme is shown to be secure by proving that if it can be broken, then so can an established scheme. Our main result can be summarized as follows. M a i n r e s u l t . The protocol in Section ~ is a C K D S which is as secure as the primitive two-party key distribution, if the key space is a group, if the keys are

126

distributed appropriately, and if no insiders are dishonest during the execution of the protocol. In the full paper we prove this for the first, second and fourth model, by using the security designated for each model and by specifying the two-party primitive. We also extend this result when the number of dishonest insiders is bounded for several settings (see Section 2). We first state our results for each model. In the unconditionally secure model we use a trusted center for the twoparty primitive of the protocol. The center distributes in advance to each pair of entities (Ui, U-) which correspond to an edge in the secure-path graph, privately, a random independent one-time key K q . We say that we have unconditionally secure privacy for a CKDS if, in a passive attack, the adversary cannot get any information at all about a fresh conference key. We shall prove that: T h e o r e m 1. Suppose that the secure-path graph is connected and that a trusted center distributes random independent one-time secret keys to pairs of entities which correspond to edges in the secure-path graph. If this is used as the twoparty primitive then the protocol in Section ~ is a CKDS for which we have unconditionally secure privacg. In the full paper we extend this result to allow for authentication by using [18]. In the proven secure model all entities, including the adversary, are polynomially bounded in the binary length Ix] of a security parameter x. We have proven secure privacy for a CKDS if, in a passive attack, the adversary cannot distinguish (i.e, does not have enough computational power) a fresh conference key from a random key. In this model, for the two-party primitive we use a trusted center which distributes privately, in advance, to each pair of entities (5~i, Uj) which correspond to an edge in the secure-path graph, a random independent long-life key. We use as primitive the scheme in [2] which we briefly survey in our context. If only privacy is required then the key, say aij, is used for a (probabilistic) pseudorandom encryption function. Then one party selects a session key ts = K and sends its encryption under faii to the other party~ From this the other party g e t s Kij = K by deeryption. If both privacy and authentication are required then an extra key a~j is needed [10]. This is used for a pseudorandom MAC. Observe that with this two-party key exchange, any one of the two parties can choose the key. Therefore by running it sequentially, the conference key K can be distributed more efficiently than with the generic sequential version of our protocol, since there is no need for extra authentication. However this is not the case with the parallel version. T h e o r e m 2. Suppose that the secure-path graph is connected and that a trusted center distributes random independent long-life secret keys. Then the protocol in Section )t, adapted as above, is a CI{DS for which we have proven secure privacy and delegated authentication, provided the key space is a group, the number of vertices in F is polynomially bounded (in Ixl), the secure-path graph has been authenticated to all entities in the conference, and all insiders are honest.

127

Our last model uses the Diffie-Hellman key exchange [5] as the two-party primitive. With this, the keys belong to Z~ = Zp\{0}, where p is a (large) prime. The group operation is multiplication and the conference key is selected randomly in Z~. To exchange a key, entities Ua, Ub select exponents r~, rb E Zp-1 at random and exchange za = o:~- mod p, Zb = a ~b mod p, respectively, where a is a generator Z~ (or an element whose order is large) and is public. The two-party key is Kab : a~~ = (a ~")~bmodp = (a~b) ~ modp, which both entities can compute. The security is based on the difficulty of computing K~b given only p, a, a ~~modp and a ~bmodp. As in the previous case all entities are polynomially bounded (in Ip]). We prove that: T h e o r e m 3. If we use the Diffie-Hellman key exchange as two-party primitive for the protocol in Section ~ then we get a CI(DS which is as secure as the DiffieHellman primitive, provided that the number of vertices in F is polynomiaIly bounded (in Ix]). Theorem 3 is for privacy only. In the full paperwe will consider extensions for which we have authentication.

Efficiency. The cost per user Ua for this conference key is two exponentiations (one for za the other for the key), log 2 p bits communicated and one interaction, for each of its adjacent vertices. The cost for the conference key can be optimized if each entity Ua sends the same za to its parent and children. This will result in a saving of deg(Ua) - 1 exponentiations. There is also a saving in the computation of the Xab and X'~b , if Us computes these as: X~b = K 9 (zb)P-~-lmodp and Xl~b = [(p~ 9 ( z b ) P - ~ - l m o d p respectively. This requires one multiplication and one exponentiation, and no inversion.

C o m p a r i s o n w i t h t h e B u r m e s t e r - D e s m e d t s y s t e m . Our scheme is more efficient than the conference system presented by Burmester and Desmedt at Eurocrypt '94 [4], as can easily be seen. For example, for the broadcast system in [4] with n = [logp] they need 2 + n exponentiations, whereas we only need 4 exponentiations (the rest is essentially the same). Similarly for the binary tree system in [4] the number of rounds is 1 + [log hi, whereas here it is only 2.

6

Conclusion

We have discussed secure conference key distribution and have seen that it is much more complex than for the two-party case, in particular with regards to authentication. We have presented a conference key distribution scheme which is secure, and which is efficient when the two-party primitive is efficient. If the Diffie-Helhnan key exchange is used as a primitive, then the cost per user for a cyclic network is roughly 1.5 times that of the Diffie-Hellman system, independently of the number of users in the conference.

128

With our scheme there is no restriction on the primitive or the network. Obviously, some networks are better than others. For authenticity graphs with a high connectivity are better. In general, for privacy, the shorter the height of the secure-path spanning tree the more unbalanced the cost is. For example in a star network the chairs have to bear most of the cost: the computation and communication complexity is proportional to the n, the size of the conference. The other extreme is the cyclic network for which the computation and communication complexity is constant, but the delay or bandwidth is proportional to n. For the binary tree the computation and communication complexity remain constant, but the delay or bandwidth is only proportional to log n. For a tree for which the number of children of a vertex is exponential in the level of the vertex, the computation and communication complexity is constant but the delay or bandwidth is only proportional to log log n.

References 1. Bertsekas, D., Gallager, R.: Data networks. Prentice Hall (second edition), 1992. 2. Bellare, M., Rogaway, P.: Entity authentication and key distribution. In Advances in Cryptology - - Crypto '93 (Lecture Notes in Computer Science 773) (1994) D. R. Stinson, Ed., Springer-Verlag, pp. 232-249. 3. Bird, R., Gopal, I., Herzberg, A., Jansen, P., Kutten, S., Molva, R., Yung, M.: Systematic design of two-party authentication protocols. In Advances in Cryptology -- Crypto '91 (Lecture Notes in Computer Science 576) (1992) J. Feigenbaum, Ed., Springer-Verlag, pp. 44-61. 4. Burmester, M., Desmedt, Y.: A Secure and Efficient Conference Key Distribution System. In Advances in Cryptology -- Eurocrypt '94 (Lecture Notes in Computer Science 950) (1995) A. De Santis, Ed., Springer-Verlag, pp. 275-286. 5. Diffie, W., Helhnan, M.E.: New directions in cryptography. IEEE Trans. Inform. Theory, IT-22(6): 644-654, 1976. G. Gibbons, A.: Algorithmic Graph Theory. Cambridge University Press, Cambridge, 1985. 7. Gilbert, E., MacWitfiams, F., Sloane, N.: Codes which detect deception. The BELL System Technical Journal, 53(3): 405-424, 1974. 8. Goldreich, 0., Goldwasser, S., Micali, S.: How to construct random functions. Journal of ACM, 33(4): 792-807,1986. 9. Burmester, M., Desmedt, Y.: Efficient and Secure Conference Key Distribution. To be submitted. For an early version s e e : http: / /www.cs.uwm.edu/~desmedt / CKDS.ps 10. Jueneman, R.: Analysis of certain aspects of output feedback mode. In Advances in Cryptology. Proc. Crypto 82 (1983) D. Chaum, R.L. Rivest, and A. T. Sherman, Eds., Plenum Press N. u pp. 99-127. 11. Kohl, J., Newmann, B.C.: The Kerberos network authentication service. MIT Project, Athena, Version 5. 12. Maurer, U.M.: Towards the equivalence of breaking the Diffie-Hellman protocol and computing the discrete logarithm. In Advances in Cryptology -- Crypto '9~ (Lecture Notes in Computer Science 839) (1994) Y. G. Desmedt, Ed., SpringerVerlag: pp. 271-281.

129

13. McCurley, K.S.: A key distribution system equivalent to factoring. Journal of Cryptology, 1(2): 95-105, 1988. 14. Rivest, R.L., Shamir, A., Adleman, L.: A method for obtaining digital signatures and public key cryptosysteins. Commun. ACM, 21: 294-299, 1978. 15. Shannon, C.E.: Communication Theory of Secrecy Systems. Bell System Techn. .]our. 28: 656-715, 1949. 16. Schrift, A.W., Shamir, A.: The discrete log is very discreet. In Proceedings of the twenty second annual A CM Symp. Theory of Computing, STOC (1990) pp. 405-415. 17. U.S. Department of Commerce, National Bureau of Standards. Data Encryption Standard, January 1977. FIPS PUB 46 (NBS Federal Information Processing Standards Publ.). 18. Wegman, M.N., Carter, L.: New hash functions and their use in authentication and set equality. Journal of Computer and System Sciences, 22: 265-279, 1981.

Directed Signatures and Application to Threshold Cryptosystems Chae Hoon Lim* and Pil Joong Lee** Department of Electrical Engineering Pohang University of Science and Technology (POSTECH) Pohang, 790-784, KOREA E-mail : [email protected] ; [email protected]

A b s t r a c t . This paper presents a directed (or designated-receiver) signature scheme with the property that the signature can be verified only with the help of the signature receiver. Such signatures are intended to protect the privacy of the signature receiver in applications where the signed message contains information personally sensitive to the receiver. We also present its application to shared verification of signatures and threshold cryptosystems. The resulting group-oriented cryptosystems are fully dynamic and scalable.

1

Introduction

Public key cryptography, invented by Diffie and Hellman [6], provides powerful tools that can solve various security and privacy problems arising in today's electronic age. Thus there is a growing use of public key techniques in cryptographic applications. In particular, a digital signature scheme is one of the most important cryptographic tools, which is essential in implementing various security services. Basically digital signatures have the property that anyone having a copy of the signature can check its validity using public information. This self-authenticating property is necessarily required for some applications of digital signatures such as certificates or official announcements issued by some authorities. However, such signatures seem to provide too much authentication than necessary in many applications. Thus it may be preferable to put some restrictions on this property to prevent potential misuse of signatures. Undeniable signatures introduced by Chaum [2] provide a way of protecting the interest of the signer. A undeniable signature is generated in such a way that it can be verified only with the help of the signer. Therefore, in this signature scheme the signer can have complete control over the use of its signatures. On the other hand, in many applications of digital signatures, the signed message may be personally sensitive to the signature receiver. Then the receiver * He is now with Baekdoo Infocrypt, Inc. E-mail: [email protected]. ** He is now on sabbatical leave to NEC Research Institute in Princeton. E-mail: [email protected].

132

may worry about abuses of the signature. Examples may contain signatures on medical records, tax information and most personM/business transactions. For these applications the most desirable form of a signature would be such that the signature can be verified only by the receiver. Of coarse, the receiver should be able to convince anyone that the signature is a valid signature issued by the signer. Thus we may call such signatures as d~reeted (or designated-receiver) signatures [9]. This signature scheme is intended to protect the privacy of the signature receiver by putting the use of a signature under the control of the receiver. The concept of directed signatures and a construction based on the GQ signature scheme [8] were first presented by the present authors at Auscrypt'92 [9]. On the other hand, at Eurocrypt'94 D.Chaum introduced the concept of designated confirmer signatures to solve a weakness of undeniable signatures (i.e., unavailability of confirmation in the absence of the signer). Later T.Okamoto presented a more practical construction method of designated confirmer signatures [11]. The two signature schemes are very similar, only different in that who is given the ability of proving the validity of signatures. The confirmation capability is directly transferred to the signature receiver in directed signatures, but to the designated third party in designated confirmer signatures. However, the intended applications are quite different, as we mentioned above. This paper describes a construction method of directed signatures based on the discrete logarithm problem. Our constructions are very similar to that of Okamoto [11]. Since the message to be signed is closely related to the privacy and/or interest of the receiver in our applications, it would be desirable to send the message under encryption. A simple method for providing secrecy in addition is also described. Directed signatures can be used to design threshold cryptosysterns (see [4, 5]) by incorporating Shamir's secret sharing scheme [13]. We present a way to implement threshold signature verification, in which the signature can be verified only by cooperation of an authorized subset of designated verifiers. We also present a threshold cryptosystem constructed by distributing the decryption capability in such a way that the ciphertext can be decrypted only by cooperation of an authorized subset of designated receiver's. The group-oriented cryptosystems we present are very attractive, compared to previous schemes, in that they are fully dynamic and scalable.

2

Preliminaries

Throughout this paper we will use the following system setting. Let p and q be two large public primes such that q divides p - 1 and a be an element of order q in Zp. The p, q, a are system parameters common to all users. We assume that every user A in the system possesses a secret and public key pair (zA, YA) such that yA = a xA mod p with Xa E Zq. Our constructions of directed signature schemes and threshold cryptosystems are based on Schnorr's signature scheme [12] and Shamir's secret sharing scheme [13]. These two basic tools are briefly described. In Schnorr's signature scheme,

133

the signer A can generate a signature (rA,SA) on message m by computing rA = h(c~k~ rood p, rn) with random kA E Zq and SA = kA -- XArA m o d q. The signature can be verified by checking that h(c~ay ~a rood p, rn) = rA. A (t, n) secret sharing scheme is a scheme to distribute a secret K into n users in such a way that any subset of t users can cooperate to reconstruct the secret K but that a collusion of t - 1 or less users can obtain no information on the secret. Shamir's scheme is based on Lagrange interpolation in a field. To implement it, a polynomial f of degree t - 1 is randomly chosen in Zq such that f(0) = K. Each shareholder i is given a secret share f(ui), where u~ is public. Now any subset of t out of n shareholders can reconstruct the secret K = f(0) as t

f(O) = E i=1

t

f(ui)

H j=l,jr

-uj

Ui - - U j

m o d q,

where we assume for simplicity that the authorized subset consists of shareholders i for i = 1 , 2 , . - . , t .

3

Directed

Signatures

Suppose that user A wants to generate a signature on message rn so that only B can directly verify the signature and that B can prove its validity to any third p a r t y C, whenever necessary. We describe a construction of such a signature scheme based on Schnorr's signature scheme. The signing and verifying processes are as follows. Signature generation by A to B 1. A picks at r a n d o m kA1, kA2 r Zq, and computes W A = (2 k A l - k A 2 mod p and zu = y ~ l m o d p. 2. A computes rA = h(zB, WA, m) using a one-way hash function h and 8 A : ]~A2 - - X A ~ A m o d q. 3. A sends {WA,rA,SA,rn} to B. -

Signature verification by B 1. B computes z~ = (C~SAy~AWA)XB m o d p. 2. B checks that rA =- h(z~, WA, rn).

In the signing process we used two random numbers kal and kA2 to protect the Diffie-Hellman common key a ~A~B m o d p. Thus, knowledge of zB (even a ''A~'B rood p) does not help to verify the signature. The obvious advantage of the above signature scheme over ordinary self-authenticating signature schemes is that the resulting signature is of no meaning to a third party since there is no way for him to verify its validity. It also has an advantage in view of security since the relation between the signature and the signer's secret key is not known to anyone but the designated receiver. Thus misuse and proliferation of selfauthenticating signatures can be prevented in this signature scheme. We believe that it is very attractive for use in most private c o m m u n i c a t i o n s .

134

There m a y be a case where the receiver needs to present the signature and prove its validity to a third party. For example, to apply for a job in a company, a person B m a y be required to prove his good health. Then B m a y obtain a directed signature for his health record from a hospital A, present the signature to the company and prove its validity. For this purpose B can use zero-knowledge proof techniques so that the company can gain nothing but the validity of the signature. The following is the procedure that B can use to prove the validity of the signature to C. - Proof of validity by B to C 1. From the signature {Wa, rA, SA, m}, B first computes fi = a~AfAA WA rood p, ZB = flx~ mod p and sends {ZB, WA, FA, SA, m } to C. 2. C then checks that r A : h(ZB, It)A, m ) . If it does not hold, C halts. Otherwise, C computes fl = a ~ y ~ w A rood p. 3. Now B proves to C that logz ZB = logs YB in a zero-knowledge fashion, for example, using the protocol for simultaneous discrete logarithm in [2, 1]. We next present another method for constructing a directed signature scheme, which will be used later to construct threshold cryptosystems. The processes for signing, verifying and proving validity are summarized below. -- Signature generation by A to B 1. A picks at random k A l , k A 2 C Zq, and computes WA = a ~a~ m o d p , k,~ m o d p and vB = t- v A l Y Bka~ m o d p. ZA ~-- W A 2. A computes rA = h(zA, WA, m) and SA = kA2 -- XArA m o d q. 3. A sends { V B , W A , r A , S A , m } to B. Signature verification by B 1. B first recovers kA1 as kA1 -~- VBWA ::B mod p. 2. B then computes z~ = (aSAy~A)k~ rood p and checks that rA = h(Z~A, WA, m). Proof of validity by B to C 1. B first recovers kA1 fro1Tl VB as before, computes fl = a~Ay] ~ m o d p and ZA = /~kA1 m o d p, and sends {ZA, WA, rA, SA, m } to C. 2. C then checks that rA = h ( Z A , W A , m ) . If it does not hold, C halts. Otherwise, C computes fl = c~SAy~Aa m o d p. 3. Now B proves to C that logz ZA = logs WA in a zero-knowledge fashion. In the above construction both wa and zA are random exponentiations and the one-time secret kA1 are securely transmitted to B by the E1Gamal encryption technique [7]. So, we can construct a directed signature scheme even in the case where the signature receiver does not have a secret and public key pair, if there is a secure communication channel between the signer and the receiver to send kA1. Note that if B reveals kAj_, then the signature can be converted into an ordinary signature. Thus the above scheme an be viewed as a counterpart of convertible undeniable signatures [1] in our directed signature schemes.

135

4

Directed Signatures with Encryption

It m a y be preferable to encrypt the message to be signed during transmissions if the message contains personally sensitive information. It is quite straightforward to add confidentiality to the directed signature scheme described above. We assume t h a t there is a symmetric encryption scheme. We denote by E K ( m ) (DK(m), resp.) encryption (decryption, resp.) of message m under the secret key K. A can derive a session key KAB from ZB, for example KAB = h(zB) with a one-way hash function h. (In the variant described in the last of Section 3, the session key can be derived either from kA1 or from ZA.) The signing process is unchanged. But A encrypts the message m as c = E K a ~ ( m ) and sends B this ciphertext together with the signature {wA, rA,SA}. B then computes z~ as before, obtains KAB = h(z'B) and decrypts the ciphertext c as m ' = DKAB(m). The signature is valid only if rA = h(z~, WA, m'). Now, suppose that B wants to prove to a third party C that the signature {WA, rA, SA} on message m is a valid signature issued by A. B then encrypts m under a session key K B c , sends C the resulting ciphertext together with {WA, rA, SA} and executes the validity proof protocol described before. Here the session key KBC can be agreed using any key exchange scheme. The simplest is to derive it from zc = ykc~ m o d p with random kB E Zq and sends WB = a k , to C.

5

Shared Verification of Signatures

A directed signature scheme can be used to implement a signature scheme with threshold verification. Suppose that A wants to generate a signature on message m in such a way that the signature can be verified by any subset of t or more users from a a designated group G of n users but that any subset with t - 1 or less users can learn nothing about the validity of the signature. We can design such a signature scheme using a directed signature scheme and Shamir's (t, n) secret sharing scheme [13]. We assume that each user B in the system has a unique public number UB. The uB m a y be B's identity or public key YB. For convenience, we also assume that G = {Bi I 1 < i < n}. The signing process consists of the following steps. 1. A picks at r a n d o m ] r E Z q , and computes w A z OlkA1 m o d p and kA~ rood p. Z A -~- W A 2. A computes rA -= h(zA, WA, rn) and SA = kA~ -- XArA rood q. 3. A randomly selects a polynomial f of degree t - 1 in Zq such that f(0) = kdl~ i.e., f ( x ) = kA1 + alx + a2x 2 + . . . + at_ix t - i with ai E Zq. 4. A then computes vB~ = f(uu~)yk~ 1 mod p using the public key YB, of Bi in G. 5. Finally A broadcasts {WA, rA, SA, m} and {VB,}~=~ to the group G.

136

In the above signature scheme we used kAx as a one-time secret and broadcast its shares using E1Gamal encryption scheme [7]. It is a generalized version of the signature scheme described in the last paragraph of Section 3. Now, suppose that a subset H o f t users from G agrees to verify the signature. For convenience, we assume that H = {Bi I t < i < t}. We also assume that there is a combiner which collects partial computations from each user in H and determines whether or not the signature is valid. The verifying process is as follows. 1. Each user B~ in H recovers f ( u B i ) = VBiW a- - : g B 2. Bi computes

i

m o d p.

t

eB, =

I-[ j=l,jr

---u---B2 m o d q uB~ tl'Bi -

-

and zB~ = (ceSAt/'x) ~sJ(~'s~) rood p, and sends zB, to the combiner. LA 3. The combiner computes z~ as t

z A' =

1I zB~ = / 3 ~ i=~ ~ U ( ~ i ) mod p, i=1

where/3 = c~Ay~A rood p, and checks that rA = i~(Z'A, WA, rn). The described signature scheme is fully dynamic and scalable. There is no need of pre-distributing fixed secret shares as is required in most threshold schemes. The parameters t and n and the verifying group G can be chosen by the signer at the time of signature generation. The only requirement is that each user i in the system possesses a secret and public key pair (xi, Yi = ~ m o d p). Thus the signature scheme with threshold verification can be easily implemented if Diffie-Hellman or EIGamal-type schemes have already been deployed. For example, a variant of the DSA (digital signature algorithm) [10] can be used to implement it in a similar way.

6

A Threshold Cryptosystem

In a group-oriented society it is often necessary to send a.n enciphered message to a group so that the ciphertext can be deciphered only by cooperation of an authorized subset of the group members. The same technique in Section 5 can be used to construct such a threshold cryptosystem. Suppose that the sender A wants to encrypt the message m so that t users from a designated group G of n users should cooperate to recover the message. The session key K a c between the sender A and the receiver group G can be derived from ZA. The signing and encrypting process is the same as in Section 5, except that the message is transmitted in an encrypted form. T h a t is, the message to be ~ broadcast consists of {wa, rA, 8A, C, { v Bi}i=l}, where e = EKAG!m) and K A a = h(zA). The decrypting and verifying process is also the same as in Section 5,

137

except that the communication channel between each user in H and the combiner should be secure (since otherwise anyone intercepting the communication can decrypt the ciphertext) and that the ciphertext should be first decrypted with the recovered session key and then verified. The above scheme has several advantages over the threshold cryptosystem due to Desmedt and Frankel [5]. Desmedt-Frankel's scheme uses a fixed secret key whose shares should be securely distributed to a given group with predetermined threshold parameters when the system is set up. Since everything is determined during the system setup, any change in group members or security policy requires to adjust group members' secret shares accordingly. Furthermore, there may be a collusion of group members to discover the group secret. In our scheme, however, everything is determined by the sender at the time of encryption. There is no fixed group secret. An individual can send ciphertexts to any chosen group with any desired security policy. A slight disadvantage is that the computation and communication complexities are increased, compared to Desmedt-F,'ankel's scheme. 7

Conclusion

Directed signatures can replace ordinary signatures in many applications, in particular where the signed message is sensitive to the receiver's privacy. By using such signatures we can minimize the possible misuse and the proliferation of self-authenticating signatures. We presented a construction of such a signature scheme based on the discrete logarithm problem. Using a directed signature scheme and a secret sharing scheme, we also presented two kinds of threshold cryptosystems: threshold verification of signatures and threshold decryption of ciphertexts. These cryptosystems are fully dynamic and scalable. They can be used for secure a n d / o r authentic communications between an individual and an arbitrary group without any requirement on group settings.

References 1. J.Boyar, D.Chaum, I.Damgard and T.Pedersen, "Convertible undeniable signatures," Advances in Cryptology- Crypto'90, Springer-Verlag, LNCS 537, pp.189-205 (1991). 2. D.Chaum, "Zero-knowledge undeniable signatures," Advances in CryptologyEurocrypt'90, Springer-Verlag, LNCS 473, pp.458-464 (1991). 3. DiChaum, "Designated confirmer signatures," Advances in Cryptology-Eurocypt'9~, Springer-Verlag, LNCS 950, pp.86-91 (1995). 4. Y.Desmedt, "Society and group oriented cryptography," Advances in CryptologyCrypto'8Z Springer-Verlag, LNCS 293, pp.120-127 (1988). 5. Y.Desmedt and Y.Frankel~ "Threshold cryptosystems," Advances in CryptologyCrypto'89, Springer-Verlag, LNCS 435, pp.307-315 (1990). 6. W.Diffie and M.Hellman, "New directions in cryptography," [ERE Trans. Info. Theory, 31, pp.644-654 (1976).

138

7. T.E1Gamal, "A public key cryptosystem and a signature scheme based on discrete logarithms," IEEE Trans. Info. Theory, IT-31, pp.469-472 (1985). 8. L.C.Guillou and J.J.Quisquater, "A practical zero-knowledge protocol fitted to security microprocessors minimizing both transmission and memory," Advances in Cryptology-Eurocypt'88, Springer-Verlag, LNCS 330, pp.123-128 (1988). 9. C.H.Lim and P.J.Lee, "Modified Maurer-Yarobi's scheme and its applications," Advances in Cryptology-Auscrypt'92, Springer-Verlag, LNCS 718, pp.308-323 (1993). 10. NIST, "Digital signature standard," FIPS PUB 186 (1994). 11. T.Okamoto, "Designated confirmer signatures and public-key encryption are equivalent," Advances in Cryptology-Crypto'9~, Springer-Verlag, LNCS 839, pp.61-74 (1994). 12. C.P.Schnorr, "Efficient signature generation by smart cards," Journal o.f Cryptology, 4(3), pp.161-174 (1991). 13. A.Shamir, "How to share a secret," Comm. ACM, 22(11), pp.612-613 (1979).

Key Escrow in Mutually Mistrusting Domains* L. Chen, D. G o l l m a n n and C.J. Mitchell Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX, UK E-mail : {I iqun, dieter, cjm}@dcs, rhbnc, ac .uk

Abstract. In this paper we present a key escrow system which meets possible requirements for international key escrow, where different domains may not trust each other. In this system multiple third parties, who are trusted collectively but not individually, perform the dual role of providing users with key management services and providing authorised agencies in the relevant domains with warranted access to the users' communications. We propose two escrowed key agreement mechanisms, both designed for the case where the pair of communicating users are in different domains, in which the pair of users and all the third parties jointly generate a cryptographic key for end-to-end encryption. The fact that all entities are involved in the key generation process helps make it more difficult for deviant users to subvert the escrowed key by using a hidden 'shadow-key'. The first mechanism makes use of a single set of key escrow agencies moderately trusted by mutually mistrusting domains. ! The second mechanism uses a transferable and verifiable secret sharing scheme to transfer key shares between two groups of key escrow agencies, where one group is in each domain.

1 1.1

Introduction Key escrow in mutually

mistrusting domains

In m o d e r n secure telecommunications systems there are likely to be two contradictory requirements. On the one h a n d users want to c o m m u n i c a t e securely with other users, and on the other h a n d governments have requirements to intercept user traffic in order to c o m b a t crime and protect national security. A key escrow s y s t e m is designed to meet the needs of b o t h users and governments, where a e r y p t o g r a p h i c key for user c o m m u n i c a t i o n s is escrowed with a key escrow agency (or a set of agencies) and later delivered to government agencies when lawfully authorised. Following the US government's Clipper proposals, [1], a ' n u m b e r of key escrow systems have recently been proposed, and for an overview of the field, the reader is referred to [4]. W h e n users c o m m u n i c a t e internationally, there is a potential requirement to provide the law enforcement agencies of all the relevant countries, e.g. the * This work has been jointly fimded by the UK EPSRC under research grant GR/J17173 and the European Commission under ACTS project AC095 (ASPECT).

140

originating and destination countries for the communication, with warranted access to the user traffic. For example, a global mobile telecommunications system might provide an end-to-end confidentiality service to two mobile users in two different countries, and taw enforcement agencies in both these countries might independently wish to intercept these communications. To make matters more complicated, these two countries will typically not trust one other (such domains are referred to as mutually distrusting countries in [6]); for example, a law enforcement agency in one country might not wish to let their counterpart in any other country know that a particular user's communications are being intercepted. We are concerned here with international key escrow, and we assmne throughout that the countries involved do not trust one another; for the maximum generality we refer to domains instead of countries throughout. We also refer to interception authorities where we mean bodies such as law enforcement agencies who may be given the right to access communications within ~ single domain. Finally we refer to escrow agencies or Trusted Third Parties (TTPs) who wit] be responsible for maintaining all the information necessary to provide access to interception agencies, when presented with the appropriate legal authorisation. We now state our requirements for key escrow in an international (i.e. a multi-domain) context. 1. No domain can individually control the generation of an escrowed key, and hence the escrowed key cannot be chosen by entities in only one domain and then transferred to the other domain. 2. The interception authorities in any domain can gain access to an escrowed key without communicating with any other domain, i.e. the key has to be capable of being escrowed in nil relevant domains independently. 3. The entities in any domain can ensure the correctness and freshness of the escrowed key. 1_.2 P r i o r a p p r o a c h e s Jefferies, Mitchell and Walker [8] recently proposed a novel key escrow mechanism suitable for international use, called the 'JMW' mechanism for short. In that scheme every user has an associated TTP. If two users, communicating with each other securely by using end-to-end encryption, are located in different domains, then the relevant pair of T T P s (one in each domain) collaboratively perform the duM rote of providing the users with key management services and providing the two interception agencies with warranted access to the users' communications. A session key for end-to-end encryption is established based on Diffie-Hellman key exchange [5]. An asymmetric key agreement pair for one user (the receiver) is separately computed by both T T P s (one in each domain) using a combination of a secret key shared between them and the receiver's name, and another asymmetric key agreement pair for the other user (the sender) is generated by himself. The receiver computes the session key by combining his private key (transferred securely from his own T T P ) with the sender's public

141

key (sent with the encrypted message). The sender computes the same session key by combining his private key with the receiver's public key (obtained from the sender's own T T P ) . Interception agencies in each domain can retrieve the session key from the T T P in the same domain. Note that this mechanism meets the three requirements for key escrow listed above. However, it requires the following assumptions about trust relationships among the users, T T P s and interception agencies. i. Each user believes that their own T T P (as well as the T T P s of any other users with which they communicate) will issue proper key agreement values and certificates, and will not reveal the escrowed key illegally. 2. Each T T P believes that the user, as a sender, will provide the correct public key (matching the secret key he uses for securing messages he sends). 3. Each T T P believes that the other T T P will contribute proper key agreement values and certificates, and will not reveal the escrowed key illegally. 4. Each interception agency believes that the T T P in its domain will provide the correct escrowed key when requested. In [6], Frankel and Yung give a different scheme for international key escrow, which requires a key escrow agency (or agencies) to be trusted by more than one domain. 1.3

Our contribution

In this paper we suppose that, in some environments where international key escrow is required, T T P s may not be trusted individually to provide proper contributions to an escrowed key and to reveal the key legally, and users also may not be trusted to provide proper contributions to an escrowed key. We consider two related key escrow mechanisms with the following properties. 1. The schemes use a set of moderately trusted third parties instead of a single TTP, in an effort to prevent a single T T P from corrupting an escrowed key. For the purposes of this paper, moderately trusted third parties are trusted collectively, but not individually, by users, interception agencies and another set of T T P s . Key splitting schemes have previously been used for splitting as1 escrowed key into n shares escrowed by n agencies in proposed key escrow systems (e.g. see [4, 9, 11, 12]); we also make use of a k out of n threshold scheme. Such a scheme allows any subset of k of the n escrow agencies to affect the recovery of a complete key, but prohibits any group of fewer than k agencies from recovering a complete key. 2. They use a verifiable secret sharing scheme in order to prevent deviant users from subverting the secret sharing scheme by providing improper shares. Such a scheme has previously been adopted in a key escrow system to let a group of key escrow agencies verify that they have valid shares [9]. 3. They use an affine expansible verifiable secret sharing scheme to let users and third parties jointly generate an escrowed key, thus preventing deviant users from obtaining a 'shadow-key' (not available to the escrow agency).

142

4. The second scheme makes use of a transferable verifiable secret sharing scheme to transfer shares between two sets of key escrow agencies which may not trust each other. The remainder of the paper is subdivided as follows. In section 2, we present a transferable verifiable secret sharing scheme and an affine expansible verifiable secret sharing scheme based on the Shamir secret sharing scheme, [15], and the Pedersen verifiable secret sharing scheme, [13]. We then propose two mechanisms for international key escrow in section 3. The first, which incorporates Frankel and Yung's idea, [6], makes use of a single group of key escrow agencies moderately trusted by mutually mistrusting domains. The second scheme, which is an alternative to the JMW mechanism, adopts the transferable and verifiable secret sharing scheme to transfer shares between two sets of moderately trusted key escrow agencies, one set within each of two mutually mistrusting domains. In both mechanisms, users and key escrow agencies jointly generate an escrowed key by using the affine expansible verifiable secret sharing scheme. In section 4, we consider possible trust relationships among the three types of entity involved in an international key escrow system, namely moderately trusted third parties, potentially untrustworthy users and multiple mistrusting domains. We conclude by giving two open questions.

2

Verifiable

Secret

Sharing

In this section we first briefly describe the Shamir secret sharing scheme [15] and the Pedersen verifiable secret sharing scheme [13]. We then discuss how to transfer a shared secret between two domains, and also how to share an affine function of a shared secret, using modifications of the Shamir and Pedersen schemes. This work will provide the basis for the key escrow schemes described subsequently. 2.1

The Shamir scheme

A (k, n)-threshold secret sharing scheme is a protocol in which a dealer distributes partial information (a share) about a secret to each of n participants such that o no group of fewer than k participants can obtain any information about the secret, and o any group of at least k participants can compute the secret. We now describe the Shamir (k,n)-threshold secret sharing scheme, [15]. Suppose p and q are large primes such that q divides p - 1, and g is an element of order q in Z . It is assumed that p, q and g are publicly known. These parameters ,/ will be used throughout this paper. Unless otherwise stated all arithmetic will be computed modulo p.

143

Let the secret s be an element of ZH. In order to distribute s among P1, ..-, P,~ (where n < q) the dealer chooses a polynomial of degree k - 1: f ( x ) = ao + al:e + ... + a k _ l x k - 1 ,

where f E Zn[w and a0 = s. Each participant Pi (1 < i < n) receives si = f ( x i ) as his private share, where xi ~ Z~ - {f} is public information about Pi (xi ~ x j , for i 5s j). Any k participants (without loss of generality we assume that they are P1, P2, --., Pk) can find f ( x ) by the interpolation formula, k f(x) =

k (

x ~ _ x~ ) f ( x i ) =

i=l h#i

(

----

)si.

i=1 h~i xi -- ggh

Thus k i=.1 h;~i

2.2

The Pedersen scheme

Assume that a dealer has a secre~ s E ZH and corresponding public value h = g*. This secret can be distributed to and verified by P1, ..., P,~, in the following way: 1. The dealer computes shares .si using the Shamir secret sharing scheme by first choosing a polynomial f ( x ) = ao + a l x + ... + a k _ l x ~-1 over Zix satisfying a0 = s and then computing si = f ( x i ) (1 _< i _< n). Here x~: is public information about Pi as previously. 2. The dealer sends the share si secretly to Pi (1 < i < n) and broadcasts a verification sequence

v = (g~

1,

0

to all n participants. 3. Each Pi (1 < i < n) computes k-1 j=0 and verifies whether hi --=.gSl.

If this does not hold then Pi broadcasts s~ and stops. Otherwise Pi accepts the share. 4. Any k participants, who have accepted their shares, can find s as described in the Shamir secret sharing scheme above.

144

2.3

Transferable verifiable secret sharing

We now consider how to transfer a shared secret between two groups of participants. We start by stating our requirements for a (k, m, n)-transferable verifiable secret sharing scheme, where k, m, and n are positive integers satisfying

1 < k <_ rain{m, n}. * A secret s shared by m participants P1, .--, P ~ needs to be transferred to, and then shared by, another n participants Q1, -.., Qn* The participants Qj (1 < j < n) nmst be able to verify their own private shares without communicating with other participants in the same domain. . Any group of at least k participants in Q~, ..., Q~, who have accepted their shares, can compute s. | No group of fewer than k participants in Q1, .-, @~ can obtain any information about s. We now present a transferable verifiable secret sharing scheme based on the Shamir and Pedersen schemes. 1 Assume that m participants Pi (1 < i < m) share a secret s C Zu using the Pedersen scheme. This secret can be transferred to and verified by another n participants Qj (1 < j <_ n), in the following way:

Algorithm

1. Each Pi (1 < i < rn) computes new shares sq (t < j < n) using the Shamir secret sharing scheme by: 9 first choosing a polynomial fi (x) = aio + aiz x +... + ai(k_ 1)x k- 1 over ZI~ satisfying aio = si, and , then computing sij = fi(xj)..Here xj is public information about Qj. 2. Pi (1 <_ i < m) sends sij secretly to Qj (1 <_ j < n) and broadcasts a verification sequence Vi ~- (ga~o

..,gai(k-t))

to all n participants Qz, ..., Q~ 3. On receipt of sij and Vi (1 < i < m), Qj (1 < j < n) computes k- 1

= 1-I(g~ /=0

and verifies whether hi j _~ gSlj

If this does not hold, Qj broadcasts sij and stops. Otherwise Qj accepts the share.

145

Theorem

2 The above algorithm has the following properties.

1. A n y group of at least k participants in Q1, ..., Qn, who have accepted their shares following A l g o r i t h m 1, can find si (1 < i < m), and hence compute 8.

2. No group of fewer than k participants in Q1, ..., Q~ can obtain any information about si (l < i < m ) and s. 3. Each Qj (1<_ j <_ n) can verify sij (1 < i < rn) and g~ without communicating with other participants in the same domain. Proof All three parts of the theorem hold by using precisely the same arguments as used to prove the same statements for the Pedersen scheme. [] This scheme will be used to transfer a partial escrowed key from a set of T T P s in one domain to another set of T T P s in a second domain in M e c h a n i s m 7 described in the next section. The two groups of participants do not have to trust each other. If fewer than k participants in any domain follow the scheme, the secret transfer cannot be successful, but no one can subvert the algorithm by forcing anyone else to accept a fraudulent secret.

2.4

Atfine e x p a n s i b l e verifiable secret sharing

We now consider an affine expansion of threshold secret sharing. We start by stating our requirements for ~affine expansion'. 9 A secret s E Zq is Shared by rn participants P1, .-., Pro. Its affine function w = as + b, where a,b E Zq and a # 0, needs to be shared by the same participants. Here a and b are public information about Pi (1 < i < m). 9 No group of fewer than k participants can obtain any information about w. 9 Any group of at least k participants can compute w. We now present an affine expansible verifiable secret sharing scheme based on the Shamir and Pedersen schemes. A l g o r i t h m 3 A s s u m e that m participants Pi (1 < i < m ) share a secret s C ZII using the Pedersen scheme, and know public information a E Zq - {0} and b E Zq. A new secret w = as + b E Zq can be shared and verified by the same rn participants without communicating with one another. The new shares wi are wi = asi + b. The corresponding public keys are gWl = gasi+b = (gSl)agb and gW _~ gas+b = (gS)a gb.

146

T h e o r e m 4 The above algorithm has the following properties.

1. It meets the ,requirements for affine expansible secret sharing. 2. Pi (1 < i < m) can verify wi (1 < i < rn) and gW without communicating with other participants. Proof This theorem again follows using precisely the same arguments as are used to establish the properties of the Pedersen scheme. [] This scheme will be used to let third parties provide a.n contribution to an escrowed key in M e c h a n i s m 5 and M e c h a n i s m 7 described below. Because the contribution is not known to users, it is difficult for the users to subvert the escrowed key by using a hidden 'shadow-public-key', the corresponding 'shadowprivate-key' of which cannot be computed by using a real key pair and 'shadowpublic-key' [9]. 3

Escrowed

3.1

key agreement

Assumptions

We make the following assamptions for ore" model of an international key escrow system. o Two entities A and /3, located in mutually mistrusting domains, want to communicate securely with each other. For this purpose they need to verify one another's identity and establish a shared session key KAB, although before the authentication and key distribution processing starts they do not share any secret. o The communications between A and B have to meet potential legal requirements for warranted interception. Interception agencies in each domain are not actively involved in the authentication and key distribution procedures, but may require access to the session key KAB. o In the first scheme ( M e c h a n i s m 5) a single set. of T T P s {T1, ...,Tin} are used as both multiple authentication servers for the users, and key escrow agencies for the interception agencies in both domains. In the second scheme ( M e c h a n i s m 7) two sets of T T P s {TI, ...,Tin} and {U1, ..., U,~}, one group in each domain, are used as multiple authentication servers for the users and key escrow agencies for the interception agencies. In both cases they are responsible for verifying A's and B's identities, establishing a session key f'2aB, and escrowing the session key. They are trusted by both the users and interception agencies collectively, but not individually. 3.2

Mechanism 1

This escrowed key agreement scheme is based on Diffie-Helhaaan key exchange [5] and the verifiable secret sharing schemes described in section 2. In the mechanism, A and B are users in separate domains, and m moderately T T P s T1 .... ,

147

T,~ work for both users as authentication servers, and for interception agencies in both domains as key escrow agencies. We assume that A and B have authenticated channels with T/ (1 < i < m). As in the J M W mechanism, these m T T P s agree a c o m m o n l y held secret key K(T1, ...,T,~) and a function f. This function f shall take as input the shared secret key and the names of A and B, and generate a private integer STAB. The scheme is designed so that for some positive integer k (k < m), any set of k T T P s can compute the session key established between A and/3, but no group of k - 1 or less T T P s can derive any useful information about this session key.

5 A set of T T P s T1, ..., Tm assist two users A and B in establishing a session key KAB, and escrow the key collectively.

Mechanism

1. A secretly chooses and stoT~s its private key agreement value SA, and cornputes the corresponding public value PA (= gS~), the private shares SA, (1 < i < m ) of SA as defined in subsection 2.1, and the public verification sequence VA as defined in subsection 2.2, and then sends SA~ and VA to Ti (l < i < m). 2. B follows the same procedure as A (choosing SB, creating private shares SB~, a verification sequence VB, and sending SB~ and VB to Ti (1 < i < m)). 3. Ti (1 <_ i <_ m ) verifies SA,, PA, and SB., PB as described in subsection 2.2. If the verification fails, Ti broadcasts the suspect share value and stops; otherwise Ti accepts the share. /~. Ti (1 < i < m ) does the following: 9 obtains STAB by using the function f with K(T1,..., T,~), A and B, 9 calculates PAT (= p S T a s ) and PBT (= pSTAs)- and 9 sends PAT to B and PBT to A. 5. A and B separately compute a session key as: I
Theorem

Proof Any group of at least k T T P s can compute SA and SB (by the properties of the Shamir scheme discussed in subsection 2.1 above). Hence they can compute

[(AB and the result follows.

=

g SASBSTAB []

The mechanism has been designed to make it difficult for A and B to prevent

[gAB from being escrowed by using a hidden ~shadow-key'. In addition, no third party can force A or B to accept a wrong message unless all the third parties are colluding, and no group of fewer than k third parties can obtain any information about K AB .

148

The method used to compose a set of key escrow agencies, who are moderately trusted by mutually mistrusting domains, depends on the requirements for international secure telecommunications. The set could consist of T T P s licensed by domains other than the two domains being served, or by a :super-domain' including the two domains, or one or other of the two domains. It would be desirable if STAB could be changed from time to time (which will mean that KAB also changes). This could be achieved by including a date-stamp in the function f used to compute STAB. Compared with a number of other proposed key agreement schemes, such as, letting the two users choose the key (see [7]), letting a set of T T P s generate the key (see [3]), and letting one user and two T T P s generate the key (see [8]), this mechanism forces all involved entities, i.e. both users and the set of T T P s , to jointly generate the key, so that it may be more difficult for users and T T P s to subvert the key. 3.3

Mechanism 2

This escrowed key agreement scheme is based on Diffie-Hellman key exchange [5] and the transferable verifiable secret sharing scheme described in section 2. In this mechanism, A and B are users in different domains. There are rn T T P s T1, ..., T,,~ working for A as authentication servers (in A's domain), and 7z T T P s U1, ..., Un working for B as authentication servers (in B's domain). These servers also operate as key escrow agencies for the interception agencies in their respective domains. Each set of third parties is moderately trusted by their users and interception agencies. Users and interception agencies do not communicate with T T P s outside their domain. T T P T~ (1 < i < m) can communicate with Uj (1 < j _< n). Again, we assume that A has an authenticated channel with each T/, and B has an authenticated channel with each Uj. Each group of T T P s agree a secret key I<(Tx,..., T,~) or K(U,,..., U~,) and a function f . This function f shall take as input the shared secret keys and the names of A and B, and generate private integers STAB and SUAB respectively. The scheme is designed so that for some positive integer k (k < rain{m, n}), any set of k T T P s from one or other of the two domains can compute the session key established between A and B, but no group of k - 1 or less T T P s can derive any useful information about this session key. M e c h a n i s m 7 Two sets of TTPs {T1, ...,T~} and {U1, ...,U~} assist two users A and B (respectively) to establish a session, key NAB. Each set. of third parties escrow the key collectively.

1. A secretly chooses and stores its private key agreement value SA, and computes the following values: 9 the corresponding public value PA (= gSA), 9 the private shares SA~ (1 < i < 'm) as defined in subsection 2. t, and | the public verification sequence VA as defined in subsection 2.2, and then sends SA~ and VA to Ti (1 < i < m).

149

2. Ti (1 < i < m) verifies SA, and PA as described in subsection 2.2. If the verification fails then Ti broadcasts the suspect share value and stops; otherwise Ti accepts the share. 3. B secretly chooses and stores its private key agreement value SB, and computes the following values: 9 the corresponding public value PB (= gSB), 9 the private shares SBj (1 <<j <_ n) as defined in subsection 2.1, and 9 the public verification sequence VB as defined in subsection 2.2, and then sends SBj and VB to Uj (1 < j < ~). 4. Uj (1 <_j <_ n) verifies SBj and PB as described in subsection 2,2. If the verification fails then Uj broadcasts the suspect share value and stops; otherwise Uj accepts the share. 5. Ti (1 < i < m) does the following: 9 obtains STAB by using the function f with K(T1, ...,T,~), A and B, 9 calculates PAT (= p~TAB), " calculates SA,j (1 <_j < n) from SA~ as defined m subsection 2.3, 9 computes the 'private shares' SA,jS~rAB, and their corresponding public values gSA~jST~B as defined in subsection 2.~, and the public verification sequence VA, as defined in subsection 2.2. 9 Finally, Ti sends SA,jSTAB, VA, and PAT to (Tj (1 <_j <_ n). 6. Uj (1 <_ j <_ n) verifies SA,jErAB, VA~ and PAT as described in subsection 2.3. If the verification fails then Uj broadcasts the suspect share value and stops, otherwise Uj accepts the share. 7. ~. (1 <_j <_ n) does the following: 9 obtains SUAB by using the function f with K(U1,..., U.), A and B, 9 calculates PATU (= PSA~AB) and sends it to B, 9 calculates PBu (-= p~vAB), 9 calculates SBj, (1 < i < m) from SBj as defined in subsection 2.3, 9 computes the 'private shares' SBj, SUAB, and their corresponding public values gS~j, SwB as defined in subsection 2.d, and the public verification sequence VBj as defined in subsection 2.2, and, finally, 9 sends SBj~ ~UAB, VBj and PBU to Ti (1 < i < m). 8. Ti (1 < i < m) verifies SBjiSUAB, VBj and PI~u as described in subsection 2.3. If the verification fails then Ti broadcasts the suspect share value and stops, otherwise Ti accepts the share, calculates PBTU (= p ~ A B ) and sends it to A. 9. A and B can now separately compute the session key: I(A.

= ( P B T V ) sA =

(PArr) sB = gSASBS~A~SUAB.

T h e o r e m 8 The above mechanism has the property that any group of at least k TTPs (in either domain) can compute KAB. Proof The proof follows immediately from the results in subsection 3.2 above.

[]

150

In this mechanism, the two sets of third parties in both domains do not have to trust each other, as mentioned in subsection 2.3. For the same reasons as in the previous mechanism, it is suggested that StAB and SUAB should be changed as often as required. 4

Further

considerations

In a key escrow system, the differing requirements of users and interception authorities are further complicated by the introduction of the key escrow agencies (or T T P s ) . The key escrow agencies are responsible to the interception agencies for preventing criminal users from abusing escrowed keys. Both the users and interception agencies should be in a position to check that the key escrow agencies cannot reveal escrowed keys illegally. In international key escrow, the relationships amongst these three groups of entities becomes still more complicated because more than one domain is involved. The key escrow agencies in one domain have a potential requirement to check that the key escrow agencies in the other domain cannot subvert the escrowed keys. In this section, we discussion some aspects of the trust relationships between the various entities involved.

4.1

Moderately trusted third parties

There are two major reasons why we make use of moderately trusted third parties in this paper. <> If interception agencies are not actively involved in session key est.ablishment for possibly deviant users and do not store every session key themselves, key escrow agencies are required to provide a valid key when lawfully authorised. Although the key escrow agencies may not be trusted individually, a group of them might be collectively trusted by the interception agencies. o If two users sharing no secret want to communicate security with each other, they need an authentication service provided by authentication servers. Although the servers may not be trusted individually, a group of them might be collectively trusted by their users. Four kinds of key splitting schemes based on secret sharing schemes (e.g. [2, 15]) have been used for splitting an escrowed key into n shares escrowed by n agencies in previously proposed key escrow systems. The first approach involves ~splitting' with an n out of n scheme, where all n components are needed to restore a given key [12]. The second approach uses splitting with an k out of n threshold scheme, which allows any subset of k of the n escrow agencies to affect the recovery of a complete key, but, prohibits any group of fewer than k agencies from recovering a complete key [9]. The third approach involves splitting with an (n,t, u)-escrow scheme, which allows a. subset of the escrow agencies to recover a key, where t escl:0w agencies could conspire without compromising a key, and n - u agencies could 'withhold' their components without interfering with key

t51

recovery (t < u _< n) [11]. The last approach involves splitting with a 'general monotone access structure', which allows for the specification of arbitrary subsets of escrow agencies that can work together to restore a key [4]. We have used the second approach in the mechanisms described here. Actually, any one of these four splitting schemes could have been chosen, and in practice the choice would depend on the requirements for establishing a set of moderately trusted third parties. Note also that the idea of t/eiter et al. regarding secure group implementation in [14] can be used to establish such a set of moderately trusted third parties and their group key. 4.2

Untrustworthy

users

We now consider the case where users are not trustworthy in a key escrow system. Kilian and Leighton gave a 'shadow-public-key' attack in [9], and we now see how this attack might work in a key escrow system based on Diffie-Hellman key exchange. Each normal user generates a pair (P, S), publishes P and gives an interception authority the ability to reconstruct S, so that both the users and interception authority can compute an escrowed key by using Diffie-Hellman key agreement. In this attack, each of two attackers instead generates two key pairs (P, ,S) and (P', S'), where (P, ,_g) is a proper (public- key, private-key) pail', (P', S') is a 'shadow' key pair, and P ' = f(P) where f is an easily computed and publicly known function. Each of them uses (P, S) in the same way as would an ordinary user, but keeps F' reserved as his shadow private key. Both attackers separately compute a 'shadow-escrowed-key' by using his ~shadow-private-key' and the other's 'shadow-public-key'. If it is infeasible to obtain S' by knowing P , p1 and S, the interception authority cannot obtain the 'shadow-escrowed-key'. Furthermore the interception authority may not detect this cheating. We presented an affine expansible verifiable secret sharing scheme in subsection 2.4, which provided the basis of users and third parties jointly generating an escrowed key in order to prevent the users from using a hidden 'shadow-key'. Note that it only makes sense to prevent criminal users from obtaining a S ~ which is in feasibly computed by using P, P ' and S. The further problem is how in practice to prevent criminal users from abusing the key escrow system by using improper keys, for examples, using an old escrowed key instead of a current one, using a modification of the escrowed key, e.g. which may be a publicly known function of the real escrowed key, and using a 'shadow-public-key', where S' may feasibly be computed by knowing P, P' and S. Although these abuses are all detectable, a key escrow mechanism may never check for such abuses, giving deviant users greater leeway in their abuses. A number of approaches could be used to prevent the above abuses, such as, keeping all old escrowed keys in a valid period to check if they are used again, and monitoring all communication channels between suspected criminal users [10]. Unfortunately, these approaches may not be practical, particularly, in complicated mobile telecommunications systems. In fact, it is impossible for a key escrow system to force two users to use only the current escrow key if the users share a secret or can use their own security

152

system. For the purposes of this paper, we suppose that two users, who want to communicate securely with each other, have to get assistance from key escrow agencies in order to authenticate one another's identity and establish a shared session key. We assume it is detectable if the users subvert key escrow systems by using an old escrowed key or a modified escrowed key. However we have not answered the question of how to force users to use only the current escrowed key.

4.3

Multiple mistrusting domains

So far we have discussed key escrow in mutually mistrusting domains. However, some modern secure communications m a y cover more than two domMns. For example, in a global mobile telecommunications system, two users, respectively, are citizens of countries C and D, work for countries E and F, are registered with two mobile companies belong to countries G and H, and are roaming in two countries I and Y. Their traffic might conceivably need to be intercepted by agencies in any of countries C - J, and hence it m a y be necessary to try and devise an international key escrow system which provides all governments involved with warranted access to user communications. To make matters more complicated, the countries involved m a y not all trust each other. Our first mechanism, as described in subsection :3.2, could be used for this purpose. However, whether or not a set of key escrow agencies could be set up which are moderately trusted by multiple mistrusting domMns, depends on political considerations beyond the scope of this paper. The second mechanism, as described in subsection 3.3, could also be used for this purpose, at least in theory. The problem is that each set of key escrow agencies in each domain involved have to collaborate to provide contributions to the escrowed key. This m a y not be practical, particularly when the number of domMns involved is quite large. 5

Conclusions

We have described a key escrow system using moderately trusted third parties in mutually mistrusting domains and analysed its use. The following open questions are of potential practical importance. o Do there exist practical key escrow systems forcing users to use only the current escrowed session key? o Can a practical key escrow scheme be designed for the case where more than two domains are involved, and where escrow agencies are not permitted to span more than one domain?

References l. National Institute of Standards and Technology. FIPS Publication 185: Escrowed Encryption Standard. February 1994.

153

2. G.R. Blakley. Safeguarding cryp~ographic keys. In the Proceedings of A F I P S 1979 NCC, Vol. 48, Arlington, Va., pages 313-317, June 1979. 3. L. Chen, D. Gollmann, and C. Mitchell. Key distribution without individual trusted authentication servers. In Proceedings: the 8th IEEE Computer Security Foundations Workshop, pages 30-36. IEEE Computer Society Press, Los Alamitos, California, June 1995. 4. D.E. Denning and D.K. Branstad. A taxonomy for key escrow encryption systems. Communications of the A CM, 39(3):34-40, 1996. 5. W. Diffie and M.E. Hellma~l. New directions in cryptography. [EEE Transactions on Information Theory, 22:644-654, November 1976. 6. Y. Frankel and M. Yung. Escrow encryption systems visited: attacks, analysis and designs. In D. Coppersmith, editor, Lecture Notes in Computer Science 963, Advances in Cryptology - - C R Y P T O '95, pages 222-235. Springer - Verlag, 1995. 7. L. Gong. Increasing availability and security of an authentication service. [EEE Journal on Selected Areas in Communications, 11:657-662, I993. 8. N. Jefferies, C. Mitchell, and M. Walker. A proposed architecture for trusted third party services. In E. Dawson and J. Golid, editors, Lecture Notes in Computer Science 1029, Cryptography: Policy and algorithms Conference, pages 98-104. Springer-Verlag, 1996. 9. J. Kilian and T. Leighton. Fair cryptosystems, revisited. In D. Coppersmith, editor, Lecture Notes in Computer Science 963, Advances in Cryptology- C R Y P T O '95, pages 208-221. Springer - Verlag, 1995. 10. A.K. Lenstra, P. Winlder, and Y. Yacobi. A key escrow system with warrant bounds. In D. Coppersmith, editor, Lecture Notes in Computer Science 963, Advances in Cryptology - C R Y P T O '95, pages 197-207. Springer - Verlag, 1995. 11. S. Micah and R. Sidney. A simple method for generating and sharing pseudorandom functions, with applications to clipper-like key escrow systems. In D. Coppersmith, editor, Lecture Notes in Computer Science 963, Advances in Cryptology - C R Y P T O '95, pages 185-196. Springer - Verlag, 1995. 12. J. Nechvatal. A pubhc-key based key escrow system. Journal of Systems and Software, to appear October 1996. 13. T.P. Pedersen. Distributed provers with apphcations to undeniable signatures. In D. W. Davies, editor, Lecture Notes in Computer Science 547, Advances in Cryptology: Proc. Eurocrypt '91, pages 221-238. Berhn: Springer-Verlag, 1991. 14. M.K. Reiter, K.P. Birman, and R. van Renesse. A security architecture for faulttolerant systems. A CA/[ Transactions on Computer Systems, 12:340-371, 1994. 15. A. Shamir. How to share a secret. Communications of the ACM, 22:612-613, 1979.

Automatic Event-Stream Notarization Using Digital Signatures Bruce Schneier

John Kelsey

Counterpane Systems, 101 East Minnehaha Parkway, Minneapolis, MN 55419 {schne ier, ke!sey}~counterpane, com

Some digital sigz:ature algorithms (such as RSA) require messages to be padded before they are signed. Secure tokens can use these padding bits as a subliminal channel to embed auditing information in their signed messages. These auditing bits simplify protecting against lost and stolen tokens, breaks of specific protocols, hash functions, and ciphers, and attacks based on defeating a token's tamper-resistance. Abstract.

1

Introduction

We present a signature format which simplifies the task of designing strong protocols for tamper-resistant tokens, like smart cards. The basic idea embeds auditing information within the block to be signed. Packets signed by RSA are typically 512- to 1024-bits long, sometimes even longer; hashed messages are only 128- or 160-bits long. These hashed messages are padded to the length required by RSA, generally with fixed bits. Some fixed bits are required to prevent arbitrary bit strings from being valid signatures and other cryptanalytic attacks against RSA, but far more bits are available than are needed to prevent these attacks. These bits can be more usefully used for other things.: Many protocols add auditing information to messages before they are hashed and signed, but that increases the length of the message and often cannot be enforced from within a token. Our signature format is essentially a subliminal channel [11], under the control of the token--one that cannot be affected by any party in the protocol--and allows the token to embed auditing information in everything it signs. The token has this ability regardless of the protocols that use it, even if it does not create or hash the actual messages. The most generally useful part of the auditing information included is the hash chain [4]: a cumulative hash of everything the token has signed to date. Every signed message depends on every previous signed message; this makes it very difficult for an attacker to make any valid-looking changes in previous transactions, even if he manages to defeat the token's tamper-resistance. This idea is used in [1, 6]. 1

Jean-Jacques Quisquater and Louis Guillou suggested embedding message bits within an RSA signature [8], which was the impetus for this idea.

156

Our protocols attempt to prevent as many potential attacks as possible. For those attacks which we cannot prevent, we attempt to minimize their damage and increase their cost to the attacker. Because token systems of this kind may be implemented in many different legal environments, we do not generally assume that the law will be helpful in tracking down incidents of fraud or misuse [2, 3]. We also attempt to increase the potential evidence available in the even of fraud. Fraud does not happen in isolation: someone does not steal $1M and then disappear. He is likely to spend some of the money. While our protocols might not prevent someone from stealing $1M, they will lead investigators to potential suspects for that theft.

1.1

Token Resources Needed

The tokens discussed in this paper require the following resources for most or all protocol steps: a. Sufficient storage to record all protocol messages in some kind of log. This is needed to provide an audit trail. Some implementations can store this log on the token itself, while others may require the user keep his own audit log and surrender it in ease of a dispute. b. Sufficient non-secure storage to maintain a current public-key certificate for the token's internal key. c. An internal, secure private/public key pair, with the private key not known by any entity except the token, and the public key certified by the token manufacturer or certification authority. (This is essentially the "Verify-Me" key in National Semiconductor's CAKE proposal [12].) d. Several internal, securely stored values: a counter, key ID, token ID, and chained hash value. e. Secure facilities for performing digital signatures and message hashing. f. An internal, secure source of random bits. Additionally, some protocols will also require: g. Secure facilities for performing public key and symmetric encryption. h. An internal, secure clock. i. A non-secure link with some external device, such as a hard drive controller or a LAN or m o d e m card. j. Some small additional secure memory, and the ability to do very simple operations upon it, such as subtraction and comparison with zero.

2

Building the Signature Packet

This section defines a specific format for signature packets. This signature format is incompatible with existing formats: e.g. PKCS [9]. A signature packet is a

157

relatively large block of data which is digitally signed with message recovery by the card. The best known digital signature scheme which allows signatures with recovery is RSA. The DSA algorithm cannot be used for this, since it does not allow message recovery. Digital signature schemes based on the discrete logarithm problem which allow message recovery are discussed in [7]. For the remainder of this paper, we will assume RSA. The signature packet has the following fields: a. Signature packet version b. Token ID c. Signing key ID d. Packet sequence number e. Hash of hash of most recently signed packet f. Hash of hash of most recently received packet g. Optional 64 or 128-bit data field

h. hash(hash(message), hash(a - - 9 ) ) Each of these fields is useful for preventing or increasing the difficulty of some kinds of attack.

S i g n a t u r e p a c k e t v e r s i o n The signature packet type and version tells the receiver of the packet how the packet is to be processed. (Many protocols will also require a message-type byte in the message, rather than the signature packet.) This is a 24-bit field, with the following structure: bit 0 - always zero ] bits 1..7 reserved--set to all zeros for version 1.x bits 8..15 major version byte bits 16..23 minor version byte A given version number corresponds to a single signature algorithm, key size, packet format (including use and meaning of optional fields), hash function, symmetric and asymmetric encryption algorithm, as well as other things. As an example, Version 01.00 might correspond to signature and asymmetric encryption algorithm RSA with a 768-bit modulus, hash function SHA1, symmetric encryption function two-key triple-DES, and no defined optional fields. Version 01.01 might correspond to the same thing, with a 64-bit optional field defined as a token-generated random number. A recipient of a signature packet with version 01.01 would then know that, if the sender's tamper-resistance hadn't been defeated, the random number that appeared in the optional field was not under the control of the sending token's owner. By including the signature packet version, we prevent some attack which involve trying to get a system to use an older We also make explicit our packet version, so that it is simple internally scan the version and accept or refuse to accept it. We

kinds of replay packet version. for the card to allow backward

158

compatibility if later versions add more fields or change their width, since the first. 24 bits of the packet can always be easily found. Note that the high-order bit must always be a 0 in RSA-based versions.

T o k e n I D Each token has a unique 64-bit ID, possibly further subdivided into 16 bits defining a specific manufacturer and 48 bits identifying a unique token. By including the token ID, we dramatically simplify the problem of tracing lost or stolen tokens. In most cases, lost or stolen tokens are dealt with using only the token ID, key ID, and sequence number.

S i g n i n g k e y ID Each key has a unique 64-bit key ID. This key ID is always included in key certificates, and can easily be fit into an X.509 certificate. The purpose of the key ID is mainly to make easy to find a unique identifier of the key being used to sign the signature packet. (Note that some tokens may have more than one signing key.) In some applications, 16 bits may signal a specific certification authority, and 48 bits this key's specific IDo As long as the key ID is unique, this does not present a problem.

P a c k e t s e q u e n c e n u m b e r The packet sequence number is 32 bits long, and is incremented by 1 every the token signs a message. Its purpose is to frustrate most replay and insertion attacks on protocols, and also to make it easier to trace lost or stolen tokens by issuing a "stop transaction" order on all transactions after sequence number X. Additionally, this ensures that there are never two identical signature packets generated by the same properly- functioning token. Finding two packets with the same sequence number, key ID and token ID is evidence that something very bad is happening with that token.

H a s h o f h a s h o f m o s t r e c e n t l y s i g n e d p a c k e t This field is included so that the sequence of signatures from a given token will form a hash chain. This ensures that, even when a token's private key is compromised, it won't be possible for an attacker to modify previously-completed transactions. The audit trail created by this hash chain is as difficult, to bypass as it is to find collision values for the hash function. A similar hashing chain is used ~o build a digital timestamping service in [HS91]. We include the hash of the previous hash, instead of the hash itself, to avoid any chance of an attack based on an untrusted application providing this value to the token. H a s h o f m o s t r e c e n t l y r e c e i v e d m e s s a g e This field ensures that the sequence of messages in a protocol form a hash chain. This makes replay and "cut and paste" attacks impractical, and makes every step in each protocol dependent on every previous step. We include the hash of the previous hash, instead of the

159

hash itself, to avoid any chance of an attack based on an untrusted application providing this value to the token.

Optional 64- o r 1 2 8 - b i t d a t a field This field can be included in the packet to carry internally generated random values or timestamps, often with the guarantee that if the token's tamper resistance hasn't been defeated, these values come directly from the token and not from the user. a - - - - g ) This is the hash of the rest of the signature packet and the current message. Note that by including the hash of the other party's most recent message in the current message, we get every protocol message cryptographieally dependent upon every previ'ons protocol message, in an auditable chain that extends through every transaction performed by each token. This is intended to make recovery fi'om various kinds of attack as easy as possible and to leave a very strong audit trail. As a side-effect, this chain of hashes fi'ustrates insertion and replay attacks in any protocol where the chained hashes are checked and all messages in the protocol are signed. Hash(message,

Note that prepending (rather than appending) a-g would leave the hash chains vulnerable to some message-extending attacks after a token's private key had been compromised.

2.1

Size o f t h e P a c k e t

The packet's minimum size is determined by the size of the hash function's output and by whether or not the optional 64- or 128- bit data field is used. For a 160-bit hash, the minimum packet size is 664 bits. For a 128-bit hash, the packet size is 568 bits. For most practical implementations of digital signatures, there is sufficient room for both the signature packet and additional redundant information to frustrate cryptanalysis.

3

P r o t o c o l building blocks

There are three protocol building blocks (subprotocols) which, along with the signature packet format, simplify the design of robust and secure protocols. We assume that, while executing these protocols, no other signing operations are performed with the token. In other words, the token must complete all the steps of one protocol before starting another.

3.1

Interlock

The interlock subprotocol is intended to convince two tokens (referred to in this section as Alice and Bob) that they are communicating with one another in

160

real time [5]. If all messages passed after the interlock subprotocol is performed are signed using the specified signature packet formats, then attacks based on insertion, alteration, or replay of messages should be impossible. If CA is Alice's certificate, and works as follows:

CB is Bob's certificate, the interlock protocol

(1) Alice: (a) Generates a random number, r20. (b) Forms message M0 = (R0, CA). (c) Sends to Bob Mo, Sign(Mo). (2) Bob: (d) Verifies CA. (e) Verifies Sig,n(Mo). (f) Generates a random number, R1. (g) Forms M1 = hash(Mo), R1, CB. (h) Sends to Alice M,, Sign(M,). (3) Alice: (i) Verifies CB. (j) Verifies Sifln( M1 ). (k) Verifies hash(Mo). (1) Forms M2 = (hash(M1)). (m) Sends to Bob M2, Sign(M2). (4) Bob:

(n) Verifies

Sifln(M2).

(o) Verifies

hash(M1).

At the end of step (3), Alice has seen enough to verify that she is getting a response by someone who knows Bob's private key, as specified in CB, because he has returned a signed message which includes a hash of her first (partially random) message, and a key certificate. After step (4), Bob can verify that he's getting a response from someone who knows Alice's private key, as specified in CA, because he, too has gotten an appropriate response to his message. In both cases, Alice and Bob each know that the other party received their entire certificates intact. This may guard against some obscure attacks, such as where Alice is talking to Bob legitimately but simultaneously Bob is pretending to be Alice to a third party. All later messages are signed, and use our signature packet

format. Note that verifying the certificates means verifying the signatures, the valid dates (possibly the issued-date of the other party's certificate against the issueddate of the token's own certificate), and possibly checking the certificates against a list of known stolen or invalid key IDs or token IDs. It's important to note that while Alice the token knows whom she's dealing with (Bob, whose token ID and key ID are clearly noted inside CB), there isn't any cryptographic way to ensure that Alice's human owner knows which Bob she's interacting with. (This is known as the "Chess Grandmaster's Problem.")

16t

For applications in which this is a problem, it is a good idea to equip the token with some kind of display, and to show some human-readable identification from CB. This gives the owner of Alice the token an opportunity to end a transaction in which she doesn't want to be involved, or at least the knowledge that she has been involved in this unwanted transaction.

3.2

Interlock W i t h Privacy

The interlock subprotocol can easily be extended to support a secure key exchange and encrypted communications. The protocol is identical for substeps (a) through (k). (1) Alice: (a) Generates a random number, R0. (b) Forms message M0 = (R0, CA). (c) Sends to Bob Mo, Sign(Mo). (2) Bob: (d) Verifies CA. (e) Verifies Sign(Mo). (f) Generates a random number, R1. (g) Forms M1 = hash(Mo), R1, CB. (h) Sends to Alice M,, (3) Alice: (i) Verifies CB. (j) Verifies Sign(M1). (k) Verifies hash(Mo). (1) Generates a random number, R2. (m) Forms I ( E = (PKEncrypt(R2, key = PI(Bob), PKEncrypt(R~, key =

PKAtic~)). (n) Forms M2 = (hash(M,), KE). (o) Sends to Bob M2, Sign(M2). (p) Forms session key KS = hash(Ro, R1, [t;). (4) Bob: (q) Verifies Sign(M2 ). (r) Verifies hash(M1). (s) Forms session key KS = hash(Ro, R1, R2). In all messages after this one, Alice and Bob sign the plaintext messages, then encrypt them and their signature packets under a symmetric algorithm. (The specific symmetric algorithm should be specified by the signature packet version.) Note that KE is encrypted under both Bob and Alice's public keys, so that either token can reproduce the session key, and thus present the plaintext that was originally signed for audit. In some systems, it may also be necessary to encrypt R2 under an auditor's public key.

162

3.3

Trusted Values from the Card

Some protocols benefit from having the card generate some internal, trusted value, such as random numbers or timestumps. In this case, the purpose of the interlock operation is going to be for Alice to get this trusted value from Bob. The simplest way to do this is to go through the interlock process, with Alice's FirstProtocolMessage set to a request for a random number or a timestamp. Bob's response is an acknowledgement message, signed with a signature packet which also includes a random value. Note that the signature packet version is used to indicate that this packet's random number or timestamp emerged Dom the token. Some tokens may always include random numbers in their signatures. (It's important to note that this kind of token would be especially vulnerable to attacks based on a subliminal channel in the random number stream; it would be trivial for a tamper-resistant device to leak 64 bits of private key per signature. This needs to be guarded against.) For applications which need these trusted values to be private as well, we use the Interlock-with-Privacy subprotocol, and the next message requests a random number or timesta.mped signature packet. Note that after Interlock-with-Privacy, all further communications, including signature packets, are encrypted.

4

Sample applications

In this section, we give several sample applications using this signature packet and the above subprotocols. These applications aren't meant as finished products, but instead as e• of the usefulness of this kind of construction.

4.1

The Digital Timestamping Proxy

Haber and Stornetta have designed some clever methods for timestamping digital documents [6]. Some variations of their methods can be used by a tamperresistant token, to allow it to function as a proxy for a master digital timestamp server. For example, the card may sit on an internal network, and be available for users of the network to timestamp their documents. Perhaps once per week, the card interacts with the master timestamp server, leaving the hash of its chain of hashes with the server. So long as the hash function is secure, this chain of hashes can't be altered even if thd tamper resistance of the card is defeated somehow. In this protocol, additionally, Bob is assumed to hawe a tamper-resistant clock. (The protocol can be done less elegantly without the clock.) Alice, Bob, and Trent are the players in this protocol. Alice is a user's card, Bob is the timestamping service proxy, and Trent is the timestamping service. (As discussed below, it turns out that Trent doesn't need to be just one device; it can be a network of cooperating devices.) When Alice has a hash value to get timestamped, she interlocks with Bob, and sends her hash value as her first protocol message. After Alice and Bob

163

have completed steps (1) through (4) in the interlock protocol, Bob performs the following: (p) Forms M3 = hash(M2). (q) Sends to Alice Ma, SignWithTirnestamp(Ma). At this point, Alice has a verification of her hash, timestamped by Bob the tamper-resistant card. When Bob interacts with Trent, things work the same way. Bob fills the part of Alice in the interlocking protocol, and Trent takes the part of Bob. Bob ends up with a timestamped verification of his hash value, which is the hash of his Chain of hashes since his last interaction with Trent. Bob must also send his chain of hashes to Trent, as his FirstProtocotMessage. If someone steals Bob, the users can get together to recreate their interactions with Bob and can (with Trent's help) produce authentication of the order of their timestamps since Bob's last interaction with Trent. Of course, every interaction before that has been saved by Trent, and can be authenticated with a consistent hashing chain and with newspaper-published hashes. If someone hacks into Bob, or there are other reliability problems with Bob, we can use similar techniques to maintain the integrity of our timestamps. It is important to note that for some applications, Alice would need to send an entire file to Bob, so that she could not conveniently lose it later if it held some incriminating information about her. Even if Trent is lost or subverted, we can use alI of the proxies to reproduce complete, internally-consistent hash chains. In a real-world system, these hash chains would be backed up off-site on a regular basis.

4.2

Auditable Applications

Many applications need a strong audit trail. In particular, security-relevant operations should generally be logged, and it should be very difficult to delete or alter the logs, and impossible to do so without being detected. The most obvious applications for this kind of thing are for key certification and key escrow agencies; in both cases, it should be infeasible to perform some operation (certify public keys, recover private or secret keys) without leaving an audit traii. Any auditable application can be attacked in at least one simple way, which cannot be prevented by cryptographic means. We will call this the "end-run" attack. The end-run attack happens when a group of users gets together and sets up their own separate system which isn't audited. To the extent that most or all of tlle resources controlled by an auditabte application can be acquired outside the system, this attack is effective. The obvious example of an end-run attack is a key-escrow system whose escrowed keys are kept in a carefully-audited database for police use, and in a "black" unaudited database for intelligence agency use. In real-world systems, this attack needs to be guarded against, but we cannot

164

provide much protection from this at the cryptographic level. About the only thing we can do is to ensure that all messages to and from the auditable application are encrypted. This makes it significantly harder for a rogue organization with some, but not all users cooperating with it to keep its black system in synch with the legitimate system. Another potential attack exists any time we leave authenticated logs with a user who could be prosecuted for whatever information is on the logs. The user may decide he's better off to :'accidentally" delete the logs, and perhaps wind up in jail for it, than to certainly go to jail for the evidence that exists on the logs. We will call this the '~Watergate attack." This can't be guarded against by cryptography, but it can be guarded against by good system design. These are the players in this protocol: Alice is the auditor's card, Bob is the user's card, Carol is the card that's controlling the audited application. We also have Mallory, the possibly malicious network owner. He can insert, delete, change, replay, and observe messages between Carol and Alice and Bob. He has a card that he's hacked open, which may or may not be on Carol's list of acceptable Bob users. Bob uses the application by interlocking with privacy with Carol, and then by sending a request for some operation or information. If Bob is authorized to do this operation (Carol must know Bob's identity a.t the end of the interlockwith-privacy protocol), Carol carries it out. In any case, the protocol messages are kept in a log. Additionally, Carol encrypts the session key used under Alice's public key as well as its own in substep (m) of the protocol. Any response data is sent back to Bob, encrypted. Alice regularly interacts with Carol. First, they Interlock- with-Privacy, and then Alice requests copies of all logs since her last interaction. Carol verifies that Alice is authorized for this, and if she is, sends her the logs, encrypted and signed. Alice can use this and her knowledge of' the signature packet format and Carol's public key to verify all transactions that have occurred in the time covered by the logs. Bob the card may have his tamper-resistance defeated, but while this allows Bob's human owner to hand out his private key to his friends, it doesn't keep him from being audited. Even defeating Carol's tamper-resistance and recovering her private key doesn't allow repudiation of old logs, only of future ones. Mallory can prevent messages from getting into and out of Carol. He can even alter her log. However, by doing this, he can't frame anyone: any alterations he makes are detected by Alice when she interlocks with Carol (and thus has the correct ending chained hash), and notices that there is an inconsistency. Mallory can destroy the logs, but only for tlhe short period of time between Alice's interactions with Carol. In addition, if Mallory wants to reverse engineer Carol, he has to somehow convincingly interact with Alice and all of the Bobs out there while he's doing it; otherwise everyone will. know something is going on.

165

4.3

The Guaranteed

Checking Account

Many secure payment protocols have been published. Ours is relatively simple, and intended to demonstrate the ease with which we can build good protocols from these signature packets and starting protocols. This system is meant to allow users to have a guaranteed checking account, where identity is verified by both possession of a smart card and by a PIN, and where sufficient funds to cover each "check" is guaranteed by the tamperresistant card. It is i m p o r t a n t to note that the account that these cards draw on must be frozen while the cards are active; otherwise they can't possibly know how much money they are allowed to spend. This system protects its users' privacy by encrypting transactions, no anonymity is supported. This is a design feature: recovery from m a n y kinds of problems involves the ability to trace a given user's transactions. Any two tokens, Alice and Bob, can transfer money freely between them, so that if Alice has $500 and Bob has $200, it's possible for them to interact to distribute that $700 in any way they choose. This works just like a checking account. However, there should be no way for them to interact in such a way that their total money after their transactions is more or less than $700. Hence, they are allowed neither to overdraw, nor to burn money in their fireplace. Three interesting things can happen in this system: Alice can transfer some money to Bob, Alice can reconcile with Dave the banker, and Trent the auditor and Dave the banker can try to recover from some attack.

S p e n d i n g Alice and Bob are tokens. The purpose of this protocol is to allow Alice to transfer some money to Bob. The first part of this is that Alice's h u m a n owner requests a transfer of $X to Bob. Alice verifies that her current internal balance is more than $X. If not, she refuses to initiate the protocol. This is not seen as an attack, it's seen as a standard operating mode of the system, protecting the user from an embarrassing miscalculation. Assuming she has the money, things proceed as follows: First, Alice and Bob interlock-with-privacy. For this application, the KE value in substep (m) of the protocol includes the session key encrypted under the bank's public key. Also for this application, note that the certificates contain valid date and sequence number ranges. Each token's certificate has an issued-date. If the issued-dates of the two tokens' certificates are more than T days apart (the smaller T is, the more often tokens must interact with the bank, but also the less time a hacked token has to write bad checks), then the tokens refuse to accept the certificates as valid, and the interlock-with-privacy protocol fails. This is used to limit the total amount of time that a rogue card (one which has been reverse-engineered) can possibly write bad checks. Next, Alice sends Bob an encrypted and signed "check" which says something like "Alice's account number transfers $X to Bob's account number." To prevent attacks based on spoofed account numbers, their account numbers are the hashes

166

of their public keys. These have been exchanged with the certificates in the interlock-with-privacy protocol, as described above. At this point, the protocol ends with an acknowledgement message from Bob. If Alice doesn't receive the acknowledgement message, she flags it as an error condition and assumes that the money has been transferred to Bob. This should be relatively rare, but it needs to be defined to prevent some classes of attacks. Bob knows whether he's got the money, because he can assume he has money as soon as he has received Alice's signed check. Now, Bob and Alice each adjust their internal balances, and go on about their business. Note that if Alice the token has been reverse-engineered or hacked, she can write bad checks to Bob. The bank has guaranteed these, and we can't assume that the authorities most places will be terribly helpful, so the bank has to have some faith that tamper-resistance is hard to defeat, so that this occurs only very rarely, and also that it can recover quickly from these rare events, and freeze the hacked token before its owners can make much of a profit. (Losing $100,000 or more on their a t t e m p t e d seam is more likely to deter t h e m from trying again than having the police after them.)

R e c o n c i l i n g w i t h t h e B a n k Alice is a user's token and Dave is a bank's token. The purpose of reconciliation is for Alice to send her accumulated logs of transactions to Dave, and then for Dave to send her a new certificate, and a new list of invalid keys or certificates. This list should be fairly short, since the certificates themselves are pretty short-lived. The T p a r a m e t e r defines how often each user must reconcile with the bank, because the bank issues certificates. If T is set to 20 days, then each account owner must reconcile with the bank every 20 days, or their token can't operate with anyone. If T is set to 5 days, then we wind up with only a very short window for a user with a hacked token and write bad checks, before his token is permanently frozen. Similarly, if Alice complains to the bank that she was mugged by some guy who'd just watched her punch in her PIN to buy something, they won't re-issue a valid certificate to the token, so the robber only has a few days of spending left. There m a y even be discounts for high-volume users to operate with a lower T, perhaps reconciling once per day. Additionally, all tokens that reconcile after the robbery is reported or the bounced checks are noticed have this token ID and key ID on their reject list, so it should quickly become difficult for a robber to use his stolen token, or for the user of a hacked token to write bad checks. Reconciliation should be possible by telephone so long as the token's certificate hasn't lapsed. If it has lapsed, then the token should need to be brought into a branch office of the bank. This gives us some chance of noticing physically hacked tokens, and also leaves us with pictures of some of the people involved on our ~ecurity ca.meras. The reconciliation protocol works as follows: First, Alice and Dave interlockwith-privacy. Next, Alice sends Dave her entire transaction log since her last

167

reconciliation, encrypted and signed. Dave verifies that her transactions don't disagree with other information available to him, and that all the logs are internally consistent. Alice may also request some additional transactions, such as moving money into or out of this account. Dave either performs these, refuses, or forwards them to some other party which can decide whether to perform them. Dave sends Alice her new current balance and her new certificate in the same message, and Alice verifies it, and sends Dave a receipt. Dave signs it and sends it back to Alice. If she doesn't get this receipt, she must call back and interact with Dave again to deal with this. If Alice has had some transactions end without proper receipts, she notes this in her transaction logs, and Dave reconciles this as well as possible: If he hasn't yet heard from the other parties in that, he leaves her balance as she has calculated it, but notes that if the transaction doesn't show up in those parties' logs, Alice should get the money back. As soon as Dave learns of overdrawn checks or stolen or lost tokens, he adds the token's certificate (with its key and token ID) to the bad certificate list, and refuses to issue that token another certificate until problems have been resolved. This should require intervention from another token, Trent.

A u d i t Dave routinely interacts with Trent, the auditor and timestamp service, at least once per day. He Interlocks-with-Privacy and sends encrypted, signed logs and running hash chains that have come in since the last interaction, and gets back a timestamped receipt. These, along with the chained hashes available in Dave's logs, protect the logs from someone defeating Dave's tamper resistance and changing previous logs. In addition, Dave needs to be under good physical security, including continuous surveillance camera coverage. If a problem arises, things have to be handled by humans using lega.1 and accounting, rather than cryptographic, methods. However, it should be possible to verify that the logs are correct up to some point. Trent also is able to (traceably) re-authorize frozen key and token IDs. Dave will take no other source for these orders. Trent may well be several tokens that must act together to authorize this.

4.4

D i s t r i b u t e d Secure Applications

All of the schemes above can be implemented with the "overseer" role (Trent the timestamping service, Alice the auditor, Trent the auditor) performed by a network of cards interacting. We will outline this using the timestamping service as an example. Instead of having one Trent, we have some large number of time- stamping proxies. Each is implemented in tamper-resistant hardware, with a tamperresistant clock. Instead of publishing hashes, the network of proxies continuously interacts. It's fairly easy to draw a network in which each proxy connects to four others: every so often, proxy A backs up its logs with an interaction with proxy B, getting a timestamp from B in the process. This kind of design can make it

168

arbitrarily difficult to spoof a digital timestamp. Similar designs can work for key certification or key escrow, audited applications, payment protocols, etc.

5

Further Work

Other audit fields could be embedded into the signature packet, which may be useful in some applications: the identity of the signer (in the case where multiple signers share the same token), the identity of the application producing the signature, and the intended recipient of the signature. These fields are different than the ones described above in that they must be explicitly told to the token by the user or application, and hence can be forged.

6

Conclusions

We have presented a signature packet format which automatically includes the key ID, token ID, a sequence number, and the current value in a running hash chain. It is hoped that this format can be used to develop token-based protocols which are more robust than was previously possible. Additionally, we feel that these techniques could be useful design principles for software implementations for abstract protocols.

7

Acknowledgments

The authors would like to thank Paul Kocher and David Wagner for their helpful comments, and the National Semiconductor iPower Business Unit for helping fund this research.

References 1. R. Anderson, "UEPS - - A Second Generation Electronic Wallet," Computer Security - - ESORICS '92, Springer-Verlag, 1992, pp. 411-418. 2. R. Anderson, "Why Cryptosystems Fail," Communications of the ACM, v. 37, n. 11, Nov 1994, pp. 32-40. 3. R. Anderson, "Liability and Computer Security: Nine Principles," Computer Security - - ESORICS '9~ Springer-Verlag, 1994, pp. 231-245. 4. R. Anderson, "Robustness Principles for Public Key Protocols," Advances in Cryptology - - C R Y P T O '95, Springer-Verlag, 1995, pp. 236-247. 5. D.W. Davies and W.L. Price, Security for Computer Networks, Second Edition, John Wiley ~ Sons, 1989. 6. S. Haber and W.S. Stornetta, "How to Time-Stamp a Digital Document," Journal of Cryptology, v. 3, n.2, 1991, pp. 99-112.

169

7. K. Nyberg and R. Rueppel, "Message Recovery for Signature Schemes Based on the Discrete Logarithm Problem," Advances in Cryptology - E U R O C R Y P T '94, Springer-Verlag, 1995, pp. 182-193. 8. J.-J. Quisquater and L. Guillou, "DSS and RSA,"presented at the rump session of Eurocrypt 1995. 9. RSA Laboratories, "Public Key Cryptography Standards #1: RSA Encryption Standard," version 1.5, 1 November 1993. 10. B. Schneier, Applied Cryptography, 2nd Edition, John Wiley & Sons, 1996. 11. G.J. Simmons, "The Prisoner's Problem and the Subliminal Channel," Advances in Cryptology: Proceedings of C R Y P T O '83, Plenum Press, 1984, pp. 51-67. 12. W.B. Sweet, "Commercial Automated Key Escrow (CAKE): An Exportable Strong Encryption Proposal, Version 2.0," National Semiconductor iPower Business Unit, 4 June 1995.

Why Isn't Trust Transitive? Bruce Christianson 1 and William S. Harbison 2 Faculty of Information Sciences, University of Hertfordshire : Hatfield 2 Computer Laboratory, University of Cambridge

A b s t r a c t . One of the great strengths of public-key cryptography is its potential to allow the localization of trust. This potential is greatest when cryptography is present to guarantee data integrity rather than secrecy, and where there is no natural hierarchy of trust. Both these conditions are typically fulfilled in the commercial world, where CSCW requires sharing of data and resources across organizational boundaries. One property which trust is frequently assumed or "proved" to have is transitivity (if A trusts B and B trusts C then A trusts C) or some generalization of transitivity such as *-closure. We use the loose term unintensional transitivity of trust to refer to a situation where B can effectively put things into A's set of trust assumptions without A's explicit consent (or sometimes even awareness.) Any account of trust which allows such situations to arise clearly poses major obstacles to the effective confinement (localization) of trust. In this position paper, we argue against the need to accept unintensional transitivity of trust. We distinguish the notion of trust from a number of other (transitive) notions with which it is frequently confused, and argue that "proofs" of the unintensional transitivity of trust typically involve unpalatable logical assumptions as well as undesirable consequences.

1

T h e N e e d for T r u s t

Principals engaging in a security protocol often require justification for doing so. They must be able to prove that they are "entitled" to take the visible actions which they do on the basis of their own individual (and possibly highly private) policies. In order to prove this, they will typically need to make explicit "trust assumptions" about other parties participating in the protocol. Trust is then used as a substitute for knowledge in order to demonstrate that the protocol has the security properties that the principal desires. Theories of knowledge typically endow knowledge with a strong form of inter-subjective agreement often mis-deseribed as "objectivity". But unlike knowledge, trust is strongly subject-dependent. The confinement or localization of trust is desirable in order to allow a principal to contain the risk that her participation in the protocol actually endows her system with additional properties which she urgently desires it not to have. Unwanted secret-sharing must be assumed transitive in any sensible threat model. One of the great strengths of public-key cryptography is its potential to allow the localization of trust, since it does not require any secrets to be

172

shared. This potential is greatest when cryptography is present to guarantee data integrity rather than their secrecy, and where there is no natural hierarchy of trust. Both these conditions are typically satisfied in the commercial world, where CSCW requires sharing of data and resources across organizational boundaries. Trust is an elusive concept, however. Many treatments of security attempt to take trust as a primitive with postulated properties, and derive consequences. One property frequently postulated or "derived" is some form of transitivity. In the simplest case (writing "A trusts B" as shorthand for "A trusts B about X under certain conditions") we allegedly have: If: A trusts B .&, B trusts C :then. A trusts C

frequently written with the addition of the sentiment "whether A is aware of the fact or not". We use the loose term m~intensional transitivity of trust to refer to a situation in which B can act in such a way as to put things into A's set of trust assumptions without A's explicit consent (or sometimes even A's awareness.) Acceptance of any account of trust which allows such situations to arise clearly poses major obstacles to the effective confinement (localization) of trust. In this position paper, we argue against accepting the unintensional transitivity of trust. We first distinguish the notion of trust from a number of other (transitive) notions with which it is frequently confused. We then argue that apparent unintensional transitivity of trust is typically an artifact of deploying unpalatable logical assumptions.

2

Some

Things

W'hich

Trust

is N o t

T r u s t is n o t R e l i a n c e . Many statements ostensibly about trust make better sense if "trusts" is replaced by ':relies upon". For example, I may be required to have my software certified by the QA department, which they do by running known ~ests on their hardware. Or I may be required to submit a transaction authorization which has been cryptographically signed by a particular guardian on a smart card. in both cases I rely (or depend) upon the other parties to do what is required of them. I cannot complete my part of the task unless they do theirs, and I cannot exercise any control over what they do (or don't do). But this does not mean that I trust them. I can va.lidate all their actions, by re-running the tests on my own hardware, or by checking the signature, before I commit to my part of the transaction. I must rely upon them, but I need not trust them. T r u s t is n o t T r u s t w o r t h i n e s s . We distinguish statements of the form ';A trusts B" from statements about trustworthiness, such as: A believes. B is trustworthy

173

(ie B is trustworthy as far as A is concerned, about X, under certain circumstances, etc.) The notion of belief used here is a very mild one: "A believes p" does not assert that A actually has a considered opinion on p's truth, merely that A would (be entitled to) accept and act upon p on the basis of her other beliefs, if she did think about it in a suitable monotonic logic with Modus Ponens. The question whether B is trustworthy (relative to a particular security policy) is a question of fact. There is a reality independent of A's belief, which A might be right or wrong about. But the fact that Alice believes Bob to be trustworthy doesn't mean that she actually trusts him (she may have no need to, or may wish to spare his blushes) nor conversely: Alice may trust Bob not because she believes him to be trustworthy but because she has no choice. Trust is an epistemic notion: statements about trust are statements about certain beliefs held by others and their reasons for holding them, not about what would make such beliefs true in the real world. Tl-ust is n o t J u r i s d i c t i o n . Often we unpack A believes.

B has jurisdiction over X

by saying "A regards B as an authority on X, and part of what that means is that A should trust B about X", or If. A believes: B has jurisdiction over X .~. B says X 9 :then. A believes X

But often this hides an ambiguity in the nature of the authority proposed. A might mean that B is an authority in the sense that X is true just because B says it. If my system manager says that my disk quota is 10Mb then my disk quota really is 10Mbl What makes it so is the fact that my system manager utters the statement (via an entry in the configuration file.) This is not why I believe it: I believe that my disk quota is 10Mb because I found out the hard way. I do not trust my system manager at all. Just because he says "your disk quota will be increased to 15Mb tomorrow" this does not make me believe it! However I do trust my friend Bob, whose visceral ability to predict such things is legendary: if Bob says that my quota is about to be increased, I am willing to bet money that it will be. Bob, of course, is (or has) a different kind of authority: his statement is the sufficient reason for my belief, rather than being what makes my belief true. The first kind of jurisdiction does not entail trust, the second kind is not something which can be unilaterally delegated or handed off. Many arguments about trust slip gently from using one kind of authority into the other, without consideration of their different natures. T r u s t is n o t D e l e g a t i o n . Suppose Alice trusts Bob about X (under certain conditions which are currently fulfilled.) Suppose Bob says "I have delegated jurisdiction over X to Carol." This does not imply that Carol accepts the delegated

174

authority. Nor does it imply that either Alice or Bob trusts Carol to use this delegated authority correctly (although they may rely upon her to do so.) Nor does it imply that Alice accepts Carol's jurisdiction over X, unless for example Bob tells Alice that she can trust Carol, and Alice trusts Bob to tell her who to trust, which begs the question. If all operations could be delegated by unilateral decision of the delegator, then many security policies would be easy to break (eg two bank managers holding different coloured keys, delegating to the same secretary.) Trusting B not to delegate inappropriately again begs the question. T r u s t m a y i n v o l v e G e t t i n g Sacked. Another way of unpacking trust is that "A trusts B" means that B has the ability to violate A's security policy, often put loosely by saying that B has the power to get A sacked. However this ability need not be transitive: it may be that B can break A's policy and C can break B's but, because A's policy is weaker (more permissive) than B's in some crucial respect, C cannot break A's policy without B's help.

3

An Anatomy

of Trust

For the sake of further argument, iet's unpack "A trusts B" as: if. A believes. B says X :~hen, A believes X

where we are unpacking belief here in the same way as in the previous sect.ion. We are not particularly advocating this (or any other) specific account of trust, although we do ask you to accept that as far as reasoning about transitivity is concerned, this definition is at least as good as most others. Now assume that A believes: .& trusts B .~. B trusts C

.g. C says X

and try to prove that A believes X

Clearly this requires some further internal structm'e So ~rust. On the same rather arbitrary basis, we may choose to decompose "A trusts B" into the conjunction of "trust in honesty": if. A believes. B says X :then, A believes. B believes X

and "trust in competence": if. A believes. B believes X :then. A believes X

respectively. Now to establish 'CA believes X" it will suffice to establish A believes. B believes X

175

This gap is usually closed by a hypothetical argument in which A reasons along the following lines: If B believed what A believes about what C says (usually expressed by saying "if B were aware of the facts") then B would believe C says

X

hence B would believe X. So A believes that B is entitled to believe X, under circumstances which are in fact the case, therefore by our use of "belief" A believes. B believes X

QED. The fact that this "proof" nowhere uses B's honesty gives the game away: A has no legitimate basis to conclude anything about what B would actually believe that C says. But surely what C says is a matter of fact, not of anybody else's belief? As an example to the contrary, consider a "secure" message delivery system, Ted, currently responsible for delivering a message M to Bob. If Ted finds himself under physical threat (eg power loss) then at least two different security policies are possible, depending upon whether disclosure or non-delivery is considered the greater threat: (1) destroy the message M (2) broadcast the message "Bob: M" Since it may be important to conceal the fact of which policy is in operation, when power is cut, Ted may well broadcast the message "Bob: Aunt Agatha will arrive on the 5:15 from King's Cross." Bob knows that this message really means that Ted has succeeded in destroying all trace of the secret message M. The fact that Alice trusts Bob and knows that Bob trusts Ted is therefore not sufficient reason for Alice to go to the station expecting to meet Aunt Agatha. (Note that Bob has not betrayed Alice's trust, since Bob has not said anything!) When we wrote A believes. C says X

we blurred "C says X to/for A" with "C says X to/for B". What was needed to make the proof work was actually that A believes. B says. C says X to/for B .to/for t

and that A trusts B about. C says X to/for B

4

Conclusion

The ability to localize trust is arguably the most important benefit of public-key cryptography. Performance optimization of distributed systems usually involves

176

the delegation of certain functions to "third-parties" that have their own policy and agenda. In order to allow an adequate analysis of the effect of these optimizations on the trust relationships of the system, it is important to remember that such an exercise consists not in establishing the properties actually possessed by the system, but rather in the analysis of the beliefs held by principals about each other and the basis upon which these beliefs are held. This analysis must consider intensional conditions of the principals (including modalities such as obligation and deceit) and not merely extensional properties of the system and the facts which make them true. Intensional conditions are not referentially transparent. In particular, Alice's analysis of Bob's beliefs must consider situations which Alice believes to be not merely false in actual fact, but impossible per se.

References 1. Burrows, M., Abadi, M., Needham, R.M., 1990, A Logic of Authentication, ACM Transactions on Computer Systems 8(1) 18-36 2. Cheswick, W.R., Bellovin, S.M., 1994, Firewalls and Internet Security: Repelling the Wily Hacker, Addison Wesley, 0-201-63357-4 3. Cresswell, M.d., 1973, Logics and Languages, Methuen, 0-416-76950-0 4. Gallin, D., 1975, Intensional and Higher-Order Modal Logic: with Applications to Montague Semantics, North Holland, 0-7204-0360-X 5. Gong, L., Needham, R., Yahalom, R., 1990, Reasoning about Belief in Cryptographic Protocols, IEEE Computer Society Symposium on Research in Security and Privacy 1990, 234-248

Securing the Residential Asynchronous Transfer Mode Networks Shaw-Cheng Chuang and David Greaves Computer Laboratory, University of Cambridge New Museums Site, Pembroke Street Cambridge CB2 3QG, United Kingdom Email: {Shaw.Chuang, David.Greaves}@cl.cam.ac.uk

A b s t r a c t . In this paper, we consider the security management of a residential ATM network, the ATM Warren. Threats within the ATM Warren are presented and counter-measures to some of these threats are suggested. Security issues in the ATM Warren such as protection domain, naming, firewalling and delegation are also discussed. We also propose user authentication mechanism based on infra-red remote control. FinaJly, we demonstrate an efficient data path protection mechanism that is able to handle dumb ATM end devices.

1

Introduction

Asynchronous Transfer Mode (ARM) networks has been conceived as a universal network supporting different kinds of applications and customer categories. In the recent years, we are beginning to see ATM to be deployed in the LANs and WANs environment. The introduction of ATM into the home environment {s now feasible, with the cost of ATM technology continue falling. The concept of "ATM Warren" enables low cost ATM network to be used as the basis of a residential ATM-based H o m e Area Network (HAN). While the use of ATM technology for home brings to a residential environment the multi-media benefits of ATM and full inter-operability with ATM standards, it also open the home environment to increase security risk. In this paper we present our preliminary work on securing the ATM Warren. We analyse the security risks of the ATM Warren and suggest, possible measures t~o address these security challenges. We begin with a brief introduction to ATM technologies follow by a description of the ATM Warren, We then examine the security threats associate with it. In the ATM Warren, there is a concept of the Warren Controller (WC) which m a y b e the only component in the Warren to possess processing intelligent. The WU plays a key role in the execution of any security policy. The location of the WC with respect to the Warren network boundary can affect the trust model and level of control allow from the Warren user. We examine different placement scenario and their impact on issues such as accounting, auditing, access control and privacy.

178

Within a Warren network, an infra-red remote control unit can be used as the universal control for the Warren devices. Such infra-red remote control unit can also be personalised and used as an authentication and authorisation tool. In this paper, we explore some design options. The Warren enables seamless inter-domain communications with the external ATM network. Security issues such as firewalling and delegation in signalling, data path confidentiality and integrity are discussed. We also consider briefly possible security impacts on naming, addressing and other high level concerns. 2

Introduction

to Asynchronous

Transfer

Mode

Asynchronous Transfer Mode (ATM) has been identified as the transfer mode for implementing the Broadband Integrated Services Digital Network (BISDN), universal network that supports different kinds of applications and customer categories. The reference model for the BISDN protocol stack, as shown in Figure 1, identifies three protocol planes~ the user, control and management planes.

~

- - - - Manag~men~Plane/ / - -

r Plane/

HigherLayer~

HigherLayers

ConlrolPlane Adaptatian Layer

UserPlane Ad~ptationLayers

ATMLayer Phy~icai Layer

/

/ /

/

/"

Fig. 1. BISDN Reference Model

The user plane provides for the transfer of user in%rmation. The control plane is responsible for the call control and connection control functions. The management plane serves two types of functions. First, the layer management functions deals with OAM information flows for each layer and resources and parameters residing in it,s protocol entity, such as meta-signalling. Second, the plane management function coordinates between the management functions of all planes. In ATM, information flow in the user plane is organised into fixed-size blocks called "cells", each consisting of a 5 byte header (the User-Network Interface (UNI) cell header is as shown in Figure 2) and a 48 byte payload information field. Cells are transmitted over a virtual circuit connection (setup using control plane functions), and routing is performed based on the Virtual Circuit Identifier (VCI) contained in the cell header.

179

The network bandwidth is organised into time slots. The fundamental characteristic of ATM is that the cell transmission time is equal to a time slot length, and slots are allocated to a cell in an asynchronous manner based on demand. Due to the demand-based dynamic allocation of bandwidth, ATM can more easily accommodate variable bit rate services. The network bandwidth can also be efficiently utilised through statistical multiplexing of traffic sources.

BIT 7

6

5

4

3

2

1

GFC

VPI VC I

I 21

VPI VCI

VCI [

3 PT

~LP

Octet

4 5

HEC

Fig. 2. BISDN Reference Model

The ATM Adaptation Layer (AAL) provides for the mapping of higher layer Protocol Data Units (PDU) into the information field of cells and the reassembly of these PDUs. The AAL consists of two sub-layers: - Segmentation and Reassembly (SAR): Segmentation at the transmitter side and reassemble at the receiver side - Convergence sub-layer (CS): Service dependent and provide the AAL service at the AAL Service Access Point (SAP). A number of AALs have been defined, such as AAL1, AAL2, AAL3/4 and AAL5. AAL5, designed to reduce processing overhead, has been most widely used. The structure of AAL5 is as shown in Figure 3. In Section 8, we developed a data path protection mechanism that is compatible with this important AAL.

I ]

i

oPesPD p.o

I PAD I

I0 I ILon "IoRc

8bits 8hits 8bits CPCS-PDUtrailer

CPCS-PDU Fig. 3. AAL5 Frame Format

i

180

3

Residential

ATM

and

the

ATM

Warren

Earlier video-on-demand trials may have used ATM in the core of the network, but terminated AAL1 circuit emulation before entry to the home, so that the home is fed with a fairly inflexible structure, such as a single continuous M P E G multiplex transport stream. Most people recognise that there will be multiple devices in the home which require outside service connections and a more generalpurpose network is required. This must support multiple streams to the home, allow communication between devices in the home and be able to support considerable bandwidth out of the home in the future. The ATM Warren is one approach where a low cost ATM network suitable for residential use can be built. The Warren is a subnetwork of ATM network composed of an arbitrary mesh of very simple ATM switches and end stations, as shown in Figure 4.

Blt~:

WARREN

c~ W a r r e n A T M Swlteh

Warren End Station

~ Werren~ !:i i!...........................................................

~,

Standard aTM

Fig. 4. An Example Warren with Superimposed Spanning Tree

The major problem with current ATM protocols is that the switches and

181

end stations are all expected to support vast quantities of signalling and management software, including a base set consisting of Q.2931, SSCOP and SNMP. For a large class of possible ATM devices, the RAM and processor required to implement these protocols is more expensive than the sum of the cost of the actual data handling components, including the AAL and line interface. The approach of the Warren will be to remove all of the software from both switches and end-stations and locate it in one controller computer, where sharing of code space and other resources is possible. The Warren ATM switches and end stations have the characteristic of being low cost and implemented entirely in hardware. The Warren devices are built without unique identification or other non-volatile configuration. They require no microprocessors for signalling and management. The proxy servers, which perform all the control functions, are software entities situated on one or more general-purpose computers connected to the external ATM network outside the Warren. The Warren provides the full set of normal imband ATM semantics as defined in ITU recommendation 1.361. VCCs (virtual circuit connections) originating, terminating, or passing through a Warren behave like any other ATM VCC. Another key aspect of the Warren protocols is that a certain amount of pointto-point ATM communication is possible without any control or management. Point-to-point connection establishment can be achieved simply by plugging a pair of end devices together. This is because a Warren transmitter and receiver expect to use a fixed hard-wired VCI value for each type of stream, whether it be for data or control. For instance, a future ATM video recorder could be directly connected to a future ATM television with a point-to-point Warren link and no software involvement. However, later on, the owner of these consumer durables may wish to expand his home entertainment centre by introducing a low cost ATM switch: for example, to attach an ATM video camera and a second ATM television in a remote room. Using the Warren approach, no modification to the ATM implementation or configuration within these pieces of equipment would be required to do this.

3.1

Warren Extent and Control

The Warren is composed of special switches which implement Warren protocols. A group of interconnected Warren Switches, together with a Warren Controller and the leaf Warren end stations, defines the extent of a Warren. The Warren Control Protocol (WCP) provides both the ATM 'Management' plane function and 'signalling' for dumb devices. Standard ATM devices that happen to be connected to a Warren can use conventional signalling through the network to a signalling agency or proxy provided alongside the Warren. The Warren switches operate as standard ATM cell switches, but have a simple standardised architecture which can easily be monitored and controlled externally using single cell messages which form part of the Warren Control Protocol. Each switch has a designated Up Port which points towards the outside world. The choice of up port for a given switch is not hardwired into the device;

182

rather the Warren executes a distributed topology determination algorithm at power-up time. The switch at the b o t t o m of the Warren (switch A in Figure 3) is special in the sense that its up port is not connected to another Warren switch, but instead to an external controller known as the Warren Controller (WC). The WC m a y actually be situated several hops away over a further mesh of conventional ATM switches (e.g. perhaps in the central office of a town). The point of exit to conventional ATM is termed the Principle Rabbit Hole (PRH). Other conventional ATM networks could conceivably hang off other switch ports of the Warren, to form other Rabbit Holes (RH), but the Warren has exactly one P R H connected to exactly one active WC. At least three types of proxy are needed for operation of the Warren as an ATM network. These are - The Warren Controller (WC) which looks after the switches. Proxies for the Warren end stations. - Proxy signalling agents for each switch, to allow non-Warren ATM devices to be attached to a Warren switch without modification. -

The WC could consist of a Linux PC without screen or keyboard, but likely with P C M C I A slots. Any equivalent multitasking processor with loadable software modules and an ATM interface will serve. The WC serves a number of purposes: - It has complete knowledge of the Warren topology which enables it to set up connections on behalf of Warren end stations. - It maintains a mirror of the contents of the routing table of each Warren switch and full information about VCI and VPI allocation on each link. - It behaves as a gateway between the ATM Warren and other standard ATM networks, such as the Homepoint [5]. This enables interworking between Warren devices and full ATM. - It behaves as a security firewall, protecting Warren devices from external unauthorised access. For each device in the Warren, there is a proxy signalling and control agent which is a software entity running on a computer outside the Warren. This computer could be the same computer as the Warren Cont~vller, but then would typically be a separate software module or process. 1 A device proxy controller m a y m a n a g e only one device, a set of devices, or all devices of a given type in one Warren. Normal ATM devices will have their signalling requirements served through a collection of PVCs to signalling agents running on machines outside the Warren. The signalling agents perform the functions expected inside an intelligent ATM switch and communicate to the Warren Controller in order to actually establish the VCCs set up by such signalling. 1 To simplify the discussion in the following sections, the term WC also includes the functionalities of the proxy computer.

183

The Warren design also allows for the use of more varied physical network topologies. Figure 3 shows examples of both bus and ring structures attached to Warren switches. These represent a valuable economy in the number of switch ports used for a modest increase in complexity of the end stations. 4

Security

4.1

Issues

in the

ATM

Warren

Low cost vs Ease of Use vs Security

While the low cost and "Plug ~ Play" nature of the ATM Warren ease tile introduction of such network into the home, it also poses a challenge to the design of security mechanisms that preserve these properties. Typical implementation of security mechanism involves the use of random number generators and cryptographic devices. Even in cases with no special purpose hardware support, at least a processor is available for cryptographic protocol processing. Warren devices break all these requirements: they are very simple, with no processor and not even unique hardware identifier. The last feature in particular rendering the concept of ATM Warren device authentication meaningless. The other design objective of the ATM Warren is that it must be simple to use and idiot-proof. The handling of security mechanism on the other hand tends to require a good understanding of the basic technology and hands-on configuration effort to suit individual security needs. As we learn from many previous experience of security breaches, human errors were behind many such incidents. Expectation might well be too high to demand people who cannot even programme their VCR to correctly configure the security policy for the ATM Warren. Hence it seems that ATM Warren and security are two conflicting concepts. The secure Warren system design has to strike a fine balance between the three conflicting requirements of cheap, simple and secure. In the following sections, we suggest potential solutions that provide different tradeoffs. As we discussed in Section 3.1, the main complexity in the management and control of the ATM Warren devices has been moved to the WC. For security management in the ATM Warren, we are taking a similar approach and place most security and protection mechanism in the WC. Since the WC deals with all signalling for the Warren devices using the proxy servers, there is still the issue of setting up a secure control channel and this is discussed in Section 5. 4.2

Threats

to the ATM W'arren and Security Requirements

In the ATM Warren, we have envisaged a few interesting threats and security requirements: - Trojan Warren appliance The target user of ATM Warren includes technology and security unaware people. ATM Warren devices or appliances are built to be "Plug ~ Play".

184

Trojan/malicious appliances hardware and the corresponding proxy control software can easily penetrate into such naive environment. The possibility of direct outside-world connectivity of the Warren also enable such Trojan appliances to coordinate attacks with outsiders. Maintenance man Remote diagnosis of faults or initial configuration of new items may be helpfully performed by an expert in a shop or local agency. The delegation of rights of access to these experts and the ability to revoke access, needs to be carefully control. - Electronic cash control With the advent of electronic commerce, we can foresee electronic cash being used to purchase services for use in the ATM Warren environment. One example of such service is the Video-on-Demand service where the on-demandvideo, purchased using electronic cash, will be directed straight to the ATM Warren Television. Therefore, the ATM Warren clearly needs to be capable of dealing with electronic commerce. We need a system which is able to handle electronic cash and produce an audit trail which is admissible in court in the case of dispute. Wire-tapping We do not consider wiretaps within the ATM Warren to be a problem. In multiple occupancy environment, we assume that the adults are civitised. However, as shown in Section 5, there is a potentially weak point in the ATM Warren that allows outsiders to tap into the ATM Warren and gain valuable information about the network configuration and usage. - Unauthorised connection from the outside world There is a need to setup firewall facility to prevent unauthorised external connections. Infra-red through the window Infra-red Warren device, such as a Warren Remote Control, is envisaged to be an important tool in Warren device control for naive user. However, we want to prevent the situation of unauthorised remote control such as infra-red directed through the window from outside the Warren or leakage. - Shared household There is a possibility of Warren usage abuse in a shared household that might consists of minors, tenants and domestic helpers etc, -

-

-

5

Protection

Domain

In a Warren environment, all the Warren devices attached are considered to be within the same

security domain~

under the control of the WC.

Hence

it is

natural to consider the W C as the security boundary. If secure communication to the outside world is desired, security policy must be enforced at (or before) this point.

185

However, one envisaged the situation that the WC might be situated several hops away over a further mesh of conventional ATM switches (e.g. perhaps in the central office of a town). This poses a few possible threats to the Warren network.

-

Compromise of the WC The WC is, by definition, physically outside the Warren environment, therefore lacking the physical security of an enclosed home environment. Furthermore, each WC can potentially control more than one ATM Warren and the Warren service provider might have more than one WC within the same premise. This increase the reward of an illicit control of the WC. Accounting and auditing With the WC physically outside the control of the user, possibly under the administration of a Warren service provider, all accounting and auditing of Warren activities is carried out outside user control. Therefore in case of dispute between the user and the Warren service provider, the users are unable to provide any audit log to support their case. Eavesdrop on the WC to Rabbit Hole path All topology determination traffic flow up from the Rabbit Hole to the the WC. A simple wiretap at the path between the WCto Rabbit Hole can easily yield all information about ATM Warren devices exist within a Rabbit Hole. This "feature" is of great attraction to potential burglar since the information enables precise targeting of ATM Warren-equipped home for maximum loot. Eavesdrop of the Warren control traffic can also be an invasion of Warren user privacy since that traffic represent activities of a private life. Message modification The down-stream control traffic from the WC into the ATM Warren consists of Warren Control Protocol (WCP). Without a secure control channel, any message modification on the WCP can cause the Warren devices to misbehave.

The use of an encryptor over the WC to Rabbit Hole path can provide confidentiality of the up-stream topology determination traffic and integrity protection of the down-stream WCF traffic, as shown in Figure 5. Since the traffic from the rabbit hole to the WC might be switched over a mesh of conventional ATM switches, a conventional line encryptor which cipher the entire cell is not suitable in this situation. The encryptor must only encrypt the payload of a cell. A single key can be used for all control traffic over the path. In Section 8, this encryptor can be extended to carry the function of a key agile cryptographic device for ATM, CryptoNode, which does per-VCC encryption. At the WC end, 1;he encryption/decryption can be done in software. The other approach to completely tackle the above threats is to move the WC within the Warren boundary and place it under the user control, as shown in Figure 6. The user is then held full responsibility for the maintenance of accounting, auditing, access control and privacy. This is however at an increase cost since one WC computer is needed for each Warren.

186

@ 8n~ |

,1 I~Encryptor: CryptoNode

:i.....................:................................~...:.~.S t a n d a r d A T M

Fig. 5. Protecting the W C to Rabbit Hole path

Thus we consider there are two classes of Warrens, based on the physical location of the W C and the domain of responsibilities. In the following discussion, we assume that the I/VC to Rabbit Hole path is confidentiality and integrity protected either through the use of an encryptor or the physical placement of the W C within the Warren.

6

Warren

Controller

The WCcan be considered as the brain or guardian of the ATM Warren. Much of its functionalities, and the security issues involved, cover both the ATM Warren and the associated HAN. In this preliminary report, we will consider the following issues: naming, delegation of control and firewall. 6.1

Naming

One of the main components of the Warren/HAN architecture is the naming architecture. The naming architecture can play a key role in the protection of simple ATM devices such as the ATM Warren devices. The naming and addressing of Warren services within a federated heterogeneous ATM networking environment should allow the separation of signalling entity addressing and the data path addressing of Warren devices. The name of Warren services can be

187

8m.

[ l j E n c r y p t o r : CryptoNode

ii................................................~* ......S t a n d a r d ATM

Fig. 6. Relocating the WC to Within Warren

resolved to obtain the address of the corresponding WC (as the signalling entity). Upon receiving a signalling request, the W C can further resolves the name into the internal Warren addresses. This is very useful especially when the Warren device address are generated dynamically based on the network topology. The Warren devices are protected from external control, since external entities cannot signal directly to it.

6.2

Delegation

This is another HAN function, handled by the WC, whose design is closely related to the ATM Warren design. The placement of the W C outside the Warren is not only as a cost saving measure by sharing a WC among a few ATM Warrens, but also allows the operation of the WC to be under profession care. There is clear advantage to have profession management of the WC since such management task might be one of the only non-trivial aspect of the ATM Warren. The user might not be interested or technically capable of handling the day-to-to running of the WC. A non-user operated WU involves the transfer of authority from the user to the hands of the W C administrator. This internal form of delegation can take two forms, each with a different trust model: The Warren user share all cryptographic secrets with the WC. - The Warren user delegate the right to manage his Warren in the form of a delegation certificate. -

t88

The difference is significant if the same set of cryptographic secret is used not only for the ATM Warren but for other applications such as mobile GSM phone. This sharing of credential between applications is made possible with the use of infra-red remote control for authentication as described in Section 7. Further delegation takes place when the WC, run by the user or a Warren service provider, needs to dynamically delegate some Warren management rights to some third parties. This situation might happen when the user has gone on holiday and therefore requires restricted remote management of the ATM Warren. In the case of a Warren service provider, further delegation can be part of a business plan of "subcontracting" third parties for some of the management functions. In this case, the Warren service provider might like to maintain the confidentiality of the delegation so that subcontracting information can be concealed from the user. With further delegations, a delegation chain can be formed. The full design of a delegation authority in such a network enviromnent is outside the scope of this paper.

6.3

Firewalling

Private ATM Warrens are considered to be locally secure but traffic across the interconnected ATM WANs is considered vulnerable and requires protection. Therefore the WC serving as a gateway between the ATM LAN and the ATM WAN can be treated as a security firewall. The granularity of protection at the firewall will normally fall into the categories of application layer firewall or network layer firewall [1]. Tennenhouse [8] has described the principle of avoiding unnecessary multiplexing in the ATM environment that we are considering. Much benefit in terms of jitter and Quality of.Service (QoS) cross-talk can be gained from minimum multiplexing. Therefore we are advocating that if an application does not multiplex over the same VCC, then there is literally no difference between an application layer firewall and network firewall. This view of providing firewalling reduces our problem to the case of providing a general solution for a per-VCC protection. The functions of the ATM firewall includes both call control filtering and data filtering. -

-

Call control filtering This is a HAN design issue. The WC serves not only as the proxy signalling entity for the Warren but also as the guard for access control. Incoming and outgoing calls are either authorised or rejected using the calling/called identifier and higher level policy terms associated with the Warren. Authenticated ATM signalling is a pre-requisite. Data filtering Traffic within the boundary of the Warren needs no security protection since the Warren is considered to be one secure domain. For an ATM connection that spans from the Warren domain to external ATM domains, the ATM data path would need confidentiality and integrity protection, on a per-VCC basis, as it traverses the insecure external ATM domains. However, we have

189

already stated that the Warren devices are unlikely to have cryptographic ability due to the cost and ease of use constraint. Therefore it is logical that the WC, as the interface between the Warren and the outside ATM world, should act as a data filter which transforms the unprotected internal Warren VCC to a cryptographically protected external VCC. There are two problems associated with using the WC as the data security filter. Firstly, as we discussed in Section 5, the WCto Rabbit Hole path is not protected. Secondly, previous experiments on cryptographically protected VCC [4] indicates that this filtering process is very CPU intensive. The WC, in the form of a processor card running Linux, is unlikely to have satisfactory performance to handle such filtering task, without degrading other WC functions. To handle data filtering with satisfactory performance, we propose to offload the cryptographic filtering of data path to a key agile cryptographic device for ATM, CryptoNode, with function as described in [4]. The placement of the CryptoNode is as shown in Figure 5. Thus we eliminate the requirement to move the WC within the Warren. The WC can remain something equivalent to a PC but still needs to performs encryption/decryption in software only on the Warren Control Protocol traffic. The CryptoNode has an ID and need to share initial secret with the WC so that initial secure control channel can be setup between them. This is a slight deviation from the philosophy of Warren devices contain no ID and initial state. The configuration depict in Figure 6 can however remove the need for ID and initial secret on the CryptoNode by means of physically secure direct control from the WC to the CryptoNode. In this case, the WC communicate with the CryptoNode securely over a secure channel such as a PVC, serial or parallel interface etc.

7

Infra-red

Wand

One of the main user control tool for the Warren is expected to be an Infra-red (IR) remote control - the Warren ]R Wand. Both the IR through the window threat and shared household threat indicated in Section 4.2 require user authentication in the Warren. We propose that the Warren IR Wand be enhanced to provide authentication of users. There are a few advantages in taking this approach:

-

- Cost sharing Security mechanism tends to be expensive to be implemented correctly. By concentrating the implementation of the authentication function in a single control device, we in effect reduce the overall cost of the ATM Warren. Implementation error can also be avoided. Keep devices simple The Warren device interface can be kept simple. This will speed up the development and introduction of Warren devices. ATM appliance designer

190

-

can continue doing what they do best without the need to be re-trained on security implementation techniques. Ease of use The I R Wand will reassemble the remote control that most peopte are accustomed to. We believe authentication with a personalised I R Wand is much user-friendly than other computer-based authentication concepts such as login. The concept of login to your ATM Warren speaker can be difficult to promote to consumer product customers.

IR signMs from the I R Wand are translated at the IR based station into the the Warren Infra-red Protocol (W-IRP). The I/V-IRP uses single cell messages to carry a compressed form of the sequence of 'needle' pulses used by I R systems and is therefore adaptable to a variety of consumer IR formats. We treat the W - I R P in a asymmetric manner. We aim to authentic the upstream I R commands by binding the commands to user ID. The downstream W - I t t P needs no authentication information since it can only originated from the WC. This mechanism relies on the integrity of the upstream and downstream path, which is setup by the WC. The design of authentication of the IR commands needs to work within a few constraints: - The IR c o m m a n d and all the authentication information need to be carried within a single cell payload. The authentication overhead should be m i n i m u m to maximise IR-comrnand payload size. - The authentication mechanism needs to be relatively high performance, at least to keep up with normal button pressing speed. - We need message freshness without the use of a synehronised real time clock on the I R Wand since it is well known that synchronising a real time clock is not a trivial task. A challenge/response protocol involves at least a roundtrip communication delay. Hence we want to avoid the need to incorporate challenge/response protocol for performance reason and also for simplicity of implementation. - The authentication protocol must tolerate the slow speed and high error rate over the IR link. We want the authentication mechanism to be usable with Wand hardware of different, processing capability. -

The IR Wand can take one of the two forms: 1. Public Wand: This correspond to a Wand that provides no authentication information, thus serving as a anonymous community Wand like today's remote control unit. 2. Personal Wand: A personal Wand takes on the identity of the owner of the identity module (similar to a SIM card for the GSM system) 2 insert to the Wand. Different SIMs can identify either different users or different roles of the same person. 2 We will use the term SIM to denote this identity module in the rest of this document

t91

A Warren IR Wand logically consists of two parts: the basic IR remote control unit and the authentication engine. The authentication engine is made up of at least a processor part and cryptographic secret part. For the personal Wand, there are a few design options: - Processor-based Smartcard This is designed with a IR Wand base unit that performs almost identically to a normal IR remote control, except with a smartcard interface incorporated. The smartcard is acting as a secure co-processor in which a normal IR message can be wrapped within an authenticated envelop. The main advantage of this approach being the ability to build very cheap IR Wand base unit and yet maintain re-usability of the SIM modules across different applications such as an electronic wallet. - Memory-based Smartcard In this case, a processor is built into the base IR Wand. Since a memorybased smartcard is currently cheaper than a processor-based smartcard, this suits the situation where a large number of users, each with a good chance of losing their SIM card, sharing a small number of IR Wands. 7.1

Authentication

Protocol

We propose the use of keyed hash function for authentication. A hash function based system has the advantage of high performance and not under export control. We define the format of IR message over the IR link to be as shown in Figure 7. The fields size has been minimised to reduce overhead.

8 bits

24 bits

16 bits

Fig. 7. Warren Infra-red Protocol Message Format: Message part

- User ID (8 bits) This user identifier onty has local significance. The W C can perform the mapping of this ID to the real ID. We consider 256 user (8 bits) to be sufficiently large for a single Warren. Sequence number (24 bits) This can either be the sequence number of a one-time password or a m o n o tonically increasing number (see later for a discussion of the usage). Authentica.tion token (16 bits) This is the message authentication code (MAC) for the IR command, created -

-

as:

192

Auth Token = keyed hash(user id, sequence number, I R command) This can be a truncated hash value, to fit in a 16 bit field, for trade-off between security and size. The truncation of the output of a collision-free hash function in effect converts it into a collision-ful hash function. As suggest in [7], this might actually improve the security of the system. Each IR c o m m a n d is authenticated with a key. This can either be a long-term secret key or a one-time password: - Long-term secret key The sequence number is monotonically increased for each I R - c o m m a n d . The IR Wand however needs to obtain a new secret from the WC before the sequence number is wrapped-round. Since the key is long term, a processorbased smartcard should be used to prevent the secret being leaked. - One-time password One-time password, similar to that suggested in the S / K E Y system [6] can be used. The one-time password are created as a chain of hash values. One of these one-time passwords is used with each I R c o m m a n d transmission from the Wand. This approach is optimised for sequences of I R commands. The Wand is charged up with a series of one-time passwords with the WC, The number of one-time password being charged effectively set a quota on the amount of Wand usage. The charging up process can be carried out in one of the following ways: * If the WC is located within the Warren, the one-time password can be charged from the WC. * If the WC is located outside the Warren, the one-time passwords are downloaded from the WC to the CryptoNode (Section 5) using the secure control channel. Residential user can then charge up from the CryptoN-

ode. | Other out-of-band mechanisms Since the IR-link is lossy, it is important to use the sequence number field to indicated the position of the one-time password in the chain.

8

D a t a Path Security

In the previous section, we address the problem of limiting network access with the WC and use of a CWptoNode for security data filtering. In this section, we deal with the design of d a t a path mechanism that guard against the threats of: Masquerading - Eavesdropping Message modification -

-

193

The countermeasures to these threats are to provide message confidentiality (for preventing eavesdrop) and integrity (for preventing masquerading and message modification). In this paper, we use the term integrity and data origin authentication interchangeably. The protection mechanism for ATM data path confidentiality and integrity need to be efficient and flexible to support different ATM operating environments, such as ATM LAN, ATM WAN, ATM Desk Area Network [2] and of course ATM Warren/HAN. The overhead introduces by such protection mechanism must be minimum and continue to support the ATM fine grain multiplexing requirement. For the ATM Warren/HAN, we propose the use of the CryptoTag mechanism, first described in [3, 4], to support data path protection. The CryptoTag mechanism is designed specifically for ATM data path internetworking with a Warren-like environment where ATM devices can be very dmnb. Cells loss in the ATM network causes loss of synchronisation and results in the incorrect processing of subsequent data, i.e. the error propagates/extends. The CryptoTag is a synchronisation token that must be inserted in-band into the ATM data path as shown in Figure 8. The in-band insertion of the CryptoTag takes advantage of the ATM no cell re-ordering property and is used to indicate the logical boundary of a cryptographic unit.

I I II 2 I ~ ~ 1 Data cell Stl~aln

CryptoTag

4 II 5 ir--T--ir"v-71~I~ Data cell stigma

CryptoTag

Fig. 8. Cell stream tagging with CryptoTag

As a result of engineering tradeoff, the CryptoTag is a single cell AAL5 frame with the Common Part Indicator (CPI) field set to a special reserved value. Different CPI values can be used to distinguish different CryptoTags that serve different security functions. Since AAL5 is one of the most widely used AAL, this approach provides compatibility with many of the current ATM hardware platforms. The detection and processing of the CryptoTag make use of existing efficient AAL5-able hardware. Since the AAL5 trailer is 8 bytes long (see Figure 3 for AAL5 format), we have the remaining 40 bytes in the CryptoTag for carrying cryptographic information. The 40 bytes information content is structured as shown in Figure 9. Key Hint The potential high speed service of ATM networks creates a problem for security management. Due to the high data volume, session key lifetime becomes very short in terms of time duration. Key hint is designed to assist the process of changing a session key very rapidly during the lifetime of a call. This field indicates that there is a key change event and is interpreted

194

64 bits 64 bits 64 bits 128bits I KeyHint IC~ ImegritylVI MAC I C13~pt~ yy, "................................................................................. I Confidenliulity [ Confidentiali,y I ,nlegri,y [ Integri,y I Mas~erKey $es~ilmKey MasterKey Sessi~t~Key Key Hint

Fig. 9. Structure of CrgptoTag

by the higher level software. This permits a lot of flexibility on how the field should be interpreted. Indeed, the exact interpretation can be determined at call setup time as part of the negotiated security profile. One naive way to use the key hint field is to put an encrypted key in the field. Another possible way in which the key hint field can be structured is as shown in Figure 9. As we can see, there are Master Key and Session Keg fields for both confidentiality and integrity. In this case, we are assuming that there is a longer-term Master Keg and a shorter-term working Session Key for ciphering of data.. Each of these fields can be used as an index into a table of keys. Alternatively the real Master Keg can use the Session Key field to generate the real Session Key, e.g. by encrypting (KM, K) where KM is the master key. The Master Key is changed on a much longer time scale, e.g. daily or when membership changes Therefore we can employ the normal full key exchange procedure or group key distribution scheme. The Master Keg field change is then used as a trigger for the new Master Key to be registered. The change in Key Hint field can be easily implemented in the hardware by a simple comparison of the current Key Hint with the previous Key Hint. If a change is detected, an interrupt to the processor is generated. The cell level processing by the tow-level hardware is halted and control of processing is passed to the higher level software. When the processor has finished with the interpretation of the Key Hint field, the virtual circuit is scheduled to be restarted. Thus we require per-VCC queueing of the cell streams. In the case of multicast traffic, the provision of message confidentiality and integrity protection for multieast group typically relies on some secret key(s) being share among the group members. This secret(s) are changed, using control plane function, when group membership changes. The key hint is used to trigger this group key change. Confidentiality IV and Integrity IV The Confidentiality IV field is the Initialisation Vector (IV) used for the encryption of the cell payloads. Notice that this field is only 64 bits. It might seems that we are limiting ourselves to the case of 64 bits IV block size. However, we should also observe that no IV is required in the calculation of many MACs. Consequently it is possible to reuse the Integrity IV field to extend the Confidentiality IV field to 128 bits. - MAC -

195

This is the MAC to provide tile data origin authentication. One possible coverage of the MAC is as shown in Figure 10:

I,, .......

DZ~ Vr~.m.e ............

J

C.~.p,_oT.~. l

Fig. 10. MAC Coverage

The MAC coverage has been carefully arranged to end on an 8 bytes boundary to allow an efficient pipelined validation of the MAC. There is no dependency between the confidentiality and integrity function. The selection of which function is to be used for a particular VCC is determined at call setup time by specifying the required security profile.

8.1

Fine Grain Integrity

For AALs such as AAL1 and some other Warren specific AALs which deal with small CS-PDU, the CryptoTag integrity checking might either be too expensive or introduce too much delay. Delay occurs since the cells within each cryptographic integrity checking boundary needs to be buffered before the outcome of the integrity check is known. The delay can be reduced by increasing the frequency of the CryptoTag but this is at an increased communication overhead. We propose the introduction of a small MAC, e.g. 8-bit, field in the payload of each cell for per-cell integrity check. The CryptoTag mechanism is still necessary for the loading of cryptographic context and longer term integrity check. We want the MAC field to be small to reduce overhead and the MAC could be the truncated output of a keyed hash function. This proposal however implies the definition of new secure AALs. The ATM Warren project is in the process of defining different AALs. The detailed structure of such secure AALs for the ATM Warren will be reported in the future. 9

Summary

Residential ATM networks, such as the ATM Warren, enable a low cost multimedia network infrastructure to be built in a home environment. In this paper, we presented the security threats associated with the Warren. We show the various tradeoff, between cost, ease of use and security, in integrating some security measures into the ATM Warren. The placement of the Warren Controller (WC) outside the Warren creates the Warren content leak problem. With further consideration on data filtering,

196

we propose the use of a key agile cryptographic device for ATM, CryptoNode, at the Warren exit switch port. With the WC located within the Warren, the CryptoNode can be designed as a conventional Wa.rren device. It also allows greater user control but increase the Warren cost alid tolerate user security mism a n a g e m e n t . If the WC is outside the Warren, then we needs to deal with a "state-ful" Warren CryptoNode and less user control on Warren. The WC serves as the security policy enforcer of the Warren. It manages the Warren name space, acts as a firewall by doing call filtering and enforces the delegation of rights to third party. The Infra-red Warren Wand allows user authentication within the Warren and therefore facilitates accountability of usage. We allow the Wa.rren to remain low cost by concentrating more costly authentication functions into a smartcardbased infra-red Warren Wand. Authentication mechanism which work with the Warren constraints have also been examined. The confidentiality and integrity protection of the d a t a p a t h makes use of the CryptoTag: single-cell synchronisation mechanism which is lightweight and AAL5 compatible. One of the key strengths of the mechanism is the ability for simple devices to generate traffic without security concerns but allows on-the-fly d a t a filtering as soon as traffic crosses the Warren security boundary. We also propose the design of secure AALs that allow fine grain per-cell integrity check. This is accomplished with a small MAC field in each cell payload.

References 1. Cheswick W. and Bellovin S.: Firewall and Internet Security: Repelling the Wily Hacker. Addison-Wesley, Reading, Mass. 1994 2. Hayter M. D. and McAuley D. R.: The Desk Area Network. ACM Operating Systems Review, v.25, n.4, pp.14-2t, October 1991 3. Chuang S. C.: Securing ATM Networks. University of Cambridge Computer Laboratory, Technical Report 384. July 1995 4. Chuang S, C.: Securing ATM Networks. Proceedings of the 3nd ACM Conference on Computer and Communications Security. March 1996. 19-30 5. Greaves D. J.: Residential ATM Common Aspects. ATM Forum Contribution 950214, HREF='http://www.cl.cam.ac.uk/users/djg/residential-baseline.txt. 1995 6. Hailer N.: The S/KEY One-Time Password System. RFC1760. February 1995 7. Lomas T.M.A.: Collision-Freedom, Considered Harmful, or How to Boot a Computer. Proceeding 1995 Japan-Korea Joint Workshop on Information Security and Cryptology. January 1995 8. Tennenhouse D.: Layered Multiplexing Considered Harmful. IFIP WG6.1/6.4 Workshop: Protocols for High Speed Networks, IBM Zurich Research Lab. Ed. Harry Rubin and Robin Williamson. May 1989

Visual Cryptography II" Improving the Contrast Via the Cover Base* Moni Naor** and Adi Shamir Department of Applied Math and Computer Science, Weizmann Institute, Rehovot 76100, Israel. e-mall: {naor,shamir}@wisdom.weizmann.ac.il

A b s t r a c t . In Eurocrypt 1994 we proposed a a new type of cryptographic scheme, which can decode concealed images without any cryptographic computations, by placing two transparencies on top of each other and using the decoder's (human) visual systems. One of the drawback of that proposal was a toss in contrast: a black pixel is translated in the reconstruction into a black region, but a white pixel is translated into a grey region (half black and half white). In this paper we propose am alternative model for reconstruction with a different set of operation (which we call the "Cover" semi-group) is proposed. In this model we are able to obtain a better contrast than is possible in the previous one.

1

Introduction

In Eurocrypt 1994 [2] we considered the problem of encrypting images (printed text, handwritten notes, pictures, etc.) in a perfectly secure way which can be decoded directly by the h m n a n visual system. The basic model consists of "splitting" the image into two transparencies I and I I (one can be considered as the ciphertext (which can be sent by mail or faxed) and the other one as the secret key). The original cleartext is revealed by placing the transparency with the key over the one with the ciphertext, even though each one of them is indistinguishable from r a n d o m noise. The system is similar to a one time pad in the sense that each page of ciphertext is decrypted with a different transparency. Due to its simplicity, the system can be used by anyone without any knowledge of c r y p t o g r a p h y and without performing any cryptographic computations. The m a i n drawback of the above scheme is that there is loss in contrast and resolution: each pixel in the original image is m a p p e d into several subpixels in b o t h transparency I and II. The distribution in each transparency of the color of these subpixels is independent of the color of the original pixel. In case the original pixel is black, then the combination of the subpixels of the two transparencies yields a completely black region. However, in case the original * Part of this work was done while the authors where visiting the Newton Institute, Cambridge. ** Research supported by a grant from the Israel Science Foundation administered by the Israeli Academy of Sciences.

198

pixel is white, then the combination of the two *ransparencies yields a region where half the pixels are white and half are black. The difference between the grey level of a black pixel and white pixels is called the contrast. Note the distinction of this model from the usual one-time-pad: the underlying algebraic structure is the "Or" semi-group rather than a group (commonly known as the Xor group). In particular, the visual effect of a black subpixel in one of the transparencies cannot be undone by the colour of that subpixel in other transparencies which are laid over it. This monotonicity rules out c o m m o n encryption techniques which add random noise to the cleartext during the encryption process, and subtracts the same noise from the ciphertext during the decryption process. It is not hard to show that in the above model and in case the encoding is done pixet by pixel then the best possible contrast we can obtain is 1/2 3 The goal of this paper is to suggest a different model allowing us to do Visual Cryptography with a much better contrast. The new model contains several important changes from the previous one: in the new model there will be two "opaque" colours and a completely transparent one (which can even be implemented as a hole, or cutout). Suppose that the original image consists of two colours, say red and yellow 4. We use the "Cover" semi-group on {Red, Yellow, Transparent} where the top opaque color wins:

top tRIYITII 1b o t t o m

R Y T

RYR: RYY RYT

Unlike the "Or" semi-group, the "Cover" semi-group is non-commutative and hence the order on which the transparencies are stacked is significant. The second change is that instead of [ and [I being a single transparency each, they are now e sheets marked 1 , . . . c. Each sheet contains red, yellow and transparent pixels. The reconstruction is done by merging the sheets of I and II, i.e. for 1 < i < c put the ith sheet of f I on top of the ith sheet of I and the (i + t ) t h sheet of I on top of t h e / t h sheet of I[. We assume that the sheets align perfectly, i.e. we can label all the pixels in the sheets in the range 1 . . . L and when the sheets are placed on top of each other all the j t h pixels in atl the sheets are in the same position. Figure 1 demonstrates the merging with c = 4. In this model we are able to obtain a much better contrast, roughly 1 - 1/c where c is both the number of sheets and the number of subpixels each pixel 3 In the Enrocrypt paper we showed that the contrast can be at most 1/2 k in case we are doing k-out-of-k secret sharing. 4 Any two colours will do of course. We choose red and yellow so as do avoid confusion with the black and white colours of [2].

199

4 4 3 3 2 2

I

II Fig. 1. Merging with c = 4

in the original image is m a p p e d to. We present two constructions: the first one (Section 2) requires both I and I[ to have c sheets each and obtains a contrast of 1-1/c. The sheets I and [[ get can be monochromatic, i.e. I gets red/transparent sheets and [[ gets yellow/transparent sheets. The second construction (section 3) requires the two users to get e sheets between them while achieving a 1 - 1/c contrast. However, each user's sheets must contain red, yellow and transparent pixels. Note that in the Eurocrypt 1994 paper (as well as in [1]) this basic model was extended into a visual variant of the k out of n secret sharing problem: given a written message, we would like to generate n transparencies so that the original message is visible if any k (or more) of them are stacked together, but totally invisible if fewer than k transparencies are stacked together (or analyzed by any other method). The original encryption problem can be considered as a 2 out of 2 secret sharing problem. We do not know how to extend our encryption scheme to the k-out-of-k secret sharing problem.

2

The Monochromatic Construction

We describe our scheme as a 2-out-of-2 perfectly secure secret sharing scheme which is equivalent to a perfectly secure encryption method where one party m a y be the one-time-pad and the other the ciphertext. As in the Eurocrypt paper, we m a p each pixel separately. Each pixel in the original image is m a p p e d into c subpixels (it is best when the e subpixels can be arranged in a square, but it is not necessary; any other method of tiling is acceptable). User I gets c sheets indexed 1 .through c. In each of those sheets, one of the subpixels is red and the

200

other c - 1 subpixels are transparent. Similarly for [I, in each sheet one subpixel is yellow and the other c - 1 subpixels are transparent. The way the sheets of [ and I[ are merged is by starting from sheet number 1 of [ and putting sheet number 1 of II on top of it, then sheet number 2 of I and so on. The order in which the subpixels of I are coloured red constitutes a permutation 7c on { 1 , . . . e } (i.e. on the ith sheet pixel ~r(i) is red) and the order in which the the subpixels of I I are eoloured yellow constitutes a p e r m u t a t i o n c~. The permutations 7r and ~r are chosen according to the following method: 7c is chosen uniformly at random from the set of all permutations on e elements a. If the original pixet is yellow let ~ = ~r and if the original pixel is red let ~r(i) = ~r(i + 1) for 1 < i < c - 1 and or(c) = re(l), i.e. cr is a shift of 7r. C l a i m 2.1 If ~r = cr then all the red subpixels are covered by yellow subpixels. C l a i m 2.2 If or(i) = rr(i + 1) for 1 < i < c -

i and ~(c) = 7c(1) then all the yellow pixels, except c~(c) are covered by red ones. Finally, in order to make sure that no partial information is leaked we have

C l a i m 2.3 Both ~r and c~ are distributed uniformly at random over the set of permutation on { 1 , . . . c } regardless of the colour of the original pixel.

Pro@ As constructed ~r is a random permutation and hence is independent of the colour of the pixel. ~ is either equal to 7r or is a cyclic shift of it. In both cases its distribution is uniform over the set of permutation on { 1 . . . c } . Since the information I and I f each gets is a collection of r a n d o m permutations corresponding to each of the pixels of the original image, this is a perfectly secure 2-out-of-2 secret sharing scheme. Note that sheet 1 of I is useless, i.e. the pixel 7r(1) will always be covered by either the one in c,(1) (in case the original pixel is yellow) or by ~r(e) (in case the original subpixel is red). Therefore we really have 2c - 1 sheets altogether. Note also that there is no need to choose ~r from the set of all permutations on c elements. It suffices to choose it from the set of all cyclic shifts on c elements, since (r would be then also distributed uniformly over the cyclic shifts.

3

The

Bi-chromatic

Construction

We now describe an improved scheme that requires roughly half the total number of sheets in order to get the same contrast. Let c be an even number. As above, each pixel in the original image is m a p p e d into e pixels. The two parties share between t h e m c sheets altogether labeled 1 through e where party I gets all the odd numbered sheets and I I gets all the even ones. The reconstruction is as before, by merging the sheets of I and II. 5 As we shall see, rr can be chosen from a smaller set, that of cyclic permutations.

201

The scheme for splitting one pixel is as follows: let C E {R, Y} be the color of the pixel shared and C the other color. Choose a permutation rr on { 1 . . . e} uniformly at random. On the ith sheet let pixel r:(i) be coloured C and pixel rr(i + 1) be coloured C' and all the rest of the pixels are transparent. To complete the description, at sheet c, make the pixel coloured R transparent as well (this pixel is either rr(c) or rr(1)). C l a i m 3.1 I F C = Y then in the reconstructed region only pixels coloured Y are visible and if C = R the c -

1 pixels are Ft and one is Y .

P r o @ First note that each position 1 < j < c is transparent in all but at most two sheets. If C = Y, then for sheet 1 < i < c - 1 the pixel coloured R (which is 7r(i + 1)) is covered by the pixel coloured Y in sheet i + 1 (which has ~r(i + 1) coloured Y). The top sheet has only a Y pixel so n o / ~ pixel is left uncovered. Finally note that position j is coloured Y in sheet 7r-x(j), so all the visible pixels are Y. If C = R, then for sheet 1 _< i < c - 1 the pixel coloured Y (which is ~r(i + 1)) is covered by the pixel coloured R in sheet i + 1 (which has 7r(i + 1) coloured R). As for the top sheet, it has pixel 7r(1) coloured Y and this will remain Y since it is left uncovered. Note that no pixel is transparent, since position j is coloured R in sheet 7r-l(j), so no visible pixel is transparent, one isY andc-1 areR.

C l a i m 3.2 The bi-chromatic scheme is perfectly secure. Proof. Given the odd sheets (those f receives) there are two candidates for 7r: one

assuming the shared pixel is Y, denoted try, and one assuming it is R, denoted 7rR. If the the j t h pixel of sheet i is Y then Try(i) = j and if the kth pixel is R then 7ry(i + 1) = k. Note that this completely specifies roy and there are no contradiction since all odd sheets have a pixel coloured Y and one coloured /~ and since I gets only the odd sheets each 7r(i) is defined once. Similarly for odd 1 < i < c - 1 we have that 7:R(i) = j if the j t h pixel at sheet i is R and 7rR(i + 1) = k if the k pixel at sheet i is Y. We claim that no matter how the original pixel is coloured, the distributions of 7:R and 7rv are uniform over the permutations of { 1 ... c}: If the original pixel is coloured C E {R, Y}, then 7cc = 7r, which is distributed uniformly, and ~rc is a shift by one position of 7r, which is also distributed uniformly. Therefore the distribution of the sheets I receives is independent of C. As for the sheets H receives, suppose that in the generations we hadn't erased the pixel coloured R on sheet e. Now the information I I receives is similar to the information I gets, which we have just argued. But since we have only erased (fixed) information, [ I cannot gain anything from it, so the distribution of the sheets I I receives is independent of C. 4

Open

Problems

As mentioned in the Introduction, we do not know a method for obtaining a k-out-of-n secret sharing in the model proposed here (for k, n >_ 3). Another

202

problem is whether we can encrypt images composed out of more than two colours while preserving the colors more or less intact 6. Another problem is that of visual authentication: can one party be convinced that the message received was indeed sent by someone who knows a common key. The test should be visual (and simple to verify by a human!). As for improving the solutions proposed, the most important factor seems to be the total number of transparencies used, since it implies technical problems of alignment and fading of the lower colors. We conjecture however that in order get a contrast of 1 - c~ one needs 1,/a transparencies (between I and I[) which is what our second construction achieves.

References 1. Giuseppe Ateniese, Carlo Blundo, Alfredo De Santis, Douglas R. Stinson, Visual Cryptography for General Access Structures, ECCC Report TR96-012, accepted on Feb 12, 1996 (to appear, ICALP 96). 2. M. Naor and A. Shamir, Visual Cryptography, Advances in Cryptology - Eurocrypt 94 Proceeding, LNCS vol. 950, Springer-Verlag, 1995, pp. 1-12.

6 Using the methods of this paper we can get a contrast of almost l / k for k colors.

Index

Ross Anderson ........................................................... Mike Burmester ......................................................... Liqun Chen ............................................................. Bruce Christianson ...................................................... Bruno Crispo ............................................................. Shaw-Cheng Chuang .................................................... Ronald Cramer .......................................................... Thomas W. Cusick ......................................................

49 119 139 171 19 177 101 111

Ivan Damgs ........................................................... Yvo G. Desmedt ........................................................ Eiichiro Fujisaki ..........................................................

101 119 33

Dieter Gollmann ........................................................ David Greaves .......................................................... W i l l i a m S. H a r b i s o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B u r t o n S. K a l i s k i J r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . John Kelsey ............................................................. Marc Joye ................................................................ P i l J o o n g Lee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chae Hoon Lim ......................................................... Mark Lomas ............................................................. Charalampos Manifaws .................................................. Wenbo Mao ............................................................... Chris J. Mitchell ........................................................ Moni Naor .............................................................. Tatsuaki Okamoto ........................................................ T o r b e n P. P e d e r s e n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jean-Jacques Quisquater ................................................. l Z o n M d L. R i v e s t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bruce Schneier ..........................................................

139 179 171 117 155 93 131 131 19 49 1 139 197 33 59, 101 93 69 155

Adi Shamir .......................................................... Chris Sutherland ......................................................... David Wheeler ...........................................................

69, 197 49 89

Lecture Notes in Computer Science For information about Vols. 1-1113 please contact your bookseller or Springer-Verlag

Vol. 1114: N. Foo, R. Goebel (Eds.), PRICAI'96: Topics in Artificial Intelligence. Proceedings, 1996. XXI, 658 pages. 1996. (Subseries LNAI).

Vol. 1131: K.H. H6hne, R. Kikinis (Eds.), Visualization in Biomedical Computing. Proceedings, 1996. XII, 610 pages. 1996.

Vol. 1115: P.W. Eklund, G. Ellis, G. Mann (Eds.), Conceptual Structures: Knowledge Representation as Interlingua. Proceedings, 1996. XIII, 321 pages. 1996. (Subseries LNAI).

Vo!. 1132: G.-R. Perrin, A. Darte (Eds.), The Data Parallel Programming Model. XV, 284 pages. 1996.

Vol. 1116: J. Hall (Ed.), Management of Telecommunication Systems and Services. XXI, 229 pages. 1996. Vol. 1117: A. Ferreira, J. Rolim, Y. Saad, T. Yang (Eds.), Parallel Algorithms for Irregularly Structured Problems. Proceedings, 1996. IX, 358 pages. 1996. Vol. 1118: E.C. Freuder (Ed.), Principles and Practice of Constraint Programming - - CP 96. Proceedings, 1996. XIX, 574 pages. 1996.

Vol. 1133: J.-Y. Chouinard, P. Fortier, T.A. Gulliver (Eds.), Information Theory and Applications II. Proceedings, 1995. XII, 309 pages. 1996. Vol. 1134: R. Wagner, H. Thoma (Eds.), Database and Expert Systems Applications. Proceedings, 1996. XV, 921 pages. 1996. Vol. 1135: B. Jonsson, J. Parrow (Eds.), Formal Techniques in Real-Time and Fault-Tolerant Systems. Proceedings, 1996. X, 479 pages. 1996. Vol. 1136: J. Diaz, M. Serna (Eds.), Algorithms - ESA '96. Proceedings, 1996. XII, 566 pages. 1996.

Vol. 1119: U. Montanari, V. Sassone (Eds.), CONCUR '96: Concurrency Theory. Proceedings, 1996. XII, 751 pages. 1996.

Vol. 1137: G. G6rz, S. H611dobler (Eds.), KI-96: Advances in Artificial Intelligence. Proceedings, 1996. XI, 387 pages. 1996. (Subseries LNAI).

Vol. 1120: M. Deza. R. Euler, I. Manoussakis (Eds.), Combinatorics and Computer Science. Proceedings, 1995. IX, 415 pages. 1996.

Vol. 1 I38: J. Calmet, J.A. Campbell, J. Pfalzgraf (Eds.), Artificial Intelligence and Symbolic Mathematical Computation. Proceedings, 1996. VIII, 381 pages. 1996.

Vol. 1121: P. Perner, P. Wang, A. Rosenfeld (Eds.), Advances in Structural and Syntactical Pattern Recognition. Proceedings, 1996. X, 393 pages. 1996.

Vol. 1139: M. Hanus, M. Rogriguez-Artalejo (Eds.), Algebraic and Logic Programming. Proceedings, 1996. VIII, 345 pages. 1996.

Vol. 1122: H. Cohen (Ed.), Algorithmic Number Theory. Proceedings, 1996. IX, 405 pages. 1996.

Vol. 1140: H. Kuchen, S. Doaitse Swierstra (Eds.), Programming Languages: Implementations, Logics, and Programs. Proceedings, 1996. XI, 479 pages. 1996.

Vol. t123: L. Boug6, P. Fraigniaud, A. Mignotte, Y. Robert (Eds.), Euro-Par'96. Parallel Processing. Proceedings, 1996, Vol. I. XXXIII, 842 pages. 1996. Vol. 1t24: L. Boug6, P. Fraigniaud, A. Mignotte, Y. Robert (Eds.), Euro-Par'96. Parallel Processing. Proceedings, 1996, Vol. II. XXXIII, 926 pages. 1996. Vol. 1125: J. von Wright, J. Grundy, J. Harrison (Eds.), Theorem Proving in Higher Order Logics. Proceedings, 1996. VIII, 447 pages. 1996. Vol. 1126: J.J. Alferes, L. Moniz Pereira, E. Orlowska (Eds.), Logics in Artificial Intelligence. Proceedings, 1996. IX, 417 pages. 1996. (Subseries LNAI). Vol. 1127: L. B6sz0rm6nyi (Ed.), Parallel Computation. Proceedings, 1996. XI, 235 pages. 1996. Vol. 1128: J. Calmer, C. Limongelli (Eds.), Design and Implementation of Symbolic Computation Systems. Proceedings, 1996. IX, 356 pages. 1996. Vol. 1129: J. Launchbury, E. Meijer, T. Sheard (Eds.), Advanced Functional Programming. Proceedings, 1996. VII, 238 pages. 1996. Vol. 1130: M. Haveraaen, O. Owe, O.-J. Dahl (Eds.), Recent Trends in Data Type Specification. Proceedings, 1995. VIII, 551 pages. 1996.

Vol. 1141: H.-M. Voigt, W. Ebeling, I. Rechenberg, H.P. Schwefel (Eds.), Parallel Problem Solving from Nature - PPSN IV. Proceedings, 1996. XVII, 1.050 pages. 1996. Vol. 1142: R.W. Hartenstein, M. Glesner (Eds.), FieldProgrammable Logic. Proceedings, 1996. X, 432 pages. 1996. Vol. 1143: T.C. Fogarty (Ed.), Evolutionary Computing. Proceedings, 1996. VIII, 305 pages. 1996. Vol. 1144: J. Ponce, A. Zisserman, M. Hebert (Eds.), Object Representation in Computer Vision. Proceedings, I996. VIII, 403 pages. 1996. Vol. 1145: R. Cuusot, D.A. Schmidt (Eds.), Static Analysis. Proceedings, 1996. IX, 389 pages. 1996. Vol. 1146: E. Bertino, H. Kurth, G. Martella, E. Montolivo (Eds.), Computer Security - ESORICS 96. Proceedings, 1996. X, 365 pages. 1996. Vol. 1147: L. Miclet, C. de la Higuera (Eds.), Grammatical Inference: Learning Syntax from Sentences, Proceedings, 1996. VIII, 327 pages. 1996. (Subseries LNAI). Vo]. 1148: M.C. Lin, D. Manocha (Eds.), Applied Computational Geometry. Proceedings, 1996. VIII, 223 pages. 1996.

Vol. 1149: C. Montangero (Ed.), Software Process Technology. Proceedings, 1996. IX, 291 pages. 1996. Vol. 1150: A. Hlawiczka, J.G. Silva, L. Simoncini (Eds.), Dependable Computing - EDCC-2. Proceedings, 1996. XVI, 440 pages. 1996. Vol. 1151: O. Babao~lu, K. Marzullo (Eds.), Distributed Algorithms. Proceedings, 1996. VIII, 381 pages. 1996. Vol. 1152: T. Furuhashi, Y. Uchikawa (Eds.), Fuzzy Logic, Neural Networks, and Evolutionary Computation. Proceedings, 1995. VIII, 243 pages. 1996. (Subseries LNAI). Vol. 1153: E. Burke, P. Ross (Eds.), Practice and Theory of Automated Timetabling. Proceedings, 1995. XIII, 381 pages. 1996.

Vol. 1171 : A. Franz, Automatic Ambiguity Resolution in Natural Language Processing. XIX, 155 pages. 1996. (Subseries LNAI). Vol. 1172: J. Pieprzyk, J. Seberry (Eds.), Information Security and Privacy. Proceedings, 1996. IX, 333 pages. 1996. Vol. 1173: W. Rucklidge, Efficient Visual Recognition Using the Hausdorff Distance. XIII, 178 pages. 1996, Vol. 1174: R. Anderson (Ed.), Information Hiding. Proceedings, 1996. VIII, 351 pages. 1996. Vol. 1175: K.G. Jeffery, J. Kr,~l, M. Bartogek (Eds.), SOFSEM'96: Theory and Practice of Informatics. Proceedings, 1996. XII, 491 pages. 1996.

Vol. 1154: D. Pedreschi, C. Zaniolo (Eds.), Logic in Databases. Proceedings, 1996. X, 497 pages. 1996.

Vol. 1176: S. Miguet, A. Montanvert, S. Ub6da (Eds.), Discrete Geometry for Computer Imagery. Proceedings, 1996. XI, 349 pages. 1996.

Vol. 1155: J. Roberts, U. Mocci, J. Virtamo (Eds.), Broadbank Network Teletraffic. XXII, 584 pages. 1996.

Vol. 1177: J.P. M(iller, The Design of Intelligent Agents. XV, 227 pages. 1996. (Subseries LNAI).

Vol. 1156: A. Bode, J. Dongarra, T. Ludwig, V. Sunderam (Eds.), Parallel Virtual Machine - EuroPVM '96. Proceedings, 1996. XIV, 362 pages, i996.

Vol. 1178: T. Asano, Y. Igarashi, H. Nagamochi, S. Miyano, S. Suri (Eds.), Algorithms and Computation. Proceedings, 1996. X, 448 pages. 1996.

Vol. I 157: B. Thalheim (Ed.), Conceptual Modeling -ER '96. Proceedings, 1996. XII, 489 pages. 1996.

Vol. 1179: J. Jaffar, R.H.C. Yap (Eds.), Concurrency and Parallelism, Programming, Networking, and Security. Proceedings, 1996. XIII, 394 pages. 1996.

Vol. 1158: S. Berardi, M. Coppo (Eds.), Types for Proofs and Programs. Proceedings, 1995. X, 296 pages. 1996. Vol. 1159: D.L. Borges, C.A.A. Kaestner (Eds.), Advances in Artificial Intelligence. Proceedings, 1996. XI, 243 pages. (Subseries LNAI). Vol. 1160: S. Arikawa, A.K. Sharma (Eds.), Algorithmic Learning Theory. Proceedings, 1996. XVII, 337 pages. 1996. (Subseries LNAI). Vol. 1161: O. Spaniol, C. Linnhoff-Popien, B. Meyer (Eds.), Trends in Distributed Systems. Proceedings, 1996. VIII, 289 pages. I996. Vol. 1162: D.G. Feitelson, L. Rudolph (Eds.), Job Scheduling Strategies for Parallel Processing. Proceedings, 1996. VIII, 291 pages. 1996. Vol. 1163: K. Kim, T. Matsumoto (Eds.), Advances in Cryptolngy - ASIACRYPT '96. Proceedings, 1996. XII, 395 pages. 1996. Vol. 1164: K. Berquist, A. Berquist (Eds.), Managing Information Highways. XIV, 417 pages. 1996, Vol. 1165: J.-R. Abrial, E. B6rger, H, Langmaack (Eds.), Formal Methods for Industrial Applications. VIII, 511 pages. 1996. Vol. 1166: M. Srivas, A. Camilleri (Eds.), Formal Methods in Computer-Aided Design. Proceedings, 1996. IX, 470 pages. 1996. Vol. 1167: I. Sommerville (Ed.), Software Configuration Management. VII, 291 pages. 1996. Vol. 1168: I. Smith, B. Faltings (Eds,), Advances in CaseBased Reasoning. Proceedings, 1996. IX, 531 pages. 1996. (Subseries LNAI). Vol. 1169: M. Broy, S. Merz, K. Spies (Eds,), Formal Systems Specification. XXIII, 54.1 pages. 1996. Vol. 1170: M. Nagl (Ed.), Building Tightly Integrated Software Development Environments: The IPSEN Approach. IX, 709 pages. 1996.

Vol. 1180: V. Chandru, V. Vinay (Eds.), Foundations of Software Technology and Theoretical Computer Science. Proceedings, 1996. XI, 387 pages. 1996. Vol. 1181: D. BjOrner, M. Broy, I.V. Pottosin (Eds.), Perspectives of System Informatics. Proceedings, 1996. XVII, 447 pages. 1996. Vol. 1182: W. Hasan, Optimization of SQL Queries for Parallel Machines. XVIII, 133 pages. 1996. Vol. !183: A. Wierse, G.G. Grinstein, U. Lang (Eds.), Database Issues for Data Visualization. Proceedings, 1995. XIV, 219 pages. 1996. Vol. 1184: J. Wagniewski, J. Dongarra, K. Madsen, D. Olesen (Eds.), Applied Parallel Computing. Proceedings, 1996. XIII, 722 pages. 1996. Vol. 1185: G. Ventre, J. Domingo-Pascual, A. Danthine (Eds.), Multimedia Telecommunications and Applications. Proceedings, 1996. XII, 267 pages. 1996. Vol. 1186: F. Afrati, P. Kolaitis (Eds.), Database Theory - ICDT'97. Proceedings, I997. XIII, 477 pages. 1997. Vol. 1187: K. Schlechta, Nonmonotonic Logics. IX, 243 pages. 1997. (Subseries LNAI). Voh 1188: T. Martin, A.L. Ralescu (Eds.), Fuzzy Logic in Artificial Intelligence. Proceedings, 1995. VIII, 272 pages. 1997. (Subseries LNAI). Vol. 1189: M. Lomas (Ed.), Security Protocols. Proceedings, 1996. VIII, 203 pages. 1997. Vol. 1190: S. North (Ed.), Graph Drawing. Proceedings, 1996. XI, 409 pages. 1997. Vol. 1191: V. Gaede, A. Brodsky, O. G0nther, D. Srivastava, V. Vianu, M. Wallace (Eds.), Constraint Databases and Applications. Proceedings, 1996. X, 345 pages. 1996. Vol. 1192: M. Dam (Ed.), Analysis and Verification of Multiple-Agent Languages. Proceedings, 1996. VIII, 435 pages. 1997.