D-FAP: Dual-Factor Authentication Protocol for Mobile Cloud Connected Devices ^†

Abstract

Emerging Mobile Cloud Computing (MCC) technologies offer a new world of promise by leveraging the quality of mobile services. With MCC, resource-constrained mobile devices could capitalize on the computation/storage resources of cloud servers via communication networks. While MCC adoption is growing significantly, several challenges need to be addressed to make MCC-based solutions scale and meet the ever-growing demand for more resource intensive applications. Security is a critical problem hindering the adoption of MCC. One of the most important aspects of MCC security is to establish authenticated communication sessions between mobile devices and cloud servers. The huge amount of data stored on mobile devices poses information security risks and privacy concerns for individuals, enterprises, and governments. The ability to establish authenticated communication sessions between mobile devices and cloud servers can resolve many security concerns. Limited computing and energy resources on mobile devices makes authentication and encryption a challenging task. In this paper, an overview of MCC authentication protocols is presented. Then, a Dual-Factor Authentication Protocol for MCC devices (D-FAP) is proposed. D-FAP aims at increasing authentication security by using multi-factors while offloading computation to the cloud to reduce battery consumption. The security of the protocol is formally verified and informal analysis is performed for various attacks. The results prove that the D-FAP is successful in mitigating various outsider and insider attacks.

1. Introduction

With the large-scale proliferation of smart mobile devices, an enormous amount of applications have been developed. Such applications can encounter significant challenges, including limited mobile battery life to cope with power hungry applications, insufficient bandwidth, complex, and varied mobile architecture and most importantly a potential attack vector for cybercriminal activities [1]. These applications also require high levels of storage and high processing capabilities. Mobile Cloud Computing (MCC) has been introduced to tackle these challenges. MCC combines such applications with the power-rich resources of the cloud.

Introducing MCC offers several benefits to mobile users. Firstly, MCC prolongs the lifetime of mobile devices. Offloading techniques allow transferring heavy weight computations and complex processing to the power rich cloud servers to utilise their capabilities, resulting in a significant power conservation of mobile devices. Secondly, MCC enables mobile users to store/access huge amounts of data on the cloud through wireless networks. For example, Google Photos can stores users’ photos and videos on the clouds immediately after capturing and allow access to them from any connected device. This also contributes in conserving a considerable amounts of energy and storage capacity on their mobile devices. Thirdly, MCC can efficiently support various tasks for data warehousing, managing and synchronizing multiple documents online. For instance, clouds can be used for playing online games, transcoding, or broadcasting multimedia services. Thus, all intensive processing that takes a long time when performed on mobile devices will be migrated the cloud. Finally, MCC improves reliability by backing up data and applications on a several of cloud servers. MCC can remotely provide security services such as virus scanning, malicious code detection, authentication, etc.

However, MCC poses several challenges. Mobile devices use a combination of heterogeneous wireless networks, networks that are known to be more energy intensive than their wired counterparts [2,3]. Furthermore, MCC provides the mobile device with a remote platform that is ‘always online’ with which the mobile device interacts frequently. The device is therefore communicating via the wireless network more often than usual, leading to increased levels of power consumption on the mobile device [2,4]. Another significant challenge for MCC is ensuring security, privacy, and trust [5,6]. Accessing cloud services grants access to a mobile device and potentially therefore access to personal or sensitive information, financial information, healthcare records, etc., which are stored on the device. Thus, more security is needed to ensure confidentiality and privacy of user’s data which is stored in the cloud. Additionally, stronger authentication processes are needed to ensure access is only given to authorized persons [7,8,9,10,11].

Significant research has been carried out to explore ways to improve the security and efficiency of the authentication process, some of which puts heavy emphasis on the complexity and the number of authentication factors, neglecting the limitations addressed above [12,13,14,15]. Some research has attempted to address these limitations by moving the authentication processing into the cloud. However, it is well known that the process of communication can be power hungry; therefore, offloading data to the cloud to be processed seems counter-productive, especially if the mobile device is acting as a dumb terminal.

Migrating computation from the mobile device to the cloud seems to be an attractive notion as it minimizes the impact of the authentication processing on the mobile device, which in turn improves its performance. The impact of security algorithms on energy consumption was analyzed in ref. [16]. An experiment was conducted to measure the energy consumption during the processing of executing security protocols. It was found that, for a typical iPhone battery, with a capacity of 18 KJ, the experiment showed that, with encryption carried out on the device, the battery would run out of charge three times faster than when encryption was not carried out by the device.

To address the energy consumption issue, a significant amount of research has been undertaken to investigate computational offloading to improve performance and save energy for mobile devices [17]. Taking the illustrations above, the inspiration for D-FAP came from a need to address the energy consumption problem, at the same time as finding a secure and efficient method to carry out the authentication process without exerting too much pressure on the limited resources of the mobile device. In addition, aiming to achieve minimal energy consumption, two-factor authentication is implemented as it involves the minimum number of authentication factors. It has been shown that it will reduce power consumption and improve likeability and adoptability of security protocols [18].

This paper extends our previous work in ref. [19] which introduces the blueprints of a new authentication protocol that would address the mobile devices resource limitations to conserve their energy and address the security issues of the MCC. The protocol produces a secure and reliable dual factor authentication that is based on smart card and password authentication methods. In this paper, an implementation and evaluation of the proposed protocol has taken place. The performance of the protocol is evaluated via formal system tool “ProVerif” and informally analyzed for various attacks. Results demonstrate that the proposed protocol (D-FAP) is reliable and secure. D-FAP addresses the power issue of offloading the processing of the authentication to an alternative medium using a smart card, which is known to be more secure and efficient for carrying out such tasks.

The proposed work makes the following contributions: (1) D-FAP addresses the mobile devices resource limitations to conserve their energy by avoiding complicated algorithms with long and convoluted processing. (2) D-FAP addresses the security issues of the MCC even in the event of mobile device loss. (3) The performance of D-FAP is evaluated to ensure it security against an active attackers. (4) D-FAP is compared against existing MCC authentication protocols to measure its viability.

The remainder of this paper is organized as follows. Section 2 surveys authentication protocols designed for smart mobile devices. Section 3 presents the proposed Dual-Factor Authentication Protocol for Mobile Cloud Connected Devices. Section 4 verifies the protocol and provides security analysis and comparisons. Section 5 concludes the paper.

2. An Overview of MCC Authentication Protocols

The exponential growth of the Internet interconnections has led to a significant growth of break-in attacks that can exploit vulnerabilities that exist within the applications, or in the operating system, on the mobile device [20,21,22]. Additionally, any attack on the cellular network can compromise the integrity of information; attacks such as International Mobile Subscriber Identity (IMSI) catchers [23], which feign man-in-the-middle attacks, can target user sensitive information, e.g., locate cellular phones, intercept communication content like text messages and phone calls. Thus, it is considered a real threat to all generations of mobile networks, breaching confidentiality through unauthorized access.

Several authentication approaches have been considered for authenticating users across many different computing platforms, including MCC. Some approaches considered the cryptographic based methods [24,25], where the authentication process is based on exchanging security keys or by using session tickets with trusted third-party entities. Other approaches focus on biometric authentication [26,27], which recognizes the user through physiological or behavioral characteristics unique to the user such as voice recognition, iris scanning, or finger prints. Approaches such as refs. [28,29], use password based authentication, which is the most widely used and accepted, due to its ease of use, its compatibility, scalability, as well as its low cost. To achieve secure, power-efficient and lightweight authentication for MCC mobile devices, dual-factor authentication protocol is introduced, in which two of the above methods are integrated ensuring minimum processing and energy consumption. The remainder of this section provides a comprehensive review of the above approaches.

