<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.1 20151215//EN" "http://jats.nlm.nih.gov/publishing/1.1/JATS-journalpublishing1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:mml="http://www.w3.org/1998/Math/MathML" xml:lang="en" article-type="research-article" dtd-version="1.1">
<front>
<journal-meta>
<journal-id journal-id-type="pmc">CMC</journal-id>
<journal-id journal-id-type="nlm-ta">CMC</journal-id>
<journal-id journal-id-type="publisher-id">CMC</journal-id>
<journal-title-group>
<journal-title>Computers, Materials &#x0026; Continua</journal-title>
</journal-title-group>
<issn pub-type="epub">1546-2226</issn>
<issn pub-type="ppub">1546-2218</issn>
<publisher>
<publisher-name>Tech Science Press</publisher-name>
<publisher-loc>USA</publisher-loc>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">52405</article-id>
<article-id pub-id-type="doi">10.32604/cmc.2024.052405</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Article</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Design of an Efficient and Provable Secure Key Exchange Protocol for HTTP Cookies</article-title>
<alt-title alt-title-type="left-running-head">Design of an Efficient and Provable Secure Key Exchange Protocol for HTTP Cookies</alt-title>
<alt-title alt-title-type="right-running-head">Design of an Efficient and Provable Secure Key Exchange Protocol for HTTP Cookies</alt-title>
</title-group>
<contrib-group>
<contrib id="author-1" contrib-type="author">
<name name-style="western"><surname>Akram</surname><given-names>Waseem</given-names></name><xref ref-type="aff" rid="aff-1">1</xref></contrib>
<contrib id="author-2" contrib-type="author">
<name name-style="western"><surname>Mahmood</surname><given-names>Khalid</given-names></name><xref ref-type="aff" rid="aff-2">2</xref></contrib>
<contrib id="author-3" contrib-type="author">
<name name-style="western"><surname>ul Haq</surname><given-names>Hafiz Burhan</given-names></name><xref ref-type="aff" rid="aff-3">3</xref></contrib>
<contrib id="author-4" contrib-type="author">
<name name-style="western"><surname>Asif</surname><given-names>Muhammad</given-names></name><xref ref-type="aff" rid="aff-3">3</xref></contrib>
<contrib id="author-5" contrib-type="author">
<name name-style="western"><surname>Chaudhry</surname><given-names>Shehzad Ashraf</given-names></name><xref ref-type="aff" rid="aff-4">4</xref><xref ref-type="aff" rid="aff-5">5</xref></contrib>
<contrib id="author-6" contrib-type="author" corresp="yes">
<name name-style="western"><surname>Shon</surname><given-names>Taeshik</given-names></name><xref ref-type="aff" rid="aff-6">6</xref><email>tsshon@ajou.ac.kr</email></contrib>
<aff id="aff-1"><label>1</label><institution>Graduate School of Engineering Science and Technology, National Yunlin University of Science and Technology</institution>, <addr-line>Yunlin, 64002</addr-line>, <country>Taiwan</country></aff>
<aff id="aff-2"><label>2</label><institution>Future Technology Research Center, National Yunlin University of Science and Technology</institution>, <addr-line>Yunlin, 64002</addr-line>, <country>Taiwan</country></aff>
<aff id="aff-3"><label>3</label><institution>Department of Computer Science, Lahore Garrison University</institution>, <addr-line>Lahore, 54920</addr-line>, <country>Pakistan</country></aff>
<aff id="aff-4"><label>4</label><institution>Department of Computer Science and Information Technology, College of Engineering, Abu Dhabi University</institution>, <addr-line>Abu Dhabi, 69911</addr-line>, <country>United Arab Emirates</country></aff>
<aff id="aff-5"><label>5</label><institution>Department of Software Engineering, Faculty of Engineering and Architecture, Nisantasi University</institution>, <addr-line>Istanbul, 34398</addr-line>, <country>Turkey</country></aff>
<aff id="aff-6"><label>6</label><institution>Department of Cybersecurity, Ajou University</institution>, <addr-line>Suwon, 16499</addr-line>, <country>Republic of Korea</country></aff>
</contrib-group>
<author-notes>
<corresp id="cor1"><label>&#x002A;</label>Corresponding Author: Taeshik Shon. Email: <email>tsshon@ajou.ac.kr</email></corresp>
</author-notes>
<pub-date date-type="collection" publication-format="electronic">
<year>2024</year></pub-date>
<pub-date date-type="pub" publication-format="electronic"><day>18</day><month>7</month><year>2024</year></pub-date>
<volume>80</volume>
<issue>1</issue>
<fpage>263</fpage>
<lpage>280</lpage>
<history>
<date date-type="received">
<day>01</day>
<month>4</month>
<year>2024</year>
</date>
<date date-type="accepted">
<day>20</day>
<month>6</month>
<year>2024</year>
</date>
</history>
<permissions>
<copyright-statement>&#x00A9; 2024 Akram et al.</copyright-statement>
<copyright-year>2024</copyright-year>
<copyright-holder>Akram et al.</copyright-holder>
<license xlink:href="https://creativecommons.org/licenses/by/4.0/">
<license-p>This work is licensed under a <ext-link ext-link-type="uri" xlink:type="simple" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</ext-link>, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="TSP_CMC_52405.pdf"></self-uri>
<abstract>
<p>Cookies are considered a fundamental means of web application services for authenticating various Hypertext Transfer Protocol (HTTP) requests and maintains the states of clients&#x2019; information over the Internet. HTTP cookies are exploited to carry client patterns observed by a website. These client patterns facilitate the particular client&#x2019;s future visit to the corresponding website. However, security and privacy are the primary concerns owing to the value of information over public channels and the storage of client information on the browser. Several protocols have been introduced that maintain HTTP cookies, but many of those fail to achieve the required security, or require a lot of resource overheads. In this article, we have introduced a lightweight Elliptic Curve Cryptographic (ECC) based protocol for authenticating client and server transactions to maintain the privacy and security of HTTP cookies. Our proposed protocol uses a secret key embedded within a cookie. The proposed protocol is more efficient and lightweight than related protocols because of its reduced computation, storage, and communication costs. Moreover, the analysis presented in this paper confirms that proposed protocol resists various known attacks.</p>
</abstract>
<kwd-group kwd-group-type="author">
<kwd>Cookies</kwd>
<kwd>authentication protocol</kwd>
<kwd>impersonation attack</kwd>
<kwd>ECC</kwd>
</kwd-group>
<funding-group>
<award-group id="awg1">
<funding-source>Abu Dhabi University&#x2019;s Office of Research and Sponsored Programs</funding-source>
<award-id>19300810</award-id>
</award-group>
</funding-group>
</article-meta>
</front>
<body>
<sec id="s1">
<label>1</label>
<title>Introduction</title>
<p>With the advent of state-of-the-art technology, the use of the Internet to access cloud services, online shopping, and social networking sites is progressively becoming an everyday activity among people. When a client visits a particular website for the first time, the website sends a cookie file along with a unique client identifier and stores it in the client&#x2019;s system. In order to obtain information about the client without requiring the re-entry of the same information, whenever the client next visits the same website, the information of the client can be accessed using the stored cookie.</p>
<p>The website&#x2019;s cookies operate in such a manner that they can be read by two methods. Firstly, cookies are tied to HTTP requests and are recognized through the use of cookie headers. Secondly, they can be explicitly requested through an Application Programming Interface (API) call by JavaScript and sent to the server [<xref ref-type="bibr" rid="ref-1">1</xref>]. The cookies request-response mechanism amid the web client and server is defined in the <xref ref-type="fig" rid="fig-1">Fig. 1</xref>.</p>
<fig id="fig-1">
<label>Figure 1</label>
<caption>
<title>HTTP cookies request-response mechanism between web client and server</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_52405-fig-1.tif"/>
</fig>
<p>Conventionally, a cookie consists of numerous attributes, including value, name, path, expiration, and domain. The value attribute is used to store a client&#x2019;s personal information, such as the user&#x2019;s session ID, email address, and identification. The other attributes store unique information that can be used to create customized web pages in the user&#x2019;s browser. This unique information includes products added to the cart or browsing history of a client on a shopping website. Moreover, web cookies are used for the following: (a) cloud services, (b) saved shopping carts, (c) automatic logins, and (d) customized web pages. Furthermore, to evade a hot-linking attack [<xref ref-type="bibr" rid="ref-2">2</xref>]. A session mechanism can also be used with cookies. As the client excessively uses HTTP cookies. Cookies are transmitted across the Internet without any security structure. An adversary can easily access the confidential information stored in the &#x201C;value&#x201D; parameter through various cookie-stealing mechanisms.</p>
<p>Microsoft has identified existing security defects in Internet Explorer, where an adversary can steal confidential information from cookies stored in the browser. Likewise, attacks (e.g., Cross-Site Scripting (XSS)) can be launched to send malicious scripts to exploit the client&#x2019;s web browser. These malicious scripts can access any data in cookies stored by a client&#x2019;s browser, and this information can be used on the associated website. Additionally, cookies can be altered on some browsers, such as Mozilla Firefox, through malicious websites. It is possible to modify the cookie&#x2019;s parameters for malicious objectives. For instance, the login session can be extended by modifying the expiration-time parameter. The aforementioned security attacks highlight the problems of both the privacy and integrity of cookies.</p>
<p>Although cookies are widely used by users, their hazardous nature has become a significant concern. Recently, Microsoft has also observed a security deficiency in its Internet Explorer browser, where an adversary can easily steal personal information from stored web cookies. Since the Internet is a public communication channel, stored data can be easily accessed through eavesdropping. Any of the cookie&#x2019;s parameters can be tampered with for malicious purposes, such as using the session expiration parameter to extend the duration of the login session. The above-mentioned threats to security are caused by either of the following problems:
<list list-type="bullet">
<list-item>
<p>Cookie Confidentiality: In a cookie, personal information is exposed to eavesdropping whenever it is transmitted in plain text over the Internet. To ensure the privacy of the client, the value of the content, except the server, should not be exposed to anyone.</p></list-item>
<list-item>
<p>Cookie Integrity: Browsers store cookies, and these cookies are transmitted over the Internet without any security features. Hence, to manipulate websites, clients, or servers, these cookies are vulnerable to severe alteration.</p></list-item>
</list></p>
<p>The superiority of our proposed method is explained through comprehensive benchmarks demonstrating enhanced security and efficiency compared to existing solutions. The need for this method arises from its unique capability to secure HTTP cookies against evolving cybersecurity threats, thereby providing a robust solution where traditional protocols fall short.</p>
<sec id="s1_1">
<label>1.1</label>
<title>Motivation and Contributions</title>
<p>The communication between a web client and server over public channels exposes sensitive data to various security threats, necessitating a robust security framework for cookie storage infrastructure. A critical review of existing authentication protocols reveals significant security flaws, particularly in areas of confidentiality, integrity, and resistance to common cyberattacks such as session hijacking and XSS. To address these vulnerabilities, we introduce a secure and lightweight authentication protocol based on ECC.</p>
<p>Our primary contributions to this research work are as follows:
<list list-type="order">
<list-item>
<p>We propose an ECC-based protocol that authenticates client-server transactions securely, leveraging the computational efficiency and lower resource requirements of ECC.</p></list-item>
<list-item>
<p>Our protocol enhances the privacy of HTTP cookies by maintaining strict confidentiality and integrity, setting a new standard in secure communication.</p></list-item>
<list-item>
<p>It is designed to resist the major security attacks that have compromised previous protocols, offering substantial security benefits and remaining robust yet lightweight.</p></list-item>
<list-item>
<p>Performance comparisons with existing protocols demonstrate that our proposed solution achieves significant reductions in communication, computation, and storage costs, thereby addressing efficiency concerns effectively.</p></list-item>
</list></p>
<p>This work not only mitigates known vulnerabilities but also introduces innovative features that differentiate our protocol from existing solutions, making it a pioneering approach in the field of web security.</p>
</sec>
</sec>
<sec id="s2">
<label>2</label>
<title>Related Work</title>
<p>In this section, we review the related protocols for cookies. We investigate various cookie protocols, and after analyzing their flaws, we presented an efficient cookie protocol. There are significant limitations are shown in the protocol [<xref ref-type="bibr" rid="ref-3">3</xref>]. Firstly, high-level confidentiality is not offered in their protocol. Second, security against cookie replay attacks are not presented in their protocol. Third, their protocol does not use any procedure for key updating. A cookie protocol is presented by [<xref ref-type="bibr" rid="ref-4">4</xref>] in which a set of inter-dependent cookies are used, e.g., a password cookie, name cookie, life cookie, and a sealed cookie. This protocol does not offer the approach for the confidentiality of cookies.</p>
<p>A survey on web tracking was conducted with cookies by [<xref ref-type="bibr" rid="ref-5">5</xref>]. The information and functionality leaked to adversaries who intercept users&#x2019; cookies are scrutinized by [<xref ref-type="bibr" rid="ref-6">6</xref>]. In 2018, a side-channel attack was presented [<xref ref-type="bibr" rid="ref-7">7</xref>] against HTTPS that worked by injecting cookies. These studies illustrate the significance of avoiding injecting attacks and cookie hijacking. Various studies have examined security problems related to cookies [<xref ref-type="bibr" rid="ref-8">8</xref>,<xref ref-type="bibr" rid="ref-9">9</xref>]. Cookie confidentiality is not offered by protocol and cookie integrity is also not provided by the protocols [<xref ref-type="bibr" rid="ref-10">10</xref>,<xref ref-type="bibr" rid="ref-11">11</xref>], and only integrity and confidentiality are discussed in the protocols [<xref ref-type="bibr" rid="ref-12">12</xref>&#x2013;<xref ref-type="bibr" rid="ref-14">14</xref>].</p>
<p>After scrutinizing the protocols, we noticed a common problem the integrity of cookies is not verified by browsers before users start browsing the Internet. Internet protocol based communication methodologies are yet considered to be the most critical selection for setting up the Internet of Things environment [<xref ref-type="bibr" rid="ref-15">15</xref>&#x2013;<xref ref-type="bibr" rid="ref-17">17</xref>] and SG&#x2019;s networks covering buildings, homes, and more prominent neighborhoods also. The selection of Internet protocols based Smart Grid communications that every smart appliance like television sets, dishwashers, heaters, air conditioners, etc., and smart meter have their own IP addresses and help in quality Internet Engineering Task Force (IETF) schemes for remote management.</p>
<p>The application of power system security using bidirectional RNN-based network anomalous attack detection in cyber-physical systems. The relevance of our cookies security discussion as it highlights the use of advanced security techniques to protect critical infrastructure. Similarly, our cookies security protocol employs advanced methods to ensure the integrity and security of cookies, which are crucial in maintaining the security of web sessions in internet communications [<xref ref-type="bibr" rid="ref-18">18</xref>].</p>
<p>The studies of [<xref ref-type="bibr" rid="ref-19">19</xref>] highlight the importance of anomaly detection in securing communication systems, which is directly applicable to our cookies security protocol. However, reference [<xref ref-type="bibr" rid="ref-20">20</xref>] emphasizes the necessity of authorizing only legitimate communications, a principle that underpins our approach to ensuring the integrity and security of cookies. By employing advanced methods to detect anomalies and authorize communications, our protocol aims to mitigate potential cyber threats, ensuring a secure browsing experience for users.</p>
<p>However, already developed IP-based communication systems, e.g., the Internet, are distinctly possible problems by controlling information and notable delay-sensitive data, and also a wide range of possible malicious attacks, like denial of service attacks, replay attacks, and traffic analysis. So, Internet Protocol (IP) based Smart Grid communications will also be considered vulnerable to security problems. As a consequence, it is necessary to develop Smart Grid communication protocols properly to control all possible security threats. Additionally, not all entities may be trusted in Smart Grid communication. It is required for Smart Grid communication that the entities participating in communication are authenticated whether they are verified and exact if SG communication is utilizing IP-based protocols [<xref ref-type="bibr" rid="ref-21">21</xref>].</p>
<p>Finally, as a resultant, the SG communication framework would be considered an adequate verification mechanism [<xref ref-type="bibr" rid="ref-22">22</xref>&#x2013;<xref ref-type="bibr" rid="ref-26">26</xref>] so that malicious client is might not able to compromise the privacy or secrecy [<xref ref-type="bibr" rid="ref-27">27</xref>&#x2013;<xref ref-type="bibr" rid="ref-31">31</xref>] of the information sharing amid the supplier and client [<xref ref-type="bibr" rid="ref-32">32</xref>,<xref ref-type="bibr" rid="ref-33">33</xref>]. Current technologies in Content Delivery Networks (CDN) [<xref ref-type="bibr" rid="ref-34">34</xref>] and smart meters like Advanced Metering Infrastructures (AMI) lead to secrecy concerns because they rely upon centralizing consumption information of the client at smart meters. According to the Netherlander ruling, they concern about the privacy of mobile computing [<xref ref-type="bibr" rid="ref-35">35</xref>&#x2013;<xref ref-type="bibr" rid="ref-38">38</xref>], fog computing [<xref ref-type="bibr" rid="ref-39">39</xref>], and smart meters [<xref ref-type="bibr" rid="ref-40">40</xref>].</p>
<p>Chachra et al. [<xref ref-type="bibr" rid="ref-41">41</xref>] discuss how affiliate marketing networks provide a structure that connects independent marketers seeking compensation with merchants looking for customers. This interaction occurs when a client visits a site and the browser sends a request containing a cookie to the affiliate network via a tracking pixel. Should the client then purchase goods, the merchant compensates the affiliate network, which in turn pays the independent marketer. Adversaries exploit this mechanism by inserting their own cookies into clients&#x2019; browsers&#x2014;a tactic known as cookie stuffing. This fraudulent activity diverts revenue intended for legitimate marketers. The paper provides a measurement-based classification of these cookie-filling scams in online marketing, analyzing the types of affiliates and networks targeted, and the specific fraud tactics employed. It also notes that larger networks are more frequently targeted than smaller, merchant-run affiliate programs. The methodology outlined in the paper is designed to meticulously analyze and measure the performance and operational strategies of large affiliate programs such as Rakuten LinkShare, ShareASale, HostGator Affiliate Program, Amazon Associates Program, CJ Affiliate, and ClickBank. Our approach involves a systematic identification process starting with the targeted merchant, moving through the affiliate network, and down to the specific affiliate ID.</p>
<p>The initial step in our methodology is the identification of the cookies and URLs used by affiliates. This is achieved by gathering online information and, where necessary, by registering with the affiliate programs to gain firsthand data. Each Publisher ID is uniquely linked to an Affiliate ID, facilitating a clear and organized tracking system. Further refining our tracking process, we utilize Google Chrome&#x2019;s extension, Afftracker. This tool enhances our ability to accurately track and associate each Affiliate ID with the domain of the corresponding merchant. By doing so, we can effectively dissect and understand the flow of traffic and the attribution of sales to respective affiliates. This methodical approach not only helps in pinpointing the performance metrics of each affiliate program but also aids in understanding the dynamics between merchants and affiliates, providing a comprehensive overview of affiliate marketing practices across different platforms.</p>
<p>In light of the prevalence of affiliate marketing and the potential risks associated with it, such as cookie stuffing fraud, the above-proposed strategy, based on the Secure Key Exchange Protocol for HTTP Cookies, was carefully examined for its confidentiality and proficiency. By conducting a comparative analysis with existing literature and techniques from relevant investigations, our study sought to address the pressing need for enhanced security measures in cookie management. The results of our investigation revealed that the proposed cookies protocol not only mitigates the risks associated with fraudulent activities such as cookie stuffing but also significantly improves the overall security and effectiveness of cookie handling in web browsing environments. These findings underscore the importance and superiority of our proposed method in comparison to existing approaches, highlighting its potential to provide robust protection against evolving threats in online advertising.</p>
</sec>
<sec id="s3">
<label>3</label>
<title>Preliminaries</title>
<p>In the current section, we explained the notation table and basics of cryptography, such as hash function, ECC, ECDLP, and CDHP. Furthermore, the adversarial model is described to know the abilities of the <monospace>A</monospace>.</p>
<sec id="s3_1">
<label>3.1</label>
<title>Elliptic Curve Cryptography (ECC)</title>
<p>The basics related to ECC used throughout the research are illustrated in this subsection. ECC is based on any chosen real elliptic curve such as <inline-formula id="ieqn-1"><mml:math id="mml-ieqn-1"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x003A;</mml:mo><mml:msup><mml:mi>y</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:msup><mml:mi>x</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msup><mml:mo>+</mml:mo><mml:mi>a</mml:mi><mml:mi>x</mml:mi><mml:mo>+</mml:mo><mml:mi>b</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mtext>mod&#xA0;</mml:mtext></mml:mrow><mml:mi>p</mml:mi></mml:math></inline-formula>. Whereas, <inline-formula id="ieqn-2"><mml:math id="mml-ieqn-2"><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mrow><mml:mi mathvariant="normal">&#x03F5;</mml:mi></mml:mrow><mml:mtext>&#x00A0;</mml:mtext><mml:msub><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-3"><mml:math id="mml-ieqn-3"><mml:mn>4</mml:mn><mml:msup><mml:mi>a</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msup><mml:mo>+</mml:mo><mml:mn>27</mml:mn><mml:msup><mml:mi>b</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msup><mml:mspace width="thinmathspace" /><mml:mi>m</mml:mi><mml:mi>o</mml:mi><mml:mi>d</mml:mi><mml:mtext>&#x00A0;</mml:mtext><mml:mi>p</mml:mi><mml:mo>&#x2260;</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula> for any large prime number <italic>p</italic>. The curve is defined by the integers <inline-formula id="ieqn-4"><mml:math id="mml-ieqn-4"><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. The points (<italic>x</italic>, <italic>y</italic>) over <inline-formula id="ieqn-5"><mml:math id="mml-ieqn-5"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> should verify the previous ECC equations. Repetitive addition is achieved through scalar multiplication defined as <inline-formula id="ieqn-6"><mml:math id="mml-ieqn-6"><mml:mi>u</mml:mi><mml:mi>V</mml:mi><mml:mo>=</mml:mo><mml:mi>V</mml:mi><mml:mo>+</mml:mo><mml:mi>V</mml:mi><mml:mo>+</mml:mo><mml:mi>V</mml:mi><mml:mo>+</mml:mo><mml:mi>V</mml:mi><mml:mo>+</mml:mo><mml:mi>V</mml:mi><mml:mo>+</mml:mo><mml:mo>&#x2026;</mml:mo><mml:mo>+</mml:mo><mml:mi>V</mml:mi></mml:math></inline-formula>(<italic>u</italic> times), where <italic>V</italic> is a point over <inline-formula id="ieqn-7"><mml:math id="mml-ieqn-7"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> also <inline-formula id="ieqn-8"><mml:math id="mml-ieqn-8"><mml:mi>u</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x03F5;</mml:mi></mml:mrow><mml:msub><mml:mi>F</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. Moreover, the same level of security is provided by ECC as compared to traditional key cryptography such as DSA and RSA with smaller key size [<xref ref-type="bibr" rid="ref-42">42</xref>].</p>
<sec id="s3_1_1">
<label>3.1.1</label>
<title>Discrete Logarithm Problem Aimed at Elliptic Curve (ECDLP)</title>
<p>Two specific random points <inline-formula id="ieqn-9"><mml:math id="mml-ieqn-9"><mml:mi>V</mml:mi><mml:mo>,</mml:mo><mml:mi>X</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x03F5;</mml:mi></mml:mrow><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>, calculate a scalar <italic>u</italic> such that <inline-formula id="ieqn-10"><mml:math id="mml-ieqn-10"><mml:mi>V</mml:mi><mml:mo>=</mml:mo><mml:mi>u</mml:mi><mml:mi>X</mml:mi></mml:math></inline-formula>. The chances of <monospace>A</monospace> that he can compute <italic>u</italic> in <italic>t</italic> (polynomial time) is stated as: <inline-formula id="ieqn-11"><mml:math id="mml-ieqn-11"><mml:mi>A</mml:mi><mml:mi>D</mml:mi><mml:msubsup><mml:mi>V</mml:mi><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:mi>h</mml:mi></mml:mrow></mml:msubsup><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>t</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>=</mml:mo><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>b</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>V</mml:mi><mml:mo>,</mml:mo><mml:mi>X</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>x</mml:mi><mml:mo>&#x003A;</mml:mo><mml:mi>x</mml:mi><mml:mi>&#x03F5;</mml:mi><mml:msub><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mo>]</mml:mo></mml:mrow></mml:math></inline-formula>. The assumptions of ECDLP states that <inline-formula id="ieqn-12"><mml:math id="mml-ieqn-12"><mml:mi>A</mml:mi><mml:mi>D</mml:mi><mml:msubsup><mml:mi>V</mml:mi><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>E</mml:mi><mml:mi>C</mml:mi><mml:mi>D</mml:mi><mml:mi>L</mml:mi><mml:mi>P</mml:mi></mml:mrow></mml:msubsup><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mtext>t</mml:mtext></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>&#x2264;</mml:mo><mml:mrow><mml:mi mathvariant="normal">&#x03F5;</mml:mi></mml:mrow></mml:math></inline-formula>.</p>
</sec>
<sec id="s3_1_2">
<label>3.1.2</label>
<title>Computational Diffie-Hellman Problem (CDHP)</title>
<p>Let <italic>C</italic> be a cyclic group of order <italic>p</italic> with generator <italic>c</italic> and two arbitrary numbers <inline-formula id="ieqn-13"><mml:math id="mml-ieqn-13"><mml:mi>&#x03B1;</mml:mi><mml:mo>,</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x03F5;</mml:mi></mml:mrow><mml:msubsup><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x2217;</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>. Computationally it is absurd to compute c<sup>&#x03B1;&#x03B2;</sup> on the input <inline-formula id="ieqn-14"><mml:math id="mml-ieqn-14"><mml:mrow><mml:mo>(</mml:mo><mml:mi>c</mml:mi><mml:mo>,</mml:mo><mml:msup><mml:mi>c</mml:mi><mml:mrow><mml:mi>&#x03B1;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mi>c</mml:mi><mml:mrow><mml:mi>&#x03B2;</mml:mi></mml:mrow></mml:msup><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula>. In other words, an attacker <monospace>A</monospace> has advantage &#x03B4; in solving the Computational Diffie-Hellman Problem (CDHP) in (<italic>C</italic>, <italic>p</italic>, <italic>c</italic>) if: <inline-formula id="ieqn-15"><mml:math id="mml-ieqn-15"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mi>A</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>c</mml:mi><mml:mo>,</mml:mo><mml:msup><mml:mi>c</mml:mi><mml:mrow><mml:mi>&#x03B1;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mi>c</mml:mi><mml:mrow><mml:mi>&#x03B2;</mml:mi></mml:mrow></mml:msup><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msup><mml:mi>c</mml:mi><mml:mrow><mml:mi>&#x03B1;</mml:mi><mml:mi>&#x03B2;</mml:mi></mml:mrow></mml:msup><mml:mo>&#x2265;</mml:mo><mml:mi>&#x03B4;</mml:mi><mml:mo>]</mml:mo></mml:mrow></mml:math></inline-formula> where the probability is taken over the arbitrary choices<inline-formula id="ieqn-16"><mml:math id="mml-ieqn-16"><mml:mo>,</mml:mo><mml:mi>&#x03B2;</mml:mi><mml:mrow><mml:mi mathvariant="normal">&#x03F5;</mml:mi></mml:mrow><mml:msubsup><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x2217;</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula> and number of bits consumed by the attacker <monospace>A</monospace>.</p>
</sec>
</sec>
<sec id="s3_2">
<label>3.2</label>
<title>Hash Function</title>
<p>A deterministic mathematical technique known as a Collison-Resistant one-way hash function, or <inline-formula id="ieqn-17"><mml:math id="mml-ieqn-17"><mml:mi>h</mml:mi><mml:mo>&#x003A;</mml:mo><mml:msup><mml:mrow><mml:mo>(</mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mo>&#x2217;</mml:mo></mml:mrow></mml:msup><mml:mo stretchy="false">&#x2192;</mml:mo><mml:msubsup><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x2217;</mml:mo></mml:mrow></mml:msubsup></mml:math></inline-formula>, takes variable length inputs and creates fixed length outputs, such as <italic>b</italic> bits. The term <inline-formula id="ieqn-18"><mml:math id="mml-ieqn-18"><mml:mi>A</mml:mi><mml:mi>D</mml:mi><mml:msubsup><mml:mi>V</mml:mi><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:mi>h</mml:mi></mml:mrow></mml:msubsup><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:mtext>rt</mml:mtext></mml:mrow><mml:mo>)</mml:mo></mml:mrow></mml:math></inline-formula> refers to an adversary&#x2019;s advantage in locating a hash collision in run time <italic>rt</italic>. Then <inline-formula id="ieqn-19"><mml:math id="mml-ieqn-19"><mml:mi>A</mml:mi><mml:mi>D</mml:mi><mml:msubsup><mml:mi>V</mml:mi><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:mi>h</mml:mi></mml:mrow></mml:msubsup><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:mtext>rt</mml:mtext></mml:mrow><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>b</mml:mi><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mi>&#x03F5;</mml:mi><mml:msub><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mi>A</mml:mi><mml:mo>&#x003A;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mi>k</mml:mi><mml:mn>1</mml:mn><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x2260;</mml:mo><mml:mi>h</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>,</mml:mo><mml:mi>h</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>]</mml:mo></mml:mrow></mml:math></inline-formula>, where the probability of random event <italic>X</italic> is <inline-formula id="ieqn-20"><mml:math id="mml-ieqn-20"><mml:mi>P</mml:mi><mml:mi>r</mml:mi><mml:mi>b</mml:mi><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mtext>X</mml:mtext></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:math></inline-formula>, and the the pairs <inline-formula id="ieqn-21"><mml:math id="mml-ieqn-21"><mml:mrow><mml:mo>(</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>k</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>)</mml:mo></mml:mrow><mml:mi>&#x03F5;</mml:mi><mml:msub><mml:mi>Z</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, indicates that the input <italic>k</italic><sub><italic>1</italic></sub> and <italic>k</italic><sub><italic>2</italic></sub> are randomly chosen by <monospace>A</monospace>. An <inline-formula id="ieqn-22"><mml:math id="mml-ieqn-22"><mml:mo stretchy="false">(</mml:mo><mml:mi>&#x03F5;</mml:mi><mml:mo>,</mml:mo><mml:mi>r</mml:mi><mml:mi>t</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>-adversary <monospace>A</monospace> attacking the collision resistance of <italic>h</italic>(.) means that the run time of <monospace>A</monospace> is at most <italic>rt</italic> and that <inline-formula id="ieqn-23"><mml:math id="mml-ieqn-23"><mml:mi>A</mml:mi><mml:mi>D</mml:mi><mml:msubsup><mml:mi>V</mml:mi><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>H</mml:mi><mml:mi>a</mml:mi><mml:mi>s</mml:mi><mml:mi>h</mml:mi></mml:mrow></mml:msubsup><mml:mrow><mml:mo>(</mml:mo><mml:mi>r</mml:mi><mml:mi>t</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo>&#x2264;</mml:mo><mml:mi>&#x03F5;</mml:mi></mml:math></inline-formula>.</p>
</sec>
<sec id="s3_3">
<label>3.3</label>
<title>Adversarial Model</title>
<p>In this subsection, we present the adversarial model as defined in [<xref ref-type="bibr" rid="ref-43">43</xref>], capabilities of the <monospace>A</monospace>, based on protocol security definition are as follows:
<list list-type="order">
<list-item>
<p>During communication between entities, <monospace>A</monospace> has full access to the communication channel (public channel).</p></list-item>
<list-item>
<p><monospace>A</monospace> can intercept, modify and replay the message or information sent on the communication channel.</p></list-item>
<list-item>
<p><monospace>A</monospace> can be a legal client on the network.</p></list-item>
<list-item>
<p>The dynamic identity of the client can be extracted by <monospace>A</monospace>.</p></list-item>
<list-item>
<p>Server is considered secure and <monospace>A</monospace> cannot extract server&#x2019;s private key.</p></list-item>
<list-item>
<p><monospace>A</monospace> can find out previous shared session keys.</p></list-item>
</list></p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Proposed Protocol</title>
<p>This section provides a detailed description of our proposed protocol based on ECC. Where a client sends a pseudo-identity to the server to be registered himself, the server sends a message with parameters for completion of registration. After completion of the registration process, the client sends a login request message. Receiving a request message, a server transmits parameters with a challenge request message, and after that, when all authentication gets completed, the session key is shared to start the services between server and client. An operational procedure and comparison with other related protocols are also provided.</p>
<p>The proposed protocol consists of three major phases as described in below subsections. Primarily, we used both random numbers and time stamps for protection against several attacks. The notations are listed in <xref ref-type="table" rid="table-1">Table 1</xref> and description and analysis of the proposed protocol are presented in Proposed Protocol.</p>
<table-wrap id="table-1">
<label>Table 1</label>
<caption>
<title>Notation table</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Notations</th>
<th colspan="2">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><italic>ID</italic><sub><italic>u</italic></sub></td>
<td colspan="2">Identity of client</td>
</tr>
<tr>
<td><italic>S</italic></td>
<td colspan="2">Secret key of server</td>
</tr>
<tr>
<td><italic>P</italic></td>
<td colspan="2">Base point of the elliptic curve <inline-formula id="ieqn-24"><mml:math id="mml-ieqn-24"><mml:msub><mml:mi>E</mml:mi><mml:mrow><mml:mi>p</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mi>a</mml:mi><mml:mo>,</mml:mo><mml:mi>b</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
</tr>
<tr>
<td><italic>Cu</italic><sub>1</sub></td>
<td colspan="2">Non sensitive information</td>
</tr>
<tr>
<td><italic>Cu</italic><sub>2</sub></td>
<td colspan="2">Sensitive information</td>
</tr>
<tr>
<td><italic>h</italic>(.)</td>
<td colspan="2">Hash functions</td>
</tr>
<tr>
<td><italic>SK</italic></td>
<td colspan="2">Shared session key between client and server</td>
</tr>
<tr>
<td>&#x2225;</td>
<td colspan="2">Concatenation</td>
</tr>
<tr>
<td>&#x2295;</td>
<td colspan="2">XoR operation</td>
</tr>
<tr>
<td><monospace>A</monospace></td>
<td colspan="2">An adversary</td>
</tr>
<tr>
<td><italic>a</italic><sub><italic>u</italic></sub>, <italic>r</italic><sub><italic>u</italic></sub></td>
<td colspan="2">Random numbers of client</td>
</tr>
<tr>
<td><italic>E</italic>, <italic>B</italic>, <italic>C</italic></td>
<td colspan="2">Variables</td>
</tr>
<tr>
<td><italic>T</italic><sub>1</sub>, <italic>T</italic><sub>2</sub>, <italic>T</italic><sub>3</sub>, <italic>T</italic><sub>4</sub></td>
<td colspan="2">Current time stamps</td>
</tr>
<tr>
<td><italic>Client</italic></td>
<td></td>
<td>Server</td>
</tr>
<tr>
<td><bold>Registration Phase</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Selects <italic>ID</italic><sub><italic>u</italic></sub></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Generate a random number <italic>r</italic><sub><italic>u</italic></sub> and compute <inline-formula id="ieqn-25"><mml:math id="mml-ieqn-25"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula></td>
<td/>
<td/>
</tr>
<tr>
<td/>
<td><inline-formula id="ieqn-26"><mml:math id="mml-ieqn-26"><mml:munder><mml:mrow><mml:mo>{</mml:mo><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mo>,</mml:mo></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>}</mml:mo></mml:mrow><mml:mo>&#x2192;</mml:mo></mml:munder></mml:math></inline-formula></td>
<td/>
</tr>
<tr>
<td/>
<td/>
<td>Stores <italic>PID</italic><sub><italic>u</italic></sub> in its database</td>
</tr>
<tr>
<td></td>
<td></td>
<td>Compute <inline-formula id="ieqn-27"><mml:math id="mml-ieqn-27"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:mi>D</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
</tr>
<tr>
<td></td>
<td></td>
<td>Generate <inline-formula id="ieqn-28"><mml:math id="mml-ieqn-28"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>s</mml:mi><mml:mi>p</mml:mi></mml:math></inline-formula></td>
</tr>
<tr>
<td></td>
<td><inline-formula id="ieqn-29"><mml:math id="mml-ieqn-29"><mml:munder><mml:mrow><mml:mo>{</mml:mo><mml:mi>i</mml:mi><mml:mi>s</mml:mi><mml:mi>s</mml:mi><mml:mi>u</mml:mi><mml:mi>e</mml:mi><mml:mi>s</mml:mi><mml:mspace width="thinmathspace" /><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>j</mml:mi><mml:mo>,</mml:mo></mml:mrow></mml:msub><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>}</mml:mo></mml:mrow><mml:mo>&#x2190;</mml:mo></mml:munder></mml:math></inline-formula></td>
<td></td>
</tr>
<tr>
<td>Client stores <italic>A</italic><sub><italic>i</italic></sub> and <italic>P</italic><sub><italic>k</italic></sub> for further uses</td>
<td></td>
<td></td>
</tr>
<tr>
<td><bold>Login and Authentication Phase</bold></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Selects <italic>a</italic><sub><italic>u</italic></sub> <inline-formula id="ieqn-30"><mml:math id="mml-ieqn-30"><mml:mi>B</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>s</mml:mi><mml:mi>P</mml:mi></mml:math></inline-formula></td>
<td></td>
<td></td>
</tr>
<tr>
<td><inline-formula id="ieqn-31"><mml:math id="mml-ieqn-31"><mml:mi>C</mml:mi><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo symmetric="true">&#x2016;</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo symmetric="true">&#x2016;</mml:mo></mml:mrow><mml:mi>T</mml:mi><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
<td/>
<td/>
</tr>
<tr>
<td/>
<td><inline-formula id="ieqn-32"><mml:math id="mml-ieqn-32"><mml:munder><mml:mrow><mml:mo>{</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>B</mml:mi><mml:mo>,</mml:mo><mml:mi>C</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>}</mml:mo></mml:mrow><mml:mo>&#x2192;</mml:mo></mml:munder></mml:math></inline-formula></td>
<td/>
</tr>
<tr>
<td/>
<td/>
<td>Check time stamp <inline-formula id="ieqn-33"><mml:math id="mml-ieqn-33"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2264;</mml:mo><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow><mml:mi>T</mml:mi></mml:math></inline-formula></td>
</tr>
<tr>
<td></td>
<td></td>
<td>abort if not equal</td>
</tr>
<tr>
<td/>
<td/>
<td><inline-formula id="ieqn-34"><mml:math id="mml-ieqn-34"><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mi>s</mml:mi><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msup><mml:mi>B</mml:mi></mml:math></inline-formula></td>
</tr>
<tr>
<td></td>
<td></td>
<td><inline-formula id="ieqn-35"><mml:math id="mml-ieqn-35"><mml:mi>C</mml:mi><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover><mml:mo>&#x2061;</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:mi>s</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula></td>
</tr>
<tr>
<td></td>
<td></td>
<td>Session aborts, if above equation not verified</td>
</tr>
<tr>
<td/>
<td/>
<td>Generates <inline-formula id="ieqn-36"><mml:math id="mml-ieqn-36"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-37"><mml:math id="mml-ieqn-37"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula></td>
</tr>
<tr>
<td/>
<td/>
<td><inline-formula id="ieqn-38"><mml:math id="mml-ieqn-38"><mml:mi>E</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>&#x2295;</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula></td>
</tr>
<tr>
<td/>
<td><inline-formula id="ieqn-39"><mml:math id="mml-ieqn-39"><mml:munder><mml:mrow><mml:mo>{</mml:mo><mml:mi>E</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mtext>T</mml:mtext></mml:mrow><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>}</mml:mo></mml:mrow><mml:mo>&#x2190;</mml:mo></mml:munder></mml:math></inline-formula></td>
<td><inline-formula id="ieqn-40"><mml:math id="mml-ieqn-40"><mml:mi>S</mml:mi><mml:mi>K</mml:mi><mml:mo>=</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo fence="false" stretchy="false">&#x2016;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula></td>
</tr>
<tr>
<td colspan="2">Check time stamp <inline-formula id="ieqn-41"><mml:math id="mml-ieqn-41"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>4</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2264;</mml:mo><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow><mml:mi>T</mml:mi></mml:math></inline-formula> abort if not fresh</td>
<td/>
</tr>
<tr>
<td><inline-formula id="ieqn-42"><mml:math id="mml-ieqn-42"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>&#x2295;</mml:mo><mml:mi>E</mml:mi></mml:math></inline-formula></td>
<td></td>
<td></td>
</tr>
<tr>
<td><italic>SK <inline-formula id="ieqn-43"><mml:math id="mml-ieqn-43"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula></italic> (<italic>A</italic><sub><italic>i</italic></sub>&#x2225;<italic>a</italic><sub><italic>u</italic></sub><italic>P</italic>&#x2225;<italic>C</italic><sub><italic>u</italic>2</sub>&#x2225;<italic>T</italic><sub>2</sub>)</td>
<td/>
<td/>
</tr>
<tr>
<td colspan="3" align="center"><inline-graphic xlink:href="CMC_52405-inline-1.tif"/></td>
</tr>
</tbody>
</table>
</table-wrap>
<p>A detailed description of the above phases is given as follows.</p>
<sec id="s4_1">
<label>4.1</label>
<title>Registration Phase</title>
<p>In this section, we present the client registration process with the server. Following steps are executed, once a client initiates a registration request:</p>
<p>REG Step 1: The client selects an identity <inline-formula id="ieqn-44"><mml:math id="mml-ieqn-44"><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> that will be unique to get services from the server, generates a random client number <inline-formula id="ieqn-45"><mml:math id="mml-ieqn-45"><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and computes <inline-formula id="ieqn-46"><mml:math id="mml-ieqn-46"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> where <inline-formula id="ieqn-47"><mml:math id="mml-ieqn-47"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> is the pseudo-identity of a client that is generated by concatenation of identity and random number <inline-formula id="ieqn-48"><mml:math id="mml-ieqn-48"><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> of the client which is protected with one-way hash function to make secure in order to make client&#x2019;s identity anonymous. Then the client sends both <inline-formula id="ieqn-49"><mml:math id="mml-ieqn-49"><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-50"><mml:math id="mml-ieqn-50"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> over a secure channel to get himself registered with the server to get services from the server.</p>
<p>REG Step 2: Server stores the <inline-formula id="ieqn-51"><mml:math id="mml-ieqn-51"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> in its database for the later usage and computes <inline-formula id="ieqn-52"><mml:math id="mml-ieqn-52"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:mi>D</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> where concatenation of <inline-formula id="ieqn-53"><mml:math id="mml-ieqn-53"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and secret key <italic>s</italic> by hash function.</p>
<p>REG Step 3: After calculation of <italic>A</italic><sub><italic>i</italic></sub>, the secret key multiply with a large prime number and make a copy as <inline-formula id="ieqn-54"><mml:math id="mml-ieqn-54"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>s</mml:mi><mml:mi>P</mml:mi></mml:math></inline-formula>; at the end of the registration phase, the server returns a pair (<inline-formula id="ieqn-55"><mml:math id="mml-ieqn-55"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, <inline-formula id="ieqn-56"><mml:math id="mml-ieqn-56"><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>) to the client and the client keeps this pair for further usage.</p>
</sec>
<sec id="s4_2">
<label>4.2</label>
<title>Login and Authentication Phase</title>
<p>This section presents the login and authentication phase of the proposed scheme, which is also summarized in Proposed Protocol.</p>
<p>LA Step 1:</p>
<p>The client selects a random number <italic>a</italic><sub><italic>u</italic></sub> and calculates an equation <inline-formula id="ieqn-57"><mml:math id="mml-ieqn-57"><mml:mi>B</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>s</mml:mi><mml:mi>P</mml:mi></mml:math></inline-formula> for <italic>s</italic>. Furthermore, stored parameters <italic>A</italic><sub><italic>i</italic></sub>, <italic>a</italic><sub><italic>u</italic></sub><italic>P</italic><sub><italic>k</italic></sub> and time stamp <italic>T</italic><sub>1</sub> in the client&#x2019;s database, he computes an equation in the following manner <inline-formula id="ieqn-58"><mml:math id="mml-ieqn-58"><mml:mi>C</mml:mi><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>T</mml:mi><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. After the calculation of the above equation, the client transmits the request message containing <inline-formula id="ieqn-59"><mml:math id="mml-ieqn-59"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, <italic>B</italic>, <italic>C</italic>, and <italic>T</italic><sub>1</sub> to the server for login over a public channel.</p>
<p>LA Step 2:</p>
<p>After the successful receiving of message request containing <inline-formula id="ieqn-60"><mml:math id="mml-ieqn-60"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>B</mml:mi><mml:mo>,</mml:mo><mml:mi>C</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula>, the server checks the time stamp <inline-formula id="ieqn-61"><mml:math id="mml-ieqn-61"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2264;</mml:mo><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow><mml:mi>T</mml:mi></mml:math></inline-formula> to check the freshness of message. The server calculates <italic>a</italic><sub><italic>u</italic></sub><italic>P &#x003D; s</italic><sup><italic>-1</italic></sup><italic>B</italic>. Otherwise, if the time stamp is not fresh, the session will be abandoned. Then server computes and verify <italic>C</italic> <inline-formula id="ieqn-62"><mml:math id="mml-ieqn-62"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <italic>h</italic>(<italic>h</italic>(<italic>PID</italic><sub><italic>u</italic></sub> &#x2225;<italic>s</italic>)&#x2225;<italic>a</italic><sub><italic>u</italic></sub><italic>P</italic>&#x2225;<italic>T</italic><sub><italic>1</italic></sub>). If this verification is not authenticated, then the session will be aborted right here; otherwise, the server generates cookies <italic>C</italic><sub><italic>u</italic>1</sub> and <italic>C</italic><sub><italic>u</italic>2</sub>. Where, <italic>C</italic><sub><italic>u</italic>1</sub> is non sensitive information and <italic>C</italic><sub><italic>u</italic>2</sub> is sensitive information. Then calculates the equation <inline-formula id="ieqn-63"><mml:math id="mml-ieqn-63"><mml:mi>E</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>&#x2295;</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> that becomes an unknown value. After that, creates a session key <italic>SK</italic> through the equation <inline-formula id="ieqn-64"><mml:math id="mml-ieqn-64"><mml:mi>S</mml:mi><mml:mi>K</mml:mi><mml:mo>=</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>. Calculated parameters <italic>E</italic>, <italic>C</italic><sub><italic>u</italic>1</sub>, and <italic>T</italic><sub>3</sub> send to the client so that he can check whether the server is trusted or not.</p>
<p>LA Step 3:</p>
<p>In order to authenticate the receiving challenge message from the server containing <italic>E</italic>, <italic>C</italic><sub><italic>u</italic>1</sub>, <italic>T</italic><sub>2</sub> the client checks the time stamp <inline-formula id="ieqn-65"><mml:math id="mml-ieqn-65"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>4</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2212;</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo>&#x2264;</mml:mo><mml:mrow><mml:mi mathvariant="normal">&#x0394;</mml:mi></mml:mrow><mml:mi>T</mml:mi></mml:math></inline-formula>. Client computes <inline-formula id="ieqn-66"><mml:math id="mml-ieqn-66"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>&#x2295;</mml:mo><mml:mi>E</mml:mi></mml:math></inline-formula>. Otherwise, the session time will be aborted if the time stamp is not fresh. After calculations of the above values, the client gets checks the session key <inline-formula id="ieqn-67"><mml:math id="mml-ieqn-67"><mml:mi>S</mml:mi><mml:mi>K</mml:mi></mml:math></inline-formula> <inline-formula id="ieqn-68"><mml:math id="mml-ieqn-68"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <inline-formula id="ieqn-69"><mml:math id="mml-ieqn-69"><mml:mi>h</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>. This procedure outlines the method by which a session key is securely shared between the client and server. Once the session key is established and mutual authentication is confirmed, the client is authorized to access services provided by the server.</p>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Security Analysis</title>
<p>In <xref ref-type="sec" rid="s5">Section 5</xref>, we provide a quick overview of both formal and informal security evaluations. These introductory remarks lay the groundwork for the full examination of the security characteristics and effectiveness of our suggested protocol in the following subsections.</p>
<sec id="s5_1">
<label>5.1</label>
<title>Information Security Analysis</title>
<p>The correctness and security of the proposed scheme are shown in the current section. Analysis of this scheme shows its robustness, improving the effectiveness of security and defense from different kinds of attacks, which are discussed in given below.</p>
<sec id="s5_1_1">
<label>5.1.1</label>
<title>Ensuring of Mutual Authentication</title>
<p>The mutual authentication between client and server is ensured as following steps. The server authenticates the client by checking <inline-formula id="ieqn-70"><mml:math id="mml-ieqn-70"><mml:mi>C</mml:mi></mml:math></inline-formula> <inline-formula id="ieqn-71"><mml:math id="mml-ieqn-71"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <inline-formula id="ieqn-72"><mml:math id="mml-ieqn-72"><mml:mi>h</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>.</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> and <italic>a</italic><sub><italic>u</italic></sub><italic>P</italic> are needed to calculate <italic>C</italic> successfully by <monospace>A</monospace>. The computation of <inline-formula id="ieqn-73"><mml:math id="mml-ieqn-73"><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> and <italic>a</italic><sub><italic>u</italic></sub><italic>P</italic> imply the secret key <italic>s</italic> of the server, which is not known by <monospace>A</monospace>. So, only the legal server can authenticate the client. Likewise, the client authenticates server by computing <inline-formula id="ieqn-74"><mml:math id="mml-ieqn-74"><mml:mi>S</mml:mi><mml:mi>K</mml:mi></mml:math></inline-formula> <inline-formula id="ieqn-75"><mml:math id="mml-ieqn-75"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <inline-formula id="ieqn-76"><mml:math id="mml-ieqn-76"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>, <monospace>A</monospace> needs to calculate the <italic>A</italic><sub><italic>i</italic></sub> to get access but it requires secret key <italic>s</italic> of server. Furthermore, adversary is unable to compute <inline-formula id="ieqn-77"><mml:math id="mml-ieqn-77"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>.</p>
</sec>
<sec id="s5_1_2">
<label>5.1.2</label>
<title>Providing Client Anonymity</title>
<p>Anonymity and privacy are considered significant features during making an authentication protocol. If anonymity is revealed to any <monospace>A</monospace>, the client&#x2019;s information, like location, social circle, moving history, and priorities, can be accessed by <monospace>A</monospace>. In the registration phase, the client calculates <inline-formula id="ieqn-78"><mml:math id="mml-ieqn-78"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> applying a hash function on the concatenated values of a random number <inline-formula id="ieqn-79"><mml:math id="mml-ieqn-79"><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and <inline-formula id="ieqn-80"><mml:math id="mml-ieqn-80"><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. The pseudo-identity <inline-formula id="ieqn-81"><mml:math id="mml-ieqn-81"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> of the client is transmitted to legal sever instead of <inline-formula id="ieqn-82"><mml:math id="mml-ieqn-82"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> in login message <inline-formula id="ieqn-83"><mml:math id="mml-ieqn-83"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, <italic>B</italic>, <italic>C</italic>, <inline-formula id="ieqn-84"><mml:math id="mml-ieqn-84"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>. Each successful authentication session executes a new pseudo-identity, <inline-formula id="ieqn-85"><mml:math id="mml-ieqn-85"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>. Additionally, the client generates a session-specific random integer <italic>a</italic><sub><italic>u</italic></sub> that prevents an adversary from determining if two independent sessions are initiated by the same or separate clients. Therefore, our protocol makes each client&#x2019;s privacy and anonymity possible.</p>
<p>The conditions of anonymity:
<list list-type="roman-lower">
<list-item><p>The identity of the client should not be leaked.</p></list-item>
<list-item><p>It should not determine that the same client initiated two different sessions.</p></list-item>
</list></p>
<p>So, both conditions of anonymity are fulfilled in this protocol. This protocol ensured the anonymity of the client.</p>
</sec>
<sec id="s5_1_3">
<label>5.1.3</label>
<title>Defense against Client Impersonation Attack</title>
<p>If an adversary <monospace>A</monospace> wants to impersonate a legal client, then he must have to issue an authentic and valid login request message <inline-formula id="ieqn-86"><mml:math id="mml-ieqn-86"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>B</mml:mi><mml:mo>,</mml:mo><mml:mi>C</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula>. So, for the calculation of <inline-formula id="ieqn-87"><mml:math id="mml-ieqn-87"><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula>, <monospace>A</monospace> requires client&#x2019;s identity. Similarly, for the calculation of <inline-formula id="ieqn-88"><mml:math id="mml-ieqn-88"><mml:mi>C</mml:mi><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula>, <monospace>A</monospace> requires the correct value of <inline-formula id="ieqn-89"><mml:math id="mml-ieqn-89"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:mi>D</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> which is possible to compute by having the private key of the server. Because the identity and secret key of the server are not known to <monospace>A</monospace>, our protocol can be considered more secure for defense against client impersonation attacks.</p>
</sec>
<sec id="s5_1_4">
<label>5.1.4</label>
<title>Defense against Server Impersonation attack</title>
<p>If <monospace>A</monospace> desires to impersonate an authentic server, then he must have to generate an authentic challenge message <inline-formula id="ieqn-90"><mml:math id="mml-ieqn-90"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mi>E</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>c</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula> <italic>}</italic>. For calculation of <inline-formula id="ieqn-91"><mml:math id="mml-ieqn-91"><mml:mi>E</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>&#x2295;</mml:mo><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula>, it requires <inline-formula id="ieqn-92"><mml:math id="mml-ieqn-92"><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mi>s</mml:mi><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msup><mml:mi>B</mml:mi></mml:math></inline-formula>, which is possible to compute by having the private key of the server. So, it is clear that our proposed protocol is secured against server impersonation attacks.</p>
</sec>
<sec id="s5_1_5">
<label>5.1.5</label>
<title>Defense against Man-in-Middle Attack</title>
<p>If <monospace>A</monospace> can calculate the authentication restriction between client and server, and the man-in-middle attack will be possible. If <monospace>A</monospace> has values <italic>B</italic> and <italic>C</italic>, he can be able to pass an authentication check. Similarly, he can also pass an authentication check of the legal server if <monospace>A</monospace> contains the server&#x2019;s secret key <italic>s</italic>. Due to the above checks, <monospace>A</monospace> cannot get all the mentioned calculations, so authentication checks cannot be passed. So, the proposed protocol facilitates the feature against man-in-middle attacks.</p>
</sec>
<sec id="s5_1_6">
<label>5.1.6</label>
<title>Providing Perfect Forward Secrecy</title>
<p>Perfect forward secrecy is an important need for designing an authentication protocol. It makes assure that the secrecy of already used previous session keys remains secure in case a long-term private key, password, or session key of any participant is revealed. In our presented protocol, every shared key <inline-formula id="ieqn-93"><mml:math id="mml-ieqn-93"><mml:mi>S</mml:mi><mml:mi>K</mml:mi><mml:mo>=</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo stretchy="false">)</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> contains the session specific random number au produced by server. Similarly, <inline-formula id="ieqn-94"><mml:math id="mml-ieqn-94"><mml:mi>S</mml:mi><mml:mi>K</mml:mi></mml:math></inline-formula> <inline-formula id="ieqn-95"><mml:math id="mml-ieqn-95"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <inline-formula id="ieqn-96"><mml:math id="mml-ieqn-96"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> contains the session specific random number au produced by the client. So, if a shared or long-term private key is revealed, already-used session keys cannot be compromised.</p>
</sec>
</sec>
<sec id="s5_2">
<label>5.2</label>
<title>Formal Security Analysis</title>
<p>In this subsection, the proposed protocol is evaluated formally using the random oracle model: Security Proof: In order to understand the security strength of our protocol, two types of security requirements, like, integrity and authentication based on the Random Oracle Model (ROM), are discussed here. For this purpose, the following definitions are considered:</p>
<p><bold>Security Proof:</bold> <monospace>A</monospace> is a person who is not registered with a system. But, <monospace>A</monospace> has knowledge of all the messages which are being transmitted over a public channel.</p>
<p><bold>Theorem T1:</bold> Authentication property under the assumption of a hash function is being satisfied.</p>
<p><bold>Proof:</bold> In order to get access to the system, the client must enter values like <inline-formula id="ieqn-97"><mml:math id="mml-ieqn-97"><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> and random number <inline-formula id="ieqn-98"><mml:math id="mml-ieqn-98"><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> as per the presented protocol. <inline-formula id="ieqn-99"><mml:math id="mml-ieqn-99"><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula> can be known by <monospace>A</monospace> easily but he is unable to know the random number <inline-formula id="ieqn-100"><mml:math id="mml-ieqn-100"><mml:msub><mml:mi>r</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:math></inline-formula>, because it is only known by client. At the time of login, client inserts <italic>a<sub>u</sub></italic> and computes:
<disp-formula id="eqn-1"><label>(1)</label><mml:math id="mml-eqn-1" display="block"><mml:mi>B</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>s</mml:mi><mml:mi>P</mml:mi></mml:math></disp-formula>
<disp-formula id="eqn-2"><label>(2)</label><mml:math id="mml-eqn-2" display="block"><mml:mi>C</mml:mi><mml:mo>=</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>T</mml:mi><mml:mn>1</mml:mn><mml:mo stretchy="false">)</mml:mo></mml:math></disp-formula></p>
<p>Furthermore, upon receiving the challenge message, the subsequent value is computed:</p>
<p><disp-formula id="eqn-3"><label>(3)</label><mml:math id="mml-eqn-3" display="block"><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>&#x2295;</mml:mo><mml:mi>E</mml:mi></mml:math></disp-formula>and check <inline-formula id="ieqn-101"><mml:math id="mml-ieqn-101"><mml:mi>S</mml:mi><mml:mi>K</mml:mi></mml:math></inline-formula> <inline-formula id="ieqn-102"><mml:math id="mml-ieqn-102"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <inline-formula id="ieqn-103"><mml:math id="mml-ieqn-103"><mml:msub><mml:mi>A</mml:mi><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>C</mml:mi><mml:mrow><mml:mi>u</mml:mi><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> is performed to determine the client&#x2019;s legitimacy. This check will be passed only if the client has inserted valid credentials. Moreover, there is no way for <monospace>A</monospace> to know the secret parameters of the client.</p>
<p><bold>Theorem T2:</bold> The proposed protocol is secured against integrity attacks under a secure hash function in ROM with polynomial time.</p>
<p><bold>Proof:</bold> Integrity property of all transmitted messages must be satisfied to prove the correctness of the message. In our proposed protocol, the client transmits message <inline-formula id="ieqn-104"><mml:math id="mml-ieqn-104"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>B</mml:mi><mml:mo>,</mml:mo><mml:mi>C</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula> to the server over a public channel. So, <monospace>A</monospace> can try to intercept and modify the message <inline-formula id="ieqn-105"><mml:math id="mml-ieqn-105"><mml:mo fence="false" stretchy="false">{</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:mi>B</mml:mi><mml:mo>,</mml:mo><mml:mi>C</mml:mi><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo fence="false" stretchy="false">}</mml:mo></mml:math></inline-formula> In order to deal with this issue and to maintain the integrity of the message, the concept of a secure hash function is used. Whereas the secure hash function is an irreversible function. On the server side, the server computes the following:</p>
<p><disp-formula id="eqn-4"><label>(4)</label><mml:math id="mml-eqn-4" display="block"><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>=</mml:mo><mml:msup><mml:mi>s</mml:mi><mml:mrow><mml:mo>&#x2212;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msup><mml:mi>B</mml:mi></mml:math></disp-formula>and determines <inline-formula id="ieqn-106"><mml:math id="mml-ieqn-106"><mml:mi>C</mml:mi></mml:math></inline-formula> <inline-formula id="ieqn-107"><mml:math id="mml-ieqn-107"><mml:mover><mml:mrow><mml:mo>=</mml:mo></mml:mrow><mml:mrow><mml:mo>?</mml:mo></mml:mrow></mml:mover></mml:math></inline-formula> <inline-formula id="ieqn-108"><mml:math id="mml-ieqn-108"><mml:mi>h</mml:mi><mml:mrow><mml:mo>(</mml:mo><mml:mi>h</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:mi>P</mml:mi><mml:mi>I</mml:mi><mml:msub><mml:mi>D</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mi>s</mml:mi><mml:mo>)</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mi>a</mml:mi><mml:mrow><mml:mi>u</mml:mi></mml:mrow></mml:msub><mml:mi>P</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> to confirm the integrity of the message received from the client. If this condition holds, then it means that the received message is correct and not modified, but if this condition fails, then it means that the message is intercepted and modified by <monospace>A</monospace>. In this case, the server discards the message immediately. So, this is the way the receiver can guess the correctness of the message transmitted over a public channel. Thus, the proposed protocol is secured against integrity attacks.</p>
</sec>
</sec>
<sec id="s6">
<label>6</label>
<title>Performance Analysis</title>
<p>In this section, we state the performance of the proposed protocol. The explanation and implementation of the proposed and related protocols are given below:</p>
<p>Cryptographic-operations <inline-formula id="ieqn-109"><mml:math id="mml-ieqn-109"><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>S</mml:mi><mml:mi>M</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>W</mml:mi><mml:mi>H</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>E</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>P</mml:mi><mml:mi>A</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>P</mml:mi><mml:mi>M</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>S</mml:mi><mml:mi>E</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>S</mml:mi><mml:mi>D</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>H</mml:mi><mml:mi>M</mml:mi><mml:mi>A</mml:mi><mml:mi>C</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>A</mml:mi><mml:mi>D</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mo>&#x2295;</mml:mo></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> are implemented in Ubunto utilizing PyCrypto library, with an 8.0 GB RAM and 2.60 GHZ processor with core i7 using Python programming-language. This verification protocol executed 10 times with the same suppositions by average time. Operations (<inline-formula id="ieqn-110"><mml:math id="mml-ieqn-110"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mo>&#x2295;</mml:mo></mml:mrow></mml:msub></mml:math></inline-formula>) and (<inline-formula id="ieqn-111"><mml:math id="mml-ieqn-111"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>s</mml:mi><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mrow><mml:mo stretchy="false">|</mml:mo></mml:mrow></mml:mrow></mml:msub></mml:math></inline-formula>) take less execution time. So, these operations are not included in the computations of total time. The operation <inline-formula id="ieqn-112"><mml:math id="mml-ieqn-112"><mml:msub><mml:mi>T</mml:mi><mml:mrow><mml:mi>O</mml:mi><mml:mi>W</mml:mi><mml:mi>H</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">(</mml:mo><mml:mo>.</mml:mo><mml:mo stretchy="false">)</mml:mo></mml:math></inline-formula> takes 0.00070 ms for execution while <italic>T</italic><sub><italic>pm</italic></sub> takes 0.0020 ms for point multiplication. The running time of cryptographic operations is described in <xref ref-type="table" rid="table-2">Table 2</xref>.</p>
<table-wrap id="table-2">
<label>Table 2</label>
<caption>
<title>Time for cryptographic operations</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Notation</th>
<th>Description</th>
<th>Required time in ms</th>
</tr>
</thead>
<tbody>
<tr>
<td><italic>T</italic><sub><italic>SM</italic></sub></td>
<td>Exhibits running time for ECC scalar multiplication</td>
<td>0.0240</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>owh</italic></sub></td>
<td>Exhibits running time for one-way hash function</td>
<td>0.00070</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>AE</italic></sub></td>
<td>Exhibits running time for modular exponentiation</td>
<td>0.0040</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>PA</italic></sub></td>
<td>Exhibits running time for point addition</td>
<td>0.0030</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>PM</italic></sub></td>
<td>Exhibits running time for point multiplication</td>
<td>0.00201</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>SE</italic></sub></td>
<td>Exhibits running time for symmetric key encryption</td>
<td>0.0250</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>SD</italic></sub></td>
<td>Exhibits running time for symmetric key decryption</td>
<td>0.0100</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>HMAC</italic></sub></td>
<td>Exhibits running time for hash-based message authentication code</td>
<td>0.0341</td>
</tr>
<tr>
<td><italic>T</italic><sub><italic>AD</italic></sub></td>
<td>Exhibits running time for asymmetric key decryption</td>
<td>0.0025</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Moreover, <xref ref-type="table" rid="table-3">Tables 3</xref> and <xref ref-type="table" rid="table-4">4</xref> present computational, storage, and communication costs of the proposed protocol in contrast to relevant protocols [<xref ref-type="bibr" rid="ref-44">44</xref>&#x2013;<xref ref-type="bibr" rid="ref-48">48</xref>] as follows.</p>
<table-wrap id="table-3">
<label>Table 3</label>
<caption>
<title>Aggregated computation cost</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Protocol</th>
<th>Computation cost</th>
</tr>
</thead>
<tbody>
<tr>
<td>Proposed work</td>
<td>6<italic>T</italic><sub><italic>owh</italic>(</sub>.<sub>)</sub> &#x002B; 9<italic>T</italic><sub><italic>pm</italic></sub> &#x003D; 0.00222 ms</td>
</tr>
<tr>
<td>Mahmood et al. [<xref ref-type="bibr" rid="ref-44">44</xref>]</td>
<td>5<italic>T</italic><sub><italic>SM</italic></sub> &#x002B; 5<italic>T</italic><sub><italic>owh</italic>(</sub>.<sub>)</sub> &#x002B; 1<italic>T</italic><sub><italic>PA</italic></sub> &#x003D; 0.1265 ms</td>
</tr>
<tr>
<td>Wazid et al. [<xref ref-type="bibr" rid="ref-45">45</xref>]</td>
<td>26<italic>T</italic><sub><italic>owh</italic>(</sub>.<sub>)</sub> &#x002B; 4<italic>T</italic><sub><italic>SM</italic></sub> &#x003D; 0.1142 ms</td>
</tr>
<tr>
<td>Eftikhari et al. [<xref ref-type="bibr" rid="ref-46">46</xref>]</td>
<td>26<italic>T</italic><sub><italic>owh</italic>(</sub>.<sub>)</sub> &#x002B; 6<italic>T</italic><sub><italic>SM</italic></sub> &#x002B; 3<italic>T</italic><sub><italic>PA</italic></sub> &#x003D; 0.1712 ms</td>
</tr>
<tr>
<td>Wu et al. [<xref ref-type="bibr" rid="ref-47">47</xref>]</td>
<td>21<italic>T</italic><sub><italic>owh</italic>(</sub>.<sub>)</sub> &#x002B; 6<italic>T</italic><sub><italic>SM</italic></sub> &#x003D; 0.1587 ms</td>
</tr>
<tr>
<td>Chen et al. [<xref ref-type="bibr" rid="ref-48">48</xref>]</td>
<td>19<italic>T</italic><sub><italic>owh</italic>(</sub>.<sub>)</sub> &#x003D; 0.0133 ms</td>
</tr>
</tbody>
</table>
</table-wrap><table-wrap id="table-4">
<label>Table 4</label>
<caption>
<title>Aggregated communication and storage cost</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Protocol</th>
<th>Communication cost</th>
<th>Storage cost</th>
</tr>
</thead>
<tbody>
<tr>
<td>Proposed work</td>
<td>1312 bits</td>
<td>672 bits</td>
</tr>
<tr>
<td>Mahmood et al. [<xref ref-type="bibr" rid="ref-44">44</xref>]</td>
<td>1600 bits</td>
<td>320 bits</td>
</tr>
<tr>
<td>Wazid et al. [<xref ref-type="bibr" rid="ref-45">45</xref>]</td>
<td>3392 bits</td>
<td>1536 bits</td>
</tr>
<tr>
<td>Eftikhari et al. [<xref ref-type="bibr" rid="ref-46">46</xref>]</td>
<td>4704 bits</td>
<td>768 bits</td>
</tr>
<tr>
<td>Wu et al. [<xref ref-type="bibr" rid="ref-47">47</xref>]</td>
<td>5376 bits</td>
<td>832 bits</td>
</tr>
<tr>
<td>Chen et al. [<xref ref-type="bibr" rid="ref-48">48</xref>]</td>
<td>2208 bits</td>
<td>928 bits</td>
</tr>
</tbody>
</table>
</table-wrap>
<sec id="s6_1">
<label>6.1</label>
<title>Comparisons of Communication Cost</title>
<p><xref ref-type="fig" rid="fig-2">Fig. 2</xref> refers to the comparison summary of aggregated calculated communication costs between relevant and proposed protocols.</p>
<fig id="fig-2">
<label>Figure 2</label>
<caption>
<title>Comparisons of communication cost between proposed and related protocols</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_52405-fig-2.tif"/>
</fig>
<p>The reserved bits are considered for timestamps, identity, point addition, and point multiplication are specified as 160 bits, encryption/decryption 128 bits, and hash takes 256 bits. Based on these assumptions, it is observed that calculations are presented in <xref ref-type="table" rid="table-4">Table 4</xref> for the sake of storage and calculation cost for proposed and relevant protocol [<xref ref-type="bibr" rid="ref-44">44</xref>&#x2013;<xref ref-type="bibr" rid="ref-48">48</xref>]. It presents the trade-off between performance and confidentiality, whilst the proposed protocol proposes extra-aided confidentiality features.</p>

</sec>
<sec id="s6_2">
<label>6.2</label>
<title>Comparisons of Computation Cost</title>
<p>The comparison summary between related and proposed protocol The computation cost is presented in the <xref ref-type="fig" rid="fig-3">Fig. 3</xref> and is depicted in <xref ref-type="table" rid="table-3">Table 3</xref> as well. The list of relevant and proposed protocols is marked vertically, while the required time in milliseconds for computation is marked horizontally in the graph. It is observed easily that the proposed protocol takes less time than a few relevant protocols for analysis.</p>
<fig id="fig-3">
<label>Figure 3</label>
<caption>
<title>Comparisons of computation cost between proposed and related protocols</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_52405-fig-3.tif"/>
</fig>
</sec>
<sec id="s6_3">
<label>6.3</label>
<title>Comparisons of Storage Cost</title>
<p>The storage costs for both related and proposed protocols are systematically compared in <xref ref-type="fig" rid="fig-4">Fig. 4</xref> and <xref ref-type="table" rid="table-4">Table 4</xref>.</p>
<fig id="fig-4">
<label>Figure 4</label>
<caption>
<title>Comparisons of storage cost between proposed and related protocols</title>
</caption>
<graphic mimetype="image" mime-subtype="tif" xlink:href="CMC_52405-fig-4.tif"/>
</fig>
<p>The graph in <xref ref-type="fig" rid="fig-4">Fig. 4</xref> displays the required bits for storage vertically, with the related and proposed protocols labeled horizontally. Notably, the proposed protocol allocates more bits for storage compared to various relevant protocols. This increased storage requirement stems from its advanced confidentiality features, which enhance the overall security of the protocol.</p>
<p>Upon detailed analysis of the data presented in <xref ref-type="table" rid="table-3">Tables 3</xref>&#x2013;<xref ref-type="table" rid="table-5">5</xref>, it becomes clear that the communication, computation, and storage costs associated with our protocol are substantially lower than those incurred by many existing protocols in the field. This indicates a significant improvement in efficiency and resource management. Additionally, the proposed protocol not only meets standard security requirements but also introduces advanced security features that provide superior protection and robustness compared to other protocols that address similar issues.</p>
<table-wrap id="table-5">
<label>Table 5</label>
<caption>
<title>Confidentiality features: Comparison summary between proposed and relevant protocols</title>
</caption>
<table frame="hsides">
<colgroup>
<col align="left"/>
<col align="left"/>
<col align="left"/>
<col align="left"/>
<col align="left"/>
<col align="left"/>
<col align="left"/>
</colgroup>
<thead>
<tr>
<th>Protocol&#x2192;Security features&#x2193;</th>
<th>Proposed</th>
<th>Mahmood et al. [<xref ref-type="bibr" rid="ref-44">44</xref>]</th>
<th>Wazid et al. [<xref ref-type="bibr" rid="ref-45">45</xref>]</th>
<th>Eftikhari et al. [<xref ref-type="bibr" rid="ref-46">46</xref>]</th>
<th>Wu et al. [<xref ref-type="bibr" rid="ref-47">47</xref>]</th>
<th>Chen et al. [<xref ref-type="bibr" rid="ref-48">48</xref>]</th>
</tr>
</thead>
<tbody>
<tr>
<td>Impersonation attack</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Replay attack</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Client anonymity</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Perfect forward secrecy</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Man in middle attack</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Mutual authentication and key agreement</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Denial of service attack</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>This enhanced security aspect makes our protocol a more reliable and attractive option for deployment in environments requiring stringent security measures.</p>
</sec>
</sec>
<sec id="s7">
<label>7</label>
<title>Conclusion and Future Directions</title>
<p>Our conclusion has been enhanced to better summarize the key findings, including the identification of various issues such as cost, privacy, and security challenges in cookie management and online transactions. We introduced an ECC-based lightweight, secure, and efficient key agreement authentication protocol designed to tackle these problems through secure cryptographic operations. Our free study evaluating the security of this protocol and a detailed comparative analysis of computation, communication, and storage costs demonstrate its superior efficiency and security over existing protocols. Additionally, we acknowledge the limitations of our research, particularly in the scalability of the protocol across diverse environments, and recommend future studies to explore this area further.</p>
<p>In the future, we will focus on improving cookie security in affiliate marketing to offer strong protection against unwanted tracking and data breaches. We want to create standards that protect user data while ensuring transparency and compliance in affiliate networks.</p>
</sec>
</body>
<back>
<ack><p>None.</p></ack>
<sec><title>Funding Statement</title>
<p>Shehzad Ashraf Chaudhry acknowledges financial support from Abu Dhabi University&#x2019;s Office of Research and Sponsored Programs Grant Number: 19300810.</p>
</sec>
<sec><title>Author Contributions</title>
<p>Study conception, Design, Conceptualization, Data curation, Writing&#x2013;original draft, Methodology: Waseem Akram; Supervision, Methodology, Writing&#x2013;original draft, Writing&#x2013;review &#x0026; editing: Khalid Mahmood; Resources, Software: Hafiz Burhan ul Haq; Validation, Visualization, Draft manuscript preparation: Muhmmad Asif; Investigation, Supervision, Writing&#x2013;original draft, Writing&#x2013;review &#x0026; editing: Shehzad Ashraf Chaudhry; Formal and informal analysis: Taeshik Shon. All authors reviewed the results and approved the final version of the manuscript.</p>
</sec>
<sec sec-type="data-availability"><title>Availability of Data and Materials</title>
<p>The authors confirm that the data supporting the findings of this study are available within the article.</p>
</sec>
<sec sec-type="COI-statement"><title>Conflicts of Interest</title>
<p>The authors declare that they have no conflicts of interest to report regarding the present study.</p>
</sec>
<ref-list content-type="authoryear">
<title>References</title>
<ref id="ref-1"><label>[1]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>F.</given-names> <surname>Roesner</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Kohno</surname></string-name>, and <string-name><given-names>D.</given-names> <surname>Wetherall</surname></string-name></person-group>, &#x201C;<article-title>Detecting and defending against third-party tracking on the web</article-title>,&#x201D; in <conf-name>9th USENIX Symp. Netw. Syst. Des. Implement. (NSDI 12)</conf-name>, <conf-loc>San Jose, CA, USA</conf-loc>, <year>2012</year>, pp. <fpage>155</fpage>&#x2013;<lpage>168</lpage>.</mixed-citation></ref>
<ref id="ref-2"><label>[2]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>Z.</given-names> <surname>Chu</surname></string-name> and <string-name><given-names>H.</given-names> <surname>Wang</surname></string-name></person-group>, &#x201C;<article-title>An investigation of hotlinking and its countermeasures</article-title>,&#x201D; <source>Comput. Commun.</source>, vol. <volume>34</volume>, no. <issue>4</issue>, pp. <fpage>577</fpage>&#x2013;<lpage>590</lpage>, <year>2011</year>. doi: <pub-id pub-id-type="doi">10.1016/j.comcom.2010.05.007</pub-id>.</mixed-citation></ref>
<ref id="ref-3"><label>[3]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>K.</given-names> <surname>Fu</surname></string-name>, <string-name><given-names>E.</given-names> <surname>Sit</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Smith</surname></string-name>, and <string-name><given-names>N.</given-names> <surname>Feamster</surname></string-name></person-group>, &#x201C;<article-title>The dos and don&#x2019;ts of client authentication on the web</article-title>,&#x201D; in <conf-name>10th USENIX Secur. Symp. (USENIX Security 01)</conf-name>, <conf-loc>Washington, DC, USA</conf-loc>, <year>2001</year>. <comment>Accessed: Jul. 07 2024</comment>. [Online]. Available: <ext-link ext-link-type="uri" xlink:href="http://www.usenix.org/events/sec01/fu/fu.pdf">http://www.usenix.org/events/sec01/fu/fu.pdf</ext-link></mixed-citation></ref>
<ref id="ref-4"><label>[4]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>J. S.</given-names> <surname>Park</surname></string-name> and <string-name><given-names>R.</given-names> <surname>Sandhu</surname></string-name></person-group>, &#x201C;<article-title>Secure cookies on the web</article-title>,&#x201D; <source>IEEE Internet Comput.</source>, vol. <volume>4</volume>, no. <issue>4</issue>, pp. <fpage>36</fpage>&#x2013;<lpage>44</lpage>, <year>2000</year>. doi: <pub-id pub-id-type="doi">10.1109/4236.865085</pub-id>.</mixed-citation></ref>
<ref id="ref-5"><label>[5]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>T.</given-names> <surname>Bujlow</surname></string-name>, <string-name><given-names>V.</given-names> <surname>Carela-Espanol</surname></string-name>, <string-name><given-names>J. </given-names> <surname>Sole-Pareta</surname></string-name>, and <string-name><given-names>P.</given-names> <surname>Barlet-Ros</surname></string-name></person-group>, &#x201C;<article-title>A survey on web tracking: Mechanisms, implications, and defenses</article-title>,&#x201D; <source>Proc. IEEE</source>, vol. <volume>105</volume>, no. <issue>8</issue>, pp. <fpage>1476</fpage>&#x2013;<lpage>1510</lpage>, <year>2017</year>. doi: <pub-id pub-id-type="doi">10.1109/JPROC.2016.2637878</pub-id>.</mixed-citation></ref>
<ref id="ref-6"><label>[6]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>S.</given-names> <surname>Sivakorn</surname></string-name>, <string-name><given-names>I.</given-names> <surname>Polakis</surname></string-name>, and <string-name><given-names>A. D.</given-names> <surname>Keromytis</surname></string-name></person-group>, &#x201C;<article-title>The cracked cookie jar: HTTP cookie hijacking and the exposure of private information</article-title>,&#x201D; in <conf-name>2016 IEEE Symp. Secur. Priv. (SP)</conf-name>, <conf-loc>San Jose, CA, USA</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>2016</year>, pp. <fpage>724</fpage>&#x2013;<lpage>742</lpage>.</mixed-citation></ref>
<ref id="ref-7"><label>[7]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>F.</given-names> <surname>Chen</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Duan</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Zheng</surname></string-name>, <string-name><given-names>J.</given-names> <surname>Jiang</surname></string-name>, and <string-name><given-names>J.</given-names> <surname>Chen</surname></string-name></person-group>, &#x201C;<article-title>Path leaks of HTTPS side-channel by cookie injection</article-title>,&#x201D; in <conf-name>Construct. Side-Channel Analy. Secur. Design: 9th Int. Works.</conf-name>, <conf-loc>Singapore</conf-loc>, <publisher-name>Springer International Publishing</publisher-name>, <year>2018</year>, pp. <fpage>189</fpage>&#x2013;<lpage>203</lpage>.</mixed-citation></ref>
<ref id="ref-8"><label>[8]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>C.</given-names> <surname>Blundo</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Cimato</surname></string-name>, and <string-name><given-names>R. D.</given-names> <surname>Prisco</surname></string-name></person-group>, &#x201C;<article-title>A lightweight approach to authenticated web caching</article-title>,&#x201D; in <conf-name>The 2005 Symp. Appl. Internet</conf-name>, <conf-loc>Trento, Italy</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>2005</year>, pp. <fpage>157</fpage>&#x2013;<lpage>163</lpage>.</mixed-citation></ref>
<ref id="ref-9"><label>[9]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>W. B.</given-names> <surname>Shahid</surname></string-name>, <string-name><given-names>B.</given-names> <surname>Aslam</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Abbas</surname></string-name>, <string-name><given-names>S. B.</given-names> <surname>Khalid</surname></string-name>, and <string-name><given-names>H.</given-names> <surname>Afzal</surname></string-name></person-group>, &#x201C;<article-title>An enhanced deep learning based framework for web attacks detection, mitigation and attacker profiling</article-title>,&#x201D; <source>J. Netw. Comput. Appl.</source>, vol. <volume>198</volume>, no. <issue>3</issue>, pp. <fpage>103270</fpage>, <year>2022</year>. doi: <pub-id pub-id-type="doi">10.1016/j.jnca.2021.103270</pub-id>.</mixed-citation></ref>
<ref id="ref-10"><label>[10]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>A.</given-names> <surname>Juels</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Jakobsson</surname></string-name>, and <string-name><given-names>T. N.</given-names> <surname>Jagatic</surname></string-name></person-group>, &#x201C;<article-title>Cache cookies for browser authentication</article-title>,&#x201D; in <conf-name>2006 IEEE Symp. Secur. Priv. (S&#x0026;P&#x0027;06)</conf-name>, <conf-loc>Oakland City, CA, USA</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>2006</year>, pp. <fpage>5</fpage>.</mixed-citation></ref>
<ref id="ref-11"><label>[11]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>A. X.</given-names> <surname>Liu</surname></string-name>, <string-name><given-names>J. M.</given-names> <surname>Kovacs</surname></string-name>, <string-name><given-names>C. T.</given-names> <surname>Huang</surname></string-name>, and <string-name><given-names>M. G.</given-names> <surname>Gouda</surname></string-name></person-group>, &#x201C;<article-title>A secure cookie protocol</article-title>,&#x201D; in <conf-name>Proc. 14th Int. Conf. Comput. Commun. Netw., ICCCN 2005</conf-name>, <conf-loc>San Diego, CA, USA</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>Oct. 17&#x2013;19, 2005</year>, pp. <fpage>333</fpage>&#x2013;<lpage>338</lpage>.</mixed-citation></ref>
<ref id="ref-12"><label>[12]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>D.</given-names> <surname>Xu</surname></string-name>, <string-name><given-names>C.</given-names> <surname>Lu</surname></string-name>, and <string-name><given-names>A. Dos</given-names> <surname>Santos</surname></string-name></person-group>, &#x201C;<article-title>Protecting web usage of credit cards using one-time pad cookie encryption</article-title>,&#x201D; in <conf-name>18th Annu. Comput. Secur. Appl. Conf., Proc.</conf-name>, <conf-loc>Las Vegas, NV, USA</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>2002</year>, pp. <fpage>51</fpage>&#x2013;<lpage>58</lpage>.</mixed-citation></ref>
<ref id="ref-13"><label>[13]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>J. P.</given-names> <surname>Yang</surname></string-name> and <string-name><given-names>K. H.</given-names> <surname>Rhee</surname></string-name></person-group>, &#x201C;<article-title>A new design for a practical secure cookies system</article-title>,&#x201D; <source>J. Inform. Sci. Eng.</source>, vol. <volume>22</volume>, no. <issue>3</issue>, pp. <fpage>559</fpage>&#x2013;<lpage>571</lpage>, <year>2006</year>.</mixed-citation></ref>
<ref id="ref-14"><label>[14]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>I.</given-names> <surname>Dacosta</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Chakradeo</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Ahamad</surname></string-name>, and <string-name><given-names>P.</given-names> <surname>Traynor</surname></string-name></person-group>, &#x201C;<article-title>One-time cookies: Preventing session hijacking attacks with stateless authentication tokens</article-title>,&#x201D; <source>ACM Trans. Internet Technol.</source>, vol. <volume>12</volume>, no. <issue>1</issue>, pp. <fpage>1</fpage>&#x2013;<lpage>24</lpage>, <year>2012</year>. doi: <pub-id pub-id-type="doi">10.1145/2220352.2220353</pub-id>.</mixed-citation></ref>
<ref id="ref-15"><label>[15]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, <string-name><given-names>A.</given-names> <surname>Irshad</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Yahya</surname></string-name>, <string-name><given-names>N.</given-names> <surname>Kumar</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Alazab</surname></string-name> and <string-name><given-names>Y. B.</given-names> <surname>Zikria</surname></string-name></person-group>, &#x201C;<article-title>Rotating behind privacy: An improved lightweight authentication scheme for cloud-based IoT environment</article-title>,&#x201D; <source>ACM Trans. Internet Technol.</source>, vol. <volume>21</volume>, no. <issue>3</issue>, pp. <fpage>1</fpage>&#x2013;<lpage>19</lpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1145/3425707</pub-id>.</mixed-citation></ref>
<ref id="ref-16"><label>[16]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, <string-name><given-names>M. S.</given-names> <surname>Farash</surname></string-name>, <string-name><given-names>N.</given-names> <surname>Kumar</surname></string-name>, and <string-name><given-names>M. H.</given-names> <surname>Alsharif</surname></string-name></person-group>, &#x201C;<article-title>PFLUA-DIoT: A pairing free lightweight and unlinkable user access control scheme for distributed IoT environments</article-title>,&#x201D; <source>IEEE Syst. J.</source>, vol. <volume>16</volume>, no. <issue>1</issue>, pp. <fpage>309</fpage>&#x2013;<lpage>316</lpage>, <year>2020</year>. doi: <pub-id pub-id-type="doi">10.1109/JSYST.2020.3036425</pub-id>.</mixed-citation></ref>
<ref id="ref-17"><label>[17]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>K.</given-names> <surname>Mahmood</surname></string-name>, <string-name><given-names>W.</given-names> <surname>Akram</surname></string-name>, <string-name><given-names>A.</given-names> <surname>Shafiq</surname></string-name>, <string-name><given-names>I.</given-names> <surname>Altaf</surname></string-name>, <string-name><given-names>M. A.</given-names> <surname>Lodhi</surname></string-name> and <string-name><given-names>S. K. H.</given-names> <surname>Islam</surname></string-name></person-group>, &#x201C;<article-title>An enhanced and provably secure multi-factor authentication scheme for Internet-of-Multimedia-Things environments</article-title>,&#x201D; <source>Comput. &#x0026; Elect. Eng.</source>, vol. <volume>88</volume>, no. <issue>3</issue>, pp. <fpage>106888</fpage>, <year>2020</year>. doi: <pub-id pub-id-type="doi">10.1016/j.compeleceng.2020.106888</pub-id>.</mixed-citation></ref>
<ref id="ref-18"><label>[18]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S.</given-names> <surname>Kwon</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Yoo</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Shon</surname></string-name></person-group>, &#x201C;<article-title>IEEE 1815.1-based power system security with bidirectional RNN-based network anomalous attack detection for cyber-physical system</article-title>,&#x201D; <source>IEEE Access</source>, vol. <volume>8</volume>, pp. <fpage>77572</fpage>&#x2013;<lpage>77586</lpage>, <year>2020</year>. doi: <pub-id pub-id-type="doi">10.1109/ACCESS.2020.2989770</pub-id>.</mixed-citation></ref>
<ref id="ref-19"><label>[19]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. J.</given-names> <surname>Kim</surname></string-name>, <string-name><given-names>W. Y.</given-names> <surname>Jo</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Shon</surname></string-name></person-group>, &#x201C;<article-title>APAD: Autoencoder-based payload anomaly detection for industrial IoE</article-title>,&#x201D; <source>Appl. Soft Comput.</source>, vol. <volume>88</volume>, pp. <fpage>106017</fpage>, <year>2020</year>. doi: <pub-id pub-id-type="doi">10.1016/j.asoc.2019.106017</pub-id>.</mixed-citation></ref>
<ref id="ref-20"><label>[20]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>W.</given-names> <surname>Jo</surname></string-name>, <string-name><given-names>S. J.</given-names> <surname>Kim</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Kim</surname></string-name>, <string-name><given-names>Y.</given-names> <surname>Shin</surname></string-name>, and <string-name><given-names>T.</given-names> <surname>Shon</surname></string-name></person-group>, &#x201C;<article-title>Automatic whitelist generation system for ethernet based in-vehicle network</article-title>,&#x201D; <source>Comput. Ind.</source>, vol. <volume>142</volume>, no. <issue>1</issue>, pp. <fpage>103735</fpage>, <year>2022</year>. doi: <pub-id pub-id-type="doi">10.1016/j.compind.2022.103735</pub-id>.</mixed-citation></ref>
<ref id="ref-21"><label>[21]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name></person-group>, &#x201C;<article-title>Correcting PALK: Password-based anonymous lightweight key agreement framework for smart grid</article-title>,&#x201D; <source>Int. J. Elect. Power &#x0026; Energy Systems</source>, vol. <volume>125</volume>, no. <issue>3</issue>, pp. <fpage>106529</fpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1016/j.ijepes.2020.106529</pub-id>.</mixed-citation></ref>
<ref id="ref-22"><label>[22]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>H.</given-names> <surname>Zhu</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Lin</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Lu</surname></string-name>, <string-name><given-names>P. H.</given-names> <surname>Ho</surname></string-name>, and <string-name><given-names>X.</given-names> <surname>Shen</surname></string-name></person-group>, &#x201C;<article-title>SLAB: A secure localized authentication and billing scheme for wireless mesh networks</article-title>,&#x201D; <source>IEEE Trans. Wirel. Commun.</source>, vol. <volume>7</volume>, no. <issue>10</issue>, pp. <fpage>3858</fpage>&#x2013;<lpage>3868</lpage>, <year>2008</year>. doi: <pub-id pub-id-type="doi">10.1109/T-WC.2008.07418</pub-id>.</mixed-citation></ref>
<ref id="ref-23"><label>[23]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>X.</given-names> <surname>Lin</surname></string-name>, <string-name><given-names>R.</given-names> <surname>Lu</surname></string-name>, <string-name><given-names>P. H.</given-names> <surname>Ho</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Shen</surname></string-name>, and <string-name><given-names>Z.</given-names> <surname>Cao</surname></string-name></person-group>, &#x201C;<article-title>TUA: A novel compromise-resilient authentication architecture for wireless mesh networks</article-title>,&#x201D; <source>IEEE Trans. Wirel. Commun.</source>, vol. <volume>7</volume>, no. <issue>4</issue>, pp. <fpage>1389</fpage>&#x2013;<lpage>1399</lpage>, <year>2008</year>. doi: <pub-id pub-id-type="doi">10.1109/TWC.2008.060990</pub-id>.</mixed-citation></ref>
<ref id="ref-24"><label>[24]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>K.</given-names> <surname>Kursawe</surname></string-name>, <string-name><given-names>G.</given-names> <surname>Danezis</surname></string-name>, and <string-name><given-names>M.</given-names> <surname>Kohlweiss</surname></string-name></person-group>, &#x201C;<article-title>Privacy-friendly aggregation for the smart-grid</article-title>,&#x201D; in <conf-name>Priv. Enhan. Technol.: 11th Int. Symp.</conf-name>, <conf-loc>Waterloo, ON, Canada</conf-loc>, <publisher-name>Springer Berlin Heidelberg</publisher-name>, <year>Jul. 27&#x2013;29, 2011</year>, pp. <fpage>175</fpage>&#x2013;<lpage>191</lpage>.</mixed-citation></ref>
<ref id="ref-25"><label>[25]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Yahya</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Garg</surname></string-name>, <string-name><given-names>G.</given-names> <surname>Kaddoum</surname></string-name>, <string-name><given-names>M. M.</given-names> <surname>Hassan</surname></string-name> and <string-name><given-names>Y. B.</given-names> <surname>Zikria</surname></string-name></person-group>, &#x201C;<article-title>LAS-SG: An elliptic curve-based lightweight authentication scheme for smart grid environments</article-title>,&#x201D; <source>IEEE Trans. Ind. Inform.</source>, vol. <volume>19</volume>, no. <issue>2</issue>, pp. <fpage>1504</fpage>&#x2013;<lpage>1511</lpage>, <year>2022</year>. doi: <pub-id pub-id-type="doi">10.1109/TII.2022.3158663</pub-id>.</mixed-citation></ref>
<ref id="ref-26"><label>[26]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>A. R.</given-names> <surname>Metke</surname></string-name> and <string-name><given-names>R. L.</given-names> <surname>Ekl</surname></string-name></person-group>, &#x201C;<article-title>Smart grid security technology</article-title>,&#x201D; in <conf-name>2010 Innov. Smart Grid Technol. (ISGT)</conf-name>, <publisher-name>IEEE</publisher-name>, <year>2010</year>, pp. <fpage>1</fpage>&#x2013;<lpage>7</lpage>.</mixed-citation></ref>
<ref id="ref-27"><label>[27]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>M.</given-names> <surname>Kgwadi</surname></string-name> and <string-name><given-names>T.</given-names> <surname>Kunz</surname></string-name></person-group>, &#x201C;<article-title>Securing RDS broadcast messages for smart grid applications</article-title>,&#x201D; in <conf-name>Proc. 6th Int. Wireless Commun. Mobile Comput. Conf.</conf-name>, <conf-loc>Caen, France</conf-loc>, <year>Jun. 28&#x2013;Jul. 2</year>, pp. <fpage>1177</fpage>&#x2013;<lpage>1181</lpage>.</mixed-citation></ref>
<ref id="ref-28"><label>[28]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>R.</given-names> <surname>Lu</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Li</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Liang</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Shen</surname></string-name>, and <string-name><given-names>X.</given-names> <surname>Lin</surname></string-name></person-group>, &#x201C;<article-title>GRS: The green, reliability, and security of emerging machine to machine communications</article-title>,&#x201D; <source>IEEE Commun. Mag.</source>, vol. <volume>49</volume>, no. <issue>4</issue>, pp. <fpage>28</fpage>&#x2013;<lpage>35</lpage>, <year>2011</year>. doi: <pub-id pub-id-type="doi">10.1109/MCOM.2011.5741143</pub-id>.</mixed-citation></ref>
<ref id="ref-29"><label>[29]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>G. N.</given-names> <surname>Ericsson</surname></string-name></person-group>, &#x201C;<article-title>Cyber security and power system communication&#x2014;Essential parts of a smart grid infrastructure</article-title>,&#x201D; <source>IEEE Trans. Power Deliv.</source>, vol. <volume>25</volume>, no. <issue>3</issue>, pp. <fpage>1501</fpage>&#x2013;<lpage>1507</lpage>, <year>2010</year>. doi: <pub-id pub-id-type="doi">10.1109/TPWRD.2010.2046654</pub-id>.</mixed-citation></ref>
<ref id="ref-30"><label>[30]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name> <etal>et al.</etal></person-group>, &#x201C;<article-title>An anonymous device to device access control based on secure certificate for internet of medical things systems</article-title>,&#x201D; <source>Sustain. Cities Soc.</source>, vol. <volume>75</volume>, no. <issue>1</issue>, pp. <fpage>103322</fpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1016/j.scs.2021.103322</pub-id>.</mixed-citation></ref>
<ref id="ref-31"><label>[31]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>A.</given-names> <surname>Hamlyn</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Cheung</surname></string-name>, <string-name><given-names>T.</given-names> <surname>Mander</surname></string-name>, <string-name><given-names>L.</given-names> <surname>Wang</surname></string-name>, <string-name><given-names>C.</given-names> <surname>Yang</surname></string-name> and <string-name><given-names>R.</given-names> <surname>Cheung</surname></string-name></person-group>, &#x201C;<article-title>Network security management and authentication of actions for smart grids operations</article-title>,&#x201D; in <conf-name>2007 IEEE Canada Elect. Power Conf.</conf-name>, <conf-loc>Montreal, QC, Canada</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>Oct. 25, 2007</year>, pp. <fpage>31</fpage>&#x2013;<lpage>36</lpage>.</mixed-citation></ref>
<ref id="ref-32"><label>[32]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>X.</given-names> <surname>Lin</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Sun</surname></string-name>, <string-name><given-names>P. H.</given-names> <surname>Ho</surname></string-name>, and <string-name><given-names>X.</given-names> <surname>Shen</surname></string-name></person-group>, &#x201C;<article-title>GSIS: A secure and privacy-preserving protocol for vehicular communications</article-title>,&#x201D; <source>IEEE Trans. Vehicular Technol.</source>, vol. <volume>56</volume>, no. <issue>6</issue>, pp. <fpage>3442</fpage>&#x2013;<lpage>3456</lpage>, <year>2007</year>. doi: <pub-id pub-id-type="doi">10.1109/TVT.2007.906878</pub-id>.</mixed-citation></ref>
<ref id="ref-33"><label>[33]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>R.</given-names> <surname>Lu</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Lin</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Zhu</surname></string-name>, <string-name><given-names>P. H.</given-names> <surname>Ho</surname></string-name>, and <string-name><given-names>X.</given-names> <surname>Shen</surname></string-name></person-group>, &#x201C;<article-title>ECPP: Efficient conditional privacy preservation protocol for secure vehicular communications</article-title>,&#x201D; in <conf-name>IEEE INFOCOM 2008-The 27th Conf. Comput. Commun.</conf-name>, <conf-loc>Phoenix, AZ, USA</conf-loc>, <publisher-name>IEEE</publisher-name>, <year>Apr. 13, 2008</year>, pp. <fpage>1229</fpage>&#x2013;<lpage>1237</lpage>.</mixed-citation></ref>
<ref id="ref-34"><label>[34]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>W.</given-names> <surname>Ali</surname></string-name>, <string-name><given-names>A.</given-names> <surname>Khan</surname></string-name>, and <string-name><given-names>W.</given-names> <surname>Akram</surname></string-name></person-group>, &#x201C;<article-title>Analyzing the deployment and performance of Multi-CDNs in Pakistan</article-title>,&#x201D; <source>Pakistan J. Eng. Technol.</source>, vol. <volume>4</volume>, no. <issue>1</issue>, pp. <fpage>169</fpage>&#x2013;<lpage>174</lpage>, <year>2021</year>.</mixed-citation></ref>
<ref id="ref-35"><label>[35]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>A.</given-names> <surname>Irshad</surname></string-name>, <string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, <string-name><given-names>O. A.</given-names> <surname>Alomari</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Yahya</surname></string-name>, and <string-name><given-names>N.</given-names> <surname>Kumar</surname></string-name></person-group>, &#x201C;<article-title>A novel pairing-free lightweight authentication protocol for mobile cloud computing framework</article-title>,&#x201D; <source>IEEE Syst. J.</source>, vol. <volume>15</volume>, no. <issue>3</issue>, pp. <fpage>3664</fpage>&#x2013;<lpage>3672</lpage>, <year>2020</year>. doi: <pub-id pub-id-type="doi">10.1109/JSYST.2020.2998721</pub-id>.</mixed-citation></ref>
<ref id="ref-36"><label>[36]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><given-names>C.</given-names> <surname>Cuijpers</surname></string-name> and <string-name><given-names>B. J.</given-names> <surname>Koops</surname></string-name></person-group>, &#x201C;<article-title>The &#x2018;smart meters&#x2019; bill: A privacy test based on article 8 of the ECHR,&#x201D;</article-title> <year>2008</year>. <comment>Accessed: Jul. 07, 2024</comment>. [Online]. Available: <ext-link ext-link-type="uri" xlink:href="https://smartgridawareness.org/wp-content/uploads/2014/11/dutch-smart-meters-report-tilt-october-2008-english-version.pdf">https://smartgridawareness.org/wp-content/uploads/2014/11/dutch-smart-meters-report-tilt-october-2008-english-version.pdf</ext-link></mixed-citation></ref>
<ref id="ref-37"><label>[37]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>Z.</given-names> <surname>Ali</surname></string-name>, <string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Mahmood</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Garg</surname></string-name>, <string-name><given-names>Z.</given-names> <surname>Lv</surname></string-name>, and <string-name><given-names>Y. B.</given-names> <surname>Zikria</surname></string-name></person-group>, &#x201C;<article-title>A clogging resistant secure authentication scheme for fog computing services</article-title>,&#x201D; <source>Comput. Netw.</source>, vol. <volume>185</volume>, no. <issue>9</issue>, pp. <fpage>107731</fpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1016/j.comnet.2020.107731</pub-id>.</mixed-citation></ref>
<ref id="ref-38"><label>[38]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>K.</given-names> <surname>Mahmood</surname></string-name>, <string-name><given-names>J.</given-names> <surname>Arshad</surname></string-name>, <string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, and <string-name><given-names>S.</given-names> <surname>Kumari</surname></string-name></person-group>, &#x201C;<article-title>An enhanced anonymous identity-based key agreement protocol for smart grid advanced metering infrastructure</article-title>,&#x201D; <source>Int. J. Commun. Syst.</source>, vol. <volume>32</volume>, no. <issue>16</issue>, pp. <fpage>e4137</fpage>, <year>2019</year>. doi: <pub-id pub-id-type="doi">10.1002/dac.4137</pub-id>.</mixed-citation></ref>
<ref id="ref-39"><label>[39]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>W.</given-names> <surname>Akram</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Mahmood</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Li</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Sadiq</surname></string-name>, <string-name><given-names>Z.</given-names> <surname>Lv</surname></string-name> and <string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name></person-group>, &#x201C;<article-title>An energy-efficient and secure identity based RFID authentication scheme for vehicular cloud computing</article-title>,&#x201D; <source>Comput. Netw.</source>, vol. <volume>217</volume>, no. <issue>4</issue>, pp. <fpage>109335</fpage>, <year>2022</year>. doi: <pub-id pub-id-type="doi">10.1016/j.comnet.2022.109335</pub-id>.</mixed-citation></ref>
<ref id="ref-40"><label>[40]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name> <etal>et al.</etal></person-group>, &#x201C;<article-title>A lightweight authentication scheme for 6G-IoT enabled maritime transport system</article-title>,&#x201D; <source>IEEE Trans. Intell. Transp. Syst.</source>, vol. <volume>24</volume>, no. <issue>2</issue>, pp. <fpage>2401</fpage>&#x2013;<lpage>2410</lpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1109/TITS.2021.3134643</pub-id>.</mixed-citation></ref>
<ref id="ref-41"><label>[41]</label><mixed-citation publication-type="conf-proc"><person-group person-group-type="author"><string-name><given-names>N.</given-names> <surname>Chachra</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Savage</surname></string-name>, and <string-name><given-names>G. M.</given-names> <surname>Voelker</surname></string-name></person-group>, &#x201C;<article-title>Affiliate crookies: Characterizing affiliate marketing abuse</article-title>,&#x201D; in <conf-name>Proc. 2015 Internet Measur. Conf.</conf-name>, <conf-loc>Tokyo, Japan</conf-loc>, <year>2015</year>, pp. <fpage>41</fpage>&#x2013;<lpage>47</lpage>.</mixed-citation></ref>
<ref id="ref-42"><label>[42]</label><mixed-citation publication-type="other"><person-group person-group-type="author"><string-name><given-names>S.</given-names> <surname>William</surname></string-name></person-group>, <article-title><italic>Cryptography and Network Security: For VTU</italic>. 4th ed. Chennai, India: Pearson Education India</article-title>, <year>2006</year>. <comment>Accessed: Jul. 07, 2024</comment>. [Online]. Available: <ext-link ext-link-type="uri" xlink:href="https://books.google.com.tw/books?id=Pl47qiuv5sgC">https://books.google.com.tw/books?id=Pl47qiuv5sgC</ext-link></mixed-citation></ref>
<ref id="ref-43"><label>[43]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>H.</given-names> <surname>Lee</surname></string-name>, <string-name><given-names>J.</given-names> <surname>Nam</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Kim</surname></string-name>, and <string-name><given-names>D.</given-names> <surname>Won</surname></string-name></person-group>, &#x201C;<article-title>Forward anonymity-preserving secure remote authentication scheme</article-title>,&#x201D; <source>KSII Transact. Int. Inform. Syst. (TIIS)</source>, vol. <volume>10</volume>, no. <issue>3</issue>, pp. <fpage>1289</fpage>&#x2013;<lpage>1310</lpage>, <year>2016</year>.</mixed-citation></ref>
<ref id="ref-44"><label>[44]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>K.</given-names> <surname>Mahmood</surname></string-name>, <string-name><given-names>S. A.</given-names> <surname>Chaudhry</surname></string-name>, <string-name><given-names>H.</given-names> <surname>Naqvi</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Kumari</surname></string-name>, <string-name><given-names>X.</given-names> <surname>Li</surname></string-name> and <string-name><given-names>A. K.</given-names> <surname>Sangaiah</surname></string-name></person-group>, &#x201C;<article-title>An elliptic curve cryptography based lightweight authentication scheme for smart grid communication</article-title>,&#x201D; <source>Future Gener. Comput. Syst.</source>, vol. <volume>81</volume>, no. <issue>2</issue>, pp. <fpage>557</fpage>&#x2013;<lpage>565</lpage>, <year>2018</year>. doi: <pub-id pub-id-type="doi">10.1016/j.future.2017.05.002</pub-id>.</mixed-citation></ref>
<ref id="ref-45"><label>[45]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>M.</given-names> <surname>Wazid</surname></string-name>, <string-name><given-names>P.</given-names> <surname>Bagga</surname></string-name>, <string-name><given-names>A. K.</given-names> <surname>Das</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Shetty</surname></string-name>, <string-name><given-names>J. J. P. C.</given-names> <surname>Rodrigues</surname></string-name>, and <string-name><given-names>Y.</given-names> <surname>Park</surname></string-name></person-group>, &#x201C;<article-title>AKM-IoV: Authenticated key management protocol in fog computing-based Internet of vehicles deployment</article-title>,&#x201D; <source>IEEE Internet Things J.</source>, vol. <volume>6</volume>, no. <issue>5</issue>, pp. <fpage>8804</fpage>&#x2013;<lpage>8817</lpage>, <year>2019</year>. doi: <pub-id pub-id-type="doi">10.1109/JIOT.2019.2923611</pub-id>.</mixed-citation></ref>
<ref id="ref-46"><label>[46]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>S. A.</given-names> <surname>Eftekhari</surname></string-name>, <string-name><given-names>M.</given-names> <surname>Nikooghadam</surname></string-name>, and <string-name><given-names>M.</given-names> <surname>Rafighi</surname></string-name></person-group>, &#x201C;<article-title>Security-enhanced three-party pairwise secret key agreement protocol for fog-based vehicular ad-hoc communications</article-title>,&#x201D; <source>Veh. Commun.</source>, vol. <volume>28</volume>, no. <issue>1</issue>, pp. <fpage>100306</fpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1016/j.vehcom.2020.100306</pub-id>.</mixed-citation></ref>
<ref id="ref-47"><label>[47]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>T. Y.</given-names> <surname>Wu</surname></string-name>, <string-name><given-names>Z.</given-names> <surname>Lee</surname></string-name>, <string-name><given-names>L.</given-names> <surname>Yang</surname></string-name>, <string-name><given-names>J. N.</given-names> <surname>Luo</surname></string-name>, and <string-name><given-names>R.</given-names> <surname>Tso</surname></string-name></person-group>, &#x201C;<article-title>Provably secure authentication key exchange scheme using fog nodes in vehicular ad hoc networks</article-title>,&#x201D; <source>J. Supercomput.</source>, vol. <volume>77</volume>, no. <issue>7</issue>, pp. <fpage>6992</fpage>&#x2013;<lpage>7020</lpage>, <year>2021</year>. doi: <pub-id pub-id-type="doi">10.1007/s11227-020-03548-9</pub-id>.</mixed-citation></ref>
<ref id="ref-48"><label>[48]</label><mixed-citation publication-type="journal"><person-group person-group-type="author"><string-name><given-names>C. M.</given-names> <surname>Chen</surname></string-name>, <string-name><given-names>Z.</given-names> <surname>Li</surname></string-name>, <string-name><given-names>S.</given-names> <surname>Kumari</surname></string-name>, <string-name><given-names>G.</given-names> <surname>Srivastava</surname></string-name>, <string-name><given-names>K.</given-names> <surname>Lakshmanna</surname></string-name> and <string-name><given-names>T. R.</given-names> <surname>Gadekallu</surname></string-name></person-group>, &#x201C;<article-title>A provably secure key transfer protocol for the fog-enabled Social Internet of Vehicles based on a confidential computing environment</article-title>,&#x201D; <source>Veh. Commun.</source>, vol. <volume>39</volume>, no. <issue>1</issue>, pp. <fpage>100567</fpage>, <year>2023</year>. doi: <pub-id pub-id-type="doi">10.1016/j.vehcom.2022.100567</pub-id>.</mixed-citation></ref>
</ref-list>
</back></article>