Available online at www.sciencedirect.com

SCIENCE DIRECT«

ELSEVIER Electronic Notes in Theoretical Computer Science 155 (2006) 111-145

www.elsevier.com/locate/entcs

Real-or-random Key Secrecy of the Otway-Rees Protocol via a Symbolic Security

Proof 1

Michael Backes

IBM Zurich Research Lab mbc@zurich.ibm.com

Abstract

We present the first cryptographically sound security proof of the well-known Otway-Rees protocol. More precisely, we show that the protocol is secure against arbitrary active attacks including concurrent protocol runs if it is implemented using provably secure cryptographic primitives. We prove secrecy of the exchanged keys with respect to the accepted cryptographic definition of real-or-random secrecy, i.e., indistinguishability of exchanged keys and random ones, given the view of a general cryptographic attacker. Although we achieve security under cryptographic definitions, our proof is performed in a deterministic setting corresponding to a slightly extended Dolev-Yao model; in particular, it does not have to deal with probabilistic aspects of cryptography and is hence in the scope of current proof tools. The reason is that we exploit a recently proposed ideal cryptographic library, which has a provably secure cryptographic implementation, as well as recent results on linking symbolic and cryptographic key secrecy. Besides establishing the cryptographic security of the Otway-Rees protocol, our result also exemplifies the potential of this cryptographic library and the recent secrecy preservation theorem for symbolic yet cryptographically sound proofs of security.

Keywords: Cryptographic soundness, Otway-Rees, real-or-random secrecy, Dolev-Yau model

1 Introduction

Many practically relevant cryptographic protocols like SSL/TLS, S/MIME, IPSec, or SET use cryptographic primitives like signature schemes or encryption in a black-box way, while adding many non-cryptographic features. Vulnerabilities have accompanied the design of such protocols ever since early

1 Extended and revised version of [4].

1571-0661/$ - see front matter © 2006 Published by Elsevier B.V. doi:10.1016/j.entcs.2005.11.054

authentication protocols like Needham-Schroeder [38,20], over carefully designed de-facto standards like SSL and PKCS [44,17], up to current widely deployed products like Microsoft Passport [22]. However, proving the security of such protocols has been a very unsatisfactory task for a long time.

One way to conduct such proofs is the cryptographic approach, whose security definitions are based on complexity theory, e.g., [24,23,25,14]. The security of a cryptographic protocol is proved by reduction, i.e., by showing that breaking the protocol implies breaking one of the underlying cryptographic primitives with respect to its cryptographic definition. This approach captures a very comprehensive adversary model and allows for mathematically rigorous and precise proofs. However, because of probabilism and complexity-theoretic restrictions, these proofs have to be done by hand so far, which yields proofs with faults and imperfections. Moreover, such proofs rapidly become too complex for larger protocols.

The alternative is the formal-methods approach, which is concerned with the automation of proofs using model checkers and theorem provers. As these tools currently cannot deal with cryptographic details like error probabilities and computational restrictions, abstractions of cryptography are used. They are almost always based on the so-called Dolev-Yao model [21]. This model simplifies proofs of larger protocols considerably and gave rise to a large body of literature on analyzing the security of protocols using various techniques for formal verification, e.g., [35,33,29,18,41,1].

Among the protocols typically analyzed in the Dolev-Yao model, the Otway-Rees protocol [39], which aims at establishing a shared key between two users by means of a trusted third party, stands out as one of the most prominent protocols. It has been extensively studied in the past, e.g., in [40,28,41], and various new approaches and formal proof tools for the analysis of security protocols were validated by showing that they can prove the protocol in the Dolev-Yao model (respectively that they can find the well-known type-flaw attack if the underlying model does not provide sufficient typing itself; the model that our proof is based upon excludes this attack). However, all existing proofs of security of the Otway-Rees protocol are restricted to the Dolev-Yao model, i.e., no theorem exists which allows for carrying over the results of an existing proof to the cryptographic approach with its much more comprehensive adversary. Thus, despite the tremendous amount of research dedicated to the Otway-Rees protocol, it is still an open question whether an actual implementation based on provably secure cryptographic primitives is secure under cryptographic security definitions. We close this gap by providing the first security proof of the Otway-Rees protocol in the cryptographic approach. We show that the protocol is secure against arbitrary active attacks

if the Dolev-Yao-based abstraction of symmetric encryption is implemented using a symmetric encryption scheme that is secure against chosen-ciphertext attacks and that additionally ensures integrity of ciphertexts. More precisely, we prove real-or-random secrecy of the exchanged keys, i.e., we show that no cryptographic attacker is able to distinguish fresh, random keys and keys that are actually exchanged between two honest participants unless the underlying cryptography can be broken. This is the accepted cryptographic definition of key secrecy. Moreover, we show consistency of the protocol in that parties that have successfully established a shared key have a consistent view of who the peers of the sessions are.2 Chosen-ciphertext security and integrity of ciphertexts are the standard security definition of authenticated symmetric encryption schemes [16,15], and efficient symmetric encryptions schemes provably secure in this sense exist under reasonable assumptions [15,43].

Obviously, establishing a proof in the cryptographic approach presupposes dealing with the mentioned cryptographic details, hence one naturally assumes that our proof heavily relies on complexity theory and is far out of scope of current proof tools. However, our proof is not performed from scratch in the cryptographic setting, but based on a recently proposed cryptographic library [10,11,8], which provides cryptographically faithful, deterministic abstractions of cryptographic primitives, i.e., the abstractions can be securely implemented using actual cryptography. Moreover, the library allows for nesting the abstractions in an arbitrary way, quite similar to the original Dolev-Yao model. While this was shown for public-key encryption and digital signatures in [10] and subsequently extended with message authentication codes in [11], the most recent extension of the library further incorporated symmetric encryption [8] which constitutes the most commonly used cryptographic primitive in the typical proofs with Dolev-Yao models, and also serves as the central primitive for expressing and analyzing the Otway-Rees protocol. However, as shown in [8], there are intrinsic difficulties in providing a sound abstraction from symmetric encryption in the strong sense of security used in [10]. Very roughly, a sound Dolev-Yao-style abstraction of symmetric encryption can only be established if a so-called commitment problem does not occur, which means that whenever a key that is not known to the adversary is used for encryption by an honest user then this key will never be revealed to the adversary. We will elaborate on the origin of this problem in more detail in the paper. While [8] discusses several solutions to this problem, the one actually taken is to leave it to the surrounding protocol to guarantee that the commitment problem does not occur, i.e., if a protocol that uses symmetric

2 A violation of this consistency property has been pointed out in [28] which arises due to a different modeling of the trusted third party. We will discuss this in the following.

encryption should be faithfully analyzed, it additionally has to be shown that the protocol guarantees that keys are no longer sent in a form that might make them known to the adversary once an honest participant has started using them. Our proof shows that this is a manageable task that can easily be incorporated in the overall security proof without imposing a major additional burden on the prover.

Once we have shown that the Otway-Rees protocol does not raise the commitment problem, we prove the security of the Otway-Rees protocol based on the deterministic abstraction. In combination with a recent result on linking symbolic and cryptographic key secrecy [9], this allows us to perform a symbolic proof of secrecy for the Otway-Rees protocol and to derive the desired cryptographic key secrecy from that. Similarly, we establish the consistency property based on the abstraction and exploit a general integrity preservation theorem [6] to derive the consistency property for the cryptographic setting. As the proof is deterministic and rigorous, it should be easily expressible in formal proof tools, in particular theorem provers. Even done by hand, our proof is much less prone to error than a reduction proof conducted from scratch in the cryptographic approach. We also want to point out that our result not only provides the up-to-now missing cryptographic security proof of the Otway-Rees protocol, but also exemplifies the usefulness of the cryptographic library [10], their extensions [11,8], and the corresponding general theorems for linking symbolic and cryptographic properties based on this library [6,9] for the cryptographically sound verification of cryptographic protocols.

Further Related Work.

Cryptographic underpinnings of a Dolev-Yao model were first addressed by Abadi and Rogaway in [3]. However, they only handled passive adversaries and symmetric encryption. The protocol language and security properties handled were extended in [2,30], but still only for passive adversaries. This excludes most of the typical ways of attacking protocols, e.g., man-in-the-middle attacks and attacks by reusing a message part in a different place or a concurrent protocol run. A full cryptographic justification for a Dolev-Yao model, i.e., for arbitrary active attacks and within arbitrary surrounding interactive protocols, was first given recently in [10] with extensions in [11,8]. Based on the specific Dolev-Yao model whose soundness was proven in [10], the well-known Needham-Schroeder-Lowe protocol was proved in [7] and a variant of the 3KP payment protocol was proved in [5]. Besides the proof that we present in this paper, the proof in [7,5] are the only Dolev-Yao-style, computationally sound proof that we are aware of. However, they are considerably simpler than the one we present in this work since it only addresses integrity

properties whereas our proof additionally establishes confidentiality properties; moreover, the Needham-Schroeder-Lowe protocol and the 3KP protocol do not use symmetric encryption, hence the commitment problem does not occur there which greatly simplifies the proof. Another cryptographically sound proof of the Needham-Schroeder-Lowe protocol was concurrently developed by Warinschi [45]. The proof is conducted from scratch in the cryptographic approach which takes it out of the scope of formal proof tools.

Laud [31] has recently presented a cryptographic underpinning for a Dolev-Yao model of symmetric encryption under active attacks. His work enjoys a direct connection with a formal proof tool, but it is specific to certain confidentiality properties, restricts the surrounding protocols to straight-line programs in a specific language, and does not address a connection to the remaining primitives of the Dolev-Yao model. Herzog et al. [26] and Micciancio and Warinschi [34] have recently also given a cryptographic underpinning under active attacks. Their results are narrower than that in [10] since they are specific for public-key encryption, but consider slightly simpler real implementations; moreover, the former relies on a stronger assumption whereas the latter severely restricts the classes of protocols and protocol properties that can be analyzed using this primitive. Section 6 of [34] further points out several possible extensions of their work which all already exist in the earlier work of [10]. Canetti and Herzog [19] have recently linked ideal functionalities for mutual authentication and key exchange protocols to corresponding representations in a formal language. They apply their techniques to the Needham-Schroeder-Lowe protocol by considering the exchanged nonces as secret keys. Their work is restricted to the mentioned functionalities and in contrast to the cryptographic library [10] hence does not address soundness of Dolev-Yao models in their usual generality. The considered language does not allow loops and offers public-key encryption as the only cryptographic operation. Moreover, their approach to define a mapping between ideal and real traces following the ideas of [34] only captures trace-based properties (i.e., integrity properties); reasoning about secrecy properties additionally requires ad-hoc and functionality-specific arguments.

Efforts are also under way to formulate syntactic calculi for dealing with probabilism and polynomial-time considerations, in particular [36,32,37,27] and, as a second step, to encode them into proof tools. This approach can not yet handle protocols with any degree of automation. It is complementary to the approach of proving simple deterministic abstractions of cryptography and working with those wherever cryptography is only used in a blackbox way.

Outline.

Section 2 introduces the notation used in the paper and briefly reviews the aforementioned cryptographic library. Section 3 shows how to model the Otway-Rees protocol based on this library as well as how initially shared keys can be represented in the underlying model. Section 4 contains the symbolic and cryptographic security properties of the Otway-Rees protocol. The symbolic property is proven in Section 5, and Section 6 shows how to derive the cryptographic property for the cryptographic implementation of the protocol. Section 7 concludes.

2 Preliminaries

In this section, we give an overview of the ideal cryptographic library of [10,11,8] and briefly sketch its provably secure implementation. We start by introducing the notation used in this paper.