2.1. Cryptographic Based Methods

Cryptographic based methods are one of the traditional methods used for authenticating users across many different computing platforms, including MCC [30]. The authentication process is based on exchanging security keys or by using session tickets with trusted third-party entities and using the same method for establishing a user’s identity. A considerable research effort has been undertaken in this field.

In ref. [24], the authors proposed an authentication mechanism using an encrypted password and mobile phone token stored within a mobile phone as the authentication factors. In this mechanism, the registration and the management of the user identity information processes are undertaken by an identity provider (IdP). A Single Sign On (SSO) functionality is provided using secure Access mark Up Language and does not require a password table. This mechanism was a positive attempt to address SSO issues. The mechanism features mutual authentication between the mobile user and the IdP, which increases the security of the authentication process. Yet, the mechanism stores an encrypted password and a token on the mobile device. This could be exploited to compromise the system if the mobile device got stolen or lost.

In ref. [31], a two-factor authentication scheme based on a One Time Password (OTP) was proposed. It used the mobile device for authentication alongside a 4-digit PIN, through a Java application installed on the mobile device, and this in turn generated an OTP, a secret random number which was stored on the mobile device, and a time stamp. The OTP, the random number, and the time stamp were hashed using MD5 (one of a series of message digest algorithms), and the user name and OTP were sent to the remote server for authentication. This system used a time stamp and OTP to eliminate any replay attacks. And, it proved to be lightweight by reducing the number of authentication factors to two. However, it proposed to use MD5, which is found to be vulnerable to attacks such as brute force attacks [32]. The scheme used the Java application to generate a 4-digit number to generate the OTP. However, if the mobile was stolen or lost, an attacker could use it to impersonate the user to login to the remote system.

The authors of ref. [25] proposed a lightweight protocol for mobile cloud environment based on local mobile network authentication. The protocol was divided into two phases; registration phase, and mutual authentication phase, where the mobile user registered with their mobile service provider by entering their International Mobile Station Identification number (IMSI) and a personal secret. The service provider issued the user with an Authentication Certificate (AC) and the user used the secret key provided with the certificate to encrypt the login messages. Once the login was successful, a session key was established and used for further communications. The protocol was lightweight as it used only two-factor authentication, symmetric encryption was also low in computational costs, and it also has a low latency. However, the protocol did not establish a secure channel, which made it susceptible to attacks. The AC was stored on the mobile device so if the mobile device was lost, stolen, or compromised, the device could be used for impersonation attacks.

2.2. Biometrics Based Methods

Biometrics is considered one of the promising authentication methods due to the fact that its resistance to losses and theft. Biometric data appear to provide the ideal means of identity verification, because they are unique and permanently attached to their owner. Although using biometrics methods has many advantages, it introduces its own challenges. It introduces privacy concern, biometrics may also disclose user’s sensitive information, such as race, gender, even health conditions. Additionally, unlike knowledge-based, personal information, biometric data poses significant risks because it cannot be replaced once compromised. For instance, if an attacker obtains someone’s fingerprint data, the victim’s identity is permanently compromised [33].

Users cannot change their biometric over and over like passwords due to the fact that human has a limited number of biometric traits, making biometric templates are hard to be replaced. Recently, many smartphones manufacturing companies have been focusing on implementing biometric technologies on smartphones (e.g., fingerprint, iris scanning, facial recognition). However, biometric systems are made up of vulnerable components such as capture devices, communication channels, and databases, which are susceptible to several attacks [34]. The protection of the biometric data is crucial since biometric systems introduce vulnerabilities that can be exploited by hackers to break into the system.

The authors of ref. [27] proposed a real-time biometric recognition system that is based on Orthogonal Line Ordinal Features (OLOF) extraction technique. The processing of the authentication is distributed on the mobile device and the server. The use of palm print that can be easily captured provides more security than any other authentication methods. However, this system could lead to a delay in the authentication process due to the intensive processing that is carried out by the mobile device (i.e., the capturing of the image, the correction of alignment functions, and the collection of data in display image and transmission). Additionally, it does not protect the biometric data from exposure during the authentication process. This method showed that using biometrics to authenticate the user may affect a protocol’s ability to be lightweight.

The authors of ref. [35] implement a novel authentication verification scheme that combines human inherence factor (handwritten signature biometrics) with the standard knowledge factor (traditional user-specified password) to achieve an enhanced level of security. The major computational load is shifted on a cloud based application server so that a platform-independent user verification service with ubiquitous access becomes possible. In this scheme, Google Application Engine (GAE) is used as a cloud service provider, a hierarchical approach is used to perform signature matching and to ensure the authenticity of biometric, decision forest classifier is used. The proposed scheme is easily scalable and is available to use on mobile platforms such as smart phones and PDAs. The cost and resource requirements of the proposed SaaS are low and independent of the user end platform. However, this scheme works well in smaller group environment but not suitable for large groups.

Recently, the authors of ref. [36] proposed a novel multifactor two-server authenticated scheme under mobile cloud computing (MTSAS). In the MTSAS, it divides the authentication method and authentication means; in the meantime, the user’s biometric characteristics cannot leave the user device. Thus, MTSAS avoids the fingerprint information disclosure, protects user privacy, and improves the security of the user data. In addition, considering user actual requirements, MTSAS provides the different authentication factors depending on the privacy level of the authentication. However, this scheme suffers from a problem in case of the loss of the user device, apparently, it may take the problem of data redundancy in the cloud when the user performs registration again.

2.3. Password Based Methods

Among the diverse types of two-factor authentication mechanisms, the password based is one of the most widely used and accepted, due to its ease of use, its compatibility, scalability, as well as its low cost [37]. In such authentication protocols, the cloud authenticating server stores a user chosen low entropy password in a verifier table that is used to verify the existence of the user. This password is secured by adding a random number called salt, and the resultant is hashed using a one-way hash function such as SHA, NTLM, or MD5.

The authors of ref. [26] have proposed a fuzzy vault authentication protocol. The protocol is based on digital signatures and zero-knowledge authentication. Asymmetric RSA Keys were used to provide authentication for the mobile device and the server. A fuzzy picture password method was used to provide authentication and usability, especially when users have a difficult time remembering a password required for sufficient length and randomness to be secure. Upon completing the authentication process, a secure communication channel is set up to connect the mobile device with the cloud server. The server starts exchanging Diffie–Hellman (DH) public values with the client. This gives the protocol resistance to man-in-the-middle, impersonation attacks, reply attacks, and sniffing attacks. However, the high amount processing on the client side (mobile device) leads to energy wastage and less battery lifetime. Moreover, the existence of the fuzzy image data on mobile device could be exposed, exported, or copied in the case of device loss.

The authors of ref. [28] recently proposed a message digest authentication scheme (MDA) that strategically incorporates hashing, in addition to traditional user ID and passwords, to achieve mutual authentication. MDA consists of three stages: registration, verification, and update. MDA utilizes hashing, which supplements traditional user ID and password based authentication, to ensure differentiation and sum during the verification stage. The performance of MDA was evaluated using Scyther, a widely-used security protocol analyzer. Results show that MDA can withstand several attacks, such as man-in-the-middle, and replay attacks. However, an attacker could exploit the password tables by carrying out a password guessing attack to compromise users’ passwords or to discover user specific details such as the user ID and the message digest. This leads to giving the attacker the ability to use these user credentials to impersonate the legitimate user, to login to other servers in the cloud.

