Advancing Secure Mobile Cloud Computing: A Chaotic Maps-Based Password Key Agreement Protocol

MCC, an integration of cloud computing and mobile communication technologies [1], empowers mobile users to access computing resources from the cloud. Cloud computing offers a range of services to surmount the inherent limitations of mobile devices, such as battery energy, memory, and computing power. This integration effectively addresses resource constraints on mobile devices by harnessing the capabilities of cloud computing in conjunction with mobile communication.

A paramount challenge in MCC is securing sensitive data outsourced to the cloud, given its open platform nature and untrusted storage environment. Encrypting outsourced data is a prevalent approach to bolster security, preventing unauthorized data access [2]. Several mechanisms for data encryption prior to cloud outsourcing have been proposed in the literature [2]. In these models, clients encrypt data before outsourcing, while users retrieve and decrypt the encrypted data upon access. These schemes generally presume the users to be reputable and authorized for data retrieval. However, this assumption engenders security challenges in distributed computing environments like MCC, where users dynamically access cloud services via public networks, thus compromising authenticity and access control.

The principles of Confidentiality, Authentication, and Authorization (CAA) [3] are vital in establishing robust security measures in MCC. Authentication and access control, coupled with data secrecy, are fundamental requirements for secure operations. Confidentiality is maintained through encryption methods applied to data before cloud storage, safeguarding sensitive information from unauthorized entities. Users are authenticated through a reliable system, verifying their credentials. Authorization, on the other hand, governs user interaction with cloud services based on assigned permissions, ensuring controlled access to cloud resources.

The exigency for secure communication and information exchange is paramount in today's digital landscape. The proposed study posits that data confidentiality [4] is ensured by storing data in an encrypted format within the Cloud Computing (CC) environment, complemented by a trust-based access control mechanism for authentication [5]. However, confidentiality and authorization alone are insufficient for comprehensive security. Authentication, which verifies the identities of the communicating entities, is equally critical. Therefore, the objective is to provide robust authentication between computing entities, necessitating mechanisms that are congruent with the resource constraints of the environment.

This research introduces a password-based authenticated key exchange protocol specifically designed for cloud computing environments. Mutual authenticated key agreement stands as a fundamental, straightforward, and indispensable approach to securing any communication environment. This process involves two parties mutually authenticating and subsequently agreeing upon a secret session key, derived through a process of information negotiation. Such an approach is essential to safeguard the communication environment from unauthorized access, ensuring that the session key is securely established solely between legitimate entities.

Existing mutual authentication protocols [6-14] have been scrutinized, revealing vulnerabilities to various attacks, including man-in-the-middle, replay, and denial-of-service attacks. A notable drawback of these protocols is their considerable computational overhead, predominantly stemming from complex cryptographic operations. This results in performance limitations, especially in mobile cloud environments where processing power and network resources are inherently constrained.

The utilization of unreliable or slow networks for connecting mobile devices to the internet can exacerbate the performance challenges posed by the computational demands of authentication protocols. This issue is particularly pronounced in mobile cloud environments where cloud servers may be geographically distant from the mobile devices, leading to significant network latency. These challenges are crucial considerations in the development of an effective mutual authentication protocol for mobile cloud environments.

Jegadeesan et al. [15] have underscored critical shortcomings in existing authentication schemes within MCC, including vulnerabilities to user impersonation, mutual authentication failures, and susceptibility to Man-in-the-Middle (MITM) attacks. In response, this paper introduces an efficient password-based authenticated key exchange protocol tailored for Cloud Computing environments. The protocol employs Chaotic Maps, based on the Discrete Logarithmic and Diffie-Hellman problems, to facilitate secure session key exchange and mutual authentication in MCC. To bolster security, symmetric encipherment and one-way hash functions are integrated into the protocol, providing robust defenses against replay and MITM attacks. The method is specifically designed to manage identity authentication and securely exchange session keys between computing entities in MCC environments.

The structure of the paper is as follows: the subsequent section delineates related work in this field. Section 3 presents the proposed protocol in detail, while Section 4 is dedicated to the performance evaluation of the protocol. The paper concludes with a discussion of the results and final conclusions.

1.png

Figure 1. PBMAK architecture

2.png

Figure 2. Authentication parameters in Chebyshev Polynomial form