2.1 Notation

Let | denote an error element available as an addition to the domains and ranges of all functions and algorithms. The list operation is denoted as l := (x1,...,Xj), and the arguments are unambiguously retrievable as l[i], with l[i] = | if i > j. A database D is a set of functions, called entries, each over a finite domain called attributes. For an entry x E D, the value at an attribute att is written x.att. For a predicate pred involving attributes, D[pred] means the subset of entries whose attributes fulfill pred. If D[pred] contains only one element, we use the same notation for this element.

2.2 Overview of the Ideal and Real Cryptographic Library

The ideal (abstract) cryptographic library of [10,11,8] offers its users abstract cryptographic operations, such as commands to encrypt or decrypt a message, to make or test a signature, and to generate a nonce. All these commands have a simple, deterministic semantics. To allow a reactive scenario, this semantics is based on state, e.g., of who already knows which terms; the state is represented as a database. Each entry has a type (e.g., "ciphertext"), and pointers to its arguments (e.g., a key and a message). Further, each entry contains handles for those participants who already know it. A send operation makes an entry known to other participants, i.e., it adds handles to the entry. The ideal cryptographic library does not allow cheating. For instance, if it receives a command to encrypt a message m with a certain key, it simply makes an abstract database entry for the ciphertext. Another user can only

ask for decryption of this ciphertext if he has obtained handles to both the ciphertext and the secret key.

To allow for the proof of cryptographic faithfulness, the library is based on a detailed model of asynchronous reactive systems introduced in [42] and represented as a deterministic machine THH, called trusted host. The parameter H Q {1 ..., n} denotes the honest participants, where n is a parameter of the library denoting the overall number of participants. Depending on the considered set H, the trusted host offers slightly extended capabilities for the adversary. However, for current purposes, the trusted host can be seen as a slightly modified Dolev-Yao model together with a network and intruder model, similar to "the CSP Dolev-Yao model" or "the inductive-approach Dolev-Yao model".

The real cryptographic library offers its users the same commands as the ideal one, i.e., honest users operate on cryptographic objects via handles. The objects are now real cryptographic keys, ciphertexts, etc., handled by real distributed machines. Sending a term on an insecure channel releases the actual bitstring to the adversary, who can do with it what he likes. The adversary can also insert arbitrary bitstrings on non-authentic channels. The implementation of the commands is based on arbitrary secure encryption and signature systems according to standard cryptographic definitions, with certain additions like type tagging and additional randomizations.

The security proof of [10] states that the real library is at least as secure as the ideal library. This is captured using the notion of reactive simulata-bility [42,13], which states that whatever an adversary can achieve in the real implementation, another adversary can achieve given the ideal library, or otherwise the underlying cryptography can be broken. This is the strongest possible cryptographic relationship between a real and an ideal system. In particular it covers arbitrary active attacks. Moreover, a composition theorem exists in the underlying model [42,12], which states that one can securely replace the ideal library in larger systems with the real library, i.e., without destroying the already established simulatability relation.

2.3 Detailed Description of the State of the Cryptographic Library

We conclude this section with the rigorous definition of the state of the ideal cryptographic library. A rigorous definition of the commands of the ideal library used for modeling the Otway-Rees protocol as well as local adversary commands that model the slightly extended adversary capabilities can be found in [10,8].

The machine THH has ports inu? and outu! for inputs from and outputs to each user u E H and for u = a, denoting the adversary. The notation

follows the CSP convention, e.g., the cryptographic library obtains messages at inu? that have been output at inu!. Besides the number n of users, the ideal cryptographic library is parameterized by a tuple L of length functions which are used to calculate the "length" of an abstract entry, corresponding to the length of the corresponding bitstring in the real implementation. Moreover, L contains bounds on the message lengths and the number of accepted inputs at each port. These bounds can be arbitrarily large, but have to be polynomially bounded in the security parameter.

Using the notation of [10], the ideal cryptographic library is a system Systhat consists of several structures ({THH}, SH), one for each value of the parameter H. Each structure consists of a set of machines, here only containing the single machine THH, and a set SH := {inu?, outu! | u E H} denoting those ports of THH that the honest users connect to. Formally, we obtain Sys nL'd := {({THh}, Sh) |HC{1,..., n}}. In the following, we omit the parameters n and L for simplicity.3

The main data structure of THH is a database D. The entries of D are abstract representations of the data produced during a system run, together with the information on who knows these data. Each entry in D is of the form (recall the notation in Section 2.1)

(ind, type, arg, hndui,..., hndUm, hnda, len) where H = {u1,..., um}. For each entry x E D:

• x.ind E INDS, called index, consecutively numbers all entries in D. The set INDS is isomorphic to N and is used to distinguish index arguments from others. The index is used as a primary key attribute of the database, i.e., we write D[i] for the selection D[md = i].

• x.type E typeset identifies the type of x.

• xx.arg = (a1, a2,..., aj) is a possibly empty list of arguments. Many values a are indices of other entries in D and thus in INDS. We sometimes distinguish them by a superscript "ind".

• xx.hndu E HNDS U {j} for u E H U {a} are handles by which a user or adversary u knows this entry. xx.hndu = j means that u does not know this entry. The set HNDS is yet another set isomorphic to N. We always use a superscript "hnd" for handles.

• x.len E No denotes the "length" of the entry; it is computed by applying the functions from L.

3 Formally, these parameters are thus also parameters of the ideal Otway-Rees system SysOR'id that we introduce in Section 3.2.

Initially, D is empty. THH has a counter size E INDS for the current size of D. For the handle attributes, it has counters curhndu (current handle) initialized with 0.

3 The Otway-Rees Protocol

The Otway-Rees protocol [39] is a four-step protocol for establishing a shared secret encryption key between two users. The protocol relies on a distinguished trusted third party T, i.e., T 0 {1,... ,n}, and it is assumed that every user u initially shares a secret key Kut with T. Expressed in the typical protocol notation, the Otway-Rees protocol works as follows.4

1. u ^ v : M, (Nu,M,u,v)Kut

2. v ^ T : M, (Nu, M, u, v)ku, , (N, M, u, v

3. T ^ v : M, (Nu, KuV)ku4 , (Nv, Kuv)kv<

4. v ^ u : M, (Nu, Kuv)Kut.

3.1 Capturing Distributed Keys in the Abstract Library

In order to capture that keys shared between users and the trusted third party have already been generated and distributed, we assume that suitable entries for the keys already exist in the database. We denote the handle of u to the secret key shared with v, where either u E {1,..., n} and v = T or vice versa, as skseUV,. More formally, we start with an initially empty database D, and for each user u E H two entries of the following form are added (the first one being a public-key identifier for the actual secret key as described below in more detail):

(ind := pkseu, type := pkse, arg := (), len := 0);

(ind := skseu, type := skse, arg := (ind — 1),

hndu := skse^j, hndj := sfcseT11^, len := skseJen*(k)).

Here pkseu and skseu are two consecutive natural numbers; treating public-key identifiers as being of length 0 is a technicality in the proof of [8], and skseJen*(A") denotes the abstract length of the secret key. These lengths will not matter in the following.

The first entry has to be incorporated in order to reflect special capabilities that the adversary may have with respect to symmetric encryption schemes in the real world. For instance it must be possible for an adversary against the

4 For simplicity, we omit the explicit inclusion of u and v in the unencrypted part of the

first and second message since the cryptographic library already provides the identity of the

(claimed) sender of a message, which is sufficient for our purpose.

ideal library to check whether encryptions have been created with the same secret key since the definition of symmetric encryption schemes does not exclude this and it can hence happen in the real system. For public-key encryption, this was achieved in [10] by tagging ciphertexts with the corresponding public key so that the public keys can be compared. For symmetric encryption, this is not possible as no public key exists, hence this problem is solved by tagging abstract ciphertexts with an otherwise meaningless "public key" solely used as an identifier for the secret key. Note that the argument of a secret key points to its key identifier. In the following, public-key identifiers will not matter any further.

We omit the details of how these entries for user u are added by a command gen_symenc_key, followed by a command sencLs for sending the secret key over a secure channel.

3.2 The Otway-Rees Protocol Using the Abstract Library

We now model the Otway-Rees protocol in the framework of [42] and using the ideal cryptographic library.

For each user u E {1,... ,n} we define a machine M°R, called a protocol machine, which executes the protocol sketched above for participant identity ■u. It is connected to its user via ports KS_outJ, KS_inu? ("KS" for "Key Sharing") and to the cryptographic library via ports inu!, outu?. We further model the trusted third party as a machine M°R. It does not connect to any users and is connected to the cryptographic library via ports inT!, outT?. The combination of the protocol machines M°R, the trusted third party M°R, and the trusted host THH is the ideal Otway-Rees system SysOR''d. It is shown in Figure 1; H and A model the arbitrary joint honest users and the adversary, respectively.

Using the notation of [10], we have SysOR,'d := {(Mh, Sh) | H C {1,..., n}}, cf. the definition of the ideal cryptographic library in Section 2.3, where Mn := {THW}U{M°R | u G mj{T}} and Sn := {KS.inJ?, KS.outJ | u G H}, i.e., for a given set H of honest users, only the protocol machines M°R with u E H are actually present in a protocol run. The others are subsumed in the adversary.

The state of the protocol machine M°R consists of the bitstring u and a set Nonceu of pairs of the form (nhnd, mhnd, v,j), where nhnd, mhnd are handles, v E {1,...,n}, and j E {1, 2, 3,4}. Intuitively, a pair (nhnd, mhnd ,v,j) states that M°R generated the handle nhnd in the j-th step of the protocol in a session run with v and session identifier mhnd. The set Nonceu is initially empty. The trusted third party M°R maintains an initially empty set SIDT to store already processed session IDs.

cry,id

KS _outu? KS_ n„! KS_outv? KS_ inv!

i i k

> >

KS _outu! KS_inu? KS _outv! KS_inv?

MOR MOR

u v

outu? in u! outv? in v!

I J k

outu! inu? outv! inv? outT! inT?

Fig. 1. Overview of the Otway-Rees Ideal System.

We now define how the protocol machine M°R evaluates inputs. They either come from user u at port KS_inu? or from TH^ at port out,/?. The behavior of M°R in both cases is described in Algorithm 1 and 3 respectively, which we will describe below. The trusted third party M°R only receives inputs from the cryptographic library, and its behavior is described in Algorithm 2. We refer to Step i of Algorithm j as Step j.i. All three algorithms should immediately abort if a command to the cryptographic library does not yield the desired result, e.g., if a decryption requests fails. For readability we omit these abort checks in the algorithm descriptions; instead we impose the following convention on all three algorithms.

Convention 1 For all w E {1,...,n} U {T} the following holds. If M°R enters a command at port inw! and receives j at port outw? as the immediate answer of the cryptographic library, then M°R aborts the execution of the current algorithm, except if the command ■was of the form list_proj orsencLi.

Protocol start.

The user of the protocol machine M°R can start a new protocol with user v E {1,..., n} \ {«} by inputting (new_prot, Otway_Rees, v) at port KS_in„?. Our security proof holds for all adversaries and all honest users, i.e., especially those that start protocols with the adversary (respectively a malicious user) in parallel with protocols with honest users. Upon such an input, M°R builds up the term corresponding to the first protocol message using the ideal cryptographic library according to Algorithm 1. The command gen_nonce generates the ideal nonce as well as the session identifier. M°R stores the resulting handles nUnd and mhnd in Nonceu for future comparison together with the identity of v and an indicator that these handles were generated in the first step of the

Algorithm 1. Evaluation of Inputs from the User (Protocol Start) Input: (new.prot, Otway_Rees, v) at KS_inu? with »6{l,...,n) \ {u}. 1: n„nd <— gen_nonce(). 2: IDhnd <— gen_nonce().

3: Nonceu := Nonceu U {(nhund, IDhnd ,v,l)}.

4: uhnd — store(u).

5: vhnd — store(v).

6: /5nd — list(nUnd,IDhnd,uhnd,vhnd).

7: c5nd <- sym_encrypt(sfcse^,/ind).

8: m5nd — list(IDhnd,c5nd).

9: sendJ(-y,rri5nd).

protocol. The command store inputs arbitrary application data into the cryptographic library, here the user identities u and v. The command list forms a list and sym_encrypt is symmetric encryption. The final command sencLi means that M°R sends the resulting term to v over an insecure channel. The effect is that the adversary obtains a handle to the term and can decide what to do with it (such as forwarding it to M°R).

Algorithm 2. Behavior of the Trusted Third Party Input: (v,T, i,mhnd) at outT? with v e {1,.. . ,n}.

20 21 22

IDhna <- list_proj(mhnd,l). type-1 <- get_type(/JDhnd). c(3)hnd Nst_proj(mhnd,3).

sym_decrypt(sfcsej"d, c' > ). yi"A <- list_proj(/(3)l"'d,i) for ¿ = 1,2,3,4. yt — retrieve (ythnd) for i = 3,4.

if (IDhnd e SIDt) V (type! = nonce) V (y2nd = IDhnd) V (y3 £ {1,

Abort end if

SIDt := SIDT U {IDhnd}. A2)1""1 <- Nst.proj(mhnd,2).

sym_decrypt(sfcsej"d3, c^"*). xTA list_proj(/(2)l"'d,i) for i= 1,2,3,4. type2 <- get.type (a;5"d). xt — retrieve (xhnd) for i = 3,4.

if (type2 = nonce) V (x2nd = yhnd) V (x3 = y3) V (x4 = y4) then

end if

sksehl

,(2)hnd to

/(2) — :

„hnd genjymenc^eyQ,

——

Cg2' «— sym_encrypt(sfcsej"d3, )

list(x5nd,sfcsehnd)

43)" — list(yhnd, sksehnd) „(3)h '

■ sym_encrypt(sfcsej"d,

{IDhnd « M}

{c(3)hnd ,M,u,v}Kvt}

{/(3)hnd ,M,u,v}}

..,n} \ {v}) V (y4 = v) then

{c(2) ^{Nu,M,u,v }Kut} {/(2)h"d « {Nu,M,u, v}}

{sksehnd « Kuv }

{l32) ~{Nu,K„„}}

{c32) ~{N„,K„„ }Kut} i£)h

