A New Hybrid Online and Ofﬂine Multi-Factor Cross-Domain Authentication Method for IoT Applications in the Automotive Industry

: Connected vehicles have emerged as the latest revolution in the automotive industry, utilizing the advent of the Internet of Things (IoT). However, most IoT-connected cars mechanisms currently depend on available network services and need continuous network connections to allow users to connect to their vehicles. Nevertheless, the connectivity availability shortcoming in remote or rural areas with no network coverage makes vehicle sharing or any IoT-connected device problematic and undesirable. Furthermore, IoT-connected cars are vulnerable to various passive and active attacks (e.g., replay attacks, MiTM attacks, impersonation attacks, and ofﬂine guessing attacks). Adversaries could all use these attacks to disrupt networks posing a threat to the entire automotive industry. Therefore, to overcome this issue, we propose a hybrid online and ofﬂine multi-factor authentication cross-domain authentication method for a connected car-sharing environment based on the user’s smartphone. The proposed scheme lets users book a vehicle using the online booking phase based on the secured and trusted Kerberos workﬂow. Furthermore, an ofﬂine authentication phase uses the OTP algorithm to authenticate registered users even if the connectivity services are unavailable. The proposed scheme uses the AES-ECC algorithm to provide secure communication and efﬁcient key management. The formal SOV logic veriﬁcation was used to demonstrate the security of the proposed scheme. Furthermore, the AVISPA tool has been used to check that the proposed scheme is secured against passive and active attacks. Compared to the previous works, the scheme requires less computation due to the lightweight cryptographic algorithms utilized. Finally, the results showed that the proposed system provides seamless, secure, and efﬁcient authentication operation for the automotive industry, speciﬁcally car-sharing systems, making the proposed system suitable for applications in limited and intermittent network connections.


