A Certified Protocol using Key Chains

Transcription

1 A Certfed Emal Protocol usng Key Chans J. Cederqust SQIG-IT and IST, TULsbon, Portugal M. Torab Dasht CWI, Amsterdam, The Netherlands S. Mauw Unversty of Luxembourg, Luxembourg Abstract Ths paper ntroduces an asynchronous optmstc certfed emal protocol, wth stateless recpents, that reles on key chans to consderably reduce the storage requrements of the trusted thrd party. The proposed protocol thereby outperforms the exstng schemes that acheve strong farness. The paper also dscusses the revocaton of compromsed keys as well as practcal consderatons regardng the mplementaton of the protocol. I. INTRODUCTION Alce wants to send an emal to Bob. She wshes to receve an evdence of recept when Bob receves (and s able to read) the emal. Bob s wllng to send back an evdence of recept to Alce only f he receves an evdence of orgn along wth Alce s emal. Certfed emal (CEM) protocols are to provde such servces. CEM protocols are nstances of far exchange protocols. Smlar to far exchange protocols, there are three general constructons for CEM, based on the degree of the nvolvement of trusted thrd partes (TTP). The frst class, whch chronologcally precedes the other classes, are CEM protocols wth no TTPs, see for nstance [1] and [2]. These are based on gradual release of nformaton and requre exchangng many messages to approxmate far exchange (CEM protocols wth no TTPs are theoretcally mpossble, see [3]). Moreover, they often assume that the partcpants have equal computatonal powers. Protocols of the second class need the TTP s nterventon n each exchange. Notable examples of these protocols are [4], [5], [6], [7] and [8]. A drawback of these protocols s that the TTP easly becomes a communcaton bottleneck or a sngle target of attacks. The thrd class of CEM protocols, known as optmstc far exchange protocols, requre the TTP s nterventon only f a falure (accdentally or malcously) occurs. Therefore, honest partes that are wllng to exchange ther tems (e.g. emals and recepts) can do so wthout nvolvng any TTP. Optmstc far exchange protocols bascally consst of three subprotocols (see, e.g., [9]): exchange protocol, recovery protocol and abort protocol. In the exchange protocol, that does not nvolve the TTP, the agents frst commt to exchange ther tems and then they actually exchange them. An agent A can run the recovery protocol f the opponent B has commtted to exchange, but A has not receved B s tem, and vce versa. A partcpant typcally aborts (cancels) an exchange f she does not receve the opponent s commtment to the exchange. Optmstc protocols requre the communcaton channels to and from the TTP to be reslent,.e. messages are delvered wthn an arbtrary but fnte amount of tme. Ths guarantees that, n case of a falure, protocol partcpants can eventually consult the TTP. As examples of optmstc CEM protocols we refer to [9], [10], [11] and [12]. CEM protocols have also been extended to deal wth mult-party exchanges, e.g. [13], [14] and [15], and certfed malng lsts [16]. Contrbutons In order to acheve strong farness (see secton II- B), asynchronous optmstc far exchange protocols requre stateful TTPs [17]. Therefore, the amount of nformaton that has to be stored by the TTP (vrtually for an ndefnte amount of tme) s an ssue n these protocols. In ths paper we ntroduce an asynchronous optmstc CEM protocol, wth stateless recpents, that ams at reducng the TTP s storage requrements usng key chans [18], whle guaranteeng strong farness. A key chan s a sequence of keys such that each key s derved by applyng a one-way functon to the prevous key. In secton II-D, we thoroughly descrbe how key chans are used n our proposed CEM protocol. We further optmze the protocol by usng a practcal aspect of CEM exchanges: Once two partcpants have started exchangng emals, usually several emals are exchanged between them. Ths observaton motvates our proposed CEM protocol whch mposes an ntalzaton overhead, but s more effcent for exchangng several emals. To the best of our knowledge, ths has not been prevously studed Structure of the paper In secton II we start by descrbng the assumptons underlyng the proposed protocol and ts desgn goals. The protocol s presented n the rest of secton II. In secton III we dscuss the securty of the proposed protocol and analyze how t acheves the desgn goals. Secton IV concerns practcal ssues and mplementaton consderatons of the protocol. Secton V compares our protocol wth exstng schemes and also ponts out some possble future work. We conclude the paper n secton VI. II. THE PROTOCOL In secton II-A we present the assumptons that our protocol s based on, along wth some notatons. The desgn goals are descrbed n secton II-B. The protocol s presented n two steps: Frst we gve a hgh level descrpton of a naïve desgn of the protocol n secton II- C. By frst descrbng ths, we show the deas and pont out some problems. However, the naïve desgn s not effcent and n secton II- D we explan an effcent verson of the protocol n detal. A. Notatons and assumptons Throughout the paper M denotes the content of the emal beng exchanged. To denote that an agent A sends message m to agent B we wrte A B : m. The concatenaton of the messages m 1 and m 2 s denoted m 1, m 2. 1) Communcaton channels assumptons: We assume reslent communcaton channels between each partcpant and the TTP. The channels connectng non-trusted protocol partcpants are however under the control of attackers. Therefore, no tme bound on delverng messages s assumed for these channels (e.g. messages can get lost). 2) Cryptographc notatons and assumptons: We assume deal cryptographc apparatus à la Dolev and Yao [19]: A message m encrypted wth the symmetrc key K s denoted {m} K, from whch m can only be extracted usng K. We assume the exstence of a publc key nfrastructure. The notatons pk(x) and sk(x) represent the publc and prvate keys of entty X, respectvely. In asymmetrc encrypton we have {{m} sk (X) } pk(x) = {{m} pk(x) } sk(x) = m. Encryptng wth a prvate key denotes sgnng and, for convenence, for {m} sk(x) we wrte (m) X. We also assume access to one-way collson-resstant hash functons. 3) TTP assumptons: We assume that the TTP T mantans a persstent secure database, wth entres of the form X, Y, Z, W, where X and Y are partcpant denttes, Z s a key and W contans

