New design of lightweight authentication protocol in wearable technology

Today, the use of wearable devices is becoming a thing inherent in the daily activities of urban communities. In practice, wearable communications may contain sensitive information regarding a user's health record, so authentication and confidentiality of data exchanged must be guaranteed. In addition, the success of authentication between users, wearable devices and smartphones is very important because there are various threats of attack on the authentication process. Based on previous studies, it was found that the security functionality of user impersonation attack is not owned by lightweight authentication protocols in the current wearable communication environment. So this research undertakes the design of a lightweight authentication protocol to be immune to user impersonation attacks to supplement the lack of security functionality in previous protocols with the support of performing a formal analysis using the Scyther Tool. The research method used is a Research Library supported by conducting protocol security test experiment. The developed protocol utilizes a modified and customized S-NCI key establishment protocol scheme to meet all targeted security functionality. The research resulted that the lightweight authentication protocol generated was immune to the impersonation attacks of users, then was able to add two new functionalities that added wearable devices and added smartphones.


Introduction
Wearable technology is an electronic technology or computer that is incorporated into items of clothing and accessories which can comfortably be worn on the body.These wearable devices can perform many of the same computing tasks as mobile phones and laptop computers; however, in some cases, wearable technology can outperform these handheld devices entirely.Wearable technology tends to be more sophisticated than handheld technology on the market today because it can provide sensory and scanning features not typically seen in mobile and laptop devices, such as biofeedback and tracking of physiological function [1].
The authentication process between WD and MT becomes very important.Authentication is very important because there are various threats of attack that can happen [2].Based on [2,3] comparative results of concise authentication protocol schemes in a wearable communication environment consisting of Liu et al [4], Sun et al [5], Liu et al [6], it was generated that the security features of mobile terminal stolen attack, wearable device stolen attack, replay attack, user/wearable device/mobile terminal impersonation attack and the use of non-tamper resistant are not supported by all three protocol schemes.In addition, a number of such attacks can be classified into unauthorized access activities where the required security requirement is with the key establishment and trust setup [7].The comparative results of a number of lightweight authentication protocol schemes in wearable communication environments based on their security features are described in Table 1.Meanwhile, wearable device usage trends are illustrated in Figure 1.The problem in this research is how the resistance of lightweight authentication protocol in wearable communication environtment is designed against mobile terminal stolen attacks, wearable device stolen attacks, replay attacks, and wearable device/mobile terminal/user impersonation attacks.
Following up on these conditions, the proposed solution in this study is designing a lightweight authentication protocol on a wearable communication environment that is immune to  ISSN: 1693-6930 TELKOMNIKA Vol.17, No. 2, April 2019: 561-572 562 mobile terminal stolen attacks, wearable device stolen attacks, replay attacks, and wearable device/mobile terminal/user impersonation attacks to complement feature deficiencies security on previous protocols supported by performing a formal protocol analysis using Scyther Tool [10][11][12].

Research Method
The research method used is a Research Library supported by conducting protocol security test experiment.Then, step research flowchart is described in Figure 2.

Results and Analysis
Based on the understanding of previous protocols, the characteristics of the lightweight authentication protocol can be explained in Table 2.In addition, the results of weakness analysis of previous protocols are Liu et al [4], Sun et al [5], Liu et al [6] and alternative development solutions described in Table 3.
In practice, key establishment protocols can involve trusted third-parties as initial system setup and online actions [13][14][15][16][17][18][19].Currently the S-NCI key establishment protocol scheme has been developed.After performing formal analysis of S-NCI [20] protocol using Scyther Tool, it was found that the security characteristics of Alive and Weakagree are not owned by the protocol.So it is necessary to modify the S-NCI protocol by adding ID T (identity T) and N T (Nonce from T), and adding a step as a Step 5. Before and after modification of the S-NCI protocol is described in Table 4. Efforts to utilize and modify related protocols in various fields are also implemented on [21][22][23][24][25][26].Has a preparatory stage 2.
Has an encryption process to ensure data confidentiality 3.
Has a hash function to ensure the integrity of the data 4.
Has a challenge response process to ensure the authenticity of each entity 5.
Has a mutual authentication process 6.
Has the process of providing session key The user's fingerprint information assets and user wearable device passwords whose utilization has not been able to prevent the possibility of impersonation attacks both WD, MT and Users.
User fingerprint information and user wearable device passwords in protocol steps designed to prevent impersonation attacks both WD, MT and Users.