Introduction
The Internet of Things (IoT) paradigm has profoundly affected the automotive industry and its long-term prospects [1,2]. Traditional vehicle-to-everything (V2X) technologies are evolving into the Internet of Vehicles (IoV) to support emerging advanced vehicular applications, including intelligent transportation systems (ITS) and autonomous vehicles [3,4]. The global market for autonomous driving is expected to reach $173.15 billion by 2030, as reported by [5]. Numerous automobile businesses, such as ArgoAI, Audi, Baidu, Cruise, Mercedes-Benz, Tesla, Uber, and Waymo, have made significant investments in this domain. Customers, suppliers, and service providers will benefit from unprecedented data collecting, easy connectivity, locationbased utilities, personalized insurance benefits, intelligent diagnostics, and assisted driving as the Internet of Things (IoT) is introduced to cars [6,7]. Although these opportunities are essential somehow, they are only as good as their weakest link [8]. According to Statista, more than 26 billion IoT-connected devices are in use today, with that number expected to rise to more than 75 billion by 2025. As the connected car's knowledge, facilities, and environment evolve, so do the risks and exposures that come with it [9,10]. According to Intel predictions, autonomous vehicles may generate and consume 5 TB of data each hour of driving, with automotive cameras and radars alone generating data at rates of 20-40 Mbps and 100 kbps, respectively, [4]. Additionally, data are derived from crowdsourced traffic networks such as Google Waze. Processing such large amounts of data generated by hundreds of thousands of vehicles requires enormous computational capabilities and effective machine learning techniques to extract crucial information that must be produced for each driver [5]. As electrical vehicles (EV) are being pushed instead of internal combustion engine (ICE) technology, it is only natural that the connectivity technology is becoming more sophisticated. Furthermore, vehicles have become increasingly autonomous to provide more safety and convenience to the users. However, the increases in sophistication and autonomy need to be balanced with comprehensive security, regardless of the condition and location of the car. Central to this connected vehicle initiative is the owner's smartphone. It is used to control, monitor, and secure the vehicles and other necessary interactions with their environment, for example, automatic parking, toll services, gas and charging stations, automakers' service networks, and other driving facilities, as shown in Figure 1. Furthermore, automakers emphasize their connected features, which range from on-board Wi-Fi to mobile applications that monitor locks and even start vehicles. The novelty of these "smart" features frequently outweighs the negative consequences in these situations. Thus, what happens if a customer's phone is lost or stolen? Is there adequate protection and authentication in place to prevent their car from being stolen as well? What happens if the customer's Internet connection is lost? Both are things to consider. Over the last few decades, vehicle networks have progressed from essential communications inside a vehicle using the CAN Bus technology (control area network) [11]. However, the issue with CAN Bus is that it was not built with safe communications in mind, and attempts to introduce secure certificate-based authentication to CAN Bus devices have largely failed. A cyberattack is a pernicious endeavor to breach the data or systems of an individual or a specific organization [12]. Several cyberattacks are possible now, such as signature to create an efficient online-offline signature scheme in 2001. According to the original scheme, the major scale and signature sizes were reduced in the proposed scheme. To improve device security, they added a new hash function called the trapdoor hash function to their model. The receiver obtains a hash collision and extracts trapdoor information from the signer, which is the signer's secret key [31]. The signer uses the same hash value to get two signatures on two different messages. The suggested scheme, on the other hand, employs many chameleon hashes values for different messages. This problem is the primary chameleon hashing disclosure issue. D. Liu et al. [32] devised an effective identity-based online/online signature scheme that avoids the main escrow issue by implementing the CLC concept. PKG generates only a partial private key, while the user generates the other partial private key, making the complete private key. As a result, the PKG is unaware of the user's private key in its entirety. The system, however, suffers from a high computational burden due to issues with identity-based signature computation. Dmitrienko et al. [33] proposed a free-float, offline-enabled car-sharing control scheme. This protocol is built on symmetric encryption, protected elements for storing private credentials, and a single car-sharing provider for access rights management. Dmitrienko et al. [34] suggested a generic access control scheme based on NFC-enabled devices that includes offline validation and authorization delegation. However, several proprietary protocols are used in this work. SePCAR is a smart car access control protocol. On the other hand, this protocol is more concerned with user privacy than with bandwidth efficiency [35].
S. Hass et al. [36] presented an offline authentication system for direct access to Industrial mobile robots (IMRs) in production facilities using one-time passwords (OTP), protected components, and smart cards. The authentication method offers two separate authentication modes to provide more flexibility. Authentication modes are used to ensure that passwords are generated from the identity of a particular IMR or group of IMRs that is accessed rather than a person's credentials. As a result, the system is susceptible to a replay attack, also known as a man-in-the-middle attack. Jia-Li Hou et al. [28] proposed a sensor-based offline-online authentication architecture for IoT healthcare systems. A robust co-existence proof protocol and a stable single sign-on authentication scheme were defined. The proposed approach combined the SSO technique with a one-way hash function and a random nonce to provide protection and performance. Following that, Li and Xiong [37] devised a safe scheme for achieving confidentiality, honesty, authentication, and nonrepudiation in a single logical stage. The proposed method divides encryption into two stages, one online and one offline, allowing a sensor node in an identity-based cryptosystem to communicate with an Internet host. Consequently, this scheme effectively incorporates WSN into IoT [38]. Saeed et al. introduced a CLC to PKI online-offline HS scheme for IoT in 2017 [39]. Besides, the authors put the scheme into practice in the fields of healthcare and smart grids. Via the signature of a certificate authority, the PKI connects each public key to its corresponding user identity (CA). PKI systems are not ideal for use in industrial IoT because managing certificates is a difficult job. Vonoth et al. 2020 [40] suggested a stable multi-factor authenticated key agreement scheme for IIoT to enable approved users to remotely access to sensing devices. They devised an authenticated key agreement scheme for simultaneously accessing multiple sensing devices and establishing a mutual session key between them. Unfortunately, due to secret-sharing technology, the proposed scheme has a high computing cost [41].
The use of blockchain-based offline authentication for a smart lock was proposed by Han et al. [42]. Centered on blockchain technology, this paper proposed a non-interactive end-to-end offline authentication scheme (BC-SNOA). Instead of using the pad in realtime, the BC-SNOA scheme uses it once. The subscriber only needs to pick the relevant information (reservation person's mobile phone number, conference name, meeting length, etc.) in this decision, and the Internet booking service system will calculate an encrypted token string and create a QR code from it. It employs the proof-of-work consensus algorithm, which entrusts the hard work to the miners. The miners are rewarded for solving difficult mathematical problems. Furthermore, the decentralized construction systems suffers from single point failure. The high energy consumption renders these complex mathematical problems unsuitable for real-world applications [43,44]. Nevertheless, the advantages and disadvantages of the existing authentication schemes that work in online and offline modes are shown in Table 1. Resolve the key escrow problem.
High computation due to Bilinear pairing.

Identity-based encryption
Allows the car to expand its services to areas without reliable network coverage. As mentioned above, specific online-offline authentication schemes were proposed to obtain a valuable service to the customers. Despite this, most of these schemes have not been proven reliable. The few proven to be secure (under conventional cryptographic assumptions) are too slow for many practical applications. Furthermore, the vehicle could book or deal with IoT devices located in a different location out of their current zone. Although there have been many papers on identifying and mitigating each type of threat, the lack of design support still challenges security engineering for development. These schemes are based on open network architecture and necessitate ongoing online services. Electromagnetic attacks, vulnerability scanning infiltration, network eavesdropping, and service system and database attacks can be used by hackers to break into rooms, steal money, steal data, and disrupt services, posing a danger to the entire industry. The proposed solutions fail to provide essential security features, such as vehicle anonymity and cross-domain authentication. They are also prone to various known attacks, including man-in-the-middle, replay, unlinkability, and vehicle impersonation and modification attacks. Moreover, these schemes incur heavy computation and communication costs, making them impractical to adapt to real-time scenarios. We propose a hybrid onlineoffline multi-factor cross-domain authentication scheme for the industrial IoT environment to address these issues. The proposed scheme involves online and offline phases, and the first phase is to enable the user to book the vehicle that belongs to another domain. Otherwise, the advantages of AES are faster execution in both the hardware and software; it meets the latest that is required by the United States' and international standards; it is also more secure to use; lastly, it supports larger key sizes than other algorithms [46]. The disadvantages of AES are that it is challenging to know the details of the process because the encryption is patented, and it will be difficult to decrypt the data (Cipher text) if the secret (private) keys are lost [47]. Therefore, our study added the ECC algorithms for efficient key management. The TOTP generator is bound to the user's device (for example, mobile device, or hardware token). Suppose this device is stolen, lost, or breaks. In that case, the association between the service provider and the TOTP generator is lost, and the service provider needs to re-issue a TOTP authenticator for the user. Thus, the study provides multi-factor authentication using user biometric to unlock the car via a biometric reader deployed in the car. The offline application is applied when the network connectivity is unavailable based on the OTP generated before the online booking phase.

Functionality and Security Goals
Based on the literature, an unquestionable requirement in terms of security and functionality has still not been met in previous studies or any IoT-connected devices. Therefore, to ensure the security and functionality of the proposed scheme, the following requirements are considered to provide an efficient and secure authentication scheme: -Replay attacks: In IoT-connected vehicles, replay attacks should be prevented by using timestamps and random numbers in the transmitted messages [48].
-Man-in-middle attack: An adversary intercepts the messages sent between the vehicle and server and replaces them with messages. -Offline password guessing attack: In this attack, an attacker can employ some of the intercepted information, such as keys, or the self-generated parameters, to guess the user's password [49]. These attacks can never be "prevented," but protocols can be made secure against such attacks. -Server spoofing attack: This attack can be solved entirely by providing mutual authentication between vehicle and server. -Privileged insider attack: When the server needs to retain the user's password for later authentication, the keys are probably being stolen by the adversary because the server can find out the patient's new password. -Denial of service (DoS) attack: Services are denied to the attackers by the automative users/vehicles and the servers [50]. -Impersonation attack: A dishonest user can easily impersonate another legal user.

Cryptography Materials
This section gives a brief overview of elliptic curve cryptography [49]. The ECC's security is based on solving the elliptic curve discrete logarithm problem (ECDLP). It can achieve the same degree of protection with a smaller key size [51]-the use of ECC with a more minor key size results in significant cost savings. Furthermore, ECC's smaller key sizes make it easier to design faster cryptographic operations that can run on small chips with limited memory. This is suitable for systems with limited resources, since it reduces power consumption and heat output. Furthermore, the combination of the AES-ECC method is briefly discussed and gives the steps of the method workflow. The AES is used to encrypt the message before it is transmitted using the receiver public key. It was chosen as an asymmetric key algorithm because of its highly secure symmetric algorithm, and it is easy to implement without affecting the complexity. As a result, AES-ECC is well suited for smart devices operating in resource-constrained situations [52].

Elliptic Curve Cryptography (ECC)
Let E/F p be a set of elliptic curve points over a prime field F p , defined by the following non-singular elliptic curve: where x, y, a, b ∈ F p and (4a 3 + 27b 2 ) mod p = 0. A point P(x, y) is an elliptic curve point if it satisfies (1), and the point Q(x, −y) is called the negative of P, i.e., Q = −P. Let P(x 1 , y 1 ) and Q(x 2 , y 2 )(P = Q) be two points on (1); line l (tangent to the curve (1) if P = Q) joining the points P and Q intersects the curve (1) at R(x 3 , −y 3 ) and the reflection of it concerning x-axis is the point R(x 3 , y 3 ), i.e., P + Q = R. The points E/F p together with a point O, called "point at infinity" or "zero points," make an additive elliptic curve cyclic group G p ; i.e., G p = (x, y) : The scalar point multiplication on G p is defined as: k · P = P + P + · · · + P(k times). A generator point P ∈ G p has order n if n is the smallest positive integer and n.P = O.

AES-ECC Algorithm
This section discusses the AES-ECC workflow. The AES key is secured in this algorithm by encrypting it with the ECC key without increasing the complexity or crossencrypting the AES and ECC keys [53]. The workflow diagram of the AES-ECC algorithm is shown in Figure 2, and the steps are illustrated as follows:

1.
Input data, i.e., username, password, and a biometric of the user using a smartphone.

2.
The data are hashed using the SHA-2 function to generate a hash value for data summary.

3.
It generates a digital signature using a private sender key K s and an ECC digital signature.

4.
Using the private key of the AES, the sender encrypts the digital signature and the data that need to be sent result in data ciphertext and signature ciphertext.

5.
The sender then encrypts the AES private key using the ECC encryption module to generate the key ciphertext. Then, it sends the ciphertext via the Internet. 6.
Upon receiving, the receiver uses his private key to decrypt the AES key; then, it decrypts the data ciphertext and signature ciphertext using the AES key. 7.
Based on the sender's public key, the receiver verifies the signature to summarize the received data and the hash value using the SHA-2 function. If the value is the same, then the data are valid; otherwise, the session is ended.

Proposed Scheme
This section proposes a new and secure multi-factor cross-domain authentication method for Industrial IoT-connected vehicles to provide an efficient and secure vehicle booking and offline authentication. The proposed scheme utilized a smartphone, username, password, and biometric (fingerprint). The combination of AES-ECC is used on the sender and receiver sides. This combination provides secure communication and efficient key management. Furthermore, it gives secure mutual authentication between the vehicle and the cross-server. The proposed scheme comprises five phases, i.e., setup, vehicle registration, server registration, booking, and offline authentication. Figure 3 shows a the general overview of the system's architecture. The notation and descriptions are illustrated in Table 2. Furthermore, the network diagram of the proposed scheme is shown in Figure 4.

Setup Phase
In this phase, the trusted authority selects a large prime numbers p and q, and a finite field of elliptic curve E/Fp. Then, the elliptic curve generates a group G with the generator P. The TA then generates the system master key selected randomly, SMK ∈ Z * q , and the system public key based on the master key and the prime number SPK = SMK.p. The encryption and decryption pair E./D. related to the AES-ECC algorithm are chosen by the TA. Then, it selects a one-way hash function h() : 0, 1 * ßZ * q. Later, it computes the corresponding AES public key PK a es The AES's public key is used to encrypt the transmitted message amongst participating entities. The elliptic curve is used to generate the keys since it has a decent efficiency in key generation. Finally, the TA publishes the public parameters of the system p, G, SPK, PK a es, E./D., h(.) and key the SMK secretly. Cross-server identity One-Way hash function

User Registration Phase
To enable the user to be authenticated by the cross-server, the user first needs to register itself into the authentication server AS in the TA. This phase is implied in online mode, where network connectivity is mandatory to complete the user's registration. First, however, the vehicle starts the registration by inserting the smart card into the card reader in the car and selecting the identity, password, and biometric. When the AS receives the message, it checks whether the user exists in the database; if yes, it sends a notification about other information. Otherwise, the AS will start performing the user registration by applying the following steps, as shown in Figure 5: The user inputs the identity ID u , passwords Pw u , and imprint biometrics Bi u . The mobile device picks a pseudonym identity ID V ∈ Z * q . Then, it generates a random number k u ∈ Z * q as a private vehicle key and calculates the vehicle public key Pk u = k u .p. Later, it generates a random number r 1 and computes  Generates ∈ * , Calculate: = . ,

Server Registration Phase
In this phase, the cross-server CS i register itself into the authentication server in online mode. For server registration, the following steps are shown in Figure 6 and described as follows: 1.
The CS i picks an identity ID CS and select a random number r 2 ∈ Z * q to compute A i = h(ID CS r 2 ). Then encrypt the message with AES's public key M 1 : E PK aes {A i } and sends M 1 to the AS.

2.
The AS receives M 1 and decrypts D PK aes {A i } using the public key to obtain the value A i , It checks whether the identity exists in the database or not; if so, the AS ask to reapply the registration. Otherwise, it generates a random number r 3 ∈ Z * q and computes a session key shared between the server and the AS KS CS→AS = h(ID CS r 3 ). Furthermore, the AS will prepare a list that contains all the registered cards in the reader CR list :

Online Vehicle Booking
In this phase, the user books the vehicle in online mode. The user enters the identity, password, and biometric using their mobile device. To book the vehicle, the user applies the following steps, as described in Figure 7: 1.
The user inputs his identity ID u , passwords Pw u , and imprint biometrics Bi u . The MD picks a pseudonym identity ID M D ∈ Z * q . Then, it generates a random number k M D ∈ Z * q as MD private key and calculates the MD public key Pk MD = k MD .p. Later, MD generates a random number r 1 and computes C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 ). The C i message is encrypted with an AES public key M 1 : E PK aes {C i Bi u } alongside the user's biometric and sends M 1 to the vehicle.