Table 2 provides abbreviations, notations, and descriptions used in the authentication algorithm. Figure 2 discusses the users, clients, and cloud service provider computed public keys, i.e., as $T_{\text {Key}_u}(v)$, $T_{\text {Key}_{c l}}(v), T_{\text {Key}_{c s p}}(v)$ with their corresponding secret key 'key'. These public keys are computed with a commonly agreed value 'v' with Chebyshev's polynomial Chaotic Maps approach. If the adversary tries to understand these values but is difficult to decode because ['key'] is unknown. Here, this proposed approach restricts the man-in-the-middle attack.

Our proposed key agreement method leverages Chaotic Maps, utilizing Chebyshev polynomials from chaos theory—a mathematical field studying highly sensitive dynamic systems. Chebyshev polynomials are defined as follows:

$\begin{aligned} & \cos (\mathrm{n} \theta) \text { could be written in the polynomial of } \cos (\theta) \\ & \cos (\mathrm{n} \theta)=\mathrm{T}_{\mathrm{n}} * \cos (\theta) \\ & \cos ((\mathrm{n}+1) * \theta)=2 * \cos (\mathrm{n} \theta) * \cos (\theta)-\cos ((\mathrm{n}-1) * \theta) \\ & \mathrm{T}_{\mathrm{n}+1} \cos (\theta)=2 * \mathrm{~T}_{\mathrm{n}} \cos (\theta) * \cos (\theta)-\mathrm{T}_{\mathrm{n}-1} \\ & \cos (\theta) \mathrm{T}_{\mathrm{n}+1}(\mathrm{x})=2 * \mathrm{x}^* \mathrm{~T}_{\mathrm{n}}(\mathrm{x})-\mathrm{T}_{\mathrm{n}-1}(\mathrm{x})\end{aligned}$

Let,

$T_x(v)=\cos (x \arccos (v))$               (1)

where, x=integer, v=variable.

Chebyshev's polynomial Chaotic Maps approach T_x: x in Chebyshev's polynomial is defined as in recurrence relation is:

$T_x(v)=2 v * T_{x-1}(v)-T_{x-2}(v) *(\bmod X) x \geq 1$               (2)

where, x=0, 1, 2, 3, ……… i.e., $x \in(-\infty, \infty)$, T₀(v)=1, T₁(v)=v, ….

Chebyshev's polynomial Chaotic Maps approach one of the most important properties is semigroup property, i.e.:

$T_a\left(T_b(v)\right)=T_b\left(T_a(v)\right)$               (3)

Based on equation (3), equation (4) is constructed for the mutual authentication between User and CSP as:

$v_{u, c s p}=T_{\text {key }_u}\left(T_{\text {Key}_{csp}}(v)\right)=T_{\text {key}_{csp}}\left(T_{\text {Key}_{u}}(v)\right)$               (4)

where, v=Agreed value, $T_{k e y_u}$=User Secret key, $T_{k e y_csp}$=CSP Secret key, v_u,csp=User and CSP computed value.

After the registration process between User and client, the User can now establish a connection between the User and CSP. After generating a session-key user can send the message-1 to CSP {msg₁: User→CSP}.

$\begin{aligned} & M S G_{U s e r-C S P}=\left\{T_{\text {key }_u}(v), I d_u, I_{c s p}, \operatorname{Hash}_u\right\} \\ & \operatorname{Hash}_u=\left(\operatorname{Id}_u\left\|I d_{c s p}\right\| T_{\text {key }_u}(v) \| \operatorname{Hash}_p\right)\end{aligned}$               (5)

where, $T_{\text {key}_u}(v)$=Computed public value of user, Id_u=Identity of a user, Id_csp=Identity of cloud service provider, Hash_u=Digested information of a user including hash password.

When a user needs the Cloud services, send a message to CSP. The message contains the User's computed public key [$T_{\text {key}_u}(v)$] using his private key 'key', identity [Id_u], particular identity [Id_csp] of CSP to which the User wants to communicate and digest message [Hash_u].

To provide secrecy from adversaries and CSP, users hash the values like [Id_u, Id_csp, $T_{\text {key}_u}(v)$ and Hash_p into Hash_u] and send to CSP. After receiving msg₁ CSP redirects to the client for validation because CSP does not know the User's password for cross verification.

To establish mutual authentication between CSP and the client based on the semigroup property of Chebyshev's polynomial Chaotic Maps approach with equation (3), they form equation (6):

$v_{c s p, c l}= T_{k e y_{c s p}}\left(T_{Key_{c l}}(v)\right)=T_{k e y_{c l}}\left(T_{{Key}_{c s p}}(v)\right)$               (6)