In order to address the password leakage from compromised remote servers, the authors of ref. [29] proposed a highly efficient cryptographic protocol by distributing the files and the user data across multiple over multiple servers in the cloud. However, in this protocol, all servers jointly validate whether the password matches or not. Moreover, the protocol suffers from password leakage on the user side. Therefore, while improving server security in general is a crucial long-term goal, helping users make stronger passwords is an immediate step that can help to protect users.

2.4. Smart Card with Password Based Methods

Password authentication with smart card is considered one of the most convenient and effective dual-factor authentication protocols in distributed systems. It assures one communicating party of the authenticity of the corresponding party by acquisition of corroborative evidence. A smart card with a password based method has been widely deployed for various kinds of daily applications—for instant, e-banking, e-government, and e-health applications.

A mobile user may initially insert the user’s smart cards into a smart card reader electrically connected with their mobile devices, and then launch a reader application on the mobile device designed to retrieve the user’s identity certificate from the smart card (a first authentication factor). Thereafter, the user may launch an application or navigate to a particular website whereby the user may be required to enter a password (a second authentication factor) before access to the system is granted. For instance, many military and governmental agencies maintain policies stipulating use of smart cards by military and civilian personnel for purposes of authenticating the holder’s identity (e.g., a smart card may employ public key infrastructure (PKI)) [38].

Existing smartphones are not equipped with a smart card reader; thus, they suffer from their inherent limitations in relation to two-factor authentication using smart cards. Several of companies have attempted to introduce solutions to address this limitation. Thursby Software [39], for example, has developed the PKard reader that can be connected to Android and Apple devices. PKard readers are plug-in readers that support a wide range of smartphones from different vendors. Additionally, ACS [40] has developed smart card readers that use NFC contactless technology with Bluetooth technology. However, existing standards complicate the integration of smart card devices, and do not adequately address interoperability between products from multiple vendors.

Smart card based methods have several benefits. First, it is assumed to be tamper-resistant, i.e., the secret information stored in the smart card cannot be revealed. Therefore, it reduces the security risk in case of mobile device loss or theft. Second, it represents an efficient and reliable environment for carrying out authentication, hence, saving on the battery consumption of the mobile device. Third, it adds to the security of the MCC by protecting the privacy of information.

The first smart card authentication protocol based on the password method was introduced by ref. [41]. In this protocol, the authors proposed a remote authentication system based on the Chinese remainder theorem, which consisted of three phases. The login information was stored on a smart card, which was used by the user to login to the remote server, which would in turn check and verify the user credentials and accept or reject the user accordingly. In this protocol, the password was generated by a password-generating center.

Recently, many smart card authentication protocols based on the password were proposed [42,43,44]. Most of these protocols are still vulnerable to ID-theft attack, offline password guessing attacks, undetectable online password guessing attacks, and user impersonation attack.

The authors of ref. [45] show that the most important aim of the smart card based password authentication protocols was to achieve ‘true’ two-factor security. This meant that the only user who could access the authentication server was the one with full knowledge of the password and who was in possession of the smart card. They also emphasized that any two-factor protocol design should adhere to the following security criteria:

(a)

An adversary with no knowledge of the user’s password, but who had full access to the user’s smart card and was able to extract the security information stored on the card, should not be able to extract the user’s password by performing an offline guessing attack;

(b)

An adversary with full knowledge of the user’s password, but who was not in possession of the user’s smart card, should not be able to attempt to impersonate the user to login to the cloud server.

There has been much research in the field exploring the use of smart cards using password based authentication. A common theme in all these protocols was that they used smart cards with a static user 𝐼𝐷, which was susceptible to identity theft. This was because the authentication process was carried out over an insecure channel of communication. There have been many identity violations over the years and these have raised concerns of user privacy among many users and human rights organizations.

To address this specific concern, the authors of ref. [46] introduced a very innovative and novel mechanism to protect the user identity, by employing a method to dynamically change the user 𝐼𝐷 for each transaction session. This eliminated 𝐼𝐷 theft or impersonation attacks. Many protocols such as ref. [46], however, did not employ mutual authentication. Although this protocol claimed it was secure against most attacks, it was shown by many protocols that followed that it was vulnerable to many attacks, such as denial of service and stolen verifier attacks [47].

Subsequently, many authentication protocols followed in the footsteps of ref. [46], such as refs. [48,49]. However, the development of a fully efficient and secure authentication protocol has proven to be a difficult task to achieve due to the limitations of smart card resources, e.g., battery life and storage capacity [50].

Authentication protocols based on symmetric key primitive, such as hash-based message authentication code (HMAC), XOR, and symmetric encryption are therefore more efficient and desirable than the more expensive asymmetric key primitive, such as point multiplication, exponentiation, and pairing.

Authentication protocols based on symmetric key primitive that are more suitable for smart cards were proposed in refs. [51,52]. However, all these protocols were vulnerable to various attacks as shown in refs. [45,53].

In 2009, the authors in ref. [54] proposed a dynamic 𝐼𝐷, smart card based protocol. The protocol’s security was analyzed [55]. Here, the authors showed that the protocol in ref. [54] was susceptible to impersonation attacks. An authorized user (adversary) could access the system legally using their credentials, could obtain other users’ secret information, and, armed with this information, the adversary could then launch an offline dictionary attack to obtain those other users’ passwords.

Ref. [55] proposed a protocol to enhance the security of ref. [54], and they claimed that their protocol was fully compliant with all the requirements set out in ref. [47]. The protocol did not store the user 𝐼𝐷 in the server and therefore claimed that the user 𝐼𝐷 was fully protected by anonymizing it and not storing it on the server.

Many other protocols followed ref. [55], which analyzed and criticized each other’s protocol, exposing the weaknesses and proposing their own improvements to eliminate those vulnerabilities. However, they presented their new improved protocol without proper analysis of the security and efficiency aspects, and this was then followed by other researchers then repeating the same process, criticizing those protocols again and proposing their own improvements. An example of such a protocol is one that was introduced in 2012 in ref. [56]. The authors pointed out the security weaknesses of the protocol in ref. [55], proposing their own improvements, but, as it was not thoroughly researched and analyzed as explained; it was then attacked by other researchers. This is unfortunately the ongoing situation with most other research in this field.

In 2015, the authors of ref. [57] proposed a new authentication protocol for distributed MCC services based on Elliptic curve cryptography. The protocol aims at authenticating mobile users to access cloud computing services from multiple service providers who use only a single private key. It included three entities: user, smart card generator, and Cloud Service Provider (CSP). Public and private keys are generated when the user and CSP get registered with a smart card generator. Therefore, they can authenticate each of them without the involvement of the Smart card generator. The protocol reduces authentication processing time required by communication and computation between cloud service providers and a traditional trusted third party service. It is claimed that the protocol supports mutual authentication, key exchange, user anonymity, and can resist a lot of attacks and meets general security requirements. However, the protocol is insecure against a server forgery attack.

To mitigate the security weakness of the above protocol [57], the authors of ref. [58] have developed an authentication protocol for mobile users that is also based on using elliptic curve cryptography (ECC). The proposed protocol enables users to access MCC services from multiple CSP by using a single private key. The methodology improved the authentication phase to prevent server forgery attack and was validated in ProVerif automatic cryptographic protocol verifier [59], which showed that the proposed work being more secure and robust as compared to the work of [57]. However, due to the expensive cost of the bilinear pairing, their protocol did not yield better performance.

3. D-FAP in Detail

D-FAP mainly focuses on the most general case of smart-card-based password authentication, where the participants involve a set of users and a single remote server. A common design architecture model that was suggested in ref. [45] faithfully follows many designers of similar schemes. D-FAP is based on the same model which consists of three phases, i.e., registration, login, and verification (authentication).