2.
Upon receiving M 1 , the vehicle decrypts the message D PK aes {C i Bi u } using an AES public key to obtain the user's information. The vehicle then verifies the user's identity and password with the ones stored in its database. If they exist, notify the user's Ui. Later, the vehicle computes 32 bits TOTP : When the AS receives M 2 it decrypts the message D PK aes {C i OTP Bi u } to obtain the values {C i OTP Bi u } and verify the identity of the user and vehicle, and checks the freshness of the timestamp T 1 = T. If invalid, the session is ended. Furthermore, it verifies the received TOTP by matching with generated TOTP batch by the AS; if there is not a match, the session is ended; otherwise, it causes a random number r 3 and computes a shared key session to enable the vehicle to communicate with the ticket granting service (TGS) KS V→TGS = h(ID v ⊕ r 3 ). Then, the AS in trusted authority generates a secret key randomly for the TGS SK TGS ∈ Z * q . It later computes the message M 2 : E PK aes {ID u ID V T 2 KS V→TGS TGS TKT }, where the TGS TKT = E SK TGS ID u ID V T 2 S i that can be decrypted by the TGS only. Finally, AS sends M 3 to the vehicle.

4.
The vehicle gets the M 2 and decrypts it using the AES public key to obtain {ID u ID V T 2 KS V→TGS TGS TKT }. Then, it forwards the message M 4 : E KS V→TGS {ID u ID V T 2 TGS TKT } to the TGS in the trusted authority. 5.
The TGS receives the message M 4 and decrypts it to obtain {ID u ID V T 2 TGS TKT }, and then decrypts the ticket The TGS verifies the secret value S i = S i ; if invalid, it ends the session; otherwise, it checks the freshness of the timestamp T 2 = T. If not new, it ends the session. Otherwise, it generates a random number r 4 and computes the key session shared between the vehicle and the cross-server KS V→CS = h(ID TGS ⊕ r 4 ). Then, composes the message M 4 : Finally, the TGS sends the M 5 to the vehicle. 6.
Upon receiving the M 5 , the vehicle decrypts the message to obtain the session key and the CS TKT . Then, it decrypts the ticket The cross-server receives the M 6 and decrypts CS TKT = E PK aes {ID u ID V E KS V→CS {ID CS T 3 S i } to obtain the values. Then, it checks the freshness of the timestamp T 5 = T.
If not fresh, it ends the session; otherwise, the vehicle booking is successfully made.

Cross-server User AS TGS Vehicle
Input , , and .

Offline Authentication
This phase enables the user to authenticate into the offline mode using TOTP [54] when the network connectivity is not available. In Figure 8, the network diagram of the offline authentication is shown. To authenticate the user with the vehicle, the user needs to apply the following steps, as illustrated in Figure 9.

User with MD Vehicle
Inputs ID u , Pw u , and Bi u MD verifies ID u , and Bi u Generates nonce = T 1 ∥ CN, Encrypts HA = E k MD (nonce).

1.
The user inputs their information identity ID u , passwords Pw u , and imprint biometrics Bi u using the mobile device. The mobile device verifies the identity ID u , and biometrics Bi u with its database. Then, the mobile device MD generates nonce based on the timestamp and checks number (CN)nonce = T 1 CN, where CN is a six-digit number for user identification which is a value obtained by calculating the mod in nanoseconds. Then encrypts the nonce with H A = E k MD (nonce). Later, it generates the time one-time password TOTP OTP = H A. The mobile device encrypts the message with AES public key M 1 : C i = E PK aes {ID u Bi u OTP T 1 } and sends M 1 to the vehicle.

2.
Upon receiving M 1 , the vehicle module decrypts it and obtains {ID u Bi u OTP T 1 }. The vehicle verifies the parameters by checking the timestamp T 1 = T, and verifies the identity and biometric. The TOTP is confirmed with the generated batch of TOTPs of the last period T by the vehicle. If the provided TOTP does not match one of the batches and the number or the authentication attempts exceeds ten times, the authentication fails. A failed authentication notifies the user. Otherwise, successful offline authentication is established.

Security Analysis
This section discusses the proposed scheme's security review. We first performed an informal and theoretical security review to show that the proposed scheme is secure and functional. Then, a formal security analysis using SVO logic was performed; more details are reported in the following paragraphs.

Informal Security Analysis
The informal security analysis is shown in this subsection to provide a deep discussion on securing against various attacks. The security properties and functionality are also provided to ensure that the proposed scheme meets the security requirements. Table 3 provides the security feature comparison.

1.
Mutual Authentication: The authentication scheme must provide mutual authentication between all the considered entities in the system. In the proposed scheme, the user can communicate with all entities by verifying the timestamp T 1 = T. The freshness of the session key KS V→TGS = h(ID v ⊕ r 3 ) is checked by the AS and the TGS. Furthermore, the one-time password (OTP) is verified by the server with the generated batch to check the message's validity and the OTP. Therefore, the proposed scheme provides a mutual authentication property.

2.
Froward secrecy: In the proposed scheme, the vehicle and the server compute the session key as KS V→TGS = h(ID v ⊕ r 3 ), KS V→CS = h(ID TGS ⊕ r 4 ); hence, the adversary cannot obtain the values because the session key is encrypted with an AES public key and also the ECC key. Furthermore, a new random number is involved in calculating the key session, and the attacker cannot obtain the random value. The user's information is further protected using the one-way hash function .Thus, the adversary cannot obtain the user's bits; therefore, the proposed scheme provides perfect forward secrecy.

3.
Anonymity: Anonymity is essential to protect the user's information in the communication between the entities, since the transmission is done via a public channel. The user's information is calculated C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 ) and encrypted further with AES public key M 1 : E PK aes {C i Bi u }. The adversary will not be able to get the user identity, password, and biometric. Furthermore, this information is protected using a one-way hash function as well. Furthermore, the key session KS V→TGS = h(ID v ⊕ r 3 ), KS V→CS = h(ID TGS ⊕ r 4 ), is generated freshly in every communication, and the adversary cannot track the communication between the entities. Assume the adversary could obtain the key session of the current transmission; he/she could not obtain the key session of the next communication. Therefore, the proposed scheme provides anonymity.

