Security and Privacy Challenges for Intelligent Internet of Things DevicesView this Special Issue
Revisiting a Multifactor Authentication Scheme in Industrial IoT
Nowadays, as one of the key applications of Internet of Things, Industry IoT (IIoT) has recently received significant attention and has facilitated our life. In IIoT environments, an amount of data generally requires to be transmitted between the user and sensing devices in an open channel. In order to ensure safe transmission of these data, it is necessary for the user and sensing devices to authenticate each other and establish a secure channel between them. Recently, a multifactor authenticated key agreement scheme for IIoT was proposed, which aims to tackle this problem and provide solutions for user multiple sensing devices’ access. This work claims that the proposed scheme is secure against vario us attacks and has less communication and computational costs than other existing related schemes. Unfortunately, we find that this scheme cannot resist smart card attack and sensing device capture attack. Furthermore, we show that this scheme fails to provide forward secrecy, which is essential for a secure multifactor authentication scheme.
Internet of Things (IoT) has developed rapidly in recent years, which generally penetrates into people’s life, and there are many IoT devices applied to various domains [1, 2]. Due to the superiority in automatic monitoring, efficient control, and intelligent manufacturing, Industry IoT (IIoT) is widely concerned among these domains. In the IIoT environment, sensing devices can be accessed and controlled by users remotely. During the process of production, sensing devices collect the real-time data, and the data can be obtained by users. The network model for IIoT is described in Figure 1. As a security critical system, IIoT has higher requirements in the secure transmission and communication of data [3, 4]. However, it is vulnerable to an attacker to perform attacks because the collected data is often transmitted through a public channel, and this brings security problems in the IIoT environment. It is possible for an adversary to launch attacks and impersonate an authorized user to obtain the data by accessing sensing devices. The unsatisfactory situation mentioned above will lead to destruction of the industrial production.
Therefore, in order to ensure the safe data transmission between users and sensing devices, many authenticated key agreement schemes [5–7] in IIoT are proposed. In these schemes, users are only allowed to access one sensing device at a time. When the user accesses multiple devices, his identity must be validated repeatedly. While supporting the critical security features, such as shared session key establishment and user authentication, an authentication scheme for IIoT environments should also be able to reduce the communication and computational costs due to the resource-constrained nature of IoT devices.
Recently, Vinoth et al.  proposed a multifactor authenticated key agreement scheme for the IIoT environment, aiming to support the authorized user remotely accessing multiple sensing devices. They claimed that their scheme is suitable for the resource-constrained IIoT and has less cost during communication and computation processes. Besides, they demonstrated the security of the proposed scheme through a formal security analysis, which indicates that their scheme is resistant to various known attacks. Unfortunately, some subtleties are overlooked. In this paper, we find that their scheme cannot resist the smart card attack and the sensing device capture attack. Furthermore, we point out that their scheme cannot support forward secrecy. Although the scheme is a multifactor authentication mechanism designed by Vinoth et al., we do not think it can provide truly multifactor security.
2. Revisiting Vinoth et al.’s Scheme
In this section, we first revisit Vinoth et al.’s scheme  briefly and list some intuitive notations and abbreviates in Table 1 for the convenience of description. Their scheme includes six phases, while we only review the first three phases, which are related to our proposed attacks.
2.1. Offline Sensing Devices’ Registration Phase
Each sensing device is registered by in offline and is distributed a unique identity . In order to calculate the secret, chooses a secret value and two vectors and . Assume that and . then computes and picks pair-wise relative positive numbers for each sensing device . computes and . Then, generates a random nonce , which satisfies . calculates as and stores it. sends to each sensing device.
2.2. User Registration Phase
(1)Step URP1: chooses a high-entropy password and an identity . imprints the biometrics and uses the generation algorithm to calculate . It notes that the algorithm is built into the fuzzy extractor. generates a 128-bit random nonce and computes as . Finally, sends a message to .(2)Step URP2: after receiving the message , generates a 1024-bit random secret key and further calculates . Then, calculates as and as . In addition, for each user , generates a 128-bit identity . Finally, generates the smart card and sends to .(3)Step URP3: after receiving , in order to protect , calculates . then computes and . further calculates . Finally, needs to store into the memory.
2.3. Authenticated Key Agreement Phase
This phase includes the following steps. This phase along with the login phase is summarized in Table 2.(1)Step AKAP1: after receiving the message , firstly verifies whether to check the freshness of login request. If it is true, obtains and corresponding to by retrieving the database. calculates , . In order to authenticate the authenticity of , checks whether is equal to . If it holds, generates the current timestamp and a random nonce . calculates as to securely send to each sensing device. Then, calculates to encrypt the parameters. After that, computes to help sensing device authenticate . Finally, broadcasts the message via a public channel.(2)Step AKAP2: after receiving the broadcast message from , each sensing device verifies to check the freshness of the message firstly. If the inequality holds, uses CRT to obtain by its stored value . then uses the group key to decrypt to attain the sensitive parameter . further calculates with the condition to verify . If it is true, each computes to encrypt the legal share and generates the current timestamp . Then, each sensing device sends the reply message to securely.(3)Step AKAP3: when receiving the message, firstly verifies to check the freshness of the message. If it holds, obtains share by calculating . further computes and and checks whether . If it holds, can reconstruct the secret successfully. Then, computes , , and . then generates the current timestamps and a new temporal identity and calculates . Finally, broadcasts the message to all the participants and sends the message to .(4)Step AKAP4: when receiving the message from , each sensing device calculates and . If , each device calculates as . validates the shared session key by computing and sends it to .(5)Step AKAP5: after receiving the message, firstly verifies to check the freshness of the message. If it holds, computes . Then, checks whether to validate the session consistency. If it holds, computes . If , further calculates as with sensing devices. calculates after receiving the message from the sensing device and checks whether . If it holds, needs to change .
3. Cryptanalysis of Vinoth et al.’s Scheme
For a multifactor authentication scheme, it is essential to create a concise and concrete adversarial model. In this section, we propose two attacks, a smart loss attack and a sensing device capture attack to show the vulnerabilities of the scheme. First of all, we refer to the adversary model proposed by Wang et al.  which is strict but reasonable. The assumptions below are about the adversary’s capabilities:(1)There exist two kinds of communication channels: a secure channel and a public channel. The former is mainly used for registration, while the other is mainly used in login and authentication phases. The adversary has full control of the public channel, i.e., can eavesdrop, intercept, modify, and redirect messages transmitted between communication participants [10, 11].(2)The adversary can offline exhaust all the items in the Descartes space of identities and passwords which are of low entropy within polynomial time.(3)When it comes to multifactor authentication, the scheme should be secure even if one or more factors are compromised, which is called truly multifactor security . Therefore, it is reasonable to make an assumption that may obtain a victim’s password by performing shoulder surfing or phishing attacks, extract the secret parameters in the lost smart card by performing side-channel attack, or attain a victim’s biometric information using malicious devices. However, the above assumptions cannot be achieved at the same time; otherwise, it will be a trivial case.(4)The adversary could be the administrator of the server or a legitimate user in the system.(5)The adversary can determine victim’s identity.
It is worth noting that users can select his/her identity and password in many protocols. However, the user selected identities and passwords are usually of low entropy () [13, 14]. Therefore, assumption (2) is realistic. Then, assumption (3) specifies truly three-factor security. And, assumption (4) can be used to capture the threats from the system when the server is corrupted or any legitimate users are malicious. Finally, assumption (5) describes the fact that most of the user identity are user’s e-mail addresses or phone numbers, which can be easily obtained. The following analysis will take the five assumptions mentioned above into account.
3.1. Smart Card Loss Attack
We employ the user as the victim to show the process of this attack. According to assumption (3), it is reasonable for the adversary to get ’s smart card (stolen or picked up) and corresponding biometrics . Besides, as a premeditated adversary, has full control of the public channel, and she can collect a past transcript between and gateway node (i.e., ). Then, can guess ’s password and identity correctly as following steps: Step 1. computes , where can be extracted from victim’s smart card Step 2. chooses a pair from , where denotes the identity space and denotes the password space Step 3. computes Step 4. computes Step 5. computes , noted that can extract from victim’s smart card and collect from the past transcript Step 6. computes and verifies the correctness of pair by checking if Step 7. executes the steps 26 repeatedly until finding the correct values
As mentioned before, users can choose his/her own and in most password-based authentication schemes (e.g., References [15–17]) aiming to achieve user-friendliness. And, Vinoth et al.’s scheme is no exception. It makes assumption (2) reasonable that users often select low entropy identities and passwords. Therefore, it is possible for to exhaust all the pairs offline within polynomial time. We can calculate the running time of the attack procedure as , where represents the number of identities, represents the number of passwords, and represents the running time for Hash operation. Note that the operation time of bit-wise XOR operation in Step 3 can be ignored. Since and are very limited (e.g., ) [13, 14], the attack mentioned above is significant and shows a challenge to user authentication protocols.
3.2. Sensing Device Capture Attack
According to Vinoth et al.’s threat model, the adversary can compromise a sensing device and extract the parameters stored in it (i.e., ). We assume that is captured by the adversary; then, can successfully impersonate the user as follows: Step 1. Computes , where is received from Step 2. Decrypts the received message by using the key and obtains the security parameters of the user who is sending the login request Step 3. Computes as Step 4. Computes , where and are obtained from the public channel Step 5. Randomly chooses a new nonce and current timestamp Step 6. Computes as and as Step 7. Sends the login request to and finishes the login phase
After receiving the message, first checks the freshness of the received message and computes , where is stored in the ’s database and retrieved according to corresponding . Then, computes and verifies whether the calculated is equal to the received . If it holds, will authenticate the authenticity of . Since the parameters are calculated correctly, the adversary can pass the verification of the . So far, the adversary has successfully impersonated user .
3.3. No Forward Secrecy
When a scheme ensures that, even the long-term private keys (or secret) of communication participants are leaked, previously agreed session keys can still be secure , then the scheme is called supporting forward secrecy. It is important for security critical systems to support forward secrecy, especially when there still exist many security and privacy problems in the IIoT environment.
If an attacker has captured a sensing device , extracted the parameters from , and intercepted the messages , the following method can be used to calculate the session key: Step 1. computes , where is received from Step 2. decrypts the received message by using the key and obtains the security parameters of the user Step 3. computes , where is received from Step 4. computes the session key
With the session key computed, the entire session will be no secret to the adversary .
3.4. Security Vulnerability Discussion
In this section, we highlight again that when considering multifactor security, even if one or more authentication factors are obtained (not all) by the adversary, the scheme should not be broken. Based on this assumption, we proposed the smart card loss attack and the sensing device capture attack. Although Vinoth et al. have employed the fuzzy-verify technique proposed by Wang and Wang , the adversary can still obtain victim’s password in the way of offline guessing. This disappointing situation is caused that they do not employ the public-key cryptosystem and no public key material is used to construct the login message. To solve this problem, we suggest to use Diffie–Hellman key exchange scheme. Specifically, computes and stores it into ’s smart card during the user registration phase, where is a generator of the group , is a large prime number, and is ’s secret key. After that, when logs in, she should choose a random number and compute first; then, she constructs the login message . Since the adversary cannot calculate , the aforementioned smart card loss attack can be prevented.
Meanwhile, in the sensing device capture attack, an adversary can impersonate user even without her password . Essentially, when authenticating the identity of user , the only checks whether the user who sends the login request holds the parameter . Unfortunately, is encrypted by the group key in the message , but obtaining the group key is easy for an adversary who has breached the and extracted . After this, could decrypt to get , and . With these parameters, can bypass the system’s user authentication. One possible countermeasure to this problem is that constructs the message and . As a result, when receiving the message, , the adversary who captures the sensing device can only obtain the parameter by decrypting . Therefore, cannot impersonate since she cannot obtain .
Note that, one may argue that when the victim user interacts with the , she uses her temporary identity , and it seems impressible for an adversary to find victim’s message from the transcript. However, according to assumption (5), the adversary can determine victim’s identity. Thus, a premeditated adversary may first compromise a sensing device and wait for the victim chosen by her to send the login request message. Then, decrypts to get and checks if this ID belongs to the victim. After that, continues to monitor the channel until ’s session ends. Finally, could calculate as Step 4 of the sensing device capture attack.
In order to fix the defects of forward secrecy, we also rely on public key cryptography. Specifically, before computing , first chooses a random number and computes . Then, computes and sends it to . After that, chooses a random number and computes , , , and . In Section 3.4, we show that the adversary can compute the session key , and this is caused by to obtain . However, is protected by the shared key now. As a result, cannot calculate the previous session key. In order to be consistent with the previous modification, the session key is calculated as .
In this paper, we have revisited and analysed Vinoth et al.’s authentication scheme for IIoT environments. We demonstrate that their scheme suffers from the smart card loss attack and the sensing device capture attack although they claimed that their scheme has the ability to defend various known attacks. We have also briefly discussed the potential causes of these defects. It is hoped that the proposed attacks can help inspire new designs of secure and efficient multifactor authentication protocols for IIoT.
Data sharing is not applicable to this article as no new data was created or analysed in this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.