2.
There is user involvement in the role of witnessing and determining whether the WD and MT have been authenticated, but before that user has not performed any special authentication process for the user itself, which ensures that that person is indeed a legitimate user.So it still allows users to forge.
User involvement in determining the success of authentication between WD and MT should be supported by a protocol stage designed to accommodate that only authorized users who can encounter authentication conditions between the WD and the MT.

3.
There are protocol steps that are inconsistent with the design principles of cryptographic protocols according to Abadi and Needham.
In designing a lightweight authentication protocol, it is best to follow the design principles of cryptographic protocols according to Abadi and Needham.

4.
There are a utilization of key exchange protocols that are vulnerable to man-in-the-middle attacks.
A lightweight authentication protocol designed, in its key exchange step should be immune to replay attacks and man-in-the-middle attacks.

5.
Protocol assets that play an important role in determining the authenticity of each entity, are still stored in the device, allowing enemies to obtain the data with a power analysis attack, and can be used for further attacks.
The designed protocol allows all protocol assets that play an important role in determining the authenticity of each entity not stored in the device.Step 1 Step 2 Step 4  →  ∶ Ks (B ||IDT) Step 4 B → T ∶ Ks (T) Step 5

Design of Lightweight Authentication Protocol
The proposed design consists of two stages, namely Registration Phase and Phase Pair and Mutual Authentication.In Phase Pair and Mutual Authentication is divided into three sub-stages.The proposed design begins with an Initialization System explanation.

Initialization System
The notation in the designed lightweight authentication protocol described in Table 5. Figure 3 describes the result of stage Initialization System.Figure 4