2 a random number (see secton II-D.1). Assocated wth each such entry, T stores a lnked lst, ntally of length zero. Each element of such a lnked lsts s of the form (, status()), where N and status() {0, 1} l {a}, for a fnte l, and a specal flag a that denotes an aborted exchange. In status, T stores the status of resolved exchanges,.e. whether they have been recovered or aborted (see sectons II-D.3 and II-D.4). 4) Idempotency assumpton: Exchanged tems,.e. emals and evdences, are assumed dempotent. Therefore, to be able to receve an emal or recept twce s not dfferent from recevng t once (meanng that t s not consdered as an attack). B. Desgn goals One of the most fundamental requrements for CEM protocols s non-repudaton. Non-repudaton guarantees that an agent cannot deny havng sent or receved a message, f t has actually done so n the course of the protocol. To acheve ths, protocol partcpants usually collect evdences, evdence of orgn (EOO) and evdence of recept (EOR), whch can later be presented to a judge. The second requrement for CEM protocols s to satsfy the far exchange propertes [9]. Here we am at strong farness as s defned below (for defntons of dfferent levels of farness see [20]). Far exchange conssts of three propertes: Effectveness states that f A and B engage n the protocol and are wllng to exchange emals for recepts, then the protocol wll reach a state where B has receved the emal content M and EOO, and A has receved EOR, and both A and B have termnated,.e. they have no further pendng operatons to perform n that protocol round. Farness states that when the protocol round termnates, f A has receved EOR, then B has receved both M and EOO, and f A has not receved EOR, then B possesses nether M nor EOO. Tmelness means that an honest partcpant can unlaterally, or wth the help of a TTP, termnate the protocol run. Moreover, after termnaton, the degree of farness does not decrease for an honest partcpant,.e. f he dd not receve hs evdence or emal content before termnatng, then t cannot be that the other partcpant gets her evdence or emal content at some future tme. Confdentalty s another requrement for CEM protocols whch states that the exchanged emal content should not be revealed to anyone (ncludng the TTP), except to the ntended recever. Our proposed protocol does not drectly address confdentalty. However, f confdentalty s desred, the exchanged emal content M can be substtuted wth the actual emal content encrypted for the recever usng hs publc-key or a shared secret key. C. The naïve protocol In most exstng non-repudaton and CEM protocols, the ntator uses a separate key to encrypt the emal to be exchanged, for each sngle protocol round. If the exchange goes amss, the partes can resort to a TTP, that wll store the key along wth some other nformaton about the exchange, such as nvolved partes, a hash value of the emal content and an exchange label (e.g. see [21]). Ths nformaton s stored vrtually for an ndefnte amount of tme (see secton V for more dscussons). We am at reducng the amount of nformaton stored by the TTP usng key chans (c.f. [18]). A chan of keys s a sequence of keys K 0,..., K n such that K := H(K 1), for > 0, where H s a publcly known one-way functon. The key K 0 s called the chan seed. The key chan s ntated by the ntator Alce who chooses a seed K 0 and shares t wth the TTP. They moreover agree on the maxmum number n of exchanges that Alce can perform usng the chan. Afterward, Alce traverses the chan backwards and she uses K n (for n) to encrypt the message n the th exchange. Provded that the hash functon H s premage resstant,.e. gven H(x) t s hard to compute x, the key used n th exchange remans unknown to the recever Bob unless he knows one of the K j for j. However, snce Alce traverses the chan backwards, the keys seem to be fresh and ndependent. The th exchange starts wth Alce sendng an emal to Bob, encrypted usng K n, a key that Bob does not know (yet). Bob commts to the exchange by acknowledgng the recepton of the encrypted emal. Afterward Alce sends Bob the key and, fnally, Bob also acknowledges the recepton of the key. In ths scenaro the TTP nterferes only when a party does not receve the message he or she expects. Intutvely, when a party can prove that the opponent has commtted to the exchange, then the TTP provdes that party wth the encrypton key along wth some affdavts. When key chans are used, n order to produce the key used n any resolved exchange, the TTP only needs to store the seed. The storage requred s thus reduced consderably. Ths protocol s trvally not purely optmstc because Alce needs to set up a chan wth the TTP. However, f the number n of exchanges s large enough, then the ganed reducton n requred storage space of the TTP wll, n many practcal applcatons, compensate the overhead of the ntal setup phase. But, one sngle problem prevents ths dea to be practcal: It s costly to abort an exchange. Ths s because of the followng stuaton: Assume that exchange number s aborted. Ths means that K n s not revealed to Bob, but he gets hold of the encrypted emal. Ths can happen for nstance when Alce sends the encrypted emal to Bob, but afterward changes her mnd and aborts the exchange, for example because Bob s slow n replyng. Now f the protocol proceeds and the ( + 1) th sesson termnates successfully, then Bob learns K n (+1). Because of the way the chan s constructed, Bob can easly fnd out K n (by computng H(K n (+1) )) and decrypt the emal content of the aborted sesson at wll. Farness s thus volated. Therefore, f an exchange s aborted, Alce needs to abandon usng the rest of the chan altogether and set up a new key chan wth the TTP. Ths can potentally mpose a huge effcency penalty on the protocol. The next secton descrbes a way to crcumvent ths problem. D. The man protocol Here we descrbe our asynchronous optmstc far CEM protocol. Ths protocol uses keys n a key chan for encryptng emals that are exchanged. Once ths chan has been ntalzed, emals can be encrypted and exchanged, each tme wth a new key. The protocol also provdes a way for the ntator to revoke an entre key chan. Each exchange (or attempt to exchange) that uses the optmstc protocol (and possbly also the recovery and abort protocols) s called a protocol round. An ntalzaton phase followed by a number of protocol rounds s called a protocol sesson. After the ntalzaton phase, the ntator can send emals to the responder. Each protocol sesson belongs to one unque ntator-responder par. However, the protocol naturally allows concurrent sessons. An agent can thus be nvolved n dfferent sessons wth dfferent opponents at the same tme.