where, v=Agreed value, $T_{k e y_{c l}}$=Client Secret key, $T_{k e y_{c s p}}$=CSP Secret key, v_csp,cl=CSP and Client computed value.

After computing the session key between CSP and client, CSP can now establish a connection between CSP and client. Message-2 sent by CSP to client {msg₂: CSP→CL}.

$\begin{aligned} & M S G_{c s p-c l}=\left\{M S G_{U s e r-c s p}, T_{k e y _{c s p}}(v), I d_{c s p}, I d_u, I d_{c l}, \operatorname{Hash}_{c s p}\right\} \\ & \operatorname{Hash}_{c s p}=\operatorname{Hash}\left(I d_u\left\|I d_{c s p}\right\| T_{Key,ycs}(v) \| v_{c s p, c l}\right)\end{aligned}$               (7)

where, $T_{\text {key}_{c s p}}(v)$=Computed public key of CSP, Id_u=Identity of a user, Id_csp=Identity of cloud service provider, Id_cl=Identity of a client, Hash_csp=Digested information from CSP.

CSP redirects the received msg₁ from a user and generate the msg₂, which contains the user's computed public key [$T_{\text {key}_{u}}(v)$] using his private key 'key', CSP's computed public key [$T_{\text {key}_{c s p}}(v)$] using his private key 'key', identity [Id_u], particular identity [Id_csp] of CSP to which the User wants to communicate, particular identity [Id_cl] of the client to which the CSP wants to communicate and digest message [Hash_u] from a user, digest message [Hash_csp] from a CSP. For message integrity, CSP hash the values like [Id_u, Id_csp, $T_{\text {key}_{c s p}}(v)$ and v_csp,cl into Hash_csp] and send it to the client.

Client computes the Hash_cl based on the information of $\mathrm{msg}_2$ and compares the hash values: Hash_cl== Hash_csp.

If both are equal, then it validates msg₁ by computing Hash_u using stored digested password Hash_p which is associated with Id_u, then validate by comparing computed Hash_u with received [Hash_u] from a CSP.

$\operatorname{Hash}_u(C S P)==\operatorname{Hash}_u($ from Client $)$

If validation is successful, then the client sends a message-3 to CSP {Msg₃: CL→CSP}.

$\begin{aligned} & M S G_{c l-c s p}=\left\{I d_{c l}, \operatorname{Hash}_{c s p}, \operatorname{Hash}_u\right\} \\ & \operatorname{Hash}_{c s p}=\operatorname{Hash}\left(I d_u\left\|I d_{c s p}\right\| T_{\text {Key }_{c s p}}(v) \| v_{c s p, c l}\right) \\ & \operatorname{Hash}_u=\left(I d_u\left\|I d_{c s p}\right\| T_{\text {key }_u}(v) \| \operatorname{Hash}_p\right)\end{aligned}$               (8)

where, Id_cl=Identity of a client, Hash_csp=Digested information from Client, Hash_u=Digested information of a user including hash password.

If validation is unsuccessful, then the client sends a message-3 to CSP {msg₃: CL→CSP}.

$M S G_{c l-c s p}=\left\{I d_{c l}\right.$, Hash $\left._{c s p}\right\}$               (9)

where, Id_cl=Identity of a client, Hash_csp=Digested information from Client.

If validation is successful from the client, then the CSP validates msg₃ by comparing received and computed hash values.

$\operatorname{Hash}_{c s p}==\operatorname{Hash}_{c l}$

If both are equal, then it validates msg₁ by comparing computed Hash_u from the client with received [Hash_u] from a user.

$\operatorname{Hash}_u($ User $)==\operatorname{Hash}_u($ from Client $)$

If validation is successful, then the CSP sends a message-4 to the User {msg₄: CSP→User}.

$\begin{aligned} M S G_{c s p-u} & =\left\{I d_{c s p}, \operatorname{Hash}_{c s p-u} \operatorname{Hash}_u\right\} \\ \operatorname{Hash}_{c s p-u} & =\operatorname{Hash}\left(\operatorname{session} \operatorname{key}\left[v_{c s p, u}\right]\left\|I d_{c s p}\right\| I d_u \| \operatorname{Hash}_{c s p}\right)\end{aligned}$               (10)

After successful validation of msg₄ received from CSP by the User and access to the cloud services.