{/^ ~{Nv ,Kuv }} {Nv ,Kuv }Kvt }

m3nd —

send J(v, nig"'

list(ID

hnd c(2)hl

{m3nd « M, {Nu, K„v }Kut, {Nv, K„v }K„t}

Evaluation of network inputs for protocol machines.

The behavior of the protocol machine M°R upon receiving an input from the cryptographic library at port outu ? (corresponding to a message that arrives over the network) is defined similarly in Algorithm 3. By construction of THH, such an input is always of the form (v, u, i, mhnd) where mhnd is a handle to a list. To increase readability, and to clarify the connection between the algorithmic description and the usual protocol notation, we augment the algorithm with explanatory comments at its right-hand side to depict which handle corresponds to which Dolev-Yao term. We further use the naming convention that ingoing and outgoing messages are labeled m, where outgoing messages have an additional subscript corresponding to the protocol step. Encryptions are labeled c, the encrypted lists are labeled l, both with suitable sub- and superscripts.

M°R first determines the session identifier and aborts if it is not of type nonce. M°R then checks if the obtained message could correspond to the first, third, or fourth step of the protocol. (Recall that the second step is only performed by T.) This is implemented by looking up the session identifier in the set Nonceu. After that, M°R checks if the obtained message is indeed a suitably constructed message for the particular step and the particular session ID by exploiting the contents of Nonceu. If so, M°R constructs a message according to the protocol description, sends it to the intended recipient, updates the set Nonceu, and possibly signals to its user that a key has been successfully shared with another user.

Behavior of the trusted third party.

The behavior of M^R upon receiving an input (v, T, i, mhnd) from the cryptographic library at port outT? is defined similarly in Algorithm 2. We omit an informal description.

3.3 On Polynomial Runtime

In order to use existing composition results of the underlying model, the protocol machines M°R and M^R must be polynomial-time. Similar to the cryptographic library, we define that each of these machines maintains explicit polynomial bounds on the message lengths and the number of inputs accepted at each port.

Algorithm 3. Evaluation of Inputs from THh (Network Inputs) Input: (v,u, i,mhnd) at outu? with v G {1,... ,n} \ {u}. 1

10 11 12

20 21 22

IDhnd <- Mst_proj(ï77hnd, 1). {IDhnd Ri AI}

typeJ <- get_type(/JDhnd). if typej = nonce then

Abort end if

if v = T AVj,nhnd : (nhnd, IDhnd ,v, j)} £ Nonceu then {First Message is input}

c(2)hnd Nst.proj(777hnd,2). {c<2>hnd « (N„,M,v,u)Kvt}

nu"d gen_nonce().

Nonceu := Nonceu u {(nhund, IDhnd, v, 2)}. uhnd ^ store(u). vhnd ^ store(v).

/23)hnd ^ list(nUnd, ID hnd,vhnd,uhnd). {/23)hnd - Nu, M ,v, u}

43) ^sym.encrypt(skse^J{2S) ). {c{23) f» (Nu, AI, v, u)Kut}

m2nd ^ list(IDhnd ,c(2)hnd ,c23)hnd). {m2nd - M, (N„ ,M,v,u)Kvt, (Nu, M,v,u)xut}

send _i(T, ni2nd). else if v = T then {Third Message is input}

c(2)hnd Nst.proj(»77hnd,2). {c<2>hnd Ri (Nv,Kuv)Kvt}

C(3)hnd <- liSt.proj(»77hnd,3). {c(3)hnd Ri (Nu,Kuv)Kut}

/(3)""a ^ sym_decrypt(sfcseJ,"j,c(3) ). {/<3)"nd « NU,KUV}

y\nd list_proj(/(3) " ,i) for i = 1,2. type2 <- get_type(j/2nd).

if (¡B!w e {1,.. . ,n} \ {u}: (y hnd, ID hnd,w, 2) e Nonce u) V (type 2 = skse) then

Abort end if

Nonceu := (Nonceu \ {(y fnd, IDhnd, w, 2)}) U {(y fnd, IDhnd, w, 3)}.

m4nd ^ list(IDhnd ,c(2)hnd). {m4nd - M, {N ,KUV }xvt}

send J(-ii), 7774nd).

Output (ok_responder,Otway_Rees,ii),/L»hnd,j/2nd) at KS.out,,!. else if v = T A3!nhnd : (nhnd, IDhnd,v, 1) then {Fourth Message is input}