3 1) Intalzaton: Frst, the ntator A chooses a fresh random key K 0, the seed of the key chan. For 0, let K +1 := H(K ) and K := H (K ), where H s a publcly known secure hash functon, whle H can be an ordnary hash functon. Moreover, we requre that H and H do not commute,.e. for any x, H (x) does not reveal any nformaton about H (H(x)). The chan K 0, K 1,... of keys s used for encryptng the emals whch are to be exchanged. Clearly any K can be calculated from K 0 usng H and H (see fgure 1). Agent A subsequently sends the seed K 0 and the dentty of the potental responder (of the sesson) B to the TTP T : 1. A T : {A, B, K 0, nc} pk(t ), (A, B, K 0, nc) A 2. T A : sd, nc, cert, (nc, cert) T (1) where the certfcate cert := (A, B, sd) T and nc s a fresh nonce chosen by A, and sd s a unque sesson dentfer chosen by T. H H K 0 K... H 1 K... H H H K 0 K 1 K Fg. 1. Double key chan T stores entres of the form ntator, responder, key, sd, where key s the seed chosen by A. The key chan rooted at key can be used for sendng CEMs from ntator to responder. When T receves the frst message, T checks the sgnature, and f t s vald then T looks for the entry A, B, K 0, n ts database. If A, B, K 0, s not already present n ts database, then T chooses a fresh sesson dentfer sd and adds A, B, K 0, sd to the database. The TTP then sends back a confrmaton of that t approves ths sesson. If A, B, K 0, already exsts n the database, T gnores the request (and sends an error message to A). 2) Exchange protocol: Each protocol round has an order number, whch ntally s 0, and after each round the ntator A ncrements t. The th protocol round s as follows 1. A B : A, B, T,, sd, h(k ), {M} K, EOO M, cert 2. B A : EOR M 3. A B : K 4. B A : EOR K (2) where EOO M := (B, T, h(k ), h({m} K ),, sd) A EOR M := (EOO M ) B EOR K := (K, h({m} K )) B Here h s a secure hash functon, possbly equal to H. In the frst message, A sends the encrypted emal content {M} K, the hash value of the encrypton key h(k ) and the sesson certfcate (A, B, sd) T. The responder B checks the correctness of the message and commts tself to receve the emal by sendng message 2, f he trusts T. Then A sends the key K. Agent B checks that ths key matches the hash value of the key that he receved n message 1. Fnally, f the key s correct, B sends a confrmaton of havng receved the key. The number s only used mplctly by B when t resolves the protocol round. 3) Recovery protocol: The ntator A may run the recovery protocol after havng receved message 2 n the exchange protocol, by presentng EOR M to the TTP. Ths shows that A has actually sent EOO M to B, ensurng that B s also able to receve a recovery token for that exchange. Agent A typcally runs the recovery protocol to complete the EOR (as defned n secton II-D.5 below), f t does not receve message 4 n the exchange protocol. The responder B may run the recovery protocol after recevng message 1 n the exchange protocol, n order to get the encrypton key. The recovery protocol ntated by P {A, B} starts wth the followng message: 1 r. P T : f r, A, B, h(k ), h({m} K ),, sd, EOR M (3) where f r s a flag used to dentfy the recovery request. On recevng ths message, T performs the followng tests: T checks f the sgnatures n the message are genune and f ts own dentty s gven as the desgnated TTP. T checks whether there s an entry n ts database matchng A, B,, sd. If the prevous tests succeed, then the result of the query s a unque entry A, B, K 0, sd (see Intalzaton phase, secton II- D.1). Subsequently T uses the retreved K 0 to check whether h(h (H (K 0))) matches h(k ) n the message. If the results of all these tests are affrmatve, then T checks whether round has already been resolved or not. For each key chan (correspondng to one sngle entry A, B, K 0, sd n T s database) and each exchange 0 that s resolved at T, T stores whether that exchange has been recovered or aborted n a status varable status() (c.f. secton II-A.3). If status() has not been ntalzed n T s database, t sets status() := h({m} K ). 1 Then T proceeds as f status() had already been set for the exchange, as s descrbed below. If status() has already been ntalzed n the database, T sets v := f status() = a, and sets v := K n case status() = h({m} K ). Then T sends the followng message and termnates ths resolve. 2 r. T P : v, (A, B, h({m} K ), v,, sd) T (4) The message (A, B, h({m} K ),,, sd) T, where s a specal flag that denotes an aborted exchange, serves as an abort token. When P receves ths message, t can safely qut the protocol. The message K, (A, B, h({m} K ), K,, sd) T serves as a recovery token for P (see evdences n secton II-D.5). If (status() = h({m} K )) or any of the tests mentoned above fals, then T gnores the recovery request and sends back the error message 2 r. T P : f e, (f e, f r, h(eor M)) T (5) where f e s an error flag. Ths ndcates a msbehavor, and based on ths message, P can qut the protocol. 4) Abort protocol: The ntator A may abort an exchange at any stage, provded that the exchange has not been recovered already. Typcally A aborts f t does not receve message 2 n the exchange protocol. On the other hand, the responder B can never explctly request the TTP to abort an exchange that has been ntated by A. To abort an exchange, A sends the followng message to T 1 a. A T : f a, A, B, h({m} K ),, sd, abrt (6) where abrt := (f a, B, T, h({m} K ),, sd) A and f a s a flag dentfyng the abort request. On recevng ths message, T checks A s sgnature on abrt and ts own dentty n the message, and t queres ts database wth A, B,, sd only f they match. The result s a unque 1 Note that f the hash functon h produces hash values of l bts length,.e. h : {0, 1} {0, 1} l, then we have status() {a} {0, 1} l.