$v_{u, c s p}=T_{k e y_{c s p}}\left(T_{Key_{_u}}(v)\right)=T_{k e y_u}\left(T_{\mathrm{Key}_{c s p}}(v)\right)$               (11)

A case study shows the construction session-key between User 'u' and Cloud Service Provider 'csp' agrees on 'v'.

Assume v=3.

The User selects the private key as a large prime number as '$T_{\text {Key}_{u}}$'=5 and calculates the public key with the agreed value ['v'] using Chebyshev's polynomial Chaotic Maps approach based on Diffie Hellman key exchange.

According to Eq. (4):

$T_{\text {Key}_{u}}$=5 is a selected secret key of a user.

$T_{\text {Key}_u}(v)$=5*3=15 computed public key by a user.

Similarly, CSP selects the private key as a large prime number as '$T_{K e y_{c s p}}$'=7 and calculates the public key with agreed value 'v' using Chebyshev's polynomial Chaotic Maps approach based on Diffie Hellman key exchange.

$T_{K e y_{c s p}}$=7 is a selected secret key of a CSP.

$T_{K e y_{c s p}}(v)$= 7*3=21 computed public key by CSP.

Client computes session key using $T_{\text {key }_{c s p}}\left(T_{\text {Key}_u}(v)\right)$ and sends $T_{K e y_{c s p}}(v)$ to User along msg₄. After receiving msg₄, the User computes the session key by using $T_{\text {key }_{c s p}}\left(T_{\text {Key}_u}(v)\right)$. Both will substitute the values in equation (4):

$v_{u, c s p}=T_{k e y_u}\left(T_{\text {Key}_{c s p}}(v)\right)=T_{k e y_{c s p}}\left(T_{\text {Key}_u}(v)\right)$

session key=5(7*3)=7(5*3)

session key=5(21)=7(15)

session key=105=105

Resultant values are equal, and then communication is established between the User and CSP using an agreed session key.

3.3 Mutual authentication and key agreement in User–Client–CSP

Figure 3 describes the handshake mutual authentication process in a step-by-step fashion between the User, Cloud Service Provider, and the client of the proposed scheme. The mutual authentication mechanism works on Chebyshev's polynomial Chaotic Maps approach based on the Diffie Hellman key exchange. In this approach, the registration process takes place between cloud users (u) and clients(cl). The User selects two keys: the private key and the public key.

The User selects the private key from a large prime number, i.e., 'Key_u' and computes the polynomial value by applying the recurrence relation based on Chebyshev's polynomial Chaotic Maps approach, i.e., $T_{\text {Key}_u}(v)$. 'v' is a mutual value between cloud users(u), clients(cl) and cloud service provider (csp). Before starting the communication, (i) cloud users(u), (ii) clients(cl) and (iii) cloud service provider [(csp)] agreed on the value 'v'.

$v=$ agreed key between user and client

$T_{\mathrm{Key}_u}(v)=$ Public key

The User [(u)] selects two parameters to get into the cloud to access the services. The parameters are identity [Id_u], and password ['p']. To avoid insider attacks, users digest the password as Hash_p. The User {Id_u, Hash_p} shared through a secure channel to the client. The client stores users securely in the server database for future validation.

3.png

Figure 3. Handshake between User, Cloud Service Provider, and Client

3.4 Mutual authentication flowchart

4.png

Figure 4. The flow of Mutual authentication agreements among Users, Cloud Service providers, and Client

The previous section's explanation of mutual-authenticated key agreement is represented in the flowchart, i.e., Figure 4. It shows the flow of the PBMAK algorithm; initially, the algorithm takes input as User(Id_u), CSP(Id_csp), Client(Id_cl), whereas Client is responsible for authenticating Users as well as CSP.

Client, Users, and CSP agree on one common value to generate a session key for session creation to exchange the information. In this process, users request cloud services from a cloud service provider. Before establishing a session key, they validate each other for mutual authentication; after verification, User and CSP establish a session key, and the User can access the authorized services from the cloud.

While validation, if [H'_u!=H_u] or [H_u!=H'_u], then the connection is rejected.

3.5 Mutual authentication algorithm

Algorithm.1 shows the Algorithm of the Mutual Authentication Agreement. This algorithm requires three parameters as User(Id_u), CSP(Id_csp), Client(Id_cl), each agrees on a value 'v' before establishing a communication path.

Algorithm 1. Mutual Authentication Agreement