4.
Confidentiality: The proposed scheme ensures the confidentiality of the message by using a fresh random number C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 ). The message is also encrypted using AES public key E PK aes {C i Bi u } in every communication amongst the entities. In the offline authentication, the mobile device encrypts the value that used to calculate the OTP with device key H A = E k MD (nonce). Furthermore, it encrypts the message with an AES key before transmission M 1 : C i = E PK aes {ID u Bi u OTP T 1 }. Furthermore, the key session is generated independently in each communication. Therefore, the proposed scheme guarantees the confidentiality of the message.

5.
Integrity: The integrity of the messages transmitted during the authentication process is guaranteed in the proposed scheme, as the scheme verifies the message by comparing the received values with stored ones in the AS, TGS, and cross-server T 1 = T. The verification depends on the timestamp's freshness and the secret values on the server side by calculating them to confirm the message's authenticity. Therefore, the proposed scheme provides message integrity. 6.
Key freshness: In the proposed scheme, the shared key session is generated as The key session is generated freshly in every communication session amongst the vehicle, AS, TGS, and cross-server. Hence, the adversary cannot obtain the key session since it calculates the identity and fresh random number. Assume the adversary obtained the current key session; he/she will not get the session key of the next communication. Therefore, the freshness of the key is provided by the proposed scheme. 7.
Offline Authentication: The proposed scheme provides an offline authentication between the mobile user device and the vehicle by providing the vehicle OTP=HA, and C i = E PK aes {ID u Bi u OTP T 1 }. The vehicle checks the timestamp T 1 = T, and verifies the identity and biometric. Furthermore, The TOTP is confirmed with the batch of TOTPs generated in the last period T by the vehicle. If the provided OTP does not match one of the batches, the authentication fails; otherwise, successful offline authentication is established. Therefore, the proposed scheme provides offline authentication between the user and the vehicle. 8.
Cross-domain authentication: The vehicle can authenticate to any server registered with a central authority and in a different geographical location. The proposed scheme allows the user to authenticate with the server in the booking phase applied in online mode. The vehicle sends an authentication request to the central authority to get the ability to authenticate with a cross-server. Therefore, the proposed scheme provides cross-domain authentication. 9.
Replay attack: The freshness of the messages is guaranteed in each session, since the message is composed of a fresh timestamp T n . The tickets and the messages M 2 : Upon receiving the message, the receiver checks the freshness of the timestamp by comparing it with the current time of the system T 1 , T 2 , T 3 = T. The T usually is very small to make it difficult for the adversary to replay the captured message within T. The message is further encrypted with a temporary session key make it computationally infeasible for the adversary to modify the composing timestamp. Therefore, the proposed scheme is resilient to replay attacks. 10. Impersonation attack: The adversary who wants to impersonate the user must calculate a valid C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 )in the online booking phase. The values h(ID u ⊕ Pw u ⊕ r 1 ) are protected using a one-way hash function, and the adversary cannot decipher such values. Additionally, post-transmission is encrypted with the AES key for secure communication and to prevent attackers from capturing the user's information. Therefore, the proposed scheme is resilient to impersonation attacks. 11. Modification attack: In the proposed scheme, the message integrity is preserved using a one-way hash function to protect the user's information. for example, the element O = hash(t) guarantees prevention against modification attacks. Any alteration in the value O can easily be identified during the comparison and reconstruction of the message at another entity. Furthermore, the messages exchanged amongst entities are encrypted using AES public key, and the communication is retained. Assume the adversary captured the message M 2 : E PK aes {ID u ID V T 2 KS V→TGS TGS TKT }; it is computationally challenging for the adversary to make any changes as the information is encrypted with a temporary session key. Similarly, the exchanged messages are ciphered to prevent any modification. Therefore, the proposed scheme withstands the modification attack. 12. Man-in the middle attack: In this attack, the adversary tries to modify the captured message in a way where the destination cannot differentiate the modified message from the original message. Assume the adversary applies an MiTM attack between the vehicle and the AS by capturing and modifying the message M 2 : E PK aes {C i , OTP, Bi u }, or the message between the vehicle and the TGS M 4 : E KS V→TGS {ID u ID V T 2 TGS TKT }. The message's construction is computationally hard for the adversary, as the message is double encrypted with both the fresh session key and an AES public key. Furthermore, the tickets, such as CS TKT = E PK aes {ID u ID V E KS V→CS {ID CS T 3 S i } are encrypted, and each contains a ciphered timestamp and secret value that will be validated later by their respective destinations. Therefore, the proposed scheme is protected from a man-in-the-middle attack. 13. Server spoofing attack: This attack tries to spoof a server by replaying an old authentication message M 2 old i : E PK aes ID u ID V T 2 KS V→TGS TGS TKT . This attempt fails, since the user uses a new and different random number, and a fresh session key is used as well, which means the session key is used differently in each session. The session key of the current communication is different from those of the last and next sessions. Therefore, the proposed scheme is resilient to a server spoofing attack. 14. Privileged insider attack: A privileged attack can allow access to a user's information.
Assume the adversary has the registration information of the user identity ID u , Pw u , and Bi u ; he/she cannot guess the information as the information is protected using a one-way hash function C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 ) and composed with a random number. Furthermore, the information is ciphered before transmission. Therefore, the proposed scheme withstands a privileged insider attack. 15. Denial of service (DoS) attack: A DoS attack makes the server unavailable. In the proposed scheme, the timestamp T n is used to check the freshness of the message.
In the booking phase, if the user and central authority exchanged the messages M 2 : E PK aes {ID u ID V T 2 KS V→TGS TGS TKT }, CS TKT = E PK aes {ID u ID V E KS V→CS {ID CS T 3 S i }, the server checks the timestamp against the current timestamp T 1 , T 2 , T 3 = T; if not fresh, the server rejects the message. Furthermore, the message also included a secret value S i . The server will check that for the validity of the message. As a result, the proposed scheme is secure against the DoS attacks. 16. Offline guessing attack: With the assistance of the side-channel attacks such as SPA and DPA, the adversary cannot obtain C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 ) because the user's information is protected using the one-way hash function. Even if the adversary obtains ID u ID V T 2 KS V→TGS TGS TKT , he/she cannot decipher the ticket in the offline environment and encrypted using the temporary session key. Therefore, the proposed scheme withstands the offline guessing attack.