4 A, B, K 0, sd (see Intalzaton phase). Then T checks whether sesson has already been resolved, by checkng whether status() has been ntalzed n ts database or not. If not, T sends back the followng message: 2 a. T A : (A, B, h({m} K ),,, sd) T (7) Ths message serves as an abort token and when A receves t, A can safely qut the protocol. The TTP T then sets status() := a and termnates ths resolve. Smlarly, f status() has already been set n T s database as status() = a, then T sends the above message and termnates the resolve. If status() has already been set n T s database ndcatng a recovery,.e. (status() = a), then T tests whether status() = h({m} K ). If the test succeeds, T sends the followng message and termnates ths resolve: 2 a. T A : (A, B, h({m} K ), K,, sd) T (8) Ths message consttutes a recovery token for A, for ths exchange. If (status() = h({m} K )) or f A, B,, sd does not exst n T s database, or f any of the tests mentoned above fals, then T gnores the abort request and sends back an error message: 2 a. T A : f e, (f e, abrt) T (9) Note that an abort token does not necessarly mean that an exchange has not fnshed successfully, snce A can abort an already completed exchange. An abort token merely ndcates that T wll never ssue a recovery token (hence releasng the key) for that partcular protocol round, unquely dentfed wth sd and. 5) Evdences and dspute resoluton: In case of a dspute, the partes can present evdences to an external judge. We note that each protocol round (of each protocol sesson) has an assocated unque EOO and EOR. The evdence of recept EOR, desred by A, conssts of A, B, T, M,, sd, K, cert, EOR M, EOR K, f t s obtaned by runnng the exchange protocol. If A uses the recovery or abort protocols, then the last element EOR K s replaced by the recovery token (A, B, h({m} K ), K,, sd) T. The evdence of orgn EOO, desred by B, conssts of A, B, T, M,, sd, K, EOO M An external judge settles a dspute by smply checkng whether the EOR or EOO presented by the dsputng partes are genune. We emphasze that abort tokens have no weght n these evdences. Therefore, havng an abort token does not overrde or repudate havng a recovery token or any other evdence. The purpose of the abort protocol s solely to guarantee tmelness for the ntator. 6) Revokng compromsed key chans: In practce t may happen that Alce s computer s compromsed and the key chan seed s revealed to an attacker. In such stuatons, Alce mght lke to revoke the key chan she has set up wth the TTP. 2 Therefore, the protocol allows Alce to ask the TTP, at any moment, to mark her key chan as obsolete: A T : f o, cert, (f o, cert) A (10) Here f o s a flag that denotes a request to mark the chan dentfed by cert as obsolete. Upon recevng ths message, T checks A s 2 We assume that the attacker cannot get access to Alce s prvate key. Methods for revokng keys n PKIs have been extensvely studed, e.g. see [22]. sgnature and f cert s a genune certfcate from T to A, and (only f ths s the case) marks the entry A, B,, sd (whch s unque) as obsolete. Markng an entry as obsolete means that T wll not recover or abort protocol rounds connected to that entry any more. But t wll behave as normal f t s quered about a protocol round for whch a status value has already been set. Ths behavor ensures that Alce cannot cheat Bob by frst resolvng an exchange and then markng the chan as obsolete (purportng that Bob would not be able to recover exchanges that use an obsolete chan). We remark that revokng a key chan does not protect contents of emals that belong to prevously aborted protocol rounds: If Bob compromses the key chan that Alce has used to send CEMs to hm, then he can read the contents of emals from prevous protocol rounds whch were aborted. E. Dscussons 1) Comparng the man protocol wth the naïve protocol: Dfferently than n the protocol sketch n secton II-C, n the man protocol (n secton II-D) t s not needed to specfy the maxmum number n of exchanges. In the protocol sketch, n was used to specfy the start pont of the chan traversal as Alce needed to traverse the chan backwards. In the man protocol the whole chan s obscured usng H. So t s not needed to put any order on the key chan traversal. Hence, t s not needed to specfy n. 2) Stateful vs. stateless recpents: Note that the recevers are stateless,.e. they do not need to keep track of the protocol rounds or sessons that they have been nvolved n. However, they mght want to store the evdences that they collect durng the exchanges. It s nonetheless possble to requre that the recevers store cert,.e. (A, B, sd) T, the frst tme they receve t (f they ntend to contnue acceptng CEMs from the sender A). Ths certfcate can subsequently be omtted from future protocol rounds between the sender and that partcular recever, hence reducng the communcaton costs. III. SECURITY ANALYSIS In ths secton we justfy the man protocol by nformally showng that t acheves the desgn goals descrbed n secton II-B. A formal treatment of the securty of the protocol s left for future work. We note that the structure of the protocol s smlar to exstng schemes, such as [12] and [21], except for the use of key chans. We thus focus the securty analyss more on ssues that are specfc to the use of key chans n the protocol. For convenence, n the followng dscussons A and B denote the ntator and the responder partes, respectvely. Non-repudaton: If A receves EOR (see secton II-D.5), t can show that B has receved both {M} K and K, and B s therefore able to extract M. Moreover, B cannot deny that t s able to obtan M because of ts sgnatures n EOR. Smlarly, f B receves EOO, t can show that A has ndeed sent K and {M} K, because of ts sgnatures n EOO M. Note that t s only A (or the TTP on behalf of A) who s able to generate K. Effectveness: If A and B follow the exchange protocol, A receves EOR ff B receves M and EOO. Farness: As mentoned above (effectveness), f the exchange protocol termnates normally then A receves EOR ff B receves M and EOO. However, f the exchange protocol s (mstakenly or malcously) nterrupted, then A can only recover the protocol round by presentng EOR M to the TTP, hence provng that B has ndeed receved EOO M n the nterrupted exchange protocol. In ths case B can also recover and receve the encrypton key used n that round. If B recovers the exchange after t has receved EOO M but wthout sendng EOR M to A,

