FORSAKES: A FORWARD-SECURE AUTHENTICATED KEY EXCHANGE PROTOCOL BASED ON SYMMETRIC KEY-EVOLVING SCHEMES

. This paper suggests a model and a deﬁnition for forward-secure authenticated key exchange (AKE) protocols, which can be satisﬁed without depending on the Diﬃe–Hellman assumption. The basic idea is to use key-evolving schemes (KES), where the long-term keys of the system get updated regularly and irreversibly. Protocols conforming to our model can be highly eﬃcient, since they do not require the resource-intensive modular exponenti- ations of the Diﬃe–Hellman protocol. We also introduce a protocol, called FORSAKES, and prove rigorously that it is a forward-secure AKE protocol in our model. FORSAKES is a very eﬃcient protocol, and can be implemented by merely using hash functions.


Introduction
Establishing secure channels is a prominent problem in secure networks. Transmitting confidential data, or ensuring its integrity over a public channel is impossible without secure channels. While communicating parties can utilize their long-term keys (LTKs) for confidentiality or integrity, it is generally considered a bad practice. The standard approach is to first exchange ephemeral keys, and then use these keys to establish secure channels.
On the surface, designing efficient and secure authenticated key-exchange (AKE) protocols does not seem to be a complicated task. However, the history shows otherwise. One of the earliest key exchange protocols, the Needham-Schroeder protocol [54], was soon found to have a subtle flaw [37]. Another example is the Otway-Rees [55] protocol, which is shown to be susceptible to typing attacks [15,32]. In another work, Bird et al. [10] formulated an attack called parallel session attack , and showed that several protocols were vulnerable to it. In particular, the attack was successfully mounted on several proposed ISO-9798 protocols. It is interesting to know that, after over 20 years, the ISO-9798 family of protocols is still open to some attacks [2]. A survey of attacks against entity authentication and AKE protocols can be found in [16,33].
One of the main reasons for the existence of such attacks is the concurrent nature of AKE protocols. The designers of vulnerable AKE protocols often fail to account for all possible scenarios which can happen in a concurrent setting. A more important reason, identified by cryptographers after a while, was the lack of a proper model and definition for AKE protocols.
A model specifies the resources (time, space, etc.) available to each party and the adversary, the way they communicate, and the special abilities at the adversary's disposal (capturing all possible attacks in a general way). A definition specifies what it means for the protocol under consideration to be secure in the model. As soon as the model and definition are determined, the security of many protocols can be formally proven or refuted.
While providing a certain level of assurance, a security proof is not the panacea. In particular: • Proving security theorems and verifying the proofs are daunting tasks, and often prone to errors themselves; • It is possible that the model fails to capture certain attacks, or the definition is inadequate for some security requirements; • The proofs are sometimes misinterpreted. For instance, an asymptotic proof of security might be of limited significance in practice, where concrete proofs of security are needed [9].
A prime example of the first two items is apparent in the work of Krawczyk [48]: He puts forward a general model for AKE protocols, as well as a security definition. Based on this model/definition, an efficient AKE protocol called MQV [50,53] is analyzed, and several security flaws are detected. MQV is then updated into an improved version, called HMQV. Finally, the security of HMQV is proven formally. However, Menezes [52] points out to a few mistakes in the proof, as well as the failure of the model to capture several practical attacks. Subsequently, Krawczyk added an appendix to the full version of his paper [48], discussing how to evade such flaws. His model has since been a de facto standard in designing provably secure AKE protocols (see Section 1.2 for a survey). The bottom line is that one must be careful while proposing a new security model or definition, and should take every possible measure to write sound security proofs. That said, a provably secure AKE protocol is certainly preferable than one which is designed and analyzed in an ad hoc manner, due to the delicate nature of these protocols, as discussed above. For this reason, researchers started to propose models and definitions for AKE protocols in different settings, for which ad hoc protocols already existed. Some of these settings are as follows: Two-party setting, threeparty setting, public-key setting, group key exchange, and password-based AKE. We survey these settings in Section 1.2.
In this paper, we put forward a model and definition for a class of AKE protocols, which were previously designed ad hoc, and then prove the security of our proposed protocol. Informally, this class contains lightweight AKE protocols which provide forward security. By lightweight, we mean the protocols which do not use heavy operations such as modular exponentiation. Forward security, also called perfect forward secrecy (PFS), is an important property of AKE protocols. It was first defined by Günther [45], used famously in the Station-to-Station protocol (STS) [39], and formalized by [5,13,25,48]. This concept is defined informally below: Informal Definition. An AKE protocol is said to be forward secure if, even if the long-term keys (LTKs) are revealed to the adversary, the ephemeral keys generated prior to the exposure of the LTKs remain protected from the adversary.
Types of KES. The literature distinguishes two types of KES: 1. LTKs are updated after a specific event in the system. For instance, AKE protocols can update the LTK upon the exchange of each ephemeral key. This is the approach that SASI and many other AKE protocols follow. 2. LTKs are updated at specific time intervals. A good example of this approach is RSA SecurID (for description and analysis, see [11,12,34,61]). This technique is also used in forward-secure public-key encryption [23], though the latter uses a DH-based construction. Updating LTKs after each key exchange provides forward security in its entirety. However, it is only suitable for the case of smart cards or security tokens, where the device performs no more than one instance of an AKE protocol at each moment. Consider what happens if there are multiple instances of the AKE protocol between two parties, and one instance is completed: The LTKs will get updated, which in turn renders all other instances of the AKE protocol invalid. Therefore, the first solution is not viable for networks such as the Internet, where each party might run several concurrent instance of the AKE protocol with another party (for instance, consider the communications between two routers, or two security gateways).
The second approach, which we adopt in this paper, is more promising for concurrent settings. However, it only satisfies the forward security property partially. 1 As explained in [23], the lifetime of the system is divided into many time stages. At the beginning of each time stage, the LTKs get updated. If the adversary gets hold of an LTK K in time stage T , she must be unable to find the ephemeral keys generated using K in time stage T − 1 or earlier. On the other hand, the security of ephemeral keys generated using K in time stage T is not guaranteed. The faster the LTKs get updated, the more forward security is satisfied. However, if the update frequency is too high, there will be no time for the actual key exchange to take place. Therefore, the update frequency should be set reasonably to prevent loss  of functionality while preserving the forward security. Depending on the unique requirements of the system, update frequencies of once per minute, once per hour, or once per day might be appropriate. However, an update frequency of once per second seems inadequate. An issue which might arise is the use of the time in security protocols. It is important to note that the precise value of the time is of no significance to our model, as we will not deal with the absolute value of the time. Rather, it is important to keep the the time synchrony between the parties in such a way that they perceive the same time stage all the time: When the update frequency decreases (say, once a day), an asynchrony of a few seconds might be acceptable.
To keep parties synchronized, a number of solutions exists: • The current technology allows us to produce devices, such as the RSA SecurID ( Figure 1(a)), which can keep the time synchrony for a long time. Furthermore, general-purpose hardware such as PCs or mobile phones are quite capable of keeping the time precisely. Solutions such as Google Authenticator TM or HDE OTP (Figure 1(b)) depend on this feature: Once the device time is set, it is rarely skewed due to hardware incompetence. • Another solution is to incorporate a trusted time source, such as a time server.
This solution is applicable to corporate networks as well as the Internet. However, it requires a trust infrastructure, such as PKI, to validate the time returned by the time server. • The third solution is to provide legitimate parties with a mechanism to dynamically resynchronize their LTKs on demand. We will investigate this option later in Section 7. Despite these solutions, the clock synchronization problem has not been totally resolved yet [51]. However, many major authentication and AKE protocols are time based. Examples include Kerberos and the Time-Based One-Time Password (TOTP) algorithm, defined in RFC 6238. The former is widely used by Microsoft Active Directory , while the latter is used in two-factor authentication to Amazon, Dropbox, Evernote, Facebook, Google, Microsoft, and Yahoo, among the others (HDE OTP is a sample implementation of RFC 6238).
The bottom line is that, while time-based security protocols face the potential problem of desynchronized clocks, they are vastly used in everyday networking. It is therefore beneficial-both in theory and practice-to study time-based authentication and AKE protocols from a theoretical perspective, and formalize a model and definition to capture their security.
1.1. Contributions. The contributions of this paper are as follows: • We put forward a new model for AKE protocols, where the LTKs evolve over time.
We also define what it means for an AKE protocol to be secure in our model, satisfying the forward security property. • Our model/definition has an algorithmic flavor. That is, we first explain the concept in plain English, and then try to algorithmically describe it. The significance of this approach is that our definitions can be incorporated into tools for automatic verification of security protocols. • We design an AKE protocol, and rigorously prove its security within the model and according to the above definition. The protocol is aptly named FORSAKES, because it is a Forward Secure AKE based on KES. (Recall that AKE stands for Authenticated Key Exchange, and KES stands for Key-Evolving Scheme.) • FORSAKES is designed in the random oracle model (Section 2) without any assumptions. Most AKE protocols depend on some cryptographic assumption, even if they use the random oracle model. For instance, [5,48,49] are proven secure in the random oracle model, but use some form of the Diffie-Hellman assumption as well (e.g., Decisional Diffie-Hellman or Gap Diffie-Hellman). • Since we prove the security of FORSAKES without any assumptions, it is unconditionally secure in the random oracle model. In other words, there is no restriction on the running time of the adversary, and the security proof holds even for infinitely powerful adversaries. (While the adversary can have infinite running time, she is not free to make as many query as she likes to the system or the random oracle. See the proofs for more information.) • We use the random oracle model only to simplify the proofs. However, since we do not use the facilities provided by the random oracle model (such as viewing or programming the adversary's queries), it is possible to replace the random oracle with a pseudorandom function [44], to achieve a secure AKE protocol in the standard model. See Section 6 for more information. • While there are efficient and provably secure pseudorandom functions [1], using the random oracle heuristic and replacing all instances of the random oracle with a hash function such as SHA-1 yields a more practical protocol. In the case of FORSAKES, we can obtain a protocol which uses nothing but hash functions, which is particularly suitable for constrained devices such as smart cards or tokens. See Section 6 for more information.
1.2. Related work. Early papers on secure authentication were either ad hoc, or adopted the zero-knowledge model of Feige, Fiat, and Shamir [43], which was suitable only for smart-card identification. In this paper, we are not concerned with such approach. A comprehensive account of papers on zero-knowledge identification can be found in [40,Section 2.2]. Formalization of a model and definition for both entity authentication and AKE protocols started with the seminal work of Bellare and Rogaway [6]. They recognized that each party can take part in multiple instances of the protocol (each of which was called a session), and modeled each session as an oracle, to which the adversary could make three types of queries: send, reveal, and test. A send query allowed the adversary to deliver a specific message to some session of her choice, and observe the result. A reveal query gave the adversary the session key of a specific session. A test query flipped a coin, and based on the result, gave the adversary either a random value or the session key of the target session. The goal of the adversary was to distinguish whether she is given the random value, or the actual session key.
The ideas of [6] were notable in several ways: (1) They defined the security of AKE protocols based on a distinguishability game. (2) They defined a notion of session freshness. If the adversary makes a reveal query to the target session before or after the test query, she can obtain the session key, and distinguish whether she is given a random value or the actual session key. Therefore, a revealed session is no longer fresh. This is also the case if the "partner session" of the target session is revealed. Therefore, there was a need to define partnership. (3) They defined partnership via the concept of matching conversations. It simply means that two sessions are partners if every message that one sends is received by the other, and vice versa (except possibly the last message, which can always be deleted by the adversary, without being detected by the sender).
Notice that [6] modeled the two-party authentication/AKE based on symmetric keys. The present paper uses a similar model. Furthermore, [6] uses random oracles in their proofs, similar to the proofs of this paper. However, the AKE definition of [6] does not support the concept of forward security. Actually, their model does not allow the adversary to obtain the long-term keys at all.
It is notable that Blake-Wilson et al. [13,14] adapted the Bellare-Rogaway model [6] for the case of asymmetric keys. Accordingly, their definition was updated to recognize the forward security property, as well as protection against new types of attacks which are meaningful only in an asymmetric setting, such as Key-Compromise Impersonation (KCI) or Unknown Key-Share (UKS) attacks. Another change of model was due to Bellare and Rogaway [8] themselves: They proposed a model for the case of three-party AKE, which is the setting used in the Needham-Schroeder protocol [54]. Their model supported a new type of query, corrupt, which allowed the adversary to obtain, and even set the long-term keys. An important achievement of their work was to differentiate between the notions of mutual authentication and authenticated key exchange, and to provide a protocol called 3PKD, which only satisfied the latter.
The notion of partnership in [8] was modeled via an "existentially guaranteed partnering function," a notion that the authors called unintuitive later [5]. Furthermore, the specific partnering function used in the proof of security of 3PKD was later found to be flawed [31].
Shoup and Rubin [59] changed the three-party AKE model of [8] by adding yet another type of query, access. This query allowed modeling a virus on the host machine, accessing the smart card which contained the long-term key.
Several later papers, like [4,58], tried to model AKE protocols using the notion of simulatability, rather than indistinguishability. The former approach is common in modeling secure multiparty computations. This approach was criticized by Canetti and Krawczyk as being "over-restrictive", since "it ruled out protocols that seem to provide sufficient security" [25].
Bellare, Pointcheval, and Rogaway [5] proposed yet another model for AKE protocols, this time formalizing password-based AKE (PAKE) protocols. Passwords are considered low-entropy secrets, and the model and security definition should prevent offline dictionary attacks against PAKE protocols. They also utilized the notion of session identifiers as a means of defining partnership, and took an algorithmic approach towards formalizing the model and definition. In this paper, we will follow a similar algorithmic approach.
Canetti and Krawczyk [25] used a technique introduced in [4] to define the AKE security in an indistinguishability framework: They considered two models, one which provided authenticated channels, while the other did not provide such luxury. The technique was to propose a general compiler , to convert any protocol secure in the former model to one that was secure in the latter model. The model proposed in [25] is generally called the CK model (CK stands for the initials of the authors). The CK model is suitable for two-party AKE in an asymmetric (public-key) setting. It has several important features: • The CK model allows for modular design of AKE protocols. The protocol designer can design a protocol in the authenticated channel model, prove its security, and then easily compile the protocol into one which is secure in the unauthenticated channel model. • The authors formalized the notion of secure channels, and showed that an AKE protocol proven secure in their AKE model could be composed with any protocol proven secure in their secure channel model. The composability theorem shows that any CK-secure AKE protocol can be used to establish a CK-secure channel. Similarly, the composability of the Bellare-Rogaway model [6] with secure channel protocols was later established [18]. See also [17] for another composable model. • The CK model was to become later known as the de facto standard in AKE security models. Many other models can be considered as a variant of the CK model.

Canetti and
Krawczyk proposed yet another security model for AKE protocols [26], this time in the broader context of the Universal Composability (UC) framework [20]. Any protocol proven secure in the UC framewok can be composed with other protocols, even insecure ones. This is important for the Internet protocols, where the protocol designer cannot guarantee that the protocols executed concurrently with his protocol are all secure. It was later shown that the UC-definition of AKE protocols is flawed [46], and the flaw was corrected accordingly. A model for password-based AKE protocols in the UC framework was later proposed [19,24] as well.
In his famous paper, Krawczyk [48] proposed an improvement of the CK model, which became known as the CK + model. In this model, the adversary was allowed to reveal party or session information via three different types of queries: statereveal queries, session-key queries, and party corruption queries. These types of queries provide the adversary with great flexibility.
LaMacchia, Lauter, and Mityagin [49] spotted several weaknesses in the CK and CK + models. Specifically, the CK model does not specify the precise result of the state-reveal queries: "An important point here is what information is included in the local state of a session; this is to be specified by each KE protocol" [25]. Furthermore, the security definitions in both models do not allow an adversary to use his full potential. Therefore, LaMacchia et al. put forward a new security model/definition, called the extended CK (eCK). The eCK model replaced the state-reveal query of CK/CK + with an Ephemeral Key Reveal query. The latter query is specific to Diffie-Hellman protocols, and allows the adversary to reveal the private exponent α in a g α mod p flow of the Diffie-Hellman protocol. The security definition of LaMacchia et al. designates a session as fresh, if either the long-term key or the private exponent of that session is revealed, but not both (and the same should hold for the partner session). This definition greatly increased the power of the adversary, and for two years it was assumed to be the strongest AKE model/definition. However, Cremers [36] showed that the state-reveal query of CK/CK + is stronger than the Ephemeral Key Reveal query of eCK, and therefore the models are incomparable. Cremers used the vagueness in the definition of the state-reveal query to reveal the intermediate results of Diffie-Hellman computations in the NAXOS protocol of LaMacchia et al., thus showing that NAXOS is insecure in the CK/CK + model.
In 2010, Sarr et al. [57] tried to amplify the eCK model, by proposing another model in which the adversary could reveal the intermediate results. Their model considered an implementation approach where the private exponents of the Diffie-Hellman protocol were computed during the idle time of a machine (i.e., before the protocol), and were stored in the RAM, which is considered an insecure storage. They called their model strengthened eCK (seCK).
One year later, Yoneyama and Zhao [62] showed a flaw in the security proofs of Sarr et al. [57], and concluded that achieving secure protocols in the seCK model is very hard, if not impossible.
The above survey shows the delicate nature of proposing security models and definitions for AKE protocols. The reader interested in further comparison of these models and definitions can consult [16,29,30,35,36].

1.3.
Organization. The rest of this paper is organized as follows: Section 2 defines the concepts and notation used throughout this paper. Section 3 presents the FORSAKES protocol. In Section 4, we put forward our new security model and definition for AKE protocols with a symmetric key-evolving scheme. Section 5 provides a rigorous proof of the security of FORSAKES according to the model/definition presented in Section 4. Section 6 discusses the issues regarding the implementation of FORSAKES in practice. Finally, Section 7 concludes the paper, and explains the future work. This paper has an appendix, Appendix A, where we prove the security of a message authentication code (MAC) based on random oracles. This proof is incorporated in the security proof of FORSAKES, in Section 5.

Preliminaries
For c ∈ N, let [c] denote the set {1, 2, . . . , c}. For a finite set S, the notion e ← R S means that the element e is picked from S randomly.
Let n k denote the number of k-subsets of an n-set. By convention, n k = 0 if k > n. Otherwise, n k = n! k!(n−k)! . We use n ∈ N as the security parameter, meaning that the resources (time, space, etc.) available to all parties and algorithms are measured in n. As is customary in cryptography, n will be provided to the algorithms in unary notation 1 n (i.e., 1 is repeated n times). This is because the resources are actually accounted based on the length of the input.
Throughout the paper, we use four functions , r, k, K : N → N, where (n) is the length of entity identifiers in the system, r(n) is an upper bound on the number of random bits used by each entity, k(n) is the length of ephemeral keys, and K(n) is the length of long-term keys. We assume that the exists a polynomial p : N → N, such that n ≤ (n), r(n), k(n), K(n) ≤ p(n) for all n ∈ N. When the context is clear, we may drop the parameter n. For instance, we may simply write r instead of r(n).
Let {0, 1} * denote the set of all binary strings of finite length, and {0, 1} n denote the set of all binary strings of length n. The length of a string x ∈ {0, 1} * is denoted by |x|. The special symbol λ ∈ {0, 1} * denotes the empty string, i.e., |λ| = 0. For two strings x, y ∈ {0, 1} * , let x || y denote the concatenation of x and y. The result of the concatenation of λ with any string is the string itself. Another special symbol is ' # '. It is called the wildcard symbol, and matches a single bit. We use the match function to compare two binary strings which may include the wildcard symbol. For instance, match("1 ## 0", "1010") is true. However, the normal comparison "1 ## 0" = "1010" is false, because the two strings are not literally identical.
We may occasionally assign 0 to a Boolean value to denote that it is logically false. Similarly, 1 is to be interpreted as logically true.
A function f : N → R is called negligible if it vanishes faster than the inverse of any positive polynomial. That is, f (n) < n −c for all c and all sufficiently large n ∈ N.
We use the random-oracle model (ROM) [7], where all parties, including the adversary, have access to a random function O : {0, 1} * → {0, 1} p(n) (recall from above that p(n) is a polynomial upper bound on k(n) and K(n), among other things). Once O is queried on some value x ∈ {0, 1} * for the first time, a random p(n)-bit value y is chosen and returned. Notice that y is independent of x and the identity of the entity making the query. From this point on, O will return y if it is queried again on x. If an entity does not require all p(n) bits of the returned value from O, he only keeps the leftmost required bits, and discards the rest.
It is instrumental to think of O as an ideal hash function, having properties such as one-wayness and collision resistance. The ROM will greatly simplify the security proofs, but as discussed in Section 6, we can replace O with pseudorandom functions.
Convention. In writing the pseudocodes, we will assume minimal evaluation: In a conditional statement, the conjuncts are evaluated from left to right. As soon as a conjunct is evaluated to false, the remaining conjuncts are ignored, and the whole statement is evaluated to false. A similar convention holds for disjuncts. 2 For instance, consider the statement if(a and b): Assuming a is false, the value of b is ignored. The minimal evaluation allows us to write shorter pseudocodes. For instance, in the above example, the variable of b may be undefined unless a is true. If we had not used the minimal evaluation convention, we should have written nested if statements: The outer if evaluates a, and only if it is true, the inner if will evaluate b.

The FORSAKES protocol
To better understand the theoretical foundations of the AKE security model and definition presented in the next section, let us first describe the FORSAKES protocol, which is more practically oriented. Protocol 1 illustrates FORSAKES on a high level.

Initiator Responder
The proposed AKE protocol. Details are described in Section 3.
System Time Stage. Let T be a variable denoting the current time stage of the system. T is assumed to be 1 in the system's epoch 3 , and is incremented every τ seconds. In this paper, we picked T to be a 64 -bit unsigned integer. Therefore, our system supports 2 64 ≈ 10 20 different time stages. However, this choice is quite conservative, and integers with much shorter bit lengths are usually appropriate as well.
Long-Term Keys. Suppose that FORSAKES initiator has identifier id x , and the responder has identifier id y . Moreover, assume that they had shared a long-term key K θ xy in time stage T = θ. This key is updated whenever the time stage is incremented. Let K θ+1 xy denote the new key. In FORSAKES, we have K θ+1 xy ← O(K θ xy ). Notice that the random oracle O can be considered as an ideal hash function, which in particular, is ideally one-way. Therefore, K θ+1 xy reveals no information about K θ xy .
Session State. As pointed out earlier, FORSAKES supports many concurrent key exchanges to run at a time. Each instance is called a session. The session information, also called the session state, is kept in memory. The sessions use independent randomness, and their states should be stored separately. Each party keeps an internal session counter c, which is initially 0. Before a new session state is stored, the session counter is incremented.
The variable st i z stores the session state on party z ∈ {x, y}, whose session counter is i. It is composed of the following variables: The session identifier. It is the (ordered) concatenation of two nonces: The nonce sent by the initiator, and the nonce sent by the responder. Let us denote by rnd i z ∈ {0, 1} r the randomness assigned to session i on party z. The nonce of each session is simply the session randomness. Before the initiator receives the nonce of the responder, he sets the nonce of the responder to # r (i.e., a wildcard string of length r).
The role of the party in the current session, which is either the initiator ('I') or the responder ('R').
The identifier of the session partner.
The time stage in which the session is initiated. We will see that FORSAKES is designed so that all three messages should be exchanged within one time stage. Otherwise, the session state will be deleted. • sk i z ∈ {0, 1} k : The first part of the ephemeral key, known as the session key. As is the case with all secure AKE protocols, the session key will not be used during the FORSAKES. Instead, it will be used used for confidentiality in the secure channel established by the AKE protocol. Therefore, it is important to protect Algorithm 3.1. Initiator's handling of session initiation.
Incoming Message: 0 || id y / / Partner ID, set by the caller.
st c x ← λ and acc c x ← 0; 5: return (λ, λ); the session key properly. The next section shows that the security of an AKE protocol is defined based on the proper protection of the session key.
The second part of the ephemeral key, known as the integrity key. Once computed, this key protects the integrity of FORSAKES messages.
• acc i z ∈ {λ, 0, 1}: The acceptance decision of the session. In the beginning, the acceptance is undecided (λ). When the session decides it acceptance, acc i z will be either false (0) or true (1). Next, we will explain how each message of FORSAKES is handled by the corresponding party. On input an incoming message m as well as other information (LTKs, session state, session randomness, etc.), the handling algorithms always return a pair (m , st). Here, m is the outgoing message, and st is the updated session state.
Remark 3.1. If the handling algorithm does not find a session corresponding to the incoming message, it will return (λ, ' ?'). If the session is found but an attack is detected, the handling algorithm will return (λ, λ). In other cases, m is processed, and the outgoing message and the updated session state is produced according to FORSAKES rules.
Session Initiation. The initiator does not receive any message from another party. However, the initiator session is supposedly called by some "higher-level application," which can be thought of as the zeroth message of the protocol. The caller determines the identifier of the desired partner. Let us assume that the ID of the initiator is id x , and the ID of the partner (i.e., the responder) is id y . The algorithm used by the initiator to handle session initiation, and generation of the first protocol message, is described by Algorithm 3.1. Notice that the zeroth message is denoted by 0 || id y .
The initiator first increases the session counter c, and then sets the session partner ID to id y . It then checks whether he has shared an LTK with y. If this check fails, x sets the session state to an empty string, rejects this session by setting st c x ← λ and acc c x ← 0, and returns (λ, λ) to report the error.
Remark 3.2 (Wiping Sensitive Data). Notice that deleting a sensitive object by freeing the memory allocated to it is a bad security practice, because the traces of that object can reside in the memory for a long time. Therefore, we urge the implementors to securely erase (wipe) the objects from the memory. This paper adopts the convention that assigning the empty string λ to a previously initialized variable denotes the secure wipe of the memory allocated to it.
If no error occurs, the session ID is set to rnd c x || # r . Recall that rnd c x is the current session's randomness, while # r is a wildcard string of length r. The reason of using a wildcard string becomes clear when we discuss how the initiator handles the second message.
In the next step, the initiator sets the session role to 'I', the session time stage to T , the ephemeral keys to empty, and the acceptance state to undecided (λ). Finally, the session state and Msg 1 are set.
Notice that the session state includes every other state variable: It will be the only variable that each session stores (by returning it to the caller). That is, there will be no need to store other variables, such as sid c x , separately. However, we will keep using other variables later, when the session receives the second message. Here, it is implicitly assumed that session state is decomposed by the party to its constituent parts.
Let us explain the construction of the first protocol message as well: (1) Notice that the message begins with 1, indicating that this is the first message of the protocol. It helps the responder-who may have participated in multiple concurrent sessions-to distinguish the incoming message. It can prevent typing attacks [15,32], where the adversary uses the syntactical similarity of protocol messages to reorder them and mount an attack.
The message includes the identifier of the sender (id x ), as well as the identifier of the partner (pid c x ). We include these two identifiers, in the order specified, in all messages of FORSAKES. This prevents parallel session attacks [10], where the attacker opens two sessions with a single party in parallel. She then sends every message she receives from the first session in the second session, and vice versa.
Msg 1 includes the current time stage of the initiator. This inclusion is because the responder should reject the message if it is delivered in a different time stage.
Finally, Msg 1 includes the nonce of the initiator (rnd c x ). The nonce is used to prevent replay attacks. Furthermore, we will see that the nonce of both parties affects the ephemeral keys in an essential way.
At the end of handling session initiation, the pair (Msg 1 , st c x ) is returned to the caller.
Handling the First Message. The first message of the protocol is specified in Equation 1. Upon receiving this message, the responder verifies the syntax, and if approved, follows Algorithm 3.2. Notice that the incoming message is described as m = 1 || id s || id r || T s || rnd s , where the subscripts s and r denote the sender and receiver, respectively. For instance, id s means the sender's ID, while id r means the receiver's ID.
st d y ← λ and acc d y ← 0; 4: return (λ, λ); yx be the LTK shared between id y and pid d y ; The responder first increments his session counter d. While not necessary, we called the responder's session counter d, to distinguish it from the initiator's session counter c. The responder then checks whether the message is intended for him (id r = id y ), and whether the time stage in which the first message was generated is the same as the local time stage (T s = T ). If either of the conditions fails, or if the receiver does not share an LTK with the sender, the responder rejects this session. To this end, the algorithm sets st d y ← λ and acc d y ← 0, and executes the return (λ, λ) command. Remark 3.3. An alternative approach is to return an error message to the initiator, but it might be wasteful of the computation time and bandwidth. The protocol designer can customize this part, if desired.
Next, the responder sets the partner ID to id s , the session ID to rnd s || rnd d y , the session role to 'R', and the session time stage to T . We also assume that K T yx is the current value of the LTK shared between the initiator and the responder.
It is now possible to compute the ephemeral keys based on the current LTK, as well as the nonces of both sessions (note that the session ID is the concatenation of nonces, in a specific order): . After setting the ephemeral keys, the acceptance state of the session is set to undecided (λ), and the session state is constructed. Then, the second message is generated with a similar syntax to the first message. There are two differences, though: (1) The second message includes the session ID rather than a single nonce; Algorithm 3.3. Initiator's handling of the second message.
st i x ← λ; 10: acc i x ← 0; 11: return (λ, λ); let K T xy be the LTK shared between id x and pid i x ; 12: sid i x ← sid; / / No more wildcards.
st i x ← λ; 17: acc i x ← 0; 18: return (λ, λ); and (2) the second message is authenticated using the integrity key. The construction of the message and the authenticator is as follows: . Finally, the responder returns (Msg 2 || Auth 2 , st d y ) to the caller.
Handling the Second Message. After verifying the message syntax, the initiator executes Algorithm 3.3 to handle the second message. It is first verified whether there exists a session whose identifier matches the session ID included in the incoming message. It is here that wildcard matching is important: Notice that the initiator only knows the first part of the session ID, and the second part is chosen by the responder. If no match is found, the incoming message is rejected by returning (λ, ' ?'), meaning that no session state matches the incoming message. Next, it is verified that exactly one match exists. If there are two or more sessions whose identifiers match the sid of the incoming message, all such sessions will be deleted by setting them to empty string, and rejecting the incoming message return (λ, ' ?'); return (λ, ' ?'); / / Unique match is required.
return (λ, st i y ); / / No incoming message after session is decided.
st i y ← λ; 10: acc i y ← 0; 11: return (λ, λ); st i y ← λ; 14: acc i y ← 0; 15: return (λ, λ); by returning (λ, ' ?'). This event should occur only with probability exponentially small in n (see Corollary 5.1 on page 502). Now that the unique session state matching the incoming message is found, the algorithm checks whether this session is already decided. If so, an empty message as well as the current session state is returned.
Next, five more verifications are performed: (1) The ID of the sender matches the ID of the session partner, (2) the ID of the receiver matches the ID of the current party, (3) the time stage of the sender matches the current time stage, (4) the current time stage matches the session time stage, and (5) the role of the current session is 'I', meaning that it anticipated the second protocol message. If any of these conditions does not hold, the session state is securely wiped, and the incoming message is rejected by returning (λ, λ).
Let us assume that K T xy is the current value of the LTK shared between the initiator and the responder. By symmetry, we have K T xy = K T yx . Next, the initiator updates the session ID to sid. This effectively replaces the wildcard string with the proper value. He will then set the ephemeral keys, and verifies the integrity of the second message by comparing Auth 2 to the value it must be. If the verification fails, the session state is securely wiped, the session acceptance is set to false, and the incoming message is rejected by returning (λ, λ).
Otherwise, the acceptance state is set to true, and the session state as well as the third message are computed and returned.
Handling the Third Message. The responder verifies the third message syntactically, and if it is OK, executes Algorithm 3.4. The algorithm first checks whether the sid on the incoming message matches a unique session state. If not, the incoming message is rejected by returning (λ, ' ?'), meaning that no session state matches the incoming message.
Next, it is verified that exactly one match exists. If there are two or more sessions whose identifiers match the sid of the incoming message, all such sessions will be deleted by setting them to empty string, and rejecting the incoming message by returning (λ, ' ?'). This event should occur only with probability exponentially small in n (see Corollary 5.1 on page 502). Now that the unique session state matching the incoming message is found, the algorithm checks whether this session is already decided. If so, an empty message as well as the current session state is returned.
Next, five more verifications are performed: (1) The ID of the sender matches the ID of the session partner, (2) the ID of the receiver matches the ID of the current party, (3) the time stage of the sender matches the current time stage, (4) the current time stage matches the session time stage, and (5) the role of the current session is 'R', meaning that it anticipated the third protocol message. If any of these conditions does not hold, the session state is securely wiped, and the incoming message is rejected by returning (λ, λ).
As a final verification, the integrity key is used to verify Auth 3 on Msg 3 . If the verification fails, the session state is securely wiped, the session acceptance is set to false, and the incoming message is rejected by returning (λ, λ).
Ultimately, the responder accepts, updates the session state, and returns (λ, st i y ). Notice that the outgoing message is λ, meaning that no outgoing message exists. This step concludes the description of FORSAKES, but many practical issues are left to be discussed in Section 6.

Security model & definition
Now that we saw a practical AKE protocol (FORSAKES), it will be easier to understand the security model and definition for general AKE protocols. In what follows, we first model a powerful adversary in Section 4.1. The adversary can arbitrarily create new parties, share a long-term key between any pair of parties, deliver arbitrary messages to them at any time, receive the response as well as information about their internal state, get access to the long-term and session keys, and so on. In the next step, we define what it means for an AKE protocol to be secure in the model. To this end, we define a game between the adversary, and a hypothetical entity called the challenger. The game provides the adversary with all the abilities specified in the model. The goal of the adversary is to distinguish any session key of her choice, from a random value provided by the challenger. The security definition is as permissive on the adversary as possible. In other words, we deem the adversary successful if she succeeds in any non-obvious way. Examples of obvious winning strategies are when the adversary reveals the session key of the target session, or a session partnered to the target session. Section 4.2 formalizes these obvious strategies, by defining what it means for a session to be partnered to another session, and how a fresh session is defined. The actual definition of secure AKE protocols is described in Section 4.3.
(a) Global variables stored by C.

Variable Description
T The time stage of the system, which is initially 1.

N
The number of parties in the system, which is initially 0.
ID A function mapping the real identifiers of parties to their ordinal identifiers. It is initially empty.
(b) Party-specific variables stored by C.

Variable Description
idx The (n)-bit string identifier of party x.

Px
The set of parties who share an LTK with party x. sessx The set of sessions created on party x.  The state of the session (x, s). We assume that this variable encodes, among other information, the value of sid s x , pid s x , sk s x , and acc s x .
exposed s x A Boolean variable, indicating whether the adversary has exposed the session (x, s).

4.1.
A model for key exchange protocols. As in the previous work, we put the adversary in "the center of the universe." No message is delivered without the permission of the adversary. The adversary can eavesdrop on, forge, redirect, replicate, change, delete, and delay messages. Moreover, the adversary is free to obtain the internal state of each session, or even acquire the long-term key of any pair of parties.
An innovation in our model is the ability of the adversary to dynamically create a network of interconnected parties. In other words, the adversary can freely register new parties in the system, and ask the system to share a long-term key between any pair of registered parties in the system. Clock Model. In two-party protocols, every pair of parties wishing to share a session key may need to have synchronized clocks. It is rarely a problem if the shared clock between A and B differs from that of B and C. However, incorporating different shared clocks between various pairs of parties may result in unnecessary clutter in the model. We therefore assume all parties in the system share a universal clock. The system starts in time stage 1, which is incremented every τ seconds. The value of the time stage is stored by the variable T .

4.1.1.
Adversarial & communication model. The interactions between the adversary and the protocol entities can be modeled as a thought experiment. The thought experiment (or the game) is played between a hypothetical challenger C and the adversary A. The challenger allows the adversary to make a set of predefined queries, to which C answers accordingly. The role of the challenger is to keep the state information, to verify the queries, to run the protocol, and to respond to the adversary.
Input of C. The input of C is the security parameter n, in the unary form 1 n . Furthermore, C has black-box access to the AKE protocol Π. We denote this fact by C Π (1 n ).
State Information of C. Let us discuss the state information which C keeps. As described below, the state changes when either A or the universal clock makes a query to C.
The global state variables are detailed in Table 1(a). The variable ID requires an explanation: Each party has two types of identifiers: An ordinal number, and an (n)-bit binary string. The ordinal number determines the order at which parties are created in the system. For instance, the fifth party registered in the system receives the ordinal 5. This identifier is for internal use by A and C, and is not used by the protocol itself. In contrast, the protocol uses the (n)-bit identifiers. The set ID contains both type of identifiers, paired together.
The challenger C also keeps state variables which are specific to one or more parties. These variables are explained in Table 1(b). Finally, C keeps sessionspecific state variables, which are described in Table 1(c). Notice that (x, s) denotes a session identified by s on party x.
Queries Allowed by C. Below, we list and describe the queries allowed by C. Except the first query (which is made by the universal clock), all other queries are made by the adversary. For the sake of simplicity (and not security), we assume that the adversary loses the game if she makes queries which are "obviously wrong." For instance, the adversary loses the game if she asks C to share an LTK between two non-existent parties in the system. In such cases, the challenger immediately outputs 0 and aborts the game (0 means the adversary has lost the game).
The TimeEvent( ) function. The universal clock calls this function at regular intervals (every τ seconds). Upon receiving this query, C updates all long-term keys in the system by calling UpdateLTK(T, K T xy ). In FORSAKES, the function UpdateLTK simply ignores its first argument, and performs a time-independent update: UpdateLTK(T, K T xy ) def = O(K T xy ). Immediately after the new key K T +1 xy is computed, the old key K T xy is wiped securely (see Remark 3.2). After all LTKs are updated, C starts a new time stage by increasing T , and notifies the adversary by calling Notify(A).
The pseudocode of the TimeEvent( ) function is described in Algorithm 4.1. for y ∈ P x 4: xy ← UpdateLTK(T, K T xy );

7:
Notify(A); Remark 4.1. TimeEvent( ) can be extended so that it notifies not only the adversary, but also all the parties in the system. In this way, the parties can do tasks such as removing old sessions which have not completed within one time stage.
The Register( ) function. The adversary calls this function to introduce a new party into the system. Upon receiving this query, C increments N , and generates a random (n)-bit identifier id N . The pair (id N , N ) is added to the set ID, and the set of sessions on N (sess N ) and the set of parties who share an LTK with N (P N ) are set to empty. Finally, id N is returned to the adversary. Notice that the adversary can keep track of N and ID by herself, and therefore C does not bother to return these values.
The pseudocode of the Register( ) function is described in Algorithm 4.2. sess N ← P N ← ∅; 6: return id N ; The ShareLTK(x, y) function. The adversary calls this function to share an LTK between the parties whose ordinal identifiers are x and y. The challenger first checks if either x or y is nonexistent, whether they are identical, and whether they have already shared a key. If either of these conditions hold, the adversary loses the game. Otherwise, a random K(n)-bit key is shared between x and y, and they will be added to the partner set of each other. Notice that by symmetry, K T xy = K T yx . Finally, the reveal time of both keys is set to infinity.
The pseudocode of the ShareLTK(x, y) function is described in Algorithm 4.3.

5:
P x ← P x ∪ {y} and P y ← P y ∪ {x}; 6: revealTime xy ← revealTime yx ← +∞; The Send(x, s, y, m) function. The adversary calls this function to send a message m to (x, s), claiming this message comes from party y. In real networks, the adversary may tap into a line, eavesdrop on packets, and forge them. Therefore, it is possible to send arbitrary messages to any destination (IP, port) pair, while claiming that they are from a specific source (IP, port) pair. The quadruple (source IP, source port, destination IP, destination port) designate the sender and the receiver. In many network applications, it also designates the session to which the message should be delivered. Therefore, the Send(x, s, y, m) function models a practical scenario in the day-to-day networking applications. For a discussion of possible extensions to Send, where either y or s (or both) can be unspecified, see Remark 4.2 below.
To start the protocol on the initiator side, the adversary should send a special message. The syntax of this special message is to be determined by the protocol designer, but it must not be confused with other protocol messages. In FORSAKES, this special message is 0 || id y , where id y denotes the ID of the responder.
If party x or y do not exist in the system, or if y does not have an LTK with x, the adversary loses the game. Furthermore, we syntactically check whether the message m belongs to the valid session (x, s), whether it is sent by y, and so on. This check is performed via a call to SyntaxCheck Π (x, s, y, m). The superscript Π means that the check is specific to the syntax of the AKE protocol Π at hand. Next, the challenger checks whether the session (x, s) exists, and if not, initializes (or changes) the following variables: • sess x : The session s is added to this set.
• skTime s x : It is set to 0, which means that the session key is not generated yet. • exposed s x : It is set to false (0), as the session is not exposed yet. • rnd s x : The randomness of the current session is picked randomly from {0, 1} r(n) . • sid s x , role s x , sk s x , acc s x , state s x , and pid s x : All initialized to default values. Let Π denote the AKE protocol executed by a single party. To run (x, s) on the incoming message m (allegedly from y), the challenger feeds Π with the following pieces of information: • the long-term key (K T xy ); • the current time stage (T ); • the current session state (state s x ); • the session randomness (rnd s x ); • the identifiers of the current party and its session partner (id x and id y ); and • the incoming message (m).

Remark 4.2 (Possible Extensions to Send).
It is possible to extend Send by allowing the adversary to specify the sender as y = 0, meaning that the sender is unspecified. In this case, it is the job the AKE protocol to extract the identity of the sender from the incoming message, and instead of K xy , the Send function should pass {K xy } y∈Px to Π.
It is also possible to allow the adversary to specify the receiving session as s = 0, meaning that the receiving session is unspecified. Again, it is the job the AKE protocol to extract the receiving session from the incoming message, and instead of state s x , the Send function should pass {state s x } s∈sessx to Π. Notice that FORSAKES is consistent with both extensions, since in FORSAKES, both the sender and the receiving session are extracted from the incoming message.
The output of Π is the outgoing message (m ), the updated session state (st), and the updated randomness (rnd s x ): (2) (m , st, rnd s x ) ← Π(K T xy , T, state s x , rnd s x , id x , id y , m) .
The reason why the randomness gets updated is explained in the description of the ExposeSS function (see below). As a convention, if a protocol returns just a pair (rather than a triple), the protocol is not interested in updating the session randomness.
Notice that Equation 2 does not update state s x directly, but introduces the temporary variable st. This is because, as described in Remark 3.1, the protocol Π might not find a unique session corresponding to m, and therefore does not know how to handle the incoming message. In this case, Π will simply return ' ?' as the updated session state. As m does not correspond to (x, s), we do not update state s x in this case.
The second possible case is that Π returns an empty (λ) state. We assume (see Assumption 4.1 below) that this corresponds to detecting an error. In this case, only acc s x is updated to false, but all other session variables (such as partner ID or session key-see Table 1(c)) remain intact.

Remark 4.3.
The reason for not updating other session variables is as follows: In Section 4.2, we will describe the rules for session partnership. We will see that the session key, session ID, session role, and session partner ID can all affect whether two sessions are partnered. If, upon detecting an error, we set other session variables to their default values, the adversary can easily "un-partner" two sessions by sending an invalid message to one of them. 4 Notice that the session variables (such as the session key) are locally stored by both the challenger C and the protocol Π itself. Therefore, the protocol can securely wipe the session variables (as per Remark 3.2), without affecting the local variables stored by C.
The third possible case is that Π returns a non-empty session state. As stated in Table 1(c), the session state encodes other values, including the session ID, the partner ID, the session key, and the acceptance state of the session. In this case, these values are obtained by applying some efficient function f Π ID to state s x : (sid s x , role s x , pid s x , sk s x , acc s x ) ← f Π ID (state s x ) Notice that the subscript ID in f Π ID means that f uses the set ID to translate the string partner ID to the corresponding ordinal value. As before, the superscript Π means that this function is protocol-specific.
Next, the value of skTime s x is set: If it is still 0, but the session key is set, then skTime s x is set to the current value of the time stage. Upon the completion of the Send function, the challenger C returns the tuple (m , sid s x , pid s x , skTime s x , acc s x ) to the adversary. Notice that the returned value does not include the session state (state s x ) or the session randomness (rnd s x ). The pseudocode of the Send (x, y, s, m) function is described in Algorithm 4.4. Before pertaining to the next query, let us mention that in describing the Send query, we assumed that Π satisfies a number of general properties, as listed in Assumption 4.1.
Assumption 4.1 (Properties of Π). We assume that Π satisfies the following rules for all s, x ∈ N: • (x, s) returns an empty state if and only if it detects an error. In this case, it returns an empty string as the outgoing message as well. if s ∈ sess x and (acc s x = λ or pid s x = y) 5: output 0 and abort; 6: if (s / ∈ sess x ) 7: skTime s x ← 0; 9: exposed s x ← 0; if skTime s x = 0 and sk s x = λ 21: skTime s x ← T ; 22: return (m , sid s x , pid s x , skTime s x , acc s x ); • The condition in line 4 of Algorithm 4.4 ensures (among other things) that if session (x, s) exists, y is its partner. In case (x, s) does not exist, we assume that SyntaxCheck Π (x, s, y, m) performs this check, meaning that the syntax of m confirms the claim that y is its sender. Therefore, we can be sure that pid s x = y after line 19 of Algorithm 4.4 is executed.
• acc s x is not set to 1 before (x, s) receives the last incoming message and verifies it.
• (x, s) will no longer accept any incoming message if acc s x is set to either 1 or 0. • If m is the last incoming message of (x, s), the session outputs the empty message m = λ as the outgoing message. • role s x and pid s x are set as soon as (x, s) receives the first message, and will not change to any other value during the lifetime of (x, s).
• Neither sk s x nor sid s x will change after the session key is set (i.e., after skTime s x is set to T in line 21 of Algorithm 4.4).
The ExposeSS(x, s) function. This function is used to model the leakage of session-specific information to the adversary.
If either party x or session (x, s) is non-existent, the adversary loses the game. Otherwise, exposed s x is set to 1, and the pair (state s x , rnd s x ) is returned to the adversary. That is, the adversary will get hold of both the session state and the randomness used for this session.
In many key-exchange protocols, the exposure of the session randomness can have a devastating result on the security of the protocol. For instance, in the Diffie-Hellman key exchange, the private exponent of each session equals (or can be obtained directly from) the session randomness. Therefore, the protocol Π is given a chance to affect rnd s x in line 12 of Algorithm 4.4. As a general guideline, the protocol designers should securely wipe the session randomness as soon as it is no longer needed. However, some protocols use all the randomness in public communications, and do not need to wipe it. For instance, FORSAKES uses the session randomness as nonce, which is sent in cleartext.
The pseudocode of the ExposeSS(x, s) function is described in Algorithm 4.5. output 0 and abort; 4: exposed s x ← 1;

5:
return (state s x , rnd s x ); The RevealLTK(x, y) function. The adversary calls this function to receive the long-term key between parties x and y. If either party is non-existent, or they do not have an LTK, the adversary loses the game. Otherwise, the variables revealTime xy and revealTime yx are set to T , and K T xy is returned. The pseudocode of the RevealLTK(x, y) function is described in Algorithm 4.6. revealTime xy ← revealTime yx ← T ;

5:
return K T xy ; In most papers, the adversary is given access to a Corrupt( ) query, which returns all long-term keys stored on a single party. RevealLTK( ) is a more flexible query, since the adversary can pick the exact LTK she wants to obtain. Moreover, since the adversary knows the set P x of parties to whom x shares an LTK, 5 she can effectively corrupt x by running RevealLTK( ) on x and every party in P x .

Session partnership and freshness.
Before defining what it means for an AKE protocol to be secure, we need to define two central notions: Session partnership, and session freshness. Our notion of session partnership, presented in Definition 4.1, is adopted from [5]. 4. pid s x = y and pid t y = x; 5. sid u z = sid s x for all (z, u) ∈ N 2 − {(x, s), (y, t)}. The first and second conditions state that both sessions should output the same non-empty session keys and session identifiers. The third condition requires that the sessions have different roles; i.e., one is the initiator and the other is the responder. The forth condition states that the sessions recognize the other party as the partner. Finally, the fifth condition requires that no other session besides (x, s) and (y, t) outputs the same session identifier.
The rules stated for partnership are very strict. For instance, if the adversary succeeds in making two sessions agree on different session keys or session identifiers, they are no longer considered partners. As another example, consider the case where the adversary observes the session ID of two sessions, and succeeds in making a third session output the same session identifier. In this case, none of the three sessions will be partnered to each other.
Remark 4.4. We require quite a lot for two sessions to be partnered. It is possible to relax some of these conditions, but the protocol designer should be aware of the effect of such relaxations on the security of the protocol. For instance, let us consider the case where the first condition is removed; i.e., two sessions can be partner even if they have non-identical session keys. This, in turn, means that the adversary can derive the session key of one session by exposing the state information of the partner session. In some (informal) sense, it indicates that one session key can be derived from a non-identical session key, and therefore the session keys are not completely "random looking." C uses the function FindPartnerSession(x, s) in Algorithm 4.7 to find the unique partner of the session (x, s), if one exists according to Definition 4.1. It is assumed that C has already made the usual sanity checks, and is assured that the session (x, s) exists in the system. The output of this function is a numeric value, denoting the ordinal t of the partner session on the party y = pid s x . In other words, (y, t) is the session partnered to (x, s). The value of t will be −1 if no partner session exists. c ← c + 1;

12:
y ← pid s x ; 13: if sk t y = sk s x or sid t y = sid s x or role t y = role s x or pid t y = x 14: return −1; 15: return t; The idea used in Algorithm 4.7 is as follows: We first count the number of sessions in the system, except (x, s), whose session identifier is sid s x . According to Definition 4.1, there must be a unique session, beyond (x, s), with session identifier sid s x . Therefore, if we count zero such sessions, or more than one such session, then (x, s) has no partner session. Otherwise, the session with identifier sid s x is examined for other conditions in Definition 4.1.
Now that the concept of partner sessions is established, one can define the concept of a fresh session. Intuitively, if a session is unfresh, then the adversary knows enough information about that session to trivially deduce the session key. For instance, if the adversary exposes a session after the session key is established, then she already knows the session key. The same holds if the adversary exposes the partner session of a session. Therefore, it is important to properly define the partner session, as we just did.
In Section 4.3, we will define the security of AKE protocols as follows: We will allow the adversary to target any fresh session, and receive either the session key or a random key. Her goal will then be to distinguish the two cases. Consequently, it is important to define the concept of fresh sessions as loosely as possible, so that when a protocol is proved secure in our model, it will resist a variety of attacks. Our definition of freshness is presented in Definition 4.2.

Definition 4.2 (Freshness). A session (x, s)
is called fresh if the following conditions hold (here, y = pid s x ): 1. skTime s x < revealTime xy ; 2. exposed s x = 0; 3. Let t ← FindPartnerSession(x, s). If t = −1, then skTime t y < revealTime yx and exposed t y = 0. The first condition is a forward security requirement: If the LTK is revealed in a time stage later than the one in which the session key is established, then the session key should remain protected. Notice that the initial values for skTime s x and revealTime xy are 0 and +∞, respectively. Therefore, condition 1 holds even if the session key is yet to be established, or the LTK is not revealed. The second condition verifies that the session is not exposed. Finally, the third condition examines the case when the session has a partner: In this case, the partner session should satisfy the first two conditions above.
C uses the function fresh(x, s) in Algorithm 4.8 to find whether the session (x, s) is fresh, according to Definition 4.2.  if skTime s x < revealTime xy or exposed s x = 1 3: return 0;

AKE security definition.
Up until now, we defined a general model for interaction between the parties and the adversary. Given this model, it is straightforward to give the definition of what it means for an authenticated key exchange (AKE) protocol to be secure. We first need to augment the challenger C with two more queries. We denote the augmented challenger by D. The new queries are the Test query, and the Guess query. Contrary to previous queries, the adversary can make the Test and Guess queries only once. Moreover, the Guess query is the last query in the system, after which D announces whether the adversary wins, and aborts the game. In a Test query, the adversary specifies a target session, which must be a fresh one containing a session key. Next, D flips a coin, and depending on the result, answers with either the session key, or a random value. The adversary continues the game by making arbitrary queries (except Test and Guess, which can only be made once). Her goal is to gather as much information as possible, to find out whether the value returned by the Test function is the actual session key, or merely a random value. Notice that in this process, she cannot make any query which makes the target session non-fresh; otherwise, she loses the game as soon as she makes a Guess query.
At some point in time, the adversary makes a Guess query, in which she announces her guess of the coin flipped during the Test query. If the target session is still fresh, and the guess is correct, the adversary wins the game. Otherwise, she loses.
Let us describe the queries in more detail. We will assume that D keeps three new global variables beyond Table 1(a): X, S, and b. The pair (X, S) denotes the target session, and b specifies the random coin. The initial value for b is −1.
The Test(x, s) function. By making this query, the adversary specifies that (x, s) is her target session of choice. She will lose the game if any of the following conditions hold: 1. The party x or session (x, s) is non-existent; 2. The adversary has already made a Test query (checked by verifying b = −1, as the value of b will be set to either 0 or 1 by this function); 3. The target session state is empty; 6 4. The target session is unfresh; 5. The session key is not established yet.
Next, the global variables X and S are set to x and s, respectively. The value of b is then set according to a random coin flip. If b is 0, the session key of (x, s) is returned to the adversary. Otherwise, a random k(n)-bit binary string is returned to the adversary. (Recall that k(n) is the length of the session key.) The pseudocode of the Test(x, s) function is described in Algorithm 4.9.
The Guess(b ) function. By calling this function, the adversary announces her guess of the random coin b. As a sanity check, the function checks whether a Test query is made before (if so, b = −1). This is done because otherwise no target session is specified. Next, it is checked that the target session is fresh. If either of of the conditions is false, the adversary loses.
The rest is pretty simple: If the adversary's guess is correct (b = b), the adversary wins and Guess outputs 1. Otherwise, the adversary loses and Guess outputs 0. In both cases, D aborts the game, as Guess is the last possible query in the game.
The pseudocode of the Guess(b ) function is described in Algorithm 4.10. Denote by D Π , A (n) the single-bit output of the challenger D, when the protocol is Π, the adversary is A, and the security parameter is n. We assume that D outputs 0 if A halts before D returns any value. Define the AKE-advantage of A by the following equation: where the probability is taken over the random coins of D and A. We can now define the security of AKE protocols.

Definition 4.3 (Secure AKE
). An AKE protocol Π is called (n, T (n), (n))-secure if: where the maximum is taken over all probabilistic algorithms whose sum of running time and code size is at most T (n). We call Π a secure AKE if for all c ∈ N, any probabilistic polynomial time adversaries A, and all sufficiently large n ∈ N, we have Adv ake A,D,Π (n) < n −c .

Proving the AKE security of FORSAKES
In this section, we provide proofs of AKE security for the FORSAKES protocol. The proof is quite involved; therefore, it is divided into several parts. The first part, presented in Section 5.1, is in fact a general proof, and is not specific to FORSAKES. It shows that if the adversary creates (polynomially) more than two parties in the system, her AKE-advantage does not change by more than a polynomial. Section 5.2 presents several lemmas about FORSAKES in a multiparty p ← p + 1 and p N ← p; 9: forward the query to D and receive id N ; 10: else 11: execute Algorithm 4.2 and receive id N ; 12: return id N to A; setting. Finally, Section 5.3 uses the aforementioned proofs to establish the security of FORSAKES in a two-party setting.

5.1.
Reducing a multi-party setting to a two-party setting. Let q reg def = q reg (n) and q ltk def = q ltk (n) denote upper bounds on the number of Register and ShareLTK queries that the adversary makes to D. Furthermore, let q def = q(n) be an upper bound on the total number of queries that the adversary makes to D.
Theorem 5.1 states that the adversary can achieve essentially the same AKEadvantage (up to a polynomial), if she registers exactly two parties in the system, rather than polynomially many. Theorem 5.1. Let Π be any AKE protocol (not necessarily secure). For all n ∈ N and any (q reg , q ltk )-adversary A against Π which runs in time at most T (n), there exists a (2, 1)-adversary S which runs in time at most T S (n) = q(n) · poly(n) + T A (n), such that: The proof essentially results from three facts in the modeling: 1. The long-term keys (K T xy ) are generated independently from each other; 2. The randomness of sessions (rnd s x ) are generated independently from each other; 3. The session states (state s x ) are stored and updated independently from each other. Since the adversary A creates at most q reg parties, the number of long-term keys in the system will be at most qreg 2 ≤ q 2 reg . The high-level strategy of the proof is as follows: First, the adversary S randomly picks two distinct integers α and β from the set {1, . . . , q reg }. The values α and β will denote the ordinal identities of two parties, which we call special parties. Next, S starts to simulate the game between A and D. It answers all queries of A by itself, except those queries related to the special parties. The latter type of queries are forwarded to D, and the answers are relayed back to A. In this way, S will make at most two Register( ) queries, and at most one ShareLTK( ) query.
In the final stage, if A picks a session between the special parties as the test session, S will win with the same probability that A wins. Otherwise, S loses. It will be shown that the probability of the former event is at least 1/q 2 reg , and therefore the theorem follows.
We now prove Theorem 5.1 more rigorously.
Proof. Let S be the adversary described by Algorithm 5.1. Since the main purpose of S is to simulate a multi-party AKE setting for A, we call it a simulator. Before going into the details of the simulation, let us note that the following conventions were used to express this algorithm more briefly: 1. Only the state variables used explicitly in the algorithm were defined and initialized. For instance, the state variable T is used implicitly by the TimeEvent( ) function (lines 3-4 of Algorithm 5.1), but since this use is not explicit, the variable T is neither defined nor initialized. The corresponding definitions can be found in Section 4. 2. No sanity check is performed by S. As an example, when A makes a ShareLTK(x, y), it must be verified that identities x and y exist in the system by checking whether x ≤ N and y ≤ N . Moreover, x and y should not have already shared a long-term key. Such sanity checks are assumed to be performed implicity by S, as specified by the rules in Section 4.
Below, each part of the simulator is explained in details.
Initialization, lines 1-2. S first picks the ordinal identity of the two special parties. This is done by picking two distinct random integers α and β from the set [q reg ] = {1, . . . , q reg }. To make sure that the numbers are distinct, α is first selected randomly from [q reg ], and then β is picked from [q reg ] − {α}.
Next, the state variables required for performing the experiment are defined and initialized. N keeps the number of parties which will be registered by A. Other state variables (p, p α , and p β ) keep a mapping between the ordinal identities of the special parties in the game between A and S, and the game between S and D. The mapping is detailed in the description of the Register( ) query below.
TimeEvent( ), lines 3-4. A TimeEvent( ) query is made by D. The simulator S answers this query by running Algorithm 4.1, which involves incrementing T , notifying A, and updating all long-term keys.
Register( ), lines 5-12. When A makes a Register( ) query, S first checks whether this is either the α th or β th query of type Register (the if statement at line 6). If this is the case, N and p are incremented, and p N is set to p. Example 5.1 illustrates how the mapping works.
Example 5.1. Assume that A is an adversary which makes at most twenty Register( ) queries. Therefore, S picks α and β randomly and distinctly from the set {1, . . . , 20}. Assume that α = 18 and β = 13. When A makes the thirteenth Register( ) query, S assigns p ← p + 1 = 1, and p 13 ← p = 1, and registers the first party with D. When A makes the eighteenth Register( ) query, S assigns p ← p + 1 = 2, and p 18 ← p = 2, and registers the second party with D.
Next, the query is forwarded to D, and the identifier id N is received. On the other hand, if this is neither the α th nor β th query of type Register, it is treated ordinarily via a call to Algorithm 4.2, where id N is computed. Finally, id N is returned to the adversary A.
Notice that from the viewpoint of A, the value of id N is distributed identically, regardless of whether N + 1 ∈ {α, β} or not. Therefore, S simulates the Register( ) query perfectly.
ShareLTK(x, y), lines 13-17. The simulator S first checks whether {x, y} = {α, β}, which means either "x = α and y = β" or "x = β and y = α". If this is the case, the adversary A wants a long-term key to be shared between the special parties. Therefore, the query is forwarded to D, with one subtlety: S makes the proper mapping, and sends ShareLTK(p x , p y ) to D. Otherwise, Algorithm 4.3 is executed.
Nothing is sent back to the adversary as the returned value. Internally, either calling D or calling Algorithm 4.3 creates a random and independent key between the corresponding parties. Therefore, S simulates the ShareLTK( ) query perfectly.
• If this is the case, A wants to send a message between two special parties. This is handled by making the proper mapping (x to p x and y to p y ), and forwarding the query to D.
After receiving the answer (m , sid s x , pid s x , skTime s x , acc s x ) from D, the simulator modifies pid s x . It is because in the returned value, pid s x = p y ; whereas p y should be mapped back to y.
• If {x, y} = {α, β}, then A wants to send a message between two non-special parties, or between a special and a non-special party. In this case, Algorithm 4.4 is executed, and the result (m , sid s x , pid s x , skTime s x , acc s x ) is received. In either case, the tuple (m , sid s x , pid s x , skTime s x , acc s x ) is returned to A. This tuple is generated by running the protocol Π, and then extracting the information from state s x via the function f Π ID (see lines 12-21 of Algorithm 4.4). Notice that the inputs to Π are distributed identically regardless of whether {x, y} = {α, β} or not: The long-term key and the session randomness are always uniformly random, and the session state state s x is initially empty. The time stage T is incremented independently, and the rest of the inputs to Π (i.e., id x , id y , and m) are determined by the adversary. Therefore, from the viewpoint of A, the output of Send is identically distributed regardless of whether {x, y} = {α, β} or not, and S simulates this query perfectly.
ExposeSS(x, s), lines 27-35. The simulator first finds the partner of the session (x, s) by letting y ← pid s x . If both partners are the special parties, the ExposeSS query is forwarded to D (making proper mappings), and the results are returned to A. Otherwise, Algorithm 4.5 is executed, and the results are returned to A.
In both cases, the returned value is of the form (state s x , rnd s x ). As explained above (while describing the way a Send query is treated), these values are identically distributed regardless of whether A is dealing with special parties or not. Therefore, S simulates this query perfectly.
In both cases, a long-term key is returned, which is distributed randomly, and is consistent with the rest of A's view. Therefore, S simulates this query perfectly.
Test(x, s), lines 43-49. This is the only query where S may fail to simulate the view of A. The simulator first finds the partner of the test session (x, s) by letting y ← pid s x . If the partners of the test session are the special parties, the query is forwarded to D (making proper mappings), and the result is returned to A.
Otherwise, the simulator fails. This failure is not because S cannot continue the simulation; rather, continuing the simulation is pointless. This is because S should make at most two register queries to D, and then attempt to distinguish a random value from the session key of one of the sessions between these two parties, using A as a guide. If A picks a test session whose partners are not the special parties, then S cannot attain its goal, and fails as a result.
Since S perfectly simulates the whole experiment up to a Test query, A has no way of distinguishing special and non-special parties. Therefore, as A has registered at most q reg parties before a Test query, there are at most qreg 2 ≤ q 2 reg pairs of parties in the system. Consequently, the probability that both partners of the test session are special parties is at least 1/q 2 reg . As a result, the probability that the simulation does not fail is at least 1/q 2 reg . Notice that if this is the case, the view of the adversary A is simulated perfectly.
Guess(b ), lines 50-51. The simulator simply forwards the guess b to D. This will finish the simulation, as D finishes the game as soon as it receives the Guess query.
Conditioned on the fact that the simulation does not fail, S forwards a Guess query, and wins with the same advantage of A. We just proved that the simulation does not fail with probability at least 1/q 2 reg . Therefore, Notice that S answers each query of A with at most a polynomial overhead. Therefore, the running time T S (n) of S is T A (n) + q(n) · poly(n). Theorem 5.1 has an important implication: Since for polynomial-time adversaries, the number of q reg queries are at most a polynomial in n, the advantage of the adversary in a multi-party setting is at most polynomially more than her advantage in a two-party setting.
Furthermore, consider practical settings, where the number of parties in the system is at most on the scale of ten thousand. If the advantage of the adversary in the two-party setting is 2 −256 , then her advantage with ten-thousand parties will be at most 2 −256 × (10, 000) 2 ≈ 2 −229 , which is still a very low advantage. 5.2. FORSAKES in a multi-party setting. In this section, we investigate FORSAKES in a multi-party setting. We start by considering the probability that two parties receive the same identifier.
Fact 5.1. Let the adversary register at most q reg def = q reg (n) parties, and assume the system uses random def = (n)-bit identifiers. Then, the probability that at least two identifiers are equal is at most qreg 2 2 − ≤ q 2 reg 2 − . In the following, we assume that the identifiers are unique. Later, in Theorem 5.2, we account for the probability stated in Fact 5.1.
Fact 5.2. The probability that two particular sessions in FORSAKES output the same nonce is 2 −r(n) .
Notice that Fact 5.2 fact holds even if the adversary obtains the long-term keys and the session keys. This is because the adversary has no control over the nonce generated by any session: The session simply reads a string of length r def = r(n) from its random tape, and outputs it.
Let σ def = σ(n) be an upper bound on the number of sessions the adversary creates on the parties. If the adversary issues at most q snd (n) queries of type Send, then σ(n) ≤ q snd (n). This is because new sessions can only be created via a Send query.
The following corollary is immediate by noting that in a system with σ sessions, there are σ 2 pairs of sessions. Corollary 5.1. In an execution of FORSAKES with σ def = σ(n) sessions, the probability that (at least) two sessions output the same nonce is at most σ 2 2 −r ≤ σ 2 2 −r . Let us call an execution of FORSAKES colliding if at least two sessions output the same nonce. Otherwise, the execution is called non-colliding. A FORSAKES session ID is composed of the concatenation of the initiator and responder nonces. The adversary can affect either of the nonces (via the Send query), but not both. Therefore, we obtain the following corollary.
Corollary 5.2. In a non-colliding execution of FORSAKES, no two sessions output the same session ID.
In the rest of this section, we assume that the execution is non-colliding. The influence of the collision, stated in Corollary 5.1, will be accounted for later in Theorem 5.2. Consequently, we will assume that the fifth condition of Definition 4.1 never holds.
Properties of FORSAKES messages. Let M be the set of nonempty messages which the adversary receives from parties. In FORSAKES, the first message is not equipped with an integrity mechanism (such as a MAC), and it can be forged easily. However, the second and third messages are authenticated. Assume the adversary issues a Send(x, s, y, m) query, where m is the second or third protocol message (i.e., it is prefixed with either '2' or '3'). Lemma 5.1 and Lemma 5.2 (in the next section) consider two separate cases, depending on whether m belongs to M or not.
Lemma 5.1. Let m ∈ M be the second or third message of FORSAKES, delivered via Send(x, s, y, m). Assume that after the delivery, acc s x = 1. Then, the probability of the following events is 0 (assuming a non-colliding execution): 1. m was generated by any party other than y; 2. m was destined at any session other than (x, s). The lemma holds even if all long-term and session keys in the system are known to the adversary.
Proof. First, notice that since the message m is generated by some party in the system, it is not important which keys are known to the adversary; she merely makes the delivery.
Any second-or-third FORSAKES message m ∈ M is authenticated. Since m includes the identifiers of the sender and responder respectively, (x, s) rejects m if the sender is any party other than y. Consequently, acc s x = 1 shows that the sender must have been y, and case (1) is ruled out.
The second and the third messages of FORSAKES carry the session identifier. Since the execution is assumed to be non-colliding, it is impossible that the message have been destined at any session other than (x, s), and acc s x = 1. Therefore, case (2) is ruled out as well.
The next section considers the case m / ∈ M, and concludes the proof of the AKE security of FORSAKES.

5.3.
Proof of AKE-security of FORSAKES in a two-party setting. In Section 5.1, we proved that any efficient adversary A against an AKE protocol in a multi-party system can be reduced to a an efficient adversary S against an AKE protocol in a two-party system, such that the running times and advantages of A and S are identical up to a polynomial. Therefore, this section restricts the adversaries to those registering at most two parties.
We also assume that the adversary against a two-party system does not make "foolish" actions which result in immediate loss of the game. Several of such assumptions are detailed below: • Any adversary registering less than two parties has an AKE advantage of 0, since there will be no test session to attack. Therefore, we assume that the adversary registers exactly two parties. Let x and y denote the ordinal identifiers of the two registered parties, in arbitrary order. That is, {x, y} = {1, 2}. • If the adversary does not share any long-term keys between x and y, or she tries to share more than one long-term keys between them, she will have an AKE advantage of 0. Therefore, we assume that the adversary registers exactly one long-term key K T xy = K T yx between x and y. • Let (X, S) denote the test session, and (Y, S * ) be the session partnered to it (the latter does not necessarily exist). If the adversary exposes (X, S) or (Y, S * ), then she will have an AKE advantage of 0. Therefore, we assume that the adversary does not make the queries ExposeSS(X, S) or ExposeSS(Y, S * ). • If the adversary reveals either the long-term keys K T xy or K T yx before or at the same time stage that the test session generates the session key, she will have an AKE advantage of 0. Therefore, we assume that the adversary either does not make RevealLTK(x, y) or RevealLTK(y, x) query, or makes either of these queries in a time stage after the session key of the test session is generated. Lemma 5.2 pertain to the case m / ∈ M, where the adversary A successfully forges a second-or-third message of FORSAKES. It is the "dual" of Lemma 5.1 in the previous section, which considered the case m ∈ M. On a high level, Lemma 5.2 converts an adversary who successfully delivers a second-or-third message m / ∈ M (without being detected), to an adversary who forges a message authentication code. For discussions related to the construction and security of a random-oracle based MAC, see Appendix A. Let q ro (n) denote an upper bound on the number of the queries which the adversary makes to the random oracle.
Lemma 5.2. Let A be an adversary against FORSAKES, who succeeds with probability A (n) in delivering a second-or-third message m / ∈ M in a non-colliding execution, to a fresh session (x, s), after which acc s x = 1. Then, there exists a (q ro , 2σ + 2, q snd , q snd )-forger F against RO-Multi-MAC (Construction A.2) which wins the Multi-MAC-Forge (Algorithm A.1) with probability F (n) = A (n).
Furthermore, the running times of A and F are related by T F (n) = T A (n) + q(n) · poly(n).
Proof. By construction, FORSAKES sessions created at time stage T will not accept any message at time stage T + 1 or later. Therefore, with no loss of generality, we limit the scope to one time stage; that is, the long-term key does not get updated.
Let F be the adversary against the RO-Multi-MAC, who takes part in the Multi-MAC-Forge experiment. By definition of this experiment, F has access to four oracles: During the experiment, F uses A as a black-box, and simulates for A a two-party execution of FORSAKES, and answers to A's queries as follows (as before, we assume that A does not make an invalid query, which makes her lose the authentication game): • Random oracle queries: The queries are forwarded to F's random oracle, and the answers are returned to A. • Register( ): A random id ∈ {0, 1} is selected by F. This id is then returned to A by F. • ShareLTK(x, y): Nothing is actually done, since the Multi-MAC-Forge experiment has already picked a random key in the initialization phase. • Send(x, s, y, m): This query is handled by F as in Algorithm 4.4; however, when the protocol Π (i.e., FORSAKES) is called, F runs Algorithm 5.2. The idea behind this algorithm is simple: It does not have access to the LTK, but uses the tag-generation oracle T O K to generate Auth 2 and Auth 3 (see Protocol 1), and uses the tag-verification oracle V O K to verify them. It also checks whether the incoming message belongs to the set M. If a second-or-third message has a valid tag, but is not in M, it means that A has successfully forged a valid message (assuming the session is fresh). In this case, the forger F outputs the forgery just found, and finishes the game successfully.
• ExposeSS(x, s): First, F uses the R O K oracle to get the session and integrity keys. This is done by setting sk s . This is the value of K in the next time stage, and is returned to A. • Test(x, y): First, F flips a random coin b. If b = 1, a random k(n)-bit binary string is returned to A. Otherwise, F sets sk s x ← R O K (0 || sid s x ), and returns sk s x to A. • Guess(b ): This query finishes the game with failure, since it is the ultimate query of A, and she has not forge any messages yet.
forger F simulates the view of A successfully. F succeeds if and only if A succeeds. Therefore, F (n) = A (n). The maximum number of queries F makes to its oracles are as follows: There are at most σ sessions on the system, each of which can be exposed. Every ExposeSS query requires 2 queries at R O K . Furthermore, there can be at most one RevealLTK and one Test query, each of which requires 1 query at R O K . Therefore, the total number of queries at R O K is at most 2σ + 2. • q snd queries at T O K , and q snd queries at V O K . This is because each message sent may need a tag verification, and a tag generation. We now pertain to the running-time analysis of F. Notice that F answers each query of A with at most a polynomial overhead. Therefore, the running time T F (n) of F is T A (n) + q(n) · poly(n).
It is now easy to prove that FORSAKES is a secure AKE protocol, because we just proved that the adversary has very little chance of delivering messages at the wrong destination, or forging messages.
Theorem 5.2 (Main Theorem). In the two-party setting, FORSAKES is a secure AKE protocol, as per Definition 4.3.
Proof. Define the following events: • E 1 : Two parties receive the same identifier.
• E 2 : The system is colliding.
• E 3 : The adversary successfully delivers a second-or-third message m ∈ M, with a fake source or at a wrong destination. • E 4 : The adversary successfully forges a second-or-third message m / ∈ M, whose destination session is fresh. The facts and lemmas in this and previous sections proved that the probability that either of of these events happen is exponentially small in n. Therefore, let us condition the probabilities on the event E 1 ∧ E 2 ∧ E 3 ∧ E 4 .
Based on the conditioning above, the adversary has four choices: 1. Faithfully deliver a message; 2. Delay the delivery of a message beyond a time stage; 3. Delete a message. 4. Try to "un-partner" two sessions. In FORSAKES, option (2) causes the destination session to reject, and option (3) prevents the generation of the session key at the destination session. Option (4) is ruled out because conditioned on the above event, the adversary cannot change the parameters that affect whether two sessions are partnered (session key, session ID, session partner ID, and session role). See also Remark 4.3.
Therefore, the adversary is left with options (1). However, if she delivers messages faithfully, and targets a fresh session using the Test query, she will receive a random and independent value key, regardless of the internal coin toss of Test. Therefore, the advantage of A in guessing the value of the coin is 0.
The following corollary is immediate by combining Theorem 5.2 with Theorem 5.1.   Figure 2. A FORSAKES TPM consists of input/output ports, a CPU, an RTC, a RAM, and a permanent storage. Its main task is to securely host the LTKs, and compute the session and integrity keys, based on the information provided by the host machine. The TPM CPU reads information from the input port (1), addresses the permanent storage (2), retrieves the relevant key (3), communicates with the RAM (4 & 5), and writes information to the output port (6). The real-time clock signals the CPU every τ seconds, upon which the CPU updates every key in the permanent storage.
6. FORSAKES in practice 6.1. Replacing the random oracle. One of the most important issues regarding FORSAKES is its use of the random oracle model. As in [6], we note that the random oracle was merely a tool used in the proofs, and it can be replaced with pseudorandom functions [44]. This is because we did not use any of the random oracle facilities, such as the ability to intercept the queries or program the response. There are efficient pseudorandom functions such as [1], which can be used in practice if provable security is desired. However, if even faster implementations are necessary, we suggest the use of encryption functions such as AES, or hash functions such as SHA-1. See [6, Section 6] for more information. It is also possible to use algorithms such as PBKDF2 (Password-Based Key Derivation Function 2), proposed by RFC 2898. Remark 6.1. While attacks such as the length-extension attack against keyed hash functions do not seem applicable to our protocol (due to the fixed length of the input), it is wise to use constructions such as HMAC [3] instead of keyed hash functions.
6.2. Implementation on a constraint device. FORSAKES is quite efficient, and as described above, can be implemented using hash functions only. Therefore, it is ideal for implementation on constraint devices, such as security tokens and smart cards. The device, also called a tamper-proof module (TPM), must be equipped with a real-time clock (RTC), and a secure storage for long-term keys. Figure 2 shows the internals of the TPM. Externally, it can be made similar to a SecurID . 6.3. Implementation subtleties. We suggest using an in-memory database to store session and key information. This approach has several advantages: • Each session can be stored as a row of a sessions table. The table is indexed based in the session ID, which helps in fast retrieval of the session information corresponding to an incoming message. Furthermore, the SQL queries support the like keyword, which is ideal for matching with wildcards (a requirement in FORSAKES). • Databases support the concept of transactions. Consider the case where the LTKs should be updated in the middle of the computation of a MAC, or some session key. Using transactions, one can be sure that concurrent accesses to the database are isolated properly. That said, the implementor may need to incorporate proper concurrency controls (such as locks or semaphores) in their code. • In-memory database have the ability to occasionally save information to some non-volatile memory, to increase the reliability and to perform recovery from a crash. However, notice that it is important to securely wipe the information which is no longer needed.

Conclusion and future work
In this paper, we formalized a model and definition for authenticated key exchange (AKE) protocols, whose long-term keys update regularly. The security definition required forward security, meaning that the revelation of long-term keys in later time stages should not compromise the security of previous session keys. We also proposed an AKE protocol called FORSAKES, and rigorously proved its security.
To improve this work, one can consider a model where the adversary has the ability to desynchronize the long-term keys between any pair of parties, using a Desync(x, y) query. This attack models the practical scenario when the clocks of either party is skewed. The protocol should then detect the desynchronization, and resynchronize the keys. To this end, each pair of parties can share a non-updating LTK, which is only used for resynchronization, and has no purpose in the actual key exchange. The security definition should be updated in such a way that it accounts for Desync queries: Entities should be able to detect asynchrony and resynchronize using their non-updating LTKs.
Another line of work is the analysis of side-channel attacks on the TPM implementations of FORSAKES, and propose improvements which foil such attacks.
2. Run the adversary F on the security parameter 1 n , and give her oracle access to MAC(K, ·). That is, the adversary can query the oracle on messages of her choice, and receive the corresponding tag. Let Q be the list of queries made by F to the oracle. 3. Eventually, F outputs a pair (m, t). She wins this experiment if m / ∈ Q and Verif(K, m, t) = 1. Otherwise, she loses the game. 7 In a secure MAC, it is required that the probability that any efficient A wins the experiment is negligible in n.
It is possible to construct a secure MAC from a random oracle, and a pre-shared key. One such attempt, called RO-MAC , is described in Construction A.1. It is easy to show that RO-MAC is a secure MAC, but we do not prove this fact here. This is because the security of our protocol (FORSAKES) does not depend on the security of RO-MAC. Rather, FORSAKES depends on a more elaborate MAC, which we will construct and prove its security next.
The new construction is called RO-Multi-MAC. In this construction, there is a single pre-shared key K, which is used to generate MAC keys used to form MACs. Construction A.2 provides a more formal description of RO-Multi-MAC. Below, we will prove that RO-Multi-MAC is strongly secure. That is, we give the adversary abilities beyond what is required in a MAC-Forge experiment, and show that RO-Multi-MAC is secure even against such strong adversaries.
In a normal MAC-Forge experiment, the adversary obtains tags on messages of her choice. We would like to extend her abilities, and allow her to reveal any number of MAC keys (k's). She wins the experiment if and only if the tag is a valid MAC under any of the unrevealed k's, and she has not previously obtained a tag for the message. Further more, the adversary is given access to a V O K oracle, and she can check for the validity of a tag for messages of her choice.