<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article  PUBLIC "-//NLM//DTD Journal Publishing DTD v3.0 20080202//EN" "http://dtd.nlm.nih.gov/publishing/3.0/journalpublishing3.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="3.0" xml:lang="en" article-type="research article"><front><journal-meta><journal-id journal-id-type="publisher-id">JIS</journal-id><journal-title-group><journal-title>Journal of Information Security</journal-title></journal-title-group><issn pub-type="epub">2153-1234</issn><publisher><publisher-name>Scientific Research Publishing</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="doi">10.4236/jis.2015.61006</article-id><article-id pub-id-type="publisher-id">JIS-53160</article-id><article-categories><subj-group subj-group-type="heading"><subject>Articles</subject></subj-group><subj-group subj-group-type="Discipline-v2"><subject>Computer Science&amp;Communications</subject></subj-group></article-categories><title-group><article-title>
 
 
  Authenticated Key Agreement Protocols: A Comparative Study
 
</article-title></title-group><contrib-group><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>reej</surname><given-names>Omar Baalghusun</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Olfa</surname><given-names>Fahad Abusalem</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Zahra</surname><given-names>Abbas Al Abbas</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Jayaprakash</surname><given-names>Kar</given-names></name><xref ref-type="aff" rid="aff2"><sup>2</sup></xref><xref ref-type="corresp" rid="cor1"><sup>*</sup></xref></contrib></contrib-group><aff id="aff2"><addr-line>Department of Information Systems, Information Security Research Group, Faculty of Computing and 
Information Technology, King Abdulaziz University, Jeddah, KSA</addr-line></aff><aff id="aff1"><addr-line>Department of Information Technology, Faculty of Computing and Information Technology, King Abdulaziz University, Jeddah, KSA</addr-line></aff><author-notes><corresp id="cor1">* E-mail:<email>jayaprakashkar@yahoo.com(JK)</email>;</corresp></author-notes><pub-date pub-type="epub"><day>17</day><month>12</month><year>2014</year></pub-date><volume>06</volume><issue>01</issue><fpage>51</fpage><lpage>58</lpage><history><date date-type="received"><day>30</day>	<month>November</month>	<year>2014</year></date><date date-type="rev-recd"><day>accepted</day>	<month>15</month>	<year>December</year>	</date><date date-type="accepted"><day>13</day>	<month>January</month>	<year>2015</year></date></history><permissions><copyright-statement>&#169; Copyright  2014 by authors and Scientific Research Publishing Inc. </copyright-statement><copyright-year>2014</copyright-year><license><license-p>This work is licensed under the Creative Commons Attribution International License (CC BY). http://creativecommons.org/licenses/by/4.0/</license-p></license></permissions><abstract><p>
 
 
  One of the most important and challenging cryptographic primitives in Public Key Cryptography is Key Agreement Protocol where two or more parties share secret values and establish the session key. Many authors have proposed key agreement protocols. In this article, we have viewed some authenticated Key Agreement Protocols and presented a comparative study. We have also described the design principle, security requirement and various attacks on Key Agreement Protocol.
 