c<2>hnd ^ Nst_proj(777h"d,2). {c<2)hnd « {Nu,Kuv}Klit}

/(2)h"d ^ Sym.decrypt(Sfc<dT,c(2)hnd). {/<2>hnd « {NU,KUV}}

xhind Nst_proj(/^2^llnd, i) for i = 1,2.

type3 <- get_type(:i'2nd).

if x5nd = nhnd V type 3 = skse then

Abort end if

Nonceu := (Nonceu \ {(xhnd, IDhnd, v, 1)}) U {(xhnd, IDhnd, v, 4)}. Output (ok_initiator,Otway_Rees,v, IDhnd ,xh2nd) at KS.outJ. else

Abort end if

4 The Security Property

In the following, we formalize the security property of the ideal and real Otway-Rees protocols. The property consists of a key secrecy property and a consistency property. We first formalize the ideal key secrecy property which is an instantiation of a general key secrecy definition for arbitrary protocols based on the ideal cryptographic library. It was introduced in [9] and is symbolic,

based on the typical notion that a term is not an element of the adversary's knowledge set. In the given Dolev-Yao-style library, the adversary's knowledge set is the set of all terms to which the adversary has a handle. After that we introduce the notion of cryptographic, real-or-random key secrecy based on the real cryptographic library. Finally, we express the consistency property, and we distinguish perfect and computational fulfillment of the property.

4-1 Definition of the Key Secrecy Property

The first step towards defining symbolic key secrecy is to consider one state of the ideal Dolev-Yao-style library and to define that a handle points to a symmetric key, that the key is symbolically unknown to the adversary, and that it has not been used for encryption. These are the symbolic conditions under which we can hope to prove that the corresponding real key is indistinguishable from a fresh random key for the adversary. Note that the operations that the Otway-Rees protocol performs on new keys are allowed in this sense. For Condition (3) in the definition, note that the arguments of a ciphertext term are (I, pk) where l is the plaintext index and pk the index of the public tag of the secret key, with pk = sk — 1 for the secret key index.

Definition 4.1 (Symbolically Secret Encryption Keys [9]) Let {T} C H C {1,... ,n, T}, a database state D of THH, and a pair (u, lhnd) E H x HNDS of a user and a handle be given. Let i := D[hndu = lhnd].ind be the corresponding database index. The term under (u, lhnd) (1) is a symmetric encryption key iff D[i].type = skse, (2) is symbolically unknown (to the adversary) iff D[i].hnda = I, (3) has not been used for encryption, or short is unused, iff for all indices j E N we have D[j].type = symenc ^ D[j].arg[2] = i — 1, and (4) is a symbolically secret key iff it has the three previous properties.

A secret-key belief function is a general way to designate the keys whose secrecy should be proved. The underlying theory from [9] is based on such functions. We instantiate them for the Otway-Rees protocol and thus essentially for all individual key exchange protocols. A secret key belief function maps the user view to a set of triples (u,lhnd,t) of a user, a handle, and a type, pointing to the supposedly secret keys. For the Otway-Rees protocol, we define secret-key belief functions seckeys_initiator_OR for the initiator and seckeys_responder_OR for the responder that designate the exchanged keys.

Definition 4.2 (Secret-key Belief Functions for the Otway-Rees Protocol) A secret-key belief function for a set H is a function seckeys that maps each view view of the user to an element of (H x HNDS x {skse})*.

The secret-key belief functions seckeys_initiator_OR and seckeys_responder_OR of the Otway-Rees protocol map each

element (ok_initiator, Otway_Rees, v, IDhnd, sksehnd) respectively

(ok_responder, Otway_Rees, v, IDbnd, sksehr[d) of view arriving at port KE_out„? in the users view to (u, sksehnd, skse) if u G H, and to e otherwise. Elements of view that are not of this form are also mapped to e.

We now define symbolic key secrecy for such a function. In addition to the conditions for individual keys, we require that all elements point to different terms, so that we can expect the corresponding list of cryptographic keys to be entirely random.

Definition 4.3 (Symbolic Key Secrecy Generally and for the Otway-Rees Protocol) Let a user H suitable for a structure ({THH}, SH) of the cryptographic library Syscry'ld and a secret-key belief function seckeys for H be given. The ideal cryptographic library with this user keeps the keys in seckeys strictly symbolically secret iff for all configurations conf = ({THH}, SH, H, A) of this structure, every v G viewconf (H), and every element (u^, 1^hnd, ti) of the set seckeys(v), the term under (ui,lihnd) is a symbolically secret key of type ti, and D[hndUi = hhnd].ind = D[hndUj = jhnd].ind for all i = j.

The ideal Otway-Rees protocol keeps the exchanged keys of honest users strictly symbolically secret iff the ideal cryptographic library keeps the keys in seckeys_initiator_OR and seckeys_responder_OR strictly symbolically secret with all users H* that are the combination of the machines M°R for u G H and a user H of those machines.

General cryptographic key secrecy requires that no polynomial-time adversary can distinguish the keys designated by the function seckeys from fresh keys. The cryptographic key secrecy of the Otway-Rees protocol is the instantiation for seckeys_initiator_OR and seckeys_responder_OR and the configurations of the Otway-Rees protocol.

Definition 4.4 (Cryptographic (Real-or-random) Key Secrecy Generally and for the Otway-Rees Protocol) Let a polynomial-time configuration conf = (MH, SH, H, A) of the real cryptographic library Sys SI'"33' and a secret-key belief function seckeys for H be given. Let genSE denote the key generation algorithm. This configuration keeps the keys in seckeys cryptographically secret iff for all probabilistic-polynomial time algorithms Dis (the distinguisher), we have

|Pr[Dis(1k, va, keysreai) = 1] - Pr[Dis(1k, va, keyset) = 1]| G NEGL

where NEGL denotes the negligible function of the security parameter k and the used random variables are defined as follows: For r G runconf, let va := viewconf (A)(r) be the view of the adversary, let (ui, /ihnd, ti)i=i'...'„ :=

seckeys(viewconf (H)(r)) be the user-handle-type triples of presumably secret keys, and let the keys be keysreai := (ski)i=1,..,n with

ski := DUt[hnd„t = hhnd].word if DUt[hndUt = /¿hnd].type = ti, else e; and keysfresh := (ski/)i=1j...j„ with sk/ ^ genA(1k) if ti = ska, else sk!l ^ e.

A polynomial-time configuration (MH U (M°R | u G H}, SH, H, A) of the real Otway-Rees protocol SysOR,real keeps the exchanged keys of honest users cryptographically secret iff the configuration (MH, SH, {H}U{M°R | u G H}, A) keeps the keys in seckeys_initiator_OR and seckeys_responder_OR cryptographically secret.

4-2 Definition of the Consistency Property

The consistency property states that if two honest users establish a session key then both need to have a consistent view of who the peers to the session are, i.e., if an honest user u establishes a key with v, and v establishes the same key with another user w, then u has to equal w. Moreover, we incorporate the correctness of the protocol into the consistency property, i.e., if the aforementioned outputs occur and u = w holds, then both parties have obtained the same key.5 In the following definitions, we write t : D to denote the contents of database D at time t, and t : p?m and t : p!m to denote that message m occurs at input port respectively output port p at time t.

The consistency property ReqCons is formally captured as follows: Assume that outputs (okJnitiator, Otway_Rees, v, IDhu"d, skseuhnd) and (ok_responder, Otway_Rees, w, IDbLnd, sksevhnd) occur at KS_outJ respectively at KS-OutJ at arbitrary times t\ and for honest users u and v such that the session identifiers are the same, i.e., t1 : D[hndu = IDUnd] = t2 : D[hndv = IDVnd]. Then the handles skseuhnd and sksevhnd point to the same entry in the database, i.e., t1 : D[hndu = skseuhnd] = t2 : D[hndv = sksevhnd] if and only if u = w. The formal definition of ReqCons is given in Figure 2.

Note that the consistency property ReqCons specifically relies on the state of THH, hence it cannot be used as is to capture the security of the real Otway-Rees system, where THH is replaced with the secure implementation of the cryptographic library. The corresponding consistency property Reqfor the real Otway-Rees system can be defined by requiring that both handles point to the same bitstring, i.e., by replacing t1 : D[hndu = skseuhnd] = t2 : D[hndv = sksevhnd with t1 : Du[hndu = skseuhnd].word = t2 : Dv[hndv = sksevhnd].word

5 A violation of this correctness aspect has been pointed out in [28] which arises since in their modeling the trusted third party creates multiple keys if it is repeatedly triggered with the same message. We explicitly excluded this in our definition of the trusted third party by storing the session IDs processed so far, cf. Step 7 and 10 in Algorithm 2.

Vu,v e H, Vt1,t2 e N: # For all honest users u and v:

t\ : KS_out„!(okJnitiator, Otway.Rees, v, IDh"d, skseuhnd) A # if u. shares a key with v

¿2 : KS_out„!(ok_responder, Otway_Rees, w, IDh"d, sksevhnd) A # and v shares a key with w

t 1 : D[hndu = IDUnd] = t2 : D[hndv = IDVnd] # and the sessions are equal

^ (u = w ^ # then u is equal to w iff

t 1 : D[hndu = skseuhnd] = t2 : D[hndv = sksevhnd]) # both keys are equal.

Fig. 2. The Consistency Property ReqCons.

for the databases Du and Dv of the real library.

The notion of a system Sys fulfilling such a property Req essentially comes in two flavors [6]. Perfect fulfillment, Sys |=perf Req, means that the property holds with probability one (over the probability spaces of runs, a well-defined notion from the underlying model [42]) for all honest users and for all adversaries. Computational fulfillment, Sys =poly Req, means that the property only holds for polynomially bounded users and adversaries, and only with negligible error probability. Perfect fulfillment implies computational fulfillment.

The following theorem captures the security of the Otway-Rees protocol.

Theorem 4.5 (Security of the Otway-Rees Protocol) Let SysOR'ld and SysOR,real be the ideal and real Otway-Rees system, respectively, as defined in Section 3.2. Then we have:

• Secrecy: SysOR'ld keeps the exchanged keys of honest users strictly symbolically secret, and all polynomial-time configurations of SysOR,real keep the exchanged keys of honest users cryptographically secret.

• Consistency: SysOR'ld perfectly fulfills the consistency property ReqCons, and SysOR,real computationally fulfills the consistency property Req^0^, i.e., SysOR'ld =perf ReqCons A SysOR'real =poly ReqCe7.

5 Proof in the Ideal Setting

This section contains the proof of the ideal part of Theorem 4.5, i.e., the proof of the Otway-Rees protocol using the ideal, deterministic cryptographic library. The proof idea is the following: If an honest user u successfully terminates a session run with another honest user v, then we first show that the established key has been created before by the trusted third party. After that, we exploit that the trusted third party as well as all honest users may only send this key within an encryption generated with a key shared between u and T respectively v and T, and we conclude that the adversary hence never gets a handle to the key. The main challenge was to find suitable invariants on the state of the ideal Otway-Rees system. This is somewhat similar to formal

proofs using the Dolev-Yao model, and the similarity supports our hope that the new, sound cryptographic library can be used in the place of the Dolev-Yao models in automated tools. The proof of the invariants is postponed to Appendix A.

5.1 Invariants

The first invariants, correct nonce owner and unique nonce use, are easily proved and essentially state that handles xhnd where (xhnd, ■, ■, ■) is contained in a set Nonceu indeed point to entries of type nonce, and that no nonce is in two such sets. The next two invariants, nonce secrecy and nonce-list secrecy, deal with the secrecy of certain terms. They are mainly needed to prove the invariant correct list generation, which establishes who created certain terms. The last invariant, key secrecy, states that the adversary never learns keys created by the trusted third party for use between honest users.

• Correct Nonce Owner. For all u G H, and for all (xhnd, ■, ■, ■) G Nonceu, it holds D[hndu = xhnd] = j and D[hndu = xhnd].type = nonce.

• Unique Nonce Use. For all u,v G H, all w,w' G {1, ...,n}, and all j < size: If (D[j].hndu, ■, w, ■) G Nonceu and (D[j].hndv, ■, w', ■) G Noncev, then (u, w) = (v, w').

Nonce secrecy states that the nonces exchanged between honest users u and v remain secret from all other users and from the adversary. For the formal-ization, note that the handles xhnd to these nonces are contained as elements (xhnd,-,v, ■) in the set Nonceu. The claim is that the other users and the adversary have no handles to such a nonce in the database D of THH:

• Nonce Secrecy. For all u, v e H and for all j < size: If (D[j].hndu, ■, v, ■) G Nonceu then D[j].hndw = j implies w G {u, v, T}. In particular, this means D [j ]. hnd a = j.

Similarly, the invariant nonce-list secrecy states that a list containing such a handle can only be known to u, v, and T. Further, it states that the identity fields in such lists are correct. Moreover, if such a list is an argument of another entry, then this entry is an encryption created with the secret key that either u or v share with T. (Formally this means that this entry is tagged with the corresponding public-key identifier as an abstract argument, cf. Section 3.1.)

• Nonce-List Secrecy. For all u,v G H and for all j < size with D[j].type = list: Let xind := D[j].arg[i] for i = 1, 2, 3,4. If (D[xjnd].hndu, ■, v, l) G Nonceu then

a) D[j].hndw = j implies w G {u, v, T} for l G {1, 2, 3,4}.

b) If l G {1,4} and D[x!nd].type = data, then D[x.|nd].arg = (u) and

D[x]nd].arg = (v).

c) If l G {2,3} and D[x3nd].type = data, then D[x^nd].arg = (v) and D[x]nd].arg = (u).

d) for l G {1, 2,3,4} and for all k < size it holds j G D[k].arg only if D[k].type = symenc and D[k].arg[1] G {pkseu,pksev}.

The invariant correct list owner states that certain protocol messages can only be constructed by the "intended" users respectively by the trusted third party.

• Correct List Owner. For all u,v G H and for all j < size with D[j].type = list: Let xind := D[j].arg[i] for i = 1, 2 and xhnud := D[x'1nd].hndu.

a) If (xhnd, -,v,l) G Nonceu and D[x2nd].type = skse, then D[j] was created by MOR in Step 1.6 if l = 1 and in Step 3.12 if l = 2.

b) If (xhnud, IDund,v,l) G Nonceu and D[x^nd].type = skse, then D[j] was created by MOR in Step 2.22 if l = 3 and in Step 2.20 if l = 4. Moreover, we have D[hndu = IDund] = D[hndj = IDTnd], where IDTnd denotes the handle that T obtained in Step 2.1 in the same execution.

Finally, the invariant key secrecy states that a secret key entry that has been generated by the trusted third party to be shared between honest users u and v can only be known to u, v, and T. In particular, the adversary will never get a handle to it. This invariant is key for proving the secrecy and the consistency property of the Otway-Rees protocol.

• Key Secrecy. For all u,v G H and for all j < size with D[j].type = skse:

If D[j] was created by M°R in Step 2.19 and, with the notation of Algorithm 2, we have that y3 = u and y4 = v in the current execution of MOR, then D[j].hndw = j implies w G {u,v, T}.

Formally, the invariance of the above statements is captured in the following lemma.

Lemma 5.1 The statements correct nonce owner, unique nonce use, nonce secrecy, nonce-list secrecy, correct list owner, and key secrecy are invariants of SysOR,ld, i.e., they hold at all times in all runs of {M°R | u G H U {T}} U {THH, H, A} for all H Q {1,..., n}, all users H and all adversaries A.

The proof is postponed to Appendix A.

5.2 Proof of the Ideal Part of Theorem 4.5

For the proof of the ideal part of Theorem 4.5, the following property of THh proven in [10] will be useful.

Lemma 5.2 The ideal cryptographic library Syscry'ld has the following property: The only modifications to existing entries x in D are assignments to

previously undefined attributes x.hndu (except for counter updates in entries for signature keys, which we do not have to consider here), and appending new elements to the list of arguments of symmetric encryptions.

Proof. (Theorem 4.5) Assume that M°R outputs (ok_a:, Otway_Rees, v, ID^d,,skse^d) at KS_outJ for x £ {initiator, responder},