5 then A can (and needs to) abort n order to receve a recovery token for that exchange. It may seem as f t could be a problem that A can reuse a key K that has been used n a prevous (possbly recovered or aborted) protocol round, to ntate a new round. But, as we wll show here, t s of A s own nterest to never reuse keys. Snce EOR K contans h({m} K ), A needs ether to send K n the exchange protocol or to recover the exchange n order to receve the EOR K and complete the EOR. In the frst case, the exchange protocol termnates successfully, leavng A and B n the same far state. In the second case, there are three possbltes: (1) The key K has been used n a protocol round that termnated normally: In ths case, the protocol executes normally,.e. as f s a fresh (not reused) ndex. (2) The key K has been used n a protocol round that was recovered: If B s honest, B wll also recover, and when they recover, both A and B receve an error message (unless the emal content s actually exactly the same as what has already been recovered). Ths leaves A and B n the same (far) state. (3) The key K has been used n a protocol round that was aborted: A receves nether the recovery token nor the last message from B. Thus, A cannot collect an EOR, nether can B collect EOO. Potentally A could abort a completed exchange and then start a new protocol round wth the same emal content and key. In the new round, f A fals to contnue the exchange protocol after recevng EOR M, B receves an abort token when t tres to resolve, snce the TTP has actually stored that round as aborted. But, because of the dempotency assumpton (see secton II- A.4), A does not gan anythng more than what t had before reusng the key and the emal content. Moreover, the abort token does not overrde the EOO that B has already collected. Thus the level of farness acheved by B s not decreased. We fnally remark that f A malcously uses a key that has been revealed to B earler, then B can easly (by volatng the protocol) obtan an EOO wthout sendng message 2 n the exchange protocol. Tmelness: The agents A and B termnate a protocol round ether by completng the exchange protocol, or by executng the recovery or abort protocol. Agent A can run the abort protocol at any tme. It can also run the recovery protocol after t has receved the second message n the exchange protocol. Agent B can recover the protocol after t has receved the frst message n the exchange protocol. Here we omt the detals, but termnaton s guaranteed by the fact that the channels to the TTP are reslent. Note that termnaton of B depends on that t has the dentty of the desgnated TTP sgned by A n the frst message of the exchange protocol (as t s n the man protocol). Ths s because A would otherwse be able to cheat B by resolvng at a TTP whch s not known (or trusted) to B, hence leavng B n an unfar stuaton. To show that the degree of farness does not decrease for an honest partcpant after termnaton, t s enough to show that, f A (B) has termnated and not receved EOR (M and EOO), then B (A) wll not receve M or EOO (EOR). But, f A (B) has termnated and not receved EOR (M and EOO), then we nfer that the protocol round was aborted, and after an aborton B (A) cannot learn M or EOO (EOR). IV. IMPLEMENTATION CONSIDERATIONS Hash chans can n practce be constructed usng SHA-1 hash functons [23] as H. A choce for H can be MD5 [24], so that H and H do not commute. Other optons for these would be to use varous HMAC constructons [25] or secure block cpher encrypton algorthms. In lght of the recently dscovered weaknesses of MD5 and the SHA famly of hash functons (see e.g. [26]), t s mportant to notce that collson resstance s not of paramount mportance to our protocol. There are two ways to counter collson attack. The frst s to add redundancy to M (before encrypton) n the frst message of the exchange protocol. In ths way a collson between the keys k and k can be detected because the ncorrect key yelds an ncorrect message after decrypton. The second approach s to requre that the TTP T determnes the ntal key K 0 nstead of the ntator A. Ths soluton wll counter collson attacks, but wll not help f the hash functon s flawed wth respect to second-premage resstance. A problem wth hash chans s that when the length of a chan s ncreased, n practce the chance that a collson between that chan and another one occurs ncreases. A standard soluton (e.g. see [27]) to ths problem s to reduce the chance of collson by usng the correspondng ndexes when computng hash values: K := H(K 1, ). For an n-depth dscusson on constructng and mplementng hash chans we refer the nterested reader to [27]. We propose to use the AES encrypton standard [28] for mplementng symmetrc key encryptons nvolved n the proposed protocol. Usng hash functons to construct keys means that the length of the keys wll be fxed, e.g. 160 bts f SHA-1 s used for H. We note that currently AES wth 128-bt keys s consdered secure. Therefore, the result of the hash functon can be truncated to 128 bts to ft nto the AES standard. 3 V. RELATED AND FUTURE WORK Related work In ths paper we use hash chans of keys for repeated encrypton n CEM protocols. The dea of usng hash chans n securty protocols can be traced back to [18], where they are used for repeated authentcaton. Hash chans have later on been used n authentcaton protocols, e.g. [30], [31], and key management systems, e.g. [32]. There s no general consensus n the lterature on the requrements of CEM protocols: For example, n [5] and [8], t s not consdered necessary for CEM protocols to provde EOO. In [33] t s argued that tmelness for the recever s not requred n CEM protocols. Conversely, n [11], tmelness for the sender s deemed unnecessary. In ths paper we am at strong farness, whch guarantees tmelness for both partes, and provdes both EOO and EOR. Below we study the effcency and compare the TTP s storage requrements and the number of messages n the exchange protocol, between our proposed protocol and exstng schemes. Exstng schemes often requre the TTP to store the key used for each sngle exchange along wth the denttes of the partcpants, the hash of the exchanged message and typcally also a unque exchange dentfer, e.g. see [21] for a revew. In our protocol the TTP only needs to store one seed for each chan and the status of recovered or aborted rounds. When resolvng, the TTP has to perform a few hash functon computatons n our protocol. However, these are n general very cheap. So, when exchangng multple certfed emals, our protocol outperforms the exstng asynchronous optmstc CEM protocols (that provde strong farness) n the amount of nformaton stored by the TTP. Note that the protocols of [11], [33] and [34], whch only need stateless TTPs, are not strongly far,.e. they do not guarantee tmelness for ether sender or recever. Other protocols 3 The Rjndael algorthm, on whch the AES s based, n fact allows usng 160-bt keys, whle the AES standard only supports 128, 192 and 256 bt key szes [29].