In the registration phase, a user chooses the login credentials and fills a registration form providing some personal information to the server. The server issues a smart card which may contain some sensitive security parameters. After completing the registration phase, the user will be able to access the server in the authentication phase. The dual-factor protocol ensures that only the user who possesses both a valid smart card and the corresponding password can be successfully verified by the server. The notation used in D-FAP protocol is provided in

Table 1. Notation used in D-FAP.

Notation	Description
$C$	Random number
$CF$	Column number where user information stored
$h(.)$	One-way hash function
$ID$	User’s ID
${MD}_u$	User message digest
$N_i$	Nonce
$PW$	User’s password
$S$	Remote server identity
$SC$	Smart card
$SI$	State identifier
$T$	Time stamp
$\Delta T$	Expected valid time interval
$U$	User
$V_i,A_i$	Security parameters
$X_s$	Secret value of server (to be stored on server)
$y$	Secret value of server (to be stored in smart card)
$\oplus$	Bitwise XOR computation
$\left|\right|$	Concatenation operation

.

3.1. Registration Phase

Prior to registration, the user obtains a digital certificate by registering with a digital certificate authority. The digital certificate comprises the public key and the digital signature of the user, along with its identity information. The registration phase is carried out only once unless the user re-registers. At this stage, the user enters their user 𝐼𝐷 and chooses a password. The password will be necessary later, and, in future logins, to ensure that the user is the legitimate owner of the smart card, i.e., is not an imposter. The user 𝐼𝐷 and password are processed and sent securely to the server.

On receipt of the user 𝐼𝐷 and password the server checks its user database to see whether the user is an existing user or a new user. If it is a new user, then the server registers the user and computes security parameters that are unique to the user. Security parameters are stored in a smart card, in a process called Smart Card Personalization. Smart cards are designed to be tamper proof and the user’s security parameters, along with the server’s secret key, are therefore, safely stored in the smart card, making it more difficult for an adversary to access these data. The registration phase is divided into two sub-phases: user registration and server registration.

3.1.1. User Registration

The user first registers with a Cloud Service Provider (CSP). At this stage, the following events will take place:

• 𝑈 signs up with a CSP a by accessing a secure registration URL;
• 𝑈 chooses a new User 𝐼𝐷 and password, at this point, the user is prompted to load their digital certificate (the user’s public key is encapsulated within the public digital certificate). The CSP will use the information provided by the certificate to identify the user, and the public key encapsulated within the certificate, to encrypt future communication with the user;
• To enhance the security of the user password, one of the most efficient ways is to employ ‘salting’ and ‘hashing’. Once the user enters their credentials, the server remotely:
  • generates a random number 𝑐 on the mobile device side,
  • concatenates the random number with the password (salting),
  • hashes the outcome with a suitable one-way hash function (hashing), i.e.,: 𝑅𝑃𝑊_𝑖 = ℎ₀(𝑐ǁ𝑃𝑊_𝑖),
  • encrypts 𝑅𝑃𝑊_𝑖 𝑎𝑛𝑑 𝐼𝐷_𝑖 using the server’s public key;
• 𝑈 uploads {𝑅𝑃𝑊_𝑖, 𝐼𝐷_𝑖} to the server using a secure encrypted channel. This can be done by using an SSL protected URL. The main purpose of this is to protect the user credentials from being sniffed by an eavesdropper.

3.1.2. Server Registration

As soon as the remote server receives the user’s registration, the following events are performed by the server:

• Record the time of receipt of registration 𝑇_𝑟𝑒𝑔. This is used to identify if the user is a registered user and, if so, when s/he was registered, and also to generate the nonce;
• Check if the user is a new user by checking its database of existing users. This is done to protect against user duplication;
• If the user is a new user, the server checks the validity of 𝑈’s digital certificate in order to guarantee its authenticity and it checks if the certificate belongs to the user being registered (if the user is already registered, then they will be rejected);
• Obtain 𝑈’s public key from the digital certificate, which is used to encrypt future communication with the client;
• 𝑈’s access policy file, including 𝑈’s usage policy and access level, is concatenated with 𝑈’s digital certificate, and the result is hashed using a suitable one-way function creating the message digest 𝑀𝐷_𝑢 = ℎ₀ (𝑈𝑠𝑒𝑟 𝑝𝑜𝑙𝑖𝑐𝑦 ǁ 𝑈𝑠𝑒𝑟 𝑐𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒). 𝑀𝐷_𝑢 is used for mutual authentication with the client, and it can also be used to identify the user;
• Generate the 𝑆 secret keys 𝑥_𝑠 and 𝑦. 𝑥_𝑠 is used by the remote server to generate security parameters for future communications with the smart card. 𝑦 is stored by the remote server in the smart card to be used by the smart card to generate security parameters for future communication with the server;
• Create a new user account in the user database with the following parameters stored on the database: 𝐼𝐷_𝑖, 𝑇_𝑟𝑒𝑔, 𝑀𝐷_𝑢;
• Compute 𝐴_𝑖 = ℎ₀(𝐼𝐷_𝑖 ⊕ 𝑥_𝑠);
• Compute 𝑉_𝑖 = 𝐴_𝑖 ⊕ 𝑅𝑃𝑊_𝑖;
• Create nonce 𝑁_𝑖 = ℎ₀(𝑃𝑊_𝑖 ǁ 𝑐) ⊕ ℎ₀(𝑥_𝑠 ǁ 𝐼𝐷_𝑖 ǁ 𝑇_𝑟𝑒𝑔), where 𝑥_𝑠 is 𝑆’s secret key;
• Personalize the smart card by storing 𝑉_𝑖, 𝐴_𝑖, 𝑁_𝑖, 𝑀𝐷_𝑢, ℎ(.), 𝑦, and #CF, where #CF is the column number in the database where 𝑈’s records are stored;
• Send the smart card with the reader securely to the client with instructions on how to:

  (a)

  use the smart card with the smart card reader,

  (b)

  keep the smart card secure,

  (c)

  change the password,

  (d)

  unlock the card,

  (e)

  report any loss or theft of the card.

NB. 𝐴_𝑖 and 𝑉_𝑖 are used to enhance the security methods for the smart card, to locally authenticate the user’s password, without actually storing the user’s password on board the smart card.

Figure 1 illustrates D-FAP registration phase.

3.2. Login Phase

The login process is used when the user intends to connect to the remote server. The user inserts his smart card in to the smart card reader and enters his/her user 𝐼𝐷 and password 𝑃𝑊. The smart card validates the user credentials. If the user fails to enter the correct credentials, the smart card should initiate a credential’s failure procedure to avoid password guessing attacks. Password guessing attacks may lead to impersonation attacks, or attempts by an attacker to change the password which can lead to a denial of service attack. However, if the user enters valid credentials, the smart card will generate an authentication message and send it to the server over the insecure channel.

It is noted that many design schemes tend to generate the authentication message without checking the validity of the user’s credential first, making those schemes vulnerable to impersonation attacks. This needs to be avoided in the new design. The login phase comprises both the local and remote procedures.

3.2.1. Local Authentication between the 𝑈 and 𝑆𝐶

As 𝑈 inserts the 𝑆𝐶 in to the smart card reader, 𝑈 is prompted by the 𝑆𝐶 to enter their 𝐼𝐷 and password 𝑃𝑊. The 𝑆𝐶 checks the validity of 𝑈’s 𝐼𝐷 and 𝑃𝑊 by:

• Concatenating the newly entered 𝑃𝑊′ with a random number 𝑐 and hashing them;
• Computing 𝐴′_𝑖 = 𝑉_𝑖 ⊕ ℎ₀ (𝑃𝑊′_𝑖 ǁ 𝑐);
• Comparing 𝐴′_𝑖 with the 𝐴_𝑖 stored in its memory. If 𝐴′_𝑖 = 𝐴_𝑖, then 𝑆𝐶 proceeds to the remote login operation, else the operation is terminated with the request for 𝑈 to re-enter the password.