u and v £ {1,..., n} at time £3, and set skseInd := D[hnd u = skseUnd ].ind. By definition of Algorithms 1 and 3, this output can only happen in Step 3.28 respectively 3.38, and only after there was an input (v,u, i, mU" ) respectively (v,u, i,mU" ) at outu? at a time £2 < £3. Here and in the sequel we use the notation of Algorithm 1- 3, but we distinguish the variables from its different executions by an additional superscript indicating the number of the (claimed) received protocol message, here 3 and 4, and give handles an additional subscript for their owner, here u.

Case 1: Output in Step 3.28.

Assume that M°R outputs (ok_responder, Otway_Rees, v, IDund ,skseu ) at KS_outJ for u G TL and v e {1,...,??.} in Step 3.28 at time £3. Hence,

(3) 3hnd

the execution of Algorithm 3 for this input must have given lu = j in Step 3.19, since the algorithm would otherwise abort by Convention 1 without creating an output.

Let l(3)'3'nd := D[hndu = l(3)'3 ].ind. The algorithm further implies D[l(3),3'nd].type = list. Let y3'nd := D[l(3),3'nd].arg[i] for i = 1, 2 at the time of Step 3.20. By definition of list_proj and since the condition of Step 3.22 is false, we have

y3u = D[y 3'n ].hndu at time £3, (1)

(y 3,7, IDhnd, v, 3) G Nonceu A D[y3'nd].type = skse at time £3, (2)

(y 37, IDhnd, v, 2) G Nonceu A D[y3'nd].type = skse at time £2. (3)

Case 2: Output in Step 3.38.

This case is similar to the first one: Assume that M°R outputs (okJnitiator, Otway_Rees, v, sk.se4u" ) at KS_out„! for u e H and v E

{1,..., n} in Step 3.38 at time t3. The execution of Algorithm 3 for this

input must have given lu2)'4 = j in Step 3.31, since it would otherwise abort by Convention 1 without creating an output. Let

l(2),4'nd :=

D[hndu = ¿u2)'4 " ] .ind, where the algorithm implies D[l(2)4 ].type = list. Let

x4'nd := D[l(2)'4Ind].arg[i] for i = 1, 2 at the time of Step 3.32. By definition of

list_proj and because of the conditions of Step 3.29 and 3.34, we have

xf: = D[xfnd].hndu at time t3, (4)

(x1h:, IDund, v, 4) G Nonceu A D[x2ind].type = skse at time t3, (5)

(x1hu, IDund, v, 1) G Nonceu A D[x2Ind].type = skse at time t2. (6)

This first part of the proof shows that M°R has received a list corresponding to a third or fourth protocol message. Now we apply correct list owner to the list entry D[l(3)'3'n ] for the first case respectively to D[l(2)'4'n ] for the second case to show that this entry was created by M°R.

Proof. [cont'd] Equations (1) and (2) respectively Equations (4) and (5) are the preconditions for Part b) of correct list owner. Hence the entry D[l(3)'3'n ] was created by M°R in Step 2.20 respectively the entry D[l(2),4'n ] was created by MOR in Step 2.22.

In both cases, the algorithm execution must have started with an input (w, T, i, mT" ) at outT? at a time t1 < t2 with w G {1,..., n}. We conclude

lf2 = j in Step 2.4 because of Convention 1, set l(3)'2'n := D[hndT = lT3)'2 ].ind, and obtain D[l(3)'2'nd].type = list. Correct list owner furthermore implies D[hndt = IDfd] = D[hndu = IDhund]. Let y2'nd := D[l(3)>2'nd].arg[i] for i = 1, 2, 3, 4 at the time of Step 2.5.

As the condition of Step 2.7 is false immediately afterwards, we obtain yf j I for i G {1, 2, 3,4}. The definition of list_proj and Lemma 5.2 imply

y2Td = D[y2'nd].hndt for i G {1, 2, 3, 4} at time t3. (7)

Step 2.7 further ensures yf G {1,..., n} \ {w} and y| = w.

As above, we conclude lT2)'2 = j in Step . , set l(2)>2 := D[hndT =

lT2)'2 ].ind, and obtain D[l(2),2'nd].type = list. Let x2'nd := D[l(2)'2'nd].arg[i] for i = 1, 2, 3,4 at the time of Step 2.13. As the condition of Step 2.16 is false immediately afterwards, we obtain x2T = j for i G {1, 2, 3,4}. The definition of list_proj and Lemma 5.2 again imply

x2T = D[x2'nd].hndt for i G {1, 2, 3, 4} at time t3.

Step 2.16 furthermore ensures x2 = y| and x2 = y|. By definition of the command gen_symenc_key, we obtain sk.sej" ^ | in Step 2.19 and set skse2'nd := D[hndT = skseyhnd].ind.

Now we exploit that MOR creates the entry D[l(3),3'nd] in Step 3.22 with the input list^y", sfcsefnd) respectively the entry D[l(2)4'n ] in Step 2.20 with the input list(;z^T ) skse^"d). With the definitions of list and list_proj, and with Equations (7) and (8), this implies y 2'nd = yfnd and skse'nd = yfnd = y|'nd = skse2'nd respectively x2'nd = x3'nd and skse'nd = x4'nd = x2'nd = skse2'nd. Thus Equations (1) and (3) imply

(y 2>TI, IDund, v, 2) G Nonceu A D[y2'nd].type = skse at time £2 (9) respectively Equations (4) and (6) imply

(x2hud, IDund, v, 1) G Nonceu A D[x2'nd].type = skse at time £2. (10)

We are now ready to show symbolic secrecy of the exchanged keys, i.e., to derive that the terms selected by seckeys_initiator_OR and seckeys_responder_OR are symbolically unused symmetric keys that have furthermore not been used for encryption yet.

Proof. [cont'd, secrecy requirement] With the notation of the previous proof, assume additionally that v gH. Together with Equation 9 and Equation 10, nonce-list secrecy applied to the entry D[l(3),3'n ] respectively D[l(2),4'n ] now immediately implies that {y2,y2} = {u, v} respectively {x2,x4} = {u,v}. This gives the precondition to apply key secrecy to the entry D[skse2'nd], which implies D[skse2'nd].hnda = j. Because of skse2'nd = skse'nd we have D[skse2'nd].hnda = D[skse'nd].hnda = j, i.e., the term under (u,skseund) is symbolically unknown. Moreover Equation 9 and Equation 10 imply D[skse'nd].type = D[skse2'nd].type = skse, i.e., the term under (u, skseund) is a symmetric key.

It remains to show that the key is unused at time t3. The only way to create an entry D[j] with D[j].type = symenc and D[j].arg[2] = skse'nd — 1 is by inputting a command sym_encrypt at port in„,? such that D[skse'nd].hndw ^ j. Since we have shown that D[skse'nd].hndw = j only if w G {u, v, T}, it remains to show that neither of them enters such a command until time t3. By inspection of Algorithm 2, this clearly holds for T, since this may only happen in Steps 2.21 or 2.23. In both cases, the key used is one of those that were initially distributed, i.e., D[j].arg[2] = sksew — 1 for some w e

{1,..., ??.}. Since we have shown that each key selected by seckeys_initiator_OR or seckeys_responder_OR is newly generated by MyR, we in particular have sksew = skse'nd. Similar reasoning can be applied to Algorithm 1 and 3 of M°R to show that the only used keys are the ones shared between u and T respectively between v and T.

It remains to show the consistency requirement ReqSec.

Proof. [cont'd, consistency requirement] Assume that M°R outputs (okJnitiator, Otway_Rees, v, IDbund, sksebund) at KS_outJ at time £3 and that M°R outputs (ok_responder, Otway_Rees, w, IDhL"d, sksehL"d) at KS-OutJ at time t's for u,v G H and w G {1,..., n}, and let t3 : D[hndu = IDund] = t'3 : D[hndv = ID¡hnd ]. We again use the notation of the main proof.

To show the left-to-right direction of the consistency property, assume that u = w. Let skse:= D[hndu = skseund].ind and sksevnd := D[hndv = skseJhnd].ind. Now the main proof immediately yields D[hndu = IDund] = D[hndT = IDThnd] = D[hndv = IDhnd], i.e., both D[skse^d] and D[skseund] have been created in an execution of M T with the same handle IDTnd. Because of the check in Step 2.7 and because of Step 2.10 both entries must have been created in the same execution, which immediately implies t3 : D[hndu = skseund] = t'3 : D[hndv = skse^nd], and we are done.

To show the right-to-left direction, assume that t3 : D[hndu = skseund] = t'3 : D[hndv = skseJhnd] holds. We have already shown that

D[hndu = skseund].hndz = j z G {u, v, T}. (11)

Hence only u, v, and T can get a handle to D[hndv = skse^nd].

We first show that if w also got a handle to D[hndv = skse^nd] then u = w trivially holds. Because of D[hndu = skseund].hndz = j only if z G {u,v, T}, we conclude w G {u,v, T}. Hence it remains to show w G {v, T}. However, the output (ok, Otway_Rees, w, IDbLnd, skseh"d) may only occur if the checks in Step 3.22 or 3.29 succeeded, which ensures that (■, ■, w, ■) G Noncev immediately before time t'3. Consider the first time that an element containing w as its third component was entered into Noncev. This could either happen in Step 1.3 or in Step 3.9. In both cases however, we obtain w G {1,..., n}\ {v} by definition of Algorithm 1 and 3, hence we have u = w as desired.

To conclude the proof, we have to consider those cases where w does not get a handle to D[hndv = skse^nd]. We show that if an honest v outputs (ok, Otway_Rees, w, IDhLnd, skse^), then the adversary can ensure that w gets a handle to D[hndv = skse^nd] (i.e., that there exists an adversary that schedules messages in a way that gives w this handle), and hence we obtain u = w

as in the previous case. The existence of such an adversary is intuitively clear and technically follows immediately from the main proof: We have that the entry D[hndv = sfcseJhnd] was created by M°R, and assume that M°R outputs send_i(u/, m.3nd) in Step 2.25 for some w'. Let m3'nd := D[hndj = m3nd]. We can assume that w' G H as the adversary would otherwise obtain a handle to D[hndu = skseund], which would yield a contradiction to Equation 11. As shown in the proof of the secrecy property, nonce-list secrecy implies w' G {v,w}, hence either the second component or the third component of D[m3'nd] is an encryption with the key that w shares with T. The command sendJ gives the adversary a handle to m3'nd, i.e., := D[mv"d].hnda. If w = w' (which means that w will be able to decrypt the third component of D[m3'nd]), the adversary forwards mj]nd to w. (Formally, it inputs adv_send_i(u;, T, m^) at ina?.) The machine M°R will then obtain a handle to D[hndv = skseVnd] in Step 3.20, where the correctness of the previous decryption step follows as in the main proof. If w = w', i.e., w will be able to decrypt the second component of m3 'nd, the adversary first determines handles to the first two components of m3'nd by means of the command list_proj, i.e., ZDand list_proj(m,5nad, 1) and cgf"" list_proj(m,5nd, 2). It then creates

a message mhnd ^ list(ID¡hnd, c32a| ) and sends mhnd to w claiming to be v. (Formally, the input is adv_send_i(u;, v, mhnd). Similar to the previous case, the machine M°R will then obtain a handle to D[hndv = sfcseJhnd], but now in Step 3.32. □

6 Proof of the Cryptographic Realization

If Theorem 4.5 has been proven, it remains to show that the Otway-Rees protocol based on the real cryptographic library computationally fulfills corresponding secrecy and consistency requirements. Obviously, carrying over properties from the ideal to the real system crucially relies on the fact that the real cryptographic library is at least as secure as the ideal one. As briefly sketched in the introduction, this has been established in [10,8], but only subject to the side condition that the surrounding protocol, i.e., the Otway-Rees protocol in our case, does not raise a so-called commitment problem. Establishing this side condition is crucial for using symmetric encryption in abstract, cryptographically sound proofs. We explain the commitment problem in detail in the next section to illustrate the cryptographic issue underlying the commitment problem, and we exploit the invariants of Section 5 to show that the commitment problem does not occur for the Otway-Rees protocol. As our proof is the first Dolev-Yao-style, computationally sound proof of a protocol

that uses symmetric encryption, our result also shows that the commitment problem, and hence also symmetric encryption, can be conveniently dealt with in cryptographically sound proofs of security by means of the approach of [8].

For technical reasons, one further has to ensure that the surrounding protocol does not create "encryption cycles" (such as encrypting a key with itself), which had to be required even for acquiring properties weaker than simulata-bility, cf. [3] for further discussions. This property is only a technical subtlety and clearly holds for the Otway-Rees protocol.

6.1 Absence of the Commitment Problem for the Otway-Rees Protocol

As the name suggests, a "commitment problem" in simulatability proofs captures a situation where the simulator commits itself to a certain message and later has to change this commitment to allow for a correct simulation. In the case of symmetric encryption, the commitment problem occurs if the simulator learns in some abstract way that a ciphertext was sent and hence has to construct an indistinguishable ciphertext, knowing neither the secret key nor the plaintext used for the corresponding ciphertext in the real world. To simulate the missing key, the simulator will create a new secret key, or rely on an arbitrary, fixed key if the encryption systems guarantees indistinguishable keys, see [3]. Instead of the unknown plaintext, the simulator will encrypt an arbitrary message of the correct length, relying on the indistinguishability of ciphertexts of different messages. So far, the simulation is fine. It even stays fine if the message becomes known later because secure encryption still guarantees that it is indistinguishable that the simulator's ciphertext contains a wrong message. However, if the secret key becomes known later, the simulator runs into trouble, because, learning abstractly about this fact, it has to produce a suitable key that decrypts its ciphertext into the correct message. It cannot cheat with the message because it has to produce the correct behavior towards the honest users. This is typically not possible.

The solution for this problem taken in [8] for the cryptographic library is to leave it to the surrounding protocol to guarantee that the commitment problem does not occur, i.e., the surrounding protocol must guarantee that keys are no longer sent in a form that might make them known to the adversary once an honest participant has started using them. To exploit the simulata-bility results of [8], we hence have to prove this condition for the Otway-Rees protocol. Formally, we have to show that the following property NoComm does not occur: "If there exists an input from an honest user that causes a symmetric encryption to be generated such that the corresponding key is not known to the adversary, then future inputs may only cause this key to be sent within an encryption that cannot be decrypted by the adversary". This event

can be rigorously defined in the style of the secrecy and consistency property but we omit the rigorous definition due to space constraints and refer to [8]. The event NoComm is equivalent to the event "if there exists an input from an honest user that causes a symmetric encryption to be generated such that the corresponding key is not known to the adversary, the adversary never gets a handle to this key" but NoComm has the advantage that it can easily be inferred from the abstract protocol description without presupposing knowledge about handles of the cryptographic library. For the Otway-Rees protocol the event NoComm can easily be verified by inspection of the abstract protocol description, and a detailed proof based on Algorithms 1-3 can also easily be performed by exploiting the invariants of Section 5.

Lemma 6.1 (Absence of the Commitment Problem for the Otway-Rees Protocol) The ideal Otway-Rees system SysOR''d perfectly fulfills the property NoComm, i.e., SysOR,'d |=perf NoComm.

Proof. Note first that the secret key shared initially between a user and the trusted third party will never be sent by definition in case the user is honest, and it is already known to the adversary when it is first used in case of a dishonest user. The interesting cases are thus the keys generated by the trusted third party in the protocol sessions.

Let j < size, D[j].type = skse such that D[j] was created by M°R in Step 2.19, where, with the notation of Algorithm 2, we have y3 = u and y4 = v for y3,y4 G {1,..., n}. If u or v were dishonest, then the adversary would get a handle for D[j] after M°R finishes its execution, i.e., in particular before D[j] has been used for encryption for the first time, since the adversary knows the keys shared between the dishonest users and the trusted third party. If both u and v are honest, key secrecy then immediately implies that t: D[j].hnda = j for all t G N, which finishes the proof. □

6.2 Proof of Real-or-random Secrecy and Computational Consistency

As the final step in the overall security proof, we show how to derive corresponding secrecy and consistency properties from the proofs in the ideal setting and the simulatability result of the underlying library. In particular, we derive cryptographic, real-or-random key secrecy as well as computational fulfillment of the consistency property.

Once we have shown that the considered keys are symbolically secret and that the commitment problem does not occur for the Otway-Rees protocol, we can exploit the following key-secrecy preservation theorem:

Theorem 6.2 (Symbolic Key Secrecy Implies Cryptographic Key Secrecy [9])

Let a polynomial-time honest user H of a structure ({THH}, SH) of the ideal cryptographic library and a secret-key belief function seckeys for H be given such that the cryptographic library with this user keeps the keys in seckeys strictly symbolically secret. Then every polynomial-time configuration (MH, SH, H, A) of the real cryptographic library (with the same user H) keeps the keys in seckeys cryptographically secret.

It is easy to show that this theorem implies the cryptographic secrecy part of Theorem 4.5 once the ideal, symbolic part has already been shown: We have shown in Section 5 that the ideal Otway-Rees protocol keeps the keys of honest users strictly symbolically secret, i.e., the cryptographic library with user H* denoting the combination of {H} U {M°R | u G H} keeps the keys in seckeys_initiator_OR and seckeys_responder_OR strictly symbolically secret. Hence Theorem 6.2 implies that every polynomial-time configuration (MH, Sh, H*, A) of the real cryptographic library keeps the keys in seckeys_initiator_OR and seckeys_responder_OR cryptographically secret, and thus that the every polynomial-time configurations of SysOR,real keeps the exchanged keys of honest users cryptographically secret.

We only briefly sketch how to derive Req¡e^ from the the ideal counterpart since the proofs contains requires slightly more knowledge about the underlying proof of soundness of the cryptographic library [10,8]: One first exploits that the real and ideal consistency properties closely resemble so-called integrity properties in the sense of [6]. Integrity properties correspond to sets of traces at the in- and output ports connecting the system to the honest users, i.e., properties that can be expressed solely via statements about events at the port set SH; in particular, integrity property hence do not rely on the state of the underlying machine. Integrity properties are preserved under simulatability, i.e., they carry over from the ideal to the real system without any additional work. Formally, the following preservation theorem has been established in [6].

Theorem 6.3 (Preservation of Integrity Properties (Sketch)) Let two systems Sys i, Sys2 be given such that Sys i is at least as secure as Sys2 (written Sys i >peCy Sys2). Let Req be an integrity property for both Sys i and Sys2, and let Sys2 =poly Req. Then also Sys i !=poly Req.

Note that this theorem would allow us to derive Reqfrom its ideal counterparts, provided that we can somehow link the statements involving the state of the ideal and real cryptographic library, i.e., the statements ti : D[hndu = skseuhnd] = t2 : D[hndv = sksevhnd and ti : Du[hndu = skseuhnd].word = t2 : Dv[hndv = sksevhnd].word. If one looks at the underlying proof of soundness of the cryptographic library, there exists a so-called combined system that links

state parts of the real library to state parts of the ideal library. In particular, we obtain that if the real Otway-Rees protocol is run with an arbitrary adversary and if we have £ i : D[hndu = skseuhnd] = t2 : D[hndv = sksevhnd] then there always exist an adversary against the ideal Otway-Rees protocol such that £ 1 : Du[hndu = skseuhnd].word = t2 : Dv[hndu = skseuhnd].word. Together with the aforementioned integrity preservation theorem, this shows that the real Otway-Rees protocol computationally fulfills ReqCe°ns and hence finishes the proof of Theorem 4.5.

7 Conclusion

We have proven the Otway-Rees protocol in the real cryptographic setting via a deterministic, provably secure abstraction of a real cryptographic library. Together with composition and preservation theorems from the underlying model, this library allowed us to perform the actual proof effort in a deterministic setting corresponding to a slightly extended Dolev-Yao model. In particular, we prove real-or-random secrecy of the exchanged keys, i.e., no polynomial-time adversary attacking the protocol is able to distinguish fresh, random keys and keys that are actually exchanged in the protocol. Besides establishing the cryptographic security of the Otway-Rees protocol, our result also serves an an exemplification of the potential of the cryptographic library and the recent secrecy preservation theorem for symbolic, automated, and cryptographically sound proofs of security protocols.

References

[1] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. Information and Computation, 148(1):1-70, 1999.

[2] M. Abadi and J. Jurjens. Formal eavesdropping and its computational interpretation. In Proc. 4th International Symposium on Theoretical Aspects of Computer Software (TACS), pages 8294, 2001.

[3] M. Abadi and P. Rogaway. Reconciling two views of cryptography: The computational soundness of formal encryption. In Proc. 1st IFIP International Conference on Theoretical Computer Science, volume 1872 of Lecture Notes in Computer Science, pages 3-22. Springer, 2000.

[4] M. Backes. A cryptographically sound Dolev-Yao style security proof of the Otway-Rees protocol. In Proc. 9th European Symposium on Research in Computer Security (ESORICS), volume 3193 of Lecture Notes in Computer Science, pages 89-108. Springer, 2004.

[5] M. Backes and M. Durmuth. A cryptographically sound dolev-yao style security proofs of an electronic payment system. In Proc. 18th IEEE Computer Security Foundations Workshop (CSFW), 2005.

[6] M. Backes and C. Jacobi. Cryptographically sound and machine-assisted verification of security protocols. In Proc. 20th Annual Symposium on Theoretical Aspects of Computer Science (STACS), volume 2607 of Lecture Notes in Computer Science, pages 675-686. Springer, 2003.

[7] M. Backes and B. Pfitzmann. A cryptographically sound security proof of the Needham-Schroeder-Lowe public-key protocol. In Proc. 23rd Conference on Foundations of Software Technology and Theoretical Computer Science (FSTTCS), pages 1-12, 2003. Full version in IACR Cryptology ePrint Archive 2003/121, Jun. 2003, http://eprint.iacr.org/.

[8] M. Backes and B. Pfitzmann. Symmetric encryption in a simulatable Dolev-Yao style cryptographic library. In Proc. 17th IEEE Computer Security Foundations Workshop (CSFW), 2004. Full version in IACR Cryptology ePrint Archive 2004/059, Feb. 2004, http://eprint.iacr.org/.

[9] M. Backes and B. Pfitzmann. Relating symbolic and cryptographic key secrecy. In Proc. 26th IEEE Symposium on Security & Privacy, 2005. Extended version in IACR Cryptology ePrint Archive 2004/300.

10] M. Backes, B. Pfitzmann, and M. Waidner. A composable cryptographic library with nested operations (extended abstract). In Proc. 10th ACM Conference on Computer and Communications Security, pages 220-230, 2003. Full version in IACR Cryptology ePrint Archive 2003/015, Jan. 2003, http://eprint.iacr.org/.

11] M. Backes, B. Pfitzmann, and M. Waidner. Symmetric authentication within a simulatable cryptographic library. In Proc. 8th European Symposium on Research in Computer Security (ESORICS), volume 2808 of Lecture Notes in Computer Science, pages 271-290. Springer, 2003. Extended version in IACR Cryptology ePrint Archive 2003/145, Jul. 2003, http://eprint.iacr.org/.

12] M. Backes, B. Pfitzmann, and M. Waidner. A general composition theorem for secure reactive systems. In Proc. 1st Theory of Cryptography Conference (TCC), volume 2951 of Lecture Notes in Computer Science, pages 336-354. Springer, 2004.

13] M. Backes, B. Pfitzmann, and M. Waidner. Secure asynchronous reactive systems. IACR Cryptology ePrint Archive 2004/082, Mar. 2004.

14] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway. Relations among notions of security for public-key encryption schemes. In Advances in Cryptology: CRYPTO '98, volume 1462 of Lecture Notes in Computer Science, pages 26-45. Springer, 1998.

15] M. Bellare and C. Namprempre. Authenticated encryption: Relations among notions and analysis of the generic composition paradigm. In Advances in Cryptology: ASIACRYPT 2000, volume 1976 of Lecture Notes in Computer Science, pages 531-545. Springer, 2000.

16] M. Bellare and P. Rogaway. Encode-then-encipher encryption: How to exploit nonces or redundancy in plaintexts for efficient constructions. In Advances in Cryptology: ASIACRYPT 2000, volume 1976 of Lecture Notes in Computer Science, pages 317-330. Springer, 2000.

17] D. Bleichenbacher. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS. In Advances in Cryptology: CRYPTO '98, volume 1462 of Lecture Notes in Computer Science, pages 1-12. Springer, 1998.

18] M. Burrows, M. Abadi, and R. Needham. A logic for authentication. Technical Report 39, SRC DIGITAL, 1990.

19] R. Canetti and J. Herzog. Universally composable symbolic analysis of cryptographic protocols (the case of encryption-based mutual authentication and key exchange). Cryptology ePrint Archive, Report 2004/334, 2004. http://eprint.iacr.org/.

20] D. E. Denning and G. M. Sacco. Timestamps in key distribution protocols. Communications of the ACM, 24(8):533-536, 1981.

21] D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, 29(2):198-208, 1983.