6 wth stateless TTPs, such as [6], are not optmstc, or rely on synchronous communcaton channels as n [35]. In fact, t has been shown n [17] that asynchronous optmstc contract sgnng (a cousn of CEM) wth stateless TTPs cannot provde strong farness. Concernng the number of messages n the exchange protocol, accordng to [17], four messages s the least to acheve strong farness for asynchronous optmstc contract sgnng protocols. Exstng CEM protocols wth only three messages n the optmstc phase are not strongly far: The protocols of [11] do not guarantee tmelness of the sender. The protocols of [36], [37] (fxng a flaw n [36]), [38] (fxng a flaw n [36] and [37]), [15] and [39] (fxng a flaw n [15]) acheve farness only under the rather unrealstc assumpton that the cheater party collaborates wth the suffered party and attends the court, n case of a dspute. In these protocols, snce some of the collected evdences can conceptually be revoked based on other evdences (c.f. [40], [41]), only a weak noton of farness s attanable. Future work The desgn of the proposed CEM protocol certanly calls for formal verfcatons to ensure that by reducng the storage requrements of the TTP, no securty flaws are ntroduced n the system. Whether the proposed protocol can be generalzed to a multparty settng s another queston whch needs further nvestgaton. VI. CONCLUSIONS In ths paper, we have ntroduced an asynchronous optmstc CEM protocol wth stateless recpents. The protocol reles on key chans to reduce the storage requrements of the TTP, mprovng on exstng schemes that acheve strong farness. We have analyzed the protocol nformally and showed that t guarantees non-repudaton, effectveness, (strong) farness and tmelness. We have also gven a cryptographc justfcaton to our usage of key chans, usng standard cryptographc technques. Acknowledgment: We are grateful to Rcardo Corn for hs contrbutons on earler versons of the paper, n partcular for the dea of usng (sngle) hash chans to reduce the TTP s storage requrements, and to Ana Almeda Matos for proof readng the paper. The frst author has been supported by the NWO project ACCOUNT and by the FEDER/FCT project QuantLog POCI/MAT/55796/2004. REFERENCES [1] S. Even, O. Goldrech, and A. Lempel, A randomzed protocol for sgnng contracts, Commun. ACM, vol. 28, no. 6, pp , jun [2] M. Ben-Or, O. Goldrech, S. Mcal, and R. L. Rvest, A far protocol for sgnng contracts, IEEE Trans. on Informaton Theory, vol. 36, no. 1, pp , jan [3] S. Even and Y. Yacob, Relatons among publc key sgnature systems, Computer Scence Dept., Technon, Hafa, Isreal, Tech. Rep. 175, March [4] A. Bahreman and D. Tygar, Certfed electronc mal, n Symp. on Network and Dstrbuted Systems Securty. Internet Socety, Feb. 1994, pp [5] J. Zhou and D. Gollmann, Certfed electronc mal, n ESORICS 96. Sprnger, 1996, pp [6] R. H. Deng, L. Gong, A. A. Lazar, and W. Wang, Practcal protocols for certfed electronc mal, J. Network Syst. Manage., vol. 4, no. 3, [7] J. Rordan and B. Schneer, A certfed E-mal protocol, n 14th Annual Computer Securty Applcatons Conference. ACM, [8] M. Abad and N. Glew, Certfed emal wth a lght on-lne trusted thrd party: desgn and mplementaton, n WWW 02. ACM Press, 2002, pp [9] N. Asokan, V. Shoup, and M. Wadner, Asynchronous protocols for optmstc far exchange, n IEEE Securty and Prvacy 98. IEEE CS, May 1998, pp [10], Optmstc far exchange of dgtal sgnatures, n Eurocrypt 98, ser. LNCS, vol. 1403, 1998, pp [11] S. Mcal, Smple and fast optmstc protocols for far electronc exchange, n PODC 03. ACM Press, 2003, pp [12] J. G. Cederqust, R. Corn, and M. Torab Dasht, On the quest for mpartalty: Desgn and analyss of a far non-repudaton protocol. n ICICS 05, ser. LNCS, vol Sprnger, 2005, pp [13] N. Asokan, M. Schunter, and M. Wadner, Optmstc protocols for mult-party far exchange, IBM Research, Research Report RZ 2892 (# 90840), dec [14] S. Kremer and O. Markowtch, A mult-party non-repudaton protocol, n ISC 00, ser. IFIP. Kluwer Academc, Aug. 2000, pp [15] J. L. Ferrer-Gomla, M. Payeras-Capellà, and L. H. Rotger, A realstc protocol for mult-party certfed electronc mal. n ISC 02, ser. LNCS, vol Sprnger, 2002, pp [16] H. Khurana and H.-S. Hahm, Certfed malng lsts, n AsaCCS 06. ACM Press, 2006, pp [17] B. Pftzmann, M. Schunter, and M. Wadner, Optmal effcency of optmstc contract sgnng, n PODC 98. ACM Press, 1998, pp [18] L. Lamport, Password authentcaton wth nsecure communcaton, Commun. ACM, vol. 24, no. 11, pp , [19] D. Dolev and A. C. Yao, On the securty of publc key protocols, IEEE Trans. on Informaton Theory, vol. IT-29, no. 2, pp , [20] H. Pagna, H. Vogt, and F. C. Gärtner, Far exchange, The Computer Journal, vol. 46, no. 1, pp. 55 7, [21] S. Gürgens, C. Rudolph, and H. Vogt, On the securty of far nonrepudaton protocols. Int. J. Inf. Sec., vol. 4, no. 4, pp , [22] D. Boneh, X. Dng, G. Tsudk, and M. Wong, A method for fast revocaton of publc key certfcates and securty capabltes, n 10th Usenx Securty Symposum, 2001, pp [23] D. Eastlake and P. Jones, US secure hash algorthm 1 (SHA1), 2001, RFC [24] R. Rvest, The MD5 message-dgest algorthm, 1992, RFC [25] M. Bellare, R. Canett, and H. Krawczyk, Keyng hash functons for message authentcaton, n CRYPTO 96. Sprnger, 1996, pp [26] X. Wang, Y. L. Yn, and H. Yu, Fndng collsons n the full SHA-1, n CRYPTO 05. Sprnger, 2005, pp [27] Y.-C. Hu, M. Jakobsson, and A. Perrg, Effcent constructons for oneway hash chans. n ACNS 05, ser. LNCS, vol. 3531, 2005, pp [28] NIST, Advanced encrypton standard (AES), 2001, FIPS PUB 197. [29] J. Daemen and V. Rjmen, The Desgn of Rjndael: AES - The Advanced Encrypton Standard. Sprnger, [30] R. Anderson, F. Bergadano, B. Crspo, J.-H. Lee, C. Manfavas, and R. Needham, A new famly of authentcaton protocols, SIGOPS Oper. Syst. Rev., vol. 32, no. 4, pp. 9 20, [31] A. Perrg, J. D. Tygar, D. Song, and R. Canett, Effcent authentcaton and sgnng of multcast streams over lossy channels, n IEEE SP 00. IEEE CS, 2000, p. 56. [32] J. Daemen, Management of secret keys: Dynamc key handlng. n State of the Art n Appled Cryptography, ser. LNCS, vol Sprnger, 1998, pp [33] G. Atenese, Verfable encrypton of dgtal sgnatures and applcatons, ACM Trans. Inf. Syst. Secur., vol. 7, no. 1, pp. 1 20, [34] A. Nenadc, N. Zhang, and S. Barton, Far certfed e-mal delvery, n SAC 04. ACM Press, 2004, pp [35] P. D. Ezhlchelvan and S. K. Shrvastava, A famly of trusted thrd party based far-exchange protocols, IEEE Trans. Dependable Secur. Comput., vol. 2, no. 4, pp , [36] J. L. Ferrer-Gomla, M. Payeras-Capell, and L. H. Rotger, An effcent protocol for certfed electronc mal, n ISW 00. Sprnger, 2000, pp [37] J. R. M. Montero and R. Dahab, An attack on a protocol for certfed delvery. n ISC 02, ser. LNCS, vol Sprnger, 2002, pp [38] G. Wang, F. Bao, and J. Zhou, On the securty of a certfed e-mal scheme. n INDOCRYPT 04, ser. LNCS, vol Sprnger, 2004, pp [39] J. Zhou, On the securty of a mult-party certfed emal protocol. n ICICS 04, ser. LNCS, vol Sprnger, 2004, pp [40] S. Even, A protocol for sgnng contracts, SIGACT News, vol. 15, no. 1, pp , [41] B. Pftzmann, M. Schunter, and M. Wadner, Optmal effcency of optmstc contract sgnng, IBM Zürch Research Lab, Zürch, Tech. Rep. RZ 2994 (#93040), February 1998.