Registration Phase
At this Registration stage, a user registers by inputting important attributes required by the protocol through MT to be stored by the Cloud Server.Registration stages are described in Table 6 and Figure 5. Results of registration of the User by using MT, stored in CS, described in Step 1 Step 2  In this case, for example, CS gets "Insert"  However, the description may consist of "Insert", "Upd_WD", "Upd_MT" dan "Upd_pwd_WD"  Description "Insert" can be used in addition to user registration for the first time, also can be used to Add Users, Add WD and Add MT  CS gets KS, NT, IDMT, IDT and Atr_P which contains (B_AddrWD||PWDWD|| IDMT||B_AddrMT||F_InfU) MT←CS∶ EKs (CS|| IDT||3) Step 3  CS calculates Ks (CS|| IDT) to be required in Step 4  MT gets NCS and IDT, so CS and T have been authenticated by MT MT → CS ∶ Ks (CS|| IDT) Step 4 CS → T ∶ Ks (T) Step 5 In Step 4, CS compares the previously computed MAC results, with results received from MT.If the result matches, then the MT has been authenticated by CS and the protocol is proceeded to Step 5, to authenticate CS by T. After all done, CS will process activities "Insert", "Upd_WD", "Upd_MT" and "Upd_pwd_WD".
 If "Insert" (can be used for Initial Registration/Adding Users/Adding WD/Adding MT) then:  CS will add and store all Atr_P data in the tabel_Registrasi_User (    (Authentication between WD and MT).All sub-stages are described in full in Figure 6, Figure 7, Figure 8, and Table 8.

Lightweight Authentication Protocol Security Analysis 3.2.1. User/Wearable Device/Mobile Terminal Anonymity Preservation
The availability of user anonymity preservation, wearable devices and smartphones will be realized when protection from replay attacks and man-in-the-middle attacks can materialize.Due to the attacker trying to get important data that play a role in the success of device authentication/users, from tapping results that can be used to perform replay attacks and man-in-the-middle.However, it can not be attackers doing because the lightweight authentication protocol designed is proven to be immune to replay attacks and man-in-themiddle attacks, so the taping results will also not be useful.

Mobile Terminal Stolen Attack Protection
An attacker can steal or get a legitimate User's Smartphone.Then attacker can perform a power analysis attack to get the data stored on the smartphone.It will not be useful because the data stored on the smartphone are IDT, IDCS, and IDMT where those items do not play an important role in determining the success of the authentication process between devices/users.So the attacker will not be able to use it for a variety of subsequent attacks.

Wearable Device Stolen Attack Protection
An attacker can steal or get a legitimate User's wearable device.Then attacker can perform a power analysis attack to get the data stored on the device.It will not be useful because the data stored on the device are IDT, IDCS, and IDWD where those items do not play an important role in determining the success of the authentication process between devices/users.So the attacker will not be able to use it for a variety of subsequent attacks.

Online/Offline Password Guessing Attack Protection
This activity cannot be done by the attacker because when the wearable device or smart phone is stolen and carried out attack power analysis, which can be obtained by the attacker is an item that is not useful or no effect in the process of authenticating the device or the user, so it can not be used as data that can support a password dictionary attack.In addition, the protocol has also been shown to be immune to replay and man-in-the-middle attacks so the attacker is unable to tap into the communication between the parties.

Privileged-insider Attack Protection
In this protocol, especially at the registration stage, the registration process involved only the legitimate User only.This means there will be no other party who can represent or have the same authority as the actual User.Because in the registration stage, there are biometric data inquiries, and only eligible or legitimate Users have WD and MT pairs alone that can populate the biometric data themselves.In addition, suppose if a legitimate User feels the need to be assisted in the registration, then there are other parties who can help, and for example theft MT, then it is also useless, because the thief if it can do power analysis, and the data obtained nothing useful in the success of the authentication process.

Traceability Preservation
Traceability of the sender's source of messages is something that can be done on a security protocol that is still vulnerable to replay and man-in-the-middle attacks.In this concise authentication protocol, the tapping results will not work because the attacker does not have its encryption key.So the attacker cannot get the actual message and cannotbrowse the message source.It also supported earlier analysis that the concise authentication protocol designed was immune to replay and man-in-the-middle attacks.

Replay Attack Protection
This protocol has been shown to be resistant to replay attacks based on test results using a Scyther tool.

Man in the Middle Attack Protection
This protocol has been shown to be resistant to man-in-the-middle attacks based on test results using a Scyther tool.

Wearable Device/Mobile Terminal Impersonation Attack Protection
An attacker to be able to forge WD or MT must have items that play an important role in determining the success of each device/user authentication process.However, even though the attacker has stolen WD/MT and performs a power analysis, the attacker still does not get any useful items to attack authentication success, so the attacker's attempt to falsify identity against the device/user will not work either.In addition, the designed protocol has to scenario that in the Phase Pair and Mutual Authentication stage it can only run with the obligation of a legitimate User to operate it, as K WDT , K MTT , PWD WD , and F_inf u in the protocol are required, and only legitimate Users have it.So there is no chance for an attacker to fake WD/MT, because running the protocol cannot.In addition, the process of comparing the hash value h(Rand CS ||h(PWD WD )) and h(Rand CS ||h(F_Inf U )) occurs within the cloud, where the attacker will not be able to encounter that phase let alone manipulate it. T calculates the value of Ks (T), to be used in Step 5  CS gets KS, hash value of H(PWDWD), B_AddrWD , NT , WD, and IDT. CS will authenticate WD if it is registered on the Registration, and also to obtain a valid MT pair in accordance with table_Registration_User, in the following way: SELECT ID_MT, B_WD FROM tabel_Registrasi_User WHERE B_WD=B_AddrWD AND P_WD=H(PWDWD) AND CsWd=H(RandomCS||H(PWDWD))  If the result does not exist, then the protocol stops and authentication stages on Sub Stage 1 fails. If the result is there, then with sourced from table_Registrasi_User, CS will get valid data that is ID_MT (IDMT) and B_WD (B_AddrWD) which is a legitimate WD pair. Then, the protocol proceeds to Step 3. WD←CS∶ EKs (CS||IDT||3) Step 3  CS calculates Ks (CS|| IDT) to be required in Step 4.
 WD gets NCS and IDT, so that CS and T have been authenticated by WD.WD→CS ∶ Ks (CS||IDT) Step 4 CS→T ∶ Ks (T) Step 5  In step 4, CS compares the previously computed MAC results, with results received from WD.If the result is the same, then the WD has been authenticated by CS and the protocol is proceeded to step 5, to authenticate CS by T. After all done, then the protocol can proceed to Sub Stage 2. Step 1  IDWD and B_AddrWD were previously obtained from CS, which took place on the previous Sub Stage 2.

𝑇→WD∶EKWDT(KS||B_AddrWD||NT||IDMT||IDT||t2)|| 𝐻(KS||B_AddrWD||NT||IDMT||IDT||t2)
Step 2  T calculates the value of Ks (T), to be used in Step 5.  WD gets KS, B_AddrWD , NT , IDMT and IDT  To authenticate that MT is the right smartphone pair of WD, then WD will compare the Bluetooth address on WD with the B_AddrWD earned. If the value of B_AddrWD compared of the WD Bluetooth address is not the same, then the protocol stops and Sub Stage 3 fails.Then, WD will display on screen "Refuse". If the value of B_AddrWD compared of the WD Bluetooth address is the same, then the protocol can proceed to Step 3. MT←WD∶ EKs (WD||IDT||3) Step 3  WD calculates Ks(WD||IDT) to be required in Step 4.  MT can get NWD and IDT, so that WD and T have been authenticated by MT.MT → WD ∶ Ks (WD||IDT) Step 4 WD → T ∶ Ks (T) Step 5  In step 4, WD compares the previously computed MAC results, with results received from MT.If the result is the same, then the MT has been authenticated by WD.Then, WD will display on the "Accept" screen.Then, the protocol proceeds to

User Impersonation Attack Protection
The lightweight authentication protocol designed has already demonstrated that the Phase Pair and Mutual Authentication stage can only work with legitimate Users operating it, as K WDT or K MTT , PWD WD , and F_inf u inputs are required in the protocol, as a requirement for the protocol to function.Then it is only the legitimate User who owns it.So with the existence of such specification, forgery of User cannot be done.

Denial-of-Service Attack Protection
A DoS attack can be done with the condition that an attacker can insert certain steps into the protocol to prevent the protocol from failing or unable to provide service.However, these conditions cannot be attackers do, because the attacker can only insert if the protocol has man-in-the-middle weakness, but it has been proven that this lightweight authentication protocol is immune to replay and man-in-the-middle attacks.So the attacker can not do the DoS attacks.

Use of Non-Tamper Resistant Wearable Device
Not discussed in this study.

Support of Password Update Phase
The activity description of "Upd_pwd_WD" allows this protocol to have the feature of Password WD Update, which occurs at the registration stage.

Support of Dynamic Users Addition Phase
The activity description of "Insert" allows this protocol to have the feature of adding User, which occurs at the registration stage.

Support of Replacing Wearable Device Phase
The activity description of "Upd_WD" allows this protocol to have the feature of Replacing WD, which occurs at the registration stage.

Support of Replacing Mobile Terminal Phase
The activity description of "Upd_MT" allows this protocol to have the feature of Replacing MT, which occurs at the registration stage.

Support Adding Wearable Device
The activity description of "Insert" allows this protocol to have the feature of adding WD, which occurs at the registration stage.

Support Adding Mobile Terminal
The activity description of "Insert" allows this protocol to have the feature of adding MT, which occurs at the registration stage.Thus, based on the designs performed and the resulting security analysis, the proposed lightweight authentication protocol has the functionality described in Table 9, as follows:

Conclusion
This study has the following conclusions: a) The lightweight authentication protocols in the wearable communication environment generated in this study are immune to mobile terminal stolen attack, wearable device stolen attack, replay attack, user/wearable device/mobile terminal impersonation attack to supplement the lack of security functionality in previous lightweight authentication protocols; b) The lightweight authentication protocols in the wearable communication environment generated in this study have been shown to be safe against replay attacks and man-in-the-middle attacks and meet all formal analysis criteria in the Scyther Tool; c) The lightweight authentication protocol in the wearable communication environment generated in this study has two new functionalities that add wearable device and add smartphone.