22] D. Fisher. Millions of .Net Passport accounts put at risk. eWeek, May 2003. (Flaw detected by Muhammad Faisal Rauf Danka).

23] O. Goldreich, S. Micali, and A. Wigderson. How to play any mental game - or - a completeness theorem for protocols with honest majority. In Proc. 19th Annual ACM Symposium on Theory of Computing (STOC), pages 218-229, 1987.

[24] S. Goldwasser and S. Micali. Probabilistic encryption. Journal of Computer and System, Sciences, 28:270-299, 1984.

[25] S. Goldwasser, S. Micali, and C. Rackoff. The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18(1):186-207, 1989.

[26] J. Herzog, M. Liskov, and S. Micali. Plaintext awareness via key registration. In Advances in Cryptology: CRYPTO 2003, volume 2729 of Lecture Notes in Computer Science, pages 548-564. Springer, 2003.

[27] R. Impagliazzo and B. M. Kapron. Logics for reasoning about cryptographic constructions. In Proc. 44th IEEE Symposium on Foundations of Computer Science (FOCS), pages 372-381, 2003.

[28] F. Javier Thayer, J. C. Herzog, and J. D. Guttman. Honest ideals on strand spaces. In Proc. 11th IEEE Computer Security Foundations Workshop (CSFW), pages 66-77, 1998.