Syverson and Van Oorschot (Svo) Logic
A growing number of researchers are turning to systematic analysis to assess their protocols and schemes' security. Syverson and Van Oorschot's (SVO) logic [45], as a significant BAN-like logic, possesses the advantages of BAN logic, GNY logic, and AT logic. Furthermore, SVO logic redefines certain standard semantic principles and has fundamental inference rules or axioms. SVO logic is now a commonly used formal analysis technique. However, we provide formal security proof of the proposed scheme using SVO logic in this subsection. Table 4 gives the notation that is used in SVO logic and relevant descriptions.

Notation
Description ϕ ϕ is a theorem PK σ (P, K) K is the public signature verification key for P PK δ (P, K) K is the public key-agreement key for P SV(X, K, Y) K can verify if X is Y's signature Fresh(X) X is fresh XK The ciphertext encrypted by K [X]K The message signed by K Initial Rules:The SVO logic has two main inference rules: 1.
SVO axiom:For any subject P and Q, the sum of the formulas ϕ and ψ have the following axiom schemata's:

Having:
Ax.20: P has K ⊃ P sees K.
According to the formal descriptions of the security proof presented in this subsection, the proposed authentication scheme is secure.

The Avispa Simulation
AVISPA offers a broad range of modeling applications for cryptographic protocol analysis, verification, and validation. It describes security protocols using the High-Level Protocol Specification Language (HLPSL) [55]. HLPSL is a high-level, modular language requiring various attacker models, cryptographic primitives, and complex security properties. The protocol was first translated into intermediate form (IF) using the HLPSL2IF translator, and then IF was used as input to four different back-ends, as shown in Figure 10, which included On-the-fly Model-Checker (OFMC), CL-based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC), and Tree-Automata-based Protocol-Analyzer (TA4SP). The transmission channel was also thought to be under the influence of the Dolev-Yao attacker. A few automated security validation tools, such as ProVerif and Scyther tools, were utilized to verify the security of the protocol. Using these tools, it is easy to know what flaws such protocols suffer from. Although verification using these tools does not ensure that the protocols once verified by these tools are flawless, they still provide a means to know many of the flaws easily. ProVerif verified specifications of protocols in the symbolic model, which could also be a limitation, since the symbolic model abstracts away the details of cryptographic operations, and specifications do not consider all implementation details [55]. Unlike other studies, we used the widely used AVISPA formal verification tool because the AVISPA tool is efficient at verifying and falsifying security protocols. This tool can be used for the final analysis of the cryptographic protocol, as it allows one to detect atypical errors according to the established requirements. There were two protocols designed, online booking and offline authentication; hence, the formal verification of the online booking and the offline authentication is discussed further in the following paragraphs.