3.2.2. Remote Login between 𝑆𝐶 and 𝑆

Once the user is locally authenticated by the 𝑆𝐶, the 𝑆𝐶 carries out the remote login process through the following steps:

• 𝑆𝐶 generates 𝑇_𝑘 = 𝐼𝐷_𝑖 ⊕ ℎ₀(𝑃𝑊_𝑖 ǁ c);
• 𝑇_𝑘 is used as a seed for Crypto Pseudo Random Number Generator (CPRNG) to generate 𝐾𝑎𝑢𝑡ℎ, which is used to encrypt 𝑀𝐷_𝑢;
• 𝑇_𝑘 is used to encrypt {{𝑀𝐷_𝑢} ǁ 𝑆𝐼}, where 𝑆𝐼 is the State Identifier;
• To protect the anonymity of the user, 𝐶𝐼𝐷_𝑖 is generated by creating a dynamic identifier, i.e., 𝐶𝐼𝐷_𝑖 = ℎ₀(𝑃𝑊_𝑖 ǁ 𝑐) ⊕ ℎ₀(𝑁_𝑖 ⊕ 𝑦 ⊕ 𝑇);
• 𝑆𝐶 computes 𝐵_𝑖 = ℎ₀ (𝐼𝐷_𝑖 ⊕ ℎ₀(𝑃𝑊_𝑖 ǁ 𝑐));
• 𝑆𝐶 computes 𝐶_𝑖 = (𝑇 ⊕ 𝑁_𝑖 ⊕ 𝐵_𝑖 ⊕ 𝑦), where 𝑇 is the current time;
• 𝑆𝐶 computes 𝐷_𝑖 = #𝐶𝐹 ⊕ {{𝑀𝐷_𝑢} ⊕ 𝑆𝐼};
• 𝑆𝐶 encrypts the message using’s public key {𝐶𝐼𝐷_𝑖, 𝑁_𝑖, 𝐶_𝑖, 𝐷_𝑖, 𝑇};
• 𝑆𝐶 sends the encrypted message to the server 𝑆.

Because 𝐶𝐼𝐷_𝑖 is dynamic, it means that the user 𝐼𝐷 cannot be predicted. 𝑐 is random which makes ℎ₀ (𝑃𝑊_𝑖 ǁ 𝑐) unpredictable and, therefore, user 𝐼𝐷 theft or a password guessing attack would be extremely difficult to achieve.

Figure 2 illustrates D-FAP login phase.

3.3. Verification Phase

The authentication phase commences when the authentication message is received by the server. The time difference between the time of arrival of the message and the time that the message was sent by the client is calculated. This time difference is important to avoid replay attacks. The server carries out multiple checks to validate the authenticity of the message. Once done, the next step is for the server to establish trust with the client. This is done by performing mutual authentication. The server initiates the mutual authentication process by sending a mutual authentication message to the client. The client, represented by the smart card, checks the mutual authentication message and, if it is authentic, then the smart card computes a session key to be used for future communications between the server and the client.

3.3.1. Server Authentication

Once 𝑆 receives the authentication message, it carries out the following tasks:

• Register the time of message arrival 𝑇∗;
• Calculate the time difference between arrival time 𝑇∗ and authentication message sent time 𝑇, extracted from the received authentication message, i.e., ∆𝑇 = 𝑇∗ − 𝑇. If the time window is acceptable, the message is accepted, else it is rejected. The time difference between the time of arrival of the message and the time the message sent is important to avoid replay attacks;
• Extract 𝑈’s password ℎ₀(𝑃𝑊_𝑖 ǁ 𝑐) = 𝐶𝐼𝐷 ⊕ ℎ₀(𝑁_𝑖 ⊕ 𝑦 ⊕ 𝑇);
• Compute 𝐵_𝑖 = ℎ₀(𝐶𝐼𝐷_𝑖 ⊕ ℎ₀(𝑃𝑊_𝑖 ǁ 𝑐));
• Compute 𝐶_𝑖 = (𝑇 ⊕ 𝑁_𝑖 ⊕ 𝐵_𝑖 ⊕ 𝑦);
• Check if 𝐶_𝑖∗ = 𝐶_𝑖. If so, then it proceeds to the next step, else, the user is rejected. This process is used to ensure the authenticity of the message received from 𝑈;
• Use the shared column reference #𝐶𝐹 to locate 𝑈’s record in the server database;
• Use 𝑇_𝐾 to decrypt {{𝑀𝐷_𝑢} ǁ 𝑆𝐼} in 𝐷_𝑖 to obtain 𝑆𝐼 and {𝑀𝐷_𝑢};
• 𝑇_𝐾 is also used as a seed for 𝐶𝑃𝑅𝑁𝐺 to generate 𝐾𝑎𝑢𝑡ℎ, which is used to decrypt {𝑀𝐷_𝑢};
• The decrypted 𝑀𝐷_𝑢 is compared with the user 𝑀𝐷_𝑢 stored in the server database. If they match, then the user is known to be a legitimate user, else the user authentication message is rejected;
• For mutual authentication, 𝑆 signs 𝑀𝐷_𝑢 using the cloud’s private key;
• 𝑆 uses 𝑈’s public key to encrypt {𝑇′, 𝑠𝑖𝑔𝑛 {𝑀𝐷_𝑢}, 𝑆} and sends to the user, where 𝑇′ is the current server time, and S is the server identity.

NB. and 𝑆 in {𝑇′, 𝑠𝑖𝑔𝑛 {𝑀𝐷_𝑢}, 𝑆} are used to prevent impersonation and replay attacks.

3.3.2. Mobile Mutual Authentication

The process involving the response to the mutual authentication message sent by the server. When the mobile receives the mutual authentication message from 𝑆, the smart card 𝑆𝐶 carries out the following tasks:

• Using the 𝑆𝐶’s private key, 𝑆𝐶 decrypts {𝑇′, 𝑠𝑖𝑔𝑛{𝑀𝐷_𝑢}, 𝑆};
• 𝑆𝐶 checks time ∆𝑇 = 𝑇″ − 𝑇′ where 𝑇″ is the time of message arrival. If the time window is acceptable, the message is accepted, else it is rejected;
• Using the cloud’s public key, 𝑆𝐶 decrypts the signed message 𝑠𝑖𝑔𝑛{𝑀𝐷_𝑢};
• The decrypted 𝑀𝐷_𝑢 is checked against the smart card’s stored 𝑀𝐷_𝑢. If they match, then mutual authentication had been accomplished; otherwise, the message will be rejected.

Figure 3 illustrates D-FAP verification phase.

3.3.3. Password Change Procedure

The following steps present the password change procedure:

• The user $U_i$ inserts the smart card into the smart card reader, and submits the current 𝐼𝐷_𝑖 and 𝑃𝑊_𝑖, and requests to change the password
• The user is prompted twice for a new 𝑃𝑊_𝑖∗;
• The Smart card computes $N_i^{*}=N_i\oplus h_0\left({PW}_i\parallel c\right)\oplus h_0\left(P{W}_i^{\prime }\parallel c\right)$;
• The Smart card computes $V_i^{*}=A_i\oplus h_0 \left(P{W}_i^{\prime }\parallel c\right)$;
• Then, once 𝑁_𝑖 will be replaced with 𝑁_𝑖∗ and 𝑉_𝑖 will be replaced with 𝑉_𝑖∗. The password has been changed with the new password $P{W}_i^{\prime }$ and terminates the operation.