[29] R. Kemmerer. Analyzing encryption protocols using formal verification techniques. IEEE Journal on Selected Areas in Communications, 7(4):448-457, 1989.

[30] P. Laud. Semantics and program analysis of computationally secure information flow. In Proc. 10th European Symposium on Programming (ESOP), pages 77-91, 2001.

[31] P. Laud. Symmetric encryption in automatic analyses for confidentiality against active adversaries. In Proc. 25th IEEE Symposium on Security & Privacy, pages 71-85, 2004.

[32] P. Lincoln, J. Mitchell, M. Mitchell, and A. Scedrov. A probabilistic poly-time framework for protocol analysis. In Proc. 5th ACM Conference on Computer and Communications Security, pages 112-121, 1998.

[33] C. Meadows. Using narrowing in the analysis of key management protocols. In Proc. 10th IEEE Symposium on Security & Privacy, pages 138-147, 1989.

[34] D. Micciancio and B. Warinschi. Soundness of formal encryption in the presence of active adversaries. In Proc. 1st Theory of Cryptography Conference (TCC), volume 2951 of Lecture Notes in Computer Science, pages 133-151. Springer, 2004.

[35] J. K. Millen. The interrogator: A tool for cryptographic protocol security. In Proc. 5th IEEE Symposium on Security & Privacy, pages 134-141, 1984.

[36] J. Mitchell, M. Mitchell, and A. Scedrov. A linguistic characterization of bounded oracle computation and probabilistic polynomial time. In Proc. 39th IEEE Symposium on Foundations of Computer Science (FOCS), pages 725-733, 1998.

[37] J. Mitchell, M. Mitchell, A. Scedrov, and V. Teague. A probabilistic polynominal-time process calculus for analysis of cryptographic protocols (preliminary report). Electronic Notes in Theoretical Computer Science, 47:1-31, 2001.

[38] R. Needham and M. Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 12(21):993-999, 1978.

[39] D. Otway and O. Rees. Efficient and timely mutual authentication. Operation Systems Review, 21(1):8-10, 1987.

[40] L. Paulson. Mechanized proofs for a recursive authentication protocol. In Proc. 10th IEEE Computer Security Foundations Workshop (CSFW), pages 84-95, 1997.

[41] L. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Cryptology, 6(1):85-128, 1998.

[42] B. Pfitzmann and M. Waidner. A model for asynchronous reactive systems and its application to secure message transmission. In Proc. 22nd IEEE Symposium on Security & Privacy, pages 184-200, 2001. Extended version of the model (with Michael Backes) IACR Cryptology ePrint Archive 2004/082, http://eprint.iacr.org/.

[43] P. Rogaway, M. Bellare, J. Black, and T. Krovetz. OCB: A block-cipher mode of operation for efficient authenticated encryption. In Proc. 8th ACM Conference on Computer and Communications Security, pages 196-205, 2001.

[44] D. Wagner and B. Schneier. Analysis of the SSL 3.0 protocol. In Proc. 2nd USENIX Workshop on Electronic Commerce, pages 29-40, 1996.

[45] B. Warinschi. A computational analysis of the Needham-Schroeder-(Lowe) protocol. In Proc. 16th IEEE Computer Security Foundations Workshop (CSFW), pages 248-262, 2003.

A Proof of the Invariants

A.l Correct Nonce Owner and Unique Nonce Use

We start with the proof of correct nonce owner.

Proof. [Correct nonce owner] Let (xhnd,-,v,j) £ Nonceu for u £ H, v £ {1,...,n}, and j £ {1, 2, 3, 4}. By construction, this entry has been added to Nonceu by M°R in Step 1.3, Step 3.9, Step 1.25, or Step 1.37. In the last two cases, the entry (xhnd, •, v, j — 1) respectively (xhnd, •, v, j — 3) was already contained in Nonceu (for the same handle xhnd and the same identity v) hence it is sufficient to consider the first two cases. In both cases xhnd has been generated by the command gen_nonce() at some time t, input at port in«? of TH^- Convention 1 implies xhnd =/= J,, as M°R would abort otherwise and not add the entry to the set Nonceu• The definition of gen_nonce then implies D[hndu = xhnd] = I and D[hndu = xhnd].type = nonce at time t. Because of Lemma 5.2 this also holds at all later times t' > t, which finishes the proof. □

The following proof of unique nonce use is quite similar.

Proof. [Unique Nonce Use] Assume for contradiction that both xi := (D[j].hnduJ, •, w, •) £ Nonceu and x2 := (D[j].hndv, -,w',/) £ Noncev at some time t. Without loss of generality, let t be the first such time and let x2 £ Noncev at time t — 1. By construction, x2 is thus added to Noncev at time t by Step 1.3, Step 3.9, Step 1.25, or Step 1.37. In the last two cases, the entry (xhnd,-,w',/ — 1) respectively (xhnd,-,w',/ — 3) was already contained in Nonceu (for the same handle xhnd and the same identity w') hence it is sufficient to consider the first two cases. In both cases, D[j].hndv has been generated by the command gen_nonce() at time t — 1. The definition of gen_nonce implies that D[j] is a new entry and D[j].hndv its only handle at time t — 1, and thus also at time t. With correct nonce owner this implies u = v. Further, x2 = (D[j].hndv, •, w , l) is the only entry that is put into Noncev at times t — 1 and t. Thus also w = w'. This is a contradiction. □

A.2 Correct List Owner

In the following subsections, we prove correct list owner, nonce secrecy, key secrecy, and nonce-list secrecy by induction. Hence assume that all three invariants hold at a particular time t in a run of the system, and we have to show that they still hold at time t + 1.

Proof. [Correct list owner] Let u, v £ H, j < size with D[j].type = list. Let xind := D[j].arg[i] for i = 1, 2 and x5,u := D[xjnd].hndu, and assume that (x5,u, IDund,v,l) £ Nonceu at time t + 1.

The only possibilities to violate the invariant correct list owner are that (1) the entry D[j] is created at time t + 1 or that (2) the handle D[j].hndu is created at time t + 1 for an entry D[j] that already exists at time t or that (3) the entry (x5nu, IDund, v, l) is added to Nonceu at time t + 1. In all other cases the invariant holds by the induction hypothesis and Lemma 5.2.

We start with the third case. Assume that (x^nu, IDund ,v,l) is added to Nonceu at time t + 1. By construction, this only happens in a transition of M°R in Step 1.3, 3.9, 3.25, and 3.37. However, in the first two subcases, the entry D[xl"d] has been generated by the command gen.nonce input at inu? immediately before, hence xjnd cannot be contained as an argument of an entry D[j] at time t. Formally, this corresponds to the fact that D is well-formed [10]. Since a transition of M°R does not modify entries in THh, this also holds at time t+1. For the latter two cases, note that Step 3.22 and

Step 3.29 ensure that (x^, IDUnd,v, 2) e Nonceu respectively (x^, IDhund ,v, 1) e Nonceu already at time t. Hence the claim follows by induction hypothesis and from the previous two subcases.

For proving the remaining two cases, assume that D[j].hndU is created at time t + 1 for an already existing entry D[j] or that D[j] is generated at time t + 1. Because both can only happen in a transition of THh, this implies (x^, IDun , v, l) e Nonceu already at time t, since transitions of THh cannot modify the set Nonceu. Because of u, v e H, nonce secrecy implies D[x]nd].hndw = 4 only if w e {u, v, T}. Lists can only be constructed by the basic command list, which requires handles to all its elements. More precisely, if w e H U {a,T} creates an entry D[j ] with D[j'].type = list and (x 1,. .. , x') := D[j].arg at time t +1 then D[xi].hndw = 4 for i = 1,... , k already at time t. Applied to the entry D[j], this implies that either u, v, or T have created the entry D[j].

We now only have to show that the entry D[j] has been created by u in the claimed steps. This can easily be seen by inspection of Algorithms 1,2, and 3. We only show it in detail for the first part of the invariant; it can be proven similarly for the second part where the claim about the session identifier immediately follows from the proof.