Input: User(Id_u), CSP(Id_csp), Hash_u, Client(Id_cl)

Output: Mutual Authentication

User send $M_{U-c s p}=\left\{T_{\text {key }_u}(v), I d_u, I d_{c s p}, \operatorname{Hash}_u\right\}$ to CSP

CSP send $M_{c s p-c l}=\left\{M_{U-c s p}, T_{k e y_{c s p}}(v), I d_{c s}, H a s h_{c s p}\right\}$ to CL

CL compute H'_u with user stored digested password Hash_p

CL send M_cl-csp=$\left\{\mathrm{Id}_{\mathrm{cl}}, \operatorname{Hash}_{\mathrm{cl}}=\left[\mathrm{H}_{\mathrm{u}}^{\prime}\right], \operatorname{Hash}_{\mathrm{u}}=\left[\mathrm{H}_{\mathrm{u}}\right]\right\}$

CSP compares H'_u=H_u

CSP Send M_csp-U =$\left\{\right.Id_{c s p}, I d_u, Hash \left._{c s p}, T_{k e y_{c s}}\right\}$

CSP and User generate a session key

$v_{c s p, u=} T_{k e y_{c s p}}\left(T_{K e y_u}(v)\right)=T_{\text {key}_u}\left(T_{\text {key}_{c s p}}(v)\right)$

If resultant values are equal

$T_{{key}_{c s p}}\left(T_{{Key}_u}(v)\right)=T_{{key}_u}\left(T_{{key}_{{csp }}}(v)\right)$

Connection establishes.

$T_{{key}_{c s p}}\left(T_{{Key}_u}(x)\right) \neq T_{{key}_u}\left(T_{{key}_{{csp }}}(v)\right)$

Reject

3.6 Result analysis

The proposed mutual authentication mechanism restricts unauthorized users and prevents insider, reply, and man-in-the-middle attacks.

3.7 Security analysis

By assuming adversaries have complete control over the transmission path. The following are the mathematical security analysis proofs of the proposed mutual authentication mechanism.

(i) Mutual Authentication over PBMAK

The PBMAK algorithm outlines a trust flow involving the User, Client, and CSP in mutual authentication.  The algorithm enables users to verify the accessibility of the session key created by the client, allowing sharing without divulging a secret key.

$v_{u, c l}=T_{\mathrm{key}_u}\left(T_{\mathrm{Key}_{c l}}(v)\right)=T_{\mathrm{key}_{cl}}\left(T_u(v)\right)$               (12)

The client must authenticate the User and CSP simultaneously because the client has a pivotal position in the authenticated key exchange phase. The client authenticates CSP and User by validating Hash_csp with v_csp,cl and v_u,cl.

CSP first authenticated the client by validating the Hash_csp with v_csp,cl. After that, CSP will trust the User because Hash_csp contains $T_{K_{c s p-u}}(v)$. As for the key agreement, after authenticating each other, the User and CSP can make the key agreement.

(ii) Insider attack over PBMAK “Insider Attack attempting to gain unauthorized access”

At the time of the registration, the User selects 'id', the password 'p' and the secret key 'key'. Compute 'key' with Chebyshev's polynomial Chaotic Maps approach along with agreed value 'v', and named as $T_{\text {Key}_u}(v)$. Also, the User generates the hash value of the chosen password Hash(p), i.e., Hash_p assumes that this password [Hash_p] communicates with cloud client through a secure channel with corresponding chosen 'id'. The client stores the user password [Hash_p] associated with 'id' for future verification. Even the client is unaware of the User's correct password.

(iii) Reply attack over PBMAK “unauthorized attempts to replay previously exchanged communication between User, client, and CSP to gain illegitimate access”

Communication exchange through the secure path using User, client, and CSP created session key. Here, we assure that the sender and receiver are either User and client or User and CSP or client and CSP because CSP and User validate with v_csp,u and v_u,csp. The client validates both by using v_cl,u and v_cl,csp. These session keys can be created only with their agreements.

(iv) Man-in-the-middle attack over PBMAK” attacker trying to impersonate a client, CSP, or User by intercepting and manipulating the key exchange process”

An adversary tries to impersonate a client, CSP or User but not because pretending as one of them requires a secret key of the User as 'K_u', the client as 'K_cl', and CSP as 'K_csp'. These private key values are chosen from large prime values. The private key was never shared with any of them and nowhere stored; the client stores the User's password as the hash value.