3.3.4. Lost Smart Card Revocation Procedure

An important feature of smart card-based authentication is revoking the lost smart cards without changing the user’s identities. In a situation where the smart card is lost or stolen, the user must immediately request a cancellation of the card. The CSP validates the user’s credentials supplied at initial registration. At that time, the user is required to supply their user digital certificate to provide additional security for the CSP to be satisfied that it is a legitimate user and not an imposter. The CSP immediately revokes the lost smart card, and the user is requested to re-register with the CSP and with a new user’s $ID$. To protect the user from impersonation attacks, the user is not allowed to use any of their previous $10$ user $IDs$ or passwords for the new registration.

4. D-FAP Security Analysis

4.1. Formal Verification by ProVerif

The formal security analysis uses an automated analysis tool called ProVerif [59]. ProVerif is a known automatic verifier for cryptographic protocols that verifies the security properties of secrecy, authentication and observational equivalences, under the assumption that the cryptographic primitives are idealized. Digital signatures, hash functions, signature proofs, etc. are suitable for analyzing an authentication protocol. Recently, many researchers [60,61,62] have verified the authentication in the user authentication protocol using ProVerif. The formal security analysis shows the results of verifying and analyzing the security of D-FAP protocol using ProVerif.

In the ProVerif attacker model, it is assumed that an attacker 𝐴 has full control of the communication channels between the communicating parties. 𝐴 is able to monitor, capture, modify, compose, send, and resend any communication messages on the communication channels. This means that 𝐴 is able to fake any messages and impersonate any of the communicating entities. It can know the password of the user 𝑈, or the information stored on the smart card, but not both.

Table 2. Define values and functions.

(* Channel *)	free pubCH: channel. free prCH: channel [Private].
(*Constants *)	Const PWi: bitstring [Private].
(* Events *)	event initiate_ Client (bitstring). event term_ Client (bitstring). event initiate_ RemS (bitstring). event term _ RemS (bitstring).
(* Functions *)	fun owh (bitstring): bitstring fun concat (bitstring, bitstring): bitstring fun Exr (bitstring, bitstring): bitstring fun SyEnc (bitstring, bitstring): bitstring fun pubk (seckey): secpubkey fun aenc (bitstring, privkey) fun sigpk (SSkey): sigpkey fun sig (bitsting, bitstring)

elaborates channels, Constants, events, and functions used in D-FAP protocol. We use two channels of communication between the user 𝑈 and the server 𝑆. A secured channel 𝑝𝑟𝐶𝐻 that is used for registration, and a public channel 𝑝𝑢𝑏𝐶𝐻 which is an unsecured channel used for the login and authentication processes. The constant used in the communication process is the password. Two events are modelled for the Client $U$, an initialization event $initiate\_ Clinet$, and a termination event $term\_ Client$. Similarly, for the remote server $S$ are $initiate\_ RemS$ and $term \_ RemS$. The rest of the functions represent the various cryptographic or logical operations which are modelled in ProVerif as constructors and destructors.

4.1.1. Simulation Processes

This subsection shows the modeling of the processes carried out by the two parties, $pUser$, the User process and $pServer$, the server process.

1. Registration phase

(∗ User_ process registration ∗)

$Let pUser=new {ID}_i:bitstring;$

$New c:bitstring;$