Specifying the Online Booking in Hlpsl
The online booking phase's implementation, including the vehicle registration phase, login, and authentication phase, is provided in this subsection. Our simulation had four main roles: vehicle (Vi), authentication server (AS), ticket granting service (TGS), and cross-server (CS), respectively. However, the vehicle's specifications in HLPSL language are shown in Figure 11. The vehicle Vi received the start signal and changed its state from 0 to 1, and the sent the registration request message (V.TGS.cLifetime_1. Bio'. Ci'. N1') to the AS securely using the /\ Snd () operation. In the login phase, the vehicle then generated (OTP': = Kv.current_time ), and sent (CS.cLifetime_2.Uid'.Bio'.TGSid'.TkT1'.{V.OTP'}_K_UG') using the /\ Snd() operation. The declaration /\ witness (V, TGS, t1, OTP') expressed the TGS acceptance of the generated OTP by vehicle. The declaration /\ wrequest (V, AS, k_cg1, K_UG') indicates that the vehicle requested the AS to check the validity of the value K_UG'. The role of the authentication server is shown Figure 12. The AS received the message (V.TGS.Lifetime_1'.N1'.OTP'.Ci') and changed its state from 0 to 1, which was maintained by the variable state, and then sent the M3':= ({Uid'.Vid'.Ts2'.TGS_tkt'}_Pk_aes) securely to the vehicle. It also generated ticket TGS_tkt':= ({Uid'.Vid'.Ts2'.K_v_tgs'}_SK_tgs) encrypted using the TGS secret key. The declaration /\ witness(AS,V,k_cg1,K_v_tgs) shows that the shared key K_v_tgs was sent to the vehicle by the AS. Likewise, /\ witness(AS,TGS,k_cg2, K_v_tgs') indicates that the TGS believed that the AS generated a fresh K_v_tgs and the AS witnessed it. The declaration /\ secret(K_v_tgs',sec_a_K_UG,{AS, V,TGS}) illustrates that the K_v_tgs' was shared securely and remained secret to the AS, V, and TGS. Figure 13 shows    The role of the cross-server CS in HLPSL is shown in Figure 14. It started by receiving the message ({V.CS.K_US'.Ts2'.CS_tkt'.Tse2'}_K_GS.V.T2'_K_US') from the vehicle using the operation Rcv(). Later, the CS declared /\ witness(CS,V,t2a,T2') to indicate that the CS witnessed the T2 that was generated by the V. The declaration /\ wrequest(CS,TGS,k_cs2,K_US ) shows that the TGS requested the CS to validate the value K_US', where /\ wrequest(CS,V,t2b, T2') declares that the V requested the CS to check the freshness of the value T2. Later, we stated /\ secret(K_US',sec_s_K_US,{TGS,V,CS}) to declare that the key K_US was secretly shared amongst the agents TGS, V, and CS. Finally, the session's roles, goal, and environment in HLPSL are shown in Figure 15. In the session role, multiple participants are instantiated. In the environment role, the sessions are combined, and intruder knowledge is defined.
There are six secrecy goals and seven authentications amongst the participants, as shown below: Goals: •

Booking Phase Simulation Results
The proposed scheme's simulation results in OFMC and CL-AtSe back-ends are shown in Figures 16 and 17. From the output format, the following analysis can be prsented: • SUMMARY: This section specifies whether the protocol is "secure," "unsafe," or "inconclusive."   The proposed scheme has been simulated on two back-ends-the On-the-fly Model-Checker and the Constraint Logic-based Attack Searcher. The SUMMARY section indicates that the proposed protocol is SAFE and is defensive against active and passive attacks, including replay and man-in-the-middle attacks.

Specifying the Offline Phase in HLPSL
The specifications of the offline authentication implementation in HLPSL is provided here. In this protocol, the two main agents are a mobile device MD and a car. Figure 18. Shows the role of the mobile in HLPSL. The role starts by receiving the signal (start) and changes its state from 0 to 2; then, it generates the nonce /  Likewise, the role of the car in HLPSL is shown in Figure 19. It starts by receiving the message from the mobile and changes its state from 1 to 3, and then it verifies the message for successful or failed authentication. In Figure 20, the role of the session and environment is illustrated. One secrecy goal is stated between the mobile device and the car secrecy_of sec1, which means that the values (Uid'.Bio'.OTP'.TS1) are known to the Md and CAR.

Offline Phase Simulation Results
The simulation results of the proposed scheme with two back-ends OFMC and CL-AtSe, are shown in Figures 21 and 22. The OFMC and CL-AtSe back-ends results show that the proposed offline phase designed to enable users to authenticate to the vehicle in offline mode is secure from active and passive attacks.

Performance Evaluation
The proposed scheme's performance evaluation is compared with the performances of other related schemes, i.e., the HOOSC [39] scheme, SM-AKA [40] scheme. CP-VBP [20] scheme, and RSEAP [18], in terms of computational cost and communication cost; their comparison is shown in Table 5. More details are shown in the following subsections.

Computational Cost
The total computational cost for the execution of our scheme is compared with those of other schemes in this section. The estimation of the cryptographic operations' execution time was computed by using the PBC library reported in [53], as illustrated in Table 6. The proposed scheme's simulation was carried out on Intel Core™i7-5700HQ, CPU 2.70GHz platform using Java Pairing-Based Cryptography Library (JPBC). Since the bitwise XOR computational cost is much less than those of other operations, it was not considered in the performance analysis. However, in HOOSC [39] scheme, there are three types of cryptographic operations the user needs to perform, i.e., the point multiplication operation (T m ), exponentiation operation (T e ), and bilinear pairing (T P ). The execution times for these operations, as stated in Table 4, are 0.832, 6.614, and 12.523 ms. In the online phase, there are four-time 4T m and one-time exponentiation 1T e that can be represented as 4T m + 1T e = 9.942 ms. In the offline phase, there is a one-time multiplication operation 1T m , one-time exponentiation 1T e , and two-time pairing 2T P that can be represented 1T m + 1T e + 2T P = 32.492 ms. Therefore, the total computational cost of HOOSC [39] is 42.36 ms.
In the SM-AKA [40] scheme, six cryptographic operations are required: a nineteen-time hash function T h , fuzzy extraction operation T f e , symmetrical encryption (T S E), symmetric decryption (T S D), scalar multiplication (T sm−ecc ), and scalar multiplication (T sm ). Hence, the computational cost in the online phase 19T h + T f e + T SE + T SD + T sm−ecc + T sm = 20.727 ms. In the offline phase, the computational cost can be represented as 9T h + T f e + 4T SE + 2T SD + 2T sm−ecc = 1.298. Therefore, the total computational cost in SM-AKA [40] is 22.052 ms.
For the pseudo-identity generation process of CP-VBA scheme [20], a vehicle needs to perform four scalar multiplication operations related to ECC and two hash operations. Thus, the computational cost of the pseudo-identity generation process of their scheme is 4T sm−ecc + 2T h + 2T sm = 21.638 ms. Note that the pseudo-identities of vehicles in CP-VBA scheme [20] are generated by RSU, and we only count the computational cost on the vehicle side. For the message signing process, a vehicle needs to perform one scalar multiplication operation related to ECC and one hash operation. Thus, the computational cost of the message signing process is T sm−ecc + T h = 0.353 ms. For the message verification process, a vehicle needs to perform three scalar multiplication operations related to ECC, two-point addition operations related to ECC, and two hash operations. Thus, the computational cost of the message verification process is 3T sm−ecc + 2T p + 2Th = 1.0622 ms. In RSEAP [18], the vehicle requires one to perform 2T IDV + 5T h , which has the cost of 11.755 ms. the total 5ET sm + 9T h operations are performed in offline phase. Thus one should calculate the total time consumption as 5 × 1.970 + 9 × 0.0023 = 9.8707.
With the proposed scheme, we performed a lightweight cryptographic operation hash function T h , symmetrical encryption (T SE ), symmetric decryption (T SD ), and publickey-based encryption (T PE ). Their execution times were 0.0046, 0.0046, 0.0046, and 3.85, respectively. In the online phase, there were four-time hash functions 4T h , six times symmetrical encryptions 6T SE , six times symmetrical decryptions 6T SD , and four public-key-based encryptions 4T PE . The execution times for these operations were 0.0184, 0.0276, 0.0276, and 15.4 ms. Therefore, the total execution time in the online phase was approximately 15.473 ms. In the offline phase, the user needs to perform onetime symmetrical encryption 1T SE , and one-time symmetric decryption 1T SD , and their execution times will be about 0.0046 and 0.0046. Therefore, the execution time in the offline phase is nearly 0.0092 ms. Therefore, the total duration required for the proposed scheme is 15.482 ms. Table 5 shows that the proposed scheme has less computational costs compared to other schemes.

Communication Cost
To compute the communication cost, we can measure the sizes of the messages transmitted between the entities multiplied by the (bit) sizes of the parameters. Here we assume that user identity has the size of 32 bits and timestamp 24 bits, the ticket value size is 128 bits, the secret value is 160 bits, and the check number CN and the OTP are 32 bits each. In the HOOSC [39] scheme, the node sends the message (C, β, µ, R) to the server in the online mode phase and the ciphertext size 640 bits, and the other is 160 bits independently. The size of the message can be represented as (640 + 3 × 160) 1120 bits. The server then sends the message (M, α) to the node and it has a size of (640 + 160) 672 bits. In the offline mode, the size of the transmitted message is 448 bits. Therefore, the total communication cost of HOOSC [39] scheme is approximately 2368 bits. In SM-AKA [40], there are six messages interacting amongst the system entities.  [40] is 2880 bits. In CP-VBA scheme [20], a vehicle needs to broadcast PID i = (PID 1 i , PID 2 i , T i ), m i , δ i = ( f i , g i ), B i , K i , R i , T 1 wherePID 1 i , B i , K i , R i ∈ G, PID 2 i , f i , g i ∈ Z * q. Thus, the communication cost of CP-VBA's scheme [20] is (320 + 160 + 32 + 160 + 160 + 160 + 320 + 3205 + 320)/8 = 244 bytes which is equal to 1952 bits. The communication overhead of RSEAP [18] computes as if T i sends < ID T ⊕ ax s , ag, W 1 , T LA1 > through the RFID reader. It takes 160 +160 + 192 bits, so it also consumes the 512 bits. Further, RFID reader passes out the message by updating the time stamp and sends < ID T ⊕ ax s ag, W 1 , T LA3 >so it also consumes the 512 bits. After authenticating the Ui, the S responds as < W 2 , bg, T LA5 >, which consumes 352 bits. Moreover, RFID tag just continues by updating the < M 3 , T LA7 >, which consumes 384 bits. Thus, the total over head of RSEAP is 1740 bits in whole communication.
In the proposed scheme, the user sends the message C i = ID V ⊕ h(ID u ⊕ Pw u ⊕ r 1 ) using the mobile device to the vehicle and the size of the message can be represented as (32 × 3) 96 bits. Later, the vehicle sends the message {C i , TOTP, Bi u }, where C i has the size of 64 bits and the TOTP, and Bi u have the size of 32 bits independently, therefore, the message costing 128 bits. The authentication server replies to the vehicle the message {ID u ID V T 2 KS V→TGS TGS TKT } that can represented as (32 × 2 + 24 + 128) 216 bits. After that, the vehicle forwards the message {ID u ID V T 2 TGS TKT } of (32 × 2 + 24 + 128) 216 bits. Then, the TGS replies the message with {ID u ID V T 3 CS TKT }, which is (32 × 2 + 24 + 128) 216 bits. Finally, the vehicle communicates with cross server by sending {ID u ID V E KS V→CS }{ID CS T 3 S i and the size of it is (32 × 3 + 24 + 160) 280 bits. Therefore, the total communication cost of the online booking phase is nearly 928 bits. In the offline mode, there are two interacting messages; only the message C i = E PK aes {ID u Bi u TOTP T 1 } which is sent to the vehicle has (32 + 32 + 24) 88 bits. Therefore, the total communication cost of the proposed scheme is approximately 1016 bits. The communication cost of the proposed scheme compared to those of other schemes is shown in Table 5.

Conclusions
This paper proposed a hybrid online-offline multi-factor cross-domain authentication method for IoT applications in the automotive industry, especially car-sharing systems. The proposed scheme utilizes a Kerberos workflow by extending using the AES-ECC algorithm. The combination of AES-ECC is applied to secure the communication between the entities and efficient key generation management due to ECC advantages, which has less processing time complexity. The proposed scheme provides an online and offline mode when connectivity services are not available. The user can book the vehicle by entering his identity, password, and some biometric using a mobile phone online. When there is no Internet connection, the user can authenticate with the vehicle using the offline authentication mode. The offline mode is based on the one-time password (OTP) algorithm by providing the authentication server's user value (CN) during the booking phase. Furthermore, the security features and properties were proved informally to obtain the achieved features. The SVO logic was used for formal security verification to validate the authentication security. Likewise, the AVISPA tool was utilized to verify that the proposed scheme is secure against passive and active attacks, i.e., replay attack, man-in-themiddle attack, impersonation attack, and so on. The proposed scheme's functionality and performance results showed that the scheme has better security, superior computational efficiency, and lower communication costs. The results were achieved due to the AES-ECC algorithm using a lightweight cryptographic operation, which has less processing time, making it suitable for the IoT environment. We plan to extend our work by applying it to the Industrial Internet of Health Things in the future. Furthermore, the proposed scheme can be implemented in the hardware environment due to its lightweight performance.