</p></abstract><kwd-group><kwd>Impersonation Resilience</kwd><kwd> Prime Factorization</kwd><kwd> ECDLP</kwd><kwd> Trapdoor Function</kwd></kwd-group></article-meta></front><body><sec id="s1"><title>1. Introduction</title><p>Cryptography is the basic technology used to secure information that travel over Internet communication and may expose by attacker (third parties). Key Establishment (KE) is one of the basic concepts in this context and the first step to set up secure, complex and higher level communication [<xref ref-type="bibr" rid="scirp.53160-ref1">1</xref>] which is defined as a method or protocol that make two or more parties sharing a secret value for getting secure information transition [<xref ref-type="bibr" rid="scirp.53160-ref2">2</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] . KE is subdivided into two kinds: Key Transport Protocol (KTP) and Key Agreement Protocol (KAP). In KTP one party is created or gets a secret value and transmitted securely to the other party, more details found in [<xref ref-type="bibr" rid="scirp.53160-ref2">2</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] . Where in KAP two or more parties create a shared secret value by contributing information and combining them to obtain the result. The KE protocol is traditionally known as the hardest one to design, several challenges are associated with KE listed below as [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] stated:</p><p>• Ensuring that the parties (sender and receiver) are exchanging keys to achieve communication encryption/ decryption.</p><p>• Preventing the disclosure of the key by eavesdropper.</p><p>• Giving evidence that a message was encrypted by the party who claims having the sent message for the re- ceiver.</p><p>This survey is presented to give a brief review; clear understanding about KAP which has important role in cryptography and it is a part of data security in any system. KAP is one of the hardest protocols to design, the reason for that as long as many attacks are discovered, protocols need to be verified again and there is a need to develop new one that can defend against the new attacks. The method that will be used in surveying is literature study and the most KAP topics that the survey discusses are present in <xref ref-type="fig" rid="fig1">Figure 1</xref>. The next section will examine what does a KAP mean and give a brief history. Security requirements of KAP are presented in second section. The third section introduces attacks that exposed to the system. The fourth section discusses the knowledge needed to design a new protocol that meets the security requirements respectively.</p></sec><sec id="s2"><title>2. Key Agreement Protocol: An Overview</title><p>KAP is one of the basic cryptography concepts, two or more parties be in agreement on a key to be used for confirming the communication privacy and authentication between them [<xref ref-type="bibr" rid="scirp.53160-ref4">4</xref>] . In 1976 W. Diffie and M. Hellman suggested the initial protocol that is taken as building block for most of the new protocols [<xref ref-type="bibr" rid="scirp.53160-ref5">5</xref>] . However, this protocol does not offer verification between the two parties of communication. Therefore, it is disposed to man in middle attack. Many of protocols have been proposed to resolve this trouble [<xref ref-type="bibr" rid="scirp.53160-ref2">2</xref>] by offering authentication. The authentication can be performed by several methods, such as using the public key infrastructure [<xref ref-type="bibr" rid="scirp.53160-ref6">6</xref>] .</p><sec id="s2_1"><title>2.1. Security Requirement of Key Agreement Protocol</title><p>Security Requirements are related to confidentially, integrity, authentication and availability. So a KAP must hold the following set of required properties [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref6">6</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref7">7</xref>] .</p><fig id="fig1"  position="float"><label><xref ref-type="fig" rid="fig1">Figure 1</xref></label><caption><title> The KAP topics taxonomy</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/6-7800260x5.png"/></fig><p>• Known key security: Every protocol must create independent key. It is not being affected if additional secretive sitting keys are revealed.</p><p>• Forward secrecy: If the long-term private key of one or more of the parties are revealed, the secrecy of earlier created sitting key should not be affected. The system has ideal forward secrecy if every one of the parties long-term key can be damaged without revealing earlier created sitting key, on other hand the system has limited forward secrecy if a few of the parties long-term key can be damaged without revealing earlier created sitting key.</p><p>• Key-compromise impersonation resilience: The attacker is capable of impersonate A, if a long-term private key of a party A has been revealed, but this must not allow it to impersonate other parties to A.</p><p>• Unknown key-share resilience: it should not be potential that A is tricked into sharing a key with party C if A wishes to generate a secret key with B [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] .</p><p>• Key control: A and B together specified the key. It cannot be forced by either A or B.</p></sec><sec id="s2_2"><title>2.2. Attacks on Key Agreement Protocol</title><p>KAPs are vulnerable to many attacks. The designers of these protocols must understand the various types of attack to know how to design a protocol that resist them. This section will briefly discuss them. The attacks are divided into two types [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] : active and passive. A passive attack in computing security is when an attacker is eavesdropping to a communication using a network tracking equipment but without attempt to alter or break the communication; this attack is considered the easiest way to attack also to defend. The communication must be encrypted so even though the attacker compromises the exchanged message, it provides no information. The active attack in computing security is when the attacker attempts to alter or modify the data exchanged in the communication, this attack is considered to be complex than passive and require more effort from attacker and the designer sides.</p><p>Examples of the most common attacks on the KAP are</p><p>• Eavesdropping: it is a kind of passive attack [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref8">8</xref>] that an eavesdropper listening to the information sent in the protocol and the communicating parties are unaware. It is impossible to prevent or stop the eavesdropping, but the message can be protected using encryption. This way the confidentiality is guaranteed. Only the communicating party can clearly read the contents of the message who know the secret key, so the key should be kept secret between communicating parties. Eavesdropping can be used as a part of more complex attack.</p><p>• Modification [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref8">8</xref>] : it is a kind of active attacks where the attacker alters or modifies the information which is sent in the protocol. Using cryptographic integrity measures are methods to prevent this attack.</p><p>• Replay:also known as playback attack which happens when a transmission maliciously or fraudulently repeated or delayed. This can be done either by the sender or by an attacker who catches the data and retransmits, or when the communication is being recorded to be replicated to the same or different parties for criminal intents. This attack can be used as a part of more complex. Using session tokens, one time password or timestamping are ways to prevent this kind of attack [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref8">8</xref>] .</p><p>• Reflection: By attacking a challenge response authentication system that uses identical protocol in both sides by tricking a target party to offer the answer to his own challenge [<xref ref-type="bibr" rid="scirp.53160-ref8">8</xref>] . By demanding the originating party to first reply to challenge prior to the target party responds to his own challenge to avoid this attack. Another way of protection is to force using a different key or protocol in both sides of a transmission.</p><p>• Denial of Service Attack: When the attacker is sending a huge number of invalid requests to a network with the aim of overwhelming and exhausting the server’s resources and preventing legitimate users from communi- cating with the server [<xref ref-type="bibr" rid="scirp.53160-ref8">8</xref>] . The attack aims to exhaust the computational resources (CPU and Storage) of the server. There are no means to fully prevent this attack, but the protection can be done by reducing the amount of calculations and number of values the server have to save for each transmission.</p><p>• Certificate Manipulation: When an attacker modifies the certificates information in order to attack the protocol.</p><p>• Protocol Interaction: When the attacker selects a new protocol to communicate with a well-known protocol. To defend against this kind of attack is by using different set of keys for each protocol, and including the protocol’s information such as: the protocol’s identifier and its version in the message authenticated part.</p><p><xref ref-type="table" rid="table1">Table 1</xref> summarizes the different common attacks.</p><table-wrap id="table1" ><label><xref ref-type="table" rid="table1">Table 1</xref></label><caption><title> Common attacks</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >Name of Attacks</th><th align="center" valign="middle" >Description</th></tr></thead><tr><td align="center" valign="middle" >Heading Eavesdropping</td><td align="center" valign="middle" >The attacker listens to information sent via the protocol.</td></tr><tr><td align="center" valign="middle" >Modification</td><td align="center" valign="middle" >The attacker changes the information sent via the protocol</td></tr><tr><td align="center" valign="middle" >Replay</td><td align="center" valign="middle" >The attacker records information sent in the protocol and forwards it to the same or a different party during protocol runs.</td></tr><tr><td align="center" valign="middle" >Replay</td><td align="center" valign="middle" >The attacker involves in the run of a protocol earlier to a run by the legitimate parties.</td></tr><tr><td align="center" valign="middle" >Reflection</td><td align="center" valign="middle" >The attacker sends protocol messages back to the party who sent them.</td></tr><tr><td align="center" valign="middle" >Denial of Service</td><td align="center" valign="middle" >The attacker prevents legitimate parties from finalizing the protocol.</td></tr><tr><td align="center" valign="middle" >Cryptanalysis</td><td align="center" valign="middle" >The attacker gets some useful control from the protocol to help in cryptanalysis.</td></tr><tr><td align="center" valign="middle" >Certificate Manipulation</td><td align="center" valign="middle" >The attacker picks or alters certificate information to attack one or more protocol runs.</td></tr><tr><td align="center" valign="middle" >Protocol Interaction</td><td align="center" valign="middle" >The attacker selects a new protocol to interact with a well-known protocol.</td></tr></tbody></table></table-wrap></sec></sec><sec id="s3"><title>3. Design Principle of Key Agreement Protocol</title><p>Any protocol designer must have some mathematics skills that help to invent a good protocol. This section will introduce a brief description about the most important topics that related to protocol design process. Many researches have been done to design new KAPs that satisfy the security requirements, present safe and secured communication. This kind of protocols is hard to develop, because there are many ways to attack the protocol as we stated early in previous section and new attacks are presented [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] . The designer are working hard, making effort and trying to enhance the protocol security but still some of protocols contain problem and defects. The process of designing new protocol is based on try and fail [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] , there is no structured way to develop a protocol, because the information is rapidly changing and security requirements are updated contagiously based on it. The process begin by proposing new protocol to achieve an excellent level of security, after that new attack is exposed, or some limitation is found so the protocol fail and are not secure any more, then the process start again. The next subsection presents the core design concepts that all KAPs based on it, which are one-way functions.</p><sec id="s3_1"><title>3.1. Cryptographic Functions</title><p>A one-way function is a computational function that can be easily calculated from a single direction which is the forward direction, but hard to calculate in the inverse direction [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] . A “trapdoor one-way function” [<xref ref-type="bibr" rid="scirp.53160-ref9">9</xref>] is a specific kind of one-way function which is complex to reverse except you have some confidential information named the “trapdoor”. If this extra information is not available, the computation is hard [<xref ref-type="bibr" rid="scirp.53160-ref9">9</xref>] . Cryptosystem with public/private keys is an example of a trapdoor one-way function, where the private key is the trapdoor needed to calculate the function in forward and inverse directions. If the private key is unknown the function can be calculated only in the forward direction. The forward direction is for the encryption and the verification of digital signature, where the inverse direction is for the decryption and generating the digital signature [<xref ref-type="bibr" rid="scirp.53160-ref3">3</xref>] . The next subsection discusses some examples of one way function.</p></sec><sec id="s3_2"><title>3.2. Discrete Logarithm Problem</title><p>Finding an integer <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x6.png" xlink:type="simple"/></inline-formula> solving the equation<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x7.png" xlink:type="simple"/></inline-formula>, where <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x8.png" xlink:type="simple"/></inline-formula> and <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x9.png" xlink:type="simple"/></inline-formula> are elements of a Solving the discrete logarithm problems is assumed to be hard. On ordinary computers there is no well-organized method for calculating discrete logarithms. The security of many public-key cryptography algorithms are based on that assumption.</p></sec><sec id="s3_3"><title>3.3. Integer Factorization Problem</title><p>Prime factorization (factorization) in number system means decomposition of an integer into prime numbers which are called factors. When multiplying these factors yields the original integer. Many cryptographic protocols are based on the complexity of factoring large composite integers such as the RSA problem.</p></sec><sec id="s3_4"><title>3.4. Discrete Logarithm Problem</title><p>This is the logarithms that are defined on multiplicative cyclic groups. Let <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x10.png" xlink:type="simple"/></inline-formula> is a multiplicative cycle group</p><p>and <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x11.png" xlink:type="simple"/></inline-formula> is a generator of<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x12.png" xlink:type="simple"/></inline-formula>, then the elements <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x13.png" xlink:type="simple"/></inline-formula> of the cyclic group are in the form <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x14.png" xlink:type="simple"/></inline-formula> for some<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x15.png" xlink:type="simple"/></inline-formula>.</p><p>Definition 1. Discrete logarithm to base <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x16.png" xlink:type="simple"/></inline-formula> of <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x17.png" xlink:type="simple"/></inline-formula> in the group <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x18.png" xlink:type="simple"/></inline-formula> is defined to be<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x19.png" xlink:type="simple"/></inline-formula>.</p><p>The discrete logarithm problem is defined as: given a group G, a generator g of the group and an element h of G, to find the discrete logarithm to the base g of h in the group G. Discrete logarithm problem is not always hard. The hardness of finding discrete logarithms depends on the groups.</p></sec><sec id="s3_5"><title>3.5. Elliptic Curve Discrete Logarithm Problem</title><p>In cryptographic context, it is a curve over a finite area, which consists of points satisfying the following equation</p><disp-formula id="scirp.53160-formula150"><label>(1)</label><graphic position="anchor" xlink:href="http://html.scirp.org/file/6-7800260x20.png"  xlink:type="simple"/></disp-formula><p>Definition 2 Given an elliptic curve <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula> defined over a finite field<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula>, a point <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x23.png" xlink:type="simple"/></inline-formula> of order<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x24.png" xlink:type="simple"/></inline-formula>, and a point<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x25.png" xlink:type="simple"/></inline-formula>, find the integer <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x25.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x26.png" xlink:type="simple"/></inline-formula> such that<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x25.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x26.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x27.png" xlink:type="simple"/></inline-formula>. The integer <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x21.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x22.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x23.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x24.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x25.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x26.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x27.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x28.png" xlink:type="simple"/></inline-formula> is called discrete logarithm</p><p>of <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x29.png" xlink:type="simple"/></inline-formula> to base<inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x29.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x30.png" xlink:type="simple"/></inline-formula>, denoted <inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x29.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x30.png" xlink:type="simple"/></inline-formula><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x31.png" xlink:type="simple"/></inline-formula> [<xref ref-type="bibr" rid="scirp.53160-ref10">10</xref>] .</p></sec></sec><sec id="s4"><title>4. Comparative Study</title><p>Authenticated Key Agreement (AKA) Protocol share widely used for any secure communication systems such as electronic commerce, wired lines, wireless and other Internet applications [<xref ref-type="bibr" rid="scirp.53160-ref11">11</xref>] . AKA provide ways to verify the communicating parties authenticity and to establish a common secret session key between the communi- cating parties for subsequent use. Also, ensure that no attacker can get the information transmitted over the communication channel. An AKA protocol in general is designed using several cryptographic schemes and pro- tocols such as public/private key pairs, Hybrid systems, passwords and other tricks Like shared secret keys.</p><sec id="s4_1"><title>4.1. W. Hsiang An et al.’s Protocol</title><p>W. Hsiang An, L. Chun Li and H. Tzonelih [<xref ref-type="bibr" rid="scirp.53160-ref12">12</xref>] propose a protocol that provides secure communications in client―server environment through a low power computing Portable devices such as PDAs,smart cards, and cellular phones and make the client perform as minor computations as possible, and to reach mutual authenti- cation and secure communications The proposed protocol is an Authenticated Key Exchange-for Low Power Computing clients (AKE-LPC) that is based on hybrid-key architecture which means that one party (client) shares a secret with the server whereas the other party (server) stores a pair of matching public/private keys. This protocol involves only one hash operation on the client side during execution stage, considering the cost of LPC client computation. Two protocols are proposed, one is already providing implicit mutual authentication and the other with a minor modification to accomplish explicit mutual authentication which is considered here to be evaluated. The protocol fulfills all requirements of security except the forward secrecy [<xref ref-type="bibr" rid="scirp.53160-ref13">13</xref>] .</p></sec><sec id="s4_2"><title>4.2. C. Popescu’s Protocol</title><p>Popescu [<xref ref-type="bibr" rid="scirp.53160-ref14">14</xref>] presents secure and efficient AKA that is constructed on DH and works in an elliptic curve group. This protocol is more efficient in the from computational cost perspective, since it involves only one integer multiplication per party. Key compromise impersonation goal doesn't fulfill in the protocol [<xref ref-type="bibr" rid="scirp.53160-ref13">13</xref>] while other security attributes do. The protocol provides efficiency and using simple computations just a hash functions and elliptic curve which does not require many resources.</p></sec><sec id="s4_3"><title>4.3. L. Harn et al.’s Protocol</title><p>L. Harn, M. Mehta and W. J. Hsin [<xref ref-type="bibr" rid="scirp.53160-ref11">11</xref>] proposed three AKA protocols based on DH. The proposed protocols used a single cryptographic assumption. Each protocol is based on one of the cryptographic assumptions which include discrete logarithm, an elliptic curve or an RSA factoring. The first one is an authenticated DH key agreement protocol based on discrete logarithm; it provides both user and shared-key authentication. The second is an authenticated DH key agreement protocol based on the elliptic curve. The third is an authenticated DH key agreement protocol based on RSA factoring. The last one will be evaluated in this comparative study. All the security attributes are achieved with this protocol except the forward secrecy.</p></sec><sec id="s4_4"><title>4.4. Tseng et al.’s Protocol</title><p>Two AKAs [<xref ref-type="bibr" rid="scirp.53160-ref15">15</xref>] proposed by Tseng that reduce the impact of denial-of-service attacks. They depend on explicit key confirmation which needs little computational cost. Both proposed protocols are able to concurrently resist both the CPU-exhaustion attack and the storage-exhaustion attack. Storage-exhaustion means that the attacker overwhelms the server’s memory with variables connected to the various requests to the server. CPU-exhaustion is when the attacker attempts to consume all server's computational resource. All security attributes of are fulfilled in these protocols. The protocol reduces the impact of denial-of service attacks against the server by minimizing the server’s computations and storage needs.</p></sec><sec id="s4_5"><title>4.5. Y. Eun-Jun et al.’s Protocol</title><p>An AKA protocol that proposed by Y. Eun-Jun and Y. Kee-Young which is based on ECDLP and usepassword authentication [<xref ref-type="bibr" rid="scirp.53160-ref16">16</xref>] . This protocol is claimed to be simple, efficient and capable to defend against off-line password guessing and modification attacks by isolate the information that may used to confirm the correctness of the guess using an asymmetric structure in the messages exchanged. The computations of the protocol are based on ECC and hash functions, which do not require much computational resources. The benefits from the ECC are in the key block size, speed, and security. This protocol meets all requirements of security if there are no fully private keys in this protocol, only the shared secret password. In this context, the key-compromise impersonation flexibility goal is not fit and decides to leave it out of the evolution. Instead if the password is compromised the parties may not be authenticated. The protocol is efficient, simple and to resist off-line password guessing and modification attacks.</p></sec><sec id="s4_6"><title>4.6. M. Nabil et al.’s Protocol</title><p>M. Nabil, Y. Abouelseoud, G. Elkobrosy and A. Abdelrazek [<xref ref-type="bibr" rid="scirp.53160-ref17">17</xref>] have proposed four authenticated KAPs that support explicit authentication. The authentication of the communicating parties is performed in a trusted third party like a firewall. In this way the end user’s devices dispose of being overwhelmed with computational burden which is tied up with the authentication. New schemes are proposed where each protocol consists of two phases, the setup phase and key generation phase. The first two protocols are two-party and the other two are three-party scheme. All of them are a certificate based PKI where the communicating parties must be registered. The bilinear maps, the Weil pairing and hard computational problems which are based on the complexity of Bilinear Diffie-Hellman Problem are used to develop these protocols [<xref ref-type="bibr" rid="scirp.53160-ref10">10</xref>] [<xref ref-type="bibr" rid="scirp.53160-ref18">18</xref>] . This paper analyzes the first protocol. The protocol fulfills all the security attributes of KAP. It relieves the communicating parties from the communication burden of the authentication and enhancing the performance.</p><p><xref ref-type="table" rid="table2">Table 2</xref> summarizes the security of the above described protocols. We have discussed on the following security attributes:</p><p>•: Known Key Secrecy (KkS)</p><p>•: Perfect forward secrecy (PfS)</p><p>•: Key-compromise impersonation resilience (KiR)</p><p>•: Unknown key-share resilience (UkR)</p><p>•: Key control (Kc)</p><p><xref ref-type="table" rid="table3">Table 3</xref> summarizes the design principle, authentication method, cryptographic function used and the mathematical hard function on which the security of the protocols relies.</p></sec></sec><sec id="s5"><title>5. Conclusion</title><p>The need to have a secure system depends on cryptography. KAP is one of the most basic concepts of crypto-</p><table-wrap id="table2" ><label><xref ref-type="table" rid="table2">Table 2</xref></label><caption><title> Security comparison</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >Protocol</th><th align="center" valign="middle" >KkS</th><th align="center" valign="middle" >PfS</th><th align="center" valign="middle" >KiR</th><th align="center" valign="middle" >UkR</th><th align="center" valign="middle" >Kc</th></tr></thead><tr><td align="center" valign="middle" >W. Hsiang An et al.’s Protocol</td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x32.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x33.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x34.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x35.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x36.png" xlink:type="simple"/></inline-formula></td></tr><tr><td align="center" valign="middle" >C. Popescu’s Protocol</td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x37.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x38.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x39.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x40.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x41.png" xlink:type="simple"/></inline-formula></td></tr><tr><td align="center" valign="middle" >L. Harn et al.’s Prtocol</td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x42.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x43.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x44.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x45.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x46.png" xlink:type="simple"/></inline-formula></td></tr><tr><td align="center" valign="middle" >Tseng et al.’s Protocol</td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x47.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x48.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x49.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x50.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x51.png" xlink:type="simple"/></inline-formula></td></tr><tr><td align="center" valign="middle" >Y. Eun-Jun et al.’s Protocol</td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x52.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x53.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x54.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x55.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x56.png" xlink:type="simple"/></inline-formula></td></tr><tr><td align="center" valign="middle" >M. Nabil et al.’s Protocol</td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x57.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x58.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x59.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x60.png" xlink:type="simple"/></inline-formula></td><td align="center" valign="middle" ><inline-formula><inline-graphic xlink:href="http://html.scirp.org/file/6-7800260x61.png" xlink:type="simple"/></inline-formula></td></tr></tbody></table></table-wrap><table-wrap id="table3" ><label><xref ref-type="table" rid="table3">Table 3</xref></label><caption><title> Summarization of the defined protocols</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >Protocol</th><th align="center" valign="middle" >Security relies on</th><th align="center" valign="middle" >Method of Authentication</th><th align="center" valign="middle" >Design Principle</th></tr></thead><tr><td align="center" valign="middle" >W. Hsiang An et al.’s Protocol</td><td align="center" valign="middle" >Hash Function</td><td align="center" valign="middle" >Hybrid Key</td><td align="center" valign="middle" >ECC</td></tr><tr><td align="center" valign="middle" >C. Popescu’s Protocol</td><td align="center" valign="middle" >ECDLP</td><td align="center" valign="middle" >Public/Private Key pairs</td><td align="center" valign="middle" >Diffie-Hellman</td></tr><tr><td align="center" valign="middle" >L. Harn et al.’s Protocol</td><td align="center" valign="middle" >IFP</td><td align="center" valign="middle" >Public/Private Key pairs</td><td align="center" valign="middle" >Diffie-Hellman</td></tr><tr><td align="center" valign="middle" >Tseng’s et al.’s Protocol</td><td align="center" valign="middle" >DLP</td><td align="center" valign="middle" >Public/Private Key pairs</td><td align="center" valign="middle" >Diffie-Hellman</td></tr><tr><td align="center" valign="middle" >Y. Eun-Jun et al.’s Protocol</td><td align="center" valign="middle" >ECDLP</td><td align="center" valign="middle" >Password Based</td><td align="center" valign="middle" >ECC</td></tr><tr><td align="center" valign="middle" >M. Nabil et al.’s Protocol</td><td align="center" valign="middle" >ECDLP</td><td align="center" valign="middle" >Hybrid Key</td><td align="center" valign="middle" >ECC</td></tr></tbody></table></table-wrap><p>graphy. This paper discusses the KAP, their security requirements and examples of attacks that threat some of them. It presents the concept of one-way function which is considered the core of KAP design. Also, it explains some standardized protocols that are considered as a building block for most of the new protocols. It discusses how the researchers classify KAPs from their perspective and some examples of new protocols are listed. Finally, it presents some AKA protocols and applies simple comparative study on them. The number of new invented protocols is increasing as long as many attacks are appearing, so direction of the future researches about verifying their efficiency.</p></sec><sec id="s6"><title>Acknowledgements</title><p>We would like to thank to our supervisor Dr.Jayaprakash Kar for his valuable suggestions and comments that helped improving this works. This support is greatly appreciated.</p></sec></body><back><ref-list><title>References</title><ref id="scirp.53160-ref1"><label>1</label><mixed-citation publication-type="other" xlink:type="simple">Saha, M. and RoyChowdhury, D. (2009) Provably Secure Key Establishment Protocol Using One-Way Functions. Journal of Discrete Mathematical Sciences &amp; Cryptography, 12, 139-158.</mixed-citation></ref><ref id="scirp.53160-ref2"><label>2</label><mixed-citation publication-type="other" xlink:type="simple">Menezes, A., van Oorschot, P. and Vanstone, S. (2010) Handbook of Applied Cryptography. CRC Press, Boca Raton.</mixed-citation></ref><ref id="scirp.53160-ref3"><label>3</label><mixed-citation publication-type="other" xlink:type="simple">Vester&amp;arings, B. (2006) Analysis of Key Agreement Protocols, 1-46.</mixed-citation></ref><ref id="scirp.53160-ref4"><label>4</label><mixed-citation publication-type="other" xlink:type="simple">Dutta, R. and Barua, R. (2005) Overview of Key Agreement Protocols. Cryptology ePrint Archive, 1-46.</mixed-citation></ref><ref id="scirp.53160-ref5"><label>5</label><mixed-citation publication-type="other" xlink:type="simple">Diffie, W. and Hellman, M. (1976) New Directions in Cryptography. IEEE Transaction on Information Theory, 22, 644-654. http://dx.doi.org/10.1109/TIT.1976.1055638</mixed-citation></ref><ref id="scirp.53160-ref6"><label>6</label><mixed-citation publication-type="other" xlink:type="simple">Mohamed, N., Yasmine, A., Galal, E. and Amr, A. (2013) New Authenticated Key Agreement Protocols. International Multi Conference of Engineering and Computer Scientists, 1, 58-63</mixed-citation></ref><ref id="scirp.53160-ref7"><label>7</label><mixed-citation publication-type="other" xlink:type="simple">Elkamchouchi, H.M., Saleh, Y.A. and Sary, A.M. (2011) New Authenticated Key Agreement Protocols. International Conference on Computer Engineering &amp; Systems (ICCES), Cairo, 29 November 2011-1 December 2011, 58-63.</mixed-citation></ref><ref id="scirp.53160-ref8"><label>8</label><mixed-citation publication-type="other" xlink:type="simple">Boyd, C. and Mathuria, A. (2003) Protocols for Authentication and Key Establishment. Springer, Berlin, Heidelberg.</mixed-citation></ref><ref id="scirp.53160-ref9"><label>9</label><mixed-citation publication-type="other" xlink:type="simple">Lopez, J. and Dahab, R. (2000) An Overview of Elliptic Curve Cryptography. Technical report, Institute of Computing, State University of Campinas, Brazil, 1-35.</mixed-citation></ref><ref id="scirp.53160-ref10"><label>10</label><mixed-citation publication-type="other" xlink:type="simple">Kar, J. (2014) Provably Secure Online/Off-Line Identity-Based Signature Scheme for Wireless Sensor Network. International Journal of Network Security, Taiwan, 16, 26-36.</mixed-citation></ref><ref id="scirp.53160-ref11"><label>11</label><mixed-citation publication-type="other" xlink:type="simple">Harn, L., Hsin, W.J. and Mehta, M. (2005) Authenticated Diffie-Hellman Key Agreement Protocol Using a Single Cryptographic Assumption. IEEE Proceeding of Communication, 152, 404-410.</mixed-citation></ref><ref id="scirp.53160-ref12"><label>12</label><mixed-citation publication-type="other" xlink:type="simple">Wen, H.A., Lin, C.L. and Hwang, T. (2006) Provably Secure Authenticated Key Exchange Protocols for Low Power Computing Clients. Computer &amp; Security, 25, 106-113. http://dx.doi.org/10.1016/j.cose.2005.09.010</mixed-citation></ref><ref id="scirp.53160-ref13"><label>13</label><mixed-citation publication-type="other" xlink:type="simple">Kar, J. (2014) A Novel Construction of Certificateless Signcryption Scheme for Smart Card. In: Case Studies in Secure Computing Achievements and Trends, CRC Press, Taylor and Francis, New York, Chapter-22, 437-456.</mixed-citation></ref><ref id="scirp.53160-ref14"><label>14</label><mixed-citation publication-type="other" xlink:type="simple">Popescu, C. (2004) A Secure Authenticate Key Agreement Protocol. IEEE MELECON, Mediterranean, 12-15 May 2004, 783-786.</mixed-citation></ref><ref id="scirp.53160-ref15"><label>15</label><mixed-citation publication-type="other" xlink:type="simple">Tseng, Y.M. (2005) Efficient Authenticated Key Agreement Protocols Resistant to a Denial-of-Service Attack. International Journal of Network Management, 15, 193-202. http://dx.doi.org/10.1002/nem.561</mixed-citation></ref><ref id="scirp.53160-ref16"><label>16</label><mixed-citation publication-type="other" xlink:type="simple">Yoon, E.J. and Yoo, K.Y. (2005) New Efficient Simple Authenticated Key Agreement Protocol. Computing and Combinatorics, 3595, 945-954. http://dx.doi.org/10.1007/11533719_95</mixed-citation></ref><ref id="scirp.53160-ref17"><label>17</label><mixed-citation publication-type="other" xlink:type="simple">Nabil, M., Abouelseoud, Y., Elkobrosy, G. and Abdelrazek, A. (2013) Certificate-Based Authenticated Key Agreement Protocols. Proceeding of IEEE ICCAT, Computer Applications Technology (ICCAT), 2013 International Conference on Location City of Sousse, 20-22 January 2013, 1-7.</mixed-citation></ref><ref id="scirp.53160-ref18"><label>18</label><mixed-citation publication-type="other" xlink:type="simple">Kar, J. (2014) Authenticated Multiple-Key Establishment Protocol for Wireless Sensor Networks. In: Case Studies in Secure Computing Achievements and Trends, CRC Press, Taylor and Francis, New York, Chapter-04, 67-88.</mixed-citation></ref></ref-list></back></article>