Figure 1 .
Figure 1.Forecasted value of the global wearable devices market from 2012 to 2018 [8]

Figure 2 .
Figure 2. Step research flowchart illustrates the proposed lightweight authentication protocol authentication model, which consists of four key entities: User, Smart Device (smart phone and smart watch), Cloud Server, and a Key Translation Center (KTC).

Figure 3 .Figure 4 .
Figure 3. System initialization on the lightweight authentication protocol

Figure 5 .
Figure 5. Lightweight authentication protocol registration phase

3. 1 . 3 .
Phase Pair and Mutual Authentication Phase Pair and Mutual Authentication consists of three sub-stages, namely Sub Stage 1 (WD Authentication by CS), Sub Stage 2 (MT Authentication by CS), and Sub Stage 3

Table 2 .
Characteristics of Lightweight Authentication Protocols in a Wearable Communications Environment

Table 3 .
Weakness Analysis of the Protocol and Alternative Protocol Development Steps

Table 4 .
Stages of the S-NCI Protocol Before and After Modification

Table 7 ,
are as follows.

Table 5 .
Notations and Definitions of the Lightweight Authentication Protocol

Table 6 .
Explanation of the Registration Phase

Table 7 .
Registration Result Stored in Table in CS (table_Registration_User)

Table 9 .
Results of Protocol Security Functionality