Forsakes: A forward-secure authenticated key exchange protocol based on symmetric key-evolving schemes

Rasool Jalili, Mohammad Sadeq Dousti
<span title="">2015</span> <i title="American Institute of Mathematical Sciences (AIMS)"> <a target="_blank" rel="noopener" href="" style="color: black;">Advances in Mathematics of Communications</a> </i> &nbsp;
This paper suggests a model and a definition for forward-secure authenticated key exchange (AKE) protocols, which can be satisfied without depending on the Diffie-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 efficient, since they do not require the resource-intensive modular exponentiations of the Diffie-Hellman protocol. We also introduce a
more &raquo; ... rotocol, called FORSAKES, and prove rigorously that it is a forward-secure AKE protocol in our model. FORSAKES is a very efficient protocol, and can be implemented by merely using hash functions. 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 [10]. A prime example of the first two items is apparent in the work of Krawczyk [11]: 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 [12, 13] 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 [14] 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 [11], 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, three-party setting, publickey 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 [15] , used famously in the Station-to-Station protocol (STS) [16] , and formalized by [11, [17] [18] [19] . 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. Most (if not all) provably-secure AKE protocols satisfying the forward security property use a variant of the Diffie-Hellman (DH) protocol [20] , which requires the heavy modular exponentiations. On the other hand, forward secure and lightweight AKE protocols are often designed ad hoc. The basic idea of such protocols is not to use DH, but to modify the LTKs regularly. Unfortunately, ad hoc protocols are often prone to attacks. A famous "ultra lightweight" AKE protocol, called SASI [21], provides a good example. SASI attempts to provide forward security without depending on DH, but is found to be flawed by several researchers [22] [23] [24] . While proven insecure, SASI (and similar protocols) follow a remarkable approach to forward security: They update the LTKs regularly and irreversibly. If the adversary gets hold of an updated LTK K new , she will be unable to infer the previous LTK K old , as doing so requires inverting the one-way function. Since the ephemeral keys depend essentially on K old , it must be impossible for the adversary to obtain the ephemeral keys from K new . We will use the term Key-Evolving Schemes (KES) for protocols which
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="">doi:10.3934/amc.2015.9.471</a> <a target="_blank" rel="external noopener" href="">fatcat:cgsqkpprhvf77i5cwyvofsejya</a> </span>
<a target="_blank" rel="noopener" href="" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href=""> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> Publisher / </button> </a>