$Out (prCH, \left({ID}_i,owh\left(concat \left(c.{PW}_i\right)\right)\right);$

$\begin{array}{l}in(prCH,({bV}_i\\ :bitstring,{bN}_i:bitstring,b{A}_i:bitstring,b{MD}_u:bitstring,by,b\#CF\left)\right);\end{array}$

In the registration phase, the $pUser$ process is used to communicate securely to the server using the secure channel ${ID}_i$ and $owh(concat\left(c,{PW}_i\right)$. The server checks the time $T_{reg}$ and computes $V_i A_i,N_i,N_i$, and ${MD}_u$ to $pUser$.

(∗ Server_ process registration ∗)

$Let pServer=new v:bitstring;$

$In \left(prCH.\left({VID}_i:bitstring,{vRPW}_i:bitstring\right)\right);$

$New Up:bitstring;$

$New Uc:bitstring;$

$Let {MD}_u=owh \left(concat\left(Up,Uc\right)\right);$

$New{x}_s:bitstring;$

$Let A_i=owh(Exr\left(vI{D}_i,x_s\right);$

$Let V_i=Exr\left(A_i,vRP{W}_i\right);$

$New Tr:bitstring;$

$Let N_i=Exr(vRP{W}_i,owh\left(concat\left(x_s,vI{D}_i,Tr\right)\right);$

$New y:bitstring;$

$New \# CF:bitstring;$

$Out \left(prCH,\left(V_i, A_i, N_i, {MD}_u, y, \#CF\right)\right);$

2. Login phase

(* 𝒑𝑼𝒔𝒆𝒓 𝑳𝒐𝒈𝒊𝒏 ∗)

$let {{RPW}_i}^{\prime }=owh\left(concat\left(c,{PW}_i\right)\right)$

$let {T_k}^{\prime }=\left({ID}_i,{{RPW}_i}^{\prime }\right)$

$let {A_i}^{\prime }=\left(b{V}_i,{{RPW}_i}^{\prime },{T_k}^{\prime }\right)$

$if y{A}_i={A^{\prime }}_i then$

$let T_k=Exr\left({ID}_i,{RPW}_i\right)$

$new Kauth:bitstring;$

$let {EMD}_u=\left({MD}_u,Kauth\right)$

$new SI:bitstring$

$let E=SyE\left(Exr\left({EMD}_u,SI\right),T_k\right)in$

$let B_i=owh\left(Exr\left({ID}_i,{RPW}_i\right)\right)in$

$new T:bitstring;$

$let C_i=Exr\left(T,b{N}_i,B_i,by\right)in$

$let CI{D}_i=Exr({RPW}_i,owh(Exr\left(b{N}_i,by,T\right)in$

$let D_i=Exr\left(b\#CF,E\right)in$

$out\left(pubCH,\left(CID,b{N}_i,C_i,D_i,T\right)\right);$

3. Authentication phase

(∗ pServer Authentication ∗)

$Event init\_Server\left(v{ID}_i\right);$

$in\left(pubCH\left(vC{ID}_i:bitstring, vb{N}_i:bitstring, v{C}_i:bitstring, v{D}_i:bitstring, vT:bitstring\right)\right);$

$new vT:bitstring;$

$let {{RPW}_i}^{\prime }=Exr\left(vC{ID}_i,owh\left(N_i, y, vT\right)\right)$

$let {B_i}^{\prime }=owh\left(Exr\left(vC{ID}_i, {{RPW}_i}^{\prime }\right)\right)$

$let {C_i}^{\prime }=Exr\left(vT,N_i,{B_i}^{\prime },y\right)$

$if {C_i}^{\prime }=C_i then$

$let E=Exr\left(v{D}_i,\#CF\right)in$

$let E^{\prime }=SyD\left(E,T_k\right)in$

$new r:bitstring;$

$let r=\left(\left({MD}_u\right),SI\right)$

$let SyE\left({MD}_u\right)=Exr\left(r,SI\right)$

$new Kauth:bitstring;$

$let {{MD}_u}^{\prime }=SyD\left({MD}_u,Kauth\right)$

$if {{MD}_u}^{\prime }={MD}_u then$

$new T^{\prime }:bitstring;$

$new sskey:bitstring$

$let a=\left({MD}_u,sskey\right)$

$new upkey:bitstring;$

$new S:bitstring;$

$let c=aenc\left(\left(T^{\prime }, sign\left({MD}_u\right), S\right),upkey\right)$

$out\left(c\right);$

$event term\_Server\left(x{ID}_i\right);$

(∗ pUser Mutual Authentication ∗)

$in\left(pubCH\left(vc\right)\right)$

$New uskey:bitstring;$

$let d=adec\left(vc,uskey\right)$

$new spkey:bitstring;$

$let {{MD}_u}^{\prime }=checksign\left(Sign\left({MD}_u,Spkey\right)\right)$

If ${{MD}_u}^{\prime }={MD}_u$ then

Let $P_i=owh\left(contact\left(C{ID}_i,y\right)\right)$

Let S_k = $owh\left(contact\left(D, p_i,y\right)\right)$

Event term_User(ID_i);

4.1.2. Simulation Results

To guarantee that an attacker $A$ is unable to obtain the user credentials, the following queries are run to test the security of the authentication process.

$$query id:bitstring:inj-event \left({term}_{Client}\left(id\right)\right)==> inj - event \left(intiat{e}_{Client}\left(id\right)\right),$$

$$query id:bitstring:inj- event \left(term\_RemS\right)) ==> inj - event \left(intiate\_ RemS \left(id\right)\right).$$

Upon successful authentication, the session secret key $S_k$ is used for future communication between the user and the server. To ensure that an attacker $A$ is unable to discover the session key, the session key is given a private value. To further test the secrecy of $S_k$, the following queries are used:

$free S_k:bitstring \left[private\right]$

$query attacker \left(S_k\right).$

If the security queries result in a ‘false’, then an attack is possible and the attacker is able to discover the session key $S_k$. While in case the query result in a ‘True’, then the query was proven and the attack was not successful. The simulation results of D-FAP protocol are shown to be accurate for all events (see

Table 3. ProVerif results.

Parameter	ProVerif Output
$S_k$	Secure
$event\left(term\_RemS\left(id\right)\right) => event\left(intiate\_RemS \left(id\right)\right)$	True
$event\left(term\_Client\left(id-1212\right)\right) => event\left(intiate\_Client \left(1212\right)\right)$	True
$not attacker\left(S_k\right)$	True

).

ProVerif has been used to test D-FAP for validating secrecy of the session key and the authentication between the user and the remote server. ProVerif queries are used to search for any valid security breaches that can be exploited by an attacker. The secrecy property of the D-FAP is tested to ensure that an attacker is unable to reach encrypted authentication messages that have been exchanged between the communicating parties using the insecure channel.

The adversary model used by the ProVerif tool to impersonate an adversary $A$, who engages with all the participants of the protocol that share the same insecure channel, is also implemented.

The results of the simulation show that both the user and server events start and terminate successfully and the security queries are applied successfully to the session key.

As shown in Table 3, in the results from the simulation of D-FAP, the secrecy of the session key $S_k$ is maintained, and the attacker $A$ is unable to obtain it. It also verifies the secrecy of the exchanged authentication messages, and shows that an attacker is unable to access these messages.

The results show that an attacker $A$, with a sequence of actions, cannot execute $event\left(initiate\_Server \left(id\right)\right)$ before $event\left(term\_Server \left(id\right)\right)$ and, therefore, cannot breach the security of the server. Furthermore, the same attacker $A$ is not able to breach the user authentication by executing $event\left(intiate\_User \left(1212\right)\right)$ before $event\left(term\_User\left(id-1212\right)\right)$.

The results also show that the session key is secure and is not revealed to the attacker. Therefore, the claim that D-FAP maintains full secrecy has been proven by simulation.

4.2. Informal Security Analysis

In this section, we provide an informal security analysis of the proposed protocol to test its agility to withstand various possible attacks found in the current literature.

1. Denial of Service attack (DoS)

DoS is an intentional cyberattack carried out by an attacker who has already gained access to the smart card. This attack usually leads to excessive consumption of computational resources, damage of configuration information, or interruption of connection [63].

In some approaches, if the client requests to change their password, the smart card will not verify that the old name they input is similar to the original name. Hence, the attacker can invoke the password change procedure by inputting ${PW}_i^{new}$, replacing the original password ${PW}_i$. Therefore, the service will be denied for the legitimate client.

In D-FAP, the client credentials are authenticated by the smart card, which compares the user ID and password to the prestored credentials. The user is then requested to reenter the old password and only then will the request for a new password be prompted.

2. Masquerade attack

This attack is a type of spoofing attack that utilizes the vulnerabilities of security protocols to masquerade as one of the two parties to the communication [63]. Hence, an attacker uses a forged identity to gain unauthorized access. This can lead to modification or fabrication attack. In D-FAP, the login message is generated only if $C_i=\left(T\oplus N_i\oplus B_i\oplus y\right)$. The attacker could record $\left\{CID, N_i, D_i, T\right\}$ by eavesdropping on the communication between the user and the server, and could then extract ${CID}_i$ from the message. However, the $CID$ is dynamic in nature, which is different in each session and encrypted using the server public key, and can only decrypted by the server’s secret key. Also, $N_i$ and $D_i$ can only be computed by the user. The attacker can try to impersonate the server by recording $\left\{T^{\prime },sign\left\{{MD}_u\right\}, S\right\}$, and trying to replay the message to the user. However, this is not possible since the identity $S$ will be different.

3. Parallel session attack

The attacker applies new runs of authentication process using knowledge gathered from the initial run. Messages from these new runs of the protocol are replayed in the initial run. This allows an attacker to masquerade a legitimate user in another session [64].

Consider an attacker records $\left\{T^{\prime },sig\left\{{MD}_u\right\},S\right\}$, and then waits for the next authentication session, until the server sends it mutual authentication message back to the user. The attacker intercepts this message and replaces with his own message to the user, trying to impersonate the server.

For this to work, the attacker needs access to the private key of the user and the time stamp algorithm. The attacker can then decrypt the message and add in his time stamp $T*$. However, he cannot input his identity in place of the server ID $S$. Even if the attacker inputs his identity, the message will be $\left\{T*,sign\left\{{MD}_u\right\}.A\right\},$ which will be rejected, as the identity of the sender is different than the identity of the server.

4. Playback attack

The playback cure network communication intercepts it, and then fraudulently delays or resends it to either parties to masquerade as the server or the client. This can lead to injecting false messages, data corruption, or faking authentication credentials [65].

This is not possible with the proposed protocol due to the strong digital signatures that include time stamps. The server and the client check the time spent by the conveyed message between the two parties, taking into consideration the network delays. When this time exceeds the acceptable time limit, the message would be rejected.

5. Smart card loss attack

This attack can lead to changing the smart card password, or guessing the password of the user using password guessing attacks, or masquerading the legitimate user to login to the system [47]. When a smart card is lost or stolen, an attacker may access these parameters $\left\{V_i,A_i,N_i,{MD}_u,h\left(.\right),y\right\}$. In a protocol that is vulnerable to this type of attack, the attacker can use the details obtained from the card to perform various attacks such as password guessing attack, or impersonation attack, to login to the cloud. However, the login message would be $\left\{{CID}_i,N_i,C_i,D_i,T\right\}$. For the attacker to find the value of the hashed password from $h_0\left({PW}_i \Vert c\right)=CID\oplus h_0\left(N_i\oplus y\oplus T\right)$, the attacker needs access to $y,c$ and $h(.)$, to guess ${PW}_i$, hash it, and then calculate $CID\oplus h_0\left(N_i\oplus y\oplus T\right)$. This cannot be performed in polynomial time. Furthermore, the smart card consists of the following parameters $\left\{V_i,A_i,N_i,{MD}_u,h\left(.\right),y\right\}$. If it is lost or stolen, the only parameter that can reveal ${PW}_i$ is $V_i$, which is $V_i=A_i\oplus {RPW}_i$. However, the attacker needs knowledge of $T_k$. This is not achievable in polynomial time. Therefore, an attacker cannot impersonate the owner of the card to login to the cloud. As a result, the proposed protocol is resistant to smart card loss attack.

6. Stolen verifier attack

In this attack, an attacker steals the password-verifier from the server’s database and applies an offline guessing attack on it to get the client’s exact password and, hence, he can masquerade as a legitimate client or the server, or can obtain the secret information [66]. D-FAP does not use password verifier tables, hence, it is immune to this type of attack.

7. Reflection attack

This attack is performed on mutual authentication protocol in which the attacker tricks the server into revealing the secret to its own challenge. The attacker creates a parallel session to initiate a valid session with the server. The attacker masquerades the legitimate user to request a login session from the server. The server attempts to authenticate the attacker by sending it a challenge, sending back a challenge, and waiting for a response. The attacker initiates another session with the server and sends the challenge. The server responds to the challenge; the attacker uses the response in the original session which will be validated by the server. Therefore, the attacker obtains access to the system resources with the privileges of a legitimate user [67].

This attack specifically targets protocols that use the challenge and response authentication system, in which an attacker uses the same protocol in both directions. D-FAP is immune to this type of attacks, since it does not use a challenge and response authentication system.

8. Insider attack

Insider attack is launched by someone with authorized system access who is purposely compromising the security. This can lead to violating the confidentiality, integrity, or availability of the system [68]. In a real-world environment, it is a common practice that many users use the same passwords to access different applications or servers for their convenience of remembering long passwords and use them easily. However, if the system manager or a privileged insider of $S$ has known the passwords of $U_i$, he may try to impersonate $U_i$ by accessing other servers where $U_i$ could be a registered user. In D-FAP, the user ID and password are secured at every stage of the process, i.e., the password is never revealed in any of the processing during the authentication process.

D-FAP does not employ a password verifier table. It uses Dynamic 𝐼𝐷 that is dynamically changed each time the user logs in. Therefore, it can resist the insider attack and stolen verifier attack.

9. Password guessing attack

The adversary could perform brute force attack to compromise the low entropy password with the eavesdrops on the communication between the user and the server record [69]. The login message would be $\left\{{CID}_i,N_i,C_i,D_i,T\right\}$. For the attacker to find the value of the hashed salted password from $h_0\left({PW}_i \Vert c\right)=CID\oplus h_0\left(N_i\oplus y\oplus T\right)$, the attacker needs access to $y$, $c,$ and $h(.)$, to guess a ${PW}_i$, salt it with $c$, hash it, and then calculate $CID\oplus h_0\left(N_i\oplus y\oplus T\right)$. This cannot be done in polynomial time and has a low probability of achievement.

The smart card consists of the following parameters $\left\{V_i,A_i,N_i,{MD}_u,h(.),y\right\}$. If it is lost or stolen, the only parameter that can reveal ${PW}_i$ is $V_i$, which is $V_i=A_i\oplus {RPW}_i$. However, the attacker needs knowledge of $T_k$. This is not achievable in polynomial time, Thus, password guessing attack is fruitless for D-FAP.

4.3. D-FAP Security Comparisons

The performance of D-FAP has been compared against two of its best rivals in the literature [57] and [58]. These protocols are similar to the D-FAP in spirit, but different in approach. Both protocols contribute to authentication in the MCC environment using smart cards and password methods.

When comparing D-FAP with the protocols proposed in refs. [57,58], using the security properties from the previous section, it has been shown that D-FAP is secure against all the specified attacks. However, an analysis of both protocols shows that they suffer from many security weaknesses. For instance, they suffer from smart card loss attack, and masquerade attacks. These vulnerabilities are due to the lack of defense mechanisms to counteract against smart card loss. D-FAP has presented a fully detailed procedure to protect against these attacks in the event of smart card loss.

A provision for generating a session key for future communication between the communicating parties is defined in D-FAP, while ref. [57] does not do this. It is important that both communicating parties maintain security after successful authentication, to be able to exchange messages in complete secrecy, and to maintain confidentiality and privacy. D-FAP is shown to maintain secrecy for all the secret keys including the session key. However, in ref. [57], if an attacker has stolen the server’s secret key 𝑥𝑠, the attacker can easily compute the user’s hashed password h(𝑃𝑊_𝑖) ⊕ ℎ(𝑥_𝑖) and impersonate that legitimate user.

Moreover, except for our scheme, other listed schemes [57,58] are proved to be susceptible to an insider attack. D-FAP does not employ a password verifier table. It uses a Dynamic 𝐼𝐷, which is dynamically changed each time the user performs login. It is therefore extremely difficult for an insider, such as an administrator, to learn the legitimate user 𝐼𝐷 and password in order to masquerade as the user and gain access to other servers that the user has access to within the cloud.

Finally, R-TFAP is shown to be efficient for parallel session attacks because of the different message structures between the user and the server. Refs. [57,58] are vulnerable to these types of attacks; this is due to the ability to compute the session key by an unauthorized person using some eavesdropped communication.

In designing D-FAP, measures to overcome the weaknesses identified when analyzing the strengths and weaknesses of other similar protocols in the literature review have been implemented. This has added to the security, efficiency, strength, and attractiveness of the protocol.

Table 4. Comparisons of security properties with related works.

Attack	Tsai et al. [57]	Chaudhary et al. [58]	D-FAP
Resist offline password Guessing attack	yes	yes	yes
Prevent playback attack	yes	yes	yes
Minimize denial of service attack	yes	yes	yes
Prevent insider attack	no	no	yes
Prevent of masquerade attack	no	yes	yes
Prevent stolen verifier attacks	yes	yes	yes
Prevent reflection attack	yes	yes	yes
Prevent parallel session attack	no	yes	yes
Prevent smart card loss attack	no	no	yes

presents the comparisons between D-FAP and other related authentication protocols.

5. Conclusions

The insecure nature and heterogeneity of wireless communications have complicated the security and privacy needs in MCC. Energy limitations in mobile devices increase the demand for a lightweight security mechanism. An essential part of such a security mechanism is authentication, which secures any system against unauthorized access. Authentication should be lightweight, in order to minimize computation and communication costs.

This paper introduces a new authentication protocol, Dual-Factor Authentication Protocol for mobile cloud connected devices (D-FAP), that addresses the mobile devices resource limitations to conserve their energy and address the security issues of the MCC. D-FAP produces a secure and lightweight dual-factor authentication that is based on smart card and password authentication methods. It is shown that D-FAP satisfies the security requirements for user authentication and session key agreement and resists various kinds of known attacks.

6. Future Work and Suggested Applications

D-FAP has the potential to be developed further to meet demands. Recommendations for future development include: D-FAP could be developed further to be used to access enterprise systems in an MCC environment. For instance, supporting PKard Readers which can be connected to mobile devices. Furthermore, since the majority of today’s smartphones are equipped with a fingerprint identity sensor, the password authentication method can be replaced with a biometric method. Although this would improve the security even further, it would increase the energy consumption and hence reduce the efficiency. Moreover, D-FAP could be optimized for IoT systems.

It is envisaged that D-FAP could be applied across a variety of different industries. This could include: Businesses that support Bring Your Own Device (BYOD) policy, as it enhances security of access and mobility; or the banking industry, as it increases security and, because it reduces the number of factors used in the authentication process, it reduces the access time, thereby increasing its likeability; or the health care industry, which deals with highly sensitive data requiring high levels of privacy and confidentiality; or high security industries such as in government and defense.