Let (x„U, IDUnd,v,/) e Nonceu for I e {1, 2} and D[x2nd].type = nonce. By inspection of Algorithms 1, 2, and 3 and because D[j].type = list, we see that the entry D[j] must have been created by either M°R or M°R in Step 1.6 if I = 1 or in Step 3.12. (The remaining list generation commands always have D[x^nd].type e {skse, symenc} by construction.) This already implies that the entry D[j] has not been generated by T. Now assume for contradiction that the entry D[j] has been generated by M°R. This implies that also the entry D[xJnd] has been newly generated by the command gen_nonce input at in„?. However, only M°R can add elements to the set Nonceu (it is the local state of M°R), but if an entry (x^nU, •, •, •) is added to the set Nonceu by M°R, then x5,U has been newly generated by the command gen_nonce input by M°R by construction. This implies (x5,d, •, •, •) e Nonceu at all times, which yields a contradiction to x^nu e Nonceu at time t + 1. Hence D[j] has been created by user u. □

A.3 Nonce Secrecy

Proof. [Nonce secrecy] Let u, v e H, j < size with x := (D[j]. hndu, IDhnd ,v,l) e Nonce u, and w e (H U {a}) \ {u, v} be given. Because of correct nonce owner, we know that D[j].type = nonce. The invariant could only be affected if (1) x is put into the set Nonceu at time t + 1 or (2) if a handle for w is added to the entry D[j] at time t +1.

For proving the first case, note that the set Nonceu is only extended by an entry x by M°R in Steps 1.3 and 3.9 (again the modifications of Nonceu in Steps 3.25 and 3.37 do not have to be considered since an entry (D[j].hndu, IDhnd, v,Z — 1) respectively (D[j].hndu, IDhnd, v,Z — 3) already existed in Nonceu before, which is ensured by the checks in Steps 3.22, 3.29, and 3.34). In both cases, D[j].hndu has been generated by TH^ at time t since the command gen_nonce was input at in«? at time t. The definition of gen_nonce immediately implies that D[j].hndw = J, at time t if w = u. Moreover, this also holds at time t +1 since a transition of M°R does not modify handles in THh, which finishes the claim for this case.

For proving the second case, we only have to consider those commands that add handles for w to entries of type nonce. These are only the commands list_proj or adv.parse input at in«,?, where adv_parse has to be applied to an entry of type list, since only entries of type list can have arguments which are indices to nonce entries. More precisely, if one of the commands violated the invariant there would exist an entry D[i] at time t such that D[i].type = list, D[i].hndw = 4 and j e (xind,. .. , £,md) := D[i].arg. However, both commands do not modify the set Nonceu, hence we have x e Nonceu already at time t. Now nonce secrecy yields D[j].hndw = 4 at time t and hence also at all times < t because of Lemma 5.2. This implies that the entry D[i] must have been created by either u or v, since generating a list presupposes handles for all elements (cf. the previous proof). Assume without loss of generality that D[i] has been generated by u. By inspection of Algorithms 1 and 3, this immediately implies j = xjnd, since such handles only occur as first element in a list generation by u. Because of j = D[i].arg[1] and (D[j].hndu,-,v, •) e Nonceu at time t, nonce-list secrecy for the entry D[i] implies that D[i].hndw = 4 at time t. This yields a contradiction. □

A.4 Key Secrecy

Proof. [Key Secrecy] Let j < size, D[j].type = skse such that D[j] was created by M°R in Step 2.19, where, with the notation of algorithm 2, we have y3 = u and y4 = v for honest u, v. Now the message output in Step 2.25 maintains the entry D[j] within an encryption with skse^ and one with skseTnv. By assumption, these keys are shared between u and T respectively v and T, and they are never sent. The definition of the command sym_decrypt implies that only u and T respectively v and T can get a handle to the entry D[j] out of these encryptions. Such a decryption could only happen

in Steps 3.19 and 3.31 yielding handles l(3) respectively l(2) . Let y1 := D[hndu = l(3) ].arg[1], yind := D[y1].hndu, and x1 := D[hndu = l(2) ].arg[2], x5nd := D[x1].hndu. In both cases, the checks in Step 3.22 respectively in Step . and . imply (yhnd, IDhnd ,w, 2) £ Nonceu respectively (x5nd, IDhnd, w, 1) £ Nonceu as otherwise M°R would abort the current transition without updating its state and without producing any output. Now nonce-list secrecy immediately implies that

D[hndu = l(2) ].hnda = D[hndu = l(3) ].hnda = Since u, v, and T only send the entry D[j] as

an argument of D[hnd u = l(2) ] or D[hnd u = l(2) ], we obtain D[j]. hnd a = J., which finishes the proof.

A.5 Nonce-List Secrecy

Proof. [Nonce-list secrecy] Let u,v £ H, j < size with D[j].type = list. Let xind := D[j].arg[i] and xhnu := D[xind ]. hndu for i = 1, 2, 3,4, and w £ (HU {a}) \ {u,v}. Let x^ £ Nonce u,v.

We first show that the invariant cannot be violated by adding an element (x^, IDund , v, l) to Nonceu at time t + 1. This can only happen in a transition of M°R in Step 1.3, 3.9, 3.25, or 3.37. As shown in the proof of correct list owner, in the first two cases, we have l £ {1, 2} and that the entry D[x]nd] has been generated by THh immediately before and hence that xind £ D[j].arg for all entries D[j] that already exist at time t + 1. This also holds for all entries at time t + 1, since the transition of M°R does not modify entries of THh. This yields a contradiction to x]nd = D[j].arg[i]. In the last two cases, Step 3.22 and Step 3.29 ensure that (xhnd, IDhnd , v, 2) £ Nonceu respectively (x5nu, IDund,v, 1) £ Nonceu already at time t. In all cases, we hence know that (x^, IDund,v,l) £ Nonceu for l £ {1, 2} already holds at time t.

Part a) of the invariant can only be affected if a handle for w is added to an entry D[j] that already exists at time t. (Creation of D[j] at time t with a handle for w is impossible as above because that presupposes handles to all arguments, in contradiction to nonce secrecy.) The only commands that add new handles for w to existing entries of type list are list.proj, sym_decrypt, adv_parse, sendJ, and adv_send_i applied to an entry D[k] with j £ D\k].arg. Nonce-list secrecy for the entry D[j] at time t then yields D\k].type = enc. Thus the commands list.proj, sendJ, and adv_sendJ do not have to be considered any further. Moreover, nonce-list secrecy also yields D[k].arg[1] £ {pkseu,pksev}. The secret keys shared between u and T respectively v and T are not known to w £ {u, v, T}, formally D[hndu = skseun ].hndw = D[hndv = sksevn ].hndw = Hence the command sym_decrypt does not violate the invariant. Finally, the command adv_parse applied to an entry of type symenc with unknown secret key also does not give a handle to the cleartext list, i.e., to D[k].arg[2], but only outputs its length.

Part b) and c) of the invariant can only be affected if the list entry D[j] is created at time t +1. (By well-formedness, the argument entry D[x3nd] cannot be created after D[j].) As in Part a), it can only be created by a party w £ {u, v, T} because other parties have no handle to the nonce argument. Inspection of Algorithms 1,2, and 3 shows that this can only happen in Steps 1.6 and 3.12, because for all other commands list we have D[x3nd].type = data which would violate the precondition.

• If the creation is in Step 1.6, the preceding Step 1.3 implies (D[xjnd].hnd^, IDhnd, w', 1) £ Noncew for some w' and some IDhnd and Step 1.4 implies D[x3nd].type = data. Thus the precondition (D[xind].hndu, IDhnd , v, 1) £ Nonceu and unique nonce use then imply u = w. Thus Steps 1.4, 1.5, and 1.6 yield D[x3nd].arg = (u) and D[x4nd].arg = (v).

• If the creation is in Step 3.12, the proof is analogous: The preceding Step 3.9 implies (D[xind].hndw, IDhnd, w', 2) £ Noncew for some w' and some IDhnd and Step 3.11 implies

D[x3nd].type = data. Then the precondition, Step 3.9, and unique nonce use imply u = w. Finally, Steps 3.10, 3.11, and 3.12 yield D[x3nd].arg = (v) and D[xind].arg = (u).

Part d) of the invariant can only be violated if a new entry D[k] is created at time t + 1 with j G D[k].arg (by Lemma 5.2 and well-formedness). As D[j] already exists at time t, nonce-list secrecy for D[j] implies D[j].hndw = 4 for w G {u,v, T} at time t. We can easily see by inspection of the commands that the new entry D[k] must have been created by one of the commands list and sym.encrypt, since entries newly created by other commands cannot have arguments that are indices of entries of type list. Since all these commands entered at a port inz? presuppose D[j].hndz = 4, the entry D[k] is created by w G {u, v, T} at time t+1. However, the only steps that can create an entry D[k] with j G D[k].arg (with the properties demanded for the entry D[j]) are Steps 1.7, 3.13, 2.21, and 2.23. In all these cases, we have D[k].type = symenc. Further, we have D[k].arg[1] = pksew/ where w denotes w's current believed partner. We have to show that w G {u, v}.

• Case 1: D[k] is created in Step 1.7. Then our precondition (D[xjnd].hndu, IDUnd , v,/) G Nonceu and (D[xJnd].hndw, ID'„n , w', ¿') G Noncew for some ID'„n , I' and unique nonce use imply w' = v.

(o)hnd

• Case 2: D[k] is created in Step 3.13. This execution of Algorithm 3 must give ¿2 ) = 4 in

(3)'nd (3)llndn

Step 3.12, since it would otherwise abort by Convention 1. Let ¿2 := D[hndw = ¿2 ].ind. The algorithm further implies D[43) ].type = list. Let x0'nd := D[43) ].arg[i] for i = 1, 2, 3, 4 at the time of Step 3.12, and let x0,w be the corresponding handles obtained in Step 3.1, 3.8, 3.11, and 3.10. As the algorithm does not abort in Steps 3.3 and 3.6, we have D[x0'nd].type = data

and D[x3'nd].arg = (w').

Together with the precondition (D[x0lnd].hndu,-,v,/) G Nonceu, the entry D[/23) ] therefore

fulfills the conditions of nonce-list secrecy. This implies D[x2'nd].arg G {u, v}, and thus w' G {u, v}.

• Case 3: D[k] is created in Step 2.21 or Step 2.23. As in Case 3, this execution of Algorithm 2 must give /(3)h"d = 4 in Step 2.4 and /(2)h"d = 4 in Step 2.12. We set /(3)'nd := D[hndw = /(3)h"d].ind and /(2)'nd := D[hndw = /(2)h"d].ind, and we have D[/(3)lnd].type = D[/(2)lnd].type = list.

Let y0'nd := D[/(3)'nd].arg[i] for i = 1, 2, 3,4 at the time of Step 2.5, and let y0w be the handles obtained in Step 2.5. Let further x 0'nd := D[/(2)'n ].arg[i] for i = 1, 2, 3,4 at the time of Step . , and let x0w be the handles obtained in Step 2.13.

As the algorithm does not abort in Steps 2.7 and 2.16, we have D[y0'nd].type = D[y4'nd].type = D[x3'nd].type = D[x4'nd].type = data and D[x0'nd].arg = D[y4'nd].arg = (w'). Further, the reuse of x^u, in Step 2.20 implies x?'nd = xjnd. Similarly, we obtain y?'nd = yjnd because of Step 2.22.

Together with the precondition (D[xJnd].hndu , IDhnd, v,Z) G Nonceu, the entry D[/(3)'nd] respectively D[/(2)'n ] therefore fulfills the condition of nonce-list secrecy. This implies D[y0'n ].arg G {u, v} respectively D[y0'nd].arg G {u, v}, and thus w' G {u, v}.

Hence in all cases we obtained w' G {u, v}, i.e., the list containing the nonce was indeed encrypted with the key that one of the intended honest participants shared with the